Here’s an interesting read if you work in or with a team that’s responsible for building public facing systems. It’s a collection of the top 25 programming errors that have been responsible for most of the major security breeches and system outages over the last few years. Some of them are pretty well known, some a bit more exotic, but it’s always a good idea to make sure you’re aware of the risks you’re facing and familiarise yourself with them.

Here are the top 3, which I’m sure most people are familiar with:

• Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
• Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)
• Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

Get the whole list here: Top 25 Most Dangerous Programming Errors

What I like about the list is that there’s a plain English description after each vulnerability (further down in the document), which you can use when explaining to non-programmers what the risk is all about. So next time your website gets hacked, you can use this to explain to your CEO exactly how it happened.

On a side note: My mate Noah maintains that the single Most Dangerous Programming Error was demonstrated to us by James Cameron in the Terminator series: Giving complete control to machines results in disastrous consequences which includes them ruling the world and going back in time to kill your mother. I have a plan for that though; if we take down the satellites they won’t have access to internet satellite services and therefore will get lost as soon as they’re out of Bluetooth range of each other. Reckon that will work?

If you’re into development in any shape or form, you’ll see a number of security issues Three has with their website, including but not limited to:

1. Password stored in plain text in a connection string
2. Trivial password that could be cracked without thinking too hard
3. And of course: not trapping errors so the whole world gets to see them.

I’ve omitted the name of the website, to protect the guilty, but there wasn’t much point, based on what the error was returning. There’s a lot that a potential hacker could learn from that lapse, and it essentially highlights the need of having a security professional involved in your development and release processes. These are basic errors that can be prevented, so why risk you site .. and your reputation!

The week has been organised to raise awareness around these issues and the website includes a number of real life stories and tips that everyone can follow to minimise their exposure to this risk. Unfortunately everyone can be targeted by nefarious criminals, it doesn’t have to be your postman. It could be a Russian hacker pretending to be an Irvine web design firm; or a buyer on eBay who bought your old computer which had all your passwords stored on it; or a complete stranger who picked our your bank statement from your recycling pile; pretty scary huh?

The end result is that we need to be more aware of our actions and our information. Always be aware of what data you’re “leaking”. Being vigilant and aware is the key.

Have you ever had a password-protected Excel document that needed opening up? It happened to me a couple of years ago. I worked for a company that used an Excel sheet in a shared folder to store passwords to different websites that the company had accounts on. One of the policies the company had was that the password to this spreadsheet would change on a routine basis, just following protocol; but the person who changed it must have typed in the wrong password. The spreadsheet was locked, but the new password just didn’t work. They tried various misspellings but still couldn’t unlock it.

Anyway, to cut a long story short, they had to bin the spreadsheet and start all over again; but today I found a product they could have used to retreive the password. It’s an Excel Password Recovery tool that has two options. It can either unlock the document and just remove the password from it. Or else, it can run a brute-force attack on the file and figure out what the password actually is. Depending on which method you use, there are different parts of the program to use, but the end effect is that you can finally get back into your document.

Pity we didn’t have access to this program back then; it could have saves lots of time and effort if that had been the case.

1. Update your applications and scripts: Most hacks out there make use of a vulnerability that has been discovered in software you’re running on your web server. Suppliers and development communities are quick to release patches that solve these vulnerabilities, but if you don’t update your software, you’re going to remain exposed.
2. Create strong passwords: Another common route to gaining access to your site is guessing one of your passwords. Make sure you always use a strong password, and for heaven’s sake, don’t use the default password that ships with any product you’re installing.
3. Mask your folders: Most webservers are configured in such a way that if they don’t find a “default document” in a folder, they’ll just show the list of files in that folder. Make sure each folder on your server has an “index.html” file or whatever default document your server uses, to help you mask the contents.

I got the tips from Web Hosting Geeks blog, a website that reviews hosting companies and helps you find the best web hosting in the category you’re looking. Now, I’m not saying that if you follow the steps above you’ll never get hacked, but you’re significantly reducing the odds by making sure the more common entry points are secured.

I came across a great whitepaper by a company called Pragma Systems that talks about their Fortress product line, designed to secure a wide variety of different platforms using protocols like SSH, SFTP, SCP and others. They have a variety of different offerings ranging from server security suites to a secure shell client and have a long list of clients including IBM, Coca-Cola, Dell and many others spread all around the world.

Read the whitepaper here

Clickjacking allows someone to place an invisible link/button below your mouse as you browse a regular page. You think you’re clicking on a regular link, but really you are clicking someplace the attacker controls that’s hidden from you. Why is this important? Because it allows the attacker to force you to interact with something without your knowledge on a page other than the one you’ve been looking at. For example, they can hide a Flash application that follows your mouse around, and when you go to click a link it starts recording audio off your microphone. We have protections in browsers to prevent someone from automatically initiating certain actions. Also, many websites rely on you manually pressing buttons for actions like transferring large sums of money out of your bank account.

