XSS UTF 7 encoded vulnerabilites and APIs that prevent them

You can check if your web application is vulnerable to XSS UTF-7 vulnerabilities by trying the following attack vectors:

1) +ADw-script+AD4-alert(+ACI-XSS+ACI-)+ADw-/script+AD4-
2) %2BADw-script%2BAD4-alert%281%29%2BADw-/script%2BAD4-
3) +ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

If your application reflects back executable script (showing the dialog XSS alert) to the browser after entering such attack vectors from user input it is vulnerable to UTF-7 encoded XSS. As you might know, reflected XSS can be used maliciously to steal confidential data stored on the victim browser such as cookies and confidential information.

So if your web application is vulnerable to XSS UTF-7 encoded attacks you should check the server side API that filter input data and make sure that do not actually fail in the implementation of basic XSS countermeasures such as:
1) use white list filtering (e.g. default deny except for safe characters)
2) perform output encoding of input strings to the HTML equivalent before sending back the output string to the browser. Example:< becomes &lt and > becomes &gt

Unfortunately, some APIs being developed in commercial web applications still use black listing with regex to strip off script tags such as <> and fail miserably when the attack vector is provided in encoded fashion such as UTF 7.

If your application filter API is actually doing black listing , you can try to fix it by changing the regular expressions and filter the UTF-7 input equivalents.


The problem I see with this approach is that soon enough another XSS script could enter unfiltered when using a different encoding and therefore exploit the vulnerability again. The main problem is that trying to black listing all XSS attack vectors is hard since is difficult to predict what is malicious (black list) rather then define what is benign (white listing)

Also do not forget to enforce the correct encoding through the metatags like in UTF 7 XSS vulnerability that where previously found in google (now being fixed) http://www.governmentsecurity.org/forum/lofiversion/index.php/t18105.html.
Actually, if you enforce the encoding to a different charset such as UTF-8 or ISO 8859-1 you will not be vulnerable to UTF-7 XSS because the browser will switch to a UTF-8 encoding and will not render the UTF-7 attack vector.

But, if you really would like to implement an effective XSS filtering API make sure to perform white list filtering and output encoding and test that the API does not fail to filter different encoded attack vectors such as the one listed on http://ha.ckers.org/xss.html.

My suggestion: do not to re-invent the wheel :) use APIs that have been tested and vetted by the security community. Some of these APIs (e.g. HTML purifier) have been already developed and tested using XSS attack vectors: http://htmlpurifier.org/live/smoketests/xssAttacks.php When using .NET look at Microsoft Anti-XSS library the version 1.5 is freely available from MSDN: http://msdn2.microsoft.com/en-us/security/aa973814.aspx XSS filtering APIs are also available to download from OWASP such as Anti-Samy and the Encoding APIs.

The OWASP Anti-Samy http://www.owasp.org/index.php/AntiSamy it's a library that parses and cleans HTML/CSS using a whitelist validation technique. It has been presented by Arshan Dabirsiaghi at 07 OWASP/WASC Appsec Conference in San Jose: www.owasp.org/images/e/e9/OWASP-WASCAppSec2007SanJose_AntiSamy.ppt The OWASP encoding library is functionally equivalent to the Microsoft AntiXSS has been developed for several languages http://www.owasp.org/index.php/Category:OWASP_Encoding_Project
More specifically for php you can also look at the OWASP PHP AntiXSS library
http://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Library_Project

Building the case for software security within your organization

Cost vs benefit ratios, source
http://webinsecurity.blogspot.com/

Just came across a video clip on last year turbo talk I did at Black Hat.

http://www.findinternettv.com/Video,item,1249009004.aspx

As I look back to this presentation and the concepts I pioneered back then (Software Security Framework) , I see that these are still very valid concepts today. If I had to do the speech again, maybe I'll introduce some new concepts. I would probably cover the risk data driven approach and put software security in the frame of the organization maturity levels CMM (Capability Maturity Model).

I'll also try to understand better the audience to tailor my talk. My BH turbo talk was intended for information risk managers with high visibility on information security processes. Since at the end of my presentation someone asked me a question on threat modeling frameworks, that make me think that I should have talk more in detail about software security activities and methodologies on how to implement them. Overall, the effectiveness of the presentation, besides the presenter skills, really depends on target the content to the right audience. If I had to talk of software security to project managers I will put the emphasis on missed deadlines on product delivery because of fixing vulnerabilities and how software security can help. If I had to talk to developer managers/architects I will probably present "how to" use case scenario for software security implementation showing use/misuse cases, architectural risk analysis, secure code reviews, source code analysis tools, security unit tests, security system tests, vulnerability management and remediation.

The scope of the 06 BH presentation was really to build the case of software security to CIOs.

So if you are looking for a software security recipe for a CIO dinner, based upon my experience (e.g. in consulting and now as information security officer) this is the one I'll use:

1) explain how software security is different from information and application security (apples and oranges)

2) make the software security risk management case using your risk data (e.g. 30% of vulnerabilities are LHF that can be fixed with better coding and source code analysis early in the SDLC instead of penetration tests in UAT and production ). If you do not have risk data use public and unbiased sources (e.g. NIST, SANS, Gartner, Forrester)

3) assess the maturity level of software security and position it on the organization CMM framework. If you do not have a CMM framework, position it on a general one.

4) make the business case using your cost center data (cost me 100 man/hrs to fix a cross site scripting vulnerability that I could have avoided by implementing secure coding standards and catch it with source code reviews and unit tests)

5) suggest both strategic (long term) and tactical (short term) solutions

6) suggest short term solutions as "stop the bleeding" kind of activities (e.g. penetration test with common vulnerability check lists, source code analysis for projects in the development phase, threat modeling for projects in the requirements and design phase)

7) recommend long term strategic solutions (e.g. ad-hoc software security frameworks, software security enhanced SDLCs methodologies)

And I stop here not because of the magic number (7) that we remember but because if your start with this you should be in the right path to build your case. Now is a good meal sufficient to made the case? Well depends. Check what the CIOs say after tasting it? Are my CIO more sensitive to tool pushing agendas or security policies/standards? Are they driven by the bottom line? (i.e. costs) Are they driven by risk analysis and the risk data? To be effective in building the case, we have to understand what CIO taste is (e.g. needs, concerns, technology, people, processes) and then build the case for it. Therefore a session after the presentation to capture feedback and explain further your point is very important.

Ultimately, I should remind you of my golden formula for security:

Security = Commitment * (Policies.Standards.Frameworks.Guidelines^2+ Procedures.Technologies.Tools)

With commitment being NULL (e.g. the people component!) there is no security as you can see from the empirical math. So to build the case you need to focus on the commitment point and move from awareness (your presentation ) to training (the next step). You know you made the point when you've asked to talk about the details and elaborate on software security activities moving forward.

As an example, you know you made the case for wine when the next time you talk to a friend of yours that knew little about wine, you do NOT need to make the case of why drinking wine is good but between choosing to drink a pinot grigio instead of sauvigon blanc

If you have been asked that question, your friend got the point of drinking wine by now :)

MFA security controls and their adequacy to mitigate financial fraud and identity theft

The FFIEC compliance for authentication in the banking environment guideline, states that single factor authentication is not adequate to secure high risk banking transactions such as the ones involving the transfer of funds and dealing with customer sensitive information (e.g. PII, Account Numbers etc). To comply with this guidance (that was EOY 2006) most banks implemented custom based authentication solutions on top of typical credentials authentication (username and password) such as One Time Password (OTP) tokens (e.g. Secure IDs), challenge/responses questions based on shared secrets and risk based authentication solutions (e.g. Cyota). Unfortunately, the fact of the matter is that most of these MFA banking solutions have not being implemented with the real intent of the FFIEC mandate to banks that is perform a risk analysis, identify the financial transactions that are at high risk, evaluate how effective are the security controls to mitigate threats and implement a security solution that is not necessarily a MFA control but can also be multi-layered security mechanism.

There is evidence from publicly available research that most MFA solutions are still vulnerable to fraud via phishing and MiTM (Man In The Middle) attacks, a proof that in the trade-off between FFIEC compliance, usability and security, security did not become the main outcome of the implementation.

