Discussion for: Advisory: Dealing with hacked websites and hacking attempts.

[RobS]

This thread is to discuss, "Advisory: Dealing with hacked websites and hacking attempts." as posted here: http://forum.joomla.org/index.php/topic,76551.0.html

[anna.y]

My globals.php file does not contain that line at all.  Am I looking at the file in the wrong directory?

define( 'RG_EMULATION', 1 );

Anna

[infograf768]

It should be in your joomla root directory

[anna.y]

It looks like I have an old version (Joomla 1.0.3) still using Mambo file - installed September 10, 2005

$value){
$GLOBALS[$key]=$_FILES[$key]['tmp_name'];
foreach($value as $ext => $value2){
$key2 = $key . '_' . $ext;
$GLOBALS[$key2] = $value2;
}
}
}
?>

Is there anything I should do about it?

[JimLouis]

Do you have to protect language files?

[infograf768]

It looks like I have an old version (Joomla 1.0.3) still using Mambo file - installed September 10, 2005

Is there anything I should do about it?

YES! UPDATE NOW to 1.0.10!
(not joking)

If you have been hacked, you may not even know why as so many security holes have been plugged since 1.0.3.

Before... backup tyour database.

[infograf768]

Do you have to protect language files?

Not that I am aware of.

[DeGrey]

I manage quite a few Mambo/Joomla sites and became quite depressed when I realized the how many files would have to be modified, so I developed (with help) a much faster way to fix this.

This is for unix servers only.
I logged into shell, browsed to the root of my mambo/joomla directory and ran a grep search:

Code: Select all

grep -Rc VALID_MOS * | grep php:0 > /path/tosave/results

I downloaded the results file and opened it in a text editor and removed the lines that I knew for sure didn't need it.
I saved and reuploaded.

I created a php file called replace.php and uploaded it to the server. It's contents are:

Code: Select all

#!/usr/bin/php -f
<?php

//
// set this to wherever your results file is located
//
define('RESULTS_ROOT', '/home/myaccount/');

//
// set this to the root of the tree you're working on is, ie: where you
// ran the 'grep' command from
//
define('TREE_ROOT', '/home/myaccount/public_html/');

$files = file(RESULTS_ROOT . 'results');
foreach ($files as $file) {
  list($filename, $junk) = explode(':', trim($file));
  $lines = file(TREE_ROOT . $filename);

  $phpFile = fopen(TREE_ROOT .$filename, 'w') or die('cannot open file');

  $i = 0;
  $done=false;
  $numLines = count($lines);
  while ($i < $numLines) {
    if ($done == false && '<?php' == trim($lines[$i])) {
      $lines[$i] = "<?php\ndefined('_VALID_MOS') or die('Restricted access');\n";
      $done=true;
    }
    fwrite($phpFile, $lines[$i++]);
  }
  fclose($phpFile);
}
?>

Then I ran the follow command in shell:

Code: Select all

php [path_to_file]/replace.php

[GoKiller]

RobS/infograf768

FYI.  When I apply that modification -- define( 'RG_EMULATION', 0 ); -- I am unable to use my Joomla - Coppermine Gallery bridge.  As soon as I remove it the problem goes away.  I don't use a lot of components but I would be surprised if that change did not affect others in a similar manner.

Using:

Joomla 1.0.10
Coppermine Gallery 1.48
Joomla - Coppermine bridge -- http://www.mehdiplugins.com/misc/index.htm

Error:

Fatal error: main(): Failed opening required 'bridge/udb_base.inc.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/website/public_html/website/bridge/joomla.inc.php on line 172

[infograf768]

I would contact the author and let him know his bridge needs REGISTERGLOBALS ON to work and ask him if he can change this requirement.

[mehdi]

Hi I'm the author of that bridge,
it works with register_globals = Off
but not when you apply the modification : define( 'RG_EMULATION', 0 );

Probably the problems comes from that unlike usual components, Joomla is executed INSIDE
the gallery (by including it). Seems that joomla cleans all internal vars previously used by the
gallery .... I'll look further into this problem later.

[friesengeist]

it works with register_globals = Off
but not when you apply the modification : define( 'RG_EMULATION', 0 );

If it does not work with RG_EMULATION = 0, that means that your component does rely on register_gobals = ON! What Joomla! does when RG_EMULATION is set to 1 is emulate the behaviour of register_globals = ON. Even though PHP does not register any global vars, Joomla! does.

Please make sure your component does not need RG_EMULATION = 1, because that actually means you rely on register_globals = ON.

[mehdi]

Hi ,

