安全代码

I spent a couple of hours tonight reversing the vulnerable code responsible for the MS08-067 vulnerability. This bug is pretty interesting, because it is in the same area of code as the MS06-040 buffer overflow, but it was completely missed by all security researchers and Microsoft. It’s quite embarassing.

Here’s the code of the vulnerable function on Windows XP SP3 and Vista SP1:

#include <wchar.h>

// This is the decompiled function sub_5B86A51B in netapi32.dll on XP SP3

// and sub_6EA11D4D on Vista SP1



int ms08_067(wchar_t* path)

{

    wchar_t* p;

    wchar_t* q;

    wchar_t* previous_slash = NULL;

    wchar_t* current_slash  = NULL;

    wchar_t  ch;

 Read the rest of this entry »

	  

POC, 听说蠕虫已经出来了。大家赶紧打补丁，呵呵

http://milw0rm.com/sploits/2008-ms08-067.zip

看资料是因为solaris 10 默认限制了root ssh 远程登录

/etc/ssh/sshd_config的两个参数
PermitRootLogin yes

PasswordAuthentication yes

不过还有另外一种方法，一般在/etc/default/login文件中

有 “CONSOLE=/dev/console”

一行，则表明root不能直接登陆，只需注释掉该行，即可以直接登陆。

1. 破坏隐藏文件显示

HKU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden的值修改为0×00000002

2. 禁止文件执行

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

3. 隐藏文件的实现暂时没时间看，有空补上。

随着 SQL INJECTION 攻击的明显增多，微软近日发布了三个免费工具，帮助网站管理员和检

挂钩 NtResumeThread 实现全局Hook

zhouzhenster[at]gmail.com
zhouzhen[E.S.T]

挂钩一直是Hack 编程中永恒的主题，基本高级的Rootkit 程序多多少少都会使用Hook 技术。
似乎Hook 都被讲烂了，不论是Ring3 的还是Ring0 的网上都有例子。Ring0 的毋庸置疑当然
是全局的了，这里说说ring3 的全局hook。Ring 3 有Ring 3 的优势，稳定是压倒一切的，
因此Mcafee 和其他一些商业的安全软件都还是使用了Ring3 的Hook 技术，无论如何用户是
无法接受蓝屏和死机的。

感兴趣的可以装个Rootkit unhooker 自己看看。

1. 以往的Ring 3全局Hook

纵观网上流行的全局Hook 程序都只用了一个Windows API， SetWindowsHookEx，此函数原型：

HHOOK SetWindowsHookEx(
int idHook,
HOOKPROC lpfn,
HINSTANCE hMod,
DWORD dwThreadId
);

idhook 安装的钩子类型，如 WH_GETMESSAGE，WH_KEYBOARD 等
lpfn hook procedure 的指针
hmod 包含 hook procedure DLL 的handle
dwThread 为0

使用这个API是有问题的，只能挂接系统中的所有G U I线程，换句通俗的话说就是有界面
的程序，Windows console 类的程序就无能为力了。

还有一种通过插入注册表来实现

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

这种方法简单，但是还是只能挂钩GUI 程序，并且这个键值已经被广大HIPS 所关注，吃力不讨好。

以上两种效果不好，因此有人有开始另外的做法，枚举所有进程，插入和挂钩 NtCreateProcess
这是非常自然的想法，似乎也把问题解决了，但是仔细思考一下，就会发现很多问题。

a. 时机不对，在NtCreateProcess函数被调用时进程并没有真正被创建，我们无法执行HOOK操作，
而当NtCreateProcess返回时，进程又已经开始运行

b. 如果是Windows console 创建的进程，你如何去监控这个调用呢？这么说似乎比较抽象，你可
以这么理解，直接在命令行下，cmd，cmd，cmd …. 你可以监控到最后一个cmd 吗，如果只
用SetWindowsHookEx

c. 是否正好站在了华容道，是否足够底层。

似乎很费劲

2. 分析系统创建进程过程，寻找方法

关于这方面内容，可以参考毛德操老师的两篇文章

《漫谈兼容内核之十七:再谈Windows的进程创建》

《漫谈兼容内核之二十二:Windows线程的调度和运行》

下面是他的blog 链接：
http://hi.baidu.com/fatbsd/blog
Read the rest of this entry »

全部内容在http://bbs.janmeng.com/thread-689183-1-1.html

这里摘录关键部分，说白了也没啥：

调用PostMessageA，向窗口持续发送消息，消息Msg从0到499！
UPX0:00402E26
UPX0:00402E26 loc_402E26: ; CODE XREF: sub_4029C7+F9 j
UPX0:00402E26 ; sub_4029C7+10F j
UPX0:00402E26 ; sub_4029C7+135 j
UPX0:00402E26 ; sub_4029C7+158 j
UPX0:00402E26 ; sub_4029C7+16E j
UPX0:00402E26 ; sub_4029C7+184 j …
UPX0:00402E26 mov esi, PostMessageA
UPX0:00402E2C xor ebx, ebx
UPX0:00402E2C
UPX0:00402E2E
UPX0:00402E2E loc_402E2E: ; CODE XREF: sub_4029C7+476 j
UPX0:00402E2E push edi ; lParam
UPX0:00402E2F push edi ; wParam
UPX0:00402E30 push ebx ; Msg
UPX0:00402E31 push dword ptr [ebp+8] ; hWnd
UPX0:00402E34 call esi ; PostMessageA
UPX0:00402E36 inc ebx
UPX0:00402E37 cmp ebx, 1F4h ; 500
UPX0:00402E3D jl short loc_402E2E
UPX0:00402E3D
显然这些发送的消息，其实是“垃圾消息”
其目的，就是要挤占目标窗口的消息队列，使目标窗口的窗口过程忙于处理这些“垃圾消息”，而用户操作时发送的有意义的操作消息，则根本来不及处理！
结果，SREng、IceSword等工具，在打开之后，用户将根本没有办法操作，因为用户操作发送给程序的消息，已经被垃圾消息挤到消息队列后面去了，得不到程序的优先响应。
这是典型的利用Windows消息驱动机制，对目标程序进行攻击使其失去响应能力的方法，有点类似于DDOS，无技术含量，但有效。

PS: 这年头猥亵方法真多，呵呵，象我这样善良的人不多了。

小技巧。但是用的人好像不多。

例子：  Windows 2000 下