+44 (0)20 86848683

Perpetual IT

News

French speakers blasted by sextortion scams with no text or links

by

Unfortunately, we’ve had to warn about sextortion, also known as porn scamming, many times before.

Porn scams are phishing tricks whereby criminals try to squeeze you into making contact with them, or even to pay them money immmediately, by claiming to have evidence that you have committed some sort of sexually-related online impropriety.

In the early days of porn scamming, the messages were often made to look like police demands, typically locking up your browser or your mobile phone and keeping you stuck on a warning page.

These pages were frequently topped-and-tailed with ripped-off police logos determined by your geolocation (e.g. if your IP number was in the US, you would see an FBI logo; if in Australia, you’d get the Australian Federal Police “branding”), to give them a whiff of legitimacy.

The web page you ended up locked onto usually offered you two choices: pay an online fine to “decriminalise” the charges and put an end to the matter, much like taking the online route of paying a parking or speeding fine; or get arrested and have your day in court.

Here’s what this sort of scamming looked like eight years ago:

The good news is that this brand of online extortion didn’t last very long, for three main reasons:

  • Reveton, one of the primary gangs behind these scams, got busted in Spain and shut down.
  • Users learned how to remove this early type of ransomware using free tools to bypass and delete the “lockup” program that tried to take control of your device..
  • Cybercriminals turned their attention to a new type of extortion.

Police locker scamming dies out

The bad news, of course, as alluded to above, is that simplistic “police locker” ransomware, as it was known, was replaced in the cybercrime arsenal by file-locking ransomware, where there was no need for the crooks to pretend to be law enforcement officials.

Quite the opposite, indeed: in modern ransomware attacks, which found their criminal feet in the early 2010s, the criminals make no secret of their criminality, usually demanding huge amounts of money for a decryption key to unscramble your files, or for a promise not get your stolen data leaked, or both:

Sextortion video scams

Porn-oriented scams soon returned to our inboxes, however, with phishing emails that were plain-and-simple blackmail demands, like this one:

I’m aware, [REDACTED] is your password. You may not know me, and you are most likely wondering why you’re getting this mail, right? […]

I installed a malware on the adult vids (sex sites) site, and there’s more, you visited this site to have fun (you know what I mean). Once you were there on the website, my malware took control of your browser. […]

Well, I believe, $1900 is a fair price for your little secret. You will make the payment through Bitcoin (if you don’t know this, search “how to buy bitcoin” in Google).

[embedded content]

Personal data used for verisimilitude

In this revised type of “sextortion” scam, the crooks typically add into the email some widely-known data from an earlier data breach.

Usually, this means data stolen from a third-party service provider to whom you’d trusted it but who hadn’t returned your trust with good cybersecurity.

By putting into the email an actual password of yours (even if it was an old one you’d already changed), or your phone number, or some other semi-private chunk of data, the criminals hoped to convince you that their claim to have implanted spyware on your computer must be true.

And even if you weren’t worried – or didn’t care about – about the porn allegations, the crooks hoped you might still reply to them on the grounds that if they know some private data of yours…

…what else might they have got hold of along the way?

Over the last year or two, however, we’ve noticed that the steady stream of sextortion emails we used to receive – at one time, we were getting several variants on the theme each week – has dwindled to almost nothing.

Note that we’re not suggesting, despite the timing, that the coronavirus pandemic has anything to do with this tail-off in porn scams to our email accounts. You can probably come up with various theories that might plausibly connect the two things, e.g. that home delivery scams turned out more lucrative, so that’s where the artisan parts of the cyberunderworld switched their attention, but correlation (or plain coincidence) does not, as you well know, does not imply causation. We hve no firm evidence for exactly why our own sextortion email “feeds” tailed off, and we can only hope it’s because there was less and less money in it for the crooks as more and more people learned to recognised these scams for what they were.

Down, but not out

Sadly, however sextortion scams haven’t died out altogether.

Like many aspects of cybercrime, old-school techniques fot crookery rarely die out altogether – in the same way when that file-locking ransomware took over from police locker ransomware, and began to dominate the cybersecurity news because of the huge blackmail payments involved…

…other types of malware and cybercriminality, such as spyware, keylogging, spambots, cryptomining and romance scamming and spambots, didn’t disappear.

Here’s a recent sextortion scam example in French, sent in by a Naked Security reader we’ll refer to simply as @M (thanks, M!) , where the porn scammers have converted their message into an image.

This is an old trick that makes it harder for security software that filters incoming messages primarily by analysing the grammar, structure, style and content of the writing:

Often, attackers stick to messages in plain text or HTML for the obvious reason that web or email links in those messages typically turn into directly tempting “calls to action”.

Web URLs inside emails (and even in plain old SMSes, or text messages) are often automatically made clickable, and embedded email addresses can usually be replied to directly, or copied semi-automatically into your address book or the To: field of a new message.

Adding an image that holds the call-to-action text obviously makes it harder for a recipient to reply, because a plain image can’t contain clickable links, or even text that can be copied and pasted.

Shaking loose some replies

But the criminals behind scam campaigns like these – fake police notices – aren’t trying to entice you to a new website or to encourage you to try clicking on a brand new service.

They’re aiming to frighten just a few of the recipients of these messages enough to scare them into replying of their own accord.

