[Emerging-Sigs] Detect non SSL traffic

[Jason Chips]

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>:

> 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
>> 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
>
>
> _______________________________________________
> Emerging-sigs mailing list
> 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

_______________________________________________
Emerging-sigs mailing list
Emerging-sigs at emergingthreats.net
http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20080710/583fcbc6/attachment.html