October 2008 Archives

Earlier this week, I presented at the RSA Europe Conference in London. The presentation topic was Internet search engines (in particular Google) and Web application security. I presented a set of threat vectors in which attackers do not interact directly with either the target application or the victim, but rather operate through search engines. Some of the techniques (i.e. Google Hacking) have traditionally been used for the reconnaissance stage of the attack. I discussed alternative uses such as sensitive data extraction, worm proliferation, malware distribution and more.

My main concerns with respect to these threats are:

-Lack of awareness (and hence the lack of proper mitigation tools).

-Search engine operators, while trying to mitigate some of the issues, do not distinguish between application owners and potential attackers. For example, there is a limit to the search rate based on source IP address. While true attackers are hardly affected by this, site owners are denied the possibility of automated, proactive mitigation.

Together with SQL Injection rennaisance, I think that search engine related threads are a growing trend in web application threats.

 - Amichai 

Conferences are one of the best places to not only meet new people, but also receive quick feedback from customers, prospects and industry peers. Last week, I was visiting the Windy City for the Mid-Atlantic IANS forum (IANS is a research company that focuses on the fields of information security, regulatory compliance and IT Risk Management). It was a great opportunity to listen to - and exchange thoughts with - industry figures like Peter Kuper, Ron Ritcjey, Nick Selby and Marcus Ranum.

Another benefit of travel is the chance visit customers and participate in some business development meetings (often over lunch).  Needless to say, these types of interactions are not typically the subject of this (or any other) blog. However, last week has proven to be a bit of an exception, as one of my meetings found its way into the comments section of a recent blog entry from Rich Mogull on WAF vs. Code Review.  These words, from Rafal Los, originated in a discussion I had with him in Chicago last week.

"First off, I can vouch for what Sharon is saying (I met him and his team for lunch the other day and they are making a genuine effort to bridge the gap, I applaud that)."

So now everyone knows what I'm doing in my meetings: Lunching...and generating quality blog content ;).

The Wall Street Journal reports that some security software companies are turning to gimmicks to try to raise awareness around the problem of data breaches. The article states:

"Breaches are up despite the fact that the percentage of businesses that encrypt laptop computers, databases, and back-up tapes--all places where sensitive data are kept--increased about 10 percentage points over the last year, according to a survey of corporate security executives by PricewaterhouseCoopers"

It goes on to add:

"The survey numbers underscore how technology can get a business only so far. Real security is a result of people understanding the nature of the threat and acting responsibly. Unfortunately, most people seem to be tuning out security news."

In my opinion, the major issue is not the lack of awareness, but the fact that the majority of existing market solutions can not prevent data breaches and are not able to protect against web application attacks or data theft from a database. There is a reason that the PCI council mandates firewalls and Anti Viruses and Web Application Firewalls and Data access control and activity monitoring and strong encryption....

Rafal recently gave his perspective on PCI and, among other things, he wrote that the requirement to perform a scan after every update to the site does not always makes sense:

"... after any changes" - so if I change the background, or add new legal verbiage I have to re-submit my site to inspection?  That makes no sense from a business perspective... does it?

In my opinion, this requirement actually makes a lot of sense.  While there may be changes that are minimal and do not affect the security of the site (e.g. changing the background color ), we all learned (the hard way) that developers have this habit of changing code even when they were told not to do so. Furthermore, some change control procedures might commit more than one code fix. In other words, while developer A might have changed just the background, developer B might have changed something that will be merged into the code in a way that would change the application. There have multiple cases where a 'simple' change has led to undesired and unexpected results.

In this case, I feel that the PCI council did the right thing by enforcing a strict change control policy and using the words "any change" to resolve conflicts over when and what to scan.  This policy makes the one auditor and programmer meeting essentially frictionless.

As a bonus, we will not have to argue about when to scan, though it looks like we can now start to debate about whether this language be used for PCI 1.2++. (YES).

Breaking from the traditional patch schedule, Microsoft released an emergency patch today (Thursday, 10/23). All users are encouraged to install a patch to protect against an unauthenticated, RPC-based vulnerability (CVE-2006-3439) that can allow an attacker to gain complete access of a vulnerable system.

According to Microsoft's FAQ:

This is a remote code execution vulnerability. An attacker who successfully exploited this vulnerability could remotely take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Microsoft security advisory ms08-67 here:

*Amichai submitted a recent entry about "Patch Tuesday" that quickly came to mind when I saw the Microsoft announcement.

I would like to explain my thoughts about the (now) common use of fingerprint readers as login devices for mobile devices such as laptops or PDA's.

It has become quite common to use our fingerprints in order to gain access to our mobile environments; in fact, it's so common that I know lots of people that have already forgotten their original passwords to log-on to their computer.

The question that should be debated: is this a good practice?

There are multiple reasons to protect data from within the organization. Some are listed here. But to the list of growing concerns we can add another one:

So October's CPU is out. "Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply fixes as soon as possible. This Critical Patch Update contains 36 new security fixes across all products."

This quarter's "Oracle patch Tuesday" has arrived again which means that there's no better time to share (yet again) my POV on patching as a security best practice.  Or should I say "worst" practice.

I'll be using Oracle as an example not because their patching cycles are worse than other vendors. On the contrary, they have shown tremendous progress over the past 3 years with their latest improvement being the use of CVE codes to identify the individual vulnerabilities.

