Recent research around new spreading approaches of one stealer malware family revealed a new way to abuse GitHub. Instead of creating repositories that contain malware files, hackers push the files they need through the issue reporting mechanism in the repository menu. This allows for making malware look like a file from a legit repo, bypassing all the security checks. It appears that GitLab is also vulnerable to such a trick.
Hackers Abuse GitHub and GitLab Feature to Upload Malware to Legit Repositories
The research regarding the new spreading campaign of RedLine stealer, that McAfee released the week before, revealed a rather unusual tactic. Hackers managed to place the malware file on the GitHub repository of Microsoft, without resorting to compromising one. Instead, threat actors exploited a design flaw of the platform.
In its Issue and Pull Request menus, GitHub offers users to attach a file they need – a neat feature which makes both actions convenient for users and the developers. Thing is – all the attachments are uploaded with the path of this repository, making them look like a thing related to this repo. User does not even need to post the message, as the link will work right away, after the system processes the file. These uploads do not appear anywhere in the repository and are kept only on GitHub’s CDN servers.
This forced analysts to dig further, and they discovered that GitLab, another developer platform, is susceptible to the very same issue. At the moment when a user attaches the file to a comment, the service generates a link to it. It remains active even if the comment was never posted or deleted shortly after publication.
This boils down to a simple conclusion: that feature allows the use of trusted and well-recognized repos as a concealed file sharing service. Repository masters will never know that someone is piggybacking their repo, and will not be able to do anything about it.
How dangerous is this?
In short: this can nullify any cybersecurity features that rely on trust ratings and designed to block access to web pages thas spread malware. Malicious programs rarely arrive “as is”, without loaders or other tricks that help it to examine the environment and run without interruptions. For quite some time now hackers rely on a place where they can upload the payload, so the said loader can pull and run one.
Usually, for this online storage, adversaries use a compromised website or a file sharing service. But modern security tools are aware of it and trigger the alarm when they see this traffic. On the other hand, a link that leads to the Microsoft repository, by the looks of it, will never be a reason for alarm. There is no way to tell whether the link leads to a file that is directly in the repo or just sits on a CDN.
The worst part here is that neither GitHub nor GitLab are able to fix the issue on short notice. Researchers who did the analysis of a GitLab case say they have contacted both companies, but did not receive a response yet. And honestly, I cannot see a quick and painless remedy here. Banning CDN uploads, the most straightforward decision, will disrupt genuine uploads. Integrating a malware scanning mechanism may create issues with educational open-source malicious software, and is also time consuming. That probably explains why the services remain silent on the request from the researchers.
