Reporter:Jonathan M Bradshaw (jonathanmbradshaw)Labels:
Date Opened:2010-08-13 09:33:44Date Closed:2011-06-07 14:00:32
Versions:Frequency of
Environment:Attachments:( 0) dumpFile-ALL-498092266901-0401.txt
( 1) dumpFile-ALL-498092266901-0945.txt
( 2) dumpFile-ALL-498092266901-2732.txt
( 3) full.21
( 4) sip.conf-text
Description:I have a set of logs, network traces etc which *may* illustrate a successful if accidental brute force attack on the ASTERISK SIP channel driver.  

perhaps it is B/S but you may want to take a look - best regards Jonathan

Additional info (net dumps etc) avail on request

* Asterisk built by mockbuild @ x86-03.phx2.fedoraproject.org on a i686 running Linux on 2010-05-05 13:14:21 UTC
* Fedora 13 (32bit)


In-line trace removed - pabelanger
Comments:By: Paul Belanger (pabelanger) 2010-08-16 10:03:59

We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:


By: Paul Belanger (pabelanger) 2010-08-16 10:21:31

As a follow up, we would need to see your actual sip.conf file, without redacted information.  This will help to reproduce the issue.

By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-16 14:00:39

per your request a log file has been provided at "full.21"

By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-16 14:09:41

per your request a SIP config file has been added at "sip.conf-text"

- Comments have been removed (all after ';')
- Passwords have been replaced with '*'

By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-16 14:11:19

A network trace for this event is available - best regards jmb

By: Russell Bryant (russell) 2010-08-16 14:49:23

It's not clear to me what the problem is here.  What did you see in your logs/traces that indicates to you that there is a problem?  Specifically, what behavior have you observed that appears to be a bug in Asterisk?

By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-17 06:34:24

In the first place I don't believe that the SIP client is behaving as it should (RFC-3261).  That aside I do not understand the pattern of INVITE traffic in this trace, or in others that I have looked at;

I expect the first 401 - UNAUTHORIZED message at 0366, based on my inspection of the RFC this is how the server is expected to provide authentication information so that the client can refine its next connection attempt.

Based on my inspection of the network frames the INVITE at 6217 is the same as the previous INVITE and as expected it is 401'ed.  The RFC suggests that in the absence of any credentials the client should have sent 'anonymous' as the username and '' as the secret.

I am OK so far but I am surprised that the INVITE at 6917 was successful.  In many respects 6917 is the same as the INVITES at 0365 and 6217 but there are some differences.

I note that some of the SIP fields in 6917 have been malformed, the FROM, CONTACT and REMOTE-PARTY-ID have changed as follows;

0365 From: "4980922559017" <sip:4980922559017@>;tag=as08c7b904
6217 From: "4980922559017" <sip:4980922559017@>;tag=as42f16889
6917 From: "004980922559017" <sip:004980922559017@>;tag=as2ed270d5

0365 Contact: <sip:4980922559017@>
6217 Contact: <sip:4980922559017@>
6917 Contact: <sip:004980922559017@>

0365 Remote-Party-ID: "4980922559017" <sip:4980922559017@>;privacy=off;screen=no
6217 Remote-Party-ID: "4980922559017" <sip:4980922559017@>;privacy=off;screen=no
6917 Remote-Party-ID: "004980922559017" <sip:004980922559017@>;privacy=off;screen=no

This is a pattern which I have observed over a number of days, I have seen as many as 5 INVITES 401'ed but when a malformed INVITE is received it is admitted.

In this example the change is the addition of '00', in other cases '00' has been replaced by '353' (the country code has been duplicated?).

I hope this helps, best regards Jonathan

PS : This system was upgraded to before the test above.  Asterisk built by mockbuild @ x86-20.phx2.fedoraproject.org on a i686 running Linux on 2010-08-02 21:14:50 UTC

tcpdump, file name 2010-08-16-20-19


6920 100 - TRYING

By: Paul Belanger (pabelanger) 2010-08-17 09:32:21

Set allowguests=no in your sip.conf and retest.

By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-18 09:31:11

OK guy's, call off the hunt!  

I have isolated this issue to the configuration on the SIP server and I apologies for distracting everyone..  

by way of an explanation, this is what I see happening; The incoming sip invite is checked against the list of peers (name first) in SIP.CONF and this results in a positive match.. In this example the e.164 pattern in the SIP invite is matched to a peer by the same name which is configured for the LAN (Cisco VoIP Phone on the private network), the credentials don't match and so the INVITE is 401'ed.  At a later stage the SIP client sends a malformed SIP INVITE which has '00' or '353' pretended to the number, this does not match any of the peers in SIP.CONF and is treated as expected..

My mistake, but thanks for your attention nonetheless!

By: Paul Belanger (pabelanger) 2010-08-18 10:22:08

Closing, not an issue.