Friday 14 November 2008

Reason to Secure your Home WiFi

Just the other week I saw “Which? Computing” report which highlighted complaints against video games companies who were going around accusing innocent of people of being file-sharing pirates. In one case Atari accused a couple in Scotland of file sharing the game Race07. The couple were aged 54 and 66, and unsurprisingly had never played a computer game in their entire life, yet they received a threatening letter care of Atari’s lawyers, instructing them to pay a £500 fine or face court action.
In due course the fine and case was rightly dropped, however there were 70 other similar cases dropped, often involving senior citizens who have never heard of peer-to-peer file sharing.
But what caught my attention was the law firm’s response in making these accusations, according to Michael Coyle, an intellectual property solicitor with law firm Lawdit, “more and more people are being wrongly identified as file-sharers. Most commonly problems arise when a pirate steals someone else's network connection by "piggybacking" on their unsecured wireless network” While prosecutors argue that users are legally required to secure their network, Mr Coyle dismisses this. "There is no section of the Copyright Act which makes you secure your network although it is commonsense to do so" he said.
For some time now I have been warning home users about the consequences of not securing their home WiFi properly, or even purposely sharing WiFi Internet access with anyone in range. In this case it was a computer game being shared without the WiFi network owners knowledge, which resulted in a scary letter from a law firm. But what if their neighbours or a complete stranger was using the Internet connection to file sharing illegal pornography, it would probably result in a knock on the door by the police, subsequent removal of all computer equipment from the address and an arrest. Interestingly the lawyers were certainly thinking about blaming the wifi networks owner, I wonder if the network was intentionally by the owner shared whether they could be found liable, regardless of that I don't think it's the smartest move to purposely share your home WiFi network outside your home..
Opening wireless network access up or not ensuring the WiFi is properly secured, opens up many other concerns. For one it’s possible for someone to listen in (snoop) your Internet traffic, learn what websites you visit and in some cases steal personal information. Unless you encrypt your Email, the bad guys can intercept and read your Email, and even adjust the Email contains without your knowledge. And by attacking the wireless router from inside WiFi network, they can even redirect you invisibly to fake websites. For instance it's possible to snoop which bank website you use, adjust the DNS on the wifi router, so the next time you visit your bank website have your computer sends you to fake bank site which has the correct URL in the address bar, in doing this the bad guys could harvest your bank account website logon credentials without your knowledge.
All food for though, whether stealing your personal information, or your neighbours are committing file sharing piracy or worst, you should make sure your home WiFi is secured for just your own usage, and avoid all the inconvenience and hassle.

Tuesday 11 November 2008

Web Application Security with HP's Billy Hoffman

The increasing shift in Internet hacking attacks against the (web) application layer is leaving many end customers as victims. Recently I met up with the head of HP Security Labs and Web application Security researcher Billy Hoffman, and discussed why this attack vector is on the rise, and solutions to the problems.

In recent years there has been an explosion in the number of web applications on the Internet, the so called “Web 2.0”. Web applications are becoming more complex, whether they are social networking sites, e-commerce sites or banking sites, the new breed of web applications are increasingly handling high amounts of consumer financial data and personal details. Such information is of commercial value and targeted by cyber-criminals. Many web applications are simply not developed as secure as they ought to be, and as a result are vulnerable to web application hacking and attacks. The bad guys are taking advantage on this situation, with recent research showing 75% of cyber attacks are now carried out at the web application level. So the stakes are high for the end consumers of these web site applications, and the rewards are high for the cyber-criminal, who exploits poorly written web application code to steal data. In essence if the application doesn’t have proper security checks written in the code, the hacker can take advantage and make the web application do something it wasn’t designed to do, this can result in large amounts of consumer information being harvested by cyber criminals. One of the most common attacks is a SQL Injection, which can literally return the whole chunks of the database within the webpage, while another common attack is know as a Cross-Site Script (XSS), which allows the attack to inject malicious code into the webpage, which in turn could steal user login sessions and deliver malware to user desktops, amongst things.

Firewalls do not protect Web Applications
What’s even more worrying about web application attacks is such attacks are often not even being monitored and therefore are going unnoticed by the website administrators. A web application (layer 7) attack completely bypasses the security and monitoring provided by devices such as network Firewalls, Intrusion Detection and Protection Systems and website encryption (SSL/TLS - that golden padlock on the browser). Even network level penetration tests resulting in “not hackable” seals of approval offer no guarantee against a web app hack. So when you see that webpage stating it’s a “secure website”, using encryption (“https”) and displaying an up-to-date anti-hack testing seal of approval by a well known security company, it all has no consequence to the security of the web application, which could be full major security issues despite all those security measures which only operate at the network layer.

The network layer security really does lull some organisations into a real false sense of security. A specific web application layer penetration test can be used to test for web application vulnerabilities; however these are still rarely regularly carried out by medium to small sized organisations, and even some large organisations, mainly because it costs too much to get one done, or the organisation just isn’t aware of the problem.

The Reality of Web App Hacks
A recent UK example highlights the problem, a few months ago Manchester based online clothing outlet, Cotton Traders, disclosed their website users were victim of an web application attack, namely a SQL Injection attack in early 2008. They had firewalls, a “secure” encrypted website and a seal of approval, yet their customers had credit card details stolen through a web application attack. And just last week NetCraft found a cross-site script vulnerability on Yahoo -Netcraft

