BleepingComputer recently reported how a GitHub flaw, or possibly a design decision, is being abused by threat actors to distribute malware using URLs associated with Microsoft repositories, making the files appear trustworthy.

It now turns out, GitLab is also affected by this issue and could be abused in a similar manner.

While most of the malware-associated activity was based around the Microsoft GitHub URLs, this “flaw” could be abused with any public repository on GitHub or GitLab, allowing threat actors to create very convincing lures.

GitLab comments can also be abused to push malware

On Saturday, BleepingComputer reported how threat actors have been abusing GitHub comments to push malware while making it seem like the malicious files were hosted on official source code repos of credible organizations.

The following URLs, for example, which were used in the attack made it seem like these ZIPs were present on Microsoft’s source code repo:

https://github[.]com/microsoft/vcpkg/files/14125503/Cheat.Lab.2.7.2.zip
https://github[.]com/microsoft/STL/files/14432565/Cheater.Pro.1.6.0.zip

Following our investigation, however, we learned that these files—which are malware, were nowhere to be found on Microsoft’s code repo.

Rather, these existed on GitHub’s CDN and were likely uploaded by a threat actor who abused the platform’s “comments” feature.

When leaving a comment on a commit or pull request, a GitHub user can attach a file (archives, documents, etc), which will be uploaded to GitHub’s CDN and associated with the related project using a unique URL in this format: ‘https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}.‘

For videos and images, the files will be stored under the /assets/ path instead.

Instead of generating the URL after a comment is posted, GitHub automatically generates the download link after you add the file to an unsaved comment, as shown below. This allows threat actors to attach their malware to any repository without them knowing.

Even if the comment is never actually posted or later deleted by the user (or an attacker), the link to the file remains live.

Sergei Frankoff, of automated malware analysis service UNPACME, had livestreamed about this bug just last month, saying that threat actors were actively abusing it.

Shortly after our reporting, readers pointed out that GitLab was not immune from this issue either.

BleepingComputer can confirm that users can indeed abuse the “comments” feature on GitLab in a similar fashion.

In our tests, we were able to upload files that would get uploaded to GitLab’s CDN but look like these existed with GitLab repos of popular open source projects like Inkscape and Wireshark:

https://gitlab[.]com/inkscape/inkscape/uploads/edfdbc997689255568a7c81db3f3dc51/InkScape-2024-Latest.exe
https://gitlab[.]com/wireshark/wireshark/uploads/b4162053fbb4dc6ee4f673c532009e16/WireShark-v4.2.4-stable-release.exe

The file used in our test is a benign JPG image, renamed to .exe to demonstrate how, by abusing this feature, threat actors can mislead users into downloading counterfeit software releases laced with malware.

The format followed by such files uploaded to GitLab CDN is:

https://gitlab.com/{project_group_namr}/{repo_name}/uploads/{file_id}/{file_name}

The file_id here looks like an MD4 or MD5 hash as opposed to a simpler numeric identifier.

Much like with GitHub, the generated GitLab file links would remain alive even if the comment was never posted  by the attacker or later deleted.

GitLab does prompt users to sign in before they can upload or download these files, but that does nothing to prevent threat actors from uploading these files in the first place.

Since virtually every software company uses GitHub or GitLab, this flaw enable allow threat actors to develop extraordinarily crafty and trustworthy lures.

For example, a threat actor could upload a malware executable in NVIDIA’s driver installer repo that pretends to be a new driver fixing issues in a popular game. Or a threat actor could upload a file in a comment to the Google Chromium source code and pretend it’s a new test version of the web browser.

These URLs would also appear to belong to the company’s repositories, making them far more trustworthy.

Unfortunately, even if a company learns their repos are abused to distribute malware, we could not find any settings that would allow them to manage or delete files attached to their projects.

BleepingComputer contacted both GitHub and Microsoft on Thursday, April 18th about this abuse but did not receive a response. We have also approached GitLab for comment in advance of publishing and are awaiting a response.