8 ms·

Hackers are spoofing themselves as GitHub's Dependabot to steal user passwords

85 points by Beggers1960 3y ago

Beggers1960 3y ago
"Hundreds of GitHub repositories have been targeted by a threat actor masked as the GitHub platform’s Dependabot feature to install password-stealing malware."
- deleted 3y ago
  [deleted]
rolph 3y ago
aquire a personal access token, reconfigure the account icons and labels to spoof dependabot, rely on complacency bred of familiarity, push malware as fix, steal credentials. for good measure restore account config, and obfusicate history
- rolph 3y ago
  that is what was going on, but at least a couple people dont seem to think so.
trey-jones 3y ago
I don't think I have ever accepted a pull request from Dependabot. I think that was already a stupid thing to do. Now it's even more obvious that you shouldn't accept a PR. Dependabot is a useful tool to find vulnerable dependencies, so that you can update them yourself.
- JohnFen 3y ago
  Are people accepting pull requests without actually reviewing the code being contributed?? That seems like the larger problem...
  - sdflhasjd 3y ago
    There are projects that automatically merge dependabot PRs...
    - mistrial9 3y ago
      projects with underpaid and outsourced contractors by any chance?
      - MiguelX413 3y ago
        More likely, simply open-source projects.
    - earthling8118 3y ago
      Funnily enough I'd assume that those projects would be immune to this type of attack unless the automation is absolutely terrible.
    - oalders 3y ago
      Presumably an automated merge would be checking something like > if: github.event.pull_request.user.login == 'dependabot[bot]'
      - turboponyy 3y ago
        No, the automated workflow would be something like this: - Run dependabot workflow (outputs: $pr_number) - Automerge $pr_number
  - Karellen 3y ago
    If dependabot is part of GitHub's own infrastructure, and the last 100 pull requests it sent were good, some maintainers might think it trustworthy. I'm pretty sure there are maintainers of Linux that Linus has been working with for long enough that he trusts them to the point that doesn't feel the need to examine every one of their commits. Also, he can't check every commit closely. Linux 6.5 merged 13,561 commits over 9 weeks[0], which is in excess of 200 commits per day - and that was a small release. Learning to trust regular contributors is one of the things that makes OSS work as scale. Edit: Of course, Linus makes sure that stuff he merges from trusted contributors is actually from them, either because it's from a repo he knows they control, or it's GPG-signed and the signatures are checked. The problem is failing to confirm that commits come from the trusted source you think they're from, not failing to examine the commits themselves. [0] https://lwn.net/Articles/941675/ https://lwn.net/Articles/941675/
