------> IMPORTANT EE 1.5 SECURITY ISSUE <------- [Archive]

Pekka

5th of June 2006 (Mon), 17:26

As reported in http://photography-on-the.net/forum/showthread.php?t=177456 , there is a security issue which makes it possible to include remote files with EE 1.5. To make this happen your PHP must have setting

register_globals = on

and also

allow_url_fopen = on

TO TEST IF YOU ARE VULNERABLE TO THIS ATTACK:

save following code as test.php and save/upload it in your EE folder.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>register_globals test</title>
</head>
<body>
<?php
error_reporting(0);
if (!isset($x)) {
print "x is not defined";
}
if (isset($x)) {
print "x = " . $x;
print "<hr>";
include ($x . "photo.php");
}

?>
</body>
</html>

Now browse to your test.php, e.g. http://www.yoursite.com/gallery/test.php . You should see a page with text:

x is not defined

Then add in the end of the address

?x=http://photography-on-the.net/gallery/

e.g. http://www.yoursite.com/gallery/test.php?x=http://photography-on-the.net/gallery/ and click enter.

RESULTS:

If you see

x is not defined

You are ok.

------------------------------------------

If you see

x = http://photography-on-the.net/gallery/

It means register_globals is on, and allow_url_fopen = off in your php configuration. You are not affected by this specific vulnerability, but you should immediately ask your ISP to set register_globals off.

------------------------------------------

If you see

