Security: Extension enumeration vulnerability

General discussions about Asterisk.

Moderators: Moderator, Support

Security: Extension enumeration vulnerability

Postby thor » Tue May 31, 2011 1:18 am

There were a few asterisk related vulnerabilities disclosed on packetstorm recently.

One in particular - http://packetstormsecurity.org/files/10 ... ation.html -
is related to careless use of type=friend instead of type=peer when defining SIP devices.
This is typical of e.g. FreePBX


I am sure this vulnerability will be addressed at some point in asterisk core, but it would probably make sense to provide some guidelines for people developing config generators. Retiring type=friend would probably make most sense at this point :D
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby malcolmd » Tue May 31, 2011 9:53 am

That doesn't appear to depend on type=friend...
Malcolm Davenport
Digium, Inc. | Senior Product Manager
malcolmd
Moves Like Spencer
 
Posts: 3019
Joined: Wed Aug 03, 2005 3:53 pm
Location: Huntsville, AL, US

Re: Security: Extension enumeration vulnerability

Postby thor » Tue May 31, 2011 10:30 am

The advisory is little short on details, but the configs used clearly show type=friend is in use.

You can also check a similar report from FreePBX

http://www.freepbx.org/trac/ticket/5103
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby malcolmd » Tue May 31, 2011 11:32 am

Sure, but try it. You don't have to have a peer defined; you don't need anything defined.
Malcolm Davenport
Digium, Inc. | Senior Product Manager
malcolmd
Moves Like Spencer
 
Posts: 3019
Joined: Wed Aug 03, 2005 3:53 pm
Location: Huntsville, AL, US

Re: Security: Extension enumeration vulnerability

Postby thor » Tue May 31, 2011 11:38 am

I think I am missing something. Would you care to elaborate on your last post ?
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby malcolmd » Tue May 31, 2011 11:40 am

I might be missing something, too.

The problem seems to be that the response varies (Unauthorized or Trying) depending on whether or not there's a definition (user, peer, friend, whatever) for the registration. The problem doesn't seem to be specific to whether something is defined as a user vs. a peer.
Malcolm Davenport
Digium, Inc. | Senior Product Manager
malcolmd
Moves Like Spencer
 
Posts: 3019
Joined: Wed Aug 03, 2005 3:53 pm
Location: Huntsville, AL, US

Re: Security: Extension enumeration vulnerability

Postby thor » Tue May 31, 2011 2:22 pm

I am worried when I hear statements like this coming from an asterisk product manager :cry:

It seems very few people know the difference between peer and user when using authentication.

In short it is:

peer can register and gets challenged on REGISTER (no challenge on consecutive INVITEs)
user can not register and gets challenged on INVITEs

Defining a device as friend ( which is a shorthand for peer+user ) makes asterisk try to authenticate the user on INVITEs.
If the device was defined only as peer, asterisk would not try to authenticate - peer must register first.
The INVITE would be ignored.

There is also an outstanding bug open asking for better docs on SIP - 19194
Lack of the proper documentation is part of the problem.
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby malcolmd » Tue May 31, 2011 3:11 pm

Hi,

Thank you for the personal criticism, I strive to better my knowledge every day.

With respect to the mentioned vulnerability...

If, using 1.8.4.1 I've defined the general section as mentioned in the report, and I attempt a random registration, then Asterisk responds:

Code: Select all
<--- SIP read from UDP:10.24.250.50:5060 --->
REGISTER sip:10.24.13.224 SIP/2.0
Via: SIP/2.0/UDP 10.24.68.105:5060;rport;branch=z9hG4bKPj0eJBB-jN9nzKtEtCYZ84ethWwhFa6EUp
Max-Forwards: 70
From: "MALCOLM DAVENPORT" <sip:malcolm2@10.24.13.224>;tag=4c4B3dHjF2-wsRC2mt-YJgnes.0KUy.l
To: "MALCOLM DAVENPORT" <sip:malcolm2@10.24.13.224>
Contact: <sip:fmnzvkru@10.24.250.50:5060>
Call-ID: nzwgP1mGol26QfV2ENqarVrtvUn7DNxn
CSeq: 1 REGISTER
Expires: 600
User-Agent: Blink 0.24.1 (MacOSX)
Content-Length:  0


<------------->
--- (11 headers 0 lines) ---
Sending to 10.24.250.50:5060 (no NAT)

<--- Transmitting (no NAT) to 10.24.250.50:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.24.68.105:5060;branch=z9hG4bKPj0eJBB-jN9nzKtEtCYZ84ethWwhFa6EUp;received=10.24.250.50;rport=5060
From: "MALCOLM DAVENPORT" <sip:malcolm2@10.24.13.224>;tag=4c4B3dHjF2-wsRC2mt-YJgnes.0KUy.l
To: "MALCOLM DAVENPORT" <sip:malcolm2@10.24.13.224>
Call-ID: nzwgP1mGol26QfV2ENqarVrtvUn7DNxn
CSeq: 1 REGISTER
Server: Asterisk PBX 1.8.4.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>

