As a technologist and security enthusiast, part of the “fun” we have at work is tossing around attack scenarios and challenging each other with situational risk. This time it started out with:
If I steal credit card track data, I can make HUGE purchases (and perhaps return for cash).
If I steal PIN data, I can get cash directly.
If I steal health-related data in bulk from a doctor’s office, the most profitable thing I can do with it is…
Let’s face it, nerds like space. After all, it IS “the final frontier…” For the duration of the Space Age, NASA has been the primary way that young dreamers have found their role in non-earthbound technologies. For those with the hacker spirit, that may change.
Apparently, someone must have activated Santa’s badge to our secured facility. It seems he then took it upon himself to surreptitiously leave gifts around the office for us. While I hate to admit it, mine seemed way too fitting – “The Official Dictionary of Sarcasm” by James Napoli. I can only assume the subtitle, “A Lexicon for Those of Us Who Are Better and Smarter Than the Rest of You,” was not intended to be sarcastic and was, in fact, a compliment toward me.
But let’s not dwell on that, lest I analyze it more and come to the realization I may have a character flaw (yes, just one).
The Hacker’s Choice (THC) has recently released THC-SSL-DOS, a new tool for performing an SSL-exhaustion attack.
In this type of attack, the client (attacker) creates multiple SSL handshakes. This is done by issuing many SSL-renegotiation requests to a web server (target), or by using new TCP connections for multiple, initial SSL negotiations. Because it takes more processing power on the server-side to handle SSL handshakes, one or two clients (even with limited bandwidth) are able to utilize most or all of the server’s processing ability. This prevents other legitimate users from accessing the system, thus creating a Denial of Service (DoS).
This new tool has received a lot of press in the last few days (at least within the security community). This bothers me, but not because I don’t think the tool is worthy of press - THC-SSL-DOS is an excellent proof-of-concept tool that is up to par with the many other wonderful THC tools.
My concern lies in the fact that this vulnerability has been known for many years. The THC-SSL-DOS release notes include the following statement:
This problem affects all SSL implementations today. The vendors are aware of this problem since 2003 and the topic has been widely discussed.
It seems that this situation illustrates one of the all-too-common patterns in how vulnerability disclosures play out:
Doing security well is not easy; it takes time, effort, and resources. The release of THC-SSL-DOS should serve as yet another reminder of how important it is make every effort to try and do things the right way the first time.
If and when mistakes do happen, the aim should be to address them before they become a significant issue.
Dave Russell from 403 Labs gave a presentation at this past week’s Computer Forensics Show in San Francisco, CA titled “A Hacker’s Method to Your Madness.”
In the days that followed the events of Hacker Jeopardy at Defcon 19, I sorted everything out. I decided I wanted to pass along my lessons from the event. It has applicability not only to technology, but so many things that we encounter daily. I also plan to submit a Defcon presentation next year on the making and breaking of the game in the hopes others will see the iceberg sooner than I did and change course.
From the experiences from the previous year’s Defcon 18, we figured out that the audience didn’t want/need to see some of the behind-the-scenes stuff like unlocking a game, editing a team or the like, so DC 19 featured a three-laptop networked configuration based on Windows Communication Foundation (WCF), which I also had never worked with.
Did I mention I only had five weeks to code and test this?
I learned a painful lesson at Defcon 19 this year. It actually got me thinking about testing in a much broader sense, hence the blog post. Let me start by setting the stage.
Hacker Jeopardy is a contest that has been around since Defcon 2. It’s a bawdy, hilarious and, well, let’s just say over-the-top performance that runs much like the real game. The main difference, at least the one I will mention here, is that the questions are centered on “Nerd Trivia.” It would be a mistake to say it’s all “hacker” stuff; there are plenty of other things in the mix. Your basic hacker, however, should have enough breadth to hold their own against the categories presented. It is played in teams of three, with the winner taking home a coveted Black Badge that allows access to all Defcons in perpetuity for free. Pretty sweet. Also very high pressure and extremely visible.
Two years ago, I found myself shaking my head as a software developer. The game, while it had matured, still made use of a PowerPoint slide deck to drive the game, and was exceedingly manual. Thank goodness for that, as we’ll see later. I thought to myself, “Why not offer to update the game and bring it into the Windows 2000 era at least?” So I contacted the game’s host, Winn Schwartau, and the game’s organizer, G. Mark Hardy, and offered my services, not knowing if they’d just tell me to get lost.
To my surprise, they accepted, and provided a list of things they’d like to see in the revamp. Cool, we’re off!
I wanted flair, so I started using the new Windows Presentation Foundation stuff, which I had never touched (I’m an old Win32 GUI/MFC programmer, this new-fangled stuff is strange!).
Nonetheless, I cut my teeth on it and at Defcon 18 debuted the new game. It featured large 4” light-up buzzers which were beer and drunk resistant (did I mention there is a beer drinking component to the game? It definitely was a design decision!) all feeding into custom hardware.
The hardware was based on the 56F800x chip that Joe Grand had used in the Defcon electronic badges for two years, so I figured we had a good relationship with Freescale (the chip vendor). Sure enough, they provided all the tools and chips to build the custom hardware. The hand-written firmware fed buzzer data (bidirectionally) back to the controller laptop over a USB-as-serial link. Relatively simple, but I was pretty proud of it.
The first game revealed an annoying firmware bug: I was not clearing the serial buffer when a buzzer was pressed, so it maintained a queue of buzzer presses, which was REALLY bad when people slammed a buzzer 50 times. A quick firmware update that night solved the problem and the game ran beautifully the rest of the con.
Defcon 19 could only go better, right? Check out Part 2 here.
