20145211《网络对抗》注入Shellcode并执行&&Return-to-libc攻击

Shellcode注入

基础知识

• Shellcode实际是一段代码，但却作为数据发送给受攻击服务器，将代码存储到对方的堆栈中，并将堆栈的返回地址利用缓冲区溢出，覆盖成为指向 shellcode的地址。

实践过程

• shellcode的生成方法指导书上已经写得很详细了，在做实验时我直接用的是老师上课用的shellcode：
  

• 将环境设置为：堆栈可执行、地址随机化关闭
  

• 选择anything+retaddr+nops+shellcode的结构构造攻击buf，先猜测返回地址所在位置，并且找到shellcode所在地址
  

• 在终端注入这段攻击buf：
  

• 先不输入“回车”，在后面的调试过程中需要继续运行的时候再回车，此时再打开另外一个终端，用gdb来调试20145215pwn1这个进程，先找到该进程的进程ID，再打开gdb，用attach指令对该进程进行调试：
  

• 对foo函数进行反汇编：
  

• 在ret处设置断点，接着继续运行到断点处，显示当前esp的值并依照此位置显示接下来的内存地址内容，来分析我们之前猜测的返回地址位置是否正确以及shellcode的地址，然而我一开始一直没有找到，如同见鬼，再修改无数次后在勉强找到

• 

  
  

• 由上图可以看出，第一个红色方块中的内容是我们之前猜测返回地址而输入的值，第二个方块中的内容则是shellcode代码，由此我们可以推断出shellcode地址为：0xffffd3d4

• 继续运行，如红色方块中所示，可以确认返回地址是被我们之前输入的\x01\x02\x03\x04所覆盖的：
  

• 将返回地址修改为0xffffd3d4，重新注入，苍天啊，终于成功了
  

Return-to-libc攻击实验

实验内容

• return-to-libc实验是一个基于缓冲区溢出攻击实验的基础上的一种攻击实验
• 缓冲区溢出攻击相关知识：
  • 原理：通过一段包含shellcode以及shellcode地址的长字符串注入到程序中，以shellcode地址来覆盖程序原有的返回地址，从而让目标程序来执行我们的shellcode，以此达到攻击目的
  • 保护措施：为了防止缓冲区溢出攻击，现在常用的保护措施有两种，一是设置堆栈不可执行，漏洞程序在执行注入到堆栈中的shellcode时就会发生程序崩溃。二是代码生成地址随机化，以此来使得攻击者无法准确得知shellcode的地址
• return-to-libc攻击原理：
  • 为了避开堆栈不可执行的问题，return-to-libc攻击放弃了让漏洞程序执行堆栈中的shellcode，而是跳转到已经存在的代码（例如libc库中的system函数）来完成攻击

实践过程

• 首先添加用户hzy

• 

• 进入32位linux环境，将地址随机化关闭，并且把/bin/sh指向zsh：
  

• 将漏洞程序保存在/tmp目录下：
  

  
  
  

• 编译该代码，使用–fno-stack-protector来关闭阻止缓冲区溢出的栈保护机制，并设置给该程序的所有者以suid权限，可以像root用户一样操作：
  

• 读取环境变量的程序：
  

  • 将攻击程序保存在/tmp目录下：　　
• 
• 用刚才的getenvaddr程序获得BIN_SH地址，利用gdb获得system和exit地址：

 

• 将上述所找到的三个内存地址填写在20145211exploit.c中：
  

• 删除刚才调试编译的20145211exploit程序和badfile文件，重新编译修改后的20145215exploit.c，gcc -m32 -o 20145211exploit 20145211exploit.c
  先运行攻击程序20145211exploit，再运行漏洞程序20145211retlib，攻击成功，获得了root权限,ls一波：

•  

 

实践思考

• 对普通缓冲区溢出攻击的防御，一方面需要学会使用能够防止缓冲区溢出的函数，警惕攻击的发生。另一方面，可以在系统中开启类似数据执行保护机制(DEP)这样的防护机制，这样被保护程序的内存使其不能同时被写和被执行，从而防止了代码注入式的缓冲区溢出攻击。但是，这些不能有效抵御 return-into-libc ，因此还需要进一步的解决方案。
• 目前对于 return-into-libc 攻击，比较好的解决方法是地址空间随机化 ，增加了攻击者成功发起攻击的难度，同时更容易导致攻击时程序运行的崩溃，使得检测机制也更容易检测到此种攻击。