Linux保护机制和绕过方式

Linux保护机制和绕过方式

CANNARY(栈保护)

​ 栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。用Canary是否变化来检测，其中Canary found表示开启。

原理

​ 函数开始执行的时候会先往栈里插入cookie信息，当函数真正返回的时候会验证cookie信息是否合法，如果不合法就停止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护检查失败而阻止shellcode的执行。在Linux中我们将cookie信息称为canary。

开启/关闭方式

gcc编译添加参数-fno-stack-protector或者-fno-stack-protector-all

gcc -o test test.c						// 默认情况下，不开启Canary保护
gcc -fno-stack-protector -o test test.c  //禁用栈保护
gcc -fstack-protector -o test test.c   //启用堆栈保护，不过只为局部变量中含有 char 数组的函数插入保护代码
gcc -fstack-protector-all -o test test.c //启用堆栈保护，为所有函数插入保护代码

绕过方式

​ 通过改写指针与局部变量、leak canary、overwrite canary的方法来绕过。

  • 格式化字符串泄露打印canary，然后通过计算offset构造ROP
  • 若存在fork()函数，当程序进入到子进程的时候，其canary的值和父进程中canary的值一样，可以通过栈溢出覆盖逐位爆破canary
  • SSP Leak(Stack Smashing Protect Leak )，利用这种方法获取到内存中的值
  • 劫持stack_chk_fail函数,stack_chk_fail函数是一个普通的延迟绑定函数，可以通过修改GOT表劫持这个函数。利用方式就是通过格式化字符串漏洞来修改GOT表中的值。通过格式化字符串漏洞来篡改GOT表中stack_chk_fail存储的地址，将它的地址修改成system("/bin/sh")函数地址，然后通过栈溢出来覆盖canary，故意触发__stack_chk_fail函数的执行，相当于执行了system("/bin/sh")函数，从而getshell

FORTIFY

​ fority其实非常轻微的检查，用于检查是否存在缓冲区溢出的错误。适用情形是程序采用大量的字符串或者内存操作函数，如memcpy，memset，stpcpy，strcpy，strncpy，strcat，strncat，sprintf，snprintf，vsprintf，vsnprintf，gets以及宽字符的变体。

原理

​ Fortify 技术是GCC在编译源码时判断程序的哪些buffer会存在可能的溢出，在buffer大小已知的情况下，GCC会把 strcpy、memcpy、memset等函数自动替换成相应的 __strcpy_chk(dst, src, dstlen)等函数，达到防止缓冲区溢出的作用。

​ FORTIFY_SOURCE机制对格式化字符串有两个限制：

​ (1)包含%n的格式化字符串不能位于程序内存中的可写地址；

​ (2)当使用位置参数时，必须使用范围内的所有参数。例如要使用%4$x，则必须同时使用1、2、3。

开启/关闭方式

GCC中-D_FORTIFY_SOURCE=2是默认开启的，但是只有开启O2或以上优化的时候，这个选项才会被真正激活。

如果指定-D_FORTIFY_SOURCE=1，那同样也要开启O1或以上优化，这个选项才会被真正激活。

可以使用-U_FORTIFY_SOURCE或者-D_FORTIFY_SOURCE=0来禁用。

如果开启了-D_FORTIFY_SOURCE=2，那么调用__printf_chk函数的时候会检查format string中是否存在%n，如果存在%n 而且format string是在一个可写的segment中的（不是在read-only内存段中），那么程序会报错并终止。如果是开启-D_FORTIFY_SOURCE=1，那么就不会报错

gcc -D_FORTIFY_SOURCE=1 仅仅只会在编译时进行检查 (特别像某些头文件 #include <string.h>)

gcc -D_FORTIFY_SOURCE=2 程序执行时也会有检查 (如果检查到缓冲区溢出，就终止程序)

gcc -o test test.c							// 默认情况下，不会开这个检查
gcc -D_FORTIFY_SOURCE=1 -o test test.c		// 较弱的检查
gcc -D_FORTIFY_SOURCE=2 -o test test.c		// 较强的检查

NX（DEP）堆栈代码执行保护

原理

​ NX即No-eXecute（不可执行）的意思，NX（DEP）的基本原理是将数据所在内存页标识为不可执行，当程序溢出成功转入shellcode时，程序会尝试在数据页面上执行指令，此时CPU就会抛出异常，而不是去执行恶意指令。

开启/关闭方式

gcc编译器默认开启了NX选项，如果需要关闭NX选项，可以给gcc编译器添加-z execstack参数。

gcc -o test test.c					// 默认情况下，开启NX保护
gcc -z execstack -o test test.c		// 禁用NX保护
gcc -z noexecstack -o test test.c	// 开启NX保护

绕过方式

​ 使用 ROP（Return-Oriented Programming）绕过

如ret2data、ret2libc、ret2strcpy、ret2gets、ret2syscall
gadget:virtualprotect、jmp esp、mona.py

PIE（ASLR）

​ 一般情况下NX（Windows平台上称其为DEP）和地址空间分布随机化（ASLR）会同时工作。

（1）ASLR（Address Space Layout Randomization）：

​ 地址随机化，通常用来防御return2libc攻击。

（2）PIE（Position-Independent Executables）：

​ 位置无关的可执行文件，和Windows下的ASLR（Address Space Layout Randomization)机制类似，PIE enabled表示程序开启地址随机化选、意味着程序每次运行的时候地址都会变化。主要是为了解决二进制本身地址已知的问题，可用来防御return2elf和其他已知地址读写问题。

