12 ms·

Alexa, what is my wifi password?

426 points by voxadam 4y ago

an_ko 4y ago
Is this that big of a deal? Surely by the time someone has hardware access, the game is over. The keys need to be decrypted into memory to use them, and nothing stops someone with hardware access from dumping that memory. No amount of encryption beats a soldering iron.
- tinus_hn 4y ago
  Even worse, that hashed key they are proposing is plaintext equivalent, it has the same access as the password (actually it is the real password, the PSK). And while for normal passwords there is the argument the password is more valuable because people reuse them, that doesn’t really apply for WiFi unless people use the same password for different SSIDs
- voxadam 4y ago
  It seems that it could be a pretty big deal to people who toss their old devices in their curbside trash to upgrade or otherwise discard their old Echo devices. Most people don't have the background to understand that attacks like this are possible. Hell, the other day I almost chucked a couple of old 11n era APs flashed with OpenWRT into the trash until I remembered that there's some incredibly sensitive data (SSID, key, logs, etc.) stored in a manner that likely wouldn't hold up to a physical attack. I do have the understanding of attacks like this and in a moment of haste to decluter my home office I nearly opened myself up to an attack like the one described in this post.
  - josephg 4y ago
    Are wireless network passwords really that important? What is the threat model here? I’m trying to figure out the downside risk. Someone finds out your wireless password, figures out your address via an AGPS lookup and then … drives to your house and what? Steals your internet? Projects something on your smart tv? Turns your insecure smart lights on and off? I can imagine that being effective as part of a complex spear phishing attack against a celebrity or something. But if someone dumpster dives and ends up finding my wifi password, why should I care?
    - tspike 4y ago
      Identity theft is the first thing that comes to mind
- squarefoot 4y ago
  That's why old devices must be properly cleaned of personal data before being sold or discarded. I buy most of my devices (network stuff, APs, laptops, etc) either as refurbished or at flea markets. If I was a malicious actor I could have easily taken advantage of many people who didn't delete their data, including WiFi settings, from a device they gave away, so although devices are used in relatively safe places like home or workplace where it would be impractical if not impossible to gain physical access for the time necessary to exfiltrate sensitive data, that becomes trivial if the device is discarded/sold without taking proper measures to delete any sensitive data it could still contain.
  - oceanplexian 4y ago
    Just don’t assume WiFi is a form of security. My WiFi network is no different than a hotspot at a coffee shop, anything important lives in another VLAN and has tight access controls. Someone could get access to my network, and they’d have zero ability to do anything useful other than access the public Internet. This also protects against sketchy apps like TikTok and proprietary devices (like voice assistants).
AshamedCaptain 4y ago
> When using this tool, it is good practice to hash the password for the wireless network before storing it in the configuration file (encrypt it in a way that cannot be reversed). This can be done with one simple command (wpa_passphrase), Huh? Anyone who has that hash can still connect to your Wi-Fi network, which kind of defeats what is being claimed. At that point you can also bruteforce the plaintext password (offline, at your leisure), or worse...
- Dragon863 4y ago
  Sorry about that! I misunderstood how hashing works, and I've updated the page with a correction at the bottom
  - deleted 4y ago
    [deleted]
