This bug is NOT ABOUT the local disk path appearing in the FOOTER of your pdf since it is clearly visible and already known by most people. This is easy enough to hide by just going File -> Page Setup -> Change the Footer value from “URL” to “-Empty-”. After doing that, you will not expect your internal disk path being put anywhere else. However, that does not happen.

The privacy issue arises from the fact that your local disk path gets invisibly embedded inside your PDF in the title attribute. Only when you open the file in an Editor like Notepad, you will see it. Currently, there is no option in IE to disable it. The only workaround is to manually nullify this value by editing the PDF file. Note that this problem does not occur when using other browsers such as Firefox and Chrome. In fact, Chrome handles the other footer issue intelligently as well by showing your disk path as “…”, rather than exposing it.

Proof of Concept:

Steps to reproduce:
1. Pick a .HTM or .HTML or .MHT file on your local computer.
2. Open this file in IE and click Ctrl-P.
OR Right-click the file in explorer and select PRINT from context menu.
4. Select any PDF writer as Printer such as Adobe PDF / CutePDF / PrimoPDF / etc.
5. Click Print. When the PDF writer asks for a filename, provide any name.
6. Open the generated pdf in notepad, and search for “file://” without quotes.

Search for this on your favorite search engine (Google/Bing)

filetype:pdf file c (htm OR html OR mhtml)

Google Search 1 (for drive C) – 4 million results
Google Search 2 (for drive D) – 13 million results
and so on…. (I added till drive letter J and total was more than 50 million….)

So, out of 280 million pdfs accessible on the internet, more than 20% look to be exposing internal disk paths which is a huge number. I have contacted the Microsoft and Adobe Security Teams about this issue. Microsoft has plans to fix this in IE9, while Adobe has opened the case but hasn’t planned the timelines yet.

Examples:

http://www.eda.gov/PDF/EDA_vol1;%20Issue10.pdf

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.0-c316 44.253921, Sun Oct 01 2006 17:14:39">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/pdf</dc:format>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>LewtasS</rdf:li>
            </rdf:Seq>
         </dc:creator>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">file://C:\Documents and Settings\lewtass\Desktop\eda newsletter</rdf:li>
            </rdf:Alt>
         </dc:title>
      </rdf:Description>

http://www.oregon.gov/OMD/OEM/plans_train/grant_info/fy2009_hsgp_investment_justification.pdf

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1-701">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
         <pdf:Producer>Acrobat Distiller 7.0.5 (Windows)</pdf:Producer>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:xap="http://ns.adobe.com/xap/1.0/">
         <xap:CreatorTool>PScript5.dll Version 5.2.2</xap:CreatorTool>
         <xap:ModifyDate>2009-03-18T15:07:10-07:00</xap:ModifyDate>
         <xap:CreateDate>2009-03-18T15:07:10-07:00</xap:CreateDate>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/pdf</dc:format>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">mhtml:file://O:\fema\shsp_2009\draft ijs\fy 2009 investment jus</rdf:li>
            </rdf:Alt>

I was evaluating this ESAPI api and the recommendations given on the wiki to see if there are any potential flaws. Any weakness impacts a very large number of users since many developers are using it to strengthen their web applications throughout the world. This is my way of contributing back to the community, but can never match the immense efforts put by Jeff and other OWASP team members in developing this library.

I want to give you a little bit of background before diving into the real vulnerability. The XSS prevention cheat sheet classifies XSS protections by dividing them into broadly four buckets – HTML Body injection, HTML Attribute injection, Javascript injection and CSS injection. For each of these four buckets, there is an ESAPI function reference you can use for output escaping/encoding.

If you allow any untrusted user input into javascript functions document.write() OR eval(), it can still execute the XSS even after you do the scrubbing using the ESAPI encodeForJavaScript() function. The reason being that hex escaped chars are converted back into normal chars at the time of execution of these functions.

Here is the proof of concept jsp code:

<%@page import="org.owasp.esapi.*"%>

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>ESAPI XSS Protection Bypass</title>
    </head>
    <body>
        <h1>ESAPI XSS Protection Bypass</h1>
        <p id="tb1"/><br>
        <p id="tb2"/>
        <script>
            //in real scenario, these three strings come from request.getParameter or user input
            <%
                String vulstr1 = "-1';alert(0);";
                String vulstr2 = "<img src=x onerror=alert(1)>";
                String vulstr3 = "0,x setter=alert,x=2";
            %>   

            // you can safely use it in places like this
            // Ex. vulstr1 is completely encapsulated in a and alert(0) not executed.
            var a='<%= ESAPI.encoder().encodeForJavaScript(vulstr1) %>';
            alert(a);

            // However, you can bypass protection in places like these
            // Ex. vulstr2 gets written to html and alert(1) executes
            document.write("<%= ESAPI.encoder().encodeForJavaScript(vulstr2) %>");
            // Ex. part of vulstr3 get assigned to u, rest alert(2) executes
            eval("u=<%= ESAPI.encoder().encodeForJavaScript(vulstr3) %>");
        </script>
    </body>
