We have finally made it this week into Mathieu Dessus'slist of fingerprinted WAFs. Wow!

You're probably wondering by now what is this list and why should you care about it? Well, let me tell you all about it.

Dessus created a tool that tries to detect what kind of web application firewall is used for protecting an application. It does that by sending an attack vector and testing response and comparing it with the default behavior demonstrated by the different WAFs to which Dessus had access. One could argue about the effectiveness of such technique in real world where people tend to change the default behavior of their devices but my point is totally different here.

We at Imperva are actively engaged in various efforts aimed at providing a standard baseline for testing the security of a WAF. In none of them fingerprinting has been raised as issue. Why is that? Because fingerprinting is a relic of the past. It's a tribute to the dark ages of security by obscurity when people used "obfuscation" instead of encryption and relied on their adversary not knowing the exact brand of web server they are using.

There were times when it made some sense. Hacking was mostly a manual process carried out by a few chosen ones, bandwidth for attackers was scarce and computing resources were very costly. Hacking in general was an expensive time consuming process and therefore attackers were first trying to "fingerprint" the targeted system and apply only those attack vectors that may seem relevant to it.

Nowadays, hacking looks completely different. Bandwidth and computing resources available for the simplest of home setups are abundant. Attack tools exist that would scan a server for thousands of vulnerabilities in a matter of seconds. Moreover, hacking today is completely industrialized and for the most parts it does not involve manual intervention during the attack phase. Hackers abuse hundreds of thousands of zombies, hooked up to a bot net in order to automatically scan and attack their targets. Adding fingerprinting capabilities and conditional execution only complicates the attack code, making it less robust, with no real value for the attacker.

Yes, from time to time individual hackers come up with new methods to bypass security devices. Sometimes they just manage to bypass a device, not even caring what type of device it is. Sometimes they get direct access to a device and manage to come up with specific evasion techniques. Once they have the new technique, it is quickly incorporated into the entire scan database and used during massive scans regardless of whether it is required or not.

To sum things up, I do appreciate researchers taking their time to test the security provided by different WAF solutions. I just wish they would focus their efforts on today's challenges rather than yesterday's.

- Amichai

Another record breaking security patch released by Microsoft this week. The patch covering 34 vulnerabilities in a variety of Microsoft products is the largest of its kind (so far), breaking the previous record set just a couple of months ago (June).

This is giving us an excellent perspective about the inherent limitations of SDLC as the first and last line of defense when it comes to information security. Microsoft has been investing more than any other software company in SDLC and secure coding within their products in recent years. They went a great deal to improve coding practices as well as incorporate different types of security tests during the software development process. Yet in the past year number of vulnerabilities is on the rise.

IMHO Microsoft has just reached the inherent limits of (real world) software debugging processes. The law of big numbers, applied to lines of code, gives us a non-zero prediction as to the number of software flaws per 1000 LOC (or 10K LOC or whatever unit you choose). There is in fact a mathematical postulate that shows that guarantying the correctness of a general computer program is a non-decisive problem (it cannot be solved in a finite time). In fact there is a point in time in which any increase in QA resources (and time) has a negligible effect over software quality. Nowadays, even the simplest of applications is comprised (either directly or indirectly) of a very large number of LOCs (check out the images size of a "Hello World" application). We can rest assured that any software out there has either known or unknown flaws in it. Using the law of big numbers again one can safely assume that some of these flaws affect information security. This happens, regardless of the effort and resources put into the software production process.

So should we give up on SDLC altogether? Definitively not. Prudent use of SDLC can dramatically improve the quality of software, and the security of the information its processing, to the point where flaws are not interfering with common usage of the software and vulnerabilities are not abounding. However, we should also understand that:

    a. we cannot rely on SDLC as the sole line of defense for security purposes and

    b. there might be solutions that are most cost and time effective in terms of mitigating security related flaws in applications.

In particular, I believe that investing resources in a web application firewall is much more effective than putting those resources into SDLC. Two main reasons for that, a. we are talking about substantially less money to begin with, and over the years, b. as discussed earlier, eventually you will need a web application firewall to mitigate those vulnerabilities that were not detected during the software production process.

- Amichai

