DAV EY WINDER
Smaller businesses should be particularly scared of the next round of ransomware attacks, plus Davey reveals why he’s going to switch banks
Smaller businesses should be particularly scared of the next round of ransomware attacks, plus Davey reveals why he’s going to switch banks.
It’s been more than a year now since the No More Ransom initiative ( nomoreransom.org) was launched by the Dutch National Police and Europol, alongside security vendors Kaspersky Lab and McAfee. This was well before the WannaCry and not Petya ransomware attacks – which begs the question: when it comes to such projects, how should we measure success?
Well, if you look at the numbers without taking WannaCry or not Petya into account, you’d say that the initiative isn’t making much of a difference. Figures released by Kaspersky Lab in June 2017 show that ransomware has continued to grow as a threat. The total number of users encountering ransomware, just within the remit of this one vendor report, grew by more than 11% during April 2016 to March 2017 versus the previous year.
So, is the No More Ransom project a busted flush when exposed to the harsh light of those ever climbing infection rates? I don’t think so. In fact, I think it would be unfair to jump to such a conclusion given that it now makes more than 50 ransomware decryption tools available for use, covering more than 100 ransomware families. At the time of writing, those tools have helped decrypt more than 28,000 devices. Not only that, but the Crypto Sheriff tool makes identifying ransomware variants from encrypted files and ransom demand texts easy-peasy – for anyone.
Indeed, I continue to point those who contact me about a ransomware infection to the No More Ransom site as a first port of call. It depends on the ransomware family, and variant, but the available decryption tools can and do prevent ransoms being paid; official numbers put the non-paid ransoms at £6.5 million. That said, basic security hygiene and an understanding of what business continuity and disaster recovery really mean combine to make for even better preventative medicine. More of that in a moment.
First, an interesting trend is revealed by a Kaspersky Security Network analysis of the year up to March 2017: the growth in Ransomware-as-a-Service (RaaS). Petya is perhaps the best-known example of malware using the RaaS threat model, whereby it’s distributed by multiple actors using an ondemand process.
The operators of this malicious service take a percentage of all ransoms paid. The monetisation model is key, leading to various technical protections being inserted into the malware code to prevent “no honour amongst thieves” pirating of the samples.
Petya proved so successful that it has driven RaaS forward as the ransomware propagation model of choice. Hardly surprising given that it enables criminals with coding kudos to make money from the more populous wannabes who don’t have the skill or resources to develop their own attacks.
RaaS isn’t the only trend this analysis spotted; targeted attacks against businesses are also on the up. Historically, most cases of organisations getting caught by ransomware are generally about collateral damage. The malware bait had been distributed in a scattergun fashion to hundreds of thousands, if not millions, of random email addresses. Some inadvertently led to enterprises. The clue has always been the small ransom amounts asked for, relative to the size of business.
But early in 2017, Kaspersky Lab researchers noticed an uptick of attacks primarily focused on financial organisations. How does it know these aren’t just more unfortunate bystanders? The ransoms have been as high as half-a-million dollars, and vary according to the victim organisation concerned.
I fully expect more actors to get in on this activity, and most likely by spotting the gap in the market: small to medium-sized business. Why? Well, larger organisations, especially those in the financial sector, are geared up to defend against attack. Everything from the initial attack vector through to disaster recovery plans make it hard for an attacker to hit pay dirt. That picture changes dramatically as you move down the enterprise scale, with those towards the smaller end being least prepared in terms of defence and response.
This can be down to a lack of technical knowledge needed to deal with the threat, but in my experience it’s more often a little of that combined with a lack of budget to throw at the solution. Hardly surprising, then, that many choose to pay a ransom of a few hundred pounds to get the business back up and running as soon as possible. According to the Malwarebytes’ international ransomware study published this summer, UK firms are the most likely to pay a ransom – and least confident in their ability to defend against an attack. The actual figures suggest 49% of UK business would pay the ransom asked compared to 42% globally.
The trouble is that paying a ransom and getting your data back aren’t guaranteed bedfellows. Far better to invest that cash – before disaster strikes – in
“I continue to point those who contact me about a ransomware infection to the No More Ransom site ”
“What drives people away from a service isn’t 2FA, but their account getting hacked”
a solid data backup and recovery system that acts as your “get out of jail free” card. Not only do cloud services make this easy for smaller business, they’re also cheap enough to build in some redundancy through a second service as a backup to your backup. Having a clean VM in the cloud somewhere that can be used to restore your business in a matter of minutes is a compelling financial argument. Couple this with a vulnerability scanning and patching strategy, which again needn’t be stupid-expensive nor stupid-complicated, and you have most bases covered.
Getting 2FA right – and oh-so wrong
As regular readers will know, I’m a big fan of two-factor authentication (2FA), which adds a secondary layer of access security to your online accounts. The reason I’m bringing up 2FA once more is less about banging on about how it should be a vital part of your security positioning, and more to do with how 2FA management can seriously impact user acceptance.
I already deal with people who argue that introducing an additional security layer that complicates the login process is counter-productive, driving people away from a service. My response is always the same: what drives people away from a service is their account getting hacked. So, what specifically am I talking about here then? The answer, dear reader, is HMRC.
Like many folk, I’m trapped within a smartphone update cycle. Be it forced upon me by a network contract, or by the arrival of a model I simply have to have, upgrading is a yearly event. One of the downsides of this, especially when dealing with service providers such as HMRC, which insist on sending one-time codes for 2FA by SMS rather than allowing the use of an authenticator app, is changing your number.
I’ve had the same couple of numbers for some years, preferring to buy SIM-free handsets and keep my network provider separate from that decision-making process. This year, I decided the time was right to consolidate the number of handsets I have. This included changing network, since the handset I wanted to pre-order was available on a good deal with a different provider. It also gave me the chance to change my number, something I like to do every few years anyway.
Unlike the majority, some might say that I’m security savvy to the point of obsession. So when it comes to smartphones and 2FA, I always ensure I have a month of overlap between old and new numbers to enable a smooth transition for all accounts protected in this way. Or at least that’s the theory; HMRC shows that practice can be altogether different territory.
Here’s the security scenario. I’m logged into my HMRC account using the existing telephone number to receive the one-time 2FA code, and thus verify my identity. You might think that as a verified user, whose identity has been validated enough to allow me to access the account, I’d be able to head to the security settings and update the mobile number for 2FA purposes. You’d be wrong. HMRC insists that you have to make a phone call, with all the waiting and woe that entails, to change a 2FA mobile number. This means jumping through all the security hoops on the phone – because I could be anyone calling – to reset it.
And there’s the thing: a social engineer with the correct information could easily fool HMRC into making the number change assuming they had some basic information about the account holder. It would have been far more secure to allow the already-validated account holder to change the number online. I’d like to think that HMRC will realise this and change the system.
I’m happy to say that not everyone gets 2FA security management so wrong. Take Box, the cloud storage firm. That I couldn’t change my 2FA number was, this time, my own fault. I’m not a regular Box user but do have an account for test purposes. I had forgotten it had 2FA enabled when I swapped phones, and my existing number had long since (three months) been consigned back into the network provider pool.
The only online option to change my 2FA number was to submit a one-time code, sent – you’ve guessed it – to my old number. The online support was only available to me as a logged-in user, something I couldn’t do as I couldn’t complete the 2FA requirement. A case of good security and a little bit of bad thinking on the support front, mixed together. I managed to find an email address to cancel accounts, so I sent a message explaining my situation and asking either for help with resetting my 2FA or to delete my account and any files within it. To the credit of Box, this was forwarded to the tech support people, who then contacted me.
Sherwin, the support guy, says “We’ll be glad to temporarily disable the two-factor feature in your account. For security purposes, in order to authorise your request to disable 2FA for your Box account, I’ll need you to please confirm the specific names of a few files and/or folders that are in this Box account and the phone number that you currently have set up with twostep verification.”
Now that is good support, since it’s offering to do what I need but without compromising the security of the account. A hacker would have to know an awful lot to be able to socially engineer this guy. My old telephone number used for 2FA, possibly; specific file names of stuff uploaded to this Box account with full path data, almost certainly not. I did, and was able to confirm a bunch of
filenames along with their full paths. My 2FA was disabled, meaning I could then log in and go through the enablement process again with my new phone.
If you thought that was enough about 2FA – sorry, I have more. Again, this was long after the old number had been discontinued, as I needed to reset my Android Pay setting and start again for reasons I won’t bore you with. One of my banks wanted to send me a verification code to confirm it was me, before adding a debit card to the mix. The only trouble being that the number it wanted to send it to was a four-year-old one.
Another telephone call ensued, during which I answered all the security questions to the satisfaction of the support person. The card was verified for use with Android Pay – so far, so good. Then I asked them to change the telephone number and also the reason they were using that one anyway. The conversation quickly became very weird. Apparently, they couldn’t change it over the phone for security reasons. This, despite just validating a card for use with Android Pay and so, one assumes, being happy that I was who I said I was. Worse, they said I should change it online using my internet banking account.
I tried explaining that I had done many years ago, and most recently a few months prior when I changed number again. They insisted it hadn’t been changed and the number concerned was the only one on the system. Which is odd, said I, as I was receiving weekly balance update texts from the bank on my new number.
In the end, I have written a rather severe letter to the bank insisting it changes that number on whatever disparate one of its systems on which it lives, and explain why it’s exposed me to such a security risk for so many years. The security risk being, in case you’re wondering, that old mobile numbers don’t die but are resurrected in the network pool and handed out to new customers. So that’s someone else who could be receiving data about my bank account by text.
At the time of writing, I haven’t heard back from my soon to be ex-bank…