symantecTM

symantec security response

ISSN 1444-9994

May 2003 Newsletter


These are the most common Viruses, Trojans, Worms reported to Symantec Security Response during the last month.


Country Spotlight
Mexico

W32.Klez.H@mm

Trojan Horse

HackTool.PWSteal
W32.Opaserv.Worm
VBS.Loveletter.CV@mm
HTML.Redlof.A
W95.Hybris.worm
W32.Kwbot.F.Worm
W32.Opaserv.E.Worm
W32.Opaserv.G.Worm



Top Global Threats

W32.Klez.H@mm
Trojan Horse

IRC Trojan

HTML.Redlof.A
W32.Sobig.B@mm
JS.Exception.Exploit
W95.Hybris.worm
W32.HLLW.Fizzer@mm
W32.HLLW.Lovgate.G@mm
W32.Nimda.E@mm

Asia Pacific
HTML.Redlof.A
JS.Exception.Exploit

W32.HLLW.Lovgate.G@mm
W32.HLLW.Fizzer@mm
W32.Klez.H@mm
Trojan Horse
W32.Sobig.B@mm
IRC Trojan
W95.Hybris.worm
Backdoor.Trojan

Europe, Middle
East & Africa
W32.Klez.H@mm
HTML.Redlof.A

Trojan Horse
IRC Trojan

W32.Sobig.B@mm
JS.Exception.Exploit

W95.Hybris.worm

W32.HLLW.Fizzer@mm
W32.HLLW.Lovgate.G@mm
W32.Nimda.E@mm

Japan
W32.Klez.H@mm
HTML.Redlof.A
IRC Trojan
W32.HLLW.Fizzer@mm
W32.Klez.E@mm

W95.Hybris.worm

Trojan Horse

W32.HLLW.Lovgate.G@mm
W32.Bugbear@mm
JS.Exception.Exploit

The Americas
W32.Klez.H@mm
Trojan Horse

IRC Trojan

W95.Hybris.worm

W32.Sobig.B@mm
JS.Exception.Exploit
W32.HLLP.Spreda
W32.HLLW.Fizzer@mm
W32.Pinfi
Backdoor.Sdbot



Removal Tools for malicious code are on our web site

A list of Virus Hoaxes
reported to Symantec

A list of Joke Programs
reported to Symantec.

Glossary for definitions of viruses, Trojans and worms and more.

Use Symantec Security Alerts on Your Web Site

 

Note: Participate in the Newsletter Subscriber Survey.

The month of May was an interesting month. I was at the AusCERT Conference in Queensland, Australia (which was again an excellent conference), when W32.HLLW.Fizzer@mm was upgraded to a category 3 triggering the usual flurry of calls and media interest. I'm sure many of you saw this worm in or at the boundary of your organizations networks as it has made number eight in our top ten list this month.

The month was unusual as we had another category 3 with W32.Sobig.B, which was originally called various names by vendors, while we all worked out exactly what it was. This highlights the difficulties in naming threats and reminds me of an earlier commentary on this subject in the April 2002 newsletter concerning W32.FBound.gen@mm.

The feature article for the month is from Brian Hernacki, Architect, Symantec Research Labs and looks at protocol anomaly detection as an alternative or complementary technology to reactive IDS (Intrusion Detection Systems).

The May edition of the newsletter contains a link to a web based questionnaire about this publication. There are only eight questions and I would encourage you to spend 5 minutes to participate so that we can ensure future editions of the Symantec Security Response Newsletter continue to be relevant and of interest to you.

The survey is here...

http://survey.confirmit.com/wi/p161533899/i.asp

Best Regards

David Banes.
Editor, Symantec Security Response Newletter.

Useful Links
Use Symantec Security Alerts on Your Web Site
http://securityresponse.symantec.com/avcenter/cgi-bin/syndicate.cgi

Viruses, Worms & Trojans

W32.HLLW.Fizzer@mm
Aliases: W32/Fizzer@MM [McAfee], Win32.Fizzer [CA], W32/Fizzer-A [Sophos], WORM_FIZZER.A [Trend], Fizzer [F-Secure], Win32/Fizzer.A@mm [RAV], I-Worm.Fizzer [KAV]
Risk: Medium [2]    
Date: May 8th 2003    
Platforms Affected:
Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Me
 

Overview
W32.HLLW.Fizzer@mm is a mass-mailing worm that sends itself to all the contacts in the Windows Address Book and contains a backdoor capability that uses mIRC to communicate with a remote attacker.


It also contains a keylogger and attempts to spread through the KaZaA file-sharing network. This worm will attempt to terminate the processes of various antivirus programs if they are found to be active.

       

Credit
Yana Liu, Symantec Security Response, USA

 
References
http://www.symantec.com/avcenter/venc/data/w32.hllw.fizzer@mm.html
 

W32.Sobig.B@mm

Aliases: W32.HLLW.Mankx@mm, W32/Palyh@MM [McAfee], W32/Palyh-A [Sophos], I-Worm.Palyh [KAV], WORM_PALYH.A [Trend], Win32.Palyh.A [CA]
Risk:Medium [3]    
Date: May 18th 2003    
Platforms Affected
Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Me
 

Overview

W32.Sobig.B@mm is a mass-mailing worm that sends itself to all the email addresses, purporting to have been sent by Microsoft (support@microsoft.com). The worm finds the addresses in the files with the following extensions:

  • .wab
  • .dbx
  • .htm
  • .html
  • .eml
  • .txt

Email Routine Details
The email message has the following characteristics:


From: support@microsoft.com

Subject: The subject line will be one of the following:

  • Your details
  • Approved (Ref: 38446-263)
  • Re: Approved (Ref: 3394-65467)
  • Your password
  • Re: My details
  • Screensaver
  • Cool screensaver
  • Re: Movie
  • Re: My application

Message Body: All information is in the attached file.

Attachment: The attachment name will be one of the following:

  • your_details.pif
  • ref-394755.pif
  • approved.pif
  • password.pif
  • doc_details.pif
  • screen_temp.pif
  • screen_doc.pif
  • movie28.pif
  • application.pif

Refer to the Technical Details section of this writeup for the characteristics of the email message.

NOTES:

  • The worm de-activates on May 31, 2003, and therefore, the last day on which the worm will spread is May 30, 2003.
  • Virus definitions dated prior to May 19, 2003 may detect this threat as W32.HLLW.Mankx@mm.

Symantec Security Response has created a tool to remove W32.Sobig.B@mm

       
Credit
Douglas Knowles, Symantec Security Response, USA
 

References
http://www.symantec.com/avcenter/venc/data/w32.sobig.b@mm.html

 

Security Advisories

Apache Mod_Auth_Any Remote Command Execution Vulnerability
Risk:High
Date:28th April 2003
Platforms Affected
RedHat Enterprise Linux AS 2.1
RedHat Enterprise Linux ES 2.1
RedHat Enterprise Linux WS 2.1
RedHat Linux 7.2
RedHat Linux 7.2 athlon
RedHat Linux 7.2 i386
RedHat Linux 7.2 i586
RedHat Linux 7.2 i686
RedHat Linux 7.2 ia64
RedHat Linux 7.3
RedHat Linux 7.3 i386
RedHat Linux 7.3 i686
RedHat Linux Advanced Work Station 2.1
Components Affected
mod_auth_any mod_auth_any 1.2.2
 
Description
A vulnerability has been discovered in the mod_auth_any Apache module. The problem occurs due to insufficient sanitisiation of user-supplied arguments. As a result, it may be possible for an attacker to execute arbitrary commands, by placing shell metacharacters within an argument.

All commands executed in this manner would be run with the privileges the Apache HTTPD server.
 

References
For more information:
http://www.sarc.com/avcenter/security/Content/7448.html

Source: RedHat RHSA-2003:113-01 Updated mod_auth_any packages available
http://online.securityfocus.com/advisories/5352

Source: mod_auth_any Homepage
http://www.itlab.musc.edu/webNIS/mod_auth_any.html

Source: RHSA-2003-114
http://rhn.redhat.com/errata/RHSA-2003-114.html

Credits
The discovery of this vulnerability has been credited to Daniel Jarboe and Maneesh Sahani.
 

Internet Explorer file:// Request Zone Bypass Vulnerability
Risk:High
Date:9th May 2003

Platforms Affected
Many Windows platforms, see list here;
http://www.sarc.com/avcenter/security/Content/7539.html

 

Components Affected
Microsoft Internet Explorer 5.5 SP2
Microsoft Internet Explorer 5.5 SP1
Microsoft Internet Explorer 5.5
Microsoft Internet Explorer 6.0 SP1
Microsoft Internet Explorer 6.0

 
Description
Internet Explorer is reported to be vulnerable to a zone bypass issue. Allegedly, if Internet Explorer attempts to open a web page containing numerous 'file://' requests each contained in a separate Iframe, the requested file will eventually be executed in the Local Computer zone.
References
For more information:
http://www.sarc.com/avcenter/security/Content/7539.html

Source: Flooding Internet Explorer 6.0.2800 (6.x?) security zones
msg://bugtraq/00f901c31541$65b1e240$6f00a8c0@ultor

Source: Re: Flooding Internet Explorer 6.0.2800 (6.x?) security zones
msg://bugtraq/5.2.1.1.2.20030510004634.00c50d80@195.143.217.90

Source: Technet Security
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/default.asp
Credits
Discovery is credited to "Marek Bialoglowy" <mb@systemintegra.com>
 

Security Feature Article

Avoiding Reactive Intrusion Detection through a Proactive System

By Brian Hernacki, Architect, Symantec Research Labs

