as appearing in PenTest Magazine Vol. 4 No. 1
As with any penetration testing engagement, you need to define the scope of the test. This can get tricky when dealing with cloud services. If you are engaging the provider directly, it’s relatively easy and you can work out the scope of what they wanted tested between the two of you as they have total control of everything in their environment (assuming they can support testing and not interfere with their customer’s business), however if you are dealing with a customer of the provider, things can get trickier. First off you’ll have to understand just what the relationship is with the cloud provider.
For the purposes of this article, let’s consider the three possible services your client could be using from a cloud provider as defined by NIST.
Software as a Service (SaaS)
Is a relationship where the provider manages the application as well and is most likely providing that same application to a number of other customers. This is where a customer signs up with a major application vendor such as a customer relationship manager and they log in to a centralized web site where every other customer logs in as well.
Platform as a Service (PaaS)
Are situations in which the customer provides the application that will be running, and the provider handles the hardware and virtualization portions. This can be found in situations where the customer has a custom built application and they are hosting it with a provider.
Infrastructure as a Service (Iaas)
Is when the provider provides the hardware and the customer is responsible for setting up the virtual environment and everything running in it. This is where the customer wants complete control over the systems they are using in the cloud environment and want complete separation of their environment from other customers of the provider.
Exactly what they are able to have tested will need clarification through their contract with the provider as well as discussions with them. You’ll also need to define the scope of what your client wants tested as well. They may not be interested in a ground up test and only care about the application level. Make sure you define their expectations and verify and work with the provider to ensure there won’t be any legal issues before you commit to a Statement of Work (SOW). In a nut shell, SaaS is the most restrictive to what can be tested if anything at all, and IaaS is going to give the most flexibility and the largest attack surface possible if your client doesn’t limit the scope to something specific.
In the next sections we will break down the different service levels and talk about what can be done in each one. Remember that we are going to be adding to complexity as we go so what we can test in SaaS, we can also test in PaaS and what we test in PaaS can be tested in Iaas.
SaaS Penetration Testing
This is going to be the most restrictive to test. Barring some near miraculous turn of events the provider won’t allow you to test the software itself. There will be no source code to review. There will be no attacking the surface of the application. You can however, check the interaction between the browser and the application. Look for session management cookies. Verify proper SSL and secure handling of traffic.
API key management could play a factor as well. If your client is the provider (which may themselves be hosting on a cloud service), you can test the application like any other web application penetration test.
This is where you will be able to actually attack the application and look for SQL Injection (SQLi) and session hijacking, Cross-site Scripting (XSS), etc. Going beyond this however will again require the agreement of the provider of the hosting services. It’s always a good idea to let them know testing is going on anyway as many will have that requirement in their contract and probably have some, Web Application Firewall (WAF), Intrusion Detection System (IDS), or Intrusion Prevention System (IPS) which could block your traffic if you are detected and it’s really not beneficially to test slowly apart from testing to see how well the WAF/IDS/IPS system works.
PaaS Penetration Testing
In this situation, we have much more to consider as a penetration tester. We have the application itself as well as the interfaces provided. This can get particularly hairy however as your client is still using a somewhat shared environment and there is potential for fallout affecting other businesses utilizing the provider. Many providers refuse to allow penetration testing for that purpose. If you were to break the application and gain high-level system access, the system does not belong to your client, but rather is running alongside other customers’ systems owned by the provider. In these situations, it may be best to setup a mirrored testing environment so the production environment is not affected. That’s actually a good idea any time when dealing with application testing to prevent production environment issues, but it may be required in this case.
In these situations as mentioned above, the typical purpose of this environment is because your client has written a custom application. This means the chances are good that you will find plenty of low hanging fruit unless they have very good experienced secure application developers. SQL and XSS will be commonplace if not. Make sure you check all those things that you may take for granted assuming that modern applications are more secured than the good ole days.
IaaS Penetration Testing
This is obviously going to give you the greatest range of testing options provided the cloud provider allows for testing. If not, then it’s time to have a serious conversation with your client about finding a new provider.
Operating System Patch Management
Typically in a cloud environment there are a number of builds that are maintained and deployed based off a base operating system with pre-loaded services such as web servers. While this can be a great security feature as a new system isn’t built from the ground up each time and has all appropriate patches in place, it can also mean that if the master image has a weakness, that weakness gets propagated to all systems so if you find one weak entry point, it can be trivial to find others based on that finding allowing you to pivot from one machine to the next. Not having the server physically present and part of the patch management program utilizing tools such as WSUS these servers typically require remote access to apply patches manually. Which brings us to the next section.
This is a primary concern in cloud services that is often not found in local networks. In order for the customer to access the server they manage on the provider’s cloud, they need remote access via SSH or RDP. It’s always best to not have those available to the Internet, but practically unavoidable in a cloud environment where the customer needs to administer the server. In addition to the dangers of having remote services exposed, more access to the server generally means more cost to the customer and their patching may not be as frequent as it otherwise would be.
Defining the Target
Public cloud services can change their IP addresses. They typically are shared and don’t have static IP addresses. It’s important to define that in the scope. You may need to consider changing IP addresses as part of the Rules of Engagement and adjustments to scope and be updated to changes that may occur during testing. Just always be sure the system you are testing is correct and you haven’t started attacking another customer’s system.
Fun with the Hypervisor
Assuming you are contracted with the cloud provider or have permission to test at this level (for example the client hosts their own cloud), there are things you can do to the cloud’s infrastructure that you wouldn’t be able to do otherwise. If they are hosting customers and not strictly their own stuff, you may have them spin up a few test images to try to break and try to escape the VM itself. However cutting to the quick you can go after Hypervisor itself and gain control of all VMs running on it. This has largely been theoretical and exploits have been few and far between.
VM Escape is an exploit which runs on a VM that allows the OS to break out of the VM sandbox and interact directly with the Hypervisor. Since VMs are typically running with high privileges so they can access the hardware, owning a VM and escaping can give you total control of the host, the hypervisor, and every other guest VM on the machine.
The most notable VM Escape exploit comes from Immunity and is part of their CANVAS penetration test tool. You can find the blackhat presentation for this http://www.blackhat.com/presentations/bh-usa-09/ KORTCHINSKY/BHUSA09-Kortchinsky-Cloudburst-PAPER.pdf.
Another recent VM Escape exploit that took advantage of a published vulnerability was developed by VUPEN. This exploit attacks the Xen hypervisor and you can read more about it here.
Hyperjacking describes attacking the hypervisor stack itself. It involves installing a rogue hypervisor to take complete control of the server which defeats conventional security measures as the OS is not aware the machine has been compromised. The hypervisor runs underneath the OS and attacking it will get you not only owning the server allowing you to attack the Virtual Machines, but it gives you persistence. Gain control of the hypervisor, and you gain control of everything running on that machine. This makes it the single point of failure and grants you the keys to the entire kingdom. Simple as that?
So the question then becomes how do we go about attacking the Hypervisor. For that you’ll need to research and understand virtual machine rootkits which is beyond the scope of this article, but maybe we’ll come back to a deep dive on that somewhere down the road.
In the meantime two notable examples exist. They are questionable at best and have been the target of much debate in the cloud/security community. In particular Bluepill caught significant heat and its credibility was largely questioned especially as it pertains to the claim that it is undetectable. Nevertheless you can find more about it here.
Subvirt, developed by Microsoft researchers and can be found here.
Denial of Service
While the other techniques mentioned above are very difficult to execute, a DOS can be stunningly effective against a cloud service when you target the guests running on it. It’s most likely not your intent nor in your SOW to perform a DOS, but I do like to give my clients the option of intentionally engaging in DOS testing as well as give them a warning that even though I won’t perform direct DOS attacks if they don’t want to do that sort of stress testing, it can happen anyway. I’ve personally accidentally knocked off several clients’ virtual hosts by flooding the network doing internal vulnerability assessments alone. Fortunately for them, those were internal networks and not exposed to the Internet, but it points out a serious problem with cloud services. The fact is, the host and the hypervisor are often overlooked when it comes to patching because of the complexity of patching it, the fact that it can require downtime for all the guests running on it, and simply people don’t think about it as a system and only look at the guest VMs. Obviously, this isn’t the case with major cloud vendors is it?
Always make sure you have a clear understanding of scope when you create your SOW and ensure you get all the proper authorizations before you begin. Depending on the type of cloud services being used, and how your client is involved in cloud services, you may have a lot to test, or very little. Most often, your client will not know the extent of which their cloud systems they have through a third party can be tested so it will be up to you to help them sort that out. You do want that contract right? Roll up your sleeves and help them through it. You’ll help seal the deal and keep yourself out of some very dangerous hot water. Make sure the provider is aware of the testing at all times, regardless of what the scope is you and your client have decided upon. It’s just good manners if nothing else. Happy hunting.