All my backslashes are gone in WordPress. Yikes.

Discovered that my most recent conversion from SQLite to MySQL seems to have screwed up my backslashes in all my posts that have backslashes.

This is bad because my code snippets should not be copy & pasted and run at face value unless you verify the code!  It could seriously break shit.

Ugh.  This is going to be a PITA to go and fix 500 posts.   It might be quicker to try to fix the SQLite DB file and try another conversion.  This isn’t the first time I’ve noticed this problem.  I see the issue when I restore from XML files as well, and even just copying database using something like mysqldump to dump and then importing using mysql command.  I’m probably just missing a simple flag to not strip slashes or something.

My next step is to confirm if there is actually a backslash in the SQL data and it is just being stripped in the_content() or something;  or if the backslash is REALLY not there.  *sad face*

update 1:  the slashes are not in SQL.  Looks like I need to look at my export DB to see if they are in that. *crosses fingers*

update 2:  found this article that creates a function to convert backslashes into HTML entities as the posts are saved.  https://www.tweaking4all.com/web-development/wordpress/preserve-backslash-in-posts/#comment-268277

WordPress SQLite to MySQL Migration Complete

Just finished migrating my website from SQLite to MySQL. What a rush. (lol)

It was actually not as bad as I thought. A lot of sed, grep and other sorcery involved; especially in transforming of SQLite statements to MySQL.

Some quick commands I used:

sqlite techish.db .dump > production_2018-08-23.dump.sql

I found that it used quotes for tables and column names, so I had to remove those first and foremost.

sed -i '/INSERT INTO/,/VALUES (/s/"//g' production_2018-08-23.dump.sql

Next I found that there was an error using mysql -ufoo -p mynewdatabase < production_2018-08-23.dump.sql because the table creations were failing still. So I did a quick fresh install of a vanilla WordPress install, did a dump of the database and just grabbed the table creation parts out:

Dump fresh database:

mysqldump -ufoo -p wordpres > wordpress.sql

Next, I just want table creations…

awk '/CREATE TABLE/, /) ENGINE/' wordpress.sql > create_tables.sql

Next, run create_tables.sql on my new database and then import data.

mysql -ufoo -p mynewdatabase < create_tables.sql

Sweet, that worked and I have a baseline of tables now.

Now importing the data…

WordPress Unauthorized Password Reset Vulnerability (CVE-2017-8259)

WordPress has a password reset feature that contains a vulnerability which might in some cases allow attackers to get hold of the password reset link without previous authentication.
Such attack could lead to an attacker gaining unauthorized access to a victim’s WordPress account.  This affects all versions of WordPress, including the current version, 4.7.4.

Description

The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner’s account.

This can be observed in the following code snippet that creates a From email header before calling a PHP mail() function:


wp-includes/pluggable.php

if ( !isset( $from_email ) ) {
        // Get the site domain and get rid of www.
        $sitename = strtolower( $_SERVER['SERVER_NAME'] );
        if ( substr( $sitename, 0, 4 ) == 'www.' ) {
                $sitename = substr( $sitename, 4 );
        }
        $from_email = 'wordpress@' . $sitename;
}

3 separate example scenarios (both the ones that require victim interaction and those that do not) include:

  1. Attacker can perform a prior DoS attack on the victim’s email account/server (e.g by sending multiple large files to exceed user’s disk quota, attacking the DNS server etc) in order to prevent the password reset email from reaching the victim’s account and bounce back to the malicious sender address that is pointed at the attacker (no user interaction required)
  2. Some autoresponders might attach a copy of the email sent in the body of the auto-replied message (no user interaction required)
  3. Sending multiple password reset emails to force the user to reply to the message to inquiry explanation for endless password reset emails. The reply containing the password link would then be sent to attacker. (user interaction required)

