add software security

lcatro · lcatro · commit 2ee6c3cf4634 · 2017-05-30T04:44:56.000+08:00
diff --git a/第一章节/操作系统与应用程序的漏洞.md b/第一章节/操作系统与应用程序的漏洞.md
@@ -0,0 +1,356 @@
+
+### 操作系统与应用程序的漏洞
+  
+  Shadow Brokers公开NSA的0 day漏洞时,很多渗透从业者与安全研究员都为之震惊.距离上一个永恒之蓝已经过去了十年(MS08-067),这十年时间里,软件开发技术与漏洞缓解技术取得很大的进步,使得漏洞挖掘和利用和以前相比变得更难了.无论是操作系统还是应用软件,产生漏洞的原理都是因为代码上的错误而导致远程代码/命令执行.在C/C++语言里,常见的漏洞类型有:<br/>
+  
+  
+  *Use after Free  --  释放后重新引用
+  
+  Use after Free 一般出现在使用到堆分配的地方,比如:malloc()或者new/delete关键字.下面是一段示例代码:<br/>
+  
+```c
+typedef struct {
+    SOCKET socket;
+    void (*send)(const unsigned char* data,unsigned long length);  //  在结构里使用回调函数能够增加代码的伸缩性,但是可能会存在潜在的问题
+    bool (*recv)(const unsigned char** data,unsigned long* length);
+} socket_client;
+
+socket_client* create_tcp_socket_client(SOCKET socket) {
+    socket_client* return_socket_client = (socket_client*)malloc(sizeof(socket_client));
+    
+    if (NULL != return_socket_client) {
+        return_socket_client->socket = socket;
+        return_socket_client->send   = socket_tcp_send;  //  适用于TCP协议的send()函数
+        return_socket_client->recv   = socket_tcp_recv;
+    }
+    
+    return return_socket_client;
+}
+
+socket_client* create_udp_socket_client(SOCKET socket) {
+    socket_client* return_socket_client = (socket_client*)malloc(sizeof(socket_client));
+    
+    if (NULL != return_socket_client) {
+        return_socket_client->socket = socket;
+        return_socket_client->send   = socket_udp_send;  //  适用于UDP协议的send()函数
+        return_socket_client->recv   = socket_udp_recv;
+    }
+    
+    return return_socket_client;
+}
+
+void destory_socket_client(socket_client* input_socket_client) {
+    free(input_socket_client);
+}
+
+//  TCP主服务关键代码
+
+while (is_server_loop) {
+    SOCKET new_client = server_accepe();
+    socket_client* new_socket_client = create_tcp_socket_client(new_client);  //  为新到来的用户连接分配socket对象
+
+    global_list_add_socket_client(new_socket_client);  //  添加socket对象到全局socket_client列表
+    create_client_server_thread(new_socket_client);  //  派发socket对象到新服务线程
+}
+
+//  服务子线程关键代码
+
+while (is_server_loop) {
+    if (!remote_socket_client->recv(&remote_data,&remote_date_length))  //  接收客户端数据
+        break;
+    
+    packet_information packet = {0};
+    
+    server_packet_resolve(remote_data,&packet_information);  //  解析数据包
+    if (setting_game_envirament(&packet_information)) {  //  操作当前游戏内的数据
+        global_list_remove_socket_client(remote_socket_client);  //  用户退出游戏,从全局socket_client列表中清除
+        
+        break;
+    }
+}
+
+destory_socket_client(remote_socket_client);  //  释放remote_socket_client
+
+return 0;  //  退出线程
+
+//  全局消息广播关键代码
+
+for (socket_client_list::iterator global_socket_client_list_index  = global_socket_client_list.begin();  //  迭代全局socket_client列表
+                                  global_socket_client_list_index != global_socket_client_list.end();
+                                ++global_socket_client_list_index)
+    global_socket_client_list_index->send(brocase_data,brocase_data_length);  //  发送数据
+```
+  
+  在这个简单的游戏服务器的代码示例里,隐藏着一个严重的Bug,就是在服务子线程里没有及时把当前的socket_client对象从全局socket_client列表中清除掉.<br/>
+  
+```c
+if (setting_game_envirament(&packet_information)) {  //  操作当前游戏内的数据
+    global_list_remove_socket_client(remote_socket_client);  //  用户退出游戏,从全局socket_client列表中清除
+
+    break;
+}
+
+destory_socket_client(remote_socket_client);  //  释放remote_socket_client
+```
+
+  当用户选择退出时,代码`global_list_remove_socket_client(remote_socket_client);`把当前的remote_socket_client从全局socket_client列表删除,但是往上面阅读<br/>
+  
+```c
+if (!remote_socket_client->recv(&remote_data,&remote_date_length))  //  接收客户端数据
+    break;
+```  
+
+  在出现网络问题的时候,客户服务线程便立即退出,没有调用`global_list_remove_socket_client`清除全局socket_client列表中保存的socket_client,于是在代码<br/>
+  
+```c
+global_socket_client_list_index->send(brocase_data,brocase_data_length);  //  发送数据
+```
+
+  会引用到一个被释放过后的对象,这样的漏洞就是use after free - 释放后重引用,看起来好像就是对数据的引用存在问题,最多也就是引起应用程序崩溃.只可惜,事情并没有向我们想象的方向发展<br/>
+  
+  在某个瞬间里,服务器接收了很多个客户端的连接(大概10000个),此时堆上面很有可能会连续分配10000相邻的socket_client对象:<br/>
+  
+```
+  注意,这些对象在堆里以16字节对齐,结构的大小为12字节,剩余的4字节将用0来对齐
+
+  sock(4byte) | send(4byte) | recv(4byte) | 0 
+  sock(4byte) | send(4byte) | recv(4byte) | 0 
+  sock(4byte) | send(4byte) | recv(4byte) | 0 
+  sock(4byte) | send(4byte) | recv(4byte) | 0 
+  sock(4byte) | send(4byte) | recv(4byte) | 0 
+  
+  ...
+```
+  
+  保留下一条连接,剩下所有的连接都通过TCP_RST重置数据包让TCP socket产生异常,触发socket_client对象的释放,堆内的9999个socket_client对象都被回收,此时被释放的堆便可以重新分配数据,但是`global_socket_client_list`并没有清空那些已经被释放的socket_client对象<br/>
+  
+  然后,客户端发送大量的数据到服务器,以至于刚好覆盖被大量释放的socket_client对象块中<br/>
+  
+```
+
+  AAAA | AAAA | AAAA | AAAA 
+  AAAA | AAAA | AAAA | AAAA 
+  AAAA | AAAA | AAAA | AAAA 
+  AAAA | AAAA | AAAA | AAAA 
+  AAAA | AAAA | AAAA | AAAA 
+
+  ...
+```
+  
+  可见,`send()`和`recv()`指向的地址不再是`socket_tcp_send()`和`socket_tcp_recv()`了,取而代之的是地址0xAAAAAAAA.黑客接下来使用广播道具触发全局广播逻辑,`global_socket_client_list_index->send(brocase_data,brocase_data_length);`就会跳到地址0xAAAAAAAA处执行代码.至此,代码执行流程已经被黑客劫持<br/>
+
+  了解操作系统的读者应该知道,操作系统有系统区域和用户区域之分,对于windows来说,0x80000000以上的内存地址属于系统区域,普通进程无法访问这个区域的地址.由于地址0xAAAAAAAA大于0x80000000,故调用`send()`函数的跳转部分则不能够被控制,所以使用0x0C0C0C0C来填充.理由是:0x0C0C0C0C不属于系统区域;0x0C0C0C0C属于较低的地址块,堆分配会优先使用这部分(这里忽略ASLR等堆分配策略);即使可以控制代码流程跳转到地址0x0C0C0C0C,但是这个地址块里保存的数据很有可能为0x0C0C0C0C,CPU会识别数据0x0C0C为汇编or al,0Ch,作为引导代码(slide code),在引导代码后面的那部分,就是黑客实际要执行的注入代码(ShellCode).<br/>
+  
+  讲述完ShellCode的构造流程之后,下一步就是要根据堆块的大小来构造堆喷射代码块.在堆里,分配数据的地方都是"随机"的,我们突破这种随机的手段就是大量申请新的内存对象,使得我们有更高的概率覆盖到之前使用到的那部分内容.10000个socket_client对象会让堆连续分配10000*4字节(0x9C40)的内存.假设ShellCode占用512字节,那么每个喷射块的大小需要小于0x9C40字节才能更有概率覆盖被释放的socket_client对象.在此,笔者让每个喷射的堆块大小限制在0x3000字节(512字节ShellCode,11776字节SlideCode),这样覆盖的概率会高一些.回顾前面,简要描述利用过程就是通过大量的异常连接引发漏洞,再通过客户端发来的大量恶意数据覆盖函数地址,最后通过调用全局广播触发漏洞,达到黑客执行恶任意代码的目的.<br/>
+
+  这段示例代码只显示了C语言里对于UaF漏洞的利用,在C++里UaF漏洞范围更广,因为C++里new和delete没有小心使用很有可能会导致UaF漏洞,也叫做野指针,悬空指针.如果觉得示例里面的结构块里面保存函数回调地址的用法比较极端,那么笔者告诉读者们,在C++里,对象的虚函数保存在一张虚函数表里,在对象内存的前一部分(占用对象的大小与继承类的数目有关),此时对象在堆内的数据结构和上面示例代码的结构大同小异.绝大多数WEB浏览器使用C++开发,与浏览器相关的很多漏洞都和UaF有关.浏览器二进制漏洞攻防多年,UaF利用难度变得越来越高,转而被更容易操作的Out-of-Bound漏洞所取代(用词语取代来形容可能不那么恰当,但是有些场景里UaF漏洞还是可以有很大的作用).<br/>
+
+
+ *Out-of-Bound  --  越界
+ 
+  Out-of-Bound 一般出现在使用到字符串和数组操作的地方,比如:memcpy()等或者数组访问越界.下面是经典的栈溢出示例代码:<br/>
+ 
+```c
+void dns_query_thread(socket_client* remote_socket_client) {  //  DNS查询服务子线程
+    dns_pack* dns_query_packet = NULL;
+    unsigned long dns_query_packet_length = 0;
+    dns_pack* dns_answer_packet = NULL;
+    unsigned char* host[HOST_MAX_LENGTH] = {0};  //  HOST_MAX_LENGTH长度为256
+
+    if (NULL != remote_socket_client) {
+        if (!remote_socket_client->recv(&dns_query_packet,&dns_query_packet_length))  //  接收数据包
+            break;
+    
+        //  省略分析DNS数据包代码
+    
+        for (int dns_query_host_index = 0;dns_query_host_index < dns_query_host_count;++dns_query_host_index) {  //  遍历DNS域名查询
+            dns_question_index* dns_answer_record = &dns_question_packet.dns_answer[dns_query_host_index];  //  获取详细记录
+            char* host_name = dns_answer_record->host_name;
+            int host_length = strlen(host_name);
+            
+            memcpy(host,host_name,host_length);  //  保存到栈
+            add_answer(dns_answer_packet,get_ip_by_host(host));  //  获取域名对应的IP
+        }
+    }
+    
+    //  ...
+}
+```
+
+  出现问题的代码在`memcpy(host,host_name,host_length);`里,host在栈贞占用256字节,当`memcpy()`复制的内存长度大于256字节时,就可以覆盖函数返回指针,控制代码执行流程,讲述至此,我们需要了解C/C++调用函数的原理<br/>
+  
+  栈和堆都是程序用来临时储存数据的地方,它们之间的区别在于栈提供给函数执行保存上下文的内存,堆是程序用来保存类对象或者更多更大的数据内存.每次调用到其它函数,栈会向下移动,退出函数时,栈则会向上移动.<br/>
+  
+  现在有main(),decrypt_data(input_data,decrypt_key)两个函数.a函数需要调用b函数,转换成汇编之后的调用代码如下:<br/>
+  
+```asm
+LEA input_data , EAX
+LEA decrypt_key , 0x402401  //  写在程序内的解密KEY
+PUSH input_data  //  传递参数
+PUSH decrypt_key
+call add  //  调用add()函数
+mov result,EAX  //  获取add()函数返回的结果
+```
+
+  初始的时候,栈里只有main()函数,栈结构如下<br/>
+
+```
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+  `PUSH`指令会向栈内保存4字节数据,两次执行`PUSH`指令之后,栈结构如下<br/>
+
+```
+|  decrypt_key |
+|  input_data  |
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+  接下来调用`CALL`指令,`CALL`指令等价于`PUSH EIP`+`JMP 函数地址`:`PUSH EIP`保存当被函数执行结束之后,应该跳转到的下一个地址;`JMP 函数地址`则是跳转到指定地址执行代码,调用完`CALL`指令之后,栈结构如下<br/>
+
+```
+|  Return_Addr |
+|  decrypt_key |
+|  input_data  |
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+  `decrypt_data()`首先会对栈进行初始化,栈结构如下<br/>
+
+```
+|  var ...     |
+|  var 2       |
+|  var 1       |
+|  Return_Addr |
+|  decrypt_key |
+|  input_data  |
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+  `decrypt_data()`执行完之后,会对栈进行调整,栈结构如下<br/>
+
+```
+|  Return_Addr |
+|  decrypt_key |
+|  input_data  |
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+  汇编通过`RETN`指令控制函数返回,`RETN`指令等价于`POP EIP`+`nPOP`+`JMP EIP`:`POP EIP`从栈中读取4字节返回地址;`nPOP`是多次调用`POP`指令,清除栈上的参数;`JMP EIP`则是跳转到上一个函数的执行地址<br/>
+
+   `POP EIP`,栈结构如下<br/>
+
+```
+|  decrypt_key |
+|  input_data  |
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+   `2POP`,栈结构如下<br/>
+
+```
+|______________|
+|              |
+|     main     |
+|              |
+```
+
+  `JMP EIP`,执行main()函数的`mov result,EAX`汇编<br/>
+  
+  了解过C/C++调用函数的过程后,栈缓冲区溢出漏洞的精髓就是在于覆盖`Return_Addr`,回过头去阅读源码<br>
+
+```c
+memcpy(host,host_name,host_length);
+```
+
+  对应的栈结构<br/>
+
+```
+|  dns_query_thread  |
+|                    |
+|      host[256]     |
+|--------------------|
+|   Return_Address   |
+|--------------------|
+|                    |
+```
+
+  如果传递进来的域名长度大于256,那么`memcpy()`复制内存将会覆盖`Return_Addr`,控制代码执行流程.栈的结构需要这样构造<br/>
+
+```
+|  dns_query_thread  |
+|                    |
+|      host[256]     |
+|--------------------|
+|   JMP ESP gadget   |
+|--------------------|
+|      ShellCode     |
+```
+
+  `JMP ESP gadget`的意思是需要找到指令为`JMP ESP`的地址,填写到`Return_Addr`之后,程序就会跳转到执行代码`JMP ESP`去,此时栈的结构如下<br/>
+
+```
+|      ShellCode     |  <-- ESP刚好指向这里
+|                    |
+```
+
+  ESP寄存器的值指向ShellCode的起始点,通过执行`JMP ESP`,控制代码流程执行ShellCode,达到远程代码执行的目的<br/>
+
+  这里用经典的栈缓冲区溢出攻击演示Out-of-Bound的漏洞利用原理.OOB在堆里也一样,利用手法则从栈的返回地址劫持变成和UaF一样的利用点(结构上的回调地址或者类的虚表劫持)<br/>
+
+
+  *Type Confuse  --  类型混淆
+  
+  要是对`sockaddr`结构有印象,那也对`sockaddr_in`和`sockaddr_in6`结构有了解.`bind()`和`connect()`函数为了提升代码健壮性,使用`sockaddr`类型来派生出`sockaddr_in`和`sockaddr_in6`结构,`bind()`和`connect()`再通过传递进来的结构长度来判断`sockaddr_in`和`sockaddr_in6`.有些场景为了提升函数的健壮性和粒度化,往往会对传递进来一个参数类型用了不同的结构来解析,潜在的问题就产生了<br/>
+  
+```c
+struct {
+    variant_type type;
+} variant;
+
+struct {
+    variant head;
+    int string_length;
+    char* data;
+} variant_string;
+
+struct {
+    variant_head head;
+    int data;
+} variant_number;
+
+
+void add(variant* output,variant* input1,variant* input2) {  //  变量相加
+    output->data = input1->data + input2->data;
+}
+
+void print_variant(variant* input_variant) {  //  显示变量的内容
+    if (TYPE_NUMBER == input_variant->type)
+        printf("%X\n",input_variant->number_value);
+    else if (TYPE_STRING == input_variant->type)
+        printf("%X\n",input_variant->string_buffer);
+}
+```
+
+  构造脚本`var a=1;var b="A";b=a+0;`,`add()`就能因为类型混淆产生写越界漏洞,由于变量`b`在初始化时为字符串为"A",所以字符串变量的data内容则指向2字节大小的堆空间里,`b=a+0`触发`add()`函数的调用,使得4字节的数据写操作越过了原来的data,产生了OOB漏洞.<br/>
+  
+  举的这个例子有些极端,类型混淆漏洞在解析引擎,文档解析器,浏览器等出现的几率较多<br/>
+ 
