Take-aways Container registries are simple services ripe for subtle abuse They are trusted endpoints making them useful for exfil and post-exploitation It’s easy to make a malicious file appear like a legitimate image layer I’m beating up container environments in the context of supply chain threats over the last few months. If you’re working in the container or Kubernetes security area, you’re constantly running into the reality that many of the exploits that you know about, are not going to be the next major cyber event on the front page of news sites.

UPDATE 11/28/2020: Thanks to @jaybeale and @sethsec for pointing out I was calling it “OPA Gateway” instead of OPA Gatekeeper. UPDATE 3/20/2021: Tim Allclair and Jordan Liggitt have a proposal with a demo that shares what PSPs may look like in the future. 3-Tier Pod Security Proposal. It’s talking about turning the ideas of PSP’s into an admission controller that implements the “Pod Security Standards” mentioned above. UPDATE: 4/8/2021 …And now they are.

I’m writing about the Kubernetes API’s use of the “LIST” verb it controls access to Secrets in a cluster. I’ve seen way too may environments, tools, templates, and examples that are hoping that LIST verbs can provide a meaningful security control compared to the GET verb. I’m going through a simple demo below and a few one-liners that can help you audit this yourself. Background Kubernetes Roles are designed to give fine grained access to various API actions within the cluster by defining “Verbs” that you’re allowed to send to the API.

TL;DR The Linux Kernel keyring is known to be a security issue for containers Download my tool for breaking out of a container to steal all the host keys here: keyctl-unmask We can use this in Kubernetes to steal all node keys as well Have you ever wanted to steal all the secrets from a Linux host from within a container? Sure we all have. Lets do it at scale and share a tool that speeds this up during security assessments.

Saturday, I gave my talk titled “Command and KubeCTL: Real-World Kubernetes Security for Pentesters” at Shmoocon 2020. I’m following up with this post that goes into more details than I could cover in 50 minutes. Here’s the important stuff: Link to Slides Link to Demos @ me on Twitter Premise This talk was designed to be a Kubernetes security talk for people doing offensive security or looking at Kubernetes security from the perspective of an attacker.

It’s been on my list for at least 6 months to start contributing to krew if possible. My first plugin is called net-forward and it’s very simple but confusing if you don’t see what I’m using it for. Kubectl net-forward From a user level, net-forward helps you create a forwarding proxy from your machine to an arbitrary IP and port that’s accessible in the cluster. For example if you wanted to connect to another Pod’s service located at 10.

Sometimes during a container or Kubernetes assessment, we get requested to review whether a runtime security tool that a client uses is sufficient for their threat model. This often means reviewing a custom seccomp-bpf profile, AppArmor config, or third party tool that tries to enforce the isolation between a container and the host. There’s two approaches we usually take during these gigs: Audit the profile and identify any flaws or bypasses that could exist Analyze the container at runtime to validate the policy actually enforces the expected ruleset.

By default Docker allows all of their containers to run with the CAP_NET_RAW capability, I believe to easily support ICMP health checks when needed. Supporting ping makes sense but this post will go through why CAP_NET_RAW is an unnecessary risk and how you can still send pings without needing CAP_NET_RAW. What does CAP_NET_RAW do? CAP_NET_RAW controls a processes ability to build any types of packets that you want. TCP, UDP, ARP, ICMP, etc.

After 8 years of Security B-Sides Rochester, it’s time for me to turn it over to new leadership that wants to keep the conference going. It’s exciting that people still want to. My role as of recent has been the person that invested the most time doing the running around to organize the conference but that’s not to say I “run” the conference – it truly is run by volunteers and one of my jobs was to try and maintain some consistency while letting people do what they want.

The folks at Rochester 2600 were regaled by a talk from Payap Sirinam who is on Matthew Wright’s academic team at RIT. They’re working on an interesting system that aims to defend against website fingerprinting attacks – a major threat to anonymity systems like tor. As in, if you’re using tor, passive adversaries in position to watch traffic between the tor client and a guard, can determine the website you’re visiting… with frightening accuracy.

One of my favorite things about the Tor Project is their proposal system. Every idea that’s worth thinking about goes into a proposal template that talks about the idea, the technical background, why it’s proposed, as well as any risks or design issues that need to be factored in. They read like RFC’s and that will either make you kind of excited or kind of sleepy. But in any case, they are a look into the future of tor as well as some hints about current issues that need to be addressed.

I noticed this bug ticket from Tor Project last week: Make exit flag depend on ports 80 and 443, not 6667 and it reminded me about a short talk I gave regarding how the port you connect to a service on, directly affects the anonymity you’re able to achieve. In short, visiting services on non-standard ports such as https://www.antitree.com:64201 increases the risk of you choosing a compromised circuit compared to visiting https://www.

Tor Project has just released version 0.3.2.1-Alpha of tor that supports the long-awaited, next-generation onion services that aim to repair many its known flaws. Here’s what I understand are the big changes and features compared to the old version. Key Size Current Onion services right now are based on RSA 1024 bit keys which, for long-term keys, aren’t an ideal size. While RSA 1024 hasn’t been publicly cracked, predicts say it should be possible this year.

This is a follow up from the Custom Seccomp profile post which went through some of the background information. Speed up custom seccomp profile generation with Syscall2seccomp You can always manually track down the syscalls that your application makes, and build a custom seccomp profile for your Docker container, but I’ve created the tool syscall2seccomp that helps speed the profile building process up. It takes the output from sysdig or strace and converts it to a usable Docker profile.

This post goes through building custom Docker seccomp profiles for your container. I’m not recommending you do this especially in enterprise environments, but I’m being charitable to the idea that system call filtering is the basis of a lot of sandboxing technologies and filtering out unnecessary ones should reduce the attack footprint of your application. This is more of an exploration of use-cases for custom Docker seccomp profiles than a suggestion that everyone does this themselves.