patches

Microsoft does not patch vulnerability for supported version of Windows

Last week was the September issue of Microsoft “patch Tuesday”. The September 2009 Microsoft Security Bulletin lists a number of vulnerabilities. Microsoft held the bulletin webcast on Wednesday, September 9, to discuss the vulnerabilities and customer concerns.

One particular bulletin is creating some concerns for Microsoft Windows 2000 users. MS09-048 is a bulletin for a vulnerability to the TCP/IP stack in all current supported versions of Windows. The bulletin describes the vulnerability:

Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution (967723)

This security update resolves several privately reported vulnerabilities in Transmission Control Protocol/Internet Protocol (TCP/IP) processing. The vulnerabilities could allow remote code execution if an attacker sent specially crafted TCP/IP packets over the network to a computer with a listening service. Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.

Even though the bulletin here describes it as potential remote code execution, the webcast focused more on the denial of service threat due to this vulnerability. Unfortunately, Microsoft has chosen to not issue a patch for Windows 2000, even though Windows 2000 is a supported version of Windows with regards to patches and security fixes. ComputerWorld gives a good amount of detail in the article: Microsoft: Patching Windows 2000 ‘infeasible’ Dark Reading published Microsoft, Cisco Issue Defenses For TCP Denial-Of-Service Attack and The Register published Microsoft, Cisco issue patches for newfangled DoS exploit.

I know that there is a reasonable population of Windows 2000 machines in operation at my organization. So, this choice by Microsoft to not issue a patch for this vulnerability raises some concerns. Fortunately the vulnerable population is not publicly exposed and does not have mobile users. The layered defenses we have in place should help mitigate the risks to our environment. However, the risk is still there and the threat needs to be addressed. What other vulnerability will come out that Microsoft chooses not to address in a supported operating system? Are you facing the same situation in your environment? How large is the risk to your environment? What are you doing to address these threats? Why are you doing what you are doing? Share your thoughts with other ITKE readers.

Thanks for reading & let’s continue to be good network citizens.

5 Things we learned from the Conficker non-event

1. The media can take a story about Information Technology and say nothing of substance. What did the 60 Minutes story do for the IT industry? It made Symantec look like they could not effectively address security risks and might even create a sense of false security. I wonder how the CBS IT staff felt when it was revealed that some computers had been compromised. Who was this April Fools joke for? Working in IT at times makes you feel like Rodney Dangerfield - “I don’t get no respect”

Continued »

Simple Conficker Scanner tool released - find the infected machines

A Simple Conficker Scanner (SCS) tool has been released by members of the Honeynet Project. This tool can be run under linux or Windows. It runs a specially crafted RPC query against a host or range of IP addresses. The tool will tell if systems are clean or potentially infected. I am running this tool against hosts on my network and I found a Windows 2000 server apparently infected by Conficker. I am in the process of clean-up on that host. It looks like a couple of things contributed to the infection on this computer:

1. Out of date anti-virus. The antivirus signatures had not been updated since January 2008.

2. Microsoft patches not applied.

Folks, the advice about maintaining up-to-date AV and applying patches is good advice. Heed the warnings and save yourself some troubles of clean-up. I will be having a discussion with my operations team about this situation and make it clear that we should have been prepared for this and this situation should not have arisen.

I am also following the advice from McAfee on Combating the Conficker worm

For more details on how the Conficker worm actually works, follow the links in my blog

The Conficker Analysis - are you ready for April 1?

Thanks for reading. Let’s continue to be good network citizens.

The Conficker Analysis - are you ready for April 1?

There is a feeling in the infosec community that Conficker may change its behavior April 1 and wreak havoc. Headlines have included:

ComputerWorld: Conficker’s next move a mystery to researchers

Computer Reseller News: Conficker Worm to Strike April 1

USA Today: PC security forces face April 1 showdown with Conficker worm

Here’s a great analysis of the Conficker variants and some details to show what to be concerned about.

Take a look at this guidance from Microsoft on Conficker.A and Conficker.B. You need to get the MS08-067 (KB958644) patch rolled out as soon as you can to your machines.

Good luck and if there is a big outbreak on your network, break the internet connection or shutdown the machines until you get them checked & updated. Don’t be afraid to shut things down to get them cleaned up. Then… once you do get things cleaned up and can estimate the time it took… figure out how much you could have saved and look at purchasing a good asset management system like Windows Systems Center Configuration Manager to push out patches and fixes to your devices.