Indeed, as this email claims (highlight 1 above; our loose translation), after warning you of the penalties for viewing illegal cyberporn (up to 5 years and a fine up to EUR75,000):

We sent you an email in this form for reasons of confidentiality. If you wish, you many reply to the address below to explain away your actions, so that we can evaluate your explanation and determine if charges should be brought. You have a strict deadline of 72 hours.

Simply put, the criminals are trying to convince you that they do have evidence against you, but they have – for reasons of “fairness” and “decency” – been discreet enough not to include this evidence in an email where someone else might come across it.

Presumably, the blackmailers behind this scam are hoping that at least some of the recipients will feel pressurised into justifying themselves, perhaps by explaining that although they have looked at porn recently, they haven’t knowingly committed any criminal offences or viewed any illegal content while doing so.

As you can imagine, anything that’s shared with the criminals will simply be worked into future correspondence with potential victims, in order to increase the amount of manipulation and the level of pressure applied by the crooks.

Any personal circumstances or explanations offered to the crooks will be turned into replies intended to amplify and expand the fear of those victims, until they agree to take some action to “suppress” or to “finalise” the matter, typically involving paying over some sort of “fine” or hush money.

The criminals finish off even more threateningly (highlight 2 above):

You are now summoned to answer in your own words immediately in order to prevent this matter from going further and taking an unpleasant turn against you. After 72 hours, we will are obliged to send our report to the Public Prosecutor to issue an arrest warrant against you. We will proceed to have you arrested by the police closest to your place of residence.

What to do?

We suspect that most or all Naked Security readers will discard emails of this sort without further thought.

But you may have family or friends who, if they are worried by a message like this, probably won’t reach out to you for help…

…so we’ve published this article to try to help them where you might not be able to.

Importantly:

  • How likely does the message really seem? The sender of this email was given as Jean-Luc Godard, who in real life is a world-famous left-wing French filmmaker now in his 90s. The investigating officer you are told to email directly is Frédéric Veaux, the Director General of the French Police. If you were being charged, you would have to be formally accused by name, not simply sent an email starting simply Monsieur/Madame. (Interestingly, the subject line said Mr/Mme, mixing up English and French in an obvious mistake.)
  • If in doubt, don’t give it out. If this were a geniune criminal investigation, you would not be invited to submit evidence in mitigation informally via email. That would be insecure both for you and the police, and would almost certainly be useless in court anyway.
  • Don’t be afraid to check with a trusted source. If this email were genuine, and there really were police charges against you, then emailing back information of your own to defend yourself against as-yet unspecified, unknown claims against you would be a very bad idea. The police themselves would not ask you to do that, which makes it obvious that this email doesn’t come from the police in the first place.
  • Check online for similar message reported by other people. Many sites, of which Naked Security is just one, make an effort to write up scams like this in order to show potential victims that they aren’t the only ones being “accused”, and thus that the message they received is simply one of many identical spams sent out to stir up fear.
News

Irony alert! PHP fixes security flaw in input validation code

by

If you’re using PHP in your network, check that you’re using the latest version, currently 8.1.3.

Released yesterday [2022-02-17], this version fixes various memory mismanagement bugs, including CVE-2021-21708, which is a use-after-free blunder in a function called php_filter_float().

A proof-of-concept exploit based on using PHP to query a database shows that the bug can be used to crash the PHP process, so a working Denial of Service (DoS) attack is already known to be possible.

Of course, as Mozilla routinely and unswervingly likes to point out in its regular updates, when bugs are patched that show evidence of memory corruption, you should “presume that with enough effort some of [them] could have been exploited to run arbitrary code.”

Remote Code Execution (RCE), where data submitted from outside can not only crash a program on your computer but also gain control of it in the process, typically leads to network intrusion, data exfiltration, malware implantation, or a foul-tasting cocktail of all of them.

Invalid validation code

Ironically, the PHP filter functions are designed to validate incoming data, for example to ensure that if you’re expecting someone to send you an integer (e.g. 5, 7, 11), they haven’t sent you a string of text that can’t reliably be converted to a whole number, such as 3.14159 or 3/16 inch.

The CVE-2021-21708 bug is part of the code that checks for valid floats, or floating point numbers, a jargon term for what you probably called “real numbers” or “decimals” at school.

Decimals typically have a dot (or a comma, depending on your country) that separates the whole part and the fractional part, as in 2.5 to represent two and five-tenths, or two-and-a-half.

PHP’s numeric filter functions allow you to check not only that the incoming number is valid, but also that it’s within a specified range, such as ensuring it’s no greater than 2.71828, or that it’s between -1 and 1.

If the number that comes in is already a floating point number (a decimal), then the code goes as shown below, where the old PHP code (8.1.2) is on the left and the new code (8.1.3) is on the right. (There’s no bug here, so the two versions are identical.)

Don’t worry if you don’t know C; the important thing to note is that the error checking is done first, followed by a line that frees up the memory currently used by PHP to store the number, followed immediately by a line that reallocates memory for PHP to use.

In case you’re wondering, the curious name zval_ptr_dtor() is shorthand for PHP internal memory pointer destructor:

Left. PHP 8.1.2. Right. PHP 8.1.3.
Both sides follow the ‘Look, step into road, cross’ approach.

If the number comes in as an integer, with no decimal part, slightly different code is used.

