Executable Installer File Permissions Weakness

Adversaries may execute their own malicious payloads by hijacking the binaries used by an installer. These processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself, are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under higher-level permissions, which could include SYSTEM.

Another variation if this technique can be performed by takin advantage of a weakness that is common in executable, self-extracting installers. During the installation process, it is common for installers to use a subdirectory within the %TEMP% directory to unpack binaries such as DLLs, EXEs, or other payloads. When installers create subdirectories and files they often do not set appropriate permissions to restrict write access, which allows for execution of untrusted code placed in the subdirectories or overwriting of binaries used in the installation process. This behavior is related to and may take advantage of DLL Search Order Hijacking.

Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. Some installers may also require elevated privileges that will result in privilege escalation when executing adversary controlled code. This behavior is related to Bypass User Account Control. Several examples of this weakness in existing common installers have been reported to software vendors. If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.

Example

In this example I will demonstrate a simple install 7z1512.exe I will run Procmon in this situation and see what is going on when my Installer is executed.

I noticed that 7z Installer is looking for a DLL named TextShaping.dll and it is looking for it in the current working directory.

I will take the same approach as previous DLL examples and try to add this DLL with the proper architecture of the program which in this case is 32-bit

We run the installer again but this time we are placing our payload named properly as the DLL that the installer is trying to load, in this case TextShaping

This time no more TextShaping location issues:

And we receive a shell on our attacking machine.

Here I received Administrator Privileges on the machine as only Admins can install new software but of course there are many scenarios where we can actually gain user permissions if the user has specific permissions to install now programs on that machine as well. Remember that proper execution of the installer is not functional anymore and will seem suspicious that we can't install a program. We can take an approach of a Proxy DLL but that is something for another time, I demonstrate that technique in DLL Side Loading