Openfire Multiple Vulnerabilities

Advisory ID Internal
CORE-2008-1128

1. Advisory Information

Title: Openfire multiple vulnerabilities
Advisory ID: CORE-2008-1128
Advisory URL: https://www.coresecurity.com/core-labs/advisories/openfire-multiple-vulnerabilities
Date published: 2009-01-08
Date of last update: 2009-01-07
Vendors contacted: Jive Software
Release mode: Coordinated release

2. Vulnerability Information

Class: Cross site scripting (XSS)
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 32935, 32937, 32938, 32939, 32940, 32943, 32944, 32945
CVE Name: N/A

3. Vulnerability Description

Openfire is a real time collaboration (RTC) server licensed under the Open Source GPL. It uses the widely adopted open protocol for instant messaging XMPP, also called Jabber. Multiple cross-site scripting vulnerabilities have been found, which may lead to arbitrary remote code execution on the server running the application due to unauthorized upload of Java plugin code.

4. Vulnerable Packages

  • Openfire 3.6.2

5. Non-Vulnerable Packages

  • Openfire 3.6.3

6. Vendor Information, Solutions and Workarounds

A fixed version of Openfire is available through their community web site [1].

7. Credits

These vulnerabilities were discovered and researched by Federico Muttis, from CORE IMPACT's Exploit Writing Team (EWT), Core Security Technologies.

8. Technical Description / Proof of Concept Code

Multiple cross-site scripting vulnerabilities have been found in Openfire, which may lead to arbitrary remote code execution on the server running Openfire server due to unauthorized upload of Java plugin code.

8.1. Reflected XSS Vulnerabilities

Several cross site scripting (XSS) were detected that lead to cross site request forgery (XSRF), which enable arbitrary remote code execution on the server running the application. These vulnerabilities are network exploitable but the victim must voluntarily interact with the attack mechanism. The victim must be an authorized user to deploy the complete attack.

We identified insufficient sanitization of several parameters in several scripts. In the case of logviewer.jsp (BID 32935), group-summary.jsp (BID 32937), user-properties.jsp (BID 32938) and audit-policy.jsp (BID 32939) there is no sanitization at all. In log.jsp (BID 32940) there is a filter against <script>, which is not enough, because several other XSS vectors exist, like the one we show below.

Proof of Concept alert() exploits follow.

[BID 32935] Insufficient sanitization in logviewer.jsp, parameter log:

http://vulnsite.com/logviewer.jsp?clearLog=false&emailLog=false&lines=&log=%22/%3E%3Cscript%3Ealert(%27xss%27)%3C/script%3E%3C!--&markLog=false&mode=desc&refresh=&saveLog=false

 

[BID 32937] Insufficient sanitization in group-summary.jsp, parameter search:

http://vulnsite.com/group-summary.jsp?search=%22%3E%3Cscript%3Ealert('xss')%3C/script%3E<!--

 

[BID 32938] Insufficient sanitization in user-properties.jsp, parameter username:

http://vulnsite.com/user-properties.jsp?username=%3Cscript%3Ealert(%27xss%27)%3C/script%3E

 

[BID 32939] Insufficient sanitization in audit-policy.jsp, the vulnerable parameters are: logDir, logTimeout, maxDays, maxFileSize and maxTotalSize.

http://vulnsite.com/audit-policy.jsp?maxTotalSize=%22%3E%3Cscript%3Ealert(%27xss%27)%3C/script%3E%3C!--&update=Save%20Settings

 

[BID 32940] Insufficient sanitization in log.jsp, <script> gets filtered out but vectors like <img> still work:

http://vulnsite.com/log.jsp?log=%3Cimg%20src=%27%27%20onerror=%27javascript:alert(%22xss%22)%27%3E

 

8.2. Arbitrary Remote Code Execution

Once the Openfire administrator's browser is executing arbitrary Javascript and his/her session cookies have been stolen, it is trivial to execute arbitrary code as there is no need to re-authenticate to upload a new server plugin. Secure web applications generally re-authenticate the administrator when performing such sensitive tasks. In this case, however, you can simply upload a new plugin, without re-authentication, with arbitrary Java code on the constructor. The constructor will be called when the plugin is uploaded.

In order to create a potentially malicious plugin that executes arbitrary Java code on the context of the server, you need to download the Openfire source [2] and the apache ant tool [3]. Uncompress the Openfire source and install the ant tool. You can modify any existing plugin, add this code and call it from the constructor:

