Using OS X TrustedBSD framework to protect critical files

October 27, 2011 in Tools | 1 comment

And here we are with a few spare minutes! My baby girl is a little cute devil who, like me, isn’t very found of sleeping all the time. She’s taking a lot of my attention so mom can rest. Well, it’s time well spent while I still have lots of it :-)

Let’s get back to business… There was some fuss around with the latest version of the so called Flashback.C OS X Trojan. This version attempts to remove Apple’s XProtect out of its way. A big public thanks to those who sent me samples of this new version :-)
This new “feature” gave me the idea to use TrustedBSD framework in our benefit. A module can be written to protect those (and other) files. We can do this system-wide instead of using the sandbox module. As I referred in the sandbox guide, Apple didn’t implemented all the available hooks and even if it did, it would be useless in this case – sandbox must be configured per process/application.

Ice, The Guardian is a PoC that implements a hook on open() (Ice was my fantastic and huge Doberman). If access to “com.apple.xprotectupdater.plist” is attempted by any process not named “XProtectUpdater”, then access is denied and an alert is issued about this.
The code is very simple and the level of protection isn’t high (spoof the process name for example?). I have some ideas to improve the level of protection and make it harder to bypass/spoof. Other syscalls also need to be hooked (unlink for example). Well, you can develop your own custom module and increase the protection level of your system.

I still have to measure the real performance impact of having such module. Some tests inside a Vmware instance with SpeedTools didn’t revealed a big penalty in disk access. Need to execute tests in my physical machine to have better results about this. Worst case scenario it should be on-par with anti-virus performance.

Feel free to send suggestions/improvements, bitching about my code, patches, or just hello :-)

Enjoy,
fG!

icetheguardian_v0.1.zip
SHA256(icetheguardian_v0.1.zip)= 0a614d66e208e422a9e82f6228f56398bd1585495676f09c3485c24429ba33a7

Poking around Sentinel HASP Envelope for Mac OS X :-)

October 13, 2011 in Mac Reversing | 1 comment

I am a sucker for all OS X anti-debug promises I  can find. There are so few tricks available that I am always curious to see if there is something new in town. So I started poking around Sentinel HASP Envelope for OS X to see what they use to fool my dear debuggers.

Well, we have the usual ptrace and sysctl tricks, a check for a kernel debugger (via kernel boot arguments ;-) ), and, to my (good) surprise, one of the anti-debug tricks I discovered a few months ago. I will not tell you what is it so you can have some fun with it :-)

There is also an import table built on the fly, with symbol strings & other strings being encrypted (gdb “info symbol address” command is useful here). And some functions where IDA disassembly fails, totally out of sync. This is where I am at the moment.

In theory I shouldn’t be able to progress much more because the unpacking will require a dongle plugged in, which is something I don’t have. I will just try to disassemble those messed up functions :-)

Has anyone else picked up on this one? Are there any more interesting things to look at here?

Don’t worry Aladdin, I will not publish any details ;-)

You can download the Sentinel CD from Aladdin website, containing all tools for Windows, Linux and OS X. The program that creates the envelope is located in VendorTools folder. Btw, the enveloped program seems to be around 10 times bigger than the original size. I am glad storage is cheap these days.

Have fun,
fG!

A small rant about dongles: the developer who can’t correctly implement a HASP!

October 11, 2011 in Mac Reversing | 2 comments

Dongles always had something mistique about them. Before this new age of packers, cryptors, etc, they were the top target to beat. In practice, that fame was only real in a reduced set of applications that correctly implemented the dongle. Most dongle-protected software features bad implementations. Developers don’t spend enough time in this area or think that it’s the magic bullet to solve their problems.

This program is another fine example of this problem. I saw this one and decided to give it a look – it had HASP in the request so my curiosity had to be fulfilled. Less than three hours later, I was disappointed! Another crappy and rushed dongle implementation. It is so damn easy that it hurts (picture is for the basic edition, the advanced is one byte away). The full crack is 5 bytes, where 4 are NOPs ;-)

I have emailed the developers 5 days ago but received no answer. The auto-reply promises feedback in 24h so they don’t seem to care. Of course I will not publish details about this. It is annoying because it would be a good example of what not to do.

Anyway, if you are a developer implementing a dongle, let me give you this small piece of (important!) advice. Your application should have an healthy dialog with the dongle instead of a “good morning” before starting to work. You can also trust it to keep your secrets instead of storing them in computer’s memory.
Explore the dongle possibilities and think a little about how can you use them. In this case, HASP examples are a bit bad because they are way too simple. Remember that example of the App Store receipt sample code that a lot of developers copied, even when they were warned not to ? Do not do the same ;-)

Back to some other projects. My baby girl seems to have inherited her parents strong personality and doesn’t want to come out, so I still have another week of free time :-)

fG!

 

Fixes for the TrustedBSD backdoor – Rex the wonder dog v0.2

September 26, 2011 in Tools | 3 comments

I like things well done and the healthy discussion with snare about this topic remembered me this PoC was a bit incomplete. So I decided to close the missing gaps.
The fix is pretty simple. Retrieve a new kauth credential with uid and gid equal to 0 and replace the old one (the code seems stable even without process locks). It also seems to work fine without the allproc lock.
The backdoor also had a small “bug” that I didn’t noticed due to a coincidence. If you are using iStat Menus then you have a daemon running as root that is collecting info from processes and uses task_for_pid() on them. So the trick of getting the task_for_pid for any process even without permissions worked because of this coincidence (the backdoor failed but iStat daemon called task_for_pid() on the process and so backdoor was activated, duh!). The fix is to do a task_for_pid() on itself. It was one of those things that you don’t feel it’s right but you don’t pay much attention to.

