Author Topic: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2  (Read 30233 times)

0 Members and 1 Guest are viewing this topic.

Offline apis

  • Super Contributor
  • ***
  • Posts: 1667
  • Country: se
  • Hobbyist
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #50 on: July 28, 2015, 02:51:06 pm »
Hashing and salting would normally be the right thing to do. In this case it might make life harder for an attacker perhaps but if the attacker get the hash and the salt it won't work because 6 digits --> 1 000 000 combinations which isn't enough to prevent brute force attack.
 

Offline acourtois

  • Contributor
  • Posts: 13
  • Country: ca
  • Test_Coil
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #51 on: July 28, 2015, 05:56:28 pm »
Based on these simples rules :P;

- Six digits combinations maximum
- After 3 unsuccesful tries, locks up for 10 minutes
- According to Dave' captured traces;
   - Accepted sequence of 2 # shows definitively different traces than any unaccepted sequences
   - A 10 second delay between key presses allowed

- Print this chart with these sequences of tries :popcorn:
(It might be optimized, I don't know) :-//
123456 678902 001122
030405 334455 667788
991098 876543 321314
151617 181924 252627
282920 353637 383930
344647 484940 424357
585950 516869 606562
797073 808471 957174
727596

- Grab traces of each key-press
- Mark the pair of digits that are accepted

- You should encounter 8 pauses of 10 minutes ;)

So let's say that unbeknowst to you, the code is 766129
You see in your chart that these accepted sequences came up;
12 66 76 61 and 29 :-+

Revisiting the rules at the top, one can deduce easily
that the code cannot be anything else than 766129. :scared:

In a little more than 1 hour, it's cracked.

There is brute force |O and there is smart brute force. :popcorn:
Humans can do anything. And they will...
 

Offline eneuro

  • Super Contributor
  • ***
  • Posts: 1528
  • Country: 00
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #52 on: July 28, 2015, 07:22:21 pm »
if the attacker get the hash and the salt it won't work
Lets say we hide salt and hash inside 1KB bytes flash, where 20 bytes of hash will be stored not in sequence, but... based on used random (TRNG) salt in those 1024 bytes. maybe in spare time will try estimate number of combinations of possible 20 bytes MD5, assumming that salt will be two times bigger, so 40 bytes -2 bytes to index each of 20 bytes of final MD5sum, so MD5sum will located at (1024-20-40) TRNG bytes indexes and we need 20 to store MD5, but it can be not one salt, but a few and not one MD5, but a few times with encapsulated results from previous MD5. It is interesting how hard it could be to test all possible MD5sums composed of sparse bytes within 1KB flash range, but it can be 4KB easy as well-attecker will see only 1KB of random bits, even if he will be able read somehow flash memory-reading another open safe memory will not help, since each safe MPU will have different bits there and final MD5 sum hidden somewhwere insode this 1KB TRNG bits block  :-DMM

Another story is attacker have to read somehow MPU memory which will be not possible before it cracks safe code, while MPU is hidden inside and he have to open safe to get access to MPU abnd its flash...but it is OTP MPU additionally  :popcorn:

What can I say... mission impossible, unless someone spends one drink night in the bed with safe owner... who will be forced open the safe to take another bootle of drink kept inside safe  :-DD
12oV4dWZCAia7vXBzQzBF9wAt1U3JWZkpk
“Let the future tell the truth, and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I have really worked, is mine”  - Nikola Tesla
-||-|-
 

Offline eilize

  • Contributor
  • Posts: 25
  • Country: be
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #53 on: July 28, 2015, 08:42:03 pm »
hello,

i don't see why do you expect a current rise in case where you encode a bad digit.

exeample:

there is a rom, isn't it?
so you can use it + use interrupt (and not polling) to have exactly the same consumption

you use the digit to configure the offset  and use an AND function on the value of the cell's rom you read
(good cell ->value ==1
bad cell->value ==0)


or you can use NOP to match the same number of instructions.


