[asterisk-users] alwaysauthreject=yes not working as expected

[Matthew Jordan]

----- Original Message -----
> From: "CB" <kjcsb at xnet.co.nz>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com>
> Sent: Tuesday, August 21, 2012 4:39:32 AM
> Subject: Re: [asterisk-users] alwaysauthreject=yes not working as expected
> 
> > > Asterisk 1.4.42

First, even if you were right and you discovered a security vulnerability in
Asterisk 1.4.42, that version of Asterisk is now in "EOL", and no new security
releases will be made.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

You would of course be more then welcome to solicit patches from the open
source community, but no new version of Asterisk 1.4.x would be released.

<snip>

> Yes I agree they are supposed to be the same but they are not. Below
> is the
> dialog when a wrong password is provided with alwaysauthreject=yes:
> 
> U 121.98.1.1:1025 -> 203.89.1.1:5060
> REGISTER sip:domain.com SIP/2.0..Via: SIP/2.0/UDP
> 192.168.1.103:5060;branch=z9hG4bK-d8754z-d88996fba8b1fd8c-1---d8754z-
> ;rport..Max-Forwards: 70..C
> ontact:
> <sip:12322222261336 at 192.168.1.103:5060;rinstance=da68419a02006162>.
> .To: <sip:12322222261336 at domain.com>..From:
> <sip:1232222
> 2261336 at domain.com>;tag=f910aa53..Call-ID:
> ZmM4YTU4NTg2MWNhYzVkYTBhN2Q2MjA1YmUyMmYzY2E...CSeq: 1
> REGISTER..Expires:
> 3600..Allow: INVITE, ACK, CANC
> EL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
> INFO..User-Agent:
> X-Lite release 5.0.0 stamp 67284..Content-Length: 0....
> 

<snip>

> U 203.89.1.1:5060 -> 121.98.1.1:1025
> SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP
> 192.168.1.103:5060;branch=z9hG4bK-d8754z-d88996fba8b1fd8c-1---d8754z-
> ;received=121.98.1.1;rport=1025..From: <sip:
> 12322222261336 at domain.com>;tag=f910aa53..To:
> <sip:12322222261336 at domain.com>;tag=as16fea110..Call-
> ID: ZmM4YTU4NTg2MWNhYzVk
> YTBhN2Q2MjA1YmUyMmYzY2E...CSeq: 1 REGISTER..User-Agent: Asterisk
> PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
> NOTIFY,
> INFO..Supported: repla
> ces..WWW-Authenticate: Digest algorithm=MD5, realm="domain.com",
> nonce="2f48b121"..Content-Length: 0....

This is expected behavior.

> U 121.98.1.1:1025 -> 203.89.1.1:5060
> REGISTER sip:domain.com SIP/2.0..Via: SIP/2.0/UDP
> 192.168.1.103:5060;branch=z9hG4bK-d8754z-5c88940128ede618-1---d8754z-
> ;rport..Max-Forwards: 70..C
> ontact:
> <sip:12322222261336 at 192.168.1.103:5060;rinstance=da68419a02006162>.
> .To: <sip:12322222261336 at domain.com>..From:
> <sip:1232222
> 2261336 at domain.com>;tag=f910aa53..Call-ID:
> ZmM4YTU4NTg2MWNhYzVkYTBhN2Q2MjA1YmUyMmYzY2E...CSeq: 2
> REGISTER..Expires:
> 3600..Allow: INVITE, ACK, CANC
> EL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
> INFO..User-Agent:
> X-Lite release 5.0.0 stamp 67284..Authorization: Digest
> username="12322222261336",re
> alm="domain.com",nonce="2f48b121",uri="sip:c-vm-
> 02.domain.com",response="cb74a7805412a3ac198800aeede3c06e",algorit
> hm=MD5..Content-Length: 0....
> 

<snip>
 
> SIP/2.0 403 Forbidden (Bad auth)..Via: SIP/2.0/UDP
> 192.168.1.103:5060;branch=z9hG4bK-d8754z-5c88940128ede618-1---d8754z-
> ;received=121.98.1.1;rport=1025..Fro
> m: <sip:12322222261336 at domain.com>;tag=f910aa53..To:
> <sip:12322222261336 at domain.com>;tag=as16fea110..Call-ID: ZmM4YTU4NTg2
> MWNhYzVkYTBhN2Q2MjA1YmUyMmYzY2E...CSeq: 2 REGISTER..User-Agent:
> Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
> SUBSCRIBE, NOTIFY, INFO..Supporte
> d: replaces..Content-Length: 0....
> 
> Is this a bug or am I missing something obvious?

That is expected behavior as well.

;alwaysauthreject = yes         
; When an incoming INVITE or REGISTER is to be rejected,
; for any reason, always reject with an identical response
; equivalent to valid username and invalid password/hash
; instead of letting the requester know whether there was
; a matching user or peer for their request.  This reduces
; the ability of an attacker to scan for valid SIP usernames.
; This option is set to "yes" by default.

The 401 response merely indicates that some level of authorization
is required.  The 403 response matches what would be sent if the
username was valid but an invalid password/hash was provided. This
response should be sent regardless if the username was actually
valid.

Based on your provided SIP traffic, that appears to be what happened.

--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org