There was an error while processing a database query There was an error while processing a database query
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

There was an error while processing a database query

Started by Acen8s, June 07, 2010, 01:38:05 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Acen8s

I've been trying to solve this issue for several days now and came up empty. My <a herf="http://www.pro-dezign.com/coppermine/index.php">Gallery</a> contains nudity so be aware before visiting. My web host informs me that it's not a server problem and they can not help.

The error message is ( mySQL error: Unknown column 'owner_name' in 'field list' ) I did a table repair in phpmyadmin but that didn't help. There is also a message that say's ( coppermine/include/functions.inc.php - Line: 250  ) so I replaced that file and that didn't solve the issue either. I am not posting the debug output until it's requested. I would appreciate any advice as to how to remedy this issue.

Thanks

Joachim Müller

Your site is still being reported as virus-infected by our corporate malware protection tool, so I can't access it. If a database table is marked as crashed and needs to be repaired, this definitely is a webhosting issue. Tell your webhost that your issue doesn't lie in the application, but on database level. Ask them to solve this issue for you. You're welcome to show them this thread as well.

onthepike

Looks to be an error displaying only thumbnails-XX.html as clicking on all displayimage-XX.html renders normally.

Perhaps a corrupt plugin? Try disabling them one at a time and verify. You may need a plugin update.

I ran your site through Norton Safe Web, Trend Micro Online Scan and Unmask Parasites; all returned "clean" ratings, though that could change at any moment. As well, neither AVG nor NIS reported any malicious download attempts locally.

Again, check your plugins. Disable them one-by-one and verify correct working order. Update as necessary, if applicable.


Joachim Müller

Most likely the SEF_URLs plugin is to blame in this aspect.

Acen8s

Thanks for the replies. I tried removing and replacing the plugins that I'm using but that doesn't seem to be the problem. I'm still getting the error message on all albums and uploads. I've also contacted my webhost again and they claim to be looking into it. I'll post the results when available.

onthepike

Your gallery is still virus-laden. Your site is still infected. Joachim Müller's initial response lead me in another direction after your plugin changes resulted in no change.

Your albums directory contains a re-direct to a trojan download. At least one of which can be found in your (admin) albums/userpics/10001/ directory (URL edited for obvious reasons).

You must fully sanitize your webspace by following these directions carefully.

I suspect a slew of .htaccess files in there along with a host of other files and folders that don't belong there.

Note however, I did not inspect your entire gallery. It's not necessary. Once one single hijacked file is found, the recourase is standard and linked above.

Let us know when you have removed the threat(s).

Jeff

Acen8s

I have followed the directions for sanitizing my gallery but their is 1 file in "coppermine" named "open" that I have no control over. I can't open, delete or change permissions. I think that this is probably the culprit and my webhost is of little help. Any idea how I can get rid of this file.

Thanks for all the help and suggestions.

onthepike

Check the permissions and the owner of the file(s) in question and make necessary changes from within your hosting account's admin panel (usually cPanel or equivalent). Most times, FTP apps will not have the ability to modify these files, especially if you must take ownership first.

Your host really should be able to help you here.

phill104

I agree. If this is indeed a dodgy file then it is in your hosts interests to delete it for you. If they simply cannot be bothered then that must say something about the quality of their service. I know I would not want to pay money if that were the case.
It is a mistake to think you can solve any major problems just with potatoes.

onthepike

Phil, I ran a review of his/her hosting company and it turns out to be "Wild West Domains" which is a sister-company and acting reseller to GoDaddy. And in my opinion, GoDaddy is among the worst web hosts out there today. But personal opinion aside, I don't believe the OP will receive much support from WWD because they're basically interested in reselling/revenue and their customization effort is 100% geared in that direction.

Take a read here: http://www.tiawood.com/articles/domain-reviews/45/318-godaddy-reseller-review-wild-west-domains.html

I understand that this topic has drifted, but I'd respectfully request the powers-that-be here to allow the thread to remain, and possibly move it to another sub-forum where this issue can hopefully be resolved for the OP. Once this issue has been resolved, perhaps create a new topic dealing with the issue, if it's still an issue after cleansing.

[/ opinion]

Jeff

onthepike

More information:

Your site: http://www.pro-dezign.com
Unmask Parasites Report: http://www.unmaskparasites.com/security-report/?page=www.pro-dezign.com
Google Search Results for "holasionweb.com/oo.php": http://www.google.com/search?num=100&hl=en&newwindow=1&safe=off&client=firefox-a&hs=FB8&rls=org.mozilla%3Aen-US%3Aofficial&q=holasionweb.com%2Foo.php
Virus Total Results: http://www.virustotal.com/analisis/e21220af693453f41a28bce9054967e9026926c5860b6adb28dcfa676daf9c42-1273758041
Related: http://forum.joomla.org/viewtopic.php?f=432&t=515398

