实战|某次红蓝对抗之Solr-RCE实战绕过

VSole2022-07-26 07:03:15

前言

在某次红蓝对抗过程中。

要结束的时候突然发现了扫描器爆出了

Solr-RCE-CVE-2019-0192漏洞。

但是进行测试过程中,发现存在各种各样的问题

绕过1

进行测试,发现目标只可以执行单命令,返回字段比较少的命令。

whoamiipconfig

执行dir,无法执行。

不出网

想着直接执行ps直接上线就好了,各种尝试之后,后知后觉发现对方不出网

写websgell

发现目标不出网的时候,只有写webshell这一条路子可以走了。

但是目标只能执行个别命令还无法解决。

dir无法执行。陷入了沉思,加入单双引号也不行。

根据以前的内网经验是不是系统无法默认调用到dir.exe。

那么 cmd /c dir是不是可以。

惊奇的发现,可以完美的执行命令。

通过dir,找到目录。进行写马尝试。

但是发现目标路由规则写死了,无法直接访问到.jsp的文件。

刚开始以为是根目录的问题。

发现不止根目录,常用的css/js和img下面的也不行。

后续在webshell中看到,翻文件看到了有类似路由机制的验证

言归正传

在执行rce的时候,找到了solr的目录。发现这里的.jsp是没有这个验证的。

利用命令执行进行找到该位置,进行写文件。

问题来了。echo 写入一直无法写入。。

问题解决

把这里的特殊字符进行特殊字符编码,即可成功写入。

又遇到一个问题。jsp的马子都有%号,这里不论怎么做 %就是写不进去。

差点放弃。找不到不带%的马子。

柳暗花明

但是想到了上午利用过的Certutil可以进行编码解码

这样就没有特殊字符了。

完全没问题。

刚开始一点一点追加,发现下面的会写进去两行

看了一下就最后有一个+号,没有特殊字符。

全部直接写进去。

然后decode进行解码,完美。

访问但是是500.不过确很开心,因为确实写上来。

接下来解决为啥500就可以了。

type 123.jsp

查看一下。

发现最后decode的时候,少了一个>

本地测试,是没有这个问题的。可能是目标一次性字符长度的问题。

这里很简单了。

追加一下就可以了。

连接成功

验证

特殊字符
本作品采用《CC 协议》,转载必须注明作者和本文链接
今天来分享一个绕过过滤比如?等字符的场景,测试环境为 PHP+Mysql假设场景php 代码通过 HTTP GET 参数 param1 接收用户输入的内容,然后经过自定义的过滤函数?过滤可能导致 SQL 注入的特殊字符。在 SQL 查询中,用户数据作为列名插入到查询语句中,比如:$query = mysqli_query;函数来打印错误信息,那么也无法使用报错注入的方式来回显数据。auth,使用 like 子句来查找该表名的第一个字符?
可以使用 '|"|}|) 等特殊字符进行检测,除了正常的参数提交外,注入的位置也可能存在于 HTTP header 中,比如 X-Forwarded-For、User-Agent、Referer、Cookie 中。不同数据库的报错内容:
快速了解 Linux Sudo 高危提权漏洞的研究利用。
CVE-2020-9054是由于可执行文件weblogin.cgi在身份验证期间未正确过滤username参数造成的。
风险描述SQL注入主要发生在应用程序数据库层面上。程序员在设计程序的时候,没有对用户的输入进行校验,含有特殊字符语句会被数据库误认为是正常的SQL指令而运行,从而使数据库受到攻击,可能导致数据被窃取、更改、删除,以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。
避免网站显示SQL错误信息,比如类型错误、字段不匹配等,防止攻击者利用这些错误信息进行一些判断。
SQL注入主要发生在应用程序数据库层面上
0x01 %00绕过WAF输入一个单引号页面报错首先闭合,这里用')闭合keywords=1') %23. order by x 被拦截,用--%0a代替空格即可直接上union select会一直卡着,没有任何返回把空格都改为--%0a,成功响应,在 select 跟 1,2,3... 之间用两个 --%0a 会无响应在 1 后面加上?并 url 编码,原理是 waf 把空字节认为是结束导致了后面的语句可以绕过0x02 Base64绕WAF发现参数为 base64 编码测试字符发现页面报错,使用报错注入来出数据133 and updatexml. 这里可以使用16进制或者科学计数法0x1或1e1keywords=11'and-updatexml
VSole
网络安全专家