Yesterday the news story broke about a list of Hotmail user access credentials that found its way to the Internet. The list containing approximately 10,000 entries sorted in alphabetical order ignited some rumors about the entire Hotmail user directory being stolen. As indicated by others, a quick mathematical exercise can show that unless the Hotmail user community is approximately 100,000 in size--this is not true.

Speculations were made as to how the list was obtained by hackers. Microsoft was quick to announce that it cannot be related to their servers’ security since they do not store clear-text passwords but only their hashed / encrypted representation. While I tend to accept this claim—it’s not completely accurate. If an attacker compromised one of the many distributed Hotmail servers and infected it with a simple ISAPI filter that attacker would be able to easily grab credentials while users perform authentication. Another speculation was that this is the result of a massive (or possible several massive) Phishing campaigns. I find this too hard to believe. First, the list is extremely long with respect to the expected results of a Phishing campaign. Given the commonly acceptable estimation regarding the success rate of Phishing campaigns it seems unlikely to be able to collect a list of 100,000 credentials within a reasonable time period. Second, a careful evaluation of the list’s contents suggests otherwise.

My estimate is that the list was obtained through keyloggers infecting computers, not only home ones but also computers used for public access (e.g. Internet Café, University Campus, etc.). The size of the list definitely agrees with this type of attack (infection figures are estimated at tens of millions, with public access computers being a panacea for attackers). Also quite a few entries in the list show the same account name with slightly different passwords, or a slightly different account name with the same password indicating a series of typos at the time of login, with the keylogger just grabbing everything and passing on.

The risk to end users is not confined to the mere contents of their mailbox. In fact many users would use the same password for a number of services. More dangerous though is the fact that password retrieval procedure for many online applications rely on sending the recovered password to an email address set during registration. With control over a user’s mailbox an attacker can compromise other accounts of that user in different online applications (this have been shown to happen a couple of months ago to a Twitter executive whose GoogleDoc account was compromised after compromising her Hotmail account).
Can users avoid falling prey to such attacks? My constant advice to users is have your anti-virus software up-to-date to avoid infections and stay out of dubious sites by using tools like Google’s Safe Browsing or Firefox built-in malicious site filters. Would that prevent infection? It would certainly reduce the chances. However the rate of new servers being infected with new strands of malware sometimes outpaces those signature based detection mechanisms.

Could Microsoft (or any other application provider) do anything to protect users against this type of attack? In my opinion: yes. For example some applications (including Gmail) can display recent account activity. This is mostly useless as account activity is given in the form of IP address. A better solution?  Instead of showing you the IP address of your last login you’d see a pointer on the world map. This would give an immediate visual notification on any suspicious activity. Other measures can be more proactive. For example, I was able to find many different copies of the list on the web by searching through Google with different account names from it. By surrendering bogus credentials to Phishing campaigns and keyloggers, the security team can later look up those same credentials over the web using different search engines and put their hands on entire lists of compromised credentials, being able to take timely action with their rightful owners before the account is compromised.

- Amichai

Back in February I blogged about an incident at Express Scripts. The company was blackmailed by cyber extortionists to pay up or have the organization's sensitive customer info published.

A raised question was what happens in such cases where state regulations actually require companies that suffered from data breaches to individually report this loss to the affected persons.

Last week we received the answer - Express Scripts is now notifying 700,000 customers that their data may have been compromised. The company further states that last month the extortionist provided more accessed data records than those shown to have in the initial blackmailing attempt. Another interesting point is that almost a year has passed but the criminal has yet to be caught.

It seems that Express Scripts cannot specify an accurate number of the records which were illegally accessed, which results in that the company needs to notify all. I admit to not have seen the forensics analysis of this breach but we could still learn from this to mitigate such breach complications. The first and foremost is to place a handy database monitoring tool. Such a tool could keep track of who accessed the data (although this cannot guarantee catching the extortionist, it could provide many helpful details to close up on her), how (was there a system vulnerability? Was this an inside job?) and of course, how many records were accessed avoiding the need to notify those who were in fact affected by the breach.

