Hackers are spoofing themselves as GitHub's Dependabot to steal user passwords
checkmarx.com
checkmarx.com
That seems like the larger problem...
> if: github.event.pull_request.user.login == 'dependabot[bot]'
- Run dependabot workflow (outputs: $pr_number)
- Automerge $pr_number
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.
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.
… 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.
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.
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?
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.
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.
“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.”
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
for good measure restore account config, and obfusicate history
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.
… the OP includes a screenshot of a malicious GHA workflow that exfils secrets. (In addition to altering the targetted project's JS.)
API tokens were stolen and then commits were made that spoofed dependabot's name and style to avoid further scrutiny.
It is difficult to get a man to understand something, when his salary depends on his not understanding it.