Self hosted MongoDB breached and encrypted

Ops and Admin
1

I had just launched a new mongodb docker 7.0 on my machine, restored a database, still had no authentication and went to take a nap feeling quite safe since the Debian 11 host has UFW allowing only WWW and SSH (on a non standard port) and therefore 27017 is firewalled.

Waking up had a shock

image_2024-03-10_15-23-07
image_2024-03-10_15-23-072238×896 164 KB

database has been encrypted and left with only one clear document asking for a bitcoin ransom.

hacker was unlucky I guess. stopped the container, erased the bound data directory, spun up a new container, immediately defined an admin and enabled auth.

Can anyone come up with ideas on how could the bastard have achieved this?

Thanks

2

If I recall correctly UFW won’t protect containers. I haven’t looked into this in some time but this article is relatively recent.

1 Like
3

Thanks Chris. Will definitely look into this.

Have been running for months my self hosted MongoDB without problems but just recently switched to a containerized version, so you might have a good clue.

I reinstalled AND activate user auth immedately an so far things look ok.

1 Like
4

FWIW I also activated my provider’s (Hetzner) firewall firewall allowing only WWW and SSH, so if the problem was a Docker/UFW interaction I should be safer.

1 Like
5

I saw the same screen earlier this month! Right after finishing a deployment using community-server and a three member replicaSet. Security was enabled with no external ip access.

Discovered the Hack when data was deleted from the replicaSet. The first measure was to delete and rebuild the vm’s. After rebuilding, connected to the remote database using Compass. Discovered the same screen image and ransom message again.

Accessed local deployment using Compass to export data to seed remote deployment. Surprisingly, found screenshot again, with the same database and collection:
Database - READ__ME_TO_RECOVER_YOUR_DATA.README

“All your data is backed up. You must pay 0.0069 BTC to bc1qa6jtyqf0hwqxtr7z67jzt02zxpkxrn4czhmc63 In 48 hours, your data will be publicly disclosed and deleted. (more information: go to https://is.gd/rudata1)After paying send mail to us: dzen+1y0bln@onionmail.org and we will provide a link for you to download your data. Your DBCODE is: 1Y0BLN”

From what I can find, the hack occurred while uploading data to the replicaSet using a remote connection string via an SSH Tunnel on Compass. It also appears the hackers placed a listener or back door on my computer.

I was able to identify successful, remote connection requests that followed certain patterns. The primary pattern - a listener initiated a remote connection request which became active when I logged out. The remote connection would determine if data had been loaded. If no data was loaded, no actions were taken. If data had been loaded, the collection was dropped.

Primary Issues and Concerns - Could hackers be monitoring and still access my computer? How much access could they have? How could they be prevented, thwarted or stopped? Did I need to rewrite the project so I could use enterprise server now and upgrade the deployment now, or continue the deployment and upgrade in the next development cycle?

Despite the fact I considered myself to be careful and security conscious, its not enough to color within the lines. That means proactively finding ways to limit access, track, monitor and control the events happening on your computer, network and vm’s.

Ultimately, I decided to start fresh. I backed up the important files from my computer, erased and formatted the hard drive, implemented security measures, enabled local firewalls, installed and activated monitoring tools, installed clean dev environments and reinstalled programs. Finally, I restarted the deployment I had been finalizing. In all, I lost 2+ weeks but gained a real appreciation for enhanced security at all phases of development.

Paying the Bitcoin would have been cheaper, but I wouldn’t have learned nearly as much.