July Meetup Highlights

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:

  • Gitlab 2022 JWT Flaw - CVSS 9.9

    • https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released

The Whitebox Lie → Whitebox Advantage

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.

    • Hunt with git log -S 'AKIA' (AWS) or org-specific patterns.

    • Automate in CI to alert + revoke.

Defenses in White Box Testing

• Entropy-as-Code → Ensure randomness/security features are programmatically enforced.

• Honeytrap Logging → Plant deceptive traces that alert you if someone is probing the system. eg: canary tokens

Core Techniques in White Box Testing

• Field Manipulation

  • Start by manipulating request parameters to attempt unauthorised actions.

  • Example: Modify JSON fields or inject extra parameters to bypass normal logic.

• Case Sensitivity Bypass

  • Test if changing the case of field names affects validation.

  • Example: AdminAction vs adminAction vs ADMINACTION.

• Parser Differentials

  • Check how different back-end services interpret conflicting input.

  • Example with multi-service architecture:

    • Go → Uses the last value of a repeated field (adminAction).

    • Python → Uses the first value (userAction).

  • 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?

  • Namespace is a linux kernel feature that allows creating isolated views on the
    following types of resources (currently there are 8 types)

    • time

    • user

    • pid

    • mnt

    • net

    • ipc

    • uts

    • cgroups

  • Lets understand some of them:

    • time - Allows different namespaces to have separate boot and monotonic clocks, enabling time virtualization within containers

    • user - Isolates user and group IDs. A process can have root privileges in its user namespace but not in others

    • pid - Gives each namespace its own set of process IDs. Processes in one PID namespace can only see other processes in the same namespace

    • mnt - Oldest ns in linux allows different views of file hierarchy similar to chroot jails (but more secure)

    • net - Provides each namespace with its own network stack, including interfaces, IP addresses, routing tables, and firewall rules

    • ipc - Security oriented namespace - prevents unauth processes from accessing/destroying the inter process comm (ipc) via segregation

    • uts - Allows each namespace to have unique host and domain names (hostname isolation)

• 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?

• A container can have an internal root process but won’t be privileged without setting the --privileged flag

• For a Non Privileged Container

  • The processes in the container maps to normal user processes on the host machine, hence don’t have the privilege to perform many attacks

  • The root user within the container will be unable to mount host files into the container/load kernel modules

  • It is still recommended to run as non-root if your application doesn’t have a usecase for it. This reduces the risk of any kernel vulnerability from being abused & the container from being further compromised

Standard Container Breakout

• To understand the type of permissions once has, one can try

  • Installing packages into the container (possible if container root)

  • Check if the host file system is mounted to the containers, with privileged one should have write access to it

  • Running capsh --print to get all the container capabilties on the host machine listed

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