Weaponizing Dependabot: Pwn Request at its finest

https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest

by chha • 1 year ago

111 58 1 year ago

woodruffw7• 1 year ago

The folks at Synaktiv had a nice detailed blog post on this same vector last year[1].

The bottom line with these kinds of things is that virtually nobody should be using `pull_request_target`, even with “trusted” machine actors like Dependabot. It’s a pretty terrible footgun.

[1] https://www.synacktiv.com/en/publications/github-actions-exp...

gdubya• 1 year ago

Fixed link: https://www.synacktiv.com/en/publications/github-actions-exp...

woodruffw7• 1 year ago

Thanks, I've fixed my comment as well.

radicalexponent• 1 year ago

Step one in making a new repo is disabling Dependabot. Automate intentionally or get pwned your choice.

Also, is automated version bumps really such a good thing? Many times I have wasted hours tracking down a bug that was introduced by bumping library. Sometimes only the patch version of the library is different so it shouldn't be breaking anything... but it does! It is so much better to update intentionally, test, deploy. Though this does assume you have a modest number of dependencies which pretty much excludes any kind of server-side javascript project.

woodruffw7• 1 year ago

I don’t disagree about automating intentionally, but it’s worth noting that Dependabot isn’t enabled by default: you have to explicitly configure it.

(The larger problem here isn’t even Dependabot per se, since all Dependabot does is fire PRs off. The problem is that people then try to automate the merging of those PRs, and end up shooting themselves in the foot with GHA’s more general footguns. It also doesn’t help that, until recently, GitHub’s documentation recommended using these kinds of dangerous triggers for automating Dependabot.)

lmm4• 1 year ago

Dependabot isn’t enabled by default: you have to explicitly configure it.

Really? Dependabot runs on a number of my repositories without my having consciously enabled it.

bravesoul23• 1 year ago

I always check changelogs of the dependencies. I treat a dependant PR as seriously as any PR.

bugtodiffer2• 1 year ago

changelogs, but not the code?

robszumski2• 1 year ago

How do you scale this besides keeping the dep list short? Are you reading every item or just scanning for words like "deprecated" or "breaking change"?

bobbiechen• 1 year ago

"Is backward compatibility even possible?" -> https://digitalseams.com/blog/is-backward-compatibility-even...

esafak• 1 year ago

You run CI on your dependabot PRs, right? IF so, how is it any different than doing the same thing manually?

udev40962• 1 year ago

I have not seen any serious OSS project to auto-merge version bumps. Most of them have manual approval for it afaik

robszumski2• 1 year ago

Curious if auto-merge philosophy changes between libraries and applications. The library definitely has a larger user base to break and a wider matrix of use-cases. IMO, auto-merge is more palatable for an application – do you agree? Especially when you're under SOC2/FedRAMP/etc.

Joker_vD• 1 year ago

Sometimes only the patch version of the library is different so it shouldn't be breaking anything... but it does!

Still have flashbacks from that one time when some dependency in our Go project dropped support for go1.18 in its patch version update, and we almost couldn't rebuild the project before the Friday evening. Because obviously /s being literally unable to build the dependency is a backwards-compatible change.

duped• 1 year ago

Also, is automated version bumps really such a good thing?

Depends. Do you want to persist the belief that software requires constant maintenance because it's constantly changing? Then yes: automate your version bumps and do it as often as possible.

If you want software to be stable then only update versions when you have a bug.

jerf2• 1 year ago

Work has been fiddling around with Dependabot and force-enabling it everywhere (not auto-merging, just having it generating the PRs)... my feedback was that it is built on the presumption that All Updates Are Automatically Good, but this is transparently a false statement. In fact, Dependabot, by being so fast and automatic, may actually raise the probability of some project getting malicious code injected into it! Consider the timeline of malicious code injection:

    1. Malicious code is injected into some project.
    2. People have a chance to pick it up and put it into their code.
    3. The malicious code is found, publicized, and people react.

The faster you act after step 1, the more chance you'll have time to put it into your system before the world reaches step 3. Dependabot maximizes the speed of reaction after step one. If I'm doing things somewhat more manually then I'm much more likely to experience the world finding out about a corrupted dependency before I start incorporating it.

