Dealing w/ Gobuster “WildCard” and “Status Code” Errors

本文转自Harley并作补充

Have you ever encountered the following error within Gobuster?

Error: the server returns a status code that matches the provided options for non existing urls. http://ipaddress/9b9353c0-3de2-4df5-abd7-0f618e4d70ab => 200. To force processing of Wildcard responses, specify the ‘–wildcard’ switch

Likely, the webserver you’re attacking is configured to always respond with a 200 response code. For example, let’s look at BART on Hack The Box.

Let’s see if we can extract anything with Curl. We’ll start by sending a request out to the default page. We see that it returns a 302 redirect to forum.bart.htb.

1	curl -vvv 10.10.10.81

Let’s try a request to a page we know doesn’t exist, and we are returned a success 200 message that displays an image. This explains why Gobuster was returning a 200 message on each directory.

We can confirm this by browsing to the page and looking at the image.

Armed with this information, we know that 200 response codes are bad, but other response codes (such as a 302) indicate a directory is present. Let’s rerun our Gobuster command, but we’ll specify which response codes we want returned.

Checking the help page, we can see that Gobuster accepts the following response codes; “200,204,301,302,307,401,403”.

So our command will look like this.

1	gobuster dir -u http://10.10.10.81 -w /usr/share/dirbuster/wordlists/directory-list-lowercase-2.3-medium.txt -s "204,301,302,307,401,403"

And with that command running, we eventually start to get some real results back.

Apache ShenYu Admin 身份验证绕过漏洞（CVE-2021-37580）漏洞复现及POC脚本编写

本文转自rabbitsafe并作补充

Apache ShenYu Admin爆出身份验证绕过漏洞，攻击者可通过该漏洞绕过JSON Web Token (JWT)安全认证，直接进入系统后台。 Apache ShenYu 是应用于所有微服务场景的，可扩展、高性能、响应式的 API 网关解决方案。

Apache ShenYu Admin 存在身份验证绕过漏洞。 ShenyuAdminBootstrap 中 JWT 的错误使用允许攻击者绕过身份验证，攻击者可通过该漏洞直接进入系统后台。

CVE 编号 CVE-2021-37580

影响版本： Apache ShenYu 2.3.0 Apache ShenYu 2.4.0

漏洞复现：

该漏洞主要是接口文件dashboardUser未设置访问权限，攻击者可以直接访问该文件获取管理员帐号和口令

通过FOFA查找使用Apache ShenYu系统

fofa:fid=”uPGDN6V9UWnc+KJdy5wdkQ==”

通过BurpSuite发送数据包，GET /dashboardUser

还需要生成jwt，将生成的jwt数据带入head，发送数据包

通过返回数据包，可获取管理员帐号和口令，登录系统后台。

通过pocsuite3下的POC扫描脚本CVE-2021-37580.py验证漏洞。

脚本研发过程也非常简单，主要是发送GET数据包到/dashboardUser，通过返回数据包进行判断是否存在漏洞。

关键代码贴出来：

generateToken()主要是生成jwt，将生成的jwt数据带入head

check(url)主要是验证漏洞函数

check(url)验证漏洞函数返回2个值，一个是状态，一个是漏洞结果，存在漏洞返回真和漏洞结果。

利用pocsuite3下的POC扫描脚本CVE-2021-37580.py

通过fofaviewer导出fofa结果，保存url到url.txt中，可批量验证漏洞

python3 cli.py -r CVE-2021-37580.py -f url.txt –threads 10

可以发现大量存在漏洞的系统。

POC代码：https://github.com/rabbitsafe/CVE-2021-37580

Mac 解决kill无法强制杀死后台程序的问题

本文转自三也视界并作补充

有些软件卸载之后，后台程序仍然在运行，使用kill都无法关闭

1	ps -ef|grep corplink |grep -v grep

可以看到这个程序，有多个进程互相保护唤醒，无法彻底杀死。可以打开mac自带的活动监视器，搜索并强制退出带有corplink的服务，发现关闭一个又启动了另一个。

尝试 ps -ef | grep 'corplink' | awk '{print $2}' | xargs kill -9 一次性全部杀死

1 2 3 4 5

kill: 6558: Operation not permitted kill: 6586: Operation not permitted kill: 6589: Operation not permitted kill: 6590: Operation not permitted kill: 7500: No such process

发现Operation not permitted，网上搜索了一下，大多数方案都是如下

mac系统下的Rootless机制，让我们在root权限下也不能随心所欲的读写所有路径了，特殊情况下我们需要关闭Rootless时，可尝试如下操作：

1 2 3 4 5 6

1. 重启按住 Command+R，进入恢复模式，打开Terminal。 2. 键入命令 csrutil disable 3. reboot Rootless机制是对抗恶意程序的最后防线，除非特殊需要时我们才将其关闭，否则保持开启状态 csrutil enable

太麻烦了，尝试其他解决办法。加sudo kill应该不会有权限问题

1	ps -ef | grep 'corplink' | awk '{print $2}' | xargs sudo kill -9

虽然杀死了，但是还会重启新的进程，该方法无效，这简直就是流氓软件，病毒式的存在

1	ps -ef|grep corplink

我们发现，该服务的文件都在 /usr/local/corplink/ ，那么强制删除文件试试，记得加sudo，否则会报权限问题

1	sudo rm -rf /usr/local/corplink/

然后打开 mac自带的活动监视器，关闭corplink的进程，发现不会启动了，成功删除