一、前言 在linux内核中，条件竞争一直是一个经久不息的问题，本文就几种简单的条件竞争模式进行探讨，希望能起到抛砖引玉的效果。 二、未加锁 CVE-2016-2546就是一个未正确加锁导致的条件竞争问题，允许多个进程同时对同一共享资源进行访问，未充分考虑加锁导致的条件竞争。 如下是snd_timer相关的文件操作，重点关注snd_timer_user_ioctl函数。 static const struct file_operations snd_timer_f_ops = { .owner = THIS_MODULE, .read = snd_timer_user_read, .open = snd_timer_user_open, .release = snd_timer_user_release, .llseek = no_llseek, .poll = snd_timer_user_poll, .unlocked_ioctl = snd_timer_user_ioctl, .compat_ioctl = snd_timer_user_ioctl_compat, .fasync = snd_timer_user_fasync, }; static long snd_timer_user_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct snd_timer_user *tu; void __user *argp = (void __user *)arg; int __user *p = argp; tu = file->private_data; switch (cmd) { case SNDRV_TIMER_IOCTL_PVERSION: return put_user(SNDRV_TIMER_VERSION, p) ?...

一、前言 WebAssembly（简称wasm）是一种可移植、体积小、加载快并且能够在浏览器上运行的一种程序文件。其能够在JavaScript通过接口进行调用执行。开发者们一直都比较关心JS的运行速度问题，V8引擎在JS的运行速度方面做了巨大的优化，但是少数情况下我们进行大量本地运算的时候，仍然可能遇到性能瓶颈，这个时候webassembly的作用就凸现出来了。例如AutoCAD利用编译器将其沉淀了30多年的代码直接编译成WebAssembly，同时性能基于之前的普通Web应用得到了很大的提升。 C/C++/Rust源代码可以被编译为WebAssembly文件，然后JS层就可以对其进行调用。WebAssembly文件中存储着字节码，位于JavaScript引擎中的WebAssembly虚拟机将会执行字节码。字节码的执行有两种方式，一种是在运行时边读取opcode边执行，另一种则是在执行前将整个WebAssembly JIT翻译为本地汇编代码，然后直接跳转到汇编代码执行。V8采用的是第二种方式。 二、WebAssembly虚拟机 WebAssembly虚拟机是一种栈虚拟机，变量使用栈进行传递。WebAssembly虚拟机有两个栈，即数据栈和指令栈。 WebAssembly的数据栈只用于存储数据，不会存储任何指针；指令栈只用于存储指令和数据在数据栈中的下标，不会存储任何数据，并且在执行opcode时会对取出的下标进行边界检查。由于WebAssembly将数据和程序流用栈给分隔开了，也就不会发生像汇编代码中的栈溢出劫持返回地址的漏洞利用手法。简而言之，WebAssembly中的所有指令都无法操作指针，也就不存在任意地址读写。但是传统的漏洞仍然存在，只是不能直接劫持程序流了。 三、WebAssembly文件格式 编译代码 emcc hello.c -s WASM=1 -o hello.html #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char buf[100]; memset(buf,0,100); scanf("%s",buf); printf("hello world: %s\n",buf); return 0; } 将得到的hello.wasm使用wabt项目中的wasm2wat转为S表达式 ./wasm2wat hello.wasm > hello.wat S-表达式是一个非常简单的用来表示树的文本格式，跟wasm二进制文件是简单的对应关系。 (module (type (;0;) (func (param i32) (result i32))) (import "wasi_snapshot_preview1" "fd_write" (func (;0;) (type 9))) (func (;0;) (type 8) i32.const 1 i32.const 2 i32.add .... ) (table (;0;) 9 9 funcref) (memory (;0;) 256 256) (global (;0;) (mut i32) (i32....

一、Terrapin Attack 背景探讨 这个漏洞是由这边的几个安全研究员提出的漏洞 ，本文也是对这里的论文进行的一个解读。这个漏洞是一个基于MITM（Man-in-the-Middle 中间人，下文简称MITM）的攻击，这意味着，这个漏洞攻击的场景如下： +----------+ +----------+ +----------+ | <------+ <---------+ | | Alice | | Evil | | Bob | | | | | | | | | | | | | | +----->| +---------> | +----------+ +----------+ +----------+ 这个漏洞是针对SSH的通信完整性发起的攻击，并且攻击者不具备对于会话相关密钥信息的知识，包含但不限于： 加密内容的密钥 MAC使用的nonce IV 所以这个问题不是一个简单的内存泄露或者逻辑漏洞，而是一种突破完整性的攻击。该攻击的意义在于降低了SSH的防护措施，突破了SSH的通信完整性，从而使得早先出现过的攻击能够重新被利用。 1.1 通信完整性定义 When a secure channel between A and B is used, the data stream received by B should be identical to the one sent by A and vice versa...

一、前言 近期在工作中遇到了一些使用php开发的应用，而这些应用都使用了不同的源码保护方案对自身代码进行了加密处理，某些应用的加密强度甚至比较高，导致工作还没开始可能就得宣告结束。 为了解决遇到的这个问题，针对市面上一些常见的保护方案进行了研究，并且成功将这些较为常见的保护完成了代码还原，接下来将对这几种常见的保护与还原方法进行介绍。 二、无扩展加密 这种程度的加密，只是对代码本身做了压缩与编码，处理完之后本身就是一个正常可运行的文件，依托于php的变量与函数可以使用绝大部分字符（除了一些特字符），导致这种方式处理之后的文件内容几乎全是不可见字符，只有零星一些明显被编码后的字符串以及极个别函数符号可见。 由于加密强度不高，所以我们可以通过强行阅读处理后的文件来还原出解码方式从而获取原始代码，下面使用两种市面上常用的加密来做例子演示如何进行逆向还原。 2.1 phpjm.net 工具地址：http://www.phpjm.net/ 使用这种方式处理后的文件，只能运行在 php < 7的版本上，而且处理后的文件代码量较少，我们甚至可以直接通过手工的方式来对其进行还原，下面是一段代码被处理之后的情况： 可以看到基本上全是不可见字符+编码后的字符串，其中可以注意到有一个明文可见的符号 base64_decode，所以也能确定那一堆可见字符就是一堆base64编码（低版本php在遇到非码表内的字符会进行忽略从而完成正常解析，而高版本php>=7会抛出异常，这也就是为什么这种处理后的代码只能跑在低版本php上），那么直接对代码进行一下格式化，然后尝试对其还原，格式化后的代码如下所示： <?php /* ������������Ϣ�����DZ�php�ļ������ߣ����Ա��ļ�����������Ϣֻ���ṩ�˶Ա�php�ļ����ܡ������Ҫ��PHP�ļ����м��ܣ��밴������Ϣ��ϵ�� Warning: do not modify this file, otherwise may cause the program to run. QQ: 1833596 Website: http://www.phpjm.net/ Copyright (c) 2012-2024 phpjm.net All Rights Reserved. */ if (!defined("EBCCDDCDEF")) { define("EBCCDDCDEF", __FILE__); global $�,$��,$���,$����,$����,$������,$�������,$��������,$���������,$����������,$�����������,$�����������,$�������������,$��������������,$���������������,$���������������; function ��($��,$���="") { global $�,$��,$���,$����,$����,$������,$�������,$��������,$���������,$����������,$�����������,$�����������,$�������������,$��������������,$���������������,$���������������; if(empty($���)) { return base64_decode($��); } else { return ��($�����������($��,$���,$���($���))); } } $���=��("c3RycmV2�"); $�����������=��("c3RydHI=�"); $����=��("LXLhbA==�","ZpomPWJL"); $����=��("A3p1bmNvbXByAXNz�","ZTQA"); $������=��("nmFzZTn0X2R�ln29kZQ==�","YhJpAn"); $����������=��("SHJlZ19yZXBsYWNl�","chtS"); $���������������=��("ZzdlNWM5Yjd�iMDRhNjLlNT�JhMDm0LGVkM�zlhMjM5YjYz�Z2U=�","LomFgvZ"); function ����(&$����) { global $�,$��,$���,$����,$����,$������,$�������,$��������,$���������,$����������,$�����������,$�����������,$�������������,$��������������,$���������������,$���������������; $����������������=��("Okll�","ZGfMkO"); @$����������($���������������,$����....

一、前言 在漏洞挖掘工作中，攻击面的选择往往是一个非常重要的环节，一些意想不到的攻击面中往往存在大量开发测试人员疏忽的点。本文就关于一种有趣的攻击面进行探讨，将其起名为SaC（Server as Client）。 二、Client Server 架构 在带有网络通信的传统软件开发过程中，往往会使用一种叫做CS（Client Server）的架构，这个架构模型大致上是由提供服务的服务端（Server）以及请求服务资源的客户端（Client）组成。 2.1 CS架构的特征 服务端通常来说，具有如下的特点： 具有高权限。为了方便的进行资源调度，权限控制等任务，大多数的服务端程序会以相当高的权限运行在机器上。 可能为分布式。服务端为了减轻请求处理的压力，有时候会将服务以微服务部署在多个服务器上，或者在多个机器上部署的同时，使用调度工具对请求进行调度。 持续监听，对请求反馈。服务端大多数为持续监听一个固定的对象，比如固定的某些端口，从而保证能够随时处理来自客户端的请求。 对请求进行校验，防护完善。由于要对请求进行鉴权，所以有着更加严格的访问控制；同时由于服务端存放大量资源，一般会有非常严格的检查 而相对于服务端，客户端往往具有如下的特点： 不一定为高权限进程。由于客户端往往只是请求某些资源，这个过程大多数情况下无需高权限访问。 每次访问只维护单个会话。客户端的每次资源请求大多数只建立一次会话，不存在同时发起多个会话的情况。 通常请求单个服务端资源。虽然客户端可能会请求多种不同类型的资源，但是每次请求基本上都有某一个固定的服务端进行响应处理。 防护相对不到位。由于客户端本质上运行在客户机器上，加之运行权限不高，一般不会有特别复杂的防护机制 Server Client 权限通常较高 权限通常不高 可能为分布式 单个端点请求资源 持续性监听 单个会话访问 安全校验严格 防护较为松散 而这类架构往往又具有如下的特点： 双方在同一网络内 请求由客户端发起，服务器端进行接受 服务端具有大量的防护机制，包括但不限于 权限控制 数据安全边界检查 软件本身代码安全标准高 三、漏洞模型分析 对于攻击者而言，大多数情况下服务端的资源为攻击目标，因此大部分的时候攻击都针对服务端发起，服务端也就在攻防对抗中逐渐加固；而客户端由于价值低，通常缺乏这类攻防事件，相对来说受到的攻击较少。那么，此时只要创建出一个场景，让服务端变为客户端，则此时服务端中存在的客户端的攻击面就会暴露出来，从而造成大量危害。 3.1 Server as Client 大多数情况下，服务端程序并不会仅仅作为提供资源的一方存在。在现代模型中，单个服务器能够完成的功能有限，在特定的情境下，服务端也会作为客户端向其他的服务端进行资源请求，例如如下的场景： 访问不存在本服务器的资源 远程路径访问 RPC调用 代理访问 当服务端A去向服务端B发起请求的时候，此时的服务端A本质上是作为客户端存在的，此时的服务端身份就转换成了客户端。而客户端往往是防护较为薄弱的一环，服务端上的客户端部分也是如此。 这类攻击往往需要构造如下的场景： 攻击者需要具有两台机器，一台攻击机（Hacker），以及受控的另一台伪造服务端（Fake Server）； 某些场景下，受控的伪造服务端要和受害主机（Victim Server）在同一个内网中。 此时，可以通过在Fake Server 上构造畸形的数据包，从而实现对受害主机的攻击。 四、实例：CVE-2021-43893 漏洞CVE-2021-43893为 Windows 上的EFSRPC服务，主要用于提供在远程服务器上进行数据的加解密。微软在修复漏洞的时候，存在疏忽，导致这个漏洞的生命周期中经历了如下两个阶段： （漏洞一）最初漏洞本身通过直接窃取Net-NTML，从而实现NTML-Relay。 （漏洞二）微软对其进行了简单的修复后，并未完全封堵，导致该漏洞可变形为未授权用户往Windows Server上传任意文件。 接下来会对两种漏洞的成因以及利用进行分析。 4.1 漏洞一成因 首先检查函数原型: long EfsRpcOpenFileRaw( [in] handle_t binding_h, [out] PEXIMPORT_CONTEXT_HANDLE* hContext, [in, string] wchar_t* FileName, [in] long Flags ); 该函数的作用为一个RPC接口，用于打开位于RPC服务端的一个文件。这里的FileName根据MSDN的定义，可以支持UncPath。...

一、前言 Linksys E8450是销量较高的一款多功能路由器。本文会讲解下该目标的攻击面选取策略，以及如何结合逆向分析和破壳平台，对目标进行漏洞发现。最终提交至CNVD漏洞平台，并获得12个漏洞编号。 固件下载 https://www.linksys.com/us/support-article?articleNum=317332 版本：Ver. 1.2.00.273012 二、攻击面分析 2.1 固件解压 最新版本固件进行了加密，通过分析Ver. 1.1.01.272918 (Unsigned)固件中的升级流程，在其upgrade.cgi文件中可以得知固件解密流程如下： 在arm架构设备中，chroot到其根目录后，如上执行gpg命令，可以得到最新版固件解密后的版本，名为raw.bin。 2.2 分析目标选择 解压后直接进入_raw.bin.extracted/squashfs-root-0/etc目录查看其可能使用的web服务器，发现了lighttpd文件夹，由此可以判断系统使用的web服务器是lighttpd。 一般来说直接分析开源的web服务器如lighttpd不是我们的首要选择，我们更关心Linksys自定义的一些功能。比如cgi程序（公共网关接口，是外部扩展应用程序与Web 服务器交互的一个标准接口）。 从下图大致就是cgi与web服务的关系，并且对于cgi程序环境变量及标准输入 是用户的输入。 根据lighttpd配置文件可知服务器的文件目录在www目录下 server.modules = ( ) server.document-root = "/www" server.upload-dirs = ( "/tmp" ) server.errorlog = "/var/log/lighttpd/error.log" server.pid-file = "/var/run/lighttpd.pid" 由下面的文件可知.cgi文件会被直接访问解析 server.modules += ( "mod_cgi" ) ## ## Plain old CGI handling ## ## For PHP don't forget to set cgi.fix_pathinfo = 1 in the php.ini. ## cgi.assign = ( "....

一、前言 关于SLP几个漏洞的成因与利用，网上已经有彭博士非常精彩且详细的分享（vSphere 攻防技法分享），这里不会做过多的赘述，写这个的意义只是记录一下针对特定低版本ESXi场景下32位SLP的利用心路。网上的一些公开利用，在低版本情况下皆无法成功。 安全研究人员在对某个目标进行研究时，经常会遇到一个场景，研究人员在一个正在开发的功能中发现漏洞，但因此功能未完善，无法进一步利用的遗憾。 笔者遇到的正是类似于此类场景，不过不是正在开发的功能场景，而是一个漏洞的触发路径上存在另一个漏洞，两个漏洞的相互影响下，导致利用无法完成的悲伤。 二、SLP历史漏洞 以下是SLP的历年漏洞 CVE编号 漏洞类型 CVE-2019-5544 堆溢出 CVE-2020-3992 UAF CVE-2021-21974 堆溢出 CVE-2022-31699 堆溢出 三、CVE-2021-21974漏洞利用 笔者最初选择的是CVE-2021-21974。 该漏洞存在于SLP的“目录代理通告”，目录代理 (DA) 是可选的 SLP 代理，用于存储和维护服务代理 (SA) 发送的服务广告的缓存。 在SLPParseSrvUrl函数中，会解析“目录代理通告”中的URL字段，如下面代码所示 /* allocate space for structure + srvurl + longest net family tag */ *parsedurl = (SLPParsedSrvUrl *)xmalloc(sizeof(SLPParsedSrvUrl) + SLP_NF_MAX_SIZE /* long enough for longest net family */ + srvurllen + 1); /* +1 for null-terminator */ if (*parsedurl == 0) return ENOMEM; /* point to family tag buffer, copy url to buffer space */ (*parsedurl)->family = (char *)*parsedurl + sizeof(SLPParsedSrvUrl); slider1 = slider2 = (*parsedurl)->family + SLP_NF_MAX_SIZE; memcpy(slider1, srvurl, srvurllen); /* find end and terminate url copy */ endptr = slider1 + srvurllen; *endptr = 0; /* parse out the service type */ (*parsedurl)->srvtype = slider1; slider2 = strstr(slider1, "://"); if (slider2 == 0) { xfree(*parsedurl); *parsedurl = 0; return EINVAL; /* ill-formatted URL - missing "://" */ } 问题出现在 slider2 = strstr(slider1, "://")...

一、前言 近些年，各个厂商常常举办WebShell绕过挑战赛，用以检测其WebShell检测引擎的稳定性与检出能力。结合一些比赛我的参赛经历以及之前对公司终端产品的WebShell检测引擎的攻防对抗经历，聊一聊WebShell检测的绕过思路。 二、引擎行为 在思考如何绕过前，首先需要明确的是，检测引擎究竟会拦截什么行为。一个WebShell检测引擎，往往会结合多种检测方法进行检测，因此我们需要拆分检测方法，再基于每个引擎的拦截方法思考对应的绕过策略，最后将各引擎的绕过方法进行整合，从而实现完整的绕过。对于拦截的内容，由于引擎对于我们来说是黑盒，因此只能通过反复测试的方法去确认引擎的拦截方式。 根据测试可以发现，检测引擎常常会使用以下几类方法进行行为检测。 静态检测。这里主要指的是源码规则的静态匹配手段，通过对已知的WebShell特征和模式（比如特定的字符串或者代码结构），例如Runtime.getRuntime().exec()、ProcessBuilder().start()等进行匹配，从而达到检测的目的。这种方法的优点是检测速度快，实现成本低，但是缺点是极其依赖文本特征的提取，容易误报也容易被绕过。 动态沙箱。将样本放在模拟的环境中执行，模拟攻击者的输入，通过hook危险函数进行检测。这种方法优点是不强依赖知识和规则，可以检测出一些未知的WebShell样本，但最大的缺点是它无法准确模拟出攻击者的外部输入，从而导致模拟执行的输入和真实攻击的输入不同，代码走向不同，形成绕过。 模拟污点执行。将样本进行词法和语法分析形成AST，通过对用户可控的数据标记为污点Source，结合对节点进行静态的遍历分析以及动态的模拟执行代码，判断污点是否可以传递到危险函数Sink，从而进行WebShell的检测。这种方法的优点是可以结合了静态和动态的分析技术，误报率相对较低，但缺点是实现相对复杂，污点传播可能由于编程语言的trick、特性等问题导致规则覆盖不全，形成绕过。 三、绕过方法 （一）静态检测绕过 针对引擎的静态检测，应对方法就是尽量去寻找一些不常见的命令/代码执行方法，这些方法最终调用了了危险的代码执行/命令执行sink，如果这些方法没有在目标引擎的匹配规则里，就可以实现绕过。在Java中最常见的命令执行方法是如下两种： Runtime.getRuntime().exec() new ProcessBuilder().start() 在Tabby中分别查找JDK11中调用了这两个方法的方法： 可以发现链不是很多，逐一手动分析。由于反射的代码特征相对明显，因此尽量减少对非公共方法或者类的依赖。整理各个关键类的特性如下 com.sun.tools.jdi.AbstractLauncher 的两个实现类：公共类，执行命令的方法为公共方法 sun.security.krb5.internal.ccache.FileCredentialsCache$2：内部匿名类，无公共调用方法 sun.net.www.MimeLauncher： 非公共类 jdk.internal 内的多个类：属于jdk.internal模块，Tomcat的WebShell默认情况下访问不到该模块，需要使用反射等方法进行类加载，动静比较大。如果目标引擎不会拦截反射可以考虑使用 com.sun.tools.jdi.AbstractLauncher的两个实现类无疑是最符合要求的。两个类差不多，这里以com.sun.tools.jdi.SunCommandLineLauncher举例分析。其存在一个public的launch方法，通过对参数的一系列赋值，对传入的命令进行字符串拼接，调用其父类的launch方法。 public VirtualMachine launch(Map<String, ? extends Connector.Argument> arguments) throws IOException, IllegalConnectorArgumentsException, VMStartException { VirtualMachine vm; String home = argument(ARG_HOME, arguments).value(); String exe = argument(ARG_VM_EXEC, arguments).value(); ... try { if (home.length() > 0) { exePath = home + File.separator + "bin" + File.separator + exe; } else { exePath = exe; } ....

0x00 前言 自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地试错，不断地思考，于是才有了现代伟大的科技时代。 在安全领域里，每个安全研究人员在研究的过程中，也同样的不断地探索着如何能够自动化的解决各个领域的安全问题。其中自动化代码审计就是安全自动化绕不过去的坎。 而SAST作为自动化代码分析的一种，有着其特有的定位以及作用，这篇文章我们就来聊聊静态分析的一些发展历程和思路。 :::info SAST是什么？ ChatGPT：SAST是Static Application Security Testing（静态应用程序安全测试）的缩写。它是一种用于检测软件应用程序中潜在安全漏洞和代码缺陷的自动化安全测试方法。 ::: 0x01 静态代码分析工具 静态代码分析我们可以理解为在不执行代码的情况下，通过静态的手段进行分析代码，并挖掘相应的漏洞/Bug. 再过去的十几年里，静态代码分析工具经历了长期的发展与演变过程，下面我们就一起回顾一下（下面的每个时期主要代表的相对的发展期，并不是比较绝对的诞生前后）： 上古时期 - 关键字匹配 如果我问你“如果让你设计一个自动化代码审计工具，你会怎么设计？”，我相信，你一定会回答我，可以尝试通过匹配关键字。紧接着你也会迅速意识到通过关键字匹配的问题。 这里我们拿PHP做个简单的例子。 虽然我们匹配到了这个简单的漏洞，但是很快发现，事情并没有那么简单。 也许你说你可以通过简单的关键字重新匹配到这个问题 \beval\(\$ 但是可惜的是，作为安全研究员，你永远没办法知道开发人员是怎么写代码的。于是选择用关键字匹配的你面临着两种选择： 高覆盖性 – 宁错杀不放过 这类工具最经典的就是Seay，通过简单的关键字来匹配经可能多的目标，之后使用者可以通过人工审计的方式进一步确认。 \beval\b\( 高可用性 – 宁放过不错杀 这类工具最经典的是Rips免费版 \beval\b\(\$_(GET|POST) 用更多的正则来约束，用更多的规则来覆盖多种情况。这也是早期静态自动化代码审计工具普遍的实现方法。 但问题显而易见，高覆盖性和高可用性是这种实现方法永远无法解决的硬伤，不但维护成本巨大，而且误报率和漏报率也是居高不下。所以被时代所淘汰也是历史的必然。 近代时期 - 基于AST的代码分析 有人忽略问题，也有人解决问题。关键字匹配最大的问题是在于你永远没办法保证开发人员的习惯，你也就没办法通过任何制式的匹配来确认漏洞，那么基于AST的代码分析方式就诞生了，开发人员是不同的，但编译器是相同的。 在分享这种原理之前，我们首先可以复习一下编译原理。拿PHP代码举例子： 随着PHP7的诞生，AST也作为PHP解释执行的中间层出现在了编译过程的一环。 通过词法分析和语法分析，我们可以将任意一份代码转化为AST语法树。PHP常见的语义分析库可以参考： PHP-Parser phply 当我们得到了一份AST语法树之后，我们就解决了前面提到的关键字匹配最大的问题，至少我们现在对于不同的代码，都有了统一的AST语法树。如何对AST语法树做分析也就成了这类工具最大的问题。 在理解如何分析AST语法树之前，我们首先要明白infomation flow、source、sink三个概念， source： 我们可以简单的称之为输入，也就是infomation flow的起点 sink： 我们可以称之为输出，也就是infomation flow的终点 infomation flow，则是指数据流动的过程。 把这个概念放在PHP代码审计过程中，Source就是指用户可控的输入，比如$_GET、$_POST等，而Sink就是指我们要找到的敏感函数，比如echo、eval，如果某一个Source到Sink存在一个完整的流，那么我们就可以认为存在一个可控的漏洞，这也就是基于infomation flow的代码审计原理。 在明白了基础原理的基础上，我举几个简单的例子： <?php $a = $_GET[‘a’]; eval($a); 这段代码对应的AST为： Assignment(Variable('$a'),ArrayOffset(Variable('$_GET'), 'a'), False) Eval(Variable('$a')) 1、Eval函数...

一、前言 在做某些服务器设备漏洞挖掘时，负责管理服务器的BMC模块是重要的一环。BMC系统被攻破，可能导致服务器主机穿透沦陷。本文将重点分析BMC相关历史漏洞。 二、BMC介绍 BMC（Baseboard Management Controller）为主板管理控制器。它是一种硬件设备或嵌入式系统，通常位于计算机主板上，用于监控、管理和维护计算机系统的硬件和软件。他本质上使用传感器来与设备进行通信，允许对被控机器进行完全控制（例如KVM）。这样可以通过远程访问BMC，然后重新配置主机，更改BIOS设置，或者刷新受控设备的固件。 不同供应商的服务器和主板可能会配备不同类型的 BMC，例如，HP 的 iLO、华为的MGMT、Dell 的 iDRAC、浪潮的IPMI 等，都是 BMC 的具体实现。 BMC通常被实现为嵌入式系统，芯片外围会配置自己的RAM、Flash等器件，插电BMC就会快速运行起来。 BMC是一个独立的系统，不依赖与系统上的其他硬件（比如CPU、内存等等），也不依赖BIOS、OS等。但BMC可以与BIOS和OS交互，一般大规模的数据中心会有OS系统管理软件与BMC协同工作实现集中管理的工作。 三、常见带外管理通信接口 带外管理系统，是指远程客户端与服务器BMC通信，对服务器进行控制管理和维护。常见的带外管理接口有 IPMI 和 Redfish。 （一）IPMI IPMI（Intelligent Platform Management Interface）是一种用于管理和监控服务器硬件的标准接口，定义了用于通过本地总线和网络进行通信的通信协议。 IPMI接口提供了一组命令和响应，可以通过网络远程访问服务器。IPMI接口可以通过命令行工具（ipmitool）、图形界面或API进行访问。（IPMI在 2015 年公布 2.0 v1.1标准后，停止更新维护，被 RedFish 永久代替。为了做到兼容，现在不少服务器上仍然支持 IPMI。）它的核心部件为BMC。 # 远程登录 $ ipmitool -I lanplus -H $host -U $username -P $pwd chassis status # 设置带外网络 $ ipmitool lan set 1 ipsrc dhcp $ ipmitool lan print 1 $ ipmitool lan set 1 ipsrc static $ ipmitool lan set 1 ipaddress 10....