創建c:\con.txt嗎?windows文件系統漏洞

創建c:\con.txt嗎?windows文件系統漏洞 你會建立c:\con.txt嗎?--windows文件系統漏洞
唉,寫完了前面的廢話頭都昏了,有錯誤及時告訴我哦。
----------------------------
如果你在想con.txt不是很正常嗎?那好,你先去創建下,只要帶有獨立的con字樣的文件就好,然後悟出什麼了再看這篇文章(如果你用linux或者mac或者unix那就算了)。

呵呵,正常來說帶有con、prn、com1這樣字眼的文件或目錄是不能創建的(原因自己找),但我想到了以前在安全焦點的一篇文章,是教你創建帶"\"的文件夾的。當時的方法是用控制檯命令(如果你叫dos命令那是不標準的)mkdir csk..\這樣的語法創建的。看來這是windows一個文件系統的漏洞了,沒錯……

我後來就在想其中的原理,可能你會發現像上面的csk..\在創建後是csk.,而他實際被windows解釋爲訪問mkdir csk.\的目錄。看來有字符在創建時被略去了。而一次偶然機會我發現mkdir C:\con\是成功的,在c下面出現了c:\con文件夾,而且刪不掉……呵呵,有一個bug……

我這時突然想到了可能的原因:首先創建目錄時肯定要驗證正確性,而像這種C:\dir\肯定是先將\符號略去了,但後面的內容呢?看來windows似乎不去檢查了……否則mkdir c:\con\就應該失敗了,而mkdir c:\con肯定是無效的。

所以我在想是否創建的文件也能利用這個漏洞奪過windows文件系統的一些檢查呢?正如你看到的,我成功了^-^


