Webhooks are a big part of @kubernetesio. I've recently been going down the webhook rabbithole, especially for offensive use-cases. And here's what I think. A 🧵 1/
@kubernetesio#kubernetes uses an access control object called an Admission Controller. This is beyond AuthN and AuthZ. This allows you to create objects that will allow you the operator to define workloads and configs that are admitted in your cluster. appsecengineer.com/courses-collec…
2/
@kubernetesio This is largely done using Admission Control webhooks. There are two types of webhooks you can use in #k8s, they are:
- validating
- mutating
Watch my 1m video here if you want to learn the differences
3/
@kubernetesio Webhooks, as you. can imagine, are a critical part of kubernetes. They can be configured to act on every single request that is hitting the kube-apiserver. They have the ability to validate/mutate workload parameters deeply. This naturally, can be abused for 👿 things. 4/
@kubernetesio Webhooks are great for post-exploit scenarios in kubernetes. How? All I would need to do is deploy a mutating admission controller that could:
- change my pod to be deployed with root privileges
- expose my service publicly
- tamper with my pod to do $x (DNS spoofing)
5/
@kubernetesio - run my code as part of your pod 🤯
- load my container as a sidecar to your pod. Now I have persistence
- pretty much do anything I want by tampering with your podspec on the fly because my webhook does that for me
6/
@kubernetesio Not only can I do nasty things with mutating webhooks. You can do naughty things with validating webhooks (that only validate config).
- ship off the request (may be a kube secret) to a third party URL
- DoS attacks by denying possibly genuine workloads from being launched
7/
@kubernetesio Why?
- Lots of Admin/Operators dont bother examining RBAC privs on CRDS and webhooks. Just a little different from the curl | sh effect
- Admin/operators dont bother inspecting helm charts for RBAC issues and malicious code
but most of all... 8/
@kubernetesio Webhooks ARE used for Policy management and enforcement. So its like a bad actor in law-enforcement. "Who watches the watchers" and all that...
In conclusion: If you're an offensive security/redteam person. You should leverage the webhooks in your kubernetes exploit toolkit
9/
@kubernetesio I am running a outright offensive training on "Attacking the Application Supply Chain" at @BlackHatEvents#BHUSA. If you're interested in pwning all types of supply-chains incl kubernetes with webhooks. You should secure your seat! blackhat.com/us-22/training…
Key Cloudwatch and Cloutrail concepts you should know for security monitoring on @AWS. A 🧵1/
@AWS Let's start with Cloudwatch. Lot of us assume that Cloudwatch is just a log management engine, i.e a time-series DB for logs from various AWS Services and your workloads on AWS. Its so much more than that. It has all of these capabilities 2/
@AWS However, the features I typically end up using the most are:
- Metrics and Alarms: You can use/configure measures for various events across several AWS services, log them and setup alarms when they hit a threshold. Example - memory consumption, 400 errors on API Gateway, etc. 3/
Container Registry Security controls you didn't know you needed. A 🧵 1/
Let's start with the basics. You need to scan your containers for vulns on the push. For that you need your registry to integrate with security scanners. Most registries support this out of the box. Some like @project_harbor even integrate with multiple scanners. Always 👍 2/
@project_harbor you need tag immutability. What if an attacker gets creds for your registry and commits container images with the tag "prod" that you use (well, for prod). you are in a world of 💩. Setting an immutable tag ensures that others can't commit to that specific "locked" tag 3/
#SSRF is a super popular vulnerability that is leveraged extensively, by bad actors. Let's look at SSRF defense in this 🧵 1/
Let's start with the basics. SSRF happens because your app makes requests to other URLs based on user-generated data. If your app doesnt need to redirect/request random URLs (functionality), ensure that you have a tight allowlist. Only redirect to URLs in the allowlist 2/
But if your app needs to redirect to a larger (purely user-defined) set of URLs, then things may get a little more complex. Now you need to validate inputs like a mf'er. Parse and Break down URLs by scheme, domain, etc. Validate each one as required 3/
The way I see it, both the identity and policy aspects of ZeroTrust require/can do with a solid "shift left" approach of being able to incorporate identity and policy checks in the build/deployment flows. 3/
Realized that there's a huge gap in knowledge for some taxonomy and terms in #infosec. Here's a 🧵
Let's start with CWE from @CweCapec. Common Weakness Enumeration.
* This is 🚫 a scoring system
* This is identifier for a type of vuln
For example: SQL Injection is CWE 89
It has broad "parent" and more specific "child" categories. But EOD, they are Vulnerability IDs 2/
@CweCapec Let's look the one its most confused with. CVE (@CVEnew). This is a number that is assigned to a specific vulnerability identified against software/hardware that is publicly available (commerical/OSS). Ex: CVE-2022-0847 is a CVE given to the Linux #DirtyPipe vul. 3/
ICYMI, this is how the #log4j#Log4Shell flaw works (in simple english), a 🧵 1. Victim is running a Java Web that uses the log4j logging lib 2. The victim web app has code that logs http request payloads/headers with log statements (example User-Agent)
1/
3. Attacker identifies vulnerable app and makes a request to the server with the User-Agent Value set to this. What does this mean? 2/
jndi == Java Naming and Directory Interface. Allows Java apps to access multiple apis for LDAP, Remote Method Invocation (RMI), etc through the JNDI Interface 4. The attacker tries to get the log4j library to lookup an LDAP server through JNDI 3/