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."
That's what you get (Score:5, Funny)
That's what you get when you allow Italians like this guy on America's internet. Don't say I didn't warn you.
The remedy is that we all need to be more proactive about patronizing Wisconsin cheese and California wine.
Re:That's what you get (Score:5, Funny)
Dude, it is far worse than you imagine. The guy is obviously Russian. The Russians are coming!
Re: (Score:2)
No, that's what you get for using a dying language (Score:5, Funny)
Ruby on Rails - the perfect blend of poor performance (Ruby) and gaping holes (Rails).
Re:No, that's what you get for using a dying langu (Score:4, Insightful)
If you don't want people to do this:
@user.update_attributes({:favorite_color => 'blue',
You need to do this:
class User < ActiveRecord::Base
attr_protected
end
Re:No, that's what you get for using a dying langu (Score:4, Insightful)
While it's true that it was sloppy coding, it is also true that the default is not really safe - and it probably should be.
Re: (Score:2)
Re: (Score:2)
like facebook? hardly anyone uses that piece of crap.
Re:PHP (Score:5, Funny)
What no Guantanamo Bay for him? (Score:5, Insightful)
Re:What no Guantanamo Bay for him? (Score:5, Insightful)
Oh wait.. this is an open source community that understood what his intentions where and didn't have a knee jerk reaction.
What I guess intelligence trumps mass panic and ignorance.
You have to realize this isn't some random dude, but a guy "well known" as having an octocat tattoo on his arm...
http://homakov.blogspot.com/2011/07/octocat-tattoo.html [blogspot.com]
Re:What no Guantanamo Bay for him? (Score:5, Interesting)
Re:What no Guantanamo Bay for him? (Score:5, Informative)
Re: (Score:2)
Not really. Suppose you sneak in a boring-sounding commit from one of the core developers of a project. That developer probably won't notice because it's lost amongst the other commits, and even though no-one else will be able to push changes until they merge the malicious commit into their own copies, that's so common in a multi-user repository that all the developers will probably do it without a moment's hesitation.
Wrong target re: individuals preceded him... (Score:2)
Based on TFA I thought the hack was more about a default flaw with Ruby on Rails key signing, not anything that was specific
Re: (Score:1)
So an octocat tattoo will protect people from being detailed without trial in Guantanamo Bay?
Re: (Score:2)
For those who don't get the "joke" he's about as close to being an insider as a outsider can be.
It would be kind of like Alan Cox posting a GIT commit in the 3.0 series using Linus's account for April Fools Day, although thats technically wrong, no ones going to freak out, or at least his odds of waterboarding are no greater than any other random innocent civilian, in other words too high in an absolute sense, but in a relative sense pretty low odds... Actually putting this in writing probably ruins the ch
Re: (Score:2)
Re: (Score:1)
Oh wait.. this is an open source community that understood what his intentions where and didn't have a knee jerk reaction. What I guess intelligence trumps mass panic and ignorance.
Incorrect assumption. Although there is a passive, appreciate communiy behind such an effort, you will see a joint effort by Italian, European and American authorities to eliminate this violation. Start with international wire fraud, malicious intent to harm, and move down the list to sopa-like attrocities such as violating terms of a website and you've got life in prison. Give them 5 more years of legislation and we'll have Texas-style hangings for these incredibly threatening comical hackers.
I heard a
Re: (Score:3)
Oh wait.. this is an open source community that understood what his intentions where and didn't have a knee jerk reaction.
What I guess intelligence trumps mass panic and ignorance.
That's exactly wrong. GH freaked out and banned his account after the Rails team repeatedly closed his bug reports. This story has been on Hacker News for a while now, so you can head there for the full story. His account was eventually reinstated after it was made clear to GH that they behaved poorly.
Re: (Score:2)
Nice hacker (Score:1)
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:Nice hacker (Score:5, Insightful)
This is NOTHING like lack of sanitizing or SQL injection.
Suppose your object has fields "name" and "is_special", and the web form only exposed "name" because "is_special" isn't supposed to be changed by regular users. The hacker who knows "is_special" exists, adds an "is_special" field to the web form on his browser and submits it. The developer probably uses "update_attributes" to process the form, and with default Rails settings it will commit the new "is_special" value to the database (properly sanitized, of course).
To prevent this, the developer may switch the settings to white-list, and provide a list of safe attributes for mass-assignment (update_attributes being one of the mass-assignment methods). Some people believe white-list mode should be the default settings. The hacker, probably being one of these people, found a great way to make his point that even seasoned Rails developers could use a push towards using white-lists.
Re:Nice hacker (Score:5, Insightful)
This is NOTHING like lack of sanitizing or SQL injection.
Yes, the act of processing user-supplied data in an unintended manner is exactly what "lack of sanitizing" means.
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...
Re: (Score:2)
I was thinking sanitation as in string sanitation and SQL injection as in '); drop table students; --. Thanks for pointing out the bigger picture, TheNinjaroach, vlm. I retract the word "NOTHING" from my previous post.
Re: (Score:3)
I've barely worked with Rails, but from what you're describing, isn't this bug somewhat like the security problems with register_globals [php.net] in PHP, which started defaulting to "off" almost a decade ago?
Everything old is new again...
Strategic software (Score:5, Insightful)
I think it's time to think about repository for strategic software, like Linux, GCC and so on.
Such a hacking can compromise a large part of the internet. Because someone can introduce backdoors, the nasty ones I mean, so deep to evade any check.
Re:Strategic software (Score:4, Insightful)
Such a hacking can compromise a large part of the internet. Because someone can introduce backdoors, the nasty ones I mean, so deep to evade any check.
Well, as far as git goes, you can't make changes undetected because all commits are signed and all clones of a repository have the whole history log.
Re: (Score:2)
Re: (Score:3)
Yes, the id of every commit is a cryptographic hash of the contents of that commit, which inherently includes the state before it; if you tried to insert a commit in the middle of the commit tree, all the id's would change, or not compute... Hard to say what would happen, because it just won't work. The tools would all scream at you. It would be very obvious, if it could even be done.
They may not all be "signatures" in the sense of identifying who committed it, but it *does* validate the consistency of th
Re:Strategic software (Score:4, Interesting)
I think the use of Git makes it pretty safe to begin with.
If someone gained access to do commits to what people consider as the "master" repo, any tampering would have to be done at the head because of all the hashes.
Hopefully the maintainer would realize this the next time they go to push to it Git would tell them that the remote is ahead of them by X commits.
In the case of Linux, I think Linus is the only one who pushes to the master branch, so he would notice.
Re: (Score:2)
You got it right. That was my goal and I got it.
But you failed to get my point: the fun.
distributed (Score:5, Insightful)
Fortunately, git is a distributed version control system, meaning that, usually, there is a copy of the sources and history information elsewhere.
Re: (Score:2)
Re: (Score:3)
It's also used for distributed development, which means that usually all the copies of the source and history information have pulled from the upstream GitHub repository and will contain any malicious code that was committed to it.
Re: (Score:2)
you don't have any idea how GIT works, do you ? or maybe you are FUDding ?
two words: distributed [wikipedia.org] and Cryptographic authentication of history [git-scm.com]
No, I have no idea the cryptographic details of GIT works - I was responding to the information in the post above mine with a hypothetical evil genius scenario in my limited understanding of DVCS (i.e. copies of stuff in multiple places). I am happy to read that it seems the developers of GIT are smarter than those that developed Sourcesafe. Which isn't a herculean feat.
I felt a great disturbance in the Force (Score:5, Funny)
...as if millions of voices suddenly cried out from coffee shops in terror and were suddenly pwned. I fear something terrible, and totally predictable, has happened.
Just wait a few years, Ruby on fails will strike back!
it could have been worse (Score:1)
Re: (Score:3)
Which would be noticed the next time anyone does a push to the repository. There'd be an unexpected non-fast-forward push, and git would force developers to deal with it by default.
The response of 99.9% of humanity: (Score:2, Insightful)
Re:The response of 99.9% of humanity: (Score:5, Insightful)
This is Slashdot, the 99.9% doesn't come here
Re:The response of 99.9% of humanity: (Score:5, Funny)
This is Slashdot, the 99.9% doesn't come here
Slashdot, home of the 0.1%.
Re: (Score:2)
This is Slashdot, the 99.9% doesn't come here
Getting close, UID 2018246, I see that 1e9*0.001 = 6000000 so apparently you show we're more than 1/3 of the way there... What is the largest /. UID and how does it compare to six million? I donno how to account for astroturfing and spam and gnaa accounts, on the other hand lots of people read and few open accounts to write, so we're probably breaking into the 99.9% range.
Re: (Score:2)
Plus, the number is probably slightly inflated by slashdot users who periodically create new accounts just to check and see the current count.
Also, Don't forget the 0.0001 * $WORLD_POPULATION accounts that are owned by Michael Kristopeit.
Re: (Score:2)
Millions? There's only one of you.. and boy are you prolific... and somewhat talented. Up at all hours, hammer and tongs sometimes.. you can go for weeks on end posting all sorts of enlightened prose along with complete bullshit.
My hat off to you, Anonymous Coward, without you /. just wouldn't be the same.
Just like Github isn't exactly the same as it was before
The response of 99.9% of Web Developers (Score:2)
Real Hacker (Score:5, Insightful)
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!
Lucky it was a white hat (Score:2)
That could've gone a lot worse...and to think many stupid countries are trying to make such benevolent activities illegal.
The devs were notified and ignored it (Score:5, Interesting)
Apparently GitHub's own admin isn't "pro" enough...
Re: (Score:2)
Apparently GitHub's own admin isn't "pro" enough...
I tried reading that thread but the language is convoluted and I know next-to-nothing about rails - am I reading it right - the devs were essentially saying "pro users know how to secure their installs!" and then got pwned themselves with the exact hack that Homakov had reported?
Re:The devs were notified and ignored it (Score:5, Interesting)
Re: (Score:3)
You're reading it right. And he actually had to blatantly pwn them repeatedly before they would deign to take notice, and even then they didn't do anything abou it until they got ridiculed across the entire Internet.
Makes the (broken) PHP development community look relatively sane.
WTF were they smoking? (Score:5, Insightful)
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: (Score:3)
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.
As I understand it, Rails isn't taking just any fields that a user submits. It's actually checking the fields against the model and only assigning the ones it recognizes. So yeah, it "knows" the parameters it is seeing and they are all valid so we're good to go.
Except that there are fields in any model that the user *shouldn't* be able to change via form. And lo, there is a mechanism in Rails to flag those fields in the model so that this sort of things doesn't happen: attr_accessible flags.
But attr_accessi
Re: (Score:3)
Madness... when defining the form you explicitly define which attributes of the model may be submitted and modified and everything else is ignored. Forms should be the filter between the crap a user may submit and your precious model.
Django does this right in my eyes: allowed a
He got the results he wanted (Score:5, Informative)
Frank Drebin knows what to do. (Score:2)
irresponsible (Score:2, Funny)
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.
They KNEW about this vulnerability? (Score:2)
When did Microsoft and Oracle start doing Open Source maintenance? Or did the GitHub team download their development principles and follow those instead of doing security reviews?
Both Microsoft and Oracle are notorious for leaving reported bugs open for years unless someone demonstrates an effective exploit using the bug. But historically, Open Source projects have taken such risks seriously and closed the holes long before an exploit showed up.
To me, that "constant maintenance" aspect of open source
How do you verify your git repo? (Score:2)
To calm any fears that no rogue commits have been added as a result of this hack?
Is git log enough and looking at the last datetime stamp?
Re:GitHub hacked (Score:5, Informative)
Re: (Score:3)
Indeed, I know a few people who are working on some commercial software with one. This is kind of a big deal (although the risk that someone made subtle alterations to say, the Linux kernel, is also a very big deal).
Re:GitHub hacked (Score:5, Informative)
Re: (Score:2)
But would he actually look at all commits? Nope, hundred, thousands, you gotta trust where its coming from if it said signed off by .
But hey, there's more. We invented a way to make sure "signed off" is _actually_ the person who say they signed off. It's called a cryptographic signature. And it's generally implemented through GnuPG.
It happens that GIT now support per commit GPG signature for this reason (after telling me so many times "oh we don't see the point for implementing it"). Regardless, if everyone
Re: (Score:2)
everyone checks the signatures locally via a list of people you trust for commits
Somehow this screams "bad idea" to me.
Re: (Score:3)
So, somebody hacked into a computer system to gain access to open source software. Brilliant.
If you can't imagine a way that unfettered access to *alter* an exceptionally popular piece of software, virtually undetected, would be useful to someone with unscrupulous intent, then good for you for being so pure of heart. However, in the rest of the world, access like that can be absolutely devastating.
Re:GitHub hacked (Score:4, Interesting)
If you can't imagine a way that unfettered access to *alter* an exceptionally popular piece of software, virtually undetected
I can't imagine a way to do that with git. Sorry, its just pretty hard to do, especially "virtually undetected". git just doesn't work that way. Probably a hell of a lot easier and more likely to succeed and frankly cheaper to get commit rights "the right way" and then sneak in 100 perfectly legit real world commits and just one with an intentional bug or issue or whatever. Now, if by "... alter ... popular ... software.." you mean something like modify the github site and user provided data itself to point to some images on some .ru domain that include yet another drive by MSIE exploit, sure that could probably have been done. But the git hosted projects are basically safe, assuming anyone is actually using them.
Which brings up an interesting attack vector, if you find generic abandoned mp3 player number 2352 on sf or github and "take it over" by whatever means, then you could put weird stuff into it without anyone noticing since no one git pulls it. This could be a problem.
Re: (Score:2)
Sorry, its just pretty hard to do, especially "virtually undetected". git just doesn't work that way.
So you're pretty safe, unless someone used a hack that gave him admin access over where the source code for git was stored, and might subtly change the way git works so that it's not so safe after all. Oh, wait ...
A successful "Thompson hack" would be devastating, git adds a new vector vector for one, and this is one heck of a scary vulnerability to be ignored by the maintainers (fortunately, they did fix rapidly once this stunt happened - but what happened in the past?)
Re: (Score:2)
But git is stored in git, so to sneak stuff into it in order to break git's security, you would have to break git's security first.
On the other hand, hiding malicious changes in otherwise legit-looking commits is a whole different issue that has nothing to do with github or git.
Re: (Score:2)
But git is stored in git, so to sneak stuff into it in order to break git's security, you would have to break git's security first.
With this flaw, couldn't you commit to the git codebase as Linus (or anyone legit) though? Of course, whomever you impersonated might notice.
On the other hand, hiding malicious changes in otherwise legit-looking commits is a whole different issue that has nothing to do with github or git.
Well, you'd need to do this once the normal way to break git, but having done that the 'hiding' part would become trivial (well, with git's tools).
Re: (Score:2)
The issues is a privilege escalation exploit. Git has no permissions model whatsoever. If you can access a git repo you can do anything you like to it with any name or address you like. Git doesn't care at all. Instead you're suppo
Re: (Score:2)
Looked more like that showed a vulnerability on it.
The real danger are the ones that could had been exploiting it and didn't announced that... and then, modified some obscure core component in a not very monitored repository to introduce a trojan or backdoor into some widely deployed open souce software based on it (i.e. not sure if that problem would make able to mask a commit as one from a trusted and active developer)
Re: (Score:2)
The real danger was the people who knew of the vulnerability for quite a while and did nothing to fix it.
Re: (Score:2)
Words change. Either move on with everyone else or be left behind.
Your choice.
Re: (Score:2)
In this situation, the term hacking is the correct usage of the term. As per your posted link,
"Hackers will sometimes do questionable legal things, such as breaking into systems, but they generally will not cause harm once they break in."
Homakov only made superficial changes to allow him to commit a snide remark to illustrate and publicize the inherent weakness in a cloud storage system used by many independent developers and commercial entities.
In almost any other situation I would side with you on the horrible misuse/overuse of the term "hacking".
Re: (Score:2)
the inherent weakness in a cloud storage system
You may want to look at what he actually did. The problem is people who don't understand "mass assignment protection" dumping rails apps on the internet with CRUD functionality and "sensitive" portions of the data.
There's an inherent conflict between just being able to scaffold something up "instantly" and keeping certain attributes locked away from the average users, and this inherent conflict has never been decisively resolved. Any time you have a tool that makes it easy to CRUD, you're going to end up
Re: (Score:2)
At this point this is practically a troll.
The battle is over and we lost. Insisting on differentiating between hacking and cracking is just silly now. The word never caught on and never will.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
What does this have to do with Linux? The vulnerability was in Rails - and I must say, the attitude of the Rails developers of "We don't have to make the defaults restrictive - let the user secure their app" is a poor one.
Oh, the linked commit is not the only funny one - after this guy's initial report was blown off by the Rails team - https://github.com/rails/rails/issues/5239 [github.com]
Re:Linux security or trust (Score:5, Informative)
Re: (Score:2)
If git itself is hacked cleverly enough, pulling in an innocuous change to the linix source using get also pulls in the malicious code secretly. Someone might catch it by inspection with other tools - or might not! This is why "Thompson hacks" are scary - if you can mess with the basic tools, you can be very subtle.
Re: (Score:2)
Re: (Score:2)
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:Linux security or trust (Score:4, Funny)
Thankfully, no serious projects are hosted on GitHub.
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]
Re:Linux? Since when? (Score:3)
"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.
Linux??? Can we mod summary as troll? Linux has its origin repository in kernel.org and is distributed over cloned repositories all over the world including my laptop. One can't simply inject a commit into one of those repositories (such as github) and expect it to automatically propagate into kernel.org.
Furthermore, even if you manage to inject a commit into some random project at Github, high are the chances that it would be detected by another developer. Who commits to a repository without reading the co
Re: (Score:2, Funny)
Couldn't resist [quickmeme.com]
Re: (Score:2)
That pretty much summarizes it :P quite funny also, thank you!
Re: (Score:2)
I've been spending too much time on Reddit, where 70% of communication is done with memes. (The rest are puns)
Re: (Score:2)
Who can really go over every line of code in the source to make sure someone hasn't already snuck in something malicious years ago?
Your local repository of git?
Re: (Score:3)
As far as I can tell, the entire point of update_attributes is that it's easy to pass unsanitized data directly from a user request to it and this makes rapid development of Rails applications simpler. Supposedly pretty much no major Rails applications get this right, so it's not surprising the one hosting the Rails Git repository doesn't either.