What else I did at Black Hat / DefCon–the Core DataMatrix Contest

Black Hat, and its associated sideshow, DefCon, consists of a number of different components. Training, Briefings, Exhibition and Contests, all make up part of Black Hat, and DefCon is a looser collection of Workshops, Events, Parties, Talks, Villages, Contests and numerous other things besides(*).

Perhaps the thing that gave me the most fun this year was the contest that I entered at Black Hat and at DefCon. The contest was run by Core Labs, a part of Core Security Technologies, and featured the theme of reverse engineering.

Reverse Engineering is the skill of looking at someone else’s code – in source code or binary form – and figuring out what the code does, and more importantly, how best to make it do what you want. This often involves exceeding the original design specifications – which is perhaps the simplest and most inclusive definition of “hacking”.

In the DataMatrix contest, the code (or at least, a portion of it) is given to you in source form, in C#. You are told that this code is running as part of a server, and you are given access to the server in the form of two webcams and an output screen. The output screen displays a score sheet, the views from each webcam, and a ‘debug’ output window. I’ve lost the link to the Black Hat version of the code, but here’s the DefCon code.

The webcams are the only form of input to the server that are available to the contestants. Each contestant is given a DataMatrix containing their activation code. This is a bitmap (kind of like a two-dimensional barcode) with some “registration” values around the edge, and squares either black or white in the middle.

And that’s it – that’s all the help you get.

But then, that’s probably all the help you’ll need.

The first challenges

The first challenges are relatively easy. First, you activate your userid by showing the webcam your initial card, and then you see there’s a function called “process_activate” – that sounds like it’s the function that was used to activate your card.

It’s fairly simple to see that this must use the single byte command (in the “cmd” variable) “1”, along with your two byte userid and four byte password, to register you in the system as an active user. It also increases a user-specific value, “score”. To make this easy to understand, we’ll call this “scoring a point”.

Then you see a function “process_free” – from the code, this is clearly a free point. All you need is a command “10”, and your userid, to score a point.

Another function, “process_pieceofcake”, is almost as easy. Command 11, and your userid, plus another four bytes which are simply the two’s-complement of your userid. Easy. In fact, in the Black Hat version, this was even easier, if I remember correctly, but I don’t have the code handy.

“process_name” is clearly one to call early on, because it gets you the bragging rights of putting your own name in the high score table. Plus, it gives you five points more. Pretty good, huh? By now you should have eight points.

Some more interesting challenges

“process_regalo” took my interest next, since it talks about a “gift_list”. Regalo is, apparently, Spanish for “gift”. This one’s strange, because the process has some activity even when the command code isn’t the code expected.

So, I took a look at what that path does. Checks four bytes for the user’s password, and if the “data_regalos” value for this user is less than 10, increments it, and then assigns an extra point to a randomly selected member of the gift list.

Having figured that out, I realised that the quicker I get on the gift list, the quicker I start racking up the points. So, I solved the little coding conundrum (did you figure that one out yourself?) in the other path of process_regalo, and added myself to the gift list.

Five times.

Yeah, five times – did you spot that in the code?

“process_fabe” and “process_fabe13” – those were a little harder. You have to not only crack an MD5 hash (not difficult, but hard), but in the “fabe13” case, figure out what the appropriate “encode” is for the “decode” function. [ROT13, if you didn’t get it]

“process_enqueue” – nasty, this one sends a message to an email address at mailinator.com that you have to figure out for yourself. I still haven’t figured it out. So, I also haven’t got the points from “process_claimMessage”.

“process_sync” was one function where I knew I had an advantage. It requires the use of a .NET Random function, and because I spend a fair amount of my development time in .NET, I knew that I could use my own system to figure out what times the sync function was expecting me at. Occasionally, the webcams weren’t reading my cards quickly enough, but that’s OK. I didn’t necessarily need a whole lot of those points.

Ladies and Gentlemen, we have a winner!

So, as you’ve probably guessed by now, using these functions I managed to rack up quite a number of points, and as it happened, I conquered the Black Hat competition. 60 points to me, 27 to my nearest opponent.

As a result of this, I am now the proud owner of an iPad. Yes, I know, all those things I’ve always said about Apple, and here I am, walking away from a competition with an iPad 2. The irony is almost unbearable. I’ll tell you later what I think of the iPad.

Then comes DefCon

DefCon started out much the same – I was streaking ahead of the competition, largely because the contest was better attended, and I’d already got my foot into the gift_list early on.

Then I saw the part of the server code that was new – it allowed you to write a limited form of program to execute on the server, that would randomly add points to your score. I entered that, and sure enough, I got a pile of points very quickly – about twice as many as I had at Black Hat.

I thought that meant I was going to win the prize.

Sadly, I hadn’t taken into consideration that this was DefCon. The people there are sometimes more devious (though there are also an awful lot of wannabes).

Sure enough, two of my competitors executed the portion of code that allowed them to dump out the list of executing code, as well as to remove the code sample I had submitted. That way, they could copy my code in order to give themselves points, and remove my ability to add points.

In a way, I almost felt like this was kind of cheating – what, they couldn’t write their own code? But, realistically, this was simply a part of the challenge – if I had been as good at reverse engineering as I felt I was, and a little less cocky, I would have spotted this functionality and taken advantage of the means with which to prevent it.

As it was, I came in third, and won a t-shirt. But the joy of winning the Black Hat contest is still something I’m proud of, and grateful to Core for letting me play their games.

NCSAM 2011–Post 21–Failure is always an option

For my last post in the National Cyber Security Awareness Month, I’d like to expound on an important maxim for security.

Failure is always an option – and sometimes the best

If you can’t handle a customer’s credit card in a secure fashion, you shouldn’t be handling the customer’s credit card.

If a process is too slow when you add the necessary security, the process was always too slow, and can not yet be done effectively by modern computers (or the computers you’re using).

If you enable a new convenience feature, and the rate of security failures increases as a result, the convenience is more to the hackers than to the users, and the feature should be removed or revisited.

Accept your own failures and deal with them

Sometimes there’s nothing to do but to say “Oops, that didn’t work”. Find something else that does.

If you’re writing software code, expect to encounter failing conditions – disk full, network unresponsive, keyboard stuck, database corrupt, power outage – all these are far more common than software developers anticipate.

Failure is not the exception, it is a part of life in an uncertain universe.

Handle other people’s failures gracefully

Other people will fail you.

This is not always their intent, nor is it necessarily something that they will recognise. Do not punish unintentional failure as if it was an intentional insult. Educate, where possible, redirect otherwise.

Where failure is intentional, be firm and decisive. Do not allow deliberate failure to continue unhindered.

Failure is always a necessary part of innovation

Innovation is doing that which has never been done before.

As a result, no one knows how to do it correctly. You will fail, a lot. If you are always right, it is because you are doing something that you already know.

Because failure is ubiquitous, look for it everywhere

Part of being a security expert is the ability to see where people, process and technology are likely to fail, and how someone might take advantage of that, or cause you disadvantage.

Turn “I can’t imagine how that might fail” into “I can see seven different ways this could screw up, and I’ve got plans for eight of them”.

And yes, I failed to finish writing this in National Cyber Security Awareness Month.