呵呵,這可不是畫出來的哦,是貨真價實的con.txt。其實原理和我上面的猜測差不多,但由於時間有限,我的分析不一定正確,下面給出具體破解過程:
2005.8.1:23:00
首先我要知道mkdir造成漏洞的原因,於是拿出ollydbg去調試cmd.exe(mkdir是內部命令嘛,不知他找誰?)。接着對KERNEL32.CreateDirectoryW設斷點,果然在輸入了mkdir c:\con\後中斷了。自然單步跟入CreateDirectoryW:
----------------------------------------------------------------
7C81E97F 50 push eax
7C81E980 57 push edi
7C81E981 FF15 3C11807C call dword ptr ds:[<&ntdll.RtlDosPathNameToNtPathName_U>>
; ntdll.RtlDosPathNameToNtPathName_U
7C81E987 84C0 test al,al
7C81E989 0F84 8ACA0100 je kernel32.7C83B419
7C81E98F 66:817D F4 F001 cmp word ptr ss:[ebp-C],1F0
7C81E995 0F87 8CCA0100 ja kernel32.7C83B427
7C81E99B 8B45 F8 mov eax,dword ptr ss:[ebp-8]

----------------------------------------------------------------
注意上面的API:RtlDosPathNameToNtPathName_U,在執行完了以後,ss:[ebp-8]指向的位置存放着:\??\c:\con\(unicode)。
然後程序執行到:
7C81E9FE FF15 0810807C call dword ptr ds:[<&ntdll.NtCreateFile>]
呵呵,Native的創建文件,到此爲止C:\con已經在你硬盤上了,由此可推測那個\??\c:\con\(unicode)便是最終的生成路徑了。
你必須用rd c:\con\才能刪除那個目錄!

然後再試mkdir c:\con:繼續跟蹤,雖然也到了ntdll.NtCreateFile,但很明顯函數執行失敗了……不過可以明確一點CreateDirectoryW似乎不檢查文件合法性……

不過我不服氣,想到那個\??\c:\con\(unicode)總該起點作用吧,於是又用了這段mkdir c:\coo。

然後再運行到ntdll.RtlDosPathNameToNtPathName_U以後找到了那段unicode的地址:dword ptr ss:[ebp-8],當時是0x001581E8,
於是打開了內存修改:
先找到那個地址:
001581E0 47 00 45 00 0F 07 1E 00 5C 00 3F 00 3F 00 5C 00 G.E..\.?.?.\.
001581F0 63 00 3A 00 5C 00 63 00 6F 00 6F 00 00 00 AD BA c.:.\.c.o.o...
然後手動改爲\??\c:\con\(注意是unicode,這裏多加了個\,爲了繞過驗證):
001581E0 47 00 45 00 0F 07 1E 00 5C 00 3F 00 3F 00 5C 00 G.E..\.?.?.\.
001581F0 63 00 3A 00 5C 00 63 00 6F 00 6E 00 5C 00 00 00 c.:.\.c.o.n.\...
然後就按F9讓他去吧,呵呵,成功了,雖然打了mkdir c:\coo,但在c:\出現了con文件夾!

到目前爲止已經搞一段落了,我先來總結下:
1.原先的文件名漏洞並不是出現在mkdir和rmdir這兩個命令中,而是ntdll.NtCreateFile,換句話說你編寫程序調用CreateDirectoryW(L"C:\\con\\",NULL);也會有同樣效果。
2.加了\後可以成功創建文件原因不明,但的確可以繞過一些檢查。
3.雖然原先的路徑字符串對是否創建文件成功(ntdll.NtCreateFile)有作用,但似乎最終文件名是由那段unicode定的。

好了,現在心裏已經有點頭緒了,那我們來試下CreateFileW吧,也就是要創建一個文件,比如con.txt。
想到控制檯中>>這個重定向命令。比如help >>c:\aa.txt可以將help命令的內容輸入到aa.txt裏面,那肯定是要調用CreateFileW了,但先不管這個,先試驗下這個:
help >>c:\con.txt\(呵呵,多加一個\,企圖繞過驗證)
結果:
C:\WINDOWS\system32>help >>c:\con.txt\
文件名、目錄名或卷標語法不正確。
呵呵,看來CreateFileW與CreateDirectoryW不同了,然後又試了C:\WINDOWS\system32>help >>c:\con.txt,這回更搞笑,唉都忘了con含義了(自己試試看)。
看來命令行裏靠不住了,於是自己編了個小程序:
HANDLE pfile=CreateFile("C:\con.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);

if (pfile!=INVALID_HANDLE_VALUE)
{
MessageBox(NULL,L"OK!",NULL,MB_OK);
}
當然運行這個肯定是失敗的,不過還是先用ollydbg看下:
跟進CreateFileW後,首先執行API的是:ntdll.RtlInitUnicodeString,呵呵,看名字就知道含義了~
同時前面的ntdll.RtlDosPathNameToNtPathName_U又出現了:
7C8109E9 50 push eax
7C8109EA 56 push esi
7C8109EB FF15 3C11807C call dword ptr ds:[<&ntdll.RtlDosPathNameToNtPathName_U>>;
7C8109F1 84C0 test al,al
7C8109F3 0F84 408E0200 je kernel32.7C839839

呵呵,看來又會是老樣子嗎?先終止吧,把代碼改稱
HANDLE pfile=CreateFile("C:\co.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
然後用老辦法,到了ntdll.RtlDosPathNameToNtPathName_U以後找到unicode對應內存,然後修改!
00142AA0 5C 00 3F 00 3F 00 5C 00 63 00 3A 00 5C 00 63 00 \.?.?.\.c.:.\.c.
00142AB0 6F 00 6E 00 2E 00 74 00 78 00 74 00 5C 00 00 00 o.n...t.x.t.\...
按下F9,向上帝祈禱……,結果……
雖然出現了帶con的文件名,但好像有問題……C:下出現的是con.tx……
不過問題一想就明白。strlen("con.tx")==strlen("con.tx")
看來原先的字符串還控制這文件名長度……第二次使用
HANDLE pfile=CreateFile("C:\coo.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
然後進Olly用相同方法,呵呵,歡呼吧,成功了!!

好了,到此爲止你知道怎麼創建了。呵呵,道理永遠是淺顯的,上面的過程無非是修改了下內存,但到底是爲什麼會造成這個問題的呢?希望大家考慮下,我這裏就賣個關子。

最後別忘了把那些垃圾刪掉吧,你可以用del命令或者自己編程,然後攔截DeleteFileW,當然程序要是unicode版的,文件名先僞造一個合法的,然後用相同方法去修改就好了。

在這裏我想說些有趣的事:
1.前面mkdir con\建立的文件夾可以訪問,能防止文件,但無法刪除
2.那些帶有con\prn的文件打不開也刪不掉,而且系統無法確定其時間。

不過上面僅供學習娛樂,創建帶con可能意義不大,不過你可以先CreateFileW一個這樣的文件,通過破解讓他順利創建後利用返回的合法HANDLE再使用WriteFile也許允許你用裏面讀寫數據哦……這樣裏面得內容就100%安全了,除非format。

不過世上還有無聊的人會編病毒……所以我就不公開提供生成這種文件的代碼了。需要的自己找我吧

最後附上能自動創建、刪除這類文件的程序:
WinFileKiller

點擊下載:[url]ftp://FTP_visitor:[email protected]/Public/Products/Crack/WinFileKiller.rar[/url]

陳士凱版權所有,轉載請標明作者與出處。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章