Workarounds

  1. If you are using Apache, you can turn on UseCanonicalName (see: https://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname)
  2. I created a simple plugin that you can install in your WordPress installation. It will disable the last password functionality.
    Disable Password Reset

From Linux Install to WordPress

A typical installation of Debian 8.x (Jessie) precedes this where I only select base system and ssh server options during operating system installation.  After installation, this is a typical configuration to get me up and running. These are my notes.
Debian Customization
These are customizations to suit my taste.

apt-get update && apt-get upgrade
dpkg-reconfigure dash
echo UseDNS no >>/etc/ssh/sshd_config && /etc/init.d/ssh restart
apt-get install fail2ban vim-nox unzip

Webserver Installation: nginx

wget http://nginx.org/keys/nginx_signing.key
apt-key add nginx_signing.key
echo 'deb http://nginx.org/packages/debian/ jessie nginx' >> /etc/apt/sources.list
echo 'deb-src http://nginx.org/packages/debian/ jessie nginx' >> /etc/apt/sources.list
apt-get update && apt-get install nginx

nginx Configuration

There are a few customizations I make and I have scripted most of this since it’s repetitive.

In the first line below, worker_processes 2; is derived from grep 'cpu cores' /proc/cpuinfo | head -1
sed -i 's/user[ ]*nginx/user www-data/g; s/worker_processes[ ]*1/worker_processes 2/g' /etc/nginx/nginx.conf
sed -i 's/access_log.*;/access_log off;/g' /etc/nginx/nginx.conf
sed -i '/access_log off;/a client_max_body_size 12m;' /etc/nginx/nginx.conf
/etc/init.d/nginx restart

With basic configuration changes made to nginx.conf, I now focus on creating the site configuration.

rm /etc/nginx/conf.d/*
cat <<EOF >>/etc/nginx/conf.d/`hostname`.conf
server {
        listen 80;
        root /var/www;
        index index.php index.html index.htm;
        server_name techish.net www.techish.net;
        location / {
                try_files $uri $uri/ /index.php;
        }
        location ~ .php$ {
                try_files $uri =404;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
;
                include fastcgi_params;
                fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        }
    location ~ /.well-known {
                allow all;
        }
}
EOF

That concludes nginx installation and configuration to THIS point. I’ll revisit toward the end when I implement SSL.

PHP 7 Installation

I use dotdeb to install PHP 7.0 via apt-get.

echo 'deb http://packages.dotdeb.org jessie all' >> /etc/apt/sources.list
echo 'deb-src http://packages.dotdeb.org jessie all' >> /etc/apt/sources.list
wget https://www.dotdeb.org/dotdeb.gpg
apt-key add dotdeb.gpg
apt-get update
apt-get install php7.0-fpm php7.0-mysql php7.0-gd php7.0-mcrypt

PHP 7 Configuration

With PHP7 installation completed, I make a few changes.

sed -i 's/^upload_max_filesize.*/upload_max_filesize = 10m/g; s/^allow_url_fopen.*/allow_url_fopen = Off/g; s/^post_max_size.*/post_max_size = 12m/g' /etc/php/7.0/fpm/php.ini

MySQL (MariaDB) Installation

Installing MariaDB is pretty straight forward with only a minor tweak in the configuration at the end.

apt-get install mariadb-server

MariaDB Configuration

sed -i 's/^bind-address/#bind-address/g; /^#bind-address/a skip-networking' /etc/mysql/my.cnf
mysql_secure_installation

Restart Services & Test

Restart the services and test out things to make sure everything works.

systemctl restart nginx.service
systemctl restart php7-fpm.service
systemctl restart mysql.service

WordPress Installation

WordPress installation is straight forward.

Database Preparation

Make sure to substitute wordpress, wpuser and ... below to reflect your database, database username and database user password.
cd /var/www
mysql -uroot -p -e create database wordpress; grant all on wordpress.* to 'wpuser'@'%' identified by '...'; flush privileges

WordPress Download & Extract

wget https://wordpress.org/latest.zip
unzip latest.zip
mv wordpress/* .
rm -rf wordpress/; rm latest.zip
chown www-data.www-data -R .

WordPress Configuration

At this point, the database is ready to go and I just visit my website to finish the WordPress installation via Web interface.

Let’s Encrypt SSL Certificate

Installation

openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Add Jessie backports repo and install.

echo 'deb http://ftp.debian.org/debian jessie-backports main' >>/etc/apt/sources.list
apt-get update
apt-get install certbot -t jessie-backports

Certificate Generation

I generate a certificate for my top level domain and subdomain.

certbot certonly --webroot -w /var/www -d techish.net
certbot certonly --webroot -w /var/www -d www.techish.net

nginx SSL Configuration

Create a directory in /etc/nginx to store a few snippets of nginx configuration.

mkdir /etc/nginx/ssl

Create SSL parameters configuration file, ssl-params.conf, that we’ll call in our site configuration file.

cat <<EOF >>/etc/nginx/ssl/ssl-params.conf
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    add_header Strict-Transport-Security max-age=63072000; includeSubdomains; preload;
    add_header Strict-Transport-Security max-age=63072000; includeSubdomains;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
EOF

Create a configuration file, ssl-kreider.conf, that will reference where my top level domain SSL certificate is stored. I call this file from main nginx site configuration file later.

cat <<EOF >>/etc/nginx/ssl/ssl-kreider.conf
ssl_certificate /etc/letsencrypt/live/techish.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/techish.net/privkey.pem;
EOF

Create a configuration file, ssl-www-kreider.conf, that will reference where my www subdomain SSL certificate is stored. I call this file from main nginx site configuration file later.

cat <<EOF >>/etc/nginx/ssl/ssl-www-kreider.conf
ssl_certificate /etc/letsencrypt/live/www.techish.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.techish.net/privkey.pem;
EOF

I update my main site’s nginx configuration.

Note that `hostname` will expand the system hostname automatically. Replace `hostname`.conf (including backticks) with your configuration file name as applicable.
vim /etc/nginx/conf.d/`hostname`.conf

My finalized site configuration file.

server {
        listen 80;
        server_name techish.net www.techish.net;
        return 307 https://techish.net$request_uri;
}
server {
        listen 443 ssl;
        include ssl/ssl-kreider.conf;
        include ssl/ssl-params.conf;
        root /var/www;
        index index.php index.html index.htm;
        server_name techish.net;
        location / {
                try_files $uri $uri/ /index.php;
        }
        location ~ .php$ {
                try_files $uri =404;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name                                                                                                                               ;
                include fastcgi_params;
                fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        }
}