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-0600 | Date Closed: | 2011-06-07 14:03:21 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
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. ****** ADDITIONAL INFORMATION ****** 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 CSeq: 102 OPTIONS User-Agent: MBTed Date: Sat, 07 Feb 2009 13:28:26 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 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. |