an EE gallery page (with text x = http://photography-on-the.net/gallery/ on top)

It means register_globals is on, and allow_url_fopen = on in your php configuration, you are vulnerable to this attack type, and you must set register_globals off ASAP!

CHANGE YOUR EE FOLDER NAME UNTIL YOU HAVE THOSE SETTINGS CORRECT. I will post files to fix it for those who cannot get php settings changed, in few minutes

If your ISP has set both these on then request immediately that both settings should be OFF (every decent ISP should know this without saying).

------------------------------------------

DELETE test.php from your server IMMEDIATELY after you have seen the results!

Pekka

5th of June 2006 (Mon), 17:44

Can this be done without having access to php.ini?

.htaccess with

php_flag register_globals off

should do it.

or

php_flag register_globals 0

On Apache 2 this will not work. It has to be put by your host in the VirtualHost handler for your website in httpd.conf.

Pekka

5th of June 2006 (Mon), 18:23

If you can not change register_globals download

http://photography-on-the.net/ee/files/1_5_secured.zip

and replace all files with the ones in the zip. Main thing is to have a line

include_once ("toroot.php");

on the very top portion of the php code, and make sure that there is a toroot.php in folder with that file. The zip contains many files that really do not need that fix, but I did all possible ones nevertheless.

HMetal

5th of June 2006 (Mon), 18:24

Thanks for giving folks a temporary solution Pekka. I didn't get exploited because I have had register_globals disabled.

It is never a good idea to use register_globals on anyways. Perhaps a note regarding this in the EE install file will render moot future incidents..

calvorn

5th of June 2006 (Mon), 18:37

My ISP (icdSoft) allows a php.ini in any directory where there are PHP files.

They suggest:

Unfortunately, it will not be possible to change the default register_globals value.

However, you can create your own php.ini configuration files and place them inside the folders where you need to alter the default PHP configuration. You simply need to create a file named "php.ini" in each directory where you want to customize the PHP settings, and insert the following lines inside:

register_globals = off
post_max_size = 20M
memory_limit = 80M
upload_max_filesize = 20M
max_execution_time = 120
expose_php=off

The first line turns off the "register_globals" variable, and the rest of the lines are needed for compatibility reasons.

Hope this helps.

Cal

Pekka

5th of June 2006 (Mon), 18:38

Thanks for giving folks a temporary solution Pekka. I didn't get exploited because I have had register_globals disabled.

It is never a good idea to use register_globals on anyways. Perhaps a note regarding this in the EE install file will render moot future incidents..

Yes in 2.0 there is an install checker tool that warns about register_globals if on. I think that I will make register_globals = off as REQUIREMENT to avoid any possible problems (also with server environment variables which can be _anything_ and thus able to override any variable on a whim).

Also, to reply issues you previously mentioned: yes, EE 2 will have much better security: all incoming globals are always filtered, all publicly needed include scripts are in "basecode" directory for easy folder protection, admin area warns persistently when default foldername, username or pass are in use etc. etc..

Sorry again for reacting so slowly. I was in Norway playing three concerts. Just flew back to find this happening.

HMetal

5th of June 2006 (Mon), 19:08

[...]
Sorry again for reacting so slowly. I was in Norway playing three concerts. Just flew back to find this happening.

Thanks Pekka, for the notes regarding EE2 and especially for having the foresight to use a basecode directory.

As for reacting slowly, I don't think you reacted slow and I am glad that, by Monday morning (my time), you have given people a solution to close up the exploit.

What you should be proud of is that you got this sealed up before the issue made it to Security Focus and the other security-conscious websites. At least now, when and if they do post and vulnerability notice, there is an instant solution without waiting for you to respond.

As someone running EE and a longtime PHP coder, I have to say that I'm impressed.

Good job.

kd6lor

5th of June 2006 (Mon), 19:11

Pekka, thanks for the reply. Not to sound like those who are impatient about the release of 2.0, but if the release is soon, rather than rebuilding the directories on my website to eliminate any potential problems, I would be willing to wait for EE 2.0. Is it likely to be soon?

Thanks, and thanks as always for your great software and support.

Paul Jaruszewski

segal3

5th of June 2006 (Mon), 20:04

Make sure you look through every directory in your gallery folder. There are files scattered everywhere...and some that are more than difficult to delete.

NetButch

5th of June 2006 (Mon), 21:51

My /gallery/temp folder was full of junk, and I cant delete or CHMOD any of it.. contacting my server admin to see if he can get rid of it for me. YUCK!

pukkita

6th of June 2006 (Tue), 04:09

Kudos Pekka for sorting this quickly...

For those with undeletable folders (I assume they're owned by your user):

chflags -R nouchg undeletablefolder
chflags -R nouunlnk undeletablefolder
chmod -R +w undeletablefolder

and try to delete them again.

please do

ls -lod gallery/temp
ls -lo gallery/temp/

and paste the output here, that way will be easier to post a find command that resets the permissions in order to easily delete the offending files.

chriz

6th of June 2006 (Tue), 05:01

I get this response in the browser window:

"; include ($x . "photo.php"); } ?>

And the title of the window is register_globals test - Mozilla firefox

chriz

6th of June 2006 (Tue), 05:37

Sorry, renamed the test file to test.php rather than test.htm and got as result:
x is not defined.

::John::

6th of June 2006 (Tue), 07:59

Thanks for that.

Register_Globals set to off now.

devenh

6th of June 2006 (Tue), 09:43

My ISP told me they could not make the change to .htaccess at the server level and advised me to change my local .htaccess file. I did so and this worked.

Deven

jseaman

6th of June 2006 (Tue), 10:50

I believe I've fixed mine ... I'm just glad I happened to stop in here to visit and noticed the threads on this issue.

Perhaps it might be a good idea to collect email addresses from those who dload EE or who are members of this board so that a very low volume email list can be created for notifications such as this?

xahmol

6th of June 2006 (Tue), 16:00

Just tested...phew...no problem here.

Set register_globals on off a long time ago as almost all PHP scripts I have ever used told me to do so for security reasons.
So why did this only now pop up with EE? Just a too unknown target before?

Pekka

6th of June 2006 (Tue), 17:38

So why did this only now pop up with EE? Just a too unknown target before?

Yes, apparently someone was deliberately seeking for ways to compromise the code. Competition is rough :)

kd6lor

7th of June 2006 (Wed), 00:14

My ISP told me to do this...

Create a PHP.ini that has the contents

register_globals = Off

and place that file in my public_html directory.

Also add this to my .htaccess file

suPHP_ConfigPath /home/melor/public_html

order allow,deny
deny from all

but now my server gives me an error msg
======
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster@melor.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
===========

so either I have a syntax error in the addition to the .htaccess file ( they were a little sketchy on the placement of the brackets, or possibly the fix is not a valid one.

Paul

shaun3000

7th of June 2006 (Wed), 09:55

Yes, apparently someone was deliberately seeking for ways to compromise the code. Competition is rough :)It was a disgruntled EE 1.5 RC4 user trying to hurry along the release of EE 2.0. ;) :lol:

