-------------------------------------------------------------------------- symantec symantec security response September 2002 Newsletter -------------------------------------------------------------------------- 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 standardise 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. 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. -------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- These are the most reported Viruses, Trojans and Worms to the Symantec Security Response offices during the last month. Top Threats W32.Klez.H@mm - http://www.symantec.com/avcenter/venc/data/w32.klez.h@mm.html JS.Exception.Exploit - http://www.symantec.com/avcenter/venc/data/js.exception.exploit.html Trojan.Horse -http://www.symantec.com/avcenter/venc/data/trojan.horse.html W32.Datom.Worm - http://securityresponse.symantec.com/avcenter/venc/data/w32.datom.worm.html W32.Yaha.F@mm - http://securityresponse.symantec.com/avcenter/venc/data/w32.yaha.f@mm.html W32.Kitro.A.Worm - http://securityresponse.symantec.com/avcenter/venc/data/w32.kitro.a.worm.html W95.Hybris - http://www.symantec.com/avcenter/venc/data/w95.hybris.gen.html W32.Klez.E@mm - http://www.symantec.com/avcenter/venc/data/w32.klez.e@mm.html Backdoor.Trojan - http://securityresponse.symantec.com/avcenter/venc/data/backdoor.trojan.html W95.CIH - http://securityresponse.symantec.com/avcenter/venc/data/cih.html -------------------------------------------------------------------------- Viruses, Worms & Trojans -------------------------------------------------------------------------- Apache_mod_ssl Worm Date:13th Sep 2002 Risk:High (Linux.Slapper.Worm) 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 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 1.0% 14 Jun 2.0% 28 Jun 4.0% 11 Jul 2.0% 21 Jul 3.0% 29 Jul 1.0% 2 Aug 3.0% 15 Aug 2.0% 1 Sep 1.0% 12 Sep 1.0% 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 Date:3rd Sep 2002 Risk:High Platforms Affected Various 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 unauthorised 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 13:04 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 -------------------------------------------------------------------------- Top Reported Viruses, Trojans and Worms Following is a list of the top reported viruses to Symantec's regional offices. -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 -------------------------------------------------------------------------- A list of Virus Hoaxes reported to Symantec http://www.symantec.com/avcenter/hoax.html -------------------------------------------------------------------------- No New Joke Programs reported to Symantec this month. http://www.symantec.com/avcenter/jokes.html -------------------------------------------------------------------------- Symantec Security Response now has Removal Tools for the following threats available on the web site at: http://www.symantec.com/avcenter/tools.list.html -------------------------------------------------------------------------- Symantec Glossary for definitions of viruses, Trojans and worms and more. http://www.symantec.com/avcenter/refa.html -------------------------------------------------------------------------- Contacts -------------------------------------------------------------------------- Correspondence by email to: securitynews@symantec.com no unsubscribe or support emails please. Send virus samples to: avsubmit@symantec.com Newsletter Archive: http://www.symantec.com/avcenter/sarcnewsletters.html -------------------------------------------------------------------------- Subscribe and Unsubscribe -------------------------------------------------------------------------- To be added or removed from the subscription mailing list, please fill out the form available on the Symantec website at: http://www.symantec.com/help/subscribe.html The Symantec Security Response NEwsletter is published periodically by Symantec Corporation. No reprint without permission in writing, in advance. -------------------------------------------------------------------------- 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. ISSN 1444-9994 --------------------------------------------------------------------------