GitHub Hacked 202
MrSeb writes "Over the weekend, developer Egor Homakov exploited a gaping vulnerability in GitHub that allowed him (or anyone else with basic hacker know-how) to gain administrator access to projects such as Ruby on Rails, Linux, and millions of others. GitHub uses the Ruby on Rails application framework, and Rails has been weak to what's known as a mass-assignment vulnerability for years. Basically, Homakov exploited this vulnerability to add his public key to the Rails project on GitHub, which then meant that GitHub identified him as an administrator of the project. From here, he could effectively do anything, including deleting the entire project from the web; instead, he posted a fairly comical commit. GitHub summarily suspended Homakov, fixed the hole, and, after 'reviewing his activity,' he has been reinstated. Homakov could've gained administrative access to the master branch of any project on GitHub and deleted the history, committed junk, or closed or opened tracker tickets."
Re:GitHub hacked (Score:5, Informative)
Re:Nice hacker (Score:5, Informative)
I find it funny that since this guy hacked github
See that's the problem. He didn't hack github. There is a wide open door in scaffolded rails apps. I am somewhat involved in rails development and even I know this, but "most people don't care". The problem in as few words as possible is a lack of input sanitation and/or more or less is the equivalent of allowing SQL injection. Makes for easy scaffolding and rollout. All you need to do is tell rails which attributes people should and should not be able to F with, which is trivially easy and impossible to default without turning rails into a fully cognitive AI system smarter than the programmers who refuse to declare which attributes are sensitive and which are not....
The phrases you don't know to google for are "mass assignment protection" and attr_accessible and attr_protected
http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1 [enlightsolutions.com]
Re:Linux security or trust (Score:4, Informative)
That is rather easy to answer. Git is a distributed version control system such that you can't make changes without it being noticed by the real authors. See ... http://git-scm.com/about ... for a better explanation. To get something malicious into the code you will need to get into the primary lieutenants source trees.
Re:Linux security or trust (Score:5, Informative)
The master branch isn't on github, if there was any tampering a trivial check against Linus' master branch would see if there'd been any extra git commits. Nobody has to go through more than that. By the way, it's also impossible to insert an "old" commit in git because you'd have to reapply every subsequent patch and all the ids would change. But I guess that you're scaremongering and the mods are either clueless or feeding the troll.
Re:Real Hacker (Score:5, Informative)
Yes. Just yes.
He did a. They ignored him.
He did b, too. He filed a ticket. The ticket got closed, just like that.
He could've just done nothing and waited for someone to mess up Github. Instead he shouted louder.
More props to this guy.
And btw his Octocat tattoo is henna (meaning fake, not a real tatttoo), to all you attention-deficit idiots.
Re:Real Hacker (Score:5, Informative)
Except he did both a and b, and they basically told him to go pound sand.
c. Demonstrate the vulnerability in a somewhat childish yet harmless and hilarious manner. Give everyone a good laugh, raise more awareness of the issue, and give the rails yet more security related black eyes!
Seems reasonable enough to me!
Re:Linux security or trust (Score:5, Informative)
Re:Linux security or trust (Score:5, Informative)
This was brought up when kernel.org was compromised last year. The decentralized nature of git makes that really hard to sneak by, especially if you use the kind of process controls that the Linux kernel uses. Legitimate commits go through maintainers, and maintainers will definitely flip if they see code pulls into their repository that they didn't commit. Some deeper discussion about how you can't just sneak things into the past history is here: http://security.stackexchange.com/a/6771/836 [stackexchange.com]
He got the results he wanted (Score:5, Informative)
Re:GitHub hacked (Score:5, Informative)
Re:What no Guantanamo Bay for him? (Score:5, Informative)
Re:WTF were they smoking? (Score:4, Informative)
Pardon some of my ignorance but isn't the point of using "smart" frameworks that you wouldn't need to worry about that stuff since the framework should _know_ what parameters it's asking the users browser to submit?
surely there has to be a framework designed with that in mind? "serve the user this blabla page that has these blabla input boxes"-> from the response just read those.
seems that rails(and how github was using it) was moving business logic to random users computers and effectively taking them as a trusted part of the system? maybe the devs should spend more time playing online games and seeing crack cheaters.
Re:irresponsible (Score:5, Informative)
He did disclose the publically.
The developers thought it was working as intended.
He hacked the site to show that they're morons.
They patched the issue.
Re:Nice hacker (Score:4, Informative)
Also, the process of carefully crafting weird http traffic to insert unexpected things is exactly the process for SQL injection, except obviously strange non-developer intended attributes are being inserted instead of "sql EOL character followed by big sql fun" from a classic sql injection attack. Its a very close analogy... The meta-rule that both specific rules lives under is if you're depending on the general internet public to send you something, you can expect someone out there to send you some absolutely crazy stuff and you better be prepared for absolutely anything. If you're not planning on getting UTF-16 encoded XML with embedded COBOL source code for an Intercal interpreter, there's someone in China coding it up right now, so you better get ready for it...
His alternative way to describe how it works and at least one way to avoid it was pretty good, regardless of his analogy analysis skills... I though "as few words as possible" and "more or less the equivalent" was about as wishy washy as I could be when tossing an analogy out there. True, I may have a low /. UID, but I wasn't exactly Moses reading the commandments off the tablets there... And if I was I'd have better commandments than this one...