Episode308

From Paul's Security Weekly
Jump to: navigation, search
Palo Alto Networks
Tenable Network Security
The SANS Institute
Pwnie Express
Black Hills Information Security
BlackSquirrel
Onapsis

SANS Las Vegas from October 26-27th will debut a new course titled "Embedded Device Security Assessments for the Rest of Us" which will teach students how to assess embedded systems of all varieties on pen tests and in your duties as a security professional. Register Here


Episode Media

MP3

Announcements & Shameless Plugs

PaulDotCom Security Weekly - Episode 308 for Thursday November 15th, 2012

  • Bsides everywhere baby! Likely there is one near you, so check the web site www.securitybsides.com. Next BSides in Boston February 23d.

Tech Segment: Reverse Engineering Firmware Primer

Introduction

Reverse engineering firmware is so much fun, but also very frustrating. Using some techniques I recently discovered, I attempted to rip apart some Dlink Dir-655 firmware. This device runs MIPS and ubicom boot loader, so its weird. I was unsuccessful in mounting a file system, however the steps below can be applied to just about any firmware.

How-To Pull Apart Firmware

binwalk rules, it looks at all of the file/file system headers and spits out a map:

# binwalk --dd=gzip:gz:2 DIR655B1_FW203NAB02.bin 
DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------------------------------------------------
0         	0x0       	uImage header, header size: 64 bytes, header CRC: 0x29953343, created: Mon Jun 27 00:33:02 2011, image size: 6395843 bytes, Data Address: 0x40100000, Entry Point: 0x408A6270, data CRC: 0x3D73C1BC, OS: Linux, image type: OS Kernel Image, compression type: gzip, image name: Unknown - IP7160_DIR855_F_Board
64        	0x40      	gzip compressed data, from Unix, last modified: Mon Jun 27 00:33:00 2011, max compression

The "--dd" option is awesome, because it will find anything that matches "gzip", extract it, name it .gz and do that 2 times. The we get a 40.gz file to extract:

gzip -d 40.gz

The file "40" now represents the data in the firmware (basically we stripped the firmware header and uncompressed it). Now you can run strings against it:

strings -8 40 | less

I found the file system map:

Launching OS on thread: %d entering at %p
device tree alloc failed
board node alloc failed
%p: board node not attached: %d
bootargs
bootargs node alloc failed
mtdparts=ubicom32_boot_flash:128k(bootloader)ro,7552k(upgrade),384k(jffs2),64k(fw_env),64k(artblock)
start trap handler...
start usb...
start ethernet...

I need to do some more work to figure out how to map the offsets above to the data section. Some more greps that are useful:

strings -8 40 | grep password
strings -8 40 | grep backdoor
strings -8 40 | grep "\<html

Next, we can run binwalk against the data file and auto-extract all the JFFS2 filesystems:

# binwalk --dd=JFFS2:jffs2:20 40

We get a bunch of stuff, including:

DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------------------------------------------------
781406    	0xBEC5E   	JFFS2 filesystem data big endian, JFFS node length: 52321
812698    	0xC669A   	JFFS2 filesystem data big endian, JFFS node length: 55456
814198    	0xC6C76   	JFFS2 filesystem data big endian, JFFS node length: 1121
<snip>
7992985   	0x79F699  	JFFS2 filesystem (old) data big endian, JFFS node length: 53312
7992993   	0x79F6A1  	JFFS2 filesystem data big endian, JFFS node length: 222272

I've tried to mount JFFS2, with not much luck, but here's how:

modprobe mtdram total_size=32768 erase_size=256
modprobe mtdblock
sudo modprobe mtdchar
sudo mknod /dev/mtdblock0 b 31 0
dd if=2686A8.jffs2 of=/dev/mtdblock1
mkdir mnt
mount -t jffs2 /dev/mtdblock1 mnt/

Likely the byte order is screwing us, this command is known to work:

jffs2dump -r -e convimage -b 2686A8.jffs2 

