Now I didn't do the website design but a couple of months ago I ported an existing website over to wordpress for a client of mine.
I got a call from a client today regarding their website, and some sort of a security problem.
The websites homepage loads up fine, but if you try to navigate to any other page it brings you to - http://secure.wheelerairservice.com/main.php.
The nav appears to still be linking to the appropriate page (when you rollover contact us, the link displays in the status bar as /contact-us) but it redirects to the above url.
Just wondering if anyone knows what the problem is, and who or what might have done this and how.
Any suggestions on how I could fix this?
thanks!
Ok I've looking into the problem some more and found that the .htaccess file had been replaced somehow. I'm just wondering how someone might have done this? via ftp access, wordpess admin account or some hole in wordpress, any thoughts?
Typically when it's the .htaccess files that have been infected, it's usually the result of stolen (compromised) FTP credentials.
This usually happens by a virus on a PC that has FTP access to the infected website. The virus works in a variety of ways, but usually one of two.
First, the virus knows where the free FTP programs stores it's saved login credentials. For instance with FileZilla on a Windows XP PC, look in:
C:\Documents and Settings(current user)\Application Data\FileZilla\sitemanager.xml
in there you'll find, in plain text, all the websites, usernames and passwords that user has used FileZilla to access via FTP.
The virus finds these files, reads the information and sends it to a server which then uses them to login to the website(s) with valid credentials, downloads specific files, in this case the .htacces files, infects them and then uploads back to the website. Often times we've see where the server will also copy backdoors (shell scripts) to the website as well. This gives the hacker remote access to the website even after the FTP passwords have been changed.
Second, the virus works by sniffing the outgoing FTP traffic. Since FTP transmits all data, including username and password, in plain text, it's easy for the virus to see and steal the login information that way as well.
Change all FTP passwords immediately
Remove the the infection from the .htaccess files
Perform a full virus scan on all PCs used to FTP files to the infected website
If the website has been listed as suspicious by Google, request a review from Google's webmaster tools.
If the hosting provider supports it, switch to SFTP which encrypts the traffic making it more difficult to sniff.
Also, look at all files for anything that doesn't belong there. It's difficult to find backdoors, because there's so many different ones. You can't go by the datetime stamp either because these backdoors modify the datetime stamp of files. We've seen infected files with the exact same datetime as other files in the same folder. Sometimes the hackers will set the datetime stamp to some random earlier date.
You can search files for the following strings:
base64_decode
exec
fopen
fsock
passthru (for .php files)
socket
These are somewhat common strings in backdoors.
Change your passwords. See Hardening WordPress and FAQ: My site was hacked « WordPress Codex and How to completely clean your hacked wordpress installation
If FTP has been used to access/modify the files in this wordpress site, then it could be more than possible that someone has got the username and password for FTP access and modified your .htaccess file. FTP is not secure at all. I would suggest using SFTP as a minimum.
Wordpress is not perfect (not many things are) but i highly doubt there would be a flaw like this, is possible but i very much doubt it.
I suggest you first, change your FTP username/password, upgrade wordpress to the latest version, change the default admin username to something else and change the password for the administrator user, ensuring that all passwords are at least 8-10 characters in length
We also getting same problem for word press website, once virus removed but it re-attacking again, So as said above first have to backup all files, then change passwords of FTP, Administrator and cPanel, then upload back the website. I did above steps for our website.
Related
Just found a nice way to spend a morning... Google wrote to us saying we have infected files on our website. They sent us the infected urls and it looks like a phishing attack when I visit them. However, when I try to locate these on my server, I can't find them. I looked at the source code of the infected urls and couldn't locate the css files neither on my server. Also, I ran the top level domain through Virustotal.com and the report came out clean. When I copy/paste the infected url in Virustotal, it tells me there's a phishing problem.
So, is there any other way to find the files on the server? Should I contact my host?
There are five files and they look alike except for the hash. After my domain name, here is what the url looks like : /~zczjzzkxzcz/x81/amli.assurance/amli.fr/amli.fr/free/sm/oo/ve/PortailAS/assure_somtc=true/dc0d2f6d7a36af8dfb05869f676736c7/index_2.html
So, after talking to my host, it looks like the problem was from another hosting account that doesn't belong to me, since the username doesn't match (happened since we have a shared hosting plan). So, next time no file is found, contact the host in the first place.
everyone.
I need to lock website for downloading via some windows tools and wget.
The site consists of js, html and php files.
I googled about security resource sharing, but it did not helpful for me.
Thank you.
As long as at the same time you need to have your website online available for everybody, this is not possible. If someone visits your site, the browser needs to access all files, in other words download them. You might be able to apply a few hacks to make it more difficult, but you can not prevent it completely.
If you want to restrict it to a defined audience, you can implement a login using for example HTTP Auth. How this can be achieved depends on your hosting. It might be doable using an .htaccess file in your web root or maybe through the admin interface of your hoster.
Your PHP file should be safe by the way, the above said applies to the public parts of your site (HTML/CSS/JavaScript/Images/...).
I have a website which is infected by some malicious malware. In the beginning I could notice that there was some strange javascript code on the site pages so I delete it and everything was fine for a few days, but now google lists the website as dangerous even though that I have checked the site code for any strange code but I could not find anything.
I have try Sucuri SiteCheck and it detects redirections to a malicious site. At first I thought that it may be an .htaccess file that was doing the redirection but I checked the files on the shared server and there is no .htaccess file.
Any ideas on how to solve this?
Your hosting account has bee hacked. Change your password on your hosting service. Go through your site code once more (every file) and look for things that don't belong. Clear your browser cache and then try again. If your account is hacked again, find a new hosting service. Once you're sure that your site is clean and your account has been secured, let Google know about the problems and request a removal from their suspect list:
Google support
check your .htaccess file for the redirection or the whether the files contain and unwanted malicious java script.
I'm making a newsletter editor which will allow file uploads (the sender of the newsletter can upload files to the server which will be linked to in the email).
The site is set up so that only .do URIs are actually executed/handled by servlets so it's not much of a security risk, but I've been told to blacklist .jsp, .php, .asp, .aspx, .exe, .com, and .bat. This does not strike me as a comprehensive blacklist, and I've the impression that blacklists are not a good policy.
On the other hand, a whitelist would be dozens long. What's the correct way to identify allowable/disallowable extensions? Or is it more proper to just allow anything and run it by a virus scanner, or some combination of these?
I would allow any file extension to be uploaded, but I would store the files in a folder that is not directly served by the web server. I would then create a HTTP handler that would be linked to from the email, which would stream the requested file. The file could be requested either by original file name, a system generated file name or by an ID. Either way, I would sanitise the parameter to guard against directory traversal attacks.
e.g. www.example.com/FileLink.ashx?FileName=Word.docx
This way you do not need to worry if in future you wish to serve additional file extensions as executable file types, as any file is served directly from a byte stream from the file system and is never passed through the web server handlers.
You can also use the handler to check that the current user has the correct permissions to load the file.
It would also be worth virus scanning each file, just in case the newsletter author uploads (either maliciously or accidentally) a file that would attack subscribers' computers rather than the server.
Also ensure that the Content-Disposition is set to attachment:
Content-Disposition: attachment; filename="filename.html"
This guards against XSS being achieved by upload of HTML containing script tags, or other Same Origin Policy bypasses using Flash or PDF files. The scenario here is one newsletter editor compromising the session of another newsletter editor. It is worth also setting X-Content-Options: nosniff, which can also protect against this. xap files (Silverlight) could also bypass the Same Origin Policy, so check that the filename cannot be ended in .xap to request your file
e.g. www.example.com/FileLink.ashx/x.xap?FileName=Word.docx
and you could blacklist the setting the content type for Silverlight as extra protection for this special case. Source here:
Note: .XAP files can be renamed to any other extension but they cannot
be load cross-domain anymore. It seems Silverlight finds the file
extension based on the provided URL and ignores it if it is not .XAP.
This can still be exploited if a website allows users to use ";" or
"/" after the actual file name to add a ".XAP" extension.
Note: When Silverlight requests a .XAP file cross-domain, the content
type must be: application/x-silverlight-app.
I've also verified these scenarios myself and are are currently valid attack vectors.
Or is it more proper to just allow anything and run it by a virus scanner.
Yes.
Both blacklists and whitelists are trivially circumvented and cause just administration pain and provide no security whatsoever.
In my opinion, even though the whitelist maybe a bit of a chore to maintain, it's far more secure than using a blacklist.
It's much better to forget to add something to the whitelist, and have to go back and change it, than to forget to add a new file extension to the blacklist and get hacked.
In addition to the whitelist, I would still virus scan the uploaded files, as even seemingly harmless files (such as .pdf or .doc) can have malicious code (.pdf's support javascript, and .doc macros)
I would recommend you:
Use a whitelist approach (by the reasons described above, it's fairly
more secure)
Check the filetype (bypassable but still one more measure)
Store uploaded files in internal folders not exposed to the public (using non enumerative IDs)
Set-up a low grade permission to the folder that will contain the uploaded files
Set-up less privileges as possible to the uploaded files
Make sure if there aren't secure libraries to upload files already available.
Antivirus aren't worth it. Most of web shells signatures are really easy to bypass since any 'hacker' can add some random code and do different types of encodings on an web shell. Sure it will protect you from common shells such as C99 but nowadays there are thousands of these tools publicly available and fully undetectable. And regarding protecting your users from executable files or infected PDF's hosted on your websites, if someone it's capable of get a shell on your site and start up a malware campaign it won't use malware or virus already spotted by av signatures.
A website I maintain pro-bono was hacked, dishing out 302s to gaming sites, etc. www.rebekahshouse.org. After much searching through my hosting company's control panel, I found the culprit in the htaccess file.
It looked something like this:
RewriteEngine on
RewriteCond %{HTTP_REFERER} .oogle.com [NC,OR]
RewriteCond %{HTTP_REFERER} .ahoo.com [NC,OR]
RewriteRule .*hxxp://87.248.180.89/topic.html?s=s- [C,L]
(I think that was C, L; I overwrote it and tried to recreate it above, might've missed a piece here and there)
Anyway, I overwrote it with this:
order allow,deny
deny from all
Is this going to anything for me? What SHOULD I have in my .htaccess file? This is purely a static html site.
Thanks!
If you're running a static site its highly likely you don't need anything in your .htaccess.
You should then workout how your site actually got hacked...as if you haven't resolved that it's just going to happen again.
Your real concern should be how it happened in the first place. Defacers and such often go back and will try the same thing again on a previously cracked site, since many times the vulnerability isn't fixed.
The htaccess file is incidental. You have been hacked by one of the Russian malware gangs. If you don't close the hole that allowed the hack to happen, you will just get hacked again.
It is entirely possible that the server itself is compromised and there is more stuff on it you don't know about, such as trojan software that might not only deface your sites, but also launch attacks on others, send spam, and so on. Assuming appropriate permissions on the directory containing the htaccess file, it should not have been possible to write a file there even if you have an insecure web application on there. Certainly if you are only dealing with static files the only way such a file could have got there is by your uploading account, or the server itself being compromised.
If it's your server, as I'm guessing from the fact it responds to a direct query by IP address, you need to flatten it and reinstall from up-to-date software, use new passwords, and check your own client machines you're uploading from for infections.
(As per #YGomez's comment: first and foremost, you need to close the vulnerability which allowed the creation of that .htaccess file, else the malware will come back almost instantly; I probably should have mentioned that explicitly)
The first part will redirect all visitors coming in from yahoo and google to 87.248.180.89
The second part ("allow, deny") will deny access to your site for everybody.
I suggest to simply delete the .htaccess and be done with it - if you use a .htaccess file, you would know what goes in there, else you don't need it.
No, that won't do anything for you. For a static site you may not need a .htaccess file at all.
Step 1 : change FTP password
Step 2 : Download all files and clean
Step 3 : upload Files
Step 4 : Set 444 permission to all files, except Custom Upload folders
Remeber Do not save FTP password in your FTP client.
If you suspects that your system is infected, Format and install OS, then install a good antivirus + firewall. I suggest Avast free edition and Comodo Firewall.
We have received many inquiries and we cleaned those infected sites.