Vulnerabilities > CVE-2018-3918 - Improper Enforcement of Message or Data Structure vulnerability in Samsung Sth-Eth-250 Firmware 0.20.17

047910
CVSS 7.5 - HIGH
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
NONE
Integrity impact
HIGH
Availability impact
NONE
network
low complexity
samsung
CWE-707

Summary

An exploitable vulnerability exists in the remote servers of Samsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17. The hubCore process listens on port 39500 and relays any unauthenticated messages to SmartThings' remote servers, which incorrectly handle camera IDs for the 'sync' operation, leading to arbitrary deletion of cameras. An attacker can send an HTTP request to trigger this vulnerability.

Vulnerable Configurations

Part Description Count
OS
Samsung
1
Hardware
Samsung
1

Common Attack Pattern Enumeration and Classification (CAPEC)

  • XML Injection
    An attacker utilizes crafted XML user-controllable input to probe, attack, and inject data into the XML database, using techniques similar to SQL injection. The user-controllable input can allow for unauthorized viewing of data, bypassing authentication or the front-end application for direct XML database access, and possibly altering database information.
  • Using Leading 'Ghost' Character Sequences to Bypass Input Filters
    An attacker intentionally introduces leading characters that enable getting the input past the filters. The API that is being targeted, ignores the leading "ghost" characters, and therefore processes the attackers' input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API. Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes. One commonly used possibility involves adding ghost characters--extra characters that don't affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations.
  • HTTP Request Smuggling
    HTTP Request Smuggling results from the discrepancies in parsing HTTP requests between HTTP entities such as web caching proxies or application firewalls. Entities such as web servers, web caching proxies, application firewalls or simple proxies often parse HTTP requests in slightly different ways. Under specific situations where there are two or more such entities in the path of the HTTP request, a specially crafted request is seen by two attacked entities as two different sets of requests. This allows certain requests to be smuggled through to a second entity without the first one realizing it.
  • HTTP Response Splitting
    This attack uses a maliciously-crafted HTTP request in order to cause a vulnerable web server to respond with an HTTP response stream that will be interpreted by the client as two separate responses instead of one. This is possible when user-controlled input is used unvalidated as part of the response headers. The target software, the client, will interpret the injected header as being a response to a second request, thereby causing the maliciously-crafted contents be displayed and possibly cached. To achieve HTTP Response Splitting on a vulnerable web server, the attacker:
  • Using Alternative IP Address Encodings
    This attack relies on the attacker using unexpected formats for representing IP addresses. Networked applications may expect network location information in a specific format, such as fully qualified domains names, URL, IP address, or IP Address ranges. The issue that the attacker can exploit is that these design assumptions may not be validated against a variety of different possible encodings and network address location formats. Applications that use naming for creating policy namespaces for managing access control may be susceptible to being queried directly by IP addresses, which is ultimately a more generally authoritative way of communicating on a network. Alternative IP addresses can be used by the attacker to bypass application access control in order to gain access to data that is only protected by obscuring its location. In addition this type of attack can be used as a reconnaissance mechanism to provide entry point information that the attacker gathers to penetrate deeper into the system.

Seebug

