+44 (0)20 86848683

Perpetual IT

News

Adobe fixes zero-day exploit in e-commerce code: update now!

by

Using the Adobe Commerce online selling platform?

Using Magento, the free, open-source variant of the same product?

Buying products from online stores that use either of these?

Using online services that themselves use services that (…repeat up the supply chain as needed…) ultimately depend upon Magento or Adobe’s paid version?

If so, make sure that the site where Magento or Adobe Commerce is actually running has downloaded and applied Adobe’s latest patches.

Note that these are so-called out-of-band updates, meaning that they’re new enough not to have made it into last week’s regular Patch Tuesday updates, but critical enough not to be left until next month’s Patch Tuesday comes round.

The reason for the urgency is obvious from Adobe’s own security report:

Adobe has released security updates for Adobe Commerce and Magento Open Source. These updates resolve a vulnerability rated critical. Successful exploitation could lead to arbitrary code execution.

Adobe is aware that CVE-2022-24086 has been exploited in the wild in very limited attacks targeting Adobe Commerce merchants.

Upgrade now

Of course, the words “limited attacks targeting merchants” shown above don’t automatically imply that “minimal damage has been done”.

Anyone who remembers the recent Colonial Pipeline ransomware incident will know how extensive the knock-on effects of a single cyberattack can be.

Also, until we know what the attackers did when they exploited this hole, we can’t tell how much data they made off with, how many users might be affected, or what follow-up crimes – such as identity theft, password recovery and account takeover – the crooks might be able to try next.

According to Adobe, it seems that any Adobe Commerce or Magento installation running a version later than 2.3.3 that hasn’t received the latest patches is vulnerable.

The patches provided are listed as tested for all of these versions: 2.3.3-p1 to 2.3.7-p2, and 2.4.0 to 2.4.3-p1.

Quite what version number will show up after patching we can’t tell you; the patch files themselves are identified as 2.4.3-p1_v1, so our assumption is that’s the version string you’ll see.

If you’re a Magento user and you’ve applied the patch, please let us know in the comments below what version identifier shows up after the update. You may remain anonymous if you wish.

Hostile input can be harmful

Once again, the bug boils down to what MITRE refers to as CWE-20, which is shorthand for the more meaningful words improper input validation.

Web services, notably those dealing with e-commerce, depend on accepting data from users, not least because you can’t process a credit card transaction without a minimal set of inputs, such as the cardholder’s name, card number, expiry date, and so on.

Other data relevant to the transaction might be discount codes, customers numbers, and more.

Although the vast majority of visitors will do their best to submit correct data (they generally want their transactions to go through, after all), there’s little to stop an attacker from supplying unusual, weird, malformed, or unlikely data instead, just to see what happens.

As the old joke goes, “A penetration tester goes into a bar and orders 1 beer, 2 beers, 999,999,999,999,999 beers (one quadrillion minus one), -1 beers, zero beers and a lizard.”

If incorrect or invalid data is accepted and processed by an e-commerce server, the outcome could be that the order goes awry, such as sending you two items for the price of one, or telling the stock control system it’s run out of stock even though nothing was bought.

Clearly, both of those would be bad for the retailer: one would allow items to be stolen at will; the other would turn away customers whose orders would otherwise have gone through fine.

But the result might also be that the wrong database file gets accessed and revealed; that an otherwise prohibited and potentially dangerous script gets run instead of an authorised, safe one; that a configuration file gets incorrectly modified to open a new security hole for later; or even that the attacker uploads a malware file and infects the server right away.

In these cases, the risks are not only bad for the retailer, who might suffer a data breach that would undermine trust and require disclosure to the regulator, but also bad for customers, whose data might be stolen and sold on to other cybercriminals for further abuse.

What to do?

  • Patch at once if you’re a retailer who uses one of these products yourself, or a service provider who offers one of these products in the retail software supply chain.
  • Watch your statements carefully if you’ve shopped recently at a site driven by Magento or Adobe Commerce.
  • Ask your favourite retailers or suppliers what e-commerce products they use if it’s not obvious from their website.
  • Keep your eyes open for follow-up information from Adobe that gives actionable details about CVE-2022-24086 and the attacks known to have exploited it.

Determining exactly what happened after an attack, especially if it was triggered via a zero-day exploit – which implies that at least the opening pages in the criminals’ playbook include things that no one’s seen before – can be a complex exercise.

Let’s hope Adobe is able to figure out the whole story and report on it soon…

News

Power company pays out $3 trillion compensation to astonished customer

by

Storm conditions in November 2021 in northern and north-eastern parts of the UK brought down powerlines in some areas, leaving many homes without electricity for several days.

British power companies, which, for better or worse, are privatised rather that state-run, are required to pay out compensation to customers who did not receive the service promised in their contract…

…and so the after-effects of Storm Arwen left Northern Powergrid, which serves electricity consumers in north-east England, with payouts to make.

