Abusing GitHub File Upload Feature via GitHub Comments

Initials

I have been reading a lot about this abuse which is related to GitHub Comments where adversaries are using Comments Feature to upload malicious binaries/malwares/droppers via well known repositories, Microsoft GitHub repository was in the limeline as RedLine Stealer was being spread under Cheats for the gaming community.

This stealer was linked to 2 Microsoft Official GitHub repositories.

• https://github.com/microsoft/vcpkg
• https://github.com/microsoft/STL

How it works

So, by reading the articles it looks like this is a default functionality of GitHub. This happens when anyone tries to create a comment on a GitHub Repository. Lets see it in action as below.

I have taken the below screenshot from the McAfee Research Article linked below in the references.

It can clearly be seen that when the user tries to upload/attach the document into the Issues/Comments or anywhere where GitHub allows to upload files, it always took the name of the user who owns that repository.

While this should have been true for the case where the owner/author of the repo is trying to upload the document. This was the case with the contributors as well.

However, just by taking another look, it looks like GitHub has removed this functionality i.e. taking the name of the owner and then linking it to the attachment.

In the below screenshots, i have tried to upload the file named Malicious.zip.

In the below screenshot, the file is uploaded successfully.

So, using this link, it is possible to download the file. What happens when the owner of the repo or the contributor deletes the comments/issues etc.

The file remains on the GitHub CDN.

In the articles, it was mentioned when we try to upload the image files, they are moved into the /assets directory which remains true for now as well.

However, the same is not the case for uploading ZIP files.

While on trying to upload an exe file directory we are blessed with the filetype check.

However, taking a closer look, i can validate the there is no Magic Bytes check by the GitHub and it only validates the Last Extension of the file being uploaded.

Just to give an example look at below.

The following is what i tried to do.

1. Uploaded a Malicios ZIP file, which goes under user-attachments.
2. Uploaded 1.png which goes under RepositoryName/Assets.
3. Uploaded ca.png, went under RepositoryName/Assets.
4. Uploaded ca.exe.png renamed to ca exe and went under RepositoryName/Assets.

Monitoring?

So, from all this study, we can come to the conclusion that we can not monitor everything as there should be other controls in place. However, as ZIP files can still be uploaded, teams should be monitoring the below URL as this has limited the surface after the GitHub fix.

For ZIP files, rather than monitoring the entire GitHub URLs, we just need to monitor the below URLs to have visibility on what is being downaloaded.

https://github.com/user-attachments/*

Conclusion

So what we devise from all this is, there was a potential success factory when adversaries were able to host malicious zip files directly on well known repositories and that increased the chances of success for the threat actors.

However, this is now limited as GitHub is moving ZIP files under user-attachments. BUt will still be working and threat actors will be hosting malicious ZIP files on GitHub CDN.

But as same files can be uploaded by just changing the extensions, this is still possible. However, threat actors needs to be in the position to download the payload in another format hosted on GitHub CDN and then convert it into the right format/extension and then have it executed.

This will limit the direct exposure where users trust the trusted GitHub repo names in the URLs but this is not going to eliminate this technique.

References

• https://www.mcafee.com/blogs/other-blogs/mcafee-labs/redline-stealer-a-novel-approach/

• https://www.bleepingcomputer.com/news/security/github-comments-abused-to-push-malware-via-microsoft-repo-urls/