LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point. You can also listen directly on Soundcloud.
With Doug Aamoth and Paul Ducklin.
Intro and outro music by Edith Mudge.
You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.
READ THE TRANSCRIPT
DOUG AAMOTH. Romance, scams, bugs, worms and REvil ransomware.
All that and more on the Naked Security Podcast.
[MUSICAL MODEM]
Welcome to the podcast, everybody.
I am Doug; he is Paul…
PAUL DUCKLIN. Well done, Doug… right way round this week!
DOUG. Why, thank you! Last week I got mixed up…
DUCK. You didn’t confuse yourself.
DOUG. But it took 65 episodes for me to make that mistake, so I’m pretty proud of myself.
It might happen again, but…
DUCK. That’s right: we’re on Route 66 today!
DOUG. We are.
DUCK. That’s quite a big deal, Doug.
DOUG. Yes.
And just like Route 66, we have a lot of attractions to look at this week – a full docket.
DUCK. [LAUGHS AT SEGUE] I love your work!
DOUG. We do like to start the show with a Fun Fact.
And usually the fun fact is related to the This Week in Tech History segment.
Not this week, though, because it’s been very cold here and a lot of people have been wearing winter hats. I was looking at a group of people and I thought, “What are those pom-poms on the top of the hats? Where did that come from?”
So I looked it up, and if you ever wonder why some winter hats have those fluffy pom-poms on top, apparently they were worn by French sailors in the olden days to protect their heads from banging against the low ceilings of ships while out at sea.
They were especially effective in rough waters.
So if you have a pom-pom on the top of your hat, you have a French sailor to thank for it.
DUCK. Oh, so it was actually padding?
DOUG. Yes.
I have a very low ceiling in our basement and laundry room, so maybe I’ll go put a pom-pom hat on and walk around and see if it helps, because I hit my head quite a bit.
DUCK. You could just duct tape a mouse mat… you know, put it on top of your head and duct tape it under your chin.
DOUG. [LAUGHS] I don’t know if they had neoprene back in those days, but it’s a good idea.
Well, let’s talk about… we’ve got a lot of stories to cover.
The first one: we have effectively ended ransomware with the alleged bust of the REvil ransomware crew in Russia.
[SARCASTIC] It’s the end of ransomware as we know it, right?
DUCK. Well, even the Federal Security Bureau of Russia, the FSB, didn’t actually say that, though they did actually do a bust.
There’s been a lot of criticism in the past…
…Russians, I think, like the Germans and French, and a whole load of countries, don’t extradite their own citizens. So, if you want to get people in those countries prosecuted for crimes they committed against another country, you basically have to provide the country with the evidence it needs.
And there’s a lot of criticism that Russia didn’t seem very willing to do that.
In this case, it looks like they were: apparently, 25 street addresses got raided in a variety of different cities.
They mentioned 14 people being targeted, though they don’t say how many of those ultimately got arrested.
But there were some arrests; plus 20 fancy cars towed away, apparently bought with the proceeds of crime. And as we’ve said before, there’s probably a bunch of forensic data in the average fancy car these days, in terms of the entertainment system, satnav, phones built into the car and all that sort of stuff.
And they got something like $6,000,000 to $7,000,000 in rubles, US dollars, euros and cryptocoins.
So the FSB was quite bullish about what it had achieved, stating that, as a result of the raid, “this cyber gang ceased to exist and its criminal infrastructure was neutralized.” So, that’s REvil.
They didn’t say, ” It’s the end of ransomware as we know it,” because obviously it isn’t.
There are two problems, even if REvil really has sunk without a trace now: [a] there are plenty of other ransomware gangs where REvil came from; and [b], sadly, there are plenty of other types of cybercrime involving crooks that have little no interest in ransomware, but are still capable of doing plenty of evil, albeit that they’re not REvil.
DOUG. Yes, Sir!
But a step in the right direction nonetheless?
DUCK. Yes, I don’t think we can complain!
But it’s still all about: patch early, patch often; don’t let your guard down; prevention is better than cure; and invest in your users.
DOUG. We’ve got more advice in our State of Ransomware 2021 report, which is linked to in the article called REvil Ransomware crew allegedly busted in Russia, says FSB on nakedsecurity.sophos.com.
Let’s just shimmy right along to another bust: a romance scammer who targeted almost 700 women has gotten 28 months in jail.
DUCK. As the National Crime Agency of the UK point out, in respect of romance scams in general, they say, “We want to encourage all those who think they’ve been a victim of romance fraud to not feel embarrassed or ashamed, but please report it.”
The National Crime Agency can’t make a case where somebody hasn’t told them, “Hey, I sent money to this person and I now think I shouldn’t have,” because if they insist that they sent the money willingly, and they don’t consider that they were defrauded, then I guess fraud hasn’t happened.
And that’s the problem with a cybercrime like this.
DOUG. Yes, we do have one heartbreaking comment on the article, and another uplifting comment at the very end.
One of our readers thinks his mom is being scammed, and she’s not reacting well to her family trying to talk her out of it; and then we have another one where they caught a scammer red-handed, which was kind of an interesting story.
DUCK. Unfortunately, these crimes don’t just leave people brokenhearted and destitute. They can also leave you with a giant rift in your family circle.
That guy said, “My mom quit talking to me because I don’t believe this is the love of her life.”
The only advice we can really give is that if you have even an inkling that you might be in a scam, no matter how heart-rending it’s going to be to have to admit that, don’t “show the hand” to your friends and family if they’re trying to warn you.
They might be wrong, but they could very, very well be right… so give them a fair hearing.
DOUG. OK, we’ve got advice in the article, and a helpful video called Romance Scams: What to do?.
We talked about listening to your friends and family if they try to warn you; we also have things like: consider reporting it to the police; don’t blame yourself if you get reeled in; look for a support group; and most importantly, get out as soon as you realize it’s a scam.
DUCK. Yes, my advice there, very particularly, is: don’t say to the scammer, “Oh, I’m beginning to suspect you. I’ll give you one last chance to prove yourself.”
Remember, if they are a scammer, they’ve already reeled you in this far.
Do you think they’re going to have too much trouble with one little objection that you’re bringing now?
If you’ve decided it’s a scam, don’t tell them – just cut contact and then go and look for a local support group.
And, by the way, be very careful, if you break off connection with the scammers, if you suddenly get contacted by somebody claiming to represent a support group, or law enforcement, or a company that can help you get your scammed money back.
Because that is the classic “counter-scam”.
When the crooks realize you really have decided they’re scammers, then they come in trying to pretend to be the antiscammers!
There are numerous cases of people getting scammed twice. If you’re going to withdraw from a scam, only deal with people you actually know, and can meet, and that you can trust face to face.
Don’t just take help from anyone who comes up offering it online – it could be the scammers coming back.
DOUG. [SAD] Wonderful. The joys of human behaviour.
That is Romance scammer who targeted 670 women gets 28 months in jail on nakedsecurity.sophos.com.
We shift from human worms to Windows worms: a wormable Windows HTTP hole.
What do we need to know about this, Paul?
DUCK. This was a fascinating start to 2022, wasn’t it? It was one of the many security bugs fixed in this month’s patch Tuesday…
DOUG. That was a big one!
DUCK. I think there were 102 bugs!
But one of them didn’t seem too harmful at first, perhaps because it didn’t say, “This bug is in the Microsoft web server that everyone knows.”
It was just described as HTTP protocol stack remote code execution vulnerability, or CVE-2022-21907.
So you kind of think, “Oh, it’s some low level code thing; probably doesn’t apply to me, because I’m not running IIS.”
And in that sense, it was a little bit like the trouble we had with Log4j, where everyone said, “I don’t have any Java servers.”
And we said: no, it’s not about servers; it’s about apps that are written in Java.
“I don’t have many of those…” Are you sure?
“Well, I do have some of them, but not many of them run Log4j…” Are you sure?
And then, as we’ve said on a couple of previous podcasts, when people would go looking for Lg4j, they’d find, “Golly, there’s a lot more of it than I thought.”
The problem here is very similar, namely that HTTP.sys is a low level driver that provides HTTP services for when you need a program that will accept and answer web requests, *including IIS*.
In fact, IIS is implemented on top of this HTTP.sys, but it’s just one of dozens, or hundreds, or thousands of applications you could have that might use this thing.
Any program you have, whether you realizs it or not, that contains some kind of web console, or web interface, or web port you can connect to, could be at risk of this bug if you haven’t patched.
And what got everyone excited is, as Microsoft said in their Frequently Asked Questions list for this particular patch, “Is this wormable?”, meaning could somebody use it to write a self-spreading virus…
DOUG. Yes!
DUCK. They really did just put that one word!
DOUG. [LAUGHS] “Yes. Full stop.”
DUCK. And they said, “Microsoft recommends prioritising the patching of affected servers.”
Now, my opinion is that the wording of that was somewhat unfortunate, because it leads you to infer that this only affects servers. Where else would you have an HTTP service listening than on a server?
Of course, the answer is: loads and loads of programs these days use HTTP as their GUI, as their interface, don’t they? Many have a web console, even if they’re programs designed for an end user.
The bug is a function of a low-level driver in Windows itself, and that’s what needs to be patched.
I guess the good-news part of that is, once you’ve done this patch, every program that depends on HTTP.sys is implicitly patched along with it because they all rely on the same low-level driver.
DOUG. Okay, what… playing Devil’s advocate. What should I do if I’m not able to patch right away for some reason?
DUCK. I came up with a fix which worked in my limited testing. Very simple.
You just go into your registry (we’ve got a script on Naked Security that shows you how to do this), and you change what’s called the “start code” for the HTTP Windows service from the value 3, which means start when needed, to the value 4.
You just have to know that 4 means disabled; can’t start.
And that essentially fixes this problem, because no software can actually fire up this driver, therefore nothing can actually use it, therefore the bug can’t be tickled.
The flipside of that is no software can use this HTTP service, so if it turns out that you *do* have an app where, without you realising it, part of its administration relies on a web-based console or a web based API… then that’s not going to work either.
So this is not a permanent solution; it’s just a workaround.
You ultimately need to fix this HTTP.sys file as part of the Patch Tuesday update.
DOUG. OK, that is Wormable Windows HTTP hole – what you need to know on nakedsecurity.sophos.com.
Now, it’s time for This Week in Tech History.
Lest you think we’d only talk about worms once in this episode… this week, on 20 January 1999, the world was introduced to the HAPPY99 worm, also known as Ska or Iworm. HAPPY99 was reported by several anti-virus vendors to be a pretty big pain in the neck.
DUCK. Believe me, it was jolly huge.
And it had a trick that you will grudgingly like, Doug.
The crooks did what you call the “B thing”: best/brilliant.
They avoided making spelling mistakes or typos or writing bad English.
They avoided all those problems simply by having no text.
DOUG. Aaargh.
DUCK. Brilliantly simple, isn’t it?
DOUG. Arrrrrgh!
DUCK. If you have zero characters, then you must, ipso facto, have zero spelling mistakes, typos, grammos, et cetera.
It simply arrived; it was an executable; it said HAPPY99.EXE; and if you ran it, it showed you a little fireworks display.
DOUG. [DOWNCAST] Yes, indeed.
All right, well, we’ve got two Serious Security articles lined up.
The first is about a Linux full disk encryption bug that has been fixed. But what happened before it was fixed?
DUCK. Usually, on Linux, when you’re doing full disk encryption – that’s the stuff that makes sure that if someone steals your laptop once it’s powered off, the disk’s just shredded cabbage unless you put in a password…
…on Linux, you’re probably using a thing called LUKS, Linux Unified Key Setup. And to help you manage LUKS, there’s a program called cryptsetup.
Unfortunately, as often happens with full disk encryption because it’s so useful, cryptsetup has an awful lot of features – probably a lot more than you would ever imagine you needed.
And one of the things that cryptsetup can do – the option is called reencrypt.
What it means is that instead of just changing the password that decrypts the master encryption key, it actually decrypts and reencrypts your whole hard drive *while you’re using it*, so you don’t have to decrypt the whole thing and risk having it unencrypted for a while.
It all sounds fantastic, except that what the cryptsetup team did is: they figured, “Hey, we could use the same code if someone needs to decrypt the disk,” like they actually want to remove the encryption for some reason.
Or if they’ve got a disk that somehow never was encrypted and now they want to add encryption back.
So they thought, “Well, those are just special cases of reencrypt. So let’s fudge the system instead of writing them as separate utilities.”
Let’s just do them as “deviant cases” of reinfection…
DOUG. [LAUGHS]
DUCK. To cut a long story short, it turns out that if you’re using decrypt or encrypt functions, rather than the reencrypt function, then cryptsetup doesn’t take sufficient care about what you might call the metadata – the temporary data – that records how far it’s got.
So, somebody who has access to your computer *but does not know your password* can modify your hard disk and basically trick the system into thinking, “Oh, I was in the middle of decryption, but it broke halfway through.”
If you tried to do that when the person was *reencrypting*, it would go, “Uh oh! Someone’s been tampering with your disk: you need to investigate!”.
But those checks, if you were using the pure *decrypt*, were not made.
So somebody could get your computer while you weren’t looking, fiddle with it, and then when you rebooted and actually put in your password, at least some part of the disk might get decrypted.
And you wouldn’t realise, but you’d end up with at least one little bit of your disk decrypted.
Which means that if you’re relying on full disk encryption to say to the regulator, “By the way, if this laptop is stolen, I can promise you there is no plaintext data on here at all”…
…well, you might not be telling the truth, because there might be a small, medium or large chunk of data that *did* get decrypted without you realising it.
And it gets worse!
What a person could do is this: they could decrypt a chunk of your disk and then come back later. If you haven’t noticed, they could dig around in that decrypted data, which is no longer integrity protected; it’s just plaintext.
They could make some cunning modifications: maybe they could change a file name, or, if they could find fragments of something that looked like your browsing history, they could insert browsing history that made you look like a very naughty person indeed.
Then they could run the bug backwards! They could say, “You need to reencrypt this stuff.”
And the next time you booted and put in your password, your disc would “heal itself” by reencrypting the stuff that had inadvertently been decrypted, but *with unauthorized changes in it*.
DOUG. Ooooooooooh.
DUCK. So this sounds like, “Well, that’s not really a bug, is it?”
But what it means is that somebody with your worst interests at heart (say, somebody who wants to gaslight you), if they have access to your computer when you’re not looking, they could, *without ever having to find your password*, stitch you up with data on your disk that’s encrypted with your password.
So they could say, “How on Earth could I have done that? I don’t know the password. I can prove I don’t know the password, beyond reasonable doubt, at any rate. If it’s encrypted with your password, well, then *you* must have done it.”
DOUG. Yes.
DUCK. And this was a little loophole that meant that assumption didn’t necessarily hold…
…and therefore you should get the latest version of the cryptsetup program, because it adds the checks that should have been in the pure decrypt and pure encrypt functions.
It adds integrity checks that make sure that nobody tries to trigger decryption or encryption without actually having known the password in advance.
If you have cryptsetup, the version you want is 2.4.3 or later.
DOUG. All right, you can learn more about that – the article is on Naked Security at Serious Security: Linux full disk encryption bug fixed – patch now.
Well, it feels good to be getting back into a rhythm, a cadence, where another week goes by…
…and we now have an Apple bug to talk about.
DUCK. [LAUGHS] I was wondering where you were going with that, Doug!
Yes, this is an Apple bug. And annoyingly, it’s a bug in Safari, or perhaps more importantly, in WebKit, which is what you might call the browser engine that Safari uses.
DOUG. [IRONICALLY] Then I believe I’ll just go download Firefox for my iPad and I’ll be just fine, Paul. Right?
DUCK. Well, that’s the problem. If it’s not macOS, but rather iOS or iPadOS, Apple requires all web browsing apps to use WebKit.
So in iOS and iPadOS, you don’t really have a workaround. Or more importantly, if you think, “Oh, I’ll just go and get Firefox,” it won’t save you from this bug.
DOUG. So what actually causes the problem here?
DUCK. It is Featureitis and Complexity Considered Harmful yet again, Doug.
DOUG. What, again?
DUCK. Again, again.
DOUG. This is becoming a theme!
DUCK. As our listeners will surely know, what’s called stateful HTTP data – in other words, things that your browser remembers so that when you go back to a website, the website can tell that it’s you coming back…
Obviously, that’s good for tracking, but it’s also good for things like, “Should I use the big fonts or the small fonts? Should I be in mobile phone mode or desktop mode?” All of those things that you want to retain between one website visit and the next.
…traditionally, those were handled by data objects called cookies.
And without cookies, we could never have had websites that allowed you to login, because the website wouldn’t be able to remember, “Hey, this is the same person coming back.”
But it turns out that cookies are inefficient, because when you send cookies, you have to send all the cookies ever set by a website, every time you connect any page on the website, even if that page doesn’t need them.
And therefore most browsers have a strict limit on how much cookie data you could have.
So guess what happened? The browser people got together and they said, “Hey, let’s have a thing called web storage,” which is like big cookies that you can access with JavaScript. You only access web storage with JavaScript from a particular web page, when you know you need the data.
So you had cookies and web storage; two different technologies. One did not require JavaScript; one did require JavaScript. One was limited in how much state data it could save; the other was much more flexible, and let you save much bigger objects.
But even web storage wasn’t good enough, Doug, because the funny thing seems to be that the more we embrace the cloud, the more we expect our browser to behave as if it were a locally installed application.
So, along came a thing called IndexedDB, which is, if you like, a THIRD type of cookie.
We’ve got cookies that go in the web headers; we’ve got web storage, which is a kind of loose, informal little mini-database that JavaScript can access; and we’ve got IndexedDB, which is nearly-but-not-quite a browser-side SQL database.
It doesn’t actually use SQL, but it lets you store much larger chunks of data – such as whole documents or whole sets of documents, If you’re doing a content management system, or massive images, if you’re writing a cloud-based image processing program, for example.
You’ve got cookies for small amounts of data; web storage where you need a bit more; and IndexedDB where you want significant amounts of structured data.
Because when two things can do something badly…
DOUG. [LAUGHS]
DUCK. …three things can do it even [PAUSES] better, apparently.
And the problem is – it’s really tiny – that on Safari, or on WebKit, there’s a special function called indexedDB.databases that, when you call it, gives you a list of all the currently active IndexedDB databases known to the browser.
But it gives any web page, any tab, any window, any website, access to the full list of database *names*.
It enforces the Same Origin Policy that says that website X cannot read the IndexedDB databases of website Y, so a website can only access its own cookie, its own web storage, and its own IndexedDB data.
But all tabs can access the list of database *names*, which, as tiny as it sounds, turns out to be a step too far.
Because as the researchers who found this – it’s a company called Fingerprint JS; they go looking for browser anomalies…
…as they discovered, lots of mainstream websites, when they create one of these IndexedDB databases for their own use, give it a bit of a telltale name.
They don’t just call it blah or db; they’ll name it in a way that indicates what service it belongs to.
This is like saying to a crook, “I’ve locked you out of all the data on my computer, but I *will* let you download a list of all my filenames.”
DOUG. Ah hah!
DUCK. You can imagine that there are a lot of secrets in your file names, in your so called metadata.
And the other thing the researchers discovered – they particularly looked into this for Google, but this is not really Google’s fault; not blaming Google…
…apparently Google uses your Google User ID as a database name, which is some random string of characters.
Now, that doesn’t tell somebody who can list that unique identifier *who* you are. A crook with a website that’s abusing this function won’t know that “Doug” is represented by this particular hexadecimal string.
But every time “Doug” visits their website, even if “Doug” has tracking protection on that tries to stop them figuring where you’ve been…
…you’ll come back *with the same Google User ID* if you’re still logged into Google.
So they won’t know who you are, but they will know that it’s the same person coming back over and over again – without setting any cookies or doing anything devious of their own.
It’s almost as though this IndexedDB database list can act like a kind of a supercookie: I don’t know who it is, but I do know it’s the same person every time.
That’s information that you probably never intended to give out.
And that’s why this bug is important, considering the effort that browser makers over the years have put into eliminating all this treachery that people could do with so-called supercookies – that’s where crooks use things like “which websites have you visited using HTTPS instead of HTTP?” as a way of tracking who you are, or “which fonts do you have installed?”, or “what screen resolution are you using?”
All those things that people would dubiously use to try and fingerprint you as an individual user can be done with IndexedDB.
And as we’ve lamented many times before, Apple aren’t saying when they’re going to fix this.
But the reason that Fingerprint JS wrote about it now is that they can see, from the open source components in WebKit, that Apple programmers seem to be looking at this, and they’re beginning to merge in a whole load of changes which will fix it.
So there is a patch to Safari/WebKit probably coming soon… but Apple doesn’t believe in telling you that it’s coming.
You just have to assume that it is. So watch this space.
DOUG. OK, we’ll keep an eye on that! That is Serious Security: Apple Safari leaks private data via database API – what you need to know, on nakedsecurity.sophos.com.
And it is that time of the show: the Oh! No! of the week.
Reddit user dilgentcockroach700 writes…
DUCK. Does that mean there are 699 diligent cockroaches before him or her?
DOUG. I know! Imagine trying to secure that username!
DUCK. [PRETENDING TO BE A SUPPORT BOT] “Other usernames you might like…”
DOUG, Yes, 700: a lot of cockroaches; they’re hard to kill.
[TELLING THE STORY] Back in the 1980s, I was working for a telecomms company in the UK. We had a Digital Equipment Corporation PDP-11 that I was in charge of, which was in an environmentally controlled room.
One Monday morning, I got to the office to find the computer was completely dead. I rushed into the computer room to find ladders, pots of paint, paint brushes, and a giant dustsheet completely covering the PDP-11, which by now was so hot it was almost glowing.
(If no one’s ever seen one of those, it’s about the size of a refrigerator that you put in your kitchen… it’s a giant computer.)
Apparently the Office Services Department had decided the room needed decorating, but didn’t bother to tell anybody.
I shut the power off to the computer, removed the dust sheet, and left it to cool down.
Later, I tried to reboot it but it wouldn’t work. Ended up having to call in DEC engineers from the US, and replacing most of the fried internals. My manager made the Office Services Department pay the several-thousand-pound bill out of their budget.
So, imagine – a giant computer the size of a refrigerator – how hot that would get…
DUCK. [LAUGHS]
DOUG. …and then putting a painter’s tarp over it to paint the room it was in.
DUCK. That was the world’s most expensive paint!
DOUG. Uh huh!
Well, I’m guessing that by now they’ve probably replaced that PDP-11 with something a little bit more svelte.
DUCK. Probably ten times more powerful, like a Raspberry Pi Zero.
DOUG. Or a cellphone!
Anyway, if you have an Oh! No! you’d like to submit, we’d love to read it on the podcast.
You can email tips@sophos.com, you can comment on any of our articles, or you can hit us up on social @nakedsecurity.
That’s our show for today – thanks very much for listening.
For Paul Ducklin, I’m Doug Aamoth, reminding you…
Until next time…
BOTH. …stay secure!
[MUSICAL MODEM]