One of the vulnerabilities fixed in this latest CPU (CVE-2008-2625) was discovered by me and reported to Oracle in December 2005. That's almost three years ago!

Now, Oracle had their reason for not rushing into releasing a patch. First of all, it scores relatively low on the CVSS (4.0 out of 10.0) mainly because of its high complexity. Additionally, it only affects a limited set of deployment scenarios (those who use proxy accounts). Now that the patch is out, administrators need to make a decision regarding whether or not they want to apply the patch. Applying a patch is not only time consuming, it's also risky. Therefore we would expect an administrator to be able to answer the following questions in order to make an intelligeble decision:

- Is the vulnerability affecting my database server?

- Is there a work around for my specific environment?

- Is there an external measure I can take to mitigate the vulnerability until a patch is applied?

Unfortunately, in the Oracle CPU advisory it is very hard to find answers to these questions. In the case of CVE-2008-2625, there is no mention of the fact that only deployments who use PROXY accounts are affected. In the case of other vulnerabilities such as CVE-2008-3989 or CVE-2008-3992, there is no mention of a work-around (i.e. remove the vulnerable packages, restrict access to administrative users, etc.).

The amount of information supplied is so scarce that while I know that there is a PeopleSoft vulnerabiliy that I've reported to Oracle that is fixed in this patch, I cannot identify which of the five it is!  Only on one occasion did Oracle provide work-around information; this was earlier this this year when a vulnerability was disclosed on the Internet before a patch was available from Oracle.

Oracle, as I mentioned earlier, is not the only guilty vendor; in fact, IBM is even worse. Microsoft is somewhat better at providing the necessary work-around information. One of the arguments used by vendors for delaying disclosure is that too many details would allow hackers to create code that can exploit systems before they are protected. Let me tell you a secret: THEY ALREADY ARE!

Hacking is a growing business. Money is invested in creating new efficient tools. Some of these tools are aimed at reverse engineering patches (I've been told that this is illegal, but so is hacking...).  Any respectable hacker (notice the irony) owns such tools. For a savvy person using the appropriate tools, it takes days to create an exploit once the patch is out. Applying patches accross an enterprise takes (at least) much, much longer than that.

Bottom line, vendors must provide more information allowing administrators to make better decisions as well as permitting independent security vendors to provide external mitigation solutions within a short time frame. Only in this way can enterprises achieve effective security for their databases.

- Amichai

In our industry, many people spend a lot of time talking about what has become the fastest-growing crime in the US - identity theft.  In doing so, we often use stories to help us illustrate the problem and personalize the black-and-white numbers.

I'm no different.  Several weeks ago, I was commenting about a story that illustrated what can happen when proper controls are not enforced and database security is breached.

...an employee of a third-party contractor (who) had misused information stored in a corporate database was blamed. He or one of his associates then used this employee data to file fake unemployment compensation claims with the Texas Workforce Commission (TWC).

As the years move by, many researchers are trying to understand the magical mystery that is the End-User and, more specifically, End-User Passwords.

Most password cracking and bruteforce techniques are pretty advanced as they use different elements to discover behavior, probable words, and dates that might be relevant to a user.  And there are also the famous rainbow tables ...But would these techniques ever work on a real-life system administrator of any type?

Lets face it, the real reason for getting behind the wheel and trying to discover a password is to access a privileged account such as a Root account or a Database account that will let you gain access to restricted systems and information.

I was scanning a recent Elizabeth Cook blog entry on Sendhill that mentioned the recent Oracle Open World conference. This specific post includes a list of things that one should never do on the trade show floor. I may not be a trade show expert, but I have certainly done my share (See my badge collection).

Our team presented at Oracle World last month and the feedback was great. Our team did very well and this post salutes them, but I also want to augment Elizabeth's blog with some of my thoughs on the things that you should do in order to have a successful event.

We just came back from a partner event in Germany where a partner did a live demo of SecureSphere integrated with a web vulnerability scanner. 

It looks like a growing number of Imperva partners are using SecureSphere integration with web vulnerability scanners to demonstrate not just the value of the SecureSphere WAF, but also to provide a complete Web Vulnerability Management solution. It's easy, simple and works just great. 

During the demo, they scan the web site without SecureSphere protection. Then they integrate the results into the policy manager and then they scan again. Very simple and straight forward process.

The current shipping version of SecureSphere provides out-of-the box integration with the latest releases of IBM AppScan (7.x) and HP WebInspect (7.7) and can be easily extended to other scanners. After a scanner has completed its task, scan results are received and SecureSphere automatically creates user-editable security policies that mitigate detected vulnerabilities. The mitigated vulnerabilities are saved in a database and the user can generate various reports about them.

Today, the PCI Council released the final version of PCI DSS 1.2. We wrote about this upcoming release several times in the past and even had a pretty successful webinar.
The requirement document now integrates the testing procedures which solves some of the ambiguity among customers, security vendors and the QSA community. Overall though, most of the changes are minor. 

In my opinion, adding the testing procedures and emphasizing some of the tests and steps that should be taken deflates one of the main controversial debate areas and simplifies section 6.6. As you know, we believe that choosing between code review and Web Application Firewall is a false dilemma. Amichai and myself were spearheading industry efforts evangelizing this idea and it looks like it has resonated well.  PCI 1.2 takes the air out of the code review option and holds up a WAF as the optimal choice for addressing section 6.6.