- badkitty99 4y ago
  But don't you need the preimage of the hash to generate it in authentication?
  - overthrow 4y ago
    On Linux you can auth using the hash instead of the password. Other OSs probably have something similar. https://unix.stackexchange.com/questions/40/use-wpa-supplicant-without-plain-text-passwords https://unix.stackexchange.com/questions/40/use-wpa-supplica...
    - lxgr 4y ago
      Yes, but I suppose GPs question was "is that enough to authenticate?" – and given that as you say Linux and iOS/macOS (for Wi-Fi "password" sharing with nearby devices) do support that, and my other comment, the answer is "yes".
  - lxgr 4y ago
    Not for WPA-PSK. The PSK is used to derive the PMK from (simplified) something like PMK = Hash(PSK, SSID). This key is static and never changes for the lifetime of a particular SSID, and is also shared across all devices in WPA-PSK. From the PMK, all other per-connection keys are then derived at association time, but everybody that captures that conversation can derive all further keys since that exchange uses only symmetric functions with all secret inputs derived from the PMK, not something like Diffie-Hellman. It's unfortunately not easy to do anything more resistant against compromised clients without storage on the APs (or at least a stable encryption key available to all access points of an SSID), so WPA-PSK doesn't – for anything more robust than that, you need WPA-EAP. (Some networks support a per-station/MAC address PSK as a proprietary feature, but that's only possible because they do have some management plane that allows the APs to share the required state.)
Aissen 4y ago
Meh, the PSK can be used to connect to the network. The "cleartext" really does not matter unless you reuse passwords, which you shouldn't do. Anyone with physical access to your Echo probably has a dozen other methods to get access to your password. Now dumping this is still quite impressive for 14 year old. Kudos.
- codetrotter 4y ago
  > Anyone with physical access to your Echo probably has a dozen other methods to get access to your password. For example, walk two meters to the side over to where the router sits, flip it over and read the label where the PSK is printed on the router. :D
  - toast0 4y ago
    Nobody read the password when it was on the router... So now I have it (with a big QR code that sometimes works) on a printed page taped to the side of the printer.
    - dzhiurgis 4y ago
      NSA has cameras that can scan your router QR code from space satellite
- dcow 4y ago
  > Now dumping this is impressive for a 14 year old. Kudos. The only part I don't believe is the three Makefiles. Even grey beards struggle write correct Makefiles. If Daniel wrote those too then that’s the truly impressive feat.
  - photochemsyn 4y ago
    It's a nice project, the Makefiles are cloned from the amonet project this is based on. I tried understanding them with the help of ChatGPT, that was an illuminating exercise. I think (not sure) that the build rules could be better ordered, it seems like they're just scattered about in the Makefile relative to the order of events (compiling the C and assembly source code into the ELF file and hence to the binary).
notum 4y ago
Not to diminish the effort (I love seeing these things cracked): if you have physical access to an Alexa device you likely have access to the router as well. The better coarse of action for a wrongdoer would be to get everything off the router using a serial interface and leave no traces behind for an extended remote access.
- voxadam 4y ago
  As I mentioned in a reply to another comment there's a lifecycle issue to consider. People frequently upgrade their devices (IoT and otherwise) or dispose of them entirely. Often times these old devices are disposed of in insecure curbside trash bins. With every old IoT device being tossed into the trash without though it's starting to look like this is a more and more effective attack vector with each passing day.
  - lxgr 4y ago
    The "old device offered on the curb with a 'still working' note" threat scenario is actually a more realistic one than something like a corporate Wi-Fi in my view, since the latter would hopefully have any physically exposed client devices like that in a separate subnet/VLAN/SSID. The added benefit is that any possible attacker gets two additional data points for free: Where the corresponding SSID is most likely located, and that that household can afford to give away the hardware for free instead of reselling it or trading it in.
    - JohnBooty 4y ago
      that that household can afford to give away the hardware for free instead of reselling it or trading it in The Echo Dot in the article retails for $40, cheap enough to be considered disposable by many/most. Would probably gain much more useful socioeconomic information simply by looking at the neighborhood in which said curb is located, right? :)
PinguTS 4y ago
So the attack vector is: you need to flash a device in a certain place. That means, you need to open the device and do other things. Honestly, who has an Amazon Echo dot on a private network in a public place? Yes, it is a valid attack vector but I would vote the likelyness and importance at very very low risk.
- lxgr 4y ago
  I've seen at least Chromecasts, Apple TVs etc. in quite a few corporate offices, so it's not completely unrealistic. Maybe somebody wants to use the Echo as a cheap speaker with the microphone disabled, or it's in a non-sensitive location. That said, in a corporate network, admins would hopefully put these in a pretty isolated subnet (by SSID+PSK, since they presumably don't support WPA-EAP where you could VLAN/subnet them based on their credentials).
  - sureglymop 4y ago
    A better way to prevent this would be to use One Time Passwords for every device joining the network. If the password is reused from a different device it gets invalidated. I don't know if such a mechanism exists for networks and I guess it would also be trivial to just spoof a mac address. I guess it does for something like a captive portal.
    - lxgr 4y ago
      That only works in a model where you only have one AP per SSID, but many networks have multiple APs, and not all of them have a central controller. If you have a single AP and replace that for some reason, you'd also need to enter the PSK again on all clients. WPA-PSK seems like a pretty bare-bones protocol, but if you consider the constraints it has to operate in, it's actually not that easy to come up with something better (other than the omission of ephemeral key exchanges through something like Diffie-Hellman, which was only added in WPA3, but would not help in this threat scenario in any case).
    - smashed 4y ago
      The best you can do is have a PSK per mac address. Hostapd which manages the encryption of wifi access point in pretty much all wireless aps already supports it. You can supply a list of mac address to psk or obtain the psk from radius server. The mac address is provided as the username, all your need to do is return a different psk depending on the mac address. I have POC code lying around I should probably publish somewhere. Like pointed in sibling comments, it is pretty trivial to clone a mac address so if you were to dump a "unique" psk, all you need is the mac address that goes with it. What it does gain you though and that is a big plus in some situations, is the ability to revoke a single psk without having to reconfigure all your client devices. That is very useful. The onboarding is a little bit wacky though. You need an easy way to get the client mac address, generate a unique psk for it, save that in your config, then attempt connection.... One way I would like to explore is have a "next available psk" easily available, for example in an app available to the network administrator. When hostapd asks for the psk associated with unknown/never seen before mac, return that default PSK and save it as associated with that mac on succesful connection, then regenerate a new default PSK for the next device. This way, an admin can share the password or onboard new devices easily. You don't need to know the mac address of the client in advance. If you need to revoke access for a device, just revoke the psk that was associated with it.
