Skip to main content

sip enumerate extensions

Summary

Perform a SIP extension enumeration attack

What it does

Reproduce, detect and exploit the SIP extension enumeration security issue. The tool goes beyond the very basics of the attack, allowing testers to probe the target concurrently, make use of custom templatable SIP messages, spreading the scan across different targets and more.

Tool functionality

The basic functionality of the sip enumerate command is as follows:

  1. Probing phase, that is, for each probing method (see probe-methods flag)

    1. sending a SIP message (starting with REGISTER) for a random SIP extension (i.e. username in the SIP URI) to the target
    2. if the response code is between 100 and 199 (inclusive), it is ignored
    3. if the response code is 407 or 401 AND never-auth is not set, try to authenticate; if the response is again 407 or 401 OR 403, 408 or 500 then it typically means that the target is not vulnerable; if we receive a different response, enable the always-auth flag
    4. if the response code is 403, 408 or 500 then it might mean that the system is not available or the wrong target hostname is provided
    5. if the response code is 2xx, log a WARN level message advising that a 2xx response code was received for a SIP URI that is assumed to be non-existent on the target; then skip to the next probe method in the list
    6. otherwise, note the response code and response reason as meaning that the attempted extension does not exist and move on to enumeration phase

  2. Start enumeration phase, that is, start sending each SIP message, each having a different SIP URI and then handling the responses as follows:

    1. if the response code and the response reason is the same as the one recorded in the probing phase, assume that the extension does not exist
    2. if the response code is between 100 and 199 (inclusive), it is ignored
    3. if the response code is 403, 408 or 500 then it might mean that the system is not available or the wrong target hostname is provided
    4. if the response code is 407 or 401 if always-auth is off, then it typically means that we found a valid extension that requires authentication
    5. if the response code is 407 or 401 if always-auth is on, attempt to authenticate
    6. if the response code is 200 then it means that the extension exists (if the request method is REGISTER), does not require authentication or that the system routes our message
    7. if the response code is 404 and the response code recorded in the probing phase was anything else, then it may be of interest for further investigation
    8. if either the response code or response reason is anything else other than the ones recorded during probing phase, assume that the extension exists and is of interest

When the enumeration SIP method is INVITE, certain extra behaviour needs to take place to handle the call.

The tool displays the following information:

  • When the extension exists, the response code, if confirmed to exist or marked as interesting and SIP URI is logged at INFO level
  • When the tool exits, the SIP URIs found grouped by the response code are returned
  • If the system is detected to be vulnerable, the exit code is 40

Video demonstration

sipvicious sip enumerate extensions

Command format

sipvicious sip enumerate extensions <target1 [target2 [target3 ...]]> [flags]

Flags

      --auth-config strings      Specify SIP authentication configuration. See documentation for details e.g. algorithm:sha-256
      --auth-mode string         Specify how to handle authentication requests (fake|real|ignore); default: ignore unless the -u flag is present (default "ignore")
  -c, --conn-count int           Number of connections to open (default 30)
  -u, --credentials string       Set the username and password in the following format: username:password (e.g. 1000:test123)
  -D, --domain string            Override domain name for the SIP address
      --ext-fmt string           Specify a format string for the extension (to be used with --extensions)
  -e, --extensions strings       Set the range of target extension numbers and/or alphanumeric extensions (default [0-9999,admin])
  -E, --extensions-file string   File to use for bruteforcing extensions or SIP URIs; to take input from stdin, use - instead of a filename
      --from string              Specify the from address either as a static string or a format string which formats the extension (e.g. sip:%04s@example.org)
  -m, --method string            Set the SIP message method to use (REGISTER|SUBSCRIBE|NOTIFY|PUBLISH|MESSAGE|INVITE|OPTIONS)
      --no-prober                Do not attempt to find out how the server should respond when an extension does not exist
      --probe-methods strings    Specify which SIP methods to use when attempting to find ways to perform enumeration (default [REGISTER,SUBSCRIBE,NOTIFY,PUBLISH,MESSAGE,INVITE,OPTIONS])
      --probe-only               Only do the probing exercise, do not run the actual enumeration
      --rate string              Specify how many packets to send for each period of time; format: packets/duration; e.g. 100/30ms
      --register                 Maintain a registration throughout the attack; requires -u
      --to-domain string         Force a particular domain in the To header value