don't you follow a bad path?
 

Offline DanielS

  • Frequent Contributor
  • **
  • Posts: 798
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #54 on: July 29, 2015, 09:28:51 pm »
Hashing and salting would normally be the right thing to do. In this case it might make life harder for an attacker perhaps but if the attacker get the hash and the salt it won't work because 6 digits --> 1 000 000 combinations which isn't enough to prevent brute force attack.
If you are somehow able to read the salt and hash data, you are also able to read whatever alternate representation of the correct key sequence may have been stored. The point of the hash is to eliminate any easily identifiable deterministic timing or macroscopic power variation related to any specific key sequence.

If the safe controller reads and compares the hash one byte at a time, then you will need a minimum of 16 failed attempts to read all 16 bytes of a 128bits MD5.

Another complication is that you need perfect knowledge of how the hash algorithm is implemented in order to do an offline attack. How does the salt gets mixed with input data? Which has function is used? Did the hash function use standard coefficients? Did it used the standard number of rounds? Is there any post-processing of the hash output? As soon as any of these differ by even one bit from your offline attack model, your offline brute force attack fails - the solutions you find offline won't match.
 

Offline Badger

  • Newbie
  • Posts: 5
  • Country: gb
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #55 on: August 01, 2015, 10:53:31 pm »
To compute MD5 on 8bit MPU like tiny ATTiny85 less than 1KB of code needed, so no need for any Unix systems  :palm:

Do you include "face palm" smilies in every post?

You missed the point again I didn't suggest it isn't possible to implement hashing (or salting) on a low-end MCU.

My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.

Password hashing: useful / necessary if you wish to stop the actual password from being compromised when an attacker gains access to one or more users' credentials - the attacker only get the hash and not the password. Probably irrelevant here because:
 1 the password can be stored on the secure side of the safe in a simple keypad-only system with a very small attack surface. In this case, if an attacker is able to gain access a stored password or hash, they're in the safe and the security has already been broken.
 2 the passcode space is susceptible to cheap forward search given its only 6 digits. If a hash was compromised, the passcode can be calculated from it.
 3 Hashing does not magically make a system immune to side-channel attacks. A hash function - and the subsequent comparison againt the correct value - would have to be coded to minimise or avoid such attacks. Coding a side-channel-immune password comparison is probably easier (if the designers even bothered to do that).

Password salting Salting prevents a  single forward search (i.e. brute force) attempt on a hashed password being used to attack multiple passwords concurrently. The safe only has one password. Relevant on web services / multi user OSs /etc but not on a safe with one password.

If the safe doesn't yield to side-channel attack, I'll bet it's because of more mundane factors such as input power supply filtering and not how the software's implemented.
« Last Edit: August 01, 2015, 11:24:10 pm by Badger »
 

Offline DanielS

  • Frequent Contributor
  • **
  • Posts: 798
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #56 on: August 02, 2015, 04:07:58 am »
2 the passcode space is susceptible to cheap forward search given its only 6 digits. If a hash was compromised, the passcode can be calculated from it.
 3 Hashing does not magically make a system immune to side-channel attacks. A hash function - and the subsequent comparison againt the correct value - would have to be coded to minimise or avoid such attacks. Coding a side-channel-immune password comparison is probably easier (if the designers even bothered to do that).
Those only work if the exact hash function is known. On operating systems and network protocols, all participating systems must agree on which hash algorithms to use and produce exact results out of the same input in order to interact. In self-contained systems, the hash only needs to be coherent within said system. Possessing a copy of the hash and salt does you no good if the exact hash function is unknown.

Side-channel attacks on SSL are possible only because every minute detail of SSL or any other standard are known to the attacker.
 

Offline apis

  • Super Contributor
  • ***
  • Posts: 1667
  • Country: se
  • Hobbyist
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #57 on: August 02, 2015, 08:22:15 pm »
Password salting Salting prevents a  single forward search (i.e. brute force) attempt on a hashed password being used to attack multiple passwords concurrently. The safe only has one password. Relevant on web services / multi user OSs /etc but not on a safe with one password.
It also helps if there is only one password since attackers typically have precomputed database of common password/hash combinations, so you should always add a salt when hashing passwords.

Those only work if the exact hash function is known.
You should almost always assume the attacker knows all the details of the system. Information will either leak to the attacker, or as in this case, the attacker has access to the hardware. If Dave was sufficiency motivated he could trace out the circuit and read the program from the micro-controller as well as any flash data and determine exactly how everything works. That is more or less always the case unless it's a one-off system that only one person has access to. What you are suggesting is known as security through obscurity and is generally best avoided since it typically only add system complexity (and thus the risk of making mistakes) without adding any real security.
 

Offline eneuro

  • Super Contributor
  • ***
  • Posts: 1528
  • Country: 00
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #58 on: August 03, 2015, 11:13:50 am »
My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.
Nope, there is reason to expect some quality since this lock was made not by China NONAME, but company which has experience in this field.
While I've shown that MD5 could be easy implemented even on low cost 8 pin ATTiny85 with 8KB of flash, there is a chance they did it right and maybe you watched too many James Bond films if you think you could crack this safe lock within hours or so :palm:
12oV4dWZCAia7vXBzQzBF9wAt1U3JWZkpk
“Let the future tell the truth, and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I have really worked, is mine”  - Nikola Tesla
-||-|-
 

Offline DanielS

  • Frequent Contributor
  • **
  • Posts: 798
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #59 on: August 03, 2015, 03:09:21 pm »
If Dave was sufficiency motivated he could trace out the circuit and read the program from the micro-controller as well as any flash data and determine exactly how everything works.
IIRC, Dave said the microcontroller appeared to be an old mask-programmable ROM type. Good luck reading the program off of that. Much simpler and cheaper to beat the heck out of the safe.
 

Offline apis

  • Super Contributor
  • ***
  • Posts: 1667
  • Country: se
  • Hobbyist
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #60 on: August 03, 2015, 04:58:08 pm »
If Dave was sufficiency motivated he could trace out the circuit and read the program from the micro-controller as well as any flash data and determine exactly how everything works.
IIRC, Dave said the microcontroller appeared to be an old mask-programmable ROM type. Good luck reading the program off of that. Much simpler and cheaper to beat the heck out of the safe.
I'm speaking generally with regard to security enginering, I don't think they have bothered to hash or encrypt anything in this particular case. It always comes down to what kind of effort you expect an attacker to be willing to make.

I think you underestimate how much effort people put into reverse enginering stuff (not simply to defeat security but also to keep track of the competition) and you underestimate how hard it would be to read the program in that mcu. It's an old chip, probably withouth any security features. I'm guessing it would be trivial with the right equipment and it might be trivial even without fancy equpment (but I'm not in a possition to prove it so we'll have to leave it at that. Fungus posted some interesting defcon videos that might give you a clue though.) Breaking the safe open would be easier in this case but you don't know where else this lock is used and what it's protecting. If you reverse engineer one of these locks you have reverse engineered all of them and it might well be worth the effort to many people.

The arrogant attitude of people who design stuff that "no-one would go through the trouble or be smart enough to decode a system" just because you couldn't is probably one of the main reasons why many security systems are so crappy. You should always assume the attacker knows how the system works and is smarter than you are. Analyse all attack vectors and make sure they meet the specifications you are designing for, don't rely on the attacker not figuring out you hid the key under the doormat. :scared:

The biggest problem (IMO) with adding obfuscating code in this case is that you risk to inadvertently leak more information, not less because more processing means you need to use more power and the processor generates more RF, etc. A more complicated system makes it easier to screw up, so why bother unless there is a clear benefit to doing so (KISS).
 

