Many local and online risks double up to threaten sites and servers as well, and in some cases the opposite is true. With our web assets though, given their constant availability and valuable prizes for the successful assailant, malicious possibilities, and the temptation to exploit those rocket our subject's risk factor, off the chart, to a sky-high level.
Note
How proactive we can be depends on our hosting plan. Then again, harping back to my point about security's best friend—awareness—even Automattic bloggers could do with a heads-up. Just as site and server security each rely on the other, this section mixes the two to outline the big picture of woe and general despair.
The overall concern isn't hard to grasp. The server, like any computer, is a filing cabinet. It has many drawers—or ports—that each contain the files upon which a service (or daemon) depends. Fortunately, most drawers can be sealed, welded shut, but are they? Then again, some administrative drawers, for instance containing control panels, must be accessible to us, only to us, using a super-secure key and with the service files themselves providing no frailty to assist forcing an entry. Others, generally in our case the web files drawer, cannot even be locked because, of course, were it so then no one could access our sites. To compound the concern, there's a risk that someone rummaging about in one drawer can internally access the others and, from there, any networked cabinets.
Let's break down our site and server vulnerabilities, vying them against some common attack scenarios which, it should be noted, merely tip the iceberg of malicious possibility. Just keep smiling.
Just how secure is the filing cabinet? We've covered physical security and expanded on the black art of social engineering. Clearly, we have to trust our web hosts to maintain the data center and to screen their personnel and contractors. Off-server backup is vital.
We manage ports, and hence differing types of network traffic, primarily with a firewall. That allows or denies data packets depending on the port to which they navigate.
FTP packets, for example, navigate to the server's port 21. The web service queues up for 80. Secure web traffic—https rather than http—heads for 443. And so on. Regardless of whether or not, say, an FTP server is installed, if 21 is closed then traffic is denied.
So here's the problem. Say you allow an FTP service with a known weakness. Along comes a hacker, exploits the deficiency and gains a foothold into the machine, via its port. Similarly, every service listening on every port is a potential shoo-in for a hacker.
Note
Attacking services with a (Distributed) Denial of Service attack
Many in the blogging community will be aware of the Digg of death, a nice problem to have where a post's popularity, duly Digged, leads to a sudden rush of traffic that, if the web host doesn't intervene and suspend the site, can overwhelm server resources and even crash the box. What's happened here is an unintentional denial of service, this time via the web service on port 80.
As with most attacks, DoS attacks come in many forms but the malicious purpose, often concentrated at big sites or networks and sometimes to gain a commercial or political advantage, is generally to flood services and, ultimately, to disable HTTP. As we introduced earlier, the distributed variety are most powerful, synchronizing the combined processing power of a zombie network, or botnet, against the target.
In most cases, we simply deny access by disabling the service and closing its port. Many of us, after all, only ever need web and administration ports. Only? Blimey!
Server ports, such as for direct server access or using a more user-friendly middleman such as cPanel, could be used to gain unwanted entry if the corresponding service can be exploited or if a hacker can glean your credentials. Have some typical scenarios.
This highly prevalent kind of memory attack is assisted by poorly written software and utilizes a scrap of code that's often introduced through a web form field or via a port-listening service, such as that dodgy FTP daemon mentioned previously.
Take a simplistic example. You've got a slug of RAM in the box and, on submitting data to a form, that queues up in a memory space, a buffer, where it awaits processing.
Now, imagine someone submits malicious code that's longer, containing more bits, than the programmer allowed for. Again, the data queues in its buffer but, being too long, it overflows, overwriting the form's expected command and having itself executed instead.
As with oh-so-many attacks, this manipulation is possible because the code's programmer hasn't ensured proper user input validation. The result could be anything from a crashed box to the hacker gaining a foothold into the machine.
Note
As we find in Chapter 2, these attacks are kiddie-play for known exploits. Using a couple of choice tools, for example, we'd scan to find some buggy service and, having cross-referenced a proven attack, deliver a compromising payload.
Security discipline protects against known exploits. We can only hope our multi-layered defense in depth will deflect the dreaded zero day, on the other hand.
So what about the worry of swiped access credentials? Again, possibilities abound.
The MITM is where someone sits between your keystrokes and the server, scouring the data. That could be, for example, a rootkit, a data logger, a network, or a wireless sniffer.
If your data transits unencrypted, in plain text, as is the case with FTP or HTTP and commonly with e-mail, then everything is exposed. That includes login credentials.
Brute force attacks, on the other hand, run through alphanumeric and special character combinations against a login function, such as for a control panel or the Dashboard, until the password is cracked. They're helped immensely when the username is known, so there's a hint not to use that regular old WordPress chestnut, admin.
Brute forcing can be time-consuming, but can also be coordinated between multiple zombies, warp-speeding the process with the combined processing power. Dictionary attacks, meanwhile, throw A-Z word lists against the password and hybrid attacks morph brute force and dictionary techniques to crack naïve keys such as pa55worD.
XSS crosses bad code—adds it—with an unsecured site. Site users become a secondary target here because when they visit a hacked page, and their browser properly downloads everything as it resolves, they retrieve the bad code to become infected locally.
An in-vogue example is the iframe injection which adds a link that leads to, say, a malicious download on another server. When a visitor duly views the page, downloading it locally, malware and all, the attacker has control over that user's PC. Lovely.
There's more. Oh so much more. Books more in fact. There's too much to mention here, but another classic tactic is to use XSS for cookie stealing.
... All that's involved here is a code injection to some poor page that reports to a log file on the hacker's server. Page visitors have their cookies chalked up to the log and have their session hijacked, together with their session privileges. If the user's logged into webmail, so can the hacker. If it's online banking, goodbye to your funds. If the user's a logged-in WordPress administrator, you get the picture.
This is not the same as XSS, but there are similarities, the main one being that, again, a blameless if poorly built site is crossed with malicious code to cause an effect.
A user logs into your site and, in the regular way, is granted a session cookie. The user surfs some pages, one of them having been decorated with some imaginative code from an attacker which the user's browser correctly downloads. Because that script said to do something to your site and because the unfortunate user hadn't logged out of your site, relinquishing the cookie, the action is authorized by the user's browser.
What may happen to your site, for example, depends on the user's privileges so could vary from a password change or data theft to a nice new theme effect called digital soup.
Unsecured access is a prime risk factor so let's re-spin the key concerns from the previous section:
wp-loginisn't the only login to shore up. Server logins, those for panels such as cPanel and phpMyAdmin, for file shares, and client areas all attract threats.Users such as root or admin are red flags to bullish brute force and other attacks.
Passwords need care. Actually, passwords are generally rubbish. Instead use unique, long, camelCase, alpha-numeric passphrases with special characters.
Using unencrypted HTTP and FTP for anything of value is plain text silly.
Open or unfiltered ports with unpatched services are gateways to hell.
The last point or two gives us the biggest headache: the dichotomy that is allowing HTTP access, yet denying the majority of server functionality. Panic stations!
So what else do hackers love us for?
A lackadaisical approach to maintenance is often the precursor to becoming successfully screwed. For instance, having installed the platform so easily, it may be tempting to think WordPress can just be left to do its own thing. Some of us, perhaps blogging by e-mail or using tools such as Press This or ScribeFire, may only rarely visit the Dashboard, far less the server. Even if you do, do you properly maintain these web assets on an ongoing basis?
Applications are patched for a reason and frequently that involves a newly found threat. Particularly if you leave unpatched, for example, web assistive programs such as Apache or PHP, else web admin services, your server could be fair game for attack.
Attention to updates is a fair start. Patch that weakness before it's exploited. This is vital for the WordPress core and, often more so, is vital for third party code such as plugins.
Note
Code red: themes, plugins, widgets, and tweaks
Introducing third party code throws up one of the biggest areas of concern.
A quick glance at the WordPress repository shows up over 1000 themes and approaching 10,000 plugins. Moreover, the nature of the platform allows us to personalize it with widgets and bespoke code such as functions, scripts, and forms. Each and every tweak is a potential Achilles' heel for the security of a site.
The point to understand is this: as soon as we detour from the generic platform, we're unprotected from the official and well-honed WordPress umbrella of vulnerability patching. Third party vulnerabilities stem from three factors:
Poor coding.
Lack of testing.
Bad maintenance.
This isn't to say that the wider WordPress development community is inept. Hardly! Tread carefully though. One worry is, being relatively easy to learn basic PHP programming, anyone can knock together a functional script. Validating that against exploitation, though, requires advanced knowledge of the language.
Otherwise, where possible, any site and server packages should be diligently tweaked with security in mind, with no syntactical errors, with logging enabled and with the logs being protected so hackers can't edit them. Anything else invites unwanted attention.
Bulk is risk and less is more so, for any app, script, plugin, or theme, if you don't use it, lose it. Backups, meanwhile, should never live on the server. Imagine the grief if the box is bashed and, perhaps despite MySQL withstanding the attack, its backup is available.
Then there are concerns about our users, the bad ones. There are numerous steps that we must take to keep the more dubious types at bay, retaining their level of subscriber and denying them elevation to the role of administrator. Many techniques are not default-set, often involving the server-side settings of web file ownership and permissions.
If we don't ensure canny ownership and least privilege permissions, then a single file can help a hacker to prise a larger opening. Potentially, for example, a user on a shared server could escape his or her jailed area and into yours or, worse, could wrangle root rights to compromise the entire server. Then again, correctly configured, if a hacker does find a way to manipulate a file, we're better poised to contain damage within an isolated area.
Note
Assorted attacks with SQL injection
One way to escalate user privileges is with a SQL injection attack.
SQL is the Structured Query Language, a bunch of commands that create, query, and edit a database. WordPress installations tend to use the MySQL brand.
A SQL injection is just that, an injection of code and if the database hasn't been properly locked down and with decent PHP protection, it will either accept that code or, if the code has poor syntax, throw an error that includes big fat clues.
Using SQL injection the hacker manipulates the database to do potentially anything you can do using, say, phpMyAdmin, so may kick off by exploring the database structure but ultimately doing despicable things such as creating a WordPress administrator, activating a malicious plugin, or stealing valuable data.
Other lingos aren't immune to the wider set of code injection attacks which, for example, may upload files or execute commands from a browser's address bar.
Using SQL injection to force an error isn't the only way to uncover hacking tip-offs such as, in that case for example, what plugins or database table prefix you're using.
Note
Be under no false impression about the danger from info leak. If hackers can tease a choice tidbit they may have an in, whether locally, to the site or its server.
When we think of a common data leak, the example that springs to mind may be the WordPress or web server version, but when hackers build a target profile, their techniques may lead them to far further afield than a site's source code or a forced error page. Gathering telling data involves anything from social engineering to Google hacking, reading WHOIS records and network, vulnerability and web application scanning.
Note
Google hacking for site reconnaissance
Hackers needn't visit a site to gain information. Cue an example Google search:
site:somesite.com intitle:index of
That finds pages, including old cached ones, with the keywords in the title and could be used, for instance, to check for error messages on a site or, as here, to pull up directory listings. Kiddies aren't always choosy, mind. They may just use the intitle operator to pull up a playtime list of vulnerable sites.
More on Google hacking and other blood-curdling info 'sploits in Chapter 2.
Another trusty old-timer forces a site error by inputting an incorrect address in the browser, perhaps revealing Apache or PHP information as well as that of MySQL.
Many of us WordPress bloggers know a cite more about content than we do about sites. After all, WordPress traditionally is a writer's tool. (Security? Little did we know!)
Quite likely then you're acquainted with scraping and maybe even know how that can negatively affect your search result position and therefore, in some cases, your income.
Content needs securing too. Arguably in some cases, more than anything else. The reality is that we can't preemptively secure content. What we can do though, for example, is to Google hack-happy to know who's got what, then send out copyright violation notices.
All that said, scraping isn't necessarily such a bad thing because, properly managed, it helps to build relationships, to drive traffic, and to improve SEO.
Hotlinking, on the other hand, not only pinches our content but at the expense of our server resources. Most outrageous really. Fortunately, this is easily prevented.
You may be used to raising an eyebrow at the tell-tale signs of an automated comment, bot-sent, hell-bent and linking to some torrid trash can of an excuse for a site. Frankly.
Spam is nauseating not only because it's like bad graffiti, but also because it dilutes the value of decent content. Rather than add a kind word or helpful information, spam defaces a site, butts into discussion between real-deal site users and, if you've not already become jaded enough to stop following links to spread the SEO love stuff, gives credit where it's never due while reducing the search value of your site. The cheek of it.
Worse still is when spam leaves the remit of annoyance to enter the danger zone. It's often injected into page content, so that sweet tutorial about baking cakes is suddenly laced with links to some scurrilous porn site or, more underhand still, your precious htaccess site configuration file becomes littered with spam redirections to a rogue site that ruins your users as well as your reputation.
Besides, Spam tastes awful. Corned beef is much nicer. Well, it's relative.