Amichai Shulman: April 2008 Archives

There's been a lot of security talk recently regarding the latest massive attack where hundreds of thousands of URLs have been hacked. Add to this that many of the infected sites belong to some big-name organizations such as the UN, the Department of Homeland Security, and UK Civil Service to mention just a few and you've got the whole world talking about this!

This attack exploits an SQL injection vulnerability in order to inject HTML code into pages that create an IFRAME which downloads a malicious payload into the victim's browser. The Hacker Webzine gave quite a thorough analysis on this type of attack [traceback] - to summarize, the attacker uses a hexadecimal notation to represent character strings which contain the commands to be executed in the DB server. Unfortunately, traditional signatures against SQL Injection will not catch an attack vector using this evasion technique as mentioned is a past whitepaper of mine. This current massive SQL Injection attack has reminded me of the other immense SQL Injection attack which took place at the beginning of March. In that attack, hackers injected IFRAME tags to Websites' search result which eventually get indexed by Google. That attack in turn reminded me of another similar widespread attack which occurred in January which redirected users of those vulnerable sites to a different domain. In all these cases huge amounts of websites have been infected by script injection, using a single non-customized attack code. There must have been some kind of automation for so many sites to have been compromised within such a short time period. My guess is that the attacker used a botnet and Google searches to launch the attack, two techniques that combined together result in a tremendously fast and efficient distribution of malware. Search engines used as a platform for malware distribution is not a new concept, "The Search of Death" as described by the Imperva ADC warned of a mega-worm crawling its way to vulnerable websites using search engines, and we've seen the proliferation of the famous SantyWorm which defaces websites by exploiting certain php vulnerability - finding those vulnerable machines just by searching Google.

It would be interesting to see the details of these attacks unravel. Unfortunately, I do not believe that these massive attacks will fade out in the short run. On the contrary, I believe that the usage of SQL Injection as a method of site defacement and malware distribution will continue to be one of the most-spoken about security challenges we face this year.

This week has raised once again the question regarding the effectiveness of patching as a security countermeasure. The past Tuesday is known to Microsoft users as Patch Tuesday, where Microsoft released eight fixes as part of its monthly security update, five of these fixes rated as critical. And tomorrow, Oracle is releasing its quarterly Critical Patch Update. The pre-release announcement states that the patch contains 41 security fixes, 17 of which are aimed at the Oracle Database itself, two of them are remotely exploitable without the need for any database credentials. Both vendors urge their customers to deploy patches immediately in order to keep their systems secure, but we all know that this is an unrealistic demand.

The operational burden involved in patching production system across an enterprise is such that it effectively limits patching frequencey to once or twice a year. Even if we are the optimistic type of DBAs, we still have to assume a time frame of weeks until a patch is deployed. This is a huge window of opportunity for hackers to launch their attack campaigns. We have seen actual attack campaigns popping up as early as a day after a patch has been released.

Leaving aside the time required for patch deployment, the fact that a security patch was released means that the vulnerability was already known to the vendor for several months, even up to 24 months... The vulnerability itself might have been present in the product for years (I have personally reported a vulnerability to a vendor, which has been present in all versions of the product for 10 years). Take for example the latest "Pwn to Own" contest by TippingPoint. The Vista Laptop was cracked, as Shane Macaulay exploited a Flash vulnerability. A few days later, Adobe announced that it knew of this bug, apparently it had been reported 5 months earlier, and yet the appropriate fix has been shipped out only last week. It is naïve to assume that the "bad" guys get to know about the vulnerabilities only when the patches are released. After all, malware markets are thriving and clandestine organizations pay top money to "security experts" to go ahead and find these security gaps (See talk by "Geekonomics" author David Rice who lectured on this underground world at last week's IT 360 conference in Toronto).

I haven't even mentioned yet the Botnet industry as a global industry as presented at the panel discussion on Wednesday's RSA 2008 Conference, didn't even start to talk about the operational hazards involved in patching production applications (see Microsoft's IIS patch problems last year and the list of software that would fail to correctly function when SP1 is applied to Windows Vista).

So, in fact we see once again that there is a huge window of opportunity for hackers to exploit known vulnerabilities where organizations rely on patching as their first line of defence. This of course calls for a different type of security solution provided by 3rd parties to provide timely detection of published vulnerabilities, as well as protection against 0-day attacks, without impacting the stability of the protected server / application. This type of solution in the form of an independent security gateway (sometimes referred to as "Virtual Patching") is probably a must have in today's turbulent information security reality.

On a completely different note, I'd like to mention an incident which happened last week where 370,000 HSBC customer details were lost. Originally, these records were supposed to be sent electronically through an encrypted channel under a well-established security policy. However, communication was down on a certain day and the records were sent via a courier service, but never really arrived as the disc got lost. Sort of reminds me of last year's incident where JFCU meant to transfer a file on an encrypted disk sent by courier, according to their set security policies, and because of some transmission error, the file was posted to the printer's Web site in an unencrypted format, the site later being indexed by Google for anyone to see. Seems that Murphy's Law which instates that if something may go wrong, it will go wrong definitely applies in the security realm - each time a security policy is bypassed, expect a security breach to happen.