Discover LinuxSecurity Features
Security is an Interactive Sport: Lessons learned from Ramen
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 systemKnow 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!
2. Be proactive
3. Update when necessary
4. Educate yourself
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
|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: https://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
Advisories are not monitored and taken into consideration
Failure to see significance.
Vendor Advisories should be held in high regard and taken seriously
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?
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
Red Hat 6.2 - wu-ftpd
6/23/2000 23:14 : Red Hat: wu-ftpd update
Red Hat 6.2 - nfs-utils
7/17/2000 23:19 : Red Hat: Updated package for nfs-utils available
7/21/2000 13:32 : Red Hat: UPDATE: nfs-utils vulnerability
Red Hat 7.0 - LPRng
09/26/2000 13:28 : Red Hat: 'LPRng' vulnerability
How do I detect and remove the worm?
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
- 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