电源侧信道攻击利用CPU功耗的数据相关变化来泄露机密信息。本文展示了在现代英特尔（和AMD）x86 CPU上，可以将电源侧信道攻击转化为时序攻击，而无需访问任何功耗测量接口，这源自于动态电压和频率调整（DVFS, Dynamic Voltage & Frequency Scaling）。在某些情况下，DVFS引起的CPU频率变化取决于毫秒级的当前功耗。这些变化可以被远程攻击者观察到，因为频率差异会转化为绝对时间差异。频率侧信道从理论上来说比当今密码工程实践中考虑的软件侧信道更强，但由于其粗粒度导致很难被利用。然而，现在这一新信道对密码软件的安全构成了真正威胁。本研究首先对现代x86 CPU上的数据、功耗和频率之间的依赖关系进行了逆向工程，发现了一些细微差别，例如一个字中设置位的位置可以通过频率变化来区分。其次提出了一种针对（恒定时间实现）SIKE的新型选择密文攻击，通过远程时序将单个密钥位的猜测放大为成千上万次高功耗或低功耗操作，从而允许通过远程时序进行完整密钥提取。0x01 简介功耗分析攻击几十年来一直被认为是侧信道信息泄露的一个主要源头。在历史上，这些攻击被用来从嵌入式设备（如智能卡）中使用物理探针泄露密码密钥。最近，功耗分析攻击也被证明可以通过软件功耗测量接口来利用。这些接口在许多现代通用处理器上都可用，已被滥用于网站指纹识别、恢复RSA密钥、破解KASLR，甚至恢复AES-NI密钥。幸运的是，基于软件的功耗分析攻击可以通过阻止（或限制）对功耗测量接口的访问来减轻并且容易检测。直到今天，这样的缓解策略将有效地减少攻击面至仅限于物理功耗分析，这在现代通用x86处理器的环境中是一个明显较小的威胁。DVFS是一种常用的技术，它包括动态调整CPU频率以降低功耗（在低CPU负载时）以及确保系统在功耗和热量极限下保持稳定（高CPU负载）。在某些情况下，DVFS引起的CPU频率调整取决于毫秒级的当前功耗。因此，由于功耗与数据相关，CPU频率调整也是与数据相关的。此外，数据相关的频率调整可以被远程攻击者观察，而无需任何特殊权限。原因是CPU频率差异直接转化为执行时间差异（因为1赫兹=1秒内的1个周期）。这一发现的安全影响是重大的。它从根本上破坏了恒定时间编程，自1996年以来一直是抵抗时序攻击的基础防御措施。恒定时间编程的前提是通过编写一个只使用“safe”指令的程序，其延迟与数据值无关，程序的执行时间将是与数据无关。然而若是通过频率信道，即使仅使用安全指令，时序也会成为数据的函数。 尽管其理论上具有很大的威力，但如何构建实际的频率侧信道攻击并容易。这是因为DVFS更新取决于数百万CPU周期内的总功耗，只反映了粗粒度的程序行为。本研究展示了频率侧信道对加密软件安全构成了真正的威胁，通过：（i）在现代x86英特尔CPU上逆向工程的精确泄露模型，（ii）展示一些加密原语能够将单个密钥位的猜测放大成数千次高功耗或低功耗操作，足以引发可测量的时序差异。为了构建泄露模型，对现代x86英特尔CPU上正在计算的数据与功耗/频率之间的依赖关系进行了逆向工程。研究结果显示，功耗和CPU频率取决于数据的汉明权重（HW, Hamming weight）以及跨计算的数据的汉明距离（HD, Hamming distance），这两种影响在现代英特尔CPU上是不同且可累加的。此外，HW效应是非均匀的。也就是说，处理具有相同HW的数据会导致功耗/频率因数据值内个别1的位置而不同。因此，根据秘密进行不同位模式数据的计算可以导致功耗和频率取决于该秘密。然后，本文描述了一种新的攻击，包括新的密码分析技术，针对恒定时间实现的SIKE（Supersingular Isogeny Key Encapsulation）。SIKE已经有十年的历史，被广泛研究的密钥封装机制。与NIST的后量子密码竞赛中的其他入围者不同，SIKE具有较短的密文和较短的公钥。当攻击者提供一个经过特别制作的输入时，SIKE的解密算法会产生依赖密钥的单个位的异常值。这些值会导致算法卡住，并在剩下的解密过程中操作中间值，这些值在剩余的解密中也都是0。当这种情况发生时，处理器的功耗较低，运行频率较高，因此解密所需的绝对时间较短。这种时序信号非常稳定，以至于可以在网络中进行密钥提取，最后，还展示了频率侧信道也可以用来进行无需计时器的时序攻击，例如KASLR破解和隐蔽信道。0x02 研究背景Intel P-States：在英特尔处理器中，动态电压和频率调整（DVFS）以P-states的粒度工作。P-states对应于不同的操作点（电压-频率对），以100 MHz频率递增。不同CPU型号的P-states数量各不相同。现代英特尔处理器提供两种控制P-states的机制，即SpeedStep和Speed Shift / Hardware Controlled Performance States (HWP)。使用SpeedStep，P-states由操作系统（OS）使用硬件协调反馈寄存器进行管理。使用HWP时，P-states完全由处理器进行管理，提高了整体响应性。HWP是在Skylake微架构中引入的。启用HWP时，操作系统只能向处理器的内部P-state选择逻辑提供提示，包括限制可用P-states的范围。否则，可用的P-states范围仅取决于活动内核的数量以及是否启用了“Turbo Boost”。本文的P-state命名约定遵循Linux中使用的约定。最低的P-state对应于支持的最低CPU频率。最高的P-state对应于处理器的“最大睿频”频率。然而，当禁用Turbo Boost时，最高可用的P-state是基本频率，将P-state和频率视为可以互换使用的术语。P-state管理也与功耗管理相关。每个英特尔处理器都有一个热设计功耗（TDP），表示在持续工作负载下的稳定状态下的预期功耗。在最大睿频模式下，处理器可以超过其名义TDP。然而，如果CPU在最大睿频模式下达到一定的功耗和热量极限，硬件将自动减小频率以保持TDP在工作负载的持续时间内。数据相关功耗：众所周知，处理器的功耗取决于正在处理的数据。数据和功耗之间的精确依赖关系取决于处理器的实现，但可以使用泄露模型进行近似。两种常用的泄露模型是汉明距离（HD）和汉明权重（HW）模型。在HD模型中，功耗取决于计算过程中数据中发生的1 → 0和0 → 1位转换的数量。在HW模型中，功耗仅取决于正在处理的数据中位为1的位数。功耗侧信道攻击：功耗侧信道攻击针对加密系统首次在1998年公开讨论，引入了分析技术，利用功耗与数据依赖性来揭示秘密密钥。随后的工作展示了针对多个加密算法的功耗分析攻击，包括AES、DES、RSA和ElGamal。然而，所有这些攻击都针对智能卡，需要物理接触设备。最近，功耗侧信道攻击也被应用于更复杂的设备，如智能手机和PC。其中一些攻击仅依赖于软件功耗测量接口，这意味着它们不需要接近设备。然而，尽管其中一些工作使用了HW和HD泄露模型，但其中没有一个对现代英特尔x86 CPU上功耗和数据之间的依赖关系进行了系统逆向工程。此外，所有这些攻击都可以通过限制对这类功耗测量接口的访问来阻止。0x03 CPU频率泄露信道实验设置：在多台不同的计算机上运行实验。每台计算机的CPU特性都在下表中。所有计算机都运行Ubuntu，版本为18.04或20.04，内核为4.15或5.4，并安装了最新的微码补丁。除非另有说明，使用默认的系统配置，不限制P-states。为了监视CPU频率，使用了MSR_IA32_MPERF和MSR_IA32_APERF寄存器，就像Linux内核中所做的那样。为了监视功耗，使用RAPL接口的MSR。A. 指令区分作为分析的第一步，需要着手了解运行不同工作负载如何影响CPU的P-state选择逻辑。从stress-ng基准测试套件中选择了两个工作负载。第一个工作负载包括32位整数和浮点运算（int32float方法），而第二个工作负载仅包括32位整数运算（int32方法）。在所有内核上运行这两个基准测试，从空闲状态开始。在基准测试的执行过程中，每5毫秒采样一次CPU频率和（包域）功耗。上图a显示了在i7-9700 CPU上进行int32float测试的结果。频率开始时为4.5 GHz，在CPU上，当所有内核都处于活动状态时，这是最高的P-state。在大约8秒的时间内，允许功耗超过TDP。然后，CPU降至较低的P-state，将功耗降至TDP（在CPU上为65W）。从那时开始，CPU保持在稳态，并在工作负载的持续时间内保持功率在TDP水平左右。示例中在稳态下，频率在两个P-states之间波动，分别对应3.9 GHz和4.0 GHz的频率。上图b显示了int32压力测试的结果。这里，频率也从4.5 GHz开始，然后降至较低的P-state。但与图a相比，降低发生在10秒后，且降低后使用的P-states更高，分别对应4.0 GHz和4.1 GHz。这是因为int32测试的功耗较低。因此，处理器不仅可以更长时间地维持最高可用的P-state，而且可以在稳态下使用更高的P-states，而不会超过TDP。以上结果的关键要点是：（i）处理器可以在最大可用P-state上花费的时间，（ii）稳态下P-states的分布都取决于CPU功耗。由于CPU功耗取决于工作负载，根据传递属性，可以得出P-states也取决于工作负载。这意味着P-states的动态调整会泄露有关处理器上当前运行的工作负载的信息。B. 数据区分已经看到P-state信息泄露了有关正在执行的指令（即工作负载）的信息。现在探讨频率泄露信道是否可以泄露有关指令正在处理的数据的信息。问题是由于已知x86处理器上的功耗与数据相关，数据相关的功耗差异是否会在P-states的分布中显示出来？为了回答这个问题，在执行相同的指令时，只改变输入寄存器的内容，同时监视CPU频率。例如使用shlx指令不断将源寄存器的位向左移动，并将结果写入循环中的不同目标寄存器，只变化源寄存器的内容。在所有内核上运行这个实验，并比较稳态下P-states的分布。下图a显示了将源寄存器的内容设置为16、32或48个1时的结果。在所有情况下，P-state在4.3 GHz和4.4 GHz之间波动。然而，汉明权重越大，频率停留在较低的P-state上的时间越长。从空闲状态开始，频率降至稳态的时间也会随着汉明权重的增加而减少（参见下图b）。汉明权重越大，频率降至稳态的速度越快。这是因为，处理具有较大汉明权重的数据消耗的功率比处理具有较低汉明权重的数据要多。也使用其他指令获得类似的结果。例如，当运行or、xor、and、imul、add、sub以及处理从内存加载的数据时，观察到了数据相关的影响。唯一需要注意的是，对于某些指令，仅在所有内核上运行目标指令的功耗不足以导致P-state降至稳态。这些情况下在后台运行了额外的固定工作负载，以增加总功耗。以上结果的关键是，P-states的动态调整会泄 ...

