As penetration testers we are often very aware of the boundaries of the exercise. Scoping is the part of the preperation where we decide what can be tested and what not. This used to be a matter of finding agreement between service owners and testers, and having them all on the same page meant the exercise could start. But nowadays we see applications being owned by multiple parties, or hosted in the cloud. The question of what is allowed becomes a little bit less clear.
The big cloud providers do provide Terms of Service, Rules of Engagement and Penetration Testing guidance. But their details differ, and a pen tester could find himself in dangerous area when he assumes the rules on AWS apply on Azure just the same.
Amazon AWS vs Microsoft Azure
The rules for Amazon AWS define that ‘non-shared resources’ are in scope, as well as some shared environments like Lambda and API gateway. Pivoting via the backend is not allowed, unless all parts in between are fully owned by the customer as well.
With Azure, the rules are a bit more strict overall. Microsoft has been conservative in supporting penetration testing initially, but seems to have become more encouraging lately. In contrast to AWS, on Azure it is not allowed for a pen tester to attempt a sandbox escape on their serverless functions (Azure Functions). Also, ‘moving beyond proof of concept’ is discouraged. As an example they provide that it is okay to illustrate you have sysadmin access by running an SQL injection, but trying to execute commands with xp_cmdshell would cross the line.
Does that mean testing any of the cloud provider infrastructure is out of scope? For your customer assignment that may be, but how about bug bounty programs?
Bug bounty programs
Currently, there is no bug bounty program for AWS. Vulnerabilities can be reported, but there will be no monetary reward. They do have a program for other parts of Amazon, but AWS is specifically excluded.
In contrast, Azure has the Microsoft Azure Bounty Program. It provides awards in the range of $500 – $40.000. Moreover, there are specific bounty programs for O365, DevOps, Azure Active Directory, and more. How is it possible to conduct a proper test with the aforementioned rules? As long as you include the string “MSOBB” in your account name and tenant name, Microsoft will recognize you as security researcher and permit you to touch the Azure core services (of course there are some testing rules, as laid out on the web page linked above).
Looking inside with Azure Stack
So how would one go about testing the cloud core. Looking for vulnerabilities in a cloud environment is mostly a black box effort. Fortunately, Azure provides a feature that allows you to run ‘Azure on-premise’. That is – without any connection to the ‘real’ Azure, you can deploy it on a local server and simulate an Azure environment in your own datacenter. This is called Azure Stack. Of course it doesn’t contain all features, but it does share the same code base (derived from a few versions older than the current one). This creates the perfect playground for us to look at the inner workings, and conduct a much more white box approach.
There have been many interesting bugs discovered in Microsoft Azure over the last few years. The number of components and features is evergrowing, which makes for a large attack surface. Take this example where a privilege escalation was found in KuduLite, a service which allows you to access diagnostic information on an App service from a Linux workstation. Turns out the SSH connection that KuduLite has with the management plane of the App service could be hijacked – resulting in complete control of the web server
At Red Timmy Security, we praise the fact that Microsoft has become more open to bug bounty research. If it makes the end product more secure is hard to measure, but it will definitely bring more trust from customers. With the program and capabilities that Azure is offering, we might put our focus on cloud research in the near future as well. So as always, stay tuned!
Check out our training on BlackHat USA this year: Practical Web Application Hacking Advanced