Below, as you can see, the sequence of “do the check and exit if it fails; but if it’s OK then deallocate-and-reallocate storage for the number” was mixed up in the old version.

The sequence was “deallocate the memory used by this PHP value, then do the check and exit if it fails, leaving behind a PHP object referring to memory that will soon get allocated to something else and will thus later cause a use-after-free conflict; but if the check is OK then reallocate new storage for the number.”

That’s a bit like stepping into the road first, and only then checking if it’s safe and completing your crossing.

The updated code in version 8.1.3 has restored the code to a safer sequence, although it would be safer still if there were a single function called, say, dtor_and_alloc_in_one_go(), so that future programmers couldn’t accidentally re-insert code between the call to the destructor and the call to the allocator.

The new code is more like checking the road is safe first, then stepping into it and walking directly to the other side.

The “diff” view (jargon for code difference) created by Visual Studio Code shows neatly how the line marked in red in the 8.1.2 version was moved down to the green spot in the 8.1.3 version:

Left. PHP 8.1.2. ‘Step into road, look, cross’.
Right. PHP 8.1.3. ‘Look, step into road, cross’.

What to do?

  • If you’re a PHP user, update to 8.1.3. If you’re using a Linux distro that manages PHP for you, check your distro for details.
  • If you’re a programmer, remember that code written in C requires you to take care with memory all the time, and everywhere, so that well-hidden bugs like this one don’t creep in unnoticed.
  • If you’re a programmer, try to write your code to reduces the number of ways that errors can be introduced by the coders who come after you.
News

S3 Ep70: Bitcoin, billing blunders, and 0-day after 0-day after 0-day [Podcast + Transcript]

by

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. Bitcoin, billing errors, and zero-day after zero-day after zero-day.

All that, and more, on the Naked Security Podcast.

[MUSICAL MODEM]

Welcome to the podcast, everybody.

I am Doug; he is Paul; and we’ve got a veritable cornucopia of security stories for you here today.

Some about crocodiles…

DUCK. Technically, there’s only one crocodile.

DOUG. Thank you for clarifying.

DUCK. And it’s not an actual crocodile.

It’s only a metaphorical crocodile.

DOUG. There we go.

DUCK. So if you’re expecting something like a great snapping frenzy, you might be disappointed.

But it is a wacky story in its own right.

DOUG. Yes!

DUCK. So hang in there.

DOUG. Important clarification – thank you.

DUCK. [LAUGHS]

DOUG.We like to start the show with a Fun Fact.

And it’s been a snowy winter here in the US, but not as snowy as 1978, when not one but two major blizzards hit in rapid succession.

The so-called Great Blizzard of 1978 dropped 52″ of snow, or 130cm, in Muskegan, Michigan, in late January, while the Northeastern Blizzard of 1978 dropped 27″, about 70cm, in Boston in early February.

And I do have a way of bringing that fact back into the show when we talk about our This Week in Tech History segment.

So strap in for that.

DUCK. I think I know what this is about…

DOUG. [QUIZZICAL] OK?

DUCK. And I think, Doug, that it is indirectly connected with Wikipedia.

DOUG. Hmmmmm?

OK, we will test that theory… stick around; we will see.

Let’s talk about crocodiles.

Excuse me, *one* crocodile.

DUCK. [LOUD LAUGHTER] Sorry…

One self-proclaimed “crocodilian person”.

DOUG. Yes – it doesn’t really work if you give yourself the nickname.

But this is the self-styled “Crocodile of Wall Street”.

DUCK. Indeed – nicknames don’t work that way, do they?

DOUG. No, they don’t!

DUCK. You can’t give them to yourself.

DOUG. I’ve been trying to get people to call me “Cool Doug” for years, and it has not caught on.

It just doesn’t work that way.

But this lady, the Crocodile of Wall Street, with her husband: they’ve been accused of stealing many, many bitcoins to the tune of many, many dollars.

So, what’s happening here?

DUCK. Well, what’s fascinating about this, Doug, is this apparently goes back to the infamous Bitfinex breach back in 2016, which was one of the early large-scale incidents: “Oh, dear! We’re a cryptocurrency exchange. And we had a bank robber, a virtual bank robbery.”

It’s alleged that these two people, the husband-and-wife team, the woman calling herself…oh, dear [LAUGHS]… the “Crocodile of Wall Street” and her husband… they’re alleged, if not actually to have done the hack that allowed them to wander off with all these customers’ investments at Bitfinex, at least to have come across, or acquired, some or all of the proceeds of that heist.

So, they’re not accused of doing the heist, but of knowingly coming into money that they didn’t get lawfully.

It was at, the time, a whopping $72 million worth of Bitcoin.

DOUG. I am looking at the original article…

It is adorable that the teaser text on there says they stole “nearly 120,000 bitcoins worth about $72 million”.

DUCK. Yes. That’s the crunch, isn’t it?

120,000 bitcoins at today’s value is north of $4000 million, or $4 billion!

So I guess they’re being charged with the offences related to the bitcoins, not to the dollar amount.

But a lot of media articles said, “New York couple alleged to have stolen $4.5 billion (in bitcoins)”.

Ironically, at the time, well, it was a mere 72 million, Doug!

The interesting thing about this case, if we take the allegations at face value for a moment: it seems that the real complexity, for the people accused of it, is cashing out the money.

