SteveW

The reason I asked is that if the script changed the file's owner to "nobody" instead of your normal ownership, you'd be able to edit the file from cPanel, but the Save would fail. If the script changed folder ownership or permissions, other similar strange behavior could result.

The "hack" allows them to upload and run a script in your site. The script would have access to all your files. In other words, a "Drupal hack" means Drupal was just the doorway into the site. Once they achieve the ability to upload and run a script, they can alter any file, even a static one. That's assuming Drupal was the way they got in, which isn't necessarily the case, but it's important to upgrade Drupal to latest version, scan your PC for viruses/spyware, and change passwords. This report might be useful: http://secunia.com/advisories/search/?search=drupal Why were you unable? It wouldn't save?

If Google has detected the malware, the site will probably be flagged in Google search results with "This site may harm your computer". If/when that happens, you can use the "Google Safe Browsing diagnostic page" for the site to help figure out some things about the malware that was found. Also, the webmaster can go into their Google Webmaster Tools account, which provides them additional information. On a compromised site, it is common for some people to get a virus warning and others not to get one, for several reasons. Sometimes, the malware is only served if the referer string shows that the visitor came from a Google or other search page. Or, often the malware is only brought into the browser when JavaScript is enabled; a visitor with JS enabled will get a virus warning, while a visitor with JS disabled will likely not. There are several online tools for scanning pages of a web site for suspicious iframes or JavaScript embedded in the code. Two of them are UnmaskParasites and Dasient WAM.

Nice analysis, that sounds right to me. Google Toolbar often first tries to get a favicon.ico from the same folder as the requested page instead of looking directly for the top-level favicon.ico.

The only thing protecting your sensitive emails is passwords consisting of long strings of completely random characters. No words that are in the dictionary, not even by combining them or making variations. Don't let your employees, employer, co-workers try to get away with anything less.

Yes, it could be worth banning the IP, but remember similar requests could come from anywhere or lots of places. If that happens, banning IPs gets pointless. The webmail page is a login page, so the 200 is ok. It served the login page. I can't add anything to why these are being requested, but the 404 is accurate. There is no such folder in public_html, so the path is invalid and the file doesn't exist. That would seem to indicate it's being requested directly for some odd reason.

If a folder or files got added to your website and you didn't initiate it some way or another, that wasn't an attempted hack. It was a hack.

I don't know of a concise checklist, but can provide two key phrases for web searches: "sql injection" and "remote file inclusion". SQL injection is specific to db applications. When you receive any input from a user, it's important to prevent them from embedding SQL statements in their input that subsequently get passed into your code, causing malicious data to be added into the database or secret data to be divulged from it. Prevention consists of careful coding practices in your code that receives and processes the user input. Remote file inclusion (RFI) results when a) the server is configured so that a command such as a PHP include() is permitted to fetch the include file from a site other than the local one (i.e. the include file is in URL form with http: or ftp: in front of it), and b ) a malicious user or robot provides input containing a malicious URL, and c) the input-processing code accepts the user input as-is, fetches the malicious remote file, includes it into the currently executing script, allowing it to do its damage. Prevention consists of a server configuration that prohibits inclusion of non-local files, processing code (or .htaccess) that rejects malicious requests, and processing code that filters incoming data, only performing the include when the data matches expected permissible values. Web searches on those will likely lead you to any lower priority things to be concerned about. Another is called "cross-site scripting", but that isn't specific to a db-application or to PHP.

As you've discovered, there are several settings to configure. If you haven't resolved this already, instead of mail.yoursite for the mailserver name, try just yoursite without the mail. That's what I've always used. For outgoing mail, you might need to specify port 26 (instead of the default port 25). Many ISPs reserve port 25 for outgoing mail being sent through their own mail servers and block you from sending outgoing mail thru port 25 to any other mail server except theirs.

