2015年8月21日星期五

Heap exploitation

bamboofox 暑期訓練課程，主要介紹 glibc 中 malloc 怎麼去運作，以及相關的 exploit 技巧

Heap exploitation from Angel Boy

2015年7月6日星期一

Execution of ELF

Bamboofox 暑期訓練課程，主要介紹 Linux 底下的執行檔是怎麼被運行的，以及 Lazy binding 機制

Execution from Angel Boy

2015年7月2日星期四

SROP

非常有趣的 ROP 技巧，不需要找多一點的 gadget 就可以完成想做的事情，不過最大的缺點在於可以塞的空間要夠大才行

Sigreturn Oriented Programming from Angel Boy

Return to dl-resolve

前陣子在玩的一個小技巧，某些時候特別好用，附上前陣子在 Bamboofox 分享的投影片

Return to dlresolve from Angel Boy

2015年4月28日星期二

PlaidDB [550]

程式行為及概述

如名稱所述是個 database 的 service ，可加入資料進 db，而每筆資料都配合一組 key，並以 binary tree 的方式去儲存，其中每個 node 都有個 row struct 大致上如下

struct row {
char *key
int size
char *content
row *left
row *right
row *parent
bool is_leaf
}

而他有的功能如下

GET
- 分配放 key 的空間，輸入 key ，可獲得 db 的內容，最後再把剛分配的空間 free 掉
PUT
- 一開使會先分配 0x38 byte 放置 row ，再分配 8 byte 放 key，再依據所輸入的 size 大小，分配相對應的空間給你，而在輸入 key 時會檢查所輸入 key 的空間夠不夠用，一旦不夠用就會重新 realloc 兩倍的空間給你
DUMP
- 會將所有 key 的資訊 dump 出來
DEL
- 分配放 key 的空間，輸入 key 之後，會先比對是否 key 是否有在 tree 中，若有，則將相對應的 key、content、row 及用來比對 key 依序 free 掉，*若無則返回 menu 選單（並沒有將剛剛用來比對的 key free 掉），這部分在後續排 heap 的階段頗好用 *
EXIT
- 離開程式

漏洞

NULL byte overflow
- 再所有輸入 key 的功能中一旦把 key 輸入完就會在結尾補上零，然而在輸入的 key 剛好是最大分配的空間時，並不會重新 realloc 而卻也會在最後補上 \x00 此時，造成了 overflow ，並蓋到了 malloc_chunk 中的 size 欄位

保護機制

CANARY : ENABLED
FORTIFY : ENABLED
NX : ENABLED
PIE : ENABLED
RELRO : FULL

漏洞利用及思路

此題一開始想觸發 unlink，但發現難以利用，很難找到一個 pointer 指回自己，也沒有看出可以 leak memory 的地方，後來看到了 google project zero 及 Glibc Adventures: The Forgotten Chunks 的用法，才理解到這題主要在考的是讓 chunk overlap 的情況，其中大致上的概念如下
- 一開始先 malloc 三塊相鄰的 chunk
- 接著 free(B)
- Null byte overflow ，這時候 libc 會認為這塊 chunk 剩下 0x100 的空間，但 c chunk 的 prev_size 卻是紀錄還有 0x120 byte
- malloc(D) 會先從剛加入 unsortbin 的 chunk 中切出 chunk
- malloc(E) 一樣從未分配完的 chunk 在切出空間來給 user
- free(D) 此時 D 也會被加入 unsortbin
- free(C) 此時 free 會根據C 這塊 chunk 的 prev_size 去找尋上一塊chunk 因此會認為 D 開始到 C 前都是同一塊 chunk 並認為這塊 chunk 有 0x120 byte 卻不知道中間已經有一塊已經分配出去的 chunk ，並將它們合併成 0x220 byte的 chunk
- malloc(0x200) 再次 malloc 夠大的空間時，會將之前已經分配出去的 chunk 一併也取進來，但使用者可以任意寫入該區內容，也就是 E 這塊 chunk 可以任意被改動，這題剛好就是讓 plaiddb 的row struct落在這一塊而被任意改動
利用上述的手法改道舊有的 row struct 其實就已經差不多了，可微調 size 大小，讓舊有的 key 也落入 overlap 的 chunk 中，並很巧妙的 free 掉時，讓 free 將 bin 的位置剛好填入舊有的 key 之中，並用 DUMP 就可以 leak 出 libc 的 base ，接著將舊有的 row 夠造成下列的形式