The only catch is that the symbol for kauth_cred_setuidgid() is not exported so it’s manually configured for Snow Leopard 10.6.8. To resolve the kernel symbols is another project ;-)

Have fun,
fG!

rexthewonderdog_v0.2.zip
SHA256(rexthewonderdog_v0.2.zip)= 890faeafef5ff00ac289e6289e14abee2d744b8e6155ac05b0b51eaf3ac4448f

Update:
All previous versions do not work with Lion because proc structures changed (check xnu/bsd/sys/proc_internal.h).
Version 0.3 adds support to Lion 10.7.1. Edit the main source file and change the define accordingly.

rexthewonderdog_v0.3.zip
SHA256(rexthewonderdog_v0.3.zip)= c85f5273497430e7328364c52d6d772ccb154c068250fb8a7ef73532b067b713

Abusing OS X TrustedBSD framework to install r00t backdoors…

September 18, 2011 in Tools | 8 comments

While poking around OS X implementation of TrustedBSD to write the sandbox guide I had the idea of trying to abuse it for backdooring purposes. It’s kind of funny that something designed to protect can be so “easily” abused to install backdoors.
This is not rocket science or a big breakthru post – I was just curious about the possibility to abuse the framework. You still need to find a way to install the kernel module!

So without further delay, I present you Rex, The Wonder Dog. It is a very simple policy module for TrustedBSD that gives r00t privileges to a process named “xyz”, if it calls task_for_pid(). For some unknown reason I couldn’t yet do the same with fork() (it was only working for Safari). I was doing this at 3am so I really didn’t bothered too much about it. It is based on SEDarwin sample policies code.
I had some trouble to compile the policy module (duplicate symbols) if I try to use the macro to initialize the module. I strongly suspect this is because I am using XCode’s kernel extension template. This is just a lazy PoC ;-)

The code is unstable. Processes start crashing and crash reporter isn’t executing. It could be due to the very lazy way that r00t privileges are changed for the target process (it only starts to happen after backdoor is activated). Kernel land is dangerous territory! It is tested only with Snow Leopard 10.6.8. Might work with Lion without any problems. Load it as a normal kernel module, with kextload.

Dmesg log when module is loaded:

calling mpo_policy_init for rex_the_wonder_dog
calling mpo_policy_initbsd for rex_the_wonder_dog
Security policy loaded: Rex, the wonder dog! (rex_the_wonder_dog)

Starting the backdoor and getting a r00t shell:

$ ./xyz
[info] calling task_for_pid()
[info] task for pid returned 0
[info] uid 501 euid 0
[info] setting uid to 0...
[info] uid 0 euid 0
[info] executing r00t shell...
# id
uid=0(root) gid=0(wheel) egid=20(staff) groups=0(wheel),204(_developer),100(_lpoperator),98(_lpadmin),80(admin),
61(localaccounts),29(certusers),20(staff),12(everyone),9(procmod),8(procview),5(operator),4(tty),3(sys),2(kmem),1(daemon),
401(com.apple.access_screensharing),402(com.apple.sharepoint.group.1)

Policy modules open interesting possibilities for implementing other things. Maybe your own binary integrity check module? Or maybe some nice anti-debug for software who must use kernel modules ;-)

Sorry for the lazy and unstable code. I’m not that much interested in backdoors, I was just interested in testing the possibility. It’s (just) a clean way to activate a kernel backdoor. If you improve and want to share your code feel free to send it!

Have fun,
fG!

Here are the goodies.

rexthewonderdog_v0.1.zip
SHA256(rexthewonderdog_v0.1.zip)= 4d75ab5859d6a3259de12a9e21a7ee4530b1bc1adb673e2fb24a4f66b9109eac

xyz.c
SHA256(xyz.c)= 3e24337fc7b61f392066e0812051007e8942060a2906d720d345f019de894576

4th anniversary…

September 14, 2011 in Uncategorized | 3 comments

This blog is more or less 4 years old (the first draft post is from 2007/09/25) … Uau, time passed by quickly! Mistakes were made, valuable lessons were learnt, new tricks developed, knowledge improved, and most important, fun!

I created this blog because there was so little public information about reversing in OS X. The act of sharing information and knowledge helps you in the research and learning process. Unfortunately I cannot share as much as I wanted to – the world is full of greed and stupidity (read Survival of the Stupidest) and someone will always misuse information. Maybe all the current economic problems make people rethink their objectives in life and the world starts to change for the better. I don’t have lots of hope about this. Let’s see if I am wrong :-)

Anyway, the blog will probably slow down a lot in the next couple of months. My baby girl is almost entering this world and parenting in the first months seems to be a pretty intense activity. It will be an hibernation period until everything is running smooth (I hope! ;-) ).

Special thanks go to saure for the little tweaks he gave to the blog design template.

As usual, if you have anything you want to publish or spread the word about, just mail it to me. I always want to learn new things :-)

Have fun,
fG!

« Older entries § Newer entries »