Windows 檔案系統漏洞中的.

來源:互聯網
上載者:User

原文:http://www.csksoft.net/blog/post/WinFileKiller2.html

 

 

[下載]你會建立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

點擊下載:ftp://FTP_visitor:visitor@ftp.csksoft.net/Public/Products/Crack/WinFileKiller.rar

 

利用動態修改API函數建立“同名”檔案及其利用

作者該文章保留對文章的著作權,轉載時請註明出處。
文章中需要WinFileKiller工具,你可以在我的blog:blog.csksoft.net找到說明文章和
工具:ftp://FTP_visitor:visitor@ftp.csksoft.net/Public/Products/Crack/WinFileKiller.rar

不要被標題那拗口的文字弄暈了,不過用這種辦法可以做很多事情哦~~

首先要從和一個朋友的對話說起:他曾經在用FlashGet下載檔案時候突然發些在案頭上產生了類似於這樣的兩個檔案

download.rar
download.rar.

注意第二個檔案名稱後面有一個點"."。我一開始也沒覺得有什麼大不了的,但後來他對我說這兩個檔案中只能刪除其中一個,假設刪除了"download.rar."。這是奇怪的事情發生了:留下的“download.rar”或自動更名成為“download.rar.”。然後就刪不掉了。

我不知道為什麼FlashGet會產生這樣的檔案,但當時我的朋友正苦於想辦法刪除那兩個檔案,於是我想到了以前發布過的WinFileKiller,就是那個用來建立con.txt的工具

畢竟那個是通過修改核心進行工作的,可能管用,於是就傳給他,用裡面的刪除功能。果然有效!檔案被刪掉了。

後來經過我研究,WinFileKiller還可以建立這樣的檔案:即檔案名稱以"."作為結尾。同樣這樣的檔案是用正常辦法無法刪除的。

不過如果問題就僅僅如此簡單那也就罷了。下面就來說說這個以"."結尾的檔案的一些有趣的問題:
除了上面所說的無法刪除和自動更名以外,如果你在建立一個前面檔案名稱字相同,但沒有最後的"."的檔案,比如:

file.txt
file.txt.

你會發現它們2者均能正常訪問,如果用記事本修改其中一個的資料,那個開啟另外一個檔案時,會發現顯示出來的資料是相同的!

當然還有更有趣的現象,那就是能建立出“同名”的檔案(對於這個的解釋後面會詳細說明)
這是在windows explorer裡面顯示的情況:

上面的圖絕對不是我處理出來的哦。其實只要在explorer裡面把test1.txt.改名為test1.txt即可。但我是給重名檔案加上引號的,因為這種重名現象很不穩定,你只要重新整理下explorer顯示就會回到前面的狀態了。

但我不是要重點說這個的,現在就來分析下產生這些現象的原因吧。

首先在explorer中是無法直接建立以"."結尾的檔案的:比如我要建立"file.txt.",如果起先沒有"file.txt"這個檔案,那麼當你在建立檔案輸入檔案名稱"file.txt."以後,系統會自動為你改名,你實際就建立了"file.txt"。對於原先存在"file.txt"的情況,當你要建立"file.txt."以後,系統就會提示你有同名檔案存在。

可以說是系統把最後面的"."給略去了,這樣正好能解釋上面的現象。那為什麼要略去呢?我們來研究下檔案系統吧。

一般檔案名稱分為標題名和副檔名兩部分,這大部分人是知道的,比如上面的file.txt。他的標題名是file,副檔名是txt。這沒問題,那麼請問中間的"."屬於什麼呢?可能只能算是分割符吧。

但實際上檔案系統中檔案名稱是不儲存分割符"."的,所以上面的file.txt在磁碟上其實就記錄成下面的形式
file txt。其中空格可能是用一個0位元組來將2部分分割開來了(當然本文不是要論述檔案系統的,具體解釋請參考資料)。

所以上面的“file.txt”,實際上那個"."是不記錄在檔案系統裡面的,只是在顯示的時候由檔案系統負責加上去了而已。

