Another day, another access-token-based database breach. This time, the victim is Microsoft's GitHub business. On December 6, 2022, repositories from our atom, desktop, and other deprecated GitHub-owned organizations were cloned by a compromised Personal Access Token associated with a machine account. Once detected on December 7, 2022, our team immediately revoked the compromised credentials and began investigating potential impact to customers and internal systems. Simply put: someone used a pre-generated access code acquired from who-knows-where to leech the contents of various source code repositories that belonged to GitHub itself. We're guessing that GitHub keeps its own code on GitHub, but it wasn't the underlying GitHub network or storage infrastructure that was breached, just some of GitHub's own projects that were stored there. Think of this breach like a crook getting hold of your Outlook email archive password and downloading your last month's worth of messages. By the time you noticed, your own email would already be gone, but neither Outlook itself nor other users' accounts would have been directly affected. Note our careful use of the word "Directly" in the previous sentence, because the compromise of one account on a system may lead to knock-on effects against other users, or even against the system as a whole. Your corporate email account almost certainly contains correspondence to and from your colleagues, your IT department and other companies. In those emails you may have revealed confidential information about account names, system details, business plans, logon credentials, and more. Using attack intelligence from one part of a system to wriggle into other parts of the same or other systems is known in the jargon as lateral movement, where cybercriminals first establish what you might call a "Beachhead of compromise", and then try to extend their access from there. In the case of stolen source code databases, whether they're stored on GitHub or elsewhere, there's always the risk that a private repository might include access credentials to other systems, or let cybercriminals get at code signing certificates that are used when actually building the software for public release. This sort of data leakage can even be a problem for public repositories, including open-source source code projects that aren't secret, and are supposed to be downloadable by anybody. Open source data leakage can happen when developers inadvertently bundle up private files from their development network into the public code package that they ultimately upload for everyone to access. This sort of mistake can lead to the very public leak of private configuration files, private server access keys, personal access tokens and passwords, and even entire directory trees that were simply in the wrong place at the wrong time. The crooks got hold of code signing certificates for the GitHub Desktop and Atom products. This means, in theory, that they could publish rogue software with an official Github seal of approval on it. Note that you wouldn't already need to be an existing user of either of those specific products to be fooled - the criminals could give GitHub's imprimatur to almost any software they wanted. The stolen signing certificates were encrypted, and the crooks apparently didn't get the passwords. This means, in practice, that even though the crooks have the certificates, they won't be able to use them unless and until they crack those passwords. Only three of the certificates had not yet expired on the day they were stolen. You can't use an expired certificate to sign new code, even if you have the password to decrypt the certificate. One stolen certificate expired in the interim, on 2023-01-04. A second stolen certificate expires tomorrow, 2023-02-01. That's also a signing certificate for Windows software. This one is for signing Apple apps, so GitHub says it is "Working with Apple to monitor for any [] new apps signed." Note that the crooks would still need to crack the certificate password first. All affected certificates will be revoked on 2023-02-02. Revoked certificates are added to a special checklist that operating systems can use to block content vouched for by certificates that should no longer be trusted. According to GitHub, no unauthorised changes were made to any of the repositories that were leeched. It looks as though this was a "Read only" compromise, where the attackers were able to look, but not to touch. The good news is that if you aren't a GitHub Desktop or Atom user, there's nothing that you immediately need to do. If you have GitHub Desktop, you need to upgrade before tomorrow, to ensure that you have replaced any instances of the app that were signed with a certificate that is about to be flagged bad. If you are still using Atom, you will somewhat curiously need to downgrade to a slightly older version that wasn't signed with a now-stolen certificate. Given that Atom has already reached the end of its official life, and won't be getting any more security updates, you should probably replace it anyway. If you're a developer or a software manager yourself. Who's got access to which parts of our development network? Especially for legacy or end-of-life projects, are there any legacy users who still have left-over access they don't need any more? How carefully is access to our code repository locked down? Do any users have passwords or access tokens that could easily be stolen or misused if their own computers were compromised? Has anyone uploaded files that shouldn't be there? Windows can mislead even experienced users by suppressing the extensions at the end of filenames, so you aren't always sure which file is which. Linux and Unix systems, including macOS, automatically hide from view any files and directories that start with a dot character.
This Cyber News was published on nakedsecurity.sophos.com. Publication date: Wed, 01 Feb 2023 18:58:02 +0000