Turn it off and on again” is more than just a com­edy catch­phrase from ev­ery episode of The IT Crowd; it’s also a tool in the se­cu­rity bag. Take, for ex­am­ple, mal­ware that hits In­ter­net of Things de­vices and re­cruits them as un­know­ing work­ers, most of­ten in a botnet. The de­sign of most “things” is lean and cheap, with min­i­mal com­plex­ity: there’s of­ten no way to up­date

rmware, even if a vul­ner­a­bil­ity has been dis­cov­ered.

The only real op­tion to get rid of mal­ware, then, has been to “switch it off and on again”. But that’s hardly a sil­ver bul­let: the vast ma­jor­ity of IoT de­vices will never be re­booted un­less there’s a power out­age. Even if they were to be, re­in­fec­tion would soon fol­low, un­less the un­der­ly­ing weak­ness in se­cu­rity is identi ed and re­solved.

Even so, you might think that the emer­gence of a new and per­sis­tent botnet is no big deal, but I’d ar­gue the op­po­site. The evo­lu­tion of the Hide and Seek (HNS) botnet is some­thing we all need to worry about. Let me point you in the di­rec­tion of the Q1 2018 Threat Land­scape Re­port from Fortinet (pcpro.link/288fort), which shows that 58% of botnet in­fec­tions are a dead duck in less than 24 hours, and only 5% last longer than a week. Even the most in­fa­mous IoT mal­ware fam­ily, Mi­rai, av­er­ages a bot life­span of just ve days.

From the mo­ment HNS ap­peared in early 2018, it was ob­vi­ous the ac­tors be­hind it meant busi­ness. For a start, it was only the sec­ond botnet to em­ploy a de­cen­tralised peer-topeer ar­chi­tec­ture, and the rst to use a cus­tom-built one rather than us­ing a BitTor­rent-based sys­tem. Un­like many other IoT bot­nets, HNS doesn’t yet ap­pear to be in­ter­ested in re­cruit­ing de­vices for ex­e­cut­ing DDoS at­tacks. In­stead, it has data ex ltra­tion and code ex­e­cu­tion ca­pa­bil­i­ties.

And then, it evolved – and evolved quickly. Within months, the HNS de­vel­op­ers man­aged a sec­ond “rst” in nd­ing a way to bring per­sis­tence to the botnet party. HNS-in­fected de­vices would stay in­fected, stay part of the botnet, even af­ter a re­boot. How? Over to the se­cu­rity re­searchers at Bit­de­fender Labs (pcpro.link/ 288bit) for the in­side info: “Once the in­fec­tion has been per­formed suc­cess­fully, the mal­ware copies it­self in the /etc/ init.d/ and adds it­self to start with the op­er­at­ing sys­tem. In or­der to achieve per­sis­tence, the in­fec­tion must take place via Tel­net, as root priv­i­leges are re­quired to copy the bi­nary to the init.d di­rec­tory.”

HNS also re­stricts ac­cess to port 23 once it has suc­cess­fully brute­forced Tel­net ac­cess, and it does this to pre­vent com­pet­ing bots from do­ing the same. The good news is that HNS doesn’t yet ap­pear to have ex­e­cuted a pay­load – or, to put it an­other way, it hasn’t been weaponised. In­stead, it’s been busy ex­pand­ing the num­ber of de­vices it can reach, by us­ing ten bi­na­ries com­piled for var­i­ous plat­forms and in­cor­po­rat­ing sup­port for ex­ploit­ing new vul­ner­a­bil­i­ties.

Apart from the data ex ltra­tion ca­pa­bil­ity that’s been there from the get-go, HNS now seems to have an at­tack ca­pa­bil­ity that can be eas­ily mon­e­tised. “Based on the ev­i­dence at hand, we pre­sume that this botnet is in the growth phase,” Bit­de­fender Labs reck­ons, “as op­er­a­tors are try­ing to seize as many de­vices as pos­si­ble be­fore adding weaponised fea­tures to the bi­nary.”

As al­ready men­tioned, older botnet fam­i­lies such as Mi­rai have “vir­tual per­sis­tence”, in that power-cy­cled de­vices tend to get re­in­fected in short or­der un­less those vul­ner­a­bil­i­ties that were al­low­ing it in the rst place are re­solved. So what should you be do­ing to mit­i­gate the IoT botnet threat in gen­eral, and for Hide and Seek? Start with a net­work au­dit so you know what de­vices are on the net­work, and then dis­con­nect those that aren’t nec­es­sary. It may sound ob­vi­ous, but legacy kit, unau­tho­rised user de­vices and the like aren’t rare sight­ings.

