记一次突破xx公有云白名单限制获取资产

一、前言起因

起因是xx客户攻防演练，小伙伴们打了两三天了说是资产都发现不了，没有任何突破，让帮忙看看。由于客户信息敏感，信息均已打码。 

二、场景分析

首先利用资产测绘平台（fofa、quake、hunter）快速收集资产并进行指纹识别分析。

• 一年前写的工具（最近开源）：https://github.com/guchangan1/SyntaxFinger

• 技术含量不高，就是聚合了三大引擎语法，输个根域名自动通过根域名+证书的语法去查三大引擎，获取资产，然后指纹识别一下。

• 但实际上打点也就这么回事，有day就秒，没day过站。子域名+全端口让平台去扫，本地快速搞站才是正确姿势。

• 注：结果会自动保存空间引擎结果和指纹识别结果。

• 实时结果分析

• 分析结果不容乐观，当前仅有官网和客服系统存活，且均为纯静态页面，无可利用点。

资产测绘的结果进行分析：

• 由于写的工具调资产测绘引擎是拉的近一年的数据，可以发现之前有大量存活网站。但这些IP都是云IP

三、 实战绕过

那也就是一堆云IP、一堆域名，访问都被WAF拦，仅存活的站也都没day，如何打？此时我相信大部分小伙伴也懒得看了，扫扫全端口，没啥发现就出安全报告了。

1. 云WAF白名单机制绕过

• 访问任意目标域名，均被云WAF直接拦截

• 由于大部分页面访问均显示WAF拦截页面，我查阅了该云WAF的官方文档，寻找可能的绕过方法。在与客户沟通时，客户明确表示：系统采用白名单访问控制，每个域名都配置了严格的IP白名单，仅允许特定出口IP访问。

• 基于对云服务架构的理解，我购买了同一云服务提供商的云服务器实例，利用该实例对客户IP进行全端口扫描。出乎意料的是，扫描结果显示大量端口存活，且能够直接访问这些服务，甚至直接访问到了客户的堡垒机系统。通过tracert路由跟踪，发现连接竟然是通过内网IP路由实现的。

• 深入分析发现，云防火墙的白名单IP机制确实限制了来自互联网的访问，但同一云服务提供商的云实例却能够绕过这一限制，直接访问被防火墙保护的资源。

• 这里因为也能访问到其他网站了，打了其他站RCE，然后互联网搞了SSO的管理员密码横向刷完了，后面控机子，没啥技术含量，就不放图了。

技术原理分析：

• 经与客户和云服务提供商共同分析，确认这是云平台底层网络架构隔离不当导致的安全问题。客户的所有业务系统均部署在云平台上，并通过云防火墙配置IP白名单限制访问，但云平台的网络隔离机制存在缺陷，未能有效区分和限制来自同一云平台内部实例的访问请求，导致防护机制被绕过。（该问题已由云服务提供商修复，帮厂商修bug了。。。）

2. 梅开二度之HOST碰撞_负载配置不当导致

在上述问题修复后，我们无法再通过之前的方法访问目标系统。经客户确认，所有业务系统均部署在云负载均衡后端。

分析云负载均衡的工作原理：

• 客户端通过域名访问服务时，DNS服务器解析负载均衡域名，并将负载均衡器的IP地址返回给客户端。

• 负载均衡监听器接收请求后，根据配置的负载均衡算法将请求分发至后端服务器。

• 这一机制类似于Nginx的反向代理功能，负载均衡器被分配公网IP，并通过Web管理界面配置基于域名和路径的请求转发规则。

• 通过这一理解，发现之前收集的IP主要是两个负载均衡IP（一个以81开头，另一个以49开头），大多数域名均解析至这两个IP。

• 当前所有URL资产均解析到81开头的IP，且无法访问。

• 推测若能将请求定向至49开头的IP，可能会有不同结果。

• 直接把之前收集的49开头的URL与域名进行碰撞，发现成功访问到对应资产。

• 通过正确配置HOST，成功访问到目标服务

技术原理分析：

• 客户在云DNS解析系统中将域名解析到81开头的负载均衡IP，并将该域名接入云防火墙进行访问控制。这确实使得通过正常域名解析访问时受到防火墙白名单限制。

• 然而，49开头的负载均衡实例原本用于测试环境，也配置了相同的域名转发规则，但在迁移至生产环境后未被清理，成为了安全防护体系中的"漏网之鱼"。

四、 启发与总结

通过这次突破云服务白名单限制的实战案例，可以得到以下几点重要启发：

1. 云服务安全架构设计的重要性

云服务提供商需要在网络架构设计阶段充分考虑租户间的隔离机制，确保即使在同一物理基础设施上，不同租户的资源也应当在逻辑上完全隔离。本案例中的第一个突破点正是由于云平台底层网络隔离不完善导致的，使得同一云服务提供商的其他实例能够绕过防火墙限制访问受保护资源。

2. 配置管理与变更控制的严格执行

第二个突破点反映了在系统迁移和环境变更过程中，配置管理不严格导致的安全问题。测试环境的配置未被完全清理就投入生产使用，造成了安全防护的缺口。企业应建立严格的配置管理和变更控制流程，确保所有环境变更都经过充分的安全评估和验证。

3. 防御纵深策略的必要性

仅依赖单一安全控制措施（如IP白名单）是不够的。本案例中，即使云防火墙的IP白名单机制运行正常，由于缺乏其他层面的安全控制，攻击者仍能通过多种方式绕过这一限制。企业应采用防御纵深策略，结合网络隔离、访问控制、身份认证、行为监控等多层次安全措施，构建全方位的安全防护体系。

4. 持续的安全评估与验证

安全不是一次性工作，而是需要持续进行的过程。企业应定期进行安全评估和渗透测试，验证现有安全控制措施的有效性，及时发现并修复潜在的安全漏洞。本案例中的问题如果在早期的安全评估中被发现，可能会大大降低安全风险。

5. 云服务商与客户的安全责任共担

云安全是云服务提供商和客户共同的责任。云服务提供商负责基础设施和平台的安全，而客户则需要负责其在云上部署的应用和数据的安全。双方应加强沟通与协作，共同构建安全可靠的云环境。

最后，这个案例也提醒我们，在安全防护中，往往最薄弱的环节不是技术本身，而是技术实施过程中的人为疏忽和流程缺陷。因此，除了技术手段外，建立健全的安全管理制度、提高安全意识、加强人员培训也同样重要。通过技术与管理的有机结合，才能构建真正有效的安全防护体系。

原文始发于微信公众号（L0una）：记一次突破xx公有云白名单限制获取资产