Prior to the COVID lockdown we were testing more and more cloud deployments. The lockdown seems to have caused a large increase in the number of cloud migrations, probably migrations which were planned but have now been rushed forward. Based on this cloud migration a common conversation we have with clients is this; ‘we don’t need any penetration testing or security reviews because we use the cloud now’. This is due to an incredible effort many cloud providers have put in to get the message across that the “cloud” is secure. Now, I don’t disagree with that, we use a lot of cloud providers, Azure, AWS, Google Cloud, Digital Ocean, and the rest. Hence, it would be pretty hypocritical to say ‘don’t use it due to security concerns’. Also I’ll explain why below that point isn’t also just a sales pitch for more penetration testing.
Cloud platforms can be secure, in some ways they can be even more secure than on premise. (But if done badly, they can actually be worse but I’ll come on to that.) To break it down, the main difference is normally a cloud provider has more resources to secure the core systems than the average companies IT department. However, as technology is constantly moving, whether in the cloud or on premise, systems become unpatched, access control becomes more permissive, security rules modified and mistakes happen.
When I began this blog I wanted to explain the specific technical issues and differences between on-premise and cloud-based environments, but a quick Google found Holly’s blog which pretty much nails the technical differences between testing between them. In her blog on AWS Holly highlights three key areas for cloud testing;
- Testing in the cloud.
- Testing on the cloud.
- Testing the cloud console.
I quickly changed tact and instead I’ve opted to build on Holly’s blog by demonstrating some of the experiences we have had. For the rest of the blog I will attempt to explain how these areas translate into real life issues for cloud deployment.
We have a few examples of where we have seen cloud migrations security fall, so hopefully you can use this to shore up your defences and get the most out of your own deployment.
Firewall Configuration
The beauty of cloud based systems is you can just spin them up in a matter of seconds. (Previous projects I have built on Digital Ocean have produced bills which will speak to this “remember the 4GB image is default size”.) – I digress.
The ease of use means it’s quite easy to set up, connect and be on your way. Unfortunately, with online on-premise systems, you need to operate these systems over the public internet which means, you need to open ports to connect to and you know what’s bad? RDP open to the internet…
Recently on tests in the cloud, we have found a number of RDP and other remote access services wide open and ready to accept connection. Some without the system owner’s knowledge. And with all the potential attack vectors against RDP this can pose a big risk.
Some beauties are easily found using Shodan, such as this one;
Mainly to brute force attacks, credential stuffing attacks (using leaked passwords which link to the organisation’s domain) and classic or more modern RDP vulnerabilities. Such as these two RDP remote code execution lovelies, which are seen as an extension of 2019’s big RDP issue and POC Bluekeep. (Others include CVE-2020-0609 and CVE-2020-0610.)
And its not just Windows last month one of our Linux servers reported over 100,000 brute force attempts, 100,000… fortunately we use a private key to authenticate. So in an ideal world, you don’t want to expose your RDP/SSH or any other remote access service to the internet, but keep that access.
For us, the simplest way to remediate this was by allow listing (formerly whitelisting) and placing these services behind a VPN. Allow listing can work well, unless you have a dynamic IP, so we find having your own VPN is the ideal solution as this allows you to retain that static IP.
Patching (it never ends and you cannot escape it)
Another area where traditional security issues transfer over is patching. Whether that’s unique AWS components (which still need updating) or class Microsoft and 3rd party matches. Moving to a cloud platform such as SalesForce can remove your requirements to patch at the operating system level. However moving your servers into an Azure or AWS EC2 Environment means you get to retain that responsibility. Unfortunately, over the past year we have seen a lot of cloud based operating systems and services which have fallen out of grace with their patch maintenance. So I ask you, why might you not patch?
I mean we only have to look back at April 2020 when we can see a Windows update causing serious damage to Windows 10 systems. This is going to make anyone nervous about updating their systems. (I get worried when we update WordPress!) But patches are needed.
And just to scare you – in March 2020 Microsoft pushed the most security patches out for 20 years (115 in total, 26 of those being critical)! So the best advice would be, don’t patch but also do patch.
But seriously, this means you need to keep on top of your patches, every month your systems and services remain unpatched increases the risk of them being compromised. Lots of organisations have developed good patch management practises over the years, and when it comes to the cloud, these need to be transferred and adapted.
User Management
Break free from Active Directory! They say, it will make your life easier they say! Ah well, actually, you might now have more accounts than you ever released.
Each new “cloud platform” comes with a host of admin and user accounts which are not so easily to integrate. There are 3rd party solution which can help but generally, you are going to need to manage those accounts in some way. Additionally, one of the other main issues we find, is now that administrative account which was only accessible whilst physically inside the network is now an AWS admin account which can be accessed via the AWS console. So that account needs to be given extra care and security attention.
When we audit accounts as part of a penetration test we can find some quite scary situations where key accounts either have very poor levels of security or users are reverting to bad practises such as weak passwords, shared passwords etc. What can you do to solve these issues?
- Cloud account policy, make sure both administrators and users are aware of the rules and requirements for password use on cloud platforms.
- Password managers can help with the various passwords needed for different accounts and prevent password use.
- And finally, multi-factor authorisation is a must for administrative accounts. (With backup codes stored securely, lose your MFA device and you will have fun resetting your account, honestly, this hasn’t happened to me….)
S3 Buckets
One of the issues Holly mentioned in her blog was about the security of S3 buckets. Now this is quite timely as whilst I am writing this one of team has just found and S3 vulnerability on a test they are carrying out. Essentially, they are able to directly access the S3 buckets and upload several files. And its not so difficult to find S3 buckets, *.s3.amazonaws.com is typically the root URL for many. And what you should see is:
The reason for it, they were unaware the bucket was publicly available. As per the design the bucket should have been accessible only by internal AWS components, unfortunately this was not the case. However, that’s the point of testing, so we can find these issues, report them and get them fixed.
Additional Security Features
Take for example a WAF (Web Application Firewall), both Azure and AWS come with really feature-rich WAF’s. I really like Azure’s, mainly because it’s based on the OWASP Core Rule Set. And my previous experience of ModSecuriy can be finally put to use.
However (here comes the catch), as good and feature rich as the WAF is, many deployments in the cloud do not make use of them. We know this because we have tested many Azure deployments and rarely have to ask them to turn them off. Just investing a small amount of time into the configuration and deployment of these defensive systems can really make an adversaries task much more difficult. We can attest to this, we have had many a cross site script or exploit blocked by a good WAF.
So overall I hope that helps and give you some pointers on what can be done to help secure your cloud deployment. Which leads into a nice sales pitch, if you are worried about your deployments or want it to be independently tested please get in touch and we will do our best to help you out and take that stress and worry away.
If you have any questions about this article, please contact the Samurai team here.