The Night Before Xssmas

Twas the night before Xssmas and all through world
Not an application was safe, no one dared click a URL.
People’s browsers sat idle and they all pondered when
It’d be safe to view greeting cards online again.

The hackers were nestled all snug in their beds,
While visions of session cookies danced in their heads.
Developers were still working to push out new code,
But soon it’d be compromised for another bot node.

Cries for help on the Internet rose to such a clatter,
That consultants at Security PS looked into the matter.
They raced to their keyboards and started to type,
“Validate data” they cried, yet many thought it hype.

A few implemented black lists for input inspection,
And found they still fell victim to SQL injection.
The clueless were left in their server rooms gawking,
As exploits were launched that left their servers talking.

The good consultants didn’t give up in spite of all this,
And created security classes taught by a bright geek named Kris.
He showed people hacking demos and watched faces fall,
When they saw they couldn’t trust client data at all.

“Your users aren’t safe,” he said, “when it is revealed,”
“I can push JavaScript into this not-so-hidden field.”
“Plus parameters are bad,” he added with a wink,
“When they can be used to create an unsafe link.”

With time a few companies began to see the light,
And changed security practices to fix their code right.
“It’s not so hard,” they said, “when you know what to do.”
“Plus it’s nice not to have Russian hackers chatting with you.”

While we don’t want to claim victory too prematurely,
We do think more applications are being developed securely.
For those still struggling to deal with the injection plight,
We say “Merry Xssmas to you, keep up the good fight!”

Defcon 15: "Strong" Authentication in Web Applications

Has your organization recently implemented multi-factor, risk-based, or mutual authentication? Do you think your application is now more secure and has a "strong" authentication system in place? Often, web applications are actually at more risk once these authentication features are introduced due to the considerable amount of complexity added. The typical result is to have implementation flaws that allow attackers to harvest usernames, obtain customers' mutual authentication images, or bypass security questions.

Until recently, there have not been many resources made available to the public about how to find and exploit vulnerabilities pertaining to these new authentication features; however Brendan O'Connor's presentation at Defcon 15 provided a great deal of visibility to these issues. His presentation, "Defeating Strong Authentication in Web Applications", discussed the common issues seen in these authentication systems and how to carry out associated attacks. O'Connor's presentation specifically discussed problems with mutual authentication, device fingerprinting, out of band authentication, one time passwords, and knowledge base archives. He highlighted technical flaws in the implementation of these features as well as reasons why the features may be inappropriate solutions to the problem an organization is trying to address.

A great example of how new risk is introduced by implementing these authentication systems can be found in the first step of many mutual authentication login processes. In the past, applications asked for the customer's username and password on a single page. If either of these credential pieces was incorrect, the application would respond with a generic authentication error which did not reveal whether the username or password was the incorrect piece.

Now that mutual authentication has been included in the mix, applications commonly ask for the customer's username ONLY as a first step. If that username does not exist, the application may display an error or behave in a completely different manner than if the username were valid. This is all happens before the application ever asks for a password, an answer to a security question, or a permanent cookie/flash object.

The added risk to the application is that an attacker can now discover one of the three secret credential pieces (for example: username, security question answer/permanent cookie, and password) needed to gain entry into the application. This reduces the "strong" authentication system's effectiveness to that of the simple username and password combination, in that only two credential pieces are needed to login.

So, is this a big deal? Do you think any hackers will test your organization's authentication system? There were around 7,000 attendees at this year's Defcon and all these attendees received a copy of O'Connor's slides. In addition, there were more than three hundred interested individuals who attended his presentation. Odds are there are many people who not only think this is a big deal, but are interested in whether your organization implemented their new "strong" authentication system securely. There are also many who may have the knowledge and expertise to find out for themselves if your web application has any of the flaws discussed in O'Connor's presentation.

My suggestion is if you haven't yet looked into these issues in your environment, you should start as soon as possible. Otherwise, someone else is going to find these authentication vulnerabilities and use them to compromise your customers' accounts.

To learn more about challenges and flaws introduced by implementing risk-based, multi-factor, or mutual authentication systems see the App Security Advisor Multi-Factor and Risk-Based Authentication podcast.

What OWASP is and what it means to you

Our blog has featured a link to the OWASP web site for most of its existence. Maybe you have clicked on it and checked out the great resources that OWASP has to offer. Maybe you already know about the organization and its ongoing projects. If you aren't familiar with OWASP, let me give you a quick introduction.

The Open Web Application Security Project (OWASP) is a not-for-profit group dedicated to improving the security of web applications. They support this goal by publishing security testing and software development guidance, creating web application security testing tools, and funding related projects that benefit the community.

