Cracking Linksys “Encryption”(devttys0.com)
devttys0.com
Cracking Linksys “Encryption”
http://www.devttys0.com/2014/02/cracking-linksys-crypto/
5 comments
FWIW, Cisco sold Linksys to Belkin. I guess slapping Cisco logos all over poorly-designed Linksys home networking products didn't do anything especially positive for people's perception of Cisco.
You're right, it is Belkin now, somehow I missed this year old news!
Wonderful. Either my WeMos will start working better or ...
Since we know about previous security issues for firmware updates on WeMo, and since I had awful customer experiences with belkin.com ... Both WeMo and Linksys products are off my "buy" list from now on, until I see some serious improvements. It's a shame, really...
Since we know about previous security issues for firmware updates on WeMo, and since I had awful customer experiences with belkin.com ... Both WeMo and Linksys products are off my "buy" list from now on, until I see some serious improvements. It's a shame, really...
Yeah WeMo has been a disaster. Just wondering, did you replace yours? If so with what? Z-Wave?
I'll take a WeMo I have to firewall from the internet any day over a Z-Wave device that responds to commands 50% of the time, and then only after 20-30 seconds. Which is exactly how all the ones I already own work. The WeMo switches always work, and always instantly.
Yeah, I have a NAT and... I takes my chances. (Wait, don't they defeat those? Hmm.)
Actually, they aren't hooked up right now, though I suppose if I were paranoid, I'd keep a second WiFi network disconnected from the net most of the time. It's a shame though that they used WiFi -- ZigBee Hue lights have worked great for me, and Bluetooth LE goes forever.
Actually, they aren't hooked up right now, though I suppose if I were paranoid, I'd keep a second WiFi network disconnected from the net most of the time. It's a shame though that they used WiFi -- ZigBee Hue lights have worked great for me, and Bluetooth LE goes forever.
Thanks for the heads up on Z-Wave, but you've also just inadvertently described the WeMo product line as well, minus the ongoing security issues they'll have and a lot of times they just go offline completely until you manually reset them. Really horrible.
What do you recommend then? Zigbee?
What do you recommend then? Zigbee?
I'm not sure an explicit description can't be inadvertent. I've had the WeMo switches and sensors for months; they've never needed a reset and have always responded and broadcast status changes instantly.
Maybe you have a problem with the phone app? I don't use it. They speak UPnP, so I use that from a node.js server.
http://i.imgur.com/aYOaB1e.jpg
I have no problem with connected devices using WiFi. I'd rather talk to them directly over TCP than have to use some hub to bridge different networks.
Maybe you have a problem with the phone app? I don't use it. They speak UPnP, so I use that from a node.js server.
http://i.imgur.com/aYOaB1e.jpg
I have no problem with connected devices using WiFi. I'd rather talk to them directly over TCP than have to use some hub to bridge different networks.
Ahh that may be it. Their iOS app is pretty bad. I've only had them for a month and I just didn't have time to experiment. I just wanted them to work.
I've actually had a lot of problems connecting them to WiFi, since before the firmware update they don't allow most special characters, and for some reason they can't hit my router due to range. I had to actually get a WiFi repeater to get everything up and running. Hmm it could have been the amount of UPnP traffic as well. I got about four switches, four plugs, and four motion sensors. Even when I didn't poll them with the iOS app, they would just randomly fail to follow their rules or maybe the motion sensors would fail to send messages.
Yeah I'm not keen on spending money for a hub with different radios but I literally just finished packing up all my WeMos today for a return. Too bad. I got them at a pretty decent discount too. I guess I'm willing to pay a little more for something that just works. I probably should have just kept them and got a Smartthings hub.
I've actually had a lot of problems connecting them to WiFi, since before the firmware update they don't allow most special characters, and for some reason they can't hit my router due to range. I had to actually get a WiFi repeater to get everything up and running. Hmm it could have been the amount of UPnP traffic as well. I got about four switches, four plugs, and four motion sensors. Even when I didn't poll them with the iOS app, they would just randomly fail to follow their rules or maybe the motion sensors would fail to send messages.
Yeah I'm not keen on spending money for a hub with different radios but I literally just finished packing up all my WeMos today for a return. Too bad. I got them at a pretty decent discount too. I guess I'm willing to pay a little more for something that just works. I probably should have just kept them and got a Smartthings hub.
Ah I see. I suspect my irritation with their use of wifi also came down to their Android app. If you can believe it, it's even worse.
That said, it's not necessarily a bad thing for devices to have a hub. The hue lights, for example, hook up to a zigbee base station with an ethernet jack. So I never needed to enter a wifi password in the first place ;-)
That said, I had range issues too. The antennas must be microscopic. Maybe we'll have pCell routers someday.
That said, it's not necessarily a bad thing for devices to have a hub. The hue lights, for example, hook up to a zigbee base station with an ethernet jack. So I never needed to enter a wifi password in the first place ;-)
That said, I had range issues too. The antennas must be microscopic. Maybe we'll have pCell routers someday.
Yeah I feel that's why the WeMos were really flawed. They needed a hub. A guaranteed place that keeps track of their status as well as a guaranteed place to relay data.
Luckily for us hackers, since they use wifi any computer can be that hub. Just give them static IP leases on your router so you don't have to re-discover them after a power/network outage.
Not to mention the complete lack of customer support
Well not any more : http://www.bloomberg.com/news/2013-01-24/cisco-sells-linksys... (as Cisco sold LinkSys to Belkin) but the point is valid.
I don't understand why the author claims "This is truly atrocious."
It doesn't matter much which algorithm is used, every one that is used for the given purpose and given circumstances can be reversed, it's just a question of invested time. Who needs it would do it, and the following publication would make his results usable to others no matter the algorithm.
It doesn't matter much which algorithm is used, every one that is used for the given purpose and given circumstances can be reversed, it's just a question of invested time. Who needs it would do it, and the following publication would make his results usable to others no matter the algorithm.
There are many standardized and reviewed encryption methods out there that are much more complex and secured than a simple XOR. I think the point he was trying to make is that this technique doesn't even deserved to be called an encryption in the first place. I have a feeling linksys devs just wanted something to hide the passwords from the plain view (eg, if somebody peaks at your config file over your shoulder they won't be able to tell what your root password is) and ended up using a wrong name for the feature.
ROT13 and XOR are encryption. This is crypto101. With a username like yours, you ought to give some books on the subject a cursory glance, at least at their first chapter where they always start with some chap called Caesar ;)
Depends on the definition of "encryption".
It looks like GP's definition of "encryption" does not include childish stuff like RO13 and XOR.
Is his definition technically accurate? No, but then words are malleable and companies hiding behind "technically accurate" in their marketing blurb is never a good thing.
It looks like GP's definition of "encryption" does not include childish stuff like RO13 and XOR.
Is his definition technically accurate? No, but then words are malleable and companies hiding behind "technically accurate" in their marketing blurb is never a good thing.
> Is his definition technically accurate? No, but then words are malleable
I've taken to calling simple XOR/Rot based schemes like that "encoding" instead then encryption, as it would seem have others, as they are essentially static alphabet changes - converting ANSI to UCS or UTF16 would be almost as effective. Of course marketing are going to use the best sounding word they can in any small way justify rather than caring about any disconnect between reality and what things actually mean to the people they are marketing to.
Obfuscation is another work I'd use for such simple schemes. They have much the same effect as code obfuscation: they hide something from the most casual of viewers but offer no protection at all against anyone with five minutes to spare.
I've taken to calling simple XOR/Rot based schemes like that "encoding" instead then encryption, as it would seem have others, as they are essentially static alphabet changes - converting ANSI to UCS or UTF16 would be almost as effective. Of course marketing are going to use the best sounding word they can in any small way justify rather than caring about any disconnect between reality and what things actually mean to the people they are marketing to.
Obfuscation is another work I'd use for such simple schemes. They have much the same effect as code obfuscation: they hide something from the most casual of viewers but offer no protection at all against anyone with five minutes to spare.
The words encryption and obfuscation do not contain any overtones of their complexities.
You would rename the Caesar Cipher to be Caesar Encoding? Not going to fly.
Any encryption where the password is public knowledge is just obfuscation. So if these backups were AESed, reversed, RC4ed, bzipped and then DES3ed ... that'd just be time-consuming obfuscation.
You would rename the Caesar Cipher to be Caesar Encoding? Not going to fly.
Any encryption where the password is public knowledge is just obfuscation. So if these backups were AESed, reversed, RC4ed, bzipped and then DES3ed ... that'd just be time-consuming obfuscation.
I would argue ROT13 isn't encryption as there is no key (it is just defined within the algorithm). Simple XOR with a constant is (bad) encryption and the constant is the key..
The Caesar cipher is encryption because the shift is the key.
The Caesar cipher is encryption because the shift is the key.
ROT13 is just like XOR; The "key" is "NOPQRSTUVWXYZABCDEFGHIJKLM". In the same way in this case the XOR "key" was just 0xFFFFFFFF.
I think josephlord's point was that the name "ROT13" completely specifies the 'key': If you changed that, it would no longer be ROT13. So it arguably can't be considered a key if you define 'key' to mean 'a piece of information additional to knowing the algorithm used that is necessary to decrypt'. (If the 'algorithm used' was specified just as ROT (i.e. caesar cypher) then 13 would be a key). But this is basically semantics.
Never said wasn't, just that we came a long way since the Roman era ;)
They could stick a hardware encryption chip into their products and with a proper crypto system could enable secure encryption even against an active attacker with control of the OS. Even a password hash using a decent hash like bcrypt would be secure against an attacker with only user privileges.
Single byte XOR is just child's play, even if the "key" was only used once. They may as well have used ROT-13.
Single byte XOR is just child's play, even if the "key" was only used once. They may as well have used ROT-13.
While this would be a better route for encryption, it wouldn't help older hardware receiving firmware updates - so a non-hardware route would be required.
Hmm. To guard against an attacker with only user privileges, couldn't you simply mark the file as accessible only by root? ;-)
That said, I'd say if you have user privileges in my router, I've bigger issues than wifi passwords and config files...
That said, I'd say if you have user privileges in my router, I've bigger issues than wifi passwords and config files...
Many of the home router vendors have released firmware with stupid flaws like allowing the inbuilt webserver (running as root) to traverse up directories and thus allow the attacker to view config files.
If the passwords were stored properly hashed then the attacker has to do a lot more work to recover the plain text.
If the passwords were stored properly hashed then the attacker has to do a lot more work to recover the plain text.
[deleted]
I'll chime in to completely agree with you, as you're getting all the encrypting-it-would-make-it-secure crowd.
They NOT the password, which makes it not show up on `strings` or some other standard scan for passwords. But if the attacker knows to go looking for passwords in backups, all they need is to find the backup, and then no amount of fancy expensive crypto will make it secure.
They NOT the password, which makes it not show up on `strings` or some other standard scan for passwords. But if the attacker knows to go looking for passwords in backups, all they need is to find the backup, and then no amount of fancy expensive crypto will make it secure.
Don't worry about what so called 'crypto experts' have to say, just keep writing code like this.
If they really insist that you use a real cipher like AES, make sure you use ECB mode as its much faster than CBC or GCM mode.
Whatever you do please don't implement a system like SSL which will incur much overhead for little gain, I mean any crypto expert will tell you that all AES keys can eventually be cracked given enough time and hardware.
I mean its just a router, what are they going to do? Pair it with Apple's SSL vulnerability and drain your bank accounts? Fat chance that might happen.
Yours truly,
Lazy Blackhat.
If they really insist that you use a real cipher like AES, make sure you use ECB mode as its much faster than CBC or GCM mode.
Whatever you do please don't implement a system like SSL which will incur much overhead for little gain, I mean any crypto expert will tell you that all AES keys can eventually be cracked given enough time and hardware.
I mean its just a router, what are they going to do? Pair it with Apple's SSL vulnerability and drain your bank accounts? Fat chance that might happen.
Yours truly,
Lazy Blackhat.
Hey L.Bh.,
thanks for the advice, it's appreciated.
My boss already complained that it's taking me so long integrating all that heavy exaggerated crypto stuff, and your suggestions are indeed easier! Customers won't realize there's a difference anyway.
Yours truly, Incompetent firmware guy
thanks for the advice, it's appreciated.
My boss already complained that it's taking me so long integrating all that heavy exaggerated crypto stuff, and your suggestions are indeed easier! Customers won't realize there's a difference anyway.
Yours truly, Incompetent firmware guy
I say you're wrong.
You're right that it really doesn't matter which encryption algorithm is used. It's the premise that encryption should be used in the first place that's wrong.
See, you don't store passwords -- not plaintext, not encrypted. Ever. (Well, unless your software is password manager, but a router is definitely not that.)
You also don't store password hashes. You don't even store salted password hashes. You'll get it wrong, and you won't even know it.
The only thing anybody should ever store is the output of a well known and well tested implementation of a well known and thoroughly studied key derivation function. (This implies that somebody else wrote it.) That's it. Anything else is broken.
So which key derivation function did they use? Oh, they didn't use one? That's what's atrocious. It doesn't matter if it's binary-not, triple-DES, AES, md5, or 10 rounds of salted sha256.
Use a key derivation function.
You're right that it really doesn't matter which encryption algorithm is used. It's the premise that encryption should be used in the first place that's wrong.
See, you don't store passwords -- not plaintext, not encrypted. Ever. (Well, unless your software is password manager, but a router is definitely not that.)
You also don't store password hashes. You don't even store salted password hashes. You'll get it wrong, and you won't even know it.
The only thing anybody should ever store is the output of a well known and well tested implementation of a well known and thoroughly studied key derivation function. (This implies that somebody else wrote it.) That's it. Anything else is broken.
So which key derivation function did they use? Oh, they didn't use one? That's what's atrocious. It doesn't matter if it's binary-not, triple-DES, AES, md5, or 10 rounds of salted sha256.
Use a key derivation function.
I don't see the point in encrypting configuration data (IPs, firewall rules etc.) from the beginning.
Although, keeping password in plain text is a stupid idea, but we have hashing for that, encrypting or obfuscating passwords is pointless.
No. Don't hash passwords. Don't even hash salted passwords. And especially don't encrypt passwords. Use a key derivation function.
The story here is not the weak encryption. Who cares if they used XOR instead of AES or whatever is the best encryption at the moment? The story is that yet another piece of software isn't using a key derivation function.
The story here is not the weak encryption. Who cares if they used XOR instead of AES or whatever is the best encryption at the moment? The story is that yet another piece of software isn't using a key derivation function.
Isn't typical use of (hash-based) KDFs for password verification purposes is essentially using them as salted hashes?
Yes, for most cases underlying primitives are iterated many times, so they're slow to compute, but that's not the point - it's still hashing.
Yes, for most cases underlying primitives are iterated many times, so they're slow to compute, but that's not the point - it's still hashing.
Of course you're right in theory. A KDF is a hash function. In practice, however, it's best if we ignore that fact when making public statements.
When many people hear about hashing passwords, they think md5 or sha1 or something. I certainly used to think that way. The problem is, it's really really easy to be ignorant of the current best practices and not even realize it. Thinking that you know what you're doing when you don't is a great way to get insecure systems.
So, I like to say that it's wrong to hash passwords, even if they're salted. It's also wrong to encrypt them. You should only ever use a KDF.
I would hope that anybody who can poke holes in my statement has nothing to learn from me and already knows to use a KDF. Anybody else will hopefully read that, scrap their plans to use salted sha1 and instead go learn about KDFs until they too can poke holes in my statement.
When many people hear about hashing passwords, they think md5 or sha1 or something. I certainly used to think that way. The problem is, it's really really easy to be ignorant of the current best practices and not even realize it. Thinking that you know what you're doing when you don't is a great way to get insecure systems.
So, I like to say that it's wrong to hash passwords, even if they're salted. It's also wrong to encrypt them. You should only ever use a KDF.
I would hope that anybody who can poke holes in my statement has nothing to learn from me and already knows to use a KDF. Anybody else will hopefully read that, scrap their plans to use salted sha1 and instead go learn about KDFs until they too can poke holes in my statement.
Wouldn't a wifi access point need to access the wpa password in plaintext in order to actually implement the wpa protocol?
So, while you could store the admin password hash, the router does need at least the WPA PSK to implement the protocol (see my reply to smtddr for more details).
What they could do, if they really wanted to be clever, is store a hash of the admin passphrase (which won't help anyone auth to the router) and store an encrypted version of the WPA PSK under a key derived separately from the admin passphrase.
Then, after the restore, you would require the admin to log in before the access point portion is turned on. When the admin logs in, rederive the encryption key, decrypt the PSK, and enable the access point.
It's a slightly degraded user experience, but it does have nice properties.
What they could do, if they really wanted to be clever, is store a hash of the admin passphrase (which won't help anyone auth to the router) and store an encrypted version of the WPA PSK under a key derived separately from the admin passphrase.
Then, after the restore, you would require the admin to log in before the access point portion is turned on. When the admin logs in, rederive the encryption key, decrypt the PSK, and enable the access point.
It's a slightly degraded user experience, but it does have nice properties.
smtddr@POKEMONGYM:~$ wpa_passphrase My_AP_SSID mysup3rs3cr3tp@ssw0rd
network={
ssid="My_AP_SSID"
#psk="mysup3rs3cr3tp@ssw0rd"
psk=a6356f17ad3bb0f18385a0faa57d10c20352b977411e636c5466f933bb415fdd
}
smtddr@POKEMONGYM:~$
First let me explain the relationship between the first and second values.
For authentcation, passphrases are used because they're a lot easier for humans to remember than 256 bit hex strings. The WPA2 standard (IEEE 802.11i) defines the passphrase to PSK derivation as "PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)" (PBKDF2 is a hashing-based key derivation function, in this case using SHA1).
So, this takes us from a password to a key. Now how do we auth to the router?
In WPA2, there's a master-key (known as the "pairwise master key" or PMK) which is known by both the client and the access point. This key (the PMK) is then used in a 4-way hand-shake and key negotiation that allows each party to establish that the other has knowledge of the key. This key is either handled via a complex authorization mechanism like radius (WPA-EPA) or is simply shared between all the parties (WPA-PSK). In this case, the pre-shared key ("PSK") that we derived above is used directly as the PMK to complete the 4-way handshake.
For authentcation, passphrases are used because they're a lot easier for humans to remember than 256 bit hex strings. The WPA2 standard (IEEE 802.11i) defines the passphrase to PSK derivation as "PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)" (PBKDF2 is a hashing-based key derivation function, in this case using SHA1).
So, this takes us from a password to a key. Now how do we auth to the router?
In WPA2, there's a master-key (known as the "pairwise master key" or PMK) which is known by both the client and the access point. This key (the PMK) is then used in a 4-way hand-shake and key negotiation that allows each party to establish that the other has knowledge of the key. This key is either handled via a complex authorization mechanism like radius (WPA-EPA) or is simply shared between all the parties (WPA-PSK). In this case, the pre-shared key ("PSK") that we derived above is used directly as the PMK to complete the 4-way handshake.
WPA uses PBKDF2 so that's probably how it gets to that value
Perhaps it's atrocious to claim something but not be doing it well? The configuration files are sensitive documents. They're misleading users by saying they're "encrypted" in any meaningful way.
That's not even XOR, that's NOT!
The problem is not using XOR in itself, since virtually all good crypto is based on it; it's what the XOR'ing is with.
The problem is not using XOR in itself, since virtually all good crypto is based on it; it's what the XOR'ing is with.
To make it even clearer, bitwise XOR with 0xFF is equivalent to bitwise NOT.
[deleted]
[deleted]
Back in 1995 I "cracked" Cisco's router password "encryption":
https://groups.google.com/forum/#!original/comp.dcom.sys.cis...
Strikingly similar 'security', which is extra funny as Linksys is owned by Cisco. (EDIT: Not anymore! Thanks for the correction)
Back then net admins would regularly post their configuration files (with 'encrypted' passwords left intact in most cases) to usenet to get help/tips on how to better configure their routers, which was an unaddressed (by Cisco) security nightmare.