Posts Tagged ‘Safari’

Using Blended Browser Threats involving Chrome to steal files on your computer

Thursday, November 5th, 2009

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

SECURETHOUGHTS.COM ADVISORY
- CVE-ID : CVE-2009-3931 (Chrome)
- Release Date : November 05, 2009
- CVSS Severity : 9.3 (High)
- Discovered by : Inferno

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

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

Chrome File Downloader Exploit - Steal Local Files with help from IE6

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

Chrome File Downloader Exploit - Steal Local Files with help from Safari

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

Chrome File Downloader Exploit - Push Por_ographic Image

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.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Browsers, Exploits, WebAppSec | 3 Comments »

Hijacking Safari 4 Top Sites with Phish Bombs

Tuesday, August 11th, 2009


Music: Bomfunk MC’s – Super Electric

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.

Apple Safari 4 Top Sites Spoofing

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.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , ,
Posted in Browsers, Exploits, Phishing | 7 Comments »

Phishing with URL Obfuscation continues in Safari 4

Wednesday, June 17th, 2009

Well it is hard to believe, but the new version of Apple’s browser “Safari 4” still continues to be vulnerable to URL obfuscation techniques. All other browser vendors, whether it is Internet Explorer, Firefox, Opera or Chrome, have fixed this issue long time ago. However, everyone had fixed this issue using completely different solutions, which brings up the question that shouldn’t they follow a common standard ??

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



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.

Url Obfuscation with Safari


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.

Url Obfuscation with Opera


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.

Url Obfuscation with Chrome


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.

Url Obfuscation with Internet Explorer


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.

Url Obfuscation with Firefox


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.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Browsers, Exploits, Phishing, WebAppSec | 10 Comments »