Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/04/04/cloud-pentesting-pt-3-the-impact-of-ecosystem-maturity/

Now that we’ve covered the basics of cloud pentesting and the style in which a cloud environment could be attacked, let’s turn our attention to the entirety of this ecosystem. This environment isn’t too different from the on-premise ecosystem that traditional penetration testing is performed on. Who doesn’t want to gain internal access to the client’s environment from an external perspective? Recently, one consultant obtained firewall access due to default credentials never being changed, and the management interface was being publicly exposed. Or how about gaining a shell on a web server because of misconfigurations?  

Typically, a client who has a bit more maturity beyond just a vulnerability management program will shift gears to doing multiple pentests against their environments, which are external, internal, web app, mobile app, wireless, and potentially more. By doing these types of pentests, clients can better understand which aspects of their ecosystem are failing and which are doing fine. This is no different than when their infrastructure is deployed in the cloud.

Cloud implementation maturity

There’s an old saying that one must learn how to crawl before walking and how to walk before running. That same adage runs true for pentesting. Pentesting a network before ever having some sort of vulnerability management program can certainly show the weaknesses within the network, but it may not show the true depth of the issue.

The same holds true with Red Teams. You wouldn’t want to immediately jump on the Red Team pentesting bandwagon without having gone through multiple iterations of pentesting to true up gaps within the environment. Cloud pentesting should be treated in the same manner.  

The maturity of a company’s cloud implementation will help determine the depth in which a cloud pentest can occur, if it can occur at all! To peel this orange back a bit, let’s say a company wants a cloud ecosystem pentest. Discovery calls to scope the project will certainly help uncover how a customer implements their cloud environment, but what if it’s a basic approach? As in, there is no use of cloud-native deployments, all user accounts have root access, tagging of assets within the environment is not implemented, and so on. Where does this leave a pentest?  

In this particular case, an ecosystem pentest is not feasible at this juncture. The more basic approaches, such as vulnerability management or scanning of built-in cloud vendor-specific checks, would most certainly be ideal. Again, crawl before you walk, and walk before you run.This would look more like a traditional pentest, where an external and an internal test are performed.

What if the client is very mature in their implementation of cloud? Now we’re talking! User accounts are not root, IAM roles are leveraged instead of users, departments have separate permission profiles, the environment utilizes cloud native deployments as much as possible, and there’s separation of department environments by means of accounts, access control lists (ACLs), or virtual private clouds (VPCs). This now becomes the cloud ecosystem pentest that will show gaps within the environment — with the understanding that the customer has implemented, to the best of their abilities, controls that are baked into the cloud platform.

Maturity example

I’ve had the absolute pleasure of chatting with a ton of potential customers that are interested in performing a cloud ecosystem pentest. This not only helps to understand how the customer needs their pentest to be structured, but it also helps me to understand how we can improve our offering at Rapid7. There’s one particular case that stood out to me, which helped me understand that some customers are simply not ready to move into a cloud-native deployment.  

In discussing Rapid7’s approach to cloud ecosystem pentesting, we typically ask what types of services the customer uses with their respective cloud vendor. In this discussion with this particular customer, we discovered they were using Kubernetes (K8s) quite extensively. After we asked a few more questions, it turned out that the customer wasn’t using K8s from a cloud-native perspective — rather, they had installed Kubernetes on their own virtual machines and were administering it from there. The reason behind this was that they just weren’t ready yet to fully transition to a cloud vendor running other parts of their infrastructure.  

Now, this is a bit of a head-scratcher, because in this type of scenario, they’re taking on more of the support than is necessary. Who am I to argue, though?  The customer and I had a very fruitful conversation, which actually led us both to a deeper understanding of not only their business approach but also their IT infrastructure strategy.

So, in this particular instance, if we were to pentest K8s that this customer deployed onto their virtual machines, how far could we go? Well, since they own the entire stack — from the operating system, to the software, to the actual containers — we can go as far as we can go. If, however, this had been deployed from a cloud-native perspective, we would have restrictions due to the cloud vendor’s terms of services.

One major restriction is container escapes, which are out of scope. This goes back to the shared environment that has made cloud so successful. If Rapid7 were capable of performing a container escape, not only would this have been severely out of scope, but Rapid7 would most certainly be reporting the exploit to the cloud vendor themselves. These are the dreams of a white hat hacker, who signed up to perform a bug bounty and get paid out potentially tens of thousands of dollars!