Once you’ve re­moved the bag­gage, change any de­fault ad­min pass­words, power-cy­cle all non­mis­sion-crit­i­cal de­vices, and in­stall avail­able rmware up­dates. Delv­ing deeper into the HNS mit­i­ga­tion (worth do­ing, as you can bet your bot­tom dol­lar the bad guys have been watch­ing what HNS is do­ing and will be copy­ing it soon enough), dis­able Tel­net lo­gins for de­vices where you can.

Of all this ad­vice, the sin­gle most im­por­tant is to change the ad­min pass­words of de­vices from the de­fault, to some­thing long and com­plex, so as to foil both brute force and dic­tio­nary at­tack modes.


Talk­ing of net­work con­nected de­vices, and as a great ex­am­ple of why se­cu­rity hy­giene needs im­prov­ing, the lat­est re­search from Avast threw up some num­bers that cer­tainly gel with my ex­pe­ri­ence of the is­sues.

Re­searchers found that 51% of those asked had never logged into their router ad­min in­ter­face, and 72% hadn’t ever up­dated the

rmware. Broad­band Genie did a sim­i­lar sur­vey ear­lier this year and the num­bers were equally dis­ap­point­ing: 86% hadn’t up­dated router rmware; 82% hadn’t changed the ad­min pass­word; 70% hadn’t checked to see what de­vices were con­nected to the net­work; and 51% hadn’t done any of the above.

Home users are less likely than busi­nesses to au­dit net­work de­vices, change ad­min pass­words or up­date

rmware. That snip­pet hasn’t come from re­search, but rather my own ex­pe­ri­ences. It’s un­der­stand­able, be­cause most con­sumers aren’t the slight­est bit “tech­ni­cal”, nor are they in­ter­ested in tweak­ing kit that they just as­sume will work out of the box.

By not mak­ing the se­cu­rity im­pli­ca­tions of ad­min de­faults clear enough, vendors aren’t help­ing. While adding a “change ad­min pass­word” step to the sim­ple di­a­gram­mat­i­cal setup in­struc­tions would be help­ful, it would also be a mir­a­cle. In­sert­ing a “now change your pass­word” re­quire­ment to open on rst use, with­out which the de­vice wouldn’t func­tion prop­erly – ditto.

Busi­nesses at the smaller end of the scale, those with­out the re­sources for a ded­i­cated IT team (or even an in­di­vid­ual), don’t do any bet­ter. I’ve gone into so many such busi­nesses over the years, where sim­ple se­cu­rity mea­sures would have pre­vented many of the prob­lems they paid me to un­ravel. Prob­lems, it has to be said, that are be­com­ing in­creas­ingly preva­lent with mass-scan­ning bot­nets that quickly dis­cover and take con­trol of poorly se­cured de­vices.


Some­thing else that most peo­ple don’t ever change are DNS set­tings. The Do­main Name Sys­tem is one of few re­main­ing real dark arts of the in­ter­net. It’s also, once again, one of those things for which the de­faults re­main un­touched by the

Not a lot be­tween de­fault, Google’s or Cloud­flare’s DNS servers – so maybe use one of the lat­ter as a fail­safe?

ma­jor­ity – from con­sumer to small busi­ness. Larger busi­nesses with more com­pli­cated net­work needs are a dif­fer­ent ket­tle of ded­i­cated DNS sh, so this ad­vice is aimed pri­mar­ily at the small end of the busi­ness scale and the pro­sumer mar­ket.

I’m as­sum­ing most PCTA read­ers will know what DNS does, so I won’t cover that in any more de­tail than to say it man­ages the hu­man-ma­chine trans­la­tion be­tween nu­mer­i­cal IP ad­dress­ing and al­pha­bet-based URLs. Most of the time, us­ing the ISPpro­vided DNS is ne and dandy. It’s the “some of the time” that you need to worry about, even if it means a one-off oc­cur­rence when your ISP DNS goes down for some rea­son.

That one-time event could cost you money if your busi­ness is dis­con­nected for an hour, or longer, and even the pro­sumer will nd stress lev­els ris­ing if the in­ter­net is ef­fec­tively down.

