Joomla site - Hacked

[Raul Dias]

Its because the file is called directly and not protected by the first line defined( '_VALID_MOS' ) or die( 'Restricted access' );

So to make it clear:

If defined( '_VALID_MOS' ) or die( 'Restricted access' );  is missing
RG=On or Emulation On
and than a call like this:

include( $mosConfig_absolute_path . '/components/com_yourcomponent/yourcomponent.class.php' );

Opens the door.

This is what trying to find out.  How exactly was that possible.

One simple/basic mistake "took down" the whole server.

In case anyone wants to inspect if your installation has other components with the same problem, you can run this command to get the places to start looking for it:

Code Select Expand

for i in `find -name '*php'`;do grep -q '_VALID_MOS' $i;if [ $? == 1 ]; then echo $i;fi ;done
With this I spoted other vulnerable 3rdp components in my own instalation.

Doing a search in the Google Code Search engine, showed that a lot components might need to be reviewed. (no I am not showing the search string here for obvious reasons).

Note that Mambo components might be in the same situation.

[Praedator]

Well the thing to know now is what happend on j!.org as there where the files protected by defined( '_VALID_MOS' ) or die( 'Restricted access' ); special for the shop so a direct call was not posible, there must be an other whole, thats why i ask now the Team other there to give more infos.

[afonic]

I think (correct me if I am wrong) that it didn't took down the whole server, just did enough to deface the site.

Also (again I am not sure) if Joomla's .htaccess file was working even without '_VALID_MOS' in the component the hack would not be possible, to not mention mod_security that would deny any reference of "wget" for example in the URL.

[Raul Dias]

I think (correct me if I am wrong) that it didn't took down the whole server, just did enough to deface the site.

Right, thats why I used quotes.
s/took down the whole server/let the websites be compromised/g;

Also (again I am not sure) if Joomla's .htaccess file was working even without '_VALID_MOS' in the component the hack would not be possible, to not mention mod_security that would deny any reference of "wget" for example in the URL.

It wasnt working.

But the point to make is that relying on 3rdp stuff to resolve is not enough.
This is a bad excuse to write bad code.

What if the server has disabled .htaccess support?
What if the host moved to a new version of apache without mod_security (mod_security could be catching up in the mean time)?
What if a hole is found to bypass mod_security (or equivalent)?

I am not saying that this shouldnt be used, just that you cant just rely on them for ungaranteed code protection.

[afonic]

I agree 100% Raul! 

I am just trying to point out how important all these steps (.htaccess, file permissions) are in the security of a server - and most times you can apply them even in a shared hosting environment.

[elfishtroll]

@Raul Dias .. reading the exchange I was not sure if you really didnt know or were just pulling his leg! but I realize you are more used to a more structured, typed language like C++ and SmallTalk, not the wild wild west that is PHP!

But RFI can enter not just through a command/url exchange but also via improper use of the EVAL() command (commonly seen in poor template or interface/bridge code and XML-RPC parsers.

and  dont forget the http://us.php.net/extract command too.

Raul,

Ok, components being called directly is indeed very poorly written to start with.
Thanks, this answers question [1].

Thats just plain false, there are MANY reasons to have a component directly callable via URL, a poor man's SOAP SERVICE is one, the AVATAR on your SMF forum is another! (while you see a GIF or JPG what is actually served up is php output from a directly called script.)

One simple mistake took down the whole server

Actually it wasnt.

More specifically it was:

Joomla Hack Cookbook

1. Serving of sloppy code

3. dollops of Pompous Server Mismanagement

4 Months of Internal Bickering and GPL Purging

5. Slices of Google URL bread chopped into breadcrumbs and trailed to every hacker site.

Stir vigorously and allow to simmer on a low flame. Wash hands and prepare a nice "Steak and 'Fk every bridge' Pie" and allow to cool. (serves 45,000)

*DING*

I see our hack is ready!

Mmmmmm just about right!
Apply a small glaze (with egg wiped off face) and reinsert (in oven: no need to think naughty thoughts here!) When the thermometer has popped up, serve to a limited audience (away from the front page in an obscure thread and board)

While guests eat, sprinkle a few drops of "AmyStephen Innuendo (tm)" and Voila! A meal fit for a King prepared by Queens!


Next Week



Are you hooked on 'Fonics?
Lets go see what other stuffing we can get outta this TURKEY in this hot oven episode!

You are absolutely right Raul: Aggressive coding means you protect your code and don't assume default or external settings will do the JOB!

You CHECK that magic Quotes are ON or OFF
You SET variables DO NOT ASSUME

[Raul Dias]

@Raul Dias .. reading the exchange I was not sure if you really didnt know or were just pulling his leg! but I realize you are more used to a more structured, typed language like C++ and SmallTalk, not the wild wild west that is PHP!

Actually the dark world of perl too .

Raul,

Ok, components being called directly is indeed very poorly written to start with.
Thanks, this answers question [1].

Thats just plain false, there are MANY reasons to have a component directly callable via URL, a poor man's SOAP SERVICE is one, the AVATAR on your SMF forum is another! (while you see a GIF or JPG what is actually served up is php output from a directly called script.)

Remeber I was talking about Joomla (and Mambo).
In there a component is like a plugin called by the main php file (which knows which component should be called by a GET).

Sure there are valid reasons to have direct call, but I would say that in Joomla/Mambo component world that represents barely 1% (number taken out of my hat).

Just considering this small set of possible problems, I already found a flawed component in my instaltion that could be exploited this way and others thru Google.

One simple mistake took down the whole server

Actually it wasnt.

More specifically it was:

Joomla Hack Cookbook

Funny.