Thanks for reading & let’s continue to be good network citizens.

PROTOCOL analysis vs protocol analysis (with a small p)

Recently we had an issue at a site where outbound messages larger than 1MB were backing up in the outbound message queue. The messages were tagged with a 421 4.4.2 Connection dropped error. This was a puzzling issue since the smart relay host was on the local LAN, and in fact, on the same switch as the Exchange server.  We checked the switch ports and NICs for errors. None were found. We knew messages were successfully coming inbound through this site because the smart relay host was processing hundreds of them per hour (we use regional hubs and this is one of our hub sites).

We first contacted the vendor for the smart relay host appliance and opened a support ticket. No real issues were identified at first review. Since the errors were being reported at the Exchange server, we contacted Microsoft and opened a support ticket. We spent hours testing and changing configuration to another regional smart relay host which seemed to get the messages delivered successfully, but we were still not able to find out what was causing the conversations with the local smart relay host to timeout.

So, we went into deeper debug mode since the application and server event logs did not shed any light on the issue. The Microsoft engineer enabled protocol logging on this particular send connector. The protocol logs did give a little more information on the situation. A snippet is shown below.

2009-01-08T22:36:19.495Z,SendConn,08CB3FF87FA34699,16,exchsvr:20709,relayhost:25,>,RCPT TO:<someone@there.com>,
2009-01-08T22:36:19.495Z,SendConn,08CB3FF87FA34699,17,exchsvr:20709,relayhost:25,<,”250 Requested mail action okay, completed.”,
2009-01-08T22:36:19.589Z,SendConn,08CB3FF87FA34699,18,exchsvr:20709,relayhost:25,>,DATA,
2009-01-08T22:36:19.589Z,SendConn,08CB3FF87FA34699,19,exchsvr:20709,relayhost:25,<,”354 Enter mail, end with “”.”” on a line by itself.”,
2009-01-08T22:36:25.417Z,SendConn,08CB3FF87FA34699,20,exchsvr:20709,relayhost:25,-,,Remote
2009-01-08T22:37:25.431Z,SendConn,08CB3FF87FA346A1,0,,relayhost:25,*,,attempting to connect
2009-01-08T22:37:25.431Z,SendConn,08CB3FF87FA346A1,1,exchsvr:20736,relayhost:25,+,,

The conversation seemed to go fine at the beginning but something was happening at the end. Since this log did not freely give up that information, we used Microsoft’s Network Monitor 3.2 (btw-if you are still using an older version of Network Monitor, you should upgrade to v3.2. It does have some nice features that make it more user friendly - but not as nice as Wireshark) to capture the actual packets between the Exchange server and the smart relay host. We ran Network Monitor directly on the Exchange server.

At this point, we were able to capture the transaction failures. The results were very interesting and a good lesson in packet analysis versus protocol analysis. The packet analysis showed that TCP was working well. Everything at layer 4 and below seemed to be working well. This was a relief. However, it appeared that the actual problem existed at layer 6 & 7. The Exchange server was ending the SMTP (Simple Mail Transport Protocol) conversation with the “.” command (a single dot on a line by itself). The Exchange server was then waiting for the smart relay host to reply with a 250 2.6.0 status message saying the message was successfully queued for delivery. The Exchange server would then reply with a QUIT command and end the SMTP session. Since the smart relay was not responding at all with the expected status message, the SMTP conversation was timing out and messages were building up in the queue.

We found out that there were some patches for the smart relay host so we applied those. Once that was done, the messages seemed to flow normally. The other puzzling thing about this is that we have two other hub sites with the same configuration that are not experiencing this problem. So, sometime today we will be rolling out the patches to those smart relay hosts to prevent this problem from happening at those sites. This issue started out of the blue but seemed coincide with the same time Exchange Server 2007 rollup 5 was applied.

The point of this whole blog posting is that while the TCP protocol was working fine and everything looked good there, the SMTP protcol was not working correctly. It is important for a network engineer to understand networking through all of the OSI layers. You cannot just assume that if things are working well at the lower levels that things at the higher levels will work too. The reverse logic is true also. So, understand the protocols at the lower layers and also the PROTOCOLS at the upper layers if you really want to be an effective troubleshooting expert.

Let’s be good network citizens out there!