By Daniel
While performing a Penetration Test for a web application, an important part is testing the Authentication process.
Even if usually it is a standard authentication process or it issues a well-known authentication framework made for security purposes, we still can find vulnerabilities in the implementation of it. For example, applications may rely on client side data without any checking with the back-end of the application, tokens may be predictable or, for applications that use PIN codes for authentication, they can be simply brute-forced). In this blog post, we are going to focus on a brute-force aspect of a PIN code authentication process.
Environment Details
The application is a live paying system, where users can log in using their phone numbers as username and PIN codes which they receive via SMS as password.
Issue
You would think that an application that uses PIN codes sent via SMS has to be more secure than a regular authentication process (with username & password). It should be, but only if implemented correctly!
In our case, we found out that the SMS sent to user contains a 5-digit number which will grant access to user account. This number is randomly generated at back-end level and it is not predictable.
Method used
We have intercepted the Login request, using Burp Interceptor, where the 5-digit number is required and we have created a payload which randomly generates 5 digit numbers from 00000 to 99999. Using a brute-force technique, in less than 5 minutes we attacked the application with all the 100.000 possible digits combination in order to have 100% coverage.
What we found using this technique
- We found out that the application doesn’t have implemented any protection against a brute-force attack. The application didn’t blocked us for trying 100.000 times to log in, within 5 minutes.
- Finally, when the correct PIN code was sent to server(Request #50k from 100k), the server returned a 302 (Redirect) status code to the client-side. This is when we knew that the PIN code inserted was a success.
We managed to bypass the authentication login page in less than 5 minutes, even if in theory, this level of architecture within the application had a great start (using SMSes as a factor of authentication).