This is from a 2600 article I wrote which was published in the August 2011 issue.
I work for a large financial corporation in the UK as a software
developer. The company uses an internal chat system called MindAlign.
It was originally developed by a company called Parlano, but was
bought by Microsoft and killed in favour of their own OCS GroupChat.
However MindAlign is still in use by five of the top seven global
banks and many other organisations. Chances are if you’ve worked in a
bank, you’ll have this software installed.
Initially the program itself doesn’t appear very interesting. It uses
a simple enough interface that allows the user to join in group chats,
send private messages to people, manage chat history, and other
instant messenger type features. MindAlign launches automatically and
without any prompt when the user logs in. I assumed that it used
Windows Authentication to identify the user and log them onto the chat
system. I used it for a few days without thinking too much about it.
Several months later, during a normal business chat with a colleague,
I noticed that the chat software highlighted and created a link based
on a word that was preceded with a hash (e.g. #test). Clicking the
“#” word launches a window saying “Unable to create ad-hoc channel”.
This type of “#” identification reminded me of IRC. That is when I
decided to start looking into MindAlign a bit more. Sure enough,
Parlano built the system on top of a standard IRC server with a
Windows client on top. Not only that, but with a bit of digging
around in the software logs, I saw that the client was not using
Windows Authentication, but a token based SSO (Single Sign-On) system.
As per normal, the usual warnings apply. This is for information
purposes only and f you get caught doing any of the things I mention,
you could get fired or even prosecuted. So don’t be stupid.
The first stop for me was the program data (typically installed to
C:\Program Files\Parlano\MindAlign). I looked through the config
files, executables, and logs. The logs did show what looked like
connections to an IRC server, but there was limited information.
Eventually I found a file called “logConfig.props”. In this file, I
changed the logging settings to VERBOSE to get the most data I could
out of the system, and then I restarted the MindAlign software.
Bingo! The logs now contained lots of messages related to the initial
SSO connection and the subsequent connection to the IRC server.
Now that I had the IRC server info, I immediately connected to the
server and tried various ways to log into it. Nothing seemed to work
even though it behaved like a standard IRC server. Back in the logs,
I found that authenticating to the IRC server was done based on a
token system driven by the SSO software. Below is an example of the
[servernode] irc << CLIENTTYPE 63
[servernode] irc << AUTH
[servernode] irc << USER joe.biggs 0 * :Joe Biggs
[servernode] irc << NICK joe.biggs [servernode] irc >> :184.108.40.206 004 joe.biggs 11272470
[servernode] irc >> :220.127.116.11 004 joe.biggs :Welcome to the
MindAlign Collaboration Network %42147
[servernode] irc << REGISTER
:ID USERNAME FIRSTNAME LASTNAME EXTERNAL_USER FOREGROUND_COLOR BACKGROUND_COLOR
[servernode] irc << ACTIVE
From that point, it was fairly simple to setup the hack. Access to
the target’s machine is essential (easy enough for IT folk, but maybe
a bit trickier for normal users). Modify the logging properties of the
the “props” file to output in VERBOSE mode. Once that’s been done, it
will be easy to get the authentication token and user information.
Access the target’s most recent log file and collect the AUTH key,
USER, and NICK. From there, simply connect to the IRC server and send
the commands just like above (follow the << prompts). Since the
authorisation has already been completed on the target’s machine, the
key will be valid even though a different NICK may be needed since the
target is probably still connected. The digits with the % in front of
them are the UID of the signed in user. Once you’ve connected, you
will appear as the target USER (even if the NICK is different) since
the chat client software only looks at the mapped UID-Token. This
enables you to send messages around the office as the target by using
the UID of the user to PRIVMSG. These UIDs can be gathered from the
log as well. Send a PRIVMSG using the syntax below:
PRIVMSG %11212 My account has been spoofed!
The failure here is that 1) the SSO service and chat system should
never log the authorisation code and 2) the IRC server shouldn’t allow
multiple connections on the same authorisation token. Hopefully this
article will open their eyes to these glaring holes. Thanks to
BearJew for the testing help.