</html>

Much thanks to Jeremiah Grossman and Jeff Williams for taking the time to review my idea and providing their insights. Jeremiah told me that he has seen such injections from time to time at WhiteHat and these do exist in the wild.

Jeff confirmed that some documentation changes will fix this. I agree that no esapi code change is required, because function themselves are not insecure.

But, if you are currently using esapi functions inside your javascript code, it is important that you re-review your javascript code and the places where your make calls to esapi functions.

If you use the esapi function encodeForJavaScript() inside document.write, it is advised that you change them with other appropriate esapi functions depending on the context where the data is ultimately landing. For example, if you have document.write(“<script>alert(‘XSS’)</script>”), you know the data is landing in html body context, so it is appropriate to use encodeForHTML() wrapper. Using user input inside eval is less common, but more disastrous. The reason for this is you can still begin another command context using , and (space) char and it won’t be encoded by function encodeForHTML(). So, it is better to avoid putting user input inside eval.

Any more suggestions or discussion on fixes is highly welcome.

Update: Security researchers Sirdarckcat and Gareth were kind enough to share the code for a pure CSS based CSRF token finder here . This is stealthier than my PoC below, which used a combination of both JS and CSS. So, it will still work even if you disable javascript and you are not safe anymore . To make this PoC more responsive to the client, you need to use multiple CSS stylesheets using the import command. The only problem I see with this pure CSS based approach is there will be network latency involved with large key spaces because your large CSS stylesheet will need to be downloaded by your browser.

I was thinking about the problem of Cross Site Request Forgery and current mitigation strategies used in the Industry. In many of the real world applications I have tested so far, I see the use of random tokens appended as part of url. If the request fails to provide any token or provide a token with incorrect value, then the request is rejected. This prevents CSRF or any cross domain unauthorized function execution.

Uptil now, it was considered infeasible for an attacker to discover your CSRF token using Brute Force Attacks on the server.

The reasons being:

1. It generates lot of noise on the network and is slow. So most probably an IDS or Web App Firewall will pick up the malicious behavior and block your ip. For example, a Base16 CSRF token of length 5 characters (starting with a character) will generate approximately 393,216 requests.
2. Many applications are programmed to invalidate your session after it detects more than a certain number of requests with invalid token values. E.g. 30.

I am going to change this belief by showing you a technique to quicky find csrf tokens without generating alerts. This technique is a client side attack, so there is almost no network traffic generated and hence, your server and IDS/Web App Firewalls won’t notice it at all. This attack is based on the popular CSS History Hack found by Jeremiah Grossman 3 years ago.

In this exploit, we discover the csrf token by brute forcing the various set of urls in browser history. We will try to embed different csrf token values as part of url and check if the user has visited that url. If yes, there is a good chance that the user is either using the same CSRF token in the current active session or might have used that token in a previous session. Once we have a list of all such tokens, we can just try our csrf attack on the server using that small list. Currently this attack is feasible for tokens with length of 5 characters or shorter. I tried it on a base16 string of length 5 and was able to brute force the entire key space in less than 2 minutes.

Some of the prerequisites for this attack to work are either

1. CSRF token remains the same for a particular user session. e.g. csrf token=hash(session_id) OR
2. CSRF token submitted in older forms for the same session is accepted. Many times, this is the case as it enhances user experience and allows using forward and back browser buttons.

Proof of Concept is available here.
Before running the PoC, you need to change the url and csrftoken paramater values.

For testing using the defaults, you need to first visit one of the following urls, e.g.

1. http://securethoughts.com/?param1=val1&csrftoken=b59fe [change b59fe to any 5-digit base 16 string starting with a character, i.e.greater than a0000]
2. http://tinyurl.com/l2lwgd [which is 301 redirect to previous url].
   

Note: http://www.securethoughts.com and http://securethoughts.com are treated differently while storing in browser history.

A sample run will look like this –

For making this attack unfeasible,