It fails, likely my offsets are off, but you get the picture. Squashfs and Cramfs are much easier to extract, and the steps are the same, Happy Hunting!

UPDATE

Huge thanks to the author of binwalk and owner of http://www.devttys0.com Craig. He wrote in with some awesome helpful tips for pulling apart the DIR-655 firmware:

JFFS2 signatures are tricky; the signature is actually for an individual JFFS2 node (an entire JFFS2 filesystem will have many nodes). So if you only see a few JFFS2 nodes, as in the extracted gzip data from the DIR-655 firmware, they're probably false positive matches (the JFFS2 node "magic bytes" are only 2 bytes long). So the JFFS2 signatures that you were seeing were just false positive matches. What sticks out to me though is the gzip match in the gzipped data extracted from the firmware image:


    $ binwalk 40
    DECIMAL         HEX             DESCRIPTION
    -------------------------------------------------------------------------------------------------------
    781406          0xBEC5E         JFFS2 filesystem data big endian, JFFS node length: 52321
    812698          0xC669A         JFFS2 filesystem data big endian, JFFS node length: 55456
    814198          0xC6C76         JFFS2 filesystem data big endian, JFFS node length: 1121
    2425639         0x250327        LZMA compressed data, properties: 0xA0, dictionary size: 67108864 bytes, uncompressed size: 41985 bytes
    2425815         0x2503D7        LZMA compressed data, properties: 0x94, dictionary size: 67108864 bytes, uncompressed size: 41985 bytes
    ...
    2935884         0x2CCC4C        gzip compressed data, from Unix, last modified: Mon Jun 27 03:32:04 2011, max compression
    7990527         0x79ECFF        LZMA compressed data, properties: 0x84, dictionary size: 1073741824 bytes, uncompressed size: 335544320 bytes
    7992985         0x79F699        JFFS2 filesystem (old) data big endian, JFFS node length: 53312
    7992993         0x79F6A1        JFFS2 filesystem data big endian, JFFS node length: 222272
    8009671         0x7A37C7        LZMA compressed data, properties: 0x94, dictionary size: 335544320 bytes, uncompressed size: 335544320 bytes
    8015031         0x7A4CB7        LZMA compressed data, properties: 0x84, dictionary size: 872415232 bytes, uncompressed size: 536870912 bytes
    8018831         0x7A5B8F        LZMA compressed data, properties: 0xA0, dictionary size: 469893120 bytes, uncompressed size: 603979776 bytes
    8018991         0x7A5C2F        LZMA compressed data, properties: 0xB8, dictionary size: 1073872896 bytes, uncompressed size: 603979776 bytes 


The gzip match has a timestamp that is within one minute of the original gzipped file found in the firmware update image at offset 0x40, so that's a good sign. Extracting and uncompressing the gzip file at offset 0x2CCC4C above reveals that it is a CPIO archive:

    $ binwalk 40 -y gzip --dd=gzip:gz
    DECIMAL   HEX       DESCRIPTION
    -------------------------------------------------------------------------------------------------------
    2935884   0x2CCC4C   gzip compressed data, from Unix, last modified: Mon Jun 27 03:32:04 2011, max compression
    $ gunzip 2CCC4C.gz 
    gzip: 2CCC4C.gz: decompression OK, trailing garbage ignored
    $ file 2CCC4C 
    2CCC4C: ASCII cpio archive (SVR4 with no CRC)


Which can be extracted with the cpio utility to get the file system contents:

    $ cpio --no-absolute-filenames -i < 2CCC4C
    $ ls
    bin  boot  dev  etc  home  init  lib  mnt  proc  root  sbin  sys  tmp  usr  var  www


So basically the file system was built as a compressed CPIO archive, then concatenated with the kernel, then the whole thing was gzipped. Likely the device does use JFFS2, but the contents of the CPIO archive are extracted to the JFFS2 partition, rather than putting a JFFS2 image into the firmware update file.

Be sure to check out his web site and training!

Resources

