Tag Archives: Aryeh Goretsky

Untangling the Web

I was away when this series of articles on ESET’s WeLiveSecurity blog was published, and in fact for quite a few days afterwards, so I didn’t do much to flag it at the time, but I think it was quite interesting.

ESET’s Tomáš Foltýn contacted a handful of us who’ve been in the security business a long, long time, and asked us some questions related to the recent 27th anniversary of the World Wide Web, publicly announced by Tim Berners-Lee on the 6th August 1991. In fact, he asked a wide range of questions relating to the web past, present and future.

I, for one, have never been one to resist the opportunity to share the benefit of my prejudices, so my responses can be found in the first article in the series here: Interviewing ESET’s experts about the Web’s journey so far – part 1.

For part two in the series, Tomáš talked to Cameron Camp, who focused less on the historical aspects of the Web and more on the clear and present dangers. And finally, he talked to Aryeh Goretsky, who was already working in the antivirus industry in 1991.

(Oddly enough, one of my jobs in the early 90s was coding some primitive programs to supplement a basic AV scanner in use at that time in my workplace, but wasn’t assimilated into the industry until 2006 or thereabouts. In small steps, admittedly, but resistance turned out to be futile. Ironically, I’ve never been involved with program development at ESET.)

David Harley


Sextortion & leaked passwords revisited

A rather different type of extortion, originally published on Chainmailcheck, but reproduced here with some additional commentary.

Here’s an interesting article by Brian Krebs: Sextortion Scam Uses Recipient’s Hacked Passwords

The scammer claims to have made a video of the intended victim watching porn, and threatens to send it to their friends unless payment is made. Not particularly novel: the twist with this one is that it “references a real password previously tied to the recipient’s email address.” Krebs suggests that the scammer is using a script to extract passwords and usernames from a known data breach from at least ten years ago.

The giveaway is that very few people are likely to be using the same password now – and it’s unlikely that there are that many people receiving the email who might think that such a video could have been made. Still, it seems that some people have actually paid up, and it’s possible that a more convincing attack might be made sending a more recent password to a given email address, and perhaps using a different type of leverage.

[Commentary from Sophos here.]

Additional commentary from me since the Chainmailcheck article:

In a related *thread on Reddit, one comment indicated that there have also been attempts to log on to accounts associated with the same user using the leaked password, which I’d say amounts to a good reason for:

(a) Not using the same password across multiple accounts in general (though some people use a ‘throwaway’ password on ‘throwaway’ accounts where a later breach wouldn’t actually matter).

(b) Checking other accounts where you might have duplicated a password. It’s perfectly possible in such a case that the password is no longer current on the email account where the extortion mail was received, but not on other accounts, perhaps used less often.

One slightly disturbing feature of that Reddit thread is that it was sparked by an extortionate email to an admin account where the password given by the scammer was still current. Fortunately, the company concerned seems to have taken appropriate actions on seeing the email, but it’s a salutary reminder that administrators are not always any better at routine security measures than the rest of us.

*Hat tip to ESET’s Aryeh Goretsky for bringing it to my attention.

David Harley

Backup, PR Pressure and Ransomware

I recently received a spate of emails from a PR person suggesting that I add Lee Munson’s article on The history of ransomware to the AVIEN ransomware resources pages. I nearly ignored it altogether because  I don’t respond well to PR pressure. It’s one of the few things I have in common with career journalists…

Backup: the Why and How

However, the article is a reasonable introductory guide and offers a brief history that includes some (but by no means all) ransomware families and some reasonable advice, so I’m OK with including it, here. That said, while I agree that backups are an essential precaution (and not only because of the risk of a ransomware attack), he misses an essential point. Of course it’s ‘preferable’ to have offsite backups in case of ‘the risks of a fire etc. in your own home’, but many people and organizations nowadays don’t think first in terms of physical media like optical disks and flash storage, but rather in terms of some form of cloud storage. Which are very likely to be offsite, of course.

Offsite versus Offline

However, where such storage is ‘always on’, its contents may be vulnerable to compromise by ransomware in the same way that local storage is, so it’s important that offsite storage:

  • Is not routinely and permanently online
  • Protects backed-up data from automatic and silent modification or overwriting by malware when the remote facility is online
  • Protects earlier generations of backed-up data from compromise so that even if disaster strikes the very latest backups, you can at least retrieve some data, including earlier versions of current data.

Most articles on backup aimed at home users don’t go deeply into backup strategies, especially as utilized by system administrators, and that’s a gap I’m considering trying to fill. (However, Aryeh Goretsky’s article for ESET, Options for backing up your computer, is a good summary for home users, even though it’s several years old.)

Making the Cloud less Nebulous

For the moment it’s worth remembering that backup isn’t a fire-and-forget one-time exercise, but an ongoing task. Furthermore, the last thing you want to do is rely on a single generation of backups on a single site, or using a single provider. Bear in mind also that when cloud providers offer versioning, when backup of a file is triggered when it is modified, it may or may not mean that (one or more) earlier generations of the same file are preserved. It may be more convenient to keep only the latest version of a document, thus saving both space and the potential hassles of version control. But it makes sense to have a generational strategy in place so that you can, if necessary, roll back to a previous version and build on that. It makes even more sense to have read-only versions in reserve, for obvious reasons.

