Perpetual IT

Even if you’re not a MOVEit customer, and even if you’d never heard of the MOVEit file sharing software before the end of last month…

…we suspect you’ve heard of it now.

That’s because the MOVEit brand name has been all over the IT and mainstream media for the last week or so, due to an unfortunate security hole dubbed CVE-2023-34362, which turned out to be what’s known in the jargon as a zero-day bug.

A zero-day hole is one that cybercriminals found and figured out before any security updates were available, with the outcome that even the most avid and fast-acting sysadmins in the world had zero days during which they could have patched ahead of the Bad Guys.

Regrettably, in the case of CVE-2023-34362, the crooks who got there first were apparently members of the infamous Clop ransomware crew, a gang of cyberextortionists who variously steal victims’ data or scramble their files, and then menace those victims by demanding protection money in return for suppressing the stolen data, decrypting the ruined files, or both.

Trophy data plundered

As you can imagine, because this security hole existed in the web front-end to the MOVEit software, and because MOVEit is all about uploading, sharing and downloading corporate files with ease, these criminals abused the bug to grab hold of trophy data to give themselves blackmail leverage over their victims.

Even companies that are not themselves MOVEit users have apparently ended up with private employee data exposed by this bug, thanks to outsourced payroll providers that were MOVEit customers, and whose databases of customer staff data seem to have been plundered by the attackers.

(We’ve seen reports of breaches affecting tens or hundreds of thousands of staff at a range of operations in Europe and North America, including organisations in the healthcare, news, and travel sectors.)

SQL INJECTION AND WEBSHELLS EXPLAINED

Patches published quickly

The creators of the MOVEit software, Progress Software Corporation, were quick to publish patches once they knew about the existence of the vulnerability.

The company also helpfully shared an extensive list of so-called IoCs (indicators of compromise), to help customers look for known signs of attack even after they’d patched.

After all, whenever a bug surfaces that a notorious cybercrime crew has already been exploiting for evil purposes, patching alone is never enough.

What if you were one of the unlucky users who had already been breached before you applied the update?

Proactive patches too

Well, here’s a spot of good but urgent news from the no-doubt beleaguered developers at Progress Software: they’ve just published yet more patches for the MOVEit Transfer product.

As far as we know, the vulnerabilities fixed this time aren’t zero-days.

In fact, these bugs are so new that at the time of writing [2023-06-09T21:30:00Z] they still hadn’t received a CVE number.

They’re apparently similar bugs to CVE-2023-34362, but this time found proactively:

[Progress has] partnered with third-party cybersecurity experts to conduct further detailed code reviews as an added layer of protection for our customers. [… We have found] additional vulnerabilities that could potentially be used by a bad actor to stage an exploit. These newly discovered vulnerabilities are distinct from the previously reported vulnerability shared on May 31, 2023.

As Progress notes:

All MOVEit Transfer customers must apply the new patch, released on June 9. 2023.

For official information about these additional fixes, we urge you to visit the Progress Overview document, as well as the company’s specific advice about the new patch.

When good news follows bad

By the way, finding one bug in your code and then very quickly finding a bunch of related bugs isn’t unusual, because flaws are easier to find (and you’re more inclined to want to hunt them down) once you know what to look for.

So, even though this means more work for MOVEit customers (who may feel that they have enough on their plate already), we’ll say again that we consider this good news, because latent bugs that might otherwise have turned into yet more zero-day holes have now been closed off proactively.

By the way, if you’re a programmer and you ever find yourself chasing down a dangerous bug like CVE-2023-34362…

…take a leaf out of Progress Software’s book, and search vigorously for other potentially related bugs at the same time.

THREAT HUNTING FOR SOPHOS CUSTOMERS

MORE ABOUT THE MOVEIT SAGA

We’re all still using passwords on many, perhaps most, of our accounts, because we’re all still using plenty of online services that don’t offer any other sort of login system.

Just today, for instance, I paid membership fees to a cycling-related group that asked for my postal address so it could send me my membership card, which I thought was a delightfully simple and old-school way of letting me retrieve my membership number in future while out on the road.

In the sort of cold and soggy weather you get for much of the year in England, digging out a mobile phone, waiting for a signal, taking off your gloves (they’re not much fun to put back on when you’re winter-waterlogged), and fiddling around with apps, websites, passwords, 2FA codes and more…

…well, it’s just not as easy as finding a waterproof, crash-proof, no-batteries-required, plastic card with your basic details on it.