一、前言 去年在做云安全运维时，忙的都没有空挖漏洞。为了弥补去年一年cnvd证书的空缺，某一天晚上我打开了FOFA搜索关键字"系统"，找到了某个系统网站进行测试。 二、思路历程 找到该系统时，首先用插件看了下网站接口是否存在未授权访问。 看了圈都是下载相关的页面，接着就用dirsearch进行目录扫描。 其中在检查扫描到的目录/login.php时，访问该网页时跳出 然后一堆代码一闪而过后，跳转到如下页面 看到上面的情形我猜测网站环境可能是不支持php的，php源码会直接打印出来 接着抓包访问/login.php，果不其然登录页面源码出现了： 在登录的源码中，最有利用价值的莫过于是数据库的账号密码、数据库名称，但是3306端口不一定就是开在公网上的 于是我把FOFA上所有的该系统都扒下来，放进goby中只检测开放了3306端口的系统 在企查查发现该系统的开发商注册资产超过5000万，漏洞目标又有10+，满足申请cnvd证书的条件 已知数据库为KDM3ADB，账号为root，密码为kdc 直接使用sqlmap对数据库进行注入： python3 sqlmap.py -d "mysql://root:kdc@X.X.X.X:3306/KDM3ADB" --tables 这样一张证书就到手了。 验证是dba的权限，以为能一把梭得到源码再审计一波 不过这个注入的地方虽然是dba的权限，但是却没有文件上传的权限，所以无法getshell   拿到数据库了，可以再测试一波弱口令 翻了下密码是这样的，很抽象应该是自己写了加密 回到之前login.php源码泄露里面，其中在登录时有对密码进行解密的源码，看着很头疼，想起了学密码学时候那些交换变换的算法 // 密码加密函数 function EncryptStr($strSo ...

