Perpetual IT

Firefox has followed Chromium to the century mark, reaching a score of 100* with its latest scheduled almost-monthly release.

For readers without the sporting good fortune of living in a cricket-playing country, an individual score of 100 in a single innings, known as a century or a ton, is considered a noteworthy achivement.

Adding an asterisk after the score means “not out”, in other words that the batter is still going strong (or completed their innings without getting out at all), making the feat even more noteworthy.

We know you’re wondering, and if you aren’t you should be, so we’ll mention that from 1959 to 1994, the highest ever score worldwide in first-class cricket was 499, with no asterisk, by the late, great Pakistani batter Hanif Mohammed. Desperate to reach 500 before he ran out of batting time, he took a weary risk for that magical 500th run but fell one short. That total wasn’t eclipsed until 1994, when West Indian batter Brian Lara got to 501*, a record that has stood ever since. Indeed, the only first-class score of 400 or more since Lara’s 501* was Lara’s own 400* in 2004, playing in an international match against England in Antigua. At its current release rate of once every four weeks, Firefox has just over 23 years to go to equal Lara’s quadruple century, and almost 30 years to reach 502*.

No trouble at the version number mill

Earlier this year, we wrote about the potential confusion that Chrome (now at 101) and Firefox (100 today) might cause for some users…

…not through any fault on the part of Google or Mozilla, the respective curators of the Chromium and Firefox codebases, but because at least a few web servers seemed unable to recognise three-digit version numbers correctly.

Today’s ever-funkier and ever-keener-to-track-you websites love to look at your HTTP headers to try to figure out which browser you’re using, and what version you’re on, for example by dissecting the User-Agent header to decide what sort of content to send back.

After updating, our Firefox User-Agent string now looks like this:

GET / HTTP/1.1
Host: testsite.example
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
[. . . .]

Back in February 2022, a few mainstream sites didn’t seem to realise that 100 was greater than 99, presumably because they were hard-coded to use only the first (or last) two characters of the version number, millennium bug style, thus turning the text 100 either into the number 10, or into the number zero.

Fortunately, we have’t had any visible trouble with Edge, which is based on Chromium and flipped over from 99 to 100 at the start of April (keeping just ahead of Firefox with 101 out at the start of May), and in the few hours that we’ve been on Firefox 100.0, we’ve had no problems either.

We’re assuming either that the last few poorly-coded websites fixed their server-side code in the interim, or that the “special case” lists of problem sites created in recent months by Google and Firefox have suppressed any problems, for example by allowing both browsers to pretend as needed still to be version 99.

Bugs fixes in this update

The good news is that none of the security bugs patched in Firefox 100 (or its equivalent long-term version 91.9 ESR, which has the feature set of Firefox 91 plus a further 9 versions worth of vulnerability updates to bring it onto a cybersecurity par with 100) is considered “Critical”, and there aren’t any zero-day holes on the list.

Nevertheless, the patches deal with an intriguing range of security issues, reminding us all just how much we rely on our browsers to do the right thing when it comes to cybersecurity.

CVE-numbered vulnerabilities dealt with in this update include:

• CVE-2022-29914. Fullscreen notification bypass using popups. An attacker who knew the right trick could have popped up misleading or fraudulent content that looked like an official notification presented by Firefox itself. Popups and page content are supposed to be easy to tell apart from information coming from the browser, which is why a web page isn’t allowed to place a misleading image over the top of the address bar that tells you what website you’re on, or to present a dialog that looks like an official browser security warning but tells a dishonest story.
• CVE-2022-29916. Leaking browser history with CSS variables. Websites aren’t supposed to be able to retrieve a list of other sites you’ve visited without your permission. This not only violates your privacy but also provides cybercriminals with useful information that might help them when attacking you or your company in future.
• CVE-2022-29910. Firefox for Android forgot HTTP Strict Transport Security (HSTS) settings. HSTS is a local database maintained by your browser that tells it which websites to visit using HTTPS, even if you click a link or type in a URL that starts with plain old http://. Although most websites immediately redirect HTTP connections to the corresponding HTTPS page anyway, that initial HTTP connection is open to hijack because there’s no encryption or integrity checking of the redirect data that’s sent back. HSTS therefore limits your exposure to your very first visit to a site, when the HSTS setting will be activated, which is a lot safer than needing to risk the insecure redirect every time you visit.
• CVE-2022-29917 and -29918. Memory safety bugs fixed in Firefox 100 and 91.9 ESR. As usual, the Mozilla coders openly admit that “we presume that with enough effort some of these [bugs] could have been exploited to run arbitrary code.” In other words, this update is worth getting for this reason alone, given that exploits are much easier for attackers to figure out after they’ve been patched, because the changes in the code essentially act as hints about where to look, and what to look for.

