How TrustSource protects against dependency confusion attacks

What has happened?

Security researchers have managed to gain access to various high-security networks with the help of a dependency confusion attack. With this attack, they managed to send protected information and data from within the affected networks to the outside. However, depending on the attack scenario, other activities would also be imaginable. Once behind the defense lines, the damage scenario can be freely chosen.

How was the attack executed?

The security researchers got the idea when they found names of private packages in the published open source tools of the companies (Apple, Adobe, etc.)

Companies often use open source and supplement certain functionalities or graphical controls with their own libraries. These, in turn, are developed by only one team and made available as separate packages or libraries to other development teams. This is efficient and convenient because the broad set of development teams does not have to worry about it, yet the look-and-feel remains consistent across different applications or services.

If the companies now play software back to the community and the references to such “private” packages are not removed from the source code, the release will carry the name of these packages outside. This in itself is not that dangerous. It only becomes interesting if the information is exploited for a dependency attack (see next page).

How could you protect yourself from this to happen?

  • Component naming:
    If the internal component names follow a naming scheme, such as ORG.COPMANY.UNIT.UITOOLS, it becomes much more difficult for third parties to create corresponding names in the package managers without causing a stir. ORG.COPMANY.UNIT.UITOOLS is more noticeable than the 100th version of UITOOLS.
  • Configuration of packet manager proxies:
    To be successful in the attack, the local distribution mechanisms must be outwitted. It should be ensured that no updates are pulled from outside for certain package types, e.g. with the help of the name identifier or a simple blacklist.
  • Version control:
    With the help of a version history, it quickly becomes possible to determine which versions are in use. A jump from 1.2.3 to 69.1.0 can be discovered quickly or is noticeable.

What is a dependency confusion?

Modern package systems use package managers, especially to manage the ever-growing number of open source components. Each build specification therefore contains a list of the components to be included. In Java this is the POM.XML file, in Node.JS (JavaScript) it is the PACKAGES.JSON.

In this file the components and the minimum requirements to the components, the version numbers are indicated. Since many components change frequently, the requirements often contain not only the exact version number, e.g. 1.2.3, but a note like ^1.2.3, which means something like: “Give me at least 1.2.3 or newer.” . If the maintainer of the component updates to e.g. 1.2.4 (new patch) or 1.3.0 (new feature), the own solution would be able to profit from the innovations with the help of the formulation during the next build.

If a malicious actor now posts a newer version in a package manager, for example a 12.1.0, he can be relatively sure that this version would be provided by the package management for the context described above.
If the project now builds a new version, the malicious code would be pulled from outside, integrated into a QA system, and deployed there. Depending on the damage scenario chosen, a lot can be done with this.

You want to manage vulnerability protection along the complete lifecycle of your product?

TrustSource can help to protect you!

If you use TrustSource, it will know the current versions of your modules and solutions, as well as publicly available components. Sudden version jumps of publicly available components are detected by our systems and reported to our support team for review. Critical developments are reported back to the projects.

If you are already using TrustSource, you are probably familiar with the concept of “linked modules”, the integration of releases of your own software. If versions appear here that were previously unknown, this also leads to a report to the respective project manager. In this way, you can be sure to notice corresponding developments quickly.