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. This is demo-focused where much of the talk is one long demo showing an attack chain. The goal being I wanted something complicated and simple to exploit. I wanted things to not work initially and you had to figure out ways around them.

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.0.0.5 on port 80, it would look like this:

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. Basics of Container Hardening There are ways to harden your runtime like dropping capabilities when a container starts but when you have a goal of re-enforcing the isolation between the container and the host towards using a container more like a sandbox, the main option you have is syscall filtering/monitoring. That’s monitoring and blocking which syscalls are allowed to go from the container to the host.

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. For example, you may have noticed when running nmap --priviliged as a normal user, the output would look something like this:

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.antitree.com:443. Calculating Probability of Anonymity Tor’s original threat model simply said that in order to compromise an individual, you would have to compromise 2 of the 3 nodes in a given circuit. Specifically the Guard and Exit. And since the nodes are run by anyone, there’s a risk that some of them could be compromised. So not factoring in anything else (path selection, guards, latency), your probability of choosing a compromised circuit comes out to be:

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. In any case, RSA 1024 has been phased out for years and shouldn’t be used.