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.
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.
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.
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.
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
Server is more flexible. It can be run as SSL, mod_perl, or php with only one installation.
Servers can be extended with other modules even after installation.
Easier module development and testing as the compiling apache source is not required each
time the module is changed.
Disadvantages
DSO is not supported on all platforms.
Startup of the server is 20% slower due to symbol resolving.
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.
DSO can produce a slightly slower server depending on platform and address resolving.
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.
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
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
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.
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.
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.
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.
Edit your httpd.conf or srm.conf file and check that these lines are present and not commented
out:
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.
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:
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.
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.