One of the truisms of container security is that when a container is run as privileged (in the sense of the Docker flag, not just running as the root user) it’s insecure and possible to break out. However, there aren’t always great examples of how to break out of a privileged container in practice.
I’ve been thinking about a project where I could travel to conferences with hardware to run a workshop that doesn’t rely on cloud resources (to avoid those concerns about network access or cloud uptime) and of course, the first part of any project like that is the fun part, buying the hardware! As I’d promised a review to a couple of people on-line, here it is.
As part of the preparations for the workshop on container security that myself and Iain Smart ran at this year’s Steelcon, there were some concerns that our standard option of SSH access might be blocked by the venue’s Wi-Fi, so a backup plan was in order. As a result, we were looking into how to provide a browser based terminal for students running on a host in AWS EC2.
At Last week’s Kubecon EU I was fortunate enough to be on stage with Ian Coldwater, Brad Geesaman, and Duffie Cooley presenting a talk called “Malicious Compliance: Reflections on Trusting Container Scanners”.
I’ve been meaning to write a post about Kubelet authorization for a while now, and as there have been some posts this week where it got a mention, now seems like a good time!
This week there were some articles about the Dero Cryptojacking operation and one of the details about what the attackers did caught my eye. It was mentioned that they were attacking clusters that allowed anonymous access to the Kubernetes API. Exactly how and why anonymous access is possible to Kubernetes is kind of an interesting topic that touches on a few different areas, so I thought I’d write a bit about it.
Last year I was taking a look at the OCI Image specification and I came across something kind of interesting, which is how you can get a container image to ping a URL when it’s pulled to a host almost like a tracking cookie. Needless to say this isn’t me dropping 0-day, I reported this to the containerd and podman security addresses back in October 2022 and the consensus appears to be that whilst this may have some security implications it’s not dreadfully serious in most cases and it’s part of the spec, so unlikely to change.
Recently I’ve been looking at SSRF in Kubernetes. When testing for SSRF, I find it very useful to have a webserver/reverse proxy that I control and can configure to do a number of tasks. I’ve been using Caddy for this. In this post I’ll show you how to use Caddy to test for SSRF.
I thought I’d start the new year with something a little fun that I’ve been looking at over the break (well for a certain definition of the word ‘fun’ :) ). Kubernetes has quite a rich API and in the various objects that you can create, some of them have URL or Service fields which, when used, cause the Kubernetes API server itself to make network requests (generally over HTTPS). Knowing this, it feels a bit like a Server-Side Request Forgery (SSRF) attack, so I wondered how possible it would be to implement something that can be used to scan for open ports on a target host from the Kubernetes API server.
Follwing on from the PCI Series I thought it’d be nice to do a bit more of an attack focused piece for a change!