- prepend 3y ago
  I’ve accepted a bunch of dependabot PRs but I always review the change they make. Sometimes I modify or reject depending on the change. All the ones I remember are just version bumps to address some vulnerability. I thought dependabot commits were signed though. So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me.
  - deathanatos 3y ago
    > I thought dependabot commits were signed though. … nothing stops a dependabot impersonator from signing their commit. (edit: the OP is rather confused on this point. While the commit could be signed, I don't know that in this case it could be signed in a way that Github would give it the green (Verified) bauble. The prose says the commit is signed, but the screenshot seems to suggest they're not. (Though they almost covered up the relevant area…)) You'd still have to notice that it's not coming from the real dependabot > So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me. Short of hovering over the user's icon¹ (which should go to the app, not to a user) or reading the contest of the commit … I don't think a good impersonation would look different from the real deal in the history. (Note that as others note: the commits here are already merged, via stolen PATs. You'd be trying to distinguish a malicious commit in your history from the real deal.) ¹actually, maybe they can't spoof the icon, since it's coming from a stolen PAT + the commit data isn't going to link up due to trying to spoof the name, which is why it's blank in the screencap. So that's a bit more of a giveaway, but I still think most people would be hard-pressed to notice.
  - hedora 3y ago
    Version bumps are often enough to own a repository. There are plenty of examples of a quickly pulled version that introduces a security hole, and a few where the maintainer [account] pushes then immediately hides a malicious point release.
    - prepend 3y ago
      Certainly. But that’s two vulnerabilities and usually by different groups. So that’s a pretty sophisticated group to pwn a package and the submit all the dependabot version bumps. Not impossible, but less likely. And I don’t blindly accept version bumps as I read the associated CVE and see if I need it. And I think it’s pretty rare for major packages to get compromised. When pandas or numpy get breached, I think I’ll hear about it way before I accept a depdabot PR to change my version.
- turboponyy 3y ago
  I don't understand this sentiment. The majority of Dependabot's commits that I've seen are 1 or 2 line diffs that just bump a version number in a workflow file. Why wouldn't you want to accept those after a quick review?
  - oceanplexian 3y ago
    Speaking as someone with SRE experience that thinking keeps me up at night. Bumping version numbers isn’t like auto updating your phone. How was the new version tested? Did it go through some sort of QA process? What subtle behavior changes are going to inpact your application or downstream dependencies? Did the license change in the new version? Are there performance regressions? Was the library hacked, and the new version introduced an exploit into your application?
caladin 3y ago
From a very cursory skim, I get the feeling that this would only work on public repositories where pull requests are allowed, correct? Not to minimize the issue, as that type of situation is likely the norm on GitHub. Another way of phrasing what I mean: private repositories are unlikely to be affected by this correct? Since the spoofer would have no way to propose the threatening pull request, only the real dependabot would have permission to do that in that case.
- capableweb 3y ago
  Well, it works to every repository the user who is doing the spoofing has access to, private or public. If the user has access to your private repository via the GitHub ACL, they'll be able to create a PR to it with their spoofed profile. But yes, if you have a private repository only you and dependabot has access to, no user would be able to perform this spoof against your repository.
  - hedora 3y ago
    This is probably the intended behavior of github, but correctly maintaining that invariant is exactly the sort of functionality middle management and project managers tend to deprioritize. “How could they get the repo uuid without access, and even if they had it, the worst they could do is create an issue or PR that they can’t even read.”
deleted 3y ago
[deleted]
sdflhasjd 3y ago
The original source appears to be https://checkmarx.com/blog/surprise-when-dependabot-contributes-malicious-code/ https://checkmarx.com/blog/surprise-when-dependabot-contribu...
- dang 3y ago
  We've changed to that from https://www.itpro.com/security/cyber-attacks/hackers-are-spoofing-themselves-as-githubs-dependabot-to-steal-user-passwords https://www.itpro.com/security/cyber-attacks/hackers-are-spo... above. Thanks! Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - hedora 3y ago
    Based on figmert’s comment, you might want to update the incorrect title too.
    - dang 3y ago
      What would be an accurate and neutral title?
elischleifer 3y ago
Just another reason not to use dependabot - it's default configuration appears to be created to burn money on GH Actions / Azure.
- viraptor 3y ago
  That's a silly conclusion. This is not dependabot specific - you can achieve the same with any system automatically suggesting merges.
  - elischleifer 3y ago
    fair point. I think I've just been burned too many times by dependabot looking to update single ts packages with single line changes. it's default configuration is overly aggresive
    - viraptor 3y ago
      Dependabot doesn't try to guess what's in the changes. It can't really tell anyway. A trivial 1 line change may be either "this box is now 1px further to the right", or "a critical bug which will delete all your data tomorrow is fixed". It's up to dependabot to report any change available.
- hinkley 3y ago
  Looks like several of the core contributors work for github. It is difficult to get a man to understand something, when his salary depends on his not understanding it.
  - Qerub 3y ago
    May 23, 2019: "Dependabot has been acquired by GitHub and we couldn't be more excited!" https://web.archive.org/web/20190601064131/https://dependabot.com/blog/hello-github/ https://web.archive.org/web/20190601064131/https://dependabo...
    - deleted 3y ago
mikey_p 3y ago
Apparently no one read the article, Dependabot was not compromised, no one accepted legitimate looking PRs, or anything else like that. API tokens were stolen and then commits were made that spoofed dependabot's name and style to avoid further scrutiny.
- deleted 3y ago
  [deleted]
figmert 3y ago
Am I going crazy or did the majority commenters here not read the article? These commits are not PRs. If I'm understanding this correct, the attacker got a hold of someone's personal access token in some way, then used that to make a commit that creates a new GHA workflow, in which the workflow ex-filtrate all the secrets and env vars to their servers. The commit was made directly to the main (?) branch and set up to be run on all pushes. So the branch doesn't even matter. So it has nothing to do with automerging dependabot PRs. Sure you shouldn't be doing that, but if your PAT is compromised, you're done for anyway. The reason dependabot is involved is because that commit looks like it came from dependabot, and that's likely because the email on the git commit was set to dependabot, which GitHub would see and show as being from dependabot.
- masfuerte 3y ago
  You're right, it's creating commits but it's not just creating GHAs. It's also directly altering the targetted project's javascript to steal credentials from end users using the project. (Edited with correction as below.)
  - deathanatos 3y ago
    > it's not creating GHAs (sic) … the OP includes a screenshot of a malicious GHA workflow that exfils secrets. (In addition to altering the targetted project's JS.)
    - masfuerte 3y ago
      Thanks for the correction. I only read the text.
- deleted 3y ago
  [deleted]
mcbrienollie 3y ago
This whole story starts from the API token leak into the worst. I think, in a way, Github should reach out to the account holders if it sees a suspicious commit is getting pushed with some sort of security algorithm. I think that shouldn't be that hard.

