GitHub comments abused to push malware via Microsoft repo URLs(bleepingcomputer.com)
bleepingcomputer.com
GitHub comments abused to push malware via Microsoft repo URLs
https://www.bleepingcomputer.com/news/security/github-comments-abused-to-push-malware-via-microsoft-repo-urls/
39 comments
Isn't the workaround for this just ... actually submitting the issue? Then presumably GitHub won't delete the file.
Maybe. Haven't tried it. Though, that does make the attack vector a little less intense than persisting even without an issue. At least the attack vector can be tracked.
fwiw, I tested this out as well by clicking open issue and uploading a file and then not actually submitting the issue. the file is still accessible 2 days later.
so it doesn't appear to be fixed. :-|
so it doesn't appear to be fixed. :-|
Just want to point out that GitHub removing the asset after 15 minutes is actually worse than leaving it. The least appetizing aspect of this for adversaries is that your payload is now forever available to anyone with the logs. If it were adversary’s choice (submit the issue and it stays, only draft the issue and it gets wiped, good riddance, a phenomenal c2 stager indeed!)
Pretty standard stuff I would say.
Back in the day when I worked in this field malware writers regularly used things like Youtube as blob-storage and Instagram comments as C2 server mechanism.
Hiding in plain sight can be very effective.
Back in the day when I worked in this field malware writers regularly used things like Youtube as blob-storage and Instagram comments as C2 server mechanism.
Hiding in plain sight can be very effective.
I think the core issue is that anyone can easily create a URL for a file that looks like it was published by the Microsoft team.
Instead, if Github uploads used the uploader's Github account in the URL path, scammers would need to resort to other means like punycode to mislead users.
Instead, if Github uploads used the uploader's Github account in the URL path, scammers would need to resort to other means like punycode to mislead users.
> looks like it was published by the Microsoft team
Right, a simple way to make these URLs seem less associated with the project in question would be to host them at www.githubusercontent.com (a domain they use for other user-generated content, IIRC). I guess current setup includes an easy way to auth access to the files: if you have access to the repo that's right there in the URL, you can download the file; if it's a private repo that you don't have access to, you get a 404/403. That might save them from a separate metadata lookup.
This is one of those things that seems obvious now, but I could easily see how this could happen, and that kind of URL structure is something I could see myself devising, thinking it's an elegant way to tie the file to other repo access rules.
But really, it's surprising to me that GH keeps around files even if you cancel or delete the comment. Perhaps nowadays they don't need to care that much about storage costs, but back when they added that feature I imagine they might have been more cost-conscious.
Right, a simple way to make these URLs seem less associated with the project in question would be to host them at www.githubusercontent.com (a domain they use for other user-generated content, IIRC). I guess current setup includes an easy way to auth access to the files: if you have access to the repo that's right there in the URL, you can download the file; if it's a private repo that you don't have access to, you get a 404/403. That might save them from a separate metadata lookup.
This is one of those things that seems obvious now, but I could easily see how this could happen, and that kind of URL structure is something I could see myself devising, thinking it's an elegant way to tie the file to other repo access rules.
But really, it's surprising to me that GH keeps around files even if you cancel or delete the comment. Perhaps nowadays they don't need to care that much about storage costs, but back when they added that feature I imagine they might have been more cost-conscious.
Those links don’t have auth. If you have one from a private repo you can access it.
Back in the day, if your FTP server had ANY kind of vulnerability you could expect it to be filled with warez, mp3z, all sorts of shit.
This seems simple to fix - deactivate all links that didn’t become part of a published comment.
I’m sure this is hard, especially at that scale - then again it seems doable eventually.
I’m sure this is hard, especially at that scale - then again it seems doable eventually.
Or add a signed timestamp to the URL after which it isn't valid anymore. So the URL can't be used without opening the actual comment on GitHub.
When do you do this? After an hour? A day? A week? There's been cases it's taken me a few days to write a comment or PR message because I was still working on things.
If you set it to short (hours) it'll be pretty annoying and confusing for people. If you set it too long (more than a day), scammers will just keep generating new links.
It's not that simple to fix, certainly not with these kind of timeouts. The only solution is to not have a "trusted" URL like that.
If you set it to short (hours) it'll be pretty annoying and confusing for people. If you set it too long (more than a day), scammers will just keep generating new links.
It's not that simple to fix, certainly not with these kind of timeouts. The only solution is to not have a "trusted" URL like that.
Theoretically they could make links that are not posted in a comment private, and once you post the comment they would be made public.
What if you make the hyperlink a dot or a zero width character? What if you place it adjacent to a legitimate link?
Can't you just comb through the HTML for the href? Then the text of the hyperlink doesn't matter.
The point is that by doing so, you can smuggle the attachment past anyone who's reading the comment section, yet still appears to the system as a legitimate attachment.
The thread OP's comment was:
> This seems simple to fix - deactivate all links that didn’t become part of a published comment.
Currently, a major convenience for the malware spreader is being able to put malware on the server and get a usable URL back without submitting the comment. Deactivating links for unsubmitted comments that were canceled is orthogonal to identifying malware, and wouldn't make the comment readers more vulnerable than they already are.
> This seems simple to fix - deactivate all links that didn’t become part of a published comment.
Currently, a major convenience for the malware spreader is being able to put malware on the server and get a usable URL back without submitting the comment. Deactivating links for unsubmitted comments that were canceled is orthogonal to identifying malware, and wouldn't make the comment readers more vulnerable than they already are.
The obvious fix is to remove the repo information, but do you grandfather in old files by redirecting to the new URL?
I’d say no, which I guarantee will break some legitimate packages that depend on files uploaded in GitHub comments.
I’d say no, which I guarantee will break some legitimate packages that depend on files uploaded in GitHub comments.
> some legitimate packages that depend on files uploaded in GitHub comments
I love these one-sentence horror stories.
I love these one-sentence horror stories.
Depends might be a strong word but this would affect things like screenshots submitted in bug reports as well, which would be less than ideal at the very least.
They could probably even just parse all comments and rewrite them. Then remove the redirects. If this feature is being used as intended these files should all be just linked to from comments and they parse the markdown anyways.
While they are at it maybe they can expire some old files that aren't referenced...
While they are at it maybe they can expire some old files that aren't referenced...
One case I’ve seen often is the author of a repo making an issue with just some images in it, then using those image links in the README
GitHub has githubusercontent.com. Why was this domain not used for these uploads? Or did image uploads in comments predate that domain?
But either way putting the repo in the URL seems completely unnecessary. If you need to track ownership you can still do that in the backing database.
But either way putting the repo in the URL seems completely unnecessary. If you need to track ownership you can still do that in the backing database.
I could have sworn that githubusercontent was used for these uploads. I’m not at my computer now so I can’t double check, but I’m guessing there is some special case involved for these repos.
No, githubusercontent.com is used for image uploads, but file attachments have always been on github.com under the repo path. I recall using this as a makeshift distribution mechanism years ago, I was surprised and already thought about the security implications back then, so this abuse can’t possibly be new.
Using the repo prefix allows them to put the same auth on uploads. So if you don’t have access to a repo, you can’t access files uploaded in its issues either.
I'm not saying that they don't need to check auth by repo. They can still check the auth when they look up the metadata for the file. Just don't include it in the URL.
The auth difficulty may make moving the files to a different domain more difficult, but same domain path shouldn't matter.
The auth difficulty may make moving the files to a different domain more difficult, but same domain path shouldn't matter.
This is yet another example of hosting hostile content on an authoritative site.
I still have a service running to track this.[1] It's a join of PhishTank and a somewhat dated list of major sites. Google is by far the worst offender. Hosting phishing sites in Google Sheets, etc. is not unusual. Yahoo and Microsoft used to be on that list, but they got better at kicking off hostile content. Adobe (via Adobe Express) has quite a few entries.
[1] http://sitetruth.com/reports/phishes.html
[1] http://sitetruth.com/reports/phishes.html
People have also been using the fact that commit data inside of PRs can never be deleted (you must keep the URL though), to distribute pirated content (or links to it) for years now.
For others interested, the term for this appears to be "parasitic storage", and has been done with MANY other services.
File links from comments should just live on a separate page. They should have nothing to do with the repo name or the organization.
I think file link shouldn't contain repo information like microsoft.
It seems to work initially, but then 5m later the file gets deleted and the link leads to a dead s3 asset page.
So I believe this is fixed. Though the solutions suggested below are crafty, trying to reproduce myself shows me this has been addressed by the GH team