SecPro#04: Container Security, AWS Pentesting
Ready to dive into great content? From how to pentest Lambda services to K8s Container Security monitoring, and our coverage of the week’s most prevalent malware, there’s a lot of stuff waiting for you!
As always, I’d love to hear your thoughts and feedback on this issue.
If you found this newsletter useful, and know other people who would too, I’d really appreciate if you’d forward it to them. Thanks for reading!
In today’s issue:
This Week in Security
- ‘Epsilon Red’ Malware Targets Exchange Servers: New Sophos research uncovers REvil threat actors may be behind a set of PowerShell scripts developed to exploit vulnerabilities in corporate networks.
- 10 Vulnerabilities Identified in CODESYS ICS Automation Software: Some of these vulnerabilities are of high and critical severity. Their exploitation can lead to remote command execution on PLC.
- Several Vulnerabilities in Accusoft ImageGear: Cisco Talos researchers discovered multiple vulnerabilities in Accusoft ImageGear. The ImageGear library is a document-imaging developer toolkit that allows users to create, edit, annotate and convert various images.
The Malware Radar
A curated list of the most prevalent malware from the past week (c. Talos Security Intelligence)
Typical Filename: ww31.exe
Detection Name: W32.GenericKD:Attribute.24ch.1201
Typical Filename: FlashHelperService.exe
Detection Name: W32.Auto:3bc24c6181.in03.Talos
Typical Filename: SAService.exe
Detection Name: PUA.Win.Dropper.Segurazo::95.sbx.tg
Kubernetes: Container Security Monitoring
Securing K8s environments as you scale up is challenging. Each new container increases your application’s attack surface or the number of potential entry points for unauthorized access.
Kubernetes audit logs provide a complete record of activity (e.g., the who, where, when, and how) in your Kubernetes control plane. Monitoring your audit logs can be super useful in helping detect and mitigate misconfigurations or abuse of Kubernetes resources before sensitive data is compromised.
Frederick Fernando of Falco talks about the basics of Kubernetes security monitoring and how Falco uses rules to achieve the detection of security issues. The default detection ruleset of Falco is enough to get yourself up and running, but you will most likely need to build on top of the default ruleset.
- Cloudplex: Top 10 K8s security tools
- DataDog Blog: Kubernetes audit logs for monitoring cluster security
3-Part Blog Series: Analyzing Security Posture of Open Source Helm Charts
Matt Johnson of BridgeCrew shares his findings of running 103 security checks against 2,312 Helm charts across 618 repos.
In a nutshell:
- Part 1 covers the importance of addressing security at the Helm chart level and reviews high-level findings.
- Part 2 provides guidance for how to improve your Kubernetes security posture.
- Part 3 analyzes one of the most commonly used Helm chart dependencies and its security posture.
More IaC resources..
How to Assess and Pentest a Lambda Service
TL;DR: How vulnerabilities with Lambda and misconfigurations can present serious challenges for organizations that fail to isolate such issues and how to avoid them.
During pentesting engagements in AWS, one of the major issues often seen as a pentester is policy issues associated with Lambda. In cloud security, policies allow and restrict access to resources and the same concept could be used to look at misconfigurations in Lambda.
A misconfiguration – for Lambda policy – occurs when a certain attribute is set in a “loose” manner. These policies are what allow unauthorized individuals to view information that was not intended for their viewing, or worse, allow malicious vectors to view and exfiltrate that data. Finding misconfigurations in weak policies is one of the more important aspects of pentesting AWS services such as Lambda and S3. Least privilege is another potential issue in target AWS environments.
So, how do we discover loose policies in Lambda? Before we proceed let’s assume we created an S3 bucket and set some “loose” permissions when creating the Lambda function. Let’s take a look at how easily and quickly that can escalate. Simple querying of the Lambda function will list its attributes. For example:
The layout of the policy is straightforward. However, if you take a closer look, you’ll notice:
Allowaction for invoking the function is allowed. While this is good, we typically don’t want to let anyone do this. Allowing anyone to invoke can create big issues later down the line because if someone were to compromise the internal AWS network, they could essentially continue to run the Lambda function.
- We also see the
pentestawslambdaS3 bucket in the policy. This exposes the full URL of the S3 bucket. An attacker could use this information to discover more about the S3 bucket or to discover even more buckets that could be in that environment.
Now that we learned a little more about loose permissions in Lambda and what to look out for, let’s take a different approach. Here, we’ll show how to use a vulnerable Lambda function to initiate a reverse connection. We will need to use the following as prerequisites:
- Kali Linux on an EC2 instance with a public DNS name
- A Lambda function
(Make sure that you are using an EC2 instance with a public DNS. The Lambda function will need to connect to that public DNS.)
Being able to get a reverse shell means that you were able to successfully exploit a target and get persistence on that machine (persistence being a terminal connection on that machine). However, it is more than just a connection; it also highlights issues within the tested environment.
A client may want you to test the monitoring and detection of their security. Creating a vulnerable Lambda function that makes calls inside and outside the network is a great way to test companies’ monitoring practices and solutions. With a shell, you can also test monitoring, firewall rules, and general security posture.
Laying Out Your Ethical Hacking Game Plan
Following are the steps to consider when performing an attack path:
- Start up an EC2 instance with a public DNS
- Create a vulnerable Lambda function that will call back to the public DNS
- Start a listener on the EC2 instance
- Test and run the vulnerable Lambda function
- Get a shell
Let’s start up our EC2 instance and log in to the Lambda dashboard. Proceed using the following steps:
- Log in to the AWS console and create a new function for a reverse shell. Name it
LambdaShelland ensure that Python 2.7 is selected.
- Set up our function to create a reverse connection to the EC2 instance. You can pull the code from the repo here. The code here is essentially setting up a function called
lambda_handlerthat will execute a connection from the Lambda function to the attacker machine.
- Next, make sure that the function does not time out too quickly. In order to establish persistence, set the timeout to about
5minutes or longer. The maximum time allowed for Lambda functions is
- Next, you’ll need to SSH into your Kali machine and set up a netcat listener on the port you assigned in your payload. Use the
su -command to switch over to the root account.
- Use the following command to set up the netcat listener to listen for incoming connections from our target Lambda service:
- Now configure the test event before executing the function. Click the Test button in the top-right corner. You’ll be prompted with a window that displays Configure test event – go ahead and click Create to move forward by clicking Test again:
- Finally, move back to the terminal on the Kali machine. You’ll be greeted with a reverse connection on the Lambda instance! Feel free to run some Linux commands in your shell.
You now have consistent access to the Lambda environment! Let’s say you were testing a Lambda environment for weak policies. A policy should not be able to allow pentesters to execute calls outside the Lambda environment as we did – remember, we went to a public DNS, which means we went outside the VPC.
[Disclaimer: This story was created using Packt’s AWS Penetration Testing title by Jonathan Helmus. Keep in mind you should not perform pentesting or any type of intrusive actions on systems which you do not own or have legal permission to do so.]
Shifting Security to the Left
TL;DR: Aim to do more security upfront in the SDLC and take a pragmatic approach to get assurance in a frictionless, automated way.
Lukas Kauffman shares a great overview of DevSecOps and some lessons learned through the years of running successful DevSecOps programs.
DevSecOps is a journey, not a destination
Security is a niche area and the reality is that it’s sometimes hard for development teams to understand some of the concepts. Some of Lucas’ key findings include:
- Invest in security champions
- Ensure you enable developers, find a flexible approach with pragmatic risk management
- Strike a balance between risk and ensuring development isn’t impeded
- Start small, create success stories, and subsequently scale-out
- Palo Alto Networks Blog: 4 practical steps for ‘shift left’ security
- GitLab Blog: DevSecOps basics and 9 tips for shifting left
Extra read: A new survey by Dark Reading finds 78% of IT and security professionals think security is important enough to delay application deployment.
Resources and Tools
Cloud Security Resources
A command-line tool to help with AWS security assessment, auditing, hardening, and incident response. It supports the CIS AWS Foundations Benchmark (49 checks) and has over 100 additional checks including GDPR, HIPAA, PCI-DSS, ISO-27001, FFIEC, SOC2, and others.
Amazon Web Services (AWS) CLI Tool Cheatsheet
A useful collection of pentest cheatsheets and tools for organizations that leverage AWS.
Microsoft Azure & O365 CLI Tool Cheatsheet
Another useful collection of pentest cheatsheets and tools for organizations that leverage Azure.
Designed by security auditors, Scout Suite is an open source, multi-cloud security auditing tool. It enables security posture assessment of cloud environments.
A CLI tool that generates
tfstate files based on existing infrastructure (reverse Terraform).
Ethical Hacking Resources
Tune in to:
- Cisco Talos Takes: Incident response is really just the friends we made along the way
- Naked Security by Sophos: Several Security Stories from the Week
- Malwarebytes: Alleviating Ransomware’s Legal Headaches
- Masters of Data: The Culture Change Observability Caused in Modern Tech
- Recorded Future: Unpacking the Emotet Takedown
The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.