payload = pack64(binsh)
payload += pack64(7)
payload += pack64(0)
payload += pack64(free_hook)
payload += pack64(free_hook-0x30)
payload += pack64(free_hook)
payload += pack64(system)

接著在 DELE 時，就會將 system 寫入 free_hook 的欄位中，當下次在 free 時等同於也執行了 system，不過當 DELE 動作快結束時就可以拿到 shell ，這邊其實只要稍微 trace 或是用 binary tree 刪除節點的概念就會知道他如何去寫入了，細節我就不多寫了

心得

很可惜的沒在兩天內解完，最後都排得差不多了，但時間還是差一點點，寫 explit 速度還是太慢，這題的關鍵主要在排 heap 的部分，因為 fastbin 並不會觸發 unlink 不容易達成上述描述的情況，必須想辦法利用 key 來製造 smallbin 的大小，至於排的過程就不詳細描述了，如果有時間的話大家可以去解解看慢慢體會一下 :-)

Exploit

exploit

2015年4月2日星期四

程式概述

freenote 為一個類似筆記功能的程式，這個程式分別有 List , New , Edit , Delete 四個主要的功能及 Exit 結束程式

會用個 note struct 去紀錄每個筆記是否為有效筆記、筆記大小及指向筆記內容的 pointer

struct note{
    int isValidNote; // 0 = not valid, 1 = valid
    int length;
    char content;
}

程式行為

經過 ltrace 分析之後，可發現到一開始程式會先 malloc(0x1810) 用來存放這些 note struct，並以陣列的形式去儲存，其中的 index 即為筆記的編號，在最前方也紀錄共有多少筆記
- List
  - 會列出每個筆記的內容（也就是內容 pointer 所指向的地方），這裏使會列出筆記為isValidNote == 1 的內容
- New
  - 再輸入你要的大小之後，如果小於 128 byte 就會分配 128 byte 給你，但如果大於 128 byte 例如 252 byte ，那麼就會給你 128 + 128 byte 的大小，依此類推
- Edit
  - 在輸入完要編輯的筆記及大小之後，程式會先判斷這個大小是否與之前的一樣，如果一樣則不會重新分配空間直接編輯內容，如過不一樣則會 realloc 夠你筆記大小的空間給他，不過這部分會先看原先分配空間的後面是否有足夠用的空間給他，如果夠用的話就不會改變起始位置
- Delete
  - 輸入完要刪除的筆記後，會將 note[i] 中的 isValidNote 改成 0，在 free(note[i]->content)，並將筆記總數 - 1

漏洞

Double free
- 在 Delete 時，並不會將筆記從 note[i] 中移除，只是將 isValidNote = 0 ，而 free 是根據 note[i] 去決定要 free 哪邊，並沒有先去檢查 note[i]->content 是否已經被 free 掉，一旦輸入同樣的 i 就會造成 double free 的漏洞
Memory leak
- 因在輸入筆記後，程式並沒有在使用者輸入的內容最後方補上 \0 ，因此在 free(note[i]) 之後，該空間會被加入 free chunk 並有 fd 及 bk 欄位，會指向 heap，當 note[i-1] 使用 edit 加大空間後，可巧妙的接續在 fd 或 bk 之前，而在使用 List 之後便可 leak 出 heap 中上次 free 掉空間的位置，這些位置的 offset 都是固定的，因此可以算出 heap base

漏洞利用及思路

為了要利用 double free 這個漏洞去改其他位置的值，必須先觸發 unlink() 不過要觸發 unlink() 必須滿足下列三個條件其中一種：
- 如果下一塊是 top chunk，且上一塊是 free chunk
  - 最後合併到 top chunk
- 如果下一塊不是 top chunk
  - 上一塊是 free chunk
  - 下一塊是 free chunk
