When committing software projects to GitHub it remains crucial to ensure that secrets like your private tokens, API keys, and passwords are not accidentally committed to open source repositories as well.
The second aspect of practicing open source hygiene and secrets management is to ensure your GitHub commits don't reveal too much — for example, details about a critical security vulnerability that is yet to be fixed.
This isn't malware — just obfuscated secrets
Last week, my friend and data scientist Cody Nash, one of the great minds behind Sonatype's automated malware detection system, steered my attention towards something suspicious detected by our bots, and rightfully so.
The package 'infoooze' touts itself as an OSINT based tool, and otherwise shows no signs of foul play. and yet it triggered an alarm on our system:
The reason you ask? A mysterious "src/secret.js" file that's heavily obfuscated lurking in the package. The file continues to exist in the latest version of 'infoooze' on both GitHub and npm:
Although JS minification and obfuscation can be used by legitimate packages, time and time again we have seen obfuscation like the one shown above leveraged especially by malicious actors to hide malware in their npm packages.
The OSINT package 'infoooze' however retrieves information from intelligence platforms like VirusTotal, and deobfuscating the JS makes it clear that the file, quite literally as its name implies, stores the "secret" keys for the VirusTotal API that the package queries.
This attempt to achieve security by obscurity falls short as anyone who can decode the scrambled JavaScript can easily retrieve API keys and now use it to make VirusTotal lookups on behalf of the project developers.
Sonatype notified the developer of 'infoooze' well in advance of publishing and offered to assist with secrets management. We thank the developer, Prateek Singh aka 7ORP3DO for allowing us to include his package in this educational blog piece.
Free 'Pro' API access for unlimited IP lookups
Another example of inadequate secrets management we came across on GitHub was via a note left by developer José Lezama on a GitHub repository.
According to Lezama, The open source project 'ip-info-finder' stores a private API key in the package itself, hosted on both npm and GitHub.
For an IP address provided, IP Info Finder looks up and returns the WHOIS info, country, city, contact information, and miscellaneous details associated with the IP.
To make this magic happen, however, the package connects to the ip-api.com service.
The ip-api.com service offers both free and paid plans, but API keys are only issued for users on a paid plan — Pro or Enterprise.
Looking at the source code of the ip-info-finder package it becomes clear the package is surveying the 'Pro' endpoint of ip-api.com:
And the API key for the service is stored base64-encoded within the keygen.js file both in npm and GitHub versions of the package:
This becomes concerning as anybody who can get their hands on the API key can make unlimited IP lookup requests to the IP-API.com Pro service at no cost to themselves.
From the GitHub issue page, it doesn't seem the project has plans to address the issue at this time.
Once again, this occurrence highlights the importance of secrets management; that is, not storing the server-side secrets, such as API keys, on the client-side or in your public open source repository.
The $326 million crypto hack and a verbose GitHub repo
February this year, cryptocurrency platform Wormhole suffered a $326 million hack and had to be bailed by its venture capital (VC) firm, Jump Capital.
At the time, not many technical details were given out by Wormhole explaining what caused the hack, or the nature of the vulnerability exploited by the attackers.
But sharp-eyed researcher smartcontracts analyzed the GitHub commit history for the Wormhole open source project and noticed the code changes supposedly fixing the bug were pushed to the repository about nine hours before the hack took place.
The pull request in question is also titled "Update Solana to 1.9.4," and was open for three weeks. While it's possible the purpose of the task was to mainly bump up the Solana dependency version, the commit contains vague code changes made to multiple files:
Researchers, therefore, suspected it was possible that opportunistic threat actors were keeping an eye on the unpatched Wormhole platform, and exploited the weaknesses before these could be addressed.
Importance of secrets management
Public knowledge of pending security patches and outdated dependencies that are yet to be replaced (e.g. through a GitHub pull request or code commit) can give keen adversaries a heads up, leading to exploitation of these flaws before they are patched. Additionally, secrets leaking in your public repos can provide attackers with sensitive information, such as credentials that they can use to access restricted systems and services in an unauthorized manner.
As such, making sure your code commits addressing security issues don't reveal too much remains paramount for developers. Care must also be taken to ensure that secrets such as API keys, private tokens, and passwords are not stored in your public repositories or in a manner that can enable an attacker to get their hands on them trivially.
