Hotfix for MSIE problem related to MS06-042
All those of you holding off on the MS06-042 patch or suffering from issues due to MSIE crashing on Windows 2000 SP4 and Windows XP SP1, there is a new hotfix out:
http://support.microsoft.com/kb/923762/en-us
It's interesting to note the date on the file, as well as the claim that the crashes seem to be triggered by websites using the HTTP 1.1 protocol and compression.
Anyway, this might make your weekend more interesting.
Thanks Kathleen for the heads-up!
--
Swa Frantzen -- Section 66
http://support.microsoft.com/kb/923762/en-us
It's interesting to note the date on the file, as well as the claim that the crashes seem to be triggered by websites using the HTTP 1.1 protocol and compression.
Anyway, this might make your weekend more interesting.
Thanks Kathleen for the heads-up!
--
Swa Frantzen -- Section 66
Keywords:
0 comment(s)
Snort rulez management
A few readers have written in with new snort rules, comments on those we have posted, or questions about managing snort rules. So this is a request for the community to share how best to write and manage snort rules. I'll summarize as the Tip of the Day at the end of this shift. Send us your tips here
The tips submitted have been published here.
So far no tips on writing rules, but some great ideas on management.
Cheers,
Adrien
The tips submitted have been published here.
So far no tips on writing rules, but some great ideas on management.
Cheers,
Adrien
Keywords:
0 comment(s)
Tip of the Day : snort rule management
Tip1
We maintained a central CVS repository where each analyst had an account. The repository contained the snort configurations for each sensor (different subdirectories) and snort rules from sourcefire in addition to tuned rules, custom local rules, and some 3rd party rules. I wrote some python scripts to filter out "good" bleeding-snort rules for example.
every N hours, each snort sensor would update its rules and configs from CVS and reload itself
on a daily basis a cron job would pull down the latest rules from sourcefire, do a diff of what changed and email that diff to all the analysts. It would then automatically add the new changes to a branch in CVS that would be merged in 24 hours unless an analyst who had seen the diff made changes otherwise.
any time a rules change was committed, the CVS server would run the config files and rules through snort -T to validate the syntax and would reject the commit if it failed validation, so the CVS repository always at least had valid configuration files in it.
whenever an analyst committed a change to anything in CVS, a diff was taken and emailled to all the other analysts letting them know what happened.
If a sensor ever blew up, replacing it was trivial, as was reverting the rules or config back to an earlier configuration thanks to CVS and additionally, all changes were tracked to who did what when, so troubleshooting problems became easier as well.
Tip2
For updating and managing Snort rules use Oinkmaster (http://oinkmaster.sourceforge
However, when it comes to implementing rules, don't just assume the rules are going to be perfect and without flaws. The process I use is:
1. Check if there are any new rules and notify me but don't install them.
2. After reviewing the rules, install the rules.
3. Run a taint check against the rules. If there is a problem, revert back to the old set (you did make a backup, right?) and notify the rule author.
4. Activate the new rules and monitor for false positives.
5. If false positives are found then report them to the rule author and help, if possible, with testing the corrected rules.
- KenM
Tip3
I work for a major (healthcare organization), and we have multiple snort boxes deployed at multiple aggregate points within the network. The architecture follows a standard snort deployment with multiple sensors sending alert data via mysql to a mysql database, and then there is an IDS correlation web application front ending the db to view event data etc. As the IDS correlation web application has the ability to manage snort rules, the functionality did not meet our technical needs. As a solution, we designated two snort sensors to serve as the rules management systems using oinkmaster. One system is positioned on our link out to the Internet, while the other is at another aggregate point. These two systems are fully redundant in respect to the oinkmaster configuration for pulling down rules, however, the sensor located on link out has a different rules directory because this is the only link we see traffic heading out to the Internet, and to avoid the same alerts in the IDS console, the HOME_NET to EXTERNAL_NET is only useful at this location. The secondary sensor does the opposite and triggers on rules not heading out to the public Internet; HOME_NET to HOME_NET etc.
The snort box on link-out is configured to automatically poll updates from bleeding-snort and snort.org using oinkmaster. As these rules are downloaded and installed, I receive an email on the rules added or if there were any modifications to the existing rules. Once this is complete, I have a script that syncs the /rules directory to all other snort sensors and restarts the snortd engine. This uses a PKI architecture to automate the login to each remote snort sensor. Also, the script is intelligent enough to sync other important snort files, such as snort.conf, and other configuration files. In regards to local rules, we administer these rules only on the link-out snort sensor, and the secondary master sensor has the same script to sync local rules to the remaining snort sensors.
In regards to snort.conf, we define all variables, such as HOME_NET, EXTERNAL_NET, DNS, etc? as this is crucial to mitigate false positives. Also, if we create local rules that need added variables to make it easier to group ports or IP addresses, we create new variables in snort.conf so each rule can cross reference the variables.
Tip4
Having already extended neck for the chopping block and been smacked accordingly ;-)...I use the following to do quick changes and checks to my Snort installs on CentOS 4.3.
Ultimately, it's purely a convenience factor to type single word commands so, in my path, I keep the following little scripts, chmod a+x applied.
For Bleeding-Edge rules, I prefer the single bleeding-all.rules so I use this to update it rather than Oinkmaster:
#bleedingpig
cd /etc/snort/rules/
rm -f bleeding-all.rules
wget http://www.bleedingsnort.com
-----------------------
To fire Oinkmaster manually rather than cron:
#oink
oinkmaster.pl -C /etc/oinkmaster.conf -C /etc/autodisable.conf -o /etc/snort/rules
-----------------------
To kill the daemon:
#killpig
killall snort
-----------------------
To confirm Snort process state:
#pigps
ps aux | grep snort
-----------------------
To confirm Snort running cleanly after config or rule changes:
#pigchk
/usr/local/bin/snort -c /etc/snort/snort.conf -i eth1 -v
-----------------------
To start the daemon:
#pigd
/usr/local/bin/snort -c /etc/snort/snort.conf -i eth1 -g snort -D
- RussM
Cheers,
Adrien
Keywords: ToD
0 comment(s)
NT 4.0 Protection
A number of readers have asked about NT 4.0 recently with regards to vulnerability advisories or exploits. I have found that one of the best ways to protect legacy applications and operating systems is to isolate them. Ideally only those clients/users that absolutely must access these systems should be able to. This can be accomplished at the switch, router, firewall, proxy, or at the end point. The painful part of the process is establishing who must access what, and then which protocols are actually needed. Then figure out where you can best form an 'enclave' or internal perimeter with access control. This isn't ideal, but can shield these systems from a worm or unauthorized access. You also need to determine the value of the data/service that these systems have. If they are performing a valuable service, or hold critical data you really should be protecting them. The unfortunate truth is that NT 4.0 is dead, and really should not be used.
One reader wrote back:
"Block port 139 at our choke routers and possibly some network routers. Remove systems from the network
Remove the infection if possible (hopefully a tool would be created to remove). Possibly buy support for NT from MS. Disable port 139 on the NT systems. This would most likely break what is running on the system, which would be broken anyway. We have a patch cycle around patch Tuesday. We will be ready to patch next Tuesday. Currently testing. The operation that you mentioned about isolating systems would be difficult for us to manage. Let's hope that those out there who might be thinking of releasing a worm remember the last several mass attacks that occurred against MS, these individuals have been arrested and prosecuted."
Another reader wrote in that there are third party support pay options for NT 4.0, including custom patch development.
The bottom line though, you really do need a migration/upgrade plan.
Cheers,
Adrien
One reader wrote back:
"Block port 139 at our choke routers and possibly some network routers. Remove systems from the network
Remove the infection if possible (hopefully a tool would be created to remove). Possibly buy support for NT from MS. Disable port 139 on the NT systems. This would most likely break what is running on the system, which would be broken anyway. We have a patch cycle around patch Tuesday. We will be ready to patch next Tuesday. Currently testing. The operation that you mentioned about isolating systems would be difficult for us to manage. Let's hope that those out there who might be thinking of releasing a worm remember the last several mass attacks that occurred against MS, these individuals have been arrested and prosecuted."
Another reader wrote in that there are third party support pay options for NT 4.0, including custom patch development.
The bottom line though, you really do need a migration/upgrade plan.
Cheers,
Adrien
Keywords:
0 comment(s)
MS06-040 and MS06-042 updates
MS06-040 (Server Service Patch):
We are getting a lot of questions about this one. The short answer: Don't panic, but keep on patching. It apprears that the release of a public exploit is imminent, but we don't have it. A lot of speculations about a possible worm. But then again, worms are so 2004. Once an exploit is made public, I would expect it to be added to standard bot payloads quickly.MS06-042 (MSIE Rollup patch):
We received some reports about users having problems with Internet Explorer crashing after applying the latest patch (MS06-042) and accessing certain sites ? mainly Peoplesoft applications.We can't confirm this yet, but it looks like only Windows XP SP1 machines that applied the patch are affected (Windows XP SP2 with the patch seems to be working ok, from some very limited tests we were able to do).
Let us know if you can confirm this.
Update
We have also had a number of reports that Windows 2000 is also affected, particularly accessing Peoplesoft applications. Rather than un-installing the patch, using an alternate browser is another workaround.
Keywords:
0 comment(s)
Snort Sig for MS06-040
The US-CERT shared the following Snort signature with us on Thursday. This is for the MS06-040 vulnerability and may not match some of the public exploits discussed in an earlier diary. If this signature alerts, please let us know via the contact form.
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; classtype:malicious-activity; sid:1000003; rev:1;)
Note that the RPC_PORTS is a placeholder for 135, 139, 445.
UPDATE #1
Russ wrote us with some additional ideas:
Thanks, Russ!!
UPDATE #2
Handler Judy Novak suggested that this will work better:
We received a few other notes suggesting that Russ' ideas above would not work properly and that as written only the last variable would trigger (445). We are working to get an updated rule that should work on all three ports. Also, as a reminder - this rule only detects one of several exploits. If you have other rules you can share, please send them in and we'll keep updating the entry.
UPDATE #3
Joel over at Sourcefire sent us some pointers:
Many subscription services have other rules available (like snort.org) but due to licensing restrictions we cannot post them here at the Internet Storm Center until the owners have given us permission to do so. So if you have any WORKING rules that you can share, please send them along via our contact page. Also, see Adrien's note about today's Tip of the Day for writing good Snort rules.
Marcus H. Sachs
SRI International
Director, SANS Internet Storm Center
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; classtype:malicious-activity; sid:1000003; rev:1;)
Note that the RPC_PORTS is a placeholder for 135, 139, 445.
UPDATE #1
Russ wrote us with some additional ideas:
In order to make the US-CERT rule work I had to do as follows:
Add to snort.conf under network variable:
# Placeholder for 135, 139, 445
var RPC_PORTS 135
var RPC_PORTS 139
var RPC_PORTS 445
Add to classification.config under NEW CLASSIFICATIONS:
config classification: malicious-activity,Malicious Activity,2
Then I dropped that actual rule in rpc.rules.
Add to snort.conf under network variable:
# Placeholder for 135, 139, 445
var RPC_PORTS 135
var RPC_PORTS 139
var RPC_PORTS 445
Add to classification.config under NEW CLASSIFICATIONS:
config classification: malicious-activity,Malicious Activity,2
Then I dropped that actual rule in rpc.rules.
Thanks, Russ!!
UPDATE #2
Handler Judy Novak suggested that this will work better:
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; flow:to_server,established; content:"| 90 90 EB 04 2B 38 03 78 |"; classtype:malicious-activity; sid:1000003; rev:1;)
We received a few other notes suggesting that Russ' ideas above would not work properly and that as written only the last variable would trigger (445). We are working to get an updated rule that should work on all three ports. Also, as a reminder - this rule only detects one of several exploits. If you have other rules you can share, please send them in and we'll keep updating the entry.
UPDATE #3
Joel over at Sourcefire sent us some pointers:
Step one, you can't just place three vars with one rule. You either have to do something like
var RPC_PORTS 135
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
var RPC_PORTS 139
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
var RPC_PORTS 445
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
Effectively reloading the rule three times.
Or you have to do something like this:
alert tcp any any -> any 135:445 (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
Which will run the rule on all ports 135 THROUGH 445.
I would also improve the rule:
alert tcp $EXTERNAL_NET any -> $HOME_NET 135:445 (msg:"US-CERT MS06-040 Indicator"; flow:to_server,established; content:"|90 90 EB 04 2B 38 03 78|"; rev:2;)
However, I make absolutely no guarantees that the payload will be caught using that content match. As you said it only detects one exploit. Writing the rule in this fashion will only make you wind up with 20 rules for 20 different exploits. The trick is to write the rule to look for the vulnerability, so no matter what the exploit method, it's detected everytime.
var RPC_PORTS 135
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
var RPC_PORTS 139
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
var RPC_PORTS 445
alert tcp any any -> any $RPC_PORTS (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
Effectively reloading the rule three times.
Or you have to do something like this:
alert tcp any any -> any 135:445 (msg:"US-CERT MS06-040 Indicator"; content:"| 90 90 EB 04 2B 38 03 78 |"; rev:1;)
Which will run the rule on all ports 135 THROUGH 445.
I would also improve the rule:
alert tcp $EXTERNAL_NET any -> $HOME_NET 135:445 (msg:"US-CERT MS06-040 Indicator"; flow:to_server,established; content:"|90 90 EB 04 2B 38 03 78|"; rev:2;)
However, I make absolutely no guarantees that the payload will be caught using that content match. As you said it only detects one exploit. Writing the rule in this fashion will only make you wind up with 20 rules for 20 different exploits. The trick is to write the rule to look for the vulnerability, so no matter what the exploit method, it's detected everytime.
Many subscription services have other rules available (like snort.org) but due to licensing restrictions we cannot post them here at the Internet Storm Center until the owners have given us permission to do so. So if you have any WORKING rules that you can share, please send them along via our contact page. Also, see Adrien's note about today's Tip of the Day for writing good Snort rules.
Marcus H. Sachs
SRI International
Director, SANS Internet Storm Center
Keywords:
0 comment(s)
Tip of the Day: Use the features of your switches
Chances are that you have very smart switches in your corporate environment, but only use them for a small portion of their capability to do some VLANs or so.
So some tips of what switches can do for you on the security side of things with a little reconfiguration.
You will notice that most of these will require a managed switch port per host, so combine them together to get to this.
Think of your DMZs: would it be good if your email gateway cannot talk to your public webserver, while still sitting in the same network ? Sure, it would mean that if somebody finds a vulnerability in your SMTP server they cannot escalate their tools towards your webserver and from there e.g. move towards your database back-end.
Another environment where this can do wonders is a internal LAN: do clients have any business need to talk to other clients ? Or do they just need to talk to default routers and servers? Worms can run rampant inside an Internal LAN, but if the machines cannot exchange packets, there is little to propagate over. Imagine running such a network and having 5 employees clicking on an email worm and only having to clean up 5 workstations (while it was network aware and would have taken out your network).
Limit the number of MACs per port
Teaching switch ports to shutdown when they learn more than one MAC address is not only an obvious way to stop rogue hubs, to stop flooding mac stables, but it teaches the users that the network and its policies is something to be taken serious.
If they have policies that deny them to mess with the network and the network shuts down when they do it anyway, you force them into turning themselves in... . Even if you can be less strict for the first problem, they learn the lesson not to mess very fast.
Shutdown unused ports
Shutting down unused ports keeps the ability to add rogue machines much lower and allows for enforcing processes that require a consious action on the network to enable the machines to use it.
Web based management might be appealing at first, but take great care with it. Using a separate VLAN to manage the switches is common good practice. So is not using protocols like telnet but relying on ssh instead. VLAN multiplexing such as 802.1q should only be done towards other switches under the same management, not towards hosts not absolutely needing this ...
Follow up on vulnerabilities for the vendor and plan the updates accordingly.
--
Swa Frantzen -- Section 66
So some tips of what switches can do for you on the security side of things with a little reconfiguration.
You will notice that most of these will require a managed switch port per host, so combine them together to get to this.
Private VLANs
Private VLANs can be used to stop certain ports to talk among themselves. Now where would such a thing be a good thing (TM)?Think of your DMZs: would it be good if your email gateway cannot talk to your public webserver, while still sitting in the same network ? Sure, it would mean that if somebody finds a vulnerability in your SMTP server they cannot escalate their tools towards your webserver and from there e.g. move towards your database back-end.
Another environment where this can do wonders is a internal LAN: do clients have any business need to talk to other clients ? Or do they just need to talk to default routers and servers? Worms can run rampant inside an Internal LAN, but if the machines cannot exchange packets, there is little to propagate over. Imagine running such a network and having 5 employees clicking on an email worm and only having to clean up 5 workstations (while it was network aware and would have taken out your network).
Limit the number of MACs per port
Teaching switch ports to shutdown when they learn more than one MAC address is not only an obvious way to stop rogue hubs, to stop flooding mac stables, but it teaches the users that the network and its policies is something to be taken serious. If they have policies that deny them to mess with the network and the network shuts down when they do it anyway, you force them into turning themselves in... . Even if you can be less strict for the first problem, they learn the lesson not to mess very fast.
Manage unknown MAC addresses
If you keep a good inventory of what MAC addresses are known good (It's not that hard to do it, really all you need is entry, replacement and exit processes for machines or network parts), you can decide what to do if a switch learns an unauthorized MAC address:- Shutting down the port is a good option in a high secure network. It teaches the lesson to the users to comply with the policies and not bring unauthorized hardware and hook it up to the network.
- Dumping the port in a "GUEST" VLAN and giving them Internet access only (no internal, no ...). This is a great solution if you have an open environment where people, consultants etc walk in and hook up to get Internet connectivity, attend meetings etc.
Limit traffic
Many switches understand traffic and can actually filter it, interesting things to limit are the ability to answer on requests such as DHCP, except for your official DHCP servers. It helps to avoid the problems with rogue DHCP servers racing to hand configuration to your clients.Monitor traffic.
Check traffic statistics on ports using commercial setups or simply with "rrd", can often detect anomalies long before anybody has analyzed the malware and or written signatures for it. Moreover you can trace it back to physical ports and physical machines that you can go and collect, no matter what clever hiding the bad guys tried to do.Shutdown unused ports
Shutting down unused ports keeps the ability to add rogue machines much lower and allows for enforcing processes that require a consious action on the network to enable the machines to use it.VLANs vs. airgaps
VLANs are easy to configure and many network engineers just love them, but in high security environments, keep in mind that an airgap using real air is fundamentally more secure than one using logic in a switch. Also you might find that small switches, even managed ones that can do all on this page, aren't all that expensive to use in e.g. a DMZ.Manage the switches, keep them secure
A bit obvious perhaps, but SNMP v1/2 community strings are basically passwords and "public" and "private" are real bad choices. Go for v3 if you can. And if you do not use SNMP, turn it off.Web based management might be appealing at first, but take great care with it. Using a separate VLAN to manage the switches is common good practice. So is not using protocols like telnet but relying on ssh instead. VLAN multiplexing such as 802.1q should only be done towards other switches under the same management, not towards hosts not absolutely needing this ...
Follow up on vulnerabilities for the vendor and plan the updates accordingly.
--
Swa Frantzen -- Section 66
Keywords: ToD
0 comment(s)
eEye Releases Free Scanner for MS06-040
We received a heads up tonight from Marc Maiffret (thanks Marc!!) that eEye had released a free vulnerability scanner that searches for the MS06-040 vulnerability. According to Marc:
"we have released a free vulnerability assessment tool for the critical, and potentially wormable, MS06-040 vulnerability. This free tool can be used by IT administrators to scan their networks for any potentially vulnerable machines. This tool does not require administrator access to machines so it will give IT administrators a real-world perspective on where their network stands against this attack regardless of what they think they have or have not patched yet."
Another email about the scanner went out to a public mailing list and provided an email address in case you find bugs in it:
"Look forward to your feedback and please feel free to email skunkworks@eeye.com if you find any bugs in it etc..."
No one around the ISC has had a chance to test it yet, but many of us have downloaded for tomorrow. Here is the tool and the link for it!
Retina MS06-040 NetApi32 Scanner
http://www.eeye.com/html/resources/downloads/audits/NetApi.html
Happy Scanning!
UPDATE
While testing the 16 IP address version (and as confirmed by one of our readers) we noticed a small bug with this tool. When selecting which IP addresses to scan, the user can pick between a single IP address, an IP range and a CIDR notation.
If the IP range option was used, a user simply has to enter the first and last IP address (there can be no more than 16 IP addresses scanned at the time). However, for some reason the tool doesn't scan the last 2 IP addresses. You can, of course, include those 2 IP addresses in the following scan, but we just wanted to warn you if you are already using this. We've contacted eEye and believe they will release a new version soon (the currently available version is 1.0.0.5).
Other than that we just wanted to add that, in order to download the tool, you have to either submit your e-mail address (for the 16 IP scanner) or fully register on eEye's site (this is required for the 256 IP scanner).
"we have released a free vulnerability assessment tool for the critical, and potentially wormable, MS06-040 vulnerability. This free tool can be used by IT administrators to scan their networks for any potentially vulnerable machines. This tool does not require administrator access to machines so it will give IT administrators a real-world perspective on where their network stands against this attack regardless of what they think they have or have not patched yet."
Another email about the scanner went out to a public mailing list and provided an email address in case you find bugs in it:
"Look forward to your feedback and please feel free to email skunkworks@eeye.com if you find any bugs in it etc..."
No one around the ISC has had a chance to test it yet, but many of us have downloaded for tomorrow. Here is the tool and the link for it!
Retina MS06-040 NetApi32 Scanner
http://www.eeye.com/html/resources/downloads/audits/NetApi.html
Happy Scanning!
UPDATE
While testing the 16 IP address version (and as confirmed by one of our readers) we noticed a small bug with this tool. When selecting which IP addresses to scan, the user can pick between a single IP address, an IP range and a CIDR notation.
If the IP range option was used, a user simply has to enter the first and last IP address (there can be no more than 16 IP addresses scanned at the time). However, for some reason the tool doesn't scan the last 2 IP addresses. You can, of course, include those 2 IP addresses in the following scan, but we just wanted to warn you if you are already using this. We've contacted eEye and believe they will release a new version soon (the currently available version is 1.0.0.5).
Other than that we just wanted to add that, in order to download the tool, you have to either submit your e-mail address (for the 16 IP scanner) or fully register on eEye's site (this is required for the 256 IP scanner).
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments