WebApp Sec mailing list archives
RE: RES: Instant Messenger
From: RSnake <rsnake () shocking com>
Date: Mon, 13 Sep 2004 10:59:13 -0700 (PDT)
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 () Grangeinsurance com> | To: 'RSnake' <rsnake () shocking com>, Alexandre Cezar <acezar () opencs com br> | Cc: Ido Rosen <ido () cs uchicago edu>, | "Murtland, Jerry" <MurtlandJ () Grangeinsurance com>, | pen-test () securityfocus com, webappsec () securityfocus com, | full-disclosure () lists 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 () shocking com] | Sent: Sunday, September 05, 2004 3:50 PM | To: Alexandre Cezar | Cc: Ido Rosen; Murtland, Jerry; pen-test () securityfocus com; | webappsec () securityfocus com; full-disclosure () lists 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 () opencs com br> | | To: Ido Rosen <ido () cs uchicago edu>, | | "Murtland, Jerry" <MurtlandJ () Grangeinsurance com> | | Cc: pen-test () securityfocus com, webappsec () securityfocus com, | | full-disclosure () lists 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 () cs uchicago edu] | | Enviada em: quinta-feira, 2 de setembro de 2004 23:17 | | Para: Murtland, Jerry | | Cc: pen-test () securityfocus com; webappsec () securityfocus com; | | full-disclosure () lists netsys com | | Assunto: Re: Instant Messenger | | | | Jabber. | | | | On Thu, 2 Sep 2004 10:00:18 -0400 | | "Murtland, Jerry" <MurtlandJ () Grangeinsurance 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 () ieee org / ido () cs uchicago edu | | | | Jabber : phaedo () jabber 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.
Current thread:
- RES: Instant Messenger Alexandre Cezar (Sep 04)
- Re: [Full-Disclosure] RES: Instant Messenger Über GuidoZ (Sep 04)
- Re: RES: Instant Messenger RSnake (Sep 05)
- <Possible follow-ups>
- RE: RES: Instant Messenger Murtland, Jerry (Sep 14)
- RE: RES: Instant Messenger RSnake (Sep 13)