LogMeIn Rescue is a well-known and widely used remote access tool, primarily designed for IT staff to provide end users with support. A typical LogMeIn Rescue session will look something like this:
- A user calls the support technician with a problem.
- The technician sends the user a link, which lets them download LogMeIn Rescue.
- The user runs the software which connects back to LogMeIn’s servers.
- The technician can then take control of the user’s system (with approval), and resolve their problem.
Unattended Access
LogMeIn Rescue also provides an option to perform an unattended installation on the user’s system. This means the LogMeIn Rescue application is persistently installed, and will allow the technician to connect to the system without any user interaction. This is commonly used on end-user systems to simplify the process of providing remote support, but it can also be used to provide remote management of servers within an organisation, especially when the IT is provided by a third party company. When the LogMeIn Rescue application is downloaded and executed by the user, it extracts itself into the user’s local AppData folder, to a path such as:
C:\Users\[username]\AppData\Local\LogMeIn Rescue Unattended\LMIR0001.tmp\
If the client is run multiple times then the number in the LMIR0001 folder will be increased for each installation. The client is then executed from this location, and can survive a reboot (if the technician chooses the option to reboot the system and persist with the connection). The application will be executed by the user who runs it, typically a low privileged user, who generally does not have administrative rights.
However, once the technician decides to perform an unattended install things get interesting. Performing the installation requires administrative rights, due to the application being installed as a service, so either the user or technician will require administrative credentials. Typically the technician will have secondary credentials for the system (often a domain account) that they can use to perform the installation, even when supporting a lower-privileged user. Alternatively, some technicians pre-install the LogMeIn Rescue Unattended service pre-installed on newly built systems to allow them to be supported in future. When the installation is performed, it creates a service running under the LocalSystem account (NT AUTHORITY\SYSTEM) with a name such as the following: LMIRescueUA_[randomID]. This service will have an executable path such as the following:
"C:\Users\[username]\AppData\Local\LogMeIn Rescue Unattended\LMIR0001.tmp\unattended_srv.exe" -service -unattendedid [randomID]
Service Vulnerabilities
There are three main issues with how this service is created, which are detailed below, two of which have serious security implications.
Service Runs From Inside a User’s Profile
The service runs from inside a user’s Local AppData folder, rather than from a system-wide directory such as Program Files, which can lead to a number of functional issues. Firstly, if the user’s account or profile is ever deleted from the system, the service binaries will also be deleted, leaving a broken and orphaned service on the system. Secondly, if the user’s entire profile is redirected (which is a bad idea, but that won’t stop people from doing it) then the service may be broken.
Service Binaries Are Owned by the User
When the LogMeIn Rescue application is first run, it executes under the account of the user who downloaded it, typically a low privileged user, and the files inside AppData are created by that user. Consequently these files are owned by the user, meaning they have full control over them, and will also have the ability to change their permissions. This means the low privileged user can delete or overwrite the service executable. In the best case this will result in them breaking the service by deleting the binaries. In the worst case they can overwrite the “unattended_srv.exe” file with a binary of their choice, which will then be executed by the LocalSystem account next time the system is rebooted – effectively granting them full administrative control over the system (technically there are some differences between being an Administrator and having SYSTEM access, but in practical terms they are essentially equal, as either can trivially take on the permissions of the other).
Service Binaries Are World Writable
So the user whose account was used to initially run LogMeIn Rescue can escalate their privileges to SYSTEM, but what about cases where the Unattended service is pre-installed by IT staff? In that case the user is not the owner of the service, but looking at the permissions on the service binary, we see the following:
> icacls unattended_srv.exe unattended_srv.exe Everyone:(I)(F)
For those who aren’t familiar with icacls, it’s a built-in Windows command line tool to display the permissions on a file. In this case, the output shows the “Everyone” group as full control (F) of the file, and that this permission is inherited (I) from the parent – in this case the “LMIR0001.tmp” folder. This means any authenticated user on the system can delete or overwrite the service binary and escalate to SYSTEM on the next reboot, as discussed in the previous section. As the file is inside another user’s home folder the user cannot browse directly to the files, unless something has gone badly wrong with the permissions on their system, but they can still access the file if they know the full path (which they can get from the service details).
Exploitation
So to exploit this and escalate our privileges to SYSTEM, all we need to do is overwrite the Unattended service binary with a malicious executable of our choice, and then cause the system (or service) to restart. This will then execute our payload with SYSTEM privileges, which will allow us to perform administrative actions on the system, such as adding a new local user with administrative rights. The easiest way to exploit this is using an automated tool like the fantastic PowerUp script, includes as part of PowerTools by PowerShellEmpire. PowerUp is essentially a set a PowerShell scripts design to help escalate your privileges on a system. There are plenty of excellent guides that discuss PowerUp, so I won’t go into detail here, but there are three cmdlets that we need to know to exploit it. Once you’ve imported, you can run the “Invoke-AllChecks” cmdlet, which will scan the system for a number of vulnerabilities, including weak service permissions. Truncated output is shown below:
PS> Invoke-AllChecks [*] Running Invoke-AllChecks [...] [*] Checking service executable permissions... [*] Use 'Write-ServiceEXE -ServiceName SVC' or 'Write-ServiceEXECMD' to abuse [+] Vulnerable service executable: LMIRescueUA_[randomID] - "C:\Users\[username]\AppData\Local\LogMeIn Rescue Unattended\LMIR0001.tmp\unattended_srv.exe" -service -unattendedid [randomID]
In order to exploit this service, you can then run the “Write-ServiceEXE” cmdlet, passing it the service name as an argument:
PS> Write-ServiceEXE LMIRescueUA_[randomID]
This will then replace the service executable with one that creates a new local administrator account as soon the system is restarted. Once this has happened and you’re logged in to your new administrator account, you can restore the original service binary using another cmdlet:
PS> Restore-ServiceEXE LMIRescueUA_[randomID]
Resolution
LogMeIn has released an updated version (7.8.406.1825) which resolves this issue by installing the service into Program Files (x86) and setting appropriate permissions in the folder. When connecting to a system which has previously had the unattended version installed, it will be updated to the latest version. Interestingly, this update process seems to temporarily install the server into the profile of the SYSTEM account at the following location:
C:\Windows\SysWOW64\config\systemprofile\AppData\Local\LogMeIn Rescue Applet\LMIR0001.tmp\
This version also allowed Everyone full control over the service executable, but after a short period of time the file and service was removed – presumably once the proper version of the service in Program Files (x86) had been installed. If for whatever reason updating the service is not possible, then ensure the service executables and folder are owned by an administrative user, and only the local administrators and SYSTEM have access to write to the folder and service. During testing this didn’t appear to have any impact on the functionality of the service – but test it yourself before rolling it out network-wide.
Thoughts
Services are often an area that gets forgotten about by IT staff, and as a result of this are a common way to escalate privileges on a system. Due to their propensity to break when making unexpected changes to their configuration, most IT staff will be hesitant to start changing permissions on services, especially if they are running under highly privileged accounts.
As a developer, remember to harden your services as much as possible, including filesystem permissions and ensuring they have quoted paths (as there have been a number of exploits related to unquoted paths in past). Unless there is a very strong reason for it, avoid running services from a user’s profile, especially if it’s running under a highly privileged account, and where possible run services under lower privileged accounts (although this isn’t always an option).
For sysadmins, it’s worth reviewing the services running on your systems, and PowerUp is a great way to run a quick check for anything exploitable. It also checks for a number of other privilege escalations issues, so you might turn up some other interesting problems with it.