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.
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.
|Microsoft Windows XP telnetd|
|Cisco or Edge-core switch telnetd|
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.
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.
|FileZilla ftpd||Alfresco Document Management System ftpd|
|Microsoft ftpd||BulletProof FTPd|
|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 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 22.214.171.124||Ecrio SIM Server 1.0|
|PSG 2.1.1584||ICTMOS 1.0-pre|
|Mule EE Core Extensions/3.3.2||TaridiumComms|
|Asterisk PBX 126.96.36.199||WildFly/8|
|Asterisk PBX 11.5.1||Wildix GW-188.8.131.52389|
|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|
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|
Figure 1 Distribution of Microsoft SQL Server Installations
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 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.
Figure 3 Distribution of OpenSSH Installations
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 😊