Vulnerability Assessment is one of those foundational IT Security tasks that often gets overlooked or thought to be reasonably straightforward, where you can actually find some interesting complications that make it trickier than expected.
This is a neat trick which could be useful when troubleshooting Kubernetes services or testing Kubernetes clusters. This got used in a TGIK episode a while back and I’ve been meaning to test it and write it up for a while, as I’ve not seen many docs on it.
I’ve been starting to have a look at podman recently and in doing so, I noticed something potentially interesting from a security perspective, which is how podman handles the pulling of new container images. As podman is billed as a “drop-in” replacement for Docker (and indeed provides a package to alias docker commands to their podman equivalents), it’s interesting to note how default settings might differ, as these differences could trip up unsuspecting users moving from Docker to podman.
Being able to practice exploits and attacks is always useful for security testers, whether it’s working out whether a tool is working properly, or fine-tuning the syntax for a command in a predictable environment, it’s a very handy technique. One factor that can slow this down is having to rely on external resources, like Virtual Machines or cloud based resources, for running our tests. Ideally we should be able to run everything locally on a single machine.
I recently got my beta invite to the awesome Github Actions feature. This is a free to use CI/CD system. If you’re not familiar with CI/CD, you can think of it as a system which runs a series of actions during your development process to help test/maintain/deploy it. For example you could use CI to run your test suite on every commit, so you know if someone just broke the build.
Following on from the last post in this series lets setup a rather more ambitious set of reverse shells when attacking a Kubernetes cluster.
