DAV EY WINDER
Davey casts light on malware attacks on IoT devices, advises on router hygiene, and reveals why your VPN may not be as secure as you think
Davey casts light on malware attacks on IoT devices, advises on router hygiene, and reveals why your VPN may not be as secure as you think.
“Turn it off and on again” is more than just a comedy catchphrase from every episode of The IT Crowd; it’s also a tool in the security bag. Take, for example, malware that hits Internet of Things devices and recruits them as unknowing workers, most often in a botnet. The design of most “things” is lean and cheap, with minimal complexity: there’s often no way to update firmware, even if a vulnerability has been discovered.
The only real option to get rid of malware, then, has been to “switch it off and on again”. But that’s hardly a silver bullet: the vast majority of IoT devices will never be rebooted unless there’s a power outage. Even if they were to be, reinfection would soon follow, unless the underlying weakness in security is identified and resolved.
Even so, you might think that the emergence of a new and persistent botnet is no big deal, but I’d argue the opposite. The evolution of the Hide and Seek (HNS) botnet is something we all need to worry about. Let me point you in the direction of the Q1 2018 Threat Landscape Report from Fortinet ( pcpro.link/288fort), which shows that 58% of botnet infections are a dead duck in less than 24 hours, and only 5% last longer than a week. Even the most infamous IoT malware family, Mirai, averages a bot lifespan of just five days.
From the moment HNS appeared in early 2018, it was obvious the actors behind it meant business. For a start, it was only the second botnet to employ a decentralised peer-to-peer architecture, and the first to use a custom-built one rather than using a BitTorrent-based system. Unlike many other IoT botnets, HNS doesn’t yet appear to be interested in recruiting devices for executing DDoS attacks. Instead, it has data exfiltration and code execution capabilities.
And then, it evolved – and evolved quickly. Within months, the HNS developers managed a second “first” in finding a way to bring persistence to the botnet party. HNS-infected devices would stay infected, stay part of the botnet, even after a reboot. How? Over to the security researchers at Bitdefender Labs ( pcpro.link/ 288bit) for the inside info: “Once the infection has been performed successfully, the malware copies itself in the /etc/init.d/ and adds itself to start with the operating system. In order to achieve persistence, the infection must take place via Telnet, as root privileges are required to copy the binary to the init.d directory.”
HNS also restricts access to port 23 once it has successfully brute-forced Telnet access, and it does this to prevent competing bots from doing the same. The good news is that HNS doesn’t yet appear to have executed a payload – or, to put it another way, it hasn’t been weaponised. Instead, it’s been busy expanding the number of devices it can reach, by using ten binaries compiled for various platforms and incorporating support for exploiting new vulnerabilities.
Apart from the data exfiltration capability that’s been there from the get-go, HNS now seems to have an attack capability that can be easily monetised. “Based on the evidence at hand, we presume that this botnet is in the growth phase,” Bitdefender Labs reckons, “as operators are trying to seize as many devices as possible before adding weaponised features to the binary.”
As already mentioned, older botnet families such as Mirai have “virtual persistence”, in that power-cycled devices tend to get reinfected in short order unless those vulnerabilities that were allowing it in the first place are resolved. So what should you be doing to mitigate the IoT botnet threat in general, and for Hide and Seek? Start with a network audit so you know what devices are on the network, and then disconnect those that aren’t necessary. It may sound obvious, but legacy kit, unauthorised user devices and the like aren’t rare sightings.
Once you’ve removed the baggage, change any default admin passwords, power-cycle all non-mission-critical devices, and install available firmware updates. Delving deeper into the HNS mitigation (worth doing, as you can bet your bottom dollar the bad guys have been watching what HNS is doing and will be copying it soon enough), disable Telnet logins for devices where you can.
Of all this advice, the single most important is to change the admin passwords of devices from the default, to something long and complex, so as to foil both brute force and dictionary attack modes.
Bad router hygiene
Talking of network connected devices, and as a great example of why security hygiene needs improving, the latest research from Avast threw up some numbers that certainly gel with my experience of the issues.
Researchers found that 51% of those asked had never logged into their router admin interface, and 72% hadn’t ever updated the firmware. Broadband Genie did a similar survey earlier this year and the numbers were equally disappointing: 86% hadn’t updated router firmware; 82% hadn’t changed the admin password; 70% hadn’t checked to see what devices were connected to the network; and 51% hadn’t done any of the above.
Home users are less likely than businesses to audit network devices, change admin passwords or update firmware. That snippet hasn’t come from research, but rather my own experiences. It’s understandable, because most consumers aren’t the slightest bit “technical”, nor are they interested in tweaking kit that they just assume will work out of the box.
By not making the security implications of admin defaults clear enough, vendors aren’t helping. While adding a “change admin password” step to the simple diagrammatical setup instructions would be helpful, it would also be a miracle. Inserting a “now change your password” requirement to open on first use, without which the device wouldn’t function properly – ditto.
Businesses at the smaller end of the scale, those without the resources for a dedicated IT team (or even an individual), don’t do any better. I’ve gone into so many such businesses over the years, where simple security measures would have prevented many of the problems they paid me to unravel. Problems, it has to be said, that are becoming increasingly prevalent with mass-scanning botnets that quickly discover and take control of poorly secured devices.
DNS settings
Something else that most people don’t ever change are DNS settings. The Domain Name System is one of few remaining real dark arts of the internet. It’s also, once again, one of those things for which the defaults remain untouched by the majority – from consumer to small business. Larger businesses with more complicated network needs are a different kettle of dedicated DNS fish, so this advice is aimed primarily at the small end of the business scale and the prosumer market.
I’m assuming most PC Pro readers will know what DNS does, so I won’t cover that in any more detail than to say it manages the human-machine translation between numerical IP addressing and alphabet-based URLs. Most of the time, using the ISPprovided DNS is fine and dandy. It’s the “some of the time” that you need to worry about, even if it means a one-off occurrence when your ISP DNS goes down for some reason.
That one-time event could cost you money if your business is disconnected for an hour, or longer, and even the prosumer will find stress levels rising if the internet is effectively down.
Aha, I hear you cry – this is the reason you have a primary and a secondary DNS configuration. If one fails then the other acts as an automatic failsafe to keep things working. Of course, both these will point at DNS operated by the same ISP by default, and there’s always the chance that it’s an ISP-wide problem, so both go down.
Rather than risk it, you can keep your primary DNS as the ISP default and change the secondary to another such as Google (8.8.8.8 or 8.8.4.4), Cloudflare (1.1.1.1) or OpenDNS (208.67.220.220 or 208.67.222.222), for example. That way, you have a viable “worse case scenario” backup.
DNS speed test
Steve Gibson over at GRC has a dedicated DNS speed test app ( pcpro. link/288dns) that Windows users can download for free; I understand it’s Wine compatible, if Mac users are interested in giving it a spin. It will compare your current DNS nameservers with a database of other known resolvers and display the results in terms of what it calls “characterisation”, which includes auditing redirection behaviours.
The beauty of this app is that it benchmarks the alternatives relative to your location at the time; geography has an impact upon DNS performance. There’s an option to automatically create a custom list of the top 50 fastest resolvers to be used as the comparison benchmark. However, unlike the default, this won’t be filtered for rogue and potentially suspect operators.
Switching your DNS to a different provider based purely on a “speed” indicator isn’t good practice, for obvious reasons. That said, I like that the testing is relatively quick and the presentation of the results flexible. You can get a written summary, in plain English, from the Conclusions tab, which includes how well your current nameservers responded and whether you should consider changing to an alternative. Want the full tabulated results? No problem, although the nameservers list display is far more readable as it can be sorted by response speed, name or owner.
Leaking VPN?
The GRC site used to have a DNS leak-test resource that could check if your VPN was actually “anonymising”
“By not making the security implications of admin defaults clear, vendors aren’t helping”
all traffic correctly or not. Actually, VPNs shouldn’t be seen as an anonymising service in the truest sense of the word, but rather one that keeps your traffic private – which is a different thing entirely. I say “used to” because the GRC test still appears to be there, but I couldn’t get it to work for me. Your mileage may vary, of course, so feel free to give it a go at
dnsleaktest.com. There’s an alternative at my-private-network.
co.uk (a VPN provider, but there’s no hard sell when using the test) that works in a similar way.
If your VPN service – and here I’m talking to those who use a service rather than have configured their own router-based VPN – is working properly then it should route all traffic, including DNS queries, via the VPN. This isn’t always the case, and system default DNS servers can sometimes be used even when a VPN service is running. This matters: you won’t realise that there’s a “DNS leak”, but threat attackers monitoring your traffic will be.
Once connected via the VPN you want to test, select the Thorough mode and hit Start. In around 30 seconds, the results will be displayed. In the results box you’ll see any DNS nameserver IPs that were used during the test. There should be only one IP, and it should be the same as the one displayed on the main page telling you the IP of your VPN connection. If you have more than one IP showing, or the IP doesn’t match, then you have a DNS leak and your VPN connection isn’t as private as you thought.