5060 - SIP

Overview

Session Initiation Protocol (SIP) is a signalling protocol commonly used for Voice over IP (VoIP) communications. SIP is responsible for establishing, modifying and terminating communication sessions, while the actual voice traffic is normally carried separately using protocols such as RTP.

During an infrastructure penetration test we may discover SIP services exposed by PBXs, VoIP gateways, call management systems or individual phones.

SIP commonly uses:

1
5060    SIP over UDP/TCP
2
5061    SIP over TLS

Port 5060 shouldn’t be treated as the only place SIP can exist. VoIP systems can be configured to listen on different ports, and we may encounter multiple SIP services within the same environment.

Once a SIP service has been identified, we want to determine what it is, which SIP methods it supports, whether users or extensions can be enumerated, how authentication is configured and what information the service exposes.

Identifying SIP

The first step is normally confirming that the discovered service is actually SIP.

Nmap service detection can provide a quick starting point. You can find a comprehensive Nmap cheat sheet here.

1
nmap -sU -sV -p 5060 <target>

Because SIP can use both UDP and TCP, it is worth checking both transports where appropriate:

1
nmap -sU -sS -p 5060,5061 <target>

A SIP response may expose useful information in headers such as:

1
Server
2
User-Agent
3
Allow
4
Contact
5
Via
6
From
7
To
8
Call-ID

Depending on the implementation, these may reveal the PBX or SIP software in use, internal hostnames, IP addresses or supported functionality.

That information can then be used to guide the rest of the assessment.

SIP Methods

SIP works using request methods in a similar way to how HTTP has methods such as GET and POST.

Common SIP methods include:

1
OPTIONS
2
REGISTER
3
INVITE
4
ACK
5
BYE
6
CANCEL
7
SUBSCRIBE
8
NOTIFY
9
MESSAGE
10
INFO

We don’t necessarily expect every SIP server to support every method.

For example, REGISTER is used by SIP clients to register their current location with a registrar, while INVITE is used to initiate a session.

OPTIONS is particularly useful during reconnaissance because it can be used to query the capabilities of a SIP endpoint without attempting to establish a call.

SIPVicious

SIPVicious is a collection of tools designed for auditing SIP-based VoIP systems and can be found here https://github.com/enablesecurity/sipvicious.

The suite contains several useful utilities:

1
sipvicious_svmap --help
2
sipvicious_svcrack --help
3
sipvicious_svcrash --help
4
sipvicious_svwar --help
5
sipvicious_svreport --help

These tools perform different parts of the SIP assessment rather than being a single general-purpose scanner.

A rough breakdown is:

1
svmap       Discover SIP devices
2
svwar       Enumerate SIP extensions
3
svcrack     Audit SIP authentication
4
svreport    Manage/report SIPVicious results
5
svcrash     Respond to certain scans from older SIPVicious clients

For normal penetration testing, svmap, svwar and svcrack are generally the ones we’re most interested in.

Discovering SIP Devices with svmap

svmap can be used to identify SIP services within an address range.

For example:

1
sipvicious_svmap -p5060-5062 <target> -m OPTIONS

Here we are scanning ports 5060 through 5062 and sending an OPTIONS request to identify responsive SIP services.

A network range can also be assessed:

1
sipvicious_svmap 192.168.1.0/24

If we already know the target SIP port:

1
sipvicious_svmap -p5060 192.168.1.0/24

The objective isn’t simply to find port 5060 open. We want to identify which systems actually respond as SIP devices and what information those responses provide.

In a VoIP network we may identify:

1
PBX
2
SIP Proxy
3
SIP Registrar
4
VoIP Gateway
5
IP Phones
6
Softphones

Each can expose a different attack surface.

Nmap SIP Enumeration

Nmap also includes SIP-specific NSE scripts.

One useful starting point is identifying the methods supported by the server:

1
nmap -sU -p 5060 --script sip-methods <target>

The returned methods can provide a better idea of the functionality exposed by the SIP service.

