6 ms·
GitHub comments abused to push malware via Microsoft repo URLs
- lpapez 3y agoPretty 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.
- bitwize 3y agoBack 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.
- et-al 3y agoI 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.
- kelnos 3y ago> 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.
- aprilnya 3y agoThose links don’t have auth. If you have one from a private repo you can access it.
- thih9 3y agoThis 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.
- mmoskal 3y agoI guess easier to make the url be githubusercontent.com/whatever without mentioning repo name (or use uuid of repo).
- thih9 3y agoSure, but existing links would still be an issue.
- pquki4 3y agoWhat if a comment is updated to remove the link? Or maybe a new comment has no link, an edited version has a link, then the latest version removes link etc.
- sebazzz 3y agoThat's why you need to do garbage collection from time to time. That adds a lot of complexity to the system.
- gruez 3y agoWhat if you make the hyperlink a dot or a zero width character? What if you place it adjacent to a legitimate link?
- cute_boi 3y agoI think file link shouldn't contain repo information like microsoft.
- Avi-D-coder 3y agoThe 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.
- pavel_lishin 3y ago> some legitimate packages that depend on files uploaded in GitHub comments I love these one-sentence horror stories.
- TheCleric 3y agoDepends 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.
- kevincox 3y agoThey 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...
- aprilnya 3y agoOne 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
- kevincox 3y agoGitHub 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.
- captn3m0 3y agoUsing 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.
- kevincox 3y agoI'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.
- chatmasta 3y agoI 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.
- oefrha 3y agoNo, 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.
- chatmasta 3y agoI’ve been using it as a free image host for years now (you don’t even need to actually post the comment, just drop the image in the box and grab the URL)… hopefully they don’t kill it :)
- Animats 3y agoThis 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 http://sitetruth.com/reports/phishes.html
- butterlesstoast 3y agoI just attempted this myself by creating an issue, commenting a file, copying the link and not submitting the issue. 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
- cmeacham98 3y agoIsn't the workaround for this just ... actually submitting the issue? Then presumably GitHub won't delete the file.
- butterlesstoast 3y agoMaybe. 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.
- V-eHGsd_ 3y agofwiw, 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. :-|
- bsmartt 2y agoJust 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!)
- anste 3y agoFile links from comments should just live on a separate page. They should have nothing to do with the repo name or the organization.
- ranger_danger 3y agoPeople 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.
- ranger_danger 3y agoFor others interested, the term for this appears to be "parasitic storage", and has been done with MANY other services.