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地址：

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

将上述所找到的三个内存地址填写在20145211exploit.c中：
删除刚才调试编译的20145211exploit程序和badfile文件，重新编译修改后的20145215exploit.c，gcc -m32 -o 20145211exploit 20145211exploit.c
先运行攻击程序20145211exploit，再运行漏洞程序20145211retlib，攻击成功，获得了root权限,ls一波：

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