What to do?

Use Help > About Firefox to force a manual check for updates.

Remember that even if you have automatic updates turned on, it’s worth checking that you’ve correctly received the update, instead of simply assuming it worked.

---

---

Early in April 2022, news broke that various users of Microsoft’s GitHub platform had suffered unauthorised access to their private source code.

GitHib has now updated its incident report to say that it is “in the process of sending the final expected notifications to GitHub.com customers who had either the Heroku or Travis-CI OAuth app integrations authorised in their GitHub accounts.”

The good news is that GitHub itself was not breached, so this is not cause for general concern for every GitHub user.

The bad news is that indirect intrusions of this sort are hard to predict.

GitHub, if you’ve never used it, is a cloud-based source code control system, best known for hosting the public repositories of many open source software projects.

Source code control systems don’t just ensure that the latest version of your software is available for download, but also maintain a continuous history of all recent changes and why they were made (and, if neccessary, why they were later rejected).

Source control systems typically also provide historical lists of official releases, tools for supporting and maintaining different release versions alongside each other, and online forums for reporting bugs and suggesting changes.

You’ve probably heard the jargon term pull request, which refers to a proposed change for which a contributor supplies a potential code update, along with a justification for it. To the suggester, of course, it’s essentially a push request, aiming to inject new code into the system; if approved by the project team, the code gets pulled, or merged, into the codebase and becomes an official part of the project.

Source code control gives software projects a formal record of changes, which makes hunting down new bugs much easier because each change can be reviwed and re-tested individually.

It also makes it easier for developers scattered around the world to co-operate efficiently without inadvertently trampling on each others’ suggested updates.

Examples of popular open source projects hosted on GitHub include the cryptographic library OpenSSL, Microsoft’s own scripting language PowerShell, and privacy-centric alternative browser Brave.

But not all GitHub projects are public, open-source repositories of code.

Many organisations use cloud-based tools like GitHub to host proprietary, closed-sourced projects that they don’t want to become public knowledge.

Startups, for instance, many not want potential competitors to know that they’re working on project X, or even that they’re experimenting in field Y at all.

Established software companies may have existing products that include algorithms and other intellectual property that they don’t want competitors to be able to clone easily.

What went wrong?

Initial investigations revealed that the organisations breached had one of two things in common: they were users either of Heroku or Travis-CI, examples of so-called continuous integration (CI) systems.

These days, a lot of software development teams have adopted what’s often referred to as an agile or a devops approach.

Coders don’t just get together every so often to combine their collective updates into a full test build.

Instead, they use an automated system that regularly and frequently scoops up all recent changes, then rebuilds and re-tests the system automatically, perhaps even several times a day.

The idea is that the sooner each proposed change gets tried out, the sooner any easily-detectable defects will get found.

This, in turn, means that newly-introduced bugs can be investigated quickly, before other parts of the project become entangled with that new code, so that fewer changes need to be taken into account when trying to figure out what went wrong.

Better still, code changes that break the build process itself are exposed right away, so that the project rarely gets bogged down to the point that it can’t be rebuilt at all, let alone re-tested.

As you can imagine, automated CI systems don’t have a real-life developer handy to put in a password and enter a 2FA code every time they want to logon to the source code control system to clone the very latest version of the project…

…so they need to be supplied with a so-called authentication token that they can inject into their network traffic to prove their access rights.

These authentication tokens generally act as a sort of medium-term “sub-password” that allows automated software tools to carry out a predetermined set of actions, for example by granting download access to all the code, and allowing bug reports to be uploaded, but not permitting any code changes to be approved.

In fact, even if you’re not a programmer, you’ll have used a system like this yourself if you’ve ever authorised a third-party toolkit to interact with your social media accounts.

If you’re a Hootsuite user, for instance, you’ve probably used your own passwords and 2FA codes to generate access tokens to allow the Hootsuite system to poke around in your social media accounts on your behalf.

You may have given the app, or one like it, the right to peek at everything coming into your social media accounts, and even to send tweets or make Facebook posts in your name.

So, if a cybercriminal got access to the stored secrets used by one of your pre-authorised apps, or was able to implant malware on your computer or in your network to spy on your network traffic and sniff out the authentication tokens in transit…

…those tokens could used by the attackers to meddle with your online acccount, or sold on to other crooks for similarly nefarious purposes.

According to GitHub, that’s what happened in this source code pilfering incident, where the attackers:

