{"id":110032,"date":"2024-07-23T07:00:00","date_gmt":"2024-07-23T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110032"},"modified":"2024-07-23T09:21:08","modified_gmt":"2024-07-23T16:21:08","slug":"20240723-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240723-00\/?p=110032","title":{"rendered":"Unquoted service paths: The new frontier in script kiddie security vulnerability reports"},"content":{"rendered":"

Some time ago, my colleague Aaron Margosis wrote about how most “Unquoted Service Paths” findings are unnecessarily alarmist<\/a>. But that doesn’t stop people from reporting it anyway.<\/p>\n

Usually from people who don’t actually know what they’re doing.<\/p>\n

We often get unquoted service path vulnerability reports. Sometimes they go like this:<\/p>\n

\n

We have identified an unquoted service path: The XYZ service has a listed service path of C:\\Program Files\\Windows Xyz\\XyzSvc.exe<\/tt> with no quotation marks to protect the spaces.<\/p>\n

Attached find a proof of concept. Copy this program to C:\\Program.exe<\/tt> or C:\\Program Files\\Windows.exe<\/tt>, then use the Services MMC snap-in to stop the XYZ service, then start it. The proof of concept program will run.<\/p>\n<\/blockquote>\n

As with most unquoted service path vulnerabilities, this one requires that the attacker be on the other side of the airtight hatchway: Creating files in C:\\<\/tt> or in C:\\Program Files<\/tt> already requires administrator privilege, so this attack presupposes that the attacker has gained administrator access. It is not surprising that an attacker with administrator access can gain administrator access.<\/p>\n

Nevertheless, when we resolve the issue as “Not exploitable, fix in next version”, the finder intended to go public and sent us a preliminary copy of a blog entry they intended to publish.<\/p>\n

The blog entry admitted that a default-configured system is not vulnerable due to the inability of non-administrative users to plant Program.exe<\/tt> in an exploitable directory, but noted that a system administrator might misconfigure the system to grant write access to those sensitive directories.<\/p>\n

Of course, we have now wandered into the realm of creating an insecure system and then being surprised that it’s insecure<\/a>.<\/p>\n

As far as I can tell, the finder never published that blog entry.<\/p>\n

But at least this is a case where the finder actually understood the issues. Often we’re not so lucky, and the finder just spits out some tool output without providing any diagnosable information.<\/p>\n

\n

The XYZ service has an unquoted service path, which could allow a user to gain SYSTEM privileges. Attached please find screen shots demonstrating the issue.<\/p>\n<\/blockquote>\n

The screen shots are heavily redacted captures from some unknown vulnerability scanning software.<\/p>\n\n\n\n\n\n\n
Service name<\/b><\/td>\nVulnerable systems<\/b><\/td>\n<\/tr>\n
\n
\u00a0<\/div>\n<\/td>\n
\n
\u00a0<\/div>\n<\/td>\n<\/tr>\n
\n
\u00a0<\/div>\n<\/td>\n
\n
\u00a0<\/div>\n<\/td>\n<\/tr>\n
Xyz<\/td>\n7<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

That’s nice, but there’s nothing diagnosable here. The finder did include a screen shot of the scanning software reporting a non-vulnerable service, but that doesn’t help us identify the vulnerable one.<\/p>\n

After some back and forth with the finder, we were able to obtain the path to the vulnerable service, and it was of the form C:\\ProgramData\\Microsoft\\Windows Xyz\\XyzSvc.exe<\/tt>, which is not exploitable because it requires administrator privileges to write to the C:\\ProgramData\\Microsoft\\Windows<\/tt> directory.<\/p>\n

Quoting service paths is a best practice. If you forget, most of the time, other defense in depth measures prevent it from being exploitable. It’s still good to fix them even though they aren’t exploitable, because you don’t want to rely on the kindness of others. However, you don’t have to fix them with the urgency of a security vulnerability.<\/p>\n

Another example of an alleged unquoted service path vulnerability is this one:<\/p>\n

\n

The lack of proper quotation marks around the service path for the XYZ service means that this vulnerability could be exploited to achieve privilege escalation. I found this on multiple systems after running a Contoso security scan.<\/p>\n

C:\\Windows\\system32\\svchost.exe -k xyz<\/tt><\/p>\n<\/blockquote>\n

In this case, the finder ran a commercial scanning tool with a free trial, and the tool reportedly claimed that this service path was unquoted.<\/p>\n

While it’s true that the path is unquoted, it’s also true that quotation marks aren’t needed because there are no spaces in the path.<\/p>\n

The path is C:\\Windows\\system32\\svchost.exe<\/tt>. The extra -k xyz<\/tt> are command line arguments to the program. They aren’t part of the path-with-spaces. In other words, this service is not trying to run a program with the funny name svchost.exe -k xyz.exe<\/tt> in the C:\\Windows\\system32<\/tt> directory. The intention is to run the C:\\Windows\\system32\\svchost.exe<\/tt> program. The lack of quotation marks is the intended interpretation<\/i>.<\/p>\n

Some script kiddies try to supplement their report with breathless prose cobbled together from fragments of other vulnerability reports they found on the Internet.\u00b9<\/p>\n

\n

This unquoted path can lead the system to access resources in a parent path. A local attacker can place an executable file in the path of the service. When the service starts or restarts, the malicious file is executed instead of the intended service.<\/p>\n<\/blockquote>\n

It’s not clear what “place an executable file in the path of the service” means here. If they mean insert an executable file in the same directory as the service, then that doesn’t work. The system will still run the intended file.<\/p>\n

If they mean to put a file in a directory in the service’s PATH<\/tt> environment variable, that still doesn’t work, because the service is registered with a full path. (And even if the service were register with an unqualified path, attacking the PATH<\/tt> directories is not fruitful because all of those directories by default are writable only by administrators anyway.)<\/p>\n

If they mean to overwrite the service executable with another executable, well, quotation marks won’t do anything to block that.<\/p>\n

In this particular report, their so-called “repro steps” didn’t actually repro any attack. All they did in the repro steps was enable the service. They never planted any file to trigger unauthorized code execution. All we can do is guess what they meant; we can’t try to infer it from their proof of concept.<\/p>\n

But the clincher was the output of their alleged repro steps:<\/p>\n

C:\\> sc query xyz\r\n    SERVICE_NAME: xyz\r\n        TYPE               : 10  WIN32_OWN_PROCESS\r\n        START_TYPE         : 2   AUTO_START\r\n        ERROR_CONTROL      : 1   NORMAL\r\n        BINARY_PATH_NAME   : \"<\/span>C:\\Program Files\\Microsoft Xyz\\XyzSvc.exe\"<\/span>\r\n        LOAD_ORDER_GROUP   :\r\n        TAG                : 0\r\n        DISPLAY_NAME       : Microsoft XYZ Service\r\n        DEPENDENCIES       :\r\n        SERVICE_START_NAME : LocalSystem\r\n<\/pre>\n
The reportedly unquoted service path is quoted!<\/p>\n
Bonus chatter<\/b>: When the security vulnerability reports reach the engineering team, the identifying information about the finder has often been removed. I’m guessing that this is done to remove sources of bias that could be introduced by recognizing, “Oh no, it’s this guy again,” and not giving the report due consideration because of its source.<\/p>\n
That said, it’s still possible to identify that two reports came from the same person. The writing styles may match up (and sometimes the two reports are word-for-word identical, just with a service name changed). And one time, I noticed that the proof of concept video that was included with the report had exactly the same wallpaper and desktop icons as another report.<\/p>\n
\u00b9 Sometimes the breathless prose is outright wrong.<\/p>\n
An attacker could place a malicious executable in a directory whose name contains a space.<\/p><\/blockquote>\n
As noted above, the attack vector is not placing a malicious executable in a directory whose name contains a space. It’s placing a malicious execute in a directory whose name is a truncation<\/i> of the unquoted path.<\/p>\n","protected":false},"excerpt":{"rendered":"
Usually not exploitable, but the script kiddies don’t know that.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-110032","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Usually not exploitable, but the script kiddies don’t know that.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110032","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=110032"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110032\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=110032"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110032"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110032"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}