Grey bar Blue bar
Share this:

Wed, 16 Jan 2013

Client Side Fingerprinting in Prep for SE

On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.


First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn't find the exact IP they were being NAT'ed to. Not wanting to stop there, I tried out Vlad's Skype IP disclosure trick, which worked like a charm. What's cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don't even need to be "friends", you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.


Once I had that IP, I went on a hunt for web logs that had been indexed by a search engine, that contained hits from that IP. My thinking was that I run into indexed Apache or IIS logs fairly often when googling for IPs or the like, so maybe some of these contained the external NAT IP of the target organisation. It took a fair bit of search term fiddling, but in the end I found 14 unique hits from their organisation semi-complete with User Agent information (some were partially obscured).


This provided me with the following stats:









Operating System


Win XP 8


Win 7 32 3


Win 7 64 3

Browser


IE 8 8


IE 6 3


IE 7 1


IE 9 1

Combination


Win 7 IE 8 4


Win XP IE 8 4


Win XP IE 6 3


Win 7 IE 9 1


Win XP IE 7 1


Granted, it could be that the same machine was present in multiple logs and the stats are skewed, but they are a large enough organisation that I thought the chances were low, especially as most of the sites who's logs I found were pretty niche. As validation of these results, later, once we had penetrated through to the internal network, it was clear that they had a big user base in regional offices still on Win XP and IE6, and a big user base at corporate offices who had been migrated to Windows 7 with IE8.


Unfortunately, the UserAgent didn't make it clear whether they had Acrobat or Java or what versions they were at. We thought of using some JavaScript to do such detection, but were under a time constraint, and went with trying to pwn them instead, with the thinking that if it doesn't work, we could retarget and at least get some debugging information.


Anecdotally, and to give the story an ending, it turned out that BlackHole and Metasploit's Browser AutoPwn were a bust, even our customised stuff got nailed by Forefront when the stager tried to inject it's payload at runtime, but an internal tool we use for launching modified meterpreter payloads worked like a charm (although, periodically died on Win7 64bit, so I'd recommend using reverse-http, you can restart sessions, and firing up a backup session to restart the other with).

Tue, 20 Nov 2012

HTTPS <=(:)=> via WinAPI

Hijacking SSL sessions initiated by the browser is a trivial task. The challenge comes when trying to intercept SSL traffic in applications such as Dropbox or Easynote. These apps create additional measures to verify certificates and their integrity, hence not very friendly to perform with Burp.

One quick solution to the above problem is hiding one level above (or below :) the OSI layer. Live API monitoring // hooking can be used to capture and manipulate HTTP/S "traffic" before it being placed on the wire, more or less the same way are used to doing it in Burp.

One great tool is the Rohitab API Monitor, which allows you to monitor, and control, API calls made by applications and services.

Steps: Attach to a target process in realtime -> selectively monitor/hook its API -> place breakpoints and manipulate API call parameter content at will.

Fig 1 - Attaching to evernote.exe | Selecting Internet (HTTP Srv API, WEbDav, WinNet etc...) API as primary filter for the session.

Fig2 - Examining HttpSendRequestA call (contains my easynote creds :) ) in realtime, before the assembled POST request leaves the host.

P.S. That isn't my password.

Wed, 4 Apr 2012

Towards Firmware Analysis

While I was evaluating a research idea about a SCADA network router during the past week, I used available tools and resources on the Internet to unpack the device firmware and search for interesting components. During security assessments, you may find interesting embedded devices available on the network. Whilst many don't look at the feasibility of doing firmware analysis, I decided to document the steps I took to analysis my target firmware, so you can take the similar approach in the case of assessing such devices. This could also be a good indication on the feasibility of automating this process (An unfinished project was launched in 2007: http://www.uberwall.org/bin/project/display/85/UWfirmforce).

The following process would be easy for most of you who use *nix systems on a daily bases:

Step 1) Scanning the firmware image

The BinWalk tool is useful for scanning firmware image files to identify embedded file systems and compressed streams inside. It can detect common bootloaders, file systems and compressed archives inside a given firmware image file. Since it works by scanning for signature and magic values, it usually has false positives and the results need to be verified manually.

U-Boot bootloader (yes, it's German :-)) signature was identified at offset 262144 and the uImage header information, such as creation date, CPU type, etc appears to be valid. This bootloader was followed by a gzip compressed stream, which probably is the zImage kernel and a squashfs file system at offset 1522004. We will attempt to extract this file system in the next step. The following are common bootloaders that are used in embedded devices with ARM CPU:

Blob bootloader Bootldr Redboot U-Boot ABLE bootloader

The bootloader's task is to load the kernel image at the correct address and pass initial parameters to it. So in most cases we are not interested in analysing the bootloader itself, but in the root file system.

Step 2) Extracting file systems

