JR Johnson Cloud, Penetration Test Cloud, External Penetration Test, penetration test

Penetration Testing in the Cloud

By now, I think everyone has heard the phrase “moving to the cloud” enough to make their head spin. And it’s true, organizations are steadily moving to the cloud because of the many benefits this model of operation offers. According to Forbes in 2017, “hybrid cloud adoption grew 3x in the last year, increasing from 19% to 57% of organizations surveyed.” Offloading the management of massive data centers filled with hundreds or thousands of physical servers to someone else is hard to argue against. A lot of these organizations making the move, however, are not experts in cloud technologies. And rightfully so, as this is a relatively new movement with a significant skills shortage, by most people’s accounts. So when you move your organizational assets to the cloud, you simplify many things, but you’ve also got to change your approach for a lot of things, such as penetration testing. Penetration testing in the cloud is not a significant shift from penetration testing for traditional networks, but there are some important nuances to understand.

Traditional Penetration Testing vs. Penetration Testing in the Cloud

Permission

The primary and fundamental difference in cloud penetration testing is that your organization doesn’t own the underlying hardware that your systems/applications/services are running on. So you’ve got to make sure that you have permission prior to testing your cloud infrastructure or having a third-party test it. In some cases, this is really simple, as many hosting providers don’t require permission anymore to perform network-level penetration testing of your public facing hosts (e.g. Azure, Digital Ocean, Google), as long as the testing doesn’t include any denial-of-service (DoS) aspects. In cases where you do have to get permission, it’s usually a ticket submission (e.g. Rackspace) or a form you have to fill out (e.g. AWS) roughly 72 hours in advance of testing starting. This may not seem like a big deal but it’s an important step in coordinating a penetration test to keep all parties out of trouble.

Scope

For your cloud services, there’s more to consider when you’r thinking about penetration testing them. Certain cloud services just can’t be tested, due to the fact that they are owned and operated by the cloud vendor. We’re talking about things like Amazon CloudFront. There are also some vendor-specific restrictions preventing penetration testing from very low resource instances, such as Amazon’s small and micro Relational Database Systems (RDS). But for most organization’s, you don’t have to be concerned with this, as your penetration tests will focus on virtual server-style instances (think EC2, Droplets, etc.) or static hosting configurations (like S3 buckets).

The other side of the coin is evaluating SaaS and other shared cloud resources, such as the Microsoft Office 365 platform. While you still want these assets in scope, penetration testers will stick to the application-layer to try and gain access to your data and resources here, since you do not own the underlying servers and related infrastructure. Hint: If you’ve got two-factor authentication turned on for these applications, you’ll be making life really difficult for a penetration tester or real world attacker.

Methodology

So with permission in hand, and a good idea of what you’re going to test in the cloud, we can move on to how those assets need to be tested. The testing approach to cloud assets is fundamentally the same when you’re looking at them from an external perspective. They are an IP address on the Internet with open ports hosting services that can be scanned and probed for vulnerabilities. You can use a traditional external penetration testing methodology in your approach. In cloud penetration testing, you’ve also got to address some additional attack vectors:

S3 Bucket Misconfiguration
Administrator Key Disclosure
Open Source Software Disclosing API Keys (AWS keys in Github)
Password Attacks on Cloud Applications (Outlook, SharePoint, etc.)

To the Cloud!

So as more and more organizations move to a full or hybrid cloud implementation, penetration testing has to adapt and shift, as well. Cloud assets still require penetration testing for compliance purposes and to maintain an all around best-practice security program. External cloud penetration testing still has a very familiar look and feel, albeit with some nuances and additional attacks to consider. For now, we’ll stick with the external perspective as we’re discussing cloud infrastructure. But in future posts, we’ll explore internal penetration testing in the cloud and cloud configuration reviews which can be a little more complex, but equally valuable for your organization.