Perl.com Hacked via Third Party JavaScript

For a short while recently, if you visited Perl.com, you were redirected to a porn site by malicious JavaScript. How did the JavaScript get there? Advertising. You can read a write-up of the incident at Oreilly.com.

In short, the site at Perl.com included JavaScript on the page that was hosted by one of their advertisers on a remote system. The advertiser allowed their domain to lapse and a pornographer bought it and changed the JavaScript. This is exactly the problem that I pointed out in my talk at the 2007 OWASP conference. If you’re allowing an advertiser, a site tracking service, or anyone else to run third-party JavaScript on any of your pages, you might as well send them all of your users’ data now because they can certainly steal it if they wanted to.

Many people choose not to worry about this problem because it seems unlikely to hurt them. This attacker took a lot of time and effort to do exactly that, including examining what third party JavaScript was running on the site, monitoring site expirations to take control of the advertiser’s domain, and creating his own version of the JavaScript files to do what he wanted.

You may trust your advertising partner not to maliciously attack you, but it’s important to keep in mind that the security of your users’ data is now dependent on the security of their server/domain/data as well. You take a lot of care to protect yourself. How can you be sure that they’re doing the same?

Recommendations for some ways to reduce the risks associated with third party active content can be found in my presentation via the link above.

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