Introduction
In the course of our work Boltonshied experts often happen to test the same system again and again, although a longer period of time passes between the individual assessments sometimes. It is also rather common that the tested system itself significantly changes between two tests. In this case study we share a short description of our application vulnerability scan where unfortunately the new version of the application included a severe vulnerability.
Our client has developed several popular web services. They decided to bring the authorization of their applications to a common platform and that is why they opted for the use of the OAuth 2.0 open standard. Their applications have proven to be particularly safe so far, that is why they thought it would be enough to perform an application vulnerability scan of the new application version after it went live.
Our first impressions
OAuth 2.0 is an open standard which is actually an aggregate of recommendations. Therefore it does not contain strict regulations to the effect how its elements should be implemented. With regard to safety the OAuth standard has well-known critical points which are often implemented incorrectly by the developers. Such flaws can easily have the consequence that the users’ accounts can be cracked.
There are some popular and publicly accessible OAuth 2.0 implementations available, the use of which can ease developers’ life significantly. They can be used to prevent the evolution of several typical vulnerabilities. However, at the beginning of the test it quickly became evident to us that we deal with a unique implementation. Accordingly we attached great importance to the exploration of these well-known vulnerabilities.
What did the client’s implementation look like?
The model determined by OAuth 2.0 has two operators:
- Authorizator
- Clients (client applications)
The authorizator party manages the authorization requests coming from the clients. For this purpose it provides a login page for the users directed to it and it generates codes and tokens used for the authorization, then they are checked subsequently. Some well-known examples of the OAuth 2.0 authentication services are Google, Facebook, Microsoft, Linkedin. Through their use it is possible to log in to our application via the Google or Facebook account as well.
Clients are the applications which use a given authorizator. When the user wants to log in, the client application redirects him to the login page provided by the authorizator. After the successful login the user can consent to the entry to the client application on the page provided by the authorizator. Then the authorizator redirects the user to the page provided by the client in advance.
Our clients used a hybrid solution in their system. In the different client applications the users had separate valid accounts but they could connect them to a central account. This convenience function makes the single sign-on possible: you have to log in only once at the central authorization party.
In the client application the user initiates the connection of the account to the central account. After that the user will be redirected to the authorizator party where he can consent to the connection of the accounts on the page provided by the authorizator. In the next step the user will be redirected to the client application with an authorization code. In the background the client application sends this authorization code to the authorizator who checks it. If the authorization code is valid, the process is closed and the two accounts are connected.
What the developers did not take into account
In the course of the application vulnerability scan we revealed that the authorizator party redirects the user to the application with an authorization code provided in a GET request. However, the authorizator does not check if the user actually started the process himself.
It is a well-known vulnerability which is called Cross-site Request Forgery (CSRF). All the attacker has to do is to create an account both in the application and at the authorizator party and then initiate their connection. At the end of the process he has to capture the request which the authorizator party would use to redirect him to the client application. Then he is able to create a link easily using the request captured. If a logged in user visits this link, he consents to the connection of his account to the attacker account without knowing.
An example for a vulnerable link: https://xxxxxxxx.app.com/oauth/callback/code=457adXy84Ydasdf
By exploiting this error the attacker can log in to the user’s account even without providing the authorization data. This actually means that the user account is compromised.
Although this attack may seem complicated at first, if you think it about it more, it becomes clear how simple the execution is in reality. The attacker does not need to make the victim visit the link directly. He can embed the link to another page in order to dispel the victim’s doubt because it is enough to start a GET request. In the presence of Cross-site Scripting vulnerability the attack can be conducted even without the user noticing anything from it.
The afterlife of the test
Based on our experience the true severity of the Cross-site Scripting vulnerability is often underestimated. In many cases even the developers are not aware how easy it is to exploit such a vulnerability and how serious the consequences can be. Therefore after the application vulnerability scan we decided to present a short demonstration in addition to the instant reporting of the error. With the demonstration we managed to convince our client of the severity of the case revealed who decided to take the instant measures proposed by us.
By the exploitation of the vulnerability revealed the accounts of thousands of users became vulnerable, so the immediate intervention was justified. Fortunately the version management model applied by our client allowed them to return to an earlier version relatively quickly. Until the fixing of the error the users had to go only without the convenience of their central account.
Our experts worked in close cooperation with the developers in the course of the fixing of this security flaw; they provided support for the fast and adequate resolving of the identified vulnerabilities.
Our client thought that they would prevent the evolution of similar issues in the future. Therefore they asked us to hold an in-company training for their developers about the vulnerabilities of OAuth 2.0 and the safety directives to be complied with. It made us proud that they also asked our team to hold several other training courses. As a result of the application vulnerability scan, our client’s systems and the security awareness of their developer team improved significantly.
You can get in touch with us to find out exactly how Boltonshield can help your organisation.