some basics on wordpress hackers

Found this useful comment on Reddit:

It seems that it is an apache vulnerability: if the site needs to be writable to write file uploads, then apache can be told to write a script into one of those writable folders, such as wp-content. Set the edit permissions on the site to mode 755 -R until you want to upload something. Wordfence however needs its cache to be writable so set that to 777. Meaning you can basically then assume that the "Viruses" will only appear in there.

The "viruses" are almost ALWAYS seven or eight gibberish characters followed by php. Such as ubzrvgwk.php or ivpuudgx.php. Generally if you run find -name "????????.php" on the folder you'll see non-english filenames and if you view them they contain attack code. Delete them.

Install wordfence-cli and get a wordfence API key. Then run it as follows:python wordfence-cli/main.py scan /var/www/

Every day just login and delete stray admin accounts if you see them. Look at your posts for javascript video icons, those are the viruses that spam your site.

The problem fundamentally is the wordpress database password is cleartext in a known file location so any uploaded script can just read that and run any sql command. Wordpress seriously needs to use password shadowing or something.

Popular posts from this blog

bash + python script to find wordpress malware and delete it.

OK so there are three parts to this script. 1. An exclude list 2. The script 3. A python script to check for randomness. The idea is it finds spammy-looking filenames and then runs a python entropy script to check if the file is random-ish internally. It then offers to delete. Note that real virii have an entropy in the 5.8 region, because they use code obfuscators. If the entropy is lower than that rather skip deleting and manually check the file. I know about wordfence-cli but I do not like it. Flags are -f for find and -d to delete. It prompts for each delete. 1. The script sudo mkdir -p /scripts/wordpress/ sudo vi /scripts/wordpress/find_spam_crap.sh #!/bin/bash export TERM='xterm-256color' # File containing known, safe PHP filenames to ignore IGNORE_FILE="/scripts/wordpress/find_spam_crap.ignore" # File containing all known filenames for exhaustive English exclusion EXCLUDE_FILE="/scripts/wordpress/find_spam_crap.exclude" # Function to load ignore list ...
Read more

enabling web interface updates over FTP or directly

Wordpress can be updated on the command line or the graphical side in the web browser. But in order to do that you need write permission on the server as the user www-data (the webs server), or, ftp access to upload files from wordpress.org to the server you are hosted at. Hence, you can either set the website to be owned by the webserver (and risk that vulnerabilities to the webserver affect your website), or you can enable FTP. The default is to let the webserver (www-data) have write permission: chown -R www-data:www-data /var/www/wordpress/ chmod -R 775 /var/www/wordpress/ To enable FTP, create a user specifically for the purpose on the server's FTP service and give them ownership of the wordpress folder. Put the following code into the wp-config.php file define( 'FS_METHOD', 'direct' ); define( 'FTP_BASE', 'www.myserver.com/www/wordpress' ); define( 'FTP_CONTENT_DIR', ' www.myserver.com /www/wordpress/wp-content/' ); define( ...
Read more

turning on debug mode

Turn debug mode on edit your wp-config.php file and find define('WP_DEBUG', false); change to define('WP_DEBUG', true); General causes of bugs 1. Dodgy plugins/templates. Remove them all and add them back one at a time. Same for themes 2. Config errors. Replace the config.php file with the template and reinstate it. Obviously copy/paste the login details for the database out before you do that, so when you recreate it, it asks for them again. 3. Code incompatibilities . You have some old code somewhere (e.g. an old php file) which was not upgraded and is now incompatible with the new php in the new issue of wordpress/plugin/template etc 4. Permission errors.  chmod -R 755 /var/www/mysite chown -R www-data:www-data /var/www/mysite assuming your installation is located in /var/www/mysite. On a single-site server it will be /var/www/html "There has been a critical error on your website" = problem 3 above, usually.
Read more