The combination of a known vulnerability in the OpenSSL protocol implementation and a new worm that exploits this vulnerability is wreaking havoc for Apache Web server administrators. In the worst-case scenario, the worm takes over servers and launches a distributed denial of service (DDoS) attack, but the worm can also compromise data on the server.
Details
Thousands of systems have already been compromised by this threat to Linux Apache Web servers due to a vulnerability (VU#102795) found in OpenSSL 0.9.6d or earlier. The worm that exploits this vulnerability is variously known as Slapper, Apache/mod_ssl Worm, bugtrac.c, and linux.slapper. The reason this worm is sometimes designated as bugtrac.c is that the source code is placed in /tmp/.bugtrac.c. Symantec identifies it as the Linux.Slapper.Worm.
According to the CERT Bulletin CA-2002-27, the worm spreads by first scanning TCP port 80 using an invalid HTTP GET request to locate potentially vulnerable systems. Next, the worm attempts to connect to SSL services through TCP port 443, placing the worm code in the system if it succeeds.
The Symantec alert on this vulnerability reports finding the infection on Red Hat, SuSE, Slackwave, Debian, and Mandrake Apache installations. It also identifies the invalid HTTP request as being in this form: ”GET / HTTP/1.1\r\n\r\n.” The report details a typical Apache Server response to the probe and provides more information that may be of interest if you are initiating a forensic analysis.
An infected system will launch a DDoS attack by establishing communication through UDP port 2002. (According to Symantec, the .B variant of the worm uses port 1978, and the .C variant uses 4156.) This attack slows the systems, but also can be used to share data between the newly formed peer-to-peer networks that the worm creates.
To see whether your systems have been compromised, look for traffic on or monitoring of UDP port 2002. You can identify an initial attack by looking for scans on TCP port 80.
Probes will probably be logged as GET/HTTP/1.1, but the presence of this or similar notation is not proof that a system has been compromised. It merely indicates that an attack has been attempted, and completely innocent events may result in similar log entries. The absence of such activity in the log usually means that your system hasn’t been targeted yet.
Applicability
According to CERT, "Versions of OpenSSL servers prior to 0.9.6e and prerelease version 0.9.7-beta2 contain a remotely exploitable buffer overflow vulnerability. This vulnerability can be exploited by a client using a malformed key during the handshake process with an SSL server connection using the SSLv2 communication process."
The OpenSSL vulnerability itself, as opposed to the Slapper worm attack, affects a great many systems, which are listed at VU#102795. Apache is listed here, but the vulnerability potential is marked as unknown, so even the few vendor systems that may still be listed at that site as having an unknown status should be viewed with suspicion. Lotus and Inktomi are the only companies whose products are actually listed on that site as “not vulnerable.”
You'll find a list of all known affected systems, including specific version numbers, here. This huge list includes many Windows systems that are affected by the SSLv2 buffer overflow vulnerability but not by the Slapper Worm attack.
Windows and Macintosh systems, as well as Linux and UNIX systems not hosted on Intel x86 hardware, are not vulnerable to this specific worm attack, but most or all Apache servers running on any platform do have the same underlying SSLv2 flaw unless they use a very recent version of OpenSSL.
Risk level—extreme
This worm can not only compromise a system, allow the attacker to run arbitrary code, and possibly gain root access to the system, but also can establish a peer-to-peer network with other compromised Apache servers and then take over the hardware and use it to launch a DDoS attack against other systems.
Mitigating factors—none
You could consider the fact that this worm doesn’t affect Windows platforms or Macintosh systems as a mitigating factor, but other than that—or the fact that the worm works only on Intel x86 systems—there is little likelihood that an Apache installation will not be vulnerable.
It’s important to remember that the underlying SSLv2 buffer vulnerability seems to apply to every Apache installation using the older version of OpenSSL. This includes some Windows networks. It’s only the Slapper Worm itself that isn’t a threat to Windows.
Fix—patch or disable SSLv2 handshaking
Links to more than 100 updates and patches are available at Security Focus Online. Until you install the patch, you can attempt to disable SSL and/or TLS on your systems, but for many, the only practical fix is to obtain the correct patch for your software. An alternative is to get the latest version of OpenSSL (or at least 0.9.6e), recompile all applications using OpenSSL to support SSL or TLS services, and restart all services.
Symantec has published specific recommendations for temporarily disabling SSL and SSLv2, but these are complex and may not be practical. Patching or obtaining the latest OpenSSL version and recompiling appears to be the best solution and one that is urgently recommended.
Note that merely patching this vulnerability will block the initial attack, but on an already compromised system, the patch won’t remove the peer-to-peer network that has been established by the worm and may not significantly reduce the amount of UDP port 2002 traffic. Because of that, you need to make certain your system wasn’t infected, even if you simply go ahead and apply the patch.
The buffer overflow vulnerability during the SSL2 handshaking process was addressed in OpenSSL code released beginning with 0.9.6e, but you'll want to check for the latest version before you upgrade. See the OpenSSL Advisory for more information.
If your system is infected, you may be able to mitigate damage or, at the very least, prevent the use of your network as the basis of a DDoS attack, by blocking UDP datagram traffic over UDP port 2002 (both source and destination).
You can find basic guidelines for recovering a compromised system at Steps for Recovering from a UNIX or NT System Compromise provided by CERT. This can be very useful, but keep in mind that it isn’t specific to this threat; it is only a checklist of general procedures.
Final word
Remember that some recent court rulings say that if your system is used as the basis of a DDoS attack, particularly one making use of a known vulnerability, you may be liable for damage to the attacked systems if you failed to make the necessary patches. That's just another incentive to get this one patched as soon as possible.
Reply With Quote
