Kubernetes Attack

Prerequisite

• Experience performing Kubernetes penetration testing or CTF participation
• Imagination

Challenge

You have been hired by online retailer Flotsam, Inc., to conduct a penetration test on a new Kubernetes cluster prior to it going public. Your point of contact has provided the cluster diagram and key details in the Target section below.

The Target

• The marketing department maintains a WordPress blog that includes a custom theme and a handful of plugins for SEO, metrics, etc. The WordPress container image is the official image from Docker Hub. A CI/CD pipeline monitors Docker Hub for new images and initiates a new build and release whenever a new image is published.
• The ecommerce team maintains an internally developed shopping site that is Flotsam’s primary source of revenue. The site is a handful of JavaEE applications that are in the process of being refactored as a cloud-native application. Previously, the applications were bundled into WARs and deployed to an HA pair of Tomcat clusters. As an initial stage of migrating to Kubernetes, the SREs have added the WARs to an OCI image based on the official Tomcat image from Docker Hub. The Java development teams are not familiar with Kubernetes, but they are otherwise very senior developers and previous penetration tests have not identified significant issues with their applications.
• The ecommerce databases store customer PII, including credit card numbers, and Flotsam’s primary concern is protecting customer data.

Requirements

• Consider how you would conduct the penetration test. Where would you start, what might you find?
• At each point, make a reasonable assumption about what you find and continue on in the scenario. What do you try even if you suspect it may not work? Given the scenario, what is a reasonable solution that would eventually give you a foot hold? Once you’ve established a foot hold, how do you pivot?
• If this feels a bit like playing a game of chess with yourself, then you’re on the right track. Choose your own adventure, but remember that the adventure you choose may limit your ability to demonstrate your knowledge, skills, and experience.

Deliverable

• A final penetration test report suitable for submission to the client that details your findings, provides supporting evidence, and offers recommendations.
• Placeholder descriptions of screenshots and/or tooling outputs are perfectly acceptable—there is no need to manufacture or stage images. However, placeholder descriptions should include the key information the screenshot/output is intended to convey.
• Actual penetration reports can be hundreds of pages long, but your submission should not be. Instead of writing out every detail, provide a complete table of contents and in less interesting sections, simply provide short two- or three-sentence descriptions of what the that section would include in a full report. For example, if you conduct a series of automated scans that produce results of limited interest (e.g., an XSS attack that could be used for vandalism but not penetration), describe the scan and the types of detail that the section would include.