Microsoft vs Apple

It's not really related to security but I found this article on the Guardian website fairly amusing. Of course the debate about whether Microsoft or Apple's products are the best is one that has gone on for many years. There is also the variant between Linux and Microsoft where all sides attack each other with the zeal of religious fanatics. The article takes a somewhat different approach, perhaps more in tune with how none techies view the debate. The best quote is:

'I know Windows is awful. Everyone knows Windows is awful. Windows is like the faint smell of piss in a subway:'

Well worth a read.

IDS and HTTP decoding

I’ve recently been doing some work on intrusion detection systems (IDS). As anyone who has ever discussed the subject with me will know, I am somewhat sceptical about the value they add to protecting an application, particularly when HTTP is involved. Part of the reason for the sceptism is the complexity of many of the tasks an IDS needs to carry out. Take for example decoding a URL. It’s claimed in a paper by Daniel Roelker at IDSResearch.org that there are over 8 different types of encoding possible for HTTP despite only two being defined in the relevant RFCs. An IDS needs to be able to understand each of these methods before it can hope to identify a malicious request. The task is complicated further by different products supporting different methods, with IIS perhaps being the worst offender. Whether such deviance from the standards is due to irresponsible software manufacturers or due to limitations or ambiguities in the standards, it is hard to tell. Note IIS7 now seems to disable many of the encoding techniques although they can easily be reactivated. IDS Research also has some useful tools for testing which encoding methods are supported by your web server and to allow you to see if your IDS can pick up the various types of encoding. It’s well worth testing your systems. You might be surprised what shows up.

Web Application Vulnerabilities – Spreading the Word

Many of the companies I have worked with in the past have been fairly progressive when it comes to security assessment. A part of this has been to commission penetration tests by a third party to determine network, OS and application vulnerabilities. Surprisingly, the most difficult part of the process was persuading colleagues to act on issues discovered in a test. This was particularly true for web application vulnerabilities as getting a stressed development manager to redirect valuable resource into fixing security holes was never easy. The main reason for this was often that the security team would find it difficult to articulate the threat level of each problem and hence not communicate the true danger level.

A testing company I’ve engaged in the past, Pentest Ltd, recently brought to my attention a site called The Web Application Firewall Information Centre, whose raison-d’être is to maintain a list of web application security incidents. The site lists all publicly reported incidents by type, time frame and outcome. Although I suspect it only includes a fraction of total incidents, not least because many are never reported, it is an excellent source of information to demonstrate how particular vulnerability types have been exploited in the real world. If nothing else it should help the security professional to explain why a vulnerability has a particular threat level and why it needs to be fixed.

Brute Force Password Cracking

The BackTrack Live CD I recently used in conjunction with a WEP proof of concept attack also comes with several SSH brute force password cracking tools. This reminded me of a previous brute force attack against my systems. One dark night in a data centre myself and a colleague were upgrading the hardware in a firewall cluster. We connected up the systems to the internet, powered on, and opened a terminal session. Within 5 minutes the terminal was flooded by failed logon attempts which was most surprising as SSH had not previously been enabled at the IP address in question. Fortunately for us, we had already configured the hardware offline and had changed the default password.

A review of the firewall logs indicated that our entire IP range had been scanned for open SSH ports and that once found, a brute force attack was launched. Further investigation suggested that the attack wasn’t specifically targeted at our firewall but was rather a speculative attempt to penetrate systems across a large IP address range. No doubt a successful authentication would have resulted in further exploitation.

There are several ways to protect against a brute force attack. The most obvious is to have some kind of account lockout, i.e. refuse logon attempts after a certain number of concurrent failures. However, this can lead to a denial of service attack where a hacker will deliberately lock out the account to prevent a legitimate user logging on. A slightly more sophisticated method is to use tarpitting where each failed logon increases the amount of time before a user can attempt a subsequent logon.

As ever, strong passwords are a must for protecting against brute force attacks. Last Bit have an interesting calculator to allow you to estimate the maximum time it would take to crack your password.

Perhaps the most simple but effective method of protection is to rename default accounts especially administrator and root. A speculative brute force attack will almost certainly use a generic account and so can be beaten whatever the strength of the password.

Cracking WEP

We all know that using WEP to protect wireless network communication is considered unsecure and many people also know that this is because of the way the depreciated RC4 stream cipher is used in its implementation. In real terms, the implementation weakness allows anyone who can capture enough WEP encrypted packets from a particular wireless access point to use statistical analysis to crack the encryption key. This is much quicker and easier that using a brute force dictionary attack.

If you are not a mathematician with some handy wireless packet capture equipment, cracking WEP still seems quite tricky. However a quick search of the internet shows that are plenty of tools out there to do the job for you. Most links point in the direction of aircrack-ng, a suite of tools that allow you to discover weak access points, capture wireless packets, inject extra packets to generate more traffic and finally to extract the encryption key. There are even plenty of You Tube videos to tell you how to use it but I found the documentation on the aircrack-ng site easier to follow.

