Windows path conversion weirdness enables unprivileged rootkit behavior

Windows path conversion weirdness enables unprivileged rootkit behavior

Attackers can take advantage of how Windows converts file paths between the traditional DOS format to the more modern NT format in order to achieve rootkit-based capabilities such as hiding files and processes without any special privileges, a security researcher has discovered.

The security implications of this DOS-to-NT path conversion were found by Or Yair, a researcher with SafeBreach and was presented at Black Hat Asia 2024. The technique, dubbed MagicDot by Yair, enabled a remote code execution and a privilege escalation vulnerability in Windows that were patched last year, but the underlying issue remains unfixed and impacts many other applications that operate with files.

“I discovered how a malicious actor — without admin privileges — could hide files and processes, hide files in archives, affect prefetch file analysis, make Task Manager and Process Explorer users think a malware file was a verified executable published by Microsoft, disable Process Explorer with a denial of service (DoS) vulnerability, and more,” Yair said in a technical writeup.

Vulnerability exploits the difference between DOS and NT paths

When someone is asked to type the path to a file on a Windows system, they are likely to type something of the form C:directorysubdirectoryfile.txt. This is known as a DOS-style file path and has been the most common way to represent a file’s location ever since the first Windows version. It still remains a common way that many applications address files on Windows when they want to perform operations on them.

However, ever since Windows NT there is another way to represent file paths. The NT path equivalent of the above DOS path would be ??C:directorysubdirectoryfile.txt. You might think that’s not much of a difference, and for this particular example, you’d be right, but what actually happens is that NT Paths support Unicode, so a larger number of characters, compared to DOS paths that only support the ANSI character set.

The issue is that WindowsAPI file operation functions, which many applications such as CreateFile call, actually work with NT Paths. If presented with a DOS path, they will first convert it to an NT Path using a function called RtlpDosPathNameToRelativeNtPathName. There are many rules applied to this conversion, but two that are relevant for Yair’s research are the removal of trailing dots from any of the path elements and the removal of empty space trailing the last element.

For example, the path C:directorysubdirectory.file. would be converted to ??C:directorysubdirectoryfile — the dots trailing the subdirectory and file would get removed. And that could actually point to a file that doesn’t exist, or worse, a different file, opening all sorts of security implications.

Exploiting the disappearing dots

“By placing a simple trailing dot at the end of a file name or by naming a file or a directory with dots and/or spaces only, I could make all user-space programs that use the normal API inaccessible to them,” Yair said.

“Such directories could not be listed or have any other operation done on them. Similarly, any files using this naming convention could not be operated on either. Users were not able to read, write, delete, or do anything else with them.”

It’s easy to see why, if an application tries to open C:UsersUserDesktopmalwaredir.malware.txt by calling the normal Windows API functions and the dot are removed during NT Path conversion, the path ??C:UsersUserDesktopmalwaredirmalware.txt (without dot) does not exist and can’t be opened.

This actually allows impersonating files too — let’s say an attacker places a malicious file called benign. and one non-malicious file called benign in the same directory. When a vulnerable application tries to open the malicious one, it would actually open the harmless one without a trailing dot, providing concealment.

Taking it further, if the attacker chooses to impersonate an existing file path to a legitimate process, they can conceal their malicious process in Task Manager and other such tools. For example, ??C:Windows.System32svchost.exe would appear as ??C:WindowsSystem32svchost.exe in Task Manager and this is a legitimate Windows service that’s always running on the system.

Developers urged to use NT paths in code to avoid the exploit

Taking it even further, Yair was able to hide files placed inside archives from Windows Explorer when using the MagicDot path trick. Archives are a common method of distributing malware on Windows, especially as email attachments with a phishing lure.

Attackers usually deploy user-level or kernel-level rootkits in order to achieve some of the same file concealment behaviors. The difference is that deploying rootkits requires Administrator or higher privileges while using the MagicDot technique doesn’t.

“While Microsoft addressed the specific vulnerabilities we found, the DOS-to-NT path conversion known issue, which was the root cause of the vulnerabilities, remains unfixed,” Yair said. “That means there might be many more potential vulnerabilities and post-exploitation techniques to find using this issue.”

The researcher advises software developers to use NT paths instead of DOS paths in their code because in this way the conversion process is avoided and they can ensure the path they provide to a Windows function is actually the one that ends up being operated on.

Software Development, Threat and Vulnerability Management, Vulnerabilities, Windows Security

 Avatar

Leave a Reply

Your email address will not be published. Required fields are marked *