Now, just typing it out it may sound like I'm more freaked out than I actually am. While supply-chain attacks are a problem, they are getting worse, and they will continue to get worse, they are also still an exotic situation bubbling on the fringe of my awareness, as opposed to something I'm encountering regularly. For a reasonable project the most likely outcome is that dependabot enhancing this exposure window will still not have any actual real-world impact, and I'm aware of that. However, where this is relevant is if you are thinking of Dependabot and its workflow as a way of managing security risk, because you imagine updates as likely carrying security improvements, and that's your primary purpose for using it (as opposed to other uses, such as, your system slowly falling behind in dependencies until it calcifies and can't be updated without a huge degree of effort, a perfectly reasonable threat and Dependabot is a sensible response to that), then you also need to consider the ways in which is may actually increase your vulnerability to threats like supply-chain attacks.

And of course, projects do not start out with all their vulnerabilities on day one and then monotonically remove them. Many vulnerabilities are introduced later. For each such vulnerability, there is a first release that includes them, and for which treating that update as if it was just a Good Thing was in fact not true, and anyone who pushed it in as quickly as possible made a mistake. Unfortunately, sometimes hard problems are just hard problems.

Though I have wondered about the idea of programming something like Dependabot, but telling it, hey, tell me about known CVEs and security releases, but otherwise, let things cook for 6 months before automatically building a PR for me to update. That would radically reduce this risk I'm outlining here.

(In fact, after pondering, I'm kind of reminded of how Debian and a lot of Linux distros work, with their staged Cutting Edge versus Testing versus Stable versus Long Term Support. Dependabot sort of builds in the presumption that you want that Cutting Edge level of updates... but in many cases, no, I really don't. I'd much rather build with Stable or Long Term Support for a lot of things, and dip into the riskier end of the pool for specific things if I need to.)

zingababba2• 1 year ago

Dependabot already differentiates between version updates and security updates:

https://docs.github.com/en/code-security/dependabot/dependab...

morningsam2• 1 year ago

Though I have wondered about the idea of programming something like Dependabot, but telling it, hey, tell me about known CVEs and security releases, but otherwise, let things cook for 6 months before automatically building a PR for me to update.

Renovate can do both of these things already:

https://docs.renovatebot.com/configuration-options/#vulnerab...

https://docs.renovatebot.com/configuration-options/#minimumr...

latchkey3• 1 year ago

I'm going through SOC2 right now, and it is essentially requiring it to be enabled. I'll just do the minimal to pass, but it isn't something you can just disable in some cases.

sethhochberg• 1 year ago

FWIW: this might be a suggestion of the specific audit team you’re working with or a requirement of one of the “follow our playbook and you’ll pass” vendors if you’re using one of those, but the SOC 2 on its own doesn’t really impose specific technical feature/control requirements like this.

I don’t have the exact exam language in front of me right now but the requirement would be something like “you have some process for learning about, assessing, and mitigating vulnerabilities in software dependencies that you use”.

Enabling an automated scan and version bump tool like dependabot is a common and easy way to prove your organization has those capabilities. But you could implement whatever process you want here and prove that you do it on the schedule you say you do in order to satisfy the audit requirement.

gregwebs• 1 year ago

I passed SOC2 with dependabot set to only perform security updates

jt2190• 1 year ago

Sometimes only the patch version of the library is different so it shouldn't be breaking anything... but it does!

OT: Semantic versioning’s major flaw is that is the presumption that the entire chain of package maintainers is extremely diligent about correctly bumping their version numbers. There have certainly been a few projects that are very good about this, but the vast majority are not.

The only solution to this that I know of is to test: Manually exercise the features with the dependencies, write automated tests that check your critical needs from a dependency, or identify and run the tests from the dependency’s test suite that cover your use cases. (Also: Contribute tests that you want in the suite!)

udev40962• 1 year ago

Wait, how is it possible for anyone who opens a PR to issue dependabot commands for main repository? There should be some kind of authorization in place to avoid it, right? Should it not ignore any commands coming from outside users who do not have commit access?

bugtodiffer2• 1 year ago

its a fork

bavarianbob• 1 year ago

This is explained here:

Here's the trick: github.actor does not always refer to the actual creator of the Pull Request. It's the user who caused the latest event that triggered the workflow.

abhisek• 1 year ago

Seems like a bit forced scenario to me. I have never seen anyone auto-merge Dependabot PR automatically using GitHub Action.

Also pull_request_target is a big red flag in any GHA and even highlighted in GHA docs. It’s like running untrusted code with all your secrets handed over to it.

woodruffw7• 1 year ago

I have never seen anyone auto-merge Dependabot PR automatically using GitHub Action.

For better or worse, it's a pattern that GitHub explicitly documents[1].

(An earlier version of this page also recommended `pull_request_target`, hence the long tail of public repositories that use it.)

[1] https://docs.github.com/en/code-security/dependabot/working-...

phyzome2• 1 year ago

What a weird and distracting AI-generated header image.

zingababba2• 1 year ago

Yeah, why is he saying "confused deputy" as he pulls the lever. Sounds like he knows he shouldn't even be in charge!

minitech• 1 year ago

And what a weird and distracting AI-generated article. The bold-labelled numbered lists (e.g. “the evil plan”) are especially awkward.

phyzome2• 1 year ago

Might have been AI-generated, or just poorly written. I found it hard to read either way.

ImPostingOnHN4• 1 year ago

So, they created workflows to auto-merge PRs if the creator was Dependabot. Seems safe, doesn't it?

No? In what world would it be safe to merge code, AI-generated or not, which you haven't reviewed, much less do it automatically without you even knowing it happened?

How do you know that you need the changes (whether bug or CVE)? How do you know the code isn't malicious? How do you know your systems are compatible with the change? How do you know you won't need to perform manual work during the migration?

carefulfungi3• 1 year ago

I think this response is understandable. But also feels disingenuous. If a dependency update appears to be an automated version bump, and you trust your test base, and you trust the dependency author (did you read the whole dependency's dependency graph before importing it? You probably didn't.) it's only a small step to auto-merge. The horror here is that the bot isn't the author and the version update isn't legitimate. That's on Github's presentation and settings, in my opinion.

Relying on a human reviewer, regardless, is a weak guarantee. If your security posture is "Joe shouldn't make mistakes", you still have a weak security posture.

ImPostingOnHN4• 1 year ago

... and you trust the dependency author ... it's only a small step to auto-merge

I disagree for the reasons listed above, but let's focus for a moment on 3rd-party dependencies here, versus trusted ones. Given the numerous scenarios I listed above, it's a huge step from "using a 3rd party library" to "trusting the author of it".

We'd have to start with "...and you don't trust the author", because for most 3rd-party dependencies, the author has given us neither sufficient evidence to do so, nor sufficient recourse if that trust is violated.

Relying on a human reviewer, regardless, is a weak guarantee.

Relying on countless random 3rd party to not own you when they know people are pulling in their code as a dependency is a far, far worse guarantee. How would that strategy have protected someone against this supply-chain attack?:

https://www.wiz.io/blog/github-action-tj-actions-changed-fil...

snickerbockers• 1 year ago

If people are this obsessed with making the little version number of their dependencies as big as possible why don't they just make downloading the dependencies part of the build system?? Or better yet make the user supply their own dependencies and link them in as shared libraries? This problem was solved at least 30 years ago...

TZubiri• 1 year ago

Yesterday on an article on some Package URL proposal and I wrote a comment about these super deep supply chains based on free volunteer work, and how it's becoming even more work to just keep a handle on them. But hn didn't allow me to post it.

When you need to add dependencies that manage packages to avoid version conflicts, when you need to add dependencies that check for vulnerabilities in your dependencies, that's when you know you are in too deep.

And it's not like these things are necessary, for the big majority of systems that have less than 100k users, you can just build systems that run for less than 200$ per month. I've started working with an empty requirements.txt and empty package.json, everything is fine.

Before you call me a dinosaur and claim that I might as well be writing assembly, first, I do depend on an Operating System and a Programming Language, and maybe a database if I need the convenience, there's such a thing as nuance. And second, I'm using cutting edge tech, these things (Linux, python, mysql) have existed for less than 50 years! They are in their infancy!

But man, I'm really banking on the ethos of building on top of the shoulders of "giants" falls soon. I hate to be on the side of hackers, but it's inevitable that something bad will happen if you keep on doing shit like this.

It's like having a friend or group of people that constantly have orgies with random people and they develop a huge culture around using different types of condoms and profilactics of some kind or other, and giving tips on what works and what doesn't and switching strategies when one of their friends gets an STD but still not quite ever abandoning the idea of having massive orgies.

All of the while the cost of developing software is dropping to 0, almost no one uses GPL, and surprise surprise, companies build proprietary systems on top of 95% software of the commons. It sucks to compete with companies and programmers that just npm install 1000 things, not sure what I'm banking on, maybe a slew of lawsuits that increase the liabilities of writing bad software that incentivizes actually understanding the shit that we build?

Gnight HN.

lrvick• 1 year ago

Mandate signed commits and signed reviews.

If someone wants to merge a bot PR or any other PR by an untrusted third party, they will have to "adopt" the bot commit as their own, sign the commit locally, and then wait for a second human reviewer to do a signed merge.

Not signing code means it could be tampered with all sorts of ways. Get a Nitrokey and setup git to sign with it and have your team do the same.

msgodel• 1 year ago

Ah the classic "do something to prevent outside organizations from having agency in your project" (pin dependency versions) followed by "delegate the agency to an automation because agency comes with responsibilities."

It reminds me of the github bot someone posted here at the beginning of the year (it was hard to tell if it was satire) that just automatically approved (not merged, just approved) PRs to get around some technicality in some (supposedly machine verified) infosec standard that required two human approvals on every PR.

Weaponizing Dependabot: Pwn Request at its finest

Related Stories