Latest news

Scanning for accessible CoAP devices

As part of the VARIoT project, consortium partner The Shadowserver Foundation implemented a new CoAP IPv4 scan type and Accessible CoAP report. This blog aims to provide an update to our original blog entry announcing the scans in June 2020 by providing the latest scan results and an EU breakdown of responding hosts.

What is CoAP?

The scan is aimed at uncovering devices that have an exposed CoAP service running on port 5683/UDP. CoAP is a specialized web transfer protocol (similar to HTTP) for use with constrained nodes and constrained networks. As described in RFC 7252, CoAP is designed for use in machine-to-machine (M2M) applications such as smart energy and building automation.

How we scan

We scan by sending out a 21-byte CoAP CoRE Resource Discovery request: we send a CoAP GET request for /.well-known/core to the default port (5693/UDP) on all ~4 billion routable IPv4 addresses every day. The relative URI /.well-known/core acts as the default entry point for requesting the list of links about resources and returns a set of links to available services from the CoAP server (if any) using the CoRE Link Format (RFC 6690). We report only responses that have the CoAP response code set to “Success”. 

What are the main threats associated with exposed CoAP services?

One of the main threats associated with exposed CoAP services is their possible usage as reflectors for DDoS amplification attacks (RDDoS). The average amplification factor of CoAP services has been quantified in the past at around 34. Our average measured response size to the 21-byte payload CoRE Resource Discovery request has been 569 bytes (without UDP overheads), which is roughly 27 times of the inbound request.

We also found that many of these CoAP services can leak information (including authorization credentials to services, such as WiFi networks). For certain devices, in some cases, it may even be possible to issue remote instructions to exposed devices using CoAP. 

There have also been software vulnerabilities in the past in CoAP implementations/libraries which could also potentially be abused for remote code execution on some of these exposed devices. 

An in-depth study of CoAP (and MQTT) security considerations can be found in a paper published by Trend Micro.  

Latest results
Our production scan when first enabled in the second half of June uncovered over 464 000 responding IPv4 hosts.  This number has been steadily decreasing since that time. A scan for the 12th of August 2020 shows 387,642 hosts responding.

      CoAP Scan Results per Day Over Time by Continent

Top Countries with Accessible CoAP Services (20th June 2020)

Philippines, China and Russia had the most hosts accessible on the 20th of June 2020. This is still the case, but the numbers for China and Russia have dropped noticeably. As discovered earlier, the predominant CoAP responses returned in the Philippines and China show Qlink resources (now rebranded as QLC Chain)  a “next generation public chain for Network-as-a-Service (NaaS).” In Russia (and the Ukraine), most of the CoAP responses are from devices apparently containing NDM Systems embedded software (described on its website as “a smart router software company”).

Top Countries with Accessible CoAP Services (12th August 2020)

In the EU (+UK), the numbers have been more steady:

      CoAP Scan Results Over Time (EU + UK)

Accessible CoAP IPv4 hosts per country (12th August 2020).

The numbers are significantly lower than in Asia or Russia. Italy and Germany have the most exposed CoAP services in the EU. A few hosts in Germany appear to have NDM Systems software, but the numbers are much smaller than in Russia, Ukraine or Belarus:

Top Countries with Accessible CoAP services (EU +UK) 12th August 2020

Accessible CoAP Report

A new accessible CoAP report has been shared with the Internet defender community since the second half of June 2020 (currently 112 National CSIRTs and 5800+ network owners worldwide) as part of Shadowserver daily free threat feeds. The format is as follows:

FieldDescription
timestampTime that the IP was probed in UTC+0
ipIP of the device in question
protocolProtocol that the CoAP response used (UDP)
portPort responding with CoAP response  (usually 5683)
hostnameReverse DNS name of the device in question
tagSet to coap
asnASN of where the device in question resides
geoCountry where the device in question resides
regionState / Province / Administrative region where the device in question resides
cityCity where the device in question resides
naicsNorth American Industry Classification System Code
responseBlob of the decoded CoAP response to the resource discovery probe. This should typically be in the CoRE Link Format as described in RFC6690.

A sample of what is being sent out on a daily basis looks as follows:

"timestamp","ip","protocol","port","hostname","tag","asn","geo","region","city","naics","sic","response"
"2020-06-20 01:21:27","192.0.2.5","udp",5683,"dsl.192.0.2.0.pldt.net","coap",9299,"PH","NUEVA ECIJA","DEL PILAR",517311,,";title=""General Info"";ct=0,;title=qlink/searchfh,;title=qlink/searchgw,;title=qlink/request,;title=qlink/success,;title=device/inform/bootstrap,;title=device/inform/boot,;title=device/inform/syncreq,;title=device/inform/offline,;title=device/inform/heartbeat,;title=device/inform/data,;ct=0"
"2020-06-20 01:21:27","192.0.2.10","udp",5683,"192.0.2.10.static.pldt.net","coap",9299,"PH","MANILA","MANILA",517311,,";title=""General Info"";ct=0,;title=qlink/searchfh,;title=qlink/searchgw,;title=qlink/request,;title=qlink/success,;title=device/inform/bootstrap,;title=device/inform/boot,;title=device/inform/syncreq,;title=device/inform/offline,;title=device/inform/heartbeat,;title=device/inform/data,;ct=0"
"2020-06-20 01:21:27","198.51.100.77","udp",5683,,"coap",38917,"RU","IVANOVSKAYA OBLAST","IVANOVO",0,,",,,,,,,"
"2020-06-20 01:21:27","203.0.113.111","udp",5683,"dsl.203.0.113.0.pldt.net","coap",9299,"PH","LANAO DEL NORTE","BUNAWAN",517311,,";title=""General Info"";ct=0,;title=qlink/searchfh,;title=qlink/searchgw,;title=qlink/request,;title=qlink/success,;title=device/inform/bootstrap,;title=device/inform/boot,;title=device/inform/syncreq,;title=device/inform/offline,;title=device/inform/heartbeat,;title=device/inform/data,;ct=0"
"2020-06-20 01:21:27","203.0.113.55","udp",5683,,"coap",9808,"CN","JIANGXI SHENG","NANCHANG",517312,,",;title=""Qlink-ACK Resource"",;title=""Qlink-Request Resource"",;title=""SearchGW Resource"",;title=""Qlink-Success Resource"",;title=""Qlink-WLAN Resource"",,,;title=""Connect To Diagnotor"",;title=""Inform Data Resource"",;title=""config-properties Resource"",,;title=""Qlink-Regist Resource"",;title=""Qlink-SHOW Resource"",,,;title=""Device Control Resource"",;title=""Control Data Resource"",,;title=""Boot-Request Resource"",;title=""bootstrap-Request Resource"",;obs;title=""Inform Data Resource"",;title=""HeartBeat Resource"",;title=""ChildDevice Offline Resource"","
"2020-06-20 01:21:27","203.0.113.240","udp",5683,,"coap",56046,"CN","JIANGSU SHENG","YANGZHOU",517312,,",;title=""Qlink-ACK Resource"",;title=""Qlink-Request Resource"",;title=""SearchGW Resource"",;title=""Qlink-Success Resource"",;title=""Qlink-WLAN Resource"",,,;title=""Connect To Diagnotor"",;title=""Inform Data Resource"",,;title=""Basic-heartbeat Resource"",;title=""Qlink-Regist Resource"",;title=""Qlink-SHOW Resource"",,,;title=""Device Control Resource"",;title=""Control Data Resource"",,;title=""Boot-Request Resource"",;title=""bootstrap-Request Resource"",;obs;title=""Inform Data Resource"",;title=""HeartBeat Resource"",;title=""ChildDevice Offline Resource"","

What can be done to improve the security of the exposed instances?

We hope that the data being shared in our new accessible CoAP device report will lead to a reduction in the number of exposed CoAP-aware devices on the Internet, as well as raise awareness to the dangers of exposing such devices to unauthenticated scanners/attackers.  As described in RFC 7252:

 “CoAP itself does not provide protocol primitives for authentication or authorization; where this is required, it can either be provided by communication security (i.e., IPsec or DTLS) or by object security (within the payload)”. 

While the RFC makes a number of provisions for securing CoAP (elaborating on the above), it is unclear how many of these have actually been adopted in practice. At the very least CoAP instances should therefore be either firewalled to only communicate with necessary devices and/or DTLS (Datagram Transport Layer Security) with certificates employed where possible.   

How can I receive the free new daily CoAP report?

Details about the format of the new report being shared can be found in the new Accessible CoAP Report page. All existing Shadowserver report subscribers are now automatically receiving the Accessible CoAP Report if any exposed CoAP services are identified within their networks and countries (for national CSIRTs). If you do not receive Shadowserver CoAP feeds, please sign up to our free daily public benefit network remediation feed service

You can also check the updated statistics for this scan on our dedicated CoAP scan page.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *