This website was created a bit more than a month ago at the time of writing this. As for any respectable website, choosing a cool domain name is important. I wanted to choose among some cool new TLD names approved by ICANN recently. I like martial arts and I loved the fact that .ninja domains exist but those I wanted were taken already, so I ended up for choosing pentest.guru . Many hosting providers also offer the registration of a domain name but from my experience I realized that it’s better to separate the subscription of the hosting and the domain name in case you decide to change hosting provider (it isn’t compulsory to do so, but I prefer having more flexibility) so I ended up choosing a registrar called hover.com for my domain name. I read many positives reviews and I personally recommend it, but when I used it, I discovered a vulnerability (now fixed) I’m gonna talk about today. As usual, finding a vulnerability is a matter of skills, luck, interest (and the vulnerability obviously needs to exist). Let’s say that I discovered this vulnerability by chance (I didn’t want to pentest hover.com). This is what happened. I successfully registered to hover.com, then a few days later I tried to login to my account for registering the domain name that I have finally chosen but I couldn’t login. It was rather strange. Then I tried to reset my password in case I forgot it, but I didn’t get any email with a link for resetting the password even if a message in the web page said an email was sent. The possibilities were 2: there was a problem about sending or receiving the email or hover.com was lying (later I discovered it was the second one :D). I didn’t receive any email because my account was suspended (my residence address didn’t match the address associated to my credit card because I recently moved to a new place). After talking to the support team my account was unlocked and the reset password function finally worked. The webpage still displayed the message “Email sent”. This time it was true 🙂 . I still felt there was something strange anyway and I decided to fire up Burp proxy and repeat the whole process.
How the enumeration of the usernames is possible:
An attacker can request the password reset by inserting a username that is known to exist (for example one created specifically for the test) and analyze the request and response by using a HTTP proxy. Then the attacker can perform the same operation by using a username that probably doesn’t exist and look for any discrepancy in the the two responses (between the negative and the positive test). Often the website that is vulnerable to username enumeration provide descriptive errors or messages like “error” or “the username doesn’t exist” or “an email with the link for resetting the password of your account was sent to your email”. In this case the hover.com website is apparently behaving in a secure way by not disclosing useful information for the attacker that can be used to enumerate the usernames. The only message displayed by hover.com after a username is submitted is “Email sent”. I tried first with my real account and thus this message appears to be true.Now it’s time to test what happens when an attacker submits a username that is unlikely to exist. One would expect that the website provides no message or a different message, instead it displays the same message “Email sent”.
This is obviously not true, no email was sent to the non existent username, but from my understanding it is by design and considered by the developers as a “security feature”. If the same message is displayed in both cases, an attacker can’t figure out whether a username exists or not, apparently. But looking carefully at the HTTP responses I could discover an interesting thing. The HTTP responses contain a JSON message that tells whether the function for checking the existence of the username returned true or false.
POST HTTP request with username [my username]
POST HTTP response that displays [my username] username exists.
At this point it is possible to craft a dictionary or brute force attack by sending multiple POST requests to the web server with the username to test and grepping the text of the JSON message in the HTTP responses.
It is possible to store all the HTTP requests and responses in a database and sort the results by the JSON message in order to have an ordered list of valid usernames displayed in a nice format.
Whoever has access to the account is able to gather info about the owner of the domain (including address and phone number), change the Auto Renew, Transfer Lock and Whois Privacy settings, change the Nameservers and the DNS settings, retrieve the Authorization Code (EPP Code) necessary for transferring the domain to another domain registrar and manage the mail forwarding or the mail boxes.
The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities. Its quantitative model ensures repeatable accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the scores. Thus, CVSS is well suited as a standard measurement system for industries, organizations, and governments that need accurate and consistent vulnerability impact scores. Two common uses of CVSS are prioritization of vulnerability remediation activities and in calculating the severity of vulnerabilities discovered on one’s systems. The National Vulnerability Database (NVD) provides CVSS scores for almost all known vulnerabilities. In particular, NVD supports the Common Vulnerability Scoring System (CVSS) version 2 standard for all CVE vulnerabilities. NVD provides CVSS ‘base scores’ which represent the innate characteristics of each vulnerability. We do not currently provide ‘temporal scores’ (scores that change over time due to events external to the vulnerability). However, NVD does provide a CVSS score calculator to allow you to add temporal data and to even calculate environmental scores (scores customized to reflect the impact of the vulnerability on your organization). This calculator contains support for U.S. government agencies to customize vulnerability impact scores based on FIPS 199 System ratings.
CVSS Base Score: 5
CVSS Temporal Score 4.8 CVSS Environmental Score: 6.4 Overall CVSS Score: 6.4
An attacker can exploit the password reset function for performing username enumeration. Once the attacker retrieves a username he is able to perform a dictionary or brute force attack of the password and if successful this can lead to account takeover.
The web application should provide only a generic message that doesn’t give any clue about the existence of the username, for example: “If the username inserted is correct you’ll receive an email with a link for resetting your password”.
Besides looking at the source code it’s possible to see that an Ajax call in JQuery is responsible for the POST request. Maybe the developers used it during the testing phase of the website, anyway in production it is a bad practice. They should avoid to display the JSON message and they perform the existence check of the username at server side.
Account Enumeration and Guessable User Account (OWASP-AT-002) (https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004)
CWE-203: Information Exposure Through Discrepancy
Author: Fabio Baroni Date: 2015-11-24 21:47:02