Tag Archives: malware

AppleDoesntGiveAFuckAboutSecurity iTunes Evil Plugin Proof of Concept

Oh this one has been into my head for so long that I finally decided to try and create the code for it. So let’s go!

What’s the background story?
In August *2011* I reported to Apple a security issue with iTunes. What happens is that iTunes plugins are loaded into iTunes process space so they have full control of iTunes. Evil plugins can do all kinds of things such as stealing iTunes passwords and credit card information, or patching some annoying features as I did with Disable m3u plugin.
This is part of Apple’s response:
After examining your report, we feel that this is an area for security hardening that we will consider for future updates.“.

Well, almost three years later and a few iTunes revisions nothing was done regarding this. The plugin folder is writable by current logged in user so a trojan dropper can easily load a malicious plugin. Or it can be used as communication channel for a RAT (Hacking Team, are you reading this?). And so on…

AppleDoesntGiveAFuckAboutSecurity is a quick PoC that installs a breakpoint on SSLWrite function and dumps the clear text buffer that is passed to it before being sent over SSL/TLS secur channel (veryyyy old trick, nothing new). A mini-debugger (exception handler) is installed to handle the breakpoint and dump the information. Of course this could have been done with function hooking but this code is more fun, even if it’s a very quick hack with hardcoded addresses. It is set to be used with latest iTunes available in Mavericks 10.9.1. If you want to play with other versions, just run iTunes under gdb and breakpoint on *SSLWrite. Give a look at the code, it’s pretty small and easy to understand.
Continue reading

Linux/HackingTeamRDorks.A, a “new” and improved version of Linux/CDorked.A

Disclaimer: This malware sample is not in any way related to Hacking Team (as far as I know) other than me making some jokes about them related to a future presentation about their OS X malware product.

Two months ago (maybe three) I started noticing a sporadic redirect when I accessed this blog pages. It wasn’t anything malicious as far as I could evaluate; just a redirect to adult friend finder site. A friend did some initial research on the site pages and content and could not find anything relevant there, other than a very old Zen encoded backdoor (LOL!). I also poked around the database contents and it appeared clean. Having read about some recent Linux rootkits injecting iframes and that kind of stuff I was convinced the shared server had been hacked. Other tasks were calling for my attention and so this matter got sidetracked.

Last week some readers started complaining about the redirects and it was finally time to find out what was really happening. I asked my great hosting friends at HighSpeedWeb to give me r00t and find the problem. My instinct was right and I found out a new variant of Linux/CDorked.A that made headlines beginning of 2013. Unfortunately I have no idea how the breach started but I bet in a local root exploit (server was running KSplice). Shared servers are a pain to manage with all kinds of vulnerable scripts being installed.
For some background on Linux/CDorked.A you should have a look at the following articles:

Continue reading

Breaking OS X signed kernel extensions with a NOP

For some reason Apple wants to change external kernel extensions location from /System/Library/Extensions to /Library/Extensions and introduced in Mavericks a code signing requirement for all extensions and/or drivers located in that folder. Extensions will not be loaded if not signed (those located in the “old” folder and not signed will only generate a warning [check my SyScan360 slides]). The signing certificates require a special configuration and to obtain them you need to justify it. You know, there are people out there coding rootkits and other nasty stuff ;).