知道了這點那麼我們就來研究“file.txt.”這樣的檔案:
按照規定,副檔名部分是檔案末端到由右向左出現的第一個"."位置的部分,如果沒有出現".",則表示沒有副檔名。

於是得出的結論是上面這個“file.txt.”是沒有副檔名的。按照上面的說法,檔案系統中他的記錄形式可以是:
file.txt<分割位元組><Null 字元串>
也就是說最後面的"."是被去掉也是無所謂的。但他和“file.txt”實際上不是同名的檔案。

但是我們知道除了檔案系統內部,一般程式都是用以“.”作為分割符的檔案名稱的,對於普通程式,由於略去了最後的“.”,“file.txt.”和“file.txt”在字串形式上就成了同名檔案。

如果你開啟了“file.txt.”,由於略去了最後的".",實際上最後訪問了“file.txt”。這就是為什麼修改了其中的一個檔案,另外一個檔案就會跟著改變的原因。

而對於檔案的刪除,由於2個檔案的等效性,無論刪除哪一個,實際上都是“file.txt”被刪除。所以總會留下那個“file.txt.”,因此就會感覺是自動被改名了。

同樣,如果再想刪除留下的那個“file.txt.”,因為實際要刪除的是“file.txt”,但這個檔案已不存在了,所以系統當然就會報錯,那也就無法刪除了。

這樣一來,上面的問題就解釋好了,不過為什麼系統會顯示file.txt.而不把"."在顯示中略去的原因我還沒有弄清楚。

這裡順便說一下以前看到的建立帶有"/"檔案夾的辦法,大家還記得建立的方法嗎?

md c:/aa../

為什麼在檔案夾後面要帶上“.”。同時建立的檔案夾也和我這裡說的帶有點的檔案具有相同的性質!後來經過我反組譯碼CreateDirectoryW API發現,其中調用完RtlDosPathNameToNtPathName_U以後,沒有對檔案名稱正確性進行檢查。這和我的WinFileKiller修改的目的一致:繞過了正確性檢查。

而我嘗試用WinFileKiller建立如下檔案“file../”。但失敗了,“/”在RtlDosPathNameToNtPathName_U調用完畢以後就被略去了,在CreateDirectoryW 中也是如此(這是說的是WinNT核心下面的情況)

所以我猜測其實md c:/aa../是建立了以“.”作為結尾的檔案夾而不是先前認為的帶有“/”。
呵呵,扯遠了。

下面就來說說利用的問題。

接著上面說的“file.txt.”和“file.txt”。因為按照常規的操作,實際上都只是“file.txt.”這個檔案被訪問,所以“file.txt.”可以被認為是“中立”了。

但是如果我們想辦法把資料寫入到其中,在需要時在通過特殊手段讀取出來不是很好玩嗎?

比如我把很重要的資料注入“file.txt.”,又附上“file.txt”裡面存著無關的資料。這樣可以很好的保護自己的資訊,別人即使開啟“file.txt.”,那也是在看“file.txt”得檔案,而要刪除“file.txt.”,那也是刪除了“file.txt”,呵呵,很有趣不是?
如果有種病毒能利用這個原理複製自己的話,那我想目前所有的殺毒軟體都會失效^_^

對於這種檔案的製作和資料植入我已經在WinFileKiller裡面實現了,具體辦法可以看

ftp://FTP_visitor:visitor@ftp.csksoft.net/Public/Products/Crack/WinFileKiller.rar

對於寫入資料其實就是用同樣辦法修改MoveFile API。

說下簡單的檔案注入:
啟動了WinFileKiller以後,選擇2:"copy a File".此時按照提示,現輸入要注入資料的源檔案路徑,然後輸入帶有"."結尾的檔案路徑即可。

其實這隻是利用了檔案系統的一些運作機制而已,並無高深技術。
本文適用於windowsXP和win2k,理論上支援winNT核心系統。測試環境winxp sp2_RTM

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.