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.
A handy technique for any pentester is the ability to create a reverse shell. This allows for a variety of cases where you want to get access to restricted environments or want to extract information from a remote system.
I’ve been looking for a way to explain an demonstrate the “no-new-privileges” option in Docker for a little while for my training course and recently came up with a way that should work, so thought it was worth a blog post.
Coming up for 4 years ago (a lifetime in Container land) Ian Miell wrote about “The most pointless Docker Command Ever”. This was a docker command that you could run and it would return you back as root on your host.
One of the common tasks in a containerized environment, where you could be running multiple applications in containers on a single host, is “what’s the best way to route traffic to my web applications”?