85 points by Beggers1960 3y ago

Beggers1960 3y ago

"Hundreds of GitHub repositories have been targeted by a threat actor masked as the GitHub platform’s Dependabot feature to install password-stealing malware."

deleted 3y ago
[deleted]

rolph 3y ago

aquire a personal access token, reconfigure the account icons and labels to spoof dependabot, rely on complacency bred of familiarity, push malware as fix, steal credentials. for good measure restore account config, and obfusicate history

rolph 3y ago
that is what was going on, but at least a couple people dont seem to think so.

trey-jones 3y ago

I don't think I have ever accepted a pull request from Dependabot. I think that was already a stupid thing to do. Now it's even more obvious that you shouldn't accept a PR. Dependabot is a useful tool to find vulnerable dependencies, so that you can update them yourself.

JohnFen 3y ago
Are people accepting pull requests without actually reviewing the code being contributed?? That seems like the larger problem...
- sdflhasjd 3y ago
  There are projects that automatically merge dependabot PRs...
  - mistrial9 3y ago
    projects with underpaid and outsourced contractors by any chance?
    - MiguelX413 3y ago
      More likely, simply open-source projects.
  - earthling8118 3y ago
    Funnily enough I'd assume that those projects would be immune to this type of attack unless the automation is absolutely terrible.
  - oalders 3y ago
    Presumably an automated merge would be checking something like > if: github.event.pull_request.user.login == 'dependabot[bot]'
    - turboponyy 3y ago
      No, the automated workflow would be something like this: - Run dependabot workflow (outputs: $pr_number) - Automerge $pr_number
- Karellen 3y ago
  If dependabot is part of GitHub's own infrastructure, and the last 100 pull requests it sent were good, some maintainers might think it trustworthy. I'm pretty sure there are maintainers of Linux that Linus has been working with for long enough that he trusts them to the point that doesn't feel the need to examine every one of their commits. Also, he can't check every commit closely. Linux 6.5 merged 13,561 commits over 9 weeks[0], which is in excess of 200 commits per day - and that was a small release. Learning to trust regular contributors is one of the things that makes OSS work as scale. Edit: Of course, Linus makes sure that stuff he merges from trusted contributors is actually from them, either because it's from a repo he knows they control, or it's GPG-signed and the signatures are checked. The problem is failing to confirm that commits come from the trusted source you think they're from, not failing to examine the commits themselves. [0] https://lwn.net/Articles/941675/ https://lwn.net/Articles/941675/