In the case of SiteKey (i.e. PassMark Security ® (now RSA ®, the security division of EMC ®)authentication technology used as MFA (Multi-Factor Authentication) for on-line banking sites such as Bank of America and other banks ( Vanguard and Pentagon Federal Credit Union) several fraud vulnerabilities have been indentified. In particular SiteKey is not a sufficient deterrent to phishing ot other online frauds: http://cr-labs.com/publications/SiteKey-20060718.pdf

On SiteKey Technology specifically, Christopher Soghoian and Prof. Markus Jakobsson, both with the Stop-Phishing Research Group at Indiana University presented a demonstration of a "man in the middle attack" against it: http://paranoia.dubfire.net/2007/04/deceit-augmented-man-in-middle-attack.html

Back in July 2006, Ravi Ganesan CEO of TriCipher was interviewed by Martin McKeay on the MiTM web proxy attacks to MFA http://media.libsyn.com/media/mckeay/nsp-072506-ep36.mp3. In the podcast Ravi explains how easy was to replicate the attack and pointed out that all token based MFA solutions such as RSA tokens, cookies, challenge response/risk based authentication with device fingerprinting, IP address and geolocation, scratch pad OTPs. were vulnerable to this class of attacks. Especially in the case of MFA that use geolocations and device fingerprinting, Ravi made the clear point that such countermeasures are not effective to mitigate phishing attacks that use botnets in different locations and are re-routed from different proxies. Also, when using cookies for authenticating (recognizing) the machine the mechanism of registering the cookie based upon a user correct answer to a challenge question was also proved to be exposed to phishing: the phisher will send a message to the victim user to provide the answer to the challenge question because the machine could not be recognized.

The main problem is probably that these MFA solutions were implemented to buy a checkmark from a FFIEC auditors and quickly adopted in a rush to comply with the 2006 EOY FFIEC deadline. Now, two years later we wonder why these MFA controls are not actually mitigating the identity theft and financial fraud that were supposed to prevent.

Nowdays there is a need of a viable MFA control that provides a good compromise between (1) cost, (2) usability and least and but last (3) security. I would not be surprised if in light of the growing identity theft and fraud threats we saw in 2007 some and the high Total Cost of Ownership (TCO) to keep these vulnerable MFA technologies, some banks will implement cheaper and more threat mitigation effective MFA controls.

Lessons learnt from TJ Maxx data breach and credit card fraud

The main security lesson that credit card issuers learnt from TJ Maxx companies 95 million credit cards data loss and 1 Million USD transaction fraud is the need to require merchants to secure the weakest ring of the chain: the WLAN connection between POS (Point Of Sale) terminal and branch servers . Merchants should learn from POS vulenarbilities and apply the right countermeasures like the ones identified in the research paper herein http://www.hackerfactor.com/papers/cc-pos-20.pdf. Now, despite the major exposure of the TJ Maxx security incident was due to weak wireless encryption such as WEP (Wired Equivalent Privacy) http://online.wsj.com/article_email/SB117824446226991797-lMyQjAxMDE3NzA4NDIwNDQ0Wj.html) there are still a large amount of retailers that either do not secure their WLAN at all or still use the flawed Wired Equivalent Privacy (WEP) protocol or the pre-shared key mode of the Wi-Fi Protected Access (WPA PSK) specification, which was originally intended as basic security for home or SOHO WLANs:http://www.pcworld.com/article/id,141429-c,privacysecurity/article.html

The other lesson is that VISA PCI compliance is more a vehicle to recoup fraud losses rather then proactive security. In the case of TJX Maxx VISA fined 53rd Bank (the TJ Maxx VISA Card processor) 880,000 USD for non being not in compliance with PCI in light of 2005 incidents but gave the credit card processor a 2008 deadline to comply http://www.scmagazineus.com/Visa-fines-TJX-credit-card-processor/article/58255/ Now 1 ML fraud vs. 880,000 fine still seem to repay VISA for most of the losses.

The other lesson is that law suits are not a strong enough deterrent for being secure in case of large retailers such as TJX Maxx. The 257 Million USD law suit that TJX Maxx settled with smaller banks http://www.boston.com/business/globe/articles/2007/10/24/court_filing_in_tjx_breach_doubles_toll/?page=2 certainly did not put TJX out of business: http://www.darkreading.com/blog.asp?blog_sectionid=403&doc_id=137756&f_src=darkreading_section_403

In Italian we have a say that "il rischio non vale la candela" (the risk does not warrant lighting the candle) saying if the air smells like the all environment is about to explode probably is better not to light the candle. Now in this case I think retailers will probably continue not being compliant with PCI standard while the fraudsters that are still uncaught and out in the wild we will continue to light the candles.

Why CAPTCHA is not a security control for user authentication

An example of CAPTCHA

CAPTCHA stands for "Completely Automated Public Turing test to tell Computers and Humans Apart". Typically this control involves a word verification via an image that is not machine readable via OCR and requires a human user in front of the computer recognizing it and entering in on the site. Typically this is an effective control to prevent spam-bots to register automatic information to a web site and stop automated posting to blogs or forums, whether as a result of commercial promotion, or harassment and vandalism. CAPTCHA it also has been deployed to protect systems vulnerable to e-mail spam, such as the webmail services of Gmail, Hotmail, and Yahoo.

Unfortunately there is a mis-understanding of this control is designed for and some sites use it as "custom" authentication factor to verify that the image word recognition challenge has indeed entered from the human that was intended to. In this case, CAPTCHA acts like a “placebo” security control for the user: it will let the user think that the site can be trusted since the site is intended to validate him as trusted user (not true!). CAPTCHA is not a valid control for authentication, is just a weak control that is vulnerable to several attacks such as social engineering. For example CAPTCHA challenges can be redirected to other users and have the images recognized to pass the test intended for the user http://www.avertlabs.com/research/blog/index.php/2007/11/01/the-captcha-challenge/

Again do not be confused on what this control is about: CAPTCHA is not an authentication control!. Is an OK control to prevent automated positing of contents to a site meant to collect information from un-authenticated users such as visitors.

Also, if you implement this control for verify a visitor posting to your site instead of a bot positing, be careful to implement it securely: most of this controls are vulnerable to insecure implementation due to unsecure session management (e.g. re-using an invalidated SessionID associated with a known recognized image, no word challenge change at fault attempt).

Some CAPTCHA attacks are due to reliance on a small library and weak hashes (e.g. MD5s) that can be collected by an attacker and broken using a rainbow table. So use a large library of images and employ strong hashes (e.g. HMAC) with random seed to prevent rainbow table attacks.

New Owasp Chapter Started

I moved to Cincinnati back in March 2007. Cincinnati did not have an OWASP chapter so I started a new one. We have our web page http://www.owasp.org/index.php/Cincinnati for notifications and the mailing list is up an running.