A Drafty House: Analysis of the Current Use of AWS EC2 Security Groups

May 29, 2015 | Russ Spitler
X

Get the latest security news in your inbox.

Subscribe via Email

No thanks. Close this now.

Note: The product mentioned in this blog, AlienVault USM for AWS, is no longer being sold. Learn more here.

After a very confusing set of results from a survey we ran and exploring the new world of threat detection and incident response in AWS, we decided to go out and do a little research to see how the world was faring with the new security features in Amazon AWS.

In short, we can safely say there is a good chunk of the EC2 users who left their front door open (actually with this analogy they also left their back door, side window, and garage open). Our analysis showed that users are:

  • Using inherently insecure services such as telnet and ftp
  • Granting public access to backend services such as databases
  • Granting public access to administrative services such as Windows RDP, SSH

This data shows us that users are simply unfamiliar with the proper use of security groups. Let’s take a little closer look at what we found.

Inherently Insecure Services

While not exclusively the fault of security groups, we do include this issue in our analysis. This is because the use of these services is not necessarily insecure in environments with appropriate controls to mitigate the exposure; however these mitigating controls did not take a trip up to the cloud along with the services.

Telnet

Wasn’t telnet outlawed in the 90’s? Well if you don’t know already - don’t use telnet for anything. Not sure what you would need it for, but telnet is present (albeit a very small presence) in AWS.

Linux telnetd
Microsoft Windows XP telnetd
Cisco or Edge-core switch telnetd

VNC

VNC provides remote access to servers, but connects without any encryption. Use of this protocol over a public network is very insecure and can lead to system compromise and data leakage. While not in broad use, there were a number of VNC servers detected in use.

VNC (Unknown)
RealVNC Personal
[email protected] Repeater

FTP

SFTP is a perfectly reasonable protocol for secure data transfer, however using FTP over the internet without the additional layer of encryption is a very poor practice. A number of FTP servers were identified listening for FTP connections.

vsftpd NcFTPd
ProFTPD zFTPServer
FileZilla ftpd Alfresco Document Management System ftpd
Microsoft ftpd BulletProof FTPd
PureFTPd WS FTPd
oftpd BSD ftpd
Pure-FTPd FreeFTPd
OpenBSD ftpd Globus GridFTPd
Gene6 ftpd WU-FTPD or MIT Kerberos ftpd
Serv-U ftpd Xlight ftpd

Public Access to Backend Services

In our traditional environments putting backend services such as memcache, database servers, or windows RPC would take a bit of doing. You would have to punch through a few routers and a firewall and explicitly expose the service. This is unfortunately not the case in Amazon and the failure to understand this is evidenced by the large number of backend services exposed.

SIP Servers

SIP Servers are used to manage and route voice over IP communication. These servers do not require public access and are used by VOIP clients to make outgoing calls. Many SIP servers were found with public accessibility.

Wildfly 8 Cibersys WebRTC Platform v.12.2_TEST001
inets/5.9.6 CommPeak SIP Proxy
PSG 1.0.0.1 Ecrio SIM Server 1.0
PSG 2.1.1584 ICTMOS 1.0-pre
Droplr.APIServer 2.2.7 inets/5.9.2
FlashCom/3.5.4 monocle/0.26
FlashCom/3.5.7 RTC/5.0
Mule EE Core Extensions/3.3.2 TaridiumComms
Asterisk PBX 1.8.24.0 WildFly/8
Asterisk PBX 11.5.1 Wildix GW-3.2.4.26389
Asterisk PBX 11.9.0 Winstone Servlet Engine v0.9.10
Asterisk PBX 12.0.0  

Web Server Utility Services

There are many services we use to optimize the performance of our web servers. These are things like memcache and orchestration protocols like Windows RPC. While the use of these is very important in our world today, there is no reason for these to be accessed by the whole wide world.

F5 BigIP Load Balancer Oracle TNS Listener
Microsoft Distributed Transaction Coordinator Microsoft Windows RPC
Microsoft Terminal Service memcached

Databases

This is probably the most obvious error we can make - there is absolutely no reason for us to have public access to log-in to a database. The only reason you might have a database running on the public internet is if it is a honeypot. Unfortunately, we can say with a pretty strong degree of certainty that the 18,060 people running MySQL are not all running honeypots. The sheer numbers of databases exposed to the internet is really mind-boggling and probably the best and easiest example of how poorly we are leveraging Security Groups.

Microsoft SQL Server 2008 MySQL 5.0
Microsoft SQL Server (Unknown Version) MySQL 5.1
Microsoft SQL Server 2005 MySQL 5.5
Microsoft SQL Server 2000 MySQL 5.6
PostgreSQL DB  

aws database group
Figure 1 Distribution of Microsoft SQL Server Installations

mysql aws groups
Figure 1 Distribution of MySQL Installations

Public Access to Administrative Services

While many of us don’t think twice about exposing services like SSH or Windows RDP to the internet (and perhaps that approach is reasonable) it is not necessary. These services are designed for strong authentication but with security groups it is simple to restrict the access to these services to a small number of IP ranges to reduce the exposure to a brute force attack or a zero-day exploit.

OpenSSH

OpenSSH is a well tested, reasonably secure service, but even so it is simple to constrain and keep up to date. In our analysis we found that not only are these broadly deployed without access restrictions, but also not kept up to date. More than 50% of these installations are not the latest version and given the recent onslaught of vulnerabilities found on OpenSSL (an underlying package) this is a critical opening in your infrastructure.

aws group sql graph
Figure 3 Distribution of OpenSSH Installations

Summary

The issues we have discussed are easily addressed with simple awareness and proper use of security groups. With the implementation of a few best practices and a way to continuously cross-check of your work will make help take the first steps towards a more secure use of EC2. USM for AWS provides the ability to automatically alert on changes to your security groups as well as perform configuration assessment for all instances you have running. This continuous monitoring provides a way to easily ensure you are not making the same mistakes as the people above 😊

Russ Spitler

About the Author: Russ Spitler

Read more posts from Russ Spitler ›

‹ BACK TO ALL BLOGS

Watch a Demo ›
Get Price Free Trial