然而紀錄上一塊是不是 free chunk 的及大小資訊（ free 是利用這些資訊去尋找上一塊 chunk 位置），會記錄在目前這塊 chunk 的 meta 中，也就是說要確定該快 chunk 是否為已經 free 的狀態是由下一塊的 chunk 所決定的，所以如果使用下一塊是 free chunk 這個條件必須改到下下一塊 chunk 的 meta data 或是利用特殊的方法欺騙 free() 下下一塊的位置，也就是必須動到三塊的 chunk 的 meta data，所以這部分稍微會比較麻煩一點點，故決定採用上一塊是 free chunk 這個條件來達成。
leak heap
- 建立四塊左右的 note，delete 0,2 塊，再利用前面所述的方法，算出 heap 位置
構建 fake chunk
- 先 new 三塊 note 之後，delete 第二塊的，再利用 edit 加大第一塊的空間，使得可以蓋過第二塊的 meta data起初大概的改法如下
- 但使用後缺發現會一直出現 double linked corruption
- 仔細查看後才發現到原來有 FD->bk != P || BK->fd != P 這項保護的機制在，不能直接改，因此必須找到滿足 P->fd->bk == P 及 P->bk->fd == P 的 pointer，才有機會利用
- 過了很久才想到在 note[i] 中都有指向 content 的 pointer 只要稍作修改就可偽造不同 size 的 chunk 讓 free 以為 note[i]->content 所指的位置為 chunk 的 head，這一步應該就是最關鍵的地方，也是讓我卡比較多時間的地方，其最後改法如下圖所示（黃框為 fake chunk ）：
- 在 delete note[1] 也就是 free(note[1]->content) 之後便可成功改到 note[0] 讓
  - note[0]->content = &(note[0]->content)-0x10 亦及 FD->bk = BK
  - note[0]->content = &(note[0]->content)-0x18 亦及 BK->fd = FD
- 因此 note[0]->content 位置就變成了 &(note[0]->content)-0x18 ，這樣就可以利用 edit 任意更改 note[i] 的內容
更改 note[i]
- 我這邊稍作了修改將 note 變成六塊
  - 第 0-1 塊用來 leak heap 位置用
  - 第 2-3 塊用來更改 note[i] 的內容
  - 因此只要再次用 edit 更改同樣大小的內容，便可改掉整個 note，這部分定要跟之前說 new 的大小相同，否則會重新 realloc 會失敗，示意圖大概如下
  - 第 4-5 塊最後會用來改 atoi 的 got
    - 事實上可以不用這麼多塊，但只是怕亂掉所以每塊都分開
- 再來將 note[i] 部分內容改成 free_got 及 atoi_got 位置
- 使用 list 後，可利用 got 來算出 libc 的位置
改 got
- 再用 edit 更改 note[5] 後，便可將 atoi 的 got 內容改為 system
跳轉到 system
- 直接輸入 /bin/sh 就會去執行 system('/bin/sh')，這樣就拿到 shell 了
exploit exploit

心得

這次 0ctf 題目算是不會很難，只是不知道為什麼第二天就體力不支了，整整兩天只解了 freenote 這題，不過這次題目出的我個人覺得還算不錯，也挺好玩的，只是實力與經驗還需再加強，也要再多多練一下其他領域的題目，不然每次解 pwn 之外的題目都幾乎不會解，就連最簡單的 SQL injection 都會有點問題，不過我覺得 freenote 這題是很棒的一題，可以拿來練習 heap exploition 的部分，未來有時間再來整理有關 heap exploition 的資料。

2015年1月28日星期三

GHOST : The Vulnerability of Glibc

前言

偶然間在網路上看到了一個名為 Ghost 的漏洞，所以稍微整理一下，以方便自己理解，背景知識為敘述漏洞時可能需要知道的地方，由於網路上文件頗多，這裡僅挑一些 link 作為參考，便不在此多談。

背景知識

vulnerability
- Buffer overflow
- Heap overflow
protection
glibc

受影響版本

glibc 2.2 - 2.17

漏洞概述

簡單來說在 glibc 中的 __nss_hostname_digits_dots() 這個 function 中存在著 buffer overflow 的問題，而會 call 這個 function 的則是 gethostbyname*() 系列的 function ，這系列 funtion 主要是用來做 IP 和 hostname 的轉換也就是所謂的 DNS Query ，但是當給的 hostname 已經本身就是 IP 的型態呢？為了這種情況 glibc 便在 __nss_hostname_digits_dots() 加了判斷只要是 IP 的型態，便會跳過 DNS 查詢，然而這個地方卻發生了 buffer overflow 的問題，但 payload 必須符合下列條件

