Windows file system vulnerabilities.

Original article: http://www.csksoft.net/blog/post/WinFileKiller2.html

 

 

[Download] Will you create C:/con.txt? Windows File System Vulnerabilities

Alas, all the previous nonsense headers are lost. Tell me if there are any errors.
----------------------------
If you are thinking about con.txt, isn't it normal? Well, you should first create a file with an independent con, and then read it again (if you use Linux, Mac, or UNIX ).

Normally, files or directories with the terms con, PRN, and COM1 cannot be created (for your own reasons), but I think of an article that was previously focused on security, it teaches you how to create a folder. At that time, the method was created using the Console Command (if you call the doscommand, It is not standard) mkdir CSK ../syntax. It seems that this is a Windows File System Vulnerability, right ......

Later, I was thinking about the principle. Maybe you will find something like the above CSK .. /After creation, it is CSK ., windows actually interpreted it as accessing mkdir CSK. /directory. It seems that some characters were omitted during creation. By chance, I found that mkdir C:/CON/was successful. The C:/con folder appears under C and cannot be deleted ...... A bug ......

I suddenly thought of the possible reason: First, you must verify the correctness of the directory when creating the directory. For example, C:/DIR/must first omit the/symbol, but what about the content? It seems that Windows does not check ...... Otherwise, mkdir C:/CON/will fail, and mkdir C:/con is definitely invalid.

So I was wondering if the files I created could also use this vulnerability to win some checks on the Windows file system? As you can see, I have succeeded ^-^

 

In one go, this is not the image, it is the real con.txt. In fact, the principle is similar to the above speculation, but due to limited time, my analysis is not necessarily correct. The specific cracking process is shown below:
2005.8.1: 23: 00
First, I want to know that mkdiris the original cause of loopholes, so I can take ollydbgto cmd.exe (mkdir is an internal command, but I don't know who he is looking ?). Then we set a breakpoint for kernel32.createdirectoryw, which was interrupted after mkdir C:/CON/was input. Naturally, follow createdirectoryw in one step:
----------------------------------------------------------------
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]

----------------------------------------------------------------
Note the above API: RtlDosPathNameToNtPathName_U, after the execution is complete, SS: [ebp-8] points to the location where :/?? /C:/CON/(UNICODE ).
Then the program runs:
7c81e9fe ff15 0810807c call dword ptr ds: [<& NTDLL. ntcreatefile>]
Haha, the native file has been created so far. C:/con is already on your hard disk. From this, you can guess which one /?? /C:/CON/(UNICODE) is the final generated path.
You must use rd c:/CON/to delete the directory!

Then try mkdir C:/CON: To continue tracking. Although NTDLL. ntcreatefile is also reached, it is obvious that function execution has failed ...... However, it can be clarified that createdirectoryw does not seem to check the file validity ......

But I'm not convinced, think of that /?? /C:/CON/(UNICODE) always serves this starting point, so the mkdir C:/Coo is used again.

Then run NTDLL. RtlDosPathNameToNtPathName_U and find the Unicode address: dword ptr ss: [ebp-8], which was 0x001581e8,
Therefore, the memory modification is Enabled:
Find the address first:
001581e0 47 00 45 00 0f 07 1E 00 5C 00 3f 00 3f 00 5C 00g. e ../.?.?. /.
001581f0 63 00 3A 00 5C 00 63 00 6f 00 6f 00 00 00 ad Ba C ../. C. O. O...
Then manually change /?? /C:/CON/(note that Unicode is added here./, to bypass verification ):
001581e0 47 00 45 00 0f 07 1E 00 5C 00 3f 00 3f 00 5C 00g. e ../.?.?. /.
001581f0 63 00 3A 00 5C 00 63 00 6f 00 6e 00 5C 00 00 00 C ../. C. O. N ./...
Then press F9 and let him go. Haha, it's successful. Although mkdir C:/Coo is played, the con folder appears in C!

