Patch to protect against public security threats for previous joomla versions

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

Hi,

I want to implement a Universal Security Hotfix for previous versions of Joomla that can provide immediate protection against publicised attacks.

Below is code I am proposing to apply to the top of the index (index.php,index2.php etc) files in both the root and administrator
folders of joomla.
I am developing a universal security hotfix that can hopefully protect sites against attacks. That is, give them a breathing space so that an unrushed upgrade of your site can be performed.

I am currently testing it and need the help of sites that are undergoing an attack to see how effective it is.

THIS IS ALPHA STAGE OF THIS CODE AND SHOULD NOT BE USED BY INEXPERIENCED USERS

TO INSTALL - Copy the code below and paste the code in your globals.php file just below the copyright messages at the top of the file.

The hotfix currently DOES NOT prevent attacks on both Simpleboard and ExtCalandar2 modules - but I am investigating further, but should prevent known attacks on Joomla itself, unless anyone has any further info I am not aware of.

I make no guarentees at this stage as its in its very early stages of development, but the more people who can test the code, the more bullet proof and more helpful this code will be to other users who sites are vunerable.

PLEASE BE AWARE THAT IS HOTFIX IS ONLY DESIGNED AS A SHORT TERM MEASURE UNTIL YOU UPGRADE TO THE LATEST VERSION OF JOOMLA AND UPGRADE AND SECURE ANY OFFENDING 3rd PARTY MODULES

Code:

// ***** Security Hotfix Code version 1.4.8 (13-JUL-06) ********

// NOTE: THIS IS ONLLY A SHORT TERM MEASURE UNTIL YOU UPGRADE TO THE LATEST VERSION OF JOOMLA




// Joomla 1.0.3 and earlier vunerabilities 2005-11-22
$hotfix_protects = array('_REQUEST', '_GET', '_POST', '_COOKIE', '_FILES', '_SERVER', '_ENV', 'GLOBALS', '_SESSION');
foreach ($hotfix_protects as $hotfix_protect) {
   if ( in_array($hotfix_protect , array_keys($_REQUEST)) ||
        in_array($hotfix_protect , array_keys($_GET)) ||
        in_array($hotfix_protect , array_keys($_POST)) ||
        in_array($hotfix_protect , array_keys($_COOKIE)) ||
        in_array($hotfix_protect , array_keys($_FILES))) {
       die("Invalid Request.");
   }
}
hotfix_sanitize_input ('Itemid'); 


// Mambo 4.5.3h and earlier vunerabilities 2006-02-22
// I dont think these are needed in Joomla, can anyone verify ???
hotfix_sanitize_input ('username'); // $_POST
hotfix_sanitize_input ('filter'); // $_POST
hotfix_sanitize_input ('task'); // $_GET, $_POST
hotfix_sanitize_input ('mos_user_template'); // $_COOKIE
hotfix_sanitize_input ('mos_change_template'); // $_REQUEST


// Joomla 1.0.9 and earlier vunerabilities 2006-06-19
hotfix_sanitize_input ('title');
hotfix_sanitize_input ('catid');
hotfix_sanitize_input ('id','integer','|com_jd-wiki|');  // convert "id" to integer except when using module com_jd-wiki


// main hotfix security functions

function hotfix_URLcheck( $filename ) {
   $urlfile = '/'.strtolower(basename($_SERVER['PHP_SELF']));
   if (strpos($urlfile,$filename) === false) {
      return false;
   } else {
      return true;
   }
}

function hotfix_sanitize_input( $vname, $dtype='', $exlist='' ) {
   if (isset($_REQUEST[$vname])) {
      $safe_data = strip_tags(mysql_escape_string($_REQUEST[$vname]));
      if ($dtype != '') {
         $m = '|'.$_REQUEST['option'].'|';
         if(strpos($exlist,$m)=== false) { 
            settype($safe_data, $dtype); 
         }
      }
      $_REQUEST[$vname] = $safe_data;
      if (isset($_GET[$vname])) { $_GET[$vname] = $safe_data; }
      if (isset($_POST[$vname])) { $_POST[$vname] = $safe_data; }
      if (isset($_COOKIE[$vname])) { $_COOKIE[$vname] = $safe_data; }
   }
}

// ***** Security Hotfix Code end ********

Can anyone see any problems with this code or how it would be applied

??

This patch is meant to be an immediate short term defence to allow breathing space to do a proper upgrade and test of joomla to its latest version in a production environment.

