QuickBit exposed 300,000 data records via unsecured MongoDB database
23 July 2019
Swedish cryptocurrency exchange QuickBit has confirmed that around 300,000 personal data records of customers were left exposed on the Internet after an external contractor engaged by the exchange uploaded the data in an unsecured MongoDB database while carrying out a security upgrade.
Earlier this month, security researcher Bob Diachenko and Comparitech discovered an unprotected MongoDB database that was indexed by the Shodan search engine. After analysing the database, the researchers concluded that data stored in it belonged to Swedish cryptocurrency exchange QuickBit.
The researchers counted as many as 301,470 data records stored in the database and these included full names, addresses, email addresses, gender, profile level, dates of birth, details of payment cards used for individual transactions, amount of transactions, and source & target currency.
They also noted that 143 of those records contained user IDs, passwords, and secret phrases and this information could be exploited by malicious actors to gain access to registered accounts with QuickBit. However, the payment card fields in the database only contained the first six and last four digits of credit cards used by customers and therefore, were of no use to malicious actors.
No financial records or cryptocurrency keys compromised, says QuickBit
According to the researchers, QuickBit acted quickly upon being informed about the exposed database and shut it down within 24 hours. On Monday, the cryptocurrency exchange announced the exposure of around 300,000 data records via the unsecured MongoDB database, stating that the exposure occurred after an outside contractor uploaded the data to the database while carrying out a security upgrade.
“QuickBit has recently adopted a third-party system for supplementary security screening of customers. In connection with the delivery of this system, it has been on a server that has been visible outside QuickBit’s firewall for a few days, and thus accessible to the person who has the right tools.
“During the delivery period, a database has been exposed with information about name, address, e-mail address and truncated (not complete) card information for approximately 2% of QuickBit’s customers,” it said.
QuickBit added that the exposure did not impact any passwords, social security numbers, credit card information, cryptocurrency keys or financial transactions.
“QuickBit’s technicians have immediately taken steps to ensure that all servers are protected behind firewalls, and prevent the possibility of similar incidents. We want to emphasize that the data that has been accessed cannot be used to harm either the Company or its customers,” it added.
In the past few months, we have covered dozens of instances of organisations storing vast amounts of customer and enterprise data in MongoDB servers but failing to secure such databases with passwords or failing to secure information stored in such databases with encryption.
MongoDB’s Field Level Encryption to reduce data exposure to third parties
In order to reduce the exposure of data stored in cloud databases, MongoDB introduced Field Level Encryption in June that also eradicated the handling of encryption on the server-side that allowed administrators to access data even if they lacked client access privileges.
Thanks to Field Lever encryption, encryption in MongoDB databases is no being handled from the client-side instead of from the server-side. What this means is that system administrators can no longer access encrypted data stored in operating systems, the database server, logs, and backups without obtaining client access along with the keys necessary to decrypt the data.
Hence, if malicious actors gain administrator privileges to certain public-facing databases, they will not be able to access encrypted data as they will have to acquire explicit client access privileges and encryption keys to read such data.
“Field Level Encryption enables users to have encrypted fields on the server—stored in-memory, in system logs, at-rest and in backups—which are rendered as ciphertext, making them unreadable to any party who does not have client access or the keys necessary to decrypt the data,” the company said.