Website offering removal tool: http://www.danielansari.com/wordpress/2010/05/holasionwebcom/

It appears that this issue, although related above to instances of WordPress and Joomla is not limited to those applications. In reading the messages contained within the search results, others have noted that this threat is potentially dangerous to most php scripts.


Joachim Müller

Well done on collecting all that material and researching this case, excellent work. Maybe you could come up with a concise posting to be merged with the Yikes thread that contains a summary of what you posted above without relation to the current case. Thanks in advance

onthepike

Would be happy to do just that and will post the details (and replace this response) tonight.

Acen8s

My site is working properly again thanks to Jeff. Their may be some other problems to work out but after a week I'm at least able to connect to my database.  Jeff told me how to add the missing table to my phpMyAdmin and it worked like a charm. I would like to thank everyone who helped me with this snafu but the real kudos goes to Jeff. I would have never worked this out without his help.

I added this table:

Field: owner_name
Type: varchar(40)
Collation: latin1_swedish_ci
Attributes: *NONE - LEAVE BLANK*
Null: No
Default: *NONE - LEAVE BLANK*
Extra: *NONE - LEAVE BLANK*



The problem is solved.

onthepike

Glad to help. Wasn't sure if I had the ability to narrow down the problem (apparently caused by the initial hack) without admin access. The error message was pretty blatant; there was a corruption to the owner_name table rendering it useless. Manually rebuilding the table solved the present issue, but does nothing to prevent it from happening again.

That problem was solved by finally deleting the /open/ directory installed at the time of the hack, by the web host. Remember, while that directory was still on his server, his server remained vulnerable to repeat attacks and infection. It acted as a private portal in many respects.

A combination of these factors, with the addition of CPG thread drift and the fear of topic locking prompted me to assist off-forum until we could at the very least, get that /open/ directory off the web space. That has been done. As, apparently, has a full update and full web space cleansing afterward.

I'll post all the generic details tonight as compiled.

Jeff

onthepike

Quote from: Joachim Müller on June 11, 2010, 07:58:40 AM
Well done on collecting all that material and researching this case, excellent work. Maybe you could come up with a concise posting to be merged with the Yikes thread that contains a summary of what you posted above without relation to the current case. Thanks in advance

Writing this actually proved much more difficult than I anticipated, because each infected website I've handled over the years is somewhat unique in that although the hack might be a widespread generic trojan or some XSS or other injection, the outward results of the infection can run the gamut. Really, no two infections duplicate the exact same symptoms, so a lot of legwork (searching, guessing, experimenting) goes into trying to identify malware; especially those that are "hidden".

What makes this more difficult is trying to maintain a "generic" approach. I use the process of elimination system; always. Look for the obvious first, then dissect slowly. And I search, search and search some more until I find something -- anything that might be relevant and go from there.

Anyway, here's my attempt to outline my steps without using this instance as a reference. Take what you wish, modify as necessary and edit to suit. I hope it helps.

Quote
Steps in attempting to identify a potential threat and/or embedded malware.

First and foremost, a few things bear repeating: You, as a webmaster, regardless of skill level, are responsible for your website, and responsible for the safe passage of visitors to and from your web space. You are responsible for maintaining a safe environment, which means, but by no means is limited to, keeping whatever applications/scripts/programs you have running (or available) as up-to-date as possible. Do not expect your web host, a volunteer or anyone else to come to your rescue should disaster strike. A good webmaster understands these basic principles and takes steps towards that end.

These steps include keeping all scripts up-to-date by regularly visiting that programs homepage and/or support forum and subscribing to their newsletter (if applicable). These steps include setting proper permissions on files and directories. These steps include removing old or unused scripts from the web space (or removing read/write access to these scripts if they are necessary for documentation purposes).  These steps include backing-up. It cannot be stressed enough how important it is to regularly back-up your files. While it can be very time consuming to fully back-up your web space, consider the alternative -- being directed to this thread overwhelmed with fear, frustration, anxiety, stress and confusion. Weighing these, backing up really isn't that bad after all! And in some cases, may be your only recourse in reviving a site that's been infected with malware, etc.