And there are all these machinations that investigators claim they were able to track down, showing them trying to set up accounts, and coming up with all these cover stories.

So, they’re charged with… in plain English: with trying to shift around cryptocurrency that they knew was stolen, whether they stole it themselves or not; and with fraud.

In other words, telling a whole bunch of lies along the way to give the impression, to places where they could cash out the cryptocoins, that they had acquired them legally.

But the vast majority of them, some significant percentage – I think around 80% of them – were, as far as I can make out, sitting in cold wallets in the cloud.

So it all hinged, as far as I can make out, on these cold wallets getting cracked.

It turned out that dispersing them and cashing them out was quite a complicated exercise.

And, in fact, if you go to the article on Naked Security and click through to the various law enforcement links, it’s a fascinating article – I think it was by an IRS investigator – about all the bits they had to piece together.

It’s quite fascinating, the machinations that these people are alleged to have gone through, in some cases to cash out as little as $500 at a time to buy gift cards.

It seems, if it’s true, they did manage to live a pretty high life – but the vast majority of these supposedly stolen funds were still sitting there while the alleged perpetrators tried to figure out what to do with them.

DOUG. I’m trying to think of how you would launder or tumble that much.

It’s mind boggling.

You couldn’t do it.

Even if they tried to tumble it all… that would clearly raise some red flags, right?

DUCK. There’s this whole back story they had to create to avoid triggering alarms at exchanges that were trying to do the right thing.

Including, “Let’s do the transactions in smaller amounts so that they don’t necessarily need to be reported.”

It’s quite a fascinating story.

If, in the end, some of the people who had lost their funds at the start get them back in dollars, they’ll probably be fairly happy.

But if they get them back in Bitcoin…

DOUG. [LAUGHS] Oh, boy!

DUCK. …they’ll probably be really, really, *really* interested, because what was $72 million at the time is north of $4000 million dollars worth of bitcoins now!

DOUG. All right, that is an interesting story. It’s: Self-styled “Crocodile of Wall Street” arrested with husband over Bitcoin megaheist on nakedsecurity.sophos.com.

And now, something the reverse of a megaheist: we have what can only be charitably referred to as a “billing error”.

Like when you’re playing Monopoly: Bank error in your favour to the tune of…

DUCK. Oh, yes, I forgot about that card! “Bank error in your favour”… it’s $50, isn’t it?

DOUG. Yes, something like that, yes.

DUCK. This was…

DOUG. [LAUGHING] Slightly larger!

DUCK. …a little bit more dramatic than that, Doug. [LAUGHS]

As far as we can make out, this was due to recent severe storms in the north and northeast of the United Kingdom, and this relates to a power company that operates in northeast England.

So, this chap had a power outage, and because power provision in the UK is privatised, the companies that get the franchises to operate these power companies… there are terms-and-aconditions whereby if you’re without power for a certain time, they have to pay you a predetermined compensation.

So, I imagine he would have been getting a payout, perhaps in the low hundreds of pounds.

But they made a blunder, Doug.

DOUG. Hmmmm…

DUCK. And I don’t know whether it was actually an underlying software flaw that’s still there, or whether this was a special case… because it was a storm bad enough to get a special name (Storm Arwen – it was the first of the season, thus ‘A’).

Maybe this was a special case of, “Send us a CSV file and we’ll just shove it through the system.”

Apparently they took his electricity meter serial number as the amount to refund.

So instead of getting, say, £210, which would be say three days at £70 a day, he got, Doug…

[READING AMOUNT IN FULL] Two trillion, three hundred and twenty-four billion, two hundred and fifty-two million, eighty thousand, one hundred and ten pounds.

How about that? He had a 13 digit payment number.

DOUG. [LAUGHS] That’s a lot of bitcoins….

DUCK. They actually sent him a cheque attached to a signed letter!

I’m using air quotes (obviously a pre-scanned signature), but it wasn’t just an email.

It was actually a letter that came through the mail, with a good old-school cheque, with a QR code, crossed “Account of Payee Only”, pay to “This person’s name Only”, converted into words.

The amount was so long…

DOUG. [LAUGHS] I’ve just seen that – it doesn’t even fit!

DUCK. …it wouldn’t even be a valid cheque, because the words and numbers don’t match – it runs out just before the “one”, where it should say “one hundred and ten pounds and zero pence”, or whatever. But that last bit is missing.

He saw the funny side, and he posted to Twitter saying, “Dear @PowercompanyConcerned, are you sure you have enough money to cover this amount?”

DOUG. [LAUGHS]

DUCK. I looked it up, and it is slightly more than the annual GDP of the economy of the entire United Kingdom of Great Britain and Northern Ireland.

DOUG. There you go.

DUCK. So it would probably have bounced…

DOUG. I think so!

DUCK. …if he tried to present it.

And although we laugh, you think, “I wonder how that happened?”

To be fair to the power company: they have apologised; they have said they’ll do their best to actually get out cheques that these people can cash, because they are entitled to compensation; and they’re trying to figure out how it happened.

I do hope that they are able to find out, and they do go public with that information, because it will be a fascinating story.

Is it an underlying flaw in the software which obviously needs addressing?

Or was it a special case – “We’ll use a special procedure!” – and maybe the whole process hadn’t been tested or validated the as much as it should.

