Openfire multiple vulnerabilities

2009-01-08 / 2009-01-09
Credit: CORE
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-79
CWE-22

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

Referencje:

https://bugs.gentoo.org/show_bug.cgi?id=254309
http://xforce.iss.net/xforce/xfdb/47845
http://xforce.iss.net/xforce/xfdb/47835
http://xforce.iss.net/xforce/xfdb/47834
http://www.securityfocus.com/bid/32944
http://www.securityfocus.com/bid/32943
http://www.securityfocus.com/bid/32940
http://www.securityfocus.com/bid/32939
http://www.securityfocus.com/bid/32938
http://www.securityfocus.com/bid/32937
http://www.securityfocus.com/bid/32935
http://www.securityfocus.com/archive/1/archive/1/499880/100/0/threaded
http://www.igniterealtime.org/issues/browse/JM-1506
http://www.coresecurity.com/content/openfire-multiple-vulnerabilities
http://secunia.com/advisories/33452


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top