But along with my payment confirmation, informing me that my membership card was on its way, was a reminder that if ever I wanted to renew my membership, or to request a replacement waterproof, crash-proof, no-batteries-required, plastic card (sadly, they aren’t loss-proof), I’d need to create an account on the group website, so why not choose a password right now?

Simply put, to avoid the need for a password in the first place, I’d need to create one in the second place.

And whenever passwords come up, a long-running question comes up too:

Should you change all your passwords all the time to make them fast-moving targets for cybercriminals, or lock in really complex ones to start with, and then leave well alone?

Indeed, that was the issue facing a long-term Naked Security reader this very morning, whose own IT team were on the horns of this very dilemma, possibly because of a cyberinsecurity near-miss that they’d just experienced first hand.

Which is better?

Complex passwords or passphrases that may not get changed often, or poorly-chosen passwords that are changed regularly?

Thoughts and cogitations

Our thoughts on the matter are as follows:

• Changing passwords regularly isn’t an alternative to choosing and using strong ones. If you want to change your password every month, that’s your choice, but it’s not an excuse for starting with your cat’s name and using minor variants of it every few weeks.
• Forcing people to change their passwords routinely may lull them into bad habits. Many users simply adopt a predictable mechanism, such as adding -01, -02, -03 and so on to satisfy the letter (but not the spirit) of your password replacement rules. Attackers can figure out that sort of behaviour.
• Scheduling password changes may delay emergency responses. If you always change your password every few weeks, there’s less incentive to change it right away if you think you might have been phished. After all, you’ll be changing it “soon” anyway.

Regularly changing your password doesn’t magically make it a better password.

Only choosing a better password in the first place makes it a better password! (This is where password managers can help.)

In other words, we suggest that you first address the problem of helping your users to choose decent passwords, then encourage them to recognise cases where they should change their passwords right away, without needing a timetable to tell them to do so…

…and only then should you worry about whether you really need a “regular changes regardless” password policy as well.

The risks of rote behaviour

Demanding password changes every month when you simply don’t need to is just inviting people to save their new passwords insecurely, or to choose new passwords sloppily, or to rotate through a repeating sequence of N related passwords, or of only ever updating their passwords every 30 days, even in emergencies.

Having said that, locking out users who haven’t accessed specific company accounts for a certain time is a good idea. (This also guards modestly against forgotten accounts, because they eventually expire automatically.)

Locking users out for inactivity is more intrusive than simply forcing them to reset their passwords regularly, and therefore unpopular.

But if someone has a company account login that they aren’t using, why not push them to justify in person why they still need it after they haven’t used it for, say, six months or a year?

After all, if it’s a login for a product or service that charges a per-user fee… you may even be able to save the cost of their subscription.

And if they genuinely don’t need the account any more, you’re helping them to stay out of trouble by preventing rogues and cybercrooks from doing bad things in their name.

BACKDOORS, EXPLOITS, AND LITTLE BOBBY TABLES

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

Firefox’s latest major update is out, following Mozilla’s usual every-fourth-Tuesday release cycle.

The list of security fixes this month (like full moons, there are sometimes two Firefox releases in a calendar month, but most months only have one) is splendidly short, and there aren’t any critical bugs or zero-days in the list.

But there’s a fascinating bug that acts as a reminder that it’s hard to write responsive, user-friendly browser code that’s also strong against deliberate trickery.

That bug, designated CVE-2023-34414, is rated High, and is described with the somewhat mysterious words: Clickjacking certificate exceptions through rendering lag.

Deconstructing the jargon

Let’s deconstruct the jargon in this bug report.

Clickjacking, very simply put, is where an attacker lures you to a part of the screen that looks safe (or even desirable) to click on, and tricks you into clicking your mouse or tapping your finger on the spot marked X…

…only to have your click sent to a component in the web page that you definitely wouldn’t have clicked on if only you’d known where your click was really going.

For example, a rogue online ad-seller might try mashing up clickable ads with unrelated images that look like harmless [OK] buttons, but that actually allow the click to activate the ad, thus co-opting you into ad fraud.

Another popular abuse of clickjacking, back when it was a big thing in the early 2010s, was to hover an invisible social media “Like” button over some entirely unrelated content (which could even be a fake [Cancel] button that well-informed users would be keen to click).

In this way, you could end up getting tricked into endorsing even outrageous content under the misapprehension that you were rejecting or refusing it instead.

Fortunately, browser makers quickly started detecting and avoiding this sort of clickjacking treachery, making it less and less useful to cybercriminals.

