Web Application Penetration Tests are some of the more involved tests that we regularly perform at Blue Goat. These tests always place us in a new and unique environment that puts our reconnaissance skills to the test. Part of the skill of being a good penetration tester comes down to the tester’s ability to properly evaluate the actual risk that comes from a vulnerability. This can be greatly skewed from the conventional risk rating for similar vulnerabilities based on the unique environment we are in.
Chaining Vulnerabilities
One way that major vulnerabilities can get overlooked is if there is a chain of multiple exploits needed to get the maximum effect. While any one part of it would be its own vulnerability, it may not be severe enough to get easily found. A good example of this would be an internal application with a SQL injection vulnerability on the same network as an external application with a Server-Side Request Forgery (SSRF) vulnerability.
In this hypothetical scenario, hackers would not be able to directly attack the external server. Similarly, the vulnerable internal server is unreachable from their position. This is where chaining the two vulnerabilities together would provide maximum severity, even if the severity is greatly lessened on its own. Attacking the internal SQL injection vulnerability would be a massive win for the attackers.
Case Study
Blue Goat was tasked with testing an external web application on this engagement. This was a Gray Box test where we had an unauthenticated, user, and admin role on the application. Testing revealed this to be a secure application with a mature security team. This often means that we will have to look more carefully to uncover vulnerabilities that may have been overlooked.
One immediate problem that presented itself was the user ID generation scheme. IDs were generated incrementally, meaning that the application had an IDOR vulnerability. It is very important to look at the impact of a vulnerability like this. A good example could be a banking site. If you visit a page such as /account?id=20, and visiting /account?id=21 gives you access to another account page, this is a big deal.
In this instance, resources were restricted from other users. Trying to manipulate the user ID parameter did not allow us access to other users’ data. This is still not a best practice to have in place since attackers can quickly iterate through IDs even just to validate the existence of an account. User IDs should be a unique value that is ideally randomly generated and unrelated to other user’s IDs.
During further testing, our testers identified a password reset functionality. These areas can have major vulnerabilities attached to them. This specific one relies on recovery questions for the user to be able to set a new password. Recovery questions are a dangerous feature on an application due to how easy it can be to find that information online. Sending temporary recovery passwords to the user’s email can be a better way to ensure security
While watching requests and responses go through our web proxy, we noticed that a request was being made to an API endpoint to request the user’s security information. The team at Blue Goat noticed that it was possible to directly make a request to that endpoint as an authenticated user to find the security questions of any other user on the application. Knowing this information could allow an attacker to scrape that information, and then simply rely on some social media reconnaissance to try and find the answers to the recovery questions.
This vulnerability, combined with the IDOR vulnerability mentioned earlier, means that an attacker would be able to write a small script to pull the security questions for every user on the platform and begin targeted attacks.
Remediation
Broken access control is the #1 vulnerability on the OWASP Top 10 list. It is extremely prevalent in modern applications, as it can be very easy to miss. Great care needs to be taken to ensure that users are properly restricted from accessing sensitive information. Giving users the least privilege possible while still allowing them to do everything they need on the application is a best practice in preventing broken access control vulnerabilities. In this example, it would have also been far harder to pull all of this information if a randomized ID generation system had been in place.
Test Your Web Application Security With Blue Goat Cyber
Web Application Penetration Tests can be a complicated process. Our team is highly trained and certified to perform these tests and can work with you to ensure that your web presence is fully hardened against attack. Contact us to learn more.
