symantecTM

symantec security response

ISSN 1444-9994

September 2002 Newsletter


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




Country Spotlight
Brazil

W32.Klez.H@mm
W32.Datom.Worm
VBS.Haptime.A@mm
VBS.Haptime.Gen@mm
JS.Exception.Exploit
Trojan Horse
Hacktool
W32.Klez.E@mm
Backdoor.Trojan
W32.Magistr.39921@mm


Top Global Threats
W32.Klez.H@mm
JS.Exception.Exploit
Trojan Horse
W32.Datom.Worm
W32.Yaha.F@mm
W32.Kitro.A.Worm
W95.Hybris.worm
W32.Klez.E@mm
Backdoor.Trojan
W95.CIH

Asia Pacific
W32.Klez.H@mm
JS.Exception.Exploit
HTML.Redlof.A
W32.Datom.Worm
Trojan Horse
W95.Hybris.worm
W32.Yaha.F@mm
W95.CIH
Hacktool
Backdoor.Trojan

Europe, Middle East & Africa
W32.Klez.H@mm
JS.Exception.Exploit
W32.Kitro.A.Worm
W32.Yaha.F@mm
W32.Klez.E@mm
W32.Datom.Worm
Trojan Horse
W95.Hybris.worm
W95.CIH
Backdoor.Trojan

Japan
W32.Klez.H@mm
W32.Frethem.L@mm

W32.Klez.E@mm
VBS.LoveLetter.A
VBS.LoveLetter.Var
VBS.Network.E
W95.Hybris.worm
W32.Badtrans.B@mm
Trojan Horse
JS.Exception.Exploit

The Americas
W32.Klez.H@mm
JS.Exception.Exploit
Trojan Horse
W32.Datom.Worm
W95.Hybris.worm
W32.Nimda.enc
Backdoor.Trojan
W32.Yaha.F@mm
W32.Magistr.39921@mm
JS.Seeker




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.



September is the anniversary of W32.Nimda so we've included a short retrospective detailing some of the facts and figures that make interesting reading. A year later it's still out there attacking vulnerable systems.

It's interesting that exactly one year later another worm should appear, Linux.Slapper.Worm, which again uses a known exploit and appears to be infecting many more machines than it should. Obviously we (the IT security community) need to continually remind everyone to patch their systems before they go online.

We have an excellent article on securing a PHP installation on Linux with Apache and the usual selection of noteworthy security advisories and virus/worm reports, all in a new format designed to standardize the layout of these articles.

We are always looking for articles on IT security for the newsletter, if you are interested in contributing contact me at the address below. The newsletter currently has a circulation in excess of 260,000 in more than 150 countries. If you want exposure as an IT security writer this is an excellent vehicle for you.

We have introduced a new template for articles this month which means virus and vulnerability descriptions use a common format. This should make things easier to read and the relevant information easier to find.

David Banes.
Editor, securitynews@symantec.com
 

W32.Nimda.A@mm Retrospective

Nimda was discovered on Sept. 18, 2001. During its peak time, Nimda commanded more than 32,000 IP addresses to attack computers located all over the world. More than 1.2 million Nimda attacks took place on Sept. 19, 2001, a day after hitting the Internet.

As the first mass-mailing blended threat, the worm changed the landscape of Internet security. An aggressive, self-replicating worm, Nimda propagates through four different vulnerabilities, causing it to be one of the worst blended threats seen:

E-mail
Web server attacks
Web browsing code
Open network shares

Nimda and CodeRed accounted for 63 percent of attack activity during July 2001 to December 2001 and had a worldwide economic impact of $635 million, per Computer Economics. Unlike CodeRed, Nimda infected a large portion of the Internet with victims ranging from end users who accidentally visited infected Web sites to administrators who failed to eliminate the back doors left by CodeRed a month earlier.

Today, Nimda continues to exploit corporate networks, more than 35,000 Nimda-related attacks still occur everyday, one Symantec sensor received 2,741 Nimda attacks in a single a day as opposed to 76 CodeRed attacks.

Viruses, Worms & Trojans

Apache_mod_ssl Worm
(Linux.Slapper.Worm)
 

Date:

13th Sep 2002   

Risk:

High
Platforms Affected
Linux
   