OWASP also encourages the creation of local chapters where security professionals and developers can meet with their peers to exchange information. These chapter meetings typically include one or more presentations covering topics like web app attacks, security testing techniques and tools, secure coding practices, and product evaluations. Meetings also serve as a good opportunity to compare notes with other locals on what is going on with web app security in their organizations.

I recently had the honor of assuming leadership of the Kansas City OWASP chapter and am excited about the chance to spread knowledge of web application security in our area. However, I can’t accomplish this goal without your help. Right now our chapter mailing list only includes a few dozen of the hundreds of Kansas City professionals who would probably want to participate in this group.

If you or others in your organization aren’t currently subscribed, I encourage you to join today. If you have friends or former coworkers at other businesses, let them know about the chapter. Subscribing to our mailing list will keep you informed about the interesting topics that will be covered at upcoming meetings.

Our next meeting is September 6th and features a presentation from a federal bank examiner about the good and bad application security practices he’s observed at financial institutions. Get the location and time at our chapter website. I hope to see you there.

Defcon 2007

The Security PS consulting team recently attended Defcon 15. With five tracks running over three days, the conference jam-packed enough hacking techniques, exploits, and security news into our heads that I’m afraid I may have blown a fuse from information overload. The presentations covered everything from Wifi attacks to application security to hardware hacking, and speakers like Bruce Schneier, Johnny Long, and Dan Kaminsky didn’t disappoint packed audiences.


When one of your job requirements is keeping up with an entire world full of blackhat hackers, it’s helpful that once a year they all get together and tell you what they’re up to. We will be posting highlights from various talks over the next few weeks. Stay tuned.

Banks fail to meet FFIEC multi-factor authentication requirements

By the end of 2006, U.S. financial institutions were told to comply with the FFIEC’s updated guidance on authentication for Internet banking. This guidance instructed financial institutions to use multi-factor authentication, along with other security controls, for any online applications that allowed "high risk" transactions. Consequently, banks, credit unions, and other organizations hustled to integrate new authentication solutions that could satisfy bank examiners and reduce online fraud.

Did they succeed? One recently published study says no. In a paper titled Trends in U.S. Multi-factor Non-Compliance, Sestus Data Company and BearingPoint Financial Services report that only 4% of the 100 banks sampled consistently required multi-factor authentication. If this sample is representative of all U.S. financial institutions, and I feel fairly comfortable that it is, we appear to have a serious problem.

The main reason for the failing grade comes from conflicting interpretations of the term "multi-factor authentication". As the report points out, 90% of financial institutions have implemented additional authentication requirements in the form of challenge questions. However the FFIEC’s original guidance and subsequent FAQ explicitly require multi-factor authentication solutions to combine at least two of the three authentication factor types: what you know, what you have, and what you are. Combining challenge questions with passwords only builds upon the single factor category of 'what you know'.

So, the big question then becomes why are bank examiners are allowing financial institutions to get away with solutions that don’t meet the defined criteria. Just to be clear, I haven’t heard any official answer to this so I can only share my theories.

The new FFIEC authentication guidance was a pretty big shock to the many financial institutions who had given limited attention to their online application security. I can tell you from experience that some of these organizations were failing to establish and enforce even basic password requirements for customers.

Many financial institutions undoubtedly raised objections when they were told to skip the step of improving passwords altogether and jump directly to implementing multi-factor authentication. Especially when this jump meant investing around $15 - $30 per user before the 2007 deadline. Some of these organizations were tempted to find lower cost solutions that would address some of the FFIEC’s concerns about authentication attacks.

At this point bank examiners could have sat down with the financial institutions and told them that these changes were inadequate. Astonishingly, I haven’t seen or heard anything to indicate that these conversations ever took place.

Maybe bank examiners are at odds with the FFIEC personnel who pushed the requirements for true multi-factor authentication. Maybe they are willing to allow partial compliance with the guidance to see if these stopgap solutions still reduce fraud. They could still come back later and tell banks that they need to improve the ineffective authentication solutions. Maybe the examiners decided too late that the requirements were too drastic and are quietly allowing compromises by financial institutions so the FFIEC can save face.

Regardless of the motive, I don’t like the result. The financial institutions who took the guidance literally are now at a competitive disadvantage to those who didn’t. They probably have better authentication security but they are also likely to have spent more money on a multi-factor authentication solution. People don’t always like what’s good for them, especially when it includes a significant change, and a stronger authentication system may drive some customers to a competitor who has laxer security standards.

