Joomla! Discussion Forums

Please, send details to robs by pm.
No use to post them here in the open.

Yeah, that would probably be a wiser choice.  If you are having trouble finding the section you can send me the whole log and make sure you let me know between what times this happened so I can limit my search. 

I can see your point. I think it would be better to block this in globals.php though, because that applies to all users, not only those with the modified .htaccess. Might be worth considering.



Not that I know of. Please let me know if I'm wrong on that.
The other way around ($_REQUEST from $COOKIE) works though.

From http://www.php.net/manual/en/reserved.variables.php



I took that to mean you can access $_COOKIE through $_REQUEST

Maybe we are talking about the same thing? (Or maybe just a language related misunderstanding? - English is not my native language)
GET data, POST data and COOKIE data are merged into $_REQUEST. From my understanding, this would be best described as "users can access $_REQUEST from e.g. $_COOKIE".

I think you are right, it also happened to me with the latest joomla version 1.10
any ideas?

http://www.matik.nl (got hacked)

That is understandable but I think it means the opposite to what you are thinking.  $_REQUEST is an associative array consisting of the whatever content is in the arrays $_GET, $_POST, and $_COOKIE.  It says while referring to $_REQUEST, "An associative array consisting of the contents of ..." meaning the contents of $_REQUEST is the same as the contents of $_GET, $_POST, and $_COOKIE combined.

OK, than we are talking about exactly the same thing

If you have access to your log files, send them to me via personal message along with approximately when the site got cracked and I will look into it.  If they won't fit in a PM due to size/length, PM me and I will give you my email address.  On a side note, I really like the design of your site.  It is very neat.

I just e-mailed to you my log files
Used the hotmail e-mail you have at your profile.
The log files are 552kb

Thanks

Hi guys,
My sites (many of them) have been hacked over the first weekend of the July. I am glad to see any attempt to help block these vicious attacks.

I have employed this code in one of my sites and was wondering if there are any scripts simulating any such attacks available which I can use to test this code resistance?
TIA,

JD

I updated the rules again to include conditions to match the exploits being used against com_simpleboard 1.1.0.

We can't obviously post such a code here.
Thank you for your understanding.

Please keep in mind that every .htaccess directive adds to server loads. Not only can they impact on your site performance, but several sites on a shared server running large .htaccess files are likely to get into strife with web hosts.

For nearly all the reported attacks so far, only two simple changes are necessary.

1. Turn register_globals OFF. 
You can ask your host to do this (it is a server-wide setting in php.ini) and if they will not, then people who have sites that run PHP as an Apache module can add the following to their .htaccess:



If you have components that require register_globals, you can use the Joomla globals.php emulation.  This emulates register_globals on while protecting from vulnerabilities if it is enabled through your server space.

If you are running your site under CGI then the .htaccess directive given above may not work for you. You will need to ask your host for assistance with turning register_globals OFF.

Please Note: register_globals is not, in itself, a security issue. However, some scripts have not been written to correctly sanitise input and use an "easy" globals option that leaves security holes. For those scripts, turning register_globals off will either protect them or break them.
If they break, please contact the script developer for a fix, or change scripts.

2. All Joomla extensions should be checked to ensure that all files contain the default:

Many of the intrusions have been because the 3rd party extensions allow direct access to the php code.

Additionally: To stop external access directly to components or modules you could also add this to your htaccess - it makes every access condtional on someone actually being on your site.
Note: I use this to stop content in wrappers being directly accessed from outside of the site itself, and have not tried it on components, but it should work just the same.



Replacing domain.com with your domain, of course!

Thanks for the reply. I sort of did know that posting a malicious hack code on this forum will not be possible, but what I really meant was that if there is any way to test this .htaccess tweak?

I know there are some sites (symantec,...) which will run a web-based activeX or Java program on demand to test the firewall and anti-virus functionality on a local computer and was hoping to find a similar service from a well known security firm which can test more serious security issues.
Regards,

JD

Try something like http://www.yourdomain.com/components/co ... /blarg.com

That is one of the recent vulnerabilities found in simple board and that information is available at security lists etc...

You should receieve a 403 Forbidden error

I tried it on my website, but it gives me 500 Internal Server Error, hence I had to remove this.

This gave 500 Internal server error to me, hence I had to remove.



This I have applied and site is OK. Lets wait & watch for any hacking attempts.

There are three things to look for if php_flag register_globals off throws up a 500 server error.
First - does your server allow AllowOverride Options? Some hosts may not give you those privileges, so your only option then is to ask your host to do it for you.

Are you running PHP as an Apache module? If you are running on phpSuExec or any other CGI option, the htaccess directive for register_globals won't work.

