NOT THE BOLTDB YOU'RE LOOKING FOR Go Module Mirror served backdoor to devs for 3+ years Supply chain attack targets developers using the Go programming language. Dan Goodin Feb 5, 2025 7:25 am | 2 Credit: Getty Images Credit: Getty Images Story textSizeSmallStandardLargeWidth *StandardWideLinksStandardOrange* Subscribers only Learn moreA mirror proxy Google runs on behalf of developers of the Go programming language pushed a backdoored package for more than three years until Monday, after researchers who spotted the malicious code petitioned for it to be taken down twice.The service, known as the Go Module Mirror, caches open source packages available on GitHub and elsewhere so that downloads are faster and to ensure they are compatible with the rest of the Go ecosystem. By default, when someone uses command-line tools built into Go to download or install packages, requests are routed through the service. A description on the site says the proxy is provided by the Go team and run by Google.Caching inSince November 2021, the Go Module Mirror has been hosting a backdoored version of a widely used module, security firm Socket said Monday. The file uses typosquatting, a technique that gives malicious files names similar to widely used legitimate ones and plants them in popular repositories. In the event someone makes a typo or even a minor variation from the correct name when fetching a file with the command line, they land on the malicious file instead of the one they wanted. (A similar typosquatting scheme is common with domain names, too.)The malicious module was named boltdb-go/bolt, a variation of widely adopted boltdb/bolt, which 8,367 other packages depend on to run. The malicious package first appeared on GitHub. The file there was eventually reverted back to the legitimate version, but by then, the Go Module Mirror had cached the backdoored one and stored it for the next three years.The success of this attack relied on the design of the Go Module Proxy service, which prioritizes caching for performance and availability, Socket researchers wrote. Once a module version is cached, it remains accessible through the Go Module Proxy, even if the original source is later modified. While this design benefits legitimate use cases, the threat actor exploited it to persistently distribute malicious code despite subsequent changes to the repository.There were other things designed to draw developers to the package. One was that the README file accompanying boltdb-go/bolt is a copy of the one from the original benign package. Another is that the original package had been archived. Developers frequently choose active forks over older versions. Others may be deceived into thinking such a malicious package is the original/legitimate one.The backdoor snuck into the module, constructed a hidden IP address and port, and connected to an attacker-controlled server. It would then execute whatever commands the remote server issued. The server IP address, hosted by Hetzner Online (AS24940), had a trustworthy reputation. The Socket researchers suspect the infrastructure was procured specifically for the campaign to avoid detection. Unlike indiscriminate malware, this backdoor is designed to blend into trusted development environments, increasing the likelihood of widespread compromise before discovery, they wrote.After discovering the module, Socket petitioned last Friday for it to be removed. Socket petitioned once again on Monday, when the package finally came down. In an email, the researchers provided the following sequence of events:Threat actor creates a typosquatted repository (github.com/boltdb-go/bolt) on GitHubThey publish a backdoored version (v1.3.1) with a hidden remote access mechanismGo Module Mirror fetches and caches this version, storing it for future installationsThe threat actor modifies the GitHub repository, replacing v1.3.1 with a clean versionManual reviewers inspecting GitHub would now see only the clean versionDespite the GitHub repository appearing safe, the Go Module Mirror continues to serve the malicious version of v1.3.1 to developersWe identified the malicious cached package and petitioned for its removal from the Go Module Mirror on January 30, 2025 and then again on February 3, 2025.We also reported the GitHub repository and associated account to GitHub for further investigation and takedown on February 3, 2025While the GitHub repository was "clean" by the time of detection, the cached package served through the Go Module Proxy remained malicious. This is why Gos module caching behavior presents a security risk, as it allows attackers to hide their traces after their package is cached.Threat actor creates a typosquatted repository (github.com/boltdb-go/bolt) on GitHubThey publish a backdoored version (v1.3.1) with a hidden remote access mechanismGo Module Mirror fetches and caches this version, storing it for future installationsThe threat actor modifies the GitHub repository, replacing v1.3.1 with a clean versionManual reviewers inspecting GitHub would now see only the clean versionDespite the GitHub repository appearing safe, the Go Module Mirror continues to serve the malicious version of v1.3.1 to developersWe identified the malicious cached package and petitioned for its removal from the Go Module Mirror on January 30, 2025 and then again on February 3, 2025.We also reported the GitHub repository and associated account to GitHub for further investigation and takedown on February 3, 2025While the GitHub repository was "clean" by the time of detection, the cached package served through the Go Module Proxy remained malicious. This is why Gos module caching behavior presents a security risk, as it allows attackers to hide their traces after their package is cached.Representatives from both Google and the Go team didnt respond to emails asking what steps are taken to ensure the safety of modules made available through the mirror.The research tells a cautionary tale of the importance of properly vetting code before running it on production devices. This process includes verifying package integrity before installation, analyzing dependencies for anomalies, and using security tools that inspect installed code at a deeper level.Dan GoodinSenior Security EditorDan GoodinSenior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 2 Comments