In recent months, attackers have become a little more insolent and attacked the supply ch…

In recent months, attackers have become a little more insolent and attacked the supply chain almost every week. Well, seriously, I constantly come across news about various high-profile hacks. Either npm, or the European Commission, or something else interesting and noticeable. Maybe it’s me with my article ( https://t.me/maxienergy_channel/376) scribbled? I don’t remember that the topic of supply chain security has ever been more relevant than it is now 🧐

So I thought I'd break down all the latest news related to supply chain attacks. One attack per post. And today let’s look at what we generally call the supply chain and the main vectors for its hacking. Let's go ⤵

To explain it as simply as possible, the IT supply chain is the path through which the final product reaches us. Not only code, but also other people's libraries, packages, containers, plugins, images, repositories, cloud services, contractors and even people who have the right to release something into production. In the article I wrote about this in a little more detail, but in essence, now the development does not look the same as before. Software has become more complex, and business demands that development proceed as quickly as possible. That's why no one writes all the code from scratch anymore. We all use libraries and packages. Well, you won’t write your own implementation of an HTTP client for your project just so that you can send requests to the API in your application. Usually, to do this, they simply include a library like axios ( https://github.com/axios/axios). And this is normal, because otherwise we would stagnate in one place for a very long time. Another thing is that we are not writing a library. We cannot be responsible for the correctness of the code written by other developers. And the vulnerabilities that this library contains (and they most likely exist there). And an attacker can take advantage of this to compromise our product through such a dependence.

That's why attacking the supply chain is so vile. Because the attacker breaks us through other people, their processes and their code. We just pulled up the package update, but there might be something bad in it. And we don’t even know. And we were hacked through this addiction. It’s even a shame 🙁

Typically, chain attacks can be divided into several scenarios:

Scenario 1: Dependency compromise. This is when an attacker slips in a malicious package or gains control of an already popular library. On the outside, everything looks legitimate (familiar name, familiar package, usual update), but inside... well, there is horror and darkness

Scenario 2: compromise of a developer or maintainer account. If an attacker has access to the account of a person who publishes releases, need I say what he can do with such wealth? A release signed by a legitimate account looks normal, although in fact it included a person who should not have had access to such changes at all

Scenario 3: Assembly and delivery infrastructure hit. If you get into the assembly stage, you can end up with a malicious artifact that has already been officially assembled. And this is one of the most disgusting scenarios, because formally the product came from the right place, but the pipelines/repositories/image registries/build scripts were kindly modified by the attackers for their purposes

Scenario 4: attack through contractors and external services. No company or team exists in a world where they are the only ones. There are integrators, access providers, etc. And sometimes the weak link is not the target itself, but someone next to it (if you attack a contractor, you get the opportunity to attack the target itself)

There are also more mundane techniques. For example, typosquatting ( https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html), when a package is created with almost the same name as a popular library (a kind of phishing from the dependency world). Or dependency confusion ( https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html?utm_source=chatgpt.com), when an internal dependency is suddenly replaced by an external one from a public repository. But these are still more special cases

Next, I will try to analyze the most popular news about supply chain attacks that I have heard and read about in recent months (yay, series of posts). At the same time, we’ll gradually figure out how to protect the supply chain in practice.

#information_security