The Scenario

The bonds in Addis Ababa are secured by a Lockitall LockIT Pro revision b.03, a surprisingly old software revision which claims "[w]e have verified passwords can not be too long." The lock is connected to a LockIT Pro HSM-1, but that hasn't stopped me the other half-dozen times I've run across one and I doubt it'll stop me now; it's time to get to work.

Understanding The Code

One notable feature the manual points out is that "[u]sernames are printed back to the user for verification", which has been true for multiple other locks in the past so calling it out now is strange; looking at the code for main(), I get it:

Apparently tired of calling puts() all the time, the Lockitall developers have graduated to using printf() and unlocked a whole new field of exploitation [1]. For those who haven't been immersed in CTF tactics for the better part of a decade, using printf() incorrectly creates format string vulnerabilities which can be exploited to read and write data wherever an attacker wants.

Exploiting The Code

Rereading the manual, the firmware should unlock the door if the HSM writes a flag in a specific location - but who says I can't write to that location myself? Having decided on a plan of attack, I first had to relearn how to perform format string attacks. Once I had read enough CTF writeups to get confident, it only took half an hour or so of flailing before I managed to get my format string working, write to the flag location and trick the lock into opening.

As someone who is knowledgable about binary exploitation but doesn't get hands-on often I found this challenge more difficult than the simpler memory corruption attacks I'd performed in locales elsewhere, as I sat on my flight to Russia I began to wonder if this is where things truly start getting difficult.