Stories

Paul's Stories

  1. Infamous Hacker Heading Chinese Antivirus Firm? - So, a Chinese hacker started an AV company, what's the problem with this? I mean, at least he's not making his own drugs and shooting people in Belize, sheesh… And I mean come on, he needs some extra cash to at least buy an LCD monitor…
  2. Hakin 9 Cross Site Scripting - "So we all remember DICKS". Yea, I mean, it was bound to happen. If you present yourself in this way in our security industry, you will be outed by the community. And we will find XSS in your web site. Just saying'
  3. tweets about your sick cat threaten our security health - I think this is one piece of the security puzzle that should garner more attention. Sure, you can educate your employees not to post stuff on social networking sites, but that will fail. The need to tweet that picture of your bagel with GPS meta data is too strong. People must know what I am eating for breakfast and which airport I am in waiting to get on a flight. Is the answer to just educate, or should it be more? What if you were to look at what employees post, then it gets creepy. Is it really an invasion of privacy or just pulling together already public information?
  4. Twitter unintentionally resets thousands of passwords - Oops. I did not get one of these emails, reminds me of the Blackhat incident this year.
  5. Adobe confirms customer data breach - What more could Adobe screw up when it comes to security? Oh yea, they can have a SQL injection vulnerability that causes data to be breached. Icing on the cake in a sea of vulnerability updates for all Adobe products this week. This week? How about every week. They should throw away all of their code and start over.
  6. Cybersecurity bill fails in U.S. Senate - I'm not sure how legislation will make things more secure. If you are responsible for critical infrastructure, you are already doing some level of security because last I checked the Internet was still up. While PCI may help many by having a standard, I'm not sure federal legislation will have the same effect. Although, if done right, could a bill be put together to make people be secure? The problem is what is the punishment, making people cut the Whitehouse lawn?
  7. For Sale: Cheap access to corporate computers - This one just amazes me, if you want access to Fortune 500 computers you can just buy it. Even if a good guy buys the list, its a moving target. Shows how sad the state of security really is these days and how bad we are losing.
  8. Skype fixes e-mail security flaw - This one was bad too, gain access to anyone's Skype account! The hole has been closed, but it was a big one.
  9. Enterprises can obtain value from red teaming exercises, expert says - Sure Red Teaming is great, you now know where the holes are, and new ones will crop up. What can we do in order to get people to implement the defensive recommendations? Also, pen testing is about testing your defenses in a controlled environment and making you aware of risk. The really hard stuff is having to fix your environment permanently.

Larry's stories

Jack's FutureHistory

  1. Exercise your right to vote! No, it isn't 2016 yet, but if you are an (ISC)2 member in good standing (hold CISSP or other of their certs) voting for the BoD starts November 16.
  2. Size matters especially when talking about IPv6 address space. An older blog post, and not quite perfect, but pretty good.
  3. Pirate Bay down due to DDoS but that's boring. What's interesting is their reaction: "The Pirate Bay said it wasn't too concerned about the attack and said it would use the downtime to perform database upgrades." Kudos to TPB for good ops.
  4. Adam Shostack asks where is the Nate Silver of InfoSec? And starts some interesting conversations about the predictability of our world, leading to this follow-up post.

Allison's stuff

  1. “I Will Use a Bomb to Destroy an Airplane,” Computer Virus Says on Victim’s Behalf This is from a few weeks ago, but I found it so interesting I'm going to bring it up anyways
  2. Someone tries to sell an anti-DDOS product by launching a DDOS attack Someone is really bad at marketing.
  3. Cyberwarfare evolves faster than rules of engagement Who would have thought?
  4. New Java Attack Introduced into Cool Exploit Kit Just another news post showing how the turnaround time between exploit discovery and use in exploit kits are so low. Patch your Java plugins, or at least disable it.
  5. Anonymous Hackers to start #OpFuelStrike, threatens to attack International Oil Companies Sounds to me like it's just going to be another excuse for them to spike gas prices.