Components Affected
Red-Hat: Apache 1.3.6, 1 3 9, 1.3.12, 1.3.19, 1.3 20, 1.3 22, 1.3 23, 1.3.26 .
SuSe: Apache 1.3.12, 1.3 17, 1.3 19, 1.3.20, 1.3 23 .
Mandrake: Apache 1.3 14, 1.3.19, 1.3.20, 1.3 23 .
Slackware: Apache 1.3 26 .
Debian: Apache 1.3.26
       
Overview
The Symantec DeepSight Threat Analyst Team has learned of the existence of a new exploit for the OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow vulnerability, targeting Apache Web servers hosted on various Linux platforms.

This also includes a number of peer-to-peer capabilities, which allow it to communicate with other clients, and participate in a Distributed Denial of Service (DDoS) network. To perform these activities, the exploit code listens on UDP port 2002.

The exploit further exhibits worm behavior in that indications are that, once it is setup, it scans and attempts to propagate by infecting other vulnerable systems. It is confirmed through various sources that this worm is in the wild and actively attacking other servers. Over 3500 IP addresses have been recorded as being the source of scanning and associated activity, according to DeepSight Threat Management System data and other sources.
       
Description
The exploit code analysed by the Symantec DeepSight Threat Analyst Team targets the Apache Web server on a number of Linux operating system distributions, including versions of RedHat, Slackware, Debian, SuSE, and Mandrake. By sending a malformed client key, the exploit opens a shell on the client machine, which is then used to upload the exploit source code in a uuencoded format. Using the same shell, it then uudecodes and compiles the source and runs it with an IP address as a parameter. Once certain pre-conditions are met, the exploit appears to scan and target vulnerable machines.
       
Recommendations
The worm can be killed using the Unix "kill" command, using the process id of the ".bugtraq process". The following three files can also be removed:

/tmp/.uubugtraq
/tmp/.bugtraq.c
/tmp/.bugtraq

Only the "/tmp/.bugtraq" file contains an executable binary of the worm. There does not appear to be any instructions allowing the worm to restart in the event of a system reset.

NOTE: If you suspect that a system has been compromised, isolate the infected system(s) quickly to prevent further compromise of enterprise systems. Perform forensic analysis and restore the system from trusted media.
       
Credit
Symantec would like to thank Fernado Nunes for providing a copy of exploit code for analysis.
       
CVE
The Common Vulnerabilities and Exposures (CVE) initiative has assigned the name CAN-2002-0656 to the OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability.
References
More detailed information is available here;
http://securityresponse.symantec.com/avcenter/security/Content/2002.09.13.html


W95.Stoogy.Worm@mm  

Date:

8th Aug 2002   

Risk:

High
Platforms Affected
Windows 95
   
       
Overview
W95.Stoogy.Worm@mm is a mass-mailing worm that emails itself to all email addresses in the Windows address book and to any email addresses found in .htm or .html files. Symantec Security Response has received submissions of this worm that were infected with the W95.Stoogy.6031 virus.
       
Recommendations
Follow the removal instructions available on the web page here;
http://securityresponse.symantec.com/avcenter/venc/data/w95.stoogy.worm@mm.html
       
Threat Metrics
Global Infection breakdown by geographic region and timeline. % of Total
The America's 11.2%
Europe, Middle East, Africa 88.8%
Japan 0%
Asia Pacific 0%
Date
% reports

31 May

14 Jun

28 Jun

11 Jul

21 Jul

29 Jul

2 Aug

15 Aug

1 Sep

12 Sep

1.0%

2.0%

4.0%

2.0% 

3.0%

1.0%

3.0% 

2.0%

1.0%

1.0%

       
Credit
Serghei Sevcenco,
Symantec Security Response, APAC
References
http://securityresponse.symantec.com/avcenter/venc/data/w95.stoogy.worm@mm.html

Security Advisories

Fragmented MIME messages bypass SMTP scanners  

Date:

8th Aug 2002   

Risk:

Low

Platforms Affected
Various
   
Components Affected
Various - Risk level is highly dependent on network configuration and mail client design.

Overview
Researchers from the SecuriTeam at Beyond Security Ltd have identified a method to bypass SMTP scanning engines, including those in antivirus products. Because some mail clients can reassemble fragmented messages (per RFC 2046), an attacker could embed malicious code in a fragmented message that may avoid detection by some SMTP scanners in its fragmented form. When reassembled by the mail client, the malicious code may execute on the client computer.

