HandBrake Hacked!

› osx/proton (re)appears







love these blog posts? support my tools & writing on patreon ! Mahalo :)

infect3d ). Please don't infect yourself! Want to play along? I've shared the malware, which can be downloaded here (password:). Please don't infect yourself!

Background

Today started like pretty much every other day in Hawaii, surf & beach ;)However, around noon, Eric Holtam ( @eholtam ) tweeted the following:Mahalo to @mikeymikey to notifying me about this tweet!Handbrake is an 'open-source video transcoder.' Heading over to their website (handbrake.fr), we can see they've added a 'Security Alert' for Mac Users:Following the url, links to a rather dire security alert, Mirror Download Server Compromised



SECURITY WARNING

Anyone who has downloaded HandBrake on Mac between [02/May/2017 14:30 UTC] and [06/May/2017 11:00 UTC] needs to verify the SHA1 / 256 sum of the file before running it.





Anyone who has installed HandBrake for Mac needs to verify their system is not infected with a Trojan. You have 50/50 chance if you've downloaded HandBrake during this period.





Yikes!The security alert also provided a hash of the disk image (

0935a43ca90c6c419a49e4f8f1d75e68cd70b274

) that was trojaned by the hackers.Hopping over to VirusTotal, we can see that while this .dmg was submitted for analysis, no anti-virus engines are currently flagging it. No surprise there :|

Analysis

Once we have a copy of the infected .dmg (I've shared it here password: infect3d), analysis can commence. Since it's the weekend - I'm going to take the 'lazy' (efficient?) route and basically just run the infected application and see what happens :)In order to facilitate malware analysis I wrote a simple user-mode 'process monitor' library that allows us to easy track what application is doing - in terms of spawning other processes, etc:



ProcessMonitor* procMon = nil;



//block

ProcessCallbackBlock block = ^(Process* newProcess)

{

NSLog(@"new process: %@", newProcess);

};





//start monitoring!

procMon = [[ProcessMonitor alloc] init];

[procMon start:block];





//run loop

[[NSRunLoop currentRunLoop] run];



Running this code and executing the infected Handbrake application, we can see exactly what's going on:

[new process]

pid=1368

binary=/Volumes/HandBrake/HandBrake.app/Contents/MacOS/HandBrake

signatureStatus = "-67062 (unsigned)



[new process]

pid=1370

binary=path=/bin/sh

args: "-c", "pgrep -x activity_agent && echo Queue.hbqueue"



[new process]

pid=1371

binary=/usr/bin/unzip

args: "-P", "qzyuzacCELFEYiJ52mhjEC7HYl4eUPAR1EEf63oQ5iTkuNIhzRk2JUKF4IXTRdiQ", "/Volumes/HandBrake/HandBrake.app/Contents/Resources/HBPlayerHUDMainController.nib", "-d", "/tmp"



[new process]

pid=1372

binary=/usr/bin/open

args: "/tmp/HandBrake.app"





unzips Contents/Resources/HBPlayerHUDMainController.nib to /tmp/HandBrake.appâ€¨ . This 'nib' is a password protected zip file who's password is: qzyuzacCELFEYiJ52mhjEC7HYl4eUPAR1EEf63oQ5iTkuNIhzRk2JUKF4IXTRdiQ

launches (opens) /tmp/HandBrake.app

So yah, when run, the infected Handbrake application:Once the

/tmp/HandBrake.app

is launched, it displays a (fake) authentication popup - which is how the malware attempts to elevate its privileges:If the user is tricked into providing a user name and password the malware will install itself (

/tmp/HandBrake.app

) persistently as:

'activity_agent.app'

Thankful, BlockBlock can alert us of this fact:Dumping the Launch Agent plist file (

fr.handbrake.activity_agent.plist

), we can see the malware has been set to automatically start each time the user logs in:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>KeepAlive</key>

<true/>

...

<key>ProgramArguments</key>

<array>

<string>/Users/user/Library/RenderFiles/activity_agent.app/

Contents/MacOS/activity_agent</string>

</array>

<key>RunAtLoad</key>

<true/>



</dict>

</plist>



According to the HandBrake advisory, the malware's peristent component,

activity_agent.app

is a 'a new variant of

OSX.PROTON

Proton (variant 'A') was discussed earlier this year by the media (for example, see: "Hackers Selling Undetectable Proton Malware for macOS in 40 BTC" Though Apple released an XProtect signature for it, the sample was never publicly shared. However, the malware author was kind enough to describe ('advertise') its capabilties:With the HandBrake hack, finally now we have a variant for analysis :). Initial triage confirms, yes this a variant of OSX/Proton ('B'), although some of the features found in the 'A' variant, (such as the ability to take screenshots) are not present.Again, unsurprisingly this new variant of OSX/Proton is also currently undetected by any anti-virus engines on VirusTotal:Interested in the technical details of OSX/Proton? I wrote it in a new blog, "OSX/Proton.B (a brief analysis, at 6 miles up)"

Conclusions

a process named 'activity_agent'



an application name 'activity_agent.app in ~/Library/RenderFiles/

in

a plist file: '~/Library/LaunchAgents/fr.handbrake.activity_agent.plist



As with KeRanger and Keydnap, hackers targeted an official distribution website of legitimate macOS software. With access to HandBrake's mirror, they trojaned the legitimate application, meaning any user who downloaded the application would inadvertently infect themselves!Luckily the trojaned disk image was only online for a few days. However as is often (always!?) the case, no anti-virus products flagged the malware :( So if you recently download HandBrake, unless you were running something like BlockBlock you'd likely have been infected.To check if you're infected, look for the following:Apple has now also pushed out an XProtect signature, meaning that all new infections should be twarted. Hooray!



$ cat /System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara



private rule Macho

{

meta:

description = "private rule to match Mach-O binaries"

condition:

uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf

or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca



}



rule XProtect_OSX_Proton_B

{

meta:

description = "OSX.Proton.B"



condition:

Macho and filesize < 800000 and hash.sha1(0, filesize) ==

"a8ea82ee767091098b0e275a80d25d3bc79e0cea"

}





just a SHA-1 hash

matches on the trojaned Handbrake binary ( HandBrake.app/Contents/MacOS/HandBrake on the .dmg) $ shasum -a 1 /Volumes/HandBrake/HandBrake.app/Contents/MacOS/HandBrake



a8ea82ee767091098b0e275a80d25d3bc79e0cea /Volumes/HandBrake/HandBrake.app/Contents/MacOS/HandBrake



Ok, so kudos to Apple for the quick turn around on signatures....but the signature is:This means if the malware authors used any other infection vector, or even just recompiled the trojaned binary, this signature would no longer flag the malware :/ Do people still say 'yolo'?And even if you don't have source code, you can just flip a single bit in the binary to thwart the signature. To test this, I changed the final byte in

HandBrake.app/Contents/MacOS/HandBrake

from an

0x00

to

0xFF

. While this doesn't impact functionality of the binary, it changes its SHA-1 hash, meaning the malware is no longer blocked by XProtect. The following, first shows XProtect 'blocking' OSX/Proton.B. However, a second modified version is allowed to run, as the signature no longer matches: