Tag Archives: rootkit

Rex vs The Romans – Anti Hacking Team Kernel Extension

After surviving the five shots at SyScan’s WhiskeyCon I am finally back home and you get a chance to see the slides and code for the TrustedBSD module I presented.

The goal of REX vs The Romans is to work as detection and prevention tool of Hacking Team’s OS X malware. The TrustedBSD hook allows to detect if the system is already infected, and the Kauth listener to warn about any future infection.
The code has a strong assumption, which is that the malware binaries are installed into /Users/username/Library/Preferences. This has been true for all past known samples found in the wild. I do have better work than this but it is embedded in a commercial product so I can’t disclose its code.

The kernel extension will generate a user alert when something wrong is detected, either on installation or already infected system. A message starting with [WARNING] will also be printed to the system log. The following screenshot demonstrates the execution and infection from the dropper in a Lion 10.7.5 system.


You are encouraged to improve this code. Unfortunately I can’t do much more because of the commercial product conflict. If you do so please tell me about it, I might be able to help with some hints and/or fixes.

I am going to try to get a personal kernel extension certificate so I can distribute a ready to use binary version of this extension. That would be the most helpful case for the common users out there. Let’s see if Apple allows me to do so.

The slides are available here. The code is available at Github.
If you have any issues or questions feel free to mail me or post a comment.

SyScan 2014 was awesome, thanks to everyone who attended and made it possible.

Have fun,

P.S.: The MPRESS dumper will hopefully be released when I do the full presentation on Hacking Team’s OS X malware this year.

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
                              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,

SyScan360 Beijing slides

Eight days and 10 flights later I am back from SyScan360 in Beijing. It was my first visit to China and I had lots of fun observing many things that I only “knew” from reading. The scale and dimension of everything in Beijing is quite a surprise. No wonder why every Western company wants to be there. We had great food and an awesome visit to the Great Wall. A big thank you to the guys and girls from the organization for all their hard work and dedication.

The conference was very cool, even if it was full of “security guards” and metal detectors at entry (!?!?!?!). Stefan’s presentation was pretty epic (as usual) and I particurarly liked Jonathan’s presentation (maybe because he attacked some assumptions in the malware industry). As usual there was almost no exchange of ideas between the atendees and speakers. This is something that really bothers me in conferences. It seems like a lost opportunity for both sides to learn new things. Don’t be shy people, speakers are like you with the extra work of having to speak in public ;-).

My slides are available here. They contain a quick review of previous presentations made this year, and some new stuff attacking Volatility and signed kernel extensions to be introduced in Mavericks. Once again, simple stuff that is effective and easy to implement. What else do we need?


Kextstat_ASLR util or how to start hiding your kernel rootkit in Mountain Lion

Welcome back!

This is a small post about a quick util that I created yesterday’s night while working on a side project. Mountain Lion introduced kernel ASLR and the kextstat util output doesn’t support (yet?) this feature. The addresses are not the real ones and this is quite annoying (kgmacros from kernel debugging also seem to fail at this!).

What this util does is to read the kernel extensions information via the /dev/kmem device (hence this util is probably not useful for a large audience) and display it like kextstat does with the correct address for each kext (just the most important information, the linked against info might be added in the future).

Besides useful for anyone wanting to read the kexts information, it’s also useful for rootkits because it implements the trick that Crisis uses to retrieve this information for 64bits kernels (my posts were against the 32bits version). The only piece left is how to find the sLoadedKexts symbol. Here it’s hardcoded for version 10.8.2. I do have a nice trick to find it but it’s not ready for public consumption. First I want to see if it’s possible to implement my new idea 🙂

Due to some whacky reason I was convinced that each kernel extension had individual ASLR slide values, which after I got this util working was demonstrated false. The slide is the same as the kernel. I probably had some mistake while searching manually for the kexts. Practice makes perfection and part of this code was needed for my new project so it’s not wasted time!

The code is located at https://github.com/gdbinit/kextstat_aslr.
One feature to be added is to “bruteforce” the whole sLoadedKexts array. The reason is that rootkits usually decrease the count but the information remains there. Since the class has a capacity instance variable, we can move beyond the count and check if there’s anything suspicious there. Just a fun detail 🙂

The last detail is that this is susceptible to changes to OSArray and OSKext classes since it’s using offsets into the instance variables. The best way would be to get this ported to C++ but I still have to read a book or two on C++. Need to verify how stable are these classes since Snow Leopard.

Phew, too many written words for such small util!
Have fun,


There is a privileged syscall called kas_info() that allows to retrieve kernel ASLR value. I’ve updated the code to use this feature.

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 1: The dropper’s box of tricks

Mac malware is back to news spotlight, this time with Crisis (insert one of the other thousand names here _____). This malware is nothing more than commercial spy software being sold by a lot of money to governments or something (oh boy, I could make a good living out of this :-X).

I’m lucky enough to have a sample of it (thank you, you know who you are!) and also lucky to be able to talk about it (it uses some similar tricks that I knew about under some contract work – so also a big thank you!).

This post is very long so I decided to change its format. The main page will just display the beginning of the article and you need to click to read the rest. I’m not a great fan of this solution, although most blog readers are from RSS feed. Let’s give it a try with these long articles 🙂

I started reversing Crisis because I’m mostly interested in the rootkit. It is able to hide itself by modifying sLoadedKexts, something that I briefly attempted and failed in the past. More on that in next posts…

Continue reading