As if to make up for the last few 'quiet' weeks, things went mad late last week and over the weekend. Code Red really took off and so has SirCam. While finishing off last week's newsletter, it was obvious from the continual stream of e-mail about it that something was happening with Code Red. After putting the newsletter to bed, I joined the fray of those pondering what the 'something' was and we qiuckly realized that a new variant had been released. Unlike the first version of this worm, this one had an effective random address generator and it was spreading like wildfire. Despite the best estimates of the statisticians being that the Code Red's best typical spread rate was probably between 1.5 and 1.8 hosts per hour per instance of the worm, at the peak of its spread there we so many machines infested and trying to spread the worm that the actual rate on the Internet as a whole was around 2000 new infestations per minute. If you look at the Code Red statistics pages linked below, just remember that they offer 'best case' scenarios and results as the recording methodologies and locations are certain to have not seen evidence of every infestation.
SirCam was also a sleeper. By last (NZ) Friday morning, it was barely showing on the radar, but come the end of the working week in the northen hemisphere (and especially in the US) it took off. This seems likely to be because people spend more time and send and receive more personal e-mail at home and thus away from automatically updated 'protection' of the corporate e-mail and desktop virus scanners...
On the security front, there are a couple of moderately important Windows patches to consider for your systems and a very important remote root vulnerability in most common telnet servers. Also, Unix-ish users of the commercial version of SSH Secure Shell should get an update to fix a remote root exploit in that product.
FBI gets SirCam-ed
Ted Bridis of the Wall Street Journal has reported that an analyst at the FBI' National Infrastructure Protection Center (NIPC) 'accidentally' released the Win32/sirCam virus inside the FBI and it was distributed some external (i.e. non-FBI) addresses before being stopped. As if that is not embarrassing enough for the NIPC, its role, purpose and effectiveness were being heavily questioned last week by a Senate review.
As far as SirCam goes, its potential for distributing documents from its victims' machines has seen all kinds of humourous, embarrassing and otherwise upsetting information leaked all over the net. According to news reports, the FBI claims no sensitive or classified ionformation was leaked during the bureau's SirCam incident, but recipients of some of the Sircam e-mail from the FBI claim to have received documents marked 'official use only'.
Further, in one of the news stories referenced below, it is claimed that it 'isn't uncommon for virus researchers to accidentally infect their own computers'. As a professional antivirus researcher, your newsletter compiler is compeled to take strong issue with that. Any responsible research into the effects of malicious code must be done on test machines and networks isolated from any 'production' systems or from the Internet or other production networks. This is especially true of unknown malicious code and one would hope, doubly-especially true of code known to mass-mail document files from the host machine to all the addresses in that machine's address books plus random e-mail addresses found in web pages in the Internet cache...
FBI Net Center Blasted Again - Wired
How hot is your mail?
Hotmail has again been lambasted for being tardy in upgrading its virus scanners. Apparently the Hotmail virus scanners are normally updated on Thursday nights, meaning that last week Hotmail just missed installing updates that would have detected the onslaught of SirCam. As a result, Hotmail users, many of whom use the service because it offers virus scanning of e-mail, have been exposed to the false sense of security arsing from the belief they are 'protected' by Hotmail's virus scanners. (Of course, the realists among the readership would not be fooled into such an obvious gullibility gap anyway, even if Hotmail updated its virus scanner once a day...)
Hotmail fails to block SirCam worm - The Register
Code Red worm fallout
At least 300,000 individual IIS web servers are known to have been compromised by the second variant of the Code Red worm. Following the posting of last week's newsletter it was determined that there was a second variant of the Code Red worm and this one had a functional random target address generator. This meant it spread much faster and more widely than the original variant. Much has been written and said about this incident, and as your newsletter compiler was involved in some of the discoveries he may not be entirely unbiased about various issues that arose. Anyway, a couple of interesting statistical reports about the worm and its progress are listed below for your edification.
Anyone running an IIS server should again double-check that it has been patched against the MS01-033 vulnerability first mentioned a month or so ago in the newsletter. This applies for all your IIS servers, even if only some of them are exposed to the Internet as access from an Internet-exposed server to the internal network means that your internal server can be compromised by the Internet-connected one.
Statistics and analysis:
Memory leak patches for Microsoft Services For Unix
The telnet and NFS services in Microsoft Services for Unix 2.0 (SFU) both contain memory leaks triggered by network-borne requests. Both can be exploited to deplete system resources in such a way that a machine running either affected service may become unstable or even lock up. Should this occur, the only recourse to recover the machine would be to reboot the machine.
SFU can be installed on both NT 4.0 and Windows 2000 machines and both services are vulnerable on both platforms. Services For Unix 1.0 is not vulnerable to either of these flaws nor is the native telnet server included in NT 4.0 and Windows 2000.
Note: As this issue of the newsletter was being finalized for posting, reports of an unrelated DoS attack against the standard Windows 2000 telent service arrived. This attack is similar to the widespread AYT
vulnerability in BSD-based telnetd code reported in an item later in this newsletter but the SFU telnet is said to not be vulnerable. Microsoft has not responded to these reports as this newsletter is posted and the full extent of the problem in terms of affected versions, is the NT 4.0 version vulnerable as well, etc are not available. Unless you really need it, it would be prudent to disable any Internet-exposed Windows telnet service until this new issue is resolved.
Update fixes memory leak in Terminal Services
NT 4.0 Terminal Server Edition and all flavours of Windows 2000 Server have a memory leak in their Remote Data Protocol (RDP) processesing code. Specially malformed RDP packets cause this code to permanently consume a small amount of server memory. If enough of these malformed packets are received by a vulnerable server, its overall performance and responsiveness will fall dramatically and the server may eventually fail. This would affect all services on the machine, not just terminal services and RDP.
Normal firewall policies would prevent exposure of the RDP ports to the Internet, reducing the likelihood of external attack via this vulnerability. That said, patches are available from the usual place.
Patch for remote root exploit in SSH Secure Shell 3.0.0
The commercial version of SSH Secure Shell 3.0.0 opens a potential remote root vulnerability via accounts with passwords of two or fewer characters. This only affects the Unix-ish versions of the product. More details, and patches, are available in the advisory at SSH's web site.
Note: There has been much confusion about whether this affects the versions of SSH software commonly supplied with Linux and similar operating systems. The answer is, as well as your newsletter compiler can determin, 'No'. It seems the open-source versions of this software are not vulnerable to this problem, but it would be prudent to keep an ear to the ground for contrary indications from the Linux vendors and the Open SSH developers.
telnetd remote buffer overflow on multiple platforms
The CERT/CC has issued an advisory on a recently discovered remotely exploitable buffer obverflow attack against most common telnet servers, or at least against those based on BSD telnetd. The vulnerabilitywas apparently discovered by members of the TESO Security Group and exploit code written by that group lists the discovery date as 9 June 2001. This overflow is being actively exploited on multiple systems and scans for open telnet ports have risen. Anyone running a telnet server, especially one exposed to the Internet should check with their vendors for the status of their telnetd and the availability of patches. Disabling Internet-facing telnet services in the meantime would be prudent, if at all practicable.
Be open to what you consider may be a 'telnet server' -- for example, XCONSOLE on NetWare 5.1 (and perhaps others) is actually implemented in TELNETD.NLM and is reported to be vulnerable. Further, please note that 'invisible' devices such as routers, network switches and hubs and the like can also be open to such vulnerabilities if they have telnet-able management ports. Don't just check with your desktop and server operating system vendors!
- TESO Security Group advisory (published in tar.gz format only)
CERT warns home users need security protection too
One has to wonder if it does not fall in the 'too little, too late' category and certainly has to question whether the intended (or 'necessary') audience will ever see it. Regardless, the CERT/CC has released an advisory pointing out the dangers of undisciplined code use and lack of even the most modest of security measures on typical home computers. With growing numbers of such machines having 'always on' DSL or cable modem Internet connections and the increased bandwidth such connections command over standard telephone system modems, the threat a small army of such machines that are compromised with a remote control DDoS agent or similar malware is quite daunting.
Your newsletter compiler adds that corporate antivirus licenses often include coverage of all your staff's home machines for no extra cost (if yours doesn't, apply the pressure to have it added for free during your next license update period, as many vendors will do this and some offer it up front). Further, as more sites consider rolling out personal firewall software (at least for their laptop using and home-working/ tele-commuting staff), it would be prudent to rachet up the pressure on your chosen firewall vendor to include similar licensing breaks for the non-work home computers as well. If the availability or pricing of such 'extra' licenses becomes the clincher on more personal firewall deals, we will see more vendors offering such options, as has happened in the antivirus marketplace.