xoa 4y ago
Eh. It's certainly not great practice though not stunning given how utter crap 99% of IOT WiFi seems to be. That said the author gets a bit overdone, and not just in brushing over the physical access requirement bit. >Storing passwords in plain text is a major security risk in hotels or businesses using the devices on their internal or private wireless networks, giving any potential attackers access to any other equipment on this network or allowing them to create a rogue network and redirect traffic or conduct a MITM (man-in-the-middle) attack. Nah, unless it's a truly awful network even for a prosumer let alone any organization. Even with IOT, ever more widespread PPSK support (which I'd consider a must have for anything greenfield at this point) makes segmenting devices onto their own tightly firewalled VLANs trivial. Normal user interactive devices (computers, smartphones, tablets etc) should all be using VPNs for internal access and just not trust the WiFi at all, or at the least again have their own VLANs. These devices should all support WPA-EAP as well so that's another option, and can just use certs and do away with passwords entirely. If IOT wasn't such crap that'd be an option there too but such is life. It would be fair to say this is all still more complex then it should be, all the tech pieces are in place to make this vastly easier even for the non-technical, the UX is poor in a bunch of respects. And I'm sure there are plenty of small businesses who just run flat networks, maybe with a guest wifi. But that's an issue anyway, and I don't think someone physically stealing an Echo and dumping its eMMC to get at their WiFi password is floor level on their threat model. More like "the desk machine has a password of abc123 and is left unlocked while the elderly B&B lady goes and makes breakfast for guests" and frankly who is breaking in looking for that anyway? It's egg on Amazon's face for sure, absolutely embarrassing for a company of that size and product line that big, and that it's exposed in plaintext on the fs might chain a remote exploit in interesting ways, but not if physical access is required. And again, organizations actually facing threats really just shouldn't be trusting WiFi much anyway. It's not that secure even in theory and implementations are a mess and probably always will be.
- Dragon863 4y ago
  Thanks for the feedback! It's the first time I've written anything like this, and I'm currently studying computer science so I appreciate the corrections as they help me improve my knowledge of the field :)
someweirdperson 4y ago
Whoever has an Alexa on their network doesn't have anything to hide (doesn't care about privacy). Exposing the wifi password on top of that doesn't seem to be a big deal, when full access has already been granted to an evil device.
- gbear605 4y ago
  It depends on your threat model. If you're worried about Bezos, Amazon, or a government, Alexa is absolutely a privacy risk. If you're worried about wide attacks or a script kiddy coming after you, Alexa is probably not the main vector of attack here.
draugadrotten 4y ago
A very inspiring thing about this article was the bio: "Hi there! I am Daniel, a 14 year old developer whose interests include cybersecurity and hardware hacking, low level hardware, web design, and linux." I look forward to seeing what you do 10 years from now. Keep it up!
- toomuchtodo 4y ago
  This too was my favorite part. Inspiring. Great things ahead for this young human.
  - dcow 4y ago
    If he can write a correct Makefile like this at 14 then a truly formidable foe is on the rise, indeed.
    - lopkeny12ko 4y ago
      Am I missing something here? The Makefiles seem very standard for a C/C++ project, and could have been easily replicated from a tutorial or example project without much modification. Not suggesting that the work is not impressive, but the kids of today grew up in the era of computers and the Internet, and a lot of problems that were hard for you and me are no longer hard today.
      - fundad 4y ago
        24 years in the industry and 24 years of “it’s knowable, didn’t you know it already?” arrogance.
      - grepfru_it 4y ago
        >and a lot of problems that were hard for you and me are no longer hard today. I spent my teenage years learning and understanding sendmail milters. I got to a point where I could write them from scratch. Guess how useful this knowledge is today...
vrglvrglvrgl 4y ago
[dead]
mavili 4y ago
The bulk of the article kinda revolves around storing wifi passwords unhashed.. and then at the end "Edit: hashed passowrds are used to connect to wifi, so hashing is not a solution".. erm, so what is the point of the article then?
- atomicnumber3 4y ago
  I thought this was really excellent technical writing given I'm not sure the author has had an English class that actually covers anything beyond grammar and basic literary analysis yet.
  - UncleEntity 4y ago
    I’m over 50 with a college degree and haven’t had an English class that actually covers anything beyond grammar and basic literary analysis yet.
- Dragon863 4y ago
  As others have pointed out, even hashed passwords can be used to connect to a network. However, storing the password in plain text is an embarrassment for a company as big as Amazon, and they should at least be stored in a non readable format if not encrypted. The physical access necessary does make the exploit less dangerous, though. You asked what the point of the article was, I think this could also be a starting point for running our own software on these devices, especially as there is a kernel for the mt8163 available on github from the postmarketos project
  - AshamedCaptain 4y ago
    I really don't agree here. There are many arguments for storing plaintext passwords in, well, plaintext, rather than behind pointless obfuscations. Expressed quite concisely by Pidgin authors many years ago: https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords
  - mavili 4y ago
    After hearing you're 14 I don't want to turn this into an argument really, but please note just because something "sounds" embarassing it may not be actually. Like others have pointed out, physical access to the device means many other measures that can be taken to protect security is not valid anymore. If there is no real need or security benefit for that password to be stored in anything other than plaintext then Amazon doesn't need to go out of their way to save any "embarassment".
