Vvun91e0n · 2015/10/11 and. Appear
Original: www.virusbtn.com/virusbullet…
0 x01 attack
Now that we have a basic understanding of dylib hijacking in OS X, it’s time to take a look at real-world attack scenarios and offer some practical defenses.
Advanced hackers know the importance of automating as much of an attack as possible. Such automation can increase the scale and efficiency of attacks. Frees the attacker to focus on higher demands or more complex aspects of the attack.
The first automated component of a hijacking attack is the mining of program vulnerabilities. We use a Python script, dylibhijackscanner.py (download link [15]), to do this. After collecting the list of running processes and all executable programs on the system, the script intelligently analyzes the mach-O header structure and load commands of the binaries. To mine binaries that might be hijacked by weak dylib loading commands, the script tries to find LC_LOAD_WEAK_DYLIB loading commands that point to non-existent dylib files.
[email protected] Making files is a bit more complicated. First, the script looks for binaries that contain at least one LC_LOAD*_DYLIB load command pointing to the run-path dependent library. If such a load command is found, the script proceeds to analyze the load command of the binary file, looking for multiple LC_rpaths. If both prerequisites are met, the script continues to check to see if run-path-Denpendent Library is found in the first run-path search path. If the library does not exist, the script prompts the user that the program has a vulnerability. The execution of the program found a large number of vulnerabilities, of course, including our test program RpathApp.app.
Figure 33 Automatic vulnerability mining program
As you can see in Figure 33, the scan script found nearly 150 vulnerability binaries on the author’s computer. Interestingly, most bugs fall into the more complex ‘Multiple Rpath’ category. Due to space limitations, the full list of vulnerabilities cannot be presented here. But Table 1 lists several well-known programs that are widely used. These programs were scanned scripts that detected the Dylib hijacking vulnerability.
With tools to automatically exploit vulnerabilities, the next logical step is to automatically create a compatible hijacked Dylib. Recall two places that had to be manually updated in order to successfully hijack Dylib. The first is that the version number of hijack Dylib must be compatible with a legitimate dylib. The second (in the case of rpath hijacking) is that hijacking dylib must include a re-export (LC_REEXPORT_DYLIB) load command pointing to a valid dylib and ensuring that all required symbols are exported.
You can automatically modify the generated dylib to satisfy both conditions very directly. Here’s a second Python script, createhijacker.py (download 15), that does this. First, the script looks for and parses the relevant LC_ID_DYLIB load command for the target dylib (the legitimate dylib that the vulnerability loads). This will extract the required version compatibility information. The same parsing is then done for hijacked dylib until the LC_ID_DYLIB command is found. The script then updates the same load command of the hijacked script with the extracted compatibility information to ensure that the version information is compatible. Next, update the LC_REEXPORT_DYLIB load command that hijacks dylib to point to the target dylib. While updating the LC_REEXPORT_DYLIB load command can be done manually, using install_name_tool is easier.
Figure 34 shows the hijacked Dylib generated with automatic processing of Python scripts. The hijack dylib is used to hijack the rPathapp. app sample program.
Figure 34 Automatic generation of hijack dylib
Dylib hijacking can be used to implement a large number of malicious acts. This article covers some of them, including covert resident, load-time injection, security bypassing, and even bypassing Gatekeeper. These attacks, while dangerous, can be carried out with a simple implant of malicious dylib that takes advantage of the legitimate behavior of the system loader. That’s why it seems so trivial that it’s unlikely to be patched, or detected by personal security software.
Dylib hijacking is one of the most important functions of this attack. If a vulnerability program can run automatically when the system is turned on or the user is logged in, a local attacker can use dylib hijacking to implement automatic startup execution of malicious code. In addition to being able to implement a new resident approach, this approach also does a good job of hiding attackers. First, you only need to populate a simple file without updating system components (such as startup configuration files or signed system files). This is important because these components are generally monitored by security software or require simple validation. Second, the attacker’s dylib will be injected into a trusted process, which makes it hard to detect because it won’t show much difference.
Of course, achieving such a stealthy and elegant residency requires a program with a hijacking vulnerability launched along with the system. Apple’s up Photo Stream Agent (/ Applications/am app/Contents/Library/LoginItems / Photostreamagent.app starts automatically when a user logs in to synchronize local data with the cloud. Fortunately, this program contains multiple run-path search directories and says in the first run-pa[email protected] that this is an excellent target for hijack attacks.
Figure 35. Apple’s buggy photo stream tool
Using the createhijacker.py script, you can easily update the maliciously hijacked Dylib configuration to be compatible with the target dylib and program. Be careful in this example, because the compromised import (‘PhotoFoundation’) is in a framework bundle (Framework bundle shown in Figure 35), So need to regenerate the packaging files and then placed in the first run – path search directory (/ Applications/libraries. The app/Contents/Library/LoginItems /). When the package file is placed correctly and the malicious hijacked Dylib (renamed ‘PhotoFoundation’) is placed in the first run-path search directory, the loader will find and load the malicious Dylib when the iCloud Photo Stream Agent starts. Since the program is launched by the system, hijack Dylib can be secretly launched after reboot.
Figure 36 hijacking Apple’s photo stream tool for resident purposes
One final point to note about resident is that any program that contains a vulnerability that can be manually launched by the user (e.g. browser, mail client, etc.) can be targeted if no vulnerability program is found to automatically start with the system. In other words, any normal program can easily become a self-starter by various means (such as registering as a Login Item). And then use it again. While this approach increases the likelihood of attack exposure, the attacker’s dylib prevents any interface from appearing on the screen. Most users will not notice that a legitimate program is running automatically in the background.
Process injection, or forcing a process to load a dynamic library, is another useful method of dylib hijacking. In this article, ‘injection’ stands for load-time injection (when the program starts at any time) rather than runtime injection. The latter might seem more powerful, but the former is simpler and can do the same amount of damage most of the time.
Using dylib hijacking to force an external process to load a malicious dylib is a stealth and powerful technique. In contrast to other large dylib hijacking techniques, it does not require any modifications to operating system components or programs (such as patching target process files). Also, because the embedded Dylib is automatically and surreptitiously loaded into the target process every time it starts, the attacker does not need any monitor components (to detect whether the target process is started and then inject the malicious library). Because attackers only need to implant malicious hijacked Dylib, it is much easier than complex runtime injection. Finally, because injection technology is a legitimate feature of the operating system loader being used, it is not easily detected by security software (which prevents remote process injection by monitoring the ‘Inter-process’ API).
Xcode is Apple’s integrated development environment (IDE). Developers use it to create OS X and iOS apps. As such, it is a favorite target for advanced hackers who may want to inject code into the IDE and then quietly infect developers’ products (for example, as an innovative automated malware distribution model). Xcode and several of its ancillary tools are vulnerable to dylib hijacking attacks. In particular, run-path-dependent dylibs such as DVTFoundation are not in Xcode’s first run-path search directory, as shown in Figure 37.
Figure 37 Vulnerability in Apple IDE Xcode
Process injection into Xcode is straightforward. First, a hijacked dylib is configured. Its version information is compatible and its re-exported points to all symbols of the legitimate DVTFoundation. And then, Will be configured dylib copy to/Applications/Xcode. The app/Contents/Frameworks/DVTFoundation framework Versions/A/(Frameworks/was the first run – path search directory ). Now, once Xcode is started, malicious code is automatically loaded. You are then free to perform any functions, such as interrupting build requests and quietly embedding malicious code into the final product.
As Ken Thompson wrote in Reflections on Confessing Trust [16], you can’t confide in your own code when you can’t Trust your own compiler.
Figure 38 Process injection via dylib hijacking.
In addition to clandestine resident and load-time injection, dylib hijacking can also be used to bypass personal security software. With dylib hijacking, an attacker can cause a trusted process to automatically load malicious code and then perform actions that were previously blocked or warned against and now go undetected.
Personal security products (PSPs) use signature codes, heuristic behavior analysis to detect malicious code, or simply pop up a warning when a user performs an action. Because dylib hijacking is a relatively new technique that exploits the legitimate functionality of the system, both feature-based and heuris-based products can be easily bypassed. Security products, such as firewalls, warn the user that any exit connection from an unknown process poses some challenge to the attacker. Dylib hijacking could easily beat this product, too.
Personal firewalls are popular on OS X platforms. They typically use algorithms that fully trust egress network connections from known programs and warn users of network activity from unknown and untrusted processes. This works well for detection-based malware, but sophisticated hackers can easily find their weak spot: trust. As mentioned earlier, such products generally have a default configuration rule that allows users to create new rules for known trusted processes (for example, allowing any exit connections from process X). But this requires that legitimate functionality not be broken. If an attacker can implant malicious code into a trusted process, the code inherits the trusted attributes of the process, so the firewall will allow its exit connections.
GPG tool [17] is an information encryption tool under OS X platform, providing key management, sending encrypted emails, or through plug-ins, providing encryption services to any program. Unfortunately, it also suffers from the Dylib hijacking vulnerability.
Figure 39 Keychain programs with vulnerabilities in the GPG tool set
Because a GPG Keychain requires various Internet functions (such as getting keys from a key server), it basically has a ‘allow any exit connection’ rule. As shown in figure 40.
Figure 40 Access rules for the GPG Keychain
Using dylib hijacking, an attacker can load a malicious dylib into the address space of a GPG Keychain program. So the dylib will inherit the same trust level as the process, so it can initiate an exit connection without raising any alarms. The test results show that hijack Dylib can have unlimited access to the Internet. As shown in figure 41.
Figure 41 Bypassing the personal firewall with dylib hijacking (LittleSnitch)
Some defensive-minded people will accurately point out that, in this case, firewalls can be made more stringent against GPG Keychain rules to defend against attacks. Only exits are allowed to connect to specific remote ports (such as known key servers). However, there are many vulnerabilities that can be hijacked to gain equally unrestricted access to the network. Or, in this case, the Little Snitch firewall by default allows any process to connect to the iCloud.com port, and this rule cannot be removed at the system level. This is enough to circumvent the firewall (for example, using a remote iCloud iDrive as a C&C server).
So far, the dylib hijacking methods have been introduced. You can see how powerful, elegant, and secretive they are. But they all need access to the user’s computer. However, dylib hijacking can also be used by remote attackers to help gain easier control of a remote computer.
There are many ways to infect a Mac, but the simplest and most reliable is to send malicious content directly to the target. This lower-end approach lets the user manually download and install a malicious file. Attackers can use a variety of creative techniques to achieve their goals, such as providing needed plug-ins, fake upgrades or patches, fake security tools, or an infected seed file.
Figure 42 disguised malicious content
If users are tricked into downloading and executing any malicious files, they become infected. Low end technology, but the impact of this technology is significant. For example, when a fraudulent security software called Mac Defender spread in this way, thousands of OS X users were infected and AppleCare received over 60,000 requests to handle the infection [18].
Trickery to infect remote targets is less effective at targeting people with computer security knowledge. A more reliable (though more advanced) technique is man-in-the-middle attacks when users download legitimate software. Most apps are still downloaded through the developer’s or company’s website because of restrictions in the Apple Store. If such software is downloaded over an insecure connection (e.g., HTTP), an attacker with access to the transport network can infect the downloaded files during the transfer. When users run the infected software, their computers become infected, as shown in Figure 43.
Figure 43 Download process of man-in-the-middle attack
Readers might be thinking, it’s 2015, and most software is downloaded through secure channels, right? Unfortunately, even today, most third-party software is distributed through insecure channels. On my computer, for example, 66% of the software was downloaded from unsecured sources.
Figure 44 software downloaded via HTTP protocol on the author’s machine
Further research shows that almost all secure software on third-party OS X platforms is downloaded using insecure methods, as shown in Figure 45.
Figure 45 Insecure downloads of most security products on OS X platforms
Apple is aware of the dangers of these attacks. Starting with OS X Lion (10.7.5), Mac computers have a built-in security software called GateKeeper to directly defend against attacks.
The concept of Gatekeeper is simple, but effective: it prevents any untrusted software from executing. It’s still a bit complicated to implement behind the scenes, but for the purposes of this article, a general explanation will suffice. When any executable file is downloaded, it is marked with a quarantine property. Gatekeeper validates this file the first time it is executed. Depending on the user’s Settings, Gatekeeper will not allow the application to execute if the software is not signed with a known Apple developer ID (the default), or if it is not from the Apple Store.
Figure 46 Gatekeeper execution
With the new version of OS X automatically installing and turning on Gatekeeper, methods of tricking users into installing malware or unsafe downloads of infected files, which break digital signatures, have largely gone out of the window. (Of course, attackers may try to obtain a valid Apple developer certificate and then sign their malware. However, Apple is careful about distributing such certificates, and has a valid certificate revocation program that blocks certificates if it detects any certificate abuse. Also, if it is set to only allow software from apple’s App Store, this abuse situation is not possible.)
Unfortunately, using dylib hijacking allows attackers to bypass Gatekeeper and execute unsigned malicious code, even if user Settings are set to allow only signed code from the Apple Store. This reopens the door to previous attacks and puts OS X users back at risk.
In theory, bypassing Gatekeeper through dylib hijacking is logical. While Gatekeeper fully validates the contents of the executing software package (for example, every file in the application package), it does not validate the “external” components.
Figure 47 theoretically both DMG and ZIP files can bypass Gatekeeper
Usually, this is not a question, why would an application that downloads (legal) applications load relative external code? (Hint: Not external files, relative.)
Because Gatekeeper only validates internal content, an attacker can bypass Gatekeeper if an Apple-signed or incoming app contains a relatively external dylib that can be hijacked. Specifically, an attacker can generate (or infect in transit) a.dmg or.zip file that has the necessary folder structure to contain malicious dylib in an external relative location. When a legitimate program is executed by a trusted user, Gatekeeper validates the package and allows it to execute. During the process load phase, dylib hijacking is triggered and the associated external malicious Dylib is loaded, even though Gatekeeper is set to only allow the execution of programs from the Apple Store!
It’s also easy to find a bug that meets the prerequisites. App is an Apple signed Gatekeeper approved program installed in a subdirectory of Xcode.app. It relies on associated dylibs outside the package, which can then be hijacked.
Figure 48 Apple’s Instruments app with the bug.
Gatekeeper can be bypassed by a malicious.dmg file with a trusted program that contains vulnerabilities. First, Instruments. App is packaged into the file. Then, the establishment of A dynamic library contains malicious external folder structure (CoreSimulator. Framework Versions/A/CoreSimulator).
Figure 49 Malicious. DMG file
To make malicious.dmg files more trusted, external files can be set to hide, with the top alias (and a user icon) pointing to Spasinstruments. App. The background is also replaced, and the entire file is set to read-only (all double-clicks are automatically displayed). The final result is shown in Figure 50.
Figure 50 final malicious. DMG file.
Upload the malicious.dmg (though seemingly harmless) file to a public URL to test it. When downloaded from Safari and executed, the Gatekeeper standard ‘This is Downloaded from the Internet’ message window pops up. The important thing is that this message will pop up for any downloaded content, it is not an exception.
Once the message window is canceled, the malicious code is quietly loaded along with the legitimate program. Of course, this shouldn’t be done, because Gatekeeper is the most stringent setup (only apps downloaded from the Apple Store are allowed to be executed). As shown in figure 51.
Figure 51 bypassing Gatekeeper through dylib hijacking
Because malicious dylib loads and executes before the program’s main method, it can be implemented without showing any Windows. In this case, the malicious.dmg file masquerades as a Flash installation package, and the malicious dylib prevents the instpictures. app interface from popping up. Instead, there is a legitimate Flash installation package.
With the technology to bypass Gatekeeper and load malicious code as signatures, attackers can fall back on their old tricks to get users to install fake patches, update packages or install packages, fake antivirus products, or infected pirated programs. To make matters worse, sophisticated hackers with net-level hacking techniques (hackers who can sever unsecured connections) can now infect legitimate software downloads at will. There is no need to worry about Gatekeeper anymore.
0 x02 defense
Dylib hijacking is a powerful new attack technique for the OS X platform, giving local and remote attackers a wide range of malicious attack methods. Unfortunately, apple has not expressed any interest in the issue despite repeated attempts to contact them. Also, there is no easy way to solve the core problem of dylib hijacking, since it is a legitimate feature of the operating system being exploited. However, the author of Gatekeeper should patch Gatekeeper to prevent unsigned malicious code execution.
Users may wonder what they can do to protect themselves. First, until Gatekeeper is fixed, it is not recommended to download untrusted software or legitimate software through insecure channels (e.g., HTTP over the Internet). One thing that can be confirmed by reviewing the previous content is that remote attackers cannot access a new computer using the methods described in this article. Since dylib hijacking is so new on OS X, it’s unlikely that an attacker or OS X malware could use it locally right now, and in any case, it won’t hurt anyone.
Dynamic Hijack Scanner(or DHS) is a new program developed by the author in order to detect local Hijack and exploit vulnerabilities. DHS tries to find hijacking attacks and vulnerabilities by scanning all running processes throughout the file system. The program can be downloaded at objective-see.com.
Figure 52 Objective-see DHS scanner
0 x03 summary
DLL hijacking is a well-known attack that affects Windows systems. OS X was previously thought to be immune to such attacks. But this paper overturns this assumption. Simulated Dylib hijack attack is demonstrated. Using weak dependencies or run-path-Denpendent imports to find a large number of vulnerabilities in Apple and third-party applications, this attack technique can be used in a variety of attack scenarios, including local and remote attacks. Dylib hijacking is becoming a powerful weapon in the hands of OS X hackers, from local crypto resident to Gatekeeper bypass that provides a shortcut to remote attacks. When Apple ignored the attack technology. Right now, OS X users can only download security software and tools like DHS to keep themselves safe… But only now.
reference
[15] dylibhijackscanner.py & createhijacker.py. github.com/synack/.
[16] Reflections on Distrustful Trust. cm.bell-labs.com/who/ken/tru… .
[17] GPG tools.gpgtools.org/.
[18] Apple support to infected Mac users: ‘You always show the customer how to stop the process.’ nakedsecurity.sophos.com/2011/05/24/… .