Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

SPA112 SIP brute force attack

Last week, my SPA112 was suddenly unable to receive incoming calls. The LAN traffic light was flashing continuously and SIP stats were showing over 1 GB data received per day.

My VOIP provider, CallCentric, ran through several troubleshooting steps over the course of a day but was unable to resolve the issue.

I discovered that the SPA112 device was the victim of a SIP brute force attack.

I initially assigned the device to a new IP address, which restored my ability to receive calls, but the attack on the original IP address continued. The UDP traffic was flooding my DSL connection.

I was able to reconfigure my router to drop the incoming traffic, but as an experiment, I reassigned the attacked IP address to a PC and used Wireshark to discover what the packets were and where they were coming from. In the following trace, I have replaced the attacker's IP address with <ATTACKER-IP> and the SPA112's IP address (attacked address) with <SPA112-IP>.

No.     Time        Source                Destination           Protocol Length Info

  34002 222.535423  <ATTACKER-IP>        <SPA112-IP>         SIP      401    Request: REGISTER sip:<SPA112-IP>

Frame 34002: 401 bytes on wire (3208 bits), 401 bytes captured (3208 bits)

Ethernet II, Src: Motorola_fc:d5:10 (00:1c:fb:fc:d5:10), Dst: HewlettP_b9:da:59 (18:a9:05:b9:da:59)

Internet Protocol Version 4, Src: <ATTACKER-IP> (<ATTACKER-IP>), Dst: <SPA112-IP> (<SPA112-IP>)

User Datagram Protocol, Src Port: alesquery (5074), Dst Port: sip (5060)

Session Initiation Protocol

    Request-Line: REGISTER sip:<SPA112-IP> SIP/2.0

        Method: REGISTER

        Request-URI: sip:<SPA112-IP>

        [Resent Packet: False]

    Message Header

        Via: SIP/2.0/UDP 127.0.0.1:5074;branch=z9hG4bK-3910607681;rport

        Content-Length: 0

        From: "3775708062" <sip:3775708062@<SPA112-IP>>

            SIP Display info: "3775708062"

            SIP from address: sip:3775708062@<SPA112-IP>

                SIP from address User Part: 3775708062

                SIP from address Host Part: <SPA112-IP>

        Accept: application/sdp

        User-Agent: friendly-scanner

        To: "3775708062" <sip:3775708062@<SPA112-IP>>

            SIP Display info: "3775708062"

            SIP to address: sip:3775708062@<SPA112-IP>

                SIP to address User Part: 3775708062

                SIP to address Host Part: <SPA112-IP>

        Contact: sip:123@1.1.1.1

            Contact-URI: sip:123@1.1.1.1

        CSeq: 1 REGISTER

        Call-ID: 211458778

        Max-Forwards: 70

I googled the packet contents and discovered the attacker was likely using "SIPvicious" (as evidenced by "friendly-scanner").

I was able to use the Ruby script on the following web site to stop the SIP brute force attack.

http://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/

I replaced

s.bind(nil, 5061)

with

s.bind("<SPA112-IP>",5060)

and ran the script with

ruby stopsip.rb

Sure enough, the traffic stopped, and has not returned.

Here's the entire script. Replace <SPA112-IP> with the attacked IP address.

[stopsip.rb]

require "socket"

s = UDPSocket.new

s.bind("<SPA112-IP>",5060)

while true

  packet = s.recvfrom(1024)

  via = packet[0].match(/Via: (.+);rport/)[1]

  from = packet[0].match(/From: (.+)/)[1]

  to = packet[0].match(/To: (.+)/)[1]

  call_id = packet[0].match(/Call-ID: (.+)/)[1]

  cseq = packet[0].match(/CSeq: (\d+) REGISTER/)[1]

  remote_ip = packet[1][3]

  remote_port = packet[1][1].to_i

  puts packet.inspect

  if packet[0].match(/^REGISTER /)

    ret = "SIP/2.0 200 OK\r\n" +

      "Via: #{via};received=#{remote_ip}\r\n" +

      "From: #{from}\r\n" +

      "To: #{to}\r\n" +

      "Call-ID: #{call_id}\r\n" +

      "CSeq: #{cseq.to_i + 1} REGISTER\r\n" +

      "\r\n"

    puts "sending to #{remote_ip}:#{remote_port}:\n#{ret}"

    s.send(ret, 0, remote_ip, remote_port)

  end

end

I have since discovered an option on the SPA112, under Voice, Line 1, called Restrict Source IP. It was set to No (default), and I have changed it to Yes. We'll see if this option helps avoid future attacks. At least I know what to do next time.

2 REPLIES
New Member

SPA112 SIP brute force attack

Thanks for the info.

For others, who want the info on the Restrict Source IP, the admin guide states...

If Lines 1 and 2 use the same SIP Port value and the

Restrict Source IP feature is enabled, the proxy IP address

for Lines 1 and 2 is treated as an acceptable IP address for

both lines. To enable the Restrict Source IP feature, select

yes. Otherwise, select no. If configured, the PAP2T will

drop all packets sent to its SIP Ports originated from an

untrusted IP address. A source IP address is untrusted if it

does not match any of the IP addresses resolved from the

configured Proxy (or Outbound Proxy if Use Outbound

Proxy is yes).

The default is no.

New Member

SPA112 SIP brute force attack

Very Interesting!  Good to know. 

I just set my SPA2102 to Restrict Source IP to see if I notice any issues. 

Tks for bringing this up.

2746
Views
0
Helpful
2
Replies