hamilyon2 4y ago
One of my favorite iot-wifi stories is about Bluetooth-enabled iqera lightbulbs and them connecting to private wifi. You have to send your wifi password cleartext to some Chinese server during setup phase. Yes, this is the only way to set up these lightbulbs.
cjxjxjxjxjxjxxj 4y ago
[flagged]
- cjxjxjxjxjxjxxj 4y ago
  [flagged]
fffffo 4y ago
Interesting read. I'm surprised Amazon haven't blocked UART access in bootrom mode, considering there's an efuse they can blow, from the bootloader (LK) environment, that will permanently disable it. As an example, Motorola did this on their Mediatek-based phones as part of a firmware update.
thekingshorses 4y ago
Any hotel that uses Alexa devices are vulnerable! I hope google chromecast don't show the password.
MuffinFlavored 4y ago
what’s something harmful you can maliciously do once you are on somebody’s typically password protect wifi network? sniff traffic? you can’t MitM due to HTTPS so… curious. what can be done?
- dfxm12 4y ago
  Aside from just stealing the Internet service, you can set up a device to do something (of questionable legality), either attended or not, that you don't want associated with your own wifi network.
- addandsubtract 4y ago
  Access (or try to) connected devices, such as a NAS?
exelib 4y ago
Cool blog post. One thing I am not sure about. If access to WiFi can lead to the mentioned or other risks, then something else is probably seriously wrong in the chain.
Dwedit 4y ago
If you can get to somebody's Echo and short that capacitor to dump the rom, chances are good that you can also just walk up to their wireless router.
asveikau 4y ago
> When using this tool, it is good practice to hash the password for the wireless network before storing it in the configuration file (encrypt it in a way that cannot be reversed). This is bullshit. The device ultimately needs the wifi passcode in plaintext. What this person is asking for is obfuscation and cryptography theater, not real security. Of course if you root the device you can read the wifi passcode. This is not shocking.
- nimih 4y ago
  > The device ultimately needs the wifi passcode in plaintext. Why is this the case? There are a number of cryptographic methods of varying complexity which allow a server to authenticate a client against a password without storing the password itself.
  - asveikau 4y ago
    Because if you had such a scheme it would no longer be wifi. WPA needs the device to have a key. You cannot replace WPA with your own key derivation scheme to avoid storing keys to keep this ridiculous statement in the blog post happy. Whatever scheme it is, it's probably compromised by rooting the device storing secrets... To make a reference to the quote used by Raymond Chen, the security flaw "rather involved being on the other side of this airtight hatchway".
    - nimih 4y ago
      That makes sense, thanks for clarifying.
- BenHays42 4y ago
  The wpa_passphrase tool simply stores the raw hash used by WPA to authenticate to the AP. This is the behavior performed under the hood even when the plaintext is utilized. You could still reuse the stored hash to maintain the same level of access afforded by the plaintext passphrase, but wpa_passphrase isn't security theater or obfuscation.
xupybd 4y ago
I'm not sure there is much point in encryption if the OS is used to protect the encryption keys the same way it is used to protect the data it is encrypting.
an-allen 4y ago
So the idea of shorting that capacitor… how did you reason that doing that would keep that chip from starting?
- Dragon863 4y ago
  Two reasons: 1. Mediatek processors have a preloader, essentially a bootloader, which checks the emmc for a bootable partition, and if it cannot find one (or the emmc is not functioning correctly) it will load bootrom mode. This is what amonet exploits. 2. When using amonet on kindle devices, a similar method was used to force the device into bootrom mode as Amazon didn't provide a hardware key to do this
deleted 4y ago
[deleted]
xyzzy_plugh 4y ago
This isn't particularly interesting, though the steps to get access are nicely done. Most devices of that era including many Android phones lacked any sort of secure enclave for tamper proof secret storage or encryption. I believe the early Echo stored the wifi password using a weak block cipher and a fixed key, like Kindles. Given the password needs to be eventually decrypted in software, any sort of encryption like this is effectively obfuscation. Physical access is far, far worse! I think folks forget how much security innovation there has been, and become accessible to consumers, in the last decade. It wasn't too long ago that SSL was considered a luxury.
beatehester 4y ago
[flagged]
hypnootis 4y ago
What framework did you use for the blog? It's gorgeous!
- Dragon863 4y ago
  Thanks! I had a go at using beercss, as material design 3 has no official web version yet
tidenly 4y ago
Just a note on the amendment at the end: Storing hashes of passwords is the industry standard - but on the server side, not on the client. Even if some other key is derived from the original password, in the end that thing is going to have to be passed as-is for authentication and will need to be stored somewhere. If you look in your apple keychains, lastpass, browser saved passwords, all of those data are viewable in plaintext on your machine. Maybe it could be argued the password shouldn't be stored in plaintext on the storage, so it would have to be decrypted during runtime to get the original plaintext password back again. This does add some security, but only takes someone dedicated enough to pull out the decryption source from the application to get around it.

426 points by voxadam 4y ago

Is this that big of a deal? Surely by the time someone has hardware access, the game is over. The keys need to be decrypted into memory to use them, and nothing stops someone with hardware access from dumping that memory. No amount of encryption beats a soldering iron.

tinus_hn 4y ago
Even worse, that hashed key they are proposing is plaintext equivalent, it has the same access as the password (actually it is the real password, the PSK). And while for normal passwords there is the argument the password is more valuable because people reuse them, that doesn’t really apply for WiFi unless people use the same password for different SSIDs
voxadam 4y ago
It seems that it could be a pretty big deal to people who toss their old devices in their curbside trash to upgrade or otherwise discard their old Echo devices. Most people don't have the background to understand that attacks like this are possible. Hell, the other day I almost chucked a couple of old 11n era APs flashed with OpenWRT into the trash until I remembered that there's some incredibly sensitive data (SSID, key, logs, etc.) stored in a manner that likely wouldn't hold up to a physical attack. I do have the understanding of attacks like this and in a moment of haste to decluter my home office I nearly opened myself up to an attack like the one described in this post.
- josephg 4y ago
  Are wireless network passwords really that important? What is the threat model here? I’m trying to figure out the downside risk. Someone finds out your wireless password, figures out your address via an AGPS lookup and then … drives to your house and what? Steals your internet? Projects something on your smart tv? Turns your insecure smart lights on and off? I can imagine that being effective as part of a complex spear phishing attack against a celebrity or something. But if someone dumpster dives and ends up finding my wifi password, why should I care?
  - tspike 4y ago
    Identity theft is the first thing that comes to mind
squarefoot 4y ago
That's why old devices must be properly cleaned of personal data before being sold or discarded. I buy most of my devices (network stuff, APs, laptops, etc) either as refurbished or at flea markets. If I was a malicious actor I could have easily taken advantage of many people who didn't delete their data, including WiFi settings, from a device they gave away, so although devices are used in relatively safe places like home or workplace where it would be impractical if not impossible to gain physical access for the time necessary to exfiltrate sensitive data, that becomes trivial if the device is discarded/sold without taking proper measures to delete any sensitive data it could still contain.
- oceanplexian 4y ago
  Just don’t assume WiFi is a form of security. My WiFi network is no different than a hotspot at a coffee shop, anything important lives in another VLAN and has tight access controls. Someone could get access to my network, and they’d have zero ability to do anything useful other than access the public Internet. This also protects against sketchy apps like TikTok and proprietary devices (like voice assistants).

AshamedCaptain 4y ago

> When using this tool, it is good practice to hash the password for the wireless network before storing it in the configuration file (encrypt it in a way that cannot be reversed). This can be done with one simple command (wpa_passphrase), Huh? Anyone who has that hash can still connect to your Wi-Fi network, which kind of defeats what is being claimed. At that point you can also bruteforce the plaintext password (offline, at your leisure), or worse...

Dragon863 4y ago
Sorry about that! I misunderstood how hashing works, and I've updated the page with a correction at the bottom
- deleted 4y ago
  [deleted]
badkitty99 4y ago
But don't you need the preimage of the hash to generate it in authentication?
- overthrow 4y ago
  On Linux you can auth using the hash instead of the password. Other OSs probably have something similar. https://unix.stackexchange.com/questions/40/use-wpa-supplicant-without-plain-text-passwords https://unix.stackexchange.com/questions/40/use-wpa-supplica...
  - lxgr 4y ago
    Yes, but I suppose GPs question was "is that enough to authenticate?" – and given that as you say Linux and iOS/macOS (for Wi-Fi "password" sharing with nearby devices) do support that, and my other comment, the answer is "yes".
