ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification
teletext.zaibatsutel.net
teletext.zaibatsutel.net
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.
The flip-side is that this isn't the sort of security most of us want, and the fact that router firmware is "insecure" from this perspective is what enables things like DD-WRT to exist in the first place. See also: iOS jailbreaking, Android rooting, console homebrew, etc.
There is a difference between making updates available in a way that enables custom firmware and doing them in a way that permits MITM attacks. Locking down automatic downloads is a good thing. Locking down manual updates is not.
Let's go back a step: Why do all of those things exist?
It seems like it would be fairly easy. Use ARM TrustZone or Intel TXT trusted environments to host a non-writeable firmware, with one-time-programmable key storage, verifies that the contents of the boot memory are correctly signed by the key. If it is, then boot. If not, don't (copy in and verify a last-known-good backup image or something).
If the manufacturer wants to create an update, they take the code to the CTO's office safe, and compile and sign the image with the air-gapped machine that holds the private key.
If the private key is not leaked, jailbreaking is impossible. Doesn't seem that hard.
0. They didn't think of it, and I just gave them the idea. Unlikely. 1. Resources required to implement this (hardware read-only keystore, crypto primitives in the bootloader, reboot scan time, backup boot image storage space plus incoming image storage space, etc) are too expensive. 2. The possibility of losing the key and having devices they mathematically can't modify without a complete recall and replacement is too terrifying. 3. They don't care relative to the effort to implement it. They talk and litigate like they care, why doesn't this message get carried down to the new product department? 4. Decision makers don't understand the difference between the "security" obfuscation measures they're being sold right now, and potential, actual mathematically secure models proposed to them. 5. They are incompetent to actually build this. They have some pretty smart people, and accomplish other impressive projects, so this seems unlikely. 6. There's a flaw in my scheme that makes it no better than existing methods that can be jailbroken.
I will see about writing something up after I am happy with my reconfigured network. Right now, I have more to do before I am happy with it.
http://www.buffalotech.com/products/wireless
My home network as two of them...and a WRT54g with dd-wrt on the Xbox 360. Buffalo has been around at least since the early 1990's when they sold printer buffers.
Maybe if sufficient number of people pester him about it.
EDIT: On a related note, I've been trying to get the ddwrt guys to improve their HTTPS setup (ciphers etc.) without much success. To me, testing with testssl.sh and fixing the errors that pop up is easy and not that much work.
Otherwise signing packages is actually preferred, because you can do it offline, so that hacking the server is not enough to push malicious code.
We're talking about software updates, you embed the key INSIDE the software to avoid this problem.
(Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)
As for “moving the problem,” it is worth it. Because it’s easier to verify the origin of the software once, then for every update. If there’s a new vulnerability in TLS this will only affect new installations. Verifying (& signing) packages offline is much more anti-fragile.
I intended to suggest you could download it on a separate system which you do trust and verify it there. Then transfer it to the target system.
With that said, security needs to be in layers and defense in depth is critical, especially for this type of core infrastructure.
He should upgrade all infrastructure points for better security where feasible.
There's also the political reason not to use Cloudflare ... we're quickly moving to a darker Internet where traffic goes into networks like Cloudflare and nobody knows what happens inside the black box. I wonder if that's where the resistance lies.
edit: This is not rhetorical. Actually curious if someone on HN familiar with this class of companies (ASUS is not unique among OEMs) can educate.
[0] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
Which is why computer OSs should start treating these as the potential hostile devices they are. None of this "trusted network" nonsense, no unencrypted or unauthenticated connections between devices on the same LAN, etc.
Bingo, I would also add that it isn't even a matter of caring. I suspect some of these people don't even know that they don't know. Which feeds exactly into your not caring statement.
"Never attribute to malice that which is adequately explained by stupidity"
I’ve done it twice, never again.
Just putting a public key in the DNS and being able to sign a CSR with the correspoding private key should be enough.
If you have DNS managed by your domain registrar, this helps you very little.
So, for the average small site that’s neither made with a kit where the hoster has a one-click SSL solution, nor large enough to have their own nameservers, this is a real issue.
And yet, these sites are the target demography for LE.
Two: ACME offers numerous ways to convince it that you own a domain name. My intent was to follow this up by saying you don't even need to be running an ACME client/mess with your apache config at all by using the dns-01 challenge variant over the http-01 variant.
> The key is that Lets Encrypt can be very difficult to configure and get things working. This is definitely a problem, it would be great to see a divorce between the apache config munger and the certificate fetcher. SSL available to the uninitiated is great but if they're on the command line then I'd like to believe they're capable of pointing their server at a specific location for certificates on disk.
Without authority, you can say "This is a good idea and you're taking a huge security risk without fixing it" as many times as you want and still be told "No new feature, not a development priority."
Needless to say, I can't interact with these sites through proxies. It could also be the case that those who care about their security and privacy simply left your community or limited their presence to just being spectators.
You don't get the same trial/iterate cycle there is with software features, when it comes to security. Kind of, but mostly not.
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 care. "BIOS updates with TLS!" stickers aren't going to improve sales.
Buying a laptop creates a consumer not a customer relationship. I want to pay the least, the manufacturer wants to deliver the least. A few years out, shiny-low-cost will drive my next purchase more than brand loyalty.
That’s the advantage of using the business line of products: it’s usually not as fucked up.
It's a shame because they make really good hardware.
They went through the process of specifying and developing a automated utility that downloads files, parses manifests and then acts accordingly to install BIOS or other updates, tested it and bundled it with their retail system build, and after all that effort didn't take the one tiny step to sign their files or at least put a $10 TLS certificated on their servers?
To me the more likely answer is that (as observed) this dates back to XP days or even earlier, when securing this sort of stuff was not front-of-mind. Back then, finding downloadable software served over https was rare. ftp or http was far more likely. And I think ASUS just never thought about updating their tools. They worked, so never really got a thorough second look at any point up until today.
Security risks are harder to quantify for the bottom line.
It also encourages reducing effort spent in fixing bugs before release, which is why I absolutely loathe this "update culture": the "we can always fix it sometime later" mentality is like procrastination, and leads to barely-working products being released.
It is true that before easy field-updateability, products did ship with unfixable bugs, but I feel like it has only gotten worse from there.
I don't deny the possibility that adding TLS to the update mechanisms might make the world better. On the other hand, I haven't seen a business case that shows a clear benefit for company's like ASUS to change all the moving parts in their logistics chain. Admittedly, I haven't looked very hard.
Insecure automatic updates need to be met with automatic, unappealable per-day fines calibrated to gobble the margin this kind of behavior creates.
Which might be better, but consequences of actions and all that.
Hardware culture involves designing it once, testing it once, setting up the supply chain and production line once, and from then on it's just quality control and marketing: totally a fire-and-forget weapon.
That means in a hardware dominated organization, where you sell hardware, revenue is in terms of units sold. Anything else is fixed overhead which detracts from the R. All those once-s above have moved on to other projects or they were short term contractors anyway.
If you make chips, after you tape out, the design organization must absolutely turn their focus to creating the chip that will obsolete it or someone else will eat your lunch. In a hardware organization, long attention span is a liability, not an asset.
With software, the road to success is incrementally increasing your value to the customer with each successive release. You are in it for the long game, and if you do not have the attention span to achieve a long-term vision, coupled with the ability to deliver incrementally on that vision, you will lose.
Having worked on the software side of a predominantly hardware company, I can tell you first hand how hard it is to get someone whose background is physical chemistry to grok anything to do with user-level software. They have been selected for a short attention span, and are good at their job because of the short attention span. This is at odds with the needs of software product management.
I can pretty much guarantee that Google Maps is not going to be the same 15 years down the road and I very much doubt Google has the interest in supporting something for that period of time. So somewhere down the road, we'll end up with all these cars that part of the early stages of connected cars that end up having completely unusable systems.
Keep it simple. Power, a 3.5mm audio connector, and a windshield suction mount. Something they can't screw up too badly. I can easily buy a new smartphone every 2 years, but a car I'm going to hold on to for more like 10. Why would I want to be stuck with a 5-generation-old navigation/music player system when the car is still fine?
Why would you be? Isn't this a solved problem?
When you want to upgrade your entertainment system, you head to somewhere like Crutchfield or Sonic or Best Buy and buy a new one to plug in. In many cars, it takes less time to install a new car infotainment unit than it takes to buy a new iPhone from a carrier store. (It's often cheaper too).
For people afraid of wires, bored teens at Best Buy will install it all for you for an extra $70.
With Electric cars / Hybrids, I can see issues since they integrate environmental controls and other stuff in to their radios. I suspect as electric cars become more common, entertainment companies will start building units with support for those features.
Is that actually true?
I'm no expert, but Crutchfield claims a 2010-2015+ Camaro can take almost any new infotainment box you'd like from their site. (Both Single or Dual DIN).
They claim you'll also retain all OnStar, audible safety alerts, and climate control functionality with your upgrade, regardless of the upgrade you choose.
See : http://www.crutchfield.com/p_120993010S/Metra-99-3010-Dash-a...
You can't just replace it and get identical/better functionality.
There's still dozens of brand-new cars that sell without a locked down center console.
For example, you could buy an 100% electric brand new 2016 Nissan Leaf. It ships today with an infotainment center you can "just replace it and get identical/better functionality" anytime you'd like. Despite being upgradable, it still supports many modern features (such as GPS, Apple CarPlay, Rear-view backup camera, etc)
At some point, people are making a choice. If you don't want to be stuck with an unmaintained computer in your car, buy any of the dozens of brand-new modern vehicles that let you freely upgrade whenever you like.
On my car I had to open up the radio and modify it by hand to accept aux input. Still, I wouldn't have chosen a different car. The other parts of of it are far more important, even if it does irk me that the center console isn't DIN compatible.
This is EXACTLY why CarPlay and Android Auto make us enthusiastic - the user interface is run and rendered on your phone, not the infotainment unit. The unit just shows a video stream of UI and sends back keystrokes, GPS and other data. Hence updating functionality and applications is in domain of your smartphone not the car or headunit manufacturer.
It took Toyota a long time to build their reputation you'd think other manufactures would do the same WRT software.
Other dimensions of quality (screen, keyboard, trackpad, hinge, case, battery, fans, overheating issues, preinstalled rootkits and adware, and certainly BIOS) are not relevant to their customers (who, even if they are frustrated with these things, don't necessarily know that something better exists).
So they go in whichever direction is cheapest (or, in the case of spyware, brings in the most 3rd party revenue).
And the rest? They're infecting themselves by opening dubious email attachments already. For someone looking to make money through viruses, MitM attacks are just not economical.
ASUS really should fix this problem by implementing TLS, but it's just very unlikely that they will lose any amount of customers whatsoever if they don't. And as long as that's the case, nothing will change in that regard.
I'm not sure whether to laugh or cry.
I think someone should write a 'virus' that would remove that vulnerable software from users' computers.
That should be enough to make them take security seriously (and not really hurt anybody.)
Actually I also don't like BIOS allowing to be flashed from within the OS for convenience. So your computer gets owned and you can't trust your motherboard anymore.
Solution? New BIOS firmware. Problem? Can only update via Windows binary.
I wish I was joking, but quite a few HP laptops can only be updated via Windows binaries...
I have had like 5 different motherboards in the last 10 years and all could be updated from a flash drive with the BIOS setup.
And yes, this required user action, they didn't just automatically flash random files from pendrives present during POST ;)
Convenience and security are often orthogonal.
(You could argue that the existence of good signature verification on the images is often sufficient, but if you have an older BIOS that's signed but has an exploit vector, you could still make use of that if you had unfettered access other than the signature checking.)
As long as the updates handle security properly (use HTTPS and verify signature), I don't see anything wrong with an "update" button in the BIOS.
IMHO the BIOS is not something that should ever change unless there's a very important reason to, and even then it should be on the explicit action and consent of the user, because of the risks of ending up with a completely non-working machine. UEFI is a whole new mess, but I think the same principle applies.
https://duo.com/assets/pdf/out-of-box-exploitation_oem-updat...
Ouch.
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.
> Windows 10 keeps the [Fast Startup] feature as Windows 8. (For more information, please refer to Windows 8-Introduction of [Fast Startup])
> Due to the reason, you CANNOT press F2 to enter BIOS configuration when booting the system.
[1] http://arstechnica.com/information-technology/2015/08/lenovo...
"or actively malicious."
* Started the trend of non-replaceable batteries in phones
* Started the trend of non-replaceable batteries in laptops
* Started the trend of locked-down devices where the owner can't decide what software to run
* Custom screws in order to prevent people from fixing their devices
* Custom enclosures in order to prevent people from replacing parts in their devices with commodity devices
* Soldering in stuff that doesn't need to be
And so on, and so forth. It'd be easier to come up with a list of good decisions they've made. In fact, for the sake of balance, here you go:
Also, I should point out that while Apple's phones don't let you install unapproved software, this isn't true of the Mac, which, unlike Microsoft-approved PCs[0], lets you install alternative operating systems (you can even boot to DOS!), disable its security features, etc.
[0] I know that MS do allow OEMs to allow disabling Secure Boot, but it's not required as of Windows 10. Meanwhile, Apple's computers don't have it in the first place!
If they consciously take a hostile action (and let's face it, you don't accidentally design a new screw) then yes, I'd call that malicious. If you do that repeatedly then I'd consider you evil.
> Also, I should point out that while Apple's phones don't let you install unapproved software, this isn't true of the Mac, which, unlike Microsoft-approved PCs[0], lets you install alternative operating systems (you can even boot to DOS!), disable its security features, etc.
Gatekeeper seems like a step towards it. And regardless, Microsoft isn't exactly a paragon to compare yourself against.[0]
In fact some of those decisions led me to chose an Apple product over a non apple one.
Locked down software ended up being a business decision for Apple's App store. As for the screws, I have no idea, but you can easily find appropriate screwdrivers online so it doesn't seem like that big of a deal to me.
Just as all the others? That's not a defense.
How the Top Five PC Makers Open Your Laptop to Hackers: https://www.wired.com/2016/05/2036876/
I hope this incident will push them towards https for all their http offerings. There really is no excuse anymore, its can be gratis and automated.
Worst-case, they might have implemented this like this:
DownloadNewUpdatesIntoUpdateDirectory();
ProcessWhateverYouFindInTheUpdateDirectory();
But perhaps you meant that you must now, as a protest, shun ASUS products. I can sympathise with that.
I usually reformat them on arrival anyway.
I checked the liveupdate01.asus.com and dlcdnet.asus.com domains referenced in the article, and they can certainly serve over HTTPS...
So outbound to an insecure HTTP url gets rewritten to pull from a HTTPS url instead etc.
I have never had to perform a BIOS update with any off the shelf computer from ASUS.
I have looked at the BIOS updates on offer. I cannot recall that they were always hosted on a server using HTTPS. Or that MD5 signatures were provided.
But my understanding was that only users that knew what they were doing applied BIOS updates after purchase.
Is flashing the BIOS really common with ordinary users?
It's a major change and not something I would want to be done automatically by a third party.
This auto-updating craze is becoming a bit farcical.
Running programs that let third parties open ports, and run downloaded executables.
But the concern is whether someone can MITM or tamper with the download?
Alas, it's illegal to "exploit" but not illegal for system vendors to enable exploits through negligence. Thus, because of how the law is written, vendors have little incentive to care about security and well-meaning white hats are disincentivized from demonstrating the vendors' irresponsibility.
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.)
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.
Just an aside, but I have been out of the loop for awhile with Windows but I couldn't believe how ugly Windows 10 looked when I booted it. I currently float between Mac, ChromeOS and Gnome and my favourite at the moment is still the material design look. Windows seems to be getting uglier. It is a shame because, although different, I am not sure it is functionally all that much worse these days.
i mean, what else is there?
Would it be possible that UEFI does that check (against a built-in signature) instead of relying on HTTPS?