If it does not work with RG_EMULATION = 0, that means that your component does rely on register_gobals = ON! What Joomla! does when RG_EMULATION is set to 1 is emulate the behaviour of register_globals = ON. Even though PHP does not register any global vars, Joomla! does.

Although what you are saying is true most of the times, that's not the case here.
To be more clear, this bridge does not work like a "true/standard component".

Anyway I've just updated files of that bridge to fix that problem.
If you are experiencing problems when doing define( 'RG_EMULATION', 0 );
then redownload that bridge and replace the file joomla.inc.php by the new one.
A similar fix has been applied to my other bridge for phpbb2. (updated joomphpbb_engine.php)

Remark: if you emulate "register_globals = Off" by doing "define( 'RG_EMULATION', 0 );" this affects Joomla only , not  the bridged script. You can let the script work with "register_globals = Off" but by modifying php configuration only (forget emulation).

cheers

[aztc]

I just looked at DocMan files and note the required security line is missing from every file - this seemed such a well developed component, is my joomla 1.1.10 site vulnerable?

EDIT: Duh - I just looked again and it seems the php files do have the line of code - sorry bout that! DocMan is SUPER. 

[friesengeist]

To be more clear, this bridge does not work like a "true/standard component".

Hi mehdi,

I just took a short look at your bridge and at coppermine, didn't know the bride works the other way around (calling coppermine by URL and then including Joomla!).

Thanks for the clarification,
Enno

[dkarlson]

I performed a grep like DeGrey suggested. There are a lot of files in /administrator/ that don't have the VALID_MOS line -- althought that doesn't concern me that much. On the 5 sites I administer, all of /administrator/ sits behind .htaccess password protection.

What does concern me are files without the line in the domit and patTemplate directories, as well as the jce editor class.

What are everyone's thoughts on the matter?

[infograf768]

Not all files need the mos or die string.

[RobS]

To elaborate, only files that actually run commands need the VALID_MOS or die checks.  We have checked all of our files and the only files that do not have the checks are files that 1) define VALID_MOS 2) are class definitions or 3) are toolbar definitions.  The patTemplate and domit files you were concerned with just define classes so they are safe.

[hilu]

Hi there,
I am victim of repeated attacks.
At first I was attcked by file inclusing and in two days time again attacked by a site insertion - telling that your site is hacked, We are Turkish etc.. I just uninstalled community builder and checked ,the site came back to life. But after just half an hour the foreign site started blowing its horrible music and banners in my site. Now I have uninstalled all the vulnerable extensions like extcal/minical/mosmedia which ever is not from joomla.org.

• Is it required to include the code  defined( '_VALID_MOS' ) or die( 'Restricted access' ); in all the files ending with *.php ? I suppose it is not needed for index.php am I right?
• And when I try to do the following In public_html folder, open .htaccess file and add this (change user toyour cPanel username):
  
  suPHP_ConfigPath /home/user/public_htm l get the message
  Forbidden
  You don't have permission to access /index.php on this server.
  
  Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
  
  
  --------------------------------------------------------------------------------
  
  Apache/1.3.34 Server at http://www.enad.co.uk Port 80

I have upgraded to joomla 1.0.10. Please advice me what is going  on.
Regards,
Hilu

[infograf768]

@Hilu

Please read the various security forum posts, including the 3pd security forums.

First go there:
http://forum.joomla.org/index.php/topic,81058.0.html

[Vince]

Hi,
Suggestion:

Why not have the quality control group check for these things in all 3PD extensions that are submitted BEFORE approving/adding them onto the main extensions.joomla.org site?

It shouldn't take them long (seconds?) with a simple tool to search for the required code.

I realise it would take too long to check all past 3PD, but if you start by adding a "QCG checked" next to the heading for each new one or updates, it would be a good start?

Thanks for considering.

- Vince

[RobS]

Unfortunately, Q&T is severly under-staffed and has probably the fewest human resources available out of all of the WG's in addition to some of the most demanding work.  We can barely handle the tasks that we have, which results in them taking a lot longer than we would like them too.  There is no way that we could even entertain this idea until those problems are addressed and we get a better handle on our other tasks.  Honestly, I don't ever see this being a priority of the Q&T team as there is much work to do in this area on the Joomla! project let alone for 3rd party extensions.  It would be much better suited for another team/group entirely but that is a whole other discussion.

[brian]

I 'used' to be a vocal advocate for this sort of testing.  something along the lines of ;
does it install automatically ?
does it have the code to prevent remote execution?
etc

then the extension would get a 'seal of approval' etc

but then I realised that there is so much more than this to ensuring an extensi n works and is safe and secure. and this sort of testing is both time consuming and potentially expensive .

But more importantly any sort of seal, no matter how limited, will potentially put joomla in a position of liability over something it does not directly control.

