My company has offices all over the world, including a software development centre in India. Many of the networks located in such locations are managed independently. I'm not sure why we have continued to let those overseas locations administer their own networks, but the policy has created extra headaches for my team in the past few weeks as we battled Blaster and other worms that exploit vulnerabilities in Windows' remote procedure calls (RPC).
These worms take advantage of a previously discovered vulnerability in the way the Windows operating system handles RPCs, Microsoft 's methodology for allowing its operating system to run programs on a remote server.
When a worm finds a server with an open, vulnerable RPC port (typically Port 135), it creates a buffer-overflow condition to force the server to spawn a shell, typically on Port 4444, and download the worm to the server. The worm then starts the process again.
Not only can a vulnerable system be used to propagate the worm, but a malicious user can also take advantage of this buffer-overflow vulnerability to execute arbitrary commands on a vulnerable server.
We first noticed problems when our network operations centre (NOC) reported an increase in network utilization within our data centre in the US After some investigation, we determined that the source of the problem was TCP/IP traffic with a large range of source and destination IP addresses, all of it destined for Port 135. Our company keeps that port open internally so we can run programs such as Microsoft Exchange, Active Directory and print services.
Externally, however, we block it at our core routers and firewalls. Shortly after the NOC detected the bandwidth problem, we started getting calls from both our Windows NT network administrators and our customers. They reported problems ranging from unauthorized accounts being created to arbitrary reboots, as well as problems when launching Microsoft Word or Excel. The call volume escalated so quickly that our help desk was inundated within an hour.
After some analysis of the Port 135 traffic, we noticed that over 40 % of it was coming from the India development site. The rest came from various IP addresses within the company. We also discovered that a Web server had been compromised and that a Web page had been altered at the India site. This was alarming because all authorised Web servers are supposed to reside in our corporate headquarters.
What's worse, the Web server in question was not only running on a publicly accessible IP address, but it also contained links to locations within our corporate intranet.
After more investigating, we found that the India site had an entire network that was publicly accessible and that the routers were configured to route public IP addresses to our internal IT network. This was a major security problem because a compromise of any of those systems could lead to a breach of our internal infrastructure. In addition, the routers were supporting Port 135 and other port numbers that should have been blocked.
We quickly took control of those network resources and had the remote administrators block all unnecessary ports and shut down their Web servers. Then we turned to the task of containing the damage. That wasn't easy because the worm was running rampant throughout the rest of the organisation.
Our first action was to prevent it from propagating further. The only way to do this was to install filters to block Port 135 at all of the routers and firewalls connected to the infected networks. This was disruptive because it prevented legitimate business functions, such as printer- and file-sharing, from continuing. We reassured users that the delay would be temporary.
Next, we instructed all administrators and infected users to immediately download the appropriate security update and run the worm-removal tool, which we provided on the corporate intranet. We then asked these parties to ensure that they were running the latest virus signatures and to reboot their machines. After giving everyone time to respond, we configured the routers back to their original state and waited to see if the problem was solved.
It has been a few weeks now. We continue to get sporadic bursts of worm activity, but it's not consuming the same amount of man-hours, and we now have a process to deal with this problem. I anticipate that in another week or so we will finally be rid of this miserable pest.
A Good One Gets Away
Shortly after we got the RPC dilemma behind us, we faced another issue: One of our top security engineers resigned. I had a feeling that this was going to happen. He has always been interested in conducting vulnerability assessments.
In other words, the engineer likes to hack, and he had anticipated that he would be given opportunities to do so. During the hiring process, I told him that I didn't think it would be a problem letting him spend some time conducting assessments and penetration testing of our applications and other infrastructure.
Unfortunately, we have had so many other priorities to address that we just couldn't let him focus on this type of work. The problem with small IT security organisations is that we can't compartmentalize job functions. If I had it my way, I would have someone whose sole job would be to do research. I think the latest rash of RPC problems really put him over the edge, and now we're now down a staffer. So next week, once again, I have to start thinking about how to fill an open position. What Do You Think?
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at email@example.com.
Aventail Adds Single Sign-on
Aventail has announced that its Secure Sockets Layer virtual private network (SSL VPN) appliances will integrate with several identity and access management products, including those from Imprivata , Netegrity and RSA Security When used with these products, Seattle-based Aventail's SSL VPN appliances will give users access to all IT resources using a single sign-on (SSO). Adding SSO support will reduce password management problems while improving VPN security, the company says. The changes take effect with Version 6.3 of Aventail's software. Customers with previous versions can upgrade for free by visiting the Aventail Web site.
Atrium Ships Antispam Suite
Atrium Software International in Phoenix has released Camelot Messaging Security Suite 1.0, a spam-filtering tool that uses fuzzy logic, Bayesian algorithms and other techniques to identify and block email spam. The tool intercepts and blocks email before it arrives at the email server. The product, which works with any SMTP-compatible email server, starts at $22 per user for 10 users. A 1,000-user license sells for $2,105.
Security Testing Manual Updated
The Institute for Security and Open Methodologies has announced Release 2.1 of the Open Source Security Testing Methodology Manual. The Barcelona-based organization's manual offers an open-standard method for performing security testing. The latest version includes new laws and best practices, plus a section titled "Rules of Engagement" that addresses ethics and security testing. The free document can be downloaded at www.osstmm.org.