Tag Archives: MongoDB

Hacker Combines Data Breach With Extortion

Hackers are creative if nothing else.

A hacker going by the name of Harak1r1 is going around looking for unprotected Mongo databases.  Mongo is a database used on many websites.  The only problem is that on some of them, people do not protect the administrator account.

What the hacker is doing is this.  First the hacker finds an unprotected Mongo database.  Next, the hacker makes a backup of the database and uploads it to his own site. Finally, the hacker deletes the database and replaces it with a new database with a message that says if you want to see your data alive, send unmarked bitcoins to this address.

Apparently this has happened to a number of users over the last few weeks.

Interestingly, you would think the ransom would be large, but apparently all the hacker is asking for is 0.2 bitcoin or around $200.

In each case, the database owner has a couple of problems:

  1. Their web site is down.  Minus its database, most websites won’t work.  That could be a business or PR disaster or both.
  2. Their data has been compromised.  Someone else has the data and the owner does not have it.  This is different than the typical ransomware because usually the hacker does not take the data, but rather encrypts it in place.  Depending on the type of data in the database, this could be a reportable breach to authorities and to the public.
  3. Obviously, the database is not secure.  Do you assume that the only thing the attacker touched was the database or do you consider that the entire web site is compromised.
  4. If you assume that the entire web site is compromised, you have to rebuild it from scratch.  Depending on how paranoid you are, you may have to replace the physical hard disks. Down time continues;  potentially for days.
  5. Assuming you have a backup, you can restore the data after you rebuild the entire web site.
  6. If you don’t have a backup, you have to consider whether to pay off the cyber mafia and hope they give you your data back.
  7. How do you stop this from happening again?

There are a couple of take-aways of course.

  1. You should never make a web site publicly visible, even for a little while, until it is fully secured and patched.
  2. Databases should NEVER be directly accessible from the public Internet.  This may require rearchitecting software, but if it is architected in a way that requires direct access from the public Internet, you are, pretty much, asking for a world of trouble.
  3. Backups. Backups and more backups.   Gotta have them; gotta test them.
  4. Monitoring.  How did this hacker delete tables out of a database without you knowing about it.
  5. Disaster recovery and business continuity plan.  If it is not extortion, it will be something else.  Plan for a web site meltdown and have a WELL PRACTICED plan to recover to a different server in a different data center.  My teams used to practice this MONTHLY.  You want to be able to do this in your sleep, because the call will likely come in at 3 AM and you WILL BE sleeping.

Lots of challenges.

OR maybe opportunities.

Take care of this before you become a statistic.

 

Information for this post came from Bleeping Computer.

Breach Exposes 58 Million. Or is it 260 Million?

One more time an open source database, MongoDB, is the source of another huge breach.  But it isn’t Mongo’s fault.  It wasn’t configured correctly.  Human error one more time.

OK, what are the details?  And is it almost 60 million or 260 million?

Modern Business Solutions apparently provides data storage services, although they have refused to comment on the breach.

The names, email addresses, birth dates, vehicle data and other information for at least 58 million subscribers was taken and posted.  The data was removed, reposted, removed again and reposted again.

After the researchers contacted Modern the database was secured.

While the 58 million records were publicly posted, the hacker – or researcher – who originally posted a pointer to the leaked data said there was another table exposed that contained 258 million records.

Since the database has now been secured better, it is not possible to validate that this additional table was exposed.

Interestingly, the leak/breach may have been disclosed accidentally.  The Twitter user who disclosed the leak – or breach – may have done it accidentally by posting a public tweet instead of a private message.

How long was this data exposed?  We don’t know since Modern is not saying.  It could have been hours.  Or it could have been years.

How many people knew about it?  Again, not clear.

What fields were in the bigger table – the one with 260 million records?  Again, we don’t know.

Apparently, whoever’s database it is feels that this doesn’t qualify as a breach that is required to be disclosed.

So what do you do?  Unfortunately, all you can do is keep your antennae up.  Unless the folks at Modern decide that they really do have a breach that they have to disclose.

OR, some state or national law enforcement agency decides that they need to fess up.

Stay tuned.

 

Information for this post came from ARS Technica.

[TAG:BREACH]