[Emerging-Sigs] Detect non SSL traffic

[Matt Jonkman]

Been thinking about this more. There are 4 sigs that I wrote for the 
detecting ssl on off ports that detect the opening of the key exchange. 
They're pretty low load, and I think they'd be reliable enough to say 
the entire stream is likely SSL. Or at least very likely not to be 
something else.

I'll test them locally for a bit and see how it goes. If anyone else is 
interested in testing on a heavy user net I'd appreciate it, please ping 
me off list.

Matt

Jason Chips wrote:
> Thanks for the suggestions Jack, I will try out the ASCII 
> "AAAAAAAAAAAAAAAA" in the payload rule for tcp/443.
>  
> Unfortunately, the hackers using the outbound tcp/443 connections use 
> their own custom-written backdoor software, which has been seen as 
> plaintext (we can see DOS commands like DIR C:\WINDOWS etc), or 
> encrypted with an algorithm other than SSL.  No actual HTTP has been 
> seen in these backdoor channels.
>  
>  
> ----- Original Message ----
> From: Jack Pepper <pepperjack at afferentsecurity.com>
> To: emerging-sigs at emergingthreats.net
> Sent: Thursday, July 10, 2008 10:01:42 AM
> Subject: Re: [Emerging-Sigs] Detect non SSL traffic
> 
> How about searching for words like POST GET, etc over port 443?
> 
> We already find lots of bofs by looking for AAAAAAAAAAAAAAAAAAAAA on 
> port 443.
> 
> should work.  What are the odds that we would see the words "HTTP 
> /1.1\r\n" in an encrypted session?
> 
> jp
> 
> Quoting Matt Jonkman <jonkman at jonkmans.com <mailto:jonkman at jonkmans.com>>:
> 
>  > Hey Jason. We have some sigs for a positive detection of ssl on off
>  > ports, we could probably do something for non-ssl using the same set.
>  > Here's what's there now, it's in Policy:
>  >
>  > 
> http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/POLICY/POLICY_SSL_TLS_on_High_Port?rev=1.2
>  >
>  > There are essentially 3 or 4 opening patterns we can detect to pretty
>  > reliably say it's going to be an SSL session, then set a flowbit to
>  > ignore the stream.
>  >
>  > We've thought about trying this before, and I think what we all
>  > discussed about it was the possibility of false positives. There are
>  > surely real apps using 443 but not ssl. Maybe if we could write these
>  > rules and test them in a few live nets to see it'd be safer. Any 
> volunteers?
>  >
>  > Matt
>  >
>  > Jason Chips wrote:
>  >> I have recently run into a couple cases where hackers who managed to get
>  >> their malware installed on systems behind our corporate firewall, would
>  >> use outbound tcp/443 connections to their C&C servers to report in,
>  >> control the infected system, etc.  I imagine they chose tcp/443 because
>  >> many people have historically ignored it at the firewall, web usage
>  >> monitor, and IDS because they assumed it to only carry legitimate
>  >> encrypted data.  I have seen cases of these C&C channels being
>  >> plaintext or encrypted with an algorithm besides SSL/TLS.  Of course a
>  >> good outbound web proxy will reject tcp/443 traffic which is not SSL/TLS
>  >> compliant.
>  >>
>  >> Can someone gve me a pointer on how to create a Snort rule to do the
>  >> following:
>  >>
>  >> Alert on tcp/443 traffic which is not a valid SSL/TLS connection.  More
>  >> specifically, I know that snort recently introduced the ssl
>  >> preprocessor, and it has the "noinspect encrypted" option[1].  I am
>  >> afraid that this option just looks for the presence of defined SSL
>  >> handshake error messages, and will only engage if it detects one of
>  >> these.  If I am wrong about this, the rule should be easy to write.  The
>  >> other way that I thought about approaching this was to check for the
>  >> presence of the SSL Client Hello pattern on the FIRST packet seen after
>  >> an established tcp connection with the Push flag set.  Is there a way to
>  >> accomplish this in Snort?
>  >>
>  >>  Thanks for any opinions or help,
>  >>
>  >> Jason
>  >>
>  >>
>  >> 1.  http://www.snort.org/docs/snort_htmanuals/htmanual_282/node135.html
>  >>
>  >>
>  >>
>  >>
>  >>
>  >> ------------------------------------------------------------------------
>  >>
>  >> _______________________________________________
>  >> Emerging-sigs mailing list
>  >> Emerging-sigs at emergingthreats.net 
> <mailto:Emerging-sigs at emergingthreats.net>
>  >> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>  >
>  > --
>  > --------------------------------------------
>  > Matthew Jonkman
>  > Emerging Threats
>  > Phone 765-429-0398
>  > Fax 312-264-0205
>  > http://www.emergingthreats.net <http://www.emergingthreats.net/>
>  > --------------------------------------------
>  >
>  > PGP: http://www.jonkmans.com/mattjonkman.asc
>  >
>  >
>  > _______________________________________________
>  > Emerging-sigs mailing list
>  > Emerging-sigs at emergingthreats.net 
> <mailto:Emerging-sigs at emergingthreats.net>
>  > http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>  >
> 
> 
> 
> -- 
> 
> Framework?  I don't need no stinking framework!
> 
> ----------------------------------------------------------------
> @fferent Security Labs:  Isolate/Insulate/Innovate 
> http://www.afferentsecurity.com <http://www.afferentsecurity.com/>
> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net <mailto:Emerging-sigs at emergingthreats.net>
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc