Secure Web

SC Magazine Names Best Buy Winner for Application Vulnerability Assessment Tool

On April 21, SC Magazine named the Best Buy winner to the application vulnerability assessment tool vendor.  The independent review took a look at 7 vendors and gave an overall start rating as well as a summary of their positive and negative attributes.  See the table below for an overview of the report. 

As you can see, the Best Buy Winner was awarded to Cenzic’s Hailstorm Enterprise ARC 5.5.  The product had no negative attributes associated with it. 

Vendor	SC Mag Positive Review	SC Mag Negative Review
Application Security, Inc’s DbProtect 2007	Flexible configuration options. Impressive enterprise-class integration with other DbProtect components.	May preclude some who have web application needs.
Cenzic Hailstorm Enterprise ARC 5.5	Integration with VMware is a unique and useful feature.	None that we found.
Fortify Source Code Analysis Suite 4.5	Powerful analysis of source code. Solid documentation with an emphasis on workflow and secure coding best practices.	The various components have a disparate look and feel. Non-coders should steer clear from code analysis tasks from a usability perspective.
HP Webinspect 7.7	Powerful scanning engine. Robust set of features that continue to evolve.	Higher price for not having true enterprise capabilities out of the box.
IBM’s Rational AppScan 7.7	Powerful scanning engine. Robust set of options. Excellent documentation.	True enterprise management, requires the purchase of additional AppScan products.
iSEC Partners Security QA Toolbar	Small footprint and low administrative overhead for QA teams who need to validate the most common application vulnerabilities.	Very high price for a browser-based toolbar. Lack of documentation and support.
Ounce Labs 5.0	Good performance with many useful features. Very detailed technical results.	The Security Analyst user interface can feel overcrowded at times depending on which perspective you are using to view the information.

2007 - Another crisis year for Web Security!

Today we published our application security trend report for Q4 and the full year 2007. And, although there was some progress made by a lot of corporations and government agencies, prognosis continues to be grim. We are barely scratching the surface. We have a long way to go and many companies are still trying to figure out what they should be doing. Here's my abbreviated executive summary from the trend report. You can download the full report from Cenzic home page at www.cenzic.com. Please feel free to provide feedback or start a dialogue on the subject here.

2007 was certainly an eventful year. And, not just for election primaries. In 2007, we saw a number of creative and lethal attacks - not just in election debates. Web site hacking continued to gain momentum as hackers had a field day exploiting vulnerabilities across all geographies and across different types of Web applications. From SQL Injection Robot to a Russian Malware gang attacking a government site to exploitation of various Google vulnerabilities to various universities – attacks continue. Financial gains continue to be the primary goal but we also saw attacks to steal intellectual property, student records, and in a few cases to deface Web sites. The total number of vulnerabilities stabilized but Web application related vulnerabilities continue to hover around 70 percent of total vulnerabilities. The “bad guys” go where the vulnerabilities are and Web applications are certainly appealing and inviting to these constituents.

 

Application vulnerabilities in Q4 tracked the first three quarters in terms of their dominance, forming 71 percent, a three percent increase over Q3, of the total 1,404 published vulnerabilities. The scary part is that 70 percent of these vulnerabilities are easily exploitable. Application vulnerabilities are the ones that pertain to Web technologies including Web servers, Web browsers, and Web applications. These published vulnerabilities are for commercially available software and infrastructure that corporations and government agencies buy from ISVs (Independent Software Vendors). These don’t take into account thousands of vulnerabilities that are created while programming in-house or proprietary applications, many of which are outsourced to other countries including India, China, and Russia. Millions of consumers spent more than $29B during the 2007 holiday shopping season in the U.S. alone, putting their personal information including credit cards numbers into all kinds of Web sites. While there haven’t been many incidents reported of records stolen or major hacking since the holiday season, the silence is deafening. There’s actually a valid reason for this. First, it takes a while before companies realize that the information has been stolen from their databases. Secondly, hackers are no longer interested in publicizing their conquest stories. It’s in their best interest to steal the information and use it in stealth mode as long as possible. Rest assured, some of these sites have probably already been hacked and stories will start coming out as the year progresses.

 

Most of the vulnerabilities in Q4 were within the applications themselves, comprising about 85 percent of all Web application vulnerabilities. Web server and Web browser vulnerabilities were 10 percent and 5 percent respectively. Applications written in PHP continued to be a major chunk forming 30 percent of all vulnerabilities.

 

Our Top 10 vulnerabilities for Q4 2007 include various technologies and companies including OpenSSL, IBM Lotus Notes, Adobe Acrobat, Java, Realplayer, PHP, IBM Websphere, Apache, and Adobe Flash. Since this is a year-end report, we added a section for the Top Five Application Security Vulnerability Trends for all of 2007. Our Top Five for 2007 include Javascript Trickery, Universal XSS in Adobe Acrobat Reader, Mass-SQL Injection Worm, Google Gadgets and Gmail Hacks, and ORKUT XSS Worm.

 

Cenzic’s ClickToSecure managed service that tests customers’ Web applications remotely once again found that roughly 7 out of 10 Web applications are vulnerable to various types of vulnerabilities including Cross-Site Scripting, Information Leaks and Exposures, Authorization and Authentication flaws, Session Management, SQL Injection, and other security defects.

 

In 2007, we were encouraged to see more corporations and government agencies taking action by testing their applications for security vulnerabilities - partially driven by regulations like PCI, AB1950, and GLBA, and partially to protect their brands. But, we still have a long way to go. Technology and expertise is available for organizations to start their application security process quickly. Now, with virtualization integration to some Web application scanners, they can also start testing their production applications and not just the applications in development and Q.A. We hope we’ll continue to see this momentum of security consciousness in 2008 as we deal with Application Security, the next frontier.

    - Mandeep Khera

Reefer Madness or Session ID Pollution, you choose

So you can grok the title of this post, anyone remember that awful '50s documentary that tried to scare everyone into not smoking marijana? Reefer Madness! What I am getting at is this: back in early 2004 I reported a vulnerability in PHP and got ridiculed by a developer for even pointing out the issue. He said in a round about way that I was suffering from the Reefer Madness Syndrome, that is to say, that I was hyping an essentially benign issue and trying to scare everybody with it. Well, I was really busy back then and didn't feel like debating the issue so I let it drop. The flaw was later silently fixed in some 5 dot dot something release in 2006.

But still, the idea interests me because I am curious the degree to which its a localized problem in older versions of PHP or a broader issue. The root cause of what I called Session ID Pollution during my talk at OWASP Appsec 2007 is a failure to sanitize the session id of a web application, allowing an attacker to append some junk to it which gets passed around by the web application. The appended junk is essentially ignored by the application itself, but as its passed between content brokers like proxies or content portals, it has the potential to do harm.  One specific example that I cited was appending <script>foo<script> to a valid session ID token and as that information is passed around, it can become cached or directly execute within a web portal when a user follows a link. Wrapping your head around this issue is really a two part process:

1. A web application allows a user to append arbitrary data to a Session ID token, and this data is not filtered or sanitized, but is transmitted as if it were part of the valid session id, like so:

SessionID=24378923479<script>malicious code</script>

The script gets more or less tacked on to the end of the session id and it doesn't affect the session or disrupt it, but its not stripped away or sanitized either, so it effectively becomes part of the session ID as its passed around, its just not a part of the session Id that the application cares about. This is the benign aspect of the vulnerability. But don't read benign to literally, because in the same way a person or animal can carry a disease, manifest no outward symptoms, but spread it around just like the monkey in the movie Outbreak with Dustin Hoffman.

2. The session ID that has been polluted is then passed around various applications, and thus it has the potential to be executable as one of these other applications parse the URI in question when presenting data to the user.  This is the part of the movie where the monkey  gives  the disease to everybody in the village and the UN has to drop a fuel  air bomb on it. The original application hands off its polluted session ID to a content broker, content portal, proxy, or web logging server.  Thus a user follows a link to a web application, the application does not filter the session ID and the malicious content contained in the link is preserved. In fact, the application goes so far as to assign the user a new session ID but preserves the data appended onto the session id in the original request. But when the user receives the response from the application, the malicious code executes in their browser as the polluted session ID is parsed by the proxy sitting between the user and the application.

Ok... so  what? (The "so what" test is venerable tradition of college debaters. Subjecting an argument to the rigors of the "'So What' test" requires asking does anybody give a damn.) Evidently, when I reported this issue back in 2004 it didn't pass the so what test of the developer to whom I reported it. Objections to the significance of so called "Session ID Pollution" were as follows:

1. Its not the fault of the application, or a bug in the application, its the Proxy's problem. I.E. The content portal, proxy, or broker should filter hazardous characters from input not pass potentially harmful data off to the user.

2. The issue is not new, its just lame old boring cross-site scripting.

3.  You're a lamer for bringing this issue to my inbox.

