Common Windows Misconfiguration: Services

System Configuration

If you want to follow and test by yourself the things that we will see in this post I highly encourage you to follow this little setup.

Firstly, you can download for free a Windows 10 virtual machine: here. Note that I’m using the MSEdge (x64) on VMWare with 4GB of RAM and 2 processor core. Then when you are logged in with the default IEUSer, who is an administrator, you can create a new low privileged user.

net user lowuser lowuser1234 /add

Secondly, we create four directory and we add four dummy service:

# Create directories for the binaryPath of our services
mkdir "C:\WeakServices\Weak Service 1"
mkdir "C:\WeakServices\WeakService2"
mkdir "C:\WeakServices\WeakService3"
mkdir "C:\WeakServices\WeakService4"

# Use a default binary
copy C:\Windows\System32\snmptrap.exe "C:\WeakServices\Weak Service 1\service1.exe"
copy C:\Windows\System32\snmptrap.exe "C:\WeakServices\WeakService2\service2.exe"
copy C:\Windows\System32\snmptrap.exe "C:\WeakServices\WeakService3\service3.exe"
copy C:\Windows\System32\snmptrap.exe "C:\WeakServices\WeakService4\service4.exe"

Thirdly, we configure the directories’ rights. More information about icacls.exe here.

icacls "C:\WeakServices\Weak Service 1" /deny lowuser:M
icacls "C:\WeakServices\WeakService3" /deny lowuser:M
icacls "C:\WeakServices\WeakService4" /deny lowuser:M

Fourthly, we create our four services. Documentation about sc.exe create here.

sc create WeakService1 displayName= "Unquoted Service Path" binPath= "C:\WeakServices\Weak Service 1\service1.exe" start= auto
sc create WeakService2 displayName= "Weak Folder Permissions" binPath= "C:\WeakServices\WeakService2\service2.exe" start= auto
sc create WeakService3 displayName= "Weak Service Permissions" binPath= "C:\WeakServices\WeakService3\service3.exe" obj= .\lowuser password= lowuser1234 start= auto
sc create WeakService4 displayName= "Weak Registry Permissions" binPath= "C:\WeakServices\WeakService4\service4.exe" start= demand

Finally, we can modify the permissions of the WeakService3 and give to lowuser a FullControl to the WeakService4 registry key.

For further information about sc.exe, you can read this page.

# Modifying WeakService3's permissions
sc sdset WeakService3 "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;DCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

service add fullcontrol

You should be good.


Windows Services & Misconfiguration

According to Microsoft:

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions.

In fact this is an application that will run in background, like daemons on Linux/Unix systems. Services who are conform to the Service Control Manager (SCM) can be managed via a GUI with the Service Control Panel or trough command line with the DOS command sc.

Few things to note when we deal with services:

  • Services are not always running with System privileges;
  • Services have different starting mode: auto, demand, etc …; and
  • Services cannot be stop/start by anyone.

Therefore, before trying to exploit a Windows service it is important to see if we are, as a low privilege account, able to modify the configuration of the service, if this service will give us more privileges and how to trig the modifications (e.g. in a real world scenario if we need to reboot a production server to exploit a service it might not be a good idea).

Now that we know a bit more about Windows services, let talk about the four common misconfigurations:

  • Unquoted Service Path
  • Weak Folder Permissions
  • Weak Service Permissions
  • Weak Registry Permissions

Official Microsoft documentation: https://docs.microsoft.com/en-gb/windows/desktop/Services/services


Unquoted Service Path

When a service is started, during the boot or manually, Windows will search the binary to execute. Therefore, two case occurs, firstly the binPath of the service is quoted and Windows directly know where the binary is located or, secondly, the binPath is unquoted and Windows do not know where the binary is located and will search in all folders, from the beginning of the path.

So, if we want to exploit this misconfiguration, three conditions have to be met:

  • The service path is unquoted;
  • The service path contains space; and
  • We have write permissions in one of the intermediate folders.

