Security Affairs 网站披露，IBM X-Force 研究人员发现威胁攻击者正在利用 Citrix NetScaler 网关存在的CVE-2023-3519 漏洞（CVSS评分：9.8），开展大规模的凭证收集活动。 2023 年 7 月底，Citrix 警告客户 NetScaler 应用交付控制器（ADC）和网关中存在的 CVE-2023-3519 漏洞正在被恶意利用。据悉，该漏洞是一个代码注入漏洞，可导致未经验证的远程代码执行。 美国网络安全和基础设施安全局（CISA）也曾针对 CVE-2023-3519 发出过警示。CISA 透露威胁攻击者正在利用该漏洞在易受攻击的系统上投放 Web 外壳，其目标可能是部署在关键基础设施组织网络中的 NetScaler ADC 设备。 一个月后，非营利组织 Shadowserver Foundation 安全研究人员指出数百台 Citrix Netscaler ADC 和网关服务器已被网络攻击者破坏。 威胁攻击者正在“积极”利用漏洞 X-Force 在为一个客户端进行事件响应活动时发现上述网络攻击活动。客户端报告称在 NetScaler 安装时身份验证缓慢，攻击者利用该漏洞将恶意 Javascript 注入设备“index.html”登录页。 此后，X-Force 在发布的报告中表示附加到合法 "index.html "文件的脚本会加载一个额外远程 JavaScript 文件，该文件会将一个函数附加到 VPN 身份验证页面中的 "登录 "元素，该函数则会收集用户名和密码信息，并在身份验证期间将其发送到远程服务器。 值得一提的是，攻击链从威胁攻击者向"/gwtest/formssso? event=start&target="发送网络请求时便已经开始了，触发 CVE-2023-3519 漏洞后，在 /netscaler/ns_gui/vpn 写入一个简单的 PHP web shell，一旦受害目标设备部署了 PHP web shell，攻击者就会检索设备上 "ns.conf "文件的内容。 然后，攻击者在 "index.html "中添加自定义 HTML 代码，该代码引用了托管在攻击者控制的基础架构上的远程 JavaScript 文件。 附加到 "index.html "的 JavaScript 代码检索并执行后，会将一个自定义函数附加到身份验证页面上的 "Log_On "按钮，恶意代码随及就能够收集身份验证表单中的数据（包括凭据），并通过 HTTP POST 方法将其发送到远程主机。 X-Force 安全研究人员发现本次网络攻击活动中还使用了多个域名，这些域名分别于 8 月 5 日、6 日和 14 日注册，并利用 Cloudflare 掩盖了域名的托管地。在安全研究人员确定威胁攻击者使用的 C2 基础设施后，确定了近 600 个唯一的受害者 IP 地址，这些地址托管着修改过的 NetScaler Gateway 登录页面。 分析显示，大多数受害者分布在美国和欧洲地区，虽然目前研究人员无法将这一活动与任何已知威胁组织联系起来，但已经提取到了入侵指标（IoCs）。 文章来源： https://securityaffairs.com/152199/hacking/citrix-netscaler-credential-harvesting-campaign.html?_gl=1*om0nuo*_ga*NjYyNDMxOTU5LjE2MzU5OTc2MDM.*_ga_NPN4VEKBTY*MTY5NjkwMjg5Ny4xNDYuMC4xNjk2OTAyODk3LjYwLjAuMA..*_ga_8ZWTX5HC4Z*MTY5NjkwMjg5OC4xMjcuMC4xNjk2OTAyODk4LjAuMC4w&_ga=2.237611651.246524512.1696747860-662431959.1635997603 ...

CISA、FBI和美国网络司令部(USCYBERCOM)于本周四（9月7日）发布的一份联合报告显示，国家支持的黑客组织利用针对Zoho和Fortinet关键漏洞攻击了美国一家航空组织。 此次攻击背后的威胁组织尚未公布，联合公告中也并未将攻击者与特定国家联系起来，但USCYBERCOM的新闻稿中将此次攻击活动和伊朗黑客联系了起来。 CISA方面声称，黑客组织至少从 1 月份开始就入侵了航空组织网络。他们此前入侵了一台运行 Zoho ManageEngine ServiceDesk Plus 和 Fortinet 防火墙的互联网外露服务器。 CISA、FBI和CNMF在公告中提到，有高级持续威胁（APT）行为者利用CVE-2022-47966漏洞非法访问了一个面向公众的应用程序（Zoho ManageEngine ServiceDesk Plus），并在其网络中建立了持久性。 该漏洞允许黑客在 ManageEngine 应用程序上远程执行代码。还有其他 APT 行为者利用 CVE-2022-42475 在组织的防火墙设备上建立存在。 正如这三个美国机构所警告的那样，这些威胁组织经常会搜索那些面向互联网却没有打补丁的设备。在渗入目标网络后，攻击者会在被黑的网络基础设施组件上保持持久性。这些网络设备很可能会被用作受害者网络内横向移动的基础或者恶意基础设施。 美国国家安全局建人们采取措施以确保基础设施的安全，这些措施包括但不限于保护所有系统免受所有已知漏洞的攻击、监控远程访问软件的未经授权使用，以及删除不必要（已禁用）的账户和组（尤其是特权账户）。 攻击和确保系统安全的警告 今年 1 月，CISA 下令联邦机构保护其系统免受 CVE-2022-47966 漏洞的攻击，几天后，网上发布了概念验证 (PoC) 漏洞利用代码，威胁方开始攻击未打补丁的 ManageEngine 实例，以打开反向外壳。 在 CISA 发出警告几个月后，朝鲜 Lazarus 黑客组织也开始利用 Zoho 漏洞，成功入侵了医疗机构和一家互联网骨干基础设施提供商。 联邦调查局和 CISA 就国家支持的组织利用 ManageEngine 漏洞攻击关键基础设施，包括金融服务和医疗保健发布了其他多条警报。 正如Fortinet在1月份披露的那样，CVE-2022-42475 FortiOS SSL-VPN漏洞在针对政府组织和相关目标的攻击中也被作为零日漏洞加以利用。 Fortinet 曾在去年11月28日修复了该漏洞，但并未公布该漏洞被利用的具体信息。不过Fortinet 自12 月中旬后已经开始敦促客户为其设备打上补丁，以确保设备安全。 参考来源：Iranian hackers breach US aviation org via Zoho, Fortinet bugs (bleepingcomputer.com) ...