My rejoinder:  Applications and servers should ensure that the session ID doesn't contain harmful or dangerous characters and that it has not been modified. Failure to do so means increased risk that some other application will recieve dangerous input from the application. One simple example is webtrends-like software that logs browsed urls in and does so in an insecure fashion. When someone views the log the script executes in their browser. Yes its a problem of the logging software, but the application, which transmits the information unsanitized, is being abused by the attacker to get their exploit into proper attack vector where it can have its impact. Now we shouldnt' go about blunting our scissors because its unsafe to run with them, but in the case of sanitizing the session ID,  there really is no good reason for someone to be able to append arbitrary data onto it, and failure to check and prevent its modification is, I suggest, a vulnerability.

At OWASP Appsec 2007 I called this vulnerability "Session ID Pollution." Because I'm interested in the topic and have been for a few years, you will be hearing more about this from me as I continue to research the issue. Consequently, at the conference where I recently presented on this topic I was challenged that the problem is only a PHP problem, and for that, at the present, I have no answer. More to follow.

-Tom S.

As Holiday Shopping approaches, Web security woes continue

With the release of our Q3 Trends report on Web application security on Nov 12th, we continue to see a rise in Application vulnerabilities which formed 68% of all published vulnerabilities in the quarter. But, the main issue here is not the rise in application vulnerabilities. Rather, the problem is with inaction or lack of sufficient action by companies and government agencies in doing something about securing their Web applications. Jupiter Research is predicting 126 million shoppers will spend over $39 billion this holiday season. That's a lot of shoppers putting their personal information in millions of Web sites that sit on top of applications - most of them vulnerable to hackers.

In looking at the data from our services unit as well as many published sources, we estimate that about 90% of all Web applications out there contain some vulnerabilities. While 70% of the applications tested by Cenzic's managed service unit were found to be vulnerable, most of these companies  are in North America and are sophisticated users who understand the importance of securing their Web applications. If we look at the entire population of Web applications across the world, there is little awareness on secure coding and application vulnerabilities.

To give credit where it's due, there are a number of leading edge companies in North America like Google, Oracle, Microsoft, and many large financial services companies and a few government agencies who are making major investments in testing their applications and fixing vulnerabilities. But, these form a small percentage of all the companies that are doing e-commerce transactions or collecting customer information online.

As hackers keep getting smarter, Web sites keep getting hacked without companies realizing the intrusion, and consumers  keep getting frustrated with their identities and other personal information being stolen. So, what can we do? Customer need to be more alert and look for the right companies to do business with and ask the right questions around Web security. Companies and government agencies need to do a lot more to secure their Web applications and start the process immediately. We have a long way to go so the quicker we can start the better. And let's hope this Christmas season doesn't turn into Halloween when it comes to holiday shopping!

- Mandeep Khera, Cenzic Inc.

Q3 2007 Trends Report: First Look

Cenzic's CIA Labs will be releasing our Application Security Trends Report for Q3 2007 next week but I wanted to give our blog readers a first look into our results. First though a few remarks are in order about the report itself for those who haven't read our previous application security trend reports. Cenzic's trends report is an industry first in many ways. Its only such report of its type that focuses entirely upon application-layer vulnerabilities, attacks, and trends. Symantec's Internet Security Threat Report, now on volume 12, is the best security trend report in publication, but its focus is also very broad and web application security is only a very small part of the overall content. Understandably, the Symantec threat reports have a much broader goal and scope than our own, and being an avid reader of the Symantec report, I noticed the need for a security trends report that focused entirely on web application security. It was our (lofty) goal to do for web application security what Symantec's report does for Internet security in general, and although this sets a very high bar, its the gradual striving toward this goal which means that our trends report will continue to evolve and improve over time.
        I want to take a moment and thank all those who contribute to the report. Since we began producing this trend report in Q1 2007 we've already seen some interesting emerging trends within the data. Although Cenzic CIA Labs performs all the research, the final report is a cooperative effort that relies on individual contributions from people both within Cenzic and a network of friends and contacts. And of course our report could not be what it is without dshield.org and the CVE (of which I am an editorial board member).
        Our Q3 trends report signals in many ways "business as usual" in the application security space. In other words, many core trends remain the same:
        1. Web application vulnerabilities continue to comprise the largest part of all vulnerability data. In Q3 2007 web application security vulnerabilities comprised 68% of the total vulnerability information.
        2. Cross-Site Scripting continues to be the most prevalent web application vulnerability reported, with SQL Injection and RFI attacks not far behind.
        3. Directory Traversal vulnerabilities, the dot-dot-slash type attacks (../../) are among the least reported web application vulnerability types, typically ranging from less than 1 to 4% of the total web application vulnerability volume.
        4.  SQL injection vulnerabilities still continue to constitute roughly 20% of the total web application vulnerability volume. In other words, 1 out of 5 reported vulnerabilities is usually a SQL related vulnerability.
        5.  Insecure coding practices in PHP continue to contribute to 30% of the total web application vulnerability volume. Vulnerabilities in PHP itself, as a programming language,  tend to contribute 1-3% of the total vulnerability volume, indicating its insecurity coding practices, and not PHP as a programming language, that contribute to the usual storm of PHP-related vulnerabilities.
        These are some of the trends that have remained constant since our first trends report in Q1, trends further substantiated by the result of our Q3 report and analysis. There are several emerging trends that signal the affects of Web 2.0 programming practices and architectures within the reported vulnerability information, but if you want to learn more about these trends, you'll have to read our full report when its published next week.

