Security researchers at Kromtech recently came across a MongoDB database that contained the personal details of more than 25,000 users who invested in the Bezop (BEZ) token. The database contained plenty of personal details including full names, home addresses, email addresses, encrypted passwords, wallet information, scanned passports, driver’s licenses and in other cases – IDs.
More specifically, the database encompassed personal details on 6,500 ICO investors. The rest of the details belonged to users who took part in the public bounty program for which they received Bezop tokens.
More about the Bezop Platform
The platform’s white paper explains that Bezop is a decentralized peer-to-peer ecommerce order management and processing system, an autonomous buyer-seller protection service, and a simple value added tax (VAT) collection system – all powered by smart contracts and built on a decentralized blockchain network.
Why was this information held in the database in the first place? The abundance of personal details was needed for a bounty program initiated by the Bezop team. The program took place earlier in 2018 when the Bezop platform gave away tokens to users who promoted BEZ on their own social media accounts.
MongoDB Data Incident Officially Confirmed
A company representative has already admitted to this data breach, explaining that the MongoDB database was negligently exposed online in the midst of a DDoS attack its developers were dealing with. The DDoS attack took place on January 8, and it proves how devastating these attacks are to businesses.
Fortunately, no user funds were compromised during this time, and the database has already been secured. Nonetheless, it is still a troubling incident as the database lacked authentication system meaning that anyone connecting to it could access the stored personal details of thousands of users.
This is not the first incident involving MongoGB databases. In January 2017, misconfigured MongoDB databases became targets of ransomware.
Servers running MongoDB were first targeted in December 2016, but the scale of the malicious attempts was small. The situation quickly escalated, because many of the compromised databases hadn’t been set to require a password for access. This lack of authentication once again made remote attacks easy to accomplish.