13-years in the wild and counting? macOS is still vulnerable to OSX.Fruitfly, which can easily be repurposed by other bad actors.
While malware hunters and the media naturally focus on the excitement of uncovering and discovering zero-day exploits and novel malware, some already-known threats remain an issue for users of macOS, even when running the latest, fully-updated builds.
Last year’s discovery of Fruitfly and the arrest of its alleged sole-developer and exploiter, Phillip R. Durachinsky, may have put minds at rest that this malware is no longer active. However, as we’ll see in this post, Fruitfly can easily be re-used by other attackers, and despite being discovered some 18 months ago after an unprecedented 13-year run in the the wild, it is not currently detected by Apple’s XProtect or removed by their MRT (Malware Removal Tool).app.
Recap: What is Fruitfly?
Fruitfly is a remote exploitation tool (RAT) that can be used to do pretty much whatever the attacker chooses. According to the indictment against Durachinsky, the malware has
“the ability to control a Fruitfly victim’s computer by, among other things, accessing stored data, uploading files to a Fruitfly victim’s computer, taking and downloading screenshots, logging a user’s keystrokes and turning on the camera and microphone to surreptitiously record images and audio recordings.”
All in a day’s work for a decently-crafted RAT, but Fruitfly has some special characteristics.
First, it may well hold the record for malware longevity on macOS. As was widely noted at the time of its discovery, Fruitfly – written in Perl, itself an unusual trait – had been active in the wild since 2003, miraculously evading discovery until January 2017. This is despite the fact that, again according to the Federal indictment, Fruitfly’s author allegedly
accessed protected computers owned by local, state and federal governments, a police department, schools, companies and individuals.
Second, as demonstrated in a VirusBulletin white paper by Patrick Wardle, Fruitfly allows the attacker to specify an IP address and port on the command line and doesn’t contain any hard-coded server addresses. This is unusual. Attackers are unlikely to expect victims to type in the IP address and port manually. Indeed, except in rare cases, victims are normally not so obliging to run code from the command line at all!
While this may have been due to Fruitfly’s infection vector (or vectors), which to this day remain unknown, evidence from the code itself suggests that it was at least partially a convenience feature for the malware author to debug his own code. As can be seen from the attached images, the code is obfuscated to hamper reverse engineering. For example, instead of having helpful names for functions and such (say, ‘getScreenshot’), the author used a system of single letters and numbers to denote functions, arguments, local variables and even path names.
The effect of this is to make the code harder to read and debug, and that holds true for the malware author as well as reverse engineers.
Notice, too, the use of the compiler directives ‘strict’ and ‘warnings’. This is standard (and good!) programmer practice to ensure clean code, but it necessitates spending considerable time debugging as warnings can appear to users when they try to run the developer’s code. Since there’s no $SIG{__WARN__} function to handle calls from warn() in the script (which a developer could use to prevent users seeing the warnings), we can conclude that the directives were meant explicitly for testing. The fact that they weren’t removed later also means the programmer must have had high confidence in his work. That kind of confidence only comes from extensive testing. Based on that, it’s reasonable to assume that having the ability to test ‘at home’ by specifying a local IP address on the command line would have been highly useful during development.
Whether for that or some other reason, the ability to specify the server address on the command line has an unexpected payoff for low-skilled hackers who either can’t or don’t want to get into the business of editing binary files themselves or are unwilling to learn the intricacies of Perl programming. A hacker can take the original Fruitfly and use it “off-the-shelf” or “as-is” by simply adding their own server address when executing the script. In a moment, we’ll see exactly how easily that can be done.
Thirdly, as we’ve already mentioned, XProtect still doesn’t recognise the Perl script executable when downloaded inside an application bundle via a browser like Safari, and that leaves open the possibility of attackers simply “dropping” the malware inside other applications and distributing it themselves. In a test demonstration, that’s exactly what we did. Following Wardle’s detailed ‘how-to’ in VirusBulletin, we wrote a custom C&C server in Python. We then wrote our own custom malware dropper, with less than 20 lines of code, to show how easily someone with basic skills can take existing malware like Fruitfly and simply reuse it to compromise macOS.
Whither XProtect?
After the initial discovery of Fruitfly in 2017, Apple did indeed provide background updates in response to the malware. However, as far as we can tell, these updates only addressed files dropped by the Perl script rather than the script itself, and these were primarily directed at hard-coded path addresses used by the original developer.
These include the Launch Agent path (used for persistence) as well as the Macho binary and other components dropped in the user’s tmp folder after infection, and which give the attacker much of Fruitfly’s power. Crucially, those paths were added to MRT.app, which deals with removing malware at known locations upon system boot or restart, and not XProtect, which is tasked primarily with blocking known malware installers based on signature detection. A search for Fruitfly-related paths in the current version of MRT.app reveals several related lines:
However, the most recent update to XProtect at the time of writing was March 2018, and that did not include any new detections for the Fruitfly Perl script.
Bypassing Gatekeeper
However, that does leave one problem for the would-be malware recycler to solve. The infection vector or vectors of the original Fruitfly remain unknown, but anyone wishing to reuse the malware in a trojan installer or drive-by download has to find a way of getting their malware wrapper past Gatekeeper. There’s a number of possibilities, including using the command line and package managers, but we’ll look at the three most obvious ways to get through the “gate” of a browser-based, email or chat client download, most of which will trigger Gatekeeper protection.
In terms of time and resources, the most difficult would be to steal, phish or buy a real developer certificate. Cases of this are not unheard of, but they require some effort on the part of the attacker or a willingness to spend money. The second option is to look for a fake developer account on the internet. Sites such as the one shown below (sorry folks, no link!), invite people to create and share fake Apple Developer IDs:
The site is even helpful enough to gather visitor feedback on how successful each credential is and how long it’s been in use.
The third option, and the one we used in our demo, is to simply rely on the user’s willingness to install unsigned software. Users typically download software because it promises something they want, and no amount of “pulling up the drawbridge” by Gatekeeper is going to prevent the user from running unsigned software if they think that software is both safe and offers them something (they think that) they need. Unsurprisingly, a user’s judgement regarding safety is often compromised by the strength of their desire for the promised software: a well-known phenomenon hackers rely on with great success!
Installing and Running Fruitfly
Let’s walk through what happens on both the attacker’s machine and the victim’s machine during our test compromise.
First, our attacker starts an instance of the C&C server on his own machine and waits for the victim to come online:
Meanwhile, the victim downloads our unsigned malware application but chooses to override the Gatekeeper warning and run it anyway.
At that point, the victim is told the software is damaged and must quit. This approximates to what macOS should do when it detects malware, but in this case the message is a fake created by our dropper to convince the user to forget about the malware and move on. Of course, regardless of whether the victim chooses “Cancel” or “OK”, the malware still executes in the background:
Back on the attacker’s machine, after the victim dismisses the phoney alert, her Mac connects to the remote server, and the attacker begins to execute commands to control the target:
Throughout, the victim is totally unaware of the breach, but we can find indicators of compromise in the victim’s running processes and open files and ports, which reveal a perl script running out of a hidden folder on the user’s Desktop and a connection to the attacker’s c2 server:
How does this affect SentinelOne customers?
The ease with which old malware can be recycled and repurposed shows the inherent weakness of rule-based and signature-based detection systems like XProtect and MRT.app. Although these may find the original versions of the malware, they are unable to detect threats that behave in similar ways but which have different file names and different hashes. A multi-layered approach with behavioural AI that looks at how malware behaves – what it does, not what it is – is the only truly effective solution to meet the security challenges not only of today, but also tomorrow.
