第⼀次不完整的ctf出题记录
第⼀次不完整的ctf出题记录
之前都是做题，⾄此有个机会打算挑战⼀下⾃⼰，出⼀道题⽬，了解⼀下出题的思路和过程。于是有了⼀个不完整的出题经历。我个⼈理解的出题思路应该是：
写出含有可以⽤漏洞的源代码
以合适的⽅式进⾏编译
⾃⼰编写漏洞利⽤的思路和代码，拿到Flag
出题结束
但是，，，，太菜了，⽬前只做了前两步，现在想想好像没有什么⼯作量啊…但还是简单的总结⼀下吧。
本次总结主要分为三个部分，每个部分包含操作的步骤以及学习到的内容。
1. 源代码的编写
2. 编译
3. 问题
源代码编写
事实上，题⽬是我根据最近做的⼀道题⽬改出来的，所以源代码编写的思路是：将原题的elf⽂件放进IDA中看它的源代码，然后想办法写⼀段C代码，使得该代码在编译之后和原题的ELF⽂件在IDA中的功能等效。
过程
这个题⽬的思路是：
构造⼀个ELF⽂件，可以对⼀个name变量输⼊⼀个字符串，产⽣溢出，覆盖进⽽修改⽂件描述符
然后通过构造fake file调⽤FILE中的close()函数，实现劫持程序控制流的⽬的
编译时开启栈保护，需要实现stack pivot，然后构造ROP拿到shell权限
1.在数据段中构造name和fp变量
希望将name和fp变量构造在.bss段，并且name位于低地址，fp位于⾼地址，使得对name进⾏输⼊溢出的时候，可以覆盖fp
都构造在bss段，就需要将这两个变量都设置为全局变量。实现过程中⼀直都⽆法将fp放在name的下边，定义形式如下：
⼀：
char x[20];
FILE* fp=NULL;
⼆：
char x;
FILE* fp;
三：
FILE* fp=NULL;
char x[20];
四：
FILE* fp;
char x;
尝试的解决⽅案：
1.编译时设置优化选项
gcc -O0 -O1 -O2
考虑是否是编译器在优化的时候⾃动将数组分配在⾼地址。
2.初始化是否影响溢出
样例⼀：
char x[20];
int a=0;
int main()
{......}
样例⼆：
char x[20];
int a;
int main()
{......}
现象：当对x输⼊，产⽣溢出时，样例⼀中a没有被修改，样例⼆中a被修改。
4.将fp和name定义在⼀个结构体中
fp和name在结构体中的顺序就是在bss段中的顺序，可⾏！
5.先定义⼀个int类型，然后在程序中将其赋值为⼀个FILE地址
char x[20];
int a;
int main()
{
FILE* fp=fopen("","r");
printf("the size of int is %d\n",sizeof(int));
printf("the size of double is %d\n",sizeof(double));
printf("the size of FILE is %d\n",sizeof(fp));
printf("the value of a is %x\n",a);
printf("input your name:\n");
scanf("%s",x);
printf("a is %x\n",a);
if(a!=0)
{
printf("hhhhhhhhhhhhhhhhh\n");
}
return 0;
}
发现int和FILE*的长度⼀样，都是4bytes，于是利⽤这个⽅法可⾏！
6.只要int或者double在内存中字节数与FILE* fp(即指针)在内存中的字节数相同，就可以⽤int或者其他类型来代替指针符号。证明：
int a;
double b;
FILE* fp=fopen("");
printf("the size of int is %d\n",sizeof(int));
printf("the size of double is %d\n",sizeof(double));
printf("the size of FILE is %d\n",sizeof(fp));
b=fp;
a=fp;
2.IDA反编译后的v2 = __readgsdword(0x14u);
启动了canary保护；这个不需要在源码中定义，只需要在编译时注意相关选项的设置即可。
3.ssignal(14, (int)handler);
为alarm信号设置handler处理函数。
收获
1.fopen()的返回值与FILE*
fopne()函数的返回值是⼀个指针，该指针指向FILE结构体的⾸地址。也就是说，这个指针对应的值是FILE结构体的⾸地址，⽽不是FILE结构体的第⼀个字节的内容。
2.结构体定义
结构体中的定义顺序就是bss段的存放顺序。
编译
在⽣成ELF⽂件的时候，⼀定要注意编译选项的设定，这很⼤程度上决定了这个题⽬是否能pwn以及pwn的思路和难度。
过程
gcc -m32 -O0 -Wallvisual studio和vs code的区别
收获
CANNARY(栈保护)
这个选项表⽰栈保护功能有没有开启。
栈溢出保护是⼀种缓冲区溢出攻击缓解⼿段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执⾏。当启⽤栈保护后，函数开始执⾏的时候会先往栈⾥插⼊cookie信息，当函数真正返回的时候会验证cookie信息是否合法，如果不合法就停⽌程序运⾏。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护检查失败⽽阻⽌shellcode的执⾏。在Linux中我们将cookie信息称为canary。
gcc在4.2版本中添加了-fstack-protector和-fstack-protector-all编译参数以⽀持栈保护功能，4.9新增了-fstack-protector-strong编译参数让保护的范围更⼴。
因此在编译时可以控制是否开启栈保护以及程度，例如：
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 //启⽤堆栈保护，为所有函数插⼊保护代码
FORTIFY
fority其实⾮常轻微的检查，⽤于检查是否存在缓冲区溢出的错误。适⽤情形是程序采⽤⼤量的字符串或者内存操作函数，如
memcpy，memset，stpcpy，strcpy，strncpy，strcat，strncat，sprintf，snprintf，vsprintf，vsnprintf，gets以及宽字符的变体。
_FORTIFY_SOURCE设为1，并且将编译器设置为优化1(gcc -O1)，以及出现上述情形，那么程序编译时就会进⾏检查但⼜不会改变程序功能
_FORTIFY_SOURCE设为2，有些检查功能会加⼊，但是这可能导致程序崩溃。
gcc -D_FORTIFY_SOURCE=1 仅仅只会在编译时进⾏检查 (特别像某些头⽂件 #include <string.h>)
gcc -D_FORTIFY_SOURCE=2 程序执⾏时也会有检查 (如果检查到缓冲区溢出，就终⽌程序)
举个例⼦可能简单明了⼀些：
void fun(char *s) {
char buf[0x100];
strcpy(buf, s);
/* Don't allow gcc to optimise away the buf */
asm volatile("" :: "m" (buf));
}
⽤包含参数-U_FORTIFY_SOURCE编译
08048450 <fun>:
push  %ebp              ;
mov    %esp,%ebp
sub    $0x118,%esp        ; 将0x118存储到栈上
mov    0x8(%ebp),%eax    ; 将⽬标参数载⼊eax
mov    %eax,0x4(%esp)    ; 保存⽬标参数
lea    -0x108(%ebp),%eax  ; 数组buf
mov    %eax,(%esp)        ; 保存
call  8048320 <strcpy@plt>
leave                    ;
ret
⽤包含参数-D_FORTIFY_SOURCE=2编译
08048470 <fun>:
push  %ebp              ;
mov    %esp,%ebp
sub    $0x118,%esp        ;
movl  $0x100,0x8(%esp)  ; 把0x100当作⽬标参数保存
mov    0x8(%ebp),%eax    ;
mov    %eax,0x4(%esp)    ;
lea    -0x108(%ebp),%eax  ;
mov    %eax,(%esp)        ;
call  8048370 <__strcpy_chk@plt>
leave                      ;
ret
我们可以看到gcc⽣成了⼀些附加代码，通过对数组⼤⼩的判断替换strcpy, memcpy, memset等函数名，达到防⽌缓冲区溢出的作⽤。
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保护
在Windows下，类似的概念为DEP（数据执⾏保护），在最新版的Visual Studio中默认开启了DEP编译选项。
PIE（ASLR）
⼀般情况下NX（Windows平台上称其为DEP）和地址空间分布随机化（ASLR）会同时⼯作。
内存地址随机化机制（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）⽅法变得难得多。
liunx下关闭PIE的命令如下：
sudo -s echo 0 > /proc/sys/kernel/randomize_va_space
gcc编译命令
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
PIE和PIC的区别
RELRO
在Linux系统安全领域数据可以写的存储区就会是攻击的⽬标，尤其是存储函数指针的区域。 所以在安全防护的⾓度来说尽量减少可写的存储区域对安全会有极⼤的好处.
GCC, GNU linker以及Glibc-dynamic linker⼀起配合实现了⼀种叫做relro的技术: read only relocation。⼤概实现就是由linker指定binary的⼀块经过dynamic linker处理过 relocation之后的区域为只读.
设置符号重定向表格为只读或在程序启动时就解析并绑定所有动态符号，从⽽减少对GOT（Global Offset Table）攻击。RELRO为”Partial RELRO”，说明我们对GOT表具有写权限。
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    // 全部开启，即
总结
NX：-z execstack / -z noexecstack (关闭 / 开启)
Canary：-fno-stack-protector /-fstack-protector / -fstack-protector-all (关闭 / 开启 / 全开启)
PIE：-no-pie / -pie (关闭 / 开启)
RELRO：-z norelro / -z lazy / -z now (关闭 / 部分开启 / 完全开启)
问题
1. 全局变量在bss段的存储顺序
2. NX表⽰的不可执⾏，将数据所在内存页标识为不可执⾏这个不可执⾏到底是在哪⾥不可执⾏

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。