[conspire] A bit more on that "worm"

[Rick Moen]

I posted a bit on this to Wednesday's Linux Weekly News item on the subject.
Hoping it's of interest:



The Lupper worm
(Posted Nov 11, 2005 20:15 UTC (Fri) by subscriber rickmoen) 

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
rick at linuxmafia.com 




The Lupper worm
(Posted Nov 12, 2005 0:46 UTC (Sat) by subscriber rickmoen) 

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:

    * The AWstats 6.3 input-validation bug will work only on systems
      with reasonable shells, as the attack uses unvalidated input to the
      "configdir" parameter to run shell commands as the httpd user. (Is
      your httpd's user allowed write access to any interesting files?
      Why?) Therefore, most Windows Web servers running the AWstats CGI
      would escape, for lack of functionality. (Additionally, the
      current iteration of this automated attack seems to need wget.
      Also, you must have AWstats's optional "rawlog" plugin installed
      and exposed to the public.)
    * The WebHints 1.03 input-validation bug likewise invokes a Bourne
      shell with trivial ease (via open() calls using a "!" command on
      the URL line). Thus, again, Windows escapes by lacking basic
      infrastructure. (By the way, the script's author not only doesn't
      have a fix, but has also blocked access to his own pages about the
      thing. Likelihood of him going back and implementing input
      validation is looking slim to none.)
    * The PHPXMLRPC 1.1.1 input validation bug, finally, appears to be
      an exception and truly OS-neutral, since the attack's trick of 
      fooling the parser with nested XML results in ability to run 
      arbitrary PHP, rather than shell sequences. 

It's possible there are OS-dependencies I didn't spot. However, it seems
likely that, in that case, equivalent automated 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
rick at linuxmafia.com 




Don wrote:

> Servers without iptables rules on OUTPUT are missed opportunities to
> detect an infection.  Servers need to talk DNS and get their software
> updates, but other outgoing connections are a sign of trouble.

In the sysadmin's dream world, you could eliminate the strategic error
of "default allow" policies everywhere, and not regret it.  You would
first study what processes need to run, and then (e.g.) put in place
egress filters enabling only the proceses you want outbound access to 
be permitted that access.

That approach might work (and certainly seems like The Right Thing) on
servers without local users.  My own main server has a number of shell 
accounts doled out to friends and relatives.  They might have any number
of reasons for occasionally opening sockets to odd ports elsewhere, 
and I don't prevent them from doing so.

I personally don't put up with upstream entities in mommy mode telling
me I may not connect to particular ports merely because Bad Things rely
on them.  So, I don't impose that locally, either.

Of course, an iptables rule on the OUTPUT chain might reasonably at
least log such activity.

It should be said that my system always lives with the risk of its users
doing dumb things including running things they shouldn't, or their 
ssh private keys being stolen on some remote system.  My policies
therefore assume the possibility of intruders masquerading as legit 
users and of misbehaving local processes started by legit users.  I try
to compensate in a number of ways, including defence in depth, and...
other things.  ;->