The technical name user interface redress attack appeared in the jargon for a while. But the ambiguity of the word “redress”, which can mean both RE-dress in the sense of dress again by draping in new clothing, and re-DRESS in the sense of set right a wrong, made this fancy-sounding expression hard to understand. The word clickjacking was not only much shorter, but also much clearer and cooler to use, so that’s the word that stuck.

Certificate exceptions relate to those warnings that your browser shows you when you visit a website that might not be what it seems, such as a server called example.com that identifies itself as unknown.invalid; a server with a web certificate that hasn’t been renewed for ages; or a certificate that hasn’t been vouched for by a known certificate authority.

For example, like this:

And rendering lag is the delay between the moment that your browser receives instructions to present new content, and the point at which it has done the necessary HTML, CSS, graphics and JavaScript processing to have the content ready for display.

According to Mozilla, the CVE-2023-34414 bug could be triggered by an attacker who got the balance (or perhaps we mean the imbalance) just right (or wrong) in the following sequence:

• Serve up content as a lure, showing a button or something of that sort that you’d probably want to click on.
• Introduce just enough, but not too much, extra CPU load on the browser by supplying new content designed to eat up rendering resources.
• Hope that your click arrives just late enough to end up on the Potential Security Risk page instead of on the fake content, but just soon enough for you not to have seen the warning page popping up first.

We’ve all done this sort of thing by mistake in other contexts: moving the mouse cursor to the button we wanted to press, for example, such as confirming that we wanted to answer an important incoming voice call right this moment…

…then looking away when we shouldn’t have, and accidentally clicking on the very location where some other urgent dialog had popped up that we hadn’t noticed, such as approving an immediate and lengthy reboot to apply updates instead.

With the right timing…

In the CVE-2023-34414 case, an attacker could orchestrate the timing of the subterfuge so that you could be tricked even if you didn’t let your attention wander, and even if you carefully didn’t click without looking:

If a malicious page elicited user clicks in precise locations immediately before navigating to a site with a certificate error, and made the renderer extremely busy at the same time, it could create a gap between when the error page was loaded and when the display actually refreshed.

With the right timing the elicited clicks could land in that gap and activate the button that overrides the certificate error for that site.

Mozilla says it has redressed this bug (in the latter sense of redress we gave above!) by controlling the timing more carefully, thus ensuring the correct activation delay that Firefox “uses to protect prompts and permission dialogs from attacks that exploit human response time delays.”

In other words, clicks from a previous, innocent-looking page no longer get delayed or left over for long enough to activate an all-important security dialog that needs genuine attention before accepting your input.

What to do?

• If you’re a Firefox user, head to the About Firefox menu option to check what version you have. If your browser hasn’t yet updated automatically, you should be asked if you want to fetch the latest version right away. You should end up with 114.0 or later if you’re using the regular flavour of Firefox, or ESR 102.12 if you’re using the Extended Support Release (the ESR includes all needed security fixes, but delays the addition of new features, in case any of them inadvertently add new bugs).
• If you’re a programmer, try to design and regulate your user interface so that critical decisions can’t be triggered by mouse clicks or keystrokes that were buffered up earlier by a user who didn’t (or couldn’t) anticipate popups that might appear in the near future, but hadn’t shown up yet.

Google’s latest Chrome update is out, and this time the company hasn’t minced its words about one of the two security patches it includes:

Google is aware that an exploit for CVE-2023-3079 exists in the wild.

There’s no two-degrees-of-separation verbiage, as we’ve often seen from Google before, to say that the company “is aware of reports” of an exploit.

This time, it’s “we are aware of it all by ourselves”, which translates even more bluntly into “we know that crooks are abusing this as we speak”, given that the bug report came directly from Google’s own Threat Research Group.

As usual, this implies that Google was investigating an active attack (whether against Google itself, or some external organisation, we don’t know) in which Chrome had been pwned by a previously unknown security hole.

The bug is described simply as: Type Confusion in V8. (Understandably, Google’s not saying more than that at this stage.)

As we’ve explained before, a type confusion bug happens when you supply a program with a chunk of data that it’s supposed to parse, validate, process and and act upon in one way…

…but you later manage to trick the program into interpreting the data in a different, unauthorised, unvalidated, and potentially dangerous way.

Type confusion dangers explained

Imagine that you’re writing a program in C. (It doesn’t matter whether you know C or not, you can just follow along anyway.)

In C, you usually declare variables individually, thus not only reserving memory where they can be stored, but also signalling to the program how those variables are supposed to be used.

For example:

 long long int JulianDayNumber; signed char* CustomerName;

