According to ZDNet, Joomla, an open source content management system for publishing web content, has recently suffered a data breach. The breach occurred due to an unencrypted backup of the JRD portal on a private AWS S3 bucket. The leaked backup file contained details for about 2,700 registered users and includes PII such as full names, addresses, email addresses, phone numbers, IP addresses and hashed passwords. While most of the information was already public, the loss of passwords, regardless of encryption level is still incredibly risky and can lead to a rise in credential stuffing.
This is yet another Amazon S3 bucket incident, which proves again that site owners are clearly not aware of the scale of this vulnerability. Time after time there are incidents where data is lost or compromised – and, when the data is not even encrypted, we are seeing potentially catastrophic outcomes.
S3 is one of the oldest services in AWS, and the good news is that it always defaults to secure and private. However, the bad news is that AWS allows people to use it and notoriously people weaken or even bypass security – sometimes without even being aware that they’re doing so. Cloud misconfiguration can easily occur, so therefore it needs to be double checked by those in charge. If you are concerned, then simply log into the console, click on S3, and look for the ‘Public’ tag to see if any data is vulnerable to theft. AWS has taken measures to better educate its customers about proper S3 bucket configurations, but protection has to be a two way street, where users take on some of the responsibility themselves too.
This incident confirms the findings of the Verizon Data Breach Investigation Report 2020, which highlighted that “misconfiguration” is in the top five action varieties for breaches. It is an important acknowledgement that not all incidents are the result of an exploited vulnerability. Misconfigurations actually lead to more breaches than exploited systems, but organizations often don’t put the same effort into assessing them as they do scanning for vulnerabilities.
Joomla users should reset their credentials immediately. In general, users should be wary of reusing passwords and try to use a password manager so that unique, long, complex passwords can be used for each site that they log into. This will prevent attackers from logging into multiple sites if the user’s credentials are compromised. When possible, ensuring multi-factor authentication is enabled on each of their accounts is also very important.
Unfortunately it seems as though businesses are not learning their lessons, and yet again leaky AWS S3 bucket security is the cause of a data breach. Enterprises must remember that their security is only as strong as their weakest link, and time and time again we are seeing AWS S3 bucket security appearing as that weakest link. It is important to remember that AWS S3 buckets have varying levels of security and it is simply not good enough to trust default settings. When it comes to processing and storing PII, businesses must ensure that information is secured at all stages of its lifetime. This includes backup files! Even if the majority of the information is in the public domain, businesses must ensure total security for any data they hold. Unfortunately, an event like this will cast a very negative light on Joomla for some time, not to mention the regulatory connotations. While there is some uncertainty as to who may have exfiltrated this information – if anyone has at all – any professional that used the Joomla Resources Directory should be sure to change any passwords that may be associated with the site, especially if passwords are reused or repurposed across different platforms.