Flags inherited from parent commands

      --ca-cert string       TLS CA Certificate
      --client-cert string   TLS client certificate
      --client-key string    TLS client private key
  -C, --config string        configuration file to use (may be JSON, TOML or YAML)
      --debug                set log level to debug
  -T, --duration duration    Stop the tool after a certain amount of time; e.g. 30s
      --logfile string       specify a log filename
      --results string       specify the filename for the result output, defaults to standard output. See documentation for information on file extension meanings
      --srtp string          Specify if either none, dtls or sdes to enforce SRTP for calls; format: method or method:parameters; see full documentation for details (default "none")
      --templates string     Directory to search for template overrides (default ".")
      --tls-key-log string   TLS key log

Examples

sipvicious sip enum ext -e 100-999,1000-2000 udp://target:5060
sipvicious sip enumerate extensions udp://target:5060

Advanced examples

# use specific ranges of extensions for enumeration, and pad the numeric range 1000-9999 with a zero (i.e. 01000-09999)
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 -e 1000-9999,10000-99999 --ext-fmt '%05d'

# use fake authentication while using a dictionary to bruteforce users
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 -c 100 --auth-mode fake -E dict.txt

# rate limit tests while using subscribe method (less intrusive)
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 --rate 1/30ms --no-prober -m subscribe

# customise a SIP message by altering the To and From domain
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 --to-domain urlonsip.tld --domain siteonsip.tld 

# do not execute the actual enumeration test, instead only perform the initial probe while maintaining a registration throughout the test
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 -u 1000:1500 --register --probe-only

# specify probe methods along with list of SIP URIs
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 --probe-methods invite,publish,subscribe --extensions-file sipuri.lst 

# enumerating using custom from address and format string for the extensions
sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060 tcp://demo.sipvicious.pro:5060 --from sip:%s@siteonsip.tld --ext-fmt '%04d' --extensions 0-9999

Exit codes

CodeDescription
40A security issue is raised when when a SIP extension enumeration is allowed and confirmed by identifying at least one SIP extension
30A network connectivity issue is raised when the connection fails or when no response is received

Full flag documentation

Flag: --auth-config

Specify SIP authentication configuration. This flag accepts the following values:

  • algorithm:value where value may be md5, md5-sess, sha-256, sha-256-sess, sha-512-256 or sha-512-256-sess. This value will force the tool to calculate the authorization response based on the first WWW-Authenticate or Proxy-Authenticate header field that matches this algorithm. If no match is found then the first WWW-Authenticate or Proxy-Authenticate header is selected.

Flag: --auth-mode

Specify how authentication requests are handled. This can be either fake, real or ignore. By default, authentication requests are ignored unless credentials are specified using the -u flag. When credentials are specified, the default behaviour is to make use of real credentials. When fake is specified, the challenge response is generated based on the challenge, but no credentials are actually used. This has the benefit of generating a failed authentication request, thus possibly triggering methods of SIP enumeration specific to authentication responses.

If fake or real is specified, the tool always tries to authenticate when challenged using SIP digest authentication; even if the probing stage determined that this is not required for enumeration. If, on the other hand, ignore is specified, the tool to never authenticates when challenged using SIP digest authentication; even if the probing stage determined that this is required for enumeration.

Flag: --ca-cert

The CA cert can be passed when making use of client certificate authentication. The file should be formatted as PEM.

Flag: --client-cert

The client certificate must be passed when making use of client certificate authentication. The file should be formatted as PEM.

Flag: --client-key

The client key must be passed when making use of client certificate authentication. The file should be formatted as PEM.

Flag: -C, --config

Specify a configuration file which may be a JSON, TOML and YAML config format. To get the default settings and figure out which settings are available, one may run the sipvicious utils dump config command. This is typically used to create a template configuration that can then be edited as need be.

