Last updated at Wed, 13 Dec 2023 23:31:47 GMT
This blog was co-authored by Steve Laura.
While performing a recent penetration test focused on a customer’s web application security program, we started with the standard OWASP testing methodology, gathering some basic information, fingerprinting the application, identifying entry points, and mapping out the application through spidering.
Overall, after a day of reviewing the web application, it looked pretty solid. The client in this case did provide user credentials based on specific user roles, but we didn’t find any common web application vulnerabilities that really jumped out as overly critical in this case.
Though user accounts with different user roles were provided for the testing, the approach of profiling the application as a malicious actor without credentials is another area to review in tests such as this one. From this perspective, we once again went back to the information-gathering phase of the testing methodology, but decided to take a different approach to open source intelligence (OSINT) gathering.
We started to profile the employees of the company, specifically those who were identified on LinkedIn as being a developer for the organization. When we identified developers, we then began profiling each individual to see whether they had information posted online—specifically, code that we could review based on the application we were testing. We happened to discover the GitHub repo for a developer that directly referenced the web application. Then, when we looked further at the code posted in this GitHub repo, we were surprised to discover a username and password listed.
We quickly attempted to see whether the username and password would provide access to the web application, and shockingly, it did! After review, the account was found to be a shared account for the company’s quality assurance team. While reviewing the access the user had within the application itself, we found that each day, developers would hold a standup meeting to discuss the application, talk about any issues they might be facing, and in some cases, review the code together, record the meeting, and store it within the application under this account.
While starting to watch the videos we discovered, a couple in particular really stood out because during code reviews, credentials were also shown that appeared to be hardcoded in files. A password shown in the recording was reused across multiple accounts on the backend for the application.
Upon discovering that a specific password was consistently reused, we gathered all the email addresses of those who were listed as meeting attendees and tested each of their accounts to see whether they had that password in use as well. We found two developers who were listed as meeting attendees reused the same passwords for their accounts, with one account specifically having full administrative privileges for the application, including the ability to clear the local database.
When it comes to pen test war stories, OSINT often takes a backseat to the more glamorous parts of the test, like sweet memory exploits or post-exploitation pillaging. This time though, OSINT saved us where our other pen test skills could not. In the words of Abraham Lincoln, “Give me six hours to chop down a tree, and I will spend the first four sharpening the axe.”
Interested in learning more about how Rapid7 pen testers conduct their assessments? Check back next week for Part 5, which will cover how Steve saw one company’s physical security weakness turn into strength when conducting multiple pen tests, and check out our previously published posts below: