This documentation applies to SIPVicious version v6.0.0-beta.1. Please note that only the latest version of SIPVicious PRO is supported.
Perform a SIP method fuzzing attack.
Perform a SIP fuzzing test on specific SIP methods. This tool allows testers to check the robustness of the SIP parser and SIP stack by sending mutated SIP messages to the target system.
The sip fuzz method
module helps identify unknown security issues using fuzzing techniques. It mutates SIP messages before they are sent to the target server by making use of the mutation engine that is specified. By default it uses radamsa
, but the zzuf
mutator can also be used as a mutation engine. In the case of most SIP messages, the functionality is rather simple: send malformed SIP messages as fast as possible. In the case of INVITE
messages, extra behaviour is implemented to trigger different conditions. A random user/extension is generated for each request sent by default.
The fuzzer works by repeating the following steps:
sip utils call
utilityWhen credentials are passed using the relevant flag, the first unauthenticated SIP message is not passed to the mutator engine. This allows authenticated messages to be fuzzed. By default, all fuzzing methods (i.e. whole message, specific headers and so on) are used randomly but this behaviour can be changed by specifying a value to the fuzz
flag. A tester can specify which SIP header is mutated by making use of the value header:specific-header
, where specific header is a valid SIP header that is to be targeted. Other options are available to, for example, fuzz only the SIP message body or request line. Additionally, all SIP methods supported by this module are used randomly unless the method flag is used to specify an individual SIP method.
A prober is switched on by default, which will send a SIP message that is known to elicit a response from the target system. This is used to monitor the system and tell if the system starts missing messages or stops responding at all. This is done by sending the same message that is used to initiate the SIP fuzzing exercise. The prober should record the response code so that if it later changes (e.g. from a 200 or 404 to a 5XX server error), it can report this change. If the prober starts missing responses, these get logged as a non-fatal error.
sipvicious sip fuzz method <target1 [target2 [target3 ...]]> [flags]
--close-conn Close the connection after sending each message, instead of keeping it alive
-c, --conn-count int Number of sockets to use (per target) (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
--duration duration set maximum duration to keep the test going
-e, --extension string specify a target extension or SIP URI in the To address; if not specified, a random numeric extension is used when required
-f, --from string specify a from extension or SIP URI to set the From address; if not specified, a random numeric extension is used
--fuzz string Specify which part to fuzz; format: part:value; (header|message|body|request-line); e.g. header:Via; see full documentation for details
--invite-mode strings Specify how to behave when the method being fuzzed is INVITE; format: action or action:duration; (ignore|hangup-trying|hangup-ringing|hangup-call|never-hangup); default: ignore
--max-requests int set the maximum number of requests to send
-m, --method string set the SIP message method to use (REGISTER|SUBSCRIBE|NOTIFY|PUBLISH|MESSAGE|INVITE|OPTIONS|ACK|CANCEL|BYE|PRACK|INFO|REFER|UPDATE)
--mutator string Specify the mutator to use (radamsa|zzuf|none) (default "radamsa")
--no-prober Do not monitor the system by sending ping messages to check for errors or timeouts (on by default)
--rate string Specify how many packets to send for each period of time; format: packets/duration; e.g. 100/30ms
--register maintain a registration; requires -u
--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
--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, - for stdout
sipvicious sip fuzz method udp://target:5060 --method invite --register -u 1000:test
sipvicious sip fuzz method tcp://target:5060 --rate 100/1s -m REGISTER
sipvicious sip fuzz method tls://target:5061 --duration 10m
# fuzz the invite method while maintaining a registration using the credentials given
sipvicious sip fuzz method -m invite -u 1000:1500 udp://demo.sipvicious.pro:5060 --register
# bypass network security rate limiting by slowing down and prolonging the attack
sipvicious sip fuzz method udp://demo.sipvicious.pro:5060 -c 100 --duration 100m --rate 1/20ms -e 2000
# fuzz the publish method
sipvicious sip fuzz method udp://demo.sipvicious.pro:5060 -e 2000 -m publish
Code | Description |
---|---|
40 | A security issue is raised when the prober detects SIP-level or network-level errors |
30 | A network connectivity issue is raised when the connection fails before the attack is started |
--ca-cert
The CA cert can be passed when making use of client certificate authentication. The file should be formatted as PEM.
--client-cert
The client certificate must be passed when making use of client certificate authentication. The file should be formatted as PEM.
--client-key
The client key must be passed when making use of client certificate authentication. The file should be formatted as PEM.
--close-conn
The default connection behaviour is to try to keep all connections alive or, in the case of UDP, to reuse the same socket. This flag overrides this behaviour so that the connection is closed after each message is sent. This can uncover vulnerabilities related to socket handling in relation to SIP signalling.
-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.
-c
, --conn-count
The conn-count
allows setting of how many sockets should be used concurrently to spread out the attack.
-u
, --credentials
Specify valid credentials so that SIP fuzzing 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.
Note: This does not set the correct SIP To
and From
headers, which might cause authorization checks to fail. Set the -e
and --from
flags if this is required.
--debug
Tells the logger to print out debug messages.
-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.
--duration
Specify the maximum duration of the attack so that it stops after a certain time.
-e
, --extension
This flag allows users to target a particular extension, overriding the default behaviour of targeting random extensions. The value can be either just the SIP extension/username (e.g. 1234) or a SIP URI (e.g. sip:user@example.org
).
-f
, --from
This flag allows users to set the From
address, overriding the default behaviour of setting a random extension or the username in the credentials when one is provided. The value can be either just the SIP extension/username (e.g. 1234) or a SIP URI (e.g. sip:user@example.org
).
--fuzz
The flag fuzz
allows one to specify which part of the SIP message to mutate. The value of this flag could be one of the following:
message
which is default and mutates the whole SIP messageheader
which only mutates one header at a timebody
which mutates the whole SIP bodyrequest-line
which only mutates the first line of the SIP requestAdditionally, when header
is specified as value, it can take a header name which is preceded with a colon. For example, the following value would fuzz the Via header: header:via
.
By default, all fuzzing methods are used randomly when the value is not set.
--invite-mode
The flag invite-mode
allows one to specify how to behave during an INVITE fuzzing session. The value of this flag could be one of the following actions:
ignore
which does not wait for SIP INVITE responses; this is the defaulthangup-trying
which sends a CANCEL
as soon as a 100 Trying
message is receivedhangup-ringing
which sends a CANCEL
as soon as a 180 Ringing
is receivedhangup-call
which hangs up (by sending a BYE
) when a call is picked up (i.e. when a 200 OK
is received)never-hangup
which handles the call flow normally without hanging upAdditionally, the action value may be preceded by a colon and a duration value. This duration should be specified when the action should be taken after a specific time (e.g. 2s or 300ms). For example, hangup-ringing:300ms
.
The following invite-mode
values cannot be combined with other invite-mode
values, nor do they take in duration values:
ignore
never-hangup
--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.
--max-requests
Specify the maximum number of messages to send before stopping the attack.
-m
, --method
The SIP fuzz method tool supports the following SIP methods:
REGISTER
SUBSCRIBE
NOTIFY
PUBLISH
MESSAGE
INVITE
OPTIONS
ACK
CANCEL
BYE
PRACK
INFO
REFER
UPDATE
In the case of INVITE
messages, the invite-mode
method specifies extra parameters that are only specific to this method. By default, all SIP methods are used randomly fuzzed when the value is not set.
--mutator
Choose the mutation engine to use. Currently supported are the following:
The none
mutator can be specified for debugging reasons, for example, to ensure that the SIP messages are generated correctly. When using this value,
--no-prober
Switches off the default prober which sends a SIP message to detect errors and issues during an attack.
--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.
--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.
--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.
--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
.
--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.
--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.
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": {
}
},
"issues": {
"type": "object",
"properties": {
}
}
}
}
}
}
}