Thanks again to all our readers,

-Tom S.

   

Symantec Threat report stresses app security, Web security woes continue for Google, Banks, Government

Symantec Corporation issued their Internet Security Threat report recently confirming a lot of trends that Cenzic had published in its first two quarterly trends report. While there are many malicious activities going on on the Internet from network level worms to client side exploitation with tools like Mpack, Web application security continues to be the most critical concern. Symantec found that 61 percent of published vulnerabilities related to Web applications which tracks closely what Cenzic found in the first two quarters. So, what does that mean? It implies that very month roughly 300 to 500 new vulnerabilities are being reported for Web applications, and organizations not only need to catch up to all the vulnerabilities from the past many months but also keep up with the new ones every month. And, the worst part is that over 70% of these vulnerabilities are easily exploitable. So, what would the hackers do? They would attack where the majority of the vulnerabilities are. And, it's not in the network any more. Web 2.0 technologies, with Ajax, and other scripting languages continue to create even more headaches, from security standpoint, for corporations and governments.

In the last few months, we have seen many attacks including the cross-site-request forgery attack on Google, CBS News, Ukranian attack on US Government job site, and Chinese government attack on Pentagon site, to name a few. Also recently, the Homeland Security Department improperly disclosed details about a serious threat to the U.S. electrical grid to industry researchers just days after it produced a video showing simulated hackers remotely seizing control over a $1 million diesel-electric generator which raised a lot of questions about Cyber Security.

So, the big question is if every one knows that they are exposed, whey aren't they doing something about it. There are many reasons including: (1) Lack of Understanding - Many security professionals across all size companies still believe that they are secure because they have network firewalls, IDS, and other network security technologies in place. This is a complete fallacy. None of these technologies will protect them from Web application attacks; (2) Lack of resources - Even if organizations understand the exposure, they have too many applications to test and they are just scratching the surface; (3) Ostrich mentality - I have been told by many  CSOs and other security executives that they have never been hacked so they are not worried. When I ask how do they know that, they typically don't have a very good answer.

We think these attacks will only intensify as hackers are getting more organized with proper structures and attacks for major financial gains or to steal IP. We'll see more politically motivated attacks as well as governments are realizing Web sites as a weak link with easily exploitable assets underneath. Governments and Corporations need to move fast to start taking Web security seriously - before it's too late.

- Mandeep Khera, Cenzic Inc.

Web Security and Ease of Doing Business

The other day I was trying to send some money to some one using one of the money transfer companies. After going through a rigorous process and phone calls for half an hour, I gave up. Good news was that this company was taking extra precautions to secure their transactions through the Web given that in this case actual money was involved. Bad news however was that it made the transaction so complicated that they lost my business.   

Many companies that conduct online transactions with customers are going through the same predicament. How to provide adequate security without making it too difficult for the customer to do the transaction?

There are certain practices that certainly make sense like strong passwords (e.g. minimum 8 character alphanumeric etc.) , having security questions, and even a secondary key. Where it starts getting sticky is when there are phone verifications or additional pieces of information that customers don't like providing or it's too time consuming.

The worst part of some of these processes is that two fundamental principles of "Let the Good Guys In" and "Keep the Bad Guys Out" are reversed. So, the good guys have problems getting in because of all the additional measures and the bad guys still come in. How does that happen?  Very simple, the bad guys are coming in by exploiting the vulnerabilities in the Web applications that are sitting underneath the front-end. Most of the applications that we have seen are still vulnerable and hackers know how to easily exploit them through the user interface including forms and fields.

As a best practice, organizations should provide some best practices mentioned above for access by the "true" customers without making it too difficult. And, a much stronger emphasis needs to be placed on finding and fixing vulnerabilities in the code itself. Make it more difficult for the hackers to come in, not the customers.