This is useful alongside SIPVicious because it gives us another way of confirming and interrogating the service rather than relying on a single tool.

Extension Enumeration

Once a SIP server has been identified, one of the more interesting questions is whether valid SIP users or extensions can be enumerated.

A VoIP environment may contain extensions such as:

1
100
2
101
3
102
4
2001
5
2002
6
2003

These extensions effectively identify SIP accounts and can provide targets for further authorised authentication testing.

SIPVicious svwar can be used for extension enumeration.

Start by reviewing the available options:

1
sipvicious_svwar --help

The exact enumeration method and range should be selected according to the target system and engagement scope.

Nmap also provides sip-enum-users:

1
nmap -sU -p 5060 --script sip-enum-users <target>

By default the script tests extensions from 0 through 999.

We can specify a more appropriate range:

1
nmap -sU -p 5060 \
2
--script sip-enum-users \
3
--script-args 'sip-enum-users.minext=1000,sip-enum-users.maxext=9999' \
4
<target>

This can be particularly useful when the organisation follows a predictable extension numbering scheme.

Understanding SIP Responses

SIP response codes can reveal whether an extension exists.

Responses may include:

1
200    Request succeeded
2
401    Authentication required
3
403    Request understood but forbidden
4
404    User/resource not found
5
407    Proxy authentication required

The important part is not simply memorising these status codes.

We’re looking for differences in behaviour between valid and invalid extensions.

For example, if:

1
Extension 1234 → 401 Unauthorized
2
Extension 8372 → 404 Not Found

the server may be giving us enough information to distinguish valid extensions from invalid ones.

That becomes an account enumeration issue.

Nmap’s sip-enum-users performs this type of comparison automatically and even begins by testing a random extension to help identify false positives.

Authentication Testing

Once valid SIP extensions have been identified, the next question is how those accounts authenticate.

SIP commonly uses digest authentication rather than transmitting the password directly.

SIPVicious includes svcrack for authorised password auditing:

1
sipvicious_svcrack --help

Authentication testing should be performed carefully.

VoIP systems may have account lockout controls, rate limiting or monitoring in place, and a large authentication attack can generate considerable noise.

Rather than immediately throwing a huge password list at every extension, first determine:

• Which extensions are valid?
• Is authentication actually required?
• Are lockouts configured?
• Is rate limiting present?
• Are default or predictable credentials likely?
• Does the engagement permit password guessing?

If password auditing is appropriate, use a controlled password list and rate.

Nmap SIP Authentication Testing

Nmap also includes a sip-brute NSE script for SIP password auditing.

Before using it, remember that this is an intrusive test and should only be performed when password auditing is within scope.

Enumeration and authentication testing are separate stages.

Knowing that extension 1234 exists does not automatically justify attempting thousands of passwords against it.

SIP over TLS

SIP may also be protected using TLS, commonly on TCP/5061.

If port 5061 is exposed, inspect the TLS service as well:

1
nmap -sV -p 5061 <target>

The certificate itself may provide additional reconnaissance information such as:

1
Hostnames
2
Internal domain names
3
Organisation names
4
Certificate authority
5
Additional Subject Alternative Names

TLS protects SIP signalling while it is in transit, but it doesn’t automatically mean the overall VoIP implementation is secure.

Authentication, extension enumeration and access-control issues may still exist above the transport layer.

Information Disclosure

SIP responses can sometimes disclose much more information than expected.

While reviewing responses, look for:

1
Internal IP addresses
2
Internal hostnames
3
SIP domains
4
Software names
5
Software versions
6
Extension numbers
7
Usernames
8
PBX identifiers
9
Network topology information

For example, Via, Contact and routing-related headers may expose addressing information that wasn’t previously known.

This becomes particularly useful during an external assessment where a publicly exposed SIP gateway may unintentionally reveal information about the internal VoIP environment.

UDP and TCP

Don’t assume that testing UDP/5060 is enough.

SIP supports both UDP and TCP, and a target may behave differently depending on the transport being used.

If SIP has been identified, check:

1
nmap -sU -p 5060 <target>

