Locking down your WordPress site

Since I don’t really want to get in trouble for this, I need to put in a disclaimer.  Some of these tools can be invasive and if you are running them against somebody then I take no responsibility for their actions against you.  I am testing these tools against my own site so the consequences are minimal.  Just be aware that there can be serious consequences for using these tools on sites and companies against their will.  I don’t want anybody going to jail.

The tools

Let’s take a poke around with WP Scan.  This tool is a WordPress vulnerability scanner, often packaged together with Backtrack or the newer Kali Linux pentesting distro.   WPScan helps find and eliminate security weaknesses in your WordPress site.  More information about this tool can be found here.

There are many other tools out there but for basic WordPress scanning this tool should suffice, because it offers a number of things that are of interest in a nice single tidy and clean interface.  Other tools that may be of interest include tools like Burp Suite, SQLmap, username enumeration through Metasploit and other reconnaissance tools.

The process

Most real world attacks will reach for the low hanging fruit when it comes to exploiting WordPress sites, typically gaining access to a site through password exploitation.  With so many WordPress sites going up it becomes easy to move from site to site trying different password brute forcing attacks, so that’s where you will see a large number of attacks.  There are others as well, such as vulnerability attacks, SQL injection attacks, XSS, etc.

To begin the process let’s start gathering some information about the WordPress site that will be the focus of this attack, my blog.  Here, I am running WPScan through Kali Linux, so the syntax may change depending on how you decide to use this tool.  Let’s see what basic information we can get about my blog.  This site scan will attempt to gather the basics of the site it is scanning.  For help just type ‘wpscan –help’.

wpscan --url http://thepracticalsysadmin.com

Let’s see how far we can get with the password brute forcing method.  To enumerate a list of user account names use the following,

wpscan --url http://thepracticalsysadmin.com --enumerate u

If you get any interesting results from this scan, for example the result returns the username admin, go ahead and see if you can brute force the account.

wpscan --url http://thepracticalsysadmin.com --wordlist /pentest/passwords/wordlists/darkc0de.lst --username admin

There are more features packed in this tool so take some time to explore what all it can do (preferably on a test box).  Odds are that on a site that hasn’t been properly locked down you can probably get in, one way or another.  I wouldn’t recommend running wpscan against this site though because I have already beefed up the security and temporarily block access if users run malicious scans against the site.

Locking it down

There are a number of techniques to help reduce the attack surface for your WordPress site as well as methods to increase the difficulty of breaching your site.  The first and foremost is the use of strong passwords.  That should be a given and I won’t get into the details here of how important strong passwords are.  Another (hopefully) obvious technique is to keep up to date with your patches.  Whether it be on the Operating System or your WordPress site/plugins you should try to be proactive about patching your systems.  The third and final obvious solution I will mention are getting good backups.  If your site does get compromised then it is incredibly helpful to have a point in time to go back to rather than starting over from square one.  There are plugins designed to help with this process and even doing it by hand isn’t that difficult.  You can get back on your feet even if you only have a database dump from your site at some point in the past.

I’d like to specifically mention some good tools to use if you have publicly facing SSH; one of which is fail2ban.  This tool can be used as a layer of defense to slow attackers down by detecting malicious activity and banning IP addresses.  Another great tool, a handy plugin for WordPress  sites is called Better WP Security.  This is an easy to use site hardening tool that can fill up weaknesses and security holes quickly for somebody that doesn’t necessarily have security in the foreground of their minds.

By utilizing  these basic techniques you will infinitely increase your WordPress site’s security and make it much more difficult to attack and exploit.  There are of course other techniques to improve security but at a certain point it can become a balancing act.  *Most* site admins aren’t overly conscious about security and so do not spend a lot of time on their security efforts, they are more concerned about the content and getting things up.  Likewise, some are probably more prone to lock things down more than they perhaps need to.  It is important to maximize your effort, and to cover the most important security aspects by implementing the basics.

Read More

Centralising logs for fun and profit

It’s one of those things that usually gets pushed to the back burner because it seems like too much work for too little gain: setting up a central syslog server which all your other systems can report back to.

This is a shame, because there’s lots of benefits to having such a server:

  • You can analyse what’s going on in your network from a single, central location – saving you from having to log into a variety of devices for troubleshooting.
  • Improved security – if you have a security breach, the offender has to break into the logging server as well if they’re to cover their tracks properly. (I wouldn’t recommend re-purposing an existing server for precisely this reason – you want your syslog server to be as secure as possible, which means it needs to be running as few services as possible).
  • You only need to remember one set of tools to manage logs from a range of devices. Most routers will happily send logs back to a remote syslog server; there are also third-party products you can install on Windows.

It’s trivially easy to set this up in any reasonably modern Linux distribution. Once again, I’m going to use Debian for this example.

Out of the box, Debian uses rsyslog and stores the configuration file in /etc/rsyslog.conf. Fortunately, the default configuration only needs minor changes to two lines as shown in this excerpt:

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

Uncomment the lines beginning $ModLoad and $UDPServerRun by removing the # symbols:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Restart rsyslogd (service rsyslog restart) and…. that’s it. Done.

Well, that’s not quite it. A remote syslog server isn’t much good unless you have equipment sending logs to it.  On any other Debian servers you may have, this is just a matter of adding a line to /etc/rsyslog.conf:

*.* @192.168.42.39:514

(substitute your own logging server’s IP address or hostname for 192.168.42.39).

Restart rsyslog on the server that will be sending logs to your remote syslog server. Now when you check your remote syslog server, you should find logs appearing from both itself and anything else that’s configured to send logs to it.

Advanced Tweaks

Once you’ve got this done, there’s all sorts of things you can add. You can separate logfiles according to the host that generated them, you can have new logfiles created every day with an appropriate filename… or you can just stick with the basic configuration which will put everything in the same set of log files and just use grep to separate the interesting information.

Whatever you do, keep a sharp eye on disk space on your logfile server. Logs can grow very large very quickly, and a syslog server with a full disk won’t log anything at all.

Read More

A Brief Overview of the Linux chattr Command

I recently watched a talk given by Raphael Mudge, the creator of Armita, entitled “Dirty Red Team Tricks”. In this talk he basically goes over the basics of how to play the hacker version of capture the flag from the point of view of the offensive team or attackers, the red team (pretty self explanatory right?). It was a really good watch, and he demonstrated some really neat little tricks to the audience, including how to use Armitage effectively. Here is the link If you would like to view the presentation.

There was one very curious trick he mentioned in his talk that I want to focus this post on and to save as a note to myself for future reference. That is the chattr command.

The main use case for this command is to essentially make a file immutable by setting the “+i” flag. This is similar to using the attrib command in dos on Windows.  So for instance, you could do something like change the attributes of a password file or any other important file that you didn’t want getting altered by issuing the following command:

chattr +i some_file_name

Note, you must be root or in the sudo group to use this. Until the flag to turn this off is issued, even the root user cannot change the file, how cool is that?! I see why Mudge likes to use this dirty little trick when competing in capture the flag games now. So to check what attributes a particular file has applied to it you can use the lsattr command as follows, notice that the i flag is now set for the file:

lsattr some_file_name
----i------------e- some_file_name

And finally, to switch this flag off use the following command:

chattr -i some_file_name

We can check again to see if the flag actually got turned off:

lsattr some_file_name
-----------------e- some_file_name

That’s it. I couldn’t believe how simple this nasty little trick was to use but how effective it may be in a given situation. I hope this post was helpful for you, and seriously, you should check out Armitage if you are messing around with penetration testing tools, Raphael Mudge is a really smart dude.

Read More