1. Server-Side Solution (for developers):
• Make your CSRF tokens long enough (8 or more chars) to be unfeasible for a CLIENT SIDE attack. The ever-increasing processing power will make this attack feasible for longer tokens as well.
• Store your CSRF token as part of hidden form field, rather than putting in url.
• Use a different random token for every form submission and not accept any obsolete token, even for the same session.
2. Client-Side Solution (for your customers/users):
   • Use a browser plugin such as SafeHistory, which defends against visited-link-based tracking techniques.
   • Use the private browsing mode in your browser.

And last, but not the least, XSS obliterates all the CSRF protections possible. So, get rid of XSS first.

I would like to thank Jeremiah for providing his insightful feedback on this post.

Before that, I have used Stefano’s Tool, SWFIntruder. It is a nice tool to audit Actionscript 2 apps, but it only reports XSS issues and does not support Actionscript 3. This time, I was out of luck, since I needed to audit a Actionscript 3 App. Also, I could not decompile and study its source code since the free tool Flare does not work on Actionscript 3.

So, I decided to give HP’s tool a try. I had a lot of expectations from this tool, since HP already has a popular tool WebInspect which is known in the industry for its website and web services auditing capabilities. I ran this tool on my app and it decompiled beautifully the complete source code of the flash app. It has a useful search feature which can aid in manually studying source code for vulnerabilities. However, I wanted to see some of its automatic auditing capabilities. So, I ran the scan and found it to find some issues like crypto issues(sha0/sha1), stacktraces, etc. Apart from that, it didn’t report any serious issues like XSS, etc. It also does report a large number of false positives in checks that start with “Possible/Potentially – - – -”. But i am willing to ignore those as long as the tool can effectively find some important vulnerabilities.

I didn’t know my app had any XSS issues or not, so I decided to use the free test.swf which is provided as part of SWFIntruder.

To my surprise, HP’s SWFScan tool did not report any of the 5 XSS issues reported by SWFIntruder.

If you see the screenshots below, swfscan shows you the vulnerabilities it found and the decompiled source code. Using manual inspection, a penetration tester can easily locate XSS issues in parameters such as _root.obj and _root.sd which are directly written into html without any escaping/filtering. I hope this free SWFScan tool improves in the near future and does not miss auditing such simple vulnerabilities.

Just when I was about to give up, I found the possibility of a phishing attack in one of the pages, specifically the error page in the application. The problem was user supplied content from the url paramater list was put directly into the error page, filtered only for XSS characters and the whitespace character. In a normal scenario, user is redirected to the error page, resulting in:

http://securethoughts.com/security/phishinguserinput/error.cgi?url=/my_app_url&user=jack

Using URL encoding and the ‘%09′ ASCII character (horizontal tab), I can phish a user to go evilsite.com. Evilsite.com will have the same inferface looks as the legitimate site and some users might unknowingly fall prey into typing their login credentials.

http://securethoughts.com/security/phishinguserinput/error.cgi?url=/my_app_url&user=%2e%54%68%69%73%09%73%69%74%65%09%69%73%09%63%75%72%72%65%6e%74%6c%79%09%64%6f%77%6e%09%66%6f%72%09%6d%61%69%6e%74%65%6e%61%6e%63%65%2e%09%50%6c%65%61%73%65%09%75%73%65%09%65%76%69%6c%73%69%74%65%2e%63%6f%6d

This class of phishing attack can apply to any page. It does not confine to error pages and is not blocked by filtering and encoding mechanisms. The only requirement is user’s language characters (including whitespace character like %09, %20, etc) should be injectable in the page output and the rendered page should sound convincing to phish a user into going to evil site. If the user is not convinced and types the domain name directly into the address bar, this attack will fail .