Firstly, let us find an unquoted service. For that we can use wmic, the command-line interface of the Windows Management Instrumentation (WMI). Moreover, by using findstr with the /i switch we can filter out everything that, in our case, contains C:\Windows\ or a double quote.

wmic service get name,displayname,startmode,pathname | findstr /i /v "C:\Windows\\" |findstr /i /v """

hunting unquoted services

To understand what append next let us take a look at two different service, WeakService1 and WinDefend, for example:

difference between services

In the first case, with WeakService1, Windows will search in this order:

  1. C:WeakServices\Weak Service 1\service1.exe
  2. C:WeakServices\Weak Service 1\service1.exe
  3. C:WeakServices\Weak Service 1\service1.exe

On the other hand, with WinDefend, due to the quotes, Windows will directly execute C:\ProgramData\Microsoft\Windows Defender\platform\4.18.1807.18075-0\MsMpEng.exe.

We know that the WeakService1 is unquoted and, as we can see, contains spaces, therefore, the last thing that we have to do is to check for write permissions. For that we can use two different tools, icacls.exe, which is present by default in Windows or accesschk.exe from the SysInternals tools (downloadable here). Personally, I prefer accesschk.exe but both are usable and will help use to find what we want.

According to this Microsoft page and to the icacls output, we have write permissions on the C:\WeakServices\ folder.

unquoted icacls

Which can be confirmed with a less cryptic output from accesschk.exe.

unquoted accesschk

Now that all requirements are validated, we simply have to create a malicious binary and to save it in the C:\WeakServices\ folder. We do not have to over complicate it, we can use msfvenom.

create and deploy weak exe

Due to the fact our low privilege user do not have permission to start/stop the WeakService1 service. However, we can reboot the system, action that lead to an elevation of our privileges by the execution of the Weak.exe binary instead of the C:\WeakServices\Weak Service 1\service.exe one.

In a real world scenario rebooting a production server or a computer is not safe and may trig alarms.

unquoted path lowuser admin


Weak Folder Permission

Everything is in the name, if a low privilege user have write permissions in a folder used by a service, he can change the binary with an arbitrary one.

Let us take example with the WeakService2 service.

weakservice2

We can easily see if we have write permission to this path with icacls.exe.

icacls weak folder permission

Or with accesschk.exe.

accesschk weak folder permission

Now, we can create a malicious binary and replace C:\WeakServices\WeakService2\service2.exe.

weakservice2 create and deploy

If we reboot the system we should, one more time, be part of the Administrators local group.


Weak Service Permissions

Another common misconfiguration is when a service is modifiable by an low privilege user, which means that a user can change the path of the binary to execute and the account who will execute the service.

Let us check the configuration of the WeakService3 service.

weakservice3 config

As we can see, the binary path is C:\WeakServices\WeakService3\service3.exe and the service is executed with low privilege (.\lowuser), but if we check the permissions of this service with accesschk.exe we can see that we have enough rights to change the configuration.

weakservice3 permission

How we can lead this misconfiguration to a privilege escalation? We can change the path of the binary to execute with an arbitrary one and, the most important, we can change the account who will execute the service.

weakservice3 change config

We upload our malicious binary and we start the service in order to gain, in this case, a reverse shell with SYSTEM privileges.

weakservice3 reverse shell

Note that we have to migrate to another process, we are not using a valid Windows service binary.


Weak Registry Permission

Last one, the misconfigured service’s registry key, and , honestly the chance to find this misconfiguration is really, really low, because an Administrator have to manually change the permission of the service’s registry key.

In Windows, services, like a tons of other things, have a registry keys and those keys are located at: HKLM\SYSTEM\CurrentControlSet\Services\<service_name>.

weakservice4

To check the permissions of registry key, as usual, we can use accesschk.exe.

Fortunately for us, the WeakService4 registry key is writable by our low privilege user.

weakservice4 check

By changing the ImagePath value with the path of one of our malicious binary (by double-clicking on the name) we will be able to execute whatever we want.

Then, by rebooting the system we will restart the service and execute our binary.

weakservice4 deploy evil binary



break

Comments