But while that isn’t exactly how all cloud pentests turn out, they can still be done just as effectively as traditional on-premise pentests. It just requires a clear understanding of how the customer has deployed their cloud ecosystem, how mature their implementation is, and what is in and out of scope for a pentest based on those factors.

Additional reading:

• Cloud Pentesting, Pt. 2: Testing Across Different Deployments
• CVE-2022-1026: Kyocera Net View Address Book Exposure
• Analyzing the Attack Landscape: Rapid7’s 2021 Vulnerability Intelligence Report
• Cloud Pentesting, Pt. 1: Breaking Down the Basics

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/03/29/cloud-pentesting-pt-2-testing-across-different-deployments/

In part one of this series, we broke down the various types of cloud deployments. So, pentesting in the cloud is just like on-prem, right? (Who asks these loaded questions!?)  

The answer is yes and no. It depends on how a customer has set up their cloud deployment. Let’s cover a few basics first, because this will really clear things up.

Each cloud vendor has their own unique restrictions on what can and cannot be attacked, due to the nature of how the cloud is architected. Most have very similar restrictions — however, these rules must be followed, or one could quickly find themselves outside of scope. The next sections will outline which parts of the “as-a-service” components are out of scope for testing, and which are in scope.

Infrastructure as a service

This, in my experience, is how most clients have come to set up their cloud deployment. This as-a-service model could have simply been the quickest way to appease a C-level person, asking their Directors and Managers to go all-in with cloud. This is that direct lift from on-premise to the cloud that we discussed in the last post.  

When it comes to testing this type of deployment, the scope is the largest it could be, with very few exceptions to what is out of scope. Getting dropped directly into a virtual private cloud (VPC) is likely the scenario that will work as an “assumed breach” approach. The client would then deploy a virtual machine, which will then be allowed specific access inbound from a tester’s IP address, along with gaining that access via an SSH keypair.  

Some exceptions to this testing that are OUT of scope include:

• Auto-scaling functions and network address translation (NAT) gateways
• Exploiting the software that was used to deploy compute instances, or changing NAT

Some items that are IN scope for this deployment model include:

• Attacking the operating system and attempting exploitation against outdated versions
• Exploiting the software or applications installed on the operating system

Platform as a service

You’ve heard of bring your own device (BYOD) — think of this as BYOS, or bring your own software. Platform as a service (PaaS) brings us up a level in terms of support requirements. With this approach, clients can utilize a cloud provider’s products that allow a client to bring their own code for things like web applications. A client no longer has to work on keeping their operating system up to date. The code is typically deployed on something like a container, which could cost the client much less than that of having to deploy a virtual machine, licensing for an operating system, vulnerability management of the operating system, and staffing considerations. There are again exceptions, however, to what can and can’t be tested.  

In this example, the following would be considered OUT of scope:

• The host itself and/or containers hosting the application
• Attempting to escape containers where the application is hosted

The items which are IN scope for this deployment model include:

• Attempting to exploit the application that is installed on the operating system itself

Software as a service

At last, the greatest reduction in liability: software as a service (SaaS). Microsoft’s Office 365 is perhaps the most common example of a very widely used SaaS deployment. Click a few buttons in a cloud provider’s dashboard, input some user credentials, upload some data, and you’re done! Easy like Sunday morning!  

Now, the only thing to worry about is the data within the application and the users themselves.  Everything else — including virtual machine deployment, operating system installation and upkeep, patch management of the operation system and the software installed on it, and the code base, to name a few  — is completely removed from worry. Imagine how much overhead you can now dedicate to other parts of the business. Windows Admins, web app developers, infosec staff, and even IT staff now have less to worry about. However, if you’re looking to have a pentest in this kind of environment, just know that there is not a whole lot that can actually be done.  

Application exploits, for example, are OUT of scope. The items that are IN scope for this deployment model are the following:

• Leveraging privileges and attempting to acquire data
• Adding user accounts or elevating privileges

That’s it! The only thing that can be attacked is the users themselves, via password attacks, or the data that is held within the application — but that’s only if authentication is bypassed.

Those above examples are not made up from Rapid7’s perspective either.  These are industry-wide standards that cloud providers have created. These types of deployments are specifically designed to help reduce liability and to increase not only the capabilities of an organization but also its speed. These are known as a “shared platform” model.

As-a-service example

Recently, we had a discussion with a client who needed a pentest performed on their web application. Their web app was deployed from a third-party cloud provider, which ended up using Google Cloud Platform on their back end. After a consultant discovered that this client had deployed their web application via the SaaS model, I explained that, due to the SaaS deployment, application exploitation was out of scope, and the only attempts that could be made would be password attacks and to go after the data.

