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.
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.
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.
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 22.214.171.124.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.