So, it will be interesting to see how this happened.

DOUG. For all the stories we talk about here that end in “Validate thine inputs”, we now get to say, “Don’t forget to validate thine outputs, too.”

Because this could have gotten caught many times over, whether flagged for such a huge amount, or “requires supervisor signature”, or who knows what else…

DUCK. [LAUGHING] Yes!

“Requires supervisor’s supervisor’s supervisor’s… TOO MANY SUPERVISORS REQUIRED error”.

You’re exactly right, Doug.

In this case, clearly the input wasn’t validated because it’s absurd, but the output should have been caught.

Why not check the output as well?

Because that’s what’s actually going on the cheque.

So, the point is that even though this did come from using the wrong input – the 13-digit electricity meter serial number instead of an amount in pounds and pennies…

…if you’ve missed the chance to catch it on the input, you’ve got a second chance to catch it at the output.

And two checks are always going to be better than one!

DOUG. Exactly.

Check that out – that article is called Power company pays out $3 trillion compensation to astonished customer on nakedsecurity.sophos.com.

It’s time for This Week in Tech History.

Well, we talked about the Great Blizzard of 1978 a little earlier in the show…

And this week, on 16 February 1978, the first public BBS, or bulletin board service, was launched by Chicago’s Ward Christensen and Randy Suess.

The two men began work on the BBS weeks earlier, after being snowed in by the storm.

The CBBS, or “computerised bulletin board system” as they called it, was modelled after the cork bulletin board Christensen’s computer club used to post things for sale, helpful information, and requests for rides.

Christensen provided the hardware for the BBS – an S-100 bus computer and a Hayes modem.

Seuss’s home served as a nice central location in the city of Chicago where the connection to the BBS was a local call for most users.

I had forgotten that… the BBS was a little before my time, but not super-before my time.

I remember, as a very young computer user, connecting to BBSes, and I had forgotten that you couldn’t just connect to whatever you wanted, because sometimes it was a long distance call.

So when I wanted to go get help with the Sierra Online games I was playing, I had to call out to California and it was a long distance call.

DUCK. Outside North America, Doug, certainly in most countries with a British heritage, local calls were metered as well as long distance ones.

DOUG. Oooof!

DUCK. So you had to pay for as long as you wanted to stay on.

But that did have a slight advantage on its flip side: there was an incentive not to stay on for hours and hours and hours once you got access to one of the modems that the BBS operator had in their home.

Because of course, he needed a separate phone line and a separate phone bill and a separate number for each one.

So that was the flip side for us: although you had to pay – it wasn’t dollars a minute, but it was certainly tens of cents a minute – to stay on locally. It did mean that there was an incentive not to hog the line.

It meant that people couldn’t jump on in the morning and then just keep the line open all day long.

[EXCITED] So there is, Doug: a tangential – maybe not even tangential – connection with Wikipedia.

Because, of course, Ward Christensen was the chap who went on to invent the concept of Wikis in 1995…

DOUG. [DELIGHTED] OK!

DUCK. …which gradually took off.

And of course, that Wiki software and the Wiki model was ultimately adopted by Larry Sanger and Jimbo Wales for Wikipedia.

DOUG. Very cool, all thanks to the Great Blizzard of 1978!

We have a blizzard of zero-day stories….

DUCK. [LAUGHS] That’s good, Doug.

DOUG. Thank you.

Thank you very much.

DUCK. That’s a triple-play segue, if you ask me.

DOUG. [LAUGHS] Great – that’s what I’m looking for!

DUCK. I’m happy with that!

DOUG. So, when we talk about zero-days – if a regular person were to ask what a zero-day is – is it fair to say it’s basically some sort of security hole or exploit that is discovered and abused by the Bad Guys before the Good Guys notice it?

In other words, this isn’t a bug that’s caught and fixed.

It’s caught because it’s already been abused.

DUCK. Yes.

In modern parlance, the “zero” is meant to remind you that even if you are the most proactive patcher in the world, even if you have a system for your entire organisation’s network that grabs and pushes out patches minutes after they appear…

…in the case of a zero-day exploit, there are quite literally zero days during which you could have been ahead of the Bad Guys.

But my understanding is that the term was transferred from the early days of game piracy, where the big game-creating software houses would drop a brand new game, and then the gamecrackers would go to work trying to figure out how to play it without buying the box and getting the licence code.

Remember those weird maps you’d get that were printed in funny colors so you couldn’t scan them?

DOUG. Uh huh!

DUCK. And what’s the third word on the 17th page of the manual, all that stuff?

DOUG. [LAUGHS]

DUCK. The crackers would try and remove that part of the program so it would work illegally.

If you could get a crack on the fourth day, that was pretty good; if you could get a three-day crack, that was very good.

And the ultimate crack, of course, would be the zero-day, which meant that you actually cracked it *on the same day it came out*.

So that metaphor was transferred to bugs.

But of course, in the case of the bugs, the crooks could have found them long before.

DOUG. And we’re talking about three large companies that are affected here, Apple, Adobe and Google.

So, three separate stories.

But, as I’m reading all three of these stories, I’m seeing some of the same phrases over and over.

I’m seeing zero-click attacks; I’m seeing arbitrary code execution; I’m seeing use-after-free.

So three separate incidents, but the same means to an end in almost all of them?

