Tag Archives: backdoor

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 3: The Italian Rootkit Job

I always had some strange attraction to rootkits and was thrilled to hear that Crisis had one. This chapter is dedicated to the rootkit implementation, its tricks and how it’s controlled (and its fuckups!).

A small disclosure note about me making fun of Italians on Twitter. I love Italy and have nothing against Italians. We just share some cultural things that I really hate and that’s the reason why I was making fun of Crisis origins and some of its design/features. It’s no coincidence that the South European countries are all in economic trouble 😉

The rootkit number of features is very small: it can hide processes, files, and itself. Two versions are available for 32 and 64bits kernels (this post is about the 32bits version using Snow Leopard). Implementation is very simple and has some flaws that I will describe later.
The main feature that got me interested was hiding itself from kextstat because this needs to be done by modifying the sLoadedKexts array (the old kmod list is not enough anymore since it’s deprecated).
It doesn’t seem an easy job to find the location of this symbol and Crisis kind of cheats in doing it. What happens is that the userland backdoor module will solve the kernel symbols and pass them to the kernel module. Done this way it’s very easy to accomplish, although compatibility with future kernel releases might be in jeopardy if sLoadedKexts is modified.
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