Description
The SecuriTeam researchers, a branch of Beyond Security Ltd, discovered an issue that, while not new, is now being considered a potential vector for the distribution of malicious code. Under RFC 2046, Multipurpose Internet Mail Extension (MIME) Part Two, there is a little known feature called Message Fragmentation and Reassembly that provides a methodology for email applications to send large emails in smaller message segments (for example, image files).

The only well-known mail client that still lets you segment outgoing email (although not by default) is Microsoft Outlook Express. There may be others. This capability permits users with slow connection speeds or those working within size restrictions imposed by an ISP or corporate mail server to split a large email into smaller sections. When another mail client that adheres to the RFC receives them, the sections are recombined into a single email message on the client computer.

Microsoft email clients recombine incoming fragmented message segments into a single message by default. According to the SecuriTeam analysis, an attacker could hide malicious code disguised as small segments in a multi-sectioned email in such a manner that it would pass through SMTP filtering engines without being detected. When reconstituted on a client computer in its original malicious form, the code could then be used to compromise the targeted computer.

Symantec Response
Symantec has been aware of the potential malicious use of this email feature. As a result, all currently supported Symantec gateway products, by default, block multi-part MIME messages at the gateway. While this is a configurable feature of Symantec gateway products and can be enabled if multi-part email is required, the rejection of segmented messages should be a part of a company's comprehensive security policy to restrict potentially harmful content from the internal network.
       
Credit
Symantec appreciates the coordination of Beyond Security Ltd's SecuriTeam in identifying and providing details of this area of concern as well as working closely with Symantec to properly address the issue.

CVE

The Common Vulnerabilities and Exposures (CVE) initiative has assigned the name CAN-1121 to this issue
 

Multiple Cisco VPN 3000 Vulnerabilities

Risk:

High 
Platforms Affected
Various

Date:

3rd Sep 2002 
Components Affected
Various Cisco VPN 3000 Concentrator's and Cisco VPN 3002 Hardware Client
       
Description
Cisco has reported a number of vulnerabilities in the VPN 3000 series concentrators. These issues affect models 3005, 3015, 3030, 3060, 3080 and the Cisco VPN 3002 Hardware Client.
The nature of these issues varies from disclosure of sensitive information, to denial of service. Some of these issues may allow for remote unauthorized access to the device or the network to occur.
       
Recommendations
Block external access at the network boundary, unless service is required by external parties.
Filter untrusted network traffic at border routers and network firewalls. Deploy network intrusion detection systems to monitor network traffic for malicious activity. Use network intrusion detection systems to identify attempted attacks and their origins. Cisco has made patches available on the basis of specific issues.
       
Credit
Vulnerability announced in a Cisco Security Advisory.
http://www.cisco.com/warp/public/707/vpn3k-multiple-vuln-pub.shtml
References
Source: Cisco 20020903 Cisco VPN 3000 Concentrator Multiple Vulnerabilities
URL: http://online.securityfocus.com/advisories/4446

Security News

PHP Secure Installation

By Dharmendra.T
8/22/2002


As we know that the vulnerabilities in PHP are increasing day by day there comes the need to secure the PHP installation to the highest level. Due to its popularity and its wide usage most of the developers and the administrators will be in trouble if they don't take appropriate steps on security issues during the installation.

First comes the question of choosing the platform for PHP! I have chosen Linux OS and Apache Web server to explain this because of its performance and security aspects. It depends on the developer's need whether he is going to install it as an Apache module or a CGI interpreter. When choosing to build PHP in either of the two ways, you should consider the advantages and drawbacks of each method.

Building as a shared object will mean that you can compile apache separately, and you don't have to recompile everything as you add to, or change PHP. Building PHP into apache staticly means that PHP will load and run faster.

Advantages

  1. Server is more flexible. It can be run as SSL, mod_perl, or php with only one installation.
  2. Servers can be extended with other modules even after installation.
  3. Easier module development and testing as the compiling apache source is not required each time the module is changed.

