Do you want to create c:\con.txt? Windows file System Vulnerability _ Security Tutorial

Will you build C:\con.txt? --windows File System Vulnerabilities
Alas, wrote the front of the nonsense head are faint, there is a mistake in time to tell me oh.
----------------------------
If you're thinking about con.txt, isn't it normal? Well, you go ahead and create, as long as you have a file with a separate con, and then read this article (if you're using Linux or Mac or Unix).

Oh, normally with con, PRN, com1 such words of the file or directory can not be created (reason to find themselves), but I think of the previous security focus of an article, is to teach you to create a folder with "\". The method at the time was to use console commands (if you call DOS commands that are not standard) mkdir CSK. \ This syntax is created. Looks like this is a Windows file system loophole, yes ...

I've been thinking about the principles, and maybe you'll find CSK like the one above. \ After creation is CSK, and he is actually interpreted by Windows as accessing the mkdir csk.\ directory. It appears that a character was omitted at the time of creation. And a chance I found mkdir C:\con\ is successful, under C appeared C:\con folder, and deleted ... Oh, there is a bug ...

I suddenly thought of the possible reason: first create the table of contents must be verified correctness, and like this C:\dir\ must first be omitted, but the later content? It seems that Windows does not check out ... Otherwise mkdir c:\con\ should fail, and mkdir C:\con is certainly invalid.

So I was wondering if the files I created could also take advantage of this vulnerability to capture some of the Windows file system checks? As you can see, I succeeded.


Oh, this is not a painting, ah, is the real con.txt. In fact, the principle and my above speculation is similar, but due to time constraints, my analysis is not necessarily correct, the following given the specific cracking process:
2005.8.1:23:00
First of all, I want to know the cause of mkdir, so take out ollydbg to debug cmd.exe (mkdir is internal command, I do not know who he find?) ）。 Then set a breakpoint on the Kernel32.createdirectoryw, and sure enough, after the input of the mkdir c:\con\ interrupted. Natural Step into Createdirectoryw:
----------------------------------------------------------------
7c81e97f push EAX
7c81e980 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]

----------------------------------------------------------------
Note the above Api:rtldospathnametontpathname_u, after the execution, Ss:[ebp-8] points to the location of the store: \?? \c:\con\ (Unicode).
The program then executes to:
7C81E9FE FF15 0810807C call DWORD ptr ds:[<&ntdll. Ntcreatefile>]
Oh, native the creation of files, so far C:\con has been on your hard drive, which can be speculated that \?? \c:\con\ (Unicode) is the final build path.
You have to use Rd c:\con\ to delete that directory!

And then try mkdir C:\con: Continue to follow, although also to the ntdll. NtCreateFile, but it's obvious that function execution failed ... However, it can be made clear that Createdirectoryw does not seem to check the legality of documents ...

But I am not angry, think of that \?? \c:\con\ (Unicode) always the starting point, and then use this paragraph mkdir c:\coo.

And then run to Ntdll. Rtldospathnametontpathname_u later found the Unicode address: DWORD ptr ss:[ebp-8], then was 0x001581e8,
So the memory changes are turned on:
Find the address first:
001581E0 0F, 1E 5C 3F 3F 5C g.e..\.?.?. \.
001581f0 3 A 5C 6F 6F AD BA c.:.\.c.o.o, and so on. 
Then manually change to \?? \c:\con\ (note is Unicode, here is an extra \, to bypass validation):
001581E0 0F, 1E 5C 3F 3F 5C g.e..\.?.?. \.
001581f0 3 A 5C 6F 6E 5C c.:.\.c.o.n.\, and so on.
Then press F9 let him go, oh, successful, although played mkdir C:\coo, but in C:\ appeared con folder!

So far it's been a bit of a fall, so let me conclude by:
1. The original filename vulnerability did not appear in the commands of mkdir and rmdir, but ntdll. NtCreateFile, in other words you write a program to call Createdirectoryw (L "c:\\con\\", NULL);
2. After the addition of the file can be successfully created for unknown reasons, but indeed can bypass some checks.
3. Although the original path string was successful for creating the file (Ntdll. NtCreateFile) works, but it seems that the final filename is set by that Unicode segment.

OK, now the mind has a little clue, then let's try Createfilew, that is to create a file, such as Con.txt.
Think of the console >> this redirection command. For example, help >>c:\aa.txt can input the contents of the helps command into the aa.txt, which must be called Createfilew, but regardless of this, first test this:
Help >>c:\con.txt\ (hehe, add a \, attempt to bypass validation)
Results:
C:\windows\system32>help >>c:\con.txt\
The file name, directory name, or volume banner method is incorrect.
Oh, it seems createfilew and createdirectoryw different, and then tried the C:\windows\system32>help >>c:\ Con.txt, this time more funny, alas forgot con meaning (try it yourself).
It seems that the command line is unreliable, so he made up a small program:
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);
}
Of course this must be a failure to run, but still first with ollydbg look at:
After the Createfilew is followed up, the API is executed first: Ntdll. Rtlinitunicodestring, hehe, look at the name to know the meaning of ~
At the same time the front of the ntdll. The Rtldospathnametontpathname_u again appeared:
7C8109E9 push EAX
7c8109ea push ESI
7c8109eb FF15 3c11807c call DWORD ptr ds:[<&ntdll. rtldospathnametontpathname_u>>;
7C8109F1 84c0 Test Al,al
7c8109f3 0f84 408E0200 JE kernel32.7c839839

Oh, looks like it will be the same old? Stop it first, rename the code.
HANDLE pfile=createfile ("C:\co.txt", file_generic_write,file_share_write,null,create_always,0,0);
Then with the old way, to the ntdll. Rtldospathnametontpathname_u later find Unicode corresponding memory, and then modify!
00142AA0 5C 3F 3F 5C 3 A/5C.?.?.. \.c.:.\.c.
00142ab0 6F 6E 2E for the O.N of all of the ... T.x.t.\ ...
Press the F9, pray to God ..., the result ...
Although there is a file name with con, there seems to be a problem ... C: The next show is CON.TX ...
But the question would be clear. strlen ("Con.tx") ==strlen ("Con.tx")
It seems that the original string also controls the length of the file name ... Second time use
HANDLE pfile=createfile ("C:\coo.txt", file_generic_write,file_share_write,null,create_always,0,0);
Then into the Olly with the same method, Oh, cheers, success!!

Okay, that's it. You know how to create it. Oh, the truth is always simple, the above process is nothing more than modified under the memory, but in the end is why it caused this problem? I hope you think about it, I sell a case here.

Finally, don't forget to delete the rubbish, you can use del command or your own programming, and then intercept Deletefilew, of course, if the program is Unicode version of the file name first forge a legitimate, and then use the same method to modify the good.

Here I want to say something interesting:
1. The previous mkdir con\ established folder can be accessed to prevent files but cannot be deleted
2. Those documents with CON\PRN can not be opened and deleted, and the system cannot determine its time.

But the above is only for learning and entertainment, create with con may not be meaningful, but you can first createfilew a file, through the crack let him successfully created after the use of the return of the legitimate handle again use WriteFile may allow you to read and write data in the inside oh ... The contents are 100% secure, unless format.

But there are still people in the world who are going to be programmed with viruses ... So I don't publicly provide the code to generate this file. You need to find me.

Finally, attach a program that automatically creates and deletes this type of file:
Winfilekiller

Click to download: [Url]ftp://ftp_visitor:visitor@ftp.csksoft.net/public/products/crack/winfilekiller.rar[/url]

Chen Shikei All rights reserved, reprint please indicate the author and source.