Why ESET’s OS X Rootkit Detector is useless…

Last week ESET released a Rootkit Detector tool for OS X. I finally gave a look at it today and as I suspected it is useless (unless rootkit authors are not reading my slides like ESET does not seem to). The only thing it appears to be doing is to check if sysent pointers were modified. Let’s be honest, it’s useless in particular when they mention they have limited visibility into OS X rootkits. So the way to improve it is to release a tool that only verifies old tricks from known rootkits. That’s the way to go!

The tool loads a kernel extension that will retrieve some information such as the kernel ASLR slide and sysent table. Just by looking at the code you know this is a fail. It will not work with Mavericks since the sysent structure is different as my SyScan360 slides show.
It is also extremely easy to detect using the same trick to attack the memory dumpers (once again, SyScan360 slides). A device called “esysent” is created by the kernel extension. Just hook devfs_make_node, lookup for this device and when detected play with it ;-). Game over, flawless victory!

To prove how useless it is, I just loaded my PoC rootkit using the shadow sysent method and ESET’s tool says there is no rootkit loaded. The system is safe. Yeah, right!

Besides the useless scanning technique used, it’s design can’t work. It requires a driver to analyse what is happening inside the kernel and that’s is the weakest link. A rootkit can easily control and react to drivers being loaded. The real problem is no Apple supported interface for interacting with kernel memory in a default install (kmem can be enabled with a boot parameter, non-default). I doubt Apple will ever restore /dev/kmem by default or implement a secure interface for this kind of stuff because there is no such thing as OS X rootkit(s), right?

Conclusion: don’t trust this tool or any other tools that promise point and click rootkit hunting. The game is a bit harder and you can’t win playing it with this kind of tools.

ESET, at least read my slides ok?

Have fun,
fG!

14 thoughts on “Why ESET’s OS X Rootkit Detector is useless…

  1. Thank you for looking into eset’s tool. I was curious what it was doing.

    Do you know of a better tool to detect rootkits? This tool _is_ free and detects something: It’s better than nothing.

    1. I have to disagree with that. I’m a fan of if you do something try to do it right ;-). The tool is useless and gives a false sense of security. It’s nothing else than a PR thing. Or ESET guys don’t really know what they are doing and that is even more worrisome.
      There are really no good tools for rootkit detection besides Volatility. I hope interest develops in this area and people start developing them, techniques in particular.

    2. I have not tested it in a long time but mac memory reader’s tool used to let you run in ‘expert mode’ which created a raw memory device that you can point Volatility too. I have no idea if this is still maintained or if it will still work like it used to. Also, I believe the device hooking method used in the recent syscan presentation would break this??? One bypass might be to edit the name of the device & driver created in the MMR binary.

      1. Hi Andrew,

        The problem is the required step of loading something to retrieve memory. If it’s thru a supported interface or API then it can be rather easily intercepted from a rootkit and subverted. I used the devfs_make_node because it was fast to create a PoC but I have other ideas.
        It must be some kind of out of band methods such as direct memory access or a kernel exploit (this one probably being the best!).
        Changing the device name is of course a countermeasure (it should be default honestly) but a rootkit can just unload whenever any device is created and inject into a user process and poll for that device. When it’s removed or something the rootkit can be reloaded.

        Quite an interesting problem to solve :-).

        1. How do you propose injecting into userland? That would leave other artifacts that could be found.

          you could also do other things to communicate with the kernel such as making a new interrupt, call gate, sysfs and so on. A anti-acquistion tool really just needs to stop drivers from loading b/c of all the ways memory can be accessed.

          1. Of course given enough time the userland artifacts could be found. The thing is that a normal running system has more than 100 processes running, that’s too many threads and memory to analyse when you have no idea what kind of code you are looking after (in theory it could be even a thread running purely on ROP code). I don’t think this is a problem too easy to solve.

            All those methods imply loading code into the kernel via the normal interfaces that a rootkit can control. Stopping the driver would raise suspicion, unloading the rootkit is much cleaner and serves the same purpose. A kernel info leak would be very useful but needs some careful usage else it can also be detected and exploited by the rootkit ;-).

            1. Yes the ROP method would be interesting, but the others would be detected automatically by normal workflows… For example, loading a library through the normal API would be detected through a baseline comparsion of shared libraries known to be on the system and injecting through some equilavent of reflective injection will generally leave pages in states that are suspsicous (e.g. RWX).

              Either way I am glad to see rootkits being written that do something more than hook the syscall table 😉

              1. Ah, you are assuming it will leave traces of the library, which is not necessarily true. And there are other injection methods that do not leave traces besides code in memory.
                That’s a lot of threads and memory to analyse 😉

  2. Hello fG! In your papers you mention about shadow sysent rootkit method on several occasions. Could you explain this method, because I found nothing about it.

    1. Hello,

      It’s usually called shadow syscall (old technique). Essentially you just need to modify the references to the array instead of the array itself. The functions that call the syscall pointers have references to the sysent array so if you modify them to your own version the tools that verify the original array see no problems because it was never touched.

  3. Thanks a lot for looking into our tool. We respect your work and we are following your blog.

    The description you provide is correct. Our application uses a kernel extension to read parts of the kernel memory.

    The OS X rootkit detector was created to be a stable and simple tool that everyone can use. We hope to use the feedback from the test users on what they find in their systems to improve our knowledge of OS X threats.

    It is not our intention to provide a false sense of security. The application does not assert the system is clean, but informs the user no syscall hooks were detected by the application.

    Regarding compatibility with Maverick, we did not mention our tool is compatible with Maverick. We will decide in due course if we want to port it to the newer versions of OS X.

    1. Hi Marc,

      It’s not clear that the app only does syscall hooking detection (at least the description never mentioned it).
      Even more important than this is that the app is vulnerable to privilege escalation if used more than once (in particular if copied to /Applications), as noar found out.

      Best,
      fG!

Leave a Reply

Your email address will not be published. Required fields are marked *