Decoding SIP Register Hack

Home » Asterisk Users » Decoding SIP Register Hack
Asterisk Users 6 Comments

I need some help understanding SIP dialog. Some actor is trying to access my server, but I can’t figure out what he’s trying to do ,or how.

I’m getting a lot of these warnings.

[May 17 10:08:08] WARNING[1532]: chan_sip.c:4068 retrans_pkt:
Retransmission timeout reached on transmission
_zIr9tDtBxeTVTY5F7z8kD7R.. for seqno 101

With SIP DEBUG I tracked the Call-ID to this INVITE :

<--- SIP read from UDP:192.111.139.146:29281 --->
INVITE sip:+48223079992@67.80.191.250:5060 SIP/2.0
Via: SIP/2.0/UDP
100.149.241.68:5060;branch=z4hG4bK-966187-1—q9ft4HdLB4ZeBqs;rportP60
Contact:
;+sip.instance=””
Max-Forwards: 70
To: :5060>
From: “Caller”:5060>;tag=sXPNixD5Ui42V
Call-ID: _zIr9tDtBxeTVTY5F7z8kD7R.. CSeq: 101 INVITE
Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
Supported: replaces User-Agent: GSM
Allow-Events: hold, talk, conference Accept: application/sdp Content-Length: 771

v=0
o=CiscoSystemsSIP-IPPhone 18338 11953 IN IP4 100.149.241.68
s=SIP Call c=IN IP4 100.149.241.68
t=0 0
m=audio 20000 RTP/AVP 0 8 18 101
a=rtpmap:3 gsm/8000
a=rtpmap:96 speex/8000
a=rtpmap:97 speex/8000
a=fmtp:97 mode=2
a=rtpmap:98 speex/8000
a=fmtp:98 mode=5
a=rtpmap:99 speex/8000
a=fmtp:99 mode=7
a=rtpmap:107 speex/32000
a=fmtp:107 mode
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:108 ilbc/8000
a=rtpmap:113 g7231/8000
a=rtpmap:18 g729/8000
a=rtpmap:100 G726-16/8000
a=rtpmap:101 G726-24/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:103 G726-40/8000
a=rtpmap:4 g723/8000
a=fmtp:18 annexb=no a=rtpmap:109 ilbc/8000
a=fmtp:109 mode a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=ptime:20
a=sendrecv
<------------->
— (15 headers 34 lines) –

6 thoughts on - Decoding SIP Register Hack

  • I’m happy with Fail2Ban protecting my Asterisk 13. Here is my configuration:

    in /etc/asterisk/logger.conf:

    messages => security,notice,warning,error

    in /etc/asterisk/sip.conf:

    allowguest=yes context=unauthenticated

    in /etc/asterisk/extensions.conf:

    [unauthenticated]
    ;; Incomming calls from unauthenticated caller -> Fail2Ban exten => _X.,1,Log(WARNING,fail2ban=’${CHANNEL(peerip)}’)

  • Thanks. Very useful as a tutorial for fail2ban.

    But I don’t think it covers this SIP hack. This guy isn’t trying to register. That why I find it puzzling. What is he trying to do ?

    sean

    —

  • His filter doesn’t only trigger on REGISTERs, see the last line of the matches and the context for guests (which logs the pattern of the last line of the filter on an INVITE).

    There are sip servers publicly reachable that will relay INVITEs, make sure yours aren’t. And there are only 2 kinds of operators of sip server:
    -those that have been the victim of toll fraud
    -those that will be the victim of toll fraud

    You can do nothing to stop this kind of traffic. The only thing you can do is block it, either using only a whitelist (cumbersome) or generate a blacklist with for example fail2ban or a more elaborate honeypot setup. Or setup a proxy that will filter patterns you discover from

    BTW this is not a person, this is an automated script, running most likely on compromised machines and sending spoofed ips. These scripts care about generating a ring on a phone (again most an abuseable/hacked account (or purchased with CC fraud)). If they find a server that does, it will be targetted for all kind of fraud.

  • Keep in mind that since this is UDP, source addresses can be spoofed so any automated solution will need a whitelist so you don’t get tricked into blocking legitimate traffic.

    And since you ‘need a whitelist’ why not just use that and block everything else?

    A clever solution to a mobile user base is to use knockd to allow remote access.

  • I’m far from a regex expert, but I don’t think that last line would capture anything in the invite. In fact, asterisk doesn’t throw any WARNING at all for this INVITE.

    I’m not sure, but I don’t even see how you can get asterisk to log these invites at all. There’s no heading such as WARNING( or NOTICE, SECURITY, etc).

    Very interesting.

    sen

    —

  • I found these by staring at sip debug, and tying together the SIP
    retransmission id with the INVITE. That was an afternoon! Is there any way to automate this ? Specifically, find the INVITE that generates the retransmission ?

    Otherwise, I can’t see how anyone could block these attempts.

    > There are sip servers publicly reachable that will relay INVITEs, make
    > sure yours aren’t.

    How do I make sure my server won’t relay INVITEs ?

    sean

    —