When trying to change some configuration settings, I click on "save new configuration" and come to a screen that says "Authenticate" with a box for user name and password. I put mine in, and it goes back to my home page and the changes have not been made.
Can anyone help me with fixing this, please? I have looked through the forum but if this was touched on in a prior post, I couldn't locate it.
Thanks!
Can you post a screenshot of this? Doesn't sound like part of Coppermine to me.
HI, I've got the same problem since today!
Yesterday, I didn't see my Captcha Image anymore. I disabled Captcha via PHPAdmin in order to be able to login. Then I removed Captcha with the Coppermine Plugin manager. Now, when trying to make changes to my Coppermine settings, this "Authenticate" screen appears. And no changes are accepted.
(https://coppermine-gallery.com/forum/proxy.php?request=http%3A%2F%2Fwww11.file-upload.net%2Fthumb%2F29.11.08%2Fmpdmk2.gif&hash=c36cbbd55fc7bfdef4e6c6f4a5c2d2f0a9c86170) (http://www.file-upload.net/view-1284131/authenticate.gif.html)
Please help!
lumo
Screen after pressing submit button on authenticate screen:
(https://coppermine-gallery.com/forum/proxy.php?request=http%3A%2F%2Fwww11.file-upload.net%2Fthumb%2F29.11.08%2Ffo5eg.gif&hash=98c1a2a7c68ccca061f91f8b297f08797133a0ba) (http://www.file-upload.net/view-1284145/authenticate2.gif.html)
lumo
Can you zip up your admin.php and attach it to this thread please. Is your gallery up to date?
I've just updated to last version.
Here's the admin.php:
http://www.file-upload.net/download-1284208/adminphp.zip.html
btw: How can I edit posts?
greetings
lumo
You can't edit posts. Please attach files to the thread instead of using some other website.
I wanted the version of admin.php that gives you this 'authenticate' box not the clean 1.4.19 version.
Sorry, I'm new here. This is the admin.php i downloaded from my Coppermine directory. Are there different admin.php in the directory?
How can I attach a file properly?
Cheers ;)
lumo
Okay, I found out how to attach.
lumo
Hi Nibbler,
any idea what's the problem here?
Greetings
lumo
The attached file is the 1.4.19 version again. Do you actually have the original?
Could be some other script interfering (possibly accidentally), or a hack to steal admin passwords.
So then, would it be better to set up a whole new gallery and delete the old one, that is, make a new install rather than an update?
Concerning the admin.php, as I told you, I downloaded it directly from the coppermine folder (cpg148) on my webspace. I made the update to version 1.4.19 yesterday. So why are you astonished about the admin.php version?
I guess this is the only admin.php file which should be situated in the cpgxxx directory, isn't it?
lumo
You probably have been hacked before performing the upgrade - your issues sound familiar: read up http://forum.coppermine-gallery.net/index.php/topic,56516.msg276234.html#msg276234 - the user there reported the very same thing.
Please note that upgrading a gallery that already was hacked won't make the hack go away - you have to sanitize your entire webspace.
Hallo Joachim, danke für den Hinweis. Ich mach jetzt erst mal ein Backup von meinen htdocs.
Die Galerie kann ich nicht auf Wartungsmodus stellen, weil ich ja nichts verändern kann. Ich denke, ich werde von Grund auf alles neu aufbauen.
Hi Joachim, thanks for your hint. First, I'm going to make a backup of my htdoc files. I can't set the gallery into maintenance mode because of the (assumed) hack. I think I'll need to rebuild everything. :'(
lumo
It doesn't hurt if you can't put the gallery into maintenance mode. Skip that step from the sanitization instructions - it is only meant to make sure that the content of your gallery doesn't change during sanitization because of users uploading images. Starting from scratch will not automatically sanitize your webspace. The attacker may have left behind a backdoor somewhere outside of the coppermine folder. I strongly suggest that you sanitize as suggested. Only English please on this part of the forum.
May I post my first results of sanitization?
- "anycontent.php" is unchanged, although it was supposed to be. Maybe when updating to 1.4.19, I made the mistake of ovwerwriting the previous file.
- in /docs/pics I've got a file named "bridge_02_app.gif" which should not be there
- in /include I've got three unexpected files named "vote.php", "readme.txt" and "exifReader.inc.php". The "config.inc.php" was changed, I found a string of program code in it, beginning with:
<? /**/eval(base64_decode('aWY
, my database acces data left at the end of the string.
- in /logs I've got a surplus file named "security.log.php"
I moved all the corrupted (?) files to a new folder before changing or deleting them.
I replaced the messy content of config.inc.php with the text which was proposed by Joachim, and adding my data instead of the XXX placeholders.
<?php
// Coppermine configuration file
// MySQL configuration
$CONFIG['dbserver'] = 'xxx'; // Your databaseserver
$CONFIG['dbuser'] = 'xxx'; // Your mysql username
$CONFIG['dbpass'] = 'xxx'; // Your mysql password
$CONFIG['dbname'] = 'xxx'; // Your mysql database name
// MySQL TABLE NAMES PREFIX
$CONFIG['TABLE_PREFIX'] = 'xxxx';
?>
Would anyone be so kind (I know well that you are all very busy) and analyze the content of the messy config.inc.php in order to find out, what it does?
I'll continue, if I may.
Yours
lumo
I forgot one thing:
In the /include folder, "install.lock" was not empty. It contained the text "locked"
Report continued:
- Removed suspicious files from server (look above)
- replaced config.inc.php on server with "clean" version"
- replaced install.lock on server with "clean" version"
- made database update
Result: "Authenticate" screen still appears. Damn!
Then I did the following:
As I knew I had no plugins installed, but there were a lot of them (uninstalled ones) in my plugins folder (don't ask me how or when I got them ...), I decided to remove all of them.
- Removed all uninstalled plugins with the pluginmgr.php
- Tried to make changes in my config table
- Success! No more "Authenticate" window opening, config changes are accepted.
So how to continue now?
Yours
lumo
Note:
Also the file "themes.php" in my customized "gray satin" theme was affected. At the beginning of the file, I found some code that should not be there. I replaced the file with an original version of "themes.php". Are you interested in the code that was smuggled in? Tell me, so I could post a screenshot.
Thank you very much, Joachim!
No thanks, the payload is unimportant for us, as it may differ on the next attack.
Ok. I wonder what threadopener sandramichelle found out - btw. sorry for kind of hijacking your thread! ;)
As Joachim said that is not important. The more important is given in the threads on how to deal with a hack.
Hack forensics (i.e. analyzing the payload of a hack and drawing conclusions from that) is something that only very skilled people can accomplish who have a security background. In fact you need to be a hacker to understand a hacker. It doesn't make sense for you as website owner to waste time and energy to find out what a malicious script has done unless you're skilled enough to read the malicious script and understand where to look into especially. However, this approach has got a flaw: analyzing that one payload file you found to figure out what the attacker did might make you ignore other backdoors or payload files. For a thorough sanitization, you can not just review the payload file: you need to sanitize your entire webspace. If you're really concerned, ask your webhost for support. The reason for that: in the past, malicious attacks have been run against entire webserver with hundreds of shared webhosting accounts on it. If the webhost had a flaw in his mechanisms that are suppossed to shield the separate accounts against each other, one infected account was enough to infect the entire server, including areas that you as user on that shared webhosting server can't even access (root-only areas). Therefor, it's always a good idea to contact your webhost and confess that you have been hacked, even it was you who is to blame because of reluctance to update your apps. The webhost should be informed anyway - a good webhost will take this seriously and at least perform some sort of security scan or audit just to make sure his entire webserver wasn't hacked along as well.
I can understand that you are concerned and exited and want to use all resources available (including this board) that will help you bring your webspace back to normal level. However, as in previous incidents, there's no use in ranting: as far as we concerned, we can only provide the most recent fixes in a timely manner - the rest is up to you. Think of the Yikes-thread as a courtesy that actually is beyond of what you can expect from regular support boards. You definitely can't expect an analysis of the payload that was uploaded to your webserver because of your reluctance to upgrade in a timely manner. It's quite natural to try to blame others for mistakes, but you have to face the truth: it's your task to keep your website clean and up to date.
Joachim