漏洞概述 Essential Addonsfor Elementor是一款功能强大、易于使用的WordPress插件，为使用Elementor建立网站的用户提供了众多额外的功能和组件，使得用户能够更轻松地创建各种网站元素，并且还提供了许多预设计样式和高级功能，使得用户能够更好地管理和定制网站。此外，通过WordPress官方统计（https://api.wordpress.org/plugins/info/1.0/essential-addons-for-elementor-lite.json）可知，它的安装量超过百万。 近期，其密码重置功能存在授权问题，允许未经认证的远程攻击者实现权限提升。 受影响版本 受影响版本：5.4.0 <= Essential Addons for Elementor <= 5.7.1 漏洞分析 问题关键在于Essential Addons for Elementor的密码重置功能没有验证密码重置密钥，就直接改变了指定用户的密码，也就是说攻击者只需知道用户名，就有可能进行密码重置，并获得对应账户的权限。 这里我们采用打补丁前的最新版本（5.7.1）进行分析，具体链接如下：https://downloads.wordpress.org/plugin/essential-addons-for-elementor-lite.5.7.1.zip 先从includes/Classes/Bootstrap.php看起，这段代码是在WordPress中添加一个动作，当网站初始化时触发该动作，调用login_or_register_user() 该函数位于includes/Traits/Login_Registration.php 它的作用是处理登录和注册表单的提交数据，并根据提交的数据调用相应的方法。正如漏洞概述所说，问题关键在于密码重置，所以我们继续跟进reset_password()，它做的第一步操作就是检查page_id和widget_id是否为空，若为空则返回”xxx ID is missing”，用作后续的错误处理，所以我们首先要做的就是给这两个id赋值： 接着代码就会检查eael-resetpassword-nonce的值是否为空，若不为空则通过wp_verify_nonce()进行验证。 那么问题来了，nonce是什么？如何获取？ 在 WordPress 中，nonce 是一个随机字符串，用于防止恶意攻击和跨站请求伪造（CSRF）攻击，它通常与表单一起使用，在表单提交时添加一个随机值，以确保表单只能被特定的用户或请求使用。而关于nonce如何获取，wp_create_nonce()可以做到这一点。 function wp_create_nonce( $action = -1 ) { $user = wp_get_current_user(); $uid = (int) $user->ID; if ( ! $uid ) { /** This filter is documented in wp-includes/pluggable.php */ $uid = apply_filters( 'nonce_user_logged_out', $uid, $action ); } $token = wp_get_session_token( $action ); $i = wp_nonce_tick( $action ); return substr( wp_hash( $i . '|' . $action . '|' . $uid . '|' . $token, 'nonce' ), -12, 10 ); } 但需要注意的是，攻击者无法通过本地生成的 nonce 绕过受害者站点的wp_verify_nonce() 验证，因为他们不能在本地生成与受害者站点相同的 nonce。不过还有一种方法来获取nonce，直接访问主页即可在localize里找到它。 至于原因，则是它被includes/Classes/Asset_Builder.php::load_commnon_asset()设置在localize_object内： 跟踪localize_object不难发现，它被两个函数调用过： 先看add_inline_js()，它用于加载内联js代码和变量。在前端页面加载时，浏览器将加载该代码，并在js中创建名为 localize 的变量，该变量的值就是localize_objects 数组经wp_json_encode()转换的json字符串。 显然，我们刚才直接访问主页发现的localize就是以json格式呈现的。再看frontend_asset_load()，它用于加载前端资源。 最终上述两个函数都会被init_hook()调用，add_inline_js() 被添加到 wp_footer 中，优先级为100，以便在 WordPress 前端页面的页脚中加载内联js代码和变量。而frontend_asset_load() 被添加到 wp_enqueue_scripts 中，优先级为100，以便在 WordPress 前端页面加载时加载所需的前端资源。 之后就是给eael-pass1、eael-pass2赋值，设置新密码了： 当我们满足了上述前提条件以后，再通过rp_login设置想要攻击的用户即可。此时，代码就会借助get_user_by() function get_user_by( $field, $value ) { $userdata = WP_User::get_data_by( $field, $value ); if ( ! $userdata ) { return false; } $user = new WP_User(); $user->init( $userdata ); return $user; } 按我们给定的字段，也就是用户名去检索用户信息： 如果这是真实存在的用户，就调用reset_password() 进行密码重置操作： 漏洞复现 通过以上分析，我们仅需知道用户名以及nonce值，再向受害站点发送满足漏洞触发条件的请求体，即可进行漏洞利用。 当然，之前也提到了受影响的版本，所以漏洞利用之前，需要优先进行版本探测，有两个方法： 第一，由于frontend_asset_load()调用了wp_enqueue_style()来加载css文件，WordPress就会自动将版本号添加到url中，这是为了确保浏览器能够正确缓存css文件，以便在文件更新时将旧文件替换为新文件： function wp_enqueue_style( $handle, $src = '', $deps = array(), $ver = false, $media = 'all' ) { _wp_scripts_maybe_doing_it_wrong( __FUNCTION__, $handle ); $wp_styles = wp_styles(); if ( $src ) { $_handle = explode( '?', $handle ); $wp_styles->add( $_handle[0], $src, $deps, $ver, $media ); } $wp_styles->enqueue( $handle ); } 第四个参数即代表指定样式表的版本号的字符串，如果它有的话，它将作为一个查询字符串添加到URL中，以达到破坏缓存的目的。如果版本号被设置为false，则会自动添加一个与当前安装的WordPress版本相同的版本号。如果设置为null，则不添加版本号。最终生成这样一条url：https://example.com/front-end/css/view/general.min.css?ver=x.x.x 第二，我们也可以通过/wp-content/plugins/essential-addons-for-elementor-lite/readme.txt进行版本探测。 确认受影响的版本以后，就是搜寻真实用户名。同样有多种方式进行探测： 使用 WordPress 的 rss feed 来提取用户名。这是一种用于发布和传递 WordPress 内容的标准格式，包含了站点的最新文章、页面、评论等内容，以及发布时间、作者、分类、标签等相关信息。这些信息可以被其他站点或应用程序订阅和使用，增加当前站点的曝光度。而其中dc:creator标签就包含了作者名称； 使用 WordPress 的 rest api 来获取用户名； 使用了 Yoast 插件提供的站点图来获取用户名。它较于第一种方法的优势在于只能获取到站点中已发布文章的作者信息。如果站点中还有其他用户没有发布文章，那么这些用户的信息是不会被获取的。 除此之外，WordPress也存在默认用户名(admin)，这也是该漏洞最常利用的用户名之一。 做完上述信息收集以后，构造报文即可成功重置任意用户密码： 修复方案 在Essential Addons for Elementor(5.7.2)中，进行reset_password()操作之前，先去做了rp_key的校验。补丁如下：   ...