as well as:

1
nmap -sT -p 5060 <target>

TLS SIP can then be investigated separately on TCP/5061.

This is especially important where an initial port scan only performed TCP scanning, as UDP SIP services can otherwise be missed completely.

SIP Exploitation with Metasploit

Once the SIP service and underlying product have been identified, it is worth checking whether the platform has any known vulnerabilities or relevant Metasploit modules.

Metasploit contains a number of SIP and VoIP-related auxiliary modules. Start by searching the installed framework:

1
msfconsole
2
search sip

You can narrow the search down further:

1
search type:auxiliary sip
2
search type:exploit sip
3
search cisco sip
4
search asterisk
5
search freepbx

Don’t search only for sip. Once we have fingerprinted the actual PBX, phone or gateway, searching for the vendor and product name will often produce more useful results.

SIP Extension Enumeration

Metasploit can also be used to enumerate SIP extensions:

1
use auxiliary/scanner/sip/enumerator
2
show options
3
set RHOSTS <target>
4
set RPORT 5060
5
run

This can provide another way of identifying valid extensions where the SIP server responds differently for existing and nonexistent users.

SIP OPTIONS Enumeration

The SIP OPTIONS method can be useful for identifying how a server responds and what functionality it advertises.

Metasploit modules vary between versions, so search the installed framework:

1
search sip

Then inspect anything relevant with:

1
info <module>
2
use <module>
3
show options

This is preferable to blindly copying module names from old write-ups because SIP modules can be added, renamed or removed between Metasploit versions.

Product-Specific Exploitation

SIP itself isn’t usually the thing we are trying to exploit. Once we have identified the underlying product, we should start looking at the PBX, SIP server, gateway or phone implementation.

For example, we may discover:

1
Asterisk
2
FreePBX
3
Cisco Unified Communications
4
3CX
5
Avaya
6
Grandstream
7
Yealink
8
Mitel
9
Kamailio
10
OpenSIPS

At this point, search Metasploit for the identified technology:

1
search asterisk
2
search freepbx
3
search cisco
4
search 3cx
5
search avaya

We should also take any disclosed version information and check it against known vulnerabilities.

For example:

1
SIP/2.0 200 OK
2
Server: Asterisk PBX 13.x

This gives us something much more useful to investigate than simply knowing UDP/5060 is open.

Testing Default Credentials

VoIP infrastructure is also worth checking for default credentials, particularly where we have discovered a web management interface alongside SIP.

For example, if scanning reveals:

1
80/tcp     HTTP
2
443/tcp    HTTPS
3
5060/udp   SIP

don’t treat these as unrelated services.

The HTTP interface may be the administrative interface for the same PBX, gateway or IP phone identified through SIP.

Check the exact product documentation for default credentials and test them where credential testing is within scope.

SIP INVITE Testing

INVITE requests can also reveal whether unauthenticated users are able to initiate calls or interact with extensions.

What Should We Look For?

Once SIP has been identified, some of the questions worth answering are:

• What SIP software or device is exposed?
• Which SIP methods are available?
• Can valid extensions be enumerated?
• Does the service respond differently for valid and invalid users?
• Is authentication required?
• Are default or weak credentials in use?
• Is password guessing rate limited?
• Are account lockouts configured?
• Is SIP exposed externally when it should only be internally accessible?
• Is signalling transmitted without TLS?
• Do SIP responses expose internal IP addresses or hostnames?
• Are software versions disclosed?
• Are unnecessary SIP methods available?
• Can unauthenticated users interact with functionality that should require authentication?

As with most services, simply finding SIP exposed isn’t automatically a vulnerability.

A properly configured SIP gateway obviously needs to speak SIP.

What matters is what the service allows an unauthenticated or low-privileged user to discover or perform.

SIP testing tends to become much easier once we stop thinking of TCP/UDP 5060 as simply another open port.

The useful information is in how the SIP server responds.

A few carefully selected OPTIONS and REGISTER requests can tell us far more about the environment than simply reporting that a SIP service is listening.