This is the wrong message for the government to send to financial institutions and consumers. Financial institutions may drag their feed in complying with any future security requirements until they find out what examiners will really require of them. Both customers and financial institutions will remain exposed to threats longer than necessary during this waiting process.

If you would like to share your perspectives on compliance with the FFIEC’s multi-factor authentication guidance, leave a comment. I’d love to hear your thoughts.

Tips for Avoiding Bad Authentication Challenge Questions

I’m excited to share the news about a brand new white paper from Security PS. We’ve had clients requesting this information for months, and I'm glad we can finally share it in a written form. This is also the white paper Kris and I discussed in the App Security Advisor Multi-Factor and Risk Based Authentication podcast.

The paper is called Tips for Avoiding Bad Authentication Challenge Questions. To be clear, a challenge question is a question used for authentication that asks you for personal information. Examples are “what is your mother’s maiden name” and “what is your pet’s name”. Financial institutions, including many of our clients, have implemented challenge questions in an effort to improve online authentication for higher risk applications.

My goal with this paper was to review how well these questions actually succeed in effectively authenticating users. I subjected challenge questions to a framework for evaluating authenticators that I developed several years ago. I also gathered a variety of examples from clients and public sources so I could illustrate the strengths and weaknesses of different questions. I think you may be surprised by our conclusions.

If your organization has implemented challenge question authentication or are simply interested in how much security they provide, I encourage you to give it a read. I’d love to get your feedback about the paper. Please enter your comments on this blog entry or send me an email directly. You’ll find my contact information at the end of the paper.

Paper link: http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf

New App Security Resource

The App Security Advisor blog and podcast has been released. While you can read and listen to the first post on the web site to hear what the resource is all about, I'll give a quick recap here.

In short, The App Security Advisor podcast discusses hot topics in the world of application security and provides insight to where the industry is at, what pitfalls companies are hitting, and what proven practices can be applied for the most effective results. Many of the discussions will be strategic and well-suited for director and executive level audiences who require insight for moving forward with application security initiatives. However, there will also be a number of segments that are technical in nature to help the technical managers and development team leaders get a handle on the technical side of the challenges and solutions.

Current topics include multi-factor authentication pitfalls, security in the SDLC, and gauging the effectiveness of app security initiatives. Other topics on the way include technical authentication gotchas, top 5 questions to ask your application vendor, and web services/SOA security.

The segments will have mini-seminars, interviews with industry experts, and question/answer segments. Leave comments on the blog or send e-mail to have your questions included in the Q/A segments, or to provide direction for future topics.

When to Assign Users Responsibility for Security

First, I wanted to mention that the Security PS blog is now one year old. We thank those of you who have scrutinized and shared our content in an effort to increase awareness of information security issues. We also encourage you to continue submitting your questions or blog entry ideas with us via the comments section or email. With your feedback we can continue to provide expert coverage of the security issues that are important to you.

Second, I want to share my concerns about a security practice that has been bothering me for some time. Almost every application or network consists of users with vastly different levels of security awareness and skill. For every company that has a user like me (my bio claims I'm pretty security savvy) they have hundreds of users that are less aware of the security threats they face. So why is it in some cases those same users are required to make important security decisions?

In this case I'm referring to the growing trend of asking users to set their own custom security questions and answers. These are the questions and answers commonly used to provide a fallback option for authenticating when a password is forgotten; or used to further validate an identity when a username and password are deemed insufficiently secure. We are seeing this built into more online financial applications in an attempt to meet the FFIEC's new authentication requirements.

My main concern is that the user can customize the questions, not necessarily that the questions and answers are used for authentication. In these situations the answers to the questions act as a substitute for, or an equivalent to, a password. Logically, they must be held to the same standards of security that passwords are. They must not be easily guessed or predicted. They must collectively ensure that only the authorized individual can provide the correct answers.

Yet this is not the main issue of concern for most users when selecting these questions and answers. They are focused on choosing a question and answer that they can easily remember. This is also important, but it cannot take priority over the confidentiality of the information.

When a user sets up a question like "what is my favorite color" -- and they do -- they have not only limited themselves to a fairly small selection of answers, but they have also chosen to prompt for a piece of information that is not considered a secret. They are likely to share the information if asked by a family member, friend, or possibly even a casual acquaintance.

How can this be considered the security equivalent of a password?

Sadly, this has been a known issue for some time. Organizations first started experiencing similar problems when they allowed users to create customized password hints. Nothing stopped users from making their hints blatantly obvious (such as "a day of the week") or even putting their password directly in this field.

Professionals cannot in good conscience allow these decisions to be delegated to the users. Claims about it being the user's responsibility to make good choices, at least in this area, simply don't make sense in today's hostile Internet environment. If you see it fit to enforce minimum password standards you must also commit to enforcing minimum question and answer standards.

The simple solution is allowing the user to select from a library of predefined questions instead of creating their own. You should select these questions with the uniqueness and confidentiality of the answers in mind. Here are some of the better examples:

- Who is your favorite character in a book?
- Who was your favorite teacher?
- What was the name of your first crush?

Want more feedback on securely implementing question and answer based authentication? Send me an email and I’ll be happy to share my thoughts.

Searching Google for SQL Injection Targets

SPI Dynamics recently had an on-demand webcast where they scanned around 1000 sites using the Google API for SQL injection. The scanning application returned approximately 700 sites that actually responded to their queries. They only did simple SQL injection tests using a very basic SQL string. Also, they only looked at sites that actually returned verbose SQL responses. Even with this very small and restricted subset, they found that 11% of sites returned verbose SQL errors. The presenter goes on to say that he thought that this estimate was representative of the population but is likely a lot higher than that.

Based on the presentation, it sounds like there are lots of vulnerable web apps out there. It is kind of interesting to me that even in this day and age, SQL injection is still so common. Thankfully, the presentation also provides the best approach to prevent SQL injection vulnerabilities; validation based on whitelists, and sound queries through parameterization.

Check it out when you have 15 minutes or so.
https://download.spidynamics.com/registration/SQL_webcast.asp

Cross-Site Scripting in Adobe Plug-In

You may have seen the recent flurry of news stories surrounding a cross-site scripting (XSS) vulnerability in Adobe's PDF browser plug-in. In case you missed it, here are a few articles that provide an overview of the problem:

Washington Post
USA Today
Information Week

Essentially, the vulnerability provides yet another way for an attacker to execute JavaScript in another user's browser when the user follows a specially crafted URL to a PDF file. By adding JavaScript commands to parameters in the URL, attackers can steal cookies and sensitive data, change the appearance or behavior of the site, and redirect users off-site in phishing attacks. To make matters worse, the attack string (the part that does the damage) in the URL is never even sent to the web server, so the attack can't be stopped by having the server look for dangerous JavaScript in requests for PDF files.

So, what can an organization do to protect its users from being attacked through PDF files stored on its web site? There is no foolproof solution, but the best approach is trying to prevent the vulnerable Adobe browser plug-in from running, which can be accomplished in some browsers by changing HTTP headers in the web server response. There are two relevant headers that could be changed:
  Content-Type: application/octet
Content-Disposition: Attachment

Both of these headers instruct the browser to download the file instead of opening it in the vulnerable Adobe plugin. We have followed this approach on our own servers and it prevents the attack in most cases. This morning, Google and Yahoo followed suit with a similar fix.

Here are instructions for adding these headers to the server response for PDF documents in Apache and IIS.

Apache:

Add these lines to the httpd.conf file inside the <Directory> tags.
  AddType application/octet .pdf
<Files *.pdf>
Header add Content-Disposition "Attachment"
</Files>

IIS (tested in 6.0, these instructions may vary some for older versions of IIS):

Change MIME type to "application/octet":
  1. Start > Run > Enter compmgmt.msc. The Computer Management console appears.
  2. Right click on the Services and Applications > Internet Information Services (IIS Manager)
  3. Select Properties > MIME Types
  4. Scroll down to ".pdf". The MIME type should be "application/pdf". Change this to "application/octet".
  5. Click OK twice.

Add Content-Disposition header (this must be done by directory or for each PDF file individually):
  1. In the IIS Management tool (not in Windows Explorer), select a directory with PDF content or an individual PDF file.
  2. Right-click on the directory or file.
  3. Select Properties.
  4. Click the HTTP Headers tab.
  5. In the Custom HTTP Headers section, click Add.
  6. A dialog appears. In the "Custom-header name" field enter "Content-disposition". In the "Custom-header value field, enter "Attachment".
  7. Click OK twice.
  8. Restart IIS (command line: iisreset).
  9. Check that PDF content from the browser now prompts the user to "download" rather than simply opening the content.

This is not a 100% solution, but changing the HTTP response headers will go a long way toward reducing the risk to users of your site. Although this works in current versions of the more popular browsers, it is possible that some browsers could ignore these headers and open the PDF with the Adobe plugin anyway.

It may also be possible to address the vulnerability programmatically. Some examples have been published for Java and .Net. These examples have not been tested by Security PS, but they have been proposed as a way to help prevent attackers from exploiting the Adobe plug-in vulnerability.

If you implement these or other changes, please let us know about your experience.