There are two sides to look at this exploitation- user and website owner. As a user, if you visit a malicious site (either a bad guy site, or a regular site that’s been hit with cross site scripting), the attacker can force you to take a very large range of actions. Anytime you click something, the attacker can redirect that click to the destination of their choice in the context of you as a user. That’s the important part here- it’s like cross site request forgery (really, an enhancement of it) that not only gets you to click, but to execute actions as yourself. That’s why they can get you to approve Flash applications you might not normally allow, or to perform actions on other sites in the background. As with CSRF, if you are logged in someplace the attacker can now do whatever the heck they want as long as they know the XY coordinates of what they want you to click.

As a website owner, clickjacking destroys yet more browser trust. When designing web applications (which used to be my job) we often rely on site elements that require manual mouse clicks to submit forms and such. As Robert (Rsnake) explains in his post, with clickjacking an attacker can circumvent nonces (a random code added to every form so the website knows you clicked submit from that page, and didn’t just try to submit the form without visiting the page, a common attack technique).

Clickjacking can be used to do a lot of different things- launching Flash or CSRF are only the tip of the iceberg.

It relies heavily on iFrames, which are so pervasive we can’t just rip them out. Sure, I turn them off in my browser, but the economics prevent us from doing that on a wide scale (especially since all the advertisers- e.g. Google/Yahoo/MS, will likely fight it).

Clickjacking is very difficult to eliminate, although we can reduce its risk under certain circumstances. Because it doesn’t even rely on Javascript and works with CSS/DHTML, it will take a lot of time, effort, and thought to eliminate.

If that sounded scary, have a look at a video showing one application of the exploit:

If you want to study that further, you can actually run it through it’s paces here.

So, what can be done about this? First of all, it’s worth realising that while it’s a powerful threat, the risk of it happening isn’t that high at the moment. Vendors have started recognising the threat and coming up with solutions for dealing with it. Adobe has come up with a workaround and NoScript has released ClearClick to help address it. It’s only a matter of time before this is quashed too (won’t be easy though)

Seems like there’s a new type of browser exploit that can cause problems to users out there. It’s called Clickjacking and here’s how it’s described:

In a nutshell, it’s when you visit a malicious website and the attacker is able to take control of the links that your browser visits. The problem affects all of the different browsers except something like lynx. The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you. It’s a fundamental flaw with the way your browser works and cannot be fixed with a simple patch. With this exploit, once you’re on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.

There’s a little more information about this on the Web Admin blog but details are still a bit sketchy. The biggest problem is that it seems to effect everyone using a browser, regardless if they’re using Firefox, IE or Chrome and whether they’re connected by dial-up, ADSL or satellite internet provider.

Hope this doesn’t cause too much consternation, because it seems like it’s not going to be trivial to fix this security hole.

So, I decided to have a play with Joomla a couple of weeks ago as one of the first websites I ever built Cruelcard needed to be moved away from my Windows host and had to be rebuilt in something other than ASP. I’ve been wanting an excuse to play with Joomla and well, here it was. I built the site, put up the plugins I wanted, themed it and lo and behold had a brand spanking new website. Everything was good .. the sun was shining etc .. until last night ..

Last night I logged in to find that the site had been defaced. I should have taken a screenshot to show you, but I just overwrite the message with a “Will be back soon” message. I left everything as it was so that I could find out exactly how the hackers broke into my site. Today I had some time, so I went through my logs and this is what I learnt:

• The hacker was from Turkey. Well, I knew that as the defacement was in Turkish but his IP address (85.110.114.98) confirmed that.
• He was specifically looking for Joomla sites to target. The first referrer I have is: http://go.mail.ru/search?&q=Powered+by+Joomla%21.+Valid+XHTML+and+CSS&no_morph=n&sf=480. You can see exactly what he was looking for, but seeing I’m on page 49, he must have gone through quite a few other sites first.
• He gained access to the site by resetting the admin password. I actually found the exploit in Milworm (possibly this one anyway). This coupled by the fact that the sequence of commands were all placed in under a minute suggests that this was a scripted attack.
• Once the admin password was changed, the hacker went straight to the admin site and did whatever he needed to do.
• The hacker also seems to have uploaded some media using the Media Manager which suggests I need a proper rebuild of the whole thing.

It was pretty interesting to follow the hacker‘s footsteps. I will need to rebuild with a newer version of the software that blocks that hole, but I am partly responsible because I didn’t change the default administrator’s name. If I had done that, I might have had a bit of protection. I’m not going to abandon Joomla just because of this but it has certainly highlighted the importance of backups to me!

If anyone’s interested, you can read through the log: cruelcardcom-hack

Note to self: Read more about Milw0rm and don’t watch so much CSI

OpenVPN is a full-featured open source SSL VPN solution that accommodates a wide range of configurations, including remote access, site-to-site VPNs, Wi-Fi security, and enterprise-scale remote access solutions with load balancing, failover, and fine-grained access-controls. Starting with the fundamental premise that complexity is the enemy of security, OpenVPN offers a cost-effective, lightweight alternative to other VPN technologies that is well-targeted for the SME and enterprise markets.

And here’s a great-writeup that offers a step-by-step rundown of how to install and configure it on a home network.