prepend 3y ago
I’ve accepted a bunch of dependabot PRs but I always review the change they make. Sometimes I modify or reject depending on the change. All the ones I remember are just version bumps to address some vulnerability. I thought dependabot commits were signed though. So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me.
- deathanatos 3y ago
  > I thought dependabot commits were signed though. … nothing stops a dependabot impersonator from signing their commit. (edit: the OP is rather confused on this point. While the commit could be signed, I don't know that in this case it could be signed in a way that Github would give it the green (Verified) bauble. The prose says the commit is signed, but the screenshot seems to suggest they're not. (Though they almost covered up the relevant area…)) You'd still have to notice that it's not coming from the real dependabot > So just seeing a commit from a user named “dependabot” would actually be extra suspicious to me. Short of hovering over the user's icon¹ (which should go to the app, not to a user) or reading the contest of the commit … I don't think a good impersonation would look different from the real deal in the history. (Note that as others note: the commits here are already merged, via stolen PATs. You'd be trying to distinguish a malicious commit in your history from the real deal.) ¹actually, maybe they can't spoof the icon, since it's coming from a stolen PAT + the commit data isn't going to link up due to trying to spoof the name, which is why it's blank in the screencap. So that's a bit more of a giveaway, but I still think most people would be hard-pressed to notice.
- hedora 3y ago
  Version bumps are often enough to own a repository. There are plenty of examples of a quickly pulled version that introduces a security hole, and a few where the maintainer [account] pushes then immediately hides a malicious point release.
  - prepend 3y ago
    Certainly. But that’s two vulnerabilities and usually by different groups. So that’s a pretty sophisticated group to pwn a package and the submit all the dependabot version bumps. Not impossible, but less likely. And I don’t blindly accept version bumps as I read the associated CVE and see if I need it. And I think it’s pretty rare for major packages to get compromised. When pandas or numpy get breached, I think I’ll hear about it way before I accept a depdabot PR to change my version.
turboponyy 3y ago
I don't understand this sentiment. The majority of Dependabot's commits that I've seen are 1 or 2 line diffs that just bump a version number in a workflow file. Why wouldn't you want to accept those after a quick review?
- oceanplexian 3y ago
  Speaking as someone with SRE experience that thinking keeps me up at night. Bumping version numbers isn’t like auto updating your phone. How was the new version tested? Did it go through some sort of QA process? What subtle behavior changes are going to inpact your application or downstream dependencies? Did the license change in the new version? Are there performance regressions? Was the library hacked, and the new version introduced an exploit into your application?

caladin 3y ago

From a very cursory skim, I get the feeling that this would only work on public repositories where pull requests are allowed, correct? Not to minimize the issue, as that type of situation is likely the norm on GitHub. Another way of phrasing what I mean: private repositories are unlikely to be affected by this correct? Since the spoofer would have no way to propose the threatening pull request, only the real dependabot would have permission to do that in that case.

capableweb 3y ago
Well, it works to every repository the user who is doing the spoofing has access to, private or public. If the user has access to your private repository via the GitHub ACL, they'll be able to create a PR to it with their spoofed profile. But yes, if you have a private repository only you and dependabot has access to, no user would be able to perform this spoof against your repository.
- hedora 3y ago
  This is probably the intended behavior of github, but correctly maintaining that invariant is exactly the sort of functionality middle management and project managers tend to deprioritize. “How could they get the repo uuid without access, and even if they had it, the worst they could do is create an issue or PR that they can’t even read.”

deleted 3y ago

[deleted]

sdflhasjd 3y ago

The original source appears to be https://checkmarx.com/blog/surprise-when-dependabot-contributes-malicious-code/ https://checkmarx.com/blog/surprise-when-dependabot-contribu...

dang 3y ago
We've changed to that from https://www.itpro.com/security/cyber-attacks/hackers-are-spoofing-themselves-as-githubs-dependabot-to-steal-user-passwords https://www.itpro.com/security/cyber-attacks/hackers-are-spo... above. Thanks! Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- hedora 3y ago
  Based on figmert’s comment, you might want to update the incorrect title too.
  - dang 3y ago
    What would be an accurate and neutral title?

elischleifer 3y ago

Just another reason not to use dependabot - it's default configuration appears to be created to burn money on GH Actions / Azure.

viraptor 3y ago
That's a silly conclusion. This is not dependabot specific - you can achieve the same with any system automatically suggesting merges.
- elischleifer 3y ago
  fair point. I think I've just been burned too many times by dependabot looking to update single ts packages with single line changes. it's default configuration is overly aggresive
  - viraptor 3y ago
    Dependabot doesn't try to guess what's in the changes. It can't really tell anyway. A trivial 1 line change may be either "this box is now 1px further to the right", or "a critical bug which will delete all your data tomorrow is fixed". It's up to dependabot to report any change available.
hinkley 3y ago
Looks like several of the core contributors work for github. It is difficult to get a man to understand something, when his salary depends on his not understanding it.
- Qerub 3y ago
  May 23, 2019: "Dependabot has been acquired by GitHub and we couldn't be more excited!" https://web.archive.org/web/20190601064131/https://dependabot.com/blog/hello-github/ https://web.archive.org/web/20190601064131/https://dependabo...
  - deleted 3y ago

mikey_p 3y ago

Apparently no one read the article, Dependabot was not compromised, no one accepted legitimate looking PRs, or anything else like that. API tokens were stolen and then commits were made that spoofed dependabot's name and style to avoid further scrutiny.

deleted 3y ago
[deleted]

figmert 3y ago

Am I going crazy or did the majority commenters here not read the article? These commits are not PRs. If I'm understanding this correct, the attacker got a hold of someone's personal access token in some way, then used that to make a commit that creates a new GHA workflow, in which the workflow ex-filtrate all the secrets and env vars to their servers. The commit was made directly to the main (?) branch and set up to be run on all pushes. So the branch doesn't even matter. So it has nothing to do with automerging dependabot PRs. Sure you shouldn't be doing that, but if your PAT is compromised, you're done for anyway. The reason dependabot is involved is because that commit looks like it came from dependabot, and that's likely because the email on the git commit was set to dependabot, which GitHub would see and show as being from dependabot.

masfuerte 3y ago
You're right, it's creating commits but it's not just creating GHAs. It's also directly altering the targetted project's javascript to steal credentials from end users using the project. (Edited with correction as below.)
- deathanatos 3y ago
  > it's not creating GHAs (sic) … the OP includes a screenshot of a malicious GHA workflow that exfils secrets. (In addition to altering the targetted project's JS.)
  - masfuerte 3y ago
    Thanks for the correction. I only read the text.
deleted 3y ago
[deleted]

mcbrienollie 3y ago

This whole story starts from the API token leak into the worst. I think, in a way, Github should reach out to the account holders if it sees a suspicious commit is getting pushed with some sort of security algorithm. I think that shouldn't be that hard.