DUCK. We don’t know exactly what form the bug took in Apple’s case because they just said, “We’re aware of a report that this CVE may have been actively exploited.”

DOUG. [HEAVY IRONY] That’s odd.

They weren’t forthcoming?

That’s weird.

DUCK. Apple’s bug, of course, was in WebKit.

That’s doesn’t just mean that it’s in Safari – as we spoke about in a previous podcast, it means it’s in the code that sits under Safari.

So, it’s in any app that uses the WebKit rendering engine – for example, for its help system.

And it’s also in any browser on your iPhone, because browsers on the iPhone aren’t allowed to bring their own rendering engines: even though it may not be Safari on top, it has to be WebKit underneath.

DOUG. I’m guessing not a lot of people know that.

If you’re downloading Firefox for iOS, you might think, “Oh, this is the actual Firefox engine underneath this.”

It’s not!

DUCK. Yes!

I think a lot of people, perhaps quite reasonably, like to have a bit of “divide-and-conquer”, don’t they?

So you might decide, “I know what: I’ll use Google as my search engine; having done that, well, I’ll use the Outlook.com for my free email, so it’s a different company; and then I’ll stick to Meta, or Facebook, for my social networking, so that’s another company; and I’ll stick to Firefox for my browser because that’s not associated with any of the others.”

But you’re right that on iOS and iPad OS – so, on iPhones and iPads – all browsers that make it into the App Store have to use WebKit underneath.

So, as you see with IoT devices, you could have three different brands, but actually, if you peel the labels off, it’s all the same product underneath.

And that certainly happens with browsers on Apple’s operating system.

Having said that, you mentioned Adobe, Doug.

And their bug, in some ways, is a bit more dramatic… because it wasn’t a bug on the client side in the browser, it was a bug in Adobe’s e-commerce products…

DOUG. Oh, dear!

DUCK. …on the server side. [LAUGHS]

When the word “e-commerce” comes in, you think, “Oh! No!”

“Insufficient input validation bug”.

Basically, that means an untrusted user… whether it’s Log4Shell style, just fill in a form with garbage or add weird HTTP headers, we don’t know; Adobe isn’t saying exactly how the bug happened.

But it did admit a little bit more than Apple, and it said it was aware that the CVE in that case had been exploited in the wild.

Then they couldn’t resist adding, “In very limited attacks”. [LAUGHS]

DOUG. [IRONIC] Of course.

DUCK. And you’re thinking, “That’s obviously better than if every single customer using Adobe Commerce or Magento (the open source version), got attacked.”

Limited attacks are better than widespread attacks.

But think of Colonial Pipeline: one company got ransomware, and three days later people were pumping gasoline into plastic bags in Delaware.

DOUG. [LAUGHING] Aaaargh…

DUCK. I may have made up some of the details there…

…but limited attacks can nevertheless not be *that* limited in their side-effect.

And, like you said, this was one of those cases where you don’t get any buses at all, and then three come along at once.

DOUG. [LAUGHS]

DUCK. One just before the weekend; I think Adobe was over the weekend; and Google’s came out yesterday – that’s Valentine’s Day as we are recording – and they reported a zero-day in Chrome, Doug.

DOUG. Oh-oh!

DUCK. I presume that means some, or perhaps all, Chromium-based browsers may be affected, too.

That would include things like Microsoft Edge, which I would say is the second most widely used Chromium-based browser out there.

And, again, Google isn’t saying much.

In fact, you could argue that, for all their Project Zero attitude of “Hey, let’s be open and honest about bugs”, they’ve said the least.

Again: “aware of reports that an exploit exists in the wild.”

Sort of like, “Hey, we haven’t seen it ourselves; it’s just a report.”

[WHISPERS] But it’s an O-day.

And , like you said, it wasn’t the only bug of its class in this bunch of Chrome updates.

It was one of five so called “use-after-free” bugs, which is where a software program mismanages memory in a way that could allow someone to exploit one part of the program to poke a knitting needle into another part of the program.

Because the first part of the program carries on using memory that it shouldn’t use, even after it’s handed it back and it’s been lent out to someone else to do something else with.

DOUG. All right!

So, extra important in all three cases of these to patch.

Especially in this Chrome one.

[DRAMATIC PAUSE] I guess in the Apple one, too.

[DRAMATIC PAUSE] And Adobe.

DUCK. I guess in the e-commerce one, Doug?

DOUG. [LAUGHING] Yes!

OK – as we said, there are three different articles.

We’ve got:

All three of those on nakedsecurity.sophos.com.

It’s time for the Oh! No! of the week.

This week, we’ve got an unfortunate comment from Naked Security reader Richard, who, on the story about the $3 trillion cheque from the power company, writes:

I was sent a demand to pay $0 once and then a few weeks later a penalty of $15 for not paying the bill of $0.

Now *that* sounds about right as far as billing errors go from power companies, in my experience!

DUCK. Yes, and that’s why I think, although there’s a funny side to the $2 trillion error because it’s just so jolly obvious…

…well, that’s a little bit like when we talked about use-after-free.

If someone pokes garbage into a little bit of memory that is part of an image you’re trying to display, then either the image will not display at all or it’ll just have some weird noisy garbage in the middle of it – it’ll be obvious that something went wrong.

But what if, in the case of a drive-by download, it all looks OK… but, in the background, something happened that you didn’t notice?

