Hacker News Reader

Comment by dlor | Hacker News Reader

I don't want to speculate on exactly how the developer at CircleCI was compromised, but it wouldn't surprise me if it was something like this. They can be pretty easily targeted and it's trivial to get RCE on a developer's laptop during package install.

These are hard to detect for a few reasons:

  - Traditional endpoint protection is often disabled on developer machines
  - Developers require much more access to their machines to do their jobs
  - Installing packages in most programming languages still results in RCE at install time
  - Most solutions are aimed at protecting code once it makes it to CI and production, but developer machines are still the wild west

If you're not already operating in a world where you assume every developer laptop is compromised, you need to start. The only real protection here is requiring multi-party review for *everything*.

View on HN

This is not a compromised supply chain, but fake packages.

See my earlier comment here https://news.ycombinator.com/item?id=34390100

The fake packages are not part of any supply chain and are quite easy to detect. More serious attack would be rigging an existing widely used OSS package, but this is not what the post is about and its title is somewhat misleading.

They can definitely inadvertently be part of someone's supply line. The official repository takes precedence over any locally configured repositories (say, an in-house package named libhttps).

When that package suddenly gets published onto the official repo, it may replace the intended package without the devs noticing until it's too late.

I think this is a flawed design for a package management tool but it's the tool we've got.

These packages could be random typosquats but they might also be targeted supply chain attacks against a specific company. With the CircleCI leak, the names of internal packages may just have leaked.

In pip, multiple configured indexes have equal priority with first-wins on order of configuration (if memory serves); the tiebreaker is the version, so the attacker would need to publish a higher version than the one used internally.

Either way, that’s not the attack described in the post, and is speculative to a degree that doesn’t warrant the “0day” descriptor. It’s also not actionable for companies that run entire PyPI mirrors rather than supplementary indexes, which is the norm.

Knowing the source code would make it easier.

> The official repository takes precedence over any locally configured repositories (say, an in-house package named libhttps).

Wow. I wonder how a repository manager like Nexus handles that. If there aren't any namespaces, would it suddenly go upstream and fetch something from the official repos?

I disagree here - these could be targeted and just because we haven't seen impact yet doesn't mean there wasn't any. All it takes is one download from the right person then it can be pivoted into a supply chain attack.

For one, commiting project dependencies into your SCM can go along way. Treat 3P code as your code. Not only does this help prevent supply chain attacks, but it makes you more conscious as to the stuff you’re importing. Maybe you don’t need a 10,000 line dependency for something you could have written in 15 lines of code. There’s also other benefits of not depending on external servers for your build step which can dramatically improve install time if you have a big project with many deps. Not to mention never worrying about dependency version mismatching. All the clones have the same copy of everything.

For languages with good package managers it might seem like an anti pattern (why commit node_modules?). But stuff like this is standard for C++ dev, for example.

I understand where you are coming from but comparing things to the state of third party/library usage for c++ will turn people off. It is in a really bad state which is why things get checked in.

> Developers require much more access to their machines to do their jobs

I think this is a pretty untrue view that only seems to crop up in developer-focused communities. You don't need admin rights to write software. In the case you need to interact with the system, you probably should be working inside virtual machines anyways.

Reply on news.ycombinator.com