Hello Guys, today we are going to talk about an interesting vulnerability found in a private program. The vulnerability allowed an attacker to completely take over the victims account whenever the user would log in to his dashboard. This is discussed later on in the post after a brief explanation of OAuth and Open Redirects and what could an attacker get from victim’s if the attack is successful. Stay tuned till the end for a Bug Bounty Tip which can be found after every post
OAuth 2.0
OAuth 2.0 is an authorization framework for Web Application. It validates the identity of a user to the website which requested it without disclosing passwords to the website. This might sound complicated at first but let’s take an example: A user wants to login to a website. He heads to the signup page and finds three options to log in- Via Facebook, Via Google, Via LinkedIn. When the user clicks one of them, he authenticates himself to the website.
To read more about OAuth 2.0 click here.
Open Redirects
As per OWASP, Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.
Attacks
Dangerous URL Redirects:
The below code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:
http://example.com/example.php?url=http://malicious.example.com
The user sees the link directing to the original trusted site (example.com) and does not realize the redirection that could take place.
Safe URL Redirects:
When we want to redirect a user automatically to another page (without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:
PHP:
<?php
/* Redirect browser */
header(“Location: http://www.mysite.com/”);
?>
In the example above, the URL is being explicitly declared in the code and cannot be manipulated by an attacker.
Mitigation
Safe use of redirects and forwards can be done in a number of ways:
- Simply avoid using redirects and forwards.
- If used, do not allow the URL as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
- If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
- Force all redirects to first go through a page notifying the user that they are going off of your site, and have them click a link to confirm.
Case Study:
The following case study is based on a Web Application on a private program. As per the terms and conditions, the name of the website has to be hidden as there is no disclosure allowed. Therefore, we are assuming the name of the website to be example.com. The application had a huge scope with few websites and its API domains. Authentication in each website was Token Based with the Authentication token as the JSON web token (jwt). Each user was provided with roles ranged from Admin to Unprivileged. The application had a Sign-Up and a Login page where a User could register himself to the application and then could sign-up using the credentials after verifying his email.
While testing for session management issues with EditThisCookie Extension on the main dashboard of the page at example.com/dashboard, I noticed that whenever any user would log out of the Application, he would be redirected to the login page where he executes https://example.com/dashboard in the Address Bar, he would be taken to a link: https://example.com/login.html?postAuthenticationUrl=https://example.com/dashboard. This is where a victim could enter his credentials and then would be redirected to the link provided in the postAuthenticationUrl. After testing this parameter for any other URLs, there were no sufficient checks placed whether the domain to be redirected to is whitelisted. The Modified URL: https://example.com/login.html?postAuthenticationUrl=https://google.com when executed in the Address Bar with the Credentials of the user, would redirect the user to https://google.com.
Exploiting Further:
This was the case of open-redirect. Now let’s see how this could help take over a complete account.
Once the user was redirected to the account mentioned in the postAuthenticationUrl parameter, the URL in the observed in the above picture as:
https://www.google.com/?jwtToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI3NzNiM2YxNjEwYTU0ZGRjOWM3YzQ2YzFhNmIxMzQ5OUB3YWxrbWUuY29tIiwiZXhwIjoxNTQ1ODMwOTY1LjI0OCwiaXNJbXBlcnNvbmF0aW5nIjpmYWxz..
As I mentioned before, the JWT tokens are used as the Authentication token in the website and the APIs. The token value is now leaked to the attacker and he could use the token in the following ways:
- Privilege Escalation: The attacker could modify his roles form user to Admin. By just updating the role from user to admin in the POST request to the server at example.com/UpdateRoles, the user could escalate his privileges to admin.
- Extract Sensitive Information: The attacker could use this token to extract information of the user such as his Name, Email ID and various other details by sending a GET request to the server at api.example.com/me. With the tokens of every victim who fell for the trap, entire contact details of the victims were leaked.
As this was a sensitive issue, the program marked it as P2 which is a high-level priority. The bug is still under examination by the program and so the bounty is undecided.
#BugBountyTip – Did you know you can sometimes retrieve data from ‘deleted’ accounts, by signing up with the e-mail that was associated with it? Another good example of why e-mail verification matters.
Thanks to: Intigriti