Disadvantages

  1. DSO is not supported on all platforms.
  2. Startup of the server is 20% slower due to symbol resolving.
  3. The server is approximately 5% slower at execution time under some platforms because position independent code (PIC) sometimes needs complicated assembler tricks for relative addressing which are not necessarily as fast as absolute addressing.
  4. DSO can produce a slightly slower server depending on platform and address resolving.
  5. DSO modules cannot be linked with other DSO modules. For example a.out-based platforms usually don't provide this functionality while ELF-based platforms do. You cannot use the DSO mechanism for all types of modules. This requires either the code be referenced directly through the Apache core, or that you compile Apache with chaining available.
  6. Some platforms cannot force the linker to export all global symbols for linking DSO and Apache executables. This is overcome using the SHARED_CORE feature of Apache and is used by default on such platforms.

Advantages/Disadvantages of compiling PHP as a CGI interpreter

  1. PHP can be compiled as a CGI binary, this allows a user to separate PHP from their web server entirely. Each PHP script that is written will need to contain a statement that points to the path of the PHP binary just as in PERL.

    #!/usr/local/bin/php

  2. CERT Advisory CA-96.11 advises against placing any type of interpreter in the CGI-BIN so it is a good idea to create an isolated directory where PHP can be run.
  3. PHP has built in security measure to prevent malicious attacks of this type as well. In the configuration file for PHP, you can specify the following security features:
    • doc_root This options only works when PHP is installed in Safe Mode. This specifies where the root document directory of PHP is. Scripts outside of this directory will not be interpreted.
    • User_dir This option only works when PHP is installed in Safe Mode. This variable specifies user directories so that scripts outside of this directory cannot be executed.
    • --enable-force-CGI-redirect This allows you to force redirection so that scripts cannot be access directly from the internet. Scripts are redirected to a URL, hiding their full path names.

      http://yoursite/test.php#test.cgi

Building as a CGI Binary means efficiency could be improved by having only a single Perl interpreter running in memory, and passing it the Perl scripts. This is where mod_perl comes in to the picture. It provides a single embedded Perl interpreter within the Apache web server. This can be either statically linked, or as a DSO module.

Some of the advantages of mod_perl are:

  • Able to write Apache modules entirely in Perl.
  • Having a persistent interpreter in the server saves on overheads due to starting a perl interpreter for each script.
  • Offers code caching, where the modules and scripts are being loaded and compiled only once.
  • Increased power and speed.
  • Full access to the web server.
  • Allows customized processing of URI to filename translation, authentication, response generation and logging practically no run-time overhead.
  • Improved performance of %200 - %2000 is apparently obtained.

One of the major drawbacks of a CGI interpreter is when PHP is compiled as a CGI. This means a lack of effieciency in handling high traffic applications.

PHP installation is very easy but installing PHP in a secured manner depends on your platform, installation type selection, and configuration options considered. Whatever method you choose please remember to follow the recommended PHP Configuration Options.

There are various options that can be set in PHP to increase the overall security of your server. We will discuss some of the most common and useful options.

Safe_mode

Safe mode is required for nearly all of the following options, safe mode allows PHP to impose more security restrictions than a normal configuration.

Safe_mode_exec_dir

Setting this variable helps you in forceing PHP to only execute scripts from a specified directory.

Open_basedir

This option allows you to control which directories PHP scripts are allowed to access files from. By default PHP will allow a script to access a file from anywhere so it is recommended that is option be set. By predefining valid directories, data can be protected.

Max_execution_time

This variable enables you to set a maximum execution time that a script can have. If a script runs longer than the allocated execution time, it will be terminated. This option will allow you to prevent attackers from tying up your web server with malicious scripts that could cause denial of service.

Memory_limit

This allows you to control the maximum amount of memory that a script can use. Using this will help to prevent buffer overflows which may lead to more serious threats.

Upload_tmp_dir

This designates where PHP will place files that are being uploaded.

We will discuss both cases here.

PHP AS AN APACHE MODULE:

