A new study from security vendor Threat Stack is set to be presented today at the AWS Summit, revealing a host of common security misconfigurations by users that expose their cloud instances to potential security risks.
Threat Stack analyzed 200 companies that were using AWS to see if there were any potential security concerns — as it turns out there were many. One of the biggest issues is the finding that 73 percent of users were leaving the Secure SHell (SSH) service open to the public internet on their cloud instances. SSH is commonly used to remotely administer a server instance.
“To be clear, this is not a vulnerability in SSH, but instead a poor Security Group (firewall) configuration, ” Sam Bisbee, CTO at Threat Stack, told eWEEK.
A typical SSH installation on any type of server will require some form of authentication. Bisbee explained that the issue his firm found with AWS, is that the Security Group configurations are allowing direct SSH access to any system in the environment from any source on the internet.
“While there are technical methods for running an architecture like this securely, they are generally considered too complex and are often not worth the additional effort or risk,” Bisbee said.
Bisbee added that the exposure of SSH services is risky as it allows for a greater public facing surface area, which can and will be attacked. For example, he noted that if an environment is exposing a thousand systems that each expose SSH, then it’s possible to spread an attack across the entire surface to lessen the chance of detection.
“A thousand hosts that each have one failed login is harder to spot than a thousand failed logins on a single host,” Bisbee said.
Bisbee added that in his experience SSH hosts come under attack rapidly.
“The last time I put SSH on the internet as a test it took less than ten seconds for SSH on the host to come under attack,” Bisbee said.
Another area of security weakness is a lack of multi-factor authentication (MFA) by AWS users. According to Threat Stack’s analysis, 62 percent of organizations are not using some form of MFA to security their AWS cloud instances.
As to why MFA adoption is not high, Bisbee has a few ideas.
“I believe the population of technologists who don’t know about MFA has shrunk dramatically,” Bisbee said. “I think people undervalue the investment and that the incorrect perception is that it’s too difficult.”
Threat Stack also found that not all AWS users were using the AWS CloudTrail auditing and compliance services across all AWS regions. Bisbee said that 27 percent of users didn’t have CloudTrail configured in all AWS regions, which means that they may have set it up in at least one region.
“This behavior is common because users are conditioned to only provision monitoring in regions that they leverage, despite it being free to monitor unused regions,” Bisbee said. “This makes sense for system monitoring (CPUs and hard drives), but not security or compliance monitoring.”
For example, Bisbee said that if an organization only has systems running in Northern Virginia, then they should never have systems in Tokyo and should wake someone up in the middle of the night if this ever changes, since it means they have either been breached or mis-provisioned a resource.
“I personally believe AWS’s strategy of education is starting to show diminishing returns, and that they need to start making small choices on behalf of customers,” Bisbee said.
For example, he suggests that CloudTrail should be enabled in all regions by default and MFA should be mandatory.
“I think the stance that security is available as a feature if users want it doesn’t work anymore, which is one of the reasons there are so many security partners,” Bisbee said. “It would be great though if AWS took care of more of the foundation by default so that we could stop highlighting the same basic misconfigurations and instead focus on the harder problems.”