[Home]

Summary:ASTERISK-16730: SIP brute force attemps having a DoS effect
Reporter:Erik Smith (eeman)Labels:
Date Opened:2010-09-24 19:00:30Date Closed:2010-12-09 16:19:59.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) example.pcap
Description:We've all seen the brute force attempts where a script blasts asterisk with thousands of attempts to learn valid accounts

example:
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from '"9941"<sip:9941@1.2.3.4>' failed for '81.31.148.109' - No matching peer found
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from '"9942"<sip:9942@1.2.3.4>' failed for '81.31.148.109' - No matching peer found
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from '"9943"<sip:9943@1.2.3.4>' failed for '81.31.148.109' - No matching peer found
[Sep 24 15:46:51] NOTICE[19686] chan_sip.c: Registration from '"9944"<sip:9944@1.2.3.4>' failed for '81.31.148.109' - No matching peer found

this seems to be having a second effect of creating a DoS attack on inbound calls. It seems that the instigating attacker's IP finds its way into legitimate SIP messages as the Contact: url. The result is the ACK messages to the corresponding 200 messages are sent instead to this IP. Observe the Contact header in this simple ACK message (i sanitized the IP addresses except for the script running ass; he can get his own DoS from this post for all i care):

rUJy`\=EX+U.HFE@SIP/2.0 200 OK
Via: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bK78126bc7;received=4.3.2.1;rport=5060
From: "BLUEGRASSNET" <sip:+18598064913@4.3.2.1>;tag=as684e24f7
To: <sip:+18129442733@1.2.3.4>;tag=as52fe0a2e
Call-ID: 4544269969f074577549d403673538de@4.3.2.1
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:+18129442733@81.31.148.109>
Content-Type: application/sdp
Content-Length: 211

v=0
o=root 19653 19653 IN IP4 1.2.3.4
s=session
c=IN IP4 1.2.3.4
t=0 0
m=audio 14936 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

as a result the ACK messages and BYE messages get sent to an IP 81.31.148.109 in the RIPE number space.
Comments:By: Stefan Schmidt (schmidts) 2010-09-25 00:56:48

i make this private cause i think this could be a security hole.

@leif madsen if iam wrong, sorry ;)
By: Stefan Schmidt (schmidts) 2010-09-25 01:00:26

if i have understood you right, the attacker sends a 200 ok message like above and will get a ACK and a BYE directly after the 200 ok to the contact ip which is set.

AFAIK you could only change the dialogs target ip (from a active call) if you know the real call-id.

By using Pedantic Sip checking this would not be possible cause the Tags had to be right too not only the call-id but pedantic is slow ;)
By: Erik Smith (eeman) 2010-09-25 06:55:24

no, you understand me incorrectly. This isnt theoretical. It really happened. We are a small ITSP who received a complaint about all incoming calls dropping. When we looked at the capture we saw that for some reason the ACK messages to legitimate calls were being sent to 81.31.148.109. When we examined the 200 OK message we found the attackers ip buried in the Contact uri. Thats when we found that this same ip had conducted a brute force sip scan on the box trying every extension from 100 through 9999.
By: Erik Smith (eeman) 2010-09-25 18:06:27

attached an extraction of packet capture that shows all sip messages related to the call.
By: Leif Madsen (lmadsen) 2010-09-27 15:17:34

Isn't this exactly the kind of thing fail2ban is meant to help solve? Based on the amount of incorrect attempts at connecting to Asterisk, fail2ban should kick in an iptables rule that just DROPs all traffic from the originating IP address.

What am I missing here?
By: Leif Madsen (lmadsen) 2010-09-27 15:45:27

You mention there is a DoS here, but you don't mention what is being fully utilized (bandwidth, CPU, I/O, etc...?)

Also, what is Asterisk doing that is not as expected? If someone is sending you a lot of requests and Asterisk is responding to a lot of requests, isn't that normal?

Network control issues are not the problem of Asterisk. That should be dealt with at the network control layer, not the application layer.
By: Erik Smith (eeman) 2010-09-27 17:30:27

either you didn't look at my capture or you're not a SIP guy. In either case I'm slightly offended here because whats going on in the capture is blatantly obvious. One box sent the ACK to the 200 message to the attacker instead of the true recipient. This is the situation..

BoxA (asterisk 1.6.2.13)
BoxB (asterisk 1.4.35)

PieceOfShitC (81.31.148.109)

BoxA and BoxB are Sip Peers

PieceOfShitC begins a scripted sip scan on BoxB, which can be seen in /var/log/asterisk/messages as failed attempts which i have posted examples of.

at some point later BoxA sends a call to BoxB but THE CALL FAILS 100% OF THE TIME. Why? As the capture so blatantly illustrates.. somehow the damn IP of PieceOfShitC is in the Contact header of a legitimate 200 OK packet sent by BoxB to BoxA. This creates a situation where PieceOfShitC hijacks all replies from BoxA that should be sent to BoxB. If this is not the very definition of Denial of Service then what is???? UNTILL I REBOOT BoxB, or restart asterisk, all inbound calls FAIL. This damned PieceOfShitC IP address keeps showing up in the Contact headers of the 200 messages preventing BoxB from ever receiving a call.

From an external view, its as if the attack itself is causing some sort of stack overflow that results in the attackers IP showing up in places it should not.

This may be an unintended side-effect of the use of this script, but penicillin was discovered observing bread mold. It wont be long before this becomes a primary DoS intent if what I am observing is exactly as it appears.
By: Olle Johansson (oej) 2010-09-28 00:55:40

Hi, thanks for writing this report.

According to the bug guidelines, which you got a link to when you filed this report, you need to include output from your asterisk and *NOT* a pcap file. We need to see what goes on in your asterisk. The PCAP doesn't help us much.

I fail to see the code path where an address from a failed registration makes it into a 200 OK as our address (put in the contact) but I guess anything is possible in software :-) It's even more interesting that it ONLY got into the Contact and not into the SDP or the From: header.

Please upload a full SIP debug if you can so that we can analyze this fully and try to help you fix it.
By: Erik Smith (eeman) 2010-10-11 06:41:46

Guys I am getting nowhere getting the client to let me re-create this bug. I have imposed a stop-gap measure by using IPTables rules to disallow all sip traffic except to their upstream provider. I have explained that this will prevent the customer from connecting valid phones from off-site (like when sales people are on the road) and they don't seem to mind (for now, I'm sure when the reality sinks in the situation will change).
By: Olle Johansson (oej) 2010-10-11 06:53:34

ok, I understand. As soon as you or anyone else see this happen again, I'm all ears.
By: Jason Parker (jparker) 2010-10-11 12:43:15

In the meantime..

Do you have an example of the REGISTER that they were sending?  Also, could you provide a copy of the sip.conf from BoxB?
By: Terry Wilson (twilson) 2010-11-09 16:31:36.000-0600

oej: Personally, I love getting PCAP captures in addition to other output. Looking at something with wireshark printing out a ladder diagram and allowing me to easily go to inspect the other packets is quite helpful. I may have to modify the bug guidelines. :-)

eeman: I'm now trying to recreate this issue. Hopefully I'll have an update soon.
By: Olle Johansson (oej) 2010-11-10 00:05:08.000-0600

twilson: The important thing is IN ADDITION. We can't do anything without the output from the console.
By: Terry Wilson (twilson) 2010-11-10 08:09:49.000-0600

oej: Agreed, in addition is definitely best. I just often use the pcaps to recreate the issue in cases like this so I can look at the debugging info myself. :-)
By: Terry Wilson (twilson) 2010-12-08 11:33:59.000-0600

The only way I see this happening is if the call-id of the register matches the call-id of the invite. handle_request_register overwrites p->initreq with the register request immediately, which would cause this problem--but only if find_call() returns matches the register req to that private structure by matching call-id, etc.
By: Terry Wilson (twilson) 2010-12-09 15:56:30.000-0600

Since the only way I can see this happening is if you have to have knowledge of (or somehow astronomically manage to duplicate, which still wouldn't do it if pedantic=yes is set) the Call-ID, I'm not considering this a security issue. For one thing, there are tons of things you can do to mess things up if you aren't using secure signaling and someone can insert valid looking packets. I am committing a patch that should fix this particular problem, though.
By: Digium Subversion (svnbot) 2010-12-09 16:00:32.000-0600

Repository: asterisk
Revision: 297959

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r297959 | twilson | 2010-12-09 16:00:31 -0600 (Thu, 09 Dec 2010) | 14 lines

Ignore spurious REGISTER requests

If a REGISTER request with a Call-ID matching an existing transaction is received
it was possible that the REGISTER request would overwrite the initreq of the
private structure. This info is used to generate messages for other responses in
the transaction. This patch ignores REGISTER requests that match non-REGISTER
transactions.

(closes issue ASTERISK-16730)
Reported by: eeman
Tested by: twilson

Review: https://reviewboard.asterisk.org/r/1050/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=297959
By: Digium Subversion (svnbot) 2010-12-09 16:10:32.000-0600

Repository: asterisk
Revision: 297960

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r297960 | twilson | 2010-12-09 16:10:32 -0600 (Thu, 09 Dec 2010) | 21 lines

Merged revisions 297959 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r297959 | twilson | 2010-12-09 16:00:30 -0600 (Thu, 09 Dec 2010) | 14 lines
 
 Ignore spurious REGISTER requests
 
 If a REGISTER request with a Call-ID matching an existing transaction is received
 it was possible that the REGISTER request would overwrite the initreq of the
 private structure. This info is used to generate messages for other responses in
 the transaction. This patch ignores REGISTER requests that match non-REGISTER
 transactions.
 
 (closes issue ASTERISK-16730)
 Reported by: eeman
 Tested by: twilson
 
 Review: https://reviewboard.asterisk.org/r/1050/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=297960
By: Digium Subversion (svnbot) 2010-12-09 16:18:22.000-0600

Repository: asterisk
Revision: 297965

_U  branches/1.8/
U   branches/1.8/channels/chan_sip.c

------------------------------------------------------------------------
r297965 | twilson | 2010-12-09 16:18:21 -0600 (Thu, 09 Dec 2010) | 28 lines

Merged revisions 297960 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r297960 | twilson | 2010-12-09 16:10:31 -0600 (Thu, 09 Dec 2010) | 21 lines
 
 Merged revisions 297959 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r297959 | twilson | 2010-12-09 16:00:30 -0600 (Thu, 09 Dec 2010) | 14 lines
   
   Ignore spurious REGISTER requests
   
   If a REGISTER request with a Call-ID matching an existing transaction is received
   it was possible that the REGISTER request would overwrite the initreq of the
   private structure. This info is used to generate messages for other responses in
   the transaction. This patch ignores REGISTER requests that match non-REGISTER
   transactions.
   
   (closes issue ASTERISK-16730)
   Reported by: eeman
   Tested by: twilson
   
   Review: https://reviewboard.asterisk.org/r/1050/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=297965
By: Digium Subversion (svnbot) 2010-12-09 16:19:58.000-0600

Repository: asterisk
Revision: 297972

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r297972 | twilson | 2010-12-09 16:19:58 -0600 (Thu, 09 Dec 2010) | 35 lines

Merged revisions 297965 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r297965 | twilson | 2010-12-09 16:18:19 -0600 (Thu, 09 Dec 2010) | 28 lines
 
 Merged revisions 297960 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r297960 | twilson | 2010-12-09 16:10:31 -0600 (Thu, 09 Dec 2010) | 21 lines
   
   Merged revisions 297959 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r297959 | twilson | 2010-12-09 16:00:30 -0600 (Thu, 09 Dec 2010) | 14 lines
     
     Ignore spurious REGISTER requests
     
     If a REGISTER request with a Call-ID matching an existing transaction is received
     it was possible that the REGISTER request would overwrite the initreq of the
     private structure. This info is used to generate messages for other responses in
     the transaction. This patch ignores REGISTER requests that match non-REGISTER
     transactions.
     
     (closes issue ASTERISK-16730)
     Reported by: eeman
     Tested by: twilson
     
     Review: https://reviewboard.asterisk.org/r/1050/
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=297972