These settings may be overwritten when the corresponding flag is explicitly set, if one is present.

Flag: -c, --conn-count

The conn-count allows setting of how many sockets should be used concurrently to spread out the attack.

Flag: -u, --credentials

Specify valid credentials so that SIP enumeration can be done authenticated. The following format is used username:password (e.g. 1000:test123). When not specified, if required, the tool will send fake challenge responses.

Additionally, a realm may be specified as a third parameter (e.g. 1000:test123:snowflake).

Flag: --debug

Tells the logger to print out debug messages.

Flag: -D, --domain

A domain name can be specified so that the SIP URI contains that particular domain rather than the one specified as the target. This is useful for targets that expect a particular domain name.

Flag: -T, --duration

Specify the maximum duration of the attack so that it stops after a certain time. Examples include:

  • 30s
  • 10m
  • 24h

Flag: --ext-fmt

The ext-fmt flag allows users to specify a format template for the extension generation. For example, -e 1-999 --ext-fmt="123%04d999" between 1230001999 to 1230999999.

The format string library used is the standard Go fmt. Please check the documentation for full details about the syntax.

Flag: -e, --extensions

This flag allows users to specify ranges of numbers and/or alphanumeric characters to be used in the enumeration attack. Each potential extension or range of numeric extensions is comma separated. Numeric ranges are separated by a minus sign. For example: 100-999,1000-1500,9999,test1,test2.

Flag: -E, --extensions-file

Specify a file containing potential SIP extensions or SIP URIs to be used in the enumeration attack. This overrides the default extensions flag.

When the filename is specified as -, standard input is used instead of taking input from a file.

The following is an example of expected content:

1000
1001
1002
sip:user@example.org
user2

Flag: --from

Specify a specific From address. The resulting string can be static, e.g. sip:1234@example.org or a format string which results in formatting the target extension, e.g. sip:123%04s999@example.org which results in sip:1230001999@example.org when the target extension is 1.

Flag: --logfile

When the logfile flag is specified, a log file is created in the location specified and logs are generated in this file instead of being sent to standard output. If the filename ends with a .json file extension, then the output format is in JSON, otherwise it defaults to text format.

Flag: -m, --method

Users who wish to force a particular SIP method for probing and enumeration, can specify that method by passing the method flag. This overrides the probe-methods flag.

Flag: --no-prober

When the no-prober flag is set, the probe phase is skipped. Instead, the tool assumes that extensions that exist should return a 401, 407 or 200 response. The tool also assumes that non-existent extensions will return a 404 response code.

If no SIP method is explicitly set, the REGISTER method is used.

Flag: --probe-methods

The probe-methods flag allows users to specify which methods to try to perform enumeration against. By default, it includes all SIP methods that are known to indicate if a particular extension exists on the registrar or can be proxied to.

This feature is useful when the target has partial protection against SIP extension enumeration that is limited to only specific methods. For example, a number of PBX systems have implemented protection against enumeration for the REGISTER method but not the SUBSCRIBE method.

By default, the tool will try to make use of the following SIP methods in the specified sequence during the probing phase:

  1. REGISTER
  2. SUBSCRIBE
  3. NOTIFY
  4. PUBLISH
  5. MESSAGE
  6. INVITE
  7. OPTIONS

The probing phase will log (at INFO level) which SIP methods appear to allow enumeration once all the methods have been tested. After that, the tool will start the enumeration phase, making use of the first method that appeared to allow enumeration. Users who wish to force a specific method for enumeration, overriding this behaviour, can do so by setting the method switch. Note that the OPTIONS method may lead to false positives.

Flag: --probe-only

This flag is given for users whose intent is to simply detect if enumeration is possible on the target. The tool will exit after the probe phase is finished, with an error code of 40 indicating that the target appears to be vulnerable.

Flag: --rate

Rate allows one to limit the attack below a certain rate. If the value is 100/30ms, that means that 100 packets should be spread out evenly across 30 milliseconds across all the connections per target.