bulletinFamilyexploit
description### Summary An exploitable vulnerability exists in the remote servers of Samsung SmartThings Hub. The `hubCore` process listens on port 39500 and relays any unauthenticated messages to SmartThings' remote servers, which incorrectly handle camera IDs for the "sync" operation, leading to arbitrary deletion of cameras. An attacker can send an HTTP request to trigger this vulnerability. ### Tested Versions Samsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17 ### Product URLs [https://shop.smartthings.com/products/samsung-smartthings-hub](https://shop.smartthings.com/products/samsung-smartthings-hub) ### CVSSv3 Score 6.5 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H ### CWE CWE-156: Improper Neutralization of Whitespace ### Details Samsung produces a series of devices aimed at controlling and monitoring a home, such as wall switches, LED bulbs, thermostats and cameras. One of those is the Samsung SmartThings Hub, a central controller that allows an end user to use their smartphone to connect to their house remotely and operate other devices through it. The hub board utilizes several systems on chips. The firmware in question is executed by an i.MX 6 SoloLite processor (Cortex-A9), which has an ARMv7-A architecture. The firmware is Linux-based, and runs a series of daemons that interface with devices nearby via ethernet, ZigBee, Z-Wave and Bluetooth protocols. Additionally, the `hubCore` process is responsible for communicating with the remote SmartThings servers via a persistent TLS connection. These servers act as a bridge that allows for secure communication between the smartphone application and the hub. End users can simply install the SmartThings mobile application on their smartphone to control the hub remotely. One of the features of the hub is that it connects to smart cameras, configures them and looks at their livestreams. For testing, we set up the Samsung SmartCam SNH-V6414BN on the hub. Once done, the livestream can be displayed by the smartphone application by connecting either to the remote SmartThings servers, or directly to the camera, if they're both in the same subnetwork. Inside the hub, the livestream is handled by the `video-core` process, which uses `ffmpeg` to connect via RTSP to the smart camera in its same local network, and at the same time, provides a streamable link for the smartphone application. The remote SmartThings servers have the possibility to communicate with the `video-core` process by sending messages in the persistent TLS connection, established by the `hubCore` process. These messages can encapsulate an HTTP request, which `hubCore` would relay directly to the HTTP server exposed by `video-core`. The HTTP server listens on port 3000, bound to the localhost address, so a local connection is needed to perform this request. While analyzing the `video-core` process, we identified the following traffic on port 39500, generated by `video-core` when requesting the "/sync" path [1]: [1] sync request $ curl "http://127.0.0.1:3000/sync" [2] video-core -> 127.0.0.1:39500 (hubCore) POST /videocore HTTP/1.1 Host: 127.0.0.1:39500 Accept: */* Content-Type: application/json X-ST-Application: Video-Core X-ST-Version: 1.5.3 Content-Length: 82 {"videoRequestType":"sync","cameraIds" : ["<camera-id1>", "<camera-id2>"]} [3] hubCore -> SmartThings server (dc.connect.smartthings.com:443) < sends a message embedding the HTTP request above > [4] SmartThings server (dc.connect.smartthings.com:443) -> hubCore < sends a message embedding the following HTTP response > HTTP/1.1 202 ACCEPTED Connection: close [5] 127.0.0.1:39500 (hubCore) -> video-core < forwards the HTTP response above > The `hubCore` process listens on port 39500, bound to "0.0.0.0", and simply forwards the HTTP request [2] to the remote Samsung SmartThings servers [3], which answer with [4]. The answer is finally forwarded back to the client [5]. Note that being `hubCore` bound to "0.0.0.0", request [1] could be omitted and request [2] could be initiated by anyone in the network, without any prior authentication. In essence, the "sync" request [1] is used to make sure that the remote servers and `video-core`'s internal database are synchronized. All camera IDs known by `video-core` are included in the JSON string, and if `video-core` contains a `camera-id` which doesn't exist in the remote servers, it will be deleted. Continuing on the example, if `camera-id2` is not found by the remote servers, the following traffic can be seen: [6] SmartThings server (dc.connect.smartthings.com:443) -> hubCore < sends a message embedding the following HTTP request > DELETE /cameras/<camera-id2> HTTP/1.1 Accept: */* User-Agent: Linux UPnP/1.0 SmartThings Content-Type: application/json Connection: Close Host: 127.0.0.1:3000 [7] hubCore -> 127.0.0.1:3000 (video-core) < forwards the HTTP request above > [8] 127.0.0.1:3000 (video-core) -> hubCore HTTP/1.1 204 No Content Server: Video-Core X-ST-Application: Video-Core X-ST-Version: 1.5.3 Connection: close Content-Length: 0 Request [6] is sent by the remote Samsung SmartThings servers over the persistent TLS connection, and is thus received by the `hubCore` process, which blindly forwards it to `video-core`'s HTTP server on port 3000 [7]. Request [8] is simply the answer of `video-core` to the "DELETE" request. To summarize, the flow of events when a deletion is going to take place is: |______Sender______|___________________Hub___________________|___SmartThings Servers___ | | | [2] | sync request ---|--> hubCore:39500 | | with JSON M1 | | [3] | | hubCore sends --|--> process JSON M1 | | JSON M1 | | | | [4] | | hubCore <--|--- send HTTP response | | | M2 (ACCEPTED) [5] | terminate <--|--- hubCore:39500 | | connection | forwards M2 | | | | [6] | | hubCore <--|--- generate and send | | | HTTP request M3 | | | | [7] | | video-core:3000 <--|--- hubCore sends | | | | HTTP request M3 | | | | | [8] | | video-core:3000 ---|--> hubCore | | | | | Where "Sender" can either be the hub itself (that is `video-core`, as shown in request [2]) or anyone in the network. As we can see, a portion of request [2] is included in request [6]: the `<camera-id2>`. In fact, it is first present in message M1, and is then propagated till `video-core` where it is sent inside M3. We noticed that the remote server does not strip whitespace characters appended to the `<camera-id>` values sent in M1. This causes the remote servers to fail, recognizing an existing camera, which in turn, initiates the deletion procedure for the requested camera ID. The `<camera-id>` will be inserted in M3 without modifications (that is, if it is still including any whitespace character), which will be discarded by `video-core`'s HTTP server. Thus, by appending one or more spaces at the end of a valid camera ID, anyone would be able to delete a camera from the hub without authentication. Moreover, note that if message M1 only contains camera IDs unknown to the remote servers, the denial of service would not be permanent and an attacker would need to send the "sync" message continuously. In fact, in this case remote servers, noticing that the the hub would have an empty camera list, will re-add all cameras known remotely by sending a "POST /cameras" request following request [8]. We found two different ways to avoid this: - Sending multiple "sync" requests in a short time could hit a race condition between the deletion and the creation of the camera. In this case, the creation request is discarded and the hub is left without any camera. - Sending the same camera ID twice in the same request, adding a space to the last camera ID. This will trick the servers into not sending the creation request because the hub is thought to still have a valid camera ID (the first one), while requesting for the deletion of the second camera ID (equal to the first one plus a whitespace). An example is shown in the proof of concept below. ### Exploit Proof of Concept The following proof of concept shows how to delete an arbitrary camera, given its "cameraId". $ curl -i -X POST "http://${hubIP}:39500/videocore" -d '{"videoRequestType":"sync","cameraIds" : ["'${sCameraId}'", "'${sCameraId}' "]}' The request received by `video-core` is: DELETE /cameras/<cameraId> HTTP/1.1 Accept: */* User-Agent: Linux UPnP/1.0 SmartThings Content-Type: application/json Connection: Close Host: 127.0.0.1:3000 Notice the additional space between the camera ID and the "HTTP/1.1" string, which will be discarded by the HTTP server. ### Timeline * 2018-04-25 - Vendor Disclosure * 2018-05-23 - Discussion with vendor/review of timeline for disclosure * 2018-07-17 - Vendor patched * 2018-07-26 - Public Release
idSSV:97454
last seen2018-07-31
modified2018-07-30
published2018-07-30
reporterMy Seebug
titleSamsung SmartThings Hub hubCore port 39500 sync denial-of-service vulnerability(CVE-2018-3918)

Talos

idTALOS-2018-0582
last seen2019-05-29
published2018-07-26
reporterTalos Intelligence
sourcehttp://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0582
titleSamsung SmartThings Hub hubCore port 39500 sync denial-of-service vulnerability