1.log4j2远程代码执行漏洞本地复现
2.Nftables CVE-2023-0179提权利用
3.Heap Spraying什么是Heap Spraying
4.Gitlab Cookie 反序列化漏洞研究

log4j2远程代码执行漏洞本地复现

       本文仅供学习参考，请勿在真实环境进行网络攻击行为。

       一、背景

       Log4j 2 是 Java 中应用非常广泛的一个日志框架，在 年底，一个名为 CVE--（也称为 Log4Shell）的69的源码严重漏洞被发现，该漏洞被CVSS评为分最高级别。网络攻击者利用这个漏洞不需要服务器密码就可以访问并操作服务器，攻击方式非常简单，技术门槛低，危害极大。受影响版本：Apache log4j2 2.0 - 2..1 下面先简单看一下攻击原理，然后直接开始操作。

       二、攻击原理

       假设现在有个网站，当用户登录时，正常请求路径如下：

       如果应用服务端的登录接口中使用漏洞版本的log4j2打印请求参数的日志，就有可能被注入。如图所示：

       三、熊猫shop源码复现步骤

       以下代码已放在github仓库：log4j漏洞复现代码

       1. jdk版本

       作者使用jdk1.8.0_和1.8.0_复现成功，1.8.0_复现失败。

       JDK 6u、7u、8u之后：增加了com.sun.jndi.ldap.object.trustURLCodebase选项，默认为false，禁止LDAP协议使用远程codebase的选项，把LDAP协议的攻击途径也给禁了。

       使用1.8.0_的情况下，将trustURLCodebase属性设置为true也没复现成功，原因暂未深究。

       2. 模拟被攻击的应用服务器

       写一个springboot项目，模拟被攻击的应用服务端登录接口，接口中打印了userName参数日志，启动此项目。端口为。访问地址为 .0.0.1:/login

       3. 编写恶意代码

       写一个在应用服务端执行的恶意代码，这里用删除一个服务器文件做演示，LSZJ指标源码实际上可以使用反弹shell等做更多有害操作。编译这个类，生成class文件。

       4. 启动/.html中学习了一个技巧：使用ptype /o struct xxx显示结构体信息与偏移。

       构建流程如下：通过漏洞溢出至nft_jumpstack结构体，并修改rule变量指向可控内容的地址。同时，将lastrule值篡改为大于rule的值。接下来，在可控内容中伪造一个nft_rule_dp结构体，篡改第一个八个字节（填充位）和第二个八个字节（函数表指针）的值，使其分别指向可控内容的地址。之后，在该地址处伪造nft_expr，将ops变量指向所需执行的函数。

       分析后得知，通过上述手段可以实现程序流程的劫持。接下来，kibana源码代码需要考虑如何伪造上述结构体。在nft_payload_copy_vlan函数中，漏洞点在于将vlan头数据复制到寄存器中，由于vlan头地址低于寄存器地址，导致在复制完vlan头后会覆盖寄存器值。这里，我们可以通过控制NFT_REG_的值来实现对jumpstack结构体的篡改。

       由于可以控制regs变量，首先泄露regs地址，然后在此基础上伪造rule并重新指向jumpstack。这里采用将last_rule设置为函数地址的技巧，以节省八个字节的空间。然而，仅控制八个字节的函数指针不足以构造完整的ROP链，因此需要使用栈迁移。栈迁移的目标是控制一段内存，选择regs作为目标。

       在寻找合适的cpy指标源码栈迁移gadget时，作者使用了vmlinux-to-elf工具提取符号表，然后利用ropper工具搜索gadget。但尝试后发现大部分gadget不可用。作者最后尝试使用objdump工具提取gadget，并通过搜索add rsp.*等指令找到栈迁移的gadget。进一步计算栈顶与regs函数地址的差值，找到相应的栈迁移gadget。

       在提权方面，作者通过覆盖modprobe_path实现提权。选择合适的gadget将rdi设置为modprobe_path，rax设置为覆盖后的路径。然而，在返回到nf_hook_slow函数时，由于设置了rax值导致状态码无法正确设置，程序跳转至NF_DROP分支，导致内核异常。最终，作者在rbp中找到了一个do_softirq函数，并尝试将其作为返回地址。运行后发现程序能够正常返回到用户态。

       最后，验证新用户是否已写入至/etc/passwd文件中，完成提权过程。完整exploit代码可参考github.com/h0pe-ay/Vuln.../poc.c。相关资料参考链接包括github.com/TurtleARM/CV...