The above topics have been covered within this Yikes thread. This post deals with actually identifying a (hidden or otherwise) threat that's embedded in your web space. The webmaster, of course, has (or should have) full and complete access to the servers file and directory structure. As a site visitor, options are much more limited and restricting. Still, there are available tools to help identify potential threats. Some are outlined below:


  • Unmask Parasites: Scans entered website seeking embedded malware, known signatures and potential unsafe links and redirects.
  • Norton Safe Web: Similar to above, however relies on cached results based upon prior automated scanning. Also allows comments from registered users, which can prove helpful.
  • Google Safe Browsing Diagnostic: Cached results of malware scanning.
  • McAfee Site Adviser: Uses a cached database to display results of previously scanned websites.
    Trend Micro Web Reputation Search: Similar to Norton Safe Web and uses cached results.
  • Virus Total*: Virus Total is a service that analyzes suspicious files  and facilitates the quick detection of viruses, worms, Trojans, and all kinds of malware detected by anti-virus engines. Works in real-time as well as cached results. *Note however, this tool is best suited for webmasters in most cases.

In addition, an excellent supplemental article to this Yikes thread, and a generally informative outline regarding repairing an infected website can be found here: How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions. Extremely large galleries with many hundreds or thousands of files and folders may benefit from utilizing cron to list all the files in your (Linux) website, where the output may be visually inspected to verify no rogue files/folders and their permissions.

Important: Before attempting to resolve a website issue, it is imperative that you first activate the anti-virus program of your choice and update it to the latest definitions. Activate your backup anti-malware program (such as Malware Bytes and/or SpyBot Search & Destroy's IE Resident -- if applicable) and fully scan your computer to identify and resolve threats there before accessing an infected website. It makes no sense to cleanse a website of an infection that your own PC may re-infect upon access. Resolve your PC issue(s) first, then move onto your website issue. After successful scanning of your virus-free computer, and using each of the tools listed above, carefully scan the infected website.

As a visitor, I begin with Unmask Parasites, a scanner that uses both cached results from previous scans as well as real-time scanning to identify possible threats and suspicious links (to known malware sites).  The scanner will display results as well as potential suspicious links and scripts. Viewing the source code of a given page will accomplish some of what Unmask Parasites accomplishes, but doesn't "red flag" anything. A supporter or helper has no way of knowing what external links are legitimate and what external links are problematic. Unmask Parasites (as well as the rest of the tools) will highlight these for you for later review -- or in some cases -- provide an in-depth explanation of the type of risk identified. Or both. Note any suspicious links or scripts and rescan again using the rest of the above tools. Upon scan completion, we should now have a pretty good idea of where to begin. Compile the list of suspicious items and head to your favorite search engine and begin the process of identifying each suspicious link and script.

Armed with whatever knowledge learned from searching, begin the process of removing potential threats.

Identify the obvious first, if possible. Visually inspect the directory structure in question (and in some respects, in general) and scan for blatantly obvious files and/or folders that aren't part of the Coppermine directory structure. Coppermine utilizes a meta-redirect within index.php files, so unless the webmaster has explicitly added them, there should be no .htaccess files; especially under the /albums directory tree. Some legitimate plugins do include an .htaccess file; verify these by inspecting with Notepad (or any other equivalent plain-text editor). In general however, an .htaccess file usually resides within the /www or /public_html directories and is usually legitimate. Note however, this file can be hijacked as well, so a visual scan and inspection of this file is a must, if such file exists. If an .htaccess file is indeed found within the /albums directory tree, delete it/them. And all others found under this directory.

If, after inspection, files and/or folders are found that shouldn't be there, delete them. If, after inspection, files and/or folders are found that shouldn't be there and can't be deleted or modified, the webmaster's options are limited.

The first step is to verify file ownership and permissions. The file in question should be "owned" by the domain name (or name that your host has given you). Verify ownership from the web host's control panel (usually cPanel or similar) file manager. While FTP apps prove extremely useful for most website publishing needs, most FTP apps do not furnish the required authentication necessary to take ownership of a rogue file or folder. So it's best to utilize the online file manager that comes as part of your domain package. Attempt to delete the folder in question. If this fails, attempt to change the permissions of the file in question to 755 (0755). If this fails, you will need to contact your web host and seek assistance in deleting the file.

Once the rogue file/folder has been removed, website cleansing may resume. Upon completion, gallery restoration, including database manipulation, if necessary, may begin.


Joachim Müller

Well done, thanks - one can see that a lot of effort and skills has gone into your article. I have quoted it in the Yikes-thread.

onthepike

Thank you, and glad you found that useful. I wasn't sure you would, because the Yikes thread is generally geared towards webmasters working on their own site(s). My efforts here began as a site visitor making outside observations, throwing in some guesswork and eventually moved onto assisting the site admin. So there was some conflict there in trying to arrange things that the actual webmaster would do in place of outside assistance.

By-the-way, you need not quote me there. If you'd prefer to format the outline in the same fashion as the rest of the messages there, that's fine. IMO, the quoting format makes it a bit more difficult to read due to the smaller text size and would probably be overlooked by most :-) Whatever you think is best.

Anyway, all issues within this thread are now resolved. And that's the important thing!