- lxgr 4y ago
  Not for WPA-PSK. The PSK is used to derive the PMK from (simplified) something like PMK = Hash(PSK, SSID). This key is static and never changes for the lifetime of a particular SSID, and is also shared across all devices in WPA-PSK. From the PMK, all other per-connection keys are then derived at association time, but everybody that captures that conversation can derive all further keys since that exchange uses only symmetric functions with all secret inputs derived from the PMK, not something like Diffie-Hellman. It's unfortunately not easy to do anything more resistant against compromised clients without storage on the APs (or at least a stable encryption key available to all access points of an SSID), so WPA-PSK doesn't – for anything more robust than that, you need WPA-EAP. (Some networks support a per-station/MAC address PSK as a proprietary feature, but that's only possible because they do have some management plane that allows the APs to share the required state.)

Aissen 4y ago

Meh, the PSK can be used to connect to the network. The "cleartext" really does not matter unless you reuse passwords, which you shouldn't do. Anyone with physical access to your Echo probably has a dozen other methods to get access to your password. Now dumping this is still quite impressive for 14 year old. Kudos.

codetrotter 4y ago
> Anyone with physical access to your Echo probably has a dozen other methods to get access to your password. For example, walk two meters to the side over to where the router sits, flip it over and read the label where the PSK is printed on the router. :D
- toast0 4y ago
  Nobody read the password when it was on the router... So now I have it (with a big QR code that sometimes works) on a printed page taped to the side of the printer.
  - dzhiurgis 4y ago
    NSA has cameras that can scan your router QR code from space satellite
dcow 4y ago
> Now dumping this is impressive for a 14 year old. Kudos. The only part I don't believe is the three Makefiles. Even grey beards struggle write correct Makefiles. If Daniel wrote those too then that’s the truly impressive feat.
- photochemsyn 4y ago
  It's a nice project, the Makefiles are cloned from the amonet project this is based on. I tried understanding them with the help of ChatGPT, that was an illuminating exercise. I think (not sure) that the build rules could be better ordered, it seems like they're just scattered about in the Makefile relative to the order of events (compiling the C and assembly source code into the ELF file and hence to the binary).

notum 4y ago

Not to diminish the effort (I love seeing these things cracked): if you have physical access to an Alexa device you likely have access to the router as well. The better coarse of action for a wrongdoer would be to get everything off the router using a serial interface and leave no traces behind for an extended remote access.

voxadam 4y ago
As I mentioned in a reply to another comment there's a lifecycle issue to consider. People frequently upgrade their devices (IoT and otherwise) or dispose of them entirely. Often times these old devices are disposed of in insecure curbside trash bins. With every old IoT device being tossed into the trash without though it's starting to look like this is a more and more effective attack vector with each passing day.
- lxgr 4y ago
  The "old device offered on the curb with a 'still working' note" threat scenario is actually a more realistic one than something like a corporate Wi-Fi in my view, since the latter would hopefully have any physically exposed client devices like that in a separate subnet/VLAN/SSID. The added benefit is that any possible attacker gets two additional data points for free: Where the corresponding SSID is most likely located, and that that household can afford to give away the hardware for free instead of reselling it or trading it in.
  - JohnBooty 4y ago
    that that household can afford to give away the hardware for free instead of reselling it or trading it in The Echo Dot in the article retails for $40, cheap enough to be considered disposable by many/most. Would probably gain much more useful socioeconomic information simply by looking at the neighborhood in which said curb is located, right? :)

PinguTS 4y ago

So the attack vector is: you need to flash a device in a certain place. That means, you need to open the device and do other things. Honestly, who has an Amazon Echo dot on a private network in a public place? Yes, it is a valid attack vector but I would vote the likelyness and importance at very very low risk.

lxgr 4y ago
I've seen at least Chromecasts, Apple TVs etc. in quite a few corporate offices, so it's not completely unrealistic. Maybe somebody wants to use the Echo as a cheap speaker with the microphone disabled, or it's in a non-sensitive location. That said, in a corporate network, admins would hopefully put these in a pretty isolated subnet (by SSID+PSK, since they presumably don't support WPA-EAP where you could VLAN/subnet them based on their credentials).
- sureglymop 4y ago
  A better way to prevent this would be to use One Time Passwords for every device joining the network. If the password is reused from a different device it gets invalidated. I don't know if such a mechanism exists for networks and I guess it would also be trivial to just spoof a mac address. I guess it does for something like a captive portal.
  - lxgr 4y ago
    That only works in a model where you only have one AP per SSID, but many networks have multiple APs, and not all of them have a central controller. If you have a single AP and replace that for some reason, you'd also need to enter the PSK again on all clients. WPA-PSK seems like a pretty bare-bones protocol, but if you consider the constraints it has to operate in, it's actually not that easy to come up with something better (other than the omission of ephemeral key exchanges through something like Diffie-Hellman, which was only added in WPA3, but would not help in this threat scenario in any case).
  - smashed 4y ago
    The best you can do is have a PSK per mac address. Hostapd which manages the encryption of wifi access point in pretty much all wireless aps already supports it. You can supply a list of mac address to psk or obtain the psk from radius server. The mac address is provided as the username, all your need to do is return a different psk depending on the mac address. I have POC code lying around I should probably publish somewhere. Like pointed in sibling comments, it is pretty trivial to clone a mac address so if you were to dump a "unique" psk, all you need is the mac address that goes with it. What it does gain you though and that is a big plus in some situations, is the ability to revoke a single psk without having to reconfigure all your client devices. That is very useful. The onboarding is a little bit wacky though. You need an easy way to get the client mac address, generate a unique psk for it, save that in your config, then attempt connection.... One way I would like to explore is have a "next available psk" easily available, for example in an app available to the network administrator. When hostapd asks for the psk associated with unknown/never seen before mac, return that default PSK and save it as associated with that mac on succesful connection, then regenerate a new default PSK for the next device. This way, an admin can share the password or onboard new devices easily. You don't need to know the mac address of the client in advance. If you need to revoke access for a device, just revoke the psk that was associated with it.

xoa 4y ago

