Alex Birsan

Alex Birsan actually published his findings for this vulnerability in Feb 2021 [1], and collected a bunch of bug bounties from various companies (Apple, Microsoft, Paypal, Yelp, Tesla, Shopify, Uber, Netflix).

He was able to steal packages names for Python (PyPi), JS (npm), Ruby (Gem), where these various companies have their own private package repositories with private modules where they don't control the package names in the default repositories.

The main requirements for this attack are

1. Having private repositories, where the package names in the default repositories is not owned by the owner of the package.

2. Package manager allows downloading packages from multiple repositories (the default and private repositories) without being able to pin specific package to only be downloaded from the private repositories.

What's notable on his findings is the omission of Facebook and Google,
which I believe due to their usage of Buck/Bazel and monorepos for their internal codes.
Another thing to note was that Alex mainly target companies internal private packages,
while this particular instance affects an open source project which was providing package on their own repository and make use of a package (which I was not able to find any bug bounty program for).

There's another post by Kjäll et.al [2] that explains how this particular vulnerabilities affects other package managers (PHP, Java, .Net, ObjC/Swift, Docker), in what conditions it's vulnerable, and how to mitigate…

Since the Github issue is turning into an unusable mess and I am currently experiencing emotions I don't have to unleash here...

There is an interesting comment by one of the older maintainers of stylus, Panya [1]. Taking this at face value, they claim to have published some malicious packages for research purposes about dependency confusion [2] (their link). This also fits with the comments of a few people claiming to be security researchers, [3] and [4], which at least say the same and point to three malicious packages published by Panya.

Based off of that, my own personal interpretation and simplest thesis is that Panya released some packages with questionable code. This triggered some security mechanism in npm and that system yanked packages they were a contributor of [5], because the account looked compromised or otherwise malicious. And then pipelines went red.

If this was an actual malicious act, or curiosity about security and security responses getting a fairly nuclear security response, I don't know. You need to apply your own security reasoning to this -- if you even want to trust this comment :)

I just wanted to collect the interesting comments in a place, because that ticket is getting impossible to navigate.

1: https://github.com/stylus/stylus/issues/2938#issuecomment-3106721706

2: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

3: https://github.com/stylus/stylus/issues/2938#issuecomment-3106424718

4:…

Hmm, they don't look that bad - https://hackerone.com/paypal

Here's an example of something that got paid out by paypal - https://hackerone.com/reports/739737 (15K)

Good writeup - https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-password-539fc2896da9

Interesting history with paypal - https://hackerone.com/alexbirsan

Here's how duplicate reports are dealt with - https://docs.hackerone.com/programs/duplicate-reports.html

I am curious if paypal provided the OP with original reports. They don't say. I wonder how much the OP is not saying here, versus how much they understand the platform they are working on.

This statement makes me very curious: "Other criticisms have pointed out that Security Analysts can first delay the reported vulnerability, report it themselves on a different bug bounty platform, collect the bounty (without disclosing it of course), and then closing the reported issue as Not Applicable, or perhaps Duplicate."

How can you do that if you're providing the original report?

Also, the guy is just wrong. You GAIN rep points for duplicates, unless you did something dumb and really amateur like not searching first for already publicly disclosed issues.

https://docs.hackerone.com/hackers/reputation.html#effects-of-report-state-on-reputation

I am a security researcher referenced in the winning web-hacking technique on that list ("Dependency Confusion" by Alex Birsan [1]) and was ranked 7th in Portswigger's 2019 issue [2,3]. My motto has always been "Learn to make it; then break it." In other words, I invest a lot of time familiarising myself with technologies and specifications before examining how their implementation might lead to security flaws. This process usually requires reading a lot of technical documentation and source code, and becoming acquainted with how organisations implement said technologies.

Once I feel comfortable with my understanding of the subject material, I start to think about how certain aspects of the technology could lead to security flaws or interesting areas of research. At times this may require out-of-the-box thinking or can even be the result of pure luck.

The "bug bounty" aspect of this all tends to come into play once I want to find case studies for my research.

[1]: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

[2]: https://portswigger.net/research/top-10-web-hacking-techniques-of-2019

[3]: https://edoverflow.com/2019/ci-knew-there-would-be-bugs-here/

I might be a bit biased, since I've been writing Scala professionally for years.

While most of the article rings true, I wanted to share some counter-arguments:

1) A lot of the problems mentioned are only really noticeable if you use Spark, which really lags behind in Scala versions compared to the rest of the ecosystem. As someone who doesn't use Spark, I don't really feel much of the "Scala minor versions" pain.

2) While not great, cross-compilation/publishing is not that bad (there are plugins like `sbt-release` and `sbt-crossproject` that pretty much take care of it).

3) I mostly disagree with the "Difficult to publish to Maven" point. I'm not saying that it's easy, but I enjoy the fact that it's not as trivial like other languages. I would argue that this whole process makes [1] almost impossible, which is a plus for me.

1: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

> enforcement of security vulnerability should be by law

I think whether there "should" be a law making you liable could depend on the details of the exploit.

If you get exploited via rowhammer, I don't think anyone would blame you. It would be unreasonable if every small business running a website was legally required to defend against magnetic interference.

However, if you're Apple and say, you get fully compromised because someone clicked a button to register version `9000.0.0` of your internal package on the public npm/pypi registry (https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610), maybe I agree there's an argument for some accountability there.