[Snort-sigs] 1:11672, 3:11672 BROWSER-OTHER Mozilla Network Security Services SSLv2 stack overflow attempt

Y M snort at outlook.com
Fri Jun 29 09:11:19 EDT 2018


Re-looking at the rule, it seems that it is triggering when external IP addresses destined to the protected network ($HOME_NET) on port 443 when the flowbit sslv2.client_master_key.request is not set, while setting at the same time.  Since the rule is compiled, it is difficult to determine the content matches. The traffic generating this could be anything from a scanner, scripts, automated tools, outdated client requests, etc. Determining the ultimate risk of this rule will be almost impossible to anyone except yourself.

Hope this helps.
YM

________________________________
From: Snort-sigs <snort-sigs-bounces at lists.snort.org> on behalf of Steve Thames via Snort-sigs <snort-sigs at lists.snort.org>
Sent: Friday, June 29, 2018 1:21 AM
To: snort-sigs at lists.snort.org
Subject: Re: [Snort-sigs] 1:11672, 3:11672 BROWSER-OTHER Mozilla Network Security Services SSLv2 stack overflow attempt




The only rule I have is 3:11672, I don't see 1:11672.



Agreed. Apparently the old rule 1:11672 is not included any longer.



Looking at the direction of the rule, I assume it is the response of the server that maybe triggering the rules. Do the responding servers have anything in common such as IP addresses, SSL configurations/certificate? You might want to look closer at the traffic and the payload triggering the rule.



Here is the rule signature:



alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"BROWSER-OTHER Mozilla Network Security Services SSLv2 stack overflow attempt"; sid:11672; gid:3; rev:8; classtype:attempted-admin;

flowbits:isnotset,sslv2.client_master_key.request; flowbits:set,sslv2.client_master_key.request; reference:cve,2007-0009; reference:bugtraq,22694;

reference:url,labs.idefense.com/intelligence/vulnerabilities/display.php?id=482; metadata: engine shared, soid 3|11672, service ssl, policy max-detect-ips drop;)



Perhaps I don’t understand snort rules but I thought this was describing traffic coming from the Internet to my servers.

Are you suggesting this alert will be triggered by a response from $HOME_NET 443?



flowbits:isnotset,sslv2.client_master_key.request; flowbits:set,sslv2.client_master_key.request;



AFAICT, this is the only part of the rule that matters and it appears to be saying “trigger this alert if the request is trying to set ‘sslv2.client_master_key.request’ and it is not already set.”

I’m guessing this alert is being triggered by a bot that is simply attempting to gain admin access by exploiting the NSS vulnerability described here<https://www.mozilla.org/en-US/security/advisories/mfsa2007-06/>.



Can someone describe how a request could trigger this rule and if there is any danger to modern Apache or IIS servers?





________________________________

From: Snort-sigs <snort-sigs-bounces at lists.snort.org> on behalf of Steve Thames via Snort-sigs <snort-sigs at lists.snort.org>
Sent: Thursday, June 28, 2018 7:30 PM
To: snort-sigs at lists.snort.org
Subject: [Snort-sigs] 1:11672, 3:11672 BROWSER-OTHER Mozilla Network Security Services SSLv2 stack overflow attempt



In my pfSense Snort IDS/IPS, I am seeing an increasing number of these alerts from customer network IPs. These are large orgs with, potentially, hundreds of clients NATed to a single public IP.



This a very old threat and I’m reasonably sure the clients are not using a 10-year-old version of Mozilla, Thunderbird, SeaMonkey, or Java to access our web servers.



Can someone shed some light on why we would be seeing an increasing number of these alerts?



Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20180629/cfc7f80d/attachment-0001.html>


More information about the Snort-sigs mailing list