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!
Thanks for adding that. I thought it was odd he was discussing `wpa_supplicant` in the context of Android, it makes a lot more sense if he's not a greybeard!
An example of a backronym as a mnemonic is the Apgar score, used to assess the health of newborn babies. The rating system was devised by and named after Virginia Apgar. Ten years after the initial publication, the backronym APGAR was coined in the US as a mnemonic learning aid: Appearance, Pulse, Grimace, Activity, and Respiration.[6]
Many United States Congress bills have backronyms as their names; examples include the American CARES Act (Coronavirus Aid, Relief, and Economic Security Act) of 2020,[7][8] the USA PATRIOT Act (Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act) of 2001, and the DREAM Act (Development, Relief, and Education for Alien Minors Act).[9] In the 113th Congress (2013) there were over 240 bills with such names.[10]
The Bing name was chosen through focus groups, and Microsoft decided that the name was memorable, short, and easy to spell, and that it would function well as a URL around the world. The word would remind people of the sound made during "the moment of discovery and decision making".[19] Microsoft was assisted by branding consultancy Interbrand in their search for the best name for the new search engine.[20] The name also has strong similarity to the word bingo, which is used to mean that something sought has been found or realized, as is interjected when winning the game Bingo. Microsoft advertising strategist David Webster originally proposed the name "Bang" for the same reasons the name Bing was ultimately chosen (easy to spell, one syllable, and easy to remember).
For me it's mix of Linux kernel and a subset of common FOSS software[0] providing the boot and low-level operations, while the middleware is provided by AOSP with Dalvik/ART and the top, the whole user experience with GUI, apps and whatever. The middle and the top has absolutely nothing common with Linux.
To give you and idea - if you swap the engine in your Ford to Cummins, would you tell everyone what you are driving Cummins? No, you would tell what you are still driving Ford. The same applies to Android, if you swap the Linux kernel to something else, eg to OpenBSD kernel, would you tell what your smartphone is now running on OpenBSD? No, it's still Android, though with OpenBSD kernel.
[0] if you have Linux kernel then it doesn't makes sense to write tooling and userspace from scratch. Like you can, but.. why?
So, it IS a Linux distribution with other userspace that's not made by GNU. What some people call non-GNU/Linux.
Distributions like Alpine for example would also be it.
>The same applies to Android, if you swap the Linux kernel to something else, eg to OpenBSD kernel, would you tell what your smartphone is now running on OpenBSD? No, it's still Android, though with OpenBSD kernel.
Nobody says that it wouldn't, and it also would be true for other Linux distributions. Remember Debian GNU/kFreeBSD?[0]
Now, you could argue that someone who's using the terminal in Debian GNU/kFreeBSD would notice that it's not in fact Linux, but that's a matter of expertise (not every Linux user relies on the terminal), and that's also true for Android.
> So, it IS a Linux distribution with other userspace that's not made by GNU
So, it IS a Cummins distr^W car with other car parts that's not made by Cummins? Despite the big blue "Ford" everywhere on the car and in the documentation?
Another litmus test I often amused by is how when where is a report of a bazillion of Windows infections (especially those when a user should explicitly run the payload, not just a drive-by) then it's Windows problem, but when there is a report of bazillion of infected Android phones and tablets then of course it's not Linux and therefore it shouldn't be chalked up in any "Amount of infected computers per OS" graphs, lol.
> So, it IS a Linux distribution
Humans tends to omit unnecessary repetition and overall tends to shorten things when it's fits their current situation.
But that doesn't make "an operating system distribution based on Linux kernel with system instrumentation and userspace common to other popular operating systems based on Linux kernel" equal to "Linux distribution" or "Linux".
>Another litmus test I often amused by is how when where is a report of a bazillion of Windows infections (especially those when a user should explicitly run the payload, not just a drive-by) then it's Windows problem, but when there is a report of bazillion of infected Android phones and tablets then of course it's not Linux and therefore it shouldn't be chalked up in any "Amount of infected computers per OS" graphs, lol.
Normally, when it comes to CVEs you tend to see it targeted to the affected piece. E.g.: CVE-2022-38533 affecting GNU binutils and CVE-2023-25139 affecting sprintf() in glibc. Those two things are core parts of most Linux distributions, yet they are still their own distinct thing.
The fact that many times the accused piece of software is Android (like in CVE-2022-20472 or CVE-2023-21079) is just a testament of how big of a monolithic most of the Android userspace is, without ceasing to be a Linux disribution.
>But that doesn't make "an operating system distribution based on Linux kernel with system instrumentation and userspace common to other popular operating systems based on Linux kernel" equal to "Linux distribution" or "Linux".
Well, that's precisely one of the arguments[0] used in favor of naming some Linux distributions as GNU/Linux:
>Since a long name such as GNU/X11/Apache/Linux/TeX/Perl/Python/FreeCiv becomes absurd, at some point you will have to set a threshold and omit the names of the many other secondary contributions. There is no one obvious right place to set the threshold, so wherever you set it, we won't argue against it.
I'm perfectly aware of the whole GNU/Linux debacle, thanks.
Counter question, is firmware on some cheap-ass $10 router is a Linux distribution? Is this cheap-ass $10 router IS Linux?
> Those two things are core parts of most Linux distributions, yet they are still their own distinct thing
Well, Explorer is the core part of the most of Windows SKUs, yet when the Explorer is at fault - it's Windows fault and goes in the stats, while millions of infected Android phones suddenly doesn't because it's not Linux, it's Android (emphasis mine). Kindergarten level of logic, yet used by grown-ass men.
>Counter question, is firmware on some cheap-ass $10 router is a Linux distribution? Is this cheap-ass $10 router IS Linux?
Well, I think it is. Although they tend to refer to them as Linux-powered, which is still the same but with a hyphen
>Well, Explorer is the core part of the most of Windows SKUs, yet when the Explorer is at fault - it's Windows fault and goes in the stats, while millions of infected Android phones suddenly doesn't because it's not Linux, it's Android (emphasis mine). Kindergarten level of logic, yet used by grown-ass men.
Yeah, probably those things come mostly from how widely present are both Windows and Android on people's lives. It's a media preference since it wont't get you many clicks to say that there was an error on Explorer :P
Still, Android is a Linux distribution until they find a new kernel
shows the powerful of self taught path versus schoo/being taught you find things intrinsic on your own that others take for granted but this also gives you a deeper understanding
I don't agree that it's one or the other. He obviously clever and driven with stamina and a desire to make his mark. He can do great things with an education also.
In an ideal world that's true, but a lot of really bright kids wind up becoming educationally restless, and fall into traps of not seeking higher education because of how slow it is. Also due to them being quite gifted, they develop some of the worst study habits due to the rest of the classes holding them back. When push comes to shove and they actually need good study habits they tend to opt for dropping out or drugs to push through. Lots of gifted kid papers about this phenomenon.
Thankfully there are some programs now where kids like that can still thrive under a job+degree hybrid (and no I don't mean that one co-op semester). The work gives them real experience and a faster pace, the degree secures a stable foundation to provide that work context. So maybe when OP is of age the programs will be less limited and accept more students.
> In an ideal world that's true, but a lot of really bright kids wind up becoming educationally restless, and fall into traps of not seeking higher education because of how slow it is.
in our real world, most of the people making cutting edge breakthroughs in math and science were gifted kids who got a great education through graduate school.
True though some ended up underemployed as patent clerks along their journey to the cutting edge. In an ideal world, those years would have never been "lost".
I'd wager most folks who know about wpa_supplicant didn't learn about it in school. Hacking around wifi on laptops wasn't a school thing, it was often the same sort of thing this is... self-exploration.
Just depending on age you might refer to it as "a tool called wpa_supplicant to manage its wireless connections, which is not uncommon on older android versions" vs "wpa_supplicant, an old standby Linux wifi management program" or somesuch.
Hey, great write up by the way! Many of us here were self taught taught teenagers, and the more successful people I meet, the more I'm convinced that's a strong factor. Keep doing what you're doing, and maybe add an RSS link for some of us to follow along!
Hi there! I wish I could claim that I wrote the Makefiles, but my knowledge of C is very limited and all the credit for that goes to xyzz, who created the original exploit intended for Amazon kindles. I simply created a fork that would work with the echo using the same CPU, the original code is here: https://github.com/xyzz/amonet
This is why I love the old pre-LLM world. Can’t help but imagine that already now many people just get the very same code suggested by Copilot and never even learn about the existence of the original author—whom they wouldn’t be able to credit even if they wanted to.
(The corollary being, of course, if that recognition and pride in one’s work are what drives people to do original research and share it openly in the first place, why would they do it now in this brave new world?)
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.
>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...
It used to be incredibly difficult for me to edit 4K footage on my computer. What’s your point? How does that undermine what young editors are doing now with 4K and beyond?
All my work arounds and tricks are completely useless today. There is some broader knowledge and problem-solving I learned I’m sure, but ultimately a lot of the tools I learned over the past 15 years are completely useless now and those youngsters are now overcoming their own obstacles!
Edit: you've broken the site guidelines a ton and we've asked you to stop doing it a ton—too many times to bother listing. Yet you're still doing it repeatedly—I saw several bad examples just skimming your comments from recent days.
Sounds exactly like my own feeling of superiority after my first hacks as a teenager. Dragon, as a greybeard who used to do equally dumb and great stuff like you… don’t let how people judge you ever stop you from hacking. Rock on!
There are "corporate versions" of Amazon Alexa devices specifically made for sale to & for use in hotel rooms[1]. It's called Alexa Hospitality[2] and it does not need to pair to an Amazon account for you/anyone to use it.
Many high end hotels/long-stay furnished apartments have Alexa devices in them.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful. We've had to ask you this once already.
My original comment was not meant to downplay you. Quite the opposite. It is a bow to you and the article. It was thorough enough that i had to ask if it was a 14 year old who wrote. Really happy for you and keep at it. I see you are looking into getting a mediatek processor after your exams, send me a message and I would be happy to get it for you. t e n d i @ o u t l o o k . c o m
I agree. There are still some posts on Usenet archives that I wrote when I was 14, and there are no telltale signs that they were written by a 14 year old, except for not understanding certain programming conventions.
I wasn't particularly bright. I think we underestimate the capabilities of children.
I see no reason a 14 year old shouldn't be able to program and say, do multivariate calculus. If anything, they are more intellectually capable than someone going through the pains of late adolescence.
Crystallized intelligence at that age might be low, but fluid intelligence is at or near its peak.
I'd have to say free time is also a huge factor! I have exams coming up, but for now in free to hack stuff in my spare time. I was also looking into newer echo models, according to hackaday they have a hidden debug port but still use mediatek processors, maybe I'll buy one on ebay in the future and have a look...
A smart 14 year old can often out-think adults in my experience, because adults are weighed down by 'adult' content like power relationship between the speakers, social appropriateness, real or imagined legal obligations, yesterday's news, thirst for alcohol and triple-X sex, you know "everyday stuff" whereas the 14 year old is relatively unburdened by all that baggage. What a 14 year old lacks is 14 years of reading on a subject, of course, or previous training. YMMV
> I think we underestimate the capabilities of children.
Probably to a large degree because we lock them up in a room all day where they spend their time listening to information targeted at the bottom decile of the room.
I suspect you are smarter than you give yourself credit for. Many 14 year olds could not have written that well. That's totally okay and they can still learn how to later in life.
When I think about it, I could have done algebra by the 5th grade, calculus by the sixth, etc. But what is not being considered is what’s going on with those neurons, at this time, instead. It is not obvious that maximizing purely academic results is optimal.
I highly doubt this was truly written by a 14 year old. Perhaps someone fudged their age to try and make the content go viral? The GitHub profile is 3 weeks old but it's clear this ain't his first GH profile, and there are commits for SEO optimization! The English skill alone seems too advanced for that age level.
Maybe he really is a genius but I've become far more cynical in recent years, don't believe everything on the internet! By the way, I'm 12 years old.
Sorry, but I'm definitely 14! I created a separate profile because I didn't want anybody (i.e. Amazon) to be able to trace it back to my main account and find my full name. I usually do more web development in my spare time, so this was a completely different experience for me, hence the misunderstanding with hashing passwords. Also, I didn't write this from scratch, as you'll see on the GitHub page it's a fork of a project to jailbreak kindles, but thanks for the positive feedback!
You're awesome. I did stuff like this when I was 14, but didn't have the skill to write about it (and still don't) due to autism. But on the other paw, your article seems really well-written!
It's because I have to express concepts in a certain way, and it doesn't usually flow very naturally. It usually sounds really serious or insensitive. When writing articles, my perceived tone is just really boring, because of the way I have to explain things. My words come out weird and the "sorry, I'm a native speaker" is real.
To the author, you should absolutely wear it as a badge of honor that people have looked at your technical writing and said, "no, I don't believe that you're 14."
As the original 14 year old on the internet (see my entry in the NET.LEGENDS FAQ), I'm glad 14 year olds on the internet are still going strong - and making a better go of it than I did.
14 isn't that young. I was running BBS built and modded using C when I was 14 back in the late 80s, and it's much easier to get deep into tech now. I'm no genius.
I’m cynical too, but if somebody lied about their age to do it for the clout, that’s weird and whatever, let it go. If they did it to try and get noticed, it’s not like they’re going to get a job out of it. They’re either actually 14, or they’re a total weirdo liar that you’re absolutely not going to hire.
> 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...
I always thought this aspect of Wifi password security was a weird annoyance. It just makes thing inconvenient without providing any real security - and it's leaked into Android and taken to new extremes. For instance you can get and share Wifi with goofy QR codes - but syncing the whole wifi password list between devices? Impossible without rooting your device
They then up the goofyness in that it doesn't provide any mechanism in the UI to actually see the password, but you can screenshot the "share QR" code, read the QR in an app, and finally extract the password phrase that way (at least in all the Android versions I've tried). I have to do this dance regularly b/c scanning a QR code from a laptop is a pain
Loosing all my wifi passwords when I get a new phone always kinda sucks...
You can sync your WiFi passwords....to your Google account. It's a privileged permission, like most fun things on Android these days are, for totally legit and not at all anticompetitive reasons.
I wanted to write a quick app to switch between VPNs based on which WiFi network I'm connected. The Wireguard app exposes an API for this and many years ago I remember enjoying the broadcast receiver API of Android to react to such general changes. Thought I'd have myself an app in half an afternoon.
Well, it turns out getting the name of the current WiFi network is near impossible. There are four different ways for four different ranges of Android versions, the most recent of which plain doesn't work on my phone.
Somewhere down the line the greedy tracking on mobile apps has gotten so bad that even Google wants to make sure their users know they're being tracked. Without a permanent notification and a permission you can't grant in a popup, you're just not getting the WiFi name.
I completely understand why they changed the API and I'll even agree with the most recent incantation, but the state of mobile app development has become truly deplorabele because of tracking companies and everyone must now suffer the consequences.
The only way was turning on some enterprise mode most home routers don't have, I think because they didn't want to get sued for leaking company passwords.
Apple used to play that security-by-obscurity game too in their implementation of password sharing with nearby devices, and by not allowing users to view passwords in the Wi-Fi settings (even passwords they hand-entered themselves, as if they can't also make a copy of that in a much less secure place at that point). Fortunately, they've come around in the newer iOS versions.
But which Android feature are you referring to? On my Pixel, I can share the PSK as a QR code – not just the hash as far as I can tell.
Huh? The password is displayed right below the QR code, at least on my Pixel. Must be a difference between Android versions or vendor customizations, which is why I asked.
Exactly, and you can also derive all other devices' pairwise session keys from the password hash as well, i.e. intercept their traffic.
The only thing you can't get from the hash (without reversing it) is the password itself, so if you use the same high-entropy one for a different SSID or non-WPA-PSK purpose (but why would you?), it helps a bit in that specific scenario.
Apple has annoyingly decided to share the password hash using the "share Wi-Fi password with nearby devices" at least in some versions, which makes it impossible to actually manually copy-paste over a password received in such a way. I consider that pretty poor security-by-obscurity as well.
If you need your network to be resilient against such attacks, you need WPA-EAP ("enterprise"). PSK was never designed for that threat model. That said, it's a shame WPA-EAP is as complicated to set up and poorly supported by most routers as it is.
> you can also derive all other devices' pairwise session keys from the password hash as well, i.e. intercept their traffic.
Note that deriving keys in a passive fashion only works with WPA2. With WPA3 SAE you must do an active Man in the Middle attack, which means also that you need to possess the key at the time of the handshake. With WPA2 you can decrypt any historic traffic you have recorded.
Apple password sharing is definitely annoying. I mainly use Apple stuff including iCloud for password management. Surprisingly, it even works well enough on chrome for windows. It doesn’t work for the 10 game launchers I’m forced to use, but it’s not a huge inconvenience, I can just grab those from my iPhone. But I cannot grab wifi passwords from my iPhone, that can only done in keychain in MacOS.
On iOS 16 (and possibly earlier), it's finally possible to view passwords!
On exception are those originally received via nearby sharing, potentially also those afterwards synced to other devices via Keychain, as the iPhone does not have the preimage to display.
It wouldn't matter if the preimage of the hash were needed for authentication.
Because, if a device has all of the information needed to connect to a network on it, then.. well, it has all of the information needed to connect to a network on it. Could be passwords, hashes, or whatever -- doesn't really matter.
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".
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.)
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.
> 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.
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).
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.
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.
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).
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
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.
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?
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.
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.
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.
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.
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 :)
No problem, good for you both for digging into it at all and then actually writing it all out, good little exercise to go through and poke at for sure! Network security is its own entire other specialization and despite working in it there's always new stuff to learn and new challenges. And the mess and issues of the WiFi standards process is an entire book itself.
I guess the one generalist suggestion I'd have for you just for security overall is to always try to consider the overall threat scenario and "economics" of given attacks when judging seriousness for clients. It's easy to theorycraft purely in terms of hardware or software and get lost in the weeds of attacks that don't actually make any sense. All "security" overall is about the economics between how much it costs to defend and attack and what the value gained/lost is. So things that scale very well, like pure software remote exploits, are huge risks since somebody can run attacks near or fully automatically dirt cheap/free at mass scale and do so in a way that can be hard to trace back. Thus even those with very few resources are at risk, if the attack is free to the attacker then anything at all is profit. In contrast an attack that requires in person access doesn't scale at all, it must be done each time by an actual human actually going out there. And that entails major physical risks as well. So while expensive to defend against, it's also expensive to execute and thus won't happen unless a lot of value is available, and naturally individuals/organizations in that position (lots of money or high value assets) tend to have the resources themselves to take action.
Anyway, "engineering is the art of the possible", getting the best bang for the buck matched to what clients or employers need sometimes is part of the real challenge. Good luck with everything!
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).
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.
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.
Ah, yes, PSK per MAC is an interesting option and seems to be used by some enterprise Wi-Fi solutions already as well. I didn't know that hostapd supports it as well, that's nice!
Another option comes to mind, thinking about it some more: The standard could be extended (or a proprietary extension added) to make the PMK something like Hash(PSK, SSID, client MAC), or Hash(Hash(PSK, SSID), client MAC) for a bit more backwards compatibility.
That wouldn't help against clients that just store the PSK (hash), of course, and clients would in fact need to do that to allow sharing the access, but it would offer some marginal security benefit (for other clients on the network) against attacks on clients that do implement it.
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).
Ruckus offers one time PSK and PSK per vlan. Very easy. I started seperating my home devices on a different vlan.
Mikrotik, you can associte PSK with mac address. it's not easy to setup but basically, PSK & mac address need to match in order to access the network. I think it also puts user in the configured vlan.
> 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.
> 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.
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".
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.
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.
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?
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
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
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".
I agree that physical access is a major limitation, yet it is something that could easily be resolved with an OTA firmware upgrade or by simply informing users how their password is stored. I personally think that physical access should still be considered when designing products like these, even if it is a more remote possibility.
You seem to be missing the point my friend. The point of the security here is if someone has access to the device, are they able to extract information with which they can then connect to the wifi? The answer is yes REGARDLESS of whether it's hashed or not. When that is the case, not hashing is not a flaw. All hashing does in this case is 'obscure' it, which isn't the same as 'more secure'.
I suppose access to plaintext vs hashed password in this case saves the owner embarassment if they've used a secret, or if they've used the same password elsewhere, though that isn't a problem of device manufacturer.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
I look forward to seeing what you do 10 years from now. Keep it up!