MySQL Ransomware Attacks: Security Analysis and Hardening Guide

According to recent reports, following MongoDB and Elasticsearch, MySQL has become the next target for ransomware attacks. Starting from February 12th, hundreds of MySQL databases exposed to the public internet have been compromised, with attackers deleting stored data and leaving ransom notes demanding Bitcoin payments.

Problem Analysis

Analysis of the MongoDB, Elasticsearch, and MySQL ransomware incidents reveals that baseline security issues are the root cause of these data hijacking attacks. These services are exposed to the public internet with empty passwords or weak credentials, allowing attackers to easily brute-force access, connect to databases, download and wipe data. Incorrect security group configurations exacerbate the problem.

Similar incidents have occurred multiple times. The Cloud Security Lab has observed an increasing trend of attacks, not just ransomware but also server intrusions leading to data exfiltration. Baseline security issues have become the primary method for server intrusion, apart from web vulnerabilities, especially weak passwords. Misconfigured services exposed to the public internet become targets for hackers, and combined with weak passwords, attackers can easily compromise these services.

Security Self-Check

Given the current situation, it is recommended to self-check servers to prevent data loss:

1. Check open ports and corresponding services on the server. If not necessary, close external access. Use NMap to scan the server's public IP to identify exposed ports and services.

2. Focus on checking configurations for services exposed to the public internet, verifying whether passwords are set and if they are weak passwords.

3. Unless necessary, avoid using root or other high-privilege system accounts to start services.

Security Recommendations and Fix Solutions

1. Use proper security groups or iptables for access control

2. Close external access and modify weak passwords:

MongoDB:

a. Configure authentication (using version 3.2 as example):

1. Start MongoDB with -auth parameter or add auth=true in configuration file

2. When starting MongoDB with auth enabled, if no user exists, MongoDB allows local access to create an administrator user:

1. Switch to admin database;
2. Create administrator user (user and pwd can be customized):
db.createUser({user: "root",pwd: "password",roles: [ "root" ]})
3. After logging in with administrator, create users as needed based on roles

b. Close public access: Configure MongoDB's bind_ip parameter to bind only to internal network IP:

1. Start with bind_ip parameter: mongod --bind_ip 127.0.0.1,10.x.x.x
2. Add to mongodb.conf:
bind_ip = 127.0.0.1,10.x.x.x
Where 10.x.x.x is your server's internal IP.

Redis:

a. Configure authentication:

1. Modify configuration file, add "requirepass password" (usually in /etc/redis.conf)

2. Or use command line: config set requirepass yourPassword

b. Close public access: Configure bind option to limit IPs that can connect to Redis

c. Other: Configure rename-command to rename Redis commands, making it harder for attackers to use config指令

MySQL:

a. Configure authentication: MySQL installation requires password by default. For weak passwords, modify using:

// After logging in as root,
USE mysql;
UPDATE user SET password=PASSWORD('new_password') WHERE user='root';
FLUSH PRIVILEGES;

// After logging in as root,
SET PASSWORD FOR root=PASSWORD('new_password');

mysqladmin -u root -p old_password new_password

b. Close public access:

1. Set bind-address in startup parameters or configuration file to bind internal IP

2. As root, check user table for users with host='%' or non-localhost, modify to localhost or specific IP, or delete unnecessary users

Other Services:

Please refer to the methods above or official documentation for configuration.