AFFECTED PRODUCTS
——————–
Safari <10.0.1 on MAC

 

DESCRIPTION
——————–
Safari Plugins view page have multiple(MIME Type、Description、Extensions) Stored XSS Vulnerabilities。

This page is a local file:

When user has installed evil-plugins , and open Safari -> Help menu -> installed plugins to view Plug-ins information may suffer UXSS attack。

 

PoC
——————–
Attackers publish malicious plug-ins. In XCODE, set info.plist, inject malicious code.

The content of info.plist

Copy the Plugin into “~/Library/Internet Plug-Ins”。Restart Safari, it will work.Open Safari -> Help menu -> installed plugins to view Plug-ins information.

Steal user passwd file POC:

 

UXSS POC:

 

Discloure Timeline

——————–

2016/7/27 Provide vulnerability detail to APPLE via product-security@apple.com

2016/10/24 Apple fix it in Safari 10.0.1

2016/11/18 Apple Reply:No CVE was issued because this issue required the precondition that the user install a malicious plug-in.

I reported the vulnerability to the APPLE in February 1, 2016 , The vulnerabilities are discussed in this article have been fixed. I think this is a very interesting logical bug, which makes the smart search bar becoming dangerous!

 

AFFECTED PRODUCTS

——————–

User Agent:

Mozilla/5.0 (iPhone; CPU iPhone OS 9_3 like Mac OS X) AppleWebKit/ 601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13E5191d Safari/601.1

DESCRIPTION

——————–

In the Safari browser for IOS, the addressbar and the smart search bar are combined together, in the settings of the Safari can choose the default search engine: such as YAHOO, Google, Bing, Baidu, DuckDuckGo……. when searching for a URL in the default search engine,the URL will be displayed on the Omnibox. According to this characteristic, if the search engine has XSS, an attacker can make a arbitrary URL in the addressbar ,and change the page’s content to spoofing attack.

PoC

——————–

Testing environment:

1, set the default search engine for Baidu

2, IPhone/IPAD

(1) Safari search in IPhone

POC:

search_spoof_1

(2) Safari search in IPAD

POC:

search_spoof_2

 

(3) Addressbar Spoofing Attacks with Search Engines

If the search engine has XSS, an attacker can make a arbitrary URL in the addressbar ,and change the page’s content to spoofing attack.Here I found a Baidu search engine XSS to prove the spoofing attack.

POC:

search_spoof_3

Online DEMO: http://xisigr.com/test/spoof/safari/url20165055483693fb8543.html

FIXED

——————–

Found a XSS in search engines of “Google, YAHOO, Bing……” is very hard. So APPLE repair scheme is to add the search mark in Smart Search bar.

search_spoof_4

CREDIT

——————–

This vulnerability was discovered by xisigr of Tencent’s Xuanwu Lab

(http://www.tencent.com).

Email:xisigr@gmail.com

0x00 Vulnerability Overview

Address Bar URL spoofing on IOS Chrome (CVE-2016-1707), I report the vulnerability to Google in June 2016. Spoofing URL vulnerability can be forged a legitimate Web site address. Attacker can exploit this vulnerability to launch phishing attack .

Affected version: Chrome < v52.0.2743.82,IOS < v10

0x01 Vulnerability Details

chrome_spoof_3

POC:

How the vulnerability happened? First click on the ‘click me’ link, The browser opens a new window called aaaa, this page loads the “https://hack.com::”, this address can be casually write. Continue running Pwned () after 500 microseconds , open the ‘https://www.gmail.com’  in the aaaa window, of course, this URL can be empty. Up to now, all the code is running well, and the next code is the core code to trigger the vulnerability.

Begin loading ‘https://gmail.com::’ in aaaa window , happying, Chrome allows to load ‘https://gmail.com::’, and then chrome address as a pending entry. Because ‘https://gmail.com::’ is an invalid address, i think Chrome should jump to about:blank, but chrome commits pending entry (‘https://gmail.com::’) and promotes it as a last committed URL. At this point, the entire loading process is completed. A perfect Spoofing URL vulnerability was born.

Online demo:

http://xisigr.com/test/spoof/chrome/1.html

http://xisigr.com/test/spoof/chrome/2.html

0x02 Fixed

[IOS] Do not commit invalid URLs during web load.

0x03 Discloure Timeline

2016/6/22  Report to Googlehttps://bugs.chromium.org/

2016/6/22  Google assignedSecurity_Severity-High

2016/7/14  Google  reward $3000

2016/7/20  Google advisory disclosedCVE-2016-1707

2016/10/2  Google allpublic disclosed

0x04 References

(1) https://googlechromereleases.blogspot.com/2016/07/stable-channel-update.html

(2) https://bugs.chromium.org/p/chromium/issues/detail?id=622183

(3) https://chromium.googlesource.com/chromium/src/+/5967e8c0fe0b1e11cc09d6c88304ec504e909fd5

CSS Handling Status Bar Spoofing, I found this interesting vulnerability 5 years ago, and now it still exists.When the key UI module of the browser can be controled by the user , I think it is dangerous,such as the orgin of the dialog box, etc..Of course the status bar of the browser is different from the traditional browser URL spoof,it is more like a logical error in design,which led to the attacker can use CSS to draw a exactly the same status bar.Although it’s not as serious as you think about it.But I still stick to my point of view, when an attacker can control the UI module of the browser , the phishing attack may happen at any time.

Now you can try CSS Handling Status Bar Spoofing 

References:
Microsoft Internet Explorer CSS Handling Status Bar Spoofing Vulnerability
http://www.securityfocus.com/bid/47547
Google Chrome CSS Handling Status Bar Spoofing Vulnerability
http://www.securityfocus.com/bid/47548
Mozilla Firefox CSS Handling Status Bar Spoofing Vulnerability
http://www.securityfocus.com/bid/47549

Vulnerability Details:

Fixed on Firefox44.0

(1) In the notification dialog, no originates hints and warnings.The attacker can then display a malicious notification dialog to the user that seemingly originates from the trusted site. Typically this notification dialog would mimic the legitimate site. An attacker may exploit this vulnerability to spoof an interface of a trusted web site.

Origin Spoof Demo:http://xisigr.com/test/notification/1.html

 

(2)Web Notification will be fully displayed, resulting in full screen display notification dialog to denial of service attack.

FullScreen Display DOS Demo:http://xisigr.com/test/notification/2.html

References:

https://bugzilla.mozilla.org/show_bug.cgi?id=1220519

CREDIT:
This vulnerability was discovered by xisigr of Tencent’s Xuanwu LAB(http://www.tencent.com).
Email:xisigr@gmail.com