Once upon a time network security infrastructure consisted only of a firewall deployed at the perimeter. This worked fairly well when there was limited interaction between internal and external networks, the internal users were well trusted and the value of the network-available assets was limited. However, in recent years things have changed considerably. Network-aware applications and interactions between networks have greatly increased in number. And while access is being granted on a greater scale to these business-critical functions, attackers and their tools have become more sophisticated.

Fortunately, many organizations have augmented their security infrastructures to accommodate these changes. Using a multiplicity of tools including virus detection systems, vulnerability assessment scanners, encryption and intrusion detection systems (IDSs), companies have made an effort to both detect and prevent security threats to their networks. Early versions of these security tools had trouble detecting certain types of threats and were unnecessarily complex IDSs in particular. Such challenges rendered IDSs difficult to deploy, frustrating to use and possible to evade.

To address these shortcomings, several products now support a technique known as anomaly detection. While it is far from new, there has been considerable confusion over exactly what anomaly detection is and how it works.

By definition, an anomaly is something different, abnormal, or not easily classified. The concept of anomaly detection in computer security then is an abnormality observed in something (i.e., a network, host, set of users, etc.) when compared against expected behavior.

One of the key differences between anomaly detection and other forms of detection is that rather than defining what is not allowed, it defines what is allowed. An accurate name for such reactive detection is explicit detection systems. Such systems work well when number of possible bad behaviors is small and slow to change. However, in larger systems with greater variation, these two conditions often do not hold.

Anomaly detection is a more proactive system which relies on having some definition of allowed behavior and then noting when observed behaviors differ. This operates well when it is easier or more efficient to define what is allowed rather than what is not. In these cases, the definition of what is allowed tends to be much shorter. It also tends not to require changes as new problems are created or discovered.

Anomaly detection systems monitor networks for two primary criteria: characteristic and statistical deviations. Characteristic deviations are more qualitative in nature and thus often unable to identify quantitative anomalies. While their counterpart statistical deviations are more quantitative and less likely to pick up on qualitative anomalies.

However, protocol anomaly detection (PAD) systems which are primarily characteristic (qualitative) in nature can also use many of the strict model system attributes to identify anomalies. This type of design takes advantage of the fact that protocols by nature are usually very restrictive. As such, it is possible to construct a very strict model of what should occur and easily note any deviations from it.

What differentiates PAD systems from traditional explicit matching systems (which are based on signatures), is the kind of patterns used. In most cases, PAD also requires some sort of stateful, protocol-aware matching system, without which it can be very prone to false positives.

PAD provides some very powerful capabilities that make it an excellent mechanism for performing network intrusion detection. First and foremost, because it does not require any prior signature to detect certain classes of attacks, it provides the ability to detect attacks before signatures are published. This eliminates the vulnerability window that exists during the first hours or days after an exploit is published.

In addition, PAD is resistant to evasion by polymorphic attacks. Since it does not rely on matching explicit patterns, variations in the attack generally are caught unlike the failure that can occur when the form of the attack changes slightly to escape detection by signature-based systems. And since signature updates are not needed, there is a lower administrative overhead.

There is, however, a caveat to such intrusion detection technology. Because PAD systems are not explicit, they generally provide less specific information than comparable signature matching systems. For example, a PAD system monitoring HTTP traffic may report observing a questionably encoded URL; while a signature system may report the same event by its exact name helping security administrators know which particular threat they are dealing with.

However, through various forms of classification work, a PAD system can be structured such that once anomalies are identified, additional work is performed to more specifically identify the event and provide additional reference information.

PAD provides a very powerful, scalable and maintainable intrusion detection mechanism. It is a core technology around which to build a detection infrastructure and provides unique capabilities, such as detection of zero-day attacks that are not available with other methods. While it is not a panacea to all security needs, it does provide a valid and effective solution to some of the more critical limitations exhibited by current security systems.

Brian Hernacki is an architect in the Symantec Research Labs where he works with a dedicated team to develop future technologies. Hernacki has more than 10 years of experience with computer security and enterprise software development. Additionally, Hernacki has conducted research and commercial product development in a number of security areas including intrusion detection and analysis techniques.

 
 

Contacts and Subscriptions:
Follow this link to subscribe or unsubscribe
http://securityresponse.symantec.com/avcenter/newsletter_regions/en.html

Send virus samples to: avsubmit@symantec.com

Symantec, the Symantec logo, [registered trademarks in alphabetical order] are U.S. registered trademarks of Symantec Corporation. [Common law trademarks in alphabetical order] are trademarks of Symantec Corporation.

Windows, Windows NT, and the Windows logo are registered trademarks of Microsoft Corporation in the United States and other countries. All other brand and product names are trademarks of their respective holder(s). 

Copyright © 2003 Symantec Corporation. All rights reserved. Printed in Australia.March 2003.