第一個字元必須是數字
最後一個不能為 dot (.)
全部都必須是數字跟點
需要夠大，足以 overflow

然而既然不能塞任意的 shellcode ，卻為什麼還是非常危險呢？這裡可能必須先知道 free chunk 是什麼？簡單來說是 glibc 中 malloc 管理分配記憶體的一個機制，會將目前為 free 的空間分成許多 chunk 並用 linked-list 串起來，只要 malloc 一個空間，就會從這個 linked-list 拿出來，主要是為了不讓分配的空間支離破碎，而這紀錄這些資訊的地方就是在每個 chunk 中最前面的地方，存有這個 chunk 是不是 inused 或是這個 chunk 大小多大等等資訊，更詳細的內容可參考這篇，或者是自行 google。

回到主題，為什麼這樣的問題會如此危險？原因是 overflow 之後攻擊者可以利用它去更改 heap 中，鄰近的 free chunk 的 header，以增加 free chunk 大小，要是後面又接著程式已使用的空間，那麼當系統在 allocate 給 user 這段空間時，便能任意更改程式所存在記憶體中的資訊，也有機會造成 memory leak 的問題，而且可以繞過 (ASLR,NX) 等保護。

漏洞細節

漏洞發生的 function 為 __nss_hostname_digits_dots() 主要在 hostname 為 IP 時就會使用到這個 function，而這個 function 的 code 中

85      size_needed = (sizeof (*host_addr)
86             + sizeof (*h_addr_ptrs) + strlen (name) + 1);

size_needed 會先去計算儲存 host_addr, h_addr_ptrs, 和 name (the hostname) 這三個空間的大小，接下來的 code 主要是確認預先分配的 buffer 是否夠大，要是不夠大則會再分配更大的空間給他，不過分成 reentrant 跟 non-reentrant 兩種 case ，這裡小提一下什麼 reentrant 跟 non-reentrant 的差別，差別在於主要是可是重複執行及不可重複執行的程式碼，像是遞迴的 code 都是使用 local variable 的，所以基本上重複執行沒問題，但如果 code 使用到的是 static variable 並且是在 multi thread 的情況下，很有可能就會有 Race condition 的情況發生，詳細的就不在這裡多說了。

reentrant

 88   if (buffer_size == NULL)
 89     {
 90       if (buflen < size_needed)
 91         {
 92           if (h_errnop != NULL)
 93         *h_errnop = TRY_AGAIN;
 94           __set_errno (ERANGE);
 95           goto done;
 96         }
 97     }

non-reentrant

 98       else if (buffer_size != NULL && *buffer_size < size_needed)
 99     {
100       char *new_buf;
101       *buffer_size = size_needed;
102       new_buf = (char *) realloc (*buffer, *buffer_size);
103
104       if (new_buf == NULL)
105         {
106           save = errno;
107           free (*buffer);
108           *buffer = NULL;
109           *buffer_size = 0;
110           __set_errno (save);
111           if (h_errnop != NULL)
112         *h_errnop = TRY_AGAIN;
113           *result = NULL;
114           goto done;
115         }
116       *buffer = new_buf;
117     }

接下來就是最關鍵的地方

121       host_addr = (host_addr_t *) *buffer;
122       h_addr_ptrs = (host_addr_list_t *)
123     ((char *) host_addr + sizeof (*host_addr));
124       h_alias_ptr = (char **) ((char *) h_addr_ptrs + sizeof (*h_addr_ptrs));
125       hostname = (char *) h_alias_ptr + sizeof (*h_alias_ptr);

從上面可以看到 buffer 的部分一共有四個不同的 pointer 指向他的的記憶體區塊，分別是 host_addr, h_addr_ptrs, h_alias_ptr, 和 hostname，但回頭看看剛剛 size_needed 那部份的 code 卻沒有計算到 sizeof (*h_alias_ptr) 的部分，因此我們可以 overflow 一個 char pointer 的大小，說到這裡可能又頭昏了，只好用圖來說明：

下圖是說明 buffer 這個空間是透過 gethostbyname*() 去分配到的 heap 中的記憶體區塊，並且有四個 pointer 分別指到其中的一部分
然而 size_needed 卻少計了 sizeof (*h_alias_ptr) ，讓系統以為所分配的大小夠塞全部的東西

