centos7mysql渗透

一台暴露在公网的CentOS7服务器，MySQL端口3306敞开着。我敲下第一行命令时，心里清楚——这不是什么高深莫测的渗透测试，而是最基础的入口试探。但往往，最基础的才是最致命的。

先用nmap扫了一圈，结果毫无惊喜：3306/tcp open mysql，操作系统CentOS 7，没开防火墙，或者规则形同虚设。我甚至懒得隐藏源IP，直接拿mysql客户端连过去。root账号，空密码？不对，被拒绝了。换root/root，还是不行。试到root/123456，提示Access denied。这管理员还算有点意识，但也就停留在“有点”的程度。

暴力破解不是我的风格，太吵也太慢。我改用CVE-2012-2122的思路——MySQL在特定版本下，只要密码校验函数出错，就能绕过认证。虽然这漏洞老掉牙，但CentOS7默认仓库里的MySQL 5.6.x，如果没打补丁，照样中招。我写了个小脚本，循环发送auth报文，大概循环了三十多次，啪，连上了。就这么简单。

进去以后第一件事看版本，5.6.51，果然没更新。然后是用户表，root的plugin是mysql_native_password，密码哈希是*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9，典型的弱口令SHA1。我没急着破解，先看看库——information_schema、mysql、performance_schema，还有一个叫“webapp”的库，里面躺着用户表，明文密码存储。这管理员把网站后台和数据库放在同一台机器上，连基本的分离都没做。

拿到webapp的用户数据后，我顺手试了试操作系统账号。密码复用是通病，用那个明文密码ssh root@目标IP，竟然直接登进去了。你看，绕了一圈，最后卡在密码复用上。这台CentOS7彻底沦陷，从数据库入口，一路打到了系统shell。整个过程没用到任何0day，全是老套路。

这事让我想起之前帮朋友排查的一台服务器，症状一样，MySQL端口暴露，结果是被爆破后植入了挖矿木马，CPU占用100%。管理员一脸懵，说密码设了12位混合字符啊。我一看日志，人家根本不是爆你的MySQL，是用了CVE-2012-2122直接绕过，连密码都没碰。你设100位密码也没用。

说回这台机器，我留下一个只读账号做记录，然后退出。清理了bash历史，删掉了临时脚本。整个过程不到十五分钟。MySQL默认端口暴露在公网，本身就是一种邀请。CentOS7默认的MySQL配置，bind-address是0.0.0.0，skip-networking默认关闭，只要iptables没拦，谁都能来敲门。

事后我给管理员的建议很简单：别把数据库暴露公网，用iptables限制来源IP；升级MySQL到8.x；密码别复用；web应用和数据库分开部署。他听没听我不知道，但我知道，如果他不改，下一次来的就不是我了。