Two weeks ago today, Microsoft released a bunch of bulletins for Patch Tuesday. One of them - ms11-058 - was rated critical and potentially exploitable. However, according to Microsoft, this is a simple integer overflow, leading to a huge memcpy leading to a DoS and nothing more. I disagree.
Although I didn’t find a way to exploit this vulnerability, there’s more to this vulnerability than meets the eye - it’s fairly complicated, and there are a number of places that I suspect an experienced exploit developer might find a way to take control.
In this post, I’m going to go over step by step how I reverse engineered this patch, figured out how this could be attacked, and why I don’t believe the vulnerability is as simple as the reports seem to indicate.
Oh, and before I forget, the Nessus Security Scanner from Tenable Network Security (my employer) has both remote and local checks for this vulnerability, so if you want to check your network go run Nessus now!
Locks that can re-key themselves?
As I’m sure you all know, I normally post about IT security here. But, once in awhile, I like to take a look at physical security, even if it’s just in jest.
Well, this time it isn’t in jest. I was at Rona last week buying a lead/asbestos/mold-rated respirator (don’t ask!), when I took a walk down the lock aisle. I’m tired of all my practice locks and was thinking of picking up something interesting. Then I saw it: a lock that advertised that it could re-key itself to any key. Woah! I had to play with it.
Now, maybe I’m an idiot (in fact, my best friends would swear it). But I hadn’t ever heard of a lock that can do that before! So I did the obvious thing: I bought it, took it apart, figured out how it worked, then took pictures of everything.
Watch out for exim!
Most of you have probably heard of the exim vulnerability this week. It has potential to be a nasty one, and my brain is stuffed with its inner workings right now so I want to post before I explode!
First off, if you’re concerned that you might have vulnerable hosts, I wrote a plugin for Nessus to help you find them (I’m not sure if it’s in the ProfessionalFeed yet - if it isn’t, it will be soon). There’s no Nmap script yet, but my sources tell me that it’s in progress (keep an eye on my Twitter account for updates on that).
Taking apart the Energizer trojan – Part 4: writing a probe
Now that we know what we need to send and receive, and how it’s encoded, let’s generate the actual packet. Then, once we’re sure it’s working, we’ll convert it into an Nmap probe! In most of this section, I assume you’re running Linux, Mac, or some other operating system with a built-in compiler and useful tools (gcc, hexdump, etc). If you’re on Windows, you’ll probably just have to follow along until I generate the probe.
Taking apart the Energizer trojan – Part 3: disassembling
In Part 2: runtime analysis, we discovered some important addresses in the Energizer Trojan – specifically, the addresses that make the call to recv() data. Be sure to read that section before reading this one.
Now that we have some starting addresses, we can move on to a disassembler and look at what the code’s actually doing. Fortunately, the author made no attempt to disguise the code or pack or or anything like that, so a simple disassembler is all we need to examine the code.
A word of warning: this is the longest, most complicated section. But stick with it, by the end we’ll know exactly how the Trojan ticks!
Taking apart the Energizer trojan – Part 2: runtime analysis
In Part 1: setup, we infected the system with the Trojan. It should still be running on the victim machine. If you haven’t read that section, I strongly recommend you go back and read it.
Now that we’ve infected a test machine, the goal of this step is to experiment a little with the debugger and learn a little about the Energizer Trojan. This can all be discovered with a simple disassembler, but I find it more fun to take apart a live sample. All we’re going to do is add a breakpoint at the recv() function and see where it’s called from.
This step is going to require Debugging Tools for Windows. If you haven’t installed it already, install it on the victim machine.
Taking apart the Energizer trojan – Part 1: setup
As most of you know, a Trojan was recently discovered in the software for Energizer’s USB battery charger. Following its release, I wrote an Nmap probe to detect the Trojan and HDMoore wrote a Metasploit module to exploit it.
I mentioned in my last post that it was a nice sample to study and learn from. The author made absolutely no attempt to conceal its purpose, once installed, besides a weak XOR encoding for communication. Some conspiracy theorists even think this may have been legitimate management software gone wrong – and who knows, really? In any case, I offered to write a tutorial on how I wrote the Nmap probe, and had a lot of positive feedback, so here it is!
Just be sure to take this for what it is. This is not intended to show any new methods or techniques or anything like that. It’s a reverse engineering guide targeted, as much as I could, for people who’ve never opened IDA or Windbg in their lives. I’d love to hear your comments!