:: Introduction ::

Foreword

This text describes the FirstClass communications system from a more technical
perspective. It will explain the system monitoring capabilities, the type of
restrictions which can be placed on the system, and some interesting hacking
techniques.

There are very few documents which give this kind of information about
FirstClass, the few that I’ve seen were badly written and extremely outdated.
Releasing this text anonymously gives me the opportunity to discuss any aspect
of the software without fear of prosecution.

What is FirstClass?

“FirstClass is a cost-effective, highly scalable, feature-rich messaging and

communications solution for schools and school districts, learning organizations
and businesses. At the foundation of our award-winning FirstClass
Communications Platform is our Collaborative Groupware, which provides our
users with the ability to effectively communicate and share valuable resources
and information via email, conferencing, directories, individual and shared
calendars and online chats. FirstClass has been used by thousands of
organizations to create powerful online electronic communities that enable
individuals and groups of people to work more effectively.” – firstclass.com

Now, that’s mostly marketing bullshit. FirstClass is an ignorant administrator’s

alternative to free network services, such as those released under the GPL
agreement (apache, samba, sendmail .etc).

FirstClass uses a virtual file system. This means that the files and directories you
create on your cute little desktop are actually stored in one huge database file,
and are not directly accessible on the disc. This is a brilliant security measure
because it effectively creates a disc which only FirstClass can access, preventing
virus infection and data theft. Damn, I sound like I’m advertising this piece of
shit.

Some interesting points can be noted about this virtual file system. First, since
the files are not stored in the normal directory tree, the files do not have to
comply with the discs file storage standards. Files in the FirstClass system are
handled by an ID; the ASCII filename is merely an attribute. You will notice that
you can construct a filename using almost any ASCII character, including forward
and back slash characters, which would usually denote file hierarchy. You can
even create two files with the same name, or leave the name completely blank.

While this fact seems useless, it created an interesting flaw when transferring
files using the FirstClass 7.0 client on Windows platforms. The FirstClass client
needs to create a file locally – but unlike the remote file, the filename has to obey
the local file system rules. FirstClass will strip invalid ASCII characters from the
file name before writing it to the temporary directory and executing it. The
programming mistake comes when the user launches a remote file. The system
checks the file name to see if it ends in the notorious four byte extension, “.exe”.
If this is the case, the FirstClass client will display a small warning dialog,
notifying the user about the possible dangers of launching executable files. By
appending an invalid ASCII character to the file extension (“example.exe#”), we
can bypass the executable extension check, however upon writing the file to the
local disc, the invalid character is stripped from the filename, and the FirstClass
software executes the binary without a warning prompt.

In conjunction with the “auto open” file attribute, it is possible to create a binary
file which will be automatically downloaded and executed when a user opens its
directory. This vulnerability was discovered in 2003 and has been patched in
FirstClass version 8.0. It is a very nice example of how a serious vulnerability
requires no low level knowledge to exploit.

Links in FirstClass messages can point to local files, which will be executed when
the link is clicked. This mainly becomes a problem when FirstClass is being used
on a Windows network with writable network shares, where a backdoor could be
placed in a world accessible location.

Data mining

FirstClass provides some great snooping possibilities. By default, each user has a
public directory, which can be accessed using the client software or via the HTTP
daemon. In situations were you do not have access to the FirstClass system, you
can still view the public folder by appending a tilde character followed by the
account name to the servers hostname (for example, http://fc.server.com/~John
Smith/). In some situations the user may have created an index.htm or
equivalent index page to prevent the directory contents being listed. However, we
can still obtain the directory list by using the “Search” function of the FirstClass
system. As disclosed in a 2003 vulnrebility, by appending /Search to the directory
name, and leaving the search field blank, the system will happily return the full
directory list.