• Acquired GitHub authentication tokens uploaded to Heroku or Travis-CI for account X. (How this happened is not disclosed, presumably because GitHub can’t be sure what happened elsehwere before the intrusions started.)
• Listed all sub-accounts with projects accessible by tokens issued by X.
• Chose interesting-sounding projects in those lists.
• Enumerated interesting-sounding code repositories within those projects.
• Cloned (i.e. stole) the code, thus causing a potentially damaging data breach.

In other words, even though GitHub accounts of the victims weren’t directly compromised, those accounts were indirectly compromised due to the exposure of what you might call “sub-passwords” that the victims had delegated to the automated tools Heroku or Travis-CI.

That’s a bit like an intruder getting access to your office building not by hacking the system that generates ID cards and creating a new pass of their own, but by stealing an active access card already issued to an authorised employee.

What to do?

Indirect data breaches like this are a form of supply chain intrusion, where you aren’t attacked directly, but instead via part of your operational process that you’ve entrusted to someone else.

Tips for protecting against this type of mishap, or for reacting promptly if you do get caught out, include:

• Regularly review all third-party access authentications you have made, for all apps associated with all the online services you use. You may have more of these than you think, including cloud services such as webmail, teleconferencing, web hosting, source code control, social media, DNS, content management and CRM. Social media sites such as Twitter and Facebook include dashboard pages where you can list all third-party apps you’ve approved. Don’t assume that just because you uninstalled an app with access to your account that its access rights were revoked at the same time.
• Make sure you know how to revoke third-party authentication tokens for every service you use. OAuth, the authentication service involved in this incident, has advice on how to revoke access. The social media dashboard pages mentioned in Tip 1, where you can list who’s got access, generally include a button that will instantly revoke that access.
• Prepare for the worst. Know what to do if a cyberattack occurs, and whom you need to contact, especially if your local laws require you to disclose data breaches.

Remember that preparing for a cyberattack is not an admission that you expect to fail.

Indeed, regular and purposeful cybersecurity practice can help you improve your resilience by exposing gaps in your policies and procedures, and by revealing access permissions that you intended to revoke but never did.

---

If you don’t have the experience or the time to maintain ongoing threat response by yourself, consider partnering with a service like Sophos Managed Threat Response. We help you take care of the activities you’re struggling to keep up with because of all all the other daily demands that IT dumps on your plate.

Not enough time or staff? Learn more about Sophos Managed Threat Response:
Sophos MTR – Expert Led Response  ▶
24/7 threat hunting, detection, and response  ▶

---

LISTEN NOW

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

---

Listen on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found.
Or simply drop the URL of our RSS feed into your podcatcher.

---

Even if you’re not a native speaker of English, you’ve probably heard the curious saying, “It’s a bit of a Curate’s Egg”, referring to something about which you’re determined to keep a positive public attitude, even if your immediate private reaction was to be disappointed.

The saying has certainly stood the test of time, coming as it does from a British satiricial cartoon from the late 1800s, in which a young curate has been invited to breakfast with the bishop.

(A curate is an Anglican church minister in their first job, right at the bottom of the clerical hierarchy, while a bishop is in the uppermost levels of church staff.)

Loosely speaking, the cartoon depicts the modern business equivalent of an intern who finds themelves in the midst of a lunch meeting of senior VPs: a promising but vaguely intimidating situation, with the very real danger of not getting a second chance to make a good first impression.

The British, of course, are well-known for eating boiled eggs at breakfast time, and in the Victorian era, there were no food labelling regulations to tell you how long your eggs had been in the supply chain, so stale eggs were a much common problem than they are today.

And a boiled egg, still being in its shell when it’s served, doesn’t reveal that it’s gone off until you open it up to eat it…

…whereupon it rapidly reports its rancidity to the rest of the room by releasing a rancorous reek. (It’s a sulfurous smell, but we’d already decided to alliterate with R, so there was no space for a stench soubriquet starting with S in that sentence.)

Anyway, in the now-famous cartoon, the bishop is seen apologising to the junior cleric for serving him a bad egg, saying, “Dear me, I’m afraid your egg’s not good!”

The timid curate, for whom both the Ninth Commandment and the aforementioned rancourous reek preclude an outright lie, but for whom politeness and social discretion is the better sort of valour, gamely but absurdly replies, “Some parts of it are very good.”

Which is a long way of warning you how you might react to the news delivered by the Sophos Ransomware Survey 2022, which we published today:

No leading questions

As usual, we didn’t conduct the survey ourselves, to avoid the problem that a cybersecurity company asking respondents cybersecurity questions might be considered “leading the witnesses”.

Surveys overtly connected with vendors often result in answers, like the curate’s remark about the egg, that the respondents thought the experts might like to hear, rather than the bald facts of what really happened.