Eh. It's certainly not great practice though not stunning given how utter crap 99% of IOT WiFi seems to be. That said the author gets a bit overdone, and not just in brushing over the physical access requirement bit. >Storing passwords in plain text is a major security risk in hotels or businesses using the devices on their internal or private wireless networks, giving any potential attackers access to any other equipment on this network or allowing them to create a rogue network and redirect traffic or conduct a MITM (man-in-the-middle) attack. Nah, unless it's a truly awful network even for a prosumer let alone any organization. Even with IOT, ever more widespread PPSK support (which I'd consider a must have for anything greenfield at this point) makes segmenting devices onto their own tightly firewalled VLANs trivial. Normal user interactive devices (computers, smartphones, tablets etc) should all be using VPNs for internal access and just not trust the WiFi at all, or at the least again have their own VLANs. These devices should all support WPA-EAP as well so that's another option, and can just use certs and do away with passwords entirely. If IOT wasn't such crap that'd be an option there too but such is life. It would be fair to say this is all still more complex then it should be, all the tech pieces are in place to make this vastly easier even for the non-technical, the UX is poor in a bunch of respects. And I'm sure there are plenty of small businesses who just run flat networks, maybe with a guest wifi. But that's an issue anyway, and I don't think someone physically stealing an Echo and dumping its eMMC to get at their WiFi password is floor level on their threat model. More like "the desk machine has a password of abc123 and is left unlocked while the elderly B&B lady goes and makes breakfast for guests" and frankly who is breaking in looking for that anyway? It's egg on Amazon's face for sure, absolutely embarrassing for a company of that size and product line that big, and that it's exposed in plaintext on the fs might chain a remote exploit in interesting ways, but not if physical access is required. And again, organizations actually facing threats really just shouldn't be trusting WiFi much anyway. It's not that secure even in theory and implementations are a mess and probably always will be.

Dragon863 4y ago
Thanks for the feedback! It's the first time I've written anything like this, and I'm currently studying computer science so I appreciate the corrections as they help me improve my knowledge of the field :)

someweirdperson 4y ago

Whoever has an Alexa on their network doesn't have anything to hide (doesn't care about privacy). Exposing the wifi password on top of that doesn't seem to be a big deal, when full access has already been granted to an evil device.

gbear605 4y ago
It depends on your threat model. If you're worried about Bezos, Amazon, or a government, Alexa is absolutely a privacy risk. If you're worried about wide attacks or a script kiddy coming after you, Alexa is probably not the main vector of attack here.

draugadrotten 4y ago

A very inspiring thing about this article was the bio: "Hi there! I am Daniel, a 14 year old developer whose interests include cybersecurity and hardware hacking, low level hardware, web design, and linux." I look forward to seeing what you do 10 years from now. Keep it up!

toomuchtodo 4y ago
This too was my favorite part. Inspiring. Great things ahead for this young human.
- dcow 4y ago
  If he can write a correct Makefile like this at 14 then a truly formidable foe is on the rise, indeed.
  - lopkeny12ko 4y ago
    Am I missing something here? The Makefiles seem very standard for a C/C++ project, and could have been easily replicated from a tutorial or example project without much modification. Not suggesting that the work is not impressive, but the kids of today grew up in the era of computers and the Internet, and a lot of problems that were hard for you and me are no longer hard today.
    - fundad 4y ago
      24 years in the industry and 24 years of “it’s knowable, didn’t you know it already?” arrogance.
    - grepfru_it 4y ago
      >and a lot of problems that were hard for you and me are no longer hard today. I spent my teenage years learning and understanding sendmail milters. I got to a point where I could write them from scratch. Guess how useful this knowledge is today...

vrglvrglvrgl 4y ago

[dead]

mavili 4y ago

The bulk of the article kinda revolves around storing wifi passwords unhashed.. and then at the end "Edit: hashed passowrds are used to connect to wifi, so hashing is not a solution".. erm, so what is the point of the article then?

atomicnumber3 4y ago
I thought this was really excellent technical writing given I'm not sure the author has had an English class that actually covers anything beyond grammar and basic literary analysis yet.
- UncleEntity 4y ago
  I’m over 50 with a college degree and haven’t had an English class that actually covers anything beyond grammar and basic literary analysis yet.
Dragon863 4y ago
As others have pointed out, even hashed passwords can be used to connect to a network. However, storing the password in plain text is an embarrassment for a company as big as Amazon, and they should at least be stored in a non readable format if not encrypted. The physical access necessary does make the exploit less dangerous, though. You asked what the point of the article was, I think this could also be a starting point for running our own software on these devices, especially as there is a kernel for the mt8163 available on github from the postmarketos project
- AshamedCaptain 4y ago
  I really don't agree here. There are many arguments for storing plaintext passwords in, well, plaintext, rather than behind pointless obfuscations. Expressed quite concisely by Pidgin authors many years ago: https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords
- mavili 4y ago
  After hearing you're 14 I don't want to turn this into an argument really, but please note just because something "sounds" embarassing it may not be actually. Like others have pointed out, physical access to the device means many other measures that can be taken to protect security is not valid anymore. If there is no real need or security benefit for that password to be stored in anything other than plaintext then Amazon doesn't need to go out of their way to save any "embarassment".

