AWS Telnet & Passwordless Root

Background

Now this is a Tweet thread all about how

SecOps got flipped, spun Bezos ‘round

And I’d like to take a minute, just sit tight ‘fam

I’ll tell you how I became the Prince of Shodan

Lately, I have been looking more and more at AWS and Google API’s, specifically how it relates to malware and phishing campaigns. This lead me to what I thought initially might be a little too elementary of a string of Shodan searches, but the results were surprising.

I started out with looking for open telnet sessions with the following search string:

port:23 -password -login

Two million results and too much noise, so I started narrowing it based on things I saw in open sessions. This cut down on some of the extra undesirable results:

port:23 -login -password -Session -name

At this point, there is still too much to go through by hand and too small a chance of finding something interesting without wasting a ton of time. Next, I added “root@”, which will give results that include a root shell that is either authenticated already or does not require authentication:

port:23 -login -password -Session -name “root@”

That is a much better range of results with probably a MUCH higher percentage content of value. Now the thing to do would be to make it information that matters to someone in particular. I picked AWS because I saw more than a few Amazon IP ranges in the results and fine tuned the search thus:

port:23 -login -password -Session -name “root@” asn:”AS16509"

That’s a lot of devices open to the internet with root access. One can safely assume that if they were set up and left in this configuration, it was done by someone with only a cursory understanding of AWS systems and securing internet facing/cloud servers. Allowing for that, consider if a bad actor were to run this query every day and create accounts with root access on just a handful of the servers, document it, and repeat the process every day. After a couple of weeks, the accounts can be checked and any that still exist probably will continue to exist unnoticed.

Instant C2's.

Disclosure

As with the other interesting tidbits I’ve found, I tweeted about this particular item and after only 15 minutes, AWS Support tweeted back at me about it. Flattering!

I followed up this reply from AWS with an email to the support address provided (aws-security@amazon.com), detailing what I have described in this article.

Their response came back about 48 hours later. Disappointingly, it’s more a template response than any real reaction to the findings.

Hi Daniel

Amazon Web Services (AWS) understands and values the trust our customers place in us. We take security very seriously, and investigate all reported security concerns.

AWS offers a complete set of infrastructure and application services that enable our customers to run all their applications in the cloud. For more information on AWS and how customers are using our products and services see:

http://aws.amazon.com/what-is-aws/

When a customer uses AWS products and services instead of traditional IT infrastructure, this creates a shared responsibility model between the customer and AWS. AWS manages the security of our services themselves, from the virtualization layer down to the physical security of the facilities in which AWS operates. AWS customers are responsible for how they provision or restrict access to their own AWS resources, such as remote access to their EC2 instances or S3 buckets / objects, as well as updates and security patches of their chosen operating system or installed application software.

Please note, the security concern that you have reported is specific to a customer application and / or how an AWS customer has chosen to use an AWS product or service. To be clear, the security concern you have reported cannot be resolved by AWS but must be addressed by the customer, who may not be aware of or be following our recommended security best practices.

We have passed your security concern on to the specific customer for their awareness and potential mitigation.

If you become aware of any security concerns specific to AWS products and services, please do not hesitate to contact us at aws-security@amazon.com. Of course, if you become aware of any security concerns specific to an AWS customer and how they are using AWS, you should still feel free to contact us, and we will reach out to the customer on your behalf.

Thank you for sharing our passion for security and helping us protect AWS customers!

Best Regards

[Name Redacted]
AWS Security

I held back the support technician’s name because it is not really pertinent to the issue and they were responding in the scripted manner they are instructed to. The response essentially acknowledges the issue but shifts the bulk of the responsibility on the customer.

Impact & Recommendations

The biggest problem resulting from this kind of rampant misconfiguration of AWS servers that comes to mind is that theses are freely available servers to operate as C2’s for malware and phishing campaigns. Amazon leaves the securing of the servers to the consumer/customer, providing little if any basic recommendations.

Companies utilizing cloud services have a responsibility to understand the product they are purchasing and the scope of the security obligation that comes with it. Part of the cost of utilizing AWS must include security personnel and knowledge to maintain the integrity of the service/servers.

Follow me on Twitter ( https://twitter.com/macroform_node ) to see more of the interesting things I find out on the internet.