White Box Penetration Testing Explained

This blog post is a transcript of Christian Espinosa’s explanation of White Box Penetration Testing, which covers the following:

• Differences between Black, Gray, and White Box Penetration Tests
• White Box = Full knowledge about the target
• White Box is typically used during development or system integration
• Often includes Black and Gray Box
• Threats emulated:
  • Poor coding practices
  • Supply chain issues

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel ( https://www.cerberussentinel.com/)

Need a penetration test? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete White Box Penetration Testing Video Transcript

Hello. This is Christian Espinosa with Alpine Security. In this video, we’ll cover white box penetration tests. This completes our series, the three video series of the different colored boxes of penetration tests. We already did a video on both the black and gray box penetration tests. With a white box penetration test, we know the most about the target. Just a quick review. With a black box, we know very little about the target other than maybe the target’s IP address or URL. With a gray box, we know a little bit more than a black box. We often have user-level access to the target such as a user-level account on a web application, or maybe an active directory user-level account. With white box though, we know the most about the target. Sometimes with white box, we have root-level or administrator-level permissions.

We also often have access to data-flow diagrams, entity-relationship diagrams, maybe even the source code, maybe even access to the developers that are actually producing the software, or developing the software, or the product. Typically, with a white box penetration test, this is most often used during development of software or a product. It’s much more beneficial to have somebody from a penetration testing team working with your developers during the development process than waiting until your product is released and then hiring a penetration testing team to poke holes in it after it’s already been released. It costs a lot more money to fix it, and it’s much more difficult to fix after it’s been released. That’s why a white box is typically done as part of the development cycle for a product or software.

It could also be performed during system integration. Let’s say you’re a systems integrator, and you integrate different subsystems from different suppliers. You integrate all that into your overall system. You have to have some degree of trust that your suppliers are actually designing their components to your specifications, and that what you’re getting from them is secure. So before you integrate that, or as you’re integrating that into your overall system, you should do some white-box testing to make sure this component you get for instance, only has the inputs you specify, and the outputs you specify. There’s no extraneous data going through that component or originating from that component.

That would be an example of when we would do a white box penetration test for systems integration. Also, a white box penetration test typically includes a gray box and a black box because as we’re going through this process, and we’re looking at what’s being developed, we often do the test from both the aspect of unauthenticated and user-level access, which is gray. The threats we emulate for a white box, typically we’re trying to discover poor coding practices. A white box perpetration test, as I mentioned, is typically performed during software development. This is the prime time to discover a input validation problem or a balance checking problem. The perfect opportunity is during the development.

As I mentioned earlier, if we wait to hire the penetration testing team until after development’s done, and they find out we have a problem such as a input validation or a buffer overflow attack that our software allows to happen because of a vulnerability, that is much more costly to fix than if we could have identified it upfront. The other threat that the white box penetration test helps with is any issues in the supply chain. As I mentioned earlier, we often do white box penetration tests to a systems integrator, so if one of your suppliers in the supply chain has a vulnerability that is introduced somewhere along the supply chain, and that component makes it into your overall system, this is the perfect opportunity to test this before it’s released again, out to your customers.

If you have any questions about white box penetration testing, you can leave them as a comment beneath this video. If you’re interested in a white box penetration test, you can contact us at www.alpinesecurity.com. I hope you enjoyed this video, and I’ll talk to you later on. Cheers.

• 0

Shares

• Share to LinkedIn Share

• Post to X (Twitter) Post

• Share to Facebook Share

• Pin to Pinterest Pin

• Share to WhatsApp Share

• Share to More Options Share

Acting With Intention: What It Means and How to Make It a Habit

Reflection Is Part of the Messy and Uncomfortable Growth Process

No One Wants to Feel Alone in Times of Need

Trying to Do the Right Thing and Getting It All Wrong

Shedding Your Defense Modes

Getting Thoughtful About Intentions

Openness to Input and Feedback Drives Self-Correction

Micro-Moments Center on the Present

Shifting Your Identity to a Serving State

Informed Intentions Make You Less Vulnerable to Circumstances