PenTest: Cloud Penetration Testing Compendium

Description

Dear PenTest Readers,

Due to fantastic feedback to our recent publications related to the topic of cloud security, we decided to prepare a special edition of PenTest Mag. “Cloud Penetration Testing Compendium” is a compilation of the best articles about cloud’s offensive security prepared for all of you, who believe that sky is not the limit, but just the beginning :)

All articles of the issue relate to different aspects of pentesting and securing the cloud. You will learn valuable techniques and methodologies, and read tutorials on helpful tools and frameworks. The contents contain case studies on using Azure, FuzzyUnicorn, PACU, ScoutSuite, and Prowler, to name a few. Naturally, a substantial amount of the write-ups relate to AWS platform security.

There are also 3 articles on Kubernetes penetration testing, as this open-source container-orchestration system is very useful for cloud environments and is getting more and more popular in the industry. Thus, securing k8s is definitely a skill in demand on the job market. 

No matter if you are a cloud security expert already, or if you’re just starting to become one, this compendium will undoubtedly enrich your perspective in the field. 

Let’s soar to the heights of pentesting the cloud as we dive into the reading!

 

Without further ado,  

Enjoy the content!

PenTest Magazine’s Editorial Team.

---

Table of Contents

---

A New Methodology for Cloud Environments Penetration Testing

by Alcyon Junior

Cloud Computing Penetration Testing is a method of actively checking and examining the Cloud system by simulating the attack from the client side. The methodology already presented is a tool to be used when talking about Cloud Computing, on-premise or even hybrid environments, provided they are performed on the client access side. With this article, I intend to present a methodology for pentest in Cloud Computing environments in a simpler and structured way.

---

Cloud Security Posture Management - Reducing the Attack Surface and Detecting Threats in the Cloud

by Yuri Diogenes

A bad habit that was created over the years when vulnerability management systems were scanning servers on-premises, and the results were sometimes ignored, is getting carried on to cloud environments. The lack of security hygiene in cloud workloads is real, is dangerous and should be immediately addressed. According to a study conducted by Online Trust Alliance, 93% of reported incidents could have been avoided with basic security hygiene best practices. Read this part again: “basic security hygiene”!! The question is, why wait to get owned before doing something?

---

Pentesting the Cloud

by Staford Titus

Pentesting has made bounds in line with the technical prowess. Clouds (no pun intended) abound in the networked skies and hence are susceptible to attacks just like any other server or network. Securing them has emerged as a priority since clouds contain large amounts of data that, if compromised, could prove disastrous, especially for companies that store all business data on them. Well, cloud pentesting is not the easiest, since a testing lab of sorts would be needed at the least, which, of course, could cost a lot based on the latest cloud pricings. Even if, overcoming all those shortcomings, you do get your hands on something of sorts, you would still need vulnerable instances and the knowledge to exploit them to practice.

---

Fuzzing in the Amazon Cloud - A Worthy Alternative to Classical Fuzzing

by Wilfried Kirsch and Prof. Dr. Hartmut Pohl

Fuzzing is a method to identify software bugs and vulnerabilities in executables. The actual development shows a trend to move fuzzing into the cloud (cloud fuzzing), that allows a dramatic fuzzing speed increase up to factor 100 compared to classic fuzzing running on a typical personal computer. This paper shows benefits and drawbacks of cloud fuzzing for companies. With the softScheck Amazon cloud fuzzing Framework, a feasible software solution for fuzzing in the Amazon Cloud is presented and its architecture sketched.

---

PACU: The AWS Exploitation Framework Equivalent to METASPLOIT

by Jhansi Jonnakuti

This article talks about AWS platform. Before even jumping into pentesting and hacking, it is important to go through the AWS services and AWS Lambda, a serverless computing platform that lets you run your code, to ensure that we understand the scope of pentesting AWS, the goal of pentesting and more. We need to know how to secure a cloud in a day as an administrator and it is an issue, even though it had built-in tolerance and monitoring services. If attackers target a cloud service, it is easy to exploit, just like any other traditional web hosting services, by attacking and creating backdoors. To avoid bad guys, here comes “PACU”, an open source exploitation framework to challenge attackers by providing offensive security testing against the cloud. This was created by Rhino Security Labs, and it allows pentesters to exploit configuration flaws and much more in your AWS account. Patch management has built-in tolerance and error handling that helps maintain security for our organization but providing layers of security is always a good principle to be followed by security professionals. Let’s go ahead!

---

Native AWS Security vs FuzzyUnicorn

by Daniel "DJ" Sherman 

The team does some research and finds that there are two ways to nullify AWS STS access. Note that disabling the active keys and the IAM user does not nullify the STS access. The first way to stop the bleeding is by deleting the devOPs1 user. This will work, however, this account may be needed for some business function that is disrupting production. The devOPs1 user is re-enabled with no password to console access and granted new keys to allow the business to continue to function. Security has to keep in mind that disabling all the things will not always be an option. This is a business decision that leadership needs to make.

---

Scaling AWS Security: a Review of Open Source Tools

by Ben de Haan

By now, everyone knows that S3 misconfigurations can lead to problems. However, authenticated compromise is the threat with the most devastating outcome nowadays. Accidentally checking in your access keys to public version control, password reuse, server-side request forgery, local file reads, remote code execution, and internal threats are more likely to test your blast containment than a missing encryption setting on RDS. The downside of offensive tooling is that they only execute known attacks, and cloud environments may change rapidly. Thus, it is extra important that they are extensible and modular to make them future proof.

---

10 Pitfalls When Working With K8S

by Jeroen Willemsen and Eric Nieuwenhuijsen

When looking at accessing the workload, you should remember that at its core, the Kubernetes nodes just run Docker containers but Kubernetes just calls them pods. One interesting attack vector to expand your foothold is via the actual containers themselves. When a container proves vulnerable by, for example, allowing SSH, kubectl exec or the applications allows you to do an RCE you have a great starting point. If you’re able to get inside a container, check if you can create new files and/or run/install kubectl: if not, then the container storage volumes are probably read-only, which will prevent a lot of manipulation of the containers. 

---

Kubernetes Master And Node Attacks

by Maxime Coquerel

The objective of this article is to present an introduction of Kubernetes penetration testing. The first goal of a Kubernetes penetration test is to increase the security of the Kubernetes resources and of your company. Security of Kubernetes Cluster is a large subject and pentesting of Kubernetes Cluster also. With a good comprehension of Kubernetes Architecture, everything is possible.

---

Beginning With Kubernetes Hacking

by Samrat Das

The HTTPS service on 10250/TCP is the default management API interface for Kubernetes clusters. It is not secured by default. This means that the developer/administrator is responsible for securing their services. As an attack vector by abusing the API we can achieve low level command execution. 2379/TCP Etcd Port: The HTTP service on 2379/TCP is the default etcd service for your Kubernetes instance. The API interface is accessible and not secured by default.