The recent SQL Injection attack campaign that was discussed this week in the press caught my attention a couple of weeks ago. The attack vector used is quite common these day, in fact, it has been very popular for about the past 18 months. However, during the 4 weeks that we have been monitoring this attack campaign, we have seen the attacks coming from 60 different servers which are all located in China. This is quite unusual as most previous campaigns had attack vectors coming from bots all over the globe.

Another concern gave me pause. As of yesterday (more than 4 weeks after the first infection attempt) the malware distribution sites at: http://a0v.org/ and http://js.tongji.linezing.com were still up and running, counting more than 1,250,000 downloads!

The latter site is hosted on a machine that bares the domain of "alimama.com." Interestingly enough, looking at Google's SafeBrowsing diagnostic information for both domains we see no current warnings about malicious activity.

Wondering through some of the web's back allies I've also recently found a list of Google Dorks that judging by the content, and the activity we see, may be the ones used by the infection agents to look for potential vulnerable sites and mount the SQL Injection attacks.My advice: be careful out there! SQL Injection is here to haunt us; we must have our defenses in place.

- Amichai

In a recent blog post Rich Mogull touched an exposed nerve with respect to the much discussed PCI-DSS standard. The post is Rich's reaction to an interview given by Heartland's CEO, Robert Carr, to CSOonline. Carr was trying to shift the blame on the much publicized Heartland data breach to their PCI assessors and to the PCI council itself. Rich dismissed Carr's claims with respect to the assessors but raised the point about differentiating PCI compliance and actual security.

This debate coincidentally occurs in proximity to the recent Network Solutions breach, in which Network Solutions claims to have been PCI-DSS compliant.

Both events (and some others) raise the question of whether PCI-DSS compliant systems are indeed secure? Is there a problem with the standard or was there a specific problem with the quality of the audit?

I think that much like any regulation or standard, PCI is here to set a measurable baseline for systems. To that extent I think that PCI is doing much better job than other regulations (e.g. SoX, HIPAA, GLBA or on the other extreme, the California Privacy Act). PCI is mostly straightforward and explicit about protected data items, security requirements and even technologies. It requires both the use of specific technical measures as well as the existence of organizational policies and the need for period internal (and external) reviews.

I do have a problem with some of the choices allowed by the PCI standard (e.g. section 6.6 providing a choice between vulnerability assessment and the use of web application firewall - but then again, I work for a WAF vendor :)). I have a problem with some of the lenient assessment frequencies required by the standard (annually for some and quarterly for others). Finally I think that some certification pieces are still missing from the PCI framework (no certification program from web application firewalls). These can (and I believe will) be eventually solved through the work of the PCI Council.

A different problem relates to the fact that compliance is measured by an audit at a singular point in time. If taken to the extreme, an organization may update their anti-virus signature file only the day before a PCI audit and never again for the next year. Information is at risk though continuously (what a shame). It is the assumption that if an organization puts up a given policy this policy is enforced and maintained all year around rather than around audit time.

And last but not least, there is indeed the issue of quality. Quality of the security solutions deployed by the organization, quality of the deployment and quality of the audit process (which is almost always derived by the amount of funds and the time frame allocated to it by the audited organization).

Any breach that is attributed to the two later issues is of course the sole responsibility of the organization. A breach attributed to the first set of issues (PCI standard related) can usually be attributed to a specific choice made by the organization.

To sum up, I think that PCI-DSS can be a positive driver for data security. It will have this effect for organizations who make the right implementation choices, insist on the quality of solutions and assessors and finally track their deployments continuously rather than discretely when audit time comes.

- Amichai  

I just read this week that the city of LA is considering the use of Google Apps for storing and processing government data rather than upgrade their internal IT infrastructure.

Will data stored by the government at the cloud come back to us like pouring rain?

This is really an interesting announcement especially in conjunction with the recent Twitter incident and the breach at Network Solutions. Cloud services are slowly making their way into mainstream business. A few weeks ago one of the major cellular providers in Israel announced that they are going to move all their internal eMail systems to GMail. Why shouldn't those be used by government organizations as well?

One possible answer is that by moving IT infrastructure into the cloud, organizations delegate the responsibility for data security and privacy to a 3rd party. While a commercial organization can do it on its own financial risk (i.e. if a breach occurs - that organization is going to have to compensate affected individuals) a government will actually compensate affected individuals with their own funds.