Now, obviously, education needs to happen all around, but again, the cloud isn’t new. After about an hour of discussing how their deployment looked, the client then asked a very interesting question: “How can I get to the point where we make the application available to fully attempt exploitation against it?” I was befuddled, and quite simply, the answer was, “Why would you want to do that?” You see, by using SaaS, you remove liability from worrying about this sort of issue, which the organization may not have the capacity or budget to address. SaaS is click-and-go, and the software provider is now at risk of not providing a secured platform for content delivery.  

After I had explained this to the client, they quickly understood that SaaS is the way to go, and transforming into a PaaS deployment model would have actually required that they now hire additional headcount, including a web app developer.

It is this maturity that needs to happen throughout the industry to continue to maintain security within not just small companies, but large enterprises, too.

Digging deeper

Externally

There’ve been numerous breaches of customer data, and there’s typically a common culprit: a misconfigured S3 bucket, or discovered credentials to a cloud vendor’s platform dashboard.  These all seem like very easy things to remedy, but performing an external pentest where the targets are the assets hosted by a cloud vendor will certainly show if there are misconfigurations or accidental access being provided. This can be treated like any normal external pentest, but with the sole focus on knowing these assets live within a cloud environment.

Internally

There are multiple considerations when discussing what is “internal” to a cloud environment. Here, we’ll dig into the differences between platform and infrastructure.

Platform vs. infrastructure

In order to move or create assets within a cloud environment, one must first set up an account with the cloud vendor of choice. A username and password are created, then a user logs into the web application dashboard of the cloud vendor, and finally, assets are created and deployed to provide the functionality that is needed. The platform that the user is logged into is one aspect of an “internal” pentest against a cloud environment.  

Platform pentest example

There I was, doing a thick client pentest against an executable. I installed the application on my Windows VM, started up a few more apps to hook into the running processes, and off to the races I went.

One of the more basic steps in the process is to check the installation files. Within the directory, I find an .INI file. I opened this file with a text editor, and I was greeted with an Amazon AWS Access Key ID and SecretAccessKey! Wow, did I get lucky. I fired up aws cli, punched in the access key ID and SecretAccessKey, along with the target IP address, and bam! I was in like Flynn.

Now, kudos go out to the client that didn’t provide this user with root access. However, I was still able to gain a ton of access with additional information. I stopped from there though, because this quickly turned into a cloud-style pentest. I called the client up right away and informed them of this information, and they were happy (not happy) that this was discovered.

Internal platform pentest

A platform pentest is like being given a domain account, in an assumed-breached scenario, on an internal pentest. It’s a “hey, if you can’t get creds, here’s a low-priv account to see what you can do with it” approach.

On a cloud platform pentest, we’re being given this account to attempt additional attacks, such as privilege escalation, launching of additional virtual machines, or using a function to inject code into containers that auto-deploy and dial back to a listening server each time. A virtual machine, preferably Kali Linux, will need to be deployed within the VPC, so you can perform your internal pentest from it.

Internal infrastructure pentest

This pentest is much easier to construct. It looks very similar to an internal, on-premise pentest. The client sets up a virtual machine inside of the VPC they want tested, then the consultant creates that public/private SSH keypair and provides the SSH public key to the client. The client allows specific source IPs to SSH into that VM, and the pentest begins.  

In my experience, a lot of clients only have one VPC, so that makes life a bit easier. However, as more and more people gain experience and knowledge with how to set up their cloud environments, VPC separation is becoming more prevalent. As an example, perhaps a customer utilizes functions to auto-deploy new “sites” each time one of their customers signs on to use their services. This function automatically creates a brand-new VPC, with separation from other VPCs (which are their other clients), virtual machines, databases, network connectivity, access into the VPC for their clients administration, user accounts, authentication, SSO, and more. In this scenario, we’d ask the client to create multiple VPCs and drop us into at least one of them. This way, we can then perform a tenant-to-tenant-style pentest, to see if it’s possible to break out of one segment to access another.

In part three, we’ll take a look at how the maturity of the client’s cloud implementation can impact the way pentests are carried out. Stay tuned!

Additional reading:

• Cloud Pentesting, Pt. 1: Breaking Down the Basics
• CVE-2022-1026: Kyocera Net View Address Book Exposure
• Analyzing the Attack Landscape: Rapid7’s 2021 Vulnerability Intelligence Report
• Stay Ahead of Threats With Cloud Workload Protection

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/03/21/cloud-pentesting-pt-1-breaking-down-the-basics/

