Not Your Typical Pentest – IAM Cloud Insecurity

Update: A co-worker brought up this story which shows exactly how bad things can get by abusing IAM roles. https://threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761/

As a penetration tester, I often have to adapt and change according to the technologies that I am testing. However, sometimes the technology I am testing may be new to me and I have to perform research to truly understand the technology so that I can do a thorough job. Too often you will find that your penetration testers can get into a mode of scan and report. They will fire up the vulnerability scanner, identify some stuff for the client to fix, and move on. This often happens because testers can get complacent with what they are seeing in the industry. Then when they land a remote shell on a system, they are repeating what they did last time because, “Hey it worked last time”.

What really makes a good penetration tester is one who not only looks at the technology being tested through the eyes of an experienced tester, but also one who looks at the technology through the eyes of the administrator, and users of the system. This mindset definitely takes a lot of effort because if you are younger and just getting into the security field, you may not have experience as an IT administrator. When I was responsible for reviewing resumes for penetration testing applicants one thing I often looked for was some level of system administration experience. How can you be expected to traverse and ultimately exploit a Windows active directory environment if you don’t have any experience using a Windows active directory. The same goes for Linux, if you don’t understand the deep inner workings of Linux, how can you hope to turn an unprivileged shell into a privileged shell without just being a script kiddie launching someone else’s kernel exploits.

An interesting shift I have seen in the last few years is that developers have been getting involved in penetration testing. Some of these guys might not have the system administration experience I would look for and it might be hard to warrant their hire due to lack of experience. But something interesting has happened in the world the last 5-10 years. While network and operating system level attacks are still around and dangerous (WannaCrypt is a huge example of this) a lot of network environments are getting to be hardened against such attacks. Firewalls, HIPS, Automatic Updates are real defenses which can mitigate many issues. WannaCrypt for example could not infect people running a properly configured firewall, OR had Automatic Updates enabled. So where do we go from here? Well to the web applications. We adapt our tactics along with the industry in order to most effectively assess security. As a result, we are now seeing that these developers actually have some skills which can be directly applied and I’ve been impressed with a few I have worked with.

So now I switch our focus to another booming and rapidly growing technology, the Cloud. I have in the past done security assessments where I look at the Cloud just like any other network. When testing the internal a client will typically set us up a system to SSH into and either proxy our scans through or perform testing from that system. Similarly, when testing an internet facing system, I approached it just like another webserver within a standard DMZ. I mean a webserver is a webserver, right?

Wrong I recently found out while studying for an AWS certification. I started this because I realized that this new technology had a lot of ins and outs that I hadn’t really played with much. So far, the biggest thing I’ve noticed of interest as a penetration tester is the Identity Access Management configuration. IAM is hardly a joyous entertaining pass time, typically its chalk full of policy creation, adherence, auditing, and a lot of repetitive work.

When I dove into my lab work I started to see a great attack avenue that I would have never considered in the past. Roles. Not just user roles, but AWS Resource roles. These are particularly attractive to an attacker because to use the role you do not need access to any credentials or access keys. These roles are designed for sharing AWS resources among each other seamlessly. I put together a small demonstration showing just how dangerous these roles can be.

Abusing AWS S3 Role Access Demo

For this demo, I have setup an EC2 Nano Instance hosting a webpage. I really like cats so I built a site where people can upload all their cat pictures to me. This is a purposefully vulnerable website to demonstrate a common vulnerability, “Unrestricted File Upload” which will inevitably lead to the upload and interaction with a backdoor on the website.

Figure 1: Sample Vulnerable Web Application

So how is the site supposed to function? Well other cat lovers would go out and choose the file they wish to upload and click upload. This executes some backend PHP which will ultimately save the file into the /uploads folder.

Figure 2: Selecting file to upload

Figure 3: File uploaded

Figure 4: File accessed

Now let’s not get stuck on how insecure this web application is. It doesn’t vet file extensions, MIME types, it allows access to the recently uploaded files… its terrible just like many applications we test. So most assessors will at this point try to upload a file that the web application owner never expected, such as a PHP web shell. Web shells just take input from the user within a command box and executes it on the target system under the context of the user running the webserver. Normally this would be www-data or apache or NetworkService hereby referred to as just apache. You may think that if we are on the system and we can execute commands that it is game over, and in a sense it is. This is truly a bad situation, typically this is where web defacements can occur. Running under the context of an unprivileged user such as apache only grants us access to read/write specific files generally only the web content. More malicious attackers would embed a malicious JavaScript IFRAME to try and infect users via an exploit kit.