Any issues please leave a message in this forum or PM me.

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

Below is code I am proposing to apply to the top of the index (index.php,index2.php etc) files in both the root and administrator
folders of joomla

Put it in /globals.php, then you don't need to put it in multiple files...

Don't know if every file (in administrator etc.) used globals.php in earlier versions of Joomla! Maybe it's better to check at least each of these files if they include globals.php.

From a short glance at it, looks good. BUT: You can't stop two SQL injections that were fixed in 1.0.10 with it. (One could possibly be stopped, the other one is quite hard to stop because the name of the variable is different for every different installation of Joomla!)

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

From a short glance at it, looks good. BUT: You can't stop two SQL injections that were fixed in 1.0.10 with it. (One could possibly be stopped, the other one is quite hard to stop because the name of the variable is different for every different installation of Joomla!)

is there a POST or GET variable I can check for to know when the "variable that is different for every installation of Joomla" is being passed through, or how many differences are there for each installation

?

Are there any other variables that have security issues that need sanitizing on the way through (that I need to add to the code)

???

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

From a short glance at it, looks good. BUT: You can't stop two SQL injections that were fixed in 1.0.10 with it.

I dont know why you cant stop the sql injections as the attacks must pass through the GET/POST variables. Isnt it just a matter of identifying which variables to sanitize on the way through ??

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

Put it in /globals.php, then you don't need to put it in multiple files...

Don't know if every file (in administrator etc.) used globals.php in earlier versions of Joomla! Maybe it's better to check at least each of these files if they include globals.php.

I just did a quick check and it appears Joomla 1.0.7 and mambo 4.5.2 you need to include the code in globals.php and index.php in the administrator folder (as globals.php in not included in that file).

Can anyone else confirm ??

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

friesengeist wrote:

From a short glance at it, looks good. BUT: You can't stop two SQL injections that were fixed in 1.0.10 with it. (One could possibly be stopped, the other one is quite hard to stop because the name of the variable is different for every different installation of Joomla!)

is there a POST or GET variable I can check for to know when the "variable that is different for every installation of Joomla" is being passed through, or how many differences are there for each installation

?

Let me try to explain this more in detail: the name does not change with every new version of Joomla! The name of the variable is dependant on the settings in your configuration.php. In case you really want to know, it's the return value of remCookieName_User, defined in /includes/joomla.php. If you take a look at it, you can see that it is built by use of many nested calls of md5(), mosHash() and many different settings from configuration.php. That's why you can't provide an easy solution. On the other hand, this hack is a bit more complicated than the exploit that was posted on the net. Unlikely to be exploited by script kiddies, i would say.

bigmudcake wrote:

Are there any other variables that have security issues that need sanitizing on the way through (that I need to add to the code)

???

The injection that "could possibly be stopped" is this: the variable "id" needs to be converted to integer. That might have side effects on other components, so this is probably not a good idea.

A few more thoughts on this in general:
I know that people sometimes refuse to update, as it involves quite some work. But on the other hand, applying the patch you provide might make them think they are secure when they are not. In my opinion it is OK to refuse to update, but then these people should really know what they are doing. That means that they need to fix the holes directly, applying this general patch is simply not enough. It's like building a low fence around your house and leaving your front door wide open. Anyone who can jump high enough can just jump over the fence and enter your house. But if you looked your door (that would be patching the hole directly) he wouldn't have made it in, no matter how high he can jump.

Don't get me wrong! I appreciate your work, and in fact it does stop some attacks against 1.0.3 and prior. But it just can not stop every hack, by design. It is the wrong place were all these "security solutions" like firewalls etc. try to do their work. The software itself needs to be secure. This patch, mod_security, the .htaccess patch, firewalls etc. are just additional checks to secure software against common attacks. For specific attacks (like the two injections I mention) the product itself needs to be secured in my opinion.

Just my 0,02€

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

Let me try to explain this more in detail: the name does not change with every new version of Joomla! The name of the variable is dependant on the settings in your configuration.php. In case you really want to know, it's the return value of remCookieName_User, defined in /includes/joomla.php. If you take a look at it, you can see that it is built by use of many nested calls of md5(), mosHash() and many different settings from configuration.php. That's why you can't provide an easy solution. On the other hand, this hack is a bit more complicated than the exploit that was posted on the net. Unlikely to be exploited by script kiddies, i would say.