原理

​ 内存地址随机化机制（address space layout randomization)，有以下三种情况：

0 - 表示关闭进程地址空间随机化。
1 - 表示将mmap的基址，stack和vdso页面随机化。
2 - 表示在1的基础上增加栈（heap）的随机化。

​ 可以防范基于Ret2libc方式的针对DEP的攻击。ASLR和DEP配合使用，能有效阻止攻击者在堆栈上运行恶意代码。

​ Built as PIE：位置独立的可执行区域（position-independent executables）。这样使得在利用缓冲溢出和移动操作系统中存在的其他内存崩溃缺陷时采用面向返回的编程（return-oriented programming）方法变得难得多。

开启/关闭方式

sudo -s echo 0 > /proc/sys/kernel/randomize_va_space

gcc -o test test.c				// 默认情况下，不开启PIE
gcc -fpie -pie -o test test.c		// 开启PIE，此时强度为1
gcc -fPIE -pie -o test test.c		// 开启PIE，此时为最高强度2
gcc -fpic -o test test.c		// 开启PIC，此时强度为1，不会开启PIE
gcc -fPIC -o test test.c		// 开启PIC，此时为最高强度2，不会开启PIE
  • 使用-fPIE编译的对象就能通过连接器得到位置无关可执行程序。
  • -fpie和-fPIE选项和fpic及fPIC很相似，但不同的是，除了生成为位置无关代码外，还能假定代码是属于本程序。

绕过方式

  • 寻找没有随机化的模块，直接RET替换（一般进程也会加载没有随机化的模块，可以找到JMP ESP指令的跳板直接调用）
  • 寻找没有随机化的模块，替换EIP一部分（找到没有随机化的模块然后使用利息泄漏确定EIP的位置，再算出模块的基地址，最后算出要跳的函数地址）
  • NOP喷射（DEP没开的情况下，创建一大块NOP+shellcode，Heap Spray是在shellcode的前面加上大量的slide code（滑板指令），组成一个注入代码段。然后向系统申请大量内存，并且反复用注入代码段来填充。这样就使得进程的地址空间被大量的注入代码所占据。然后结合其他的漏洞攻击技术控制程序流，使得程序执行到堆上，最终将导致shellcode的执行。统slide code（滑板指令）一般是NOP指令，譬如：0x0C（0x0C0C代表的x86指令是OR AL 0x0C），0x0D等等，不影响程序的执行的。）
  • 暴力（如果漏洞不会造成程序崩溃，可以暴力测试256种模块基地址来测试，只到有满足的）最LOW

RELRO（Relocation Read Only）重定向只读

​ 在Linux系统安全领域数据可以写的存储区就会是攻击的目标，尤其是存储函数指针的区域。 所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处.

原理

​ GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术: read only relocation。大概实现就是由linker指定binary的一块经过dynamic linker处理过 relocation之后的区域为只读.用来防御hijack GOT攻击。

​ 设置符号重定向表格为只读或在程序启动时就解析并绑定所有动态符号，从而减少对GOT（Global Offset Table）攻击。RELRO为” Partial RELRO”，说明我们对GOT表具有写权限。

开启/关闭方式

​ RELRO有Partial RELRO和FULL RELRO两个选项，如果开启FULL RELRO，意味着无法修改GOT表；如果为Partial RELRO，说明对GOT表具有写权限。在Linux下默认开启状态。

  • Partial RELRO：重定位表格只读，重定位项可读写；
  • FULL RELRO：重定位表格和重定位项均为只读（但会导致符号懒加载失效，同时会带来启动时的效率下降）；
gcc -o test test.c						// 默认情况下，是Partial RELRO
gcc -z norelro -o test test.c			// 关闭，即No RELRO
gcc -z lazy -o test test.c				// 部分开启，即Partial RELRO
gcc -z now -o test test.c				// 全部开启，即

绕过方式

​ 可通过ROP绕过

参考链接：

ELF安全防御机制小结：https://www.mi1k7ea.com/2019/02/09/ELF安全防御机制小结/

linux保护机制整理：https://my.oschina.net/u/2424583/blog/762006

Canary保护详解和常用Bypass手段：https://www.anquanke.com/post/id/177832

posted @ 2020-11-17 22:16  一点涵  阅读(2722)  评论(0)  编辑  收藏  举报