I would love to hear some of the best practices people are following that are working well. Please post your comments.

- Mandeep Khera, Cenzic Inc.

Web App Security, not as Sexy as James Bond but Close

I saw a news story last week that was kind of surprising to me but really shouldn't have been. An article posted by the Financial Times discussed the Chinese military hacking into the Pentagon. http://www.ft.com/cms/s/0/9dba9ba2-5a3b-11dc-9bcd-0000779fd2ac.html It surprised me because I never really thought of the military groups from different countries hacking into each other. Call me old school, but I still pictured spying and espionage between countries to be handled by the equivalent of James Bond. Thinking about it just a little and applying a tad of logic makes me realize how foolish that thinking is.

In the article, China was painted as the villain since they hacked into the Pentagon and had previously hacked into some German government computers. However, the article also mentions that the US is assumed to regularly scan Chinese networks. Both of these ideas simply emphasize how much easier it is to hack into a computer system than to directly risk the lives of your "super spies." It might be sexier to seduce foreign agents while stealing top secret documents but it's safer to do it online instead. No need to end up being strapped to a table while a laser preps to slice you in half.

How and where the computer was hacked wasn't mentioned but comments near the end of the article had me thinking it was an email account that was hacked. It could just as easily been via a Web site instead. Hopefully any Web sites being used by the Pentagon are performing some simple input validation. Most Web application vulnerabilities can be avoided by validating the data being entered. If asking for a person's name, accept only letters. If asking for a phone number, accept only numbers. At least block the simple stuff. It might not make you a super spy but you can still be a hero in your office. You can always hope for more excitement when ordering that martini shaken, not stirred.

How Web Application Security and Guns are Common

In an attempt to do the right thing, the Germans aren't really helping themselves. News.com is reporting that "As of Saturday, it's a crime in Germany to build, sell, distribute or obtain so-called 'hacking tools' designed to allow access to protected data or promote other illegal acts." http://news.com.com/8301-10784_3-9759051-7.html There are a few scary things about this.

A lot of the "hacking tools" fall into a nebulous classification of neither good nor bad. They are more along the lines of how you use the tool. It's not evil if I'm using Nessus on my own network to determine where a vulnerability might exist. The same is true for any Web application testing software. When used within an environment I am testing or responsible for, the results are positive and not negative.

The same logic can be applied to many open source tools that are used for more generic purposes. Paros and nmap would both fall into the realm of "hacking tools." You might be using them safely but this law would outlaw them.

Web application testing solutions don't fall into a bad category by themselves. This law might work for protecting messaging environments; it makes tools like Send Safe (automated spam generator created and operated out of Moscow) and other Russian 'bot exploiters illegal. However, the law is too generic and would also apply to simple load testing tools. All it would take to quickly deluge a lot of people with junk is a purchased list of email addresses, Load Runner and a little time to format a spam message. All with a tool that I should be using to verify my system can work properly.

While the law might only be enforced in situations where most of us would agree it is warranted, it is not a clear cut case. And I wouldn't want to trust that some overzealous prosecutor is not looking to form his reputation by putting away "evil hackers," especially when the bulk of the public don't understand the difference.

- Mike Kazmierczak, Cenzic, Inc.

 

Both insurance and prevention!

One of the hardest things about security is getting people to understand and to implement it. This can be small simple things or something more advanced. For example, most of us realize that having a complex password is a good thing but what about changing that password on a regular basis. Work probably forces you to change it quarterly but when is the last time you changed your Amazon password? Or the password for your banking account?

Deciding what kind of security system is needed is part of this process. Some things such as a network firewall or SMTP gateway are easy decisions. They are de facto needs (firewalls) or an obvious problem (blocking spam via a SMTP gateway). Deciding to protect against something that hasn't happened to you yet (your Web site being hacked as an example) takes a more forward thinker. How much does having an automated Web application security solution really help? Are you wasting resources and time testing for something that might never affect you? Or will you be glad to have it?

If you think about it, security is an insurance policy. It's something that you spend effort deploying and implementing in order to protect yourself. When you don't need it, you feel like the time and money was wasted. At the same time though, when it is needed, you are eternally grateful.

Yet at the same time security is a preventative tool. If you regularly lock your car, then nothing is stolen (or at least not as often). If you've fixed all the holes in your Web applications, then there is no opening for the hackers to get in. So while security might seem tedious and at times an overkill, it is still better than cleaning up the mess of lost or stolen data afterwards.

- Mike Kazmierczak, Cenzic, Inc.