Over the last two years, security researchers have seen servers accessed and data wiped with the attacker sending a ransom note to have the data restored. The most recent victim has been the team behind R6DB, an online service which provides Rainbow Six Siege player statistics. The attack occurred on September 30 in which an automated bot accessed the server, wiped the database, and left a ransom note behind. The database appears to be a PostgreSQL instance. At the time of writing, this article R6DB have recovered most of the data and are currently running updates on the new server.
How the attacker managed to gain access to the server
In this instance, the attacker’s bot gained access to the database as the companies engineers accidentally left remote connections enabled for the database server from the development phase. In a statement released to the public, a spokesperson said “Due to the hectical and unplanned September migration, we didn’t have everything locked down yet, which led to this situation…They left a nice ransom message, but we have no reason to believe that they kept any data. On top of that our backups are useless since they didn’t work on the Postgres codebase yet.” It was also stated by R6DB that the attacker could only access the database but to ensure the new server is secure company engineers decided to wipe and reinstall the entire machine, just to be safe.
Not all data expected to be recoverable
Since the incident company engineers have been working to recover as much data as possible but some data is feared to be lost for good. Players should be aware that the company was not in the practice of storing any personal data, so users of the service can rest easy in that no personal data could have been stolen. What does appear to be lost is all of the historical data pertaining to player statistics which is obviously central to the service offered by the company. R6DB fears some player profiles have also been wiped but profiles can be reindexed at a later stage. It is expected that the restoration process should be finished by Monday 2.
An emerging trend claims another victim
This hack may be the first instance of an attack on a PostgreSQL database but such an attack is by no means unique. Similar attacks emerged towards the end of 2016 when hackers began to scan the Internet for exposed databases, wiping their content, and leaving ransom notes behind in the hopes that victims fall for the trick and pay the ransom without investigating what truly happened to their data. MongoDB, ElasticSearch, Hadoop, CouchDB, Cassandra, and MySQL servers have been targeted.
One of the earliest instances of such an attack occurred on MongoDB’s servers around December 2016. What was interesting in this case was that professional ransomware groups began targeting servers, perhaps seeing how profitable it could be. All in all, was professional groups such as Kraken began exploiting vulnerabilities a total of 28,200 servers had been held ransom. These databases are easy pickings because they've been left exposed to Internet connections with no password on the administrator account.
With such easy pickings, a feeding frenzy appeared to be created with researchers determining at least 12 known ransomware groups were actively targeting unsecured servers. For the Kraken group who had previously created their own ransomware, attacking servers in such a way seemed easier and perhaps more profitable. The Kraken ransomware was never the popular choice when compared to other variants. By attacking unsecured servers the group managed to receive over 70 payments to Bitcoin wallets associated with the group. Using January 2017 Bitcoin exchange rate that amounted to over $6,000 in three days. Researchers believe the group was ill-prepared for the influx of emails and payments from victims as there were reported cases of victims paying the ransom but never receiving their data in return. It is also possible due to the competition amongst rival ransomware groups who actively rewrite each other's ransom notes. This means people might end up paying the ransom to the wrong group, who don't have their data.
MongoDB struck again
At the start of September 2017, MongoDb was again struck by a number of attacks. In this case, new groups began to access unsecured servers and wipe the data. One group was estimated to hijack over 22,000 servers while 26,000 were hijacked in total. In many of the past cases, the servers that were exposed were test systems but some did have production data, data which companies thought valuable enough to pay the ransom. Compared with attacks earlier in the year, the latest batch of server hijackings was fewer in number but researchers believed the hijackings had a greater impact perhaps showing that groups are evolving their attack vectors to become more efficient. The groups could also become better at targeting individuals and companies they believe are more likely to pay out.
In the later batch of server hijackings, security researchers determined that the servers that were targeted were admin accounts with no passwords. The problem can be traced back to MongoDB v2.6.0 came with a default configuration that allowed anyone to access the administrative interface from all network locations, not just localhost. This was further exacerbated by the admin account which did not feature a password. This allowed attackers to connect to databases with the user root and no password. After the September incidents, it was announced by MongoDB that there were plans to beef up the security features. A spokesperson for the company stated “Beginning with development release version 3.5.7, localhost-only binding is implemented directly in the MongoDB server, making it the default behavior for all distributions... This will also be incorporated into our upcoming production-ready 3.6 release.”
One can imagine other companies will also be improving security features on products offered to prevent similar vulnerabilities that could be exploited this way. While the cat and mouse game continues this year has so far some interesting developments in how hackers are looking to extort money from victims.