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 ignored it. After a while, I realized it was still not accessible. So I restarted the server, but the error persisted.

Something might be 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 last night when 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 the problem lies with those commands. 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 similar free query services online ||).

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

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 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 other IPs logging in, using the same protocol and showing 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 planned by the same hacker.

But I read through the logs one by one, and after the drop operation, it logged out quite efficiently. 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 of 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 for 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 where all the files were || But if I had used Docker, it wouldn't have been so easy ||).

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, I must 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 once a day.

The problem is now 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 whether authentication is enabled!

Also, do not pay to try to recover your data! There are several reasons:

It's too expensive, and you can't afford it.
By searching for similar cases, it was found that after paying, the "hacker" will not restore your data but will continue to demand more money until your wallet is drained!
There are multiple login records overnight. Even if you pay, what will be restored is the previous READ__ME_TO_RECOVER_YOUR_DATA.README.
The hacker doesn't actually have your data. The evidence is as follows:
- 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 my server's bandwidth, this is impossible.

You should also remember to regularly back up. 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