Bleeping Computer 网站消息，Gafgyt 恶意软件正积极利用 Zyxel P660HN-T1A 路由器五年前曝出的漏洞，每天发动数千次网络攻击活动。据悉，漏洞被追踪为 CVE-2017-18368，是路由器设备远程系统日志转发功能中存在的严重性未验证命令注入漏洞（CVSS v3：9.8），Zyxel 已于 2017 年修补了该漏洞。 早在 2019 年，Zyxel 就强调当时的新变种 Gafgyt 可能会利用该漏洞发动网络攻击，敦促仍在使用旧固件版本的用户尽快升级到最新版本，以保护其设备免遭接管。然而自 2023 年 7 月初以来，Fortinet 仍能够监测到平均每天 7100 次的攻击活动，且攻击数量持续至今。 Fortinet 发布警报表示截止到 2023 年 8 月 7 日，FortiGuard 实验室持续监测到利用 CVE-2017-18368 漏洞的攻击活动，并在过去一个月中阻止了超过数千个独特 IPS 设备的攻击企图。 试图利用 Zyxel 路由器中的 CVE-2017-18368 漏洞（来源：Fortinet ） Fortinet 指出虽然目前还尚不清楚观察到的攻击活动中有哪一部分成功感染了设备，但自 7 月份以来，攻击活动一直保持稳定。值得一提的是，CISA 近期发布了 CVE-2017-18368 在野外被利用的情况，并将该漏洞添加到其已知利用漏洞目录中，要求联邦机构在 2023 年 8 月 28 日前修补 Zyxel 漏洞。 为应对漏洞利用的爆发，Zyxel 又更新了安全公告，提醒客户 CVE-2017-18363 只影响运行 7.3.15.0 v001/3.40(ULM.0)b31 或更旧固件版本的设备，运行 2017 年为修复漏洞而推出的最新固件版本 3.40(BYF.11) 的 P660HN-T1A 路由器不受影响。 此外，Zyxel 表示 P660HN-T1A 在几年前就已达到报废年限。因此，强烈建议用户将其更换为更新一代的产品，以获得最佳保护。 路由器感染恶意软件常见迹象包括连接不稳定、设备过热、配置突然改变、反应迟钝、非典型网络流量、开放新端口和意外重启，如果怀疑自己的设备受到网络恶意软件的攻击，用户可以执行出厂重置，将设备固件更新到最新版本，更改默认的管理员用户凭据，并禁用远程管理面板，只从内部网络管理设备。 文章来源： https://www.bleepingcomputer.com/news/security/gafgyt-malware-exploits-five-years-old-flaw-in-eol-zyxel-router/#google_vignette ...

适用于白盒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 < 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、评估、流程改进等等就放到下篇，最近的工作可能要忙一些其他的。  ...

谷歌宣布，从Chrome浏览器116版本开始，其安全更新频率将从过去的每两周一次压缩为每周一次，以解决攻击者通过补丁更新的时间间隔，利用N Day和0 Day漏洞进行攻击活动。 谷歌表示，Chromium 是一个开源项目，任何人都可以查看其源代码并提交漏洞修复，这些更改、修复和安全更新将添加到 Chrome 的开发版本（Beta/Canary）中，并在将其推送到正式稳定版 Chrome 之前对其进行稳定性、性能或兼容性问题测试。 这一机制虽然有良好的透明度，但也让攻击者有可乘之机，即在这些修复正式推送到稳定版 Chrome的庞大用户群之前在野外利用这些漏洞。 谷歌早在几年前就发现了这个问题，当时补丁间隔平均为 35 天，而在 2020 年，随着 Chrome 77 的发布，谷歌将间隔缩短为每两周更新一次， 通过压缩到每周的更新，Google 进一步缩短了补丁间隔，并将N Day漏洞的利用窗口机会减少到一周，从而可以有效阻止需要更复杂利用路径的漏洞利用。这无疑会对 Chrome 的安全性产生积极影响，但仍不能避免攻击者使用已知技术对某些漏洞进行有效利用。 需要注意的是，Android的生态系统让谷歌难以控制，很多情况下，谷歌发布的补丁需要几个月的时间才能将其引入第三方厂家生产的设备中。 参考来源：Google to fight hackers with weekly Chrome security updates ...