Headline
Hackers Create Legit Phishing Links With Ghost GitHub, GitLab Comments
An utterly innocuous feature in popular Git CDNs allows anyone to conceal malware behind brand names, without those brands being any the wiser.
Source: Image Source Limited via Alamy Stock Photo
Hackers are using 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 Sergei Frankoff of Open Analysis last month, allows anyone to impersonate any repository they wish without the owners of that repository knowing about it. And even if the owners do know about it, they can’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 repos “vcpkg” and “STL,” according to McAfee. Frankoff independently discovered more cases involving the same loader used in that campaign, and Bleeping Computer found an additional affected repo, “httprouter.”
According to Bleeping Computer, the issue affects both GitHub — a platform with more than 100 million registered users, and its closest competitor, GitLab, with more than 30 million users.
Undetectable, Unstoppable, Believable Phishing Links
This remarkable flaw in GitHub and GitLab lies in possibly the most mundane feature imaginable.
Developers will often leave suggestions or report bugs by leaving comments on an OSS project page. Sometimes, such a comment will involve a file: a document, a screenshot, or other media.
When a file is to be uploaded as part of a comment on GitHub’s and GitLab’s content delivery networks (CDNs), the comment is automatically assigned a URL. This URL is visibly associated with whatever project the comment pertains 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 figured out is that this provides perfect cover for their malware. They can, for example, upload a malware loader for the RedLine Stealer to a Microsoft repo, and get a link in return. Though it houses malware, to any onlooker, it will appear to be a legitimate link to a real Microsoft repo file.
But that’s not all.
If an attacker posts malware to a repo, you’d figure that the owner of that repo or GitHub would spot it and address it.
What they can do, then, is publish and then quickly delete the comment. The URL continues to work and the file remains uploaded to the site’s CDN, nonetheless.
Or, even better: The attacker can simply not post the comment to begin with. On both GitHub and GitLab, a working link is automatically generated as soon as a file is added to a comment in progress.
Thanks to this banal quirk, an attacker can upload malware to any GitHub repo they wish, get a link back associated with that repo, and simply leave the comment unpublished. They can use it in phishing attacks for as long as they’d like, while the impersonated brand will have no idea that any such link was generated in the first place.
Don’t Trust Links
Malicious URLs tied to legitimate repos lend credence to phishing attacks and, conversely, threaten to embarrass and undermine the 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, concomitantly preventing bug reporting and collaboration with the community, but there is no permanent fix.
Dark Reading reached out to both GitHub and GitLab to ask if they plan on fixing this issue and how. Here’s how one responded:
“GitHub is committed to investigating reported security issues. We disabled user accounts and content in accordance with GitHub’s Acceptable Use Policies, which prohibit posting content that directly supports unlawful active attack or malware campaigns that are causing technical harms,” a GitHub representative said in an email. “We continue to invest in improving the security of GitHub and our users, and are looking into measures to better protect against this activity. We recommend users follow the instructions provided by maintainers on how to download the software that is officially released. Maintainers can utilize GitHub Releases or release processes within package and software registries to securely distribute software to their users.”
Dark Reading will update the story if GitLab responds. In the meantime, users should tread lightly.
“Developers seeing the name of a trusted vendor in a GitHub URL will often trust that what they are clicking on is safe and legitimate,” says Jason Soroko, senior vice president of product at Sectigo. "There has been a lot of commentary about how URL elements aren’t 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 capacity to create mistaken trust.
“Developers need to rethink their relationship to links associated with GitHub, or any other repository, and invest some time scrutinizing, just like they might with an email attachment.”
About the Author(s)
Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes “Malicious Life” – an award-winning Top 20 tech podcast on Apple and Spotify – and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts “The Industrial Security Podcast,” the most popular show in its field.