Stories from the Pentesting Trenches
Several years back, our security engineers worked with a client to perform a penetration test of their web application. From the beginning, we knew something was different with this one. Our point of contact seemed very eager to see what we could find. Almost too eager. He didn't provide any details other than the URL, though. No credentials. No software specifications.
Upon navigating to the site, we started to understand why he was not forthcoming. The application had the most unique login page we had ever seen. It was a 5x5 grid of images. No input fields. No instructions. We clicked on one image. Nothing happened. We clicked on a second image. Still nothing.
At this point, we reviewed the HTML source code of the site and analyzed the mechanics of the front end. Going back to the grid, then, we clicked on three different images. Immediately, we saw the message, "Invalid Login", at the top of the screen. Progress!
On to the network traffic. The images were translated to simple numbers before being submitted to the server. So, a login request would simply be the numbers associated with the images, such as "4 9 15" or "8 2 19". No repeating numbers. No username or other identifier.
For the math nerds out there, that is 25 options, choosing 3, where order matters, but no repeating numbers. In other words, 25 x 24 x 23, or 13,800 possibilities. After submitting a few random guesses to ensure we didn't get locked out, we wrote a short script to enumerate every combination. After one hour, our script had discovered 7 valid "credentials" to user accounts. After four hours, it had found them all, including application administrators.
We reviewed the results with our point of contact. As it turned out, he had protested the redesigned login page, but the developers had thought it was a brilliant way to make the login process easier. Each user just had to remember three images to click on. Simple. Easy. Totally vulnerable.
The Takeaway: Securing an application is a complex endeavor, without adding custom functionality that replaces tried and true security mechanics, such as a username and password. Brilliant researchers are working hard on alternatives, but until new ideas are thoroughly vetted, it is usually better to not reinvent the wheel. Make it easy - follow best practices.
Security News
Nearly a fifth of Facebook's entire user base, around 533 million users, had their profiles posted for download on a publicly accessible criminal forum. Facebook confirmed the leak but clarified that the data is from 2019 at the latest. Moreover, the vulnerability that allowed the data breach has been patched. The data published included profile names, email addresses, location information, gender details, job data, and anything else users might have entered in their profiles.
Speaking of social media, phishing attacks are getting more specialized by scraping data from users' LinkedIn profiles to personalize their attacks. This variation includes the target's title from their profile in the name of the attached malware.
Stanford student data was leaked after a Stanford Medicine file transfer service was compromised. Affected data included Social Security numbers, addresses, emails, family members, and financial information.
More data from universities has been published online, allegedly originating from the University of Maryland and the University of California. This attack has been attributed to the Clop ransomware group that, earlier in March 2021, also targeted the University of Miami and the University of Colorado.
In an ironic twist, the online store for stolen personal and payment records, Swarmshop, had their user and administrator data leaked online. The affected data included credit card details, online banking account credentials, and social security numbers.
A data breach has hit the courts, as a lawsuit has been filed against Roper St. Francis for a breach of patient data in October, 2020. No public word yet on how much money in damages the plaintiffs are seeking.
Comments