Perusing the release notes for the latest Linksys WRT120N firmware, one of the more interesting comments reads:
Firmware 1.0.07 (Build 01)
– Encrypts the configuration file.
Having previously reversed their firmware obfuscation and patched their code to re-enable JTAG debugging, I thought that surely I would be able to use this access to reverse the new encryption algorithm used to secure their backup configuration files.
Boy was I giving them way too much credit.
Here’s a diff of two backup configuration files from the WRT120N. The only change made between backups was that the administrator password was changed from “admin” in backup_config_1.bin to “aa” in backup_config_2.bin:
OFFSET backup_config_1.bin backup_config_2.bin ---------------------------------------------------------------------------------------- 0x00001468 9E 9B 92 96 91 FF FF FF |........| / 9E 9E FF FF FF FF FF FF |........|
Two things to note here:
- The first letter of each password (“a”) is encrypted to the same value (0x9E)
- The same letter (“a”) is encrypted to the same value (0x9E), regardless of its position in the password
I immediately suspected some sort of simple single-byte XOR encryption. If true, then XORing the known plain text (“a”, aka, 0x61) with the known cipher text (0x9E) should produce the XOR key:
0x61 ^ 0x9E = 0xFF
Applying the XOR key of 0xFF to the other characters in the password gives us:
0x9E ^ 0xFF = a 0x9B ^ 0xFF = d 0x92 ^ 0xFF = m 0x96 ^ 0xFF = i 0x91 ^ 0xFF = n
And XORing every byte in the config file with 0xFF gives us a decrypted config file:
00000000 33 34 35 36 00 01 df 60 00 00 46 ec 76 31 2e 30 |3456...`..F.v1.0| 00000010 2e 30 37 00 00 00 00 00 00 00 00 00 00 00 00 00 |.07.............| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 57 52 54 31 |............WRT1| 00000030 32 30 4e 00 00 00 00 00 00 00 00 00 00 00 00 00 |20N.............| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 61 64 6d 69 6e 00 00 00 00 00 00 00 00 00 00 00 |admin...........| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 61 64 6d 69 6e 00 00 00 |........admin...| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 00 00 00 00 00 00 00 00 30 2e 30 2e 30 2e 30 00 |........0.0.0.0.| 00000110 00 00 00 00 00 00 00 00 01 01 01 00 00 00 00 01 |................| 00000120 00 00 00 01 00 00 00 00 00 00 00 08 32 39 34 38 |............2948| 00000130 33 31 30 35 00 01 00 00 00 31 39 32 2e 31 36 38 |3105.....192.168| 00000140 2e 31 2e 31 00 00 00 00 00 32 35 35 2e 32 35 35 |.1.1.....255.255| 00000150 2e 32 35 35 2e 30 00 00 00 00 00 00 04 00 02 00 |.255.0..........| 00000160 01 00 00 00 00 00 00 00 00 00 00 00 00 00 4c 4f |..............LO| 00000170 4f 50 42 41 43 4b 00 00 00 00 31 32 37 2e 30 2e |OPBACK....127.0.| 00000180 30 2e 31 00 00 00 00 00 00 00 32 35 35 2e 32 35 |0.1.......255.25| 00000190 35 2e 32 35 35 2e 32 35 35 00 00 00 00 00 00 00 |5.255.255.......| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 49 52 51 3d 30 20 50 4f 52 54 3d 30 |....IRQ=0 PORT=0| 000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ...
This is truly atrocious. Given that “encrypting” the backup configuration files is done presumably to protect end users, expecting this to thwart any attacker and touting it as a product feature is unforgivable.
OK, I don’t really care that much. I’m just disappointed that it took longer to write this blog post than it did to break their “crypto”.
yes it is
encryption – when you hide / change data. obfuscation – when you change execution order of the code and inject useless loops and commands.
you are cool!
Encryption is something that should be impossible/impractical to decode without both of two things: the method and some sort of key. This allows only authorized parties to have access to the concealed information. Some algorithm can be considered cryptographic at first but be “broken” over time; if techniques or technology arise to decode the message without knowledge of those. That’s what’s happened to, for example, Caesar’s cipher; nowadays it’s more of an obfuscation than an encryption method.
Obfuscation is much broader and generally means “making something harder to understand/interpret”. Which usually is indeed done by messing with code/text order, loops and such, but can be as arbitrary as adding 1 to each byte/letter or swapping every odd pair of them.
This is then, of course, the second case, since you don’t need to know the “key” 0xFF to gather information about the encoded information. In theory you could even make changes to this configuration file without understanding the XORing process at all. So calling it “encryption” is really a stretch.
This seems to be a common pattern of obfuscation. My previous, ISP-branded router was a device from Arcadyan. It allowed exporting settings that turned out XORed with 0xFF as well.
“XOR 0xFF” == NOT
Yep. It’s actually implemented as a NOR in the assembly (each byte is NOR’d with 0x00).
Well, even if it would be really correctly encrypted with best-practice and all, you would still have access to their private key that way. The moment someone publishes the algorithm and key(s), like you here, it’s “game over”. The only disappointment maybe is that they used an algorithm that simple.
As long as the key was unique to the device and not reasonably predictable, then publishing the key from my router would only affect my router. They already have standard encryption algorithms in their code as well, for supporting HTTPS administration.
Of course, that would also mean that you couldn’t use the backup config from one WRT120N on another WRT120N, which might be a requirement.
Wow…just, wow. That is unbelievable.
I love your posts. Keep ’em coming!
I need to thank linksys to make craig wrote a post that I understand from the vegin to the end
Anyway, even when i cant understand what you did I like your posts
Excellent post. Your blog is one of the most useful, informative and *interesting* blogs I’ve ever come across
Give them some credit.
Xoring with 0xff leaves you with not even a single bit as before! They get the most different file they can get 😉
(It’s a joke 😉 )
When I find these gems and cannot change the equipment, firmware or fix the issue, I simply pick a password, and encrypt it, then I take that encrypted hash and make THAT the password.
Now, as you read that, you likely came to the conclusion that this secures NOTHING any better than before, and by saying that, you would be right.
However, when we look at an unencrypted config file (whether we cracked it or it was left in the clear), like in this instance, we still look at this file and determine if the data is truly “in the clear”.
Looking at my password, you would see an encrypted hash of some crazy value, and assuming that the device allows for VERY LONG passwords, you will ASSUME it’s encrypted.
That is a social engineering trick I have used MANY times on files that are not secure when in production / “the field”.
EVERY single person I have invited to crack my devices using this “hashed password”-password has assumed it was encrypted and spent time DECRYPTING it, only to find that:
A) It was strong enough to give up the attempt
or
B) They actually DID decrypt it, and tried that password, only to find out that it was NOT the password!
Only ONE person, AFTER giving up, and MUCH later in a conversation with me had a moment when it “Clicked”, he looked at me and asked me directly if that is what I had done.
I denied it in the group, but later admitted it to him privately.
When left with security devices that are not secure, you have to improvise.
+1. That is very clever! Good idea!
-1. You just told everyone about it so we can’t use it.
Stories about what your friends tried is not something people should be basing their security off of: the plural of anecdote is not data.
Much better to have potentially sensitive data in cleartext than “protected” by a scheme like that. If it’s in cleartext I have a clear understanding of what I may permit myself to do with this file (i.e. be very careful that it doesn’t end up where someone can get it). If it’s protected by the assumption that people who look at my password maybe kinda sorta think it’s not my password, I had better be treating the file exactly as though it were in cleartext — in which case this misdirection would be useless anyway.
I will grant that your story is amusing and carries a certain charm, but please do not mistake that for it being remotely safe.
Haha
I really enjoy your ending, that it took you more to write a blog post than to break their encryption.
Nice work!
Pingback: Linksys (cisco) needs to enhance their encryption. Linksys WRT120N firmware easy cracked. - b-real.org
Pingback: Linksys et son chiffrement en carton « Korben Korben
They could of at least used RC4; that’s not very resource intensive and uses very little lines of code to implement.
XOR with a single byte is just pathetic.
Pingback: Linksys et son chiffrement en carton « Mes idées HIGH TECH
Pingback: Linksys et son chiffrement en carton