“Storm season” in Ireland, the UK and The Netherlands officially starts in September each year, with severe storms referred to by names starting with a pre-arranged, multilingual list of names starting A, B, C, and so on (excluding Q, U, X, Y and Z). For 2021-2022, the list starts Arwen, Barra, Corrie; runs through Logan, Méabh, Nasim; and ends, if needed, with Tineke, Virgil and Willemien.

That’s a LOT of money

Let’s hope that the software code controlling Northern Powergrid’s power delivery has been reviewed and tested more thoroughly than the account compensation software that runs when power delivery fails.

That’s because the company recently issued some of the most astonishing refunds ever offered to customers anywhere.

Gareth Hughes, for example, tweeted about his recent payout:

Here’s a cropped image of the payment cheque itself, cleaned up and with perspective correction applied:

Do you dare to try the QR code, assuming that it’s still legible after all the image transformations applied?

There are two obvious problems with the software that generated this cheque:

  • The words and numbers don’t match. The software failed to notice that it had generated a textual version of the number that simply wouldn’t fit in the allowed space. (We assume, indeed, we hope, that receiving bank would invalidate the cheque on those grounds alone. If not, why bother demanding that both numbers and words be used on the document in the first place?
  • The amount to be paid out is slightly larger than the annual GDP of the entire UK. The software failed to notice that it was generating a cheque that could not conceivably be cashed.

There’s a third exciting aspect to the software:

  • There’s room for two more decimal digits, if needed. This mistake could therefore have been up to 430 times more serious, given that the upper limit on the cheque, which apparently has a pre-printed denomination in Pounds Sterling, is a tidy £999,999,999,999,999. (One quadrillion minus one.)

According to a report on the Guardian website, 74 customers received absurd payments of this sort, which Northern Powergrid blamed on software that consumed the customer’s meter ID (in Gareth Hughes’s case, apparently some sort of 13-digit serial number) instead of the compensation amount.

Whether that was down to a column mismatch in a hand-exported CSV file (we’ve all done it, though perhaps never quite as excitingly as this) created for the admittedly unusual circumstance of storm-related compensation, or a more fundamental software bug that could occur at other times…

…we have no idea.

Danger, Will Robinson

Things could have worse.

For example, if the misaligned column used as the payment amount had been “time of last meter reading” (e.g. 14:30), then customers might have received cheques for, say, £1430 (we expect the actual amount due would be in the low hundreds of pounds) and have cashed them in good faith, only to be chased to refund the amount later on.

Or a future bill could have had the numeric value of the last reading itself transposed into the amount due column, leaving customers whose meters showed, say, 493286, facing bills of £4932.86 that might leave them scrambling to prove they hadn’t used that much electricity in the past month.

But how do you prove a negative?

It would be fairly easy to show that you had been busily mining cryptocoins at full-tilt for several weeks, simply by producing blockchain entries to supprt your claim; or to demonstrate that you had, indeed, been growing high-quality hydroponic vegetables for the artisan vegan restaurant market, by showing invoices from the eateries concerned.

But if you’d been sitting quietly at home, using the energy consumed by a typical household for typical household purposes, how could you prove you hadn’t been doing any of those otherwise perfectly lawful things?

At least Northern Powergrid apologised to affected customers, thanked them for reporting the glitch, and promised to figure out what happened.

We’re interested to hear what went wrong: we hope the company shares its findings, because there’s probably something in the story from which we can all learn a lesson.

What to do?

In the meantime, our advice to programmers is:

  • Validate your outputs, not just your inputs. In this case, of course, the blunder should have triggered error-detection code on the way in. But don’t just assume that if the input passed muster, the output must therefore pass muster too. If you have two chances of catching one mistake, take both of them!
  • Don’t ignore warning signs. In this case the words came out longer than the maximum length allowed. Even if this cheque had been for a genuine amount, it shouldn’t have been printed anyway because it didn’t match its own specifications.
  • Test special-case code, if you have any, at least as well as everything else. The fact that this blunder seems to have been limited to just a few customers suggests that an unusual or little-used process may have been invoked (severe storm damage is, thankfully, quite rare in the UK).

Oh, and if you do receive a payout from a company you do business with that is more than you expected, don’t be in too much of a hurry to spend it.

In this case, the error was fortunately both obvious and amusing…

….but if an overpayment is by hundreds or thousands instead of billions or trillions, it’s still not automatically yours.

You’re very likely to have to pay it back unless you can show that you were reasonably expecting the amount at the time you received it, and thus that you were reasonable to assume it was yours.

News

Apple zero-day drama for Macs, iPhones and iPads – patch now!

by

Here on Naked Security, we’ve been lamenting the mysterious nature of Apple’s security updates for ages.

For example, even when widely-known security problems appear in components that are part of Apple’s operating system, Apple routinely refuses to say when, or even if, it plans to address the issues itself.

Back in February 2013, for instance, a dangerous bug was found and patched in the widely-used sudo command:

As you probably know, sudo is a program that allows you to substitute the current user and do a command (strictly, su here stands for setuid(), the Unix/Linux function used to switch between accounts).

Because the most prevalent use of sudo is to switch up to the root account, rather than down to a less privileged one…

…any authentication bypass bug in sudo should be considered critical, because it could provide anyone who’s currently logged into your computer with a trivial and apparently official way to to turn themselves instantly into an administrator.

Quickly patched by most

The bug in this case, CVE-2013-1775, was patched almost immediately by the sudo project, and the update was distributed almost immediately and universally throughout the BSD and Linux ecosystems.

Apple, however, infamously said nothing, even though the bug affected its own products.

After six months of silence, a public exploit appeared for use with the popular cybersecurity attack tool Metasploit, perhaps in an effort to squeeze Apple into action:

By not saying anything at all – and that is Apple’s official policy on cybersecurity updates: no comment until after the fix is out – the company leaves its users unable to figure out whether Apple:

  • Has yet to notice that the problem even exists.
  • Knows about the problem but has figured out that its own products are immune.
  • Knows about the problem but has decided it won’t be fixed.
  • Knows about the problem but can’t figure out how to fix it.
  • Has a workaround for the time being but won’t tell anyone about it.
  • Is working on a fix but won’t say so.

Slowly fixed by Apple

In the sudo bug case, Apple did eventually come to the party, and updated its own products in September.

Of course, Apple’s style of public security discourse means that we still don’t know whether the company sluggishly took seven months to implement a fix that took other operating system distros just a few days to sort out, or worringly decided to ignore the bug it altogether until the Metasploit exploit forced its hand:

The flip side of Apple’s “cybersecurity cone of silence” is that security patches that arrive suddenly – as welcome as they are if they fix critical problems – often show up with uncertain and incomplete explanations that leave users and network administrators with little to work with.

When a zero-day security hole gets patched, how do you go threat hunting to see if you were one of the unlucky people who already got targeted by cybercriminals…

…if you have next to nothing to go on even after the update is available and you know you’re safe now?

That’s where Apple users are today, following last night’s release of emergency updates for macOS, iOS and iPadOS.

If this were a Microsoft patch, we’d probably be referring to it as “out of band”, a jargon term commonly used to denote that an update is a critical one-off that just couldn’t wait for the next round of scheduled updates, and therefore doesn’t fit into the expected cycle.

Of course, in Apple’s world, there is no “band” that an individual update can be “out of”, given that all its updates arrive unnannounced and unexpected.

Even more urgent and important than usual

Nevetheless, this one feels even more urgent and important than usual, given that there is just one bug fixed, dubbed CVE-2022-22620, that affects Apple’s WebKit browser substrate, and is described with these words:

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: A use after free issue was addressed with improved memory management.

You should assume this means “booby-trapped web pages could pwn your phone in a zero-click attack.”

A zero-click browser attack means that just looking at a web page, even if you don’t download anything from it or see any warnings or pop-ups on it, could steal private data, make unauthorised changes, or implant malware, including spyware.

(You may also have heard this sort of attack, when used to infect your device with malware, referred to by the jargon term drive-by download, where just window-shopping a website could leave you unknowingly infiltrated.)

Remember that bugs in WebKit always affect Safari, which is based on WebKit, and often affect apps with browser-like features, because those apps often use WebKit as a utility library to simplify their own coding.

Also, bugs in WebKit also affect every browser on iPhones and iPads, even non-Apple browsers like Firefox, Edge and Chrome, because Apple won’t allow other vendors’ browsers into the App Store if they bring their own low-level browser engine with them: under the surface, it’s WebKit or nothing.

What to do?

  • Update to Monterey 12.2.1: If you have a Mac that is running the latest macOS version, this is for you. See Apple bulletin HT213092.
  • Update to iOS 15.3.1 or iPadOS 15.3.1: If you have a recent iPhone or iPad on the latest version, this is what you need. See Apple bulletin HT213093.
  • Update to Safari 15.3*: For users of the previous two macOS versions, Catalina and Big Sur, the patch comes as a Safari-only update, and doesn’t change your operating system build number. See Apple bulletin HT213091.

Users of the previous two iOS and iPadOS versions, iOS 14 and iOS 12, you’re out of luck yet again: Apple has once more maintained its oath of silence about your situation.

Are you unaffected because this bug isn’t in older WebKit code? Affected but won’t get the update for a while yet? Or simply and silently unsupported and never going to get a fix for this or any other future bugs? (Those are rhetorical questions: there’s no way to tell.)

In the list above, you’ll note that we wrote Safari 15.3* for Catalina and Big Sur users (that asterisk is not a typo), which is how Apple denotes the patch in its own bulletin.

Annoyingly, the version you already have is Safari 15.3, and the version you’ll have after updating is still Safari 15.3.

The only way to tell the old and new verions apart is to do Safari > About, and check the five-part version meganumber that comes up: if it ends 4.9.1.7 then you are out of date; if it says 4.9.1.8 then you’re patched.

Surprisingly, perhaps, the copyright notice still says 2003-2021 in both versions, as though Apple knew about this bug and coded up the fix last year, even though there have been numerous other WebKit bugs fixed in the interim:

Left. Catalina before the update. Right. Catlina afterwards.
News

S3 Ep69: WordPress woes, Wormhole holes, and a Microsoft change of heart [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. WordPress plugins, cryptocrime, and Microsoft web safety.

All that more on the Naked Security Podcast.

[MUSICAL MODEM]

Welcome to the podcast, everybody.

I am Doug; he is Paul.

And, Paul, we have an exciting lineup of stories we’ll get to today.

But first, we like to begin the show with a Fun Fact.

For those of you that play chess… anyone who’s played chess knows that the queen is the most powerful piece on the board.

It wasn’t always that way, though.

No: initially, the queen could only move one space diagonally; she was then upgraded to two.

However, in the late 1400s, Spain’s Queen Isabella led an improbable come-from-behind victory at the Siege of Baza.

And, from that point forth, the queen became the strongest piece in chess.

How do you like *that*?

DUCK. Boy, so if ever there’s a Pawn Uprising… presumably, pawns will be able to move in circles, perhaps…

DOUG. [LAUGHS]

DUCK. …or retreat if they need to?

DOUG. Well, that would be something!

We’ll talk a little bit about chess later in the show… and not to foreshadow too much, this does have a link to our This Week in Tech History segment.

DUCK. Does it involve Alan Turing?

DOUG. It involves his influences a bit, but no.

DUCK. OK.

Onwards and upwards, Doug…

DOUG. The reverse of upwards: a downward feeling in the Elementor WordPress plugin.

This is a popular website creation toolkit that many people use to drag-and-drop their WordPress sites into the perfect harmonious design…

…and something bad happened.

A lesson in data validation, which we’ve talked about – it seems many, many times before.

But Paul, what happened here?

DUCK. Well, it’s not the Elementor tools themselves that had the bug; it’s a plugin that essentially hooks up your standard WordPress installation with the Elementor toolkit.

It’s called, imaginatively, Essential Addons for Elementor.

Like you said, the idea is that this is a whole load of templates and pre-built stuff that makes it easy for you to drag-and-drop funky things such as, “Hey, I want a timeline.”

So, instead of writing loads of JavaScript, you just say , “Make a timeline out of my posts,” and when you visit that page, it will magically do all the work for you.

Also: image Galleries; good looking forms for e-commerce sites… so you can understand why this is quite popular for people who want a good-looking site, but don’t want to spend seven weeks doing JavaScript hacking.

And this Essential Addons for Elementor plugin?

Unfortunately, it had an input validation problem whereby you could provide input in a URL that it trusted, even though it shouldn’t.

It built a file name out of some data that you’d sent, and it didn’t check that you hadn’t put the traditional funny characters in that file name: ../../../../ and so on…

…which takes you up-up-up-up, and then across, and then down-down-down-down, thus potentially allowing you to make an innocent-looking web request to somebody’s site and retrieve a file that has nothing to do with the website itself.

For example: the username database (the /etc/passwd file on Linux), or somebody else’s files inside the WordPress setup.

So, you might have another user, or a second customer, with files in a directory name you could guess, and maybe you could just hop over to their part of the site and retrieve their data, or data about their customers.

And because this was part of a normal connection by a user, rather than someone actually logged in, it meant that essentially anybody could do it.

DOUG. This is tough, because these WordPress plugins – there are many of them…

DUCK. Thousands. Tens of thousands.

DOUG. …and they’re generally trusted.

If you’ve never worked with WordPress, before you install one of these plugins, there’s a little page with reviews and the number of downloads.

So, something like this that has a large number of downloads, and four or five stars – you can see the comments on it, too: you generally trust these when you’re installing them.

And it’d be very hard to know to look for something like this when you’re installing one of these plugins.

This may have taken a lot of people by surprise.

DUCK. I think that’s the problem, isn’t it?

That the user reviews aren’t penetration tests…

DOUG. [LAUGHS] Yes.

DUCK. or code reviews, or security oversight.

They’re just people saying, “Look, I tried this: it worked really well; it set up a beautiful website; I haven’t had any problems with it.”

And what they mean is, “Well, nobody’s found a security hole yet. Or if they have, they haven’t used it against my site. Or they have used it against my site, but I haven’t even noticed yet.”

DOUG. Very good – if you’re using the Essential Addons for Elementor plugin, make sure you’re running 5.0.6.

And for web developers, we’ve been saying this again and again… what should they do, Paul?

DUCK. [CLERICAL VOICE]. Validate Thine Inputs.

DOUG. Please!

DUCK. Now, the irony here was that when this bug was reported to the creators of the plugin, they quickly produced a patch.

But that didn’t quite close off all the ways that you could sneak funny characters into your web request and cause this “wandering around the file system” escape.

And then they did another patch, and *that* didn’t close it properly.

So, I think the bug was found in 5.0.3; and then they quickly had 5.0.4; and then 5.0.5; and subsequently 5.0.6.

We saw that with Log4Shell, didn’t we?

DOUG. We did.

DUCK. The quick-fix did a great job, but it didn’t do a complete job.

By the way, Doug, if this sounds like, “Oh, well, all you can do is go and sneakily read files that aren’t supposed to be accessible”, remember, particularly in PHP-type installations like WordPress (but not only PHP – this could be the case with IIS if you have Active Server Pages done with, say, Visual Basic Script)…

…sometimes, when you read a file on the other end, if the file has a particular extension, like .php, or .aspx, or whatever it is for the web server being used, what that tells the server is, “Don’t read in this file and return the content of the file.”

What it’s saying is, “Read this file, *run it as a local program*, take the output the program creates and send *that* back to the user.”

So, the problem is that when you have a file escape like this, that lets you read files you’re not really supposed to, it can also often lead to remote code execution.

Because if you can guess the names of other scripts (they may be ones that only an admin is supposed to trigger), and you can reach out and trigger those from an unauthenticated web connection…

…you may be able to get the server to spill data, or even let you run commands that are supposed to be off-limits to you.

You could actually get information about the whole server; about the whole WordPress installation; or even run commands that change content, put malware on there, etc. etc.

DOUG. All right, that is: Elementor WordPress plugin has a gaping security hole – update now on nakedsecurity.sophos.com.

And now we will deftly slip to this “Wormhole crypto trading” story.

This is a lot of money changing hands here, and it’s an odd story!

DUCK. These things are always odd stories, aren’t they?

DOUG. I did start reading this article and I was like, “Wow, $340,000,000! That’s got to be some sort or record…”

And then I was like, “No, Poly Networks was almost twice that. It’s no big deal. Just gone.”

DUCK. And I find myself going back to my own articles, even the day after I’ve written them, and thinking, “Oh dear, I’ve made a terrible blunder. Silly me. I’ve accidentally written an old story as if it were new.”

DOUG. [LAUGHS]

And then you think, “No, hang on, this is completely different. The same badness happened.”

I don’t know whether braggadocio or bravado is the right word… this company, on its website, if you go to their main page, has this big text, “THE BEST OF BLOCKHAINS”.

Which led me to think of Charles Dickens, Doug.

DOUG. [LAUGHS]

DUCK. I couldn’t think of anything but A Tale of Two Cities.

[PRETENDS TO READ FROM THE NOVEL]

It was the best of blockchains, it was the worst of blockchains, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to heaven, we were all going direct to the other place – in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only.

[DEJECTED] $340,000,000… due to some smart contract coding issue that apparently hadn’t been foreseen.

And once again, like the Poly Networks hack, they sent a zero-value Ether transaction, where the transaction existed only to have a message in it:

[QUOTING AGAIN]

We noticed that you were able to exploit the Solana VAA verification and mint tokens. We’d like to offer you a whitehat agreement.

I seem to remember that Uber got into an awful lot of trouble for doing that retrospectively…

DOUG. Indeed.

DUCK. …but maybe it’s different if you make the offer publicly?

And we will present you with a bug bounty of $10 million for exploit details.

Oh, and returning the money you have stolen.

DOUG. Yes! Wow!

DUCK. Apparently it didn’t work this time, Doug.

As far as I know, they haven’t heard anything.

DOUG. We have some tips at the end of the article.

This is a great one that you’ve said before, but you expanded upon at this time: “If you’re getting into cryptocurrency, never invest more than you can afford to lose.”

And by “afford to lose”, you don’t mean, “I put $100 into this crypto; hopefully I make $110 and it doesn’t go down to $90.”

You mean it could get stolen, and it could be *zero*.

DUCK. Here, I think the expectation is, “I’m putting in $1,000; if it goes down to half, that would really hurt, but it wouldn’t leave me bereft. And I might get some advance warning. So I’ll just keep my eye on it.”

And then you go to the kitchen to make yourself a cup of coffee, and you come back…

DOUG. [LAUGHS]

DUCK. …and *poof*!

They’ve spun the wheel; black came up; your red bet’s gone – whatever you put in.

If you know that if it comes out at zero, it’ll hurt like crazy *but it won’t derail your life*, then you’re OK.

When it comes to cryptocurrency, how did Charles Dickens put it?

“It was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness,” Doug.

It’s hard to know how well it’s going to pan out for you.

DOUG. And another piece of advice you have here, which is great with all these cryptotrading companies popping up: “Make sure to look for ones that will allow you to hold your crypto in your own offline cold wallet.”

DUCK. Yes, when you’re putting crypto tokens somewhere where they can be live-traded, you have to trust that other person with the wherewithal to trade your currency for you *by accident or by design*.

That’s the idea of a hot wallet.

So, maybe, if you are going to test the waters, test them a little less aggressively at first, where you can actually make the investment and keep the result securely at home…

(Don’t lose the encryption key! Obviously, that’s going to be a problem – that will be like setting fire to banknotes.)

…but it does mean that you’re not just putting the tokens where you’re relying on somebody else not making a programming blunder.

DOUG. All right, we will keep an eye on that.

Something tells me the story may not be finished, but that is: Wormhole crypto trading company turns over $340,000,000 to criminals.

And it’s time for This week in Tech History.

We talked a bit about chess earlier in the show, and this week, in February 1996, IBM’s Deep Blue supercomputer became the first machine to beat a human chess champion.

Garry Kasparov lost two games of a six-game match against Deep Blue.

It would take a rematch, in May 1997, for Deep Blue to win the match outright, three-and-a-half games to two-and-a-half games. (I’m guessing a half-game is a draw.)

And I have a bonus Fun Fact for everyone, Paul: researchers at Carnegie Mellon said, in 1957, that it would only take ten years for a computer to be able to beat the reigning world chess champion of the time.

It actually took 40 years – they did not realise how hard it would be to program computerised chess.

I did also read, ironically – it may have been the match that he lost outright or one of the games that he lost – that there was a bug in the code, and the computer made this weird move that Kasparov didn’t understand.

It was an incomprehensible, weird move.

And he thought, “Oh, this is some sort of brilliant thing I haven’t thought of.”

And so he panicked a little bit, and that’s what cost him.

DUCK. Really? [LAUGHS]

DOUG. That came because of a computer bug doing something that a human wouldn’t have done.

So, not all bugs are bad! I guess it’s more of a feature…

DUCK. It still doesn’t answer the question, “Can machines think? !

DOUG. [LAUGHS]

DUCK. That’s why I was thinking of Alan Turing earlier.

DOUG. Yes.

Apparently, I read, researchers that are working on computerised chess say it still hasn’t been cracked; it still hasn’t been solved.

There are still so many permutations.

But one thing that people are trying to solve at Microsoft is web safety.

We’ve got a two-pack of web safety stories, so let’s start with the App Installer one.

DUCK. They’re both rather interesting!

One of them deals with a recent cybersecurity incident.

In fact, SophosLabs… I think we were among the first people to investigate this, for the reason that a whole load of people at Sophos, myself included, received the email in this particular cybercriminal attack.

And Naked Security readers may remember – this was an article from last November which we entitled Customer complaint email scam preys on your fear of getting into trouble at work.

And I think we talked about this on the podcast, didn’t we?

DOUG. Yes.

DUCK. Where it was the “Sophos Main Manager Assistant” – I remember you thought that was a bit of a joke, because there was no such job title…

BOTH. [LAUGHTER]

DUCK. But it was, “Hey, there’s a customer complaint against you. Why didn’t you tell us? We’ve got a crisis meeting! You should have told me! You’d better read this… you’d better see what the customer is saying about you.”

And there’s a link, and it goes to a PDF file.

Except the PDF file… well, you need to install a program – it’s an “Adobe PDF component”.

But it’s very different to other traditional executable downloader phishing scams.

It didn’t just go, “Oh, you need this new codec: download this executable and run it”, because everyone knows that’s a terrible idea.

It actually used a system that is available to use on your own web server, but that is probably more closely associated in people’s minds with how it works when you go to somewhere more trusted – or at least vetted – like the Microsoft Store.

Instead of an https:// link, you get a link that’s ms-appinstaller://

And if you click one of those on Windows, it doesn’t just download the file, it launches and processes it in the App Installer utility, which gives you a more believable experience than just, “Hey, download this program and run it.”

Firstly, the app has to be digitally signed.

Except that it’s just the App Bundle that’s digitally signed, and the name that shows up for the program – in the case we examined, it just said “Publisher: Adobe Inc” – comes up with “Trusted app”, with a little green checkmark.

But if you clicked on “Trusted App”, the company name that came up was an accounting firm in the UK.

Seems a bit weird!

However, it *was* a real company, as far as we could tell; it was a real digital signature.

Somehow the crooks had got this, and just by signing the App Bundle, they could basically deviate someone – who might otherwise be quite suspicious about downloading an installer – into a process that looks much more legitimate.

Perhaps more legimate-looking than anything they’ve ever seen before if they’d never use the Microsoft Store.

The other idea of an App Bundles is that it’s like an “ueber-ZIP” file

It actually contains more than you need, so it’ll have versions for different flavors of Windows; different chipsets: if you’ve got ARM versus Intel, it’ll get the right one for you.

So it feels like the operating system is in charge of the process: this isn’t just “download this file, stick it on your desktop and then double-click it.”

Microsoft admitted that this was considered a vulnerability: it got a CVE number, and they gave out some mitigations about how you could control this, such as locking people down so the process only worked if you went to the Microsoft Store.

Well, finally they’ve decided, given the kind of abuse that this has attracted from crooks, given the fact that they can make things look much more trustworthy than they really are… they’re actually going to block ms-appinstaller:// URLs by default from random websites.

So, it’s a feature that Microsoft really liked, that they claim was popular with vendors – I can see why: you build the package, and then when the download happens, it’s more likely to work properly for the user.

Basically, if you have been using this App Bundle process for a prepackaged app rather than just an old school installer, you may need to change your ways.

Because Microsoft has basically deliberately broken a feature in its own operating system… for the greater good of all.

How about that, Doug?

DOUG. It seems consumer friendly, although I’m sure it’ll cause a little consternation against software developers that are using App Bundles to distribute their software.

DUCK. Yes, Microsoft has said that it wants to keep the principle and the protocol, but find a better way of doing it.

Like we said last week, when you have things that make cybersecurity easier, sometimes you end up making it *too* easy.

And if that were OK, we’d all have two-character passwords, Doug.

DOUG. [LAUGHING] People would still forget their passwords!

OK, that’s: Microsoft blocks web installation of its own App Installer files.

Then, another exciting story of things being turned off by default…

DUCK. Yes!

Having written that story about App Installer (I think I wrote that yesterday), when I woke up this morning, I thought, “Oh, well, I wonder what I’ll be writing about today. Microsoft changed the world yesterday.”

And I had a look, and, “My golly, it’s like a bus! You wait for years, and then two come along at once!”…

DOUG. [LAUGHS]

DUCK. …which is the way of traffic.

Maybe these two things are related: somebody [at Microsoft] decided to approve both of these changes at once.

But this is, in my opinion, a much longer-overdue default change.

And it is that – if you get an Office document via the internet, e.g, you receive it as an email attachment, or download it from the web, and then open it…

Instead of getting that warning, the yellow warning, that says, “There are macros in here; it could be bad. Click here for bad things to happen”, and everyone clicks there, and the crooks have little arrows saying, “Yes, you should click this button! It’s really important! This will improve your security”…

Instead of having that by default, but an option that admins can set that says, “No, don’t allow it at all”…

…they’re flipping that round.

At least, they’re flipping it round by default in *some* versions of Ofice over the next twelve months, on *some* operating systems, for *some* of the apps in the Office stable.

So this is still very much an incomplete fix – but I’m not going to knock it.

Basically, unless you go out of your way to allow your users to do this on a corporate network, and unless you go fiddling around as a user at home, then if you get a document from the internet and you open it up just to see what’s in it, you won’t get that “Enable Content” button.

You will get a red pop up… a pink pop up that says: “Security risk. Microsoft has blocked macros from running because the source of the file is untrusted. End of.”

A lot of people in the cybersecurity industry have been wanting something like this in Office since about 1995-and-a-half… it was towards the end of 1995, when Word macro viruses came out.

Then we had the combined Office suite in 1997, where there was the Visual Basic for Applications macro language, where the same code worked on multiple operating systems and in multiple document types, so you could use very similar, identical code in Excel, and in PowerPoint, and in document files.

Ever since then, there’s been this call, “Why don’t you just make this optional? Why don’t you let someone have a version of Office where they just say, ‘You know what? I know macros are lovely. I know they’re super-powerful. I know I paid for them, *but I want to install without them*.”

I’d like to have the supercharger disconnected, please. If I really need it, I’ll go in and get the mechanic to fit it again, if I’m willing to burn 40% more fuel in return for bigger wheelspins.

BOTH. [LAUGHTER]

DOUG. So, a step in the right direction?

DUCK. Absolutely.

Well, *if* you’re using Office 2022.

That’s going to roll out over the coming twelve months, I believe, so this feature will only start in April 2022, and only the early adopters will get it in their versions of Office at first…

…but I think it’s the cultural change that is big.

DOUG. All right, that is called: At last! Office macros from the internet to be blocked by default.

If you’d like to read more, it is on nakedsecurity.sophos.com.

And, as the sun slowly sets on our episode this week, it’s time for the Oh! No!

Reddit user WeldinMike27 writes:

“Years ago, my wife worked at a local TV station, helping people with the changeover from VHF to UHF signals.

Some TVs required flicking a switch on the back, or just doing something behind it.

One gentleman called up, very agitated, claiming that the changeover had caused a ‘split’ in the picture.

Literally, one side of the screen was a different definition than the other side.

My wife and the local tech support were pulling their hair out, trying to figure out what might have happened – obviously, nothing like this had happened before.

It took ages and some very heated discussions until the gentleman finally realised that his TV was coated in dust.

And while playing around at the back, he’d rubbed half the layer of dust off one side of the screen.”

DUCK. [LAUGHS] Oh, dear!

DOUG. If you remember those old tube TVs, they were just like dust magnets!

DUCK. Because it’s all electrons flying around, isn’t it?

So it’s going to get charged up.

UHF… that’s going back a way, Doug!

DOUG. Those were the days.

Well, they weren’t, but they were days. [LAUGHS]

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 one of our articles; or hit us up on social @NakedSecurity.

That is 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

Self-styled “Crocodile of Wall Street” arrested with husband over Bitcoin megaheist

by

The story as we know it now sounds simple, but the investigation wasn’t.

It all started, according to court papers, with a security breach reported in August 2016 by the Bitcoin exchange Bitfinex.

(The court application for an arrest warrant refers to the company only as “VCE”, short for Virtual Currency Exchange, but the US Department of Justice explicitly identifies VCE as Bitfinex.)

The company’s original breach notification didn’t record how much cryptocurrency had vanished from its coffers, but it quickly emerged that the virtual bank robbers had made off with close to 120,000 bitcoins: BTC 119,756, to be precise, worth a whopping $72 million at the time:

Colossal Cave Adventure

After an investigation that sounds like the 1970s computer game Colossal Cave Adventure (“you are in a maze of twisty little passages, all alike”), law enforcement says that the stolen funds were spread around in various ways:

  • Split between thousands of bitcoin addresses in cold wallets, some stored in the cloud.
  • Moved into darkweb accounts on now-defunct underground site Alpha Bay.
  • Spread amongst numerous cryptocoin accounts hosted on 10 other cryptocoin exchanges.

Ultimately, claims the investigation, many of the accounts created and used for shuffling the stolen funds around were traced back to a New York couple who have now been arrested on fraud and money laundering charges: Heather Morgan, 31, and her husband Ilya Lichtenstein, 34.

Technology website Engadget identifies Morgan as self-styled rapper/artist/activist/entrpreneur RazzleKhan, whose still-active website leads with:

The infamous Crocodile of Wall Street strikes again! More fearless and more shameless than ever before, she’s taking on everyone from big software companies to healthcare to finance bros.

Engadget even links to a video of one of Morgan’s YouTube rap songs in which she riffs: “Spearfish your password/All your funds transferred”, but that video is now marked private, so you can no longer watch for yourself.

Who hacked Bitfinex?

Whether Morgan and Lichtenstein pulled off the original hack against Bitfinex isn’t addressed in the arrest warrant affidavit.

In orotund legalese, the allegations deal not with the hack itself but what happened thereafter:

[This criminal investigator] submits that there is probable cause to believe that ILYA “DUTCH” LICHTENSTEIN and HEATHER MORGAN violated 18 U.S.C. § 1956(h), which makes it a crime in relevant part to conspire to conduct or attempt to conduct a financial transaction involving the proceeds of specified unlawful activity, knowing that the property involved in the financial transaction represents the proceeds of some form of unlawful activity, and knowing that the transaction is designed in whole or in part to conceal or disguise the nature, location, source, ownership, or control of the proceeds of specified unlawful activity. […]

[The investigator also] submits there is also probable cause to believe that ILYA “DUTCH” LICHTENSTEIN and HEATHER MORGAN violated 18 U.S.C. § 371, which makes it a crime in relevant part for two or more persons to conspire to defraud the United States, or any agency thereof, in any manner or for any purpose, and to do any act to effect the object of the conspiracy.

Simply put, the arrested couple are accused of trying to shift around cryptocurrency that they knew to be stolen, and of telling a bunch of lies along the way to make it sound as though they had legitimately acquired the cryptcoins they wanted to trade.

The maximum penalty for the former offence is 20 years in prison; for the latter, 5 years. (Note, however, that maximum sentences are unusual.)

Cracked at last!

One fascinating part of this obviously lengthy investigation (and, presumably, one reason why the arrest warrant was only issued on 2022-02-07) is that investigators managed to trace data relevant to the case to a cloud storage service account belonging to Lichtenstein.

A search warrant meant that law enforcement already had copies of those files – the affidavit doesn’t say when they were acquired – but couldn’t do much with them…

…until the last day of January 2022, when the investigation came up trumps:

The majority of the stolen funds remained in [this wallet] from August 2016 until January 31, 2022. On January 31, 2022, law enforcement gained access to [the wallet] by decrypting a file saved to LICHTENSTEIN’s cloud storage account, which had been obtained pursuant to a search warrant. The file contained a list of 2000 virtual currency addresses, along with corresponding private keys. Blockchain analysis confirmed that almost all of those addresses were directly linked to the hack.

Bingo!

Law enforcement then got a “probable cause” warrant to seize the funds in those 2000 addresses, which came to a total of BTC 94,636, just under 80% of the amount original plundered from Bitfinex.

Once the coins were safe, the arrest warrant application went ahead.

As you can imagine, law enforcement isn’t saying how long it took to crack the encrypted data to recover the bitcoin private keys, or what sort of encryption was used, or how the cracking was done.

But the astonishing fact is that those recovered bitcoins, worth about $57 million when the heist took place, are today valued at just over $4 billion.

Latest Blog

View All
go top