Unsecured and unencrypted South Korean loyalty platform exposes data of more than 1 million customers

Dodo Point records exposed more than a million customers’ records online. The data was stored in an unencrypted bucket that could be accessed without any kind of authentication.

According to the Website Planet security team, a recent incident affected the Dodo Point loyalty point service platform and resulted in a huge exposure of personal data.

Dodo Point is operated by Yanolja Cloud in South Korea. The service is based on users’ phone numbers. Customers enter their phone numbers in restaurants or stores via a tablet (Figure A) and are then credited with their rewards.

Figure A

An Amazon bucket used by the company was not secured: No authentication protocol had been deployed, and no data encryption had been used on the storage, resulting in the exposure of around 73,000 files, representing over 38GB of data.

Amazon is not responsible for the misconfiguration of Dodo Point’s bucket, as the security of a bucket is the responsibility of the Amazon customer.

SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)

Investigation based on the number of customer records exposed in Excel files and accounting for duplicate entries led the researchers to estimate at least one million customer records were leaked in the breach.

According to the company’s website, huge multinational brands including Nike and Marriott use Dodo Point.

The exposure contains the users’ names, birth dates, gender, phone numbers, email addresses,, stores visited and possibly more (Figure B).

Figure B

Less than 1,000 bank transfer and direct debit details were also found in the database. All of this data could allow anyone to do profiling on the habits of specific users.

Inefficient incident reporting

The researchers who found the breached data first tried to reach Spoqa, a company to which Dodo Point belonged at the time of the data discovery. After receiving no response, they made contact with the Korean Computer Emergency Response Team. Once again, they got no answer. The researchers tried to reach new contacts at Spoqa while also disclosing the incident to Amazon Web Services, neither of which replied.

Finally, Yanolja became the new owner of Dodo Point and could be reached. The company replied promptly to the researchers, and two days later the Amazon bucket was secured.

While the ownership change for Dodo Point likely made things more difficult, computer security incidents should always be handled, no matter the context.

Similar exposures online

The researchers from Website Planet run an extensive web mapping project. As part of this project, they use web scanners to identify unsecured data stores on the Internet before analyzing and reporting these stores to impacted companies to secure them and raise awareness on the dangers of such exposures.

Recently, TechRepublic wrote about thousands of unsecured and exposed Elasticsearch databases being held for ransom.

In 2017, 27,000 MongoDB servers were hit by a similar attack. In 2018, an unsecured database belonging to an e-marketing company exposed 11 million records.

Such exposures are quite frequent, and it is not difficult for an attacker to use online scanning tools to hunt for such databases and discover exposed data that is not encrypted or protected by any authentication process.

These data exposures can lead to the exploitation of personal data for cybercrime: An attacker might impersonate an individual or use their information to target them with specific phishing or social engineering tricks. Some threat actors might also collect information that can be used for cyberespionage purposes.

How to improve incident reporting speed

The case exposed here shows once again that incident handling can only be efficient when researchers are immediately able to reach the appropriate people in a company. With people changing jobs, it might be difficult to reach an individual when needed, but solutions exist.

The use of a dedicated email address for security issues might be the best solution. In April 2022, the Internet Engineering Task Force published its RFC 9116, which entices companies to use a file named security.txt that would be stored in clear text and accessible via the world wide web for anyone at the root of every website, or in a folder named .well-known.

Google, Meta and GitHub already use this file to provide security contacts for any researcher who might want to reach them to report a security issue. The security.txt website offers to help companies generate their security.txt file and provides more information about the project.

How to protect from such a threat

Companies should never expose databases to the Internet if it is not strictly necessary. If it is necessary, secure authentication mechanisms such as multi-factor authentication should be deployed.

Role-based access controls should be set and appropriate privileges assigned to every user. Data stored in such databases should be encrypted so that even if an attacker manages to access data, it may be useless to them.

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.