This article outlines the importance of monitoring vendor advisories and applying appropriate
software patches when necessary. It uses the Ramen epidemic as an example showing the possible effects of poor system administration.
Whether you're a security professional,
system administrator, or average Linux user you've probably already heard
many of the stories surrounding the recent outbreak of the Ramen worm.
If you haven't heard the details, or would like an overview of the specifics,
you may want to skip down to the middle of this paper. I have answered
some of the most common questions and provided specific information on how to
prevent and disable the worm as well as how it works. Ramen does not only exploit
vulnerabilities in wu-ftpd, nfs, and LRPng, it takes advantage of lazy/inattentive/irresponsible/naive
system administrators.
In this paper I answer many questions.
What actually enabled the Ramen worm to be so successful? Who's
responsible? What knowledge can we take from this situation?
Maintaining a secure network can
be broken up into 4 abstract parts:
1. Know your system
2. Be proactive
3. Update when necessary
4. Educate yourself
Know your system - One of the
most important factors of maintaining a system is knowing what you have.
This often means reading documentation completely before installing, understanding
all configuration options, and being aware of any risk that a particular package
may incur. If you do not have a specific need for a package or service,
then by all means remove it. Packages just lying around should be considered
a threat and removed immediately. An administrator should be aware
of all executables, configuration files, processes, users, and normal system operation.
Know your system intimately!
The Ramen worm is a great example
showing how package negligence can lead to vulnerabilities. This particular
worm attacks nfs, wu-ftpd, and LPRng, but it might as well have been a samba
exploit in a general case. The specific vulnerable packages do not matter, it
is the attitude of the administrator. I would be willing to bet that in
most cases where there was a compromise the vulnerable services were not in
use. Most users install Linux using an "out-of-the-box" configuration
leaving the door wide open to compromise. Most distributions require a
small bit of configuration before actually being ready for the Internet.
Too often, unskilled users put boxes up not knowing what kind of significant
effect it can have. This is a problem that will continue until vendors
put more emphasis on a secure default configuration. Many times users will ignore
warnings given simply because they do not maintain a high-profile server or
have a connection faster than dialup, cable, or DSL. Proper precautions should
still be taken because privately owned systems are often used as stepping stones
to attack larger servers. By not updating regularly, you are contributing to
the problem.
| Be proactive
- Having a cut down Linux box is a good first step, but that does not
eliminate the problem. It is necessary to monitor vendor advisories
from the packages and distributions that you are using. Again, knowing
your system is helpful. What packages do you have installed?
Many system administrators have trouble managing advisories, keeping up
with the lists, and following through. We have tried to make this
process easier for you. For those of you who are not aware, we release
a weekly vulnerability newsletter "Linux
Advisory Watch." Linux Advisory Watch is comprehensive newsletter
that outlines the security vulnerabilities that have been announced throughout
the week. It includes pointers to updated packages and descriptions
of each vulnerability. |
|
Update when necessary - If
no steps are taken to fix known problems then the system is still vulnerable.
Often, administrators will read new vendor advisories, but then get distracted
performing other tasks. The system then sits idle and remains vulnerable
until a new release of the distribution is installed. The process repeats
itself. Advisories are often numerous and annoying. This is why
it is necessary to have the minimum amount of packages installed. It should
be your sole purpose in life to make sure that vulnerable packages are patched
as soon as an advisory is released. If you are/were vulnerable to the
Ramen worm, a general updating scheme could have eliminated that risk.
Advisories dating back to June 2000 provided fixes to today's Ramen worm problem.
Who's fault it that? If not this time, it will be the next. Staying
current is extremely important.
At times there may be situations
when a patch is not available and you want to limit the impact of a vulnerability
that may arise. Something as simple as:
ipchains -A input -i eth0
-p tcp -s 0/0 -d 192.168.1.1 21 -j DENY
ipchains -A input -i eth0
-p tcp -s 0/0 -d 192.168.1.1 23 -j DENY
can be used to restrict
access to telnet and ftp from the external interface. Although beyond the scope
of this paper, ipchains should play an important roll in your configuration.
Educate yourself - When you
have time on your hands, it can be best spent reading articles and white papers
that describe how to build and maintain secure networks. Where can you
find good papers? Each week, in the "Linux Security Week" newsletter,
LinuxSecurity.com outlines the best two or three articles/papers released.
An archive of releases can be found here: http://www.linuxsecurity.com/news/articles_forums-1.html
Education will help you avoid falling into problems that other people have faced.
Security requires experience and often a bit of creativity.
What else can be done? Testing your
system often reveals vulnerabilities that you may not have been aware of. Here
is an excellent paper on NMAP that
can get you started. Red Hat users may want to consider using up2date (Red
Hat Update Agent), a program that initiates an interactive process to easy apply
the appropriate RPMSs to a system.
The Ramen worm was successful
because of a few factors.
Lack of system
knowledge
Systems are installed using all default
values not giving the configuration any thought
Passive Administrators
Advisories are not monitored and
taken into consideration
Failure to see significance.
Vendor Advisories should
be held in high regard and taken seriously
Education
Security requires constant learning.
How can you prepare for new vulnerabilities?
What is the Ramen Worm?
The 'Ramen worm' is a set of scripts
written to propagate by compromising vulnerable systems, downloading itself,
and then using the compromised host to search for other systems to attack.
After the system is compromised, the script replaces all files named 'index.html'
with the text "Hackers looooooooooove noodles" and a picture touting their favorite
snack, "Top Ramen." After the damage has taken place the scripts seemingly
close the vulnerabilities (only disable FTP) to prevent the server from
future Ramen attacks or looting script kiddies.
What systems are vulnerable?
Red Hat 6.2 systems not patched
for wu-ftp for nfs vulnerabilities and Red Hat 7.0 systems not patched for LPRng
are vulnerable. Although Red Hat is the only distribution specifically
mentioned, other distributions (especially those based on Red Hat) that distribute
these packages are also at risk.
What exactly does the Ramen
Worm do?
do {
Initially after a system has been
compromised, the Ramen worm starts scanning for systems with port 21 (common
port used for FTP) open. The scripts then grab the FTP banner and use
the version and date information to determine which vulnerability would
most likely exist. After a system is exploited it creates a directory
"/usr/src/.poop" and requests a copy of itself (ramen.tgz) for download through
its own port 27374. It then changes every instance of "index.html" found
on the system.
} while (NETWORK_CONNECTION);
How can it be prevented?
After reading the text above, you
should probably already know the answer to this question. In short,
get to know your system, remove what you don't use, and update what you do use.
Currently the Ramen worm targets Red Hat systems running LPRng, wu-ftp, and
nfs.
Red Hat 6.2 - wu-ftpd
6/23/2000 23:14
: Red Hat: wu-ftpd update
http://www.linuxsecurity.com/advisories/redhat_advisory-500.html
rpm -Uvh ftp://updates.Red Hat.com/6.2/i386/wu-ftpd-2.6.0-14.6x.i386.rpm
Red Hat 6.2 - nfs-utils
7/17/2000 23:19
: Red Hat: Updated package for nfs-utils available
http://www.linuxsecurity.com/advisories/redhat_advisory-562.html
rpm -Uvh ftp://updates.Red Hat.com/6.2/i386/nfs-utils-0.1.9.1-1.i386.rpm
7/21/2000 13:32 : Red Hat:
UPDATE: nfs-utils vulnerability
http://www.linuxsecurity.com/advisories/redhat_advisory-572.html
Red Hat 7.0 - LPRng
09/26/2000 13:28
: Red Hat: 'LPRng' vulnerability
http://www.linuxsecurity.com/advisories/redhat_advisory-753.html
rpm -Uvh ftp://updates.Red Hat.com/7.0/i386/LPRng-3.6.24-2.i386.rpm
How do I detect and remove
the worm?
Max
Vision has written an excellent paper that describes the makeup of the Ramen
Worm in great detail. It is titled "Ramen Internet Worm Analysis" and is located
here: http://whitehats.com/library/worms/ramen/
He offers a detailed section
on removal and incident recovery. Here is the method that he outlines
for removal. If you have any questions or have the curiosity to want
to know how the scripts actually work I would highly recommend reading
his paper.
-
If you want to allow anonymous
FTP, then remove "ftp" and "anonymous" from /etc/ftpusers
-
If you use wu-ftpd then upgrade
to the latest version from the Red Hat errata web site
-
If you use NFS then upgrade
to the latest version from the Red Hat errata web site
-
If you use LPRng then upgrade
to the latest version from the Red Hat errata web site
-
Remove "/usr/src/.poop/start*.sh"
from /etc/rc.d/rc.sysinit
-
Delete the /usr/src/.poop directory
containing worm files
-
Delete /tmp/ramen.tgz
-
Delete /sbin/asp
-
Change /etc/xinetd.conf or /etc/inetd
to no include /sbin/asp
-
Red Hat 6.2: Remove "asp stream
tcp nowait root" from /etc/inetd.conf
-
Red Hat 7.0: Remove asp entry
from /etc/xinetd.conf
-
Restore /etc/hosts.deny unless
you didn't use tcp wrappers
-
Restore any replaced index.html
files with originals from backup
-
Reboot the system to kill active
worm daemons
Only registered users can write comments.
Please login or register. Powered by AkoComment! |
