Cloud computing is thriving as firms queue up to drive DevOps-fuelled innovation and greater IT agility. As long ago as 2017 UK cloud adoption hit nearly 90%, and the market for public cloud in Western Europe could hit $43 billion this year. But alongside these gains are the security barriers, and increasingly at the top of this list is the challenge of misconfiguration.
Security researchers have been warning about it for years. But now hackers are automating their efforts to target these mistakes, the quest to mitigate misconfiguration errors has taken on a new urgency.
What’s going on?
Cloud misconfiguration is nothing new. One vendor has documented thousands of organisations over the past four years that have made serious mistakes with their Amazon S3 deployments – exposing sensitive IP and customer data in the process. These include:
- 540 million records left exposed by third-party Facebook app developers
- A huge trove of trade secrets leaked online
- 73GB of internal data from ISP Pocket iNet left publicly exposed, including admin passwords
- 48 million customer records exposed by data aggregator LocalBlox
It’s not just Amazon S3. Similar privacy snafus have been spotted on MongoDB, Elasticsearch and other platforms. The difference now is that attackers are weaponizing these mistakes to further their own ends.
- One of the most common ways to do this is to automatically scan the internet for exposed data stores – something that can be done via a simple Shodan search – copy the data, delete the original and then leave a ransom note. These attacks aren’t particularly new, but recent weeks have seen something of a resurgence in the tactic:
- Choice Hotels: The international hotel chain left an exposed MongoDB instance Hackers left a note demanding a ransom and claiming they had stolen 700,000 customer records including guest names, email addresses and phone numbers
- Libreria Porrua: The popular Mexican bookseller exposed over two million customer records online in a MongoDB database. The public configuration allowed hackers to manage the entire system with full administrative privileges, stealing the data and leaving a ransom note
- Another attack technique exploiting cloud misconfiguration involves the use of notorious digital skimming code known as Magecart. A group using the code to steal card data from organisations’ customers was spotted automating the scanning of exposed S3 buckets containing JavaScript. It then takes advantage of misconfigured write permissions to append malicious Magecart JavaScript to the code. The result could be the compromise of as many as 17,000 domains including some of the world’s top-ranked websites.
Basic errors
Often when news gets out about misconfigured cloud settings the issue has been caused by a third-party provider or contractor. In the case of Choice Hotels, the vendor was working with the data with a view to providing the hospitality giant with a new tool. It should not have even been using live data, and in fact most of the 5.6 million records compromised were not associated with real people.
It goes without saying that organisations need to get better at cracking down on these preventable mistakes. It’s a cast iron certainty that we’ll see an incident like this attract the attention of GDPR regulators pretty soon, if they aren’t already investigating. For any company unsure about the potential impact on their business, BA was fined a record £183m last month for mistakes leading to a breach of customer data by Magecart hackers.
Misconfigurations exposing data also extend beyond cloud platforms like AWS S3. One analysis from last year claimed that SMB (33% of visible files), rsync (28%) and FTP servers (26%) exposed the vast majority of the 1.5 billion sensitive files it found online during one scan. S3 accounted for just 7%.
Impact on regulatory compliance
It’s important to remember that GDPR regulators take into account both an organisation’s operational procedures and its infrastructure best practices. In other words, misconfigurations that result in breaches, regardless of how non-malicious these mistakes may have been, have significant regulatory consequences. Fines can reach 4% of global annual turnover, and regulators have recently shown themselves to be more than willing and able to levy major sums.
Misconfigurations at the IT level can therefore cause an organisation to be deemed non-compliant, so proactively managing them becomes a much more important task.
What to do
Also last year, an analysis by IBM revealed a 424% jump in data leaks stemming from misconfigured cloud systems, accounting for 70% of compromised records. It’s clear that IT leaders must get more proactive about mitigating these risks. Cloud security is a shared responsibility and it’s important to remember that the customer is 100% on the hook for configuring its environment.
A good checklist for starters should include the following:
- Restrict access to cloud administration according to principle of least privilege
- Make use of improvements AWS introduced in November 2018 to reduce the chance of misconfigurations
- Ensure you’re on MongoDB 3.5.7 or later to take advantage of security enhancements that mean all networked connections to the database are denied unless explicitly configured by an administrator
- Use a Cloud Security Posture Management (CSPM) solution (third party solutions are more automated than native solutions) which will continually scan for misconfigurations and remediate them
- Switch on logging to track changes and identify any misconfiguration mistakes
- Apply these policies and processes to third-party suppliers
Cloud security, like protection of on-premises environments, requires a multi-layered approach that goes way beyond the above. But firms failing to prevent basic mistakes like misconfigured accounts are falling at the first hurdle. For hackers looking for the low-hanging fruit, these are a dream come true.