First, I extracted the uImage content at offset 262144 by using dd command and then used uboot-mkimage (packages.debian.org/uboot-mkimage) to test if it's a valid uImage file and to discover more information about it:

The image format was valid and it contained two other file system images with 1MB and 2MB sizes, which probably are kernel zImage and root file systems (RAMdisk). If you check the uImage file format, you will notice a 64 bytes long header. There is a “multi-file” image list that contains each image size in bytes and this list is terminated by a 32bit zero. So, I would need to skip 64+2*4+4=76 bytes from start of the uImage file to get to the first Image content that would be kernel zImage:

The file command could not detect kernel image or squshfs in the extracted file systems; this might be due to lack of squashfs (with LZMA compression) in my Ubuntu kernel. I proceed by using Firmware Mod Kit which contains a set of programs to decompress various file system images including squashfs-LZMA. After trying the various unsquashfs version 3.x scripts, I was able extract the rootfs image files successfully:

Step 3) Searching the root file system

Once the root file system files were extracted, we can file and strings search tools to look for interesting files and patterns such as RSA private key files, password and configuration files, SQL database files, SQL query string and etc. In my case, I was looking for RSA certificate or private key files and found the following: (a database of private keys in embedded devices was published in 2011 but it's not actively maintained, you can access it at http://code.google.com/p/littleblackbox/)

One can write shell scripts to automate the file system search process.

Step 4) Running and debugging the Executables

The Qemu emulator supports multiple CPU architectures including ARM, MIPS, PowerPC, etc and can be used to run and debug the interesting executable extracted from the firmware image on your system for dynamic analysis purposes. You would need to build the Qemu with —static and —enable-debug options. The following figure demonstrates how to run the web server (httpd) that was extracted from my target firmware using chroot and Qemu:

As you can see from the above screenshot, the web server was working fine, but was not able to display the bootloader version, because it couldn't read this value from the NVRAM (not volatile RAM) normally mounted by the kernel in a real device (there is an interesting post here about resolving the NVRAM access errors while emulating embedded device executables). Some of the executables, like the remote management agent example below, could have more severe problems running under emulator.

For troubleshooting such cases, or monitoring an emulated process while fuzzing it, we would need to attach a debugger to it. This can be achieved by using —g switch in Qemu and using a debugger out of the emulator process or even on a remote windows machine. I used IDA pro remote GDB debugging tool as shown in the figures below:

Once successfully attached to the remote emulated process, IDA pro can be used to simply trace the execution of the process, placing breakpoints or running IDA scripts.

Often overlooked during assessments, firmware analysis of devices can yield results and often do when we target them at SensePost. Our methodology includes the above steps and we recommend yours does too.

Fri, 11 Nov 2011

Decrypting iPhone Apps

This blog post steps through how to convert encrypted iPhone application bundles into plaintext application bundles that are easier to analyse.

Requirements: 1) Jailbroken iPhone with OpenSSH, gdb plus other utilities (com.ericasadun.utilities etc. etc.) 2) An iPhone app 3) On your machine:

  • otool (comes with iPhone SDK)
  • Hex editor (0xED, HexWorkshop etc.)
  • Ida - Version 5.2 through 5.6 supports remote debugging of iPhone applications (iphone_server).
For this article, I will use the app name as “blah”.

Some groundwork, taken from Apple's API docs [1, 2]:

The iPhone apps are based on Mach-O (Mach Object) file format. The image below illustrates the file format at high-level:

A Mach-O file contains three major regions: 1. At the beginning of every Mach-O file is a header structure that identifies the file as a Mach-O file. The header also contains other basic file type information, indicates the target architecture, and contains flags specifying options that affect the interpretation of the rest of the file. 2. Directly following the header are a series of variable-size load commands that specify the layout and linkage characteristics of the file. Among other information, the load commands can specify:
  • The initial layout of the file in virtual memory
  • The location of the symbol table (used for dynamic linking)
  • The initial execution state of the main thread of the program
  • The names of shared libraries that contain definitions for the main executable's imported symbols
3. Following the load commands, all Mach-O files contain the data of one or more segments. Each segment contains zero or more sections. Each section of a segment contains code or data of some particular type. Each segment defines a region of virtual memory that the dynamic linker maps into the address space of the process. The exact number and layout of segments and sections is specified by the load commands and the file type. 4. In user-level fully linked Mach-O files, the last segment is the link edit segment. This segment contains the tables of link edit information, such as the symbol table, string table, and so forth, used by the dynamic loader to link an executable file or Mach-O bundle to its dependent libraries.