And that’s the problem here.

He says explicitly, Doug, “I was sent a demand to pay zero DOT zero”, as though they normally only asked for amounts rounded to the nearest pound or dollar or whatever. And then he got a penalty for not paying zero DOT zero.

Why would you print $0.0?

I don’t know any currencies that work with tenths.

Maybe the problem there was that they had incorrectly displayed what was actually going on, which means that it’s entirely impossible for him to troubleshoot it!

DOUG. Well, I do wonder if the total he was supposed to pay was displayed incorrectly…

…or if he was actually current on his bill, and there’s just a boolean in this billing software that says, IF user doesn't make payment THEN charge $15.

DUCK. Ah, you mean that later on it doesn’t actually check how much he didn’t pay?

It just checks “here’s the list of people who haven’t paid”?

DOUG. Yes: “We sent a bill. You didn’t pay it.”

DUCK. It doesn’t matter whether it’s $1000 or $12… charge them $15.

DOUG. Yes!

DUCK. That’s another problem, isn’t it?

Which is why: “Check thine inputs, and check thine outputs.”

DOUG. Very good!

Bringing it all back home… good job, Paul!

If you have am 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 one of our articles; 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 to…

BOTH. …stay secure!

[MUSICAL MODEM]

News

VMWare fixes holes that could allow virtual machine escapes

by

VMWare’s latest security bulletin doesn’t mince its words about how quickly you should patch:

When do I need to act?

Immediately. The ramifications of this vulnerability are serious, especially if attackers have access to workloads inside your environments.

[… G]iven the severity, we strongly recommend that you act.

The issues referred to here are covered in the company’s just-released advisory VMSA-2022-0004.

The good news, we’re pleased to tell you, is that this is the bad news.

Acting now will almost certainly jump you ahead of the many inquisitive (and acquisitive!) cybercriminals out there, given that none of the bugs patched in this update seem to be zero-day security holes.

Competitive bug-hunting

According to VMWare, the company “has not seen evidence that this has been exploited in the wild”.

VMWare says that he bugs were responsibly disclosed during the Tianfu Cup, a organised hacking contest run in China along the lines of the well-known Pwn2Own contest in Canada.

The bugs patched in VMSA-2022-0004 cover five different CVE numbers (CVE-2022-22040, -41, -42, -43, and -50), but the first two are the ones to focus on if your change control committee insists on taking time to rank vulnerabilities into decreasing order of badness before acting.

Both CVE-2022-22040 and CVE-2022-22021 are annotated with the comment that “a malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine’s VMX process running on the host.”

At first glance, the fact that an attacker first needs to login with a superuser account first might make this seem like an inconsequential sort of bug.

After all, if you’re already root, you can already do almost anything you like to the computer you’re on, so why bother with an exploit that gets you root again?

The danger of “guest escapes”

The big difference in this case is that virtual machine (VM) software is supposed to allow one computer, known as the host, to run numerous “guest machines” that are oblivious to each other’s presence, even though they’re actually running on the same hardware.

The VM host software is supposed to prevent the guest VMs from messing with one another without prior arrangement.

That’s because, in a typical VM setup, even one that isn’t hosted in the cloud, one physical VM server might act as the host for many guests, all of them administered by different company departments – or even split up amongst different organisations – that can’t, don’t, or shoudn’t trust each other.

In other words, a VM server hosting 10 different VM guests might have 11 different administrators: one each for the various guest operating systems installed, and one for managing the host server itself.

That’s entirely by design: the idea is that if I’m the root user of the host computer, I can let you choose and install your own operating system, set it up how you like, and dish out usernames and passwords to your own users…

…without having to worry that you might “escape” from your VM and mess either with other VM users assigned to the same server, or (worse still) get access to the host operating system itself, which would probably let you snoop on me and all the other VMs on the server at will.

Indeed, I should assume not merely that you might know the superuser password for your own VM, but that you will and indeed must know it on account of having set the guest VM up in the first place; and I should remember that I have little or no control over how widely you might share your own administrator login details anyway.

After all, different VMs on the same server hardware are meant, by default, to operate independently and separately, as if they were running on their own separate physical servers.

(This is good for resilience, redundancy and availability: if you suddenly need a couple of extra servers to tide you through a busy period, for example, you don’t need to buy and install new hardware; you can just rent some additional “VM space” from your VM provider, perhaps even hosted in another part of the world for speed or efficiency reasons.)

Therefore any bug that undermines either guest-to-host cybersecurity separation, or even just guest-to-guest separation, must always be considered a serious security risk.

A VM guest escape bug is a bit like finding out that someone you’ve never heard of has got hold of a key to your server room or your network patch closet, and could sneak in at will and fiddle with your kit and your cabling without permission.

Privilege escalation

There’s a second security advisory that came out at the same time, VMSA-2022-0005, which fixes another responsibly disclosed vulnerability, though this one didn’t emerge from the Tianfu Cup competition.

This one apparently closes off a bug in the NSX Data Center for vSphere Edge Appliance: anyone with SSH access to such a device, typically used for managing the network connectivity of multiple VM servers in a network data centre, could promote themselves to an administrator.

Presumably, this might include low-privilege users who normally have only minimal access, for example to look at usage statistics.