David Harley

Unlucky 7ev3n: greedy ransomware and how to avoid it

Bob Covello posted an interesting article on Graham Cluley’s site on The new economics of data protection in a world of ransomware. He cites the case of 7ev3n, a more-than-usually greedy instance of ransomware demanding a hefty 13 bitcoins for the key to your encrypted data. Which is very much in contrast, by the way, to the £350 apparently demanded by the attackers who caused Lincolnshire council to shut down their systems for a few days, though the BBC reported the ransom demand as being for a heart-stopping£1m. A subsequent report by the BBC  not only cited the lower figure, but asserted that the council had announced that it would not pay the ransom. It’s by no means impossible that demands will continue to rise if and when ransomware gangs get more into the idea of extorting businesses rather than (or at any rate as well as) individuals who may simply not be able to afford such sums. Come to that, a business may be less able to write off its data than an individual who may simply decide that his or her data is not worth paying so much for.

The core message of Covello’s article is simple enough. Even the most expensive backup and cloning options he cites look much more attractive than paying an estimated $5,000 in the hope of having the 7ev3n gang restore your data.

I wouldn’t agree with Marcin Kleczynski that

Even using backup systems isn’t an effective countermeasure because ransomware would actively look for different types of backup systems and encrypt them, too.

Nevertheless, it is worth remembering that ransomware does look for external storage and encrypt what it finds there, if possible. So you need to bear in mind:

  • While external storage is connected, data stored there may be as vulnerable as data on your internal drives. Storage that is only connected when you need it to be is obviously safer than an always-on network or cloud drive. And don’t discount the value of backups of backups. This paper by my colleague Aryeh Goretsky is several years old and so predates the current upsurge in ransomware, but it does address the backup basics very clearly, and they haven’t changed much: Options for backing up your computer
  • If you do have to restore from backup, you need to be sure that the malware is no longer on your system. (Part of the value of cloning.)

David Harley

Who Will Educate the Educators?

@vmyths, otherwise known as Rob Rosenberger, notes on Twitter that

“3doz firms THAT EMPLOY COMPUTER SECURITY EXPERTS got whacked in a zero-day attack. How about some “education” for THEM, eh?”

Well, “computer security experts” is a somewhat fuzzy term, and a little pejorative: when the media use it, they usually mean themselves, or the company that supplied the press release they’re recycling. When they actually mean computer security professionals, it’s usually in the sense of “so-called security experts who can’t see what is absolutely clear to any right-thinking journalists.” A somewhat similar mindset, perhaps, to those denizens of Security-Basics who believe that anyone who has letters after his name has to be a blithering idiot with no actual security experience. No, I’m not getting into that argument again…

But let’s assume that Rob means the same group that I probably would, if I couldn’t avoid using the term: information security professionals not necessarily working within the security industry. (I know there sometimes seems to be far too many of us who are in the industry, but most of us are OK, honestly.)

A group, in fact, rather like the subscribers to the first incarnation of AVIEN: people with a wide range of job titles, skill sets and responsibilities, from independent researchers to experienced managers and system administrators to people who suddenly found themselves landed with (some) security responsibility for their company. (Yeah, me too…)

Well, it’s true: if you’re going to make people responsible for security, you do need to ensure that they already have some experience and training, or that they at least receive some training to jumpstart them into the role. Especially if, like me, you believe that part of the security professional role is to take some responsibility for the education of others. (Yes, I know that there’s a sizeable section of the security community that believes there’s no mileage in trying to educate the end-user – http://www.eset.com/download/whitepapers/People_Patching.pdf – but I’m not getting into that argument right now, either.

Before we start blaming everything (yet again) on lazy, incompetent, uneducated security experts though (and hopefully that isn’t what Rob meant), let’s remind ourselves of a few pertinent facts.

  • As my colleague Aryeh Goretsky has pointed out, banks with security guards are not immune to bank robberies. “Mitigation of risk != elimination in its entirety.”
  • When a company hires security professionals, it doesn’t necessarily mean it listens to those professionals. Especially when listening to their advice entails spending significant sums that could be better spent on upgrading the catering on the Executive floor.
  • The corollary to assuming that employing security professionals (even competent individuals with exemplary support from the Boardroom) is enough to eliminate risk, is that if some malicious actor does get through, someone has “failed” and needs to be fired. That’s just lazy thinking: not so different to giving the bank janitor a uniform, a revolver and six shells, and saying “Hey, you’re promoted: now our asses are covered.”

Let’s not forget Spaf’s first principle of security administration:

If you have responsibility for security, but have no authority to set rules or punish violators, your own role in the organization is to take the blame when something big goes wrong.

That observation by Professor Eugene Spafford is as accurate now as it was when I first read it nearly twenty years ago…

David Harley [Formerly FBCS CITP CISSP]
ESET Senior Research Fellow