The iPhone apps are normally encrypted and are decrypted by the iPhone loader at run time. One of the load commands is responsible for decrypting the executable.

Push EBP
Mov EBP, ESP
JMP loc_6969
loc_6969:
Once you have downloaded and installed an app on your iPhone, make a copy of the actual executable on your machine.

Note1: The blah.app is not the actual executable. If you browse this folder, you will find a binary file named blah. This is the actual application binary.

Note2: To find the path where your application is installed, ssh onto your iPhone and use the following command:

sudo find / | grep blap.app
Once you have copied the app binary on your machine, follow the steps below (on your local machine).

Open up a terminal and type the following command:

otool —l blah | grep crypt
This assumes that iPhone SDK or otool is already installed on your machine.

The above command will produce the following output:

If cryptid is set to 1, it implies that the app is encrypted. cryptoff and cryptsize indicates the offset and size of crypt section respectively. Now, firstly we'll have to locate the cryptid in the binary and set it to zero. This is done so that when we finally decrypt the binary and execute it on iPhone, the loader does not attempt to decrypt it again. Open the binary in a hex editor and load the binary. I did not come across any definite method of locating the cryptid. Once you have loaded the binary in a hex editor, search for “/System/Library/Frameworks”. You should be able to locate it around the address 0x1000. In the line, just above the very first instance of this statement (/System/Library/Frameworks), you will find bytes 01. Flip it to 00 and save the file.

Note3: In case you find multiple instances of 01, use coin-tossing method of choosing between them.

Use otool again to query the crypt data. You will see that the cryptid is now set to 0 (zero).

Next, we need to run the app, which was installed on iPhone and take a memory dump.

Note4: The actual application code starts at 0x2000. The cryptsize in case of our sample app is 942080 (0xE6000). Hence, we add 0x2000 and 0xE6000.

0x2000 + 0xE6000 = 0xE8000
Therefore, we need to dump the running process from 0x2000 till 0xE8000. Now, ssh onto your iPhone, run the target app and look for the process id using “ps —ax” command. Once you have the process id, use the following command to dump the process:
gdb —p PID
dump memory blah.bin 0x2000 0xE8000
Once you have taken the memory dump, use “quit” command to exit gdb. Use the following command to get the size of memory dump:
ls —l blah.bin
The size of this bin file should exactly be same as the cryptsize of the original app. Refer to screenshot above. Now pull this bin file onto your local machine. On your local machine, load the bin file in a hex editor and copy everything (using select all or whatever). Close the file and open the original app in the hex editor. (The file in which we modified cryptid 01 to 00). If you remember, the cryptoff was 4096, which is 0x1000 (in hex). Proceed to memory address 0x1000 and make sure that your hex editor is in overwrite mode, not in append mode. Once you are on memory address 0x1000, paste everything you copied from the bin file. This will overwrite the encrypted section with the decrypted one. Save the file and you're done.

Open the file in IDA pro and you'll see the difference between the encrypted and decrypted binaries. At this point, you can easily reverse engineer the app and patch it. The first image below shows an encrypted app and the second one illustrates a decrypted app:

After patching the application, ssh onto the iPhone and upload it to the application directory. This would mean replace the original binary with the patched one. Once uploaded, install a utility called "ldid" on your iphone.

apt-get install ldid
Finally, sign the patched binary using ldid:
ldid -s blah
This will fix the code signatures and you will be able to run the patched app on your iPhone.

References:

1) http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

2) http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html

Mon, 7 Dec 2009

Criticism, Cheerleading, and Negativity

[Alex Payne] has an excellent post up titled "Criticism, Cheerleading, and Negativity". It's a 2 minute read, but its worth it:

"

We understand well the idea of being in favor or something, or against something, but we don't particularly understand how criticism fits into this dichotomy.

..

The reason a person is critical of a thing is because he is passionate about that thing. In order to have a critical opinion, you have to love something enough to understand it, and then love it so much more that you want it to be better. Passion breeds critical thinking.

..

“That sucks” is negativity. “That sucks, here's why, and here's how to fix it” is criticism, and it comes from a place of love. That's the difference.

Everyone says they're comfortable with criticism and with critics, because not being able to handle criticism is a sign of immaturity. What people really want, though, are cheerleaders. Nowhere in life is this more true than in business.

A healthy business needs passionate employees to succeed. Critics are the most passionate people you can find, but we're conditioned to assume that critics are negative curmudgeons with nothing more than slings and arrows to contribute. So rather than seeking out critics, employers seek out cheerleaders.

"

Read the article.. its worth it..