Windows 文件系统漏洞中的.

原文：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<分割字节><空字符串>
也就是说最后面的"."是被去掉也是无所谓的。但他和“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