The first variable declaration reserves 64 bits for storing a plain old integer value representing the astromonomical day number. (In case you’re wondering, this afternoon is JDN 23157 – Julian Days start at noon, not midnight, because astronomers often work at night, with midnight being the middle of their working day.)

The second reserves 64 bits for storing a memory address where the text string of a customer’s name can be found.

As you can imagine, you’d better not mix up these two values, because a number that makes sense, and is safe, to use as a day number, such as 23157, would almost certainly be unsafe to use as a memory address.

As you can see from this memory dump of a running Windows program, the lowest memory address that’s allocated for use starts at 0x00370000, which is 3,604,480 in decimal, way larger than any sensible day number.

The actual memory addresses used by Windows vary randomly over time, to make your memory layout harder for crooks to guess, so if you were to run the same program, you’d get values, but they’ll nevertheless be similar:

And (although it’s off the bottom of the image above) the memory addresses of the runtime user data section when this program ran from 0x01130000 to 0x01134FFF, representing the unlikely date range of 22 July 44631 to 16 August 44687.

Indeed, if you try to mix those two variables up, the compiler should try to warn you, for example like this:

 JulianDayNumber = CustomerName; CustomerName = JulianDayNumber; warning: assignment makes integer from pointer without a cast warning: assignment makes pointer from integer without a cast

Now, if you’ve ever programmed in C, you’ll know that for convenience, you can declare variables with multiple different interpretations using the union keyword, like this:

 union { long long int JulianDayNumer; signed char* CustomerName; } data;

You can now reference exactly the same variable in memory in two different ways.

If you write data.JulianDayNumber, you magically interpret the stored data as an integer, but writing data.CustomerName tells the compiler you’re referencing a memory address, even though you’re accessing the same stored data.

What you’re doing, more or less, is admitting to the compiler that you’ll sometimes be treating the data you’ve got as a date, and at other times as a memory address, and that you’re taking responsibility for remembering which interpretation applies at what moment in the code.

You might decide to have a second variable, known as a tag (typically an integer) to go along with your union to keep track of what sort of data you’re working with right now, for example:

 struct { int tag; union { long long int JulianDayNumer; signed char* CustomerName; } data; } value;

You might decide that when value.tag is set to 0, the data isn’t initialised for use yet, 1 means you’re storing a date, 2 means it’s a memory address, and anything else denotes an error.

Well, you’d better not let anyone else mess with that value.tag setting, or your program could end up misbehaving dramatically.

A more worrying example might be something like this:

 struct { int tag; // 1 = hash, 2 = function pointers union { unsigned char hash[16]; // either store a random hash struct { void* openfunc; // or two carefully-validated void* closefunc; // code pointers to execute later } validate; } } value;

Now, we’re overloading the same block of memory so we can sometimes use it to store a 16-byte hash, and sometimes to store two 8-byte pointers to functions that our program will call upon later.

Clearly, when value.tag == 1, we’d be happy to let our software store any 16-byte string at all into the memory allocated for the union, because hashes are pseudorandom, so any collection of bytes is equally likely.

But when value.tag == 2, our code would need to be extra-super careful not to allow the user to provide unvalidated, untrusted, unknown function addresses to execute later.

Now imagine that you could submit a value to this code while tag was set to 1, so it didn’t get checked and validated…

…but later, just before the program actually used the stored value, you were able to trick the code into switching the tag to 2.

The code would then accept your unvalidated function addresses as “known and already verified safe” (even though they weren’t), and would trustingly dispatch program execution to a rogue location in memory that you’d sneakily choosen in advance.

And that is what happens in a type confusion bug, albeit using a contrived and simplified example,

Memory that would be safe to consume if if were handled one way is maliciously delivered to the program to process in an alternative, unsafe way.

What to do?

Make sure you have the latest version of Chrome or Chromium.

You want Chrome 114.0.5735.106 or later on Mac and Linux, and 114.0.5735.110 or later on Windows.

Microsoft Edge, which is based on Chromium, is also affected by this bug.

Microsoft has so far [2023-06-06T16:25:00Z] noted that

Microsoft is aware of the recent exploits existing in the wild. We are actively working on releasing a security patch.

Edge is currently at version 114.0.1823.37, so anything numbered later than that should include Microsoft’s CVE-2023-3079 patches.

To check your version and force an update if there is one that you haven’t received yet:

• Google Chrome. Three-dot menu (⋮) > Help > About Chrome.
• Microsoft Edge. Settings and more (…) > Help and feedback > About Microsoft Edge.

You’re welcome.