Alleged Hacker Infects Python Project, Apologizes and Claims to be a Researcher

An alleged hacker added a malicious binary to the PyTorch machine-learning project on Python and then clarified that it was not intentional. The binary had the potential to expose the username, environment variables, a list of password hashes, and the first 1000 files in the user’s home directory, among other data, for anyone to decode.

The presently unknown attacker pleaded and clarified that they were a researcher who was investigating the dependency confusion issues.

The details of the alleged cyberattack infecting Python

Since the attacker used the name “torchtriton”, which was the name of a software package loaded from the private repository, and the malicious package was in the PyPI repository, it took precedence and got installed over the one in the official repository.

The name ‘torchtriton’ was maliciously used by the attacker and the use of the package in the Python Package Index with the functions which was usually employed in PyTorch. This led to the uploading of other users’ data to a server in another domain which is not defunct.

In an advisory, the PyTorch team urged users to uninstall PyTorch nightly installed on Linux via pip between 25 and 30 December. They also asked them to uninstall torchtriton and replace it with the latest nightly binaries that are newer than 30 December 2022. These are:

1. $ pip3 uninstall -y torch torchvision torchaudio torchtriton
2. $ pip3 cache purge

The advisory notified users regarding the supply chain attack adding that it affects dependencies for packages on public package indices. However, those on the PyTorch stable packages were not impacted by the malicious dependency package torchtriton.

Details of the malicious binary

1. The malicious binary was installed at – PYTHON_SITE_PACKAGES/triton/runtime/triton
2. Its SHA256 hash was – SHA256(triton)=2385b29489cd9e35f92c072780f903ae2e517ed422eae67246ae50a5cc738a0e
3. It was capable of gaining system data, including nameservers, hostnames, usernames, working directory names and environment variables.
4. It could also access /etc/hosts and /etc/passwd among other files.
5. It was capable of uploading the stolen information through encrypted DNS queries to the now defunct *.h4ck[.]cfd domain using the wheezy[.]io DNS server.

What the alleged hacker said

In a tweet, the alleged hacker defended themselves by saying that had they been a criminal, they would have sold the data to the highest bidder. They clarified that they even reported the vulnerability to Facebook on December 29 and several times to the company itself.

Apologizing for the disruption, the tweet read that they would have never filed a bug bounty report either if their intention was malicious.

Researchers remain skeptical about the authenticity of the defendant.- “How is this a “false alarm”? This malware deliberately steals your data… and transmits it scrambled, not encrypted (AES-256-GCM with a hardcoded key and IV), so anyone on your network path who recorded it can trivially decode it,” responded Paul Ducklin, whose bio describes him as a “passionate security proselytiser”.