这两个洞是公众号的，以下是我利用Charles+burp进行抓包，Charles的配置。 测公众号的话，可以用浏览器打开，以下主要是可以进行微信小程序的测试。不用下载什么模拟器，pc端完全可以。但是找小程序包的逆向看源码，我发现有一个相同的小程序，模拟器里面的包有主包和分包。PC端的只有一个主包。进行查看，分包里面的内容也没有什么可用的，但是有的小程序PC端也会发现分包。真机的话，已经在root的手机没有在小程序包的目录发现。 还有小程序在模拟器找小程序包的话，要root，用雷神的话，文件管理器会赋予root权限，可以进行根目录的查看。要是真机或者mumu的话需要下载一个Root Explorer，才可以查看根目录。当然可以用adb进入shell，在导出wxapkg包也完全可以。 首先安装证书 之后跟着走就安装好了 接着需要配置https。 最后配置连接到bu ...

适用于白盒fuzzing input corpus 收集语料库 对于模糊测试工具而言，我们需要为其准备一个或多个起始的输入案例，这些案例通常能够很好的测试目标程序的预期功能，这样我们就可以尽可能多的覆盖目标程序。收集语料的来源多种多样。通常目标程序会包含一些测试用例，我们可以将其做位我们初始语料的一部分，此外互联网上也有些公开的语料库你可以收集他们做为你的需要。关于语料库的主动性选择，这个更多需要你对fuzzing 目标内部结构的了解。例如你当你要fuzzing的目标对随着输入的规模内存变化非常敏感，那么制作一批很大的文件与较小的文件可能是一个策略，具体是否是否有效取决于你经验、以及对目标的理解。此外，需要注意控制语料库的规模，太过庞大的语料库并不是好的选择，太过潘达的语料库会拖慢fuzzing的效率，尽可能用相对较小的语料覆盖更多目标代码的预期功能即可。 语料库唯一化 我们在上一小节最后提到一点，太过庞大的语料库会因为有太多的测试用例重复相同的路径覆盖，这会减慢fuzzing的效率。因此人们制作了一个工具，能够使语料库覆盖的路径唯一化，简单的说就算去除重复的种子输入，缩减语料库的规模，同时保持相当的测试路径效果。在AFL++中可以使用工具afl-cmin从语料库中去除不会产生新路径和覆盖氛围的重复输入，并且AFL++官方提示强烈建议我们对语料库唯一化，这是一个几乎不会产生坏处的友谊操作。具体的使用如下： 将收集到的所有种子文件放入一个目录中，例如 INPUTS 运行 afl-cmin： 字典 其实将字典放到这一个大节下面不是很合适，因为字典可以归类为一种辅助技巧，不过因为字典影响输入，所以我就将其划到这里了。关于是否使用字典，取决于fuzzing的目的与目标。例如fuzzing的目标是ftp服务器，我们fuzzing的目的是站在用户的视角仅能输入命令，因此我们的输入其中很大一部分可以规范到ftp提供的命令，我们更多的是通过重复测试各种命令的组合来测试目标ftp服务器在各种场景都能正确运行。又比如，当你fuzzing一个很复杂的目标时，它通常提供一个非常非常丰富的命令行参数，每一次运行时组合不同的参数可能会有更好的覆盖效果，因此可以将你需要启用的参数标记为字典添加进命令行参数列表中。最后，目标程序可能经常有常量的比较和验证，而这些环节通常会使得fuzzing停滞在此，因为模糊器的变异策略通常对应常量的猜测是非常低效的。我们可以收集目标程序中使用到的常量，定义为一个字典提供给模糊器。但目前对于AFL++来说有更好的方法解决这种需求，而无需定义字典，后面我们会介绍这些方法。 # 模糊器默认的变异策略通常难以命中if分支为true的情况，因为input做为64位，其值的空间太大了，根本难以猜测。 if (input = 0x1122336644587) { crash(); } else { OK(); } 编译前的准备 选择最佳的编译器 如我们上一节中谈到收集程序常量定义字典时，事实上收集常量并生成字典这个事情，在编译时完全可以顺便将其解决。没错，功能强大的编译器可以使我们在编译期间获得非常多有用的功能。对于AFL++的编译器选择，官方提供了一个简单的选择流程，如下 +--------------------------------+ | clang/clang++ 11+ is available | --> use LTO mode (afl-clang-lto/afl-clang-lto++) +--------------------------------+ see [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.lto.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.lto.md) | | if not, or if the target fails with LTO afl-clang-lto/++ | v +---------------------------------+ | clang/clang++ 3.8+ is available | --> use LLVM mode (afl-clang-fast/afl-clang-fast++) +---------------------------------+ see [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.llvm.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.llvm.md) | | if not, or if the target fails with LLVM afl-clang-fast/++ | v +--------------------------------+ | gcc 5+ is available | -> use GCC_PLUGIN mode (afl-gcc-fast/afl-g++-fast) +--------------------------------+ see [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.gcc_plugin.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.gcc_plugin.md) and [https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.instrument_list.md](https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.instrument_list.md) | | if not, or if you do not have a gcc with plugin support | v use GCC mode (afl-gcc/afl-g++) (or afl-clang/afl-clang++ for clang) 若你的LLVM和clang版本大于等于11，那么你可以启用LLVM LTO模式，使用afl-clang-lto/afl-clang-lto++，该模式通常是最佳的。随后依次是afl-clang-fast/afl-clang-fast++和afl-gcc-fast/afl-g++-fast。关于为什么LTO模式通常是最佳的，其中一个原因是它解决了原版AFL中边碰撞的情况，提供了无碰撞的边(edge)检测。在原本AFL中，因为其对边(edge)的标识是随机的，对于AFL默认2^16容量来说，一旦程序足够大，边的标识会重复，这种现象就算边碰撞，它会降低模糊测试的效率。此外LTO模式会自动收集目标代码中的常量制作成为一个字典并自动启用，并且社区提供的一些有用的插件和功能很多时候是要求LLVM模式(clang-fast)甚至是LTO模式(clang-lto)。 NOTE：此处涉及一点AFL度量覆盖率的工作原理，可以参考我注意的另一篇文章《基于覆盖率的Fuzzer和AFL》，写的很一般（逃 关于编译器的选择，如果可能直接选LTO模式即可。但你需要注意，LTO模式编译代码非常的吃内存，编译时间也会很久，尤其是启用某些Sanitizer的时候。 NOTE：你的计算机配置最好至少由8核心，内存最好不低于16G。请注意8核心，16G仍然不是很够用，最好32G，16核或以上，核心越多越好。因为到时候你会编译很多不同版本的程序，不同的插件、不同的sanitizer、不同策略等等，这些不同的选项往往不能兼并到一个程序上，往往需要编译多分不同配置的程序，并你会经常patch程序再编译测试patch的效果。简言之，你会编译很多次程序，你需要足够大的内存和核心来编译目标，使得你不必经常阻塞等待编译队列和结果。 编译的选项 AFL++是一个非常活跃的社区，AFL++会集成社区中、互联网上一些强大的第三方插件，这些集成的插件有一些我们可以通过设置对应的编译选项启用。对于LTO模式（afl-clang-fast/afl-clang-lto）进行编译插桩时，可以启用下面两项比较通用的特性，主要用于优化一些固定值的比较和校验。 Laf-Intel：能够拆分程序中整数、字符串、浮点数等固定常量的比较和检测。考虑下面一个情况assert x == 0x11223344，Laf-Intel会拆分为assert (x & 0xff) == 0x44 && ((x >> 8) & 0xff) == 0x33 ....这样形式，每一次只会进行单字节的比较，这样AFL就可以逐个字节的猜测，每当确定一个字节时，就会发现一个新的路径，进而继续在第一个字节的基础上猜测第二个字节，如此使得模糊器可以快速猜出0x11223344。如果你没有自己制作好的字典、丰富的语料库，这个功能会非常有用，通常建议至少有一个AFL++实例运行Laf-Intel插件。在编译前设置如下环境使用：export AFL_LLVM_LAF_ALL=1 CmpLog：这个插件会提取程序中的比较的固定值，这些值会被用于变异算法中。功能与Laf-Intel类似，但效果通常比Laf-Intel。使用该插件需要单独编译一份cmplog版本的程序，在fuzzing时指定该cmplog版本加入到fuzzing中。具体的用法如下： # 编译一份常规常规版本 cd /target/path CC=afl-clang-lto make -j4 cp ./program/path/target ./target/target.afl 编译cmplog版本 make cleanexport AFL_LLVM_CMPLOG=1CC=afl-clang-lto make -j4cp ./program/path/target ./target/target.cmplogunset AFL_LLVM_CMPLOG 使用cmplog， 用-c参数指定cmplog版本目标，因为cmplog回申请很多内存做映射因此我们设置 -m none，表示不限制afl-fuzz的内存使用。你也可以指定一个值例如 -m 1024，即1GB。 afl-fuzz -i input -o output -c ./target.cmplog -m none -- ./target.afl @@ NOTE：需要注意，两个插件并不是说谁替代谁，往往在实际fuzzing中两者都会用至少一个afl实例启用。 考虑下面两种场景。有时候你想要fuzzing的目标中，他自动的集成了很多第三方的库代码，他们会在编译中一并编译，而你并不想fuzzing这些第三方库来，你只想高效、快速的fuzzing目标的代码，额外的fuzzing第三方代码只会拖慢你fuzzing的效率。有时候你的目标会非常庞大和复杂，他们的构建往往是模块化的，有时候你只想fuzzing某几个模块。这上面两种情况都是我们fuzzing中很常遇见的，所幸AFL++提供了部分插桩编译的功能，即"partial instrumentation"，它允许我们指定应该检测那些内容以及不应该检测那些内容，这个检测的颗粒是代码源文件、函数级两级。具体用法如下： 检测指定部分。创建一个文件(allowlist.txt,文件名没有要求)，需要在其中指定应包含检测的源代码文件或者函数。 1.在文件中每行输入一个文件名或函数 foo.cpp # 将会匹配所有命名为foo.cpp的文件，注意是所有命名为foo.cpp的文件path/foo.cpp # 将会只确定的包含该路径的foo.cpp文件，不会造成意外的包含fun:foo_fun # 将会包含所有foo_fun函数     设置export AFL_LLVM_ALLOWLIST=allowlist.txt 启用选择性检测 排除某些部分。与指定某些部分类似，编写一个文件然后设置环境变量export AFL_LLVM_DENYLIST=denylist.txt以启用，这会跳过我们文件中指定的内容。 Note：有些小函数可能在编译期间被优化，内联到上级调用者，即类似于宏函数展开。这时将会导致指定失效！如果不想受此影响，禁用内联函数优化即可。此外，对于C++由于函数命名粉碎机制，你需要特别的提取粉碎后的函数名。例如函数名为test的函数可能会被粉碎重命名为_Z4testv。可以用nm提取函数名，创建一个脚本筛选出来。 添加Sanitizer检测更多BUG Sanitizer最初是Google的一个开源项目，它们是一组检测工具。例如AddressSanitizer是一个内存错误检测器，可以检测诸如OOB、UAF、Double-free等到内存错误的场景。现在该项目以及成为LLVM的一部分，相对较高的gcc和clang都默认包含Sanitizer功能。由于AFL++基本只会检测到导致Crash的BUG，因此启用一些Sanitizer可以使得我们检测一些并不会导致Crash的错误，例如内存泄露。AFL++内置支持下面几种Sanitizer： ASAN：AddressSanitizer，用于发现内存错误的bug，如use-after-free、空指针解引用（NULL pointer dereference）、缓冲区溢出（buffer overruns）、Stack And Heap Overflow、Double Free/ Wild Free、Stack use outside scope等。若要使用请在编译前设置环境变量export AFL_USE_MSAN=1。更多关于ASAN的信息参与LLVM官网对ASAN：AddressSanitizer的描述(https://clang.llvm.org/docs/AddressSanitizer.html)。 MSAN：MemorySanitizer，用于检测对未初始化内存的访问。若要启用，在编译前设置export AFL_USE_MSAN=1以启用。 UBSAN：UndefinedBehavior Sanitizer，如其名字一般用于检测和查找C和C++语言标的未定义行为。未定义行为是语言标准没有定义的行为，编译器在编译时可能不会报错，然而这些行为导致的结果是不可预测的，对于程序而言是一个极大的隐患。请在编译前，设置export AFL_USE_UBSAN=1环境变量以启用。 CFISAN：Control Flow Integrity Sanitizer，CFI的实现有多种，它们是为了在程序出现未知的危险行为时终止程序，这些危险行为可能导致控制流劫持或破坏，用于预防ROP。在Fuzzing中，CFISAN主要用于检测类型混淆。请在编译前，设置export AFL_USE_CFISAN=1环境变量以启用。 TSAN：Thread Sanitizer, 用于多线程环境下数据竞争检测。在目前，计算机通常都是多核，一个进程中通常包含多个进程，常常导致一个问题，即数据竞争。此类错误通常很难通过调试发现，出现也不稳定。当至少两个线程访问同一个变量，并且同时存在读取和写入的行为时，即发送了数据竞争，若读取在写入之后，线程可能读取到非预期的数据，可能导致严重的错误。请在编译前，设置export AFL_USE_TSAN=1环境变量以启用。 LSAN，Leak Sanitizer,用于检测程序中的内存泄露。内存泄露通常并不会导致程序crash，但它是一个不稳定的因素，可能会被利用、也可能没办法被利用，这不是一个严格意义上的漏洞。与其他Sanitizer的使用不同，需要将__AFL_LEAK_CHECK();添加到你想要进行内存泄露检查的目标源代码的所有区域。在编译之前启用 ，export AFL_USE_LSAN=1。要忽略某些分配的内存泄漏检查，__AFL_LSAN_OFF(); 可以在分配内存之前和__AFL_LSAN_ON();之后使用，LSAN不会检查这两个宏之间区域。 Note： 一些Sanitizer不能混用，而即使有些可以同时允许的Santizier也可能导致意想不到的行为影响fuzzing，这需要结合你fuzzing的目标情况而定。如果你不熟悉Sanitizer的原理，最好一个编译实例中只启用一个Sanitizer，这样通常不会出问题，而且组合Sanitizer不见得会有好效果，基于对目标的了解正确的使用Sanitizer才是最佳的实践。 有些Sanitizer提供了参数设置的环境变量，如ASAN_OPTIONS，如果你有很明确的需求可以设置该变量进一步限制Sanitizer的检测行为，这可能会提高你fuzzing的效率。如果你不熟悉、也没有明确的需求，那么保持默认即可，这通常是最实用的。 启用CFISAN的实例，可能会检测出很多crash(成百上千)，这是正常的，但大多数是无用的，甚至全是无用的，你需要注意甄别。 如果你对目标内部结构足够熟悉，你确定那些区域是线程并发的高发区域，那么你可以结合TSAN与partial instrumentation功能提高TSAN的检测效率，因为启用TSAN的实例通常fuzzing速度会大幅减慢。 通常启Sanitizer后，会大幅减慢fuzzing的速度，CPU每秒执行次数会减少，内存也会被大量消耗(AddressSanitizer会大量消耗内存，甚至可能导致计算机内存耗尽)。如果你的计算机配置不行，请斟酌一个合理的搭配。 一种Sanitizer只应该允许一个实例 。在两个实例上允许两个同样的Sanitizer是一种浪费，因为AFL++会同步所有实例的testcase，其他实例的testcase无论如何都会被该实例上的Sanitizer检测一遍，不应该启用两个相同的Sanitizer检测两遍，这会减慢效率。 暂时只想到这些，以后想到了再补充。 LLVM Persistent Mode In-process fuzzing是一个强大功能，通常比默认常规编译fuzzing的速度快得多，大概快10-20倍，并且基本没有任何缺点。如果可以，请毫不犹豫的使用Persistent mode。众所周知，AFL使用ForkServer来进行每次fuzzing，然而即便不用execve这种巨大的开销，但fork仍然是一笔不小的开。而Persistent fuzzing即一次fork进程种进行多次fuzzing，而无需每次都fork。Persistent mode提供一组AFL++的函数和宏，我们使用下面的形式,用一个while包含我们要进行Persistent fuzzing的区域。请注意，该区域的代码必须要是无状态的，要么是可以手动可靠的重置为初始状态！这样我们才能再每次fuzzing时重置进而再次fuzzing。afl-clang-fast/lto编译的情况下，只需要使用下面的形式即可，但若不是，则复杂一些。AFL++官方的仓库对Persistent Mode花了不小的篇幅讲诉，讲的也比较全面，请在此处Persistent Mode中查阅，我就不做过多描述了。 #include "what_you_need_for_your_target.h"   __AFL_FUZZ_INIT(); int main() { // anything else here, e.g. command line arguments, initialization, etc. #ifdef __AFL_HAVE_MANUAL_CONTROL __AFL_INIT(); #endif unsigned char *buf = __AFL_FUZZ_TESTCASE_BUF; // must be after __AFL_INIT // and before __AFL_LOOP! while (__AFL_LOOP(10000)) { int len = __AFL_FUZZ_TESTCASE_LEN; // don't use the macro directly in a // call! if (len &lt; 8) continue; // check for a required/useful minimum input length /* Setup function call, e.g. struct target *tmp = libtarget_init() */ /* Call function to be fuzzed, e.g.: */ target_function(buf, len); /* Reset state. e.g. libtarget_free(tmp) */ } return 0; } Patch 大多数时候，我们fuzzing一个目标想要其达到我们预期的效果，都需要Patch。并且我们在后续fuzzing流程的持续改进中可能还会发现一些影响fuzzing效率的地方，我们又会倒回来patch，编译重新启动fuzzing。此外，有时候一些校验、检查，它们往往对于fuzzing的结果没有什么影响，但是却严重影响fuzzing的效率。此时我们通常会审查目标内部代码，将这些严重性fuzzing效率的地方Patch，或者是删除。我们都知道Persistent Mode收益十分巨大，但却要求Persistent循环区域内的代码是无状态的，有时候区域会有一些有状态的函数，但他们却并不重要，这时你可以Patch它们，使它们返回诸如硬编码之类可以，这样就变成无状态的，我们就可以使用Persistent Mode了。例如一个区域的输入可能依赖于socket IO读入，而处理socket IO是很麻烦的，因此我们可以考虑将socket fd替换为文件 fd，并patch那些受socket fd受影响区域，以便我们fuzzing正确运行。简言之，Patch最好有明确的理由，随意的Patch对模糊测试来说可能会导致很糟糕的现象，要么你对此处的Patch是基于改进fuzzing效率，要么是为了启用某些有益的fuzzing功能....总之，最好清楚自己的Patch是为了什么。但请注意，对于一次模糊测试来说Patch只是可选的，如果你对自己的工具、目标不甚了解，那么Patch对你而言可能不重要。如果你清楚目标的内部结构，并且明确知道要改进fuzzing的流程和目的，那么Patch可能是你定制化自己fuzzing的一个重要手段。 后续 目前就先写到着，后面的内容，包括build、fuzzing、评估、流程改进等等就放到下篇，最近的工作可能要忙一些其他的。  ...