With over 73,000 views, a few thousand upvotes, and several hundred comments it's easily the most successful video I've ever published to Youtube.
Or anywhere, for that matter.
Cachy is based on Arch Linux, and in that video I spent a lot of time praising the Arch User Repository which has recently become the vector for a massive malware supply-chain attack.
An attack that's distributed automatically using trusted sources as a vector, and apparently open-source is pretty vulnerable to this sort of thing.
In early 2024 was the first time I had heard the term supply chain used in regards to software. During the Covid fiasco we heard the term a whole a lot regarding how goods get(or didn't get) to our stores and homes.
The 2024 Linux Supply Chain Attack was given a CVSS (Common Vulnerability Scoring System) rating of 10, The highest possible.
And a Common Vulnerabilities and Exposures identification of CVE-2024-3094.
The XZ Utils Backdoor exploit was distributed upstream in the Github repository of XZ Utils which is part of the Tukaani Project.
The code was committed by the user account Jia Tan, and more specifically found in the liblzma library. XZ is a data compression tool essentially ubiquitous to Linux.
A script called by build-to-host.m4 unpacks malicious test data and used it to modify the build process.
IFUNC, a mechanism in glibc that allows for indirect function calls, is used to perform runtime hooking/redirection of OpenSSH's authentication routines. IFUNC is a tool that is normally used for legitimate things, but in this case it is exploited for this attack path.
Because the malicious XZ Utils versions (5.6.0 and 5.6.1) were discovered before rolling out to major enterprise distributions, the vulnerability primarily affected beta, development, and rolling-release Linux distributions rather than production servers
This was a very sophisticated attack that was virtually undetectable, and was only found because Microsoft employee who discovered it noticed an ever-so-slight lag when using OpenSSH.
This attack was believed to be state-sponsored by many security analysts.
On June 9th through 12th the AUR attack dubbed "Atomic Arch" was discovered.
Because it's limited to Arch Linux distros it was not given a proper CVE ID, but Sonatype security has assigned it a CVSS score of 8.7.
The malicious code was implanted in ORPHANED AUR packages.
The AUR is a separate repository for packages submitted by Arch users, and is use at your own risk. And there is absolutely risk:
AUR packages are more like scripts. They consist of PKGBUILD files that contain recipes for building software on Arch, and they pull packages from various 3rd party sources.
The attackers automated the creation of new AUR accounts, and automated the adoption of orphaned packages. It turns out adopting orphaned packages is as simple as the click of a button so it's not particularly impressive.
I have found Reddit posts from 6 years ago mentioning that this is a very likely vector of attack.
One clever move they employed was spoofing the git commit metadata to make their changes appear as though they had been done by the previous maintainer or creator of the orphaned packages.
The first wave of attacks added this simple line of code:
npm install atomic-lockfile
NPM is the Node Package Manager which is commonly used by developers, and it's central part of Node.js: a very popular Javascript backend for building websites and applications.
The second wave command uses
bun install digest-js
Bun is a newer Javascript framework based on Apple's Webkit/Javascript-Core instead of Google's V8.
Bun is developed by Anthropic. The very-same company who is famous for the Claude AI LLM that's all the rage with developers.
Developers are the target of this attack rather than individual user compromise.
But the malicious files themselves were on the npm/bun repositories, and the AUR's Pkgbuilds are simply the vector of attack.
If a user had these orphaned packages installed on their system, and updated between Jun 9th-12th; the changes would be pushed to their system.
Both commands pull the same payload: A Credential-Stealer written and compiled in Rust that steals all sorts of important credentials like SSH keys, cloud credentials, crypto-wallet addresses, and even the bearer tokens for AI services.
Rust is a relatively young programming language that has had an insane amount of success/adoption.
Rust compiles down to a native, statically linked binary that's inherently less conspicuous to detection.
The second possible attack vector is a ROOTKIT that exploits eBPF.
A Rootkit is inherently an extreme vulnerability because it's purpose is to reach Ring-0 of the system; meaning the kernel where it's virtually unrestricted.
eBPF is kind of difficult to explain, but it's like a virtual-machine, in the kernel that modifies how data moves through the operating system.
eBPF is actually commonly used in security, firewalls, and tracing tools that are used to detect exploits.
This Rootkit uses eBPF to hide the main payload. The 3 maps it installs make this malware/attack and it's networking invisible to people trying to locate it.
But what's interesting is the stealing of the credentials happens when you install the package from the AUR.
So the Rootkit's job appears to be making sure you don't realize this happened because you'd be able to rotate your credentials/passwords.
Or at least this is my best understanding of it.
A systemd service unit is also generated that makes this process persistent if you kill it, or reboot your system.
To get the stolen credentials off your system it runs a http-server called temp.sh. This is a very common public server (and .sh shell script) to see which also conceals it's purposes.
It routes out of your network via a reverse-proxy through local-loopback(127.0.0.1)
to a command & control server over the TOR network.
TOR stands for The Onion Router, and it's specifically for making your web traffic anonymous. It's also how you get onto the "Dark Web".
I don't think there's any evidence of the attacker having the ability to remote-in to the infected system, but rather the exploit is automated to locate the credentials and send them out to the "command & control server".
But theoretically it could be used to do other things on the infected computer.
Over 1900 AUR orphaned packages were infected.
On a positive note; the fact that they were orphaned packages means they were probably not widely-installed on Arch systems to begin with.
But if you performed an update between June 9-12, and had any of these packages installed you'd be exposed to this very serious threat.
Some people talking about this attack have pointed out that the method the attacker used to infect the AUR packages was very conspicuous. Automating the creation of new accounts, and adopting 400 and later 1500 orphaned packages isn't exactly subtle. But then the exploit itself is pretty sophisticated at concealing itself. These two things are incongruent, and that makes me wonder if this supposed to be some kind distraction so the real intention would be missed altogether.
The same method used to add the exploits was also used to modify the ~/.bashrc, ~/.zshrc, and ~/.config/fish/config.fish files where your user terminal configurations are stored to add echo commands(commands that basically write text into your terminal) with Russian language-profanities and slurs regarding Ukraine.
To me, this looks like an attempt to place the blame on Russian attackers, and doesn't necessarily mean this was carried out by Russians.
For instance, it could just as well mean this was carried out by Ukrainians who would prefer to indict Russians.
Or even US hackers wanting to do the same.
As of publishing this you still cannot register or create an AUR account.
They may even change the rules somehow since this happened.
A list has been compiled of all the known infected packages that I will link here: AUR Attack Package List
And here is a tool that can be used to scan for this exploit, and it can detect lots of other older exploits as well:
AUR Malware Check
File Size: 255.1 Megabytes
Runtime: 10 minutes 21 seconds long
Container: ISO MP4/M4A 1920x1080
Codec: H.264(High Profile) 30 frames per second | Bitrate: 3083-kbps
Audio container:MPEG-4 AAC Stereo 48000Hz | 193-kbps
Six video tracks & 2 audio tracks.
Planned, produced/recorded, and edited over about 2 weeks (this is pretty fast for me.)