Lenni

7th of June 2006 (Wed), 12:21

I replaced the existing with files in 1_5_secured.zip files in my server as required.
I tested with test.php file as explained.
However, I got the worst result, an EE gallery page (with text x = http://photography-on-the.net/gallery/ on top.

Then I also updated the htaccess.txt following the instructions.

However, I got the same result. I checked the server, and there is
register_globals = on as well as
allow_url_fopen = on

It is an Apache server, the version I don't know.

Is there anything I made wrong or what should I try next?
toroot.php is also there.
Is the only way to try to get the admin to change
register_globals = off
and
allow_url_fopen = off

Lenni

Pekka

7th of June 2006 (Wed), 13:33

I replaced the existing with files in 1_5_secured.zip files in my server as required.
I tested with test.php file as explained.
However, I got the worst result, an EE gallery page (with text x = http://photography-on-the.net/gallery/ on top.

Then I also updated the htaccess.txt following the instructions.

However, I got the same result. I checked the server, and there is
register_globals = on as well as
allow_url_fopen = on

It is an Apache server, the version I don't know.

Is there anything I made wrong or what should I try next?
toroot.php is also there.
Is the only way to try to get the admin to change
register_globals = off
and
allow_url_fopen = off

Lenni

Please note that test.php result is not changed by upoading 1_5_secured.zip! The zip contains fixed files to prevent this attack, but there is no saying they will find new ways later. Test.php tells you php setting effect, nothing else.

register_globals = off is all that is needed. Your server admin MUST be able to set it so on your server.

Lenni

7th of June 2006 (Wed), 14:48

Pekka,

Thanks a lot for your help.

I will ask them to do it.

Lenni

segal3

7th of June 2006 (Wed), 19:46

The file should be named .htaccess, not htaccess.txt.

DavidW

8th of June 2006 (Thu), 10:50

It depends on the operating system. Pekka develops on Windows, I believe, and Apache on Windows probably expects the file to be htaccess.txt.

On any UNIX flavour, you should rename the htaccess.txt files to .htaccess

David

Lenni

8th of June 2006 (Thu), 15:19

Changed to .htaccess

Requested the operator to change on server also register_globals = off, now confirmed by the admin.
Now the test reult OK.

Thanks everybody for help!
Lenni

tommykjensen

8th of June 2006 (Thu), 16:41

I closed the hole with the .htaccess file on my site but am wondering if the file need to be in all subfolders or is it only required in the root folder of EE?

Suppose I request my host to set globals off on server level will it then be possible to set globals on if some software need it on to work? ( I am just asking before I send the request to my host so I can use that as an argument that the customers that want to take the risk can do so by setting the globals parameter on where they need it).

neil_r

8th of June 2006 (Thu), 18:03

I was away on holiday so this was all a bit too late for me and I now have a suspended domain.

Pekka

8th of June 2006 (Thu), 18:18

I was away on holiday so this was all a bit too late for me and I now have a suspended domain.

They will reopen it as soon as the security hole is plugged. Give them the address to this thread for an overview and remedy.

malum

9th of June 2006 (Fri), 13:04

My host said this when I enquired

Popular applications such as OScommerce and Zencart require register globals on.

If your scripts are probably coded there are no additional security risk to having register globals on.

Pekka

9th of June 2006 (Fri), 14:34

My host said this when I enquired

http://www.oscommerce.com/community/contributions,2097

Zen Cart specifically ASK USERS TO SET register_globals OFF in installation setup. Pages like http://www.nexcess.net/hosting/support/tutorials/zencart/1.2.0d/ saying "You should now see that all of the errors have gone away except for the 'Register Globals' warning, which you can safely ignore." are ignorant of this.

malum

9th of June 2006 (Fri), 15:34

http://www.oscommerce.com/community/contributions,2097

Zen Cart specifically ASK USERS TO SET register_globals OFF in installation setup. Pages like http://www.nexcess.net/hosting/support/tutorials/zencart/1.2.0d/ saying "You should now see that all of the errors have gone away except for the 'Register Globals' warning, which you can safely ignore." are ignorant of this.
My host would seem to be ignorant of this too.
They also tell me I cannot turn it off locally.

I am not at risk from this exploit because the allow_url_fopen = off

I cannot install the fixed files though as I have heavily modified my install and it would be an awful lot of work

Pekka

9th of June 2006 (Fri), 18:25

I cannot install the fixed files though as I have heavily modified my install and it would be an awful lot of work

Just make sure every file public can open has a line

include_once("toroot.php");

in beginning. Also, make sure there is toroot.php in that directory.

OR add

$toroot = "./";

to the beginning of each file on gallery root, and

$toroot = "../";

to the beginning of each file on first level folders

MikeCaine

10th of June 2006 (Sat), 12:04

A further thought about the hack - I now always have my ftp software set up to show hidden directories. I've been hacked twice, both times through a hole in some software, and both times hidden files and folders were created.

On my Mac using Transmit it's a simple case of chosing "Show hidden files" and on my PC using WS_FTP I use -al as the remote file mask. That way I hope to be able to spot any hidden files that shouldn't be there

yosemite

10th of June 2006 (Sat), 13:15

mike,

do you know if the cpanel that many isp's use will show hidden files and folders? how about aceftp, will it show these as well?

my isp is lunar pages whom i have been very happy with. the only problem is that their default is globals=on. they have been very quick replying to any problems i have had and really helped on this security issue, i guess i cant ask to much for $7 a month as far as backups go. i did discover backups in the cpanel though and just created one.

MikeCaine

10th of June 2006 (Sat), 15:11

Good point - as far as I can see cpanel's file manages does show hidden files and folders.

I'm no expert, but as far as I know in unix files and folders that start with a . are normally hidden and cpanel seems to show these by default. I don't know how it works on Windows servers.

yosemite

10th of June 2006 (Sat), 16:33

i did see those .folders when i used aceftp to delete all the crap. i did not know they were supposed to be hidden.

MikeCaine

11th of June 2006 (Sun), 05:50

A further question - If I use a .htaccess file containing a line to turns the globals off, does that need to be in every directory under gallery, or is it OK just to put in in the gallery root directory?

I only have it in my root directory at present as I've assumed it work in the same manner as when you control access to directories and that add directories underneath the root one are also protected.

Could someone confirm if this is the case with the globals=off please?

Pekka

11th of June 2006 (Sun), 07:08

A further question - If I use a .htaccess file containing a line to turns the globals off, does that need to be in every directory under gallery, or is it OK just to put in in the gallery root directory?

I only have it in my root directory at present as I've assumed it work in the same manner as when you control access to directories and that add directories underneath the root one are also protected.

Could someone confirm if this is the case with the globals=off please?

Only safe way is to test (run test.php in a folder). Usually htaccess rules effect all folders below it.

ITC

14th of June 2006 (Wed), 11:54

Pekka

I ran test.php and got x is not defined
I ran ?x=photography-on-the.net/gallery/ and got a gallery page (the worst result)

However when I run an info script to show me my PHP configuration both register_globals and allow_url_fopen are set to OFF both locally and globally. I have tested it and I can change both of these values with my php.ini file.

Am I doing something wrong???

I want to be sure that I have this security hole patched correctlly and I prefer not to have to replace alot of files if possible.

Thank you for your help with this matter.

Pekka

14th of June 2006 (Wed), 12:38

Pekka

I ran test.php and got x is not defined
I ran ?x=photography-on-the.net/gallery/ and got a gallery page (the worst result)

However when I run an info script to show me my PHP configuration both register_globals and allow_url_fopen are set to OFF both locally and globally. I have tested it and I can change both of these values with my php.ini file.

Am I doing something wrong???

I want to be sure that I have this security hole patched correctlly and I prefer not to have to replace alot of files if possible.

Thank you for your help with this matter.

The php.ini you edit might not the one your php is using. For example Zend accelerator changes php.ini path, and so do many control panels. The test.php tells the "truth": in technical terms if x can be defined without $_GET then globals ARE on.

ITC

14th of June 2006 (Wed), 12:42

Thank you for your reply.

mandarinfish

14th of June 2006 (Wed), 12:49

Pekka, if I turn allow_url_fopen off, then when I bring up a photo from the gallery, using photo.php, I get "photo is temporarily unavailable" where the photo should be. Is there something else I need to tweak to get this to work when allow_url_fopen = off?

thanks...

Pekka

14th of June 2006 (Wed), 13:23

Pekka, if I turn allow_url_fopen off, then when I bring up a photo from the gallery, using photo.php, I get "photo is temporarily unavailable" where the photo should be. Is there something else I need to tweak to get this to work when allow_url_fopen = off?

thanks...

In Misc settings set (global settings) "When image file is not found" to setting 1. Set also (photo page settings) "Clicking a big photo gets you" to "the next photo".

mandarinfish

14th of June 2006 (Wed), 14:41

That fixes my issue. Thanks, Pekka!

seanspeng

14th of June 2006 (Wed), 18:57

Pekka,

I have a question regarding the Permission on some of the folders. Currently EE program have set permission 777 for folders like
/export/
/upload/
/upload/test/
/upload/ee_temp_upload/
/ftp_temp/
/temp/

My EE site got backed into the /export/ folder because it's permission was set to 777. I changed it to 755 now. But should I change the permission to 755 for folder /upload/ and all its subfolders?

Pekka

14th of June 2006 (Wed), 19:17

Permission stuff goes like this:
777 or 776 usually is needed for temp folders. You could try stricter permissions, in some servers they might work. I do not like to put anything 777 but this is a requirement by PHP so that it is able to list folder contents and write files in folders. All other folders can be 755 and php files read/execute only (was it 655 or...). When upload is done from EE (or any other ftp write), all written photos get suitable permission from ftp server's setup file.

seanspeng

14th of June 2006 (Wed), 19:25

Pekka,

Thanks for your explanation. I still do not fully understand if I should change the permission for directory /upload/ and its subdirectory to 755 or not. If I change them to 755, the upload function in EE won't work. If I leave them at 777, I am very concerned because my site got hacked into twice in the past month due to some folder permission of 777. Someone was able to upload some script in and create problems.

Thanks!

Pekka

14th of June 2006 (Wed), 19:46

When your site is hacked with php it is possible to write files to 777 folders. If you are on Windows server they can write on any folder. But there is no way around php's limitation that it can not write files to normal folders in UNIX. Upload works with ftp, but it needs to create temporary files somewhere. PHP is "public" user on your server.

Read permission is required in order for a user to view the contents of the directory. Write permission allows a user to create or remove files within the directory.
Execute permission is required in order to access the directory at all

I could avoid php file functions totally with all-ftp system, but I have to think is it worth putting time to do and test it - instead of relying that server owners secure their php, keep it and apps up-to-date, keep input folder renamed etc.

Simple option would be to write a small funtion which would change the folder permission when needed and put old permissions back when not needed. Let's see..

seanspeng

14th of June 2006 (Wed), 19:51

Ok, I think I found some answer from your reply. So you are saying if we changed the /input/ folder renamed then there won't be a problem with the /upload/ folder because it's within the /input/ folder, so hackers won't find it even it is 777 permission, right?

If that's the case, what about these folders:
/export/
/ftp_temp/
/temp/
/test/

These I believe were 777 out of box, and they are not hidden under input folder. Should we leave these permission to 777 or 755?

Many thanks for your patience in helping me.

Pekka

14th of June 2006 (Wed), 20:32

All those folders have a purpose and also a reason why they need to be in public "side" of EE. No one can do anything with them unless they are already hacked your server. In other words, 777 means someone from within SAME server can alter it (and that would be logged).

seanspeng

14th of June 2006 (Wed), 20:45

So that means those folders have to stay at permission 777?

If these directory are left set to 777, it is quite simple to upload files to it through php exploits, such as php proxy. In this case, they don't have to be within the server.

Let's hope the new 2.0 version come with some extra security feature...

Pekka

14th of June 2006 (Wed), 21:09

No, you can not write anything to 777 folder from outside the server. There is no filehandling php app that does NOT need 777 on folders it works with. It is just needed because php works so.

seanspeng

14th of June 2006 (Wed), 21:20

Pekka,

I do not fully understand the issue. And thanks for your explanation.

Just wanted to let you know that we were "hacked by IGNOR3" (if you do a search on google) with the php proxy script from http://www.whitefyre.com/poxy/ . That is why I was so concerned about it.

Pekka

14th of June 2006 (Wed), 21:51

PHProxy - Anonymizing PHP Web Proxy
"The server that this script runs on simply acts as a medium that retrives resources for you"

How nice that some people write stuff like that!

I think it goes like this (I'm not a hacker): You have a flaw in program and couple of php settings "wrong". Someone uses the flaw to get their own file included (= run on your server). The included file is retrieved from PHProxy server to hide its origin. The new file starts feeding stuff, they may use PHProxy for it, too.

Pekka

14th of June 2006 (Wed), 21:53

And finally, I assure you that I take all these things very seriously. My server runs EE just like yours. And I will think of ways to make possibility of an attack as small as it can be done.

seanspeng

14th of June 2006 (Wed), 21:55

And finally, I assure you that I take all these things very seriously. My server runs EE just like yours. And I will think of ways to make possibility of an attack as small as it can be done.

Many thanks! That's all we need to know. And I just wanted to share all the information for your reference. I know fighting with hackers is never ending job...

tgillilan

18th of June 2006 (Sun), 10:01

If you can not change register_globals download

http://photography-on-the.net/ee/files/1_5_secured.zip

and replace all files with the ones in the zip. Main thing is to have a line

include_once ("toroot.php");

on the very top portion of the php code, and make sure that there is a toroot.php in folder with that file. The zip contains many files that really do not need that fix, but I did all possible ones nevertheless.

I uploaded via FTP, and overwrote all files that it asked ofr, and I do not pass the "test.php" as directed. I get your gallery page in the test???????????

Pekka

18th of June 2006 (Sun), 10:08

I uploaded via FTP, and overwrote all files that it asked ofr, and I do not pass the "test.php" as directed. I get your gallery page in the test???????????

Yes of course. The test.php tests your php settings, not EE. The fixed files prevent the attack of this kind, but they do not change your php settings.

tgillilan

18th of June 2006 (Sun), 10:26

Yes of course. The test.php tests your php settings, not EE. The fixed files prevent the attack of this kind, but they do not change your php settings.

Ok, thanks. As long as I am not vulnerable to this kind of attack, then I will leave the php settings.

If I am not vulnerable to the current attack, then should I still change my php settings?

Pekka

18th of June 2006 (Sun), 12:29

If I am not vulnerable to the current attack, then should I still change my php settings?

Yes. This way you close one potential security problem for all php apps and unknown exploits using this method.

malum

19th of June 2006 (Mon), 10:59

according to your test mine had register globals on and allow_url_fopen = off, which should have left me OK.
I went on holiday thinking I'd plug the hole when I return as it wasn't urgent.
Got hacked while away and the site suspended.

I have just restored everything and fixed the files with the toroot thingy.

Buggered if I can restore the database though.
It's only small (2.3MB) and I have removed all the uncookied data.

Just sits for ten seconds and returns a blank screen in EE backup
in PHPmyadmin in just sits for tens of minutes and then times out

I'm tearing my hair out here :lol:

Edit

I managed to restore by splitting the file, seems odd to have to split a file so small.

OneNoneBlond

20th of June 2006 (Tue), 17:37

Hello!
My gallery, and not only gallery, got hacked from South Arabia last week. Fortunately no loss of data, but some mass mailing and unpleasant discussions with my ISP. :-(
Anyway, I did almost all as suggested in this forum and hope that my site will stay untouched from now. :-)
Pekka, you changed my opinion about musicians, as my sister is a professional violinist and has huge problems sending an email! ;-)
Want to thank you for your support, reaction time, professionalism and your huge knowledge which allows us to present our photos in such a gorgeous way!
THANK YOU VERY MUCH!
Best regards!
Sanja
www.sanja.name

Darter

22nd of June 2006 (Thu), 09:40

For those with undeletable folders (I assume they're owned by your user):

chflags -R nouchg undeletablefolder
chflags -R nouunlnk undeletablefolder
chmod -R +w undeletablefolder

and try to delete them again.

My host (1and1) did not have chflags available, and the above chmod command gave me the "permission denied" error. I tried just this and it worked:

chmod -R +rwx undeletablefolder

OneNoneBlond

23rd of June 2006 (Fri), 14:46

If you can not change register_globals download

http://photography-on-the.net/ee/files/1_5_secured.zip

and replace all files with the ones in the zip. Main thing is to have a line

include_once ("toroot.php");

on the very top portion of the php code, and make sure that there is a toroot.php in folder with that file. The zip contains many files that really do not need that fix, but I did all possible ones nevertheless.

Pekka,
I changed register_globals but now my booking-script is not working anymore (http://www.island-cres.net/de/anfrage.php). I also downloaded 1_5_secured.zip and updated all files within it. If I remove register_globals from .htaccess am I vulnerable again? Sorry for inconvenience, but I'm pretty scared since the attack.
Many thanks!
Best regards!
Sanja

richx

24th of June 2006 (Sat), 17:28

Thanks for the patch pekka! I just discovered someone had intruded my account and installed the eggdrop IRC script into my export folder, for God knows what reason! I also found the "ch99shell" tool installed. I didn't know what it was at first - but I tried to download it off my server. Didn't bother to do the same with the IRC script.

It scared the socks off me to find out what the ch99shell could do. The guy who uploaded it was dumb enough to put in a username, and that showed up in my logs. Normally the only logged user in my web server would only be my EE account, but suddenly there was a "michael".

I panicked. I changed permissions, deleted what I could, and renamed what I couldn't. Decided to read this forum, and patched the gallery script. Couldn't find a way to delete the eggdrop files still, and figured out I could re-use the guy's ch99shell to my advantage.

Changed the filename, username and password and re-uploaded it to my account. And what do you know - finally erased that darned eggdrop installation for good, and removed the ch99shell again. Let's hope that's the last I'll hear of "michael". At least he didn't damage my gallery content!

Cheers and thanks! :)

Edit: I don't like to moan and complain, because everything after the patch seems to work properly, _except_ the lens information popup! When I click on it, I receive the an error that says "INSTALL ERROR: DEFAULT LANGUAGE 'eng' NOT AVAILABLE". Any idea what I can do about this? Thanks!

MikeCaine

26th of June 2006 (Mon), 15:13

When I click on it, I receive the an error that says "INSTALL ERROR: DEFAULT LANGUAGE 'eng' NOT AVAILABLE". Any idea what I can do about this? Thanks!

I had the same problem in my thread at
http://photography-on-the.net/forum/showthread.php?t=178401

Turns out I was missing some folders. Don't know if the hack deleted them, at the time I assumed that I hadn't re uploaded them after wiping the folder post hack

Jussuff

27th of June 2006 (Tue), 11:54

I was contacted and informed by my ISP yesterday regarding a phishing activity originated from my account. After checking the forum here I downloaded Pekka's "1_5_secure.zip" and uploaded the files to my EE installation.

Is that it or what do I have to do / check / install further on? Sorry, but I have no clue what is required in such a case as I am just an amateur photographer who loves Pekka's piece of software. :confused:

Any hints for me?
J.

OneNoneBlond

27th of June 2006 (Tue), 14:03

I was contacted and informed by my ISP yesterday regarding a phishing activity originated from my account. After checking the forum here I downloaded Pekka's "1_5_secure.zip" and uploaded the files to my EE installation.

Is that it or what do I have to do / check / install further on? Sorry, but I have no clue what is required in such a case as I am just an amateur photographer who loves Pekka's piece of software. :confused:

Any hints for me?
J.

Hi!
just read the post in this threading, here, and you'll get the idea what is needed to close security hole.
good luck!

MikeCaine

28th of June 2006 (Wed), 05:07

Is that it or what do I have to do / check / install further on?

You'll probably still have the files that the hackers uploaded to your website, unless your ISP has deleted them for you.

What these files are would depend on who hacked you and what they did, we won't all have been hacked by the same people even though they all used the same vulnerability.

These files / folders are likely to be hidden by starting their name with a period "."

cpanel's file manager seems to show them or you might have to set up yout ftp sofware to show hidden files

Samiad

24th of July 2006 (Mon), 12:13

Can you believe this...after I plugged the exploit many weeks ago (after being hacked) I got hacked again last night, and my web account suspended. My webserver "support" had decided to change my .htaccess file for some unknown reason and re-enable the exploit!

And they blame me!

Samiad

24th of July 2006 (Mon), 12:16

Okay - important question.

Previously I plugged this exploit by editing .htaccess in my webroot folder. This took effect in all subdirectories under root.

Now I have had to resort to using php.ini - but this only takes effect in the current directory where php.ini resides! How can I make PHP.ini apply to all subfolders, or alternatively, where are the minimum places I need to put PHP.ini?

tommykjensen

24th of July 2006 (Mon), 12:16

Can you believe this...after I plugged the exploit many weeks ago (after being hacked) I got hacked again last night, and my web account suspended. My webserver "support" had decided to change my .htaccess file for some unknown reason and re-enable the exploit!

And they blame me!

I would say it is time to kick that host and find a new.

tommykjensen

24th of July 2006 (Mon), 12:17

Okay - important question.

Previously I plugged this exploit by editing .htaccess in my webroot folder. This took effect in all subdirectories under root.

Now I have had to resort to using php.ini - but this only takes effect in the current directory where php.ini resides! How can I make PHP.ini apply to all subfolders, or alternatively, where are the minimum places I need to put PHP.ini?

What about the fixed files Pekka posted. Have You uploaded those? They should close the exploit.

Samiad

24th of July 2006 (Mon), 16:28

Actually I haven't - I have customised some files so I'd have to be careful before doing that.

I've gone through a bunch of folders and uploaded php.ini's - was just wondering if there was a way to make it control subfolders as well.

It doesn't help that I have two EE installations on this host :(

DavidW

29th of July 2006 (Sat), 18:25

Back up the EE folder, diff your customised files against the original 1.5 release archive and save the output to a file (unified diff is usually the best - diff -u), install the fixed files from Pekka, use patch to install your customisations again. Check the output from patch to see that it's managed to apply all the chunks in the file correctly.

David

jetli91

9th of August 2006 (Wed), 12:57

.htaccess with

php_flag register_globals off

should do it.

or

php_flag register_globals 0

Hi,
Whenever I add any of the following line to my .htaccess (locate under my public_html directory), I would get the following message and my web page would stop displaying. Please advise ...

php_flag register_globals off
or
php_flag register_globals 0

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@thlphotography.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

UPDATE:
Ok, I followed the instruction to add php.ini inside gallery and it work

register_globals = off
post_max_size = 20M
memory_limit = 80M
upload_max_filesize = 20M
max_execution_time = 120
expose_php=off

thx

offrench

30th of November 2006 (Thu), 11:01

I still use version 1.22. I have modified it a lot and can not upgrade without a lot of additional work.

I have asked my ISP to have both parameters changed, but do not know if they will be able to do it (I am using shared hosting)

Is there any other way to fix the problem?

Also, I have read about the vulnerabilities from Secunia (http://secunia.com/advisories/15583/)
I do not use photo_comment.php nor styles.php
I only use list.php to navigate between the pages (with the long url with valists). The other ones have been rewritten.

I guess my install is still vulnerable, but the 7 guys who searched Exhibit engine 1.22 in Google this week and found my website did not figure out how to hack it... yet.

Pekka

30th of November 2006 (Thu), 11:08

Upgrade to 2.01 ASAP.

offrench

30th of November 2006 (Thu), 11:23

Would setting register_globals to 'off' solve all the problems on 1.22?

I will make a local install of 2.01 to test it but it will take me some time to get the same result as from my customized 1.22...

Pekka

30th of November 2006 (Thu), 13:17

There are LOTS of new code in EE 2 aimed to make it as secure as possible, user login, spam filtering, input data sanitation etc. Well worth the upgrade effort.

wkitty42

2nd of December 2006 (Sat), 14:11

not to mention all the other new capabilities as well as look and relative ease of customization of the look with CSS... eE v2 is a huge advantage over previous eE releases... in many more ways than the few expressed here...