Aha, I hear you cry – this is the rea­son you have a pri­mary and a sec­ondary DNS con gu­ra­tion. If one fails then the other acts as an au­to­matic fail­safe to keep things work­ing. Of course, both these will point at DNS op­er­ated by the same ISP by de­fault, and there’s al­ways the chance that it’s an ISP-wide prob­lem, so both go down.

Rather than risk it, you can keep your pri­mary DNS as the ISP de­fault and change the sec­ondary to an­other such as Google ( or, Cloud are ( or OpenDNS ( or, for ex­am­ple. That way, you have a vi­able “worse case sce­nario” backup.


Steve Gib­son over at GRC has a ded­i­cated DNS speed test app (www.grc.com/dns/bench­mark. htm) that Win­dows users can down­load for free; I un­der­stand it’s Wine com­pat­i­ble, if Mac users are in­ter­ested in giv­ing it a spin. It will com­pare your cur­rent DNS name­servers with a data­base of other known re­solvers and dis­play the re­sults in terms of what it calls “char­ac­ter­i­sa­tion”, which in­cludes au­dit­ing re­di­rect­ion be­hav­iours.

The beauty of this app is that it bench­marks the al­ter­na­tives rel­a­tive to your lo­ca­tion at the time; ge­og­ra­phy has an im­pact upon DNS per­for­mance. There’s an op­tion to au­to­mat­i­cally cre­ate a cus­tom list of the top 50 fastest re­solvers to be used as the com­par­i­son bench­mark. How­ever, un­like the de­fault, this won’t be ltered for rogue and po­ten­tially sus­pect op­er­a­tors.

Switch­ing your DNS to a dif­fer­ent provider based purely on a “speed” in­di­ca­tor isn’t good prac­tice, for ob­vi­ous rea­sons. That said, I like that the test­ing is rel­a­tively quick and the pre­sen­ta­tion of the re­sults

ex­i­ble. You can get a writ­ten

“By not mak­ing the se­cu­rity im­pli­ca­tions of ad­min de­faults clear, vendors aren’t help­ing”

sum­mary, in plain English, from the Con­clu­sions tab, which in­cludes how well your cur­rent name­servers re­sponded and whether you should con­sider chang­ing to an al­ter­na­tive. Want the full tab­u­lated re­sults? No prob­lem, al­though the name­servers list dis­play is far more read­able as it can be sorted by re­sponse speed, name or owner.


The GRC site used to have a DNS leak-test re­source that could check if your VPN was ac­tu­ally “anonymis­ing” all traf c cor­rectly or not. Ac­tu­ally, VPNs shouldn’t be seen as an anonymis­ing ser­vice in the truest sense of the word, but rather one that keeps your traf c pri­vate – which is a dif­fer­ent thing en­tirely. I say “used to” be­cause the GRC test still ap­pears 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 dnsleak­test.com. There’s an al­ter­na­tive at my-pri­vate-net­work. co.uk (a VPN provider, but there’s no hard sell when us­ing the test) that works in a sim­i­lar way.

If your VPN ser­vice – and here I’m talk­ing to those who use a ser­vice rather than have con gured their own router-based VPN – is work­ing prop­erly then it should route all traf c, in­clud­ing DNS queries, via the VPN. This isn’t al­ways the case, and sys­tem de­fault DNS servers can some­times be used even when a VPN ser­vice is run­ning. You won’t re­alise that there’s a “DNS leak”, but threat at­tack­ers mon­i­tor­ing your traf c will be.

Once con­nected via the VPN you want to test, se­lect the Thor­ough mode and hit Start. In around 30 sec­onds, the re­sults will be dis­played. In the re­sults box you’ll see any DNS name­server IPs that were used dur­ing the test. There should be only one IP, and it should be the same as the one dis­played on the main page telling you the IP of your VPN con­nec­tion. If you have more than one IP show­ing, or the IP doesn’t match, then you have a DNS leak and your VPN con­nec­tion isn’t as pri­vate as you thought. ◆

Cloud­flare in­tro­duced the free DNS ser­vice on 1 April, but it’s no joke

DAVEY WIN­DER is an award­win­ning jour­nal­ist and con­sul­tant spe­cial­is­ing in pri­vacy and se­cu­rity is­sues

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.