Storm Chasing: How We Hacked Your Cloud

Overview

The traditional methodology of a remote attacker who has no preconceptions of a target network used to be fairly static. With organizations moving to “the cloud”, the approach attackers are taking is going to change drastically if it hasn’t already. In this blog post I am going to detail why, if your organization has moved its assets to the cloud, an attacker is likely going to make that their primary attack focus. They will likely succeed, and you will likely not know that it happened.

Cloud Computing Primer

Scalable storage, easy collaboration between employees, and cost savings by eliminating the need for a data center are all benefits that organizations see in “the cloud”. From a security perspective there are definitely some added benefits of cloud computing, but I am going to discuss a few shortfallings. One very common misconception is that “the cloud” is some mystical flying entity that protects your data, saves you valuable hard drive space, and shades you from the sun.

This is the definition of ‘cloud computing’:

Cloud Computing: n. the practice of using a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server or a personal computer.

This essentially means that your data that previously would have been on your own system is just on someone else’s system now, and you are renting space from them. There are many considerations that must come to mind when you look at handing your data over to a cloud provider.

• Is the cloud provider doing their own due diligence when it comes to network security? Many people see the likes of Google, Microsoft, and Amazon and immediately believe that because these services are so popular and widespread that they must be secure. If one of these organizations had a breach it would be bad for a lot of people.
• Is the data physically secure? Your data is physically sitting on a hard drive somewhere inside one of the data centers of the cloud provider you choose. What are they doing to protect physical access to those?
• One concern I’m not going to get into in this post but is definitely one many have is this: Are the cloud providers themselves being ethical when it comes to the handling of your data? Are they able to access whatever they want of yours? If so, would you know if they do? …And what about if a government entity requests data from them?

Sure, cloud computing is convenient. But sacrificing security for convenience is a fatal mistake.

External Network Pentest Forecast

When it comes to an external network architecture most organizations think that there are only two possible attack vectors for an attacker to gain access to internal resources. Most think that an attacker must either find a remotely exploitable flaw in an externally exposed system, or they must phish an employee of the organization.

Of course there are a multitude of other ways an attacker might gain access to an organization’s internal network but these typically involve some sort of physical access. For example, many organizations offer wireless networks and occasionally do a poor job at segmenting guest networks from corporate networks. There is also the risk of a malicious insider who already has physical access to an internal asset of an organization. With organizations moving more and more of their internal data systems, assets, and communication architecture to the cloud this adds a new attack vector for remote attackers.

In two other blog posts I’ve written I detailed ways an external attacker can gain access to domain credentials without being on a target network. In part 1 I discussed how employees are reusing the same passwords on personal accounts as corporate accounts and how attackers can find these. In part 2 I discuss password spraying Outlook Web Access portals.

Both of these techniques can result in an attacker gaining access to domain credentials, but an attacker who wants to compromise an organization’s assets would still need access of some kind to a target network. This would historically mean the attacker would still need to find some sort of VPN access, or phish an internal employee. With more movement of corporate assets to cloud infrastructures it is becoming more likely that an attacker simply needs a valid credential and a web browser to access sensitive corporate data.

Case Study: Let’s Go Hack A Cloud

Very recently a coworker of mine Derek Banks (0xderuke) and myself were performing a “Blackbox External Network Assessment”. The blackbox nature of this assessment means that we had no scoping information. No target ranges were provided to us so we were on our own to perform recon and discover where this company’s external assets were. Through our recon we found a few external hosts, but the attack surface was very slim.

Through bruteforcing of subdomains we discovered an ‘autodiscover’ subdomain. The ‘autodiscover’ subdomain is commonly used to assist in the setup of email clients so that the user simply needs to enter an email address and password. This is very commonly associated with Microsoft Exchange environments. For this particular customer, when we navigated a web browser to the autodiscover subdomain we were redirected a Microsoft Office 365 login portal. At this point we contacted the customer to determine if the Microsoft Office 365 portal was in scope for testing. They confirmed that it was. (Note: when pentesting third-party services of any kind it is very important that the organization communicate that an assessment is going to occur with the third-party. Most third-party orgs have a pentest authorization form the organization can fill out to authorize the pentest. See below for a list of these.)

During our reconnaissance phase we always try to find both valid email addresses as well as usernames. For this particular company we had discovered a relatively low number of valid email addresses, and no usernames. Nevertheless we proceeded in attempting password-spraying attacks. Even with the low number of email addresses we had discovered we were still able to password spray a valid user credential using the always-reliable, season-year combination (Spring2016).

Here’s where the magic comes into play when it comes to attacking cloud infrastructures. We started with a very small number of valid email addresses, and then password sprayed one. This organization did not utilize two-factor authentication so at this point we had access to this particular user’s Office 365 account, which had access to Outlook mail, Sharepoint, OneDrive, etc. Before we proceeded in pillaging the Office365 services we wanted to see if we could find any more valid email addresses. So, naturally we started poking around Outlook. The thing we quickly learned was that the “Address Book” gave us pretty much everything we needed. It included the email addresses, usernames, phone numbers, and full names of every employee in the company. At this point we now had a complete list of everyone’s email address in thecompany.

Outlook Address Book

We continued on with more password spraying, this time with a full email list. Many more credentials were obtained and we now had access to the cloud infrastructure as a number of different types of users with different roles in the company. For each user the types of files and things we could access in the cloud were different. But just like a file share on an internal network, the permissions must be configured so that only the correct users are able to access protected resources.

Anytime there is a collaboration/documentation platform like Sharepoint used by an organization there is commonly a treasure-trove of data to be found there. We found a ton of very sensitive information being stored in this organization’s cloud. While we navigated through the Sharepoint site and located sensitive company information we more importantly found access to the organization’s actual internal infrastructure.

Sharepoint, like pretty much every other cloud service, has a very useful ‘search’ function. This is useful to employees to find the documents they are looking for fast but is also useful to an attacker if the organization is storing sensitive documents there. During our reconnaissance phase we didn’t discover any sort of remote access systems like a VPN server. This was very much intriguing to us as we assumed that this rather large organization had users accessing their network remotely. We performed a search in their Sharepoint site for “VPN”. Low and behold we found a document detailing exactly what VPN client to install, where to direct it to connect to, and the “PIN” that must be used along with valid user credentials to authenticate to the organization’s network.

Of course two-factor wasn’t enabled on the VPN as well. We VPN’d into the network as one of the users we password sprayed. From there we escalated privileges to domain admin through our typical means.

Conclusion

While this story ended up with us accessing an organization’s internal network infrastructure during a blackbox external network assessment, we did it by hacking our way through the organization’s cloud infrastructure. This particular assessment was focused on attacking the Microsoft Office 365 platform, but could easily be performed against similar cloud infrastures like Google, or Amazon’s AWS.

If you are an organization that utilizes cloud services to host your organization’s data, email, etc. please implement two-factor authentication. Had two-factor authentication been enabled during the case study above we would have been stopped way earlier.

Remember that if you are going to perform a pentest against a third-party service get authorization first. I’ve crafted a list of a few of the auth forms below.

Pentest Authorization Forms

Microsoft Azure – https://security-forms.azure.com/penetration-testing/terms

Amazon AWS – https://aws.amazon.com/security/penetration-testing/

Google Cloud Platform – https://cloud.google.com/security/

        -Interestingly enough Google says you don’t have to contact them.