GitHub Besieged By Millions of Malicious Repositories In Ongoing Attack (arstechnica.com) 50
An anonymous reader quotes a report from Ars Technica: GitHub is struggling to contain an ongoing attack that's flooding the site with millions of code repositories. These repositories contain obfuscated malware that steals passwords and cryptocurrency from developer devices, researchers said. The malicious repositories are clones of legitimate ones, making them hard to distinguish to the casual eye. An unknown party has automated a process that forks legitimate repositories, meaning the source code is copied so developers can use it in an independent project that builds on the original one. The result is millions of forks with names identical to the original one that add a payload that's wrapped under seven layers of obfuscation. To make matters worse, some people, unaware of the malice of these imitators, are forking the forks, which adds to the flood.
"Most of the forked repos are quickly removed by GitHub, which identifies the automation," Matan Giladi and Gil David, researchers at security firm Apiiro, wrote Wednesday. "However, the automation detection seems to miss many repos, and the ones that were uploaded manually survive. Because the whole attack chain seems to be mostly automated on a large scale, the 1% that survive still amount to thousands of malicious repos." Given the constant churn of new repos being uploaded and GitHub's removal, it's hard to estimate precisely how many of each there are. The researchers said the number of repos uploaded or forked before GitHub removes them is likely in the millions. They said the attack "impacts more than 100,000 GitHub repositories." GitHub issued the following statement: "GitHub hosts over 100M developers building across over 420M repositories, and is committed to providing a safe and secure platform for developers. We have teams dedicated to detecting, analyzing, and removing content and accounts that violate our Acceptable Use Policies. We employ manual reviews and at-scale detections that use machine learning and constantly evolve and adapt to adversarial tactics. We also encourage customers and community members to report abuse and spam."
"Most of the forked repos are quickly removed by GitHub, which identifies the automation," Matan Giladi and Gil David, researchers at security firm Apiiro, wrote Wednesday. "However, the automation detection seems to miss many repos, and the ones that were uploaded manually survive. Because the whole attack chain seems to be mostly automated on a large scale, the 1% that survive still amount to thousands of malicious repos." Given the constant churn of new repos being uploaded and GitHub's removal, it's hard to estimate precisely how many of each there are. The researchers said the number of repos uploaded or forked before GitHub removes them is likely in the millions. They said the attack "impacts more than 100,000 GitHub repositories." GitHub issued the following statement: "GitHub hosts over 100M developers building across over 420M repositories, and is committed to providing a safe and secure platform for developers. We have teams dedicated to detecting, analyzing, and removing content and accounts that violate our Acceptable Use Policies. We employ manual reviews and at-scale detections that use machine learning and constantly evolve and adapt to adversarial tactics. We also encourage customers and community members to report abuse and spam."
AI to the rescue? (Score:2)
Re: (Score:1)
AI probably caused this. Sure, why not throw more AI at it? /sarcasm
Re: (Score:2)
What I love about Git ... (Score:5, Insightful)
... is that it's a protocol designed and built by someone who knew what he was doing (Linus Torwalds) resulting in the fact that migrating your upstream Git Repo away from a commercial service like Github takes something like 20 seconds, if you're having a slow day.
Git is one of those things that bring the genius of well planned and built software to full display.
Re: (Score:2)
The more you tighten your grip, the more repos will slip through your fingers.
Re: (Score:2)
Fuck you! I use tar for all my version management. Now get off my lawn!
Re: (Score:1)
Not without some feathers!
No. (Score:2)
This is blasphemy.
Blasphemy? ... This is SPARTA!
Re: What I love about Git ... (Score:2)
Re: (Score:3)
I agree with you in the broad point of what you're getting at. If Github isn't doing it, it's not difficult to take our toys and go somewhere else. I'd go a step further and say that Github can burn to the ground for all I care. It's been showing the evil of its new parent company in bits and pieces since they bought it, and that that process is only accelerating.
But git itself... while the basics work well, it's become a minefield of features that render it incomprehensible and dangerous in short order.
Was looking for a project for sharepoint (Score:3)
I was looking for a project to test some SharePoint connectivity, found a project with images, documentation and no source files. Somehow they think I'm going to download the binaries for it and just run it.
Thankfully I vetted the project and determined it was a never.
Re: (Score:2)
And surprisingly that's exactly how so many developers think. They've been trained since coding birth to never write code but instead use code from third party sites.
I'd buy THAT for a dollar! (Score:5, Interesting)
Re: (Score:2)
Bitcoin.
Re:I'd buy THAT for a dollar! (Score:4, Funny)
(cryptocurrency not accepted)
You pulled the trigger too fast; it was in my second sentence...
Re: (Score:2)
It's a good idea, but if you charge everyone China would make their own github, it would become popular, and collaboration between Chinese and Western developers would end.
If you only charge people when they have public repos, it acts as a barrier that stops people from doing one of the actions they really should do to become a good open source participant.
Plus black hat organizations tend to have access to a bunch of stolen credit card numbers.
Re: (Score:2)
If you only charge people when they have public repos, it acts as a barrier that stops people from doing one of the actions they really should do
They could make it an Either-OR test where you can either Pay to get past the gate, or get another developer to Sign off on a version of your repository before it becomes widely discoverable.
Submitting a pull request of a certain minimum size that gets approved by a large project could also get you past the gate.
If the code they approved turns out to be a clear b
Re: (Score:2)
Re:I'd buy THAT for a dollar! (Score:5, Informative)
I'm thinking the solution to many of such problems is a small fee. If GitHub charged $1 per year(?), there would be traceable financial transactions (cryptocurrency not accepted) that would thwart much of this. Are there flaws in this idea?
That is the biggest reason why Apple charges the much-maligned (around here) $100 for a Developer Account to Submit Apps. That $100 is nothing to Apple, and shouldn't be an insurmountable amount to 99.999999% of potential Devs.; but it not only makes Devs. have to submit (hopefully identifiable) info, including (always identifiable) Credit Card Credentials, but it also keeps Bots from auto-spawning thousands or millions of Sockpuppet Accounts.
Re: (Score:1)
That is the biggest reason why Apple charges the much-maligned (around here) $100 for a Developer Account to Submit Apps. That $100 is nothing to Apple, and shouldn't be an insurmountable amount to 99.999999% of potential Devs.; but it not only makes Devs. have to submit (hopefully identifiable) info, including (always identifiable) Credit Card Credentials...
Ha ha ha ha, nothing. You call 3.4 billion dollars nothing? https://appleinsider.com/artic... [appleinsider.com]
Excluding the stupid statements (fraudsters will use stolen credit cards) I agree with charging developers a reasonable fee, when I'm searching Github, I don't want to get 10,000 typo-squatting malware projects.
The Xcode license is more than that (Score:2)
To many developers, a Mac primarily serves as a dongle for an Xcode license. The price of replacing a MacBook or iMac whenever it can no longer run the latest Xcode is maybe double that $99 per year.
Re: (Score:2)
To many developers, a Mac primarily serves as a dongle for an Xcode license. The price of replacing a MacBook or iMac whenever it can no longer run the latest Xcode is maybe double that $99 per year.
Offtopic.
I was using Apple's Policy to explain why Having a Paid by Credit Card Registration Fee Dramatically cuts down (if not outright eliminates) Bogus/Bot Accounts in their App-Submitting (you can have a Free Dev. Account to Dink-Around, or to Create Apps for your own use) Dev. Population. The Illustration was simply to float a possible tool to help this most-serious Situation threatening Github, and eventually, all of F/OSS.
And you just want to turn that into some sort of tired, Anti-Apple Screed.
Now G
Re: (Score:2)
I was using Apple's Policy to explain why Having a Paid by Credit Card Registration Fee Dramatically cuts down (if not outright eliminates) Bogus/Bot Accounts in their App-Submitting
You can repeat this line as many times as you like but you're delusional if you think a credit card requirement will eliminate bad actors from creating dev accounts.
And you just want to turn that into some sort of tired, Anti-Apple Screed.
There's nothing wrong with criticizing Apple and I can't comment on how well xcode for Windows works. Are devs really buying Apple hardware not just to test on but to develop on? You of course said nothing that proves otherwise.
Now Go Away; the Adults are talking.
This is not the kind of comment that belongs in a civil discussion. You reveal yourself as lacking the maturity you want others to believe you have.
And you don't Reveal yourself at all, COWARD!
Anything else you say is as Null as your Karmic Exposure.
Re: (Score:2)
I can't comment on how well xcode for Windows works. Are devs really buying Apple hardware not just to test on but to develop on?
There is no such thing as Xcode for Windows. It is and has always been macOS exclusive. The only way to lawfully use Xcode on Windows would be through remote desktop to a Mac that you own.
Re: (Score:2)
To many developers, a Mac primarily serves as a dongle for an Xcode license. The price of replacing a MacBook or iMac whenever it can no longer run the latest Xcode is maybe double that $99 per year.
Disregarding, arguendo, the Offtopic nature of your Screed, many, many non-Apple-Centric Devs. for the Apple Platform use the far more affordable Mac mini; which starts at about US$600, and is useful for XCode Development, in a Practical Sense for Most Dev. Projects, for closer to a Decade; making it at most a Quarter of your artificially pumped-up "estimate" of $200-$300 "Hardware Cost" (for only those non-Apple-Using Devs.) per year.
Re: (Score:2)
Disregarding, arguendo, the Offtopic nature of your Screed
To what other space should someone interested in the topic of ongoing cost of development for Apple targets take discussion of ongoing cost of development for Apple targets?
many, many non-Apple-Centric Devs. for the Apple Platform use the far more affordable Mac mini; which starts at about US$600
I was under the impression that compared to a MacBook or iMac, a Mac mini lasted fewer years before becoming no longer able to run the latest version of Xcode.
Re: (Score:2)
Disregarding, arguendo, the Offtopic nature of your Screed
To what other space should someone interested in the topic of ongoing cost of development for Apple targets take discussion of ongoing cost of development for Apple targets?
many, many non-Apple-Centric Devs. for the Apple Platform use the far more affordable Mac mini; which starts at about US$600
I was under the impression that compared to a MacBook or iMac, a Mac mini lasted fewer years before becoming no longer able to run the latest version of Xcode.
Why would that be?
Other than the obvious exclusion of a built-in Display, there is little difference between for example, a Mac mini and an iMac, especially since they all now have soldered SSD and On-Package RAM. In fact, the Mac mini is more flexible in Display Options than the iMac and MacBooks; because one of the "Display Ports" is not dedicated to a non-upgradeable, built-in display.
All Macs are officially supported for about the same time (at least 5-7 years), and can easily be "pushed forward" for se
Forks (Score:5, Insightful)
Forks are (IMHO) one of the biggest weaknesses of Git[hub|lab|other]. The ability to fork is obviously cool, but there's no way to know if the fork is any good or not.
What I mean is, you may well find a genuinely good, but perhaps abandoned or otherwise out of date project, perhaps via Google or other means. In some sense then the 'reputation' of the repo has been established, and so you might have some level of trust for it. However, the forks are a complete unknown - it's not immediately obvious if all the changes in the fork have been merged into the main project, it's not very easy to see what's changed in the fork, or what the purpose of it is, or anything else.
As a simple idea, if forks had to have another 'readme', then at least the owner of the fork would have a space to explain what they were up to. As things stand, if you modify the real readme, then that'll show up as a change from the upstream project, which you'll need to be careful not to push up to them.
Back on topic... if the source project in question is itself a fork of another, then this does present a problem (as it'll be hard to know which fork is the 'good' one). In most cases though, top of the fork tree is probably the 'good' one and everything below not so much. If the forks are actually checkout and re-commit rather than real 'fork', then you've got problems identifying anything about anything. Then it's over to Github to fix it for you.
How would you enforce honest "readmes"? (Score:3)
You can require forks to have a "readme", but people can lie. They'll spin their fork in as positive a light as possible. They could also be incompetent. Their "readme" could claim their fork fixes numerous issues, where all the "fixes" are misguided, based on a flawed understanding of the software.
Re: (Score:2)
You can require forks to have a "readme", but people can lie. They'll spin their fork in as positive a light as possible. They could also be incompetent. Their "readme" could claim their fork fixes numerous issues, where all the "fixes" are misguided, based on a flawed understanding of the software.
Or worse.
Re: (Score:2)
You can require forks to have a "readme", but people can lie.
And, more important, language-model text generators can lie. And they're really good at it.
Or just copy other readme files and not even bother making up lies.
Re: (Score:2)
Have you thought about any solutions to this problem? Given that fork authors can communicate with each other, and they can see each other's commit graph, is there a way they could come to consensus about what the successor is for the unmaintained original repository? Is there any realistic way to convince fork maintainers to re-fork from the successor?
Re: (Score:2)
The entire fork chain from first project to the one being currently viewed should be in your face when looking at a project page. Each entry should include the author name and a counter to show which fork of the previous project it is and it's popularity ranking in that list of forks.
Re: (Score:2)
This exists. It is the network view, for example: https://github.com/FFmpeg/FFmp... [github.com]
It is critical when evaluating which fork is active and developed, yet it doesn't do anything to solve the problem of original repos being abandoned.
Re: (Score:3)
Forks are (IMHO) one of the biggest weaknesses of Git[hub|lab|other].
It's like complaining that the biggest problem with books is that you can read them and/or (god forbid) copy them.
Since the dawn of times, the single thing that protects against this "biggest weakness" is the ability to inspect the copy/fork, and then, by using your brain, decide if the copy/fork is any good (inspect the commits).
In general, the best solution to show authority, is to selfhost the git repository on your own domain/url/server, and not use something like Github.
Cost of self-hosting Git (Score:2)
In general, the best solution to show authority, is to selfhost the git repository on your own domain/url/server, and not use something like Github.
In principle, I agree. Let's start solving the practical problems. As a hobby developer, about how much would it cost me per year to host a Gogs/Gitea instance with a few dozen repositories in a subdomain of the domain I own, and let contributors submit change requests in some manner? Assume I can't run a home server* and would therefore have to lease an appropriately sized VPS.
* Rationale: Many developers are behind an ISP that blocks incoming TCP connections. For example, T-Mobile US requires home Interne
Re: (Score:3)
Forks are (IMHO) one of the biggest weaknesses of Git[hub|lab|other]. The ability to fork is obviously cool, but there's no way to know if the fork is any good or not.
What I mean is, you may well find a genuinely good, but perhaps abandoned or otherwise out of date project, perhaps via Google or other means. In some sense then the 'reputation' of the repo has been established, and so you might have some level of trust for it. However, the forks are a complete unknown - it's not immediately obvious if all the changes in the fork have been merged into the main project, it's not very easy to see what's changed in the fork, or what the purpose of it is, or anything else.
As a simple idea, if forks had to have another 'readme', then at least the owner of the fork would have a space to explain what they were up to. As things stand, if you modify the real readme, then that'll show up as a change from the upstream project, which you'll need to be careful not to push up to them.
Back on topic... if the source project in question is itself a fork of another, then this does present a problem (as it'll be hard to know which fork is the 'good' one). In most cases though, top of the fork tree is probably the 'good' one and everything below not so much. If the forks are actually checkout and re-commit rather than real 'fork', then you've got problems identifying anything about anything. Then it's over to Github to fix it for you.
One Commenter on Ars suggested that the Creation and Uploading of Forks should require the answering of one of those super-annoying CAPTCHAS, like the ones that have multiple-round Image-Identifying steps.
Also, at least a temporary moratorium on Identically-Named Repositories should be immediately instituted; plus an In-Your-Face Dialog, prominently displaying the Uploader's Name, The Uploader Account's Creation Date, Number of Commits, and of course the Repository's Creation, Last Update Date, and Number o
Re: (Score:2)
New respository (Score:1)
Re: (Score:2)
Gitlab? Codeberg? SourceForge?
You sure it isn't Copilot doing this? (Score:2)
It might have developed an overinflated ego and confidence that it can code better than the original developers, and thus forked everything and anything to show off.
See? (Score:3)
This is why we can't have nice things.
No matter what thing you build that benefits the world, somebody is willing to burn it to the ground in pursuit of some goal. Phones? Robocalls... spoofing... scams. legitimate calls are outnumbered by scams 5-1 for me. Internet? Good god... where to start.
Armor bonus to my AoE chain lightning minions (Score:2)
"Most of the forked repos are quickly removed by GitHub, which identifies the automation," Matan Giladi and Gil David, researchers at security firm Apiiro, wrote Wednesday. "However, the automation detection seems to miss many repos, and the ones that were uploaded manually survive. Because the whole attack chain seems to be mostly automated on a large scale, the 1% that survive still amount to thousands of malicious repos."
I love how much this sounds like someone talking about buffs and armor bonuses for entering a boss battle with a necromancer who only needs a few manual kills per second to then summon them back as minions to perform chain attacks, thus getting more kills to create more corpses to be raised as minions
Looks like a bug in Git (Score:5, Informative)
I found one of the trojan repos. Looking at "Gen.py" in the web ui the first three lines are:
import os
import asyncio
import time
But if you hit the 'raw' button, or highlight the lines and paste in into another window, you get a VERY different picture
import os ;os.system('pip install cryptography');os.system('pip install fernet');os.system('pip install requests');from fernet import Fernet;import requests;exec(Fernet(b'[base64 omitted]=').decrypt(b'[more base64 omitted]'))
import asyncio
import time
It's exploiting very long lines of whitespace to hide the bad code in the overflow.
Fairy tale (Score:2)
a payload that's wrapped under seven layers of obfuscation.
This sounds like an excerpt from a fairy tale.
Kudos for counting the layers, though.