How to Get Better Bugs from Your Pentest
During scoping for penetration tests, customers often say that they want us to perform the engagement exactly as a bad actor would, with no collaboration from the customer’s IT or security teams and no access to inside information. This is known as a black box penetration test, a methodology we often advise against.
On the surface, this feels counterintuitive. If attackers have zero insider knowledge, wouldn’t we want to simulate the exact same conditions during a penetration test? Yes, however there are two key components to take into account: time and money. A black hat hacker has an unlimited amount of time to devote to breaching an organization. That same organization, on the other hand, generally needs to have a penetration test performed in a 2-4 week time period, as a highly credentialed security consultant can get expensive very quickly. ivision’s white-box approach to penetration testing helps a security consultant get more coverage across your environment in a shorter period of time than a bad actor with unlimited time.
Specifically, source code access helps us identify instances of SQL injection, a vintage (but still very common) attack much faster, and across the whole codebase. Source code access also helps us find hidden or unpublished API endpoints with a much higher degree of certainty than blackbox testing. In a recent white box engagement, we discovered a hidden logging endpoint that allowed us to compromise the administrative account for the application (which otherwise followed good security practices)!
At ivision, our ultimate objective from every engagement is to help our customers improve their information security as dramatically as possible, and white box engagements help us achieve this goal. When it comes down to it, black box testing only tests your ability to defend against a known (and limited) attack model. As new software, hardware and other weaknesses present themselves, current defenses and monitoring may not be able to detect and defend against them. Defense in depth is critical in a rapidly changing environment, and white box testing digs below the initial defensive layer and helps our customers protect their business, even if the front-line defenses fail. White box testing not only helps us find more impactful issues faster, it also broadens what we can find that may not be an issue right now, but could turn into an issue as the application gets built out and security assumptions and trust boundaries change. If you want to use your penetration testing engagement to help your teams from an engineering perspective, ditch the black box requirement and share your source code and security architecture diagrams.
