3187207970_7dd7c42426_z

INFOSEC 101: Breaking Down Scary Terms and What They Mean

I am not a hacker. But I understand the information security world. It’s a scary place, unfortunately, to people who have no exposure to it. Yesterday, WordPress 3.0.4 was released as a critical release… and it was. Matt explained the reason for the release in this way:

Version 3.0.4 of WordPress…is a very important update to apply to your sites as soon as possible because it fixes a core security bug in our HTML sanitation library, called KSES. I would rate this release as “critical.”

Simple enough. He goes on to refer to the vulnerability as an XSS vulnerability which caused a bit of angst on Twitter about what that means and if non-technical users should be given more information due to the terminology.

So, as a public service, I give you some basic definitions and concepts of web security and what we mean. These concepts are rightly scary, but the names tend to be scarier to those who don’t understand them.

XSS

XSS means cross site scripting. Cross site scripting attacks are generally attacks that occur because something is injected into a URL or “event” on a site to make the site do something else. Do something else can mean “hijack” a site so all visitors are sent somewhere else, or special HTML is injected into a site (often in the form of hidden links that diminish Google search results for the site, etc). This was the nature of the vulnerability fixed in WordPress yesterday.

XSS attacks are almost always carried out because of JavaScript injection. WordPress does have security API that makes dangerous characters (that is, special characters that make JavaScript do things) and it is encouraged that all plugin and theme developers use these APIs. [Docs]

CSRF

CSRF means Cross Site Request Forgery. With CSRF attacks, browsers (and sometimes other things) are hijacked to “do” things to a website without a user knowing. It’s the proverbial trojan horse where there is an inherent trust from a site that the user/browser is doing something trusted and so attacks riding the coat tails of such trust are given the same trust that the user would also get.

A simple example (does not actually exist) would be that an authenticated user in WordPress with admin privileges is tricked into clicking a link (as the authenticated user) and then admin privileges are transferred to the attacker. We’ve seen this kind of attack on Facebook and Twitter before where DMs or messages are spread across Facebook walls or via Twitter DM).

SQL Injection

SQL Injection is an attack that, without going into the technical details, allows an attacker to send special queries to the database that can alter, modify or even delete a database altogether. You don’t see many of these anymore because most apps are built on frameworks or platforms (like WordPress or Drupal) that have built in routines and APIs that prevent this. In WordPress, there is a prepare() function in the database class which ensures that no SQL injection is possible.

0Day Vulnerabilities

0Day (that is Zero, not “Oh”) is a vulnerability that is exploited before it has been disclosed. Many security researchers work closely with web application developers to alert them to newly discovered vulnerabilities before they are publicly disclosed. They then work with the developers to close the hole before disclosing the vulnerability. The term 0Day comes from the idea that the web app developer knows about the exploit on the 0th day after public disclosure (it hasn’t been disclosed yet).

Denial of Service/(D)DoS

(D)DoS is a (Distributed) Denial of Service attack. These attacks are carried out by flooding a site with traffic/requests to the point where the site can no longer handle the traffic and collapses. If the attack comes from a single source, it’s a DoS but if it comes from more than one, it is a DDoS.

Obviously, there are many aspects of security. We could go way complicated on terminology and concepts, but these are some of the basics you should know when you see something about a vulnerability.

Photo Credit: heathbrandon

grey-xl

WordPress Security and How I’m Going to Take All Your Money

So, it’s happened again. Another vulnerability discovered in WordPress that is now becoming the raging topic around the blogosphere. Is WordPress insecure? Should people move to another platform? If we stomp our feet loud and enough and whine enough, then we can make WordPress look like a ridiculous piece of software that only amateurs should use.

I call bullshit. Here’s why.

The current security paranoia is around an exploit that has already been fixed! That’s right, it was known and fixed two releases ago. The problem is, the people complaining about WordPress’ security are running old software. They didn’t bother to do the responsible thing and keep their blog up to date!

See, WordPress has two different types of releases. Major releases (2.5, 2.6, 2.7, 2.8, etc) provide new features. These releases keep the software innovative, bringing new functionality to bloggers every 4-6 months. Security releases (2.8.1, 2.8.2, 2.8.3, 2.8.4, etc) are arguably more important than major releases because they keep you safe!

Bloggers who ignore these security releases do so at their own risk.

And because of that, when you are hacked, I will charge you an assload of money to fix you up! Believe it.

There is nothing more I want to do on a holiday weekend that also happens to be my birthday weekend, than to fix peoples blogs who didn’t bother to take care of themselves. It’s personal responsibility. Oh, I’ll do it. You won’t like the bill, though.

If you’re using WordPress 2.7+, as said loudmouth blogger was, it’s so simple to keep things up to date with the auto-upgrade button. WordPress even informs you when your version is out of date and provides a direct link to the upgrade page. If you ignore that, it’s not my fault… it’s yours.

For clients hosted on my servers, you are up to date. Why? Because I make sure of it. For the rest of you, do your part, so I don’t have to. Because my part will be making your blog secure, but it will also be sending you a sizable invoice.

Cheers, and happy Labor Day!

Security Problems and Government 2.0

The other day, I made a very serious point about the fad that is “Government 2.0″. I was pleased by the amount of attention it received and the large number of very reputable and poignant comments it recieved. However, it was largely a philosophical post, and did not provide anything concrete.

Today, that concrete example fell in my lap as I read this post by IT Security company, Websense. The post outlines how malicious users added an image to a “user generated” section of My.Barack.Obama. The image led to a trojan download site that is infecting user computers.

Granted, the MBO site is not a government site, but it is certainly related, wouldn’t you say?

Veteran federal IT Administrators are vicious about protecting internal systems and intranets. Trust me, I know. I come from a Lockheed Martin, CSC and Northrop Grumman background where projects I worked on were all government-facing or oriented. This is what we did.

For as much complaint as there is about the lack of transparency, the lack of public facing services that engage the public in a Web 2.0 way, I’d point out that there is a valid reason for it. I would love to see the Government opened up to more Web-savvy ways, but there are very tangible reasons why they are not!

This is also why Government 2.0 will not rule the day. At least not soon. Until there is a sensible way to prevent user-generated content from being user-generated security nightmares, such as this incident was, Government 1.0 will rule the day.

Security will always trump anything else and right now, there is too much opportunity for mischief to entrust the federal systems to user-generated anything.