We also made an effort to keep our sample size high, and to talk to a broad and representative cross-section of the global business community.

We therefore used a survey company to conduct the process, and they asked numerous cybersecurity questions to more than 5500 randomly-chosen respondents from a wide range of businesses of varying sizes in more than 30 countries across the globe.

As with the Curate’s Egg, you’ll find that some parts of the report are indeed very good, but it’s hard to sugar-coat the headline statistic of this year’s survey, which is disappointing.

In our Ransomware 2020 survey, 1/2 of our respondents said that they’d actually had a ransomware infection in the past year (2019).

In our Survey 2021, we were pleased to report that figure was down to about 1/3, with a creditable 63% of respondents saying they’d avoided ransomware altogether during 2020.

But in the Ransomware 2022 survey, the figure has gone up again, with 2/3 of our respondents admitting to a ransomware infection during 2021.

In other words, the underlying prevalence of ransomware attacks has doubled since our previous report, which implies that the size, scale and skills (if we may use that word in this context) of the cybercriminal underworld have increased correspondingly, too.

Not everyone needed to pay up

The upside to that figure is that 1/3 of those who did get hit nevertheless managed to prevent the usual disastrous denoument by heading off the cybercriminals before they were able to unleash the final data-scrambling part of the attack.

In other words, even though all of those who suffered a ransomware intrusion faced an extensive malware cleanup exercise and a possible data breach disclosure to their local regulator, defence-in-depth meant that 33% of them were spared the total derailment of their business that typically happens after a file-encrypting ransomware attack.

Also, just over 1/2 (54%) of those who did get hit, and were faced with the choice of paying up, didn’t hand money to the crooks, but found other ways to recover instead.

Sadly, however, the proportion of victims who refused to pay up is one statistic that has deteriorated over the past three years.

In 2020, just 1/4 of victims said they paid up; in 2021, that was up to 1/3; but in 2022, as we just said, the figure was close to 1/2.

What to do?

Our Top Tips are:

• Ensure high-quality defences at all points in your environment. Review your security controls and make sure they continue to meet your needs. As the ever-increasing success of ransomware criminals reminds us, cybersecurity is a journey, not a destination. The security precautions you picked back in 2019 aren’t necessarily the right ones for today, because “set-and-forget” just doesn’t work in the cybersecurity game.
• Proactively hunt for threats so you can stop adversaries before they can execute their attack. If you don’t have the time or skills in-house, look for a Managed Detection and Response (MDR) specialist to help you out. The file-scrambling part of a ransomware incident may unfold within a few hours, or even in a matter of minutes, with the criminals deliberately scheduling the coup de grace for a specific, and usually inconvenient, time of day (or night). But when our own Managed Threat Reponse (MTR) experts are called in to investigate attacks after they’ve occurred, they frequently find tell-tale signs going back days, or even weeks, that could have been used as a tip-off to close down the attack and eject the criminals in time.
• Harden your environment by searching for and closing down security gaps such as unpatched devices, unprotected computers, insecure remote access servers, and more. Cybersecurity products with Extended Detection and Response (XDR) features are ideal for this purpose, because they allow you to close the gap between your cybersecurity policy (see Tip 1) and your cybersecurity practice (see Tip 2). If you don’t search for exploitable holes in your network, you can be sure that the crooks will!
• Prepare for the worst. Know what to do if a cyberattack occurs, and whom you need to contact, especially if your local laws require formal and speedy data breach disclosures. Preparing for a cyberattack is not an admission that you expect to fail. Indeed, regular and purposeful practice can help you improve your resilience by exposing places where you haven’t followed Tip 1, Tip 2 and Tip 3 as robustly as you thought.
• Make backups, and practise restoring from them. A backup that you can’t reliably and rapidly restore doesn’t count, so you might as well not bother making backups in the first place if they aren’t going to be any use. Your goal is to get back up and running quickly, with minimum disruption, and without being forced to pay blackmail money to the crimnals.

Remember that although the Ransomware Survey 2022 reports that 2/3 of respondents were ransomware victims, more than 1/2 of them recovered without paying up, suggesting that they not only had backups handy, but were able to restore them in a timely way.

As we like to say on Sophos Naked Security:

The only backup you will ever regret is the one you didn’t make.

Time to act!

---

If you don’t have the experience or the time to maintain ongoing threat response by yourself, consider partnering with a service like Sophos Managed Threat Response. We help you take care of the activities you’re struggling to keep up with because of all all the other daily demands that IT dumps on your plate.

Not enough time or staff? Learn more about Sophos Managed Threat Response:
Sophos MTR – Expert Led Response  ▶
24/7 threat hunting, detection, and response  ▶

---