From: rsnake at shocking.com (RSnake)
Subject: RE: RES: Instant Messenger

	There is only one way I have heard of that can potentially solve part
of this problem.  Of course this will only work with published algorithms so
your mileage may vary.

1) user initiates a connection to a remote server
2) MITM (probably using a variant of ettercap) stops the SSH session and
initiates it's own based on it's own key with the user (you'd have to know what
the SSH headers look like - hense the published algorithm issue)
3) MITM initiates it's own connection to the remote server using it's own key
pair
4) MITM watches for chat traffic, and kills it or logs it accordingly.

	So, there are a number of problems with this, that I'm sure we can all
see.  First, it has to be a known protocol, like SSH.  Second, the user will
get an error, because of the MITM.  Third, doing something painfully simple
like putting every word through a pig latin translator can fool signature based
content filters (I wish I were kidding).  You could do some cryptanalysis on
what chat traffic looks like from a Baysean heuristic perspective, rather than
based on signatures.  This is a stab in the dark, really.  All you'd have to do
is layer another form of encryption or steganography to get around anything
like this.  Really you are talking about all the same issues that you have with
a traditional IDS.  Also, I haven't seen anyone talk about using two different
connections at the same time to bypass content filters, but it is possible
assuming something on the other side can understand the communication.  Socket
1 for the first char, socket 2 for the second, socket 1 for the third, and so
on...  So sure, you can block outbound SSH sessions fairly easily, but what
about some home grown encryption?

	As a side note I was talking to one woman working in a Casino who was
unable to get out of her network because it blocked outbound SSH (well,
anything but outbound port 80 and 443 actually).  That was vaguely effective
only because she couldn't host anything on port 80 because of her own ISPs
restrictions, but a determined chatter, or someone who wants to send secrets
outside the company will be able to do it.  Another idea would be to kill any
active sessions that require open sockets for anything other than port 80, and
even then only one way traffic.  That will kill things like Java Applets that
need open sockets, and certain types of streaming media that don't use UDP...
However, UDP itself could be used to bypass this type of filter.  Sorta reminds
me of how the KIS trojan communicates with unopen sockets.  Anyway, it's a hard
problem, and I haven't seen a vendor yet who can answer even the pig latin
problem, let alone the really hard stuff.

On Mon, 13 Sep 2004, Murtland, Jerry wrote:

| Date: Mon, 13 Sep 2004 11:47:24 -0400
| From: "Murtland, Jerry" <MurtlandJ@...ngeinsurance.com>
| To: 'RSnake' <rsnake@...cking.com>, Alexandre Cezar <acezar@...ncs.com.br>
| Cc: Ido Rosen <ido@...uchicago.edu>,
|      "Murtland, Jerry" <MurtlandJ@...ngeinsurance.com>,
|      pen-test@...urityfocus.com, webappsec@...urityfocus.com,
|      full-disclosure@...ts.netsys.com
| Subject: RE: RES: Instant Messenger
|
| Snake,
|
| That's a very good step-by-step illustration of how to proxy through secure
| remote to external systems.  I'm sure it would make other security staff
| feel as uncomfortable as it does me, but I was aware of this.  However,
| there might be something else that we can discuss that would be of good use
| to me as well as others looking to work on ways to detect and block this
| sort of activity.  Obviously, you can't sniff or detect secure protocol, and
| I've heard of some that say they can, but they that's via SSL and the
| certificates are pointed to from the IDS for filtering signatures.  Not
| effective.
|
| I'm looking for a way to be able to block this all together.  What
| immediately comes to mind is to only allow specific IP's to SSh outbound
| through your firewall and deny all else.  I guess my question is, "Are there
| other methods to circumvent this block after creating this rule set?"
|
| Thanks for the document, I put it to good use!  ;)
|
| Jerry Murtland
|
|
| -----Original Message-----
| From: RSnake [mailto:rsnake@...cking.com]
| Sent: Sunday, September 05, 2004 3:50 PM
| To: Alexandre Cezar
| Cc: Ido Rosen; Murtland, Jerry; pen-test@...urityfocus.com;
| webappsec@...urityfocus.com; full-disclosure@...ts.netsys.com
| Subject: Re: RES: Instant Messenger
|
|
|
| 	On the flip side I wrote a short paper on bypassing content filters
| by
| sending Trillian Pro messages over SSH.  It's a tad off topic, but still
| relevant: http://www.shocking.com/~rsnake/trillianremote.html
|
| On Fri, 3 Sep 2004, Alexandre Cezar wrote:
|
| | Date: Fri, 3 Sep 2004 11:42:31 -0300
| | From: Alexandre Cezar <acezar@...ncs.com.br>
| | To: Ido Rosen <ido@...uchicago.edu>,
| |      "Murtland, Jerry" <MurtlandJ@...ngeinsurance.com>
| | Cc: pen-test@...urityfocus.com, webappsec@...urityfocus.com,
| |      full-disclosure@...ts.netsys.com
| | Subject: RES: Instant Messenger
| |
| | Take a look at http://www.akonix.com for securing IM communication and
| | I recommend this paper
| | www.giac.org/practical/GSEC/Frank_Reiss_GSEC.pdf
| |
| |
| | Regards
| | -----Mensagem original-----
| | De: Ido Rosen [mailto:ido@...uchicago.edu]
| | Enviada em: quinta-feira, 2 de setembro de 2004 23:17
| | Para: Murtland, Jerry
| | Cc: pen-test@...urityfocus.com; webappsec@...urityfocus.com;
| | full-disclosure@...ts.netsys.com
| | Assunto: Re: Instant Messenger
| |
| | Jabber.
| |
| | On Thu, 2 Sep 2004 10:00:18 -0400
| | "Murtland, Jerry" <MurtlandJ@...ngeinsurance.com> wrote:
| |
| | > I am looking for white papers on enterprise Instant Messenger security
| | > concerns.  It doesn't have to be, but anything on MSN IM would be
| | > helpful too.  Does anyone have any good resources to share?
| | >
| | > Jerry J. Murtland
| | >
| | >
| | >
| |
| |
| | --
| | +-------------------------------------------------+
| | |  Email : ido@...e.org / ido@...uchicago.edu     |
| | | Jabber : phaedo@...ber.org                      |
| | |    PGP : http://www.dork.com/ido                |
| | +-------------------------------------------------+
| |
|
| -R
|
| The information in this email is confidential and may be legally
| privileged.  It is intended solely for the addressee.  Access to
| this email by anyone else is unauthorized.  If you are not the
| intended recipient, any disclosure, copying, distribution or any
| action taken or omitted to be taken in reliance on it is
| expressly prohibited and may be unlawful.
|

-R

The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to
this email by anyone else is unauthorized.  If you are not the
intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it is
expressly prohibited and may be unlawful.

Powered by blists - more mailing lists