I think that such ventures ought to be postponed until we have a clear definition of who is responsible for the security of personal information stored by governments on 3rd party systems and until there are clear methods for the government to attest to the security of that information with respect to its own regulations while stored on 3rd party systems.

- Amichai

^{Following recent announcements, Chris Gates, one of the prominent conributors to the Metasploit project is going to reveal a new automated tool for testing Oracle database exploits.}

Chris Gates has been releasing Oracle exploit code and “hacking training” videos for quite some time now. The new tool is probably merely a compilation of existing code modules that exist in Metasploit. I personally think that the Metasploit project is important for the security research community. However, I don’t think that the new tool has any real value as a security assessment tool for enterprises big or small.

Assessing a database server by simulating attacks puts that database server in a lot of risk. There are existing alternatives for testing databases for vulnerabilities that do not have this dangerous effect. In particular, all the information required for accurately detecting whether a database is vulnerable or not can be retrieved from the database itself with simple SQL queries. This is in fact the approach that we use with our free database assessment tool Scuba, available for download.

At the same time, I don’t think that providing such a tool makes it especially easier for hackers to attack databases. The code and tools provided by metasploit to the ethical hacking community have been circulating independently among the black hat hacking community. I technical details of the vulnerabilities supported by the tool have already been made public in the past. I therefore don’t see any real support for the claim that it has an adverse effect on database security.

- Amichai

Following the Twitter hack last week, Twitter founder Biz Stone ended his breach blog post with the famous quote: "... akin to having your underwear drawer rifled: Embarrassing, but no one’s really going to be surprised about what’s in there."  

As the hacker revealed how the breach occurred, and I must say that the way the underwear drawer was unlocked was not surprising. As the details were exposed we got the Full Monty: Inactive accounts on different portals which may be recycled by other users, current accounts pointing to old accounts, Google Hacking (or in this case, Social Network digging), taking advantage of password reset mechanisms, reusing passwords for multiple accounts, no “separation of duties” on passwords (the same password used both for personal and business accounts), and of course - organizational policies on (mis)using the cloud.

Gaining all the initial information to carry out such an attack points to issues in the “Your Secret Questions” and your "Secret Facebook Account". When people choose their secret questions (required by many systems as a means for protecting the password recovery process) they'll not be hesitant in selecting questions like “Your childhood hero”, “Pet's name” and “Mother's maiden name”. Answers to these questions are unlikely to be easily found anywhere—except on a person's “Secret Facebook Account". But lo and behold, it turns out that most people don't keep their Facebook pages secret, they actually share them with the entire Internet population, happily exposing such details as... Pet's name, childhood hero and guess what? Even a mother's maiden name.

Reflecting back on OWASP EU2009 I think it was a very good event. The contents were good - see Ross's and Bruce's talks on the economics of security. Interesting people attended - I had a chance to talk with people coming from a variety of backgrounds such as development teams, code review, pen testing and assessment services. Finally, the location was great.
I feel that the two keynote talks really sunk in the difference between theoretical security and practical security where the last is that part of security that is driven by real economic factors and real businesses needs. As security experts I think it is important to focus on both the theoretical and the practical however, I feel that sometimes we tend to focus too much on the theoretical side.

I reflect some of these ideas in my presentation where I present the growing risk of business logic attacks. Business logic attacks are attacks that turn the web application functionalities against the business - breaking the business logic instead of breaking the application. Analyzing hacking incidents from the recent years that inflicted real money loss we see more facilitating business logic attacks. Some examples are comment SPAM and Web Leeching attacks and even a better example is how Google's own features are used by hackers to make money. You can learn more about Google Hacking from our presentations: "Beyond Google Hacking", OWASP 2008 and "Blame it on the Media(Bot)", InfoSec 2009.
We are constantly revealing new evidence on the increasing risk of business logic attacks (for example, by analyzing malicious traffic in our HoneyPot servers) and I would also appreciate feedback from researchers outside Imperva on this topic. So, feel free to send comments on my presentation or on the field of business logic security in general (my mail: eldad at Imperva dot com).

See you in the next OWASP...