So, if you need both the content and file name in your Intruder attack, choose Pitchfork as the Attack type and use File as Payload for one Payload set and Filename as Payload for the other.

With this update you can synchronize the file name and its contents in the attack without much hassle, something that was not trivial in the previous version.

So I wrote an extension that reads a folder files and feeds their content, one at a time, as a payload to use in the Intruder.
Suppose you have a folder with your best malicious files, zip and xml bombs, jpegs with other contents, php shells, etc. You point the extension to this folder and just use the Repeater normally, setting the payload source as being this extension.
If you need/want to synchronize the file contents with the file name, the extension tab shows the names of the files it just read so you can use them as payload for a second position in the request, using the pitchfork attack.

EDIT
There is a new version of the extension that provides two generators, one for the file name and other for the file contents, easing this synchronization process. See this update post.

Choosing the input files

Configuring the Intruder

The extension is available here as a single jar. The code is available here.
I have submitted it to the BApp Store but it hasn’t been approved yet.

EDIT
Now available at the BApp Store, here :)

Enjoy.

OCSP stapling is good: you have one less connection to a server that has nothing to do with the intended purpose of the original connection and still get an OCSP response. Sure, you have a few more bytes on every connection but it is harder for the attacker to interrupt the OCSP process without interfering with the target server itself.

For nginx, you need to use a configuration at least with these directives:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/certs/bundle_with_root_stapling.pem;


ssl_stapling on; enables stapling. To be honest, you can make stapling work only with this line.

ssl_stapling_verify on; this forces our server to check if the OCSP response is valid, meaning properly signed by the respective CA.

ssl_trusted_certificate /etc/nginx/certs/bundle_with_root_stapling.pem; path to the chain that validates the responses. If you enabled ssl_stapling_verify you need this directive. It must have all the intermediates CAs, including the root. Just concatenate every CA in the chain, PEM encoded, with the root in the end.

Then just issue sudo service nginx restart and test it. You can test it with echo | openssl s_client -connect mendo.pt:443 -status

You will likely get something like
OCSP response: no response sent

This happens because nginx will not prefetch a valid response until it gets a connection, so the first connection won’t receive an OCSP response. Try again after a few seconds and you will get

OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = IL, O = StartCom Ltd. (Start Commercial Limited), CN = StartCom Class 1 Server OCSP Signer
Produced At: May 8 20:48:21 2015 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 6568874F40750F016A3475625E1F5C93E5A26D58
Issuer Key Hash: EB4234D098B0AB9FF41B6B08F7CC642EEF0E2C45
Serial Number: 05A143427C3754
Cert Status: good
This Update: May 8 20:48:21 2015 GMT
Next Update: May 10 20:48:21 2015 GMT

Signature Algorithm: sha1WithRSAEncryption
98:47:f1:39:4b:ef:f6:67:3d:46:d4:3c:93:fc:ab:95:20:a3:
e8:d0:2b:64:63:d8:46:d7:65:3f:00:5d:50:9c:7d:b7:2c:4c:
36:b1:58:86:9f:4b:95:d4:a4:fa:0f:bb:50:3b:a3:e8:d2:a6:
f3:5f:8c:c3:62:b1:75:90:8a:ab:50:cd:33:6a:cc:6c:ea:04:
a5:65:ff:09:15:41:0c:76:98:7a:79:93:f4:e1:8b:a5:a1:0c:
1e:90:04:25:05:98:91:2c:cc:62:0a:2b:06:a3:28:46:55:90:
f3:0f:09:3c:57:51:98:ed:9c:6f:03:f6:01:9e:d5:61:1b:cf:
f2:7a:0b:f2:9d:e1:52:ba:4a:34:ba:5c:95:7b:40:de:83:96:
55:d0:df:41:e7:14:58:28:9b:6a:67:67:fc:db:59:ab:8a:35:
90:a9:75:8b:9e:8b:46:51:0c:e9:8c:4e:43:60:34:f7:86:06:
09:0b:5f:03:16:b7:ab:15:49:ea:15:c4:f7:c6:d0:ec:22:01:
fd:8a:f1:d0:b9:f5:12:14:b7:13:5b:13:80:a6:60:be:11:bc:
28:c8:86:44:4b:1f:dd:fc:1e:5a:2e:a0:21:52:8d:c7:6c:e5:
72:c0:11:f4:15:16:54:96:14:f7:5f:5a:3f:cf:46:10:60:f5:
46:15:0a:8b


Simple.

EDIT
Because nginx will only resolve the OCSP hostname at startup and its IP can change, you might consider setting the following directive (pick you DNS resolver):

resolver 8.8.8.8;

For the installation just follow the official documentation found here to which I just want to make one remark about the database password strength:

GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname" IDENTIFIED BY "password";