In other words, even if your general network security controls shield your Edge Appliances from direct probes from the internet, and therefore this bug might only be triggerable by network “insiders”, the list of insiders with enough access to abuse this bug might be a long one.

Cybercriminals who compromised the accounts of any of the users on that list might be able to use this bug to set up a beachhead for a much bigger-scale onward attack.

What to do?

Affected products include:

  • VMware ESXi
  • VMware Workstation Pro / Player (Workstation)
  • VMware Fusion Pro / Fusion (Fusion)
  • VMware Cloud Foundation (Cloud Foundation)
  • NSX Data Center for vSphere

Consult VMWare’s advisories here and here for the version numbers to look for after you’ve updated, in order to track the progress of your patching.

If, for some reason, you can’t patch right away, VMWare has published a temporary workaround to prevent the guest-to-host escape bugs (CVE-2022-22040 and CVE-2022-22041) from being exploited, although this means managing without USB support inside your guest VMs.

Happy patching!

News

Google announces zero-day in Chrome browser – update now!

by

In the past few days, both Apple and Adobe have published software updates to close off zero-day security holes that were already being exploited by attackers.

Remember that a zero-day exploit is a security bypass, typically one that allows Bad Guys to break in and run or implant software of their own choosing, that was discovered and abused by the attackers before the Good Guys found and fixed it.

In other words, now matter how quickly you update against a zero-day once the patch is announced, you know that someone – and you have to hope that it wasn’t you! – has already been attacked and pwned, even if they’re accustomed to patching promptly themselves.

Simply put, the zero part of the jargon means that there were zero days during which you could have been patched proactively, no matter how hard you tried, because the attackers got there first.

Annoyingly, but perhaps understandingly, both Apple and Adobe made only the briefest of admissions about the zero-days they fixed.

Apple said simply that it was “aware of a report that [CVE-2022-22620] may have been actively exploited”:

Abobe was slighly more forthcoming, admitteding that it was “aware that CVE-2022-24086 has been exploited in the wild in very limited attacks”:

No hints about how or where the attacks were carried out, what the attackers were after, what the attackers made off with, what indicators of compromise (IoC) you could look for in your own logs, how to evaulate your risk, or whether there are any workarounds or mitigations you could apply until you’re sure everything’s been patched.

Now it’s Google’s turn to wave its hand at a just-patched zero-day bug: the company has pushed out the latest Chrome update, using an underwhelmingly Apple-esque remark that it is “aware of reports that an exploit for CVE-2022-0609 exists in the wild”.

Use-after-free bugs galore

Intriguingly, CVE-2022-0609 was only one of five use-after-free coding bugs fixed in this update.

A use-after-free bug happens when one part of a program requests a block of memory to be reserved for its own exclusive access, uses that memory for a while, then relinquishes its claim on that memory block…

…only to carry on accessing that memory anyway, even after it’s been reallocated to some other part of the program, or perhaps even to another program entirely.

Imagine that you’re in the middle of a PowerPoint presentation that you’ve checked carefully and rehearsed plentifully, but just before you click through from slide 4 to slide 5, someone who thinks they’re updating slide 5 of their presentation manages to write their new data into your presentation instead. You’d end up blithely presenting someone else’s content as your own, with no inkling of the impending disaster. Even if that sort of thing happened entirely by accident, due to a genuine mistake by a trustworthy colleague, the outcome would probably be annoying, and might even be embarrassing. But if the other person knew perfectly well what they were doing, and how to orchestrate it, and if they timed their “intervention” deliberately and maliciously, the outcome could be disastrous, and perhaps even career limiting. That’s an analogy of the content crisis that use-after-free bugs can cause, often with malware implantation being the unexpected and unwanted side-effect of an exploitable use-after-free hole.

Why browser zero-days matter

Zero-days triggered by memory mismanagement while the browser is rendering a page are always worrying.

That’s because remote code execution (RCE) holes in a browser often lead to so-called drive-by downloads, where merely looking at a booby-trapped web page could leave you with malware implanted on your computer or your phone.

You will also hear this sort of infection called a zero-click attack, because the attackers don’t need to convince you (or your computer) to do anything more than to view their content – something that’s generally supposed to be safe because it happens entirely inside your browser window.

Most phishing attacks, for example, need to persuade you to fill in and submit a dishonest web form, to open a malicious attachment, or to agree to download and launch a file you weren’t expecting and didn’t ask for.

That gives well-informed users a good chance to avoid the attack, because it generally can’t happen by default, or by mistake.

But a zero-click or drive-by attack can happen “by default”, without giving even the best-equipped user a chance to to say, “No!” and head off the malevolence.

What to do?

Check that you have Chrome (or Chromium) 98.0.4758.102 or later, up from the previous offical build number of 98.0.4758.80.

We can’t tell you whether Edge, probably the next-most-widely-used Chromium-based browser out there, is affected by this bug, and Edge version numbers don’t align with Chrome’s numbering after the initial pair of “major/minor” numbers (in this case, 98.0).

The stable version of Edge doesn’t have an update out yet [2022-02-15T16:10Z], at least in its official Linux repository, where we update from, but we suspect there will be one out soon.

To check whether you’re already running the latest version in both Chrome and Edge, click DotDotDot (the More menu) in the top right, then use Help and About to access the version-plus-update dialog.

Latest Blog

View All
go top