Why are these Web Application Attacks possible?
It’s quite simple, the developers writing the web application code, either do not know how to code a web application to be secure, such as using proper field validation, or the developers are skipping proper code techniques in a bid to have the application ready and released due to commercial pressures on time. Either way these are needless flaws and yet are too common place, with 8 out 10 web applications on the Internet having a high to medium web application vulnerability going unchecked.

How to combat Web Application Security?
Some vendors will state their or their client’s reputation on installing Web Application Firewall (WAF); however WAFs are still a relative new technology. I have to say I am sceptical about any vendor who says such a product is the silver bullet which will plug all possible web application layer vulnerabilities. The other big problem with a WAF, is throughput, as every packet has to be inspected at the top layer of protocol stack (layer 7), so data packets need to dissembled and analysed, which takes time and results in a performance hit. The answer to the performance hit is to have a large or many WAF devices inline, which can really rack up the cost. I am not dismissing using a WAF, but for me it needs to be a “belt and braces” security approach, which means ensuring the code is developed and tested for web application vulnerabilities prior to release, which for me is the first and key battleground to win ahead of the installing a WAF.

How to Secure the Development of Web Applications
To do this, developers need to be properly and regularly trained to code web applications securely. In addition other controls within the development process are needed to ensure corners are not cut, security coding is not being missed, or mistakes being made. It is surprisingly easy to miss validation on that one field, the more complex the application, the more likely security vulnerabilities tend to slip in. The answer to this problem is to use a web application vulnerability scanning tool as part of the development process, and for testing within live environments.

One of the leading commercial web application vulnerabilities scanning suite of tools is Hewlett-Packard Security Labs’ DevInspect, WebInspect & QAInspect, which was formally under the umbrella of SPI Dynamics, which were acquired by HP in 2007. For further details about these tools and what they can do click here
https://h10078.www1.hp.com/cda/hpms/


Billy Hoffman (HP Security Labs)
I managed to spend quality time with web application expert Billy Hoffman, Head of HP Security Labs. I use the phrase “quality time”, because Billy Hoffman is just one of those guys who I could talk techie security all day long, and I count myself lucky to have spent several hours chatting about web application security with Billy, as well as listening to several fascinating “hacking” stories, which I can’t publicly repeat!


Billy is just one of those inquisitive out of the box thinkers, which makes you thankful he is one of the good guys, alas a white hat. However Billy became well known as a bit of a grey hat hacker, known as Acidus. While he was studying at Georgia Tech he famously hacked the university swipe card system, finding a fault with the magnetic stripe data, and it’s fair to say his resulting exposure of the flaw wasn’t fully appreciated by the system owners. Billy went on to graduate from Georgia Tech and joined Atlanta start-up company SPI Dynamics, becoming their Lead Security Researcher. Billy and SPI Dynamics specialised in web application security and web app vulnerabilities scanning products. So Billy is a real web application subject matter expert and is a frequent speaker on the subject at many of the top security conference events around the world. In fact I think the term “Web Application Security Guru” is the more fitting description to use when describing Billy Hoffman.

In late 2007 Billy released his first and in my view a much needed book on Ajax Security, appropriately called “Ajax Security”. http://www.amazon.co.uk/Ajax-Security-Billy-Hoffman Today many Web Application are being re-written in Ajax, which gives an application that “real desktop application” feel within the web browser. However poorly written Ajax code produced by developers is introducing a new frontier of web application security vulnerabilities problems which the bad guys are taking advantage of.

Prajakta Jagdale (HP Security Labs) on Flash Security
Also in attendance at the met up was HP Security Labs Security Researcher Prajakta Jagdale, who highlighted issues with Flash application security. In recent times malware has targeted poorly secure Flash web applications, and there have been several cases of successful exploitation of premium website Flash applications by malware and hackers. A common example of such an exploitation is specific malware which automatically embeds advertisements within the application, which known by the term “Malvertisement”. The bottom line is secure Flash application development is really not too different to traditional secure web application development, developers need to code the application so it fit for the purpose of being public facing. We all agreed writing a secure web application isn’t rocket science; most of it is just common scene, such as adding proper validation checks on entry fields, by white listing acceptable characters instead of trying black list. However the “secure” development of Flash application still tends to be overlooked by many organisations, perhaps because Flash applications are more difficult to scan than traditional web applications and perhaps there are less people with the expertise to code review and test them, or perhaps Flash application aren’t on radar with security testers and professionals. Whatever the reason, Prajakta’s research and findings with Flash application security is very interesting, leads me to believe there are many Flash applications on the Internet today which are vulnerable to attack.

Summary
In summary, in the security industry today it is generally accepted the web application security problem is increasing, with the bad guys going after this layer more. It’s not hard to learn how to attack at web application layer either, anyone can do it, and interesting it is not particularly difficult to fix. Speaking with application security experts like Billy Hoffman and Prajakta Jagdale, really underlines the importance of web application security, and the role of the HP Security Labs Dev\Web\QAInspect web application vulnerability tools in tactically the problems. It is clear that the HP Security Labs suite of web app security tools are helping many responsible organisations develop and deliver public facing web applications much securely, which in end protects those organisations end consumers.

If you have any interest in testing your web application, check out the HP Security Labs website and download a 15 day free trial of their tools.
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201-200_4000_100__