4 ms·

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 prett

by dlor 4y ago

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*.

extheat 4y ago
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.
- rileymat2 4y ago
  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.
miohtama 4y ago
This is not a compromised supply chain, but fake packages. See my earlier comment here https://news.ycombinator.com/item?id=34390100 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.
- dlor 4y ago
  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.
- jeroenhd 4y ago
  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.
  - woodruffw 4y ago
    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.
    - DelightOne 4y ago
      Knowing the source code would make it easier.
  - donmcronald 4y ago
    > 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?
ocdtrekkie 4y ago
> 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.

by dlor 4y ago

extheat 4y ago

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.

rileymat2 4y ago
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.

miohtama 4y ago

This is not a compromised supply chain, but fake packages. See my earlier comment here https://news.ycombinator.com/item?id=34390100 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.

dlor 4y ago
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.
jeroenhd 4y ago
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.
- woodruffw 4y ago
  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.
  - DelightOne 4y ago
    Knowing the source code would make it easier.
- donmcronald 4y ago
  > 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?

ocdtrekkie 4y ago

> 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.