Analysis of New Windows OS Bug — Can it be leveraged for an 0-day?
Good morning hackers, REs, and every nerd alike. A co-worker sent me a really cool article this morning (Shout out to Kass) — original article can be found here, and after I did some digging, I’ve decided to write my own take on it.
If you haven’t already know, Jonas L (a security researcher) discovered a bug which corrupts your NTFS file system, which pretty much can be categorized as Denial of Service (DoS).
Please do not enter this command unless you’re in revertible Virtual Machine
Let’s take a few steps back and analyze this command. First, Windows store its files and directories in multiple data streams, there is the main stream and there is NTFS-feature specific called the “alternate data stream” or (ADS) or “named stream”. The content of files and folders are stored in the main stream and is visible to the user, while the alternate data streams, as the name suggests is data stream used to store extra information (if any) such as metadata of a file, which is not usually visible to its users.
I really want to talk about the weaponization of ADS for red-teaming, but that should go into another article
I’m going to give you a quick example, when a file is created on Windows OS
echo “This is a test file” > test.txt
This will create a “test.txt” file on windows which contains the string specified in the echo command. However, that’s not all — we can add additional content to the alternate data stream of “test.txt” by invoking the following command
echo “what if I just wreck havoc?” > text.txt:secret.txt
here, we are adding the string (hidden) in the alternate data stream of text.txt called “secret.txt”. When you read the content of text.txt using a regular “type” command, you would only see “This is a test file” string; if you type the following command
You will not see anything since command prompt is giving you an error. No worries, you can just invoke notepad on the alternate data stream and if it works correctly…
Note that this works the same way for files as it would for directories, however, to hide a content in a directory, you would only put the following command.
echo “hide text in current directory” > :secret.txt
Now that we understand how alternate data stream works, let’s re-visit the command which triggered the BSOD bug on Windows.
We know that :$I30 represents the alternate data stream as it would “secret.txt” in our directory example. After conducting additional research on this value, MSDN explains that $I30 stream represents an index location of a directory (some sort of pointer).
Although directories do not have a default data stream, they can have named data streams.
Meaning that the “buggy command”
is already referring to an index location of the root C:\ directory C:\:$I30. However, notice in the bug that Jonas L identified, it seems as if he is trying to access the alternate data stream of the $I30 alternate data stream, which is interesting. Logically speaking, unless I missed something in my research, alternate data stream does not have its own alternate data stream (does tat make sense?). However, he did it anyway, USING $bitmap data type.
The $bitmap data type, according to Microsoft, is used by indexes to manage b-tree free space of a directory, and is present in every directory.
My assumption is that
>> Original researcher meant to look for a pointer to free space within a directory, and thought this attribute might be inside :$I30 — hence the C:\:$I30:$bitmap. While in reality, it could have been just C:\:$bitmap — or something else.
This is very interesting and I have to give props to Jonas L for discovering the bug. Another interesting part of this bug that made me say “it may lead to an or another 0day”, is the fact that once the buggy command is executed, a dialog box is called.
If you are familiar with how Windows OS works, when a dialog/message box is invoked, there is a process that is calling the user32.dll library (again — this is another topic).
When the buggy command is invoked, a notification popup is shown; I have yet to successfully identify which library is used for this notification window (please let me know in the comment), but if one reverses the process and can identify how the bug command is being processed at the lower level, it may be possible to abuse that process — which could potentially lead to arbitrary code execution.
Edit 1: I’m still looking into this issue and will update accordingly