只用?和/读取/etc/passwdLinux 通配符绕 WAF 的原理与实测最近在研究 WAF 对命令执行类攻击的检测时碰到一个挺有意思的问题。正常情况下如果 Web 应用存在命令执行漏洞我们直接提交/bin/cat /etc/passwd这种请求基本属于重点关注对象。cat、/etc/passwd、/bin/sh、wget、curl这些关键字在很多 WAF、IPS 和安全设备的规则里都很常见。但 Linux Shell 本身还有一套通配符展开机制。也就是说HTTP 请求里看到的字符串和 Shell 最后真正执行的字符串可能并不是一回事。我在本地环境实际跑了一下发现只修改几个字符就能很直观地看到这种差异。一、先看一个普通的 Linux 通配符Linux 下经常会用*和?匹配文件。比如ls*.txt*可以匹配任意数量的字符。而?只匹配一个字符。例如/etc/passw?在正常 Linux 环境中就可能匹配到/etc/passwd命令路径也是一样。例如/bin/ca?可以匹配/bin/cat所以我们直接执行/bin/ca? /etc/passw?Shell 最终处理的实际内容就是/bin/cat /etc/passwd这里并不存在什么特殊漏洞它只是 Bash 很正常的 glob 通配符展开。真正值得关注的是如果前面的安全设备只根据请求中的原始字符做规则匹配这里就会出现检测差异。二、/???/??t到底是什么网上经常能看到这样一种写法/???/??t /???/??ss??第一眼看起来很奇怪。如果只看字符很难马上联想到/bin/cat /etc/passwd但 Linux Shell 并不是把它当普通文本处理。比如/???表示根目录下名字长度为 3 个字符的目录。可能匹配/bin /etc /dev /run后面的/??t则表示长度为 3 个字符并且最后一个字符是t的文件。所以/???/??t理论上就可能匹配/bin/cat /bin/cut /bin/apt ...我直接在当前 Linux 环境里跑了一次。可以看到/???/??t并不会固定只得到/bin/cat在我的测试环境里它同时匹配出了多个文件。这也是我实际测试后觉得比较值得注意的地方。很多文章会直接把/???/??t理解成/bin/cat其实并不准确。Glob 不是编码也不是字符替换。Shell 会根据当前系统真实存在的目录和文件进行匹配。所以系统环境不同最终结果也可能不同。三、换一种更稳定的写法实测为了方便测试我把匹配范围进一步缩小/bin/ca? /etc/passw?然后直接在 Linux 上运行。可以看到/bin/ca?被展开成/bin/cat而/etc/passw?被展开成/etc/passwd最终成功读取/etc/passwd整个过程其实很简单。HTTP 参数中不一定需要完整出现/bin/cat也不一定需要完整出现/etc/passwd但等命令进入 Shell 后这些路径又会通过 glob 自动恢复出来。这里就出现了一个比较典型的问题检测设备看到的是一套字符串Shell 真正执行的是另一套字符串。四、为什么简单的 WAF 规则可能识别不到为了把这个问题看得更清楚我又做了一个很简单的本地测试。假设安全规则只判断输入里有没有/bin/cat和/etc/passwd正常输入/bin/cat /etc/passwd两个关键字都可以直接命中。但是换成/bin/ca? /etc/passw?再做字符串判断时/bin/cat不存在。/etc/passwd也不存在。于是简单的关键字规则就会认为未命中但如果把这段字符串交给 Shell/bin/ca?又会被展开成/bin/cat而/etc/passw?会被展开成/etc/passwd我本地把这个过程单独写了个 Demo。结果很直观[input] /bin/ca? /etc/passw? [check] exact sensitive token matched: False但继续进行 glob[glob] command - [/bin/cat] [glob] target - [/etc/passwd]最后得到root:x:0:0:root:/root:/bin/bash这就是我这次测试真正想说明的东西。单纯依靠关键字识别命令执行实际并没有想象中那么稳。五、放到 Web RCE 场景里是什么效果我们再把它放回 Web 环境。假设 PHP 里存在这么一段代码?phpif(isset($_GET[c])){system($_GET[c]);}这是一个非常典型的命令执行场景。请求?c/bin/cat /etc/passwd进入 WAF 后很容易出现多个明显特征cat /etc/passwd如果规则直接检测敏感文件访问这种请求基本很容易识别。但换成?c/bin/ca? /etc/passw?从 HTTP 参数本身看完整的/bin/cat已经不存在。完整的/etc/passwd也没有出现。请求如果继续进入 PHPsystem()最终交给 Shell 后才开始发生通配符展开。整个链路实际上就是HTTP 请求 ↓ WAF 检测 ↓ Web 应用 ↓ system() ↓ Shell ↓ Glob 展开 ↓ /bin/cat /etc/passwd这里最关键的地方就在于WAF 检测发生在 Glob 展开之前。六、这不是简单的“关键字绕过”刚开始看到这种技巧时很容易理解成把 cat 变一下 把 passwd 变一下 然后绕过去实际跑完以后我觉得这种理解有点浅。真正的问题不是?这个字符本身。问题是不同组件之间对输入的理解并不一致。WAF 看的是/bin/ca? /etc/passw?Shell 看完 Glob 后却是/bin/cat /etc/passwd同一份输入在不同处理阶段出现了完全不同的语义。从这个角度再去看一些常见的 WAF 绕过方式就比较容易理解了。比如URL 编码多次 URL 解码路径规范化大小写转换字符串拼接它们背后的一个共同问题就是安全设备检测时看到的数据和后端真正解释后的数据不一致。七、再看 ModSecurity CRS 的检测思路如果只是几个简单的正则或者关键字规则这种问题比较容易理解。成熟 WAF 的检测当然不会这么简单。比如 ModSecurity 配合 OWASP Core Rule Set会同时检测OS 文件访问命令执行特征、异常字符、协议格式以及其他攻击行为。其中比较典型的一类规则就是OS File Access Attempt比如/etc/passwd就属于非常典型的系统文件访问特征。CRS 里面还有一个很重要的概念Paranoia Level也就是偏执等级。从 PL1 到 PL4检测规则会逐渐增加对输入内容的限制也会越来越严格。简单理解就是PL1更侧重低误报和常见攻击。等级继续提高以后会加入更多异常输入和边界情况的检测。不过这里不能简单理解成PL 越高越好如果业务参数本身比较复杂偏执等级拉得太高误报也会明显增加。所以实际项目里还是要结合接口功能去调。八、写 WAF 规则时我觉得还有一个问题值得注意假设我们写规则出现 /etc/passwd 就拦第一版看起来完全没问题。然后有人输入/etc/passw?规则就可能失效。继续补规则/etc/passw?也加入。攻击输入还可以继续变化。如果一直沿着发现一个 Payload 增加一个关键字这个思路补规则后面会越来越被动。写规则时最好先考虑接口正常情况下应该接收什么。比如一个接口参数user_id正常情况下只应该出现123456那么最有效的限制往往不是分析cat passwd bash wget curl而是直接约束user_id 只能是数字异常字符直接拒绝。这样规则会简单很多。九、从开发角度看WAF 也不应该成为最后一道保险如果后台存在system($_GET[c]);这种逻辑本身就已经非常危险。WAF 能做的是降低利用成功率。但真正解决问题还是要从应用代码入手。能不用system() exec() shell_exec()处理用户输入就尽量不要直接使用。确实存在调用系统命令的业务需求也应该把可执行程序和可接受参数控制住。比如程序固定调用一个工具/usr/bin/xxx用户只能控制其中一个数字参数。这和直接把完整字符串扔给/bin/sh完全不是一个风险等级。十、这次测试我最大的感受一开始我关注的是这串东西/???/??t /???/??ss??看起来确实挺有意思。真正自己把 Glob 展开、文件匹配和字符串检测跑了一遍以后我反而觉得 Payload 本身没有那么重要。因为/???/??t在不同机器上的结果可能完全不一样。真正值得记住的是这条链用户输入 ↓ 安全设备理解 ↓ 应用程序处理 ↓ Shell 解释 ↓ 最终执行结果做 WAF 规则或者分析命令执行类告警时不能只盯着请求里有没有cat passwd bash更重要的是继续往后想一步这串数据到了后面的解释器里最后到底会变成什么。这也是我觉得这类通配符技巧真正有价值的地方。它不只是一个 WAF Payload。更像是在提醒我们安全检测面对的从来不只是字符串还包括字符串进入后端之后产生的真实语义。本文测试仅用于本地安全研究、WAF 规则验证及授权安全测试请勿用于未授权目标。