Tools

You are currently browsing the archive for the Tools category.

Display Mach-O headers plugin for IDA

November 3, 2011 in Tools | 8 comments

This is a simple plugin to display mach-o headers inside IDA, something I miss from time to time. It was a good excuse to mess a little with IDA SDK.
It’s not quite what I had initially in mind but it does the job. I was thinking about something more sophisticated such as allow to display only the segment you wanted and so on. Now I am not sure if it’s worth the effort :-)

Tested with IDA 6.x in OS X and Windows, 32 and 64 bits. Included are Makefile and XCode project for OS X, and Windows DevC++ projects for 32 and 64 bits.

Give a look to the README file for extra information. Too tired and too late to write a long post :-)

Yeah, the code isn’t beautiful! Anyway I hope it’s useful for you.

Have fun,
fG!

MachOPlugin_v0.2.zip
SHA256(MachOPlugin_v0.2.zip)= aea01470a92a94a67ae29e6eba659b195829e599165265f8dd0fdc80333bc5a7

MachOPlugin_v0.3.zip
SHA256(MachOPlugin_v0.3.zip)= 73ea3471856027d7882b3b89986209f633bd19bc8b2159da7346a3e89c34fa4d

Also available at github.

Update:
v0.3 fixes some bugs/missing stuff and implements a workaround to IDA crashing.

IDA BUGS:
I seem to have found a few bugs in IDA QT GUI implementation.
The most annoying one is that the plugin will crash IDA if called more than once in the same session. What happens is that IDA happilly keeps opening new custom views even if there is code trying to prevent it.
The create_tform() function from the SDK should return a new handle if there is already a form with the same caption. Well this works with the old GUI but fails with the new one (QT). The same happens with find_tform. In this case, it never returns NULL if there’s no form (which is the expected behavior).
I implemented a small workaround, which is to add a number to the form caption. This way each call to the plugin will generate a new custom view and not crash IDA. Not pretty but the other workarounds I tried failed since I can’t find if form exists or not.

The other bugs are described in the README file. If you know a better workaround for this one please tell me :-)

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

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

Another patch for Apple’s gdb: the define/commands problem

August 20, 2011 in Tools | No comments

One known problem with Apple’s fork of open source software is their slowness in fixing vulnerabilities and bugs. Gdb fork isn’t immune to this; it was forked around release 6.6 or something like that and lots of stuff isn’t kept in sync with GNU’s gdb version.

The short story for this bug is that you can’t have a “commands” command inside a “define” command. This creates some problems for useful scripting. The funny thing is that I had hit this bug a few weeks ago but didn’t paid any attention to it, just worked around it and never bothered to understand why my script didn’t work.
What I did here was to find where the bug was, compare with GNU gdb to find where it was fixed (version 6.7) and backport the required code. So all coding work was done by someone else (thank you :-) ). I just “reversed” the problem!

Hey Apple, I am not your codebase maintainer ;-) (but I would be interested in working for you, probably in Strategy or Marketing, since you rock at those areas [well I also love design but I can't draw anything] and I suck at coding, LOL :-) ).

For now I will only post the patch – the version that includes all previous patches, and another just for this bug. Later I will put up patched binaries for Leopard/Snow Leopard and Lion.
I have to format my computer since I had to install some Chinese kernel drivers for Internet access. I do not trust their shit, especially low level stuff such as kernel drivers (TODO list has one more item – verify the code for those modules!). It’s a real sad state of affairs! But a format once in a while is always healthy, despite what is commonly said in Mac space.

To patch & compile your own gdb, please refer to here and here.

Enjoy,
fG!

all_patches_v0.3.patch.gz
SHA256(all_patches_v0.3.patch.gz)= 38a891327b14b94d73b7e6f5ef66b4848df03a59a8bac5e89b93869046078608

commands_bug.patch.gz
SHA256(commands_bug.patch.gz)= b84be03e73a5a5ada59ab8b7fbd595e531fe149446418750d5d747d6598aa6a0

Update:

Here is the binary version for Snow Leopard, 32/64 bits fat binary. Replace as gdb-i386.apple-darwin in /usr/libexec/gdb and don’t forget to fix permissions :-)

gdb-i386-apple-darwin.1344.gz
(SHA256(gdb-i386-apple-darwin.1344)= a0be45855569ad76c24f3422597c97aafa7bbb4d78793361f5978567be0f2506)

And the version for Lion, also a fat binary for 32/64 bits.

gdb-i386-apple-darwin-1705.gz
(SHA256(gdb-i386-apple-darwin-1705)= be1c462c8f271fd59581142d8d87a410d2cf1d2fcf27019796bee6424e50a9c6)

End of update.

Here’s how the problem looks like:

$ gdb
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Mon Feb 28 15:50:14 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".
gdb$ define test
>b *0x1000
>commands 1
>set $eax=1
>end
gdb$ bpl
No breakpoints or watchpoints.
gdb$ test
Breakpoint 1 at 0x1000
^CQuit
gdb$ bpl
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x00001000
gdb$

Gdbinit v7.4.2, Github and Twitter

August 11, 2011 in Tools | 1 comment

Hello,

It seems like things are very quiet and I only push gdbinit updates. Well, I have been very busy with very interesting projects, most of which can’t see yet the “light of the day”. Need to find some time to fool around with some new stuff.
It seems that vmprotect is coming to OS X and that is exciting news. I hope they finish it soon since I am curious about Mac specific implementation and tricks.

This is just a minor release for gdbinit. It fixes a very weird bug that is happening in FreeBSD (many thanks to Evan for reporting it) and adds the (Linux) anti-anti-ptrace command posted here.
I finally uploaded it to Github, https://github.com/gdbinit/Gdbinit/. Now I need to understand its access control (I think I must add collaborators? I hate to RTFM these days ;-) ). You can find always the latest version here and there.

I also have a Twitter account, @osxreverser. It is usually used in a passive way, to keep up-to-date of what’s happening – I still have some difficulties to understand Twitter. My web interests are mostly related to Economics and Management, which are topics a bit stretched for a RE audience. Anyway, I just got up some followers after giving a tip to Charllie Miller (I am spending too much time into gdb source hehehe).

From Blackhat US 2011 there’s a very interesting presentation from iSEC Partners regarding APT (Advanced Persistent Threat) in Macs. Original link here. I am pretty sure that new challenges will arise in this area for Macs (if they don’t exist already!). Macs share in the corporate is increasing and this kind of attackers will of course wanting to extract (valuable) information from those machines (top execs usually have a preference for Apple products).

Happy holidays and have fun,
fG!

gdbinit742.gz
SHA256(gdbinit742.gz)= 058b4910320a2370bf4ca5dc10da4f7cea105e73b9a28478c6f3e8475dba1bcf

The latest version can always be found here.

Update:
There’s a bug in Apple’s gdb implementation where you can’t have a “commands” command inside a “define” command. Additionally, the “catch syscall ptrace” doesn’t work in OS X so it will give another error. The solution for now is to comment out the “ptraceme” function. I have replaced the file with this fix. If you need to use it in Linux just uncomment it out. That’s what you get for copy & paste without proper testing! My fail ;-)
Meanwhile, time to track gdb change logs to find the fix for above problem.

« Older entries § Newer entries »