The Israeli marketing firm revealed 49 million unique email addresses after mishandling the security certificates for the Elasticsearch servers, which found stored in plain text on an insecure web server.
In a vaguely worded statement this week, Straffic, a privately owned digital marketing firm, announced that the event was the result of a “security vulnerability” involving one of its servers.
Data leak is not the whole tale, though, and this incident shows that large networks are still at danger even when accessing them requires authentication.
Leaked data
The straffic team stated that “a private network for connecting elite affiliates with CPA [cost per action] & CPL [cost per lead] offers from trusted advertisers.”
In specific, on Feb 26, 2020, straffic announced that,
“we would like to bring to your attention that we have been reported that a security vulnerability has been found on one of the servers we use to provide our services.”
The asset was a database of Elasticsearch with 140 GB of contact details consisting of names, telephone numbers, and postal addresses. While it was password secured, it seems that the certificate was not correctly stored.
A security researcher using the 0m3n Twitter handle noticed them in plain text on the webserver. A security-focused DevOps developer, 0m3n, decided to check the webserver after obtaining a spam message connection.
0m3n told Jeremy Kirk that they had found a configuration text file (.ENV) that led to an instance of AWS Elasticsearch. The site isn’t running anymore.
A.ENV file is usually used in the Laravel PHP software platform when checking a program. It should not be rendered in the git repo during the initialization process and is applied to the ignore list(.gitignore) for this purpose.
0m3n said that developers might have forgotten to add a.gitignore file and that the configuration file found synchronized to the webserver.
This would make it a case of a “misconfigured webserver” rather than a “security vulnerability.” 0m3n said that multiple free automated checks could be carried out for the automatic deployment of web servers that would eliminate this risk.
Over about six months, 0m3n got and reviewed most of them, about 30 and 50 spam text identical to the one above. However, no other file was a. ENV configuration file available. The above statement may support the theory that the data mistakenly launched.
Troy Hunt said 70 percent of Straffic’s client emails were already present on Have I Been Pwned, the reporting platform he developed for the data breach. It indicates that many of them, he says in a reaction to Under the Breach on Twitter, “did not come from prior breaches.”
49M emails with “just” 70% already being in HIBP means these emails are pretty private and not gathered from public sources, generally speaking, no? @troyhunt
— Under the Breach (@underthebreach) February 27, 2020
Straffic released a notice on the same day to confirm their user saying that
“Although we do our very best to protect the security of our service and deeply regret such a vulnerability has been found on our service, it is impossible to create a totally immune system, and these things can occur”
Indeed, security problems may occur even when the right measures are in place and are more likely to occur while database credentials are floating on the internet, mainly when they are in plain text.
Hunt, who is well acquainted with transparency documents, points out that Straffic’s statement lacks the essential details that should be included in such a letter. Details of the date of the incident are lacking, what caused it, how it was handled, and how the parties involved were told.