Here Apache should run as an ordinary user with least privileges. Never run apache as a root user. Try to run Apache in a root jail. If you are running PHP as an Apache Module it is fine, means it provides maximum security. Following are the steps to install and configure the same.

  1. gunzip apache_xxx.tar.gz
  2. tar -xvf apache_xxx.tar
  3. gunzip php-xxx.tar.gz
  4. tar -xvf php-xxx.tar
  5. cd apache_xxx
  6. ./configure --prefix=/www --enable-module=so
  7. make
  8. make install
  9. cd ../php-xxx
  10. ./configure --with-mysql --with-apxs=/www/bin/apxs
  11. make
  12. make install

    If you decide to change your configuration options after installation, you just have to repeat the last three steps. You also have to restart apache for the new module to take effect. A recompile of Apache is not needed.

  13. cp php.ini-dist /usr/local/lib/php.ini

    You can edit your .ini file to set PHP options. If you prefer this file in another location, use --with-config-file-path=/path in step 8.

  14. Edit your httpd.conf or srm.conf file and check that these lines are present and not commented out:

    AddType application/x-httpd-php .php
    LoadModule php4_module libexec/libphp4.so

The path on the right hand side of the LoadModule statement must point to the path of the PHP module on your system. The above statement is correct for the steps shown above.

Different examples of compiling PHP for apache are as follows:

./configure --with-apxs --with-pgsql

This will create a libmodphp4.a library, a mod_php4.c and some accompanying files and copy this into the src/modules/php4 directory in the Apache source tree. Then you compile Apache using --activate-module=src/modules/php4/libphp4.a and the Apache build system will create libphp4.a and link it statically into the httpd binary. The PostgreSQL support is included directly into this httpd binary, so the final result here is a single httpd binary that includes all of Apache and all of PHP.

./configure --with-apache=/path/to/apache_source --with-pgsql=shared
./confgure --enable-debug=no Note: Will not disclose the physical path if some error occurs.
./confgure --enable-safe-mode

Banner Off in apache's configuration file httpd.conf, will not disclose the server's banner information. This makes attacks more difficult for would-be intruders.

Lets consider the second case...

PHP AS A CGI INTERPRETER:

Download the latest version of PHP from http://www.php.net/downloads.php.

  1. Extract the package

    # tar zxvf php-x.x.x.tar.gz Where x.x.x. is the version number.

  2. Change to the PHP directory

    # cd php-x.x.x

  3. Configure it with the various options present

    #./configure --without-apache --without-apxs --enable-force-cgi-redirect

This is to tell PHP that it isis built without Apache support and as a CGI binary. You should get the binary in /usr/local/bin/php.

Now you know why it is compiled with the --enable-force-cgi-redirect option.

The CGI binary isn't compiled within Apache, it runs under a separate process and user. Hence the question comes of placing the CGI binary in a proper location. I would suggest that the CGI binary should be placed outside the web directory, as the risk would be greatly reduced and also make sure that you have enabled safe mode in the php.ini configuration file.

Most commonly attacks arise in the form of getting access to files. Therefore you can prevent the user from calling the CGI binary directly by forcing a CGI to redirect within Apache. For this, just add the following directives in Apache's httpd.conf file:

Action php-script /cgi-bin/php.cgi
AddHandler php-script .php

Now you will see that URL is rewritten

http;//test.com/application/test.htm

into:

http://test.com/cgi-bin/php/application/test.htm

Note: Ensure that you perform permission checks on the application/directory in the process.

This gives you the added benefit of making the URL a little shorter. Lastly, change your doc_root and user_dir options in the php.ini appropriately.

SUMMARY:

Here we have discussed the issues on how best the user can secure PHP installation considering both cases and I hope this will be helpful to all those who are keen in securing PHP and thus eliminating the many of the security risks involved.

Article By:

Dharmendra.T
Linux Security Expert
dharmu@linuxmail.org

 
 
Contacts and Subscriptions:
Correspondence by email to: securitynews@symantec.com, no unsubscribe or support emails please. Follow this link to subscribe or unsubscribe http://securityresponse.symantec.com/avcenter/newsletter_regions/en.html Send virus samples to: avsubmit@symantec.com
Disclaimer- THIS DOCUMENT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY.

This message contains Symantec Corporation's current view of the topics discussed as of the date of this document. The information contained in this message is provided "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, and freedom from infringement. The user assumes the entire risk as to the accuracy and the use of this document. This document may not be distributed for profit.

Symantec and the Symantec logo are U.S. registered trademarks of Symantec Corporation. Other brands and products are trademarks of their respective holder(s). (c) Copyright 2002 Symantec Corporation. All rights reserved. Materials may not be published in other documents without the express, written permission of Symantec Corporation.