Hackers use unpublished GitHub and GitLab comments to generate phishing links that appear to come from legitimate open source software (OSS) projects.
The clever trick, first described by Open Analysis’ Sergei Frankoff last month, allows anyone to do it impersonate any repository they wish without the owners of that repository knowing. And even if the owners knew, they couldn’t do anything to stop it.
Case in point: hackers have already abused this method to distribute the Redline Stealer Trojan, using links associated with Microsoft’s GitHub-hosted repositories “vcpkg” and “STL,” according to McAfee. Frankoff independently discovered multiple cases involving the same loader used in that campaign, and Bleeping Computer found an additional affected repository, “httprouter”.
According to Bleeping Computerthe issue affects both GitHub, a platform with over 100 million registered users, and its closest competitor, GitLab, with over 30 million users.
Undetectable, unstoppable and credible phishing links
This notable flaw in GitHub and GitLab lies in perhaps the most banal feature imaginable.
Developers often leave suggestions or report bugs by leaving comments on an OSS project page. Sometimes, a comment like this will be about a file: a document, a screenshot, or other media.
When a file needs to be uploaded as part of a comment to the GitHub and GitLab content delivery networks (CDNs), the comment is automatically assigned a URL. This URL is visibly associated with the project the comment refers to. On GitLab, for example, a file uploaded with a comment earns a URL in the following format: https://gitlab.com/project_group_name/repo_name/uploads/file_id/file_name.
What hackers have realized is that this provides perfect cover for their malware. They can, for example, upload a malware loader for RedLine Stealer to a Microsoft repository and get a link in return. Although it contains malware, to anyone it will appear to be a legitimate link to a real Microsoft repository file.
But that is not all.
If an attacker posts malware to a repository, you’d imagine that the owner of that repository or GitHub would spot it and deal with it.
What they can do, then, is quickly post and then delete the comment. The URL continues to work and the file still remains uploaded to the site’s CDN.
Or better yet: the attacker can’t just post the comment in the first place. On both GitHub and GitLab, a working link is automatically generated as soon as a file is added to an in-progress comment.
Thanks to this trivial quirk, an attacker can upload malware to any GitHub repository they want, get a link associated with that repository, and simply leave the comment unpublished. They can use it in phishing attacks for as long as they want, while the impersonated brand will have no idea that such a link was generated in the first place.
Don’t trust the links
Malicious URLs tied to legitimate repositories lend credence to phishing attacks and, conversely, threaten them embarrass and undermine credibility of the impersonated party.
What’s worse: they have no recourse. According to Bleeping Computer, there is no setting that allows owners to manage files attached to their projects. They can temporarily disable comments, while preventing bug reporting and community collaboration, but there is no permanent fix.
Dark Reading has reached out to both GitHub and GitLab to ask if they plan to fix this issue and how. This article will be updated if either organization provides a response.
“Developers who see the name of a trusted vendor in a GitHub URL will often have confidence that what they are clicking on is safe and legitimate,” says Jason Soroko, senior vice president of product at Sectigo. “There have been many comments about how URL elements are not understood by users or don’t have much to do with trust. However, this is a perfect example that URLs are important and have the ability to create incorrect trust.
“Developers need to reconsider their relationship with links associated with GitHub or any other repository and invest some time in analyzing it, just as they would with an email attachment.”