SecPro #35: Hackers Find Way Into Kubernetes ☸️, How To Avoid Broken Authentication, How To Conduct Digital Forensic Triage
Here’s another edition of the SecPro and it’s got a bit of something for everyone. Not only has the SecPro team been chatting about the new Kubernetes vulnerability all week, but we have decided to launch a new set of tips to help newbies understand how security works in the real world with tricks on Avoiding Broken Authentication. And don’t forget to read about our advice on implementing the next installment in our OWASP Top 10 series! 💬 In today’s issue:
- 🔸 New Kubernetes ☸️ Exploit: Legacy Software Gives Attackers a Way In
- 🔸 How to Conduct Digital Forensic Triage in an Active Incident
- 🔸 OWASP Top 10: A07:2021 – Identification and Authentication Failures
- 🔸 The Beginner’s Corner: Threat Modeling for Beginners
- 🔸 Secret Knowledge: Building Your Security Arsenal
But there’s also news of a change, however – starting from next week, the SecPro newsletter will be getting a new Editor-in-Chief!🥂 But don’t worry, it’s not some stranger who doesn’t understand what Packt and the SecPro team is all about.
Austin Miller has been writing content for us over the past few months and advising you all on how to break your computers (and occasionally defend them as well and keep your organization safe…), so he knows what the SecPro community wants! He tells me that he knows exactly how to deliver the content that appeals to battle-hardened security professionals as well as the newbies who are taking their first steps in the cybersec world.
Don’t worry, you’ll still see my name every now and then. From next week onwards, Austin will be here to deliver the SecPro issues every Friday and quiz you all about what you want to see.
Cheers!
Kartikey from Packt
Exploit Detection & Analysis
New Kubernetes Exploit: Legacy Software Gives Attackers a Way In
By Austin Miller
For everyone that is running a Kubernetes cluster or two right now, you need to start vulnerability scanning to make sure you are covered for the latest exploit. Discovered by William Liu and James Hill-Daniel, a Kubernetes user could find themselves dealing with full cluster compromise if an attacker found their system unpatched.
But before we all quickly update our clusters, here’s what you need to know about the vulnerability and how we can fix it.
The Exploit Explained
If you have been following security issues for Linux systems, then you probably already understand this exploit – it reared its head as CVE-2022-0185 in mid-January.
Due to an integer underflow problem in the Linux/Kubernetes components related to File System Context, an adversary can launch a privilege escalation attack and gain access to the kernel with write privileges. This privileged access allows attackers to add themselves to any process that is running, potentially leading to sensitive data exposure and remote code execution.
What is an integer underflow problem?
The opposite of the much more common integer overflow (where the input “overflows” the restrictions set in a variable), an integer underflow is when not enough input is entered into the system. This isn’t hacking, really – it happens every day and rarely leads to a vulnerability or exploit. For example, take a program which can only count as low as -128:
#include <stdio.h>
int main(int argc, char* argv[]) {
char a,b;
a = -128;
printf(“%dn”, a);
b = a-1; //Underflow occurs
hereprintf(“%dn”,b); }
In this scenario, the -1 causes the system to count lower than it can. This would result in the system putting out a result such as 127 – a broken answer.
How does the Kubernetes exploit work?
The exploit begins with an attacker an integer underflow attacker against a Kubernetes cluster or node. Although this usually wouldn’t necessarily cause a severe issue in other contexts, this brings about a size check fail in Kubernetes. This is where the problem starts.
Through this size check fail, the adversary can now write to the kernel. In any given Linux distro, there is 4kb of memory that can be written to in normal circumstances. However, when the size check fails occurs, the adversary now has unlimited write permissions. This means that a skilled threat actor can access the kernel controls to technically anything. This means you have fully compromised Kubernetes clusters if you do not have the patch or another mitigation in place.
Doesn’t the Kubernetes API server stop this?
Although Kubernetes introduced the File Context API to address weaknesses in the File System Context component, File System Context still exists for legacy reasons. If a user relies on the API, the vulnerability cannot be exploited.
However, as with many legacy compatibility situations, the inclusion of the older code allows the attackers to circumvent the fixes and potentially launch widespread cluster compromise. By using the weaker File System Context, the adversary can target security vulnerabilities in the exploitation path of the node’s network namespace. If this happens, you could be looking at malicious activity in your Kubernetes nodes before long.
How do I defend my Kubernetes clusters?
As always, the best way to defend your software against the adversary is to update your systems and install all the relevant patches. But this isn’t a solution for everyone – if you can’t administer the patch to your version of Kubernetes, there are two workarounds that should defend your worker nodes.
Workaround #1
If you can’t apply the patch, the first workaround requires you to disable namespaces to unprivileged users or – if that doesn’t work – entirely. The following command can be used to disable namespaces to all unprivileged users.
sysctl -w kernel.unprivileged_userns_clone = 0
But you can also use the following command if you want to disable namespaces entirely if you are using a kernel that does not use containers.
# echo “user.max_user_namespaces=0” > /etc/sysctl.d/userns.conf# sysctl -p /etc/sysctl.d/userns.conf
The latter workaround is for Red Hat users and users who have systems built on the Linux kernel. After either of these commands have been used, you should have no issues with Kubernetes and integer underflow issues!
Workaround #2
Another workaround is to effectively copy Docker. Unlike Kubernetes, Docker has no issue with this vulnerability in the Linux kernel because it automatically blocks the exploitation path with a Secure Computing (seccomp) filter. Kubernetes clusters, on the other hand, do not automatically run with this protection. Before running containers in Kubernetes, set a seccomp filter to stop the adversary from exploiting the weakness.
Protecting your clusters
If you have been running clusters before the Linux or Kubernetes patch came out, you may need to protect your cluster data as well. To ensure that your containerized applications and data are safe, check that CAP_SYS_ADMIN is disabled on all non-essential workloads. This will stop the adversary from being able to exploit the privilege escalation vulnerability due to a lack of administrator rights for said cluster or cluster nodes. Armosec offered an example of how to run C-0046 on Kubescape to check your existing clusters.
Tutorial
How to Conduct Digital Forensic Triage in an Active Incident
While investigating an incident, it is essential to understand the significance of Digital Forensics and Incident Response (DFIR). Executing Digital Forensics Triage during an Incident Response is focused on speed. It is about how we get ahead of the threat actor and understand their Tactics, Techniques, and Procedures (TTPs) to gain utmost control over the incident.
Conducting digital forensic triage will enable us to answer their inquiries not only from a “controlling the narrative” perspective but also from a legal perspective. Especially if cybersecurity leaders can understand the technical details of DFIR then they can make better technology and business decisions.
Technical requirements to conduct digital forensic triage
Location, location, location – just like real estate, the same applies to incidents. Having the right place for your environment and ensuring its effectiveness is vital. For this, you will need a location in an environment with remote central access for multiple reasons.
Looking to read the complete tutorial? Click the button below to access the full tutorial on the SecPro website.
OWASP
OWASP Top 10: A07:2021 – Identification and Authentication Failures
By Austin Miller
Once known as Broken Authentication and rated as the second most serious threat to web application developers in 2017, Identification and Authentication Failures are now a lowly number 7 on the OWASP Top 10.
Identification and authentication failures have a weighted exploit score (i.e. CVSS) of 7.40 (number three on the list overall after A05: Security Misconfiguration and A10: Server Side Request Forgery), showing that common identification and authentication failure attack types – such as credential stuffing and over-sharing session IDs – are serious problems for IT teams if they aren’t carefully defended against. But what are the signs of identification and authentication failures and how do we guard against them?
What are identification and authentication failures?
Identification and authentication failures include anything that allows the attacker to gain access to a system by abusing tools used to confirm a user’s identity or authenticate their sessions. Some of the most notable attack types within this entry in the OWASP Top 10 include:
- Brute force attacks
- Credential stuffing
- Session hijacking
- Poor token deletion on exiting the session
Anything that requires identity theft or session manipulation, basically. Despite the broadness of this category, there are a few handy fixes for most attacks that fall within these descriptors. For security teams to fight against these attacks, however, we must learn to recognize these problems first.
What are the signs of broken authentication and identification failures?
OWASP offers a few telltale signs that show authentication and identification failures in your software:
- A weakness to credential stuffing or weakness to brute force attacks
- Poor password strength metrics
- Stores passwords in plain text, in poorly encrypted plain text, or with weak hashes (to find out more about these cryptographic failures, check out SecPro #30 or head over to the OWASP page)
- Limited or missing multi-factor authentication
- Poor session token management practices, such as exposing the session ID in the banner or failure to invalidate after a period of inactivity
If these signs are true about your app, the odds are that it has weaknesses that line up with identification and authentication issues. Being weak in this area can lead to disastrous data breaches and identity theft, so learning how to avoid broken authentication is key to securing your app and your users.
Avoiding Broken Authentication
Because identification and authentication failures cover everything from weak passwords to authentication-related attacks such as rainbow tables, offering a fix-all solution is practically impossible.
Multi-factor authentication (MFA)
MFA has been growing in popularity in recent years and there are a few ways to provide additional layers of authentication to your organization’s logins. Good MFA authentication will require at least two of:
- Something I have: security tokens, identification cards, or temporary third-party authentication application codes
- Something I know: passwords
- Something I am: fingerprints, eye scans, and any other biometrics
Avoiding Broken Authentication: Read NIST 800-63b
Now read it again. Specifically, section 5.11. If you haven’t already read this document all the way through before starting a career in cybersecurity, you have some catching up to do.
The document lays out in full the best approach to creating and maintaining secure passwords and password protocols. This includes the absolute minimum security that would be expected of your mandatory password strength, rules for allowing UNICODE characters, how to implement non-password-based logins, and how to use MFA. If you read the document and find you are still confused, maybe take a look at this XKCD comic to find out what we consider secure passwords might be anything but for a talented threat actor.
Better session management in Avoiding Broken Authentication
Although using common passwords and man in the middle attacks are, there is an interesting example attack scenario included on the OWASP Top 10 Identification and Authentication Failures page:
Application session timeouts aren’t set correctly. A user uses a public computer to access an application. Instead of selecting “logout,” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.
In this story, we are reminded that the adversary doesn’t need to be talented – they just need to be lucky. However, these are exactly the types of attacks that security teams should be focusing on!
The Beginner’s Corner: Threat Modeling for Beginners
The world of cybersecurity is difficult to navigate and confusing for beginners, so understanding the basics and giving practical advice about how to implement them is a high priority for SecPro. This week, we’re going to explore how threat modeling helps new security analysts support the development process.
To help new cybersecurity professionals make their way in the world, the SecPro team will be launching the Beginner’s Corner as a fortnightly feature. Keep your eyes open to catch some important tips.
Understanding your Role
Not everyone who is threat modeling is a security professional. In fact, you should expect software developers to have similar concerns about threat agents throughout the Software Development Life Cycle (SDLC). Because of that, you need to understand the differences between a developer’s threat model and your version as a security professional. Here’s how a software developer will look at security requirements throughout the SDLC:
A threat model included in the SDLC
Whereas your threat modeling process should look a little more like this:
As a trained expert, you should be able to identify vulnerabilities in the software architecture and nip a potential threat in the bud. To do this effectively, you must understand how application data is handled and the potential impact of an attack on the system. Get started with this complete guide using the button below.
Take me to the Beginner’s Corner!
Secret Knowledge: Building Your Security Arsenal
Discover useful security resources, cheatsheets, hacks, and open-source CLI/web tools.
New & Trending 🔄
🔸lanrat/certgraph : An open-source intelligence tool to crawl the graph of certificate Alternate Names.
🔸paazmaya/shuji – Tool for reverse engineering JavaScript and CSS sources from sourcemaps.
🔸 ovotech/gitoops: GitOops helps you identify lateral movement and privilege escalation paths in GitHub organizations by abusing CI/CD pipelines and GitHub access controls.
Container Security 📦
🔸 cybersecsi/RAUDI: A repo to automatically generate and keep updated a series of Docker images through GitHub Actions, by SecSI.
🔸 kata-containers: Kata Containers is an open-source project and community working to build a standard implementation of lightweight Virtual Machines (VMs).
