On June 8, Yunus Çadırcı, a cybersecurity senior manager at EY Turkey released a whitepaper and proof of concept code repository for a newly discovered vulnerability in the Universal Plug and Play (UPnP) protocol. UPnP is widely used in intranets to facilitate service discovery for many types of devices (printers, televisions, etc.).
The vulnerability, which has been named “CallStranger” has been issued CVE-2020-12695. CallStranger focuses on the “SUBSCRIBE” feature of UPnP, wherein an interested party can request notification of certain events occurring on the UPnP enabled device. The SUBSCRIBE feature allows for the interested party to provide a callback URL which will be requested (using an HTTP “NOTIFY” method) when the event occurs. The problem with this technique is that most UPnP enabled devices do not check the URL in any way. This allows an attacker to insert any URL in this field and the UPnP device will connect to it without validation.
By allowing the attacker to essentially force a connection to an arbitrary URL, CallStranger can be used in three key ways:
- Data Exfiltration: By encoding data to be exfiltrated from a network, an attacker can use a local (to that network) UPnP enabled device to exfiltrate that data. They simply craft a URL that points to a server they control (outside of the network) with the encoded data appended to the end, and set the callback URL of a UPnP SUBSCRIBE command to be that URL. The UPnP device will now exfiltrate data on behalf of the attacker, potentially disguising the fact that the data is leaving the network.
- DDoS Amplification: By setting the callback URL to a URL that the attacker wishes to flood, the UPnP device will amplify the attacker’s SUBSCRIBE traffic by a potentially large amount (see the whitepaper for exact amplification values observed in practice).
- Port Scanning: If a UPnP device is exposed to the Internet, an attacker can use that device to port-scan arbitrary devices inside of the victim’s network.
After reading the whitepaper, we put together a quick Zeek plugin that can detect the first two – data exfiltration, DDoS amplification. The script really highlights the power of Zeek and its ability to process network-related events in Zeek scripts in real time. The script will monitor HTTP traffic and identify if there is any UPnP traffic that looks like CallStranger exploit attempts/successes. If it observes any, it adds a notice in the notice.log with one of the following notice types:
- CallStranger_Data_Exfiltration_Attempt: Observed an attempt to have a UPnP device exfiltrate traffic
- CallStranger_Data_Exfiltration_Success: Observed a UPnP device likely exfiltrating data
- CallStranger_UPnP_Request_Callback_To_External_Host: Observed an attempt to have a UPnP device call back to an external host
- CallStranger_UPnP_To_External_Host: Observed a UPnP device calling back to an external host
Generally speaking, this script shouldn’t cause false positives on most networks. False positives are more likely if your network regularly has UPnP traffic that is Internet-bound. If so, you may have to tune the script accordingly. There are two configuration options to help you with this:
- CallStrangerDetector::exfiltration_threshold: The number of bytes that need to be observed in a UPnP Callback URL in order to be classified as data exfiltration.
- CallStrangerDetector::ignore_subnets: A set of subnets that should be ignored for UPnP detections. Use this if you have false positives where UPnP is traversing the Internet legitimately.
- CallStrangerDetector::strict_upnp_protocol_detection: This boolean controls whether the script will be more strict when trying to identify UPnP SUBSCRIBE commands. It does so by requiring the “NT” (Notification Type) header to be observed. The default is false because the NT header doesn’t actually do anything, it’s just required by the UPnP specification. If you have non-UPnP SUBSCRIBE traffic, you may have to set this to true.
The script also uses your Site::local_nets variable to ignore any internal UPnP traffic. It is recommended that you configure this in your site/local.zeek.
Overall, it’s incredible to see how quickly we can leverage the power of Zeek scripting to create detections for new vulnerabilities. We can also quickly modify our detection if there are any issues or if the vulnerability changes in any way.
Grab the plugin/script from https://github.com/corelight/callstranger-detector.
If you’d like to learn more about Corelight or this prototype detection script, please contact us.