After looking at the way remCookieName_User is generated I think its not what I would consider needed for this security patch. Unless there is an exploit out there ?? Can anyone confirm ??

I am only looking to add to my security patch to fix either
- publicly known exploit code known in the wild
- critical holes - ones that can be exploited very easily.

friesengeist wrote:

I know that people sometimes refuse to update, as it involves quite some work. But on the other hand, applying the patch you provide might make them think they are secure when they are not. In my opinion it is OK to refuse to update, but then these people should really know what they are doing.

You missed the aim of this security patch. It is NOT about people refusing to update. It is about allowing people to be secured enough to allow time to update in an orderly way.

How many posts have you seen with the title "I have been hacked". It is not good enough to allow sites to remain unsecured while your trying to rush and upgrade the whole site with a new version. Its a receipe for disaster. Its never trivial to upgrade to a new version, you need to make sure nothing breaks first before going live, In the meantime the site may get "hacked". That is not a good situation to put people in.

friesengeist wrote:

It's like building a low fence around your house and leaving your front door wide open. Anyone who can jump high enough can just jump over the fence and enter your house. But if you looked your door (that would be patching the hole directly) he wouldn't have made it in, no matter how high he can jump.

A better analogy - Its like having a house where you know the only entry points like doors and windows that potential robbers can enter is known (POST,GET,COOKIE variables etc). Now because the house cannot handle the robbers once they enter, should the ONLY solution be to replace the house with a new one that can (this takes time), or also should you put security on the entry points to monitor and guard who enters the existing house.

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

The injection that "could possibly be stopped" is this: the variable "id" needs to be converted to integer. That might have side effects on other components, so this is probably not a good idea.

Maybe if I first convert to integer (to wipe out any hacks) and then convert back to a string.

Unless I am mistaken, isnt the "id" stored in the database as an integer for most joomla records. ??

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

After looking at the way remCookieName_User is generated I think its not what I would consider needed for this security patch. Unless there is an exploit out there ?? Can anyone confirm ??

There is a SQL injection vulnerability that was fixed in 1.0.10. I modified the exploit that worked for the weblinks hole in a way to work against that remember me thing. As far as I know, such an exploit is not "out there". The only ones who have my exploit are the core devs who are on the security@joomla... mailing list.

bigmudcake wrote:

I am only looking to add to my security patch to fix either
- publicly known exploit code known in the wild
- critical holes - ones that can be exploited very easily.

That "id" hole can (under certain circumstances) easily be exploited. Not publicly know though, I'd say.

bigmudcake wrote:

friesengeist wrote:

I know that people sometimes refuse to update, as it involves quite some work. But on the other hand, applying the patch you provide might make them think they are secure when they are not. In my opinion it is OK to refuse to update, but then these people should really know what they are doing.

You missed the aim of this security patch. It is NOT about people refusing to update. It is about allowing people to be secured enough to allow time to update in an orderly way.

Ok, sorry for missing that. After re-reading your first post I must admit that I have missed that, I mainly looked at the code. Sorry!
Could you maybe edit your post to indicate more clearly that people still need to upgrade as soon as a patch comes out?

bigmudcake wrote:

friesengeist wrote:

It's like building a low fence around your house and leaving your front door wide open. Anyone who can jump high enough can just jump over the fence and enter your house. But if you looked your door (that would be patching the hole directly) he wouldn't have made it in, no matter how high he can jump.

A better analogy - Its like having a house where you know the only entry points like doors and windows that potential robbers can enter is known (POST,GET,COOKIE variables etc). Now because the house cannot handle the robbers once they enter, should the ONLY solution be to replace the house with a new one that can (this takes time), or also should you put security on the entry points to monitor and guard who enters the existing house.

Quite true for the time from when a new hole is found and before it is fixed.

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

friesengeist wrote:

The injection that "could possibly be stopped" is this: the variable "id" needs to be converted to integer. That might have side effects on other components, so this is probably not a good idea.

Maybe if I first convert to integer (to wipe out any hacks) and then convert back to a string.

PHP makes no difference between int and string, so converting back would not be needed.

bigmudcake wrote:

Unless I am mistaken, isnt the "id" stored in the database as an integer for most joomla records. ??

There are 3PD components (like com_jd-wiki, see id in this URL) that need id to be a string. That's why I first said converting is maybe not a so good idea. On the other hand, if it is really only for short time defence, breaking thoses 3PD components is probably better than having the hole open

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

PHP makes no difference between int and string, so converting back would not be needed.

typecast can be important when doing variable comparisions in PHP

friesengeist wrote:

There are 3PD components (like com_jd-wiki, see id in this URL) that need id to be a string. That's why I first said converting is maybe not a so good idea. On the other hand, if it is really only for short time defence, breaking thoses 3PD components is probably better than having the hole open

Probable easier just to apply my sanitize_imput function to the "id" rather than converting to integer. Should still strip out anything nasty while still maintaining compatability.

I have editied my original post (first post in this thread) to reflect changes you suggested in your earlier post.

Do you think maybe I should include code to counter the remCookieName_User ??

Thinking about it more, I think I should.

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

friesengeist wrote:

There are 3PD components (like com_jd-wiki, see id in this URL) that need id to be a string. That's why I first said converting is maybe not a so good idea. On the other hand, if it is really only for short time defence, breaking thoses 3PD components is probably better than having the hole open

Probable easier just to apply my sanitize_imput function to the "id" rather than converting to integer. Should still strip out anything nasty while still maintaining compatability.

That's not enough, because not a single quote is needed in that injection string!

bigmudcake wrote:

I have editied my original post (first post in this thread) to reflect changes you suggested in your earlier post.

Do you think maybe I should include code to counter the remCookieName_User ??

Thinking about it more, I think I should.

Thanks for editing the first post!

remCookieName_User: It's up to you how much effort you want to put into it. I think script kiddies won't find that hole. One needs a little bit more knowledge of http requests to conduct a successful injection on that. Of course it would be good to stop injections... Decide for yourself

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

In case you really want to know, it's the return value of remCookieName_User, defined in /includes/joomla.php. If you take a look at it, you can see that it is built by use of many nested calls of md5(), mosHash() and many different settings from configuration.php. That's why you can't provide an easy solution. On the other hand, this hack is a bit more complicated than the exploit that was posted on the net. Unlikely to be exploited by script kiddies, i would say.

I have been looking at the code and correct me if I am wrong, but it seems the offending code was only introduced in 1.0.8. Does that mean only versions 1.0.8 and 1.0.9 are vunerable ??

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

I have been looking at the code and correct me if I am wrong, but it seems the offending code was only introduced in 1.0.8. Does that mean only versions 1.0.8 and 1.0.9 are vunerable ??

I avoided stating it this clearly, but yes, you are absolutely right. It was introduced in 1.0.9, so it's only one version that is affected by this hole.

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

friesengeist wrote:

bigmudcake wrote:

friesengeist wrote:

There are 3PD components (like com_jd-wiki, see id in this URL) that need id to be a string. That's why I first said converting is maybe not a so good idea. On the other hand, if it is really only for short time defence, breaking thoses 3PD components is probably better than having the hole open

Probable easier just to apply my sanitize_imput function to the "id" rather than converting to integer. Should still strip out anything nasty while still maintaining compatability.

That's not enough, because not a single quote is needed in that injection string!

Would stripping out semicolons work for "id" plus still maintain compatability ??

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

bigmudcake wrote:

Would stripping out semicolons work for "id" plus still maintain compatability ??

Please PM me your email adress...

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

I have updated the security code (now version 1.1.4) in the first post of this thread to cast "id" as an integer except when used in module com_jd-wiki.

Can anyone see any bugs or outstanding issues in the code before I start intensive testing ??

Does that fix all major security issues in 1.0.9 ??

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

I found a bug, so the security patch shown in the first post of this thread is now updated to version 1.1.5

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

I will eventually set this security patch code up as a component that can be easily installed/uninstalled

mauri · **Joined:** Mon Aug 22, 2005 6:47 pm **Posts:** 59

bigmudcake
In your code is '_GET'
Can I use only 'GET'

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

mauri wrote:

bigmudcake
In your code is '_GET'
Can I use only 'GET'

$_GET, $_POST are the new style superglobals in php that I am pretty sure Joomla uses.

I dont think Joomla use the old style variables for accessing incomming data. Can anyone confirm ??

Old style are $HTTP_GET_VARS, $HTTP_POST_VARS etc.

using just GET wont work because thats not how a superglobal is set. must be $_GET.

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

I have updated the security code (version 1.2.6) in the first post of this thread for peer review to include the following enhancements

- Include code to stop attacks to simpleboard

- Include code to stop attacks to ExtCalandar2

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

I have updated the code (now version 1.3.7) to fix parse errors and am now testing. If anyone wants to help test, just insert the code into the top of your globals.php file below the copyright messages