Offline f4eru

  • Super Contributor
  • ***
  • Posts: 1086
  • Country: 00
    • Chargehanger
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #61 on: August 03, 2015, 05:16:14 pm »
Quote
My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.
I woudn't be so shure of that.
The contents of the eeprom are passed to the MCU via a SPI. The EMC of that SPI could potentially be snooped on if there is a capacitive coupling to the wires going "outside".
Hashing and salting would very well prevent this atack, especially if the microcontroller serial number is used as salt, and therefore not visible on the SPI.

Offline eneuro

  • Super Contributor
  • ***
  • Posts: 1528
  • Country: 00
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #62 on: August 03, 2015, 08:32:23 pm »
It's an old chip, probably withouth any security features. I'm guessing it would be trivial with the right equipment and it might be trivial even without fancy equpment (but
I'm really interested in using (old) ATTiny85 MPU at home automation security system and that is why I'm interested in MD5 implementation and possibility to read back MPU flash, so quick research leads to this:
Bypassing copy protection in microcontrollers using glitching
http://reverseengineering.stackexchange.com/questions/1698/bypassing-copy-protection-in-microcontrollers-using-glitching

Quote
From time to time, forum posts are made by companies offering their services to read out protected ATmega chips. There are also sites, generally .ru, that offer these services. Price tends to be around $500-$1500 with a turnaround time of a few weeks.

I suspect at these costs, they are not decapsulating the chip and using a laser probe to reset the fuse bits. I have queried if they return the chip undamaged, but did not get a response.

However, even if the costs to read out protected AVR from flash read using ISP (lock bits) could be acceptable, still in the case of the safe lock, while MPU is inside it doesn't help to much if you brake sample safe MPU and read its code when this code will be different in other safe locks  :popcorn:

Anyway, to make those glitchers work as I read you have to have full control about MPU power, so you have to replace oryginal, so while you have access only to battery, but threre is regulator IC inside safe lock, caps, etc, you can't make successfull glitch sttack to try read MPu flash program code to be able try find place where hashed and salted password is stored  |O

Quote
In order to read out the flash contents for an Atmel AVR ATmega MCU?you can break the master chip. It doesn't return the chip undamaged, but provides the code and program.
They wrote that those services doesn't return you not damaged chip, but provides code and program, so it is not a trivial and probably not possible, when ... you can not send them MPu itself while it is inside safe lock  :palm:

That is why, robbers do not loose time to try guess any passwords, but use... explosives to destroy.. ATM.

However this attempt was avarded to epic fail watch why  :-DD

He, was lucky he survived this uncontroled expolsion-what a donk?  :palm:

And now how professional robbers open ATMs-they even protected adventitious unaware man to keep him in safe place during ATM explosion !!!  :o
« Last Edit: August 03, 2015, 08:44:53 pm by eneuro »
12oV4dWZCAia7vXBzQzBF9wAt1U3JWZkpk
“Let the future tell the truth, and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I have really worked, is mine”  - Nikola Tesla
-||-|-
 

Offline apis

  • Super Contributor
  • ***
  • Posts: 1667
  • Country: se
  • Hobbyist
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #63 on: August 03, 2015, 09:29:11 pm »
However, even if the costs to read out protected AVR from flash read using ISP (lock bits) could be acceptable, still in the case of the safe lock, while MPU is inside it doesn't help to much if you brake sample safe MPU and read its code when this code will be different in other safe locks  :popcorn:

Anyway, to make those glitchers work as I read you have to have full control about MPU power, so you have to replace oryginal, so while you have access only to battery, but threre is regulator IC inside safe lock, caps, etc, you can't make successfull glitch sttack to try read MPu flash program code to be able try find place where hashed and salted password is stored  |O
How hard it is differs from chip to chip, in some cases it's really easy because you can circumvent the copy protection or reset the read protection fuse with the right signals and voltage levels. In the end you can always decap the chip and circumvent read protection by probing the chip directly. In the video Fungus found a guy explains how he is reverse engineering chips that have a lot of extra security features specifically designed to prevent reverse engineering by decapsulating, but that isn't the case for general purpose mcus like this.

It might be OK to store a salt/serial in the chip if it's not normally accessible. I was talking about reverse engineering a system you have full access to in order to determine the details of how it's working (possibly destructively). In this case, if the attacker has already opened the safe, protecting the password is probably low priority so they might not have done that (but you never know). As for the eeprom leaking out as EMI when read, if that is a problem then hashing might help assuming there is no way for the salt to leak out as well.

Big companies can go to extreme lengths to reverse engineer the competitors products. Car manufacturers completely dissemble and test all parts of their competitors cars routinely to determine their marginal cost and other details for example. And you have to assume information will leak anyway. If it's only you who designed and use the system at home you can get away with hiding the design, but that is generally not the case for commercial products like this lock.

And yes of course, in the end most thiefs are not so clever and will just use powertools, bulldozers, explosives or put a gun to your head anyway.  :o :(

But in some cases, especially for networked equipment it can be really important to get the security right.
 

Offline DanielS

  • Frequent Contributor
  • **
  • Posts: 798
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #64 on: August 04, 2015, 10:30:43 am »
In the end you can always decap the chip and circumvent read protection by probing the chip directly.
Yes, given enough time and money, just about anything can be broken into. For a safe like this though, the electronic lock only needs to be good enough to make breaking the safe the conventional way more practical than attacking the MCU.

If you are already going to have to drill through the safe just to insert the EMI probe (the mounting holes should be plugged by bolts and washers) so you can attempt to read the SPI/I2C traffic, you might as well drill the hole in a place where you could directly pick the locking mechanism: measuring the exact location of that little plunger pin so you can drill it out from the front is much simpler than reverse-engineering the MCU. Since the MCU is inside a metal can inside the safe, you may need to drill into the MCU's box to get usable EMI readings anyway.

As far as extreme reverse-engineering and leaks go, how successful have hackers been at reverse-engineering WiFi, 3G and 4G chipsets to create open-source firmware and drivers for them? I do not remember reading about any successful attempts.
 

Offline Badger

  • Newbie
  • Posts: 5
  • Country: gb
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #65 on: August 08, 2015, 09:19:57 pm »
2 the passcode space is susceptible to cheap forward search given its only 6 digits. If a hash was compromised, the passcode can be calculated from it.
 3 Hashing does not magically make a system immune to side-channel attacks. A hash function - and the subsequent comparison againt the correct value - would have to be coded to minimise or avoid such attacks. Coding a side-channel-immune password comparison is probably easier (if the designers even bothered to do that).
Those only work if the exact hash function is known. On operating systems and network protocols, all participating systems must agree on which hash algorithms to use and produce exact results out of the same input in order to interact. In self-contained systems, the hash only needs to be coherent within said system. Possessing a copy of the hash and salt does you no good if the exact hash function is unknown.

Side-channel attacks on SSL are possible only because every minute detail of SSL or any other standard are known to the attacker.

https://en.wikipedia.org/wiki/Security_through_obscurity
 

Offline Badger

  • Newbie
  • Posts: 5
  • Country: gb
Re: EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2
« Reply #66 on: August 08, 2015, 11:49:22 pm »
My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.
Nope, there is reason to expect some quality since this lock was made not by China NONAME, but company which has experience in this field.
While I've shown that MD5 could be easy implemented even on low cost 8 pin ATTiny85 with 8KB of flash, there is a chance they did it right and maybe you watched too many James Bond films if you think you could crack this safe lock within hours or so :palm:
 

1. Whether MD5 can fit is still irrelevant (see last post).
2. You still have no explanation of why hashing the passcode is beneficial to security in this case.
3. Regarding your argument: "there is reason to expect some quality since this lock was made not by China NONAME, but company which has experience in this field."
   a. are you serious?
   b. Closed firmware like this is almost always crap. Assume so until proven otherwise.
   c. See 2.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf