{"id":17968,"date":"2020-03-17T20:38:47","date_gmt":"2020-03-18T04:38:47","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2020\/03\/17\/news-11701\/"},"modified":"2020-03-17T20:38:47","modified_gmt":"2020-03-18T04:38:47","slug":"news-11701","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2020\/03\/17\/news-11701\/","title":{"rendered":"\u201cDouble agent\u201d: a MacOS bundleware installer that acts like a spy"},"content":{"rendered":"

Credit to Author: Sergei Shevchenko| Date: Tue, 17 Mar 2020 08:00:58 +0000<\/strong><\/p>\n

\n

Security software frequently blocks \u201cbundleware\u201d installers – software distribution tools that bundle their advertised applications with (usually undesired) additional software – as potentially undesirable applications. But one widely-used software distribution tool for MacOS applications goes to great lengths to avoid being blocked as \u201cbundleware\u201d – using a number of anti-forensics techniques that are more common in malware code. The installer is from a legitimate company, which claims to reach over 1 billion users per month with its various downloaders and adware platforms.<\/p>\n

This software attempts to evade blocking by endpoint protection systems with anti-debugging code, strings and API encryption, runtime decompression and virtual machine detection. Its developers went as far as to embed a full backdoor-like component into the installer that allows remote injection of new code into the installer – granting it capabilities that extend far beyond what one might expect from a piece of installation software.<\/p>\n

This particular bundleware has potential access to a large number of Macs around the world. The power given to the installer practically enables full control over the target system. Even if this was done so that the company behind it would have ‘advanced analytics’ or the ability to push any third-party software it wants, given the amount of power it aggregates, what happens if this power is abused?<\/p>\n

We’re not naming the company or the installer here because of its wide distribution; this research is entirely focused on technical aspects of the reverse-engineered software. The developers have been contacted by researchers, but have shown no interest in changing what they see as a feature of their installer, as long as it allows them to monetize the installations of their software.<\/p>\n

The allure of bundleware<\/h3>\n

MacOS application developers use third-party installers for a number of reasons. One of the reasons often given is the desire to improve the overall “user experience” of software installation. Many developers turn to application installation platforms because they promise enhanced installation analytics, an optimized footprint, and a guaranteed smoothness of installation.<\/p>\n

But these installers offer another attraction that is more important to many developers: the promise of monetization. Developers or websites distributing freeware (such as free games) or software based on open source components may not be able to charge for the applications, but they can capture some revenue by teaming with a third-party installation tool.<\/p>\n

Some of these application installation platforms bundle the title application with third-party software such as adware or browser toolbars, leading to a setup that the end-user might find unwanted. Once the target application is installed, users often encounter undesirable consequences, such as installed browser hijackers that modify the search engine for their web browser. In some cases, these inject messages for “scare-ware” removers that prompt the user to pay for the removal of non-exist threats.<\/p>\n

Apple actively combats these types of unethical applications, which the company labels as ” suspicious software<\/a> .” In 2019, starting with macOS 10.14.5 (Mojave), Apple began requiring application developers to submit their code for ” notarization<\/a> “, and blocking applications without notarisation or with revoked developer signatures by macOS’s Gatekeeper<\/a> . Apple can revoke notarisation and the developer accounts associated with applications that are found to be abusive. But bundleware installers may not get flagged as “suspicious” in the notarization process.<\/p>\n

Detecting bundleware is almost never a problem for endpoint protection systems – it’s a much more simplistic breed, so to speak, than malware. But the bundleware package we examine here, already blocked by a number of endpoint protection tools as a potentially unwanted application, adopts many anti-forensics and counter-detection techniques that have in the past been found mostly in malware.<\/p>\n

The Application<\/h3>\n

The bundleware described in this post is a Cocoa application – an application built with the AppKit<\/a> framework, and is distributed as an application bundle<\/a> .\u00a0From sample to sample, the name of the main executable varies. For example, it can be named as radiosurgical<\/code>or Herculid<\/code>.<\/p>\n

The digital signature used to sign the app varies, as this is generated by the developer packaging the application with the installer. Some observed installers are signed by \u201cOwen Bell\u201d. Some other installers were found to be signed by \u201cRuiQing Software Technology Beijing Inc.\u201d or \u201cAVSoftware EOOD\u201d.<\/p>\n

The main executable<\/h3>\n

Compiled as Mach-O (the native executable file format for macOS), the main executable relies on Objective-C runtime libobjc.dylib<\/code>. When the kernel first loads the main executable, it makes sure that the executable is a valid Mach-O file, and then examines its mach_header<\/code>structure.<\/p>\n

Next, it loads the dynamic linker to load all the shared libraries that the main executable links against.\u00a0The dynamic linker then initializes the Objective-C runtime, and then calls the program’s main ()<\/em> function.<\/p>\n

However, the main executable’s entry point starts from garbage bytes – that is, it has no valid code to execute:<\/p>\n

__text: 0000000100001150 04 <\/span>     start<\/span>     db     4<\/span>    __text: 0000000100001151 4A<\/span>                db     4Ah<\/span> ; J   __text: 0000000100001152 3E<\/span>                db     3Eh<\/span> ; ><\/pre>\n
With no valid code at the entry point, how does it run without crashing?\u00a0The answer lays in Objective-C’s concept of non-lazy<\/em> (‘eager’) and lazy<\/em> (‘on-demand’) implementation of classes.<\/p>\n
Non-lazy<\/em> classes are realized when the program starts up. These classes will always implement + load<\/em> method.\u00a0Contrary to that, lazy<\/em> classes (classes without + load<\/em> method) do not have to be realized immediately, but only when they receive a message for the first time (hence the term ‘lazy’).<\/p>\n
\/\/ Realize non-lazy classes (for + load methods and static instances) <\/span>  for<\/span> (EACH_HEADER) {       classref_t<\/span> * classlist = _getObjc2NonlazyClassList (hi, & count);      for<\/span> (i = 0; i <count; i ++) {           realizeClass (remapClass (classlist [i]));       }   }  <\/pre>\n
GETSECT (_getObjc2NonlazyClassList,    \/\/ function name <\/span>           classref_t<\/span> ,                  \/\/ content type <\/span>           \"__objc_nlclslist\"<\/span> );         \/\/ section name - 'nl' stands for non-lazy<\/span>  <\/pre>\n
In the case of our bundleware executable, the __objc_nlclslist<\/code>data section of the main binary is very small. It enlists only two non-lazy<\/em> classes: ListedUpaithric<\/code>and __ARCLite__<\/code>:<\/p>\n
__objc_nlclslist: 0001000692C8     __objc_nlclslist segment para public 'DATA' use64<\/span>    __objc_nlclslist: 0001000692C8 dq offset _OBJC_CLASS _ $ _ ListedUpaithric<\/span>    __objc_nlclslist: 0001000692D0 dq offset _OBJC_CLASS _ $ ___ ARCLite__<\/span>    __objc_nlclslist: 0001000692D0     __objc_nlclslist ends<\/span><\/pre>\n
The ListedUpaithric<\/code>name, like many of the other class names in the executable, is random. For example, in another sample this class is called HoundingHusky<\/code>.<\/p>\n
These two non-lazy classes will be called in the order they’re listed, realized by their + load\u00a0<\/em> method.\u00a0\u00a0However, at first glance the + load<\/em> method of the __ARCLite__<\/code>class contains no valid code, because it is located within the __text<\/code>section of the executable – which is encrypted.<\/p>\n
Finding a secret agent<\/h3>\n
The + load<\/em> method of the ListedUpaithric<\/code>class is physically located in a section of the executable that has a random name, such as __amorpha<\/code>or __mottled<\/code>. Once run, the + load<\/em> method will take a 32-byte XOR key hard-coded in the body and then use that key to decrypt the __text<\/code>section (around 15KB in size) of the executable, including the + load<\/em> method of the __ARCLite__<\/code>class.<\/p>\n
The decryption routine relies on a special anchor stored in the __text<\/code>section. The virtual address of this anchor is used to describe the virtual address and virtual size of the encrypted __text<\/code>section.<\/p>\n
For example, in this particular sample, the anchor can be located at the virtual address 0x100001CF0<\/code>, as shown below:<\/p>\n
__text: 000100001CF0 23        anchor <\/span>      db 23h<\/span> ; #      ; DATA XREF: decrypt_code + 101<\/span>    __text: 000100001CF1 2B                     db 2Bh<\/span> ; +   ...<\/pre>\n
The decryptor uses the address of the anchor to describe the parameters of the __text<\/code> section. In the snippet below, the decryptor makes the __text<\/code> section writable and executable, by assigning a new protection to it. To do that, it takes the address of the anchor 0x100001CF0<\/code> and subtracts 0xBA0<\/code> from it to locate the start of the __text<\/code> section – 0x100001150<\/code>:<\/p>\n
vm_protect (mach_task_self (),          \/\/ decoded stings: 'vm_protect', 'mach_task_self_'<\/span>                ( char<\/span> *) & anchor - 0xBA0,    \/\/ 0x100001150 -> start of the __text section<\/span>                0x37F2,                    \/\/ size of the entire __text section: 14,322 bytes<\/span>               0 ,               VM_PROT_ALL)               \/\/ assign read, write, and execute access rights<\/span>  <\/pre>\n
Once the entire __text<\/code>section is decrypted, the anchor shown above gets decrypted into the following text:<\/p>\n
__text: 000100001CF0 MaximMaximovicIsayev db ' Maxim Maximovich Isayev<\/span> ', 0<\/span><\/pre>\n
The resulting text is the same across all the samples we’ve looked at, and is quite interesting by itself.\u00a0Maxim Maximovich Isayev (\u041c\u0430\u043a\u0441\u0438\u043c \u041c\u0430\u043a\u0441\u0438\u043c\u043e\u0432\u0438\u0447 \u0418\u0441\u0430\u0435\u0432) is the Russian name of Max Otto von Stierlitz, the lead character<\/a> in a popular Russian book series written in the 1960s, and of the most popular Soviet television series ever, Seventeen Moments of Spring<\/em> .<\/p>\n
\"\"<\/a>A Soviet James Bond<\/a> , Stierlitz takes a key role in SS Reich Main Security Office in Berlin during World War II. Working as a deep undercover agent within SS, he diverts the German nuclear “Vengeance Weapon” research program into a fruitless dead-end.<\/p>\n
Leaving a hidden marker like that could indicate an intentionally planted false flag. Regardless of the intention, this marker stays constant across the entire family of this bundleware.<\/p>\n
After the ListedUpaithric<\/code> class is called and decrypts the text, being next in line, the + load<\/em> method of the __ARCLite__<\/code> non-lazy<\/em> class is called to perform further initialization. The decrypted __text<\/code> section is quite small – it’s a valid code section containing a valid entry point in it, and it consists of another layer of decryptor and decompressor:<\/p>\n
__text: 0000000100001150             public start<\/span>    __text: 0000000100001150      start proc near<\/span>    __text: 0000000100001150 push    0<\/span>   __text: 0000000100001152 mov rbp, rsp   __text: 0000000100001155 and rsp, 0FFFFFFFFFFFFFFF0h<\/span>    __text: 0000000100001159 mov rdi, [rbp + 8<\/span> ]<\/pre>\n
With both non-lazy<\/em> classes realized, the entry point above receives control. From there, the main ()<\/em> function of the executable is called, followed with _exit ()<\/em> .<\/p>\n
The main () function<\/h3>\n
Once the entry point within __text<\/code>section is called, the main ()<\/em> function that follows it will read an internal chunk of data with the size of ~ 300KB.<\/p>\n
This encrypted data is stored in a separate section of the executable.<\/p>\n
The data will be read, its CRC32-based hash validated, then decrypted and further decompressed into a buffer, allocated with vm_allocate ()<\/em> function.<\/p>\n
The decompression is achieved by dynamically loading libz.1.dylib<\/code> library, and calling uncompress ()<\/em> API from it.<\/p>\n
The decompressed data has a size of ~ 800Kb, having a format of Mach-O executable ( MH_BUNDLE<\/code> type). This data is loaded from memory as a plugin with the help of NSCreateObjectFileImageFromMemory ()<\/em> and NSLinkModule ()<\/em> APIs.<\/p>\n
This method is equivalent to dynamic DLL loading on Windows. It is described on macOS man page<\/a> as a way to programmatically load plugins<\/a> after a program starts executing.<\/p>\n
The Engine<\/h3>\n
The loaded module represents itself an engine driven by the JavaScript files.<\/p>\n
Some of the scripts reside in the app’s Resources directory in an encrypted form, forming an SDK. Other JavaScript files are fetched from a remote server as tasks (internally called ‘offers’ as they are designed to offer \/ advertise other products).<\/p>\n
\"\"<\/a><\/p>\n
The downloaded tasks rely on high-level function calls from the SDK. This allows composing tasks with a very flexible logic.<\/p>\n
There are several classes exposed by the engine to the SDK, such as:<\/p>\n
Looking at the Objective-C Runtime’s source<\/a> in objc-file.mm<\/code>, one can see that _getObjc2NonlazyClassList ()<\/em> function collects non-lazy<\/em> classes from the __objc_nlclslist<\/code>data section:<\/p>\n
Let’s check out Objective-C Runtime’s own source,<\/a> found in objc-runtime-new.mm<\/code> file.\u00a0The snippet below realizes the non-lazy<\/em> classes, retrieved with _getObjc2NonlazyClassList ()<\/em> call:<\/p>\n