APromptRiskDBThreat intelligence atlas
AI Case Study

Compromised PyTorch Dependency Chain - AI Case Study

Linux packages for PyTorch's pre-release version, called Pytorch-nightly, were compromised from December 25 to 30, 2022 by a malicious binary uploaded to the Python Package Index (PyPI) code repository. The malicious binary had the same name as a PyTorch dependency and the PyPI package manager (pip) installed this malicious package instead of the legitimate one. This supply chain attack, also known as "dependency...

View attack chainRead summary
IncidentPyTorchUnknownInitial AccessCollectionExfiltration

Overview

Case steps3Steps described in the case record.
Techniques3Attack methods mentioned in the case steps.
Linked CVEs0Known vulnerabilities mentioned in the record.

Risk patterns

Patterns found in the case record and its linked vulnerabilities.

  • 1Dominant ATLAS tactic. Initial Access appears in 1 case steps.
  • 2Multiple attack methods. The case connects to 3 unique AI attack methods.

Procedure timeline

Search the case steps or filter them by attacker goal.

Initial Access1Collection1Exfiltration1
  1. Initial Access

    A malicious dependency package named torchtriton was uploaded to the PyPI code repository with the same package name as a package shipped with the PyTorch-nightly build. This malicious package contained additional code that uploads sensitive data from the machine. The malicious torchtriton package was installed instead of the legitimate one because PyPI is prioritized over other sources. See more details at this GitHub issue.

  2. Collection

    The malicious package surveys the affected system for basic fingerprinting info (such as IP address, username, and current working directory), and steals further sensitive data, including: - nameservers from /etc/resolv.conf - hostname from gethostname() - current username from getlogin() - current working directory name from getcwd() - environment variables - /etc/hosts - /etc/passwd - the first 1000 files in the user's $HOME directory - $HOME/.gitconfig - $HOME/.ssh/*.

  3. Exfiltration

    All gathered information, including file contents, is uploaded via encrypted DNS queries to the domain *[dot]h4ck[dot]cfd, using the DNS server wheezy[dot]io.

Related CVEs

Known software flaws mentioned in the case record.

No related CVEs found for this case. Built from MITRE ATLAS case study records and listed case steps.

Mitigations

Defenses connected to the attack methods in this case.

Code Signing

Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing. Adversaries can embed malicious code in AI software or models. Developers should also cryptographically sign SBOM and AIBOM components that track model or data provenance. Enforcement of code signing can prevent the compromise of the AI supply chain and prevent execution of malicious code.

Control Access to AI Models and Data at Rest

Establish access controls on internal model registries and limit internal access to production models. Limit access to training data only to approved users.

Use Ensemble Methods

Use an ensemble of models for inference to increase robustness to adversarial inputs. Some attacks may effectively evade one model or model family but be ineffective against others.

Sources

Original public records and references for this case.

Original source

Original source links

Open the MITRE ATLAS data and public references used for this case study.

Repositoryhttps://github.com/mitre-atlas/atlas-dataATLAS.yamlhttps://github.com/mitre-atlas/atlas-data/blob/main/dist/ATLAS.yamlSchemahttps://github.com/mitre-atlas/atlas-data/blob/main/dist/schemas/atlas_output_schema.jsonPyTorch statement on compromised dependencyhttps://pytorch.org/blog/compromised-nightly-dependency/Analysis by BleepingComputerhttps://www.bleepingcomputer.com/news/security/pytorch-discloses-malicious-dependency-chain-compromise-over-holidays/