crazylazy.info

txt

Apple developers left doors open. Threats come out.

About the idea

Currently I'm doing some research on vulnerability discovery techniques, speaking of black-boxing, white-boxing and yes... gray boxing, too. These are general code-review techniques for source-code auditing, automated function-auditing and formal software verification.
The sheer mass of information is overwhelming. And that's good. But in order to give all this stuff a purpose now it's necessary to collect easy and practical hands-on experience. That's where the MacOS system comes in, because it's fun - while using Windows systems would be the huge next step because the complexity is higher. It's pretty much that good people in the fields started with Windows, which today grew into a very complex and restrictively secured system. I wouldn't really want to mess with its architecture unless I knew what to expect.
So the idea here is: use some stuff and apply it on MacOS. Beginner friendly in-depth vulnerability discovery. The overall process on Windows, or BSD systems has similarities. And most of the following tools are available for Windows, too.

Foot-printing a Mach-O

Surely one can start IDA on a Windows box, and get the stuff done. Let's get it done less in a less complex way firstly.

Disassembling

Most applications on an a MacOS OS will be Objective C based, which means there'll be msg_sent calls. These have to be cleaned up in order to gain readability. Something that otool, which is part of the developer tools, doesn't do by default.

Additional programs: otoole and otx

otoole enhances otool with exactly this feature.

otx even offers an otool GUI. But functions like class-dumping aren't directly accessible. It has got convenient preferences like opening the dump directly with an editor afterwards and a configurable output.

class-dump has got a GUI, too.

Emulation

Emulation is useful for many different RE tasks. Not just for Malware and polymorph code. I found two implementations quite useful: a IDA utilizing modified plugin, and the scriptable pyEMU.

IDA with modified x86emu

x86emu is an IDA loader plugin that simply emulates the x86 CPU to simulate the binary-run. Normally this plugin runs for doing Malware analysis where there's an obfuscated PE file. - But with some slight modifications it also can record Objective C msg_send calls; while starting the functions isolated.

Patching x86emu for Objective C

The patch is there, as part of the MacHackers handbook.
IDA has got the ability to open Mach-O binaries by default. It will automatically detect and disassemble them. Nevertheless you can try an IDC Objective C cleanup script.
With an installed x86emu plugin reversing gets easier.

pyEMU

At least this seems to work: pyEMU and pyDBG from the Paimei MacOS subfolder and modified sys.path.append information.

Formal verification

This is a huge topic I'm not familiar enough with jet.
At least - from my standpoint - it's much more interesting than just fuzzing, because it's offering direct assumptions about the specific problems.
A problem actually seems to be that security directed formal verification implementations aren't released, however there're many papers. Seems to be an interesting topic to explore in-depth.

Valgrind - memcheck (massif)

Valgrind is a DBI (Dynamic Binary Instrumention) framework, quite heavy, but heavy functional, too. The MacOS port of valgrind contains memcheck, but officially misses all other stuff. It has no Objective C garbage collection. That's very problematic.

Additional tools for Valgrind

Heap profiling with massif actually seems to work. The ms_print outputs are quite similar, however I suppose that because the port lacks Objective C garbage collection it won't work for every application. C++/C based programs I wrote are verified correctly. Fair enough.

Use other systems

MacOS is a fun-hacking system, but when it comes to something serious: leave it.
Valgrind catchconv doesn't work for MacOS - no need to try. Neither does chronicle-reocder. Just stay Linux for the real experience. There's no need to tryout the advanced features currently.

And btw. don't try PIN. It's really awesome, but that MacOS version is for 10.4 and uses another procmod policy. Furthermore ptrace changed. Maybe I'll give a port a try, but that has been a one minute read for now. Save your time.

LLVM

LLVM is a modular compiler infrastructure. There's a great Google Tech Talk about it. And a Chaosradio Express if you're German.

For security specific bug-hunting with LLVM there's clang, an Objective-C (and other C based languages) static code checker.
And there's klee - a llvm symbolic virtual machine. It has got interesting function testing capabilities.

Both these llvm-tools run on MacOS without issues.

Checking code - ready to rewrite?

Speaking of static code analysis voodoo: in order to find a solution it's necessary to rethink the code. I have seen developers which had the great ability to circumvent the code checkers - and created bad code. Simply because they had no idea what the inconsistent report messages were supposed to mean. That's to be avoided. ;)

RATS

Rats is a free tool whose name makes clear what I meant. It's very basic.

splint... and others

Splint again is for C. PMD, FindBugs, Hammurapi from the Java world work very well and are integrate-able into Eclipse, IDEA or NetBeans.

Blast is a model checker for C programs, which is worth mentioning.

As I said: I'm trying out a lot to gain experience. If there's something awesome I'm missing, tell me.

Code-coverage and process-stalking

An approach I'm much more familiar with. So let's leave the formal world of applied verification theory and get pragmatic again.

Paimei: block identification through breakpoints

Through-process stalking Paimei can identify blocks based on breakpoints set by its pyDBG backend. That's fairly trivial via the GUI. And therefore really awesome.

RE:trace: real-time code coverage through Dtrace probes

RE:trace can do real-time code-coverage based on Dtrace probes. At MacOS we're in the great situation being able to use Dtrace. With idarub and a IDA Pro Windows backend this gets visualized.
However I found out that real-time is really fast ;).

Debugging in the software-era of careful revision

This is ironic, because in the real world very often people just skip revision and release. Otherwise the exploit databases would grow slower.

Hooking is modern

pyDBG is well capable for defining hooks. That has got a great variety of use-cases.

cgdb - gdb on ncurses

cgdb is a lightweight GDB frontend. Because Apple uses its own GDB there're some tricks that are more or less GDB only.

Fuzzing frameworks - hold your debugger

Peach (Python based), Spike (C), or Sulley (Python) can run on MacOS. In order to make use of CrashWrangler and Debugging (with GuardMalloc) these Fuzzers might scale according to your needs.

There's to say that Peach only runs command-line based on MacOS. However the GUI will be supported in the upcoming wxPython 2.9 (wx-progrid component needs bindings).
Spike has a pretty interesting fork for file-fuzzing.

Finding attack-surface

Since for example our friend Adobe is indirectly flooding the vulnerability databases... there's nothing more to say but: execute stuff on the Heap directly.
Today Metasploit has Payloads. So it's not that hard any longer and you've got a fair chance to develop an exploit without spending weeks. Code-signing at Apple seems to be non-existent for real. Firmware updates are alterable. Yes, that was fun.

Summary

It's fun-science. Nothing more. Very few Macs will be exploited within the next years simply because no one cares. Apple doesn't bother for security, normal users don't. Just some people do, enjoying to use the system in a whole different way. But I sometimes enjoy breaking it.
However maybe some of the recommendations should be followed; like don't open and install stuff you don't trust. Or "think different": don't just believe the advertisement. Where there's money, truth is rare.

Have fun,
wishi