21–30 of 200 posts
Try to direct the DNS requests to their own server instead of the LiveUpdate one? If so, how?
Also, would we be a better design? Hard-code IP addresses to prevent the DNS trick? Use HTTPS and hardcode the public key of the server on every machine?
(Only asking out of curiosity, clearly.. Seems like a good case study for designing things right.)
Very nice find. What are the business unit motivations behind critical suppliers like ASUS repeatedly violating customer trust in this manner? At what point in the management chain is the decision reached to sacrifice reputation for - whatever cost savings there are from not implementing TLS/blob signing? edit: This is not rhetorical. Actually curious if someone on HN familiar with this class of companies (ASUS is no…
It's hard to make a case for long term support of commodity hardware sold into the consumer market because the most shiny things at the lowest first tends to drive purchases. It's as true for laptops as it is for Android phones. BestBuy doesn't care if it stocks ASUS or not. It cares about sales and margins. If there's an extra dollar putting Gateway on the shelf instead of ASUS they will. And their customers won't c…
Damn ASUS that's a real shame, because that Royal Blue Zenbook 3 is god damn sexy https://www.asus.com/Notebooks/ASUS-ZenBook-3-UX390UA/
But perhaps you meant that you must now, as a protest, shun ASUS products. I can sympathise with that.
I have an Asus now but installed Ubuntu first thing when I got it. If I couldn't use Ubuntu I'd use Mac. I see the problem has two sides, Windows for allowing for malware preinstalled and OEM for installing it.
Out of curiosity, how would an attacker exploit this to run a code s/he wants? Try to direct the DNS requests to their own server instead of the LiveUpdate one? If so, how? Also, would we be a better design? Hard-code IP addresses to prevent the DNS trick? Use HTTPS and hardcode the public key of the server on every machine? (Only asking out of curiosity, clearly.. Seems like a good case study for designing things ri…
Hardcoding the IP is not a good idea and it doesn't work against MITMing. HTTPS with certificate pinning would be the standard way to secure the connection. Verifying the BIOS image using a certificate before installing it is also "a good idea" (ie. pretty much mandatory), that way users can provide a binary downloaded on another computer.
Earlier quoted context omitted.
It's hard to make a case for long term support of commodity hardware sold into the consumer market because the most shiny things at the lowest first tends to drive purchases. It's as true for laptops as it is for Android phones. BestBuy doesn't care if it stocks ASUS or not. It cares about sales and margins. If there's an extra dollar putting Gateway on the shelf instead of ASUS they will. And their customers won't c…
True but it creates business for ThinkPad and I'm loyal to them. They fupped too though
In the case of routers, things are beginning to change because the FCC is requiring that manufacturers prevent users from modifying radio parameters to their satisfaction and the easiest way to do that is to prevent users from using OSS firware:
http://hackaday.com/2016/02/26/fcc-locks-down-router-firmwar...
In the case of Linksys routers, the router firmware appears to also auto-update and until recent firmware versions, it lacked verification. I do not know if it auto-updates over HTTP. If it does, the ones running older firmware would definitely be vulnerable to the same kind of attack as the Asus motherboards.
I recently purchased a Linksys EA8500-RB to use as an access point and wanted to flash OSS firmware that I built myself for a reasonable level of confidence in its trustworthiness. It turned out that DD-WRT is the only third party project that supports it at this time. There is no documentation on how to get the precise sources used by the ddwrt developer to build the images he distributes and those downloading them are vulnerable to MITM attacks from the absence of HTTPS+checksums and/or PGP signatures:
http://desipro.de/ddwrt/K3-AC-IPQ806X/
The DD-WRT project does have a subversion repository that could be used, but anyone doing a checkout are vulnerable to a MITM attack due to the absence of HTTPS. A mirror is available on github, although there have no assurance that whatever is replicating the repository from subversion to git is not vulnerable to a MITM attack. Furthermore, the build instructions for the image are missing and while generic instructions exist, they are incomplete. They also specify the use of a binary cross compiler toolchain, which similarly has no obvious source code and no protection against MITM attacks.
I built my own toolchain with Gentoo's crossdev, but the incomplete instructions require that I figure out how to use a custom toolchain, the dd-wrt config parameters, the kernel config parameters, how to go from a build to a factory to ddwrt image, etcetera. It is a huge pain, but it is one that I must endure if I want to have an access point running OSS firmware that built myself. Building it myself gives me a high level of assurance that the binaries correspond to the source code and that the source code can be audited by either myself or people in the community.
It really should not be that difficult to get trustworthy firmware and Asus' goof is just the tip of the iceberg.
Wow. I always knew hardware manufacturers half-assed their software, but this is kind of a new low. I'm not sure whether to laugh or cry.
Could be worse, the title made me imagine UEFI firmware itself making HTTP downloads and reflashing itself ;)
This means I can basically go to a Starbucks and pwn the Asus there, right? I have an Asus now but installed Ubuntu first thing when I got it. If I couldn't use Ubuntu I'd use Mac. I see the problem has two sides, Windows for allowing for malware preinstalled and OEM for installing it.