for this reason I no longer advocate testing of 3pd extensions and instead would prefer the disclaimer, as seen on extension.joomla.org to be even more prominent and perhaps  even present in joomla itself and displayed each time you use the extension  installers

[brad]

Yip, I agree Brian, as a host, we'd also like to see a warning before people install anything (comp/mod etc) to make it clear that they are now outside of the scope of Joomla and will have to keep this extension secure and up to date.

[brian]

what would also help would be if there was a 'standard' way to check for updates.

perhaps this could be done by having an extra parameter in the extension xml install file that included the url that the latest version will be recorded.

this data could then be added to a table that your joomla install queries on a defined time scale or manually ,and could then notify you of any extension that needs updating. [far better than just displaying 'this is x days old']

[Rochen]

I just wanted to drop a quick reply to support what Brian and Brad have both said above

Joomla has no responsibility for maintaining third-party code (such as components) and I wouldn't expect them or want to get into that. Both because it would take away from the development of Joomla itself and could potentially open Joomla up to liability, I do however think there is far more that can be done proactively to protect people who install components.

As a hosting provider the major problem we have seen is that people will install a component under Joomla and while they will keep Joomla updated they wont bother keeping the component itself updated because they don't think they have to. Their site then gets hacked due to the outdated component and they can't understand why until we explain to them. This type of situation is going to end up giving Joomla a bad name as far as security goes in the hosting community even although Joomla is not at all to blame for the problems. Hosting providers who aren't as familiar with Joomla will just automatically blame it and not think about the components.

In my opinion there needs to be a very prominent security warning and disclaimer on any page within the Joomla Admin Panel where you can install components or third party code. It needs to warn users that if they install a component then they need to be proactive with updates. I just don't think a lot of people get it right now and more could be done to explain this to people. It would take literally zero effort on the part of Joomla and it would greatly help people to keep their Joomla installs secure, give Joomla a better reputation with a lot of hosting providers and encourage more people to use it.

- Chris

[infograf768]

In my opinion there needs to be a very prominent security warning and disclaimer on any page within the Joomla Admin Panel where you can install components or third party code.

This indeed would not, I hope, be considered by the dev team as a new prone-to-break-something feature and it makes sense to introduce it asap i.e. in 1.0.12.

[steve4j]

In my opinion there needs to be a very prominent security warning and disclaimer on any page within the Joomla Admin Panel where you can install components or third party code.

This indeed would not, I hope, be considered by the dev team as a new prone-to-break-something feature and it makes sense to introduce it asap i.e. in 1.0.12.

I disagree somewhat- the problem with 3pd code i feel is that every bloody site has a copy of com_crapcomponent.zip with no indication of when they got it or how uptodate it was.

A generic DISCLAIMER WARNING message with no specific plan of action will directly contribute to user apathy and create BACKGROUND NOISE which makes the warning (and others following) less effective.

Also, in the Joomla Extensions site, some of the extension links DO NOT DOWNLOAD but instead go to another site where you may have to register or some other crap. I think the extensions should be hosted by Joomla and the extension submitter be authenticated by Joomla before being hosted.

The install function should then have a
* Link to the Joomla 3PD directory
* Link to the 3PD security advisory board


my $1.00
(previously my 2 cents, but adjusted for inflation)

[jon68]

In reference to:
    "Lastly, it is imperative that you take care of any files that do not have the proper “VALID_MOS” check, again, the line below should be in ever .php file of every third party component.
    defined( '_VALID_MOS' ) or die( 'Restricted access' );"


Here is a nice one liner to find such files. I assume you have shell access on a Linux host:

shell:> find . -name "*.php" -exec grep -Hc Restricted {} \; | grep ":0" | grep "mambots\|components\|administrator"

You may of course instead look for some other text, e.g. VALID_MOS.

The command might take a few seconds to complete. But you'll be rewarded with a list of files where the word "Restricted" has not been found, i.e. files which pose a security risk.


You may also automatically process the files found - e.g. view the first 5 lines or run a script/command on them.  Like this:
shell:~> find  -name "*.php" -exec grep -Hc VALID_MOS {} \; | grep ":0" | grep "mambots\|components\|administrator" | cut -d: -f1 | xargs -i head -5 -v {} |less

[ewel]

I am wondering if the recommendation to edit globals.php in the Joomla root directory on line 12 to define( 'RG_EMULATION', 0 ); still applies for version 1.5RC4, as I cannot find globals.php in the root of my installation on Wamp5.

On a side note, interesting to see the above discussion similar to one I participate in here: http://forum.joomla.org/index.php?topic ... icseen#new.