Try saying No (don't stop running the script), and then wait 5-10 minutes to see what happens. The script in question is probably the "magic-revision" script that has something to do with displays in cPanel. It must be a long script, and JavaScript is slow. Some SMF folders have hundreds of files in them, and the script may be spending all that time formatting the page. I've encountered this message at some point in cPanel with IE, and if I waited long enough, whatever I was expecting to happen did eventually happen.

Not sure about Vista, but in XP, C:\Documents and Settings\Desktop\YourName\downloads would not normally be able to exist, but C:\Documents and Settings\YourName\Desktop\downloads could. Most of the programs on your computer have an update method, but your programs came from many different manufacturers, and the update methods will not be the same for all of them. It is likely that one of them might have created the \downloads folder for its use, but it is not likely that all your programs use that folder for their updates. Most programs show status reports on the screen while they do their update. They tell you what they're doing, often tell you whether the update was successful, and tell you if there is anything further you need to do, such as restart the computer. Be sure to read those screens as they occur. If you pay attention to them "in the moment", you won't have to wonder later what the update did. I would recommend deleting files only when you do know specifically what they are and you do know that they are obsolete or not needed. Otherwise, you should normally leave them alone. There are likely more than 100,000 files on your computer, and you probably don't know what 99,000 of them are. Deleting some of them because they look like clutter can result in malfunctioning programs, lost user settings, corrupted user profiles, and, in the worst case, Windows itself becoming corrupted and unable to run properly or at all. (The same don't-delete policy is also a good one in a website.) If you hadn't deleted them, one way to find out what some of those files were would have been to copy down the exact names and do a web search on them, or post the names here and ask what they might be. I know that doesn't truly answer your question, but the only way to find out what that downloads folder is really for will be to wait until another file shows up there and research it before you delete it.

Oh... is there just one website, that will have a new name? No files to move?

At cPanel > Backups is a Full Backup Option. Click that link. It's safe: it doesn't make the backup right away. You'll first choose options where to put the backup: in your home directory from where you can download it, or you can FTP it directly to the home directory of your new site. Once it's there, I don't know how to unpack it. A TCH tech did that for me when I moved my site to TCH. There's also a cPanel > Backup Wizard that just looks like a user-friendly interface for the same thing. Description is at http://twiki.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/BackupWizard. The Full Backup is preferable, if you can determine that someone will be able to unpack it for you. It transfers everything, including email addresses, etc. If restoring from a Full Backup turns out not to be possible, the smaller backups you can make in Backup can still be reassembled at the new site, but you'd need to create some things manually. I don't think it will create the email accounts.

Another good reason why I'm happy to be hosted here. Great work, techs. Nice work, everybody.

