From the development office: An insight into how a product as sophisticated as Conseal Server is security-ensured before we allow it out.

Any server product naturally needs very careful testing and analysis to ensure, amongst other things, that it is safe for users and secure for the computer it's installed to. With Conseal Server, we arguably have an even greater responsibility than most to ensure complete security, given the sensitivity of the data it protects.

Each release, therefore, goes through a very strenuous series of tests. Our current checklist calls for a vast 8,404 separate tests on each and every release - and this number grows with every release. The checks allows us to guarantee things like user permissions working as they should, devices being available only as permitted by user-supplied access rules and users being correctly "sandboxed" (meaning they cannot overstep their permissions).

We also test against security flaws which commonly affect other server software, such as protection against cross-site request forgery and HTML and SQL injection attacks. It is my job as a penetration tester to attack the server in as many different ways as I can. Again, we have a checklist of attacks we try on every release - by the fun of my work is finding ever-more creative ways of attacking!

As a final layer of security testing, we analyse all the differences in code between releases. This can also be helpful in formulating attacks against the server - knowing how it's written can suggest further attacks to try.

If you are looking to start pen-testing a server, whether your own code or a third party one you've just installed (or even if you want to confirm our work on Conseal Server!) then here is a very useful guide to some of the most common and dangerous flaws.

A very significant new flaw in all versions of Windows allows hackers complete control over your computer if you visit an infected website or open a document. The flaw is fixed in KB2783534 which is currently on Windows Update.

This has vast damage potential, and we're not sure why it isn't receiving more media attention. The flaw exists in the way that fonts are opened and displayed - so in any situation where hackers can get your computer to display a custom font, they can take control over your system. This includes just visiting a web page for example.

This is uniquely damaging because it's software-independent. It would apply regardless of the browser you are using, as presumably they all use Windows' own mechanisms for loading and displaying fonts.

We advise all customers to ensure they have the latest OS patches.

In numbers:

26%	companies which believe their staff have a very good understanding of their security policies
75%	of those organisations in which security policy was poorly understood, the percentage which had staff-related data breaches
67%	percentage of large organisations which expect more security breaches next year
37%	number of small businesses which do not have a formally documented security policy
568m	number of flash drives expected to be in use by 2015

In numbers:

£500,000	maximum fine for data breaches from the ICO
70%	number of businesses which have traced the loss of sensitive or confidential information to USB flash memory sticks in the past two years
81%	risk of data breaches to small businesses (compared to 75% of large organisations)
35%	breaches caused through loss of mobile devices (the top cause of breaches)
> 50%	small organisations which don't use encryption and have no systems in place to protect against data loss
Zero	of 50 analysed USB sticks lost on trains, the number which were encrypted

In numbers:

17,000	number of USB sticks found in the UK - by dry cleaners alone.
36%	proportion of data breaches caused by employee negligence (for example lost USB sticks) in 2012
68%	the rise in costs of data breaches to UK businesses over the last 5 years
£79	average cost per compromised record in a data breach last year
£1.75m	the average cost of a data breach to UK organisations last year
£780,000	cost of data breaches to UK firms last year - in lost revenue alone

Here is a rather beautiful Unix command which will lock up a computer:

:(){ :|:& };:

It's neat because it's short, deadly and pleasingly all-punctuation. It's what's known as a "fork bomb", a self-replicating program which does nothing except multiply. It locks up the computer because there is a limit to how many processes can be run at once. When the limit is breached, no more commands can be entered because each command necessarily starts a new process.

However since the colons in the example are just placeholders and can be replaced with any single word, the same thing could be written, with added spacing, as:

destroy()
{
     destroy | destroy &
}
destroy

ie: we first define a function called 'destroy' which simply runs two copies of itself. Then we run it once, setting off the chain reaction.

It causes a fairly significant security problem because it potentially allows a non-admin user to take down the entire system. The solution? Process limits - limiting the number of processes that users can create. A starter for ten is the file /etc/security/limits.conf.

Hello world! I am Conseal's new leader of penetration testing - meaning I am paid to deliberately break our products and web sites. This is even more fun than it sounds. Recently I have had the pleasure of trying to rip into the new version (currently in beta) of Conseal Server.

Having only recently joined Conseal, I was essentially trying to break into a product whose internal machinations I knew nothing about. This is much harder than hacking products that I'm familiar with or which I've had a hand in developing, because I don't know the mechanisms involved. For example, I don't know what happens internally when a client authenticates itself - knowledge of which I would otherwise use to develop specific attacks.

So when working from cold I can only guess. It's a case of thinking carefully about how a product may have been written, and what security mistakes a programmer may therefore have made. For example, are a users' permissions checked correctly for every action they may take - or can I get into somewhere I'm not supposed to, simply because there's no bouncer on the door?

One of the most common mistakes I find allows me to read any file on a server's hard disk including system settings or password hashes. Even more significantly, it even allows me to read (and potentially reverse-engineer) the server's executable code - meaning I no longer have to work "from cold". Jackpot!

Here's how to protect yourself from an evil-minded version of me reading anything I want off your server's hard disk.

The problem occurs whenever a server takes a user's input and uses it to read a file (perhaps a template for example) from the disk.

Take a web server for example, and say it's used to display information on products. Let's say there's a URL like this:

http://www.my-parrot-shop.com/products?name=norwegian-blue

So there is a script called 'products' which is used to display a product named 'norwegian-blue'. The same script could be used to display any other parrot by replacing 'norwegian-blue' in the above with the parrot's name.

A common way of writing the 'products' script is:

1. Read the contents of a file called 'norwegian-blue'
2. Paste this into a template web page and display it to the customer.

So in step 1, we are taking the user's input and using it to form the filename. Can you see the security flaw yet? Let's ask this question... What happens if I request the following:

.../products?name=/etc/passwd

That would cause the script to serve me the contents of /etc/passwd as part of a web page! (A file which, under Unix, typically contains users' password hashes).

In fact, I could use the name of any file. This is known as a directory traversal vulnerability.

Scary? You'd be surprised how often this kind of hack works. Whenever you see a web page which takes a parameter which just might be a filename, try this out.*

It's such a great hack because it's so obvious, and so easy for programmers to get wrong. The solution is, of course, equally simple. If the file name you're reading from is based on a user's input, make sure it only consists of letters, numbers and dashes!

...So, most importantly, is this a hack that would work against your own website?

PS: You'll be pleased (or maybe disappointed as I was) to know that Conseal Server wasn't subject to any directory traversal vulnerability. Ah well. Next!

* Okay, perhaps check you're allowed to first.