Joomla, the open-source CMS project has admitted to a breach. The personal details of over 2,700 developers registered on the Joomla Resource Directory (JRD) have been leaked. The cause of the breach is multiple unencrypted full site backups of the JRD site that were stored in a third-party Amazon S3 bucket. The breach was detected due to an internal website audit. Joomla has not indicated how long the data had been exposed.
What data was lost?
The breach report lists the data that was exposed. It points out that much of the data was already public as users provided it so that it could be published in the directory. The exception is passwords that were encrypted. The full list of data lost includes:
- Full name
- Business address
- Business email address
- Business phone number
- Company URL
- Nature of business
- Encrypted password (hashed)
- IP address
- Newsletter subscription preferences
Identity data not lost
The report also deals with the risk of fraud or identity theft, stating it is low. It states: “Data that would be typically used for the purposes of identity theft or fraud such as driver’s license numbers, social security numbers, mother’s maiden name was not included in the database. Usernames and passwords were included in the database, however Joomla has always encrypted passwords and does not hold them as free text. It was therefore considered that the risk for individuals in terms of password recoverability was low.”
How low that risk is, is unclear. If an attacker has a complete copy of the website, they would be able to create a duplicate. It would allow them to send phishing emails to individuals listed in the directory to try and obtain copies of that data.
Joomla shows how audits and transparency are a positive move
Having a breach and warning people is one thing. Publishing the audit report that uncovered the breach along with the actions taken to prevent another breach is exceptional practice. The report on the website states: “Given the overall risk classification legal advice received was that no formal notification was required, however as an Open Source Project and in the spirit of full transparency we have issued this statement and made all those who potentially might have been affected aware.”
This raises the bar for transparency. It demonstrates that the Joomla team is willing to take responsibility and improve its internal processes. It is also a move that many organisations should consider to improve public confidence after a breach occurs.
The breach report also shows that there was a considerable amount of best practice already in place. Take the fraud and identity theft assessment. It states: “Each backup copy included a full copy of the website, including all the data.” What is not in this data, as we now know, is payment and more personal information. That, it appears, is stored in a separate system.
Such an approach makes sense. Public-facing systems are always at risk of a breach and having data stolen. Separating sensitive data and storing that elsewhere makes it harder for an attacker to compromise that data.
Yet another S3 misconfiguration leads to a data breach
Commenting on the news Jake Moore, Cybersecurity Specialist at ESET said: “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 see 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 in to 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.”
It is easy to blame S3 misconfiguration for this breach, but there is another issue here. Why was the backup not encrypted? It is a question that remains unanswered in the breach report.
Enterprise Times: What does this mean
Breaches happen. Anyone who thinks otherwise is living in blissful ignorance. What many organisations fail to do is have a process that can detect a breach and quickly assess the risk. They also fail to be transparent about the cause and impact of any breach.
It is good to see an organisation such as Joomla not only publish the details of the breach but the full audit report. That report contains recommendations that the organisation will act on to improve its processes. In doing this, it demonstrates best practice and how to minimise reputational damage.