Heap Spraying什么是Heap Spraying

       堆喷射（Heap Spraying）是一种在计算机安全领域中常见的技术手段，用于获取任意代码执行的Exploit。它被描述为Exploit源码中使用的一种技术。其核心目标是将自身大规模地分配至进程堆栈，并以正确方式填充命令，以实现预定内存位置的命令写入，通常依赖于堆喷射执行时堆栈区域始终位于同一位置的特性。

       堆喷射技术依赖于内存管理机制中的堆区域。在程序运行时，内存分配器会为新创建的对象分配空间。堆喷射代码通过巧妙地利用这些分配行为，将自身代码部署在进程的堆内存中。这一过程不仅涉及对内存的分配，还涉及对分配后空间的控制，确保这些空间在执行时能够承载特定的命令序列。

       在实现堆喷射时，攻击者通常会构造特定的数据结构或利用缓冲区溢出，将恶意代码注入到目标进程的堆内存中。这些注入的代码随后可以被直接或间接执行，从而实现特定的攻击目标，如代码执行、权限提升或数据泄露等。

       堆喷射技术之所以有效，部分原因在于它的隐蔽性和复杂性。攻击者可以利用堆喷射来绕过一些基于内存检查的安全机制，从而在目标系统上执行恶意代码。这种技术在零日漏洞利用和高级持续性威胁（APT）攻击中特别有用，因为它们通常需要高度定制和复杂的攻击策略。

       总结而言，堆喷射是一种旨在利用堆内存分配和控制机制的攻击技术。通过将恶意代码部署到进程堆栈中，并在特定位置执行，攻击者可以实现任意代码执行，从而对目标系统造成损害。了解堆喷射的工作原理对于开发安全的软件和防御此类攻击至关重要。

Gitlab Cookie 反序列化漏洞研究

       Gitlab Cookie 反序列化漏洞研究

       在hackthebox的Laboratory靶机中，我遇到了一个利用Gitlab任意文件读取漏洞进行getshell的过程。尽管很多walkthrough提到了漏洞利用，但对getshell原理的解释不够详尽，这让我感到疑惑。因此，我决定深入探究。

       漏洞源头始于Hackone上William Bowling (vakzz)的报告，指出UploadsRewriter函数的文件名验证漏洞，导致了任意文件读取。Gitlab最初评估该漏洞价值美元。然而，作者发现当cookies_serializer默认设置为：hybrid时，可能导致远程命令执行漏洞。他提供了一个代码示例，但对不熟悉Ruby的我来说，操作起来并不顺利。

       作者通过发送数据包执行命令，结果在带有Gitlab的rails console上实现了命令执行。阅读作者的PDF文档，虽然英文有些吃力，但了解到cookie被分为两部分，第一部分是Base编码的session哈希，第二部分是用secret_token生成的签名。关键在于，客户端控制的cookie允许用户输入自定义序列化对象，只要能伪造签名，攻击者就能在服务器上执行任意代码。而secret_token的存在使这一过程变得可能，但其安全性取决于开发者是否妥善保管。

       在Metasploit源码中，我寻找关于Gitlab cookie反序列化攻击的资料，但未果。最终，我直接分析了msf模块multi/http/gitlab_file_read_rce的执行过程。源码中的exploit函数和build_payload函数构建了反弹shell。经过多次测试和解码，我提炼出了Ruby生成payload的简化脚本，最终成功构造了能够执行命令的Cookie。

       通过这次研究，我深刻认识到技术能力的不足耗费了大量时间。经过两天两夜的努力，我才解决了这个问题，也更加理解了Gitlab Cookie反序列化漏洞的原理。