hamilyon2 4y ago

One of my favorite iot-wifi stories is about Bluetooth-enabled iqera lightbulbs and them connecting to private wifi. You have to send your wifi password cleartext to some Chinese server during setup phase. Yes, this is the only way to set up these lightbulbs.

cjxjxjxjxjxjxxj 4y ago

[flagged]

cjxjxjxjxjxjxxj 4y ago
[flagged]

fffffo 4y ago

Interesting read. I'm surprised Amazon haven't blocked UART access in bootrom mode, considering there's an efuse they can blow, from the bootloader (LK) environment, that will permanently disable it. As an example, Motorola did this on their Mediatek-based phones as part of a firmware update.

thekingshorses 4y ago

Any hotel that uses Alexa devices are vulnerable! I hope google chromecast don't show the password.

MuffinFlavored 4y ago

what’s something harmful you can maliciously do once you are on somebody’s typically password protect wifi network? sniff traffic? you can’t MitM due to HTTPS so… curious. what can be done?

dfxm12 4y ago
Aside from just stealing the Internet service, you can set up a device to do something (of questionable legality), either attended or not, that you don't want associated with your own wifi network.
addandsubtract 4y ago
Access (or try to) connected devices, such as a NAS?

exelib 4y ago

Cool blog post. One thing I am not sure about. If access to WiFi can lead to the mentioned or other risks, then something else is probably seriously wrong in the chain.

Dwedit 4y ago

If you can get to somebody's Echo and short that capacitor to dump the rom, chances are good that you can also just walk up to their wireless router.

asveikau 4y ago

> When using this tool, it is good practice to hash the password for the wireless network before storing it in the configuration file (encrypt it in a way that cannot be reversed). This is bullshit. The device ultimately needs the wifi passcode in plaintext. What this person is asking for is obfuscation and cryptography theater, not real security. Of course if you root the device you can read the wifi passcode. This is not shocking.

nimih 4y ago
> The device ultimately needs the wifi passcode in plaintext. Why is this the case? There are a number of cryptographic methods of varying complexity which allow a server to authenticate a client against a password without storing the password itself.
- asveikau 4y ago
  Because if you had such a scheme it would no longer be wifi. WPA needs the device to have a key. You cannot replace WPA with your own key derivation scheme to avoid storing keys to keep this ridiculous statement in the blog post happy. Whatever scheme it is, it's probably compromised by rooting the device storing secrets... To make a reference to the quote used by Raymond Chen, the security flaw "rather involved being on the other side of this airtight hatchway".
  - nimih 4y ago
    That makes sense, thanks for clarifying.
BenHays42 4y ago
The wpa_passphrase tool simply stores the raw hash used by WPA to authenticate to the AP. This is the behavior performed under the hood even when the plaintext is utilized. You could still reuse the stored hash to maintain the same level of access afforded by the plaintext passphrase, but wpa_passphrase isn't security theater or obfuscation.

xupybd 4y ago

I'm not sure there is much point in encryption if the OS is used to protect the encryption keys the same way it is used to protect the data it is encrypting.

an-allen 4y ago

So the idea of shorting that capacitor… how did you reason that doing that would keep that chip from starting?

Dragon863 4y ago
Two reasons: 1. Mediatek processors have a preloader, essentially a bootloader, which checks the emmc for a bootable partition, and if it cannot find one (or the emmc is not functioning correctly) it will load bootrom mode. This is what amonet exploits. 2. When using amonet on kindle devices, a similar method was used to force the device into bootrom mode as Amazon didn't provide a hardware key to do this

deleted 4y ago

[deleted]

xyzzy_plugh 4y ago

This isn't particularly interesting, though the steps to get access are nicely done. Most devices of that era including many Android phones lacked any sort of secure enclave for tamper proof secret storage or encryption. I believe the early Echo stored the wifi password using a weak block cipher and a fixed key, like Kindles. Given the password needs to be eventually decrypted in software, any sort of encryption like this is effectively obfuscation. Physical access is far, far worse! I think folks forget how much security innovation there has been, and become accessible to consumers, in the last decade. It wasn't too long ago that SSL was considered a luxury.

beatehester 4y ago

[flagged]

hypnootis 4y ago

What framework did you use for the blog? It's gorgeous!

Dragon863 4y ago
Thanks! I had a go at using beercss, as material design 3 has no official web version yet

tidenly 4y ago

Just a note on the amendment at the end: Storing hashes of passwords is the industry standard - but on the server side, not on the client. Even if some other key is derived from the original password, in the end that thing is going to have to be passed as-is for authentication and will need to be stored somewhere. If you look in your apple keychains, lastpass, browser saved passwords, all of those data are viewable in plaintext on your machine. Maybe it could be argued the password shouldn't be stored in plaintext on the storage, so it would have to be decrypted during runtime to get the original plaintext password back again. This does add some security, but only takes someone dedicated enough to pull out the decryption source from the application to get around it.