Undetected Malware For Os X
Jul 01, 2019 Undetected Pirrit Malware Lurking In the Wild. As macOS is now much more common in the enterprise, and considering the relatively weak protection provided by the OS, malware actors clearly see the platform as a lucrative target. As cyber criminals are always looking for the weakest link, you should ensure all your macOS users, even if they. Disclosure: Creating undetected malware for OS X. The difference compared to a packer is that the decryption code is not present in the executable itself and so the static analysis engine can’t recognize a stub or base itself on other data present in the executable, since all segments can be encrypted. Disclosure: Creating undetected malware for OS X While this PoC is about static analysis, it’s very different than applying a packer to a malware. OS X uses an internal mechanism to load encrypted Apple executables and we’re going to exploit the same mechanism to defeat current anti-malware solutions.
This article was originally published on cerbero-blog.com on October the 7th, 2013.
While this PoC is about static analysis, it’s very different than applying a packer to a malware. OS X uses an internal mechanism to load encrypted Apple executables and we’re going to exploit the same mechanism to defeat current anti-malware solutions.
OS X implements two encryption systems for its executables (Mach-O). The first one is implemented through the LC_ENCRYPTION_INFO loader command. Here’s the code which handles this command:
2 4 6 8 10 12 14 16 | if(pass!=3) ret=set_code_unprotect( addr,map,slide,vp); printf('proc %d: set_code_unprotect() error %d ' p->p_pid,ret,vp->v_name); * encrypted but we failed to set up the psignal(p,SIGKILL); break; |
This code calls the set_code_unprotect function which sets up the decryption through text_crypter_create:
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 | #define APPLE_UNPROTECTED_HEADER_SIZE (3 * PAGE_SIZE_64) staticload_return_t uint64_t file_off, structvnode*vp, vm_map_t map, vm_map_size_t map_size) kern_return_t kr; * The first APPLE_UNPROTECTED_HEADER_SIZE bytes (from offset 0 of * this part of a Universal binary) are not protected.. */ file_off+file_size<=APPLE_UNPROTECTED_HEADER_SIZE){ kr=KERN_SUCCESS; if(file_off<=APPLE_UNPROTECTED_HEADER_SIZE){ * We start mapping in the unprotected area. */ delta=APPLE_UNPROTECTED_HEADER_SIZE; map_addr+=delta; } structpager_crypt_info crypt_info; crypt_info.crypt_ops=NULL; #pragma unused(vp, macho_offset) kr=vm_map_apple_protected(map, map_addr+map_size, } returnLOAD_FAILURE; returnLOAD_SUCCESS; |
Two things about the code above. The first 3 pages (0x3000) of a Mach-O can’t be encrypted/decrypted. And, as can be noticed, the decryption function is dsmos_page_transform.
Just like text_crypter_create even dsmos_page_transform is a function pointer which is set through the dsmos_page_transform_hook kernel API. This API is called by the kernel extension “Dont Steal Mac OS X.kext“, allowing for the decryption logic to be contained outside of the kernel in a private kernel extension by Apple.
Apple uses this technology to encrypt some of its own core components like “Finder.app” or “Dock.app”. On current OS X systems this mechanism doesn’t provide much of a protection against reverse engineering in the sense that attaching a debugger and dumping the memory is sufficient to retrieve the decrypted executable.
However, this mechanism can be abused by encrypting malware which will no longer be detected by the static analysis technologies of current security solutions.
To demonstrate this claim we took a known OS X malware:
Since this is our public disclosure, we will say that the detection rate stood at about 20-25.
And encrypted it:
After encryption has been applied, the malware is no longer detected by scanners at VirusTotal. The problem is that OS X has no problem in loading and executing the encrypted malware.
The difference compared to a packer is that the decryption code is not present in the executable itself and so the static analysis engine can’t recognize a stub or base itself on other data present in the executable, since all segments can be encrypted. Thus, the scan engine also isn’t able to execute the encrypted code in its own virtual machine for a more dynamic analysis.
Two other important things about the encryption system is that the private key is the same and is shared across different versions of OS X. And it’s not a chained encryption either: but per-page. Which means that changing data in the first encrypted page doesn’t affect the second encrypted page and so on.
Our flagship product, Cerbero Profiler, which is an interactive file analysis infrastructure, is able to decrypt protected executables. To dump an unprotected copy of the Mach-O just perform a “Select all” (Ctrl+A) in the main hex view and then click on “Copy into new file” like in the screen-shot below.
Core kg patcher for mac os sierra 10 12 6. The saved file can be executed on OS X or inspected with other tools.
Of course, the decryption can be achieved programmatically through our Python SDK as well. Just load the Mach-O file, initialize it (ProcessLoadCommands) and save to disk the stream returned by the GetStream.
A solution to mitigate this problem could be one of the following:
- Implement the decryption mechanism like we did.
- Check the presence of encrypted segments. If they are present, trust only executables with a valid code signature issued by Apple.
- 3. Check the presence of encrypted segments. If they are present, trust only executables whose cryptographic hash matches a trusted one.
This kind of internal protection system should be avoided in an operating system, because it can be abused.
After we shared our internal report, VirusBarrier Team at Intego sent us the following previous research about Apple Binary Protection:
http://osxbook.com/book/bonus/chapter7/binaryprotection/
http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/
https://github.com/AlanQuatermain/appencryptor
The research talks about the old implementation of the binary protection. The current page transform hook looks like this:
2 4 6 8 10 12 14 16 | if(v90x2E69CF40)// this is the constant used in the current kernel // current decryption algo else if(v9!=0xC2286295) // .. { ++some_bool; } } |
VirusBarrier Team also reported the following code by Steve Nygard in his class-dump utility:
This is the correct decryption code. In fact, the kernel extension by Apple, just as in the code above provided by Steve Nygard, uses the OpenSSL implementation of Blowfish.
We didn’t know about Nygard’s code, so we did our own research about the topic and applied it to malware. We would like to thank VirusBarrier Team at Intego for its cooperation and quick addressing of the issue. At the time of writing we’re not aware of any security solution for OS X, apart VirusBarrier, which isn’t tricked by this technique. We even tested some of the most important security solutions individually on a local machine.
The current 0.9.9 version of Cerbero Profiler already implements the decryption of Mach-Os, even though it’s not explicitly written in the changelist.
We didn’t implement the old decryption method, because it didn’t make much sense in our case and we’re not aware of a clean way to automatically establish whether the file is old and therefore uses said encryption.
These two claims need a clarification. If we take a look at Nygard’s code, we can see a check to establish the encryption method used:
The malware is currently being distributed to unwitting victims via an email phishing campaign. Currently, it’s mostly targeting users in western Europe, but the researchers added that it’s the first large-scale malware attack directed almost entirely at macOS users. The phishing campaign reportedly asks users to review inconsistencies in their tax returns, tricking them into running a malicious ZIP file. Because it’s an authenticated piece of malware, it bypasses Apple’s Gatekeeper security feature — which normally blocks such files from running.
Once installed on a machine, the malware creates a pop-up window claiming that a security issue has been discovered, asking for the user’s password. Once they do, the malware gains full administrative access, giving it the ability to install additional malicious tools — namely, TOR and SOCAT. DOK then installs a new root certificate on the macOS system, allowing attackers to impersonate any website that the victim might attempt to browse.
Os X Malware Scan
The end result is that attackers are able to carry out a Man-In-The-Middle attack, allowing them to view and tamper with a victim’s traffic. Reportedly, once it’s done attacking a system and setting up proxies, the original DOK malware deletes itself, making it even harder to detect.
Reportedly, Apple can resolve the issue fairly easily by revoking the authenticated developer certificate that is being used by the malware’s creators, according to The Hacker News. Most Mac users probably believe that they are far less susceptible to malware attacks than PC machines — but this is increasingly becoming untrue. According to McAfee Labs, malware attacks toward macOS computers skyrocketed 744% last year.
Undetected Malware For Os X 1
In the meantime, it’s highly recommended that users avoid clicking links or downloading files in messages or emails from unknown sources. Finally, exercise extreme caution before inputting your system’s root password into any software — no matter how legitimate it looks.