The evolution of security: the story of Code Red | Kaspersky official blog

Credit to Author: Enoch Root| Date: Thu, 04 Aug 2022 10:41:27 +0000

Code Red was a worm that targeted Windows-based systems with Microsoft IIS (Internet Information Services for Windows Server) installed. Its story has a happy beginning at least: the spread of the malware was detected right at the start of the outbreak. Code Red discoverers were researchers at eEye Security, who at the time of detection (July 13, 2001) just so happened to be developing a system for finding Microsoft IIS vulnerabilities. All of a sudden, their test server stopped responding. This was followed by a sleepless night, which they spent poring over the system logs looking for the traces of infection. They named the malware after the first object that caught their blurry eye: a can of Mountain Dew Code Red soda.

However, the relatively early detection did little to halt the epidemic. The malware used already infected systems for further attacks, and in a matter of days it had spread worldwide. Later, the Center for Applied Internet Data Analysis (CAIDA) unveiled statistics for July 19, which clearly demonstrated the speed of Code Red’s distribution. According to various sources, more than 300,000 servers were attacked in total.

Spread of the Code Red worm as of July 19, 2001.

Spread of the Code Red worm as of July 19, 2001. Source.

How Code Red works

The internet worm exploited a trivial vulnerability in one of the web server modules, more specifically an extension for data indexing. There was a buffer overflow error in the idq.dll library. The vulnerability was given the identifier MS01-33. The bug is easy to exploit — you just send the server an overly long request like this:

GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a  HTTP/1.0

As a result, the data after the numerous N characters is interpreted as instructions and executed. The entire malicious payload is contained directly in the request; that is, given a vulnerable installation of Microsoft IIS, the system is guaranteed to be infected instantly. The most visible consequence of the infection, quite literally, was the defacement of sites served by the web server. Instead of their usual content, the following stub was displayed:

What a website on a Code Red-infected web server looked like.

What a website on a Code Red-infected web server looked like. Source.

According to Kaspersky, the defacement was not permanent: 10 hours after a successful attack, the worm restored the website’s normal content. Further actions depended on the date. From the 1st to the 19th of each month, the worm propagated itself, sending out malicious requests to random IP addresses. From the 20th to the 27th, various fixed IP addresses were DDoSed, including that of the website of the US presidential administration. From the 28th till the end of the month, Code Red took a not-so-deserved break.

The view from 2022

Similar incidents still occur today, but are usually associated with zero-day vulnerabilities most often detected when investigating an active attack. A typical example is a series of vulnerabilities in the Microsoft Exchange mail server that was actively exploited at the time of detection. More than 30,000 organizations worldwide were affected, and mail service administrators in many companies found themselves needing to install a patch “yesterday” and having to conduct an audit in case infection had already occurred.

This example shows not only that attacks have become far more sophisticated, but also that defenses have made some progress. Code Red exploited not a zero-day vulnerability but one that was detected and closed a month before the epidemic. But back then, the slowness of installing updates, the lack of tools for automatic installation, and low awareness of corporate users all played a role. Another important difference between Code Red and modern-day attacks is the lack of monetization. Nowadays, a hack of a vulnerable company server would be followed inevitably by data theft or encryption plus a ransom demand. Also, today’s cybercriminals rarely deface hacked sites; on the contrary, they are more likely to take all possible steps to hide their footprints in the company’s IT infrastructure.

A bitter lesson

Code Red, it has to be said, departed the scene pretty quickly. August 2001 saw the appearance of a slightly modified version, Code Red II, able to infect systems that had already been “visited” by the first variant of the worm. Generally speaking, though, in the early 2000s there were many other attacks with similar scenarios. Already in September 2001, we saw the Nimda worm epidemic, which likewise tapped long-patched vulnerabilities in Microsoft IIS. In 2003, the Blaster worm spread far and wide. At long last, word got round that patches for critical vulnerabilities in corporate software must be installed as quickly as possible: when an update is released, cybercriminals carefully study it and begin to exploit the vulnerability straight away, hoping that some users still haven’t patched it. But even now, the problem cannot be said to have been solved. There are more recent examples, such as the 2017 WannaCry attack.

What can be said, however, is that Code Red and numerous other malicious programs responsible for infecting hundreds of thousands of systems around the globe helped shape the corporate security approaches that guide us today. Unlike 21 years ago, we are now wholly dependent on IT systems for everything from communications to payments, not to mention critical infrastructure. We have learned how to defend against cyberattacks, but have yet to produce a silver bullet for all business problems in cyberspace. As cybersecurity inevitably evolves, we must recognize that perfect security is not a fixed state of things but a continuous struggle.


https://blog.kaspersky.com/feed/