SIP options module broken

h00die commented 5 years ago

option_tcp seems to be fine:

msf5 auxiliary(scanner/sip/options_tcp) > run

[*] 2.2.2.2:5060    - 2.2.2.2:5060 tcp SIP/2.0 200 OK: {"Server"=>"Cisco-SIPGateway/IOS-12.x", "Allow"=>"INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, $
[*] 2.2.2.2:5060    - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

but I don't get any UDP love:

msf5 auxiliary(scanner/sip/options) > run

[*] Sending SIP UDP OPTIONS requests to 2.2.2.2 ->2.2.2.2 (1 hosts)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

I can verify the service is good via nmap:

nmap --script=sip-methods -sU -p 5060 2.2.2.2

Starting Nmap 7.70 ( https://nmap.org ) at 2018-10-11 15:50 EDT
Nmap scan report for 2.2.2.2
Host is up (0.0035s latency).

PORT     STATE SERVICE
5060/udp open  sip
|_sip-methods: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Loaded up wireshark. Request goes out fine:

OPTIONS sip:nobody@2.2.2.2 SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK.ae2be03f;rport;alias
From: sip:Vkzf@1.1.1.1:5060;tag=70c00e8c
To: sip:nobody@2.2.2.2
Call-ID: 2546895629@1.1.1.1
CSeq: 1 OPTIONS
Contact:  sip:Vkzf@1.1.1.1:5060
Max-Forwards: 20
User-Agent: Vkzf
Accept: application/sdp
Content-Length: 0

Response comes back:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK.ae2be03f;rport;alias
From: sip:Vkzf@1.1.1.1:5060;tag=70c00e8c
To: sip:nobody@2.2.2.2;tag=14697EA4-1400
Date: Fri, 07 Jan 2000 19:48:21 GMT
Call-ID: 2546895629@1.1.1.1
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 OPTIONS
Supported: 100rel,resource-priority,replaces
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 172

v=0
o=CiscoSystemsSIP-GW-UserAgent 4302 4092 IN IP4 2.2.2.2
s=SIP Call
c=IN IP4 2.2.2.2
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3
c=IN IP4 2.2.2.2

however it doesn't seem to process. I added a hook to see if it was the response was coming back and not being caught, or a processing bug... never got any output so it looks like its a pre-sip response processor issue.

  def scanner_process(data, shost, _)
    print_good(data.to_s)
    report_response(data, shost, 'udp')
  end

busterb commented 5 years ago

Did you try running as root?

h00die commented 5 years ago

yup, default root on kali.

github-actions[bot] commented 3 years ago

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

bcoles commented 3 years ago

Removing the stale label. I'm not sure if this is still an issue. Someone who isn't me should probably take a look at this.

rapid7 / metasploit-framework

SIP options module broken #10796