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.

Last week, the PCI Standards Council has issued a press release and a supplement document clarifying some of the ambiguous points in the PCI standard, including section 6.6.

SecureSphere addresses 8 or 10 of the 12 PCI requirements (depends on interpretation and not all of the sections have a lengthy clarification), including web application security as well as the database security and cardholder data protection requirements. However, section 6.6 is one of the common use cases. Requirement 6.6, which becomes effective on June 30, 2008, provides two options which are intended to address common threats to cardholder data and ensure that input to web applications from un-trusted environments is fully inspected. The Information Supplement for requirement 6.6 gives organizations clarification on implementing application code reviews (option one) and/or application firewalls (option two).

The first option for application code review for meeting Requirement 6.6 is now subdivided
into four alternatives designed to meet the intent of the requirement. They include:

• Manual review of application source code
• Proper use of automated source code analyzer (scanning) tools
• Manual web application security vulnerability assessments
• Proper use of automated web application security vulnerability assessment (scanning) tools.

The second option for Requirement 6.6 is a Web Application Firewall (WAF - which is now finally described including a list of recommended capabilities for WAF, additional
recommended capabilities for certain environments, additional considerations for organizations implementing a WAF and additional sources of information on Web application security).

Since PCI version 1.1 was introduced in 2006 we worked with hundred of organizations to meet the PCI requirement, ensuring that web application are protected and secured. During this time, we have learned that once a vulnerability is discovered in a production system, it may take weeks and even months until most organizations can patch, test and deploy the fix.

According to the PCI Standards Council, "The intent of Requirement 6.6 is to ensure web applications exposed to the public Internet are protected against the most common types of malicious input."

It adds that "Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities...Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats"

While scanners of any kind would be very useful during the development cycles or as part of the QA process, they will not be able to protect web applications once a new vulnerability is identified. In fact, it creates a new type of problem to the organization, as the managers running the scanners might be aware and accountable for newly discovered vulnerabilities that can not be  fixed in due time.

Both technologies (actually all three) should be in use by organizations following best practices, but for those trying to get the most bang for the buck in the short term, the place to start is with a Web Application Firewall.  WAFs are a faster and more cost-effective approach to meeting the PCI requirements without facing the accountability of knowing about a vulnerability, not to mention SecureSphere's other benefits as it addresses more than just section 6.6 alone.

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.

So the party RSA is over. Even though most bloggers and reporters

In my opinion, the report of hackers assault epilepsy patients might be the first recorded occurrence of physical, human damage due to large scale hacking. We heard about medical facilities attacks and records destruction in the past. But according to wired,the incident, possibly the first computer attack to inflict physical harm on the victims, began Saturday, March 22, when attackers used a script to post hundreds of messages embedded with flashing animated gifs.
Wow. I wonder what's next, programing HAL 9000?