Hackers are using the names of popular GitHub repositories to trick users into downloading malicious code, new research reveals.
Checkmarx analysis found that cybercriminals are abusing GitHub's search functionality to trick unsuspecting developers into uploading malware to their systems.
The author of the report, Checkmarx research engineer Yehuda Gelb, detailed how hackers use a number of techniques to artificially inflate the popularity of their fake repositories to push them higher in GitHub search results.
The first of these involves taking advantage of the platform's automation tool, GitHub Action, to frequently update malicious repositories, making minor adjustments to a log file or updating the date or time, for example.
This activity in the repository increases its visibility, particularly if developers choose to filter their search by the most recent updates, a common option for developers who want to ensure that code is properly maintained.
The attackers were also observed creating multiple fake accounts to promote their own malicious repositories, adding fake stars in an attempt to make the asset appear more trustworthy.
Gelb noted that this research found that attackers had become more subtle in their attempts to push their fake repositories among developers, learning from previous cases where attackers were easily identifiable by the high amount of churn their fake activity created.
“Unlike previous incidents where attackers were found to be adding hundreds or thousands of stars to their repositories, it appears that in these cases the attackers opted for a more modest number of stars, likely to avoid raising suspicion with an exaggerated number.” , Gelb explained.
“This social engineering technique is designed to manipulate users into believing that the repository is widely used and trusted, taking advantage of the inherent trust that users place in highly featured repositories.”
GitHub Users Should Be Careful of Suspicious Visual Studio Project Files
The malicious code used in these attacks is often hidden within Visual Studio project files to evade detection, according to the study, which is automatically executed when the project is built.
Unless users explicitly search the repository for suspicious items, they will not notice questionable files, the report notes.
Interestingly, the PowerShell script contained in the malware retrieves the country code of the target machine's IP address to determine if the victim is located in Russia.
Depending on where the victim is located, the payload downloaded to the machine is different, suggesting that the attackers could be located in Russia and tailor their attacks to avoid impacting domestic entities and reduce any unwanted attention from state authorities. .
The report includes advice on some Indicators of Compromise (IoC), including whether the repository in question received complaints via the GitHub Issues feature or pull requests from developers who experienced problems after downloading and deploying code.
Gelb recommended developers take a closer look at repositories, paying attention to commit frequency.
For example, does the repository have an incredible number of commits compared to the time it has been available on the platform? Or do these modifications only change a file with minor edits?
Gelb also recommended users research the accounts that have featured the repository they are considering using, paying special attention to how long these accounts have been active and whether they match other accounts that have featured the repository.
All of these indicators should warn developers to be careful before downloading and running code, according to Gelb, who argued that the recent XZ attack should be enough evidence to prove that relying on reputation is not enough for meaningful chain security. of supply.
“Following the XZ attack and many other recent incidents, it would be irresponsible for developers to rely solely on reputation as a metric when using open source code,” Gelb wrote.
“A developer who blindly takes code also blindly takes responsibility for that code. These incidents highlight the need for manual code reviews or the use of specialized tools that perform extensive code inspections for malware. Simply checking for known vulnerabilities is insufficient.”