However, as a penetration tester we are brought in to demonstrate risk instead of just communicate vulnerabilities. This is what breaks a penetration test apart from a vulnerability assessment. As a professional I am not going to deface our client’s website, nor would it be a good idea to try to just start launching exploits at whoever visits the site. Normally our goal is to elevate our privileges within the system and attempt to access sensitive data or pivot to another system where we may be able to better demonstrate risk. For the sake of this demo, we are going to assume that I was unable to elevate my privileges, unable to identify any sensitive data, and unable to find any other systems to pivot to. In all honesty the test would normally end here with a write up explaining the malicious things an attacker could do. So, now that we understand the playing field, lets upload our web shell. For this example, I used a new web shell I found at https://gist.github.com/RyanKung/3369063 (thanks Ryan)

Figure 5: Uploading PHP web shell

Figure 6: Web shell uploaded

Figure 7:Web shell accessed

Great so we now have remote command execution on the target system. Keeping in line of our scenario we will assume no privilege escalation, sensitive data, or pivot points exist on this system. We can also see that my terminal is running as an unprivileged user apache.

Figure 8: 2 commands, first “id”, then “cat /etc/shadow”

This is where the real penetration testers can shine. Now this is just one example of abuse however its really about being in the right mindset about how to approach new technologies. From my training, I knew it was possible for an EC2 instance to have access to other AWS services such as S3. In order to leverage these privileges, we only need command execution, and the use of the AWS CLI tools which are conveniently already installed on this system for us (as is the case with all Amazon Linux AMI’s). Using our web shell and the AWS CLI tools, we can issue the command “aws s3 ls” to determine if there are any Amazon S3 buckets on the account which this EC2 instance has access to.

Figure 9: Result of command "aws s3 ls"

Wow great, we see that we have multiple S3 buckets which showing up, next let’s see if we can get deeper into the “mycorpshare”. This is done with the command “aws s3 ls mycorpshare”.

Figure 10: Result of command "aws s3 ls mycorpshare"

Well it seems like we may have found the location where some department file shares are being housed. Upon digging into these you might imagine all the juicy sweet things which could be obtained. Attackers are harvesting W2’s for identity theft, Direct Deposit account information for financial theft, Documents containing Intellectual Property, Documents containing sensitive IT information, and the list never ends. If your business produces it someone wants to steal it. For this scenario, let’s check out the IT folder.

Figure 11: Result of command "aws s3 ls mycorpshare/IT/"

Figure 12: Result of command "aws s3 ls mycorpshare/IT/John/"

Well isn’t that interesting? John seems to have stored a secret text file on his folder share. Using a few commands, we will copy the file, print it to our screen, and then delete our copy of the file.

Figure 13: Result of command "aws s3 cp s3://mycorpshare/IT/John/S3cr3t.txt /tmp/S3cr3t.txt"

Figure 14: Result of command "cat /tmp/S3cr3t.txt"

Figure 15: Result of command "rm -rf /tmp/S3cr3t.txt"

Now you might be thinking it’s silly of me to find a username and password in a folder share, and the truth is that it’s not. This happens everywhere due to poor policy, or employee security awareness. I’ve seen people storing credit cards in text files like this… not good!

To wrap this up we will SSH into our system with our new username and password, elevate our privileges, and obtain root access. This was all achieved by leveraging intended functionality which if the penetration tester didn’t know to look for, or research, may have been missed. This is just an example for S3 but using this example you would also be able to do some terrible things. Deleting and Creating instances would be pretty bad. Imagine if someone spun up 25 huge instances over and over then deleting them just to drive your bill up? Or started bitcoin mining? Imagine if your production systems were deleted, then all your snapshots deleted, and all the backups you have on S3…. deleted…..yikes.

Figure 16: Root access obtained

The moral of the story as a penetration tester try to rise above being a security tester and look at things from the standpoint of system administration, design, utility etc. Be well rounded and take the time to do some research into your technologies before you assume that you have seen it all before. Our world changes daily and we need to change with it in this profession.

As an enterprise cloud administrator, try to ensure that your security policies are locked down as tight as possible and realize that unprivileged users on an EC2 system have the same access to Roles as ROOT applied to the AWS resource, don’t store your passwords in text files, and don’t build a really crappy web app about cats.