BreachForce’s July edition bought 2 talks.
Whitebox Warfare: Beyond Scanners, Beyond Bounties
by Kaustubh Rai
Container Security: A Build Your Own Adventure
by Sumir Broota
Whitebox Warfare
TL;DR
Green dashboards lie. “0 criticals” doesn’t mean safe.
Whitebox isn’t “run SAST.” It’s architectural X-ray + action.
Three high-leverage plays: Dependency Autopsy, Secrets Archaeology, Attack-Surface Mapping.
Three ≤1-day defenses: Entropy-as-Code, Dependency Surgery, Honeytrap Logging.
Key Concepts:
Are we safe if the SAST Scan doesn’t detect vulnerabilities?
Scanner says we are safe. So we are safe right?
Vulnerabilities missed by SAST Scanners costs to companies both reputably or financially
For example: A code snippet which decodes JWT Token is given below
public static String getUsername(String token){
try {
DecodedJWT jwt = JWT.decode(token);
return jwt.getClaim("username").asString();
}
catch (JWTDecodeException e){
return null;
}
}
In the above snippet, the method takes a JWT token, tries to decode it, and fetches the "username" field. If decoding fails, it returns null.
However, this code only decodes the token; it does not verify the signature or check expiry, and therefore should not be used for authentication by itself. Such code can escape the scrutiny of SAST scanners, as they are often not focused on the nuances of authentication.
The remediation is shown in the snippet below:
DecodedJWT jwt = JWT.decode(token);
DecodedJWT jwt = JWT.require(Algorithm.HMAC256(secret)).build().verify(token);
The first line just decodes the JWT without validation, while the second line verifies the token’s signature and integrity using the secret key.
The above snippet validates the cryptographic signature, rejects altered tokens, enforces the algorithm parameter, and prevents none algorithm attacks.
A Real World Example would be the below CVE:
The Whitebox Lie → Whitebox Advantage
| Myths |
| WhiteBox = SAST + Compliance ❌ |
| Slow Development ❌ |
Reality:
Whitebox is architectural X-ray. Done right, it deletes bug classes (auth mistakes, parser traps, transitive risk) and speeds teams up by preventing redesigns later.
Attack Surface in White Box Testing
As most new infrastructure relies on old technology buried deep within layers of libraries, a vulnerability in even one of those libraries can put the entire system at risk.
The attack surface extends beyond what is visible to the human eye or to SAST scans. Here are ways to dig deeper into those hidden layers:
Dependency Autopsy: The process of analyzing and investigating software dependencies to uncover vulnerabilities, risks, or failures after an incident. Even if direct dependencies appear safe, a vulnerable package buried several layers deep (a dependency of a dependency) can serve as a hidden attack vector.
Run deep trees (npm ls --depth 10, language equivalents).
Flag packages with old release cadences, open vulns, or abandoned repos.
Dependency Surgery: The process of identifying, isolating, and removing vulnerable or unnecessary software dependencies to eliminate potential attack paths. This involves cutting out risky dependencies from the software stack to neutralize threats.
Secrets Archaeology: The practice of systematically uncovering hardcoded credentials, API keys, tokens, and other sensitive information hidden within source code, repositories, or configuration files, often buried deep in version history or dependencies.
Defenses in White Box Testing
Core Techniques in White Box Testing
Field Manipulation
Case Sensitivity Bypass
Parser Differentials
Check how different back-end services interpret conflicting input.
Example with multi-service architecture:
Exploit the inconsistency to bypass authorization.
RFC 8259 allows duplicates; behavior is implementation-dependent. Many parsers keep the last value; some error; some keep all.
Format Confusion
Send a request in a format that the system partially understands but misinterprets.
Example: Force a JSON response, but send a request in XML shaped like JSON.
Goal: Trigger parsing inconsistencies or bypass validation layers.
Operationalizing White Box
Policy-as-code: Semgrep custom rules, CodeQL queries, IaC checks.
Pipelines: Pre-commit hooks → PR checks → required status → nightly sweeps.
Playbooks: Keep a repo of rules/queries and a “fix-once” mindset (when a bug appears, add a rule so it never returns).
Attack Chain in White Box Testing
Scan the code base with rules (both default and custom rules).
If a vulnerability is spotted, craft payloads for that vulnerability.
If a defense is present, bypass the defense in the code base.
Container Security
What do Containers do?
Isolation: Keeping Your Code Safe from Other Processes
Portability: Moving Applications Across Platforms
Allows Scalability: Handling Increased Demand
How Virtualization happens in Containers?
Are Docker & Kubernetes the only type of containers?
- No, there are many like podman, LXC, runc, containerd, BSD jail
What separates them from VMs?
The fact that they share the host machines kernel
Containers are pure software virtualisation which allows faster boot
Any hardware device is virtualised in VM’s & they give dummy values
How do docker containers create this separation?
- Docker daemon → containerd runtime → runc (low level runtime) → namespaces

What are namespaces and cgroups?
What are namespaces?
What are cgroups?
- They act like virtual "cages" for processes, enabling resource management and control by partitioning and restricting access to system resources such as CPU, memory, disk I/O, and network
What is the meaning of root in container?
Standard Container Breakout
Dirty Pipe Container Breakout
DirtyPipe vulnerability is a kernel level bug that allows a malicious user to write files to a read-only file system. When data is loaded in memory it is done so using pages.
Using the PIPE_BUF_FLAG_CAN_MERGE pipe flag to a user can force their mal data into memory & use the splice syscall to write it to target destination.
Securing Your Containers
Best Practices
Always use trusted images from verified sources
Ensure regular updates to maintain security
Conduct scanning for vulnerabilities consistently
Additional Measures
Implement strict access controls for users
Utilize network segmentation for isolation
Monitor container activity for anomalies