Summary:ASTERISK-13574: SIP calls being allowed without valid username/password
Reporter:Mark W (mjwbase)Labels:
Date Opened:2009-02-12 14:29:08.000-0600Date Closed:2011-06-07 14:03:21
Versions:Frequency of
Description:Third-party was able to make SIP calls via server without providing valid username & password. Server is configured to only allow SIP connections with valid credentials.

Sample output from SIP SHOW CHANNELS while third-parties were connected.

Peer             User/ANR    Call ID      Seq (Tx/Rx)  Format           Hold     Last Message
85.xxx.xxx.xxx    (None)      3b05abda4e8  00101/00102  0x0 (nothing)    No       Rx: OPTIONS
173.xxx.xxx.xxx     (None)      5ebb8ebc3c4  00101/00102  0x0 (nothing)    No       Rx: OPTIONS
85.xxx.xxx.xxx    (None)      0e8be383584  00101/00102  0x0 (nothing)    No       Rx: OPTIONS
3 active SIP channels

Server was taken offline immediatly this was discovered and checking the cdr records with the server disconnected from the network it was evident that they had been able to place a large number of calls and that these were sucessfully connected.


Server and configuration files were immediatly checked after the incident and were found to show no signs of tampering. sip.conf was also rechecked to ensure nothing such as insecure=very had been added by error.

Server OS is CentOS 4.6 32-bit.

A capture of packets being sent to the server's IP address after it was taken offline showed large numbers SIP packets of the type:

G0E-9(Ury_OPTIONS sip:212.xxx.xxx.xxx SIP/2.0
Via: SIP/2.0/UDP 85.xxx.xxx.xxx:5060;branch=z9hG4bK043efa01;rport
Max-Forwards: 70
From: "MBTed" <sip:MBTed@85.xxx.xxx.xxx>;tag=as6616094d
To: <sip:212.xxx.xxx.xxx>
Contact: <sip:MBTed@85.xxx.xxx.xxx>
Call-ID: 12e968c30fe512d149e89fb521c824d4@85.xxx.xxx.xxx
User-Agent: MBTed
Date: Sat, 07 Feb 2009 13:28:26 GMT
Supported: replaces, timer

Unfortunatly it wasn't possible at the time to capture the full packet.
Comments:By: Joshua C. Colp (jcolp) 2009-02-12 14:57:44.000-0600

Unfortunately there is not much to go on from this report. The output you have provided doesn't show anything out of the ordinary, it is perfectly fine for remote SIP devices to send us OPTIONS packets. They are not used to setup/tear down a call. Are you going to be able to provide any further information? Your configuration? Console output of these calls in progress? Additional SIP traces?

It is possible that an account was brute force attacked and once the password acquired calls sent out using it. There have been quite a few reports of this happening.

By: Mark W (mjwbase) 2009-02-15 15:45:42.000-0600

unfortunatly it was not possible at the time of the problem to capture data as the server had access to a primary rate ISDN line and the priority was to cut off access.

Sorry about this, I normally like to provide as much information as I can possible give. It is possible the passwords were brute-forced as you suggest and as you say without further info it is not possible to find out.

I think close this issue - however I'll try and get permission to setup a server with no PSTN access  but with an otherwise identical setup and see if they come back and I can get more data then.

Thanks for taking time to answer, Mark

By: Joshua C. Colp (jcolp) 2009-02-16 07:50:22.000-0600

Suspended per reporter.