Another day, another access token based database violation.
This time the victim (and in some ways the culprit as well) is Microsoft’s GitHub business.
GitHub says it’s found a violation Quickly the day after it happened, but by then the damage had been done.
on December 6, 2022
atom,desktop, other deprecated GitHub-owned organizations were cloned by compromised personal access tokens (PATs) associated with computer accounts. After detection on December 7, 2022, our team immediately revoked the compromised credentials and began investigating the potential impact to our customers and internal systems.
Long story short, someone used pre-generated access codes obtained from who-knows-where to pull content from various source code repositories belonging to GitHub itself.
We’re guessing that GitHub keeps its own code on GitHub (otherwise that would be a no-confidence vote per se!), but it wasn’t the underlying GitHub network or storage infrastructure that was compromised. Some of our own projects on GitHub stored there.
Beachhead and flanking
Think of this breach as a scammer obtaining your Outlook email archive password and downloading the last month’s worth of messages.
By the time you noticed, your emails were already gone, but Outlook itself or other users’ accounts probably weren’t directly affected.
However, note the careful use of the word “directly” in the previous sentence. This is because compromise of one account on the system can have a cascading effect on other users or the entire system.
For example, your corporate email account will almost certainly contain correspondence with co-workers, your IT department, and other companies.
That email may have disclosed confidential information about your account name, system details, business plan, logon credentials, etc.
Wriggling attack intelligence from one part of a system to another part of the same or a different system is known in jargon as: lateral movementCybercriminals first try to establish what they call a “bridgehead” and then expand their access there.
What’s in the repository anyway?
In the case of stolen source code databases, whether stored on GitHub or elsewhere, private repositories may contain access credentials to other systems, or cybercriminals may be able to obtain the code signing certificate used to actually build the database. There are always risks. Software for Public Use.
In fact, data leaks of this kind are no secret and can be a problem even with public repositories, including open source code projects that should be available for download by anyone.
Open-source data leaks can happen when developers accidentally bundle private files from development networks into public code packages that are uploaded for everyone to access.
Mistakes of this kind can lead to very public (and very publicly searchable) leaks of personal configuration files, personal server access keys, personal access tokens and passwords, and even entire directory trees that were in the wrong place at the wrong time.
For better or worse, it took GitHub almost two months to figure out how much information the attacker had in this case, but now the answer is out and it looks like this:
- Scammers have obtained code signing certificates for GitHub Desktop and Atom products. This means, in theory, that malicious software can be published with the official Github seal of approval. You don’t have to be an existing user of these particular products to be fooled. Criminals can give GitHub approval to almost any software they want.
- The stolen signing certificate was encrypted and the crooks did not seem to be able to get the password. This actually means that even if the crooks have the certificate, they won’t be able to use it unless they decrypt it.
mitigating factor
Sounds like pretty good news from a bad start. And here’s what makes the news even better.
- Only 3 of the certificates have not yet expired the day they were stolen. Even if you have the password to decrypt the certificate, you cannot use the expired certificate to sign new code.
- One stolen certificate prematurely expired on January 4, 2023. That certificate was for signing Windows programs.
- The second stolen certificate expires tomorrow 2023-02-01. It is also a signing certificate for Windows software.
- The last certificate expires only in 2027. Since this is for signing Apple apps, GitHub says: “We are working with Apple to […] Your new app is signed.” Scammers still need to decrypt the certificate first.
- All affected certificates will be revoked on 2/2/2/2023. Revoked certificates are added to a special checklist that apps, such as browsers, and operating systems can use to block content endorsed by certificates that are no longer trusted.
- According to GitHub, no unauthorized changes have been made to the leeched repositories. This appears to be “read-only” damage that an attacker can see but not touch.
What should I do?
The good news is that if you’re not a GitHub Desktop or Atom user, there’s nothing you need to do right away.
if you have GitHub desktopYou’ll need to upgrade before tomorrow to make sure you’ve replaced all instances of your app that were signed with a certificate that will be flagged as bad.
if you are still using atom (Discontinued in June 2022 and ended life as an official GitHub software project on December 15, 2022) downgrade With a slightly outdated version that wasn’t signed with the now-stolen certificate.
Given that Atom has already reached the end of its official lifespan and will no longer receive security updates, you should replace Atom anyway. (Also, the very popular Visual Studio Code, which belongs to Microsoft, seems to be the main reason Atom was discontinued in the first place.)
If you are a developer or software manager…
…why not use this as an incentive to go and check it out?
- Who has access to which parts of our development network? Do you have legacy users left with access they no longer need, especially for legacy or end-of-life projects?
- How carefully is access to code repositories locked down? Does anyone have a password or access token that could easily be stolen or misused if their computer is compromised?
- Has anyone uploaded a file that shouldn’t be there? You can’t always be sure which file is which, as Windows suppresses extensions at the end of filenames, which can mislead even experienced users. Linux and Unix systems, including macOS, automatically hide (but don’t use!) all files and directories from view that start with the dot (period) character.
.