Flag: --register

Register requires credentials to be passed so that a REGISTER message is sent to authenticate with a registrar server before starting the attack. The registration is maintained as per SIP standards, so that authentication does not time out.

Flag: --results

When the results flag is specified, upon completing the test, it outputs the results to the specified filename. The format for this output file is text unless the filename ends with a .json file extension. In that case, the result output is that of JSON.

The schema for the JSON output for this submodule can be found here.

Flag: --srtp

The srtp flag when specified, allows users to set the SRTP mode. By default, outgoing calls do not make use of SRTP, while incoming calls automatically handle SRTP depending on the SDP body of the incoming INVITE message. When the srtp flag is set to none, incoming calls do not make use of SRTP, regardless of the SDP body in an incoming INVITE. The srtp mode can also be either dtls or sdes. In both dtls and sdes modes, the parameters are not required and will be generated randomly as need be.

Options for both dtls and sdes mode may be passed after a colon. For example:

  • --srtp dtls:cert.crt:cert.key[:ca.crt] where the first argument after the mode (dtls) is the public certificate cert.crt, then the private key cert.key and finally, the optional certificate authority file ca.crt
  • --srtp sdes:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj where the argument is the base64 encoded cryptographic master key appended with the master salt.

Note that in the case of sdes key, the master key needs to be a valid length, which is 30 octets, for the default crypto-suite AES_CM_128_HMAC_SHA1_80.

Flag: --templates

Allows one to set the template directory which is used to load (or save) the SIP templates.

To get the default SIP templates, make use of the sipvicious sip utils dump templates command.

Flag: --tls-key-log

The TLS key log creates a file with the TLS key that can then be used to decrypt the TLS stream in tools that support it, such as Wireshark.

Flag: --to-domain

Force a specific domain name for the To address. This is useful when the domain name for the SIP address is different than the one passed for the SIPURI in the first line. If no domain or from argument is passed, this overrides the value for the From header as well.

Caveats

Detection of false positives

In some cases, some targets may respond positively (e.g. with a 200 OK) when scanned. This is especially the case when the enumeration method is set to OPTIONS. Therefore, by default, the tool detects instances where all extensions start resulting in a positive response. This is done by going into probe phase every 300 messages.

On making use of INVITE for enumeration

When making use of INVITE, the tool tries to cancel calls by sending a CANCEL as soon as a 180 response is received and if that fails, sends a BYE if the call is picked up.

Future enhancements

  • Intelligent SIP extension enumeration similar to VOIPPACK
  • Allow distributed attacks by splitting extensions and telemetry
  • Detect changes in headers or additional provisional responses when extensions do exist
  • A more accurate probe phase for lab environment tests where existent extensions are already known; this can be done by comparing responses for extensions that exist and those that do not, removing anything that is generated randomly in the SIP response and comparing the rest

JSON schema

The following is the JSON schema for the JSON output of this tool:

{
  "type": "object",
  "properties": {
    "status": {
      "type": "object",
      "properties": {
        "returncode": { "type": "integer" },
        "description": { "type": "string" }
      }
    },
    "targets": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "target": { "type": "string" },
          "status": {
            "type": "object",
            "properties": {
              "returncode": { "type": "integer" },
              "description": { "type": "string" }
            }
          },
          "results": {
            "type": "object",
            "properties": {
              "methods": {
                "type": "array",
                "items": {
                  "type": "object",
                  "properties": {
                    "potentiallyvulnerable": {"type": "boolean"},
                    "usedforenumeration": {"type": "boolean"},
                    "method": {"type": "string"},
                    "statuscode": {"type": "integer"},
                    "reasonphrase": {"type": "string"}
                  }
                }
              }
            }
          },
          "issues": {
            "type": "object",
            "properties": {
              "extensions": {
                "type": "array",
                "items": {
                  "type": "object",
                  "properties": {
                    "extension": {"type": "string"},
                    "reason": {"type": "string"},
                    "statuscode": {"type": "integer"},
                    "reasonphrase": {"type": "string"}
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}