[Dshield] Trillian Instant Messenger Software

toon@trapped-under-ice.com toon at trapped-under-ice.com
Tue Nov 19 17:41:23 GMT 2002


I use it all the time. The secure channel feature uses a varient of SSL,
basicly. Because of the way it is implimented, however, it is vulnerable to
man-in-the-middle attacks, and I have seen this happen (not in the wild, but
as part of a security exercise). When a MITM attack takes place, no
indication is given to either user that anything is amiss.

This attack is possible because Trillian (like many other "secure"
protocols) focus on securing the end-to-end points, but do not spend any
time attempting to validate either end (to make sure each end is
whom they purport to be).

Here is how the attack happens (watered down explaination):

Alice and Bob both start Trillian.
Alice and Bob both make sure that SecureIM capabilities are turned on in
 their (for this example) AIM transports (all transports are vulnerable).
Alice starts a conversation with Bob using the AIM componant.
Unbeknownst to Alice or Bob, Eve has (somehow) managed to insert a machine
 between Alice and Bob (too many ways to do that to go over here).
Alice's Trillian sees that Bob's AIM is actually Trillian, and that Bob's
 AIM supports SecureIM.
Alice's Trillian initiates a SecureIM connection.
Eve's computer is intercepting each packet and relaying it to the other
 party. So, every packet Alice sends, Eve receives, and then sends to Bob.
 Every packet Bob sends Eve receives and sends to Alice.
Eve's computer sees the SecureIM connection setup, and replaces Alice's key
 with her own, then forwards the packet to Bob.
Bob's Trillian receives the SecureIM setup with Eve's key, not Alice's.
 Bob's secureIM responds with his key, completing the SecureIM connection
 with Eve (not Alice).
Alice takes Bob's key, replaces it with her own, and sends the packet back
 to Alice. This completes the SecureIM connection setup between Alice and Eve
 (Not Bob).
Alice may now sit in the middle, and decrypt each secureIM packet as it
 passes through with her key, and re-encrypt with the final recipient's key,
 and neither Alice nor Bob's Trillian will know.

Sorry that's so long-winded, and I hope I explained it well enough for
everyone to get.

Basicly, it boils down to people making the same mistake they always do -
thinking they can design something better (crypto-wise) that what's already
out there, freely available, in the public domain.

Trillian is a great product, but trust it as much as you trust any other IM
product; not at all.

As I understand it, however, there are some jabber clients which interface
with SSL (again, same MITM attack exists), and/or PGP/GPG (not vulnerable to
MITM attacks).

If you need security, you shouldn't be using an IM client anyway, IMHO.

Just my $.02

 Tod.

On Tue, Nov 19, 2002 at 12:00:02PM -0500, list-request at dshield.org wrote:
> From: "Ronnie Clark" <rsclark at kingwoodcable.net>
> Subject: Re: [Dshield] Trillian Instant Messenger Software
> Date: Mon, 18 Nov 2002 20:45:43 -0600 (CST)
> 
> Yes, I am using the Trillian software right now. But, I have not yet 
> tried the secure channel. As soon as I set it up on my wife's computer, 
> I will let you know how it performs. I'll even post packet dumps if 
> that might be useful...
> 
> Ron Clark
> 
> 
> > Has anyone had a chance to evaluate the Trillian IM software?  I
> > understand it's supposed to be a secured messaging channel?  Does 
> anyone
> > have anymore info?
> > 
> > - WB
> > 

-- 

 * This email posted in pure ASCII * HTML is for browsers.    *
 * for your protection.            * My MUA is not a browser. *
 * chown -R us.us yourbase         *         KC0MRX           *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/list/attachments/20021119/ee7ab153/attachment.bin


More information about the list mailing list