<--- Transmitting (no NAT) to 10.24.250.50:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.24.68.105:5060;branch=z9hG4bKPj0eJBB-jN9nzKtEtCYZ84ethWwhFa6EUp;received=10.24.250.50;rport=5060
From: "MALCOLM DAVENPORT" <sip:malcolm2@10.24.13.224>;tag=4c4B3dHjF2-wsRC2mt-YJgnes.0KUy.l
To: "MALCOLM DAVENPORT" <sip:malcolm2@10.24.13.224>;tag=as1224f78b
Call-ID: nzwgP1mGol26QfV2ENqarVrtvUn7DNxn
CSeq: 1 REGISTER
Server: Asterisk PBX 1.8.4.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3d97cd13"
Content-Length: 0


<------------>


If, on the other hand, I attempt registration of an already defined peer, then I get:

Code: Select all
<--- SIP read from UDP:10.24.250.50:5060 --->
SUBSCRIBE sip:asterisk@10.24.13.224:5060 SIP/2.0
Via: SIP/2.0/UDP 10.24.68.105:5060;rport;branch=z9hG4bKPjcPe-jn0zgXaWT95xtpN3hRAqGjX.24.a
Max-Forwards: 70
From: "malcolm" <sip:malcolm@10.24.13.224>;tag=AhRDQWRw2FllrDXyS6VZQxthD0yvIwqv
To: <sip:malcolm@10.24.13.224>;tag=as239c2b7a
Contact: <sip:kqiufwjd@10.24.250.50:5060>
Call-ID: wvFyp4wO-etAV4diFUO.SW85NipQy8.K
CSeq: 4643 SUBSCRIBE
Event: message-summary
Expires: 0
Accept: application/simple-message-summary
Allow-Events: conference, message-summary, presence, presence.winfo, xcap-diff, refer
User-Agent: Blink 0.24.1 (MacOSX)
Content-Length:  0


<------------->
--- (14 headers 0 lines) ---
Found peer 'malcolm' for 'malcolm' from 10.24.250.50:5060

<--- Transmitting (no NAT) to 10.24.250.50:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.24.68.105:5060;branch=z9hG4bKPjcPe-jn0zgXaWT95xtpN3hRAqGjX.24.a;received=10.24.250.50;rport=5060
From: "malcolm" <sip:malcolm@10.24.13.224>;tag=AhRDQWRw2FllrDXyS6VZQxthD0yvIwqv
To: <sip:malcolm@10.24.13.224>;tag=as239c2b7a
Call-ID: wvFyp4wO-etAV4diFUO.SW85NipQy8.K
CSeq: 4643 SUBSCRIBE
Server: Asterisk PBX 1.8.4.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="0703a3a4"
Content-Length: 0


<------------>


Because Asterisk is responding with a 100 Trying, is there not a "leak" that someone has guessed an invalid peer definition?
Malcolm Davenport
Digium, Inc. | Senior Product Manager
malcolmd
Moves Like Spencer
 
Posts: 3019
Joined: Wed Aug 03, 2005 3:53 pm
Location: Huntsville, AL, US

Re: Security: Extension enumeration vulnerability

Postby thor » Tue May 31, 2011 3:16 pm

The vulnerability does not affect 1.8
It only affects 1.4/1.6.
There are obviously some (documented ?) changes that happened in user processing between versions 1.6 and 1.8.
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby malcolmd » Tue May 31, 2011 4:09 pm

Howdy,

No, but on REGISTER, this:
http://packetstormsecurity.org/files/vi ... ration.txt
happens.
Malcolm Davenport
Digium, Inc. | Senior Product Manager
malcolmd
Moves Like Spencer
 
Posts: 3019
Joined: Wed Aug 03, 2005 3:53 pm
Location: Huntsville, AL, US

Re: Security: Extension enumeration vulnerability

Postby thor » Tue May 31, 2011 7:21 pm

You need to give me a warning when changing subject out of nowhere. :D
You've confirmed the vulnerability in 1.8.4 is real. 1.8.3 is clean so this is a recent change.

Can we go back to talking about 1.4/1.6 vulnerability ? The one that originally started the thread :D
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby thor » Wed Jun 01, 2011 3:12 am

Did some more testing against 1.8 and it is also vulnerable.
With alwaysauthreject=yes and allowguest=no existing user gets "401 Unauthorized", non-existent user gets "407 Proxy Authentication Required". The packetstorm report states existing user gets timeout but this seems incorrect. Dynamic user needs to be challenged.
The report on freepbx.org is the correct one - http://www.freepbx.org/trac/ticket/5103

There is really no workaround other than not using type=friend at this point.
The possible fix for people who need to use type=friend ( not sure who would that be ) is to change the 407 reply into 401.
thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm

Re: Security: Extension enumeration vulnerability

Postby malcolmd » Wed Jun 01, 2011 7:26 am

Yuck.

The best thing to do would be to try and address the issue so that continuing to use type=friend doesn't impact anyone or require them to make configuration changes.

We'll start churning on it.
Malcolm Davenport
Digium, Inc. | Senior Product Manager
malcolmd
Moves Like Spencer
 
Posts: 3019
Joined: Wed Aug 03, 2005 3:53 pm
Location: Huntsville, AL, US

Re: Security: Extension enumeration vulnerability

Postby thor » Wed Jun 01, 2011 11:22 am

I think it would be a good time to ask yourself why people use type=friend ?

I have not been using asterisk long enough to know where did this idea originate,
but here is a plausible explanation:

thor
Oldsterisk
 
Posts: 238
Joined: Thu Mar 18, 2010 12:19 pm


Return to Asterisk General

Who is online

Users browsing this forum: Google [Bot] and 1 guest