Last night I downloaded the home pages from the sites I could identify that are on the server and searched thru the logs and the retrieved pages, about 320 page requests from probably about 150 sites (without noticing I had the www and non-www version of each, which I'll fix today). The sites of gtman55 and klibreck were two of them. (OJB, feel free to send me your domain name by PM, if you like). I only got 3 of the "Read error (Connection reset by peer) in headers." messages, on 2 sites, neither of them yours. I only found 2 suspicious iframes, except it was on the www and non-www versions of the same site, so it's just 1. This morning, I did the same downloads. Unfortunately, I accidentally overwrote the log file, so can't count "Connection reset" messages. I only got the same 1 iframe on the same 1 site. I'll try to look into that further. I also crawled about 500 pages from gtman55's site this morning (sorry, but at least it was only at dial-up speeds). I got no "Connection reset" messages and no virus alerts. I haven't completed the text searches, but a quick search finds no suspicious iframes. Later today I'll try to do the all-sites crawl again to see if those "Connection reset" messages occur on different sites than previously. ----- I'd suggest that anyone getting reports of strange behavior or viruses try to get detailed information about the circumstances: what page they were viewing, what they were trying to do (only reading, or posting a message?, etc.). Anything this intermittent is hard to pin down. It's hard to fix something if it won't act broken during the time you're looking at it. It actually makes it more difficult that no site so far as been flagged at Google with "This site may harm your computer", because we therefore don't have Google's machinery and their reports to help investigate. If someone (someone who is immediately affected by this, meaning someone in this thread or on dantooine, not just anybody) wants to look up the 150 sites in the Google SafeBrowsing Database to see if any are flagged, I can provide the list, but it's against Google TOS to do it programmatically, so it has to be one-at-a-time lookup. At the moment, there is very little evidence to go on. I downloaded more than 1,100 pages from this server, and only found evidence of 1 possibly hacked site, and I'm not even sure about that one, and it's not one of the ones being discussed here. So even though it can be said that the behavior being reported sounds at least similar to a "goscanpark" type compromise, there is very little of that behavior, and it's especially strange that no site is flagged at Google, so it's way too soon to make an assumption, or even have a belief, that that's the case. Anyone affected should carefully go through all the steps that they would ordinarily do if they were certain that it was only their site that got hacked, and not try to "make a case" that it's the server, because usually it isn't. Going by statistics, individual site compromise has to be ruled out before it's justified to wonder if it might be a problem in the server. That being said, comparing notes on what people are seeing, as is being done in this thread, is exceptionally useful. If admins want to take a pre-emptive look to see if anything seems out of place, one of the things in the useful comments here: http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/ is the discussion of malicious crontabs being found running in memory but that have been deleted from disk so they can't be found by searching files.

When I was using the FrontPage Extensions, I was able to password-protect individual folders in cPanel without any problem. That was at a different host, but I doubt this is a host-dependent thing (though it's not impossible). If you were trying to password-protect public_html, I can imagine it's possible that that is more likely to present a problem for the FPE than if you password-protect other folders. You might try this workaround: leave public_html unprotected and open to the public. Move your entire site into a folder below public_html, and password protect that. On the index.htm page in public_html, put a link to the index.htm page of your subfolder. After people click the link, they should be prompted for their password before they can continue. If that works, and you don't want people to have to click the link, you can 301-redirect your public_html/index.htm page to subfolder/index.htm. If the FPE make it impossible to do that kind of redirect in cPanel or .htaccess, you could do it with a meta-refresh header in the public_html/index.htm page, although that is not the preferred way to do it because some people browse with meta-refresh disallowed for security reasons. The meta-refresh won't work for those people, but it shouldn't be much of a problem because they can just click the link on the page.

What is the full path of that "Downloads" folder?

When you create the database user in cPanel > MySQL Databases, you don't enter the userID prefix for the username or the database name. cPanel prepends the prefix for you. You'll see that it did when you go back to the database summary screen from the add user confirmation screen.

In connection scripts on a shared server is it necessary to prefix both the user and the database with your TCH userID? It appears that way in cPanel > MySQL Databases. Everything gets prefixed (because one instance of MySQL handles all databases of all websites on the server, and the prefix ensures unique names). What I'm not sure of is whether you must use the prefix in your connection scripts. So a database db1 would be referred to as YourTCHuserID_db1. Your MySQL database user would be referred to as YourTCHuserID_DBUserName. That would probably be a difference between your TCH server and your local XAMPP. Edit: yes, I think the prefix is necessary. I found the connection settings for SMF Forum, and it uses the prefixes.

To clarify one part of the problem, are you saying that when you first boot the computer and arrive at the Windows "Welcome" screen, your account is the only one shown, and thus you are the only person who can log in? I'm not familiar with the complications of networked computers, and I'm using XP rather than Vista. The consequences could be: things I mention below might have slightly different names, or not be in exactly the locations I say they are, or I could be totally wrong... First, most of the steps below involve just looking at things to assess what the problem is. I would avoid making any changes until Microsoft has had ample time to get back to you. After you have logged into your regular administrator account, go to Control Panel > User Accounts. As an administrator, you should be able to see all the existing accounts. See if your husband's account (and any others that should be there) are still there. I can't check it now because I'm not in my administrator account, but I believe that's also the place where you can view and change the Fast User Switching setting. If it's not, go to Start > Help and Support, search for "fast user switching", and follow links to instructions how to turn it on and off. If your husband's account was not shown in User Accounts, it would seem that the account was somehow deleted but the files left intact. Did you rescue his entire "user profile", or only his files that were in My Documents? If it was only My Documents, I'd do it again to get the entire user profile: it's at C:\Documents and Settings\UserName\ and contains a whole bunch of files and folders in addition to the ones in My Documents. You can burn them to DVD from, for example, Nero. If necessary to conserve space, there are some large things like Temporary Internet Files that you can omit. Assuming your email program is Outlook: within his user profile should be a folder called C:\Documents and Settings\UserName\Local Settings\Application Data\Microsoft\Outlook\ that should contain a file called Outlook.pst that contains all his active accumulated email folders and messages. If he has archived old messages, those will be in additional ".pst" files. I did once have to rescue a corrupted user in the way you're having to do, by creating a new user and transferring whatever files and settings I could, but it was a few years ago and I don't remember a lot about it. I was not able to "uncorrupt" the user and make the account usable again, but I didn't know much about XP back then. That's why it would be good to wait until you hear from Microsoft; they might know how. If you can't repair the old account and have to use the new one, what I would try myself in this situation is: in the new account, in the folder that contains the .pst files (see above) should be a small Outlook.pst file that just contains the initial data for a new user. I'd rename that file to Outlook.pst.bak (or something like that), and copy into this folder the rescued Outlook.pst file from the old account, and any other .pst files. When you open Outlook in the new account, I think it is likely you'll find all the old lost data is magically there. A user profile contains thousands of files and configuration settings, which is why it is good to rescue all of it in case some of the other things can be restored as easily as the Outlook items, although I'm not sure that they can, and in some cases doing it that way might be more trouble than just creating the new settings fresh.

Do select "Always Allow PopUps From This Site" in Internet Explorer. In FileManager, right next to the heading at the top is a "Settings" link, where you can "Disable Character Encoding Verification Dialogs". Maybe you set that setting at some point, on purpose or by accident? Those two sentences seem contradictory. Can you explain more fully what's happening? Or do you successfully go to the file editing page, but can't edit the text in it? Are you unable to edit, or unable to Save? What is the "blocked signage" icon? cPanel is at a new version since the last time I checked. There might be a few differences, or new bugs. Old: 11.24.4-STABLE Build 33345 Theme=x3 New: 11.24.5-STABLE Build 38506 Theme x3

The google_ad_client is the unique AdSense publisher ID of the person who will be paid for clicks on those ads, so it's a major clue. Check for security advisories about all the programs you use (photo album, classifieds, and the wordpress blog), and their plug-ins, at Secunia. Here is the one for Noah's Classifieds, in case that's what you're using: http://secunia.com/advisories/product/5705/?task=advisories If a file is everybody-writeable (666 or 777), it means that any PHP script running on any site on your shared server can potentially access it without having to supply a userID or password. I suspect it also means that it's accessible by FTP, and telnet/SSH (if I'm using those terms correctly), but in those cases they would first need the userID/password. If the changed file was 664, it was probably modified by a PHP script running on your site. While technically possible that the script was running on some other site on your server, it is rare. It's still serious, though. If they can modify one file, they can modify, or delete, the entire site. WordPress at Secunia. Yet another vulnerability in the past few days: http://secunia.com/advisories/search/?search=wordpress

That sounds a lot more complicated than anything I had to do for AdSense. Could you post a link to the Google FAQ/Help/Answer page that discusses the procedure you're trying to do?

My memory is a bit hazy on this, but I encountered the same thing when transferring my site. I think I recall doing a web search on it, discovering many webhost FAQ pages saying that PHP includes wouldn't work until the nameserver change is propagated, and concluding that there was no way around it and it wasn't worth trying to find a fix for testing purposes. Once propagation was complete, the PHP includes worked fine. I suspect it might be other aspects of the PHP transition that you're more concerned about and that you want to test more thoroughly, such as the TCH servers maybe being a different PHP version, with those potential complications. If it's any help, my nameserver change was propagated at my location within about 15 minutes, and at most locations in the world within about 2 hours, and I think after about 10-12 hours my old site never got another hit. So in spite of my worry about the potential 72 hour propagation time, it turned out that if I had found any disastrous problems with the transfer, I could have changed the nameserver info back, and the total downtime would have been pretty minimal.

(Simple Machines Forum) SMF 1.1.10 and 2.0 RC1.2 released: http://www.simplemachines.org/community/index.php?topic=324169.0