I would be interested in feedback on how this patch goes. It should work for ALL versions of Joomla and hopefully prevent all known attacks.

RobS · **Posted:** Thu Jul 13, 2006 5:57 am

bigmudcake wrote:

- Include code to stop attacks to simpleboard

- Include code to stop attacks to ExtCalandar2

You might want to rethink making those statements in your post. That code will NOT stop the ExtCalendar2 and SimpleBoard exploits for one very simple reason. The files are being requested directly, not through Joomla and the files in those two components that have the flaws in them do not include/require Joomla's globals.php. Therefore, that code being added to globals.php will do absolutely nothing for the security of those components by itself. There has to be an additional fix made first (adding defined( '_VALID_MOS' ) or die( 'Restricted access' ); to every file those components installed) which should solve the problem by itself.

The same will apply to any other component/module that does not do the proper 'VALID_MOS' checking and the same lack of effectiveness of your sanitation routines will apply to all of those exploits.

I personally think addressing these issues via an .htaccess rewrite rule is more effective as this occurs at the server level and does not require the files to be called through Joomla in order to catch exploit attempts. However, this should not give anyone an excuse for not dealing with the inevitable, these files are insecure, they are old and no longer maintained. It is a recipe for disaster.

PhilTaylor-Prazgod · **Posted:** Thu Jul 13, 2006 8:27 am

DO NOT BE DECIEVED BY THESE STATEMENTS! They are wrong

Quote:

The hotfix should prevent attacks on both Simpleboard and ExtCalandar2 modules, plus all known attacks on Joomla itself.

IT IS FACTUALLY INCORRECT.

ExtCal ad SB recent exploits are direct access exploits and adding the proposed code to any Joomla file is NOT GOING TO PROTECT YOU

Misleading less experienced users by using such blatantly factually incorrect language is very dangerous.

EDIT: RobS is right - I agree

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

PhilTaylor-Prazgod wrote:

DO NOT BE DECIEVED BY THESE STATEMENTS! They are wrong

Quote:

The hotfix should prevent attacks on both Simpleboard and ExtCalandar2 modules, plus all known attacks on Joomla itself.

IT IS FACTUALLY INCORRECT.

ExtCal ad SB recent exploits are direct access exploits and adding the proposed code to any Joomla file is NOT GOING TO PROTECT YOU

Misleading less experienced users by using such blatantly factually incorrect language is very dangerous.

EDIT: RobS is right - I agree

Ok, will change and test further.

bigmudcake · **Joined:** Thu Dec 08, 2005 8:38 am **Posts:** 55

bigmudcake wrote:

PhilTaylor-Prazgod wrote:

DO NOT BE DECIEVED BY THESE STATEMENTS! They are wrong

Quote:

The hotfix should prevent attacks on both Simpleboard and ExtCalandar2 modules, plus all known attacks on Joomla itself.

IT IS FACTUALLY INCORRECT.

ExtCal ad SB recent exploits are direct access exploits and adding the proposed code to any Joomla file is NOT GOING TO PROTECT YOU

Misleading less experienced users by using such blatantly factually incorrect language is very dangerous.

EDIT: RobS is right - I agree

Ok, will change and test further.

Less experienced users probably are so overwhelmed by the myraid and dis-organisation of how the security info is dispensed and contradicted that its less of a danger then trying to get something happening where eventially there is an all in one simple patch that can be applied in the short term (and only one solution they have to turn to) to get them out of their short term woes.

I will add to my original post that the patch is only in early alpha stage and not to be tried by in-experienced users.

PhilTaylor-Prazgod · **Posted:** Thu Jul 13, 2006 9:18 am

Without trying to make this sound like a personal attack - you are showing that you dont understand the very nature of the recent attacks by thinking that you can provide a universal "simple patch"

Quote:

myraid and dis-organisation of how the security info is dispensed

It is NOT the responsibility of the Joomla Developers - or the community in this forum - to organise or dispense security advice on 3rd Party Components - that is the responsibility of the original developer of a component. If the component is no longer developered then as a user you should take responsibility for ensuring they protect yourself by using current versions of supported products.

Most GPL/Free Components come with no warranty at all

A "simple [universal] patch" is NOT going to fix ALL the recent issues in all the components.

Joomla! Discussion Forums

Forum rules

Patch to protect against public security threats for previous joomla versions

Quick reply

Who is online