Asterisk PBX 1.2 through 1.6 and Trixbox PBX 2.6.1, when running with Digest authentication and authalwaysreject enabled, generates different responses depending on whether or not a SIP username is valid, which allows remote attackers to enumerate valid usernames.
Credit:
The information has been provided by Kerin Millar and Fergal Glynn.
Vulnerable Systems:
* Asterisk Open Source all versions prior to 1.2.32
* Asterisk Open Source all versions prior to 1.4.24.1
* Asterisk Open Source all versions prior to 1.6.0.8
* Asterisk Business Edition all versions that are part of A.x.x
* Asterisk Business Edition all versions prior to B.2.5.8
* Asterisk Business Edition all versions prior to C.1.10.5
* Asterisk Business Edition all versions prior to C.2.3.3
* s800i (Asterisk Appliance) all versions prior to 1.3.0.2
Immune Systems:
* Asterisk Open Source version 1.2.32
* Asterisk Open Source version 1.4.24.1
* Asterisk Open Source version 1.6.0.8
* Asterisk Business Edition version B.2.5.8
* Asterisk Business Edition version C.1.10.5
* Asterisk Business Edition version C.2.3.3
* s800i (Asterisk Appliance) version 1.3.0.2
In 2006, the Asterisk maintainers made it more difficult to scan for valid SIP usernames by implementing an option called "alwaysauthreject", which should return a 401 error on all replies which are generated for users which do not exist. While this was sufficient at the time, due to ever increasing compliance with RFC 3261, the SIP specification, that is no longer sufficient as a means towards preventing attackers from checking responses to verify whether a SIP account exists on a machine.
What we have done is to carefully emulate exactly the same responses throughout possible dialogs, which should prevent attackers from gleaning this information. All invalid users, if this option is turned on, will receive the same response throughout the dialog, as if a username was valid, but the password was incorrect.
It is important to note several things. First, this vulnerability is derived directly from the SIP specification, and it is a technical violation of RFC 3261 (and subsequent RFCs, as of this date), for us to return these responses. Second, this attack is made much more difficult if administrators avoided creating all-numeric usernames and especially all-numeric passwords. This combination is extremely vulnerable for servers connected to the public Internet, even with this patch in place. While it may make configuring SIP telephones easier in the short term, it has the potential to cause grief over the long term.
Resolution:
Upgrade to one of the versions below, or apply one of the patches specified in the Patches section.
