The Authentication Tool was created to attempt to determine the password
for each user who is the subject of certain SIP messages.

    Copyright (c)  2004  Mark D. Collier/Mark O'Brien
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.2
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".
 
Authors:  Mark D. Collier/Mark O'Brien   09/20/2004  v1.0
          www.securelogix.com - mark.collier@securelogix.com
          www.hackingexposedvoip.com

This tool was produced with honorable intentions, which are:

  o To aid owners of VoIP infrastructure to test, audit, and uncover security
    vulnerabilities in their deployments.

  o To aid 3rd parties to test, audit, and uncover security vulnerabilities
    in the VoIP infrastructure of owners of said infrastructure who contract
    with or otherwise expressly approve said 3rd parties to assess said
    VoIP infrastructure.

  o To aid producers of VoIP infrastructure to test, audit, and uncover security
    vulnerabilities in the VoIP hardware/software/systems they produce.

  o For use in collective educational endeavors or use by individuals for
    their own intellectual curiosity, amusement, or aggrandizement - absent
    nefarious intent.
   
Unlawful use of this tool is strictly prohibited.

The username/password pairs output by this tool could be used
as input to a tool such as the SIP Registration Hijacker. The
presumption is that SIP servers are invoking MD5 authentication
challenges to clients invoking these SIP requests:

REGISTER
INVITE
OPTIONS

Refer to the following RFCs for SIP Authentication
protocol information:  3261, 2617, and 1321.

This tool inputs a file of SIP messages and scans
for these SIP header lines:

REGISTER
INVITE
OPTIONS
From:
Authorization:
Proxy-Authorization:

Before encountering an Authorization header line, the tool
expects to find at least one REGISTER, INVITE, or OPTIONS
request line, and at least one "From:" header line. The scanning
is not as robust as a production tool would require. The scan
does not distinguish between SIP headers and SIP message
bodies (e.g. SDP). If a line in a message body is encountered
starting with any of the keywords above, the Authentication
Tool happily proceeds under the presumption that a SIP
message header line has been found. SIP message fragments
may cause the tool to perform poorly or even crash.

When an Authorization header line is encountered, the tool
attempts to extract the parms required to recompute the
the MD5 digest that must also be present on that Authorization
line. The tool recomputes the digest as directed by the operator.
It either employs a dictionary attack using the dictionary of
passwords specified by the operator on the command line, or it
uses the solitary password specified by the operator on the
command line. When a password is encountered which results
in the same MD5 digest product as the digest string found in the 
Authorization header line, then the username, the password,
and the URI are output to the result file and/or the monitor.
The tool completes normally when all SIP messages in the
input file have been exhausted.

NOTE: The URI output to the file is NOT the one extracted
      from the Authorization line "uri" parm. The uri parm
      from the Authorization line does not necessarily identify
      the user whose password has been found. This is true
      in most cases. For example, the INVITE request line
      contains the URI of the person being invited into a call,
      not the user whose authentication was challenged. The
      REGISTER message request line has the URI of the proxy
      server or Registrar, not the URI of the user whose
      authentication was challenged. The user's URI is 
      typically in the "From:" header line. This is the URI
      presently being output with a username/password pair.

      It is debatable which URI a hacker would wish to know.
      The URI informs the hacker of the domain information
      This is needed by the hacker to know where to direct
      an attack (e.g. Registration Hijacking) using the 
      usernames and passwords produced by the Authentication
      Tool. For now, the From header URI is being output.
      The tool may always be amended to output additional
      URIs.

The tool is stateless in that it does not check for username
repeats as it encounters SIP messages with Authorization
header lines. In fact, the same username may be provisioned
in different authentication realms. It might identify the
same person or it might not, so a simple check for username
repeats would be insufficient in any case. Even if it does
identify the same person, the password might be different
for different authentication realms.

make the Makefile and you should be ready to go. Since the
MD5 code is circa 1991, you might receive some warnings
in that code based on the compiler version you are using
(which - generally - are less forgiving than 1991).

A typical invocation of the tool might be:

./authtool capturedsipmsgs -d dictionary -r usernames_passwords -v

where:

capturedsipmsgs         - file of SIP messages
-d dictionary           - dictionary file (source of passwords for the attack)
-r usernames_passwords  - results file
-v                      - verbose mode

or perhaps

./authtool capturedsipmsgs -p snoopy -v

where:

capturedsipmsgs         - file of SIP messages
-p snoopy               - solitary password to use in the attack
-v                      - verbose mode

or perhaps

./authtool capturedsipmsgs -p snoopy

For that last case, output to the monitor is restricted to
username/password matches and a summary of the number
of solutions found.

Sample REGISTER messages are found in the SIPMessages file and 
a sample output for the processing of those messages is found
in the usernames_passwords file.

Mark O'Brien