My blog has been hacked!

If anyone noticed, the blog was inaccessible before 11 am this morning. || Did anyone else notice...? ||

I thought it was a caching issue, so I didn't pay much attention. After a while, I realized that it was still not accessible. So I restarted the server, but the error persisted.

Something must have gone wrong. I logged in to SSH and checked all the services. But they all showed "running normally."

Then, by chance, I opened Navicat and connected to MongoDB. Suddenly, I discovered that all the blog data had been cleared, and there was a READ__ME_TO_RECOVER_YOUR_DATA.README database. Inside the database was a Bitcoin transaction address, which roughly meant that you had to pay to recover the data.

Paying is impossible. Now let me explain the recovery process.

How the hacker connected to the database#

First, I needed to understand how the hacker connected to my database, otherwise the recovered content might still be overwritten.

I remembered that last night, I needed to use Navicat to log in to the database to fix some migration errors. But I usually use MariaDB, so I almost forgot the MongoDB commands.

Therefore, I asked ChatGPT to generate a bunch of commands for me, so that I could log in with a certain account and password. I didn't look closely, but I could log in remotely by pasting them, so I didn't pay much attention.

Thinking about it now, it's likely that those commands were the problem. I checked the content of the commands. I was shocked when I saw it. ChatGPT helped me open remote login permissions and disable the firewall. What's more, after createUser() in the database, it didn't enable authentication!

This means that anyone who gets hold of the source server IP can remotely log in to the database. Fortunately, the site is currently hosted on Cloudflare, so theoretically, the source IP is hidden (in theory. With certain techniques, the source IP can also be found. || As long as you're willing to search, there are free query services online as well ||).

Therefore, it is highly likely that the hacker obtained the source server IP through an automated program brute-forcing.

Checking the deleted content#

Since the hacker claimed to have obtained my data, I needed to check what data the automated program actually obtained and whether it left behind any viruses through vulnerabilities.

Since I personally installed and configured all the software, it was easy for me to access the database logs.

{"t":{"$date":"2024-07-19T03:07:24.728+08:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"37.120.206.51:38104","uuid":{"uuid":{"$uuid":"20875d27-2321-452c-a717-1520dd7816f4"}},"connectionId":43,"connectionCount":27}}

{"t":{"$date":"2024-07-19T03:07:24.729+08:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn43","msg":"client metadata","attr":{"remote":"37.120.206.51:38104","client":"conn43","negotiatedCompressors":[],"doc":{"driver":{"name":"PyMongo","version":"4.6.1"},"os":{"type":"Linux","name":"Linux","architecture":"x86_64","version":"5.4.0-189-generic"},"platform":"CPython 3.8.10.final.0"}}}

Soon, I could see that an IP from Romania was the first to log in to my database. It used Python and brute-forced the source server IP address.

Then I could check the remaining logs and see that it dropped a bunch of tables, created READ__ME_TO_RECOVER_YOUR_DATA.README, and then immediately logged out. The whole process took only 25 seconds.

Next, I could even see logins from other IPs, using the same protocol and almost identical content. After being repeatedly overwritten, at 8 am, the last READ__ME_TO_RECOVER_YOUR_DATA.README was created. These servers were probably all planned by the same hacker.

But I read through the logs one by one, and after the drop operation, it promptly logged out. It seems that it did not insert any new content.

This also proves that the file system and SSH are secure, so the recovery process is quite simple.

Recovering the data#

First, I thought about the opLog, but there was no replication set started, so I skipped this solution.

At this point, I remembered the Alibaba Cloud server that I was preparing to refund. I didn't destroy it last night because it was too late. I logged in remotely and obtained the database content. Unfortunately, the content in the database was somewhat outdated, missing the diary entry from July 18. However, the diary was synchronized to xLog, so it was easy to recover.

https://oimaster.top/notes/7

But being lazy, I thought about whether there were other solutions. Then I suddenly remembered that mx-space has an automatic backup system, which creates a full site backup every day at 1 am. This means that I actually had the data before the hacker accessed it. Through SSH, it was easy to find the backup files (after all, I didn't use Docker or similar technologies, so I knew exactly where all the files were || But if I had used Docker, it wouldn't have been a problem either ||).

Then I uploaded the backup files, and the problem was solved!

Preventing it from happening again#

||First, I will follow up with ChatGPT. It quickly admitted its mistake.|| In the future, when asking ChatGPT for help, I will make sure to check what it has done and review the code.

I have enabled the firewall and disabled external login for MongoDB (since the data has already been migrated). To avoid any negligence on my part, I also blocked all ports except 80 and 22 in the Tencent Cloud panel.

I will continue to enable automatic data backups every day.

That's how the problem was resolved.

If you also have a server...#

If you have a server, please make sure to check the security of your database and SSH, and ensure that authentication is enabled!

Also, do not pay to try to recover your data! Here are the reasons:

It's too expensive, and you can't afford it.
By searching for similar cases, it has been found that after paying, the "hacker" will not actually recover your data but will continue to demand more money until they drain your wallet!
There are multiple login records throughout the night. Even if you pay, what will be recovered is the previous READ__ME_TO_RECOVER_YOUR_DATA.README.
The hacker doesn't actually have your data. Here's the proof:
- According to the logs, the automated program only executed drop and create operations, without copying any of your data.
- I have a large amount of data, and according to the Tencent Cloud panel, the hacker only created a few hundred KB of traffic.
- If the data had been copied before the drop command, it would mean that the hacker had to complete all the copying within 1 second. However, based on the bandwidth of my server, this is impossible.

You should also remember to regularly back up your data. Only those who back up daily can smile and calmly write a blog post documenting the recovery process.

This article is synchronized and updated to xLog by Mix Space.
The original link is https://oimaster.top/posts/soft-engi/recu-data