但接下來這段 code 就是造成 overflow 的地方，主要是將 name 的內容塞到 hostname 所指的記憶體區塊

157           resbuf->h_name = strcpy (hostname, name);

問題來了，假設 size_needed 剛好為預先分配的最大值 1024 ，那麼這時候 hostname 所指的位置應該只剩 sizeof(name)-sizeof(*h_alias_ptrs) 的空間可以放而已，因此當 name 複製到 hostname 時就會造成 overflow，就如下圖所示

這就是這次漏洞的主要問題點，不過要走到這項流程必須符合之前所說的條件才會達成，更詳細的內容請參考 Qualys 所釋出的漏洞分析，上面有更詳細的說明及測試。

POC

可測試系統中是否為安全的，使用方式為，請將下列程式碼寫入 ghost.c 檔案中，然後執行

$ gcc ghost.c -o ghost
$ ./ghost
# 如果出現 vulnerable 那麼就代表系統中存在這個風險

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

受引響的服務

Exim、clockdiff、pppd 等調用 gethostbyname*() 的服務新增 wordpress 等 php 相關的 CMS 也有機會受影響

排除名單

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd. 雖然上述是目前應該不會有問題的，但還是建議更新一下 glibc 以防萬一

同場加映

這幾天下來又有研究人員發現以 php 所寫的相關應用也都有機會受到影響，像是 wordpress 等等 CMS ，攻擊者有機會藉由惡意的 domain 來觸發 ghost 這個漏洞，危害極大，所以老話一句，無論如何都請更新 Glibc ，以確保伺服器的安全。

修補方式

Debian 系列

# apt-get clean 
# apt-get update
# apt-get upgrade
# reboot

Red Hat 系列

# yum clean
# yum update
# yum install glibc*
# reboot

其他各版本的修補方式可參考這篇

Reference

Qualys Security Advisory CVE-2015-0235 glibc Cross Reference Freebuf threatpost

附註

如上述內容有任何錯誤的地方歡迎留言告知

2015年1月20日星期二

CTCTF

這場 CTF 是交大程式安全及台大電腦安全課程的期末考，不過玩起來就跟真正的比賽一樣完全不像期末考，這次是以旁聽生的身份去參加，也是第一次參加現場攻防類型的 CTF ，不過因為經驗不足的關係，完全只能墊底，不過也當作一次經驗，這次實在過於注重在解題部分，並沒有考慮到要先把洞補起來，以及封包的重送等等，導致失去得分的機會，這類比賽跟以往的 Jeopardy 更有挑戰性，也相當有趣，只可惜這類比賽不多也不常見，希望哪天有機會可以多出去玩玩看，也希望能在這段時間能多多訓練自己，這條路實在是太廣了。

在這做個小筆記好了，未來有機會在玩這類型的比賽時，可以更快地上手

賽前準備
- 寫好可以直接送封包 data 的 script
- 寫好可以直接送 key 的 script
- 寫好 exploit 大致上的雛形
- 寫好 wrapper .......
- 安裝好各項工具
- gdb , wireshark , tcpdump , IDA ......
賽中
- 先把已知道洞補起來！！！
- 盡量在其他組別解出來前先解出來，雖然很不容易 XD
- 要有人做封包分析及備份
- 一旦有人攻擊成功，立即找出攻擊的封包，並利用它來送給其他組，以防與他組分數落差太大
- 分析完立刻補起漏洞
結束後
- 分析嚴重失分原因
- 分析分工是否妥當
- 下次該如何應對

訂閱：文章 (Atom)

2015年8月21日 星期五

2015年7月6日 星期一

2015年7月2日 星期四

2015年4月28日 星期二

PlaidDB [550]

程式行為及概述

漏洞

保護機制

漏洞利用及思路

心得

Exploit

2015年4月2日 星期四

程式概述

程式行為

漏洞

漏洞利用及思路

心得

2015年1月28日 星期三

前言

背景知識

受影響版本

漏洞概述

漏洞細節

POC

受引響的服務

同場加映

修補方式

Reference

附註

2015年1月20日 星期二

CTCTF

2015年8月21日星期五

2015年7月6日星期一

2015年7月2日星期四

2015年4月28日星期二

2015年4月2日星期四

2015年1月28日星期三

2015年1月20日星期二