A couple of days ago while trolling around in IRC someone complained about this and I decided to give it a quick try (I sort of already knew it would work this way but never really tried it). Kextd is the daemon responsible for processing requests to load kernel extensions. The message you get when trying to load a unsigned kernel extension is: “ERROR: invalid signature for %@, will not load”. Load IDA, disassemble and search for this string (the alternative is to go to opensource.apple.com and download 10.9 kext_tools package – my brain defaults to IDA!). What you can see is this code for one of the two hits:

    OSStatus  sigResult = checkKextSignature(theKext, true);
    if ( sigResult != 0 ) {
        if ( isInLibraryExtensionsFolder(theKext) ||
            sigResult == CSSMERR_TP_CERT_REVOKED ) {
            /* Do not load if kext has invalid signature and comes from
             *  /Library/Extensions/
             */
            CFStringRef         myBundleID;          // do not release
 
            myBundleID = OSKextGetIdentifier(theKext);
            result = kOSKextReturnNotLoadable; // see 13024670
            OSKextLogCFString(NULL,
                              kOSKextLogErrorLevel |
                              kOSKextLogLoadFlag | kOSKextLogIPCFlag,
                              CFSTR("ERROR: invalid signature for %@, will not load"),
                              myBundleID ? myBundleID : CFSTR("Unknown"));
        }

Nothing more than a simple call to the check signature function and then a simple test to see if it was valid or not. This is pretty common in (lame) software protection schemes. One of the usual ways to bypass it is to NOP the test. Or you can just patch the checkKextSignature and return always TRUE. Many different ways to solve it.

patchmebabyNow to the interesting part. I have no idea what was Apple thinking (sometimes they do not seem to think!) by implementing the code signature checks like this. It is very hard (to impossible) to protect kextd against something running at the same privilege level (kextload or something else require root to load kernel extensions). To launch the rootkit one just simply needs a binary that runtime patches kextd (task_for_pid, mach_vm_protect, mach_vm_write) and then loads the rootkit . Game over!
Of course it is easy to argue that if attacker got root everything is possible and the game is lost. Maybe! But making things like this is just security theatre and nothing else. It creates a useless artificial barrier to load unsigned code into the kernel and a false sense of security. This kind of checks needs to be done in the kernel, at a different privilege level. True that a rootkit can just patch files at disk and bypass a kernel protection but a non persistent rootkit just needs to patch kextd, get loaded and do its work. This is just (more?) careless and sloppy work from Apple.

Have fun,
fG!

OS.X/Boubou – Mach-O infector PoC source code

More than half a year as passed since Hitcon’12 and as far as I know no one cared much about implementing some sort of detection/protection against this type of attack (correct me if I’m wrong :-)). As explained in Hitcon slides, this trick can be very useful to install backdoors and avoid the usual lame LaunchDaemons type of thing.

I did some massive cleanup to the original PoC that I had glued for Hitcon but it’s still a bit messy and definitely not “production” ready. It contains many “design” decisions that make it easily detectable but keep in mind it can be worked and improved a lot.

The goal here is to show how (easily) it can be done and improve detection/protection. History keeps repeating itself and while everyone is worried with 0days, stupid simple tricks are still very effective. We need to get rid of these first!

Code is available at github and also a zip at the end of the post.

This version only supports non-fat targets so you need to work on it if you want to make a cyberweapon out of it (ahhh, couldn’t resist to make the joke :P).

Link to the Hitcon slides in case you want to reread the concept.

Don’t forget to chown -R root:wheel to all apps in /Applications (very few give problems with this, at least protect the main binary and frameworks).

Have fun,
fG!

osx_boubou_v0.1.zip
SHA256(osx_boubou_v0.1.zip)= 4e5429aeca58f8d6aea89034409804cc4a8a787fc56b1ce617bb28071eb8d0ce

Tales from Crisis, Chapter 4: A ghost in the network

This chapter was supposed to be about additional methods to detect OS.X/Crisis but I had the evil idea of taking full control of Crisis, and played with this idea for the last couple of days. It’s pretty damm easy to customize the dropper, and at the limit, be able to deploy your own version of Crisis to anyone. This raises some problematic questions, some of which I was fooling around with at Twitter. To make it clear, I have no intent whatsoever to resell Crisis or something. First because it enters in conflict with my values, and second because it enters a potentially big legal minefield.

To me, hacking is all about raising the weird questions, playing with stuff, and experimenting with what others doesn’t see. I would love to have the resources to answer and test the legal minefield just because it’s a curious topic. The world is increasingly dangerous for hacking. It’s sort of a paradox that in a age of fast access to information the trend seems to be running towards making it more difficult to access and spread information. But enough of philosophical questions!
I will keep researching in private if I have time to. My free time status is going to change soon so things will be different. I still have some very cool ideas to try with Crisis and they would probably generate some interesting articles. We’ll have to wait and see if the environment changes.
Continue reading

Tales from Crisis, Chapter 2: Backdoor’s first steps

Let’s continue our cute story about OS.X/Crisis, this time with the startup flow of the main backdoor module.
Please apologize for the delay on this chapter – I had some fun with the rootkit and that diverted me to other things.

The first curious detail about the backdoor module (installed asĀ /Users/USERNAME/Library/Preferences/jlc3V7we.app/IZsROY7X.-MP) is that no obfuscation/anti-debugging tricks are used (except one) so its analysis is easier than the dropper. It also uses Objective-C heavily, which is still a bit annoying in IDA but has the advantage of the code being very descriptive.

Continue reading