Security: Extension enumeration vulnerability

Asterisk Asterisk General
1

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

One in particular - 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 :smiley:

2

That doesn’t appear to depend on type=friend…

3

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

freepbx.org/trac/ticket/5103

4

Sure, but try it. You don’t have to have a peer defined; you don’t need anything defined.

5

I think I am missing something. Would you care to elaborate on your last post ?

6

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.

7

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.

8

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:

<--- 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:

<--- 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?

9

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.

10

Howdy,

No, but on REGISTER, this:
packetstormsecurity.org/files/vi … ration.txt
happens.

11

You need to give me a warning when changing subject out of nowhere. :smiley:
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 :smiley:

12

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 - 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.

13

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.

14

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:

[ul]The SIP docs have been out of shape for so long:
issues.asterisk.org/jira/browse/19194
[/ul]