A solution to this issue is to use url encoding or html entities for all the special characters [not just XSS chars < > " '] before writing back user’s input data back to the browser. For links, using url encoding instead of html entities also protects from HTTP Parameter Pollution.

“You can even completely hide your private folders from virtually all applications, and such folders would remain invisible until you enter a valid password.”

Is this really true?? No, not at all. Let’s see how. Actually, my friend used one of these softwares and challenged me if I can expose his data without the password used to lock the data. So, I decided to give it a try.

I first downloaded and installed a trial copy of Folder Guard software on my computer. Then I created a folder named “mysecretfiles” inside directory “test” on G: drive. Then, I opened Folder Guard, created a login password and locked this folder. The configuration setting I used for this folder was Access = “No Access” and Visibility = “Hidden”. You should see a similar screenshot after you lock a folder.

I closed Folder Guard and clicked on “Yes” in the “Start Protecting the System” dialog box. This caused Folder Guard to enable protection on my folder. As a result, I didn’t see my locked folder in Windows Explorer.

I tried to understand how these softwares work. Almost all of them placed hooks into the windows device drivers and block access calls to locked files and folders. This model is flawed because an attacker can use the back channel, often referred to as Direct Disk Access Mode.

So, I decided to fire my favorite Disk Editor WinHex and I could easily see and browse my locked folder with ease. I could look inside my locked file “mysensitivedata.txt” and check its contents with my username, password and SSN . The other best part of this disk editor is that I don’t need to install it, I could just easily run it from a USB pen stick.

So, the best protection to protect your data is still to use industry standard encryption with algorithms such as AES, 3DES, etc. Even if the data falls in wrong hands, the confidentiality of the data won’t be compromised. Use softwares like TrueCrypt to protect your sensitive data.

A web page is composed of three major content types, namely HTML content, Javascript Code and CSS styling code. I felt the need of a tool that could beautify or format the entire web page source code. I use Burp Suite, my favorite web proxy tool. However, it does not have source code formatting feature, it just colors the web page by choosing different colors for html tag names, html attribute values, javascript, css, etc.

I looked on the internet for free alternatives, but I could not find free tools that could format the entire web page. Most of them could only format either one of HTML or Javascript or CSS. So, I decided to write a perl script myself. I used the libraries HTML::Tidy by Dave Raggett and Javascript::Beautifier by Einars Lielmanis. And I have written my own CSS formatting code.

Example of HTML Formatting

Example of CSS Formatting

Example of Javascript Formatting

In addition, I have done one more improvement by formatting the javascript code in html event handlers. I picked the comprehensive event handlers list from XSS Attacks Book by RSnake, Jeremiah, Pdp, Anton Rager and Seth Fogie. Another excellent book to have on your shelf.

Example of Event Handler Code Formatting (see the onload and onclick event handlers)

And finally the …

Inferno’s All-In-One HTML + Javascript + CSS Formatter
Paste your Source Code below

I would advise trying any of the search engines’ source code like google, yahoo, etc. Their code is highly compressed. If you have any problem using the text box above, try using this Link.

Plans for future additions include
* Add custom event handlers and variables (e.g. expr variable in Samy Worm Code)
* Javascript Deobfuscation
* More configuration Options
* Burp Proxy Plugin

Please provide your valuable suggestions to improve this tool. This tool is completely free for your use.

In Billy’s Blog, two solutions have been discussed :-

Solution 1. Update to the latest version of JRE. This will protect you. However, if I am a web application writer, I cannot ensure that my customers will be protected. The reason is I cannot control the JRE version that my customers will be running on their client machines. The JRE updates don’t work like Windows Updates. So their obsolete JRE environments will not get automatically updated, which leaves them vulnerable to cross-domain exploits. So, Billy discusses another solution for the application writer.

Solution 2. Serve user controlled files from a “throw away” domain. However, having a separate domain might not be feasible at all times, for reasons such as cost, management issues, etc.

My Solution. This made me think of some solution that could help an application developer to filter malicious jar content on the server side. If the application is able to restrict the upload of malicious files, it solves the problem on the server side without worrying about which version of JRE the client is running. I found the api JarFile in Java library java.util.jar to be extremely useful. It takes as input a file parameter, and returns a JarFile object if the input file has jar content. Otherwise, it raises a java.util.zip.ZipException exception.

I have constructed Proof of Concept code that tests a input file for malicious jar content.

import java.io.*;
import java.util.*;
import java.util.jar.*;

public class DetectGIFAR {
    public static void main (String args[])
         throws IOException {

		if(args.length != 1)
		{
			System.out.println("Usage: java DetectGIFAR image_file");
			System.exit(1);
		}

		try
		{
			JarFile jarFile = new JarFile(args[0]);
			System.out.println("This is a malicious image with embedded jar content.\nFollowing are the contents:-");
			Enumeration jarenum = jarFile.entries();
			while (jarenum.hasMoreElements()) {
				JarEntry jarent = (JarEntry) jarenum.nextElement();
				System.out.println(jarent.getName() + ", " + jarent.getSize() + " bytes");
			}
		}
		catch(java.util.zip.ZipException e)
		{
			System.out.println("This is a benign image file. No jar content detected.");
			System.exit(0);
		}
		catch (Exception e)
		{
			System.out.println("Error occured. Unable to process GIFAR contents.");
		}
	}
}

DetectGIFAR.java, DetectGIFAR.class, titanic.gif, evil.gif

Below is sample output

And if you are new to the GIFAR exploit, below is example html applet code that loads a malicious gif hosted on my domain. You need to have the vulnerable JRE 1.6 update 10 or lower to see this applet running. You can play with this applet by typing anywhere inside it .

Let me know your thoughts and opinions on this server side fix. I am always open for discussions.