public void start() { try { Runtime.getRuntime().exec("C:\\WINDOWS\\system32\\calc.exe"); } catch (Exception ex) { ex.printStackTrace(); } }

Then navigate to Openfire source build/ directory and execute ant plugins, this will build all the plugins. You'll end up with a new file work/plugins/yourplugin.jar which is now infected.

8.3. Stored XSS Vulnerabilities

[BID 32943] The page server-properties.jsp displays the properties without sanitization, an exploit triggered via a reflected XSS vulnerability could add a new property with a name like "><script>alert(/xss/.source)</script>, which will be triggered every time the administrator uses the server-properties.jsp or security-audit-viewer.jsp.

[BID 32944] The page muc-room-summary.jsp displays properties edited in muc-room-edit-form.jsp, for example, room name <script>alert('xss')</script>.

These vulnerabilities can be used to ensure the persistence of any attack.

8.4. Directory traversal

[BID 32945] Insufficient validation in log.jsp allows remote attackers to read any .log file that the user running Openfire has access to. The vulnerable code located in log.jsp is the following:

File logDir = new File(Log.getLogDirectory()); String filename = (new StringBuilder()).append(log).append(".log").toString(); File logFile = new File(logDir, filename);

 

Proof of Concept:

log.jsp?log=..\..\..\windows\debug\netsetup

The string .log will be appended to the filename, so this attack only works to read .log files,

9. Report Timeline

  • 2008-12-04: Core notifies the vendor that vulnerabilities were found and that an advisory draft is available. Publication scheduled for December 15th.
  • 2008-12-04: Vendor acknowledges and asks for a copy of the advisory's draft.
  • 2008-12-04: Core sends the vendor a copy of the advisory's draft.
  • 2008-12-04: Vendor acknowledges and requests to uphold the publication of the advisory until the end of January.
  • 2008-12-04: Core reschedules the publication for January 27th and requests a more precise estimate, when available.
  • 2008-12-04: Vendor acknowledges the new publication schedule for the advisory.
  • 2008-12-17: Core requests updated information on the patches.
  • 2008-12-17: Vendor informs that the vulnerabilities have been patched and that they are ready to release patches the following week.
  • 2008-12-17: Core insists that advisories are published simultaneously with the patched software releases.
  • 2008-12-17: Vendor asks if the advisory will include complete information on how to possibly exploit the bugs.
  • 2008-12-17: Core confirms the vendor that the advisory will include the complete analysis and all the information available to reproduce the bugs, giving the users the ability to assess the impact of the vulnerabilities.
  • 2008-12-17: Vendor suggests January 8th, 2009, as the coordinated release date and requests the future URL of the advisory.
  • 2008-12-17: Core says that January 8th, 2009, is an adequate date for advisory publication.
  • 2008-12-22: Core sends the vendor the URL where the advisory will be published.
  • 2008-12-29: Core requests the patched product version number and confirmation that patches will be published on January 8th 2009.
  • 2008-12-29: Vendor confirms publication date and patched version number.
  • 2009-01-08: Core publishes advisory CORE-2008-1128.

10. References

[1] Openfire http://www.igniterealtime.org/projects/openfire/
[2] Openfire 3.6.2 source http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_src_3_6_2.zip
[3] Apache Ant http://ant.apache.org/

10. About CoreLabs

CoreLabs, the research center of Core Security, A Fortra Company is charged with researching and understanding security trends as well as anticipating the future requirements of information security technologies. CoreLabs studies cybersecurity trends, focusing on problem formalization, identification of vulnerabilities, novel solutions, and prototypes for new technologies. The team is comprised of seasoned researchers who regularly discover and discloses vulnerabilities, informing product owners in order to ensure a fix can be released efficiently, and that customers are informed as soon as possible. CoreLabs regularly publishes security advisories, technical papers, project information, and shared software tools for public use at https://www.coresecurity.com/core-labs.  

11. About Core Security, A Fortra Company

Core Security, a Fortra Company, provides organizations with critical, actionable insight about who, how, and what is vulnerable in their IT environment. With our layered security approach and robust threat-aware, identity & access, network security, and vulnerability management solutions, security teams can efficiently manage security risks across the enterprise. Learn more at www.coresecurity.com.

Core Security is headquartered in the USA with offices and operations in South America, Europe, Middle East and Asia. To learn more, contact Core Security at (678) 304-4500 or [email protected].

12. Disclaimer

The contents of this advisory are copyright (c) 2009 Core Security Technologies and (c) 2009 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

14. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team.