Monday, August 18, 2014

Patching the Mach-o Format the Simple and Easy Way

This is a strange post for me.

I'm relatively new to mac research.  So when I find something new, that seems cutting edge, but relatively simple I question it. Has anyone else done this before? Is this in the public domain? Is this in the academic domain that I have no way of researching?

I google like hell.

I question myself (for a short period of time).

I write my congressman.

I wait.

I try to contact people in the know without letting them know to much.

Then I'm afraid I've said too much.

So here we are.

Thank's to the guys in #osxre (fg!) for telling what would work and not work.

This is my 'new' method for patching the mach-o format.

The macho format is simply nested segments in a very straight forward waterfall format that IMHO is much more simple than the PE and ELF formats.

As you have seen many times, this is the format, no seriously, this is it:

From: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

What is so special about this format?

It is very hackable easy to modify, far easier than ELF and PE formats.

There are not many code caves in a mach-o executable:
$ file ls.mach-o
ls.mach-o: Mach-O 64-bit executable x86_64

$ python ./find_caves.py ls.mach-o
[*] Looking in ls.mach-o for caves
[*] Looking for caves of 50 byes in size
No section
->Begin Cave 0x736
->End of Cave 0x10f8      # <--- Remember this one
Size of Cave (int) 2498
**************************************************
No section
->Begin Cave 0x4ff6
->End of Cave 0x5038
Size of Cave (int) 66
**************************************************
No section
->Begin Cave 0x54d1
->End of Cave 0x6000
Size of Cave (int) 2863
**************************************************
[*] Total of 3 caves found

The caves are large, but they are not in a section that includes read/execute attributes.

But let's look at the beginning of the __TEXT/_text segment/section:



Let's look at lower address space, what's going on?



Continuing:

Continuing:


You get the idea.  Many zeros. Much waste. Wow.

But that looks like enough room for shellcode, right? (The answer is yes).

How do we make that part of the __TEXT,__text segment/section?

Easy:

1. Change the __text section Address and Offset to the beginning of your shellcode and Size to accommodate your new shellcode.

Update 1/28/2014: This step is not necessary. Greetz to fG!: https://reverse.put.as/2012/02/02/anti-disassembly-obfuscation-1-apple-doesnt-follow-their-own-mach-o-specifications/

Before:


After:


2. Change LC_Main to point to the __text Offset or if a LC_UNIXTHREAD binary make sure [eip|rip] points to the new __text Address.

Before:











After:



3. You need to fork() your shellcode so that it continues after the parent has completed and you need to make sure that what LC_MAIN/LC_UNIXTHREAD was pointing to originally is the first thing that is executed whether a dyld or the __text section. Here I have the shellcode that I use in my POC.



And that's it. No really. That's it.

Here's the beginning of the __TEXT Segment after:



As you may have already figured out, this method works on both LC_MAIN and LC_UNIXTHREAD binaries. Also, this will work from within Fat binaries.

Proof:
Top window: netcat listener
Bottom window: Executing the patched ls.macho showing all the other successfully patched bins with my POC.

I've already automated the i386/x64 intel chipset mach-o patching, expect an update in BDF supporting these chipsets and Fat binaries containing these mach-o formats.

Cheers,
Midnite_runr

Monday, April 7, 2014

Why The BackdoorFactory

Yes.  I've questioned myself on the name: Backdoor Factory.  Early on in it's release, the Google search for my own tool comes up with some interesting results.  I don't have the courage to click the "Willy Wonka and the Backdoor Factory" link that ends up in the results:


Alas, I probably could have picked a better name.

No matter, time to sleep in the bed I made. 

Backdoor Factory (BdF or BDF) is the result of taking the Cracking the Perimeter from Offensive Security.  During the CTP, you learn to patch PE files by hand, among other awesome things.  However, I like automation.  Although it's taken a lot of time to write BDF, the ability to patch both PE and ELF file formats has taught me a lot about how windows and linux OS'es work as far as loading each format into memory and linking.

Now I'm working on BDFProxy, patching binaries over HTTP(S) via a transparent proxy MITM style.  I have have a full working demo using a wifi pineapple as a wireless AP with a VM running BDFProxy with two NICs.  It's fast, multi-threaded, and will support archive files (zip, tar).  Release timeline will depend on Con acceptance. :)

Here, I made a diagram:
<Internet>---<BDFPROXY>----<Evil AP>

Also, I'm looking into the Mach-o format.  Similar to ELF, but not.  Like the 90's version of the Red Hot Chilli Peppers compared to the 00's version. Once Mach-o is supported, I'll be moving on to ARM chipsets.

But before ARM, I want to dive into import address table (IAT) patching.  Not hooking.  Patching.  Let's think about this.  There has been plenty of writing about hooking the IAT and let's face it, if it's on CodeProject or Infosec Institute, it's been out there a long time.  Patching the IAT would include adding thunks for each API call that you need to complete the functionality of your shellcode.  I think by adding the necessary thunks to a BDF target binary, we could take a 380 byte shellcode (reverse tcp) and shorten it to less than 200 bytes by removing Steven Fewer's API lookup shellcode.  Yes, it's not position independent, but if you are patching a binary, you don't need to be position independent; you should know where you are in memory at any given instruction before even running your executable. I have a feeling this will defeat most all AVs as you will be making legitimate API calls. As a bonus this should defeat the EMET's caller protection (ROP protection, which works only on 32 bit anyway).  I hope to have this done by Fall 2014. 

So why BDF?

To learn binary executable formats, to show everyone that HTTPS should be everywhere and whitelisting should be easy to implement/come standard on OS'es, and to show that AVs really don't work.