Handler on Duty: Guy Bruneau
Threat Level: green
Published: 2006-10-31
Ghoulies and Ghosties
Ah, scary things are afoot and go bump while you surf the web! Increasingly unfriendly critters are set to leave you the choice between "trick or trick" whenever you open the browser! One bit that recently caught my eye again is the increasing effort made by Javascript exploit authors to disguise their crud. Take this one:
Now, anyone can tell from looking at this that whoever wrote this code is trying to hide something. Gone are the days when simple substitutions (like: encoded B is an A, encoded C is a B, etc) were used to hide the URLs where the next bit of nefarious code was pulled from. Over the last months, attackers have apparently evolved beyond first grade math, to highly complex :) concoctions involving binary "shift" and "bitwise and" operations. Wow!
Good thing is though, no matter how many turns and twists they take, decoding the mess is still pretty easy. Frequent readers of this diary will know that "amending" such Javascript blobs with a little additional Javascript, like a carefully placed
Published: 2006-10-30
ToD - Configuration Management - maintaining security awareness
There have been multiple Anti Virus vendor security issues reported over the past month. Myself being a user of a wide assortment of Anti Virus packages in an ongoing malware categorization and analysis project, thought it would be a 'good idea'(tm) to offer a new 'Tip of the Day' in recommending that you ensure sufficient attention is being paid to security related notices and upgrades for any applications that you may be dependant upon. The concept really falls back to generic host configuration management best practices and is applicable to any application you may use aside from specific security applications. Of specific concern should be any application that may use content obtained from the public internet at large. Anti Virus, Personal Firewalls, Streaming media applications, Office productivity tools, Instant Messaging applications, and the list goes on. To avoid the perception of vendor bashing *which I am not*, I choose to leave it to the reader to determine your security product patch/release status.
Target Audience:
William Salusky
"Malware Hunter/Gatherer (among other things)"
Handler on Duty Geotagged: nearby
Target Audience:
- Maintaining security awareness for your installed application base is likely more important for the average SOHO/home user running Anti Virus and other security solutions that may not benefit from an enterprise configuration management team watching out for their interests 24x7.
- Visit all application vendor websites for your installed application base and subscribe to any available RSS feeds, or announcement mailing lists they may offer to licensed application holders.
- Determine if your chosen product(s) have an embedded update notification mechanism and enable that feature for notification or auto-update as appropriate.
William Salusky
"Malware Hunter/Gatherer (among other things)"
Handler on Duty Geotagged: nearby
0 Comments
Published: 2006-10-29
Remote DoS released targets Windows Firewall/Internet Connection Sharing (ICS) service component
We have received a report that a DoS exploit has been released that targets ipnathlp.dll, which is used by the Windows Firewall/Internet Connection Sharing (ICS) service. We also received a report that the exploit works against a fully patched XP SP2 system (Tyler Reguly of nCircle / blogs.nCircle.com submitted the report, some of his report information is below).
UPDATE Yesterday Tyler completed additional work and posted information at nCircle's blog, see his Microsoft ICS DoS FAQ
Thanks again Tyler.
Original Diary below;
The Windows Firewall/Internet Connection Sharing (ICS) service may be running even though Windows Firewall is disabled.
To determine if your system has the service running, type the following at a command prompt:
sc query sharedaccess
The short name of this service is SharedAccess, the full name is Windows Firewall/Internet Connection Sharing (ICS).
Tyler Reguly reported;
Microsoft Error Message:
Generic Host Process for Win32 Services has encountered a problem and needs to close. We are sorry for the inconvenience.
View What's in this report:
Error signature:
szAppName: svchost.exe szAppVer: 5.1.2600.2180
szModName: ipnathlp.dll szModVer 5.1.2600.2180 offset: 0001d45e
UPDATE - 1:16 PM EDST - Tyler reported that only ICS was enabled, "the Firewall was disabled at the time.".
Thanks for the work and followup Tyler!
Other information;
UPDATE - 5:40 PM EDST - According to the MS Windows Compute Cluster Server 2003 Deployment website, "Windows Compute Cluster Server 2003 relies on Internet Connection Sharing (ICS) to provide network address translation between the public and private networks. ICS also provides DHCP service for the private network. ICS is enabled during Compute Cluster Pack setup".
SharedAccess — Windows Firewall/Internet Connection Sharing (ICS).
Provides network address translation, addressing, name resolution, and/or intrusion prevention services for a home or small office network.
Start mode: Auto
Login account: LocalSystem
DLL file: ipnathlp.dll
Dependencies: Netman, winmgmt
msdn Diagram of Internet Connection Sharing and Internet Connection Firewall
Additional information will be added to this Diary as it is developed.
UPDATE Yesterday Tyler completed additional work and posted information at nCircle's blog, see his Microsoft ICS DoS FAQ
Thanks again Tyler.
Original Diary below;
The Windows Firewall/Internet Connection Sharing (ICS) service may be running even though Windows Firewall is disabled.
To determine if your system has the service running, type the following at a command prompt:
sc query sharedaccess
The short name of this service is SharedAccess, the full name is Windows Firewall/Internet Connection Sharing (ICS).
Tyler Reguly reported;
Microsoft Error Message:
Generic Host Process for Win32 Services has encountered a problem and needs to close. We are sorry for the inconvenience.
View What's in this report:
Error signature:
szAppName: svchost.exe szAppVer: 5.1.2600.2180
szModName: ipnathlp.dll szModVer 5.1.2600.2180 offset: 0001d45e
UPDATE - 1:16 PM EDST - Tyler reported that only ICS was enabled, "the Firewall was disabled at the time.".
Thanks for the work and followup Tyler!
Other information;
UPDATE - 5:40 PM EDST - According to the MS Windows Compute Cluster Server 2003 Deployment website, "Windows Compute Cluster Server 2003 relies on Internet Connection Sharing (ICS) to provide network address translation between the public and private networks. ICS also provides DHCP service for the private network. ICS is enabled during Compute Cluster Pack setup".
SharedAccess — Windows Firewall/Internet Connection Sharing (ICS).
Provides network address translation, addressing, name resolution, and/or intrusion prevention services for a home or small office network.
Start mode: Auto
Login account: LocalSystem
DLL file: ipnathlp.dll
Dependencies: Netman, winmgmt
msdn Diagram of Internet Connection Sharing and Internet Connection Firewall
Additional information will be added to this Diary as it is developed.
0 Comments
Published: 2006-10-28
Multiple DoS Vulnerabilities in Wireshark
Wireshark is reported to have multiple vulnerabilities that could cause it to crash or use up memory when reading a crafted packet. Versions affected are 0.9.8 up to and including 0.99.3.
The HTTP, LDAP, XOT, WBXML, and MIME Multipart dissectors are affected. If AirPcap support is enabled, parsing a WEP key could also sometimes cause it to crash.
Solution is to upgrade to Wireshark 0.99.4. If not possible, disable HTTP, LDAP, XOT, WBXML, and MIME multipart dissectors.
http://www.wireshark.org/security/wnpa-sec-2006-03.html
Note that the advisory is dated 30 Oct 06 and currently, Version 0.99.4 is not available on its download page yet (Thanks to Jim for pointing out this).
Update: (2006-11-01 03:30 UTC) the new version is available. The download link was messed up for a bit, but that has been fixed.
The HTTP, LDAP, XOT, WBXML, and MIME Multipart dissectors are affected. If AirPcap support is enabled, parsing a WEP key could also sometimes cause it to crash.
Solution is to upgrade to Wireshark 0.99.4. If not possible, disable HTTP, LDAP, XOT, WBXML, and MIME multipart dissectors.
http://www.wireshark.org/security/wnpa-sec-2006-03.html
Note that the advisory is dated 30 Oct 06 and currently, Version 0.99.4 is not available on its download page yet (Thanks to Jim for pointing out this).
Update: (2006-11-01 03:30 UTC) the new version is available. The download link was messed up for a bit, but that has been fixed.
0 Comments
Published: 2006-10-27
ADODB.connection Vuln
A recently discovered vulnerability in ADODB.connection has a proof of concept exploit. Microsoft has mentioned it in their blog. William believes this will be the 'drive by' threat vector of the next little while. This particular threat impact is remote code execution of choice.
The code creates new ActiveXObject('ADODB.Connection.2.7') and then executes a number of times. The PoC is a Denial of Service, but it is just a question of time until a working version with shellcode is out (if not already).
Mitigation: Disable ActiveX completely, or only allow it in trusted zones
US-CERT has published a note here. "The ADODB.Connection ActiveX control can be disabled in Internet Explorer by setting the kill bit for the following CLSID:
Cheers,
Adrien de Beaupré
(Only in Canada eh?)
BSSI/Cinnabar Networks
The code creates new ActiveXObject('ADODB.Connection.2.7') and then executes a number of times. The PoC is a Denial of Service, but it is just a question of time until a working version with shellcode is out (if not already).
Mitigation: Disable ActiveX completely, or only allow it in trusted zones
US-CERT has published a note here. "The ADODB.Connection ActiveX control can be disabled in Internet Explorer by setting the kill bit for the following CLSID:
- {00000514-0000-0010-8000-00AA006D2EA4} "
Cheers,
Adrien de Beaupré
(Only in Canada eh?)
BSSI/Cinnabar Networks
0 Comments
Published: 2006-10-26
Are you sure you're as prepared as you think you are?
Recently, the area I live in experianced a power outage due to a surprise storm that came through and snapped trees like they were matchsticks. When those trees broke, they took thousands of power lines with them. At one point, there were nearly 500,000 households and businesses without electricity - including of course, my employer.
There are quite a few things we've learned as a result of this, so I'm going to point them out as the story moves along.
As in many companies, our first line of defense is a UPS. On any normal day according to the display on the unit we should have about 45 minutes of runtime available at full capacity.
Now, 45 minutes is not a lot of time to shutdown the number of servers we have, but we felt somewhat comfortable because we have a 2 year old Natural Gas fed generator that was powerful enough to feed the UPS at full capacity (we're only at about 55% max load) and to power the AC unit which keeps the systems happy.
Does this sound like you?
If so, read on. If not, and you're working for a company that receives electricity from multiple grids and has redundant sets of N+1 generators, feeding redundant sets of N+1 UPS units running wet cells, mini fusion reactors or whatever, well, good for you. ;)
The fun began at about 9pm on a Thursday night when I was called by one of my staff (Nick) telling me the power to the building was out, and he wasn't sure if the AC (on the generator unit) was running.
After an hour drive of near zero visibility, (driving around trees, powerlines and transformers that had fallen into the street, navigating countless intersetctions with no working traffic signal) to travel what is normally 20 minutes I arrived at the office to find the lights in the datacenter on (remember, we only estimated 45 minutes of run time on the UPS) and the AC unit running.
I met our facilities manager who had been called by the alarm company 30 minutes after the power went out.
[LESSON LEARNED #1 - Do you have an SLA on the timing of your notifications of emergency situations? Yes, it was a wide outage and the poor guy manning the desk at the alarm company probably needed CPR when he saw 90% of his customers drop off the grid almost instantly, but 30 minutes? Fortunately for us, a user was still in the building when the power went off and was able to use her cell phone to call IT so we were already on the way in when the alarm company finally notified us.]
On his way to the facility the facilities manager was in contact with the power company who told him the power outage was widespread and could last into Monday or Tuesday of the following week. We braced for the worst and went to check the generator which was running very well at the time and was treated to a spectacular show of blue-green lightning mixing with the bright blue flashes of exploding transformers in the distance and a symphony of tree limbs breaking off in the woods behind our office.
[LESSON LEARNED #2 - Blue-Green lightning is bad (and somewhat eerie).]
Nick had also arrived and he and I checked the run time on the UPS. 45 minutes as expected, good. We began making plans for what servers would be shutdown in what order in the event of a generator failure. Yes, I know, this should have been done long before, and I agree completely. The fact is that this area of documentation had not yet been completed for a number of reasons, none of which seemed particularly relevant in light of the issue.
[LESSON LEARNED #3 - If you don't already have it completed, find time to develop your emergency response policy and procedures as soon as possible.]
We completed the list and began calling other staff on thier cell phones to assign systems to be shut down remotely, only to find that they too were without power and internet connectivity and phone service from thier homes. By this time, there were more tree limbs and transformers blocking the roads and the town where our office was located issued a driving ban. No one was coming in to help, and no one could connect remotely.
[LESSON LEARNED #4 - Out of band communications are a must during emergency situations.]
About 11:45 that evening, I was behind the datacenter near the AC unit when I heard the worst sound imaginable - sudden silence followed by a frantic yell of "Chris?!?!?!?". The generator had failed and Nick immediately checked the UPS. Right around 24 minutes of power remaining was the display. We got down to the business of following our list and shutting down the systems while praying that the 24 minutes was a display error. I checked the unit again about 5 minutes later and it read a time remaining that was within a minute of the last entry. About 5 minutes later a third person checked the display and again saw a time remaining within a minute of the last display. So here we are, 10-12 minutes into the generator failure, three people have checked the unit and a time between 22 and 24 minutes has been reported and what do you think happens?
Yep, less than 5 minutes after the last check, the room went dark and silent. If you have ever been in a datacenter which is always noisy with AC units pushing air and cabinets full of servers and network equipment suddenly go silent, you know how creepy that is.
A very soft "Oh <explicative deleted>" slipped from Nick and I as we reached for the flashlights.
Our facilities manager checked the generator and began the process of getting emergency support on the phone, and if needed, here.
About three hours later, a cable in the generator that had wiggled loose was pushed back in by a maintenance tech from the company we contract out to for generator service and the generator started back up.
Long before the generator came back to life, Nick had left for home as there really wasn't anything he could do with the power being out and the indications we had that the generator would not be fixed at any time soon.
At 3:30 am, the generator came back on and seemed like it should be stable. I mean, a cable wiggling loose after only 3 hours run time is a fluke when we had recently run it for 16 hours with no problems, right?
The network equipment, servers, phone and other systems come back up and by 7am most applications are running fine except those applications hosted on one of the three servers that died as a result of the hard power down.
By 10:30 a few more issues had been reported, and mostly resolved and I was feeling pretty good despite being up over 24 hours. That is, until the generator died again. To add the proverbial icing onto the cake, the batteries on the UPS hadn't charged so the whole datacenter went down hard, for the majority of the systems, again.
It turns out, the same cable had come loose.
[LESSON LEARNED #5 - Fix the problem right, the first time. When he returned, our facilities manager re-connected the cable and secured it with cable-ties so that it couldn't come loose again. If the maintenance tech who fixed the problem the first time had secured the cable, well, you get the idea.]
Power was restored and systems started coming on line just before Noon. Luckily, we had no additional system failures when the power came back on the second time.
Street power was returned late Sunday evening and the remainder of the weekend was uneventful compared with the adventures of Thursday evening and Friday morning.
So what is this all about? One simple question that need not generate a flood of e-mail but is more intended as food for thought.
Are you sure you're as prepared as you think you are?
Do you have a service level on your alarm company response? If not, did you think you would need it?
Is the display on your UPS correct?
Here's an interesting one .. is it a part of your local fire company's response plan to shut of the gas supply to your area in cases of large industrial fires in your area or other scenarios? Our facilities manager initially thought this was the problem when the generator stopped the first time, as he knows that the response plan for certian incidents in the office park we are in is to shut off the gas supply. It is just as easy to shut off gas for an individual office building under certain scenarios as well.
Does your UPS shut down systems gracefully when X minutes remain? Would it have worked if X minutes were never displayed?
How about your power fail phones, do they actually work? Have you tested them?
The magnetic security locks on your doors, do they fail open, or closed? Are you sure?
I've listed only some of the questions that have come up, there are many, many others that I haven't listed here but become obvious after reading the story.
Challenge some of the assumptions you've made. You'll probably find more exposures than you knew about originally.
Hopefully they can be corrected before they become a problem.
There are quite a few things we've learned as a result of this, so I'm going to point them out as the story moves along.
As in many companies, our first line of defense is a UPS. On any normal day according to the display on the unit we should have about 45 minutes of runtime available at full capacity.
Now, 45 minutes is not a lot of time to shutdown the number of servers we have, but we felt somewhat comfortable because we have a 2 year old Natural Gas fed generator that was powerful enough to feed the UPS at full capacity (we're only at about 55% max load) and to power the AC unit which keeps the systems happy.
Does this sound like you?
If so, read on. If not, and you're working for a company that receives electricity from multiple grids and has redundant sets of N+1 generators, feeding redundant sets of N+1 UPS units running wet cells, mini fusion reactors or whatever, well, good for you. ;)
The fun began at about 9pm on a Thursday night when I was called by one of my staff (Nick) telling me the power to the building was out, and he wasn't sure if the AC (on the generator unit) was running.
After an hour drive of near zero visibility, (driving around trees, powerlines and transformers that had fallen into the street, navigating countless intersetctions with no working traffic signal) to travel what is normally 20 minutes I arrived at the office to find the lights in the datacenter on (remember, we only estimated 45 minutes of run time on the UPS) and the AC unit running.
I met our facilities manager who had been called by the alarm company 30 minutes after the power went out.
[LESSON LEARNED #1 - Do you have an SLA on the timing of your notifications of emergency situations? Yes, it was a wide outage and the poor guy manning the desk at the alarm company probably needed CPR when he saw 90% of his customers drop off the grid almost instantly, but 30 minutes? Fortunately for us, a user was still in the building when the power went off and was able to use her cell phone to call IT so we were already on the way in when the alarm company finally notified us.]
On his way to the facility the facilities manager was in contact with the power company who told him the power outage was widespread and could last into Monday or Tuesday of the following week. We braced for the worst and went to check the generator which was running very well at the time and was treated to a spectacular show of blue-green lightning mixing with the bright blue flashes of exploding transformers in the distance and a symphony of tree limbs breaking off in the woods behind our office.
[LESSON LEARNED #2 - Blue-Green lightning is bad (and somewhat eerie).]
Nick had also arrived and he and I checked the run time on the UPS. 45 minutes as expected, good. We began making plans for what servers would be shutdown in what order in the event of a generator failure. Yes, I know, this should have been done long before, and I agree completely. The fact is that this area of documentation had not yet been completed for a number of reasons, none of which seemed particularly relevant in light of the issue.
[LESSON LEARNED #3 - If you don't already have it completed, find time to develop your emergency response policy and procedures as soon as possible.]
We completed the list and began calling other staff on thier cell phones to assign systems to be shut down remotely, only to find that they too were without power and internet connectivity and phone service from thier homes. By this time, there were more tree limbs and transformers blocking the roads and the town where our office was located issued a driving ban. No one was coming in to help, and no one could connect remotely.
[LESSON LEARNED #4 - Out of band communications are a must during emergency situations.]
About 11:45 that evening, I was behind the datacenter near the AC unit when I heard the worst sound imaginable - sudden silence followed by a frantic yell of "Chris?!?!?!?". The generator had failed and Nick immediately checked the UPS. Right around 24 minutes of power remaining was the display. We got down to the business of following our list and shutting down the systems while praying that the 24 minutes was a display error. I checked the unit again about 5 minutes later and it read a time remaining that was within a minute of the last entry. About 5 minutes later a third person checked the display and again saw a time remaining within a minute of the last display. So here we are, 10-12 minutes into the generator failure, three people have checked the unit and a time between 22 and 24 minutes has been reported and what do you think happens?
Yep, less than 5 minutes after the last check, the room went dark and silent. If you have ever been in a datacenter which is always noisy with AC units pushing air and cabinets full of servers and network equipment suddenly go silent, you know how creepy that is.
A very soft "Oh <explicative deleted>" slipped from Nick and I as we reached for the flashlights.
Our facilities manager checked the generator and began the process of getting emergency support on the phone, and if needed, here.
About three hours later, a cable in the generator that had wiggled loose was pushed back in by a maintenance tech from the company we contract out to for generator service and the generator started back up.
Long before the generator came back to life, Nick had left for home as there really wasn't anything he could do with the power being out and the indications we had that the generator would not be fixed at any time soon.
At 3:30 am, the generator came back on and seemed like it should be stable. I mean, a cable wiggling loose after only 3 hours run time is a fluke when we had recently run it for 16 hours with no problems, right?
The network equipment, servers, phone and other systems come back up and by 7am most applications are running fine except those applications hosted on one of the three servers that died as a result of the hard power down.
By 10:30 a few more issues had been reported, and mostly resolved and I was feeling pretty good despite being up over 24 hours. That is, until the generator died again. To add the proverbial icing onto the cake, the batteries on the UPS hadn't charged so the whole datacenter went down hard, for the majority of the systems, again.
It turns out, the same cable had come loose.
[LESSON LEARNED #5 - Fix the problem right, the first time. When he returned, our facilities manager re-connected the cable and secured it with cable-ties so that it couldn't come loose again. If the maintenance tech who fixed the problem the first time had secured the cable, well, you get the idea.]
Power was restored and systems started coming on line just before Noon. Luckily, we had no additional system failures when the power came back on the second time.
Street power was returned late Sunday evening and the remainder of the weekend was uneventful compared with the adventures of Thursday evening and Friday morning.
So what is this all about? One simple question that need not generate a flood of e-mail but is more intended as food for thought.
Are you sure you're as prepared as you think you are?
Do you have a service level on your alarm company response? If not, did you think you would need it?
Is the display on your UPS correct?
Here's an interesting one .. is it a part of your local fire company's response plan to shut of the gas supply to your area in cases of large industrial fires in your area or other scenarios? Our facilities manager initially thought this was the problem when the generator stopped the first time, as he knows that the response plan for certian incidents in the office park we are in is to shut off the gas supply. It is just as easy to shut off gas for an individual office building under certain scenarios as well.
Does your UPS shut down systems gracefully when X minutes remain? Would it have worked if X minutes were never displayed?
How about your power fail phones, do they actually work? Have you tested them?
The magnetic security locks on your doors, do they fail open, or closed? Are you sure?
I've listed only some of the questions that have come up, there are many, many others that I haven't listed here but become obvious after reading the story.
Challenge some of the assumptions you've made. You'll probably find more exposures than you knew about originally.
Hopefully they can be corrected before they become a problem.
0 Comments
Published: 2006-10-26
MSIE IE7 Popup Address Bar Spoofing Vulnerability
Secunia (http://secunia.com/advisories/22542/ is reporting a new Microsoft Internet Explorer (MSIE) 7.0 vulnerability. This vulnerability allows a malicious site to spoof the content of the address bar. Instead of the actual URL, the user will see a "fake" URL. We tested the vulnerability and found it to work quite well. As a quick workaround you may want to configure MSIE 7.0 to open new windows in a new tab. In order to do this, Tools -> Internet Options -> Tabs Settings -> When a pop-up is encountered: Always open pop-ups in a new tab.
(click image for full size)
The PoC exploit by Secunia is pushing the real URL off the screen to the left by adding multiple '%A0' characters between the real URL and the string 'www.microsoft.com'. It appears that the new window will only show right-most part of the URL. For tabs, the left most part is shown.
This vulnerability has a lot of potential for phishers or others that attempt to trick the user into trusting the popup window as they trust the site displayed in the main window.
Update:
Jeroen writes in to tell us:
"By default, Safari doesn't show the address bar in a popup ... so this trick will probably also work for Safari users since the popup window has the title 'Microsoft Corporation'. If you choose to display the address bar, it displays the correct URL (secunia).
Thanks Jeroen.
-Chris
UPDATE 2:
We received a lot of reports from our readers suggesting that Firefox and some other browsers are vulnerable to this exploit as well.
In case of this vulnerability, it is not easy to say if a browser is vulnerable or not ? we're not talking about exploiting a remote execution so it either works or it doesn't work. In this case, an attacker is actually trying to make the user believe that he's on a different site, and that can be, unfortunately, done using this vulnerability on almost all browsers.
If you try the test on Secunia's web page with other browsers, you will see different results, shown below.
Firefox (both 1.5.x and 2.0 versions) will open a new pop-up window completely without the address bar, so it's irrelevant what the JavaScript code attempts to do. The good thing about Firefox is that it will show the real site you connected to in the window title bar, as shown in the screen shot below. This is why the exploit does not work in Firefox as it should, but of course ? a user can still be fooled with this if they don't check the window title bar:
Opera is also not vulnerable to this exploit, but the pop-up window looks a bit different. You can see that it prints the real site name below the window title, but again, a user might miss this:
--
Bojan Zdrnja
0 Comments
Published: 2006-10-25
Vulnerabilities in RFID-enabled credit cards
Some time ago we wrote about vulnerabilities in RFID cards. Our reader Robert sent us an e-mail about an interesting report published by the University of Massachusetts.
Researches tested various RFID-enabled credit cards and were able to launch a series of attacks against them, with home made equipment. Scary!
You can download the whole paper from http://prisms.cs.umass.edu/~kevinfu/papers/RFID-CC-manuscript.pdf.
Researches tested various RFID-enabled credit cards and were able to launch a series of attacks against them, with home made equipment. Scary!
You can download the whole paper from http://prisms.cs.umass.edu/~kevinfu/papers/RFID-CC-manuscript.pdf.
0 Comments
Published: 2006-10-24
Mozilla Firefox 2 officially released
As announced, the Mozilla Foundation released version 2.0 of their popular browser. Besides new features, this version includes some security fixes as well.
Phishing Protection will probably be the most valuable for average users. This feature, which is turned on by default, has a local blocklist that is updated hourly. This looks like a more reasonable approach on saving the bandwidth, but for those living on the edge there is also the possibility of validating web sites through a third party service.
You can download new Mozilla Firefox off their web site, http://www.mozilla.com.
Phishing Protection will probably be the most valuable for average users. This feature, which is turned on by default, has a local blocklist that is updated hourly. This looks like a more reasonable approach on saving the bandwidth, but for those living on the edge there is also the possibility of validating web sites through a third party service.
You can download new Mozilla Firefox off their web site, http://www.mozilla.com.
0 Comments
Published: 2006-10-24
Update: Malware Analysis: Tools of the Trade
First I want to thank everyone who sent in tools for this endeavor. I hope that this list of tools continues to grow and everyone can get good use out of it. If you look at the diary entry that launched this endeavor, you will find the information that I'm looking to obtain about the tools. If you have some that need would be good to list here, please pass them along and I'll update the list. Some folks sent in entries and checked the box not to have thier names mentioned, so there are no names by those submissions. If you want me to include your name, I'd love to, but you need to give me permission first when you submit the information. All information has been submitted as provided. If you have any additions, I'd be happy to add them!
Here are the tools that people have sent in thus far:
1. Malcode Analyst Pack
3. Windows 2000 RAM dump parsing tools: Submitted by Harlan Carvey
WEBSITE LINKS:
1. Pedram's site: http://pedram.redhive.com/ Submitted by Vince Maes
Here are the tools that people have sent in thus far:
1. Malcode Analyst Pack
a. Where you can get it (if known)- iDefense http://labs.idefense.com/labs-software.php?show=8
b. Shareware/Freeware- GPL/Freeware
c. What it does-
This install package contains a handful of small utility type applications that have proven useful while analyzing malicious code.
These are quick tools designed to meet specific needs while in a malcode testing lab environment. Functionality is tailored specifically to these ends, implementation may be crude at some points but all have proven utility.
This package includes:
• ShellExt - explorer shell extensions
• socketTool - manual TCP Client for probing functionality.
• MailPot - mail server capture pot
• fakeDNS - spoofs dns responses to controlled ip's
• sniff_hit - HTTP, IRC, and DNS sniffer
• sclog - Shellcode research and analysis application
• IDCDumpFix - aids in quick RE of packed applications
• Shellcode2Exe - embeds multiple shellcode formats in exe husk
• GdiProcs - used to detect hidden processes
• socketTool - manual TCP Client for probing functionality.
• MailPot - mail server capture pot
• fakeDNS - spoofs dns responses to controlled ip's
• sniff_hit - HTTP, IRC, and DNS sniffer
• sclog - Shellcode research and analysis application
• IDCDumpFix - aids in quick RE of packed applications
• Shellcode2Exe - embeds multiple shellcode formats in exe husk
• GdiProcs - used to detect hidden processes
d. Tips for using it or gotchas- N/A
e. Is the source of the tool considered trustworthy?- as trustworthy as iDefense is :)
f. Screen Shots of the tool in action (optional)- there is a wmv of the shellcode logger usage on the site (link at bottom of page)
g. Links to additional resource information about the tool- N/A
2. RegMon, FileMon, Ethereal: Submitted by Ronan Rosee. Is the source of the tool considered trustworthy?- as trustworthy as iDefense is :)
f. Screen Shots of the tool in action (optional)- there is a wmv of the shellcode logger usage on the site (link at bottom of page)
g. Links to additional resource information about the tool- N/A
a. Where you can get it (if known)-
RegMon, FileMon and TCPView at www.sysinternals.com
RegMon, FileMon and TCPView at www.sysinternals.com
Ethereal: Included with red hat many linux distros
MSVPC: microsoft.com (trial)
b. Shareware/Freeware- unknown - trial versions / freeware
c. What it does:
- RegMon: monitors processes accessing the registry.
- FileMon: monitors processes accessing file system.
- TCPview: lets you see in real time what applications are listening on your ports.
- Ethereal: will give you a good view of what is happening on the network at a packet level.
- MSVPC: will allow you to set up a network on your PC. I have a 2.4 ghz, 60GB HD and 750 mb ram which allows me to run 3 VMs simultaneously in a LAN - server2003 to provide dns, ftp, smtp etc,
- Win2k client as Malware host and to run filemon and reg mon on, and redhat 7.2 vm to use ethereal
d. Tips for using it or gotchas-
- In the case of malware with Regmon look for processes polling the "run" keys in the registry . You will need to exclude some processes from both tools (there is quiet alot happening under the bonnet in windows) to improve legability, but if you are still not finding your problem, remember that some malware can inject itself into legit processes, so drop any filters and start again.
- Filemon should show you any process that is systematically looking for information on your hard drive.
- TCPview lets you see in real time what applications are listening on your ports. Some of the newer malware claims to be able to defeat some of the file, registry, tcp view type apps with rootkits etc. When in doubt, check ethereal - if the network is still busy, then you are still infected!
e. Is the source of the tool considered trustworthy? All tools are trustworthy and come from a reliable source.
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
g. Links to additional resource information about the tool-
3. Windows 2000 RAM dump parsing tools: Submitted by Harlan Carvey
a. Where you can get it (if known)- http://sourceforge.net/project/showfiles.php?group_id=164158
b. Shareware/Freeware-
c. What it does-
d. Tips for using it or gotchas- The tools themselves should be platform-independant, and only require Perl. I've had previous versions tested on Linux, and even a Mac G5.
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
4. Wireshark, formerly Ethereale. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
a. Where you can get it (if known)- http://www.wireshark.org/
b. Shareware/Freeware- Free & Open source
c. What it does- Analyzes network traffic & packets. Useful for observing if and where malware is attempting to deliver/recieve payload(s) and via which protocol(s).
d. Tips for using it or gotchas-
e. Is the source of the tool considered trustworthy? Yes, trustworthy, would run it on primary systems if needed. Open source, can compile from source code if desired. Having access to the full source code for scrutiny adds to the level of trust.
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool- Numerous links available on the Wireshark home page, www.wireshark.org
5. OllyDbg: Submitted by Vince Maese. Is the source of the tool considered trustworthy? Yes, trustworthy, would run it on primary systems if needed. Open source, can compile from source code if desired. Having access to the full source code for scrutiny adds to the level of trust.
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool- Numerous links available on the Wireshark home page, www.wireshark.org
a. Where you can get it (if known)- http://www.ollydbg.de/
b. Shareware/Freeware- OllyDbg is a shareware, but you can download and use it for free.
c. What it does- Provides binary code analysis for Windows-based malware. Some of it's best features are:
-Attaches to running programs
-Analyzes complex code constructs such as call to jump to procedure
-Sets conditional, logging, memory and hardware breakpoints
-Traces execution and logs arguments of known functions.
-And lots more...
-Analyzes complex code constructs such as call to jump to procedure
-Sets conditional, logging, memory and hardware breakpoints
-Traces execution and logs arguments of known functions.
-And lots more...
d. Tips for using it or gotchas-
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
6. IDA Pro: Submitted by Vince Maes
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
a. Where you can get it (if known)- http://www.datarescue.com/
b. Shareware/Freeware- Cost of standard edition is $439 This tool is worth the cost.
c. What it does- Disassembler and debugger with an assortment of community developed plug-ins. Supports a multitude of processors. Use a graphic interface. It allows you to step through malicious code. Best to run in a virtual machine with no network access.
d. Tips for using it or gotchas-
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
7. Holodeck: Submitted by Vince Maes
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
a. Where you can get it (if known)- http://www.securityinnovation.com/holodeck/
b. Shareware/Freeware- Cost of single user license $1495.00
c. What it does- Basically a great fuzzing tool. Automated point-and-click fault scenarios, function call logging, operation intercepts, network packet logging, and a debugger just to name a few. There is a book by the developers that contains a light version of the product: How to Break Software Security.
d. Tips for using it or gotchas-
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
e. Is the source of the tool considered trustworthy?
f. Screen Shots of the tool in action (optional)-
g. Links to additional resource information about the tool-
1. Pedram's site: http://pedram.redhive.com/ Submitted by Vince Maes
0 Comments
Published: 2006-10-22
Botnet Research
I'm doing some research into botnets and botnet sizes and am looking for some data from our readers. What I'm trying to find are the average sizes of botnets and what their specific purpose was when they were found (DDoS, cracking credit cards, generating spam, DNS impersonation, etc.) I don't need links to stories or conjecture about what you think might be out there, but specific information about botnets you have personal experience discovering or disabling. If you want me to mention your name or if you want to remain anonymous, please tell me. I'll compile the data that is sent in and post a story later this week with the results.
This next statement might sound a bit nutty, but if you are a botmaster and don't mind sharing some of your experiences I'd like to hear them too. How much are botnets currently worth? Is there an active market to buy and sell them, who are the buyers, who are the sellers, etc. I'm pretty sure that any botmasters reading this will want to remain anonymous and we'll honor your request. Also, what direction are botnets going in? In other words, we are familiar with DDoS and spamming botnets, so what is next?
Please send your data via the contact form rather than via direct email. Thanks in advance for any information you forward to us.
Marcus Sachs
Director, SANS Internet Storm Center
This next statement might sound a bit nutty, but if you are a botmaster and don't mind sharing some of your experiences I'd like to hear them too. How much are botnets currently worth? Is there an active market to buy and sell them, who are the buyers, who are the sellers, etc. I'm pretty sure that any botmasters reading this will want to remain anonymous and we'll honor your request. Also, what direction are botnets going in? In other words, we are familiar with DDoS and spamming botnets, so what is next?
Please send your data via the contact form rather than via direct email. Thanks in advance for any information you forward to us.
Marcus Sachs
Director, SANS Internet Storm Center
0 Comments
Published: 2006-10-20
False positive on sfc.dll
Bojan was the primary handler on this one... We received a report that Symantec Antivirus was detecting a virus on sfc.dll, which is a component of Windows File Protection. At first, we were a little worried that a trojan was disabling the protection features, which would be a bad thing. However, it looks like this was a false positive and new signatures released today seems to have fixed the problem. This was occuring on Windows 2000 SP4 machines without the Security Rollup applied.
UPDATE
Just a short update about this problem. As we already wrote, Symantec removed detection for this file from their definitions.
However, the main reason why they added this detection is pretty interesting, so we decided to write a bit more about this, as we received some useful information from Symantec’s security response team.
Basically, the sfc.dll file provides Windows 2000 and XP operating systems with a feature called System File Checker (SFC), which is part of Windows File Protection. Windows File Protection prevents programs from replacing critical Windows system files (you can find more information about WFP at http://support.microsoft.com/kb/222193).
As you can see, WFP makes it a bit more difficult for malware to replace Windows system files. The bad guys, however, found a way to circumvent SFC – all they have to do is to “patch” the sfc.dll file (the patch actually only modifies 2 bytes!) and add an undocumented registry key.
According to Symantec, a lot of Infostealer Trojans modify the sfc.dll file, so they added detection for it. However, it looks like there might be some other, legitimate, reasons for this, so some people might have been caught with this false positive detection (when the system actually wasn’t infected).
Symantec posted a knowledge base article about this, so if you were affected visit http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2006102011570548.
UPDATE
Just a short update about this problem. As we already wrote, Symantec removed detection for this file from their definitions.
However, the main reason why they added this detection is pretty interesting, so we decided to write a bit more about this, as we received some useful information from Symantec’s security response team.
Basically, the sfc.dll file provides Windows 2000 and XP operating systems with a feature called System File Checker (SFC), which is part of Windows File Protection. Windows File Protection prevents programs from replacing critical Windows system files (you can find more information about WFP at http://support.microsoft.com/kb/222193).
As you can see, WFP makes it a bit more difficult for malware to replace Windows system files. The bad guys, however, found a way to circumvent SFC – all they have to do is to “patch” the sfc.dll file (the patch actually only modifies 2 bytes!) and add an undocumented registry key.
According to Symantec, a lot of Infostealer Trojans modify the sfc.dll file, so they added detection for it. However, it looks like there might be some other, legitimate, reasons for this, so some people might have been caught with this false positive detection (when the system actually wasn’t infected).
Symantec posted a knowledge base article about this, so if you were affected visit http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2006102011570548.
0 Comments
Published: 2006-10-20
Analysis of botnet spamming trojan (SecureWorks)
The following article is a great analysis of a trojan that pumps out spam. There are some new techniques described that are very interesting. Great work by Joe Stewart and the folks at SecureWorks (recently merged with LURHQ). http://www.secureworks.com/analysis/spamthru/
0 Comments
Published: 2006-10-20
New Internet Explorer and an old vulnerability
As you probably know by now, Microsoft yesterday released the final version of Internet Explorer 7; if you want to install it on your machine you can download it from http://www.microsoft.com/windows/ie/default.mspx. Microsoft also said that in couple of weeks this will be automatically pushed to all client machines through Windows Update, so if you still haven't tested your mission critical internal web applications with IE7, you better do it now.
Besides news about the final version of IE7, a lot of people are already talking about the first vulnerability for IE7, which was announced yesterday on various security mailing lists. The vulnerability is caused by an error in redirections handling with the "mhtml:" URI handler.
After analyzing this security vulnerability, we have to disappoint you – it's nothing new. Actually, this vulnerability was announced way back in April this year for Internet Explorer 6 (http://secunia.com/advisories/19738). It is still not patched, so besides IE7, this vulnerability can be exploited in a fully patched IE6 installation as well.
So what's going on here, did Microsoft just used old code? Not really. The vulnerability exists in the MSXML ActiveX component which is actually part of Outlook Express (so it is installed on every machine as well).
The exploit uses a "double" redirection trick – it will first create an Msxml2.XMLHTTP ActiveX object which is then used to retrieve a web page from the same server that the original web page is hosted on (one containing the exploit). This web page is actually just a redirection (302) which uses a mhtml: URI. This causes the ActiveX object to retrieve any other web page referenced by the mhtml: URI, which can be referenced from the original web page.
In other words, this exploit can be used by an attacker to possibly retrieve other data that your browser has access to. While stealing information like banking data is possible, our testing showed that only content of the web page can be retrieved by the attacker – they can not steal your credentials and they can not retrieve that data unless you are logged in to your bank account at the same time when you visit the web page hosting the exploit.
It looks like Microsoft once again got caught into "ancient" bugs which were already present on the machine (we do wonder why this hasn't been fixed before though).
One thing worth nothing is that Internet Explorer 7 has a native XMLHTTPRequest object implementation so theoretically it should be possible to disable the ActiveX object, but pages using it would have to be rewritten (hence support for the ActiveX object). Further testing will show if the native support implementation is also vulnerable – we'll post new information as we get it.
Besides news about the final version of IE7, a lot of people are already talking about the first vulnerability for IE7, which was announced yesterday on various security mailing lists. The vulnerability is caused by an error in redirections handling with the "mhtml:" URI handler.
After analyzing this security vulnerability, we have to disappoint you – it's nothing new. Actually, this vulnerability was announced way back in April this year for Internet Explorer 6 (http://secunia.com/advisories/19738). It is still not patched, so besides IE7, this vulnerability can be exploited in a fully patched IE6 installation as well.
So what's going on here, did Microsoft just used old code? Not really. The vulnerability exists in the MSXML ActiveX component which is actually part of Outlook Express (so it is installed on every machine as well).
The exploit uses a "double" redirection trick – it will first create an Msxml2.XMLHTTP ActiveX object which is then used to retrieve a web page from the same server that the original web page is hosted on (one containing the exploit). This web page is actually just a redirection (302) which uses a mhtml: URI. This causes the ActiveX object to retrieve any other web page referenced by the mhtml: URI, which can be referenced from the original web page.
In other words, this exploit can be used by an attacker to possibly retrieve other data that your browser has access to. While stealing information like banking data is possible, our testing showed that only content of the web page can be retrieved by the attacker – they can not steal your credentials and they can not retrieve that data unless you are logged in to your bank account at the same time when you visit the web page hosting the exploit.
It looks like Microsoft once again got caught into "ancient" bugs which were already present on the machine (we do wonder why this hasn't been fixed before though).
One thing worth nothing is that Internet Explorer 7 has a native XMLHTTPRequest object implementation so theoretically it should be possible to disable the ActiveX object, but pages using it would have to be rewritten (hence support for the ActiveX object). Further testing will show if the native support implementation is also vulnerable – we'll post new information as we get it.
0 Comments
Published: 2006-10-18
Heap overflow vulnerability in Opera 9.0, 9.01
iDefense published details about a heap overflow vulnerability in Opera browsers.
The vulnerability can be exploited with a tag that contains a URL bigger than 256 bytes, and looks like a typical heap overflow which is relatively easy to exploit.
Opera versions 9.0 and 9.01 on both Windows and Linux are confirmed to be vulnerable. Version 8 is not vulnerable.
It is recommended that you upgrade to version 9.02 which fixes this vulnerability: http://www.opera.com/support/search/supsearch.dml?index=848.
The vulnerability can be exploited with a tag that contains a URL bigger than 256 bytes, and looks like a typical heap overflow which is relatively easy to exploit.
Opera versions 9.0 and 9.01 on both Windows and Linux are confirmed to be vulnerable. Version 8 is not vulnerable.
It is recommended that you upgrade to version 9.02 which fixes this vulnerability: http://www.opera.com/support/search/supsearch.dml?index=848.
0 Comments
Published: 2006-10-18
Oracle Quarterly Critical Patch Update (Oct 2006)
Yesterday, Oracle released their quarterly updates.
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2006.html
David Litchfield released an excellent summary here:
http://www.databasesecurity.com/oracle/OracleOct2006-CPU-Analysis.pdf
There are too many updates (101) to go into much detail (or fully digest to be honest) here.
It is worth noting that there are gaps in coverage in the update.
From David's report:
The tools from Oracle, NGSSoftware and others for evaluating risk matrices based upon the Oracle applications, versions, and platforms in use highlights the complexity of determining exposure points. Its probably a good idea to use this strategy across all the applications and platforms in your environment and there are a number of tools to do this. And all of these techniques require a good system inventory which is kept up to date with the platforms and services installed in a network. Everyone keeps and maintains those too right?
It is also worth noting that Oracle has adopted the Common Vulnerability Scoring System (CVSS).
Additional summary details from the SC Magazine article (thanks to a certain person that sends out the highest number of news digests ever)
"The update delivered fixes for a host of company solutions, including
Oracle Database (22 patches), Application Server (14), E-Business Suite
(13) and PeopleSoft Enterprise (eight).
None of the bugs in Oracle Database - the vendor's most popular product
- are remotely exploitable without valid authorization, according to
the CPU. The highest Database risk assessment score - on a scale of 1
to 10 - was 4.2."
Additional links for those that like links:
http://blogs.oracle.com/security/2006/10/11#a33
http://www.scmagazine.com/uk/news/article/599039
http://secunia.com/advisories/22396/
http://www.securityfocus.com/bid/20588
Thanks to everyone that submitted links and information (Juha-Matti, Ramu, and others)
Robert
ISC Handler on Duty
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2006.html
David Litchfield released an excellent summary here:
http://www.databasesecurity.com/oracle/OracleOct2006-CPU-Analysis.pdf
There are too many updates (101) to go into much detail (or fully digest to be honest) here.
It is worth noting that there are gaps in coverage in the update.
From David's report:
| Version | Platform |
Due |
| 9.2.0.6 |
All Operating Systems |
End of Oct. |
| 10.1.0.5 |
All Operating Systems |
End of Oct. |
| 10.2.0.1 |
Linux (Power) |
End of Oct. |
| 10.2.0.2 |
Windows |
End of Oct. |
The tools from Oracle, NGSSoftware and others for evaluating risk matrices based upon the Oracle applications, versions, and platforms in use highlights the complexity of determining exposure points. Its probably a good idea to use this strategy across all the applications and platforms in your environment and there are a number of tools to do this. And all of these techniques require a good system inventory which is kept up to date with the platforms and services installed in a network. Everyone keeps and maintains those too right?
It is also worth noting that Oracle has adopted the Common Vulnerability Scoring System (CVSS).
Additional summary details from the SC Magazine article (thanks to a certain person that sends out the highest number of news digests ever)
"The update delivered fixes for a host of company solutions, including
Oracle Database (22 patches), Application Server (14), E-Business Suite
(13) and PeopleSoft Enterprise (eight).
None of the bugs in Oracle Database - the vendor's most popular product
- are remotely exploitable without valid authorization, according to
the CPU. The highest Database risk assessment score - on a scale of 1
to 10 - was 4.2."
Additional links for those that like links:
http://blogs.oracle.com/security/2006/10/11#a33
http://www.scmagazine.com/uk/news/article/599039
http://secunia.com/advisories/22396/
http://www.securityfocus.com/bid/20588
Thanks to everyone that submitted links and information (Juha-Matti, Ramu, and others)
Robert
ISC Handler on Duty
0 Comments
Published: 2006-10-17
Hacking Tor, the anonymity onion routing network
On October 4th one of our readers sent in a very worrying analysis of what appeared to be "traffic modification" (in his words) on the part of the Tor network.
The Tor ("The Onion Router") network is an anonymizing peer-to-peer network of routers on the Internet which uses various techniques to bounce traffic around the Internet in such a way that traffic analysis becomes difficult if not impossible to perform. Tor is a perfect example of a dual-use technology: it can be used to avoid government-imposed Internet censorship or to protect the identity of a corporate whistleblower but at the same time it is sadly ideal for various nefarious uses.
The key tenet of Tor is that it should protect anonymity and the reader's analysis pointed not only to traffic modification on the part of a so-called "exit router" (the last hop in a Tor circuit before your packets reach the real destination) but also an attempt at tracking the true origin of the traffic (in a Tor network a hop only knows that the traffic comes from a previous hop but no futher back).
Both William Salusky and myself looked into the data and it seemed to implicate packetstormsecurity.org, an exit router in Denmark and, more curiously, a DNS tunnel to transmit data out (via obviously fake hosts under the t.packetstormsecurity.org domain). This last item was interesting because it replicated data which was apparently being submitted to the host via an HTTP cookie so it seemed that the idea was to have the cookie travel to the unwitting Tor user and be sent back via DNS tunnel to an external host to confirm the real identity of the host. As both of us were busy we looked a little deeper but ultimately we recommended that the reader report this to the Tor authors.
Well, the moral of the story is that our reader, who sadly asked not to be named in the original e-mail, was dead right and a paper entitled "Practical Onion Hacking" by Andrew Christensen was released today on packetstormsecurity.org.
Our combined analysis had it almost entirely correct except that the DNS tunnel was not quite in Dan Kaminsky's "let's carry RealAudio over DNS" style but a simpler trackable DNS request and we had guessed at but not entirely understood the Shockwave flash trick. All in all a pretty impressive paper, warmly recommended.
Finally a closing remark quoting from the actual paper for those who think Tor is "game over":
The Tor ("The Onion Router") network is an anonymizing peer-to-peer network of routers on the Internet which uses various techniques to bounce traffic around the Internet in such a way that traffic analysis becomes difficult if not impossible to perform. Tor is a perfect example of a dual-use technology: it can be used to avoid government-imposed Internet censorship or to protect the identity of a corporate whistleblower but at the same time it is sadly ideal for various nefarious uses.
The key tenet of Tor is that it should protect anonymity and the reader's analysis pointed not only to traffic modification on the part of a so-called "exit router" (the last hop in a Tor circuit before your packets reach the real destination) but also an attempt at tracking the true origin of the traffic (in a Tor network a hop only knows that the traffic comes from a previous hop but no futher back).
Both William Salusky and myself looked into the data and it seemed to implicate packetstormsecurity.org, an exit router in Denmark and, more curiously, a DNS tunnel to transmit data out (via obviously fake hosts under the t.packetstormsecurity.org domain). This last item was interesting because it replicated data which was apparently being submitted to the host via an HTTP cookie so it seemed that the idea was to have the cookie travel to the unwitting Tor user and be sent back via DNS tunnel to an external host to confirm the real identity of the host. As both of us were busy we looked a little deeper but ultimately we recommended that the reader report this to the Tor authors.
Well, the moral of the story is that our reader, who sadly asked not to be named in the original e-mail, was dead right and a paper entitled "Practical Onion Hacking" by Andrew Christensen was released today on packetstormsecurity.org.
Our combined analysis had it almost entirely correct except that the DNS tunnel was not quite in Dan Kaminsky's "let's carry RealAudio over DNS" style but a simpler trackable DNS request and we had guessed at but not entirely understood the Shockwave flash trick. All in all a pretty impressive paper, warmly recommended.
Finally a closing remark quoting from the actual paper for those who think Tor is "game over":
"Clearly Tor's designers have done a pretty good job: I couldn't find any weakness in Tor itself that violate the tenets set out at http://tor.eff.org/ (basically that end-to-end traffic analysis is always possible, but the traffic analysis should [be] difficult to everything but a global Echelon). So instead, I attacked the data which Tor carries the most of: web traffic."
0 Comments
Published: 2006-10-17
NetSol Worldnic DNS server issues
As several of our readers have pointed out to us, it is Network Solutions' turn to have DNS problems. A number of their servers seem to be having intermittent issues.
0 Comments
Published: 2006-10-17
Bellsouth.(net|com) troubles
We've received several reports telling us that Bellsouth.(net|com)'s services are down. This seems to be not only affecting their DNS servers, but it also is affecting their Managed Services, email, hosted email, and who knows what else.
It does not appear to be affecting their managed internet services.
Thanks to the many readers who wrote in and let us know.
It does not appear to be affecting their managed internet services.
Thanks to the many readers who wrote in and let us know.
0 Comments
Published: 2006-10-16
Active exploit of Open Conference Systems web application
We're looking into a host compromise reported by Mike, a diary reader. Mike reported a PHP remote file inclusion attack against an Open Conference Systems web application used in his organization. A modified r57shell php script was used to compromise the system.
A vulnerability disclosure for the Open Conference System was posted to BugTraq on Friday October 13th which mentions that version <= 1.1.3 are vulnerable. Interestingly enough, the official software distribution site at http://pkp.sfu.ca/ocs_download/ states that all versions prior to version 1.1.6 are vulnerable. Take a look at your respective environments to determine if you are running OCS software, and if you find it... Do I have to say it? Patch.
The time between vulnerability disclosure and determined time of host compromise in this case was approximately 1.5 hours. I can only speculate as to how many hosts have already or are yet to become phishing sites, spammer nodes, iframe exploit hosts or fall prey to any other manner of abuse due to this vulnerability.
If you do have OCS installed, a quick check for abuse could be indicated by the following command line statement.
grep "fullpath=http:" YourWebServerLogLocation.log
Handler on Duty
William Salusky
A vulnerability disclosure for the Open Conference System was posted to BugTraq on Friday October 13th which mentions that version <= 1.1.3 are vulnerable. Interestingly enough, the official software distribution site at http://pkp.sfu.ca/ocs_download/ states that all versions prior to version 1.1.6 are vulnerable. Take a look at your respective environments to determine if you are running OCS software, and if you find it... Do I have to say it? Patch.
The time between vulnerability disclosure and determined time of host compromise in this case was approximately 1.5 hours. I can only speculate as to how many hosts have already or are yet to become phishing sites, spammer nodes, iframe exploit hosts or fall prey to any other manner of abuse due to this vulnerability.
If you do have OCS installed, a quick check for abuse could be indicated by the following command line statement.
grep "fullpath=http:" YourWebServerLogLocation.log
Handler on Duty
William Salusky
0 Comments
Published: 2006-10-16
ClamAV fixes multiple vulnerabilities
Multiple vulnerabilities have been fixed with the release of version 0.88.5 of the free and open-source ClamAV AntiVirus product related to the handling of PE files and the unpacking of CHM help files. The PE handling issue poses a significant risk and users of versions prior to ClamAV 0.88.5 are urged to upgrade ASAP.
Optionally, and also of noteworthiness on the ClamAV site, is the availability of release candidate v0.90RC1. You may want to consider testing out this new release of ClamAV software in addition to your security conscious software upgrade.
Handler on Duty
William Salusky
Optionally, and also of noteworthiness on the ClamAV site, is the availability of release candidate v0.90RC1. You may want to consider testing out this new release of ClamAV software in addition to your security conscious software upgrade.
Handler on Duty
William Salusky
0 Comments
Published: 2006-10-16
Hawaii connectivity
After this morning's earthquake, we have reports of networks to or in Hawaii that are down, including www.hawaii.gov. News about the incident can be found at:
http://www.thehawaiichannel.com/video/4324656/index.html ,
http://www.thehawaiichannel.com/news/index.html ,
http://www.cnn.com , and
http://the.honoluluadvertiser.com/article/2006/Oct/15/br/br9634517802.html . We send our best wishes to the residents of Hawaii. (Thanks to two readers for their help.)
http://www.thehawaiichannel.com/video/4324656/index.html ,
http://www.thehawaiichannel.com/news/index.html ,
http://www.cnn.com , and
http://the.honoluluadvertiser.com/article/2006/Oct/15/br/br9634517802.html . We send our best wishes to the residents of Hawaii. (Thanks to two readers for their help.)
0 Comments
Published: 2006-10-15
Sunday, little to report, and backups
We've had a quiet Sunday at the Handlers Operation Center . There were a few isolated email issues, but not much else.
I'd like to leave you with one question: If you found out that a hard drive under your management had died, can you confidently say you can rebuild it from backups? That goes for any hard drive, not just the critical machines on which you focus.
-- Bill Stearns, http://www.stearns.org/
I'd like to leave you with one question: If you found out that a hard drive under your management had died, can you confidently say you can rebuild it from backups? That goes for any hard drive, not just the critical machines on which you focus.
-- Bill Stearns, http://www.stearns.org/
0 Comments
Published: 2006-10-14
Issues on MS patches?
One reader reported that the standby hibernate mode on some of his systems is being disable after applying the recent Microsoft patches. If you also encounter similar issue or any other major issue, do drop us a note.
0 Comments
Published: 2006-10-14
MS06-061
We have received reports from our readers that previously Microsoft Update, MBSA 2.0, and ITMU may not indicate the need to install additional package for this security update if you have Microsoft XML Core Services 4.0 SP2 (but MBSA 1.2.1 did). However, it seems that Microsoft has updated the scan files and is now able to detect the need of additional package.
From Microsoft Knowledge Base article number (924191):
If you have multiple versions of the Microsoft XML Parser or Microsoft XML Core Services (MSXML) installed, you may have to install multiple packages for this security update. Additionally, if you install a version of MSXML after you install this security update, you may have to install an additional package for this security update.
One of our reader suspected the MBSA 2.0, Microsoft Update and ITMU are only considering the patch to be applicable if the MSXML4.DLL was installed as part of a MSI package for XML 4.0:
Microsoft's patch detection code for Microsoft Update as of 4 PM ADT 10/13/2006 wasn't detecting MSXML4 SP2 if it was installed via the merge module (i.e. as the result of installing a third party product that redistributed Microsoft's code using the Microsoft-approved method for doing this). Sometime between then and now, Microsoft updated the scan files. In the original scan files (released on Tuesday), Microsoft would only consider the patch applicable if the MSI version of MSXML4 SP2 was installed.
The new scan files work around this - they still detect language-specific variants of the MSI if they are installed (and generate unique UpdateIDs for those variants), but if no MSI is installed it will fallback to the UpdateID that was used in the original scan files if (and only if) the 1033 (i.e. US English) version of the MSI was installed.
In this aspect, it is recommended that you rescan your systems to determine whether you need any additional patch that was not reported earlier.
http://support.microsoft.com/kb/924191
http://support.microsoft.com/kb/925672
From Microsoft Knowledge Base article number (924191):
If you have multiple versions of the Microsoft XML Parser or Microsoft XML Core Services (MSXML) installed, you may have to install multiple packages for this security update. Additionally, if you install a version of MSXML after you install this security update, you may have to install an additional package for this security update.
One of our reader suspected the MBSA 2.0, Microsoft Update and ITMU are only considering the patch to be applicable if the MSXML4.DLL was installed as part of a MSI package for XML 4.0:
Microsoft's patch detection code for Microsoft Update as of 4 PM ADT 10/13/2006 wasn't detecting MSXML4 SP2 if it was installed via the merge module (i.e. as the result of installing a third party product that redistributed Microsoft's code using the Microsoft-approved method for doing this). Sometime between then and now, Microsoft updated the scan files. In the original scan files (released on Tuesday), Microsoft would only consider the patch applicable if the MSI version of MSXML4 SP2 was installed.
The new scan files work around this - they still detect language-specific variants of the MSI if they are installed (and generate unique UpdateIDs for those variants), but if no MSI is installed it will fallback to the UpdateID that was used in the original scan files if (and only if) the 1033 (i.e. US English) version of the MSI was installed.
In this aspect, it is recommended that you rescan your systems to determine whether you need any additional patch that was not reported earlier.
http://support.microsoft.com/kb/924191
http://support.microsoft.com/kb/925672
0 Comments
Published: 2006-10-14
Cisco Security Advisory: Default Password in Wireless Location Appliance
Cisco has earlier published a security advisory, reporting a vulnerability in Cisco Wireless Location Appliance (WLA). The appliance uses a default password for the 'root' administrative account. A user with knowledge of the password can login and gain full control of the device.
As reported in the advisory, the default password is the same in all installations of the product prior to version 2.1.34.0 when shipped as part of a new product purchase. The vulnerability still exists on upgraded installations unless explicit steps have been taken to change the password after the initial installation of the product.
Cisco has issued a fix for the version 2.1.34.0 and later. Previous versions of software which have been upgraded will not prompt the user to change the password for the root user during the upgrade. So get your password change if you have not done so on your vulnerable version.
Cisco indicates that there have been several instances in which Cisco Wireless Location Appliances have been compromised due to this vulnerability.
http://www.cisco.com/warp/public/707/cisco-sa-20061012-wla.shtml
As reported in the advisory, the default password is the same in all installations of the product prior to version 2.1.34.0 when shipped as part of a new product purchase. The vulnerability still exists on upgraded installations unless explicit steps have been taken to change the password after the initial installation of the product.
Cisco has issued a fix for the version 2.1.34.0 and later. Previous versions of software which have been upgraded will not prompt the user to change the password for the root user during the upgrade. So get your password change if you have not done so on your vulnerable version.
Cisco indicates that there have been several instances in which Cisco Wireless Location Appliances have been compromised due to this vulnerability.
http://www.cisco.com/warp/public/707/cisco-sa-20061012-wla.shtml
0 Comments
Published: 2006-10-14
Website with Malware
Our reader, Micheal, has notified us a website which could cause users to download a malware.
http:// c n n w a r n e w s . c o m/
A lookup at the domain shown that it is a newly registered domain (registered date is 12 Oct 06).
The website will load a normal webpage from an australian news website (through using frame). It will also however attempt to open a malware from another site.
http:// z a g e v q s o i i .b i z /dl/l o a d a d v 4 3 3 . e x e
VirusTotal shows the result of this malware:
Antivirus Version Update Result
AntiVir 7.2.0.30 10.13.2006 TR/Dldr.Small.dib.6
Authentium 4.93.8 10.13.2006 Possibly a new variant of W32/Downloader-Sml-based!Maximus
Avast 4.7.892.0 10.13.2006 Win32:Small-BSO
AVG 386 10.13.2006 Downloader.Harnig.AM
BitDefender 7.2 10.14.2006 DeepScan:Generic.Malware.dld!!g.07E540DB
CAT-QuickHeal 8.00 10.14.2006 no virus found
ClamAV devel-20060426 10.13.2006 Trojan.Downloader.Small-2840
eTrust-InoculateIT 23.73.22 10.13.2006 Win32/SillyDL!Trojan
eTrust-Vet 30.3.3131 10.13.2006 Win32/Harnig!generic
DrWeb 4.33 10.14.2006 Trojan.DownLoader.13549
Ewido 4.0 10.13.2006 no virus found
Fortinet 2.82.0.0 10.14.2006 W32/Dowadv.CU!tr.dldr
F-Prot 3.16f 10.13.2006 Possibly a new variant of W32/Downloader-Sml-based!Maximus
F-Prot4 4.2.1.29 10.13.2006 W32/Downloader-Sml-based!Maximus
Ikarus 0.2.65.0 10.13.2006 no virus found
Kaspersky 4.0.2.24 10.14.2006 Trojan-Downloader.Win32.Harnig.cu
McAfee 4873 10.13.2006 no virus found
Microsoft 1.1603 10.14.2006 TrojanDownloader:Win32/Vxidl
NOD32v2 1.1803 10.13.2006 a variant of Win32/TrojanDownloader.Small.DIB
Norman 5.80.02 10.13.2006 W32/DLoader.gen2
Panda 9.0.0.4 10.14.2006 Suspicious file
Sophos 4.10.0 10.13.2006 no virus found
TheHacker 6.0.1.098 10.14.2006 Trojan/Downloader.Tibs.gen
UNA 1.83 10.13.2006 no virus found
VBA32 3.11.1 10.13.2006 suspected of Downloader.Small.3 (paranoid heuristics)
VirusBuster 4.3.7:9 10.13.2006 Trojan.DL.Harnig.Gen.3
It just shown that seemly harmless website may not be that harmless at all. You should be extremely vigilant when visiting unfamiliar websites. If in doubt, it is always good to tighten your browser configuration (e.g. disable Java/ Java script/ ActiveX) before making any attempts to visit the site. This is of course assuming you have the usual security measures in place (latest patch, virus definition etc.).
http:// c n n w a r n e w s . c o m/
A lookup at the domain shown that it is a newly registered domain (registered date is 12 Oct 06).
The website will load a normal webpage from an australian news website (through using frame). It will also however attempt to open a malware from another site.
http:// z a g e v q s o i i .b i z /dl/l o a d a d v 4 3 3 . e x e
VirusTotal shows the result of this malware:
Antivirus Version Update Result
AntiVir 7.2.0.30 10.13.2006 TR/Dldr.Small.dib.6
Authentium 4.93.8 10.13.2006 Possibly a new variant of W32/Downloader-Sml-based!Maximus
Avast 4.7.892.0 10.13.2006 Win32:Small-BSO
AVG 386 10.13.2006 Downloader.Harnig.AM
BitDefender 7.2 10.14.2006 DeepScan:Generic.Malware.dld!!g.07E540DB
CAT-QuickHeal 8.00 10.14.2006 no virus found
ClamAV devel-20060426 10.13.2006 Trojan.Downloader.Small-2840
eTrust-InoculateIT 23.73.22 10.13.2006 Win32/SillyDL!Trojan
eTrust-Vet 30.3.3131 10.13.2006 Win32/Harnig!generic
DrWeb 4.33 10.14.2006 Trojan.DownLoader.13549
Ewido 4.0 10.13.2006 no virus found
Fortinet 2.82.0.0 10.14.2006 W32/Dowadv.CU!tr.dldr
F-Prot 3.16f 10.13.2006 Possibly a new variant of W32/Downloader-Sml-based!Maximus
F-Prot4 4.2.1.29 10.13.2006 W32/Downloader-Sml-based!Maximus
Ikarus 0.2.65.0 10.13.2006 no virus found
Kaspersky 4.0.2.24 10.14.2006 Trojan-Downloader.Win32.Harnig.cu
McAfee 4873 10.13.2006 no virus found
Microsoft 1.1603 10.14.2006 TrojanDownloader:Win32/Vxidl
NOD32v2 1.1803 10.13.2006 a variant of Win32/TrojanDownloader.Small.DIB
Norman 5.80.02 10.13.2006 W32/DLoader.gen2
Panda 9.0.0.4 10.14.2006 Suspicious file
Sophos 4.10.0 10.13.2006 no virus found
TheHacker 6.0.1.098 10.14.2006 Trojan/Downloader.Tibs.gen
UNA 1.83 10.13.2006 no virus found
VBA32 3.11.1 10.13.2006 suspected of Downloader.Small.3 (paranoid heuristics)
VirusBuster 4.3.7:9 10.13.2006 Trojan.DL.Harnig.Gen.3
It just shown that seemly harmless website may not be that harmless at all. You should be extremely vigilant when visiting unfamiliar websites. If in doubt, it is always good to tighten your browser configuration (e.g. disable Java/ Java script/ ActiveX) before making any attempts to visit the site. This is of course assuming you have the usual security measures in place (latest patch, virus definition etc.).
0 Comments
Published: 2006-10-13
Java Trojan/Bot
Jan sent us a nice trojan he found on a friend's defaced website. After 20 seconds, the defaced site will redirect users to the java applet which appears to implement a full featured bot. You should see a java security popup notifying you that the applet is signed by an "Unknown User". As always, do not click 'OK' but deny.
Given that it is written in Java, this bot could potentially work on different operating systems.
Given that it is written in Java, this bot could potentially work on different operating systems.
0 Comments
Published: 2006-10-13
New UrSnif/Haxdoor Variant
A number of readers reported a new variant of "Haxdoor" attachements. As usual, AV will not pick up this new virus for the most part. See below for a sample e-mail as submitted by our reader Derek. He ran the attachement through virustotal. Only e-Trust, Ikrasus and Panda picked it up as suspect.
Thank you for ordering from our internet shop. If you paid with a
credit card, the charge on your statement will be from name of our shop.
This email is to confirm the receipt of your order. Please do not reply
as this email was sent from our automated confirmation system.
Date : 08 Oct 2006 - 12:40
Order ID : 37679041
Payment by Credit card
Product : Quantity : Price
WJM-PSP - Sony VAIO SZ370 C2D T7200 : 1 : 2,449.99
Subtotal : 2,449.99
Shipping : 32.88
TOTAL : 2,482.87
Your Order Summary located in the attachment file ( self-extracting
archive with "37679041.pdf" file ).
PDF (Portable Document Format) files are created by Adobe Acrobat
software and can be viewed with Adobe Acrobat Reader. If you do not
already have this viewer configured on a local drive, you may download
it for free from Adobe's Web site.
We will ship your order from the warehouse nearest to you that has your
items in stock (NY, TN, UT & CA). We strive to ship all orders the same
day, but please allow 24hrs for processing.
You will receive another email with tracking information soon.
We hope you enjoy your order! Thank you for shopping with us!
Update:
One of our reader (Matthew) has notified us that McAfee is able to identify this new
trojan and had already provided "extra.dat" support to allow customers to update
their definitions (all platforms).
Running through VirusTotal again, other anti-virus scanners are starting to detect
this malware. Below are those with positive results:
Authentium 4.93.8 10.13.2006 W32/Goldun.NK
AVG 386 10.13.2006 Downloader.Generic2.TFP
BitDefender 7.2 10.14.2006 Trojan.Downloader.Agent.APP
ClamAV devel-20060426 10.13.2006 Trojan.Downloader.Small-2854
eTrust-InoculateIT 23.73.22 10.13.2006 Win32/Ursnif.MJI!Trojan
eTrust-Vet 30.3.3131 10.13.2006 Win32/Ursnif!downloader
DrWeb 4.33 10.14.2006 Trojan.DownLoader.14120
Fortinet 2.82.0.0 10.13.2006 W32/Dloader.AYT!tr.dldr
F-Prot 3.16f 10.13.2006 security risk named W32/Goldun.NK
F-Prot4 4.2.1.29 10.13.2006 W32/Goldun.NK
Ikarus 0.2.65.0 10.13.2006 Win32.Outbreak
Kaspersky 4.0.2.24 10.14.2006 Trojan.Win32.Small.kn
McAfee 4873 10.13.2006 Downloader-AXM
Microsoft 1.1603 10.14.2006 TrojanDownloader:Win32/Agent.EP
NOD32v2 1.1803 10.13.2006 Win32/TrojanDownloader.Small.NPO
Norman 5.80.02 10.13.2006 W32/DLoader.BAOZ
Panda 9.0.0.4 10.14.2006 Trj/SpyForms.J
0 Comments
Published: 2006-10-13
0-Day Thursday: PoC for Powerpoint Vulnerability
Late yesterday, the MSRC blog reported a new public PoC for a yet unpatched Powerpoint vulnerability. I guess the game is still going on. We have seen it many times over the last few months where a new exploit was published just after patch tuesday.
Details: MSRC Blog
Details: MSRC Blog
0 Comments
Published: 2006-10-12
Mother Nature - Please Help Us Cool Our Server Room
Earlier this week, the weather forecast was for cooler weather in our area by this time. We could really use a small Ice Age in our server room right now. ;-)
What happens when you put 40000 BTU/hr of equipment in a server room with 3 tons of AC cooling capacity? For those less familiar with server room and HVAC design, 1 ton of cooling capacity can handle 12000 BTU/hr of heat generated by equipment. So the answer is - we have probably exceeded our cooling capacity. I say probably since most of the servers aren't drawing the full power possible from their power supplies. While most large companies with data centers or server rooms probably have sufficent space and capacity for growth, small and medium size companies may perhaps be more limited.
Several employers ago, in a small office, we used a closet as our server room. Yes, really, a closet. Now at the time, we only had 1 server and 1 frame relay router and we did have an air vent in the closet, but we were pretty restricted in terms of future growth due to the lack of ability to handle heat dissipation. Eventually we did move the equipment to an actual room which had better airflow.
Currently, where I work, we have a server room that we designed more than 4 years ago. We have a Liebert air handler with a 3-ton condenser outside. When we started, we had two computer racks, 1 comm rack and we planned extra capacity to be able to add 2 more racks of equipment. We had sufficient dedicated power circuits, generator capacity and cooling capacity to handle this planned growth.
Four years and now four racks later, with many more smaller computers packed with multiple CPUs and lots of disk drives, plus miscellaneous other equipment, we walk into the server room and notice that it's a little warm at times. When one or more admins work in the room for 30 minutes or so, we notice it gets much warmer. The human body is a pretty good furnace.
We are currently researching options to either upgrade our main AC system to have a higher capacity or to add additional small cooling units in the room up on the walls.
This is just a reminder that as IT admins, in addition to protecting our data by making backups, patching systems to remove vulnerabilities and using defenses such as firewalls to reduce the potential unwanted exposure of of our data, we also need to be cognizant of our physical infrastructure and capacity.
If we don't have enough power, our systems turn off. Operationally, this is bad but at least the system will most likely boot back up once power is restored.
If we don't have enough cooling, again our systems may go offline, perhaps in a more permanent manner. While not as a result of our current AC issue, we have previously seen servers where the CPUs melted down and caused a fire in a server.
What happens when you put 40000 BTU/hr of equipment in a server room with 3 tons of AC cooling capacity? For those less familiar with server room and HVAC design, 1 ton of cooling capacity can handle 12000 BTU/hr of heat generated by equipment. So the answer is - we have probably exceeded our cooling capacity. I say probably since most of the servers aren't drawing the full power possible from their power supplies. While most large companies with data centers or server rooms probably have sufficent space and capacity for growth, small and medium size companies may perhaps be more limited.
Several employers ago, in a small office, we used a closet as our server room. Yes, really, a closet. Now at the time, we only had 1 server and 1 frame relay router and we did have an air vent in the closet, but we were pretty restricted in terms of future growth due to the lack of ability to handle heat dissipation. Eventually we did move the equipment to an actual room which had better airflow.
Currently, where I work, we have a server room that we designed more than 4 years ago. We have a Liebert air handler with a 3-ton condenser outside. When we started, we had two computer racks, 1 comm rack and we planned extra capacity to be able to add 2 more racks of equipment. We had sufficient dedicated power circuits, generator capacity and cooling capacity to handle this planned growth.
Four years and now four racks later, with many more smaller computers packed with multiple CPUs and lots of disk drives, plus miscellaneous other equipment, we walk into the server room and notice that it's a little warm at times. When one or more admins work in the room for 30 minutes or so, we notice it gets much warmer. The human body is a pretty good furnace.
We are currently researching options to either upgrade our main AC system to have a higher capacity or to add additional small cooling units in the room up on the walls.
This is just a reminder that as IT admins, in addition to protecting our data by making backups, patching systems to remove vulnerabilities and using defenses such as firewalls to reduce the potential unwanted exposure of of our data, we also need to be cognizant of our physical infrastructure and capacity.
If we don't have enough power, our systems turn off. Operationally, this is bad but at least the system will most likely boot back up once power is restored.
If we don't have enough cooling, again our systems may go offline, perhaps in a more permanent manner. While not as a result of our current AC issue, we have previously seen servers where the CPUs melted down and caused a fire in a server.
0 Comments
Published: 2006-10-10
Delays on Windows Update & the Death of SUS
Windows Update is currently experiencing delays and not serving up all those happy patches. The MSRC is reporting some delays with getting the patches up. If you need them immediately you can download directly from the bulletins. ISC Reader Jim McCormick found that by clearing out C:\WINDOWS\SoftwareDistribution\DataStore and C:\WINDOWS\SoftwareDistribution\Download he was able to take care of business. Choice is yours. You could also always wait. :)
Alan Mercer sent in a reminder that Microsoft is discontinuing support for SUS on Dec. 6th, 2006. Because this is before the December patch cycle, it seems that November will be the last patch cycle that SUS will be supported. With the holidays coming up, it's time to think about upgrading to WSUS.
Alan Mercer sent in a reminder that Microsoft is discontinuing support for SUS on Dec. 6th, 2006. Because this is before the December patch cycle, it seems that November will be the last patch cycle that SUS will be supported. With the holidays coming up, it's time to think about upgrading to WSUS.
0 Comments
Published: 2006-10-10
MS06-065: Remote Code Excution in Windows Object Packager
There exists a remote code execution vulnerability in Windows Object Packager (MS06-065) due to the way the application handles file extensions. A specially crafted file could be created that would execute code if a user was sent to a malicious website. However, there is quite a bit of user interaction required for this exploit to actually work. Enhanced Security Configuration for Windows 2003 will effectively mitigate this problem.
The CVE for this exploit is CVE-2006-4692 and will not likely see much action in the wild.
The CVE for this exploit is CVE-2006-4692 and will not likely see much action in the wild.
0 Comments
Published: 2006-10-10
MS06-064: Vulnerabilities in IPv6
According the advisory this one will fix a couple of
vulnerabilities. The vulnerabilities have the CVE numbers of CAN-2004-0790,
CAN-2004-0791 , CAN-2004-0230 and CAN-2005-0688.
The best way to understand the fixes is to think of them as an IPv6 version of
the same patch that fixed these same vulnerabilities last year with
MS05-019 (http://www.microsoft.com
Another thing is that it is a DoS condition remote attack, which could
make your system reboot or stop to repond, so I would recommed you to
follow the same procedures (test, test, test, deploy).
vulnerabilities. The vulnerabilities have the CVE numbers of CAN-2004-0790,
CAN-2004-0791 , CAN-2004-0230 and CAN-2005-0688.
The best way to understand the fixes is to think of them as an IPv6 version of
the same patch that fixed these same vulnerabilities last year with
MS05-019 (http://www.microsoft.com
Another thing is that it is a DoS condition remote attack, which could
make your system reboot or stop to repond, so I would recommed you to
follow the same procedures (test, test, test, deploy).
0 Comments
Published: 2006-10-10
MS06-063: Mailslot DoS (Server service)
This vulnerability from Microsoft is a simple Denial of Service against all Windows platforms. The attack vector is TCP ports 139 or 445. Apparently, there is an unitialized buffer that could be modified remotely to crash the box. Exploit code has been available for this bug since July 19, 2006. Famed handler Swa covered it in a diary entry last month: http://isc.sans.org/diary.php?storyid=1599
It looks like the Core Security folks found this after the MS06-035 in July (http://www1.corest.com/common/showdoc.php?idx=562. Microsoft also has a blog entry on it: http://blogs.technet.com/msrc/archive/2006/07/28/443837.aspx .
There probably isn't any need to freak out on this one. The exploit has been out in the wild for several months. If you are seeing some mysterious reboots on Windows machines and untrusted people can hit TCP 139 or 445 on those hosts, then this could potentially solve your problems (although Microsoft is claiming that it hasn't been used in the wild yet). Otherwise, there are no code execution possibilities with this vulnerability, so you don't need to be in "emergency mode" to patch it.
It looks like the Core Security folks found this after the MS06-035 in July (http://www1.corest.com/common/showdoc.php?idx=562. Microsoft also has a blog entry on it: http://blogs.technet.com/msrc/archive/2006/07/28/443837.aspx .
There probably isn't any need to freak out on this one. The exploit has been out in the wild for several months. If you are seeing some mysterious reboots on Windows machines and untrusted people can hit TCP 139 or 445 on those hosts, then this could potentially solve your problems (although Microsoft is claiming that it hasn't been used in the wild yet). Otherwise, there are no code execution possibilities with this vulnerability, so you don't need to be in "emergency mode" to patch it.
0 Comments
Published: 2006-10-10
MS06-057: Vulnerability in Windows Shell Could Allow Remote Code Execution (926043)
https://www.microsoft.com/technet/security/bulletin/ms06-057.mspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4690
http://isc.sans.org/diary.php?storyid=1749
Affected Software:
- Microsoft Windows 2000 Service Pack 4
- Microsoft Windows XP Service Pack 1 and 2
- Microsoft Windows XP Professional x64 Edition
- Microsoft Windows Server 2003 and WS 2003 Service Pack 1 (Mitigated)
- Microsoft Windows Server 2003 and WS 2003 w/ SP1 for Itanium-based Systems (Mitigated)
- Microsoft Windows Server 2003 x64 Edition (Mitigated)
Impact: Remote Code Execution
Severity: Critical
(This replaces 06-045 for XP SP 1)
Description: This is a remote code execution for Internet Explorer, that is caused by improper validation of the WebViewFolderIcon ActiveX object.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4690
http://isc.sans.org/diary.php?storyid=1749
Affected Software:
- Microsoft Windows 2000 Service Pack 4
- Microsoft Windows XP Service Pack 1 and 2
- Microsoft Windows XP Professional x64 Edition
- Microsoft Windows Server 2003 and WS 2003 Service Pack 1 (Mitigated)
- Microsoft Windows Server 2003 and WS 2003 w/ SP1 for Itanium-based Systems (Mitigated)
- Microsoft Windows Server 2003 x64 Edition (Mitigated)
Impact: Remote Code Execution
Severity: Critical
(This replaces 06-045 for XP SP 1)
Description: This is a remote code execution for Internet Explorer, that is caused by improper validation of the WebViewFolderIcon ActiveX object.
Why do you have "Mitigated" in Yellow up above?
By default, Internet Explorer on Windows Server 2003 runs in a restricted mode that is known as Enhanced Security Configuration. This mode mitigates this vulnerability.
To set the kill bits for CLSIDs with values of {e5df9d10-3b52-11d1-83e8-00a0c90dc849} and {844F4806-E8A8-11d2-9652-00C04FC30871}, paste the following text in a text editor such as Notepad. Then, save the file by using the .reg file name extension.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{e5df9d10-3b52-11d1-83e8-00a0c90dc849}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{844F4806-E8A8-11d2-9652-00C04FC30871}]
"Compatibility Flags"=dword:00000400
0 Comments
Published: 2006-10-10
MS06-061: XSLT/MSXML Buffer Overflow Code Execution Vulnerability (moderate)
This vulnerability sounds like a classic parser buffer overflow. The advisory actually includes information regarding two distinct vulnerabilities. But only one of them allows arbitrary code execution.
As with similar vulnerablities, the user has to expose the browser to malicious XML code. This could happen by visiting a compromissed site. Once the browser is exposed to the exploit, it will inherit all the privileges of the user running the browser.
Mitigation steps: SandboxIE, do not run as administrator and similar steps will help limit the impact of the vulnerability. This vulnerability is first of all a client issue, less a server issue. You could also try the "Internet Explorer Enhanced Security Configuration". However, I find it a bit too strict most of the time (e.g. no Javascript).
As with similar vulnerablities, the user has to expose the browser to malicious XML code. This could happen by visiting a compromissed site. Once the browser is exposed to the exploit, it will inherit all the privileges of the user running the browser.
Mitigation steps: SandboxIE, do not run as administrator and similar steps will help limit the impact of the vulnerability. This vulnerability is first of all a client issue, less a server issue. You could also try the "Internet Explorer Enhanced Security Configuration". However, I find it a bit too strict most of the time (e.g. no Javascript).
0 Comments
Published: 2006-10-10
MS Office vulnerabilities (-058, -059, -060, -062)
There are four advisories for Microsoft Office this month. All of them appear to be standard client-side vulnerabilities. So the exploitation model is someone evil sends a document (of the affected type) with an exploit buried inside and if the exploit works, the attacker gets the privileges of the user opening the document. These types of bugs have been very popular lately.
MS06-058: Four vulnerabilities in PowerPoint that were reported privately. Exploit code and details have not been released yet.
MS06-059: Four vulnerabilities in Excel. Two of these have had proof of concept exploit code posted publicly already; the other two vulnerabilities were privately reported to Microsoft.
MS06-060: Four vulnerabilities in Word. Two of these have been publicly disclosed already; the other two vulnerabilities were privately reported to Microsoft.
MS06-062: Three vulnerabilities in Office and Publisher that were reported privately. Exploit code and details have not been released yet.
MS06-058: Four vulnerabilities in PowerPoint that were reported privately. Exploit code and details have not been released yet.
MS06-059: Four vulnerabilities in Excel. Two of these have had proof of concept exploit code posted publicly already; the other two vulnerabilities were privately reported to Microsoft.
MS06-060: Four vulnerabilities in Word. Two of these have been publicly disclosed already; the other two vulnerabilities were privately reported to Microsoft.
MS06-062: Three vulnerabilities in Office and Publisher that were reported privately. Exploit code and details have not been released yet.
0 Comments
Published: 2006-10-10
MS06-056: ASP.NET XSS Information Disclosure Vulnerability (moderate)
A XSS vulnerabiity in ASP.NET could allow information disclosure. The bulletin is a bit vague on the details, but it does mention a problem with headers. Typically, cookie information could be disclosed using XSS attacks. In turn, the cookie information can be used to impersonate an authenticated user.
The script inserted with XSS will inherit all the capabilities the particular user has. For example, a user could be tricked into clicking a link that will escalate privileges for a malicious user. Exploitation typially requires intimate knowledge of the respective web based application.
XSS exploits are typically not browser specific. Any browser is "vulnerable" given that the actual problem is the web based application. Turning off javascript may help, but then again, you will hit this issue typically as you visit a trusted web site (for example you own web site written in ASP.NET).
You will probably consider this problem more severe ("critical") if you use ASP.NET extensively to manage internal applications. However, on the same note first test the page using your specific web based applications.
Other mitigation steps: Disable ASP.NET if not used on your web server.
This patch is not important for workstations and only applies to servers running web sites with ASP.NET support turned on.
The script inserted with XSS will inherit all the capabilities the particular user has. For example, a user could be tricked into clicking a link that will escalate privileges for a malicious user. Exploitation typially requires intimate knowledge of the respective web based application.
XSS exploits are typically not browser specific. Any browser is "vulnerable" given that the actual problem is the web based application. Turning off javascript may help, but then again, you will hit this issue typically as you visit a trusted web site (for example you own web site written in ASP.NET).
You will probably consider this problem more severe ("critical") if you use ASP.NET extensively to manage internal applications. However, on the same note first test the page using your specific web based applications.
Other mitigation steps: Disable ASP.NET if not used on your web server.
This patch is not important for workstations and only applies to servers running web sites with ASP.NET support turned on.
0 Comments
Published: 2006-10-09
Microsoft black tuesday - October 2006 STATUS
Overview of the October 2006 Microsoft patches and their status.
| # | Affected | Known Problems | Known Exploits | Microsoft rating | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
| MS06-XXX | XXX - affected component (short) CVE-2006-XXX CVE-2006-XXX |
XXX - No known problems KB XXX |
XXX - No known exploits |
Critical | PATCH NOW | PATCH NOW |
We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
- We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leaisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-caserole.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
--
XXX
0 Comments
Published: 2006-10-09
IE7 to hit the streets
Thanks to one of our readers that wrote in to tell us that IE7, in all of it's wonder, will be released this month via Automatic Update according to Microsoft's "IEBlog".
Excuse me if I am less than impressed. IE4 was bad, as was 5, guess what?? IE6 was horrible too. IE7 will be par for the course. I've tried it, yes, I've used it, yes. But it just looks like every other browser! I mean, thank you Microsoft for finally making functionality available that has been in other browsers since... 1995?
Your RSS reader looks like Apples, your Tabbed browsing looks like... everyone elses.. and your security.. well.. lets at least HOPE its better.
My advice? Diversify. Use other browsers. I use Safari, Firefox, and Opera. I own zero Windows based computers, but I have access to thousands. I suggest you out there in 'reader land' switch to something else. Unless we see empirical evidence that IE7 is vastly more secure and superior.. it will be just like every other browser that has been out since 2000.
Excuse me if I am less than impressed. IE4 was bad, as was 5, guess what?? IE6 was horrible too. IE7 will be par for the course. I've tried it, yes, I've used it, yes. But it just looks like every other browser! I mean, thank you Microsoft for finally making functionality available that has been in other browsers since... 1995?
Your RSS reader looks like Apples, your Tabbed browsing looks like... everyone elses.. and your security.. well.. lets at least HOPE its better.
My advice? Diversify. Use other browsers. I use Safari, Firefox, and Opera. I own zero Windows based computers, but I have access to thousands. I suggest you out there in 'reader land' switch to something else. Unless we see empirical evidence that IE7 is vastly more secure and superior.. it will be just like every other browser that has been out since 2000.
0 Comments
Published: 2006-10-09
SANS Network Security 2007 -- Vegas
Well, having freshly returned from SANS NS 2007 in Las Vegas, NV. I thought I would add a few thoughts.
First off, Vegas is a great city, it appeals to some, and others hate it. I personally, love Las Vegas. It's fun, my wife quotes it to be an adult Disneyland. I think that's an appropriate description.
I did several things while there. First off, on Sunday night, we had our Incident Handlers dinner. Mike Poor, Lorna Hutcheson, Marc Sachs, Johannes Ullrich, Brian Granier, Ed Skoudis, me, and a couple others were there (If I forgot exactly who was sitting around the table, don't beat me fellow handlers! Please remind me). We had a good time sitting around swapping stories about Microsoft.
We each had our own respective classes to teach last week. (Some are still out there teaching!), I taught the Snort: Building and Operating and Snort Rules classes, and in the meantime ran over and hung out/spoke in Mike Poor's Intrusion Detection in-Depth Class.
I attended a couple talks while I was there, notably Marty Roesch's (Creator of Snort, and founder of Sourcefire) "Snort: Past, Present, and Future" talk on Thursday night, and his "One Click Compliance" talk on Friday at lunch. I didn't get a chance to attend Brian's Spam/Anti-Spam talk, nor did I get a chance to see Lorna's Malware talk. Both of which I wanted to attend but had conflicting events. I did attend a roundtable discussion Sunday night with Marc Sachs, Johannes Ullrich, Ed Skoudis, Stephen Northcutt, and Eric Cole on "Future threats". It was an excellent discussion.
All in all, I met a lot of the readers, I hung out with a lot of the handlers, and was able to spend a lot of time with all my friends.
Maybe today will be a slow day for the Internet, and you, the reader, can write in and share your experience with us at Vegas. Please use our contact link above, by clicking on the Handler of the Day's name. Also -- my fellow handlers -- feel free to edit this article and add your own thoughts and experiences!
First off, Vegas is a great city, it appeals to some, and others hate it. I personally, love Las Vegas. It's fun, my wife quotes it to be an adult Disneyland. I think that's an appropriate description.
I did several things while there. First off, on Sunday night, we had our Incident Handlers dinner. Mike Poor, Lorna Hutcheson, Marc Sachs, Johannes Ullrich, Brian Granier, Ed Skoudis, me, and a couple others were there (If I forgot exactly who was sitting around the table, don't beat me fellow handlers! Please remind me). We had a good time sitting around swapping stories about Microsoft.
We each had our own respective classes to teach last week. (Some are still out there teaching!), I taught the Snort: Building and Operating and Snort Rules classes, and in the meantime ran over and hung out/spoke in Mike Poor's Intrusion Detection in-Depth Class.
I attended a couple talks while I was there, notably Marty Roesch's (Creator of Snort, and founder of Sourcefire) "Snort: Past, Present, and Future" talk on Thursday night, and his "One Click Compliance" talk on Friday at lunch. I didn't get a chance to attend Brian's Spam/Anti-Spam talk, nor did I get a chance to see Lorna's Malware talk. Both of which I wanted to attend but had conflicting events. I did attend a roundtable discussion Sunday night with Marc Sachs, Johannes Ullrich, Ed Skoudis, Stephen Northcutt, and Eric Cole on "Future threats". It was an excellent discussion.
All in all, I met a lot of the readers, I hung out with a lot of the handlers, and was able to spend a lot of time with all my friends.
Maybe today will be a slow day for the Internet, and you, the reader, can write in and share your experience with us at Vegas. Please use our contact link above, by clicking on the Handler of the Day's name. Also -- my fellow handlers -- feel free to edit this article and add your own thoughts and experiences!
0 Comments
Published: 2006-10-08
Swa Frantzen -- Section 66
Spam Backscatter
Over the weekend I dealt with a (rather massive) spam campaign side effects.
In a few minutes about 10,000 messages arrived on a "catch-all" email address. Those messages consisted of:
- Non-Delivery Reports (NDR)
- Delivery Status Notifications (DSN)
- Out of Office messages
- Automated responses indicating the target does not work anymore where he was working
- Questions to confirm the message is genuine
- Automated reports informing it was considered spam
- Automated reports informing it contained a virus
- Automated reports informing it contianed bad links
- ...
These messages come in at an incredible rate where they contain the original headers you can see they are spammed from all over the address space (so it's likely to be a botnet sending it out). The error messages are in at least half a dozen languages.
The spams were spoofed to come from random names at a domain and all those responses from the victims only create more victims.
So in order to keep the Internet a place where we all can survive it is critical:
- Your email servers know which messages can be accepted or not and refuse the message if it needs to bounce before letting the sender move on and need a NDR or DSN to be sent to another victim.
- You do this by NOT having fallback MX records where these messages are dumped and then generate all the bounces. The fallback MX mechanism is only useful if you have a very unreliable link and actually use something like ETRN to fetch your email. But if you can surf the Internet reliably, the MTAs will work perfectly without a fallback MX.And should your sefver be down: the orginating MTA will store it till the next queue run.
- You do this by scanning for active mailboxes before accepting the email.
- You do this by scanning for unwanted content before accepting the email.
- Kill all vacation, out of office messages, does nto work here anymore, .... automated replies: it's a risk. And if you get a few thousand of them while you didn't send those people anything it's a real pain.
- Stop grey-listing: this is really the cheap solution and it is protecting yourself and putting the burden on the rest of us who don't even want to have anything to do with you in the first place.
- Automated scanning; if you do need to send somebody somethign that a unwanted message got filtered: send it to the recipient. If (s)he wanted the message, it can be gotten out of quarantine, but don't bother others with it, you're sending it toward the wrong people. And those that did send it to you: they know.
How do you survive this onslaught? You stop accepting the catch-all email and refuse all those incoming messages and/or -for those addresses you need to accept email- you start to drop all of those unwanted messages in a filter. Dropping MX records only works if you have no A record, but it might be an option. And no: you don't reply to any of them, there have been enough victims.
Personally I feel it's long overdue to really start implementing a usable alternative to the current email system. One of the requirements would be sender authentication and inability to create just a new identity after you got blocklisted.
Next comes that you might not be able to send much email anymore as there will be enough people who are misguided in assuming you or your domain in fact did send that message (the header forgery was not that bad, so some might even believe you relayed the messages).
If you do think you absolutely need fallback MX records, need DSN, ... well I'm sure you might sing a slightly different tune when are the victim of 10K messages in the first few minutes, and still going strong after many hours.
Swa Frantzen -- Section 66
0 Comments
Published: 2006-10-08
Weekend blues
While weekends in general are kinda slow in security news, there seems to be somewhat of an opposite trend on the side of those who attack us.
- Email spammers seen to be more active during weekend
- Forum/feedback spammers seem to be on the same page
- The iframe gang seems to start their campaigns on Fridays
- New exploits typically are usedin the wild on Friday afternoon/nights
Why the bad guys do this is easy: it slows us defenders down to have to take countermeasures during the weekend.
So if there is a lesson to learn, it's to make sure our defences during the weekend are up to speed. Yet even if we do have experienced staff in place, those laptops e.g. are still outside of their protective perimeter, possible even used for (mostly?) non-professional activity.
Keeping our defenses up to speed means also even for small companies to be reachable towards our ISP, and the world at large if you have anything that's connected to the Internet: if one of our servers gets abused and is used to attack otheers we need to be able to take action on the problem we're causing.
--
Swa Frantzen -- Section 66
0 Comments
Published: 2006-10-07
Is it a SIP Recon scan or something else
It seems that there have been some reports of calls on SIP devices over the last couple of days
with a caller ID of ‘John Doe <4000>‘.
According to an article on freePBX.org's blog site FreePBX :
"This does seem to be a world first - It’s someone, or something, actively scanning the entire internet for misconfigured SIP devices."
Is someone or something testing for a hole or are they checking for systems that are vulnerable to some exploit? According to article SIP uses port 5060. A quick look at the DShield report for port 5060 Dshield.org there has been some activity on this port but nothing significant. It will be interesting to see just how wide spread this is. If you are using an SIP device and have seen this activity on your system let us know. If you have any thoughts or ideas regarding this activity tell us about it.
Thanks to Babak for sending us this information.
According to an article on freePBX.org's blog site FreePBX :
"This does seem to be a world first - It’s someone, or something, actively scanning the entire internet for misconfigured SIP devices."
Is someone or something testing for a hole or are they checking for systems that are vulnerable to some exploit? According to article SIP uses port 5060. A quick look at the DShield report for port 5060 Dshield.org there has been some activity on this port but nothing significant. It will be interesting to see just how wide spread this is. If you are using an SIP device and have seen this activity on your system let us know. If you have any thoughts or ideas regarding this activity tell us about it.
Thanks to Babak for sending us this information.
0 Comments
Published: 2006-10-07
Handlers in Vegas - Slow Diary Day
It has really been a slow news day and many of our Handlers are in Vegas at the SANS conference. Humm, makes you wonder if there is a connection. Anyway we can't wait to get a report back from those attending as to the fun and frivolities that they have encountered.
In light of the slow diary day, I want to take this opportunity to write about the SANS Reading Room.
SANS Reading Room
If you haven't taken a look at the information in the Reading Room yet you will be surprised at what you have missed. There is a wealth of information and lots of valuable resources on a number of topics of interest to anyone in the Computer Security/Information Security field. There is also a great deal of information to help you learn more about how to secure your networks.
New information and articles are added regularly so you will want to check back often to see what new information is available.
In light of the slow diary day, I want to take this opportunity to write about the SANS Reading Room.
SANS Reading Room
If you haven't taken a look at the information in the Reading Room yet you will be surprised at what you have missed. There is a wealth of information and lots of valuable resources on a number of topics of interest to anyone in the Computer Security/Information Security field. There is also a great deal of information to help you learn more about how to secure your networks.
New information and articles are added regularly so you will want to check back often to see what new information is available.
0 Comments
Published: 2006-10-05
There are no more Passive Exploits
The class of so-called "passive exploits" are more serious than previously considered. In the past, you would have to "trick" users to visit webpages or otherwise go to the exploit. This has shown to be easy enough, some users will click on anything. However, with the ubiquity of wireless, it is not only easy to get around the passive part of the exploit with wireless man-in-the-middle attacks, it allows for targetting the exploits to certain classes of people or organizations for maximum impact.
Wireless man-in-the-middle attacks are pretty trivial and can take several forms. For instance, "airpwn" which debuted at DefCon some time ago would focus on replacing images when victim machines would surf the web. It would be easy, for instance, to inject harmful malware into innocuous web traffic and infect machines unknowingly to the user. The Intel wireless driver vulnerability suggests that it is possible to exploit wireless drivers directly. The mindless expansion of wireless availability without thinking of the security implications means we need to play a little catch up.
The downside of using wireless exploits is that it ties the hacker to a geographical area. The upside is that it allows you to highly target your victims without "spamming the world". This helps malware developers avoid their malware getting detected by AV/Anti-Spyware applications.
It is trivial to determine if your malware is detected by these applications, you can simply scan the file yourself. If your malware doesn't trip the heuristics or the signatures, the malware will slip past anything used to defend a PC. If you spead this malware on a local basis, it makes it that much more difficult for AV/Anti-Spyware vendors to find the malware, reverse engineer it, and develop a signature. The malware has to find the AV/Anti-Spyware companies, in a sense, before it can be examined. It's not impossible, but it is another large barrier of defense. Anti-Virus/Anti-Spyware applications are, by design, set up for maximum privilege (as opposed to least privilege). Anything that doesn't trip their rules is allowed.
The particular application here isn't the general script kiddie, mass identity theft stunts that are all too common. The application is corporate espionage or espionage proper. Here's an example:
Alpha Industries has invested massive amounts of R&D and developed products far ahead of the competition, Zulu, Inc. Zulu, realizing they are being left in the dust and suffering from a bout of "moral flexibility" decides to try to spy on Alpha Industries. They know the headquearters is near a popular coffee shop with wireless that many Alpha employees frequent. They pay a hacker to sit in the coffee shop and silently inject malware onto any machine that connects.
This malware is pretty simply. All it does is search a desktop machine for any "office files" that it sees, takes a few, zips them with a password, and then silently mails them to a dropbox read by Zulu, Inc. employees. Those employees then take the, hopefully, proprietary information and starts to get a leg-up.
The basic point here is that it became much more important to patch even those "passive exploits" if you have information to protect, to start thinking about how to layer defense against malware, and to develop policies and procedures to protect confidential information especially if laptops containing it "go on the road."
---
John Bambenek, bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
Wireless man-in-the-middle attacks are pretty trivial and can take several forms. For instance, "airpwn" which debuted at DefCon some time ago would focus on replacing images when victim machines would surf the web. It would be easy, for instance, to inject harmful malware into innocuous web traffic and infect machines unknowingly to the user. The Intel wireless driver vulnerability suggests that it is possible to exploit wireless drivers directly. The mindless expansion of wireless availability without thinking of the security implications means we need to play a little catch up.
The downside of using wireless exploits is that it ties the hacker to a geographical area. The upside is that it allows you to highly target your victims without "spamming the world". This helps malware developers avoid their malware getting detected by AV/Anti-Spyware applications.
It is trivial to determine if your malware is detected by these applications, you can simply scan the file yourself. If your malware doesn't trip the heuristics or the signatures, the malware will slip past anything used to defend a PC. If you spead this malware on a local basis, it makes it that much more difficult for AV/Anti-Spyware vendors to find the malware, reverse engineer it, and develop a signature. The malware has to find the AV/Anti-Spyware companies, in a sense, before it can be examined. It's not impossible, but it is another large barrier of defense. Anti-Virus/Anti-Spyware applications are, by design, set up for maximum privilege (as opposed to least privilege). Anything that doesn't trip their rules is allowed.
The particular application here isn't the general script kiddie, mass identity theft stunts that are all too common. The application is corporate espionage or espionage proper. Here's an example:
Alpha Industries has invested massive amounts of R&D and developed products far ahead of the competition, Zulu, Inc. Zulu, realizing they are being left in the dust and suffering from a bout of "moral flexibility" decides to try to spy on Alpha Industries. They know the headquearters is near a popular coffee shop with wireless that many Alpha employees frequent. They pay a hacker to sit in the coffee shop and silently inject malware onto any machine that connects.
This malware is pretty simply. All it does is search a desktop machine for any "office files" that it sees, takes a few, zips them with a password, and then silently mails them to a dropbox read by Zulu, Inc. employees. Those employees then take the, hopefully, proprietary information and starts to get a leg-up.
The basic point here is that it became much more important to patch even those "passive exploits" if you have information to protect, to start thinking about how to layer defense against malware, and to develop policies and procedures to protect confidential information especially if laptops containing it "go on the road."
---
John Bambenek, bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
0 Comments
Published: 2006-10-05
Microsoft Advance Notice Out - 11 Patches
This months Advance Bulletin is out. The breakdown is 6 Windows with critical(s), 4 Office with critical(s) and 1 .NET patch that's moderate. More details as we get them but it looks to be an active day of patching with (hopefully) some pretty important patches (like this one).
UPDATE (3:21PM Central) - To clarify, that's not 6 criticals; that's somewhere between 1 and 6 criticals.
--
John Bambenek , bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
UPDATE (3:21PM Central) - To clarify, that's not 6 criticals; that's somewhere between 1 and 6 criticals.
--
John Bambenek , bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
0 Comments
Published: 2006-10-05
MS06-053 revisited ?
When we first read MS06-053 we ended up discussing and not fully understanding what Microsoft was trying to say (or hide, depending on your level of trust). It seemed like every time we thought we had it, the confusion crept in again.
Well, the confusion is still not fully gone, but some seem to have developed the thing to a point where there is no ignoring that you do not need an Indexing Service, nor an IIS server in the picture, in fact all you need is Microsoft's browser.
CVE-2006-0032 seems to indicate in its description that it indeed is a problem in the server allowing UTF-7 encoding.
Wait a second, "+ADw-" is supposed to represent "<" ? How many application developers know of this encoding?
UTF-7 is defined in RFC2152, titled "Mail-Safe Transformation Format of Unicode". How many of those developers do really care about something designed for email when writing their application for the web?
Ok, back to the core of the problem: this UTF-7 XSS vulnerability in the indexing service, was that it? Or was it just the tip of the iceberg, and is there something wrong in MSIE (as well)?
Not giving encoding back and including some seemingly innocent strings ([A-Za-z0-9+\-] is enough) -based on user input- is enough to create a XSS vulnerability for visitors using MSIE.
The "ouch" part are e.g. custom error pages that might not include any character set information but might include (part of) the requested URL: CVE-2006-5152.
Conclusion
Swa Frantzen -- Section 66
Well, the confusion is still not fully gone, but some seem to have developed the thing to a point where there is no ignoring that you do not need an Indexing Service, nor an IIS server in the picture, in fact all you need is Microsoft's browser.
Back to the start
MS06-053 is about a vulnerability in the Indexing Service it seems. The title is "Vulnerability in Indexing Service Could Allow Cross-Site Scripting (920685)". It references to CVE-2006-0032. And has hidden deep inside the workarounds: "Disable page encoding auto-detection in Internet Explorer". So the confusion is really if this is a server problem or a client problem and it somehow seems we're not the only confused ones out there. Now with XSS it's the client that's abused by trusting a vulnerable server. Yet it seems that making the client do things differently the server is saved?CVE-2006-0032 seems to indicate in its description that it indeed is a problem in the server allowing UTF-7 encoding.
Now what does that encoding look like?
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
Wait a second, "+ADw-" is supposed to represent "<" ? How many application developers know of this encoding?
UTF-7 is defined in RFC2152, titled "Mail-Safe Transformation Format of Unicode". How many of those developers do really care about something designed for email when writing their application for the web?
Ok, back to the core of the problem: this UTF-7 XSS vulnerability in the indexing service, was that it? Or was it just the tip of the iceberg, and is there something wrong in MSIE (as well)?
MSIE
Well it seems that if MSIE is not given a character set, it will autoselect one, and might just choose UTF-7. I'm sure somebody must have found it a cool feature, just like having a flight simulator in excel is cool.Not giving encoding back and including some seemingly innocent strings ([A-Za-z0-9+\-] is enough) -based on user input- is enough to create a XSS vulnerability for visitors using MSIE.
The "ouch" part are e.g. custom error pages that might not include any character set information but might include (part of) the requested URL: CVE-2006-5152.
Conclusion
- Well we could put on the recorded message of not using MSIE. It does sound broken, doesn't it? But those that would listen will have done so already by now.
- We could urge people to change the settings of MSIE:
- Launch Internet Explorer
- Click on View;
- Click on Encoding;
- Deselect Auto-select if it is selected.
- We can ask people to take care of their visitors and make the applications stronger in authenticating users before taking actions and in not storing authentication, sensitive information etc. in cookies and the like.
- If you develop web applications, make sure you always set the encoding, don't ever let MSIE guess as perfectly innocent looking strings might cause XSS problems.
- We could urge people to look at their errorlog and find 404 results and see if there was recon on using UTF-7 in it, but the recon can be very subtle. So at least check if your custom 404 web pages return the requested URL and stop doing that.
Swa Frantzen -- Section 66
0 Comments
Published: 2006-10-04
Sniffers in Perl?!?
Maybe this will be interesting to the coders out there or possibly inspire someone to solve a problem in a different way... Download it here: http://handlers.sans.org/khaugsness/tail-pcap.pl
A while back I needed to do some sniffing for very specific packets in Perl. And I needed to wrap some logic around the packet processing. Doing regex matching and normal byte filtering in tcpdump wasn't going to be sufficient. So I wrote a quick little script using a Perl module to interface with the libpcap library. Everything was straight-forward and well documented until I needed to tail an existing pcap file. Google failed me. So through a little trial-and-error I figured out how to solve the problem. Here is an example script on how to do this.
Lessons learned: it isn't hard to write your own customized sniffer. Perl and Python have well-documented high-level interfaces that do most of the hard work for you.
A while back I needed to do some sniffing for very specific packets in Perl. And I needed to wrap some logic around the packet processing. Doing regex matching and normal byte filtering in tcpdump wasn't going to be sufficient. So I wrote a quick little script using a Perl module to interface with the libpcap library. Everything was straight-forward and well documented until I needed to tail an existing pcap file. Google failed me. So through a little trial-and-error I figured out how to solve the problem. Here is an example script on how to do this.
Lessons learned: it isn't hard to write your own customized sniffer. Perl and Python have well-documented high-level interfaces that do most of the hard work for you.
0 Comments
Published: 2006-10-04
Old Webmin bug still being exploited
Sometimes it isn't the latest and greatest bug that gets the most utility from the criminals on the Internet, it's the easiest and most reliable. We received some solid analysis from a large hosting provider showing that Webmin versions below 1.290 are still being actively exploited. Version 1.290 that fixes the problem was released in June 2006, so the exploit is several months old.
To give some insight, this particular bug allows the attacker to read any file from the target as the root user. So the attacker is grabbing /etc/passwd and /etc/shadow from targets and then running john the ripper against the encrypted passwords. There is a nice auto-rooter toolkit that has a .ro (Romania) e-mail address claiming authorship.
While there is nothing exotic or shocking about any of this, it's still important for us to think about *NIX security. We don't want all the *NIX folks out there feeling that Microsoft client-side bugs are getting all the attention lately.
To give some insight, this particular bug allows the attacker to read any file from the target as the root user. So the attacker is grabbing /etc/passwd and /etc/shadow from targets and then running john the ripper against the encrypted passwords. There is a nice auto-rooter toolkit that has a .ro (Romania) e-mail address claiming authorship.
While there is nothing exotic or shocking about any of this, it's still important for us to think about *NIX security. We don't want all the *NIX folks out there feeling that Microsoft client-side bugs are getting all the attention lately.
0 Comments
Published: 2006-10-03
[ scan result ]
Swa Frantzen -- Section 66
Scammer tying in on disasters
We saw them before, scum trying to make money off of disasters in other people's lives. And an aircraft crash in Brazil is not different. Start with a spammed campaign promoting a website, the website promoting clicking on tiny thumbnail images that lead to malware. Not cool.
Find courtesy of Websense, who has an article about it.
Here is what the antivirus vendors think of the malware (virustotal):
[ file data ]| size | 274462 |
| md5 | fca50b317ac7648b65c80a2f08ede9ef |
| sha1 | bd85d52e616ab14bef3bfe42e9d44c0820d895cf |
[ scan result ]
| AntiVir | 7.2.0.22/20061003 | found [DR/Spy.Bancos.YT] |
| Authentium | 4.93.8/20061002 | found [W32/Banker.XCA] |
| Avast | 4.7.892.0/20061003 | found nothing |
| AVG | 386/20061003 | found nothing |
| BitDefender | 7.2/20061003 | found [Generic.Banker.VB.11DF9CB6] |
| CAT-QuickHeal | 8.00/20061003 | found nothing |
| ClamAV | devel-20060426/20061003 | found nothing |
| DrWeb | 4.33/20061003 | found [BackDoor.Generic.1437] |
| eTrust-InoculateIT | 23.73.11/20061002 | found nothing |
| eTrust-Vet | 30.3.3113/20061003 | found nothing |
| Ewido | 4.0/20061003 | found nothing |
| F-Prot | 3.16f/20061002 | found [security risk named W32/Banker.XCA] |
| F-Prot4 | 4.2.1.29/20061002 | found [W32/Banker.XCA] |
| Fortinet | 2.82.0.0/20061003 | found [Spy/Bancos] |
| Ikarus | 0.2.65.0/20061003 | found [Backdoor.Win32.Radmin.w] |
| Kaspersky | 4.0.2.24/20061003 | found [Trojan-Spy.Win32.Bancos.yt] |
| McAfee | 4865/20061003 | found nothing |
| Microsoft | 1.1603/20061003 | found nothing |
| NOD32v2 | 1.1787/20061003 | found [probably a variant of Win32/Spy.Bancos.U ] |
| Norman | 5.80.02/20061003 | found [Bancos.KVY] |
| Panda | 9.0.0.4/20061003 | found nothing |
| Sophos | 4.10.0/20061003 | found nothing |
| Symantec | 8.0/20061003 | found nothing |
| TheHacker | 6.0.1.090/20061003 | found [Trojan/Spy.KeyLogger.bp] |
| UNA | 1.83/20061003 | found nothing |
| VBA32 | 3.11.1/20061003 | found [Trojan-Spy.Win32.Bancos.yt] |
| VirusBuster | 4.3.7:9/20061003 | found nothing |
IOW: a bank aware keylogging piece of malware that's not detected by some of the big name vendors.
The important lesson to learn is not to click on links in email or IM, or any other way you could be social engineered into doing things you don't want to do. That however needs to be translated not just on the receiving end into not following links we're given, but also on the sending end by not offering friendly links to our friends.
e.g.:
- NOT: pointing to http://news.bbc.co.uk/1/hi/world/americas/5401846.stm
- BUT instead tell them go to the bbc and search for 'brazil aircrash' instead.
Swa Frantzen -- Section 66
0 Comments
Published: 2006-10-03
Firefox ...
Firefox seems to have its share of followers, just like the Mac community. I'm actually using both typing this so don't get on my case too much. Their supporters seem to react a lot when it comes to vulnerabilities being exposed at hacker venues. While fascinating from a social perspective, let's look at what we do know:
Over the weekend a conference called ToorCon was held in San Diego and one of the presentations by Mischa Spiegelmock and Andrew Wbeelsoi was (among other things?) about Firefox security.
None of us handlers at that point had seen the presentation(*) itself and the interaction with a Mozilla staffer, but we did see the Mozilla developers react to it like it was real (as they should) and we reported briefly about it ourselves. So there was something but none of us knew exactly what or how it was and the threat of having more exploits up their sleeve wasn't going to give a comfortable feeling any time soon.
Today we were pointed by numerous readers towards more news by Mozilla. While it seems to debunk the whole situation somewhat, do reread this one before calling it a hoax. There is a DoS in there and those have shown in the past this nasty habit of sometimes turning around and biting you with code execution (like the setslice thing did for MSIE).
All in all the whole thing obviously was hilarious to present and attend (see the video above), but it still leaves the rest of us with a foul taste.
(*): In a twisted way, you need javascript enabled and sit through the commercial before you can see it.
--
Swa Frantzen -- Section 66
0 Comments
Published: 2006-10-03
Detecting attacks against servers
We all hear of servers getting hit on one of their exposed interfaces and then being used in phishing attacks, spreading malware, feeding warez and basically support all other things the bad guys out there do.
But how can you detect it with little to no fancy means?
Flows are a neat source of information. Basically it's the routers you already have telling you what IP address talked to what other IP address using what port during a relatively short interval. Now collecting flows from a high end router is no little feat, so you will need storage and processing resources but if you can do it, it allows for insights in traffic patterns on a large scale.
E.g. discovering machines scanning for SSH (port tcp/22) next starting to talk on port tcp/4000 to some of those machines is a sign of something spreading to the next server. If those already affected IP addresses are then also relatively high bandwidth and owned by companies that sound like they are in the hosting business, the impact of each and every of these machines getting owned is not insignificant. A shared hosting server can service many hundreds domainnames and each one of those might be adding the newest 0-day exploit towards its visitors.
So keep those applications such as openssl and openssh patched on your servers, they are being scanned for.
--
Swa Frantzen -- Section 66
But how can you detect it with little to no fancy means?
Flows are a neat source of information. Basically it's the routers you already have telling you what IP address talked to what other IP address using what port during a relatively short interval. Now collecting flows from a high end router is no little feat, so you will need storage and processing resources but if you can do it, it allows for insights in traffic patterns on a large scale.
E.g. discovering machines scanning for SSH (port tcp/22) next starting to talk on port tcp/4000 to some of those machines is a sign of something spreading to the next server. If those already affected IP addresses are then also relatively high bandwidth and owned by companies that sound like they are in the hosting business, the impact of each and every of these machines getting owned is not insignificant. A shared hosting server can service many hundreds domainnames and each one of those might be adding the newest 0-day exploit towards its visitors.
So keep those applications such as openssl and openssh patched on your servers, they are being scanned for.
--
Swa Frantzen -- Section 66
0 Comments
Published: 2006-10-02
SANS ISC presentation in Brazil
This is for the brazilian security community. I will give a talk about SANS ISC and security threats in the Colaris (Conferencia Latino Americana de Resposta a Incidentes de Segurança ) Security Conference in Brazil next week as part of the FIRST Technical Colloquium. The Colaris one is open to general public and registration can be done until Oct. 4th. I will be speaking in the second day (Oct 10th) and will be a pleasure to talk to those that want to meet me there. For english information click here .
0 Comments
Published: 2006-10-02
Reader's tip of the day: ratios vs. raw counts
Today, I'd like to present another of our tips of the day (see the whole series here). This one provided by one of our faithful readers, Dai Morgan, in response to my log analysis stories from last month. Here is an excerpt from the e-mail we received:
---------------------------
Jim Clausing, jclausing --at-- isc dot sans dot org
I've recently been dealing with a harvesting incident and needed to identify IP addresses which were running scripts against a web site. If you just look at the high talkers then big customers and gateways can be as big as the bad guys. After some work I found it was useful to look at the ratio of URLs to hits. Normal users hit a wide variety of pages, but the scripts just churn round and round at the same URLs.
Using perl it's easy to pull the source IP address and the URL as you loop through the web server logs. To analyse this data it needs to be loaded into a hash of hashes to keep a count of urls per ip address.
$hash{$ip}{$url}++;
When you've finished the log file loop, start another loop through the hash , you can get the url count as follows
my $url_count = (keys (%{hash{$ip}}));
Then it is just a matter of dividing number of hits by the url count. The bad guys have a higher ratio than normal users. Each site will have slightly different characteristics, so some degree of local tuning will be required. It also helps to strip out any in URL tokens, either in the perl or externally via a 'grep -v'. (or sed/awk, JAC)
I think this technique has other applications, for example looking at signon success and failures. Its also possible to produce summary data of IDS data.
I thought it was an excellent observation that the ratio rather than raw number of hits might provide some very useful data. Dai has provided the script and you can see it here. Dai's explanation and usage docs are here and here, respectively. The explanation doc goes into a lot of detail on what the Perl is actually doing which is quite educational if you aren't a Perl guru. Dai, thanks for sharing the tip and script with our readers.Using perl it's easy to pull the source IP address and the URL as you loop through the web server logs. To analyse this data it needs to be loaded into a hash of hashes to keep a count of urls per ip address.
$hash{$ip}{$url}++;
When you've finished the log file loop, start another loop through the hash , you can get the url count as follows
my $url_count = (keys (%{hash{$ip}}));
Then it is just a matter of dividing number of hits by the url count. The bad guys have a higher ratio than normal users. Each site will have slightly different characteristics, so some degree of local tuning will be required. It also helps to strip out any in URL tokens, either in the perl or externally via a 'grep -v'. (or sed/awk, JAC)
I think this technique has other applications, for example looking at signon success and failures. Its also possible to produce summary data of IDS data.
---------------------------
Jim Clausing, jclausing --at-- isc dot sans dot org
0 Comments
Published: 2006-10-02
Back to green, but the exploits are still running wild
Folks, as is our policy here at the Internet Storm Center, once we feel we've raised awareness of an issue by raising infocon to yellow, we move it back to green (otherwise, with the constant release of exploits of unpatched vulnerabilities, infocon would stay at a heightened level and become as meaningless as the DHS terrorist threat level). Normally, we do this after 24 hours, but in this case, since we didn't raise infocon until Saturday, we felt we should wait until most folks had made it back to work on Monday before going back. That doesn't mean that there is no more risk. Quite to the contrary, until the vulnerabilities are patched, the risk remains high because we know there are many variants of the exploit in the wild as I type this. There were even Metasploit modules released over the weekend, so it doesn't take much talent at this point to create a new exploit. However, we feel that things have leveled off somewhat. We've published pointers to the workarounds in Saturday's story, so there isn't much more that we can do at this point other than remain vigilant.
0 Comments
Published: 2006-10-01
Weekend Vulnerability Roundup
Our readers told us about several vulnerabilities that caught the public's eye this weekend. Here's a brief summary:
Firefox
CNet reported that an unpatched vulnerability in the Firefox JavaScript engine was demonstrated at ToorCon the other day. According to the article:
A Bugtraq listing for this issue states that the cause of the problem is Firefox' failure "to properly sanitize user-supplied input before using it to create new JavaScript objects." (Thanks for the pointers, Juha-Matti.)
We don't have any additional information regarding this vulnerability. In the mean time, we suspect using the NoScript extension to only enable JavaScript for trusted sites might be an effective mitigating measure.
OpenSSH
OpenSSH patched two vulnerabilities in the release of OpenSSH 4.4. (Thanks for letting us know, Hamid.)
One denial-of-service condition was discovered by Tavis Ormandy, and could cause the SSH daemon "to spin until the login grace time expired." This issue affects OpenSSH if it has support for SSH version 1 enabled. (Please migrate to SSH version 2, if you can do so and haven't already.) A proof-of-concept exploit for this vulnerability is floating around. The CVE reference for this vulnerability is CVE-2006-4924.
The other denial-of-service condition was discovered by Mark Dowd. It could, theoretically, lead to remote execution of arbitrary code. This is probably the strongest reason to upgrade to OpenSSH 4.4 sooner, rather than later, although the release also includes some enticing new functionality.
phpMyAdmin
An XSRF/CSRF vulnerability was reported in phpMyAdmin, a web-based front-end for managing MySQL servers. The bug could allow an attacker "to inject arbitrary SQL commands by forcing an authenticated user to follow a crafted link." The issue was fixed in the first release candidate for phpMyAdmin 2.9.1.
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
Firefox
CNet reported that an unpatched vulnerability in the Firefox JavaScript engine was demonstrated at ToorCon the other day. According to the article:
The JavaScript issue appears to be a real vulnerability, Window Snyder, Mozilla's security chief, said after watching a video of the presentation Saturday night. "What they are describing might be a variation on an old attack," she said. "We're going to do some investigating."
A Bugtraq listing for this issue states that the cause of the problem is Firefox' failure "to properly sanitize user-supplied input before using it to create new JavaScript objects." (Thanks for the pointers, Juha-Matti.)
We don't have any additional information regarding this vulnerability. In the mean time, we suspect using the NoScript extension to only enable JavaScript for trusted sites might be an effective mitigating measure.
OpenSSH
OpenSSH patched two vulnerabilities in the release of OpenSSH 4.4. (Thanks for letting us know, Hamid.)
One denial-of-service condition was discovered by Tavis Ormandy, and could cause the SSH daemon "to spin until the login grace time expired." This issue affects OpenSSH if it has support for SSH version 1 enabled. (Please migrate to SSH version 2, if you can do so and haven't already.) A proof-of-concept exploit for this vulnerability is floating around. The CVE reference for this vulnerability is CVE-2006-4924.
The other denial-of-service condition was discovered by Mark Dowd. It could, theoretically, lead to remote execution of arbitrary code. This is probably the strongest reason to upgrade to OpenSSH 4.4 sooner, rather than later, although the release also includes some enticing new functionality.
phpMyAdmin
An XSRF/CSRF vulnerability was reported in phpMyAdmin, a web-based front-end for managing MySQL servers. The bug could allow an attacker "to inject arbitrary SQL commands by forcing an authenticated user to follow a crafted link." The issue was fixed in the first release candidate for phpMyAdmin 2.9.1.
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
0 Comments
Published: 2006-10-01
You know about XSS. How about XSRF/CSRF?
First, a few words about XSS
You know about cross-site scripting (XSS). It's an attack that injects malicious code into a vulnerable application such that the code executes in the victim's application viewer and, therefore, with the victim's session privileges. In most cases, the viewer is a web browser and the malicious code is written in JavaScript. (XSS won over the arguably more correct abbreviation "CSS" because of confusions with an unrelated term Cascading Style Sheets.)
In theory, the victim's viewer could be another application, rather than a web browser. Imagine a vulnerable website that accepts code as input from the attacker and, without properly filtering on input or output, incorporates the code into a spreadsheet that the victim views in Excel. If the attacker could find a way to supply code that Excel will execute, then we have an instance where an XSS attack targeted a non-web browser. I suppose we could call this a cross-application cross-site scripting (XAXSS) attack. (I wouldn't want to suggest the abbreviation "CAXSS" because then people could confuse it with the term Computer Assisted X-ray Screening System.)
XSS has been discussed for a while. Even though the mechanisms of such attacks are well-understood, XSS vulnerabilities continue to plague many web-based applications. SecurityFix mentioned a number of popular sites that have had XSS holes.
Now, a few words about XSRF/CSRF
An attack mechanism that is not as well-known, but is also very effective in targeting web applications is Cross-Site Request Forgeries (CSRF). (It's sometimes abbreviated as XSRF, although I prefer CSRF acronym, despite the potential for confusing it with the acronym for Canadian Sex Research Forum.) I wasn't as familiar with CSRF techniques as I should have been until I came across the Matasano Chargen posting, which pointed to Jeremiah Grossman's blog, which led me to Chris Shiflett's write-up.
A CSRF attack takes advantage of the web application's ability to act according to the HTTP command it receives from the user. Most web applications do that by design, of course. The trick in a CSRF attack is to get the victim's browser to submit the command of attacker's choice. The victim could receive a link to the targeted web application. The link would contain a GET request, which would cause the application to take action when the victim clicks on the link.
For example, clicking on the following link would cause the victim's Google.com preferences to be reset to Irish language:
http://www.google.com/setprefs?hl=ga&submit2=
Save%20Preferences%20&prev=http://www.google.com/search?
q=poodles&q=&submit=Save%20Preferences%20
This link, crafted by Dwayne Litzenberger, takes advantage of a XSRF weakness in Google.com's handling of user preferences. There are many ways in which the victim or his browser can be tricked into "clicking" on a link like this. For instance, the link could be embedded in a concealed iframe of the website the victim is visiting (as Google Blogoscoped pointed out), or it could be embedded into an img tag on the malicious site.
By submitting the request, the user will command the application to take the appropriate action. If the user is already logged in to the vulnerable application, the action could be taken behind the scenes without the victim's knowledge. For instance, a vulnerable banking site could be tricked into transferring the the victim's money out of his account.
Not only GET requests can be used as CSRF attack vectors. POST requests can be used as well; the task would be a bit more complicated than with GET requests, but JavaScript can help implement such an attack without much difficulty.
How to mitigate CSRF risks?
As a web application developer, you can prevent CSRF vulnerabilities by using some difficult-to-predict token that a proper request needs to include, in addition to the session ID that the browser submits automatically via a cookie. The token could be embedded in the form that the application generates for the user. A CSRF link provided by the attacker would not include the token, and would be invalidated.
Alex Stamos commented on the use of such tokens in response to the Matasano Chargen posting on CSRF:
Other ways of mitigating CSRF risks include the use of CAPCHA to check whether the request to an important page was submitted by a human before executing it, keeping the session time-out short, and not relying on cookie-based mechanisms for managing session IDs.
As a user of web applications, consider logging out of sensitive websites, rather than keeping yourself logged in while multi-tasking and browsing the web. Disabling scripting support in your web browser might help to some extent, especially against attacks on POST-driven AJAX application that might be vulnerable to CSRF attacks. However, there are plenty of GET-based CSRF flaws that could be exploited without the use of JavaScript.
For additional information about CSRF, please see Chris Shiflett's write-up, the Cross Site Reference Forgery paper by Jesse Burns, and the Session Riding paper by Thomas Schreiber. (Session Riding is another term for CSRF attacks.)
-- Lenny
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
You know about cross-site scripting (XSS). It's an attack that injects malicious code into a vulnerable application such that the code executes in the victim's application viewer and, therefore, with the victim's session privileges. In most cases, the viewer is a web browser and the malicious code is written in JavaScript. (XSS won over the arguably more correct abbreviation "CSS" because of confusions with an unrelated term Cascading Style Sheets.)
In theory, the victim's viewer could be another application, rather than a web browser. Imagine a vulnerable website that accepts code as input from the attacker and, without properly filtering on input or output, incorporates the code into a spreadsheet that the victim views in Excel. If the attacker could find a way to supply code that Excel will execute, then we have an instance where an XSS attack targeted a non-web browser. I suppose we could call this a cross-application cross-site scripting (XAXSS) attack. (I wouldn't want to suggest the abbreviation "CAXSS" because then people could confuse it with the term Computer Assisted X-ray Screening System.)
XSS has been discussed for a while. Even though the mechanisms of such attacks are well-understood, XSS vulnerabilities continue to plague many web-based applications. SecurityFix mentioned a number of popular sites that have had XSS holes.
Now, a few words about XSRF/CSRF
An attack mechanism that is not as well-known, but is also very effective in targeting web applications is Cross-Site Request Forgeries (CSRF). (It's sometimes abbreviated as XSRF, although I prefer CSRF acronym, despite the potential for confusing it with the acronym for Canadian Sex Research Forum.) I wasn't as familiar with CSRF techniques as I should have been until I came across the Matasano Chargen posting, which pointed to Jeremiah Grossman's blog, which led me to Chris Shiflett's write-up.
A CSRF attack takes advantage of the web application's ability to act according to the HTTP command it receives from the user. Most web applications do that by design, of course. The trick in a CSRF attack is to get the victim's browser to submit the command of attacker's choice. The victim could receive a link to the targeted web application. The link would contain a GET request, which would cause the application to take action when the victim clicks on the link.
For example, clicking on the following link would cause the victim's Google.com preferences to be reset to Irish language:
http://www.google.com/setprefs?hl=ga&submit2=
Save%20Preferences%20&prev=http://www.google.com/search?
q=poodles&q=&submit=Save%20Preferences%20
This link, crafted by Dwayne Litzenberger, takes advantage of a XSRF weakness in Google.com's handling of user preferences. There are many ways in which the victim or his browser can be tricked into "clicking" on a link like this. For instance, the link could be embedded in a concealed iframe of the website the victim is visiting (as Google Blogoscoped pointed out), or it could be embedded into an img tag on the malicious site.
By submitting the request, the user will command the application to take the appropriate action. If the user is already logged in to the vulnerable application, the action could be taken behind the scenes without the victim's knowledge. For instance, a vulnerable banking site could be tricked into transferring the the victim's money out of his account.
Not only GET requests can be used as CSRF attack vectors. POST requests can be used as well; the task would be a bit more complicated than with GET requests, but JavaScript can help implement such an attack without much difficulty.
How to mitigate CSRF risks?
As a web application developer, you can prevent CSRF vulnerabilities by using some difficult-to-predict token that a proper request needs to include, in addition to the session ID that the browser submits automatically via a cookie. The token could be embedded in the form that the application generates for the user. A CSRF link provided by the attacker would not include the token, and would be invalidated.
Alex Stamos commented on the use of such tokens in response to the Matasano Chargen posting on CSRF:
The token you want to add to protect against XSRF really doesn't have a different function than a cookie. The real problem is that there is no such thing as a browser security model, only a cobbled together set of rules written by the developers that championed features inside of Netscape in 1997. The root issue isn't the assertion made by the cookie, it's that some idiot said "Let's make sure the browser automatically attaches cookies to cross-domain script tags and iFrame POSTs. That would be awesome!"
So we're back to hidden fields in forms and big blobs of crypto in GET parameters along with entropic and protected cookies...
So we're back to hidden fields in forms and big blobs of crypto in GET parameters along with entropic and protected cookies...
Other ways of mitigating CSRF risks include the use of CAPCHA to check whether the request to an important page was submitted by a human before executing it, keeping the session time-out short, and not relying on cookie-based mechanisms for managing session IDs.
As a user of web applications, consider logging out of sensitive websites, rather than keeping yourself logged in while multi-tasking and browsing the web. Disabling scripting support in your web browser might help to some extent, especially against attacks on POST-driven AJAX application that might be vulnerable to CSRF attacks. However, there are plenty of GET-based CSRF flaws that could be exploited without the use of JavaScript.
For additional information about CSRF, please see Chris Shiflett's write-up, the Cross Site Reference Forgery paper by Jesse Burns, and the Session Riding paper by Thomas Schreiber. (Session Riding is another term for CSRF attacks.)
-- Lenny
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
0 Comments
Published: 2006-10-01History
On Friday 29th (and for nearly all of our readers past their working day), we saw the WebViewFolderIcon setslice exploit spreading in the wild. We raise our Infocon to Yellow for 24 hours in order to increase the awareness of the problem and call for action. Without further spectacular evolutions we will go back to to Green after 24 hours. We will remind our readers on Monday.
This exploit started in the Month of Browser Bugs on July the 18th as a Denial of Service, however its author released recently a code executing variant of it.
Reason for Yellow
The WebViewFolderIcon setslice exploit is becoming more widespread, so we changed the InfoCon level to yellow to emphasize the need to consider fixes.
If you have not taken measures yet, please consider some emergency fixes to cover the weekend. The exploit is widely known, easy to recreate, and used on more and more websites. The risk of getting hit is increasing significantly and the type of users of the exploit are also not the least dangerous ones. Some of the exploits are believed to be linked to CWS (CoolWebSearch), which is notoriously hard to remove.
(*): It's important to note the difference of your antivirus solutions detecting the exploitation itself (very rare) and detecting the payload of known exploits (common). Only the first will offer real protection against new threats.
(**): There are currently no reports of side effects on other application when stopping this ActiveX control.
--
Swa Frantzen -- Section66
Yellow: WebViewFolderIcon setslice exploit spreading
History
On Friday 29th (and for nearly all of our readers past their working day), we saw the WebViewFolderIcon setslice exploit spreading in the wild. We raise our Infocon to Yellow for 24 hours in order to increase the awareness of the problem and call for action. Without further spectacular evolutions we will go back to to Green after 24 hours. We will remind our readers on Monday. This exploit started in the Month of Browser Bugs on July the 18th as a Denial of Service, however its author released recently a code executing variant of it.
Reason for Yellow
The WebViewFolderIcon setslice exploit is becoming more widespread, so we changed the InfoCon level to yellow to emphasize the need to consider fixes.If you have not taken measures yet, please consider some emergency fixes to cover the weekend. The exploit is widely known, easy to recreate, and used on more and more websites. The risk of getting hit is increasing significantly and the type of users of the exploit are also not the least dangerous ones. Some of the exploits are believed to be linked to CWS (CoolWebSearch), which is notoriously hard to remove.
Actions
We suggest following actions (do them all: a layered approach will work when one of the measures fails):- Update your antivirus software, make sure your vendor has protection for it (*).
- Install following killbits (**):
{844F4806-E8A8-11d2-9652-00C04FC30871}
{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}
{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}
make sure you set both.
You can do this manually as in the Microsoft security advisory, by using Tom Liston's tool, with a GPO, ...
You can do this manually as in the Microsoft security advisory, by using Tom Liston's tool, with a GPO, ...
- Consider asking your users to stop their usage of MSIE, we know it's hard to break an addiction, but you're using the most targeted browser in the world.
References
- Jesper's blog about setting killbit using group policy (GPO)
- Exploit prevention labs blog entry - iframe
- Exploit Prevention labs blog entry - CWS
- SunbeltBlog
- F-Secure blog
- Malicious ActiveX Controls (Oreilly)
- Setting killbits (Microsoft - KB240797)
- Snort VRT sigs: SID 7985 and SID 7986, available since September 1st.
- JS/Exploit-BO.gen - McAfee
- JS_PLOIT.BC - TrendMicro
- Bloodhound.Exploit.83 - Symantec
- Sept. 30th diary
- Sept. 29th diary with tool to set the killbits
- Sept. 28th diary
(*): It's important to note the difference of your antivirus solutions detecting the exploitation itself (very rare) and detecting the payload of known exploits (common). Only the first will offer real protection against new threats.
(**): There are currently no reports of side effects on other application when stopping this ActiveX control.
--
Swa Frantzen -- Section66
0 Comments
Published: 2006-10-01
Perhaps the updater only detects major version changes? In this case, we saw no important security reason to rush with the 1.5_0_09 update. However, we hope that the update mechanism will work as advertised when an important security vulnerability needs to be patched.
(Original diary entry by Koon Tan; update by Lenny Zeltser)
SunJava 1.5.0_09 Released
One of reader shared with us that SunJava 1.5.0_09 has been released. You can get it from:
Java Runtime Environment (JRE) 5.0 Update 9
Release Notes
Test your installation
Update: As of Sun Oct 1 09:00:00 EDT 2006, neither the locally-installed, nor the on-line Java version tester seems to be aware of the 1.5.0_09 update. In one test, the on-line updated reported that 1.5_0_06 is the latest version. Also, Jim Manico reported that in his test, version 1.5_0_08 was reported as being up-to-date as well.
Perhaps the updater only detects major version changes? In this case, we saw no important security reason to rush with the 1.5_0_09 update. However, we hope that the update mechanism will work as advertised when an important security vulnerability needs to be patched.
(Original diary entry by Koon Tan; update by Lenny Zeltser)
0 Comments
0 Comments