If you’re interested in cybersecurity you’ve probably read any number of reports in recent years about the often tenuous state of security in consumer devices.
From insecure doorbells to webcams, and from light bulbs to home routers, we’ve written our own share of horror stories in recent years.
That’s disappointing, but hardly surprising.
Computing gear of this sort – a market segment often referred to as the Internet of Things (IoT), because the devices are typically tiny and don’t look or feel like traditional computers – is generally simple to use, and thanks to a highly competitive market is usually built down to a price, which is good news for consumers…
…but it doesn’t leave a whole lot of time or money for vendors to expend on security.
IoT devices also typically have limited memory, disk and processing capacity, for reasons of size and weight as much as price, so their software is often stripped down to fit.
That can work out well, because the more features you leave out, the fewer places there are for bugs to lurk; but it can also end badly because what gets omitted often includes security checks that might otherwise have been included, or implemented more thoroughly.
Nevertheless, some vendors of low-cost devices are responsive to bug reports and publish security fixes promptly, which leads to another problem with the IoT ecosystem, namely that many consumers take a “set and forget” attitude to these devices.
So even if your home router gets updated reguarly with security improvements, when was the last time you went and checked if your device actually has the latest firmware version installed?
Well, if you have an ASUS RT-AC1900P home router – a high-end, high-bandwidth home device – then we recommend that you do an update check now.
Researchers at Trustwave found security holes in this router’s firmware late in 2019, which ASUS duly patched, and those researchers have now gone public with a security advisory that details their findings.
Ironically, the bugs related to the router’s firmware update process, so the update actually patches the update system itself.
Trustwave found two vulnerabilities, dubbed CVE-2020-15498 and CVE-2020-15499, that could have allowed crooks to pull off a double-barrelled attack:
- A bogus firmware update wouldn’t have had any digital signature checking during download. In theory, crooks could advertise a fake update, or subvert a genuine one, and go undetected.
- Firmware updates could include release notes with JavaScript that your browser would run without warning. In theory, crooks wouldn’t even need a full-blown fake firmware download in order to launch an attack. A fake firmware update notice with booby-trapped JavaScript would be enough.
The first bug seems to have been a simple oversight – perhaps code added for testing that was never removed, or an insecure option left over from years ago that was never revisited and reviewed.
Simply put, the router – which runs Linux and standard Linux tools, like many IoT devices – used the well-known wget command utility to organise its downloads, and correctly used an HTTPS (secure) web link…
…but added the non-default command line option --no-check-certificate so that a download from a bogus site would not be detected.
As the wget documentation explains, this option tells the software:
Don’t check the server certificate against the available certificate authorities. Also don’t require the URL host name to match the common name presented by the certificate.
The second bug relied on what’s known as cross-site scripting.
That’s where a web server puts data that you originally provided, typically text, into a web page it sends back to you, but accidentally allows the text to include JavaScript commands.
In other words, by putting booby-trapped JavaScript in your release notes, you could provoke the server to include your script in a page that was served up under one of its own URLs.
Injecting JavaScript into a page that’s served up by someone else is basically as good as hacking their server and uploading your own JavaScript to it.
In both cases the JavaScript comes with the imprimatur of that server, and can therefore access any saved JavaScript resources – cookies, web storage and autentication tokens, for example, that are supposed to be private to that server.
What to do?
If you own an affected ASUS model, check your firmware version.
According to Trustwave, these bugs are fixed if your version is 3.0.0.4.385_20253 or later.
If you are a programmer, whether of IoT devices or anything else:
- Don’t take cryptographic shortcuts. A job worth doing is worth doing well. If you have gone to the trouble of using HTTPS in the first place, don’t turn off certificate checking just to get round a temporary problem or to save time while coding.
- Regularly review cryptographic code for outdated usage and settings. Even if you made an effort to get the cryptography right a few years ago, recommended settings and algorithm choices regularly get updated. As cryptographers like to say, “Attacks only ever get faster.”
- Validate all your inputs. Always watch out for booby-trapped input, for example strings that are too long, or that contain disallowed characters. Don’t give attackers the chance to trigger buffer overflows or to inject rogue commands into what is supposed to be plain data.