[HN Gopher] Hackers are spoofing themselves as GitHub's Dependab...
___________________________________________________________________
Hackers are spoofing themselves as GitHub's Dependabot to steal
user passwords
Author : Beggers1960
Score : 57 points
Date : 2023-09-27 20:01 UTC (3 hours ago)
(HTM) web link (checkmarx.com)
(TXT) w3m dump (checkmarx.com)
| trey-jones wrote:
| 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 wrote:
| Are people accepting pull requests without actually reviewing
| the code being contributed??
|
| That seems like the larger problem...
| sdflhasjd wrote:
| There are projects that automatically merge dependabot PRs...
| earthling8118 wrote:
| Funnily enough I'd assume that those projects would be
| immune to this type of attack unless the automation is
| absolutely terrible.
| mistrial9 wrote:
| projects with underpaid and outsourced contractors by any
| chance?
| oalders wrote:
| Presumably an automated merge would be checking something
| like
|
| > if: github.event.pull_request.user.login ==
| 'dependabot[bot]'
| Karellen wrote:
| 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/
| EGreg wrote:
| There should be an actual green checkmark for Dependabot
| and others
| deathanatos wrote:
| It seems like these are being pushed directly, using stolen
| credentials. (I.e., attackers are just leaking more
| credentials & compromising the repo. They're just hiding
| behind dependabot's good name by spoofing it.)
| prepend wrote:
| 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 wrote:
| > _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 icon1 (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.)
|
| 1actually, 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.
| caladin wrote:
| 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 wrote:
| 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.
| rolph wrote:
| 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
| [deleted]
| Beggers1960 wrote:
| "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]
| sdflhasjd wrote:
| The original source appears to be
| https://checkmarx.com/blog/surprise-when-dependabot-contribu...
| dang wrote:
| We've changed to that from
| 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
| elischleifer wrote:
| Just another reason not to use dependabot - it's default
| configuration appears to be created to burn money on GH Actions /
| Azure.
| viraptor wrote:
| That's a silly conclusion. This is not dependabot specific -
| you can achieve the same with any system automatically
| suggesting merges.
| elischleifer wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| May 23, 2019: "Dependabot has been acquired by GitHub and we
| couldn't be more excited!" https://web.archive.org/web/201906
| 01064131/https://dependabo...
| Micrococonut wrote:
| Just one more reason to actually read the article instead of
| just assuming its contents say whatever you want.
| mikey_p wrote:
| 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]
| figmert wrote:
| 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.
| [deleted]
| masfuerte wrote:
| 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 wrote:
| > _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 wrote:
| Thanks for the correction. I only read the text.
___________________________________________________________________
(page generated 2023-09-27 23:01 UTC)