So far, it has come to a conclusion:
1. the original file name vulnerability does not appear in the mkdir and rmdir commands, but NTDLL. ntcreatefile. In other words, you can write a program to call createdirectoryw (L "C: // con/", null.
2. The reason for successfully creating a file is unknown after/is added, but some checks can be bypassed.
3. Although the original path string has an effect on whether the file is successfully created (NTDLL. ntcreatefile), it seems that the final file name is determined by the Unicode.

Now, we have come to try createfilewbar to create a file, such as con.txt.
Think of Console> this redirection command. For example, help> C:/aa.txtcan input the content of the helpcommand to aa.txt. It must be called createfilew:
Help> C:/con.txt/(haha, add one more/to bypass verification)
Result:
C:/Windows/system32> help> C:/con.txt/
The file name, directory name, or volume label syntax is incorrect.
Haha, it seems that createfilew is different from createdirectoryw, And then try C:/Windows/system32> help> C:/con.txt. This is even more funny, I forgot the meaning of con (try it myself ).
It seems that the command line is unreliable, So I compiled a small program:
Handle pfile = createfile ("C:/con.txt", file_generic_write, file_pai_write, null, create_always );

If (pfile! = Invalid_handle_value)
{
MessageBox (null, l "OK! ", Null, mb_ OK );
}
Of course, running this operation will certainly fail, but you should first check it with ollydbg:
After following up with createfilew, the first API to be executed is NTDLL. rtlinitunicodestring ~
At the same time, NTDLL. RtlDosPathNameToNtPathName_U appeared again:
7c81_e9 50 push eax
7c8109ea 56 push ESI
7c8109eb ff15 3c11807c call dword ptr ds: [<& NTDLL. RtlDosPathNameToNtPathName_U>;
7c81_f1 84c0 test Al, Al
7c81_f3 0f84 408e0200 je kernel32.7c839839

What does it look like again? Stop it first and rename the code
Handle pfile = createfile ("C:/co.txt", file_generic_write, file_cmd_write, null, create_always );
Then, in the old way, locate NTDLL. RtlDosPathNameToNtPathName_U, find the memory corresponding to Unicode, and modify it!
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 ./...
Press F9 and pray to God ......, Result ......
Although the file name with con appears, it seems that there is a problem ...... C: con. TX ......
But you can understand the problem as soon as you think. Strlen ("con. TX") = strlen ("con. TX ")
It seems that the original string still controls the file name length ...... Second use
Handle pfile = createfile ("C:/coo.txt", file_generic_write, file_assist_write, null, create_always );
Then use the same Olly method !!

Okay, so far you know how to create it. The principle is always simple. The above process is nothing more than modifying the memory, but why does it cause this problem? I hope you can consider it. I will sell it here.

Finally, do not forget to delete the garbage. You can use the del command or program it yourself, and then intercept deletefilew. Of course, if the program is a unicode version, the file name must be forged to be legal first, then you can modify it in the same way.

Here I want to talk about some interesting things:
1. the folder created in mkdir con/can be accessed to prevent files from being deleted.
2. Files with con/PRN cannot be opened or deleted, and the system cannot determine the time.

However, the above is only for learning and entertainment. Creating a file with con may not be of great significance. However, you can create a file like createfilew first, after successful creation, he can use the returned valid handle and then use writefile. This may allow you to read and write data in it ...... In this way, the content is 100% secure unless the format is used.

But there are still boring people in the world who will make up the virus ...... Therefore, I will not publicly provide code for generating such files. Find me if you need it.

Finally, the program that can automatically create and delete such files is attached:
Winfilekiller

Download ftp: // ftp_visitor: visitor@ftp.csksoft.net/public/products/crack/winfilekiller.rar

 

Create a file with the same name using the dynamic modification API function and use it

The author retains the copyright of the Article. Please indicate the source when reprinting.
The winfilekiller tool is required in this article. You can find the description and
Tool: ftp_visitor: visitor@ftp.csksoft.net/public/products/crack/winfilekiller.rar

Don't get dizzy with the text of the title, but you can do a lot of things in this way ~~

First of all, let's start with a conversation with a friend: He used to download files with flashget and suddenly generated two files like this on the desktop.

Download.rar
Download.rar.

Note that the second file name is followed by a dot ".". I didn't think it was a big deal at first, but then he told me that only one of the two files can be deleted, assuming that "download.rar." was deleted .". This is a strange thing happened: the downloaded download.rar.pdf is automatically renamed as downloaded download.rar .". Then, it cannot be deleted.

Token Tool

After all, the job is done by modifying the kernel, which may work, so it is passed to him and used the delete function in it. Valid indeed! The file is deleted.

After my research, winfilekiller can also create such a file: the file name ends. Such files cannot be deleted normally.

However, if the problem is just so simple, that's all. Here are some interesting questions about the file ending:
Except for the aforementioned undeletable and automatic renaming, If you create a file with the same name but no last "." file, for example:

File.txt
File.txt.

You will find that both of them can be accessed normally. If you use NotePad to modify one of the data, when opening another file, you will find that the data displayed is the same!

Of course, there is a more interesting phenomenon, that is, the file with the same name can be created (the explanation will be detailed later)
This is displayed in Windows Explorer:

The figure above is definitely not handled by me. In fact, you only need to change test1.txt.to test1.txt in the assumerinterface. However, I put quotation marks on the duplicate name file, because the duplicate name phenomenon is unstable, you only need to refresh the explorer display and it will return to the previous status.

But I don't want to focus on this. Now let's analyze the causes of these phenomena.

First, you cannot directly create a file named ". "End file: for example, I want to create" file.txt. "If the file" file.txt "is not found at first, enter the file name" file.txt. "In the future, the system will automatically rename you, and you will actually create" file.txt ". If you want to create "file.txt.", the system will prompt you that a file with the same name exists.

It can be said that the system omitted the last "." To explain the above phenomenon. Why should I skip it? Let's study the file system.

The general file names are classified into two types: anonymous and extended. This type of file is the same as file.txt. The title name is file, and the extension is TXT. This is okay. What is "." in the middle? It can only be a delimiter.

But in fact, the file name in the file system does not save the separator ".", the corresponding file.txt is actually recorded in the following form on the disk:
File TXT. Spaces may be separated by a 0-byte string (of course, this article does not discuss the file system. For details, refer ).

In fact, "." is not recorded in the file system, but is added by the file system when it is displayed.

Knowing this, we will study the example file.txt. "file:
According to regulations, the extension part is the first "." position from the end of the file to the right to the left. If "." is not displayed, it indicates that there is no extension.

The conclusion is that there is no extension. According to the above statement, the record format in the file system can be:
File.txt <split byte> <empty string>
That is to say, it doesn't matter if the last "." is removed. But he and file.txt are not files of the same name.

In string form, it becomes a file with the same name.

If you open file.txt. ", because the last". "is omitted, the last file.txt is uploaded ". This is why one file is modified and another file is changed.

The deletion of a file. Because of the equivalence of the two files, no specific deletion is made, all files are deleted. In this case, we will always leave the other file.txt. ", so it will feel changed automatically.

In the same example, if you want to delete the remaining file.txt.txt file, the file is deleted because it does not exist. Therefore, the system reports an error and cannot delete the file.

In this case, the problem is explained. The reason why the system displays file.txt instead of "." is not clear yet.

By the way, do you still remember how to create a folder with a slash?

Md c:/Aa ../

Why do I need to add "." To the folder? At the same time, the created folder is of the same nature as the files I mentioned here! Later I found through the createdirectoryw API, in which the correctness of the file name was not checked after RtlDosPathNameToNtPathName_U was called. This is consistent with the objective of modifying winfilekiller: The correctness check is bypassed.

I tried to use winfilekiller to create the following file: "file ../". But failed. "/" is skipped after RtlDosPathNameToNtPathName_U is called, as is in createdirectoryw (this is the case under winnt kernel)

So I guess in fact, md c:/aa ../creates a folder ending with "." Instead of what I previously thought was "/".
Oh, it's far away.

The following describes the exploitation issues.

Connect to the latest file.txt.htm and file.txt ". Because of the regular operation, only the file.txt.txt file is uploaded, And the file.txt. file can be considered as "neutral.

But if we want to write data to it, isn't it fun to read it out through special means when necessary?

For example, I want to add the most important data to file.txt.txt, and include the "file.txt" file with irrelevant data. Isn't it interesting?
If there is a virus that can be used to replicate itself, I think all anti-virus software will be ineffective. ^_^

I have already implemented the file production and data implantation in winfilekiller. For details, refer

FTP: // ftp_visitor: visitor@ftp.csksoft.net/public/products/crack/winfilekiller.rar

You can use the same method to modify the movefile API for writing data.

Simple file injection:
After winfilekiller is started, select 2: "copy a file". Follow the prompts to enter the path of the source file for data injection, and enter the path of the file with the end.

In fact, this only utilizes some operating mechanisms of the file system, and there is no advanced technology.
This article applies to Windows XP and Win2k, and theoretically supports the WINNT kernel system. Test environment: WINXP sp2_rtm