burp_crawl_rce复现-从点击劫持到rce
2023-11-7 23:27:14 Author: 漏洞推送(查看原文) 阅读量:5 收藏

漏洞来源 https://hackerone.com/reports/1274695

漏洞环境

burpSuite 2021.7

https://portswigger-cdn.net/burp/releases/download?product=pro&version=2021.7&type=jar

poc文件见h1链接

漏洞复现

添加一个扫描任务,用于启动burp内置的无头chrome

启动以后用 python3 -m http.server启动一个http服务,然后用chrome打开burp.html

打开以后会尝试 扫描本地的chrome的debug端口

扫描到了以后会创建一个iframe 地址是 http://127.0.0.1:49576/

该页面的内容为,多个A链接:

然后使用点击劫持,当点击CLICK ME以后实际上是点击 http://127.0.0.1:49576/下的 about:blank链接

iframe发生跳转,地址为

https://chrome-devtools-frontend.appspot.com/serve_file/@4bb19460e8d88c3446b360b0df8fd991fee49c0b/inspector.html?ws=127.0.0.1:49576/devtools/page/9D8411A3AA381D422364000736AE56D9&remoteFrontend=true

这个地址中包含最重要的 ws=127.0.0.1:49576/devtools/page/9D8411A3AA381D422364000736AE56D9这个地址可用于chrome调试

那么这个时候,问题就是怎么拿到这个iframe中的地址了,因为这个同源策略,我们在top页面上只能拿到http://127.0.0.1:49576/这个地址,点击a连接跳转以后的https://chrome-devtools-frontend.appspot.com这个地址我们是拿不到的

比如这个页面,我们在127上iframe到另一个域的网站,然后a链接跳转到7k7k,我们通过src拿到的还是127的地址

如果想要拿到真实的src地址,就要同源,我再iframe一个7k7k,在这个iframe下就能拿到真实的src了

于是攻击者利用了appspot.com下的一个dom xss漏洞,新建一个iframe页面,然后把地址通过postmessage发送到top页面,得到了ws地址

https://chrome-devtools-frontend.appspot.com/serve_rev/@191797/devtools.html?remoteFrontendUrl=javascript:top.postMessage(top.frames[1].location.href,"*")

拿到这个地址以后,通过chrome-remote-interface就可以操作浏览器的行为了。配置文件下载路径

然后用blob协议发起文件下载请求,就能够实现任意文件写入了

值得注意的是,这个作者实现mac rce的方式也是很有价值是通过,覆盖burp的vmoptions来实现的

给jvm设置极小的内存,burp会迅速内存耗尽,触发了OnOutOfMemoryError选项导致命令执行。

在这个案例中,一共使用了js扫描探测端口->点击劫持->dom xss->操纵浏览器实现任意文件写入->jvm rce。攻击链相当复杂,虽然实战中可利用可能性不大,但是相当具有参考价值。


文章来源: http://mp.weixin.qq.com/s?__biz=MzU5MTExMjYwMA==&mid=2247485659&idx=1&sn=47f1f78d5d2042482c976f06344733ac&chksm=fe32b82cc945313afe7408468863c49060a7ab45ab75755ebda5ceacbfe90375ec8eba627607&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh