[ale] brochure 2000=VIRUS

[Transam@cavu.com]

phrostie <pfrostie at yahoo.com> wrote:

> been there, got one, but mine was called "rolodex.doc.bat"

...

I didn't know at the early time when I sent the original email all of
the details.  Here are some more details on this virus, the Code Red worm,
and some Linux security issues:

This virus seems to have been spread rather extensively and supposedly
will trash one's hard disk after spreading to the systems listed in
one's M$ address book.  Linux and Unix are immune.

--Bob


Some additional information on the SirCam windows virus is at:

http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_SIRCAM.A

Thanks to:

Cabezon Aurélien
http://www.iSecureLabs.com
======================================================================
The following is some information on the recent Code Red worm that
infects Windows systems via email and a user's address book.

From: "Marc Maiffret" <marc at eeye.com>
To: ale at ale.org
To: "BUGTRAQ" <BUGTRAQ at securityfocus.com>
Subject: Tool released to scan for possible CodeRed infected servers
Date: Fri, 20 Jul 2001 16:27:56 -0700

In an effort to help administrators find all systems within their network
that are vulnerable to the .ida buffer overflow attack, which the "Code Red"
worm is using to spread itself, we have decided to release a free tool named
CodeRed Scanner. It can scan a range of IP addresses and report back any IP
addresses which are vulnerable to the .ida attack, and susceptible to the
"Code Red" worm.

The program will allow you to either scan a single IP address or a Class C
(254) set of IP addresses. It will output a list of IP addresses which can
be double clicked on to get information on how to patch your system from the
.ida vulnerability and to eradicate the "Code Red" worm from your system.
Also this is a program you get to install on your own computer so you do not
have to go to a website and register to scan 1 IP address at a time etc...
like some of the other scanners we have seen that scan for the CodeRed Worm.

We are able to remotely scan IP addresses (web servers) for the .ida
vulnerability (CodeRed Worm) without having to test your system via a buffer
overflow, which can bring your web server down. Instead we use a technique
which we have taken from Retina that allows CodeRed Scanner the ability to
test a web server remotely, without causing any harm to it. This allows us
to see if the .ida patch is installed or not (if the server is infected or
susceptible to infection).

To download CodeRed Scanner go to:
http://www.eeye.com/html/Research/Tools/codered.html

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
======================================================================
Date: Fri, 20 Jul 2001 15:06:39 -0500
From: John Kristoff <jtk at depaul.edu>
To: ale at ale.org
Subject: Code Red host list

The following is a list of about 11,000 host IPs that are thought to be
or were infected by the recent Code Red worm.  I hope this is helpful. 
If I was watching more closely at the time I'm sure the list would be
significantly larger.

http://condor.depaul.edu/~jkristof/codered-hosts.txt

This has been blind carbon copied to multiple recipients in order to
ensure that it reaches all interested parties.  Apologies to those that
may receive this note more than once.

John
- - ----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see:

http://aris.securityfocus.com
======================================================================
From: "Stephanie Thomas" <customer.service at ssh.com>
To: ale at ale.org
To: <bugtraq at securityfocus.com>
Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Date: Fri, 20 Jul 2001 17:34:02 -0700

- - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Secure Shell Community,

A potential remote root exploit has been discovered 
in SSH Secure Shell 3.0.0, for Unix only, concerning 
accounts with password fields consisting of two or 
fewer characters. Unauthorized users could potentially 
log in to these accounts using any password, including 
an empty password.  This affects SSH Secure Shell 3.0.0
for Unix only.  This is a problem with password 
authentication to the sshd2 daemon.  The SSH Secure 
Shell client binaries (located by default in 
/usr/local/bin) are not affected.   

SSH Secure Shell 3.0.1 fixes this problem.

Please note that if using a form of authentication 
other than password, AND password authentication 
is disabled, you are NOT VULNERABLE to this issue. 

PLATFORMS IMPACTED: 
  
Red Hat Linux 6.1 thru 7.1 
Solaris 2.6 thru 2.8 
HP-UX 10.20 
HP-UX 11.00 
Caldera Linux 2.4 
Suse Linux 6.4 thru 7.0 

Please note that other platforms not listed here 
may also be vulnerable. 

PLATFORMS NOT IMPACTED: 

Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable. 

Please note that other platforms not listed here 
may also be immune.

SCOPE

Some stock machines which have default locked accounts 
running SSH Secure Shell 3.0 are vulnerable to 
arbitrary logins.  This is a serious problem with 
Solaris, for example, which uses the sequence "NP" to 
indicate locked administrative accounts such as "lp", 
"adm", "bin" etc.  Some Linux machines which have 
accounts with !! in the etc/passwd or /etc/shadow such 
as xfs or gdm are also vulnerable. Since it is relatively 
easy to become root after gaining access to certain 
accounts, we consider this a potential root exploit.

DETAILED DESCRIPTION

During password authentication, if the field containing 
the encrypted password in /etc/shadow, /etc/password, 
etc. is two or less characters long, SSH 3.0.0 will 
allow anyone to access that account with ANY password.
The bug is in the code that compares the result of calling 
crypt(pw, salt) with the value of the encrypted password 
in the /etc/shadow (or /etc/password) file. SSH Secure Shell 
Server 3.0.0 does a bounded string compare bounded to the 
length of the value stored in aforementioned file (2 
characters in this case) against the return value of 
crypt(). The return value of crypt() is 13 characters, 
with the first two characters being the salt value itself.  
The salt value used is the first two characters of the 
encrypted password in /etc/shadow (or /etc/password). A 
2 character string comparison between the 2 character 
encrypted password in /etc/shadow, and the 13 character 
crypt() return value, whose first two characters ARE the 
2 characters from the password in /etc/shadow. The strings 
match, and the 3.0.0 daemon then accepts the password, no 
matter what is input. 

SOLUTIONS 

Preferred 

Immediately upgrade to SSH Secure Shell 3.0.1 
which will be available on our e-commerce site 
http://commerce.ssh.com shortly, and is available 
on the ftp site now - ftp://ftp.ssh.com/pub/ssh
A patch for 3.0.0 source code is also available there.

Alternative work-arounds 
  
Disable password authentication to the SSH Secure Shell 
daemon (sshd2) in the /etc/ssh2/sshd2_config and use 
another form of authentication such as public key, 
SecurID, Kerberos, certificates, Smart Cards, or 
hostbased to authenticate your users.  These alternative 
authentication methods are NOT VULNERABLE.  Please see 
our SSH Secure Shell support web pages for more 
information on how to enable these authentication methods. 

 OR 

If you cannot disable password authentication fully, 
limit access to the sshd2 daemon to allow only users 
with entries in the /etc/passwd and /etc/shadow which 
exceed two characters.  This can be done using the 
AllowUsers, AllowGroups, DenyUsers, and DenyGroups 
keywords in the /etc/ssh2/sshd2_config file.  See 
our SSH Secure Shell support web pages 
http://www.ssh.com/support/ssh and man sshd2_config 
for more information. 

 OR 

Assign a valid password for each account.  Because 
it is possible that assigning a password to some 
system accounts could cause problems on some operating 
systems, this work-around is limited and is provided 
only as a last-resort alternative.

 OR

Use the following patch in the source code:

"""
File /lib/sshsession/sshunixuser.c
Function ssh_user_validate_local_password
Location near line 953, before 
/*Authentication is accepted if the encrypted 
passwords are identical. */

Add lines

if (strlen(correct_passwd) < 13)
return FALSE;

"" 

We apologize for any inconvenience this may cause. 
SSH Communications Security takes security issues very 
seriously, and a CERT advisory and submission to Bugtraq 
regarding this issue have been submitted.  Please make 
every effort to ensure that your systems are protected 
using one of the above methods as quickly as possible.  
As this information becomes widely known, your systems could 
be at even greater risk if appropriate measures are not taken. 

SSH is fully committed to serving and supporting our users 
and products. While we may not be able to address each request
for information on this issue individually, we will 
make publicly available any relevant information possible 
which addresses your questions and concerns.

CREDITS

This vulnerability was found and reported by an 
anonymous system administrator at the Helsinki University 
of Technology and by Andrew Newman of Yale University.

- - -----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.1

iQA/AwUBO1jNq9BQTPJLnwPSEQKmMQCeIOd7B30wubtA3p3hrAK61dZhn08AoIx+
kAzWH6o/mdL81W9TC4tJINgp
=2BQq
- - -----END PGP SIGNATURE-----
======================================================================
Many Linux systems continue to be vulnerable to crackers because they
run old buggy versions of named or Sendmail.  All recent versions of
named can (and should) be invoked with the -u flag to cause them to
run a non-root user (that is not used for any other purpose).

Old versions of Sendmail also are vulnerable to being used as a spam
reflector.

Some people still run portmap, nfs and friends, rsh and friends, or
telnetd on systems accessible from the Internet.  This should not be done.

The line printer daemon insists on listening on TCP port 515 and runs as
root, inviting disaster.  Every system accessible from the Internet
should have this port blocked by IP Chains, IP Tables, or an upstream
firewall.

Hardening systems, periodic security audits, log file monitoring, tracking
and installing needed security patches immediately, an effective firewall,
choosing a secure platform to begin with, and other measures discussed
in the book are critical to maintaining system and network security.

Bob Toxen
transam at cavu.com                       [Bob's ALE Bulk email]
bob at cavu.com                           [Please use for email to me]
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.