Use a long password here, something like sK8ytB8mR5PtxqqTmCEYThEUJS5J6D which is 30 chars long. You won’t need to type this password often so there is no need to use a memorable one.
To be honest, a weak password here wouldn’t be that bad since it is unlikely that you server will fall because of this…unless you expose it beyond 127.0.0.1.

For the hardening, start here. There is some smalltalk but there are also some good advices regarding a few topics:

• updates
• file permissions
• wp-admin
• wp-includes
• security plugins

updates
Keeping your installation up to date is paramount to ensure proper security. Before version 3.7 updates really sucked because the easiest way to (automatically) update was to have all files writable by the webserver process, so basically any malicious code executed by the webserver would be able to overwrite any file from our installation. The alternative was more secure but harder, so people wouldn’t update.
In the latest versions there is some magic that let you have automatic updates without the need to have files writable by the webserver. I think there is more than one way to achieve this: I went for the SSH one.
I followed this tutorial. In addition to the 5 defines added to the wp-config.php file, I also added define('FS_METHOD', 'ssh2');.
Since we are adding a new SSH user and we don’t want to increase your attack surface, disable password authentication for SSH at /etc/ssh/sshd_config with PasswordAuthentication no. Well…you should always disable password authentication for SSH.

file permissions
The important thing here is to prevent the webserver from writing files. There are some exceptions, as you might want to allow functionality such as image upload (so I can haz pretty potatoes pic).
You can have all files with owner and group wp-user, everything with 644 (files) or 755 (diretories).
The exception is wp-content/uploads that must be writable by the group (775) and have the group www-data set. You don’t need to allow webserver writing for the others since updates and installations are done through SSH and run with wp-user.

wp-admin
/wp-admin is a prime target for attackers because that is where you login to administrate your blog with your admin username and your weak password :)
Leaving /wp-admin world accessible exposes you to two problems: credential bruteforce/reuse/theft and direct access to files that may have all sort of vulnerabilities.
The most practical way to protect you from these is require some sort of authentication, say basic authentication. With nginx you just need to add this to your virtual host

location = /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /path/to/your/htpasswd;
}

and define the username and password. Please use a strong password here and also for your /wp-admin accounts.

EDIT
Also protect the /wp-login.php since it is used to login to edit the blog.
I include the snippet below to demonstrate the care you must take with nginx locations while configuring the rules described in this blog. Without going into details, prefix matching has precedence over regexp matching and nested locations with regex must have only regex inside.
location = /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/htpasswd;
}

location ~ \.php$ {
location ~* /wp-login.php {
auth_basic "Restricted login";
auth_basic_user_file /etc/nginx/htpasswd;
}

location ~* wp-config.php {
deny all;
}


security plugins
Having many plugins installed is asking for trouble since many have vulnerabilities and don’t even get fixed. So, going against the usual recommendation of not installing plugins, install the Sucuri Security – Auditing, Malware Scanner and Hardening plugin.
After installing, you get a Sucuri Security button on your dashboard side menu that lets you access the plugin dashboard

Some of the features are paid, but you get a few nice things for free. In the hardening tab you can verify if have the proper secure configurations, however some only work if you are using Apache. More specifically, “Protect uploads directory”, “Restrict wp-content access” and “Restrict wp-includes access” will remain red under nginx even if properly configured, because the plugin expects Apache specific configuration.
In the Settings tab you have another interesting feature: the scanner. The plugin can scan your wordpress installation for changes and notify you by email, like an HIDS. Go through the Settings tabs and activate/deactivate options as you please.

Additionally to the 5 previous topics, I recommend following this extra 2:

Delete themes
Regarding themes…you just use one so delete those you don’t use, as well as the pre-installed useless plugin Hello Dolly.

Limit PHP execution
Direct access to PHP files laying around in your installation are known to cause problem, so disable PHP execution wherever you can. If using nginx add the configuration below to your virtual host. For Apache just use the Sucuri plugin or use Google.

location ~* wp-config.php {
deny all;
}

location ~* wp-includes/uploads/sucuri$ {
deny all;
}

And finally…HTTPS
I don’ need extra motivation to make my blog available only by HTTPS but you if you are thinking twice, just remember Google favors HTTPS sites in the search results and you can get certificates for free from StartSSL, for instance.
Configuring HTTPS for WordPress is just like doing it for any another virtual host. Just remember a few things:

• change your site from http://example.com/ to https://example.com at Settings->General->WordPress Address and Site Address
• force a 301 redirect from HTTP to HTTPS
• send a HSTS header to ensure you are always under HTTPS
• disable all SSL versions and enable only TLS
• enable strong ciphers such as ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH
• enable server cipher preference

Then, go to SSL Labs and test your configuration.

If you are paranoid, you can continue hardening your WordPress, webserver, PHP, and OS forever, but you have to balance that against the time you have available.

So..I guess I have an WordPress blog. Lets see how long it holds without being hacked…