The Sys-Security Group
Security Advisory
More Vulnerabilities with
Pingtel xpressa SIP-based IP Phones
How one can exploit vulnerabilities
with MyPingtel Portal to subvert a VoIP infrastructure which includes IP Phones
and/or softphones from Pingtel
Founder
The Sys-Security Group
Abstract
The following advisory lists several severe vulnerabilities
with Pingtel’s MyPingtel Portal and Pingtel’s SIP-based IP Phones and
Softphones which leads to the complete control of a user’s credentials to the
VoIP network resulting in “Call Hijacking”, “Registration Hijacking”, and total
subversion of a user’s settings for the VoIP network
Contents
2.1 What is Voice over IP (VoIP)?
2.2 What is the Session Initiation Protocol (SIP)?
2.3 Introduction to the SIP Registration Process
3.1 Predictable Parameter Values with SIP REGISTER
requests sent from Pingtel’s
3.2 Compromising VoIP infrastructure using the MyPingtel
Portal
3.2.1 E.T. Phones Home – Information Leakage leading to
the compromise of
3.2.2 E.T. Get’s a Call – Information Leakage leading to
the compromise of the
3.2.2.1 Username and password enumeration using the http://my.pingtel.com
3.2.2.2 What a successful authentication can bring…
3.4.1 Availability – Random Reboots of the IP Phone
3.4.2 No verification of downloaded software
3.4.3 User Enumeration by Physically Accessing the Phone
3.4.4 Hard coded usernames and passwords within web pages
served with MyPingtel Portal
Figure
List
Figure 1:
Registration request to my.pingtel.com
Figure 2:
Ethereal Capture of “E.T. Phones Home”
Figure 3:
http://my.pingtel.com Sign-in page
Figure 4:
username and password enumeration made easy
Figure 5: What’s
the username used?
Figure 6: Hard
Coded username and password, as well as the IP Phone’s IP Address
1.0 Introduction
Pingtel (http://www.pingtel.com) develops intelligent Java-based voice-over-IP phones and softphones for service providers and enterprises. Using the vulnerabilities enumerated within this advisory it is possible to jeopardize critical telephony infrastructure based on Pingtel’s xpressa SIP-based IP phones and softphones. Additionally, certain vulnerabilities allow an attacker to take complete control over an IP Phone or a softphone node either directly or by circumventing other SIP entities on the network by abusing the ‘node’s credentials’. The most severe issue discussed is the way an attacker can exploit vulnerabilities with MyPingtel portal (http://my.pingtel.com) to subvert a VoIP infrastructure which includes IP Phones and/or softphones from Pingtel.
2.0 Background
Information
2.1
What is Voice over IP (VoIP)?
IP Telephony is a technology in which IP networks are being
used as the medium to transmit both data and voice packets. VoIP (Voice over
IP) describes a scenario were managed IP networks are being used as the
medium to carry both data and voice packet. VON (Voice On the Net) or Internet
Telephony describes the scenario were the Internet is being the medium
used to transport the data and voice packets.
Any IP Telephony solution
must be combined from several protocols:
- Signaling Protocols, which are responsible
for:
§
Locating
a User – The ability to locate another user which whom a user wish to
communicate with
§
Session
Establishment – The ability of the called party to accept a call, reject a
call, or redirect the call to another location or service
§
Session
Setup Negotiation – The ability of the communicating parties to negotiate the
set of parameters to use during the session, this includes, but not limited to,
audio encoding, sampling rates, etc.
§
Modify
a Session – The ability to change a session’s parameters such as using different
audio encoding, adding/removing a session participant, etc.
§
Teardown
a Sessions – The ability to end a session
- Media Transport Protocols, which are responsible
for the digitization, encoding (and decoding), packing, reception, and
ordering of voice samples.
2.2
What is the Session Initiation Protocol (SIP)?
The Session Initiation
Protocol (SIP), described in RFC 3261[1],
is an application-based control protocol used to create and manage real-time
multimedia sessions. While SIP is a framework for managing sessions, it is
using other protocols to negotiate the parameters for the multimedia sessions
it is setting.
SIP supports several
facets of establishing, managing and terminating multimedia sessions which are
essential with any session management protocol.
As such SIP is being used
for IP Telephony signaling, and for Internet conferencing.
SIP is modeled after HTTP
(and draws some similarities with SMTP) and is based on a client-server
architecture.
2.2.1 SIP
Components
SIP has two main
components: UAs (User Agents) and network servers. A SIP endpoint, or a UA, is
able to send and receive SIP requests. Therefore a UA is combined from two
components: a UAC (client part, User Agent Client) and a UAS (server part, User
Agent Server). While the UAC is used to initiate SIP requests the UAS component
is able to handle incoming SIP requests and to send appropriate responses.
The SIP network servers
provide name resolution and user location services. Although their logical roles
are different, they might be co-located on the same physical machine:
- SIP Proxy
- SIP Redirect
- SIP Registrar
A SIP Proxy Server
acts on behalf of SIP UACs to facilitate the session establishment. A SIP Proxy
is able to relay call signaling to another SIP server, to “fork” a request to
multiple targets, maintain a “call state”, and other.
A SIP Redirect Server
receives SIP requests and redirects them to another SIP server. The SIP
Redirect server’s operation is somewhat like the operation of a non-recursive
DNS server.
A SIP Registrar Server
receives SIP REGISTER requests which are binding requests for a user’s “call
sign” (a SIP URI[2])
to its current location (a hostname, an IP address, etc.). The SIP Registrar is
a front-end to a database, also referred as a location server or a location
service in which the bindings are stored. When a SIP Proxy server or a SIP
Redirect server will have to route a SIP request to a user they will consult
the location service for the user’s current binding. Using the information
received from the location service, a SIP Proxy or a Redirect server should be
able to route the SIP request (or provide routing information) to its
appropriate destination.
2.3
Introduction to the SIP Registration Process
A SIP REGISTER request
associates a SIP or a SIPS URI with a SIP-enabled device a user is currently
using. Usually a SIP REGISTER request will be sent from a UA to a SIP Registrar
server, which is a special type of a UAS only receiving SIP REGISTER requests,
when the UA boot-up and on certain time intervals. Third parties are also able
to send SIP REGISTER requests on behalf of other users as RFC 3261 states. The
SIP (or SIPS) URI to machine binding (with the machine’s name, and/or with its
IP address) will be written by the SIP Registrar to a database, also referred
to as a location server or a location service, which the SIP
Registrar is a front-end to. When a SIP Proxy server or a SIP Redirect server
will have to route a SIP request to a user within their domain they will
consult the location service for the domain for the user’s current binding.
Using the information received from the location service, a SIP Proxy or a
Redirect server should be able to route the SIP request (or provide routing
information) to its appropriate destination.
Figure 1: An Abstract Registration
Process
SIP REGISTER requests are
able to create, add, remove, and query bindings. If no binding exists for the
particular SIP or SIPS URI represented in the SIP REGISTER request a new entry
will be created in the location service records. A SIP REGISTER request can
remove existing binding as well as add extra binding to an existing entry. With
all operations, a successful response will carry all current bindings for the
particular SIP or SIPS URI which is being created, or modified.
The next example is a SIP
registration request sent from bob@biloxy.com to its SIP Registrar server at
registrar.biloxy.com:
REGISTER
sip:registrar.biloxi.com SIP/2.0
Via:
SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards:
70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length:
0
The following headers must
be presented with each SIP REGISTER request:
- The Request-URI (REGISTER sip:registrar.biloxi.com
SIP/2.0)
contains the domain name the
registration request is for (in the example above it is biloxy.com)
- The ‘To’ header contains the SIP or
SIPS URI in which this registration request should create, add-to, remove,
or query an entry in the location service (in the example above it is for sip:bob@biloxy.com)
- The ‘From’ header contains the SIP or
SIPS URI of the person performing the registration (in the example above
this it is sip:bob@biloxy.com)
- The ’Call-ID’ header value contains a
unique identification number. With each future request aimed at updating
the binding created by this request the ’Call-ID’ header value must
be the same (in the example above the ‘Call-ID’ value is 843817637684230@998sdasdh09)
- The ‘Cseq’ header value acts as a
classical sequence number to identify and order transactions (in the
example above the ‘Cseq’ value is 1826)
- The ‘Expires’ header value contains
the number of seconds this entry is valid for (in the example above the ‘Expires’
value is 7200 seconds, two hours).
The ’Contact’
header may be presented. It may contain a zero or more values
representing the address binding. With the example above it is the IP address 192.0.2.4.
The
following is the 200 OK response sent from registrar.biloxy.com to
bob@biloxy.com, acknowledging his registration:
SIP/2.0
200 OK
Via:
SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To:
Bob <sip:bob@biloxi.com>
From:
Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires:
7200
Content-Length:
0
The ‘Contact’
header within the reply lists the current bindings for sip:bob@biloxy.com which is sip:bob@192.0.2.4, an IP address which represents a SIP-enabled device bob is using.
With any SIP REGISTER message there are a number of parameter
values which control the affect of the SIP REGISTRAR request. Several rules
were defined:
- For each binding listed with a SIP REGISTER
request the SIP Registrar will search its records to find a matching entry
with the location service database.
- No Match Found – If no match is found the SIP
Registrar will create a new binding also recording the ‘Call-ID’
and the ‘CSeq’ values of the SIP REGISTER request.
- Match Found – If the binding does exist
within the location service records, the SIP Registrar will examine the ‘Call-ID’
values of the SIP REGISTER request and the binding entry. If the ‘Call-ID’
values differ, the SIP Registrar needs to examine the expiration time for
the stored binding, if it is zero the SIP Registrar must remove the
binding and store the binding from the SIP REGISTER request, if the
expiration time is different than zero than this request updates the
current entry with another set of binding.
- If the ‘Call-ID’ value is the same
with the SIP REGISTER request and with the stored binding the SIP Registrar
will inspect the ‘CSeq’ values of the SIP REGISTER request and the
stored binding. Only if the ‘CSeq’ value of the SIP REGISTER
request is higher than the ‘CSeq’ value of the stored binding the SIP
Registrar will either update or remove (if the expiration time interval
reached zero) the current stored binding with the binding with the SIP REGISTER
request. If the ‘CSeq’ value of the SIP REGISTER request is lower
than the one stored with the binding the update must be aborted and
the SIP REGISTER request will fail.
3.0 The Vulnerabilities
3.1
Predictable Parameter Values with SIP REGISTER requests sent from Pingtel’s IP Phones
The following is a SIP REGISTER request sent from a Pingtel
SIP-based IP Phone to a SIP Registrar SERVER:
REGISTER sip:192.168.1.57 SIP/2.0
To: sip:carol@192.168.1.57
From: sip:carol@192.168.1.57;tag=456248
Call-ID: 8-reg@192.168.1.59
CSeq: 1 REGISTER
Contact: sip:carol@192.168.1.59
Expires: 3600
Content-Length: 0
Accept-Language: en
Supported: sip-cc, sip-cc-01, timer
User-Agent: Pingtel/1.2.6 (VxWorks)
Via: SIP/2.0/UDP 192.168.1.59
The values required to subvert a registration which are used by
the request are all predictable. The ‘Call-ID’ is fixed (with another Pingtel
IP phones it was always fixed to ‘9-reg@myIP’),
the sequence number sent is 1 (so setting it to any higher number would be
sufficient), the ‘To’ and ‘From’ SIP URIs are also predictable
allowing a remote attacker to circumvent the SIP Registrar and write any
bindings to the location service remotely (if no authentication is required).
Although authentication will be required in some cases, requiring
the attacker to have the right credentials for the user before having the
ability to circumvent the SIP Registrar and to write false records into the
location service, there are a number of ways to extract the username and
password from a Pingtel SIP-based IP phone, some outlined in this advisory some
in other[3].
3.2
Compromising VoIP infrastructure using the MyPingtel Portal
MyPingtel is a Portal (http://my.pingtel.com)
for one to use and manage his Pingtel xpressa softphone or IP phone. The
MyPingtel web site can be used to:
“Learn about new applications and
services and install them from your PC. Create and manage your speed dial phone
book using the PC keyboard. Set your call handling preferences for call
forwarding when you're away from the phone and on the phone. Get tips and
online help for using your phone. Stay current with news from Pingtel…”
In order to use the application/Portal, a user needs to register
his Pingtel xpressa SIP-based IP phone with the MyPingtel Portal. This is done
in two stages: A user needs to register to Pingtel’s Portal, and than the user
needs to register his IP phone (physically accessing the IP phone) using the details
(and credentials) he supplied when registering with Pingtel’s Portal.
This first stage is simply accomplished by browsing to http://my.pingtel.com and filling the
required registration form[4].
Figure 1: Registration
request to my.
The user’s credentials
supplied to Pingtel’s Portal with the registration process must be a valid
username and password that allows the registering user to login to his IP phone
via the web server interface of his IP Phone.
The next step would be to use the MyPingtel Sign-In application,
which is supplied by default with Pingtel’s IP phone and softphone, to register
the IP phone, physically accessing the phone. This is simply done by pressing:
More 
MyPingtel Sign-In Next [Enter your username] [Enter your password] OK [Enter Admin Password]
[Enter Phone Name] Next OK
A message will be displayed confirming the registration[5].
3.2.1 E.T. Phones
Home – Information Leakage leading to the compromise of the IP Phone
When the IP phone (or softphone) boot-up, the IP phone will send
all registration information to Pingtel’s MyPingtel Portal (http://my.pingtel.com) utilizing the HTTP
protocol. The information sent to Pingtel’s Portal will include the following:
§
Admin name in clear
text
§
Admin Password in MD5
hash
§
Mac Address in clear
text
§
Physical Password in MD5
hash
§
Admin Domain in clear
text
§
IP Address of the IP
phone in clear text
§
Web Server Port
in clear text
§
And other information
Figure 2: Ethereal Capture of “E.T. Phones Home”
Any malicious party able to extract this information from the wire
(upstream to Pingtel, local network to the phone, intermediate network, etc.)
will have the ability to brute force the user’s password offline. This might be
done utilizing the same hashing/crypto algorithm used. A malicious party might
choose to actively brute force the password either against the IP phone’s web
server or utilizing Pingtel’s Portal.
The value of the information is even greater when the IP address
of the IP phone is routable from the Internet. This will allow a remote
attacker to connect to the IP phone’s web server remotely (the web server
access is required for the operation of MyPingtel Portal) either directly or
through MyPingtel Portal using the credentials he extracted.
Although administrator access is needed to circumvent some of the IP
phone’s features (the username is “admin” and the out-of-the-box
password is clear) having a valid username and password would allow a malicious
party to circumvent the “Call Handling” features of the IP phone, such as the
various “Call Forwarding” features[6].
3.2.2 E.T. Get’s
a Call – Information Leakage leading to the compromise of the IP Phone
To use Pingtel’s Portal one needs to supply his username and
password. The web page is composed of 2 parts. The left part contains a login
page which is using HTTP over SSL (HTTPS), where the right part of the page is
simply a list of application and other miscellaneous pieces of information.