Did you edit your .htaccess file directly on your server or did you download, edit and upload? If you edit .htaccess locally make sure you use something like EditPad Lite (free) or some other editor that allows you to write the file and save in UNIX format. Windows and Macintosh editors often insert special characters that may corrupt the .htaccess file and make your site unreachable.

I am not aware about the allowoverride option set by my host. But PHP is not run as apache module and I edited the file directly on the server so that there is no question of any other character.

Ok, sorry, but the php_flag directive will only work when PHP is run as an Apache module (that is, it is run under Apache, not on CGI).

This gave 500 Internal server error to me, hence I had to remove.

[quote]
Maybe your server run phpsuexec
this give you this error
in this case you create an php.ini file with this

register_globals = Off

and upload it in the root folder

okay, here is my issue with getting register_globals OFF.

my server is running phpsuexec, which will not allow the
php_flag register_globals off
line in my .htaccess file.

so, i made a local php.ini file with the code
register_globals = Off

when i go to the backend of my site and go to system-->system info,
register globals is on.
i go to php info tag,
shows master php.ini file and local php.ini file, register_globals is on.


when i browse to a php page with the content:


It shows that register_globals is OFF for both local and master.


Why is Joomla! getting them the variable turned back on? any assistance?

Ok, people need to be aware that for the php_flag method of turning register_globals off  it requires two things.

The web host MUST allow .htaccess overrides (some don't), and
The site MUST be running with PHP under Apache.

Additional point: the directive needs to be written differently if your site is running Apache 2.

500 server errors usually mean there is a configuration error - ie. the code you entered may not have been entered correctly.
See my earlier post where I mention UNIX-friendly editors. Notepad and Wordpad should not be used for writing/editing .htaccess files.
Your server logs are really your best friend here as they will show exactly what has caused the 500 internal server error.

Now, the second issue, which also relates to what nathandiehl has mentioned with his CGI method, is this...

If you are on Apache 2.x or if your host has disabled local Apache directives in .htaccess, you will most likely NOT get an error, but your changes will have no effect. If you are unsure about whether your host will allow your .htaccess directives to run, please ask them.

Do NOT assume your .htaccess is protecting you. You need to check the output of the php.ini to ensure register_globals has indeed been turned off.

Anyone running Robs htaccess directives needs to keep a close eye on your server logs to ensure there are no unintended consequences. Remember, the .htaccess file at your server root applies to the root directory and all directories under it.

This is most likely not Joomla, Nathan. If your host has the server set up so it does not allow register_globals to be turned off locally, you wont get an error, the directive just won't work. It is something you need to ask your host.

With so many people trying to add .htaccess directives at the moment, I decided to write a brief guide to .htaccess that I hope may help.
If you go to the forum link in my sig and look at the FAQ's, you will see the guide.
It may help explain some of the issues that have been discussed here.

Elpie, thanks for promoting "register_globals = off" and bringing this to the attention of other users! There are way to few people who do that! Of course I'm in favour of having RG off, too.



I think you are missing one point here:
If you have the php RG setting switched off, it's harder for crackers to get in through files without the "defined ('_VALID_MOS') or die" statement. But many attacks can also be conducted through Joomla!. For example, having RG off serverwide but having Joomla! emulate RG=on, the latest hole in ExtCalendar could still be exploited! (For details please PM me). Edit: I might have been a bit to fast on concluding this. But still, it is always better to have RG off.

So for the future, please tell people to also switch RG emulation in Joomla! off.



@everyone:
Edit the file /globals.php. Change line 17 from:

to:


This won't break Joomla! core components, but might break 3PD components.

After going through everything, I asked my hosts to turn the Register Global = OFF , explaining them the need to do serverwide setting, for which they immediately agreed and changed the RG to OFF. Lets hope that this prevents some major attacks throgh various exploits.



When I make certain changes like to my .htaccess file, for incorrect settings, it gives me 500 Internal Server error. Does that mean my .htaccess is working properly ?

If you were to misspell something in your .htaccess file and Apache freaked out, yes, it is parsing your .htaccess file and it should therefore be working properly.

Not necessarily.
A 500 server error means one of two things - either the directive you have entered has a mistake in the syntax (that is, an error in the way it was written) OR your host has not permitted certain directives to be run in .htaccess.

There are differences between Apache 1.x and Apache 2.x that require directives to be handled a little differently, so knowing which version of Apache is running is important too.

Much depends on the way a host sets AllowOverrides in the server settings (getting errors is actually a good sign as it tells us that your host allows at least some directives to be written in .htaccess). 

I am not trying to direct traffic to my site, but there is a Guide to .htaccess in the FAQ's at Mambo Guru (use the forum link in my sig) that may help explain all this. I will talk to the mods here about posting this as a FAQ on Joomla.