In confronting malware, there is nothing innovative about the new strains of Klez, Yaha, SirCam and Code Red. Yet all of these worms have demonstrated unprecedented staying power on the Internet despite the existence of patches, anti-virus signatures, personal firewall protection and Intrusion Detection technology. Why are these threats so prolific, and why do new threats gain traction so quickly if all they amount to are retread malicious code?
This paper analyzes the patterns of emerging malware and presents a strategy to assist network and security administrators in addressing “new” yet old threats.
Lessons from the past
It’s easy to dismiss old news and, in the case of Code Red, nobody wants to take a look in the rear view mirror. We want to forget about a malware invasion that required working IT staff overtime, rebuilding and patching machines, and auditing networks to make sure our respective environments were clear. But by examining the history and effects of the Code Red outbreak from its inception in the summer of 2001 up through the present, we can learn a great deal. First and foremost, the experience should remind us not to downplay or give up for dead any malicious code in the wild. Even before it was finished wreaking havoc, Code Red was estimated by the United States Government Accounting Office to have caused upwards of 2.4 billion dollars’ worth of damage with hundreds of thousands of MS Internet Information Servers infected.
Who even remembers that Code Red was thought of at the time to be so severe a threat that it brought Microsoft and the FBI together to brainstorm solutions? The IT industry was fixated on girding for an even greater and more sophisticated malware threat “in the future.” Well, the future is here, and it seems our preventive maintenance procedures haven’t changed all that much. Code Red is back in 2003 and following the same pattern it followed in 2001. Maybe it won’t repeat the scale of menace it once was, but clearly, the concept is applicable to any new threat. For example, it seems like a new Yaha strain emerges every other month. SirCam just won’t go away and Klez retains a stranglehold as the hardiest malware the Internet has ever seen.
In the case of Code Red, a patch eventually materialized – by the time it did, the worm had cascaded across the Internet and the damage was done. An industry collective mindshare was part of the cleanup process, discussing the Code Red problem and how to best prevent it from happening again.
Unfortunately, such wakeup calls have a short shelf life. We are all driven by new priorities every day and if there is no perceived immediate danger, it’s only natural to forge ahead with our workday with tasks requiring immediate attention. Still, this should not preclude maintaining a diligent asset protection program with ongoing patch and change management processes.
Vigilance is key
There is tremendous value in keeping an eye on early warning reports of new malware threats. No matter how retread they may seem, you should these new threats and exploits whenever feasible to insure that your environment is assured to be as least vulnerable as you can possibly make it. This involves more than sending an advisory e-mail to your user-base regarding new threats and where to download a patch.
Ongoing preventive maintenance involves writing procedures based on notes you have taken and information collected in preparation for the day we all hope never arrives – that day of reckoning when your network is ripped to shreds by a malware attack.
Network and security technicians should never overlook seemingly innocuous details. Perhaps you are already familiar with that sinking feeling of discovering a compromised box on your network. That should be motivation enough to maintain a preventive maintenance program; but if that were true, we would not be having a discussion on a re-emergence of Code Red.
The first step in preventive maintenance is adapting a proactive rather than a reactive approach to combating Internet threats. We tend to think the most important details involve retracing what we have already done to address the last outbreak – our machines are patched, we’ve upgraded our gateways and desktops and laptops with the latest anti-virus signatures. What can possibly go wrong?
To find out what could go wrong, let’s look at the pattern of what occurred when Code Red first emerged. The original Code Red attacked an IIS buffer overflow vulnerability that was discovered in July 2001. It took at least one month for the worm author(s) to develop the malware code and send the worm into the wild, and for it for it to gather steam. The impact was not immediate. Some worms have the ability to propagate very rapidly. This is not always the case, though, so don’t be fooled by so-called “low risk” worms. All worms have the potential to become more serious problems.
Are malware techniques becoming more sophisticated? Are the propagation methods any different? Not really. We’re actually looking at the exact same patterns emerging and in many cases through the same exact malware. A few differences exist here and there but by and large, it’s all old hat and we’re just as vulnerable to a network shredding now as we were back in 2001.
The age of polymorphic malware is upon us yet we can expect more of the same: intelligent algorithms identifying IP addresses, backdoors sending broadcasts to other servers with the same vulnerabilities as the infected host. Even if the malware is not successful in locating suitable new hosts, the replication process causes the most harm. This is what bottlenecks the Internet worse than spam.
The experts predicted worms of the future would leave us with no lead-time to respond to new threats after a vulnerability is published. To an extent, that prediction has come true. It’s not uncommon for the speed of saturation to be extraordinarily rapid. In the case of SQL Slammer, for example, it sought targets by way of broadcasting connection requests to random IP addresses in a rapid manner. The worm itself was only applicable to MS SQL Servers; yet the rate of infection was high even though Microsoft had already had a patch available six months prior.
Challenges for IT staff
While it’s not possible to stop every worm outbreak, the record over the last two years clearly shows the need for new approaches for dealing with the proliferation of pattern malware attacks. This is especially true with new strains of malware. There may only be subtle differences among strains but malware is still a sophisticated and intelligent menace. The only way to understand the threat is to see it in action, and to study its behavior in a contained environment.
It’s in the best interest of network and security administrators to test suspicious programs and to gauge their impact on their networks. Take note of patterns in file names associated with particular malware and utilize security software that makes use of MD5. MD5 is an algorithm that produces 128-bit message digests unique to every application. It is computationally infeasible for different applications to have the same MD5 signature. Therefore, MD5 can be used to verify data authenticity and serve as the primary instrument of file comparison and file detection as well as determinant of file corruption and tampering.
If you really want to get serious about malware testing, build a lab, segregate it from your company network and use it to exclusively test malware, spyware and adware. Replicating user experiences in a safe environment is invaluable to your own education and will come into play as you continue to flesh out the priorities of your defense strategies. Having a test environment ready can win the day.
There is no substitute for adopting an ongoing preventive maintenance attitude. The following are some suggestions to use in building or adding to your malware response framework:
- Devise rapid response checklists and workflows that anyone can follow. The hardest part of this is finding the time to keep them updated. Structured documentation goes a long way.
- Have a GHOST server or another image software server at the ready to warehouse the most updated operating systems, service packs and security fixes. Most importantly, make sure the builds are clean. If you suspect an image build is compromised, err on the side of caution and build it again.
- Maintain a secure FTP server with backups of image builds, diagnostic tools, bookmarks, etc. Have everything you need ready for rapid re-deployment in case disaster strikes and your main repository is cut off.
- When you install a patch, do you also test its effectiveness? This is an extra step that most technicians don’t take. It can be time consuming but it’s too easy to place our faith in a vendor to fix a problem by simply installing a patch. As evidenced by the strength of malware, patches sometimes just cover up problems instead of fully resolving them. Second wave vulnerability discoveries are common. It takes more than one layer of shielding to thwart some of the more resilient malware.
- End-users are going to be independent but don’t let that stop you from training and educating them on effective desktop security usage. The more you impress handy tips upon them, the less prone they will be to make mistakes that can impact your network. Familiarity with new security policies must be reinforced.
- Don’t take compromises personally. You’re not going to win every battle. Take careful notes and make the effort to not to repeat the mistakes of the past. Become a stronger technician with each experience.