The most difficult part of the process is getting you wireless network card to work with the software as not all chipsets are supported. Refer to the hardware compatibility list. Aircrack-ng works better with Linux but if you only have Windows you can use a Live CD such as BackTrack.

My own experimentation showed that once you have your attack system up and running, it typically took less that 10 minutes to break into a WEP protected wireless network. Although it is possible to complicate the process by hiding the SSID and restricting MAC addresses, these measures only delay the WEP network’s compromise.

To conclude, WEP shouldn’t be used to secure a wireless network. Given that I can pick up four WEP networks just from my house, (I do live near a business centre), it’s possible it is still in widespread use. Even those networks that are WPA protected are not necessarily safe. The aircrack-ng software also included a brute force attack method that worked against the 4 way handshake part of the initial WPA negotiation although it’s only really successful if common dictionary words are used for the key. There are also reports of new techniques similar to the WEP attack that can be used against WPA TKIP, so it is surely only a matter of time before tools are available for crack this as well. So my advice is to use WPA2 (AES), strong keys and upgrade as new technology comes available.

What the Hell is Cloud Computing?

The following link from PrudentCloud leads to a collection of You Tube videos on the definition of Cloud Computing as seen by various industry leaders. I particularly like the one from Larry Ellison of Oracle fame. If you watch all the videos, you will see that Cloud Computing means different things to different people.

My own take on Cloud Computing is based on my experience of working in the ‘Cloud’ space for over ten years. Back in 2000, I was Operations Director for an Application Service Provider (ASP) who towards the middle of the decade, rebranded their product range as Software as a Service (SaaS). Although, the same company is not yet publicly marketing themselves as cloud provider, their competitors are so I am sure it will only be a matter of time. Not surprisingly, the part of their solution that could be called ‘Cloud’, i.e. the delivery method to the client, is exactly the same as it was when the company was an ASP or SaaS provider.

The same seems to be true for ISP/hosting providers. In 1998 I as able to rent web space that would run perl scripts and interface onto a MySQL database (I think it was MySQL), also hosted by the ISP. The pricing model was based on resource utilisation; disk space and bandwidth. Such a service certainly seems to fit into the Cloud Computing definition. The offerings on today’s market are somewhat more advanced but the underlying architecture and pricing model is more or less the same.

Hence, from my perspective, Cloud Computing is more marketing than innovation but as it opens up a whole range of possible Cloud Computing security consultancy opportunities, I probably shouldn’t complain too much.

Home Security

After leaving the comfort zone of my job as Operations Director at a well known SaaS provider to set up as an independent IT Security Consultant, I though it might be wise to first test my skills on my own home and now also office network.

My home/office network is not dissimilar to many other peoples; there are 4 PCs running either Windows XP or Vista and an ADSL internet broadband connection. I also have a test server for work purposes running VMware with 2 virtual machines: Ubuntu Linux and Windows server 2008.

My starting point was to run a vulnerability scanner on my internal subnet. For this I chose Nessus which has an excellent reputation and is free for home use. My objectives were to gain a level of confidence as to the security of my home systems as seen from the privileged position of the local subnet and also to assess just how accurate Nessus is at vulnerability assessment.

I configured Nessus to scan the entire subnet rather than individual systems and also ran all security tests. After about 10 minutes the scan completed finding mostly what I expected but also a few interesting extras.

Firstly, Nessus managed to pick up my 4 PCs and correctly identify the operating systems and in three cases the hostname. The PCs running Skype were successfully detected as were the systems with ITunes. Two PCs were shown to have file-sharing enabled

Nessus also identified my VMware server which had a large number of ports open although none were flagged as a potential risk. The Linux server was identified with just SSH and Nessus (not surprisingly) running but gave me a whole list of recommendations as to how to better configure my server to stop information leakage and recommended an upgrade of acpid.

The Windows 2008 server was incorrectly identified as Windows Vista but this is not a million miles from the truth. The correct open ports for the server were detected; HTTP (80), FTP (21) and RDP (3389). Nessus pointed out that anonymous logins were available for ftp and that I could improve the security levels of RDP and FTP. The correct version of IIS7 was also identified.

Nessus also detected my iPhone, connected via wifi, the web server on my ADSL router, the streaming channel for TV and the FTP server on my TV decoder.

First conclusion from this test is that Nessus is excellent at system and service discovery. The second is that although overall security seems adequate, there are far more attack vectors on my network than first thought. It seems fanciful that my TV decoder might be a future target for hackers but a year ago, one might have said the same about mobile phones and ADSL routers, both of which have had know attacks in the past month.