Table of Content
Introduction
The exploitation of Server Misconfiguration is a big concern for any cybersecurity organization. A lot of data breaches occur because of this vulnerability.
A big example of such an attack is Toyota. Toyota is leaking their customer’s personal information due to misconfiguration in their server. They stated on their portal that a client data breach mistake transpired as a result of an inaccurate cloud configuration.
In this blog, we will discuss how misconfiguration can lead to a bigger cyber incident. We will discuss how cloud misconfiguration is a serious concern and how these security misconfigurations are happening.
We will also show you a practical example of how threat actors can exploit a server misconfiguration. In our case, we will be using the Amazon web service.
In our recent blog, we have also elaborated on how the data breach occurred. This gives a brief of web app vulnerabilities that can cause damage to an organization’s assets.
Amazon Web Service
Before going into how cloud misconfiguration can lead to data breaches, let’s first understand the basics of Amazon Web service. As per the following example, we will be using Amazon Web Service. It’s the most used cloud platform and we will be exploiting its misconfiguration.
Amazon web service or aws is the most used cloud service among organizations because of its flexibility, reliability, and features. Their inbuilt IAM service also helps organizations to take control of their assets by default.
Amazon S3 Bucket
Amazon S3 bucket or Amazon Simple Storage Service provides a secure storage service where some organizations store their website assets such as images, files, and audio, or the organizations store their entire server
AWS S3 bucket provides default security whenever a user creates a new s3 bucket, so that means only the bucket and object owner have access to their s3 data.
Additionally, IAM or Identity Access Management can also be used to manage permission and user privilege on an s3 server. The problem is that when an amateur user creates a new user account or tries to change the settings in the s3 bucket, this can cause security misconfiguration and lead to data leaks, giving the public access to unauthorized and unprivileged users.
So let’s see a practical example of how these cloud misconfigurations looked like and how threat actors can exploit them.
Step 1: Recon the target for server misconfiguration
The recon part is about discovering if there’s any firewall on the cloud server, as some aws apps are not configured behind the web app firewall this allows us to get the region of the server.
We will be exploiting https://flaws.cloud so let’s check if the target website has any firewall or not.
First, we will get the basic info about the target server, we will be using “whatweb flaws. cloud” command.
The IP address we obtained is 52.92.212.51, let’s do a reverse lookup to check if we can get the server region.
We will be using nslookup 52.92.212.51 to get the region and the server details it is using to host the data.
So doing nslookup gives us information that it’s hosted in the US-West region. This also confirms that it’s not behind the firewall and we are good to go for our next step to exploit this server.
Additionally, If we open s3-website-us-west-2.amazonaws.com in our browser, it will redirect us to the Amazon Web Service website. This indicates that it’s actually hosted on the AWS server.
Step 2: Enumeration S3 permission
In this step we will explore the content hosted on this cloud, to do this we will use the aws cli version.
So using aws s3 ls://flaws.cloud/ –no-sign-request –region us-west-2 listed all the content hosted on our target server. This indicates that our target server has publicly accessible assets.
We can have a look at the above snippet that has all the content of the webserver hosted on the cloud. We can see there’s a secret HTML file on this server. Let’s copy all the content to our machine and check what’s stored inside that secret html file.
For this, we will use aws s3 cp s3://flaws.cloud/secret-dd02c7c.html –no-sign-request –region us-west-2 to our machine’s home directory.
Let’s read the content inside this secret file. Here, we will use more secret.doc.html commands.
Well, this looks like we have found the secret doc, in the real world scenario this could be a secret key, a client’s personal details, or other sensitive details.
Step 3: Enumerating write permission: server misconfiguration
The worst-case scenario could be when the threat actor gets ‘write permission’ on the target machine.
The worst-case scenario could be when the threat actor gets written permission on the target machine. Let’s see if we have write permission on this machine. We will enumerate the write permission using aws s3 cp /home/dave/run.sh s3://flaws.cloud/ –no-sign-request –region us-west-2
We have directed aws to copy run.sh ( just a random file ) from our machine to the target server and we got permission denied.
Well, at least this permission is not allowed here. In our penetration testing, we have seen organizations that have given written permission which allows the malicious actor to do whatever they want with the server.
Toyota Data Leak
By reading Toyota’s statement on the data leak, it indicates that it was not that worse. Even though there were several misconfigured servers leaking their customer’s personal information allowing anyone on the internet to access them.
But there wasn’t any written permission, therefore, a threat actor had access to only view them. This vulnerability is also defined as Directory listening.
Conclusion
In the aforementioned instance, we used Amazon Web Service to show cloud misconfiguration, but server misconfiguration is not limited to AWS only. There are several web servers that need to audit in different ways. There are various pen-testing and auditing techniques for cloud misconfiguration.
Kratikal, a Cert-In impannelled industry can help your organization be secure and harden from any misconfiguration. This can protect your organization from any future threats.