Posts Tagged ‘homakov’

I know this is slightly old news, but I still wanted to talk briefly about it.  Near the beginning of March, GitHub users received this message via email.

A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. This would have provided an attacker with clone/pull access to repositories with read permissions, and clone/pull/push access to repositories with write permissions. As of 5:53 PM UTC on Sunday, March 4th the vulnerability no longer exists.

While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys.

. . .

Until you have approved your SSH keys, you will be unable to clone/pull/push your repositories over SSH.

. . .

Sincerely, The GitHub Team

The following is a rough sequence of events that led up to the official notification of the users.  All times are in PST.

March 1
3:14 AM
Homakov opens Rails issue 5228 for mass assignment vulnerability. [source]
March 2
6:10 AM
Homakov tests the vulnerability by opening an issue “from the future”. [source]
Homakov's Future Issue
March 2
10:07 AM
Issue 5228 is closed. [source]
March 3
3:19 PM
Issue 5228 is deemed not a Rails issue. [source]
fxn's Comment
March 4
8:49 AM
Homakov fully demonstrates the vulnerability by committing to the Rails master branch. [source]
Homakov's Commit
March 4 GitHub suspends Homakov’s account. [source]
March 4
9:53 AM
GitHub fixes the vulnerability on their site. [source]
March 4
12:31 PM
GitHub posts an entry on their blog informing the public of the exploit. [source]
March 4
1:56 PM
Homakov describes the procedure for the exploit on his blog. [source]
March 4
4:20 PM
GitHub posts another blog entry detailing Homakov’s reinstatement, as well as amendments to their security policy. [source]
March 4
4:22 PM
Homakov’s account is reinstated. [source]
March 7
10:22 AM
GitHub sends out an email informing all users that their public keys have been frozen and will be unusable until manually approved. [source: email]

This is a classic case of hacker discloses vulnerability by exploiting vulnerability.  Opinions often vary as to whether or not this is an appropriate method of disclosure.  The intentions of the responsible parties have to be called into question, as well as the level of severity of the exploit.  In this case, many argued that Homakov tried to report the issue but was brushed off, leaving him with no other way to call attention to the vulnerability.  Others argued that he was trying to inform the wrong people, or that he simply should have refrained from exploiting the security hole himself.  In any event, the damage (if it can be called damage) was extremely minimal considering what could have been produced by a malicious attack.

As stated in GitHub’s blog post, the final verdict was “no malicious intent”, and Homakov ultimately had his account restored.  After reading through loads of comments, the general attitude of GitHubbers seems to be one of praise rather than condemnation, but it’s certainly an arguable issue in the way of ethics.

When, if ever, is it okay for hackers to act on a vulnerability in order to demonstrate flaws?

Read Full Post »

%d bloggers like this: