.:: Keypicking :: Anything And Everything For Locksmiths, Hobbyist Lock Pickers, Locksport, Lock Picking, lockpicks, cutaways and Security. Simply The Best Lockpicking Forum Around!

As I started already passing information between keypicking and koksa a links posted on koksa:
http://tresoroeffnung-bayern.de/blog/20 ... hloessern/

And a short summary: There is a tool publicly available in Germany which opens La Gard Safeguard, Basic and 33E locks until about 2014 and S&G 6120 series locks within about 15 minutes just via the keyboard cable.

I assume the weakness was known some years before (since 2014?) to safe technicians which kept quiet. And I assume the tool is not only available in Germany. This tools looks to me like what he is talking about: http://www.taylortechtools.com/phoenix (came up after a very very simple search as the first hit). So if you have such a lock you might want to consider a replacement.

I marvel at the complete and utter design failure that would make this possible.
When designing something like this, from a security perspective you have ONE JOB.
And the security barrier - trusted vs untrusted side - is literally a physical wall. There should be absolutely no chance of the sort of confusion that frequently occurs in software when it comes to access control, authentication and trust. By plugging into the keypad connector you should only be able to do exactly what you can do using the keypad itself, i.e. enter codes with enforced lockout delays.

To make matters worse, even evaluating the very basic principles of operation and security properties of electronic, "intelligent", security products takes quite the effort.
I have done it to varying degrees for a couple of clectronic access control systems and, well, lets just say I recommend combining them with a mechanical lock so you need both to actually get in...

Anyone knows what sort of attack this is? Backdoor? Memory corruption in the protocol implementation? Side channel / glitching attack?

This is why we can't have nice things...

It measured the current consumption and how long it takes for the lock to fault out on wrong code. The coding is done such that it compares the stored number with the inputted number digit by digit and bails out once one wrong is found. Thus the code execution time varies depending on how many digits you have correct.

The device also depowers the lock once it detects the lock is starting to beep at you, so it has no time to do an EEPROM write of the error count which would provide the lockout function. This then enables bruteforcing the numbers, basically giving you 10 options per number.

There is a DEFCON paper detailing this attack in detail.

Hahaha. Side channel attack then. I love it when electronic locks manage to replicate the issues of mechanical locks! It just turns out a lot worse when you can just feed it numbers instead of spinning a dial or poking at pins...
In computer circles, this type of attack (and how to avoid it!) was well known in the 70s, and I bet it had been done even before what you'd recognize as computers arrived (electromechanical phone systems for example). If you read ANY book on implementing cryptography and authentication it will tell you in very big letters (figuratively) to use constant time comparisions.

The depowering part is funny as well! I remember cheating a bit at Super Mario Land 2 for Gameboy using the same attack. It had save games (battery backed up), and if you lost all lives you had to replay the bosses. So when playing the last levels and dying all the time, I turned off the Gameboy when I died.
Apple also managed to make the same screwup in earlier iPhones.

As to replicating the issues of mechanical locks, a certain electronic lock with wireless transponders have managed to do it perfectly as well. The cryptography is reasonably tight, but... If you dump the keys from any lock in the system, you can produce transponders with full access. Even easier than mechanical locks since then you usually need atleast two locks, or one lock and a key...

That is probably the mentioned DEFCON paper:
https://media.defcon.org/DEF%20CON%2024 ... -Locks.pdf

Interesting attack with the EEPROM erase/write cycle timing! Slight twist on the classic.

If I would make a tool to open such a lock, I would definately make it like in the Hollywood movies where they plug it in, numbers start spinning wildly on the 7-seg display and then one by one the correct numbers drop in