You'd best sit down.
It stands to reason that we can't properly secure a WordPress site until we have a heads-up on its vulnerabilities and the threats it faces. So let's kick off by ensuring awareness.
In this opening chapter, we'll set the scene by introducing the hackers and their tricks and considering how the former plies the latter against a site, whether directly or indirectly:
Knowing the enemy, the variety of mindset, and the levels of skill
Considering physical security and the threat from social engineering
Weighing up OS security, allow vs. deny policies and open vs. closed source
Mulling over malware in its many shapes and forms
Assessing risks from local devices such as PCs and routers
Treading carefully in the malicious minefield that is the web
Sizing up vulnerabilities to WordPress and its third party code
Addressing the frailties of and attacks to your server-side environment
You may think that most of this is irrelevant to WordPress security. Sadly, you'd be wrong.
Your site is only as safe as the weakest link: of the devices that assist in administering it or its server; of your physical security; or of your computing and online discipline. To sharpen the point with a simple example, whether you have an Automattic-managed wordpress.com blog or unmanaged dedicated site hosting, if a hacker grabs a password on your local PC, then all bets are off. If a hacker can borrow your phone, then all bets are off. If a hacker can coerce you to a malicious site, then all bets are off. And so on.
Let's get one thing clear. There is no silver bullet as I will repeat throughout this book. There is no such thing as total security and anyone who says any different is selling something. Then again, what we can achieve, given ongoing attention, is to boost our understanding, to lock our locations, to harden our devices, to consolidate our networks, to screen our sites and, certainly not least of all, to discipline our computing practice.
Even this carries no guarantee. Tell you what though, it's pretty darned tight. Let's jump in and, who knows, maybe even have a laugh here and there to keep us awake ☺.
So what is the risk? Here's one way to look at the problem:
A vulnerability is a weakness, a crack in your armour. That could be a dodgy wireless setup or a poorly coded plugin, a password-bearing sticky note, or an unencrypted e-mail. It could just be the tired security guy. It could be 1001 things, and then more besides. The bottom line vulnerability though, respectfully, is our ignorance.
A threat, on the other hand, is an exploit, some means of hacking the flaw, in turn compromising an asset such as a PC, a router, a phone, your site. That's the sniffer tool that intercepts your wireless, the code that manipulates the plugin, a colleague that reads the sticky, whoever reads your mail, or the social engineer who tiptoes around security.
The risk is the likelihood of getting hacked. If you update the flawed plugin, for instance, then the threat is redundant, reducing the risk. Some risk remains because, when a further vulnerability is found there will be someone, somewhere, who will tailor an exploit to threaten it. This ongoing struggle to minimize risk is the cat and mouse that is security.
You may be wondering, why bother calculating risk? After all, any vulnerability requires attention. You'd not be wrong but, such is the myriad complexity of securing multiple assets, any of which can add risk to our site, and given that budgets or our time are at issue, we need to prioritize. Risk factoring helps by initially flagging glaring concerns and, ideally assisted by a security policy, ensuring sensible ongoing maintenance.
Securing a site isn't a one-time deal. Such is the threatscape, it's an ongoing discipline.
Let's take a WordPress site, highlight potential vulnerabilities, and chew over the threats.
Note
WordPress is an interactive blogging application written in PHP and working in conjunction with a SQL database to store data and content . The size and complexity of this content manager is extended with third party code such as plugins and themes . The framework and WordPress sites are installed on a web server and that, the platform, and its file system are administered remotely .
WordPress. Powering multi-millions of standalone sites plus another 20 million blogs at wordpress.com, Automattic's platform is an attack target coveted by hackers. According to wordpress.org 40% of self-hosted sites run the gauntlet with versions 2.3 to 2.9.
Interactive. Just being online, let alone offering interaction, sites are targets. A website, after all, is effectively an open drawer in an otherwise lockable filing cabinet, the server. Now, we're inviting people server-side not just to read but to manipulate files and data.
Application, size, and complexity. Not only do applications require security patching but, given the sheer size and complexity of WordPress, there are more holes to plug. Then again, being a mature beast, a non-custom, hardened WordPress site is in itself robust.
PHP, third party code, plugins, and themes. Here's a whole new dynamic. The use of poorly written or badly maintained PHP and other code adds a slew of attack vectors.
SQL database. Containing our most valuable assets, content and data, MySQL, and other database apps are directly available to users making them immediate targets for hackers.
Data. User data from e-mails to banking information is craved by cybercriminals and its compromise, else that of our content, costs sites anything from reputation to a drop or ban in search results as well as carrying the remedial cost of time and money.
Content and media. Content is regularly copied without permission. Likewise with media, which can also be linked to and displayed on other sites while you pay for its storage and bandwidth. Upload, FTP, and private areas provide further opportunities for mischief.
Sites. Sites-plural adds risk because a compromise to one can be a compromise to all.
Web server. Server technologies and wider networks may be hacked directly or via WordPress, jeopardizing sites and data, and being used as springboards for wider attacks.
File system. Inadequately secured files provide a means of site and server penetration.
Administered remotely. Casual or unsecured content, site, server, and network administration allows for multi-faceted attacks and, conversely, requires discipline, a secure local working environment, and impenetrable local-to-remote connectivity.
Note
We'll spend the rest of Chapter 1 expanding on these overall concerns. First up, let's set the stage with the main players in the security scene, the hackers.
This may sound like anathema, but a hefty chunk of this book is devoted to cajoling your angelic innocence into something more akin to that of a hacker's savvy.
This isn't some cunning ploy by yours-truly to see for how many readers I can attain visitor's rights, you understand. The fact is, as we practise in Chapter 2 and as any crime agency would explain, to catch a thief one has to think like one.
Besides, not all hackers are such bad hats. Far from it. Overall there are three types—white hat, grey hat, and black hat—each with their sub-groups.
One important precedent sets white hats above and beyond other groups: permission.
Also known as ethical hackers, these decent upstanding folks are motivated:
To learn about security
To test for vulnerabilities
To find and monitor malicious activity
To report issues
To advise others
To do nothing illegal
To abide by a set of ethics to not harm anyone
So when we're testing our security to the limit, that should include us. Keep that in mind.
Out-and-out dodgy dealers. They have nefarious intent and are loosely sub-categorized:
A botnet is a network of automated robots, or scripts, often involved in malicious activity such as spamming or data-mining. The network tends to be comprised of zombie machines, such as your server, which are called upon at will to cause general mayhem.
Botnet operators, the actual black hats, have no interest in damaging most sites. Instead they want quiet control of the underlying server resources so their malbots can, by way of more examples, spread malware or Denial of Service (DoS) attacks, the latter using multiple zombies to shower queries to a server to saturate resources and drown out a site.
These are hackers and gangs whose activity ranges from writing and automating malware to data-mining, the extraction of sensitive information to extort or sell for profit. They tend not to make nice enemies, so I'll just add that they're awfully clever.
Politically-minded and often inclined towards freedom of information, hacktivists may fit into one of the previous groups, but would argue that they have a justifiable cause.
While not technically hackers, scrapers steal content—often on an automated basis from site feeds—for the benefit of their generally charmless blog or blog farms.
This broad group ranges anything from well-intentioned novices (white hat) to online graffiti artists who, when successfully evading community service, deface sites for kicks.
Armed with tutorials galore and a share full of malicious warez, the hell-bent are a great threat because, seeking bragging rights, they spew as much damage as they possibly can.
Again not technically hackers but this vast group leeches off blogs and mailing lists to promote their businesses which frequently seem to revolve around exotic pharmaceutical products. They may automate bomb marketing or embed hidden links but, however educational their comments may be, spammers are generally, but not always, just a nuisance and a benign threat.
Grey hatters may have good intentions, but seem to have a knack for misplacing their moral compass, so there's a qualification for going into politics. One might argue, for that matter, that government intelligence departments provide a prime example.
Strictly speaking, hackers are white hat folks who just like pulling things apart to see how they work. Most likely, as kids, they preferred Meccano to Lego.
Crackers are black or grey hat. They probably borrowed someone else's Meccano, then built something explosive.
Over the years, the lines between hacker and cracker have become blurred to the point that put-out hackers often classify themselves as ethical hackers.
This author would argue the point but, largely in the spirit of living language, won't, instead referring to all those trying to break in, for good or bad, as hackers. Let your conscience guide you as to which is which instance and, failing that, find a good priest.
So far, we have tentatively flagged the importance of a safe working environment and of a secure network from fingertips to page query. We'll begin to tuck in now, first looking at the physical risks to consider along our merry way.
Note
Risk falls into the broad categories of physical and technical, and this tome is mostly concerned with the latter. Then again, with physical weaknesses being so commonly exploited by hackers, often as an information-gathering preface to a technical attack, it would be lacking not to mention this security aspect and, moreover, not to sweet-talk the highly successful area of social engineering.
Physical risk boils down to the loss or unauthorized use of (materials containing) data:
Break-in or, more likely still, a cheeky walk-in
Dumpster diving or collecting valuable information, literally from the trash
Inside jobs because a disgruntled (ex-)employee can be a dangerous sort
Lost property when you leave the laptop on the train
Social engineering which is a topic we'll cover separately, so that's ominous
Something just breaks ... such as the hard-drive
Password-strewn sticky notes aside, here are some more specific red flags to consider when trying to curtail physical risk:
Building security whether it's attended or not. By the way, who's got the keys? A cleaner, a doorman, the guy you sacked?
Discarded media or paper clues that haven't been criss-cross shredded. Your rubbish is your competitor's profit.
Logged on PCs left unlocked, unsecured, and unattended or with hard drives unencrypted and lacking strong admin and user passwords for the BIOS and OS.
Media, devices, PCs and their internal/external hardware. Everything should be pocketed or locked away, perhaps in a safe.
No Ethernet jack point protection and no idea about the accessibility of the cable beyond the building.
No power-surge protection could be a false economy too.
This list is not exhaustive. For mid-sized to larger enterprises, it barely scratches the surface and you, at least, do need to employ physical security consultants to advise on anything from office location to layout as well as to train staff to create a security culture.
Otherwise, if you work in a team, at least, you need a policy detailing each and every one of these elements, whether they impact your work directly or indirectly. You may consider designating and sub-designating who is responsible for what and policing, for example, kit that leaves the office. Don't forget cell and smart phones and even diaries.
Note
Refer to Appendix C's Security Policy as a template to start working on yours.
This is the age-old practice of conning naturally trusting people into doing something under false pretences. The extraordinarily effective techniques can be played out in person or online. Here are some confident examples.
Individuals or company employees may be targeted with a call from someone pretending to be a fresh-faced co-worker, an irate boss, a record-keeping human resources manager, or a concerned IT administrator, for example. The engineer may plead for, else demand, sensitive information such as a name, contact, a username, or a password. They may be phoning from, say, your workplace reception area or could be using a spoof caller ID service to give them internal credibility while actually calling from an outside line.
The walk-in alternative of, or extension to, the phone call scam, sees a social engineer pose in one of many possible roles to gain entrance to a building, to gain people's confidence, and ultimately to steal something sensitive such as network credentials.
Here moving into a technical vein, an attractive link, perhaps added to a site without the owner's knowledge, grabs your attention so you click it. Bam! You've been subjected to a Cross Site Scripting (XSS) attack. The retrieved site is malicious but it's unlikely you'd suspect that. You could be lured to download malware if you'd not already done so when resolving the page, else to provide some sensitive data. This is a commonplace scenario.
These prolific e-mail scams, again, often try to tempt you to some site where you're liberally scalped. Alternatively you could receive a spoof e-mail that is apparently from a known contact who has kindly sent you a file. Duly executed, the Trojan rootkit now provides the hacker a controlling backdoor access to your PC and its network.
Here's the growth market. Splashing around your sensitive data, trusting any old social application, and friending strangers on traceable online profiles is begging for trouble.
Engineering social networks is like shooting fish in a barrel, but there's also low hanging fruit to be had in forums, on personal or business sites, on blogs and wikis, and in newsgroups where, for instance, your new IT recruit may be asking what's the problem with that vulnerable old version of something like, well, WordPress for example.
Social engineering is invariably tough to tackle, but what we can do is to create general awareness and set down a policy of what team members can and cannot divulge to anyone without a proven identity. That policy should extend to the use of network kit, of any type, that leaves the office and, sadly, may have to extend to internet use as well.
Note
Again, refer to Appendix C's Security Policy as a help in setting up security rules.
Bear in mind that the guy who's copying that joke to your thumbdrive could be uploading a worm as well, the girl who's borrowing your wireless may be infiltrating the network, or the colleague who's fawning over your new phone could be tapping your data. You have to be ultra-careful who you trust and, for those working for you, you should give them the excuse to blame their refusal on strictly enforced default-deny guidelines.
Note
Technically risky
Let's advance to this book's core task, assessing and protecting those technical risks to your site and, by relation, to network assets also affecting its security.
We'll slice and dice the broad scope of the subject by starting locally with the PC and winding up in the guts of the site and server. First we'll assess the broad risk and, throughout the ensuing chapters, reflect that with our end-to-end solutions.
Let's be clear, no system is immune to virus threats, not least of all because we remain equally capable of being socially engineered, of being duped into running malware. Then again, if you're serious about security, then use a system that's designed around security. In other words that's Linux-based or, to a lesser extent, a Mac. So why?
They benefit from deny-by-default permission models
Linux is open source (OS X is partly)
Note
For the ultimate in security, we'd run a BSD system such as PC-BSD. The downside is reduced usability and a more limited community to help. This book therefore looks at systems requiring less of a brain tease. Then again, decide for yourself:
BSD operating systems – http://www.bsd.org
BSD from A-Z – http://forums.freebsd.org/showthread.php?t=9294
Windows has long been a hacker's target of choice due to its popularity. There's another reason too. Up until Vista, Windows systems have been far easier to hack due to the allow-by-default permission model where a standard user—including an interloping hacker using your rights—needs no administrative privileges to execute a script. The script could be a friendly program executable. It could also be a virus.
Compare that to the deny-by-default policies of Macs and Linux: neither we nor anyone else can execute files without first escalating user rights to those of an administrator. When you hear these systems' users saying they don't run anti-malware suites—which is not recommendable by the way—yet have never been hit, this is the main reason why.
Note
There's another reason. Hackers haven't been hitting Linux or Macs. With Windows 7 proving a tougher target, they're now beginning to, particularly against OS X, and the myth that these two systems are "secure" may finally be broken.
Meanwhile, hacked to a pulp, Microsoft eventually wised up with the security U-turn that was Vista which adopts deny-by-default. They dub it User Account Control. Vista, otherwise, was a pig's ear of a pear shape. Windows 7, on the other hand, is a very decent system offering security as well as prettiness. After 20 odd years of Microsoft, well done!
Note
So what about Windows XP? After all, it has almost as many users as all the other operating systems combined. Well, in terms of their scope for exploitation, the malware magnets that are XP and earlier may be reliably compared to Swiss cheese. Chapter 3's solutions will help ... as will trundles of maintenance time.
Like WordPress or server-side apps such as Apache, MySQL, or PHP, Linux is open as opposed to closed source, so what the bejeebers is that?
Take Windows. This is closed, proprietary software, meaning that only a relatively tiny team of talents can develop it, for instance smoking out bugs before pushing out patches.
Compare that to most Linux systems. Being open, they can be tweaked and tested by anyone working in a strict hierarchy of users and geeks-on-high to ensure quality control.
OS X, meanwhile, has a proprietary user interface and applications, but sits on an open source kernel, the system core which, in this case, is a fork from BSD.
So this is a numbers game. Do the math. Aside from being free, open source software is more thoroughly tested and, finding a bug, the patch rollout is often dramatically faster.
At the risk of further fanning the flame wars, of the more user-friendly systems, the open model of Linux gives it the security edge. That said, Macs aren't far behind and Windows 7 is worthy of praise. This is very much IMHO, I hasten to add. The lack of a level playing field, where for instance hackers still mostly target Windows systems which also dominates market share, makes a fully justifiable comparison impossible to achieve.
XP, on the other hand, requires great user discipline to ensure security. That's not to say it can't be used. It can. It would, however, be dim to encourage its use in a security book.
We'll look now at the kind of malwares that can afflict any system. In Chapter 3, we'll apply an extensive anti-malware solution to keep those dangers in check as best we can, primarily nursing the most needy patient overall, Windows.
So, what is a rootkit anyway? Let's categorize malwares and, to be clear, the jargon surrounding these little critters that compromise machines and data. Hold on to your hats.
The biggest threats that we face, both locally and on our remote servers, are from malware cocktails that embody a malevolent mix to produce devastatingly wide-reaching attacks.
For example, take a worm and cross it with a rootkit and you have the famous W32/Blaster. Blaster took advantage of a Windows deficiency to propagate far and wide and had a mission to execute a Denial of Service attack on the Windows Update service from infected hosts, all at the same time. While the worm itself didn't cause lasting damage to the host machines' data, it slowed them down and bunged up their web connections making it harder to download removal instructions and patches.
Choice blends, otherwise, tend to bundle some miscreant into a Trojan which is a bit like coating arsenic with a sugar substitute and pretending it's candy.
An increasingly threatening trend in cybercrime, crimeware comes in many malicious forms which seek to steal confidential data for the purpose of financial exploitation. Mostly, it's directed at financial, military, and government networks.
As with many malwares, there can be useful equivalents to data loggers and we commonly use them, for instance, to record and repeat tedious exercises such as form filling. Data loggers can also be hardware-based.
In terms of malicious use though, data loggers can be wrapped into all manner of malware and planted onto our machines to record our activities, our data, in fact anything and everything that we or our device does.
You've probably heard of keystroke loggers, or keyloggers, that record your typing and send off the text to some remote place where, then, someone's kind enough to siphon off your hard-earned cash? Well, if that's the big daddy of data loggers, he's got an in-bred family from hell, often scamming together, and they none of them smell any too pretty:
Keyloggers. We covered these spy tools, used for social profiling and data-mining. Damn annoying just to think about and hot damn dangerous in the practical. Maybe you think you're safe because you copy/paste everything?
Clipboard loggers. Well, I warned you. Talk about bad form ...
Form grabbers. Capturing form data entry, including hidden passwords.
Password loggers. They tap into applications so that, for instance, when you provide that super-secure password and it shows up as a row of asterisks like this, ****************, the logger reports back the actual key.
Screen loggers. They take screenshots periodically or, given a mouse click, catch anything from around the cursor to the entire ruddy screen.
Link loggers. If you don't want the world to know that your true passions are knitting and crochet, think twice before navigating those knotty links.
Wireless keyboard sniffers. Working rather like wireless sniffing, the hacker catches the data packets between your keyboard and the PC.
Acoustic keyloggers. Assimilating a sound pattern from the manner in which you type, these note the subtle differences between hitting the various keys, reporting back a transcript. Here, at least, it pays to be a poor typist.
There are more, capturing Instant Messaging, Text Messaging, phone numbers, FTP traffic, controlling your webcam and so on and so forth, and with variants residing not only independently but attaching to programs, to keyboard drivers, embedding into operating system kernels, and even sitting beneath the OS as a kind of virtual system. So there's some fun.
That's probably enough of a hint. Keyloggers can be nigh-on impossible to detect and are a mighty good reason, from day one, to keep a clean and lean, local machine.
Hoax viruses are just that, hoaxes, and generally take the form of chain-mail. They socially engineer a degree of panic whereby, for example, someone is persuaded to delete important system files or visit a rogue site that may plant malware or extract user data.
These give away the keys by providing, for instance, a back door access on a computer to provide a hacker with full local administrative—or root—control, together with all the associated network privileges. That's as dangerous as it sounds. What's more, they're not as easily detected as other malwares and may be confused for rootkits that are good and wanted.
Often bundled in crapware to covertly log our computing habits, spywares are highly intrusive and used for anything from market research to monitoring employees.
Some would argue that an alternative form of spyware is the tracking cookie and, more accurately, that another is the LSO or flash cookie which logs browsing habits and is more difficult to remove than a regular cookie. Many major sites inflict these upon us.
As already touched on, a Trojan masquerades as something useful but, installed, enables some kind of malware.
Often bundled into Trojans that are shared by downloads, e-mail, or media storage, viruses are executed manually to infect a file system. The macro virus, meanwhile, is a virus that hides in macros and is executed in programs such as office software.
Automatically replicating themselves on a computer, worms spread quickly by penetrating networks with security loopholes.
In the underworld of black hat hackerdom, the zero day is the crème de la même.
So what is a zero day? And in that question lies an oxymoron, because by their very nature, nobody knows what a zero day is until one is discovered. (I'm being difficult.)
Zero days are newly found vulnerabilities and the clock ticks loudly until a remedial patch is released. If we're lucky, it is a white hat such as the software vendor who discovers the problem, patching it before hackland is able to attack too many victims.
And really, it's these zero days and the clever manipulation of malware that is at the crux of network security, from our humble devices through to the weaving web itself. With an inkling of the above, we can understand the race against time to keep our systems secure.
Network security is never something to be taken for granted. Web-connected, the threatscape multiplies exponentially. Be under no illusion, the place is a war zone.
Of all our local programs, it's the browser that most generally flies closest to the sun, the hackfest that is the web. Browsers that aren't religiously updated are likely to be prone to infection, some posing mild and others critical risks such as allowing the local installation of malicious code even though the user's merely browsing innocent-looking sites.
The browser isn't the only worry. Any application is a worry. Web-facing ones—anything that traffics data via a port as we'll detail later in the chapter—are a particular worry. These days, that's most of them as they send reports about who-knows-what back to their big brother marketers. Delete anything you don't need and set the rest to auto-update.
Any data you send over the web is fair game for interception and, among many other things, extortion. That could be your IM or VOIP chatter, it could be your e-mail or webmail, it is everything via FTP, it is everything over HTTP.
Note
FTP is perilous. So is Telnet. So is HTTP. We cover safe protocols in Chapter 5.
Yes, we covered some of this already. You need to hear it again.
Sites get hacked and often the visitor is the target. As we'll cover soon enough in this chapter, we can innocently surf a trusted site, click on a link and, hey presto: blue screen. Really, it's a base example but the fact is that, online, it's that easy to get hit. What's worse is when there's no blue screen and we've no idea we just downloaded a keylogging rootkit. (And just before logging into the server too, which five minutes later becomes the latest addition to some Russian botnet while our data's being sold to the highest bidder.)
Then there's socially engineered traffic-driving, frequently via a nasty Facebook app or one of those short links on Twitter. Before you know it you've been phished off, pressed the wrong button, and went and sold Grandma. Or maybe you wanted that XYZ off thepiratething, else P2P'ed the crack, only it was a hack and you took the whack. Not to mention the red lights, or the gambling dens, hardly breathing the problems with the try this links on IRC and so on, and on, and on, and on.
If it smells fishy but it's not edible, throw it back. Fishy or not, if it's a link, know the risk.
Hmmn, this'll be mainly about cybercafés then. Well, infection per se, you may as well eat your dinner off the floor of a WC, let alone use a public PC. Just read that bit about browser updates again, look me in the eye and tell me you think that those machines are secure. We'll have some fun here in Chapter 4. Following that you may never go, laptop-free, on holiday again.
OK, this is a biggie so pay attention. Wireless sniffing is hazardous to your network, your site, your wallet, and not least of all to your stress level.
Running an Ethernet-cabled network and internet connection, barring cable bashing hackers, is fool-proof but, if you haven't taken the time to properly secure a wireless connection, you may as well climb onto the roof and start shouting out your passwords, credit card numbers, personal fetishes, and the fact that you hate your boss. Or if you get vertigo, just hook up a 60" monitor and pop it in the window facing the street.
You're especially vulnerable to having your wireless sniffed—where your web traffic data packets are intercepted, decoded, and later mined for data or personal profiling—if:
Actually, that's it. Sure there may be other worries like, come the case-study medical papers, that we're beginning to resemble 60-second chicken dinners, but this is the bottom line security concern.
Similarly, given the above, it doesn't take a genius to work out that inherently insecure hotspots aren't great places to maintain your site or file a tax return. Indeed, they're piping red hot danger zones, and then there are the evil twins ...
An evil twin mimics a public wireless point, but has been set up by a phisher, often usurping a genuine neighboring hotspot. It induces you with free web access before sniffing data that may be used, say, to deplete your smile.
Meanwhile, the spoof hotspot logon page typically phishes your user data, harvests account information, and injects malware onto your device. Nice.
By way of a section summary and in terms of the threats we face, the web is ground zero. It's fabulous, enriching, a hell of a surf. It's downright dangerous, getting red-line worse, and we've barely scratched the surface.
The security of your site, your network, your business, and your identity depend upon you understanding its danger and, as far as is feasible, muzzling the damn thing.
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.
There's more? Yes there is. Much more. Frightening amounts more but I'm fresh out of aspirin.
By now, you really ought to understand the problem with the weakest link which, contrary to popular opinion, isn't just some crummy TV show on a weekday afternoon ... not that I ever watch it and besides it's always on too early.
You should be able to grasp the vulnerabilities of and the threats against your network, from the local box to the server and thus to WordPress itself, and to weigh up your risk.
In Chapter 2, we'll get our hands dirty as we assess our machines and sites for problems and consider ways to test them against exploitation before someone else does. In some cases, the results will be shocking and, in others, less concerning. In all cases, we should remember that even a small chance of being hacked, where that chance can be reduced, is a chance too great, particularly with the next zero day just around the corner.
Don't have nightmares. Just read on.
