Tech Segment: Immunity Debugger Contest Winner
By Justin Seitz
The ID contest was a call to arms, to invite some of the security research community to develop some interesting tools using ImmunityDebugger. My contest submission was called Mike & Boo (this was to jive with the Sulley fuzzing framework, for those of you who aren't Monsters Inc. fans).
The concept was to provide an automated method for dissection of an unknown binary protocol which is typically a labor intensive, and error prone process. Generally when you are assessing a network application for bugs, you have to be able to understand how it processes packets, and be able to drive as far as you can into the packet parsing routines. Before Mike & Boo, you had two main methods to do this:
a) Fuzzing Using Genetic Algorithms
b) Manual Design Recovery :)
Fuzzing Using Genetic Algorithms
Fuzzing has become more and more intelligent as the years have gone by. No longer are we doing a cat /dev/urandom | nc to do bughunting. An excellent example of an intelligent fuzzer is the Evolutionary Fuzzing System (EFS) by Jared DeMott of VDALabs. Without diving into the details of what a genetic algorithm is and what it does, it is important to know that a genetic algorithm uses "fitness" to determine how much of the code in the target process has been covered. Code coverage is a common term in QA and security research, which just means how many functions did you touch when you sent in some data.
In order to measure code coverage on an application that you don't have the source code for, you have to understand how a disassembled binary is broken up. Each application is sliced into functions and basic blocks.
Functions are just like your standard function in any language, it takes parameters, performs a task, and returns a value (this is a generalization). Every function is broken down into smaller parts called basic blocks. A way to illustrate this using some Python code:
def paul(beer): happiness = "" if beer == "SamAdams": happiness = True elseif beer == "Pilsner": happiness = False return happiness
The function is "paul", and it would contain three basic blocks: the first if statement is a basic block, the second elseif statement is a basic block and generally the return statement will be treated as a basic block.
In assembly, basic blocks are terminated by conditional jmps (this is the if/elseif type statements).
When using genetic fuzzing, you must first analyse the binary, and then set breakpoints on all of the functions (or the basic blocks but doing basic blocks is extremely time consuming with little benefit). When you send in a packet to the target process, you monitor how many breakpoint hits you get.
For example to test Apache:
POOP / HTTP/1.1
Might result in a code coverage result of say 10 functions, which probably means it just hit the server, and it didn't recognize the request, and threw an error. This request would have a very low "fitness" score.
GET / HTTP/1.1
Might result in say 100 code coverage hits, which would have a very high fitness score. The genetic algorithm will keep this in mind when doing further requests, so it may mutate the GET request slightly and then see if it can achieve a higher count than 100. It will do this over and over and over again until it hits a maximum code coverage point.
While this is great for automating fuzzing, you can use it to discover how a binary protocol is constructed. The fuzzer will slam around at the process until it starts getting better and better coverage, but this can take hours or days until you get a good set of results. This isn't good, and can be frustrating or error prone.
Let's examine "manual design recovery" :)
Manual Design Recovery
The manual way of taking apart a protocol involves live dynamic analysis with a debugger. Dynamic analysis means you are observing the process as it's running, static analysis means you are using a tool like IDA to look at the disassembly without actually running the process.
To begin, we first have to know what port the process is running on. Using ImmunityDebugger, this is simple: File->Attach will bring up a list of processes, and their associated TCP/UDP ports. Easy as pie, pick the process you want to monitor, and click Attach. The debugger will break in and halt the process.
With the process halted, we now have to set breakpoints on the common Win32 routines that handle the reception of packets. To do this use the command bar at the bottom of the debugger and type in the following lines, hitting enter after each:
bp ws2_32.recv # recv is used for TCP bp ws2_32.recvfrom # recvfrom is used for UDP bp ws2_32.WSARecv # allows for more complex TCP packet reception bp ws2_32.WSARecvFrom # allows for more complex UDP packet reception
Excellent, now when a packet is sent from the network, the process will stop, and we can examine the packet contents. Hit F9 to resume the process, and fire up netcat. Using netcat, just send the target a packet ~ something like this:
echo "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdefghijklmnopqrstuvwxyz" | nc 127.0.0.1 1666
When you hit enter, the process should stop. If you look in the bottom right pane of Immunity Debugger (this is the STACK window) you will see the parameters of the receive call. You could do some more trickery here with those parameters, such as setting memory breakpoints, etc. but that is beyond the scope of this segment.
If you hit CTRL-F9 it will run the process til the end of the receive routine and stop on the RETN instruction. When this call returns, we are now going to be going back into the main process which is going to start processing the packet. Hit F7 (step-in) to get there.
Now the long story short is that you will single-step (F7 or F8) and watch in the top-left pane (the disassembly window) for your packet payload to be touched. An example of this would be:
CMP ESI, DWORD PTR DS:[EBX+C] ------------------------------- DS:[0091D94C] = ABCDEFGHIJ ESI=0091E954 = LARRYISGOD
What I have denoted is the instruction (CMP ESI, DWORD PTR DS:[EBX+C]) and below that is what is called the InfoPanel in ImmunityDebugger. The info panel is directly below the disassembly window, but above the dump (bottom left) window. It is used to show you what data an assembly instruction is using.
In the above case, we see that the process is comparing what is stored in EBX+C (ABCDEFGHIJ) to the value in the ESI register (LARRYISGOD). Obviously this comparison will fail as they are not the same, but we have gleaned a critical piece of information here: we now know that the first 10 bytes of our packet must be LARRYISGOD in order to drive further into the process. We can now change our netcat output to get past the first packet parsing routine.
Rinse, wash repeat the process until you have built up a good idea of how the packet parsing works, what bytes are required at particular offsets, and the overall length of the necessary packets. From there you can either use more manual techniques to try to find vulnerabilities or you can use a fuzzer that is pre-loaded with your test packet to try to find vulnerabilities.
So this process is slow, time consuming, and error prone. Enter Mike & Boo from the left.
Mike & Boo
Taking what we learned from the manual process, I aimed to automate the process and present the information in a friendly format for the analyst. The overall layout of how this works is depicted in beautiful ASCII art below:
Boo <-> ImmunityDebugger(Mike)
Pretty sweet eh? Boo is a server daemon who's job in life is to wait for Mike to call, and when he does, Boo sends a test packet to the target process. Mike's job is to run inside of ImmunityDebugger and automatically trap packets as they come in off the network. It then applies some simple heuristics to monitor what portions of the test packet were used in comparison routines inside the target process. Each subsequent run of the Mike & Boo system should produce a closer and closer depiction of the protocol (this part was cut out of the final submission due to time constraints, but it's coming!).
When Mike is finished, it actually sends back a graph to Boo, who stores the graph before moving on to the next test packet. I have linked to some example graphs which depict how Mike & Boo denote packet comparisons, packet length matches, etc.
This is really powerful in that the analyst can fire them up, have it generate test packets, and then analyse the resulting graphs, without having to spend a great deal of time doing it manually.
Links & Resources
- ImmunityDebugger - http://debugger.immunityinc.com
- EFS - http://vdalabs.com/tools/efs_gpf.html
- IDA Pro - http://datarescue.com
- Sulley - http://fuzzing.org
- OpenRCE - http://openrce.org
What I Won (SILICA >= Badass) - http://www.immunityinc.com/products-silica.shtml
Mike & Boo Graphs - http://www.openrce.org/blog/view/989/Binary_Protocol_Dissector
Great Example of Manual Recovery - http://dvlabs.tippingpoint.com/blog/2007/07/24/step-by-step-of-how-tpti-07-013-was-discovered
Contact me for a copy of Mike & Boo jms /at/ bughunter.ca I haven't publicly released it, but it is to ship with ImmunityDebugger in the February release.
Mini-Tech Segment: Maltego - The Ultimate Recon Tool
Maltego (Formerly Paterva), was brought to light at Blackhat/Defcon 07 by HD Moore and valsmith. It allows you to easily collect so much useful information about your target. I run it on OS X natvely as its a Java app. I downloaded the latest verison, uncompressed it, and then changed into its directory. From there I ran "bin/maltego &" and it start with no problems on my system. However, be certain to read the install instructions carefully, as you have to register it to enable all of the "Transforms", which are operations performed by Maltego. Kick off the process by hitting the "Pallete" and then clicking the "Domain" item and dragging it on to the graph area. Then right-click on it and click "All Transforms". From here you will get all sorts of neat stuff:
- Collects the DNS, Web, and Mail servers in the domain (same deal as BidiBlah)
- Collects people's email addresses based on their PGP keys, which is a nice way to make sure you have a valid email address
- Collects phone numbers, people's names and more importantly web sites that are affiliated or contain relavent information about your target
- Downloads all of the files on the web site and has its own metadata collector
Whats nice is that once you get an object on the graph you can right click on it and run transforms against that. Pretty soon you have this "Web" of information that collects so much useful information about your target that its scary. You should run this tool if:
- You are collecting usernames for password guessing against exposed services
- You are running email social engineering and client-side attacks
- For any social engineering engagement
Remember how the Tiger Team show had the team picking through the garbage to figure out who they use for tech support? Maltego most likely can find information such as that.
Stories of Interest
Quicktime 0day - [Larry] - I thought that this particular exploit was neat. The vulnerability exists in the 404 error message processing for streaming media in the "LCD panel". By manipulating the 404 message that gets processed, they were able to trigger code execution. Now we need to be careful of 404 messages!
Wireless Travels Bruce (or Chuck) Norris - [Paul] - So, you just shouldn't run an open wireless network. Here's a couple of good reasons:
1) Distance - From very far away someone can sniff your traffic, use your network, and launch attacks against hosts using your wireless network.
3) Clear-Text - No matter how hard you try, something may get sent in clear-text, i.e. your AIM login because AIM started up on accident.
4) Liability - If you can easily implement some security, there is no excuse for letting other people use your connection.
Linksys WRT54GL CSRF - [Larry] Even more for paul! Embedded device and CSRF!. This one will disable the firewall, but other changes are possible (say, enabling remote administration on the wan port?) My favorite quote:
During the attack, however, the owner of the router must be logged into the user interface and be surfing a manipulated web site. But this is not an infrequent situation, because users often search the internet for instructions on configuring certain parts of the device, and are logged into the router at the same time.
Ya, this is a certainly valid attack. [Paul] - So, I know that no one besides a fellow SANS instructor believes me, but I found this bug a few months ago while researching for my (IN)Secure Magazine article. Most home-base wireless routers are vulnerable to CSRF. Now, is it s huge deal? I don't think its the end of the Internet as we know it, I think a more serious bug is leaving the default password, which doesn't require a vulnerability. Also, I don't think that you are going to 0wn many people with this exploit given the conditions. However, if could find a nice way to preempt users to login into their routers, then send them a link to click on, now you're talkin'.
Polish youth hacks Tram system - [Larry] - ...and causes 4 derailments and several injuries by tripping the track routing switches. The track routing switches are controlled by *insert dramatic music here* Infared! Apparently the 14 year old youth broke into a rail yard to analyze the switches - likeley by fuzzing the Infared on the switch - much like adam laurie dod for hacking hotel TV systems...
MS08-001 is bad, like really bad... - [Paul] - Like, break the Internet bad. A flaw has been found in the TCP/IP stack in most major windows operating systems, and BONUS, can be used to exploit machines remote and bypass the Windows firewall. Sweeeet! It has to do with the way XP handles multi-cast packets, which is interesting as many organizations may run multicast and not firewall it properly. Depends on your firewall, some firewalls will just drop multicast, others will let it through, and some will terminate it. Go back to the office on Monday and find out.
Free Jawbone headsets at CES - [Larry] - Just give them your old bluetooth headset. This is nice, because Josh Wright's demo of bluetooth headset injection/recording hack was done with a Jawbone - because that is what Josh had on hand.
iPhone "Malware" - [Paul] - This doesn't sound like malware: "The fake firmware prep package did in fact install a collection of well-known iPhone tools (Erica's Utilities). However, uninstalling the package damaged some other previously installed programs including OpenSSH, Launcher and Doom." But sounds more like an 11-year old boy creating some prank software, which is exactly what this was. I think better malware for this delivery would be to export the metasploit payload and package that for the Installer.app. However, you would need to specify and IP address to connect back to, so it would be shut down pretty fast unless they got fancy and developed a P2P protocol for the iPhone metasploit payload. Then I would be impressed.
Now that's secure storage - [Larry] A new device at CES for an external enclosure that performs the encryption on the disk - to decrypt a smartcard and a pin are required.
787 Hackable? - [Larry] - Allegedly the new networking features of the new 787 are attached to flight and control systems, either directly or via a "firewall". Either way, the FAA is pretty clear that any flight control systems need to be airgapped form the passengers. This is scary - hackers on a plane anyone (maybe hackers on a crashed plane...)? Mark Loveless (aka Simple Nomad) of hacking the friendly skies fame commented in this article.
Malicious Digital Picture Frames - [Paul] - This is a great way to spread malware, just embed it in a digital picture frame and when users plug it into their computer to upload pictures, BAM!, a trojan! I like it, there was some debate as to how easy this would or would not be to infect devices at the manufacturer. However, many companies outsource manufacturing to another company. Hack into that company and you've got a better chance. They mentioned anti-virus software as a way to prevent this from happening at the manufacturer, so if you're smart you infect the PCs with just enough malware to get a dropper on the device, and hopefully slip past A/V. *more evil grins*
Hacker safe site hacked - [Larry] geeks.com. As part of the hackersafe program (and Scanalert), scheduled scans revealed issues, and at those times the logo should be removed. They suspect that the times that the compromises happened was during those times on Hacker Safe non-compliance. My word of warning - just because the website says it is safe, or you are using ssl (or the vendor is using a trusted card processor - say authorize.net), doen't always mean that your data is safe.
Top Gear host gets owned - [Larry] - Jeremy Clarkson publishes his back account info in an article claiming that we have nothing to fear about getting money stolen
Quote(s) of the week: "I have never known such a palaver about nothing. The fact is we happily hand over cheques to all sorts of unsavoury people all day long without a moment's thought. We have nothing to fear."
"The bank cannot find out who did this because of the Data Protection Act and they cannot stop it from happening again. I was wrong and I have been punished for my mistake."
The next statement revealed that 500 pounds had been transferred from his account. Egg meet face.
Facebook Spyware - [securethoughts.net] Fortinet Global Security Research Team discovered a malicious Facebook Widget actively spreading on the social networking site which ultimately prompts users to install the infamous "Zango" adware/spyware.
Facebook Voter Registration App Asks for SSN w/o SSL - [securethoughts] Turns out to be a false alarm. The widget doesn't load as an SSL-encrypted page, but the Ajax backend opens up an SSL-encypted link to the company who runs the widget. Still... seems like many users were happy to submit their SSN even though there wasn't even any 'appearance' of security.
FAA warns of Boeing 787 hacker vulnerability - [securethoughts] Boeing's still in the final stages of production on its 787 Dreamliner mid-sized jet, but the FAA has already spotted what looks to be a serious security vulnerability in the plane's IT infrastructure. Apparently the computers that provide the 787's passenger area with in-flight internet access and other amenities are physically networked with the main plane computers, including control, navigation and communication systems, which could theoretically provide a path for a hacker to screw with the plane, and even go as far as take full control of the 787.
Airline Security Priorities - [securethoughts] Airlines need to get their priorities straight and sort out stupid vulnerabilities before installing $40 billion anti-missile systems. Related to the above story (plus some anti-missile devices).
UK TV Presenter's Plan Backfires - [Linda] Presenter of UK's car show "Top Gear" published his bank details in a newspaper in an attempt to prove that the loss of unencrypted CDs containing 25 million bank records wasn't a big deal. He insisted that the worst that could happen would be that someone could pay money into his account. As a result, his bank details were used to set up a direct debit of £500 to a diabetes charity.
Proxies Leaking Authentication Credentials - [node5] According to this article some proxies, namely BlueCoat proxies, seem to leak authentication credentials to websites that are visited through that proxy.
CCC Sues German Govt to Stop eVoting - [securethoughts] "The German hacker group Chaos Computer Club today sued the German State of Hessen to prevent the use of electronic voting machines (Google translation) in the upcoming elections on January 27. This comes as a follow-up to the Dutch initiative 'We don't trust voting machines,' which succeeded in banning the same type of voting machines in the Netherlands."
Port Shuffling - [securethoughts] New interesting network security technique (similar to port knocking) to periodically change the listening port for a particular service using a cryptographic function and key to determine the current valid port number. All other invalid ports then become traps which can ban an attacker's IP, or simply return confusing results.
Another QT Vulnerability - [byte_bucket/securethoughts] QuickTime automatically tries to access a stream via HTTP if an RTSP connection cannot be established. A flaw exists in QT's ability to parse 404 error messages which are displayed in the LCD-style panel, which results in a remote buffer overflow. Vulnerability affects both Windows and Macs. Deny outbound connections from QT to avoid this one.
For Your Amusement
No more Tiger Team - [Larry] Noooo! I liked this show. Hrm, TruTV, want to have more episodes?
Dashboard Ninjas - [Paul] - I SO want one.
Trust me I know the internets - [securethoughts] Paul as a kid. ;)
Virus Tank - [securethoughts] I want one!