In the previous blog in this four-part blog series, we discussed AWS IAM and how it can be compromised to allow for data exfiltration. In this blog we will drill into data exfiltration.
One of the more common issues reported on lately involves EC2 instances running data storage services like Elasticsearch and MongoDB, which by default don't have any credential requirements to interact with the data store. And if you don't get your security groups set up properly you can inadvertently expose, for example, the Elasticsearch port (9200) out to the Internet. If that happens, you can bet that somebody is going to find it and dump its entire data set.
Here’s a common scenario we’ve seen in AWS: A web application is capturing user details and analytics. The developers want to capture that data in a metrics-friendly repository (in addition to the database that the application uses) so they spin an EC2 instance, install Elasticsearch and start dropping data in it that is useful for analytics tracking. It’s probably not sensitive data so they’re not too worried about locking it down and for convenience, the backend Elasticsearch port is exposed to the Internet. As the analytics requirements evolve along with the application, more and more data ends up in the completely exposed data store. Then a bad guy does a port scan and finds it sitting there, ripe for the picking. It's become so common that adversaries have gone through the trouble of creating ransomware that fully hijacks the data store and encrypts the data within it.
Here are some examples:
Data Exfiltration: Risks
- Veeam Server Lapse Leaks Over 440 million Email Addresses - TechCrunch
With a public vulnerability search tool such as Shodan, you can do a search for publicly exposed Elasticsearch databases and it’ll give you a big list. It's not difficult to find systems that have been exposed this way and attackers are finding them pretty quickly.
The other way that data exfiltration takes place is through an application vulnerability, but this isn't AWS-specific. There are common application vulnerabilities that some attackers are very adept at discovering. A crafty attacker will bang on a web application long enough to find a vulnerability that they can use to exfiltrate data from the system. This technique is very effective because most web applications need access to some degree of sensitive data in order to be of any use.
I highlight this because AWS actually has some resources and utilities you can use to try to help prevent this sort of thing, which we’ll get into in another blog, but, before we go there, the next part of this blog series will offer some insights on how to monitor IAM in AWS.