前言:在某些场景中不想进行目标的资产测绘只想确定一个URL是否存在某种漏洞,或者已经确定其存在某种漏洞,想进一步利用(反弹shell,代码执行)。本插件就是为了解决这种场景而生——通过直接调用Goby API对指定的URL进行PoC的检测以及EXP的利用。

 

0x001 插件效果

1.1 插件使用

第一次使用需要先生成一个页面去呈现可能扫出的漏洞信息(插件中叫做载体),之后扫描可以选择之前生成过的载体,或者重新生成载体。由于漏洞显示原因,所有生成的载体都会存在一个Git repository found的漏洞。

1.2 一瓢冷水

设想很美好,但是还是有不少缺陷,以上面的GIF为例,首先就是看不到URL检测的进度,其次是还是需要一个Goby的资产测绘页面去呈现漏洞信息,以及大多数PoC的URL path截断问题。最后一个问题直接导致了漏洞检出与否。

以下图的st045 PoC为例

同理执行调用EXP API时也有这种问题。不过听@帅帅的涛哥说后续PoC可能会解决这个问题。

 

0x002 插件开发

2.1 确定PoC检测的API

以下API使用均为臆测和遐想

以下应该是Goby全部的API
assetDetail
assetDetailPage
assetSearch
startScan //  开始检测模块, assetSearchPage
assetTags
check
debugExp //  exp验证模块 debugPoc //  用户POC验证模块 deleteAssets //  删除资产 deleteTask //  删除任务 deleteTaskPage
deleteTasks //  批量删除任务 exportAssets
getChildrenCategory
getComponents
getCrawlerURLs //  获取指定TaskID下的爬取到的url getEnvi //  获取一些配置环境 getHostLists
getIPInfo
getIPInfoPage
getPOCInfo //  获取POC详细详细 getPOCInfoPage
getPOCList //  获取POC列表 getPOCListPage
getPOCs //  获取POC列表 getPocsPage
getProgress
getScanIPObjects
getStatisticsData
getStatisticsDataPage
getTasks
getValueCategory
getVulAnalysis
getVulStatistics
getWebList
getWebListPage
hostSearch
importAssets //  导入任务 ipSegment
listAdapters
listAdaptersPage
listSupport
listSupportPage
live
rescanVulnerability //  poc检测 resumeScan
ruleVuls
setEnvi
stopScan //  停止当前进行的任务 tasks //  获取所有的历史任务 tasksPage
verifyPoc //  验证导入的poc version
vulnerabilitySearch //  可以获取存在漏洞的host信息 vulnerabilitySearchPage
vulnerabilityStatisticsData 

这些API根据名字还是很好猜测其功能,比如getEnvi,就是获取一些系统配置环境。

首先第一步获取PoC的列表,通过/api/v1/getPOCList或者/api/v1/getPocs都可以获得,我们的目的是获取filename。

获取了filename之后就可以进行下一步的操作了。

我们需要的是PoC检测功能,也就是下图红框中的按钮。

抓包发现如下所示,使用了/api/v1/rescanVulnerabilityAPI

大胆猜测与尝试构造如下data后点击发送(只保留options字段也可以正常发包,但是不知道该如何呈现漏洞):

可以看到我们在[]中输入的URL都被检测了,与此同时也产生了上面说过的两个缺陷。

1.好像没有扫描检测进度的API供我们调用。(下图为正常流程下的漏洞检测,猜测是此检测进度条没有API实现)

2.通过API调用实际上是通过goby-cmd检测漏洞,但是没有找到合适的API去单独呈现扫描到的漏洞,/api/v1/rescanVulnerability这个API也和大多数PoC检测一样,分为有回显检测和无回显检测。有回显不用多说,返回包匹配一下字符判断即可,无回显的这里用到了DNSLog的方式去判断,在Goby中有一个godserver就是用来判断这一类无回显的漏洞,以及反弹shell之类的操作,以上面的shiro检测为例,我们解密一下rememberMe可以发现:

所以在进行漏洞检测之后,goby-cmd会通过https://gobygo.net/api/v1/pull?gid=3d358d3a2aaccaf4进行DNSLog的查询,来判断是否存在漏洞,其中gid在Goby启动时就已经生成。

2.2 EXP用到的API

EXP用的到API为/api/v1/debugExp相比上面的PoC检测API,因为不用用到TaskId,感觉上更加独立。如下调用一个st2045的EXP执行命令:

但是这个EXP是有点问题的whoami;echo be4ea51d962be8308a0099ae1eb3ec63,在wins下会报错,再大胆猜测一下,之所以要执行两句是因为想通过匹配这一串md5,来确定命令执行是否成功,如果匹配成功,回包中的output字段就会回显代码执行的结果,如果匹配失败,output将为空。于是发包->拦截->修改->放行,就可以得到上图的结果了:

AttackType除了cmd代码执行外,还有goby_shell_linux的反弹shell的方式,还以045为例:


会发现有一条这个请求https://gobygo.net/api/v1/bind?magic=true&key=84e32117d16abdf8&type=reverse_linux

会去GodServer获取一个监听的端口,获取到端口后,将会对目标发送反弹的EXP,如果成功就会获得一个session

如果反弹成功,/api/v1/debugExp的回包中的output字段就会包含远程会话的地址,同时左