[nsp-sec] SSDP amp Scanner results

[Schiel, John]

I was able to pull down the script from http://packetstormsecurity.com/files/127994/SSDP-Amplification-Scanner.html and give it a run. It's fairly simple to run but the script could use some tweaking to provide some verbosity or status. More than once when I ran it, I couldn't Cntrl-C the script to stop it, I had to kill it instead.

The script does have the important piece of this whole SSDP amplification which is:

    data = "M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: \"ssdp:discover\"\r\nMX: 2\r\nST: ssdp:all\r\n\r\n"

Or:

        M-SEARCH * HTTP/1.1\r\n
            Host: 239.255.255.250:1900\r\n
            Man: "ssdp:discover"\r\n
            MX: 3\r\n
            ST: ssdp:all\r\n  <--- this is the fun part.
            \r\n

I ran the script against my CenturyLink modem at home and didn't get a response, whew,  so I used an alternate IP I know of that was responding to these ssdp:all discovery requests. I found that the IP I used in the ssdp-amp script was returning 11 separate services available on the modem.

I've attached the output from following the UDP stream in Wireshark for the 11 segments. Each service has a unique USN id as required by the UPnP protocol so you'll see the first and last segments do both contain "uuid:WANConnection" as part of the USN but the whole USN is unique so the service is thus unique.

Using just these 11 segments, the attack on our network was a 24X amplification. This was ONE IP and does not represent the full amplification factor for these types of attacks. I would trust the US-CERT numbers if you are looking for amplification factors.

>From my research, I'm speculating the attackers are submitting multiple ssdp:all discovery requests to the same modem and it happily responds to all requests. I've not yet found any limits so I'm not sure if there are any limits at this time.

These types of attacks are going to occur for a while in my opinion. I've been on the testing side of modems before and I know how slow the firmware updates can go at times. In addition, the majority of modems affected are in CN, https://ssdpscan.shadowserver.org/, and  I suspect those will be around for a very long time.

I bookmarked a few reference docs that were helpful in getting a handle on this issue.

US-CERT Alert (TA14-017A)
https://www.us-cert.gov/ncas/alerts/TA14-017A

UPnP Device Architecture 1.0 (rev. 15-Oct-2008)
http://www.broadband-forum.org/technical/download/TR-064.pdf

TECHNICAL REPORT
DSL Forum
TR-064
LAN-Side DSL CPE Configuration (May-2004)
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20081015.pdf

(Yeah, I know, PDF, but I couldn't find anything else. )

Happy hunting.

John A Schiel
Security Architect




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



The content contained in this electronic message is not intended to constitute formation of a contract binding tw telecom. tw telecom will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: raw-ssdp-amp-results-from-pcap.txt
URL: <https://puck.nether.net/mailman/private/nsp-security/attachments/20141003/75f94fd0/attachment-0001.txt>