Hackers Create Legit Phishing Links With Ghost GitHub, GitLab Comments

Share This Post

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.

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.

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 has reached out to both GitHub and GitLab to ask if they plan on fixing this issue and how. This article will be updated should either organization provide a response.

“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.”

https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt88b0e53ccd5ad9f1/6628035acc81a51d43aa992b/Typing-Image_Source_Limited-Alamy.jpg?disable=upscale&width=1200&height=630&fit=crop

This post was originally published on this site

More Articles

Article

Navigating SEC Regulations In Cybersecurity And Incident Response

Free video resource for cybersecurity professionals. As 2024 approaches, we all know how vital it is to keep up to date with regulatory changes that affect our work. We get it – it’s a lot to juggle, especially when you’re in the trenches working on an investigation, handling, and responding to incidents.

Article

BFU – Seeing is Believing

Oh no, the device is in BFU. This is the common reaction; a device needs extracting, and you find it in a BFU state. Often, there’s an assumption that a BFU extraction will only acquire basic information, but that isn’t always the case.