The concept of cloud computing has been around for awhile, but it seems like as of late — at least in the penetration testing field — more and more customers are looking to get a pentest done in their cloud deployment. What does that mean? How does that look? What can be tested, and what’s out of scope? Why would I want a pentest in the cloud? Let’s start with the basics here, to hopefully shed some light on what this is all about, and then we’ll get into the thick of it.

Cloud computing is the idea of using software and services that run on the internet as a way for an organization to deploy their once on-premise systems. This isn’t a new concept — in fact, the major vendors, such as Amazon’s AWS, Microsoft’s Azure, and Google’s Cloud Platform, have all been around for about 15 years. Still, cloud sometimes seems like it’s being talked about as if it was invented just yesterday, but we’ll get into that a bit more later.

So, cloud computing means using someone else’s computer, in a figurative or quite literal sense. Simple enough, right?  

Wrong! There are various ways that companies have started to utilize cloud providers, and these all impact how pentests are carried out in cloud environments. Let’s take a closer look at the three primary cloud configurations.

Traditional cloud usage

Some companies have simply lifted infrastructure and services straight from their own on-premise data centers and moved them into the cloud. This looks a whole lot like setting up one virtual private cloud (VPC), with numerous virtual machines, a flat network, and that’s it! While this might not seem like a company is using their cloud vendor to its fullest potential, they’re still reaping the benefits of never having to manage uptime of physical hardware, calling their ISP late at night because of an outage, or worrying about power outages or cooling.

But one inherent problem remains: The company still requires significant staff to maintain the virtual machines and perform operating system updates, software versioning, cipher suite usage, code base fixes, and more. This starts to look a lot like the typical vulnerability management (VM) program, where IT and security continue to own and maintain infrastructure. They work to patch and harden endpoints in the cloud and are still in line for changes to be committed to the cloud infrastructure.

Cloud-native usage

The other side of cloud adoption is a more mature approach, where a company has devoted time and effort toward transitioning their once on-premise infrastructure to a fully utilized cloud deployment. While this could very well include the use of the typical VPC, network stack, virtual machines, and more, the more mature organization will utilize cloud-native deployments. These could include storage services such as S3, function services, or even cloud-native Kubernetes.

Cloud-native users shift the priorities and responsibilities of IT and security teams so that they no longer act as gatekeepers to prevent the scaling up or out of infrastructure utilized by product teams. In most of these environments, the product teams own the ability to make commitments in the cloud without IT and security input. Meanwhile, IT and security focus on proper controls and configurations to prevent security incidents. Patching is exchanged for rebuilds, and network alerting and physical server isolation are handled through automated responses, such as an alert with AWS Config that automatically changes the security group for a resource in the cloud and isolates it for further investigation.

These types of deployments start to more fully utilize the capabilities of the cloud, such as automated deployment through infrastructure-as-code solutions like AWS Cloud Formation. Gone are the days when an organization would deploy Kubernetes on top of a virtual machine to deploy containers. Now, cloud-native vendors provide this service with AWS’s Elastic Kubernetes Services, Microsoft’s Azure Kubernetes Services, and for obvious reasons, Google’s Kubernetes Engine. These and other types of cloud native deployments really help to ease the burden on the organization.

Hybrid cloud

Then there’s hybrid cloud. This is where a customer can set up their on-premise environment to also tie into their cloud environment, or visa versa. One common theme we see is with Microsoft Azure, where the Azure AD Connect sync is used to synchronize on-premise Active Directory to Azure AD. This can be very beneficial when the company is using other Software-as-a-Service (SaaS) components, such as Microsoft Office 365.  

There are various benefits to utilizing hybrid cloud deployments. Maybe there are specific components that a customer wants to keep in house and support on their own infrastructure. Or perhaps the customer doesn’t yet have experience with how to maintain Kubernetes but is utilizing Google Cloud Platform. The ability to deploy your own services is the key to flexibility, and the cloud helps provide that.

In part two, we’ll take a closer look at how these different cloud deployments impact pentesting in the cloud.

Additional reading:

• Why Security in Kubernetes Isn’t the Same as in Linux: Part 1
• Dropping Files on a Domain Controller Using CVE-2021-43893
• Time to Act: Bridging the Gap in Cloud Automation Adoption
• Hands-On IoT Hacking: Rapid7 at DefCon IoT Village, Part 1