If ( ! sub_52C44(( int)&unk_A5A78, &v6) )Īs one can see, the destination buffer is defined as big as 64 bytes, which means that if the value provided for the key 'remoteIp' is longer than 64 characters, the function 'get_value_key' will overflow the buffer v6. Signed int _fastcall executeCGICmd( int a1, const char *a2)Ĭonst char *v2 // r4 int v3 // r8 int v5 // r0 char v6 // char v7 // char v8 // char s // int v10 // The snippet of the function that retrieves its value, by calling the get_value_key function, is reported below: Other bugs related to the GET keywords 'pid', 'pwd' and 'usr' were assigned to CVE-2018-12640.Īmong the GET keys accepted by the web-server, there is one called 'remoteIp'. For space reasons, and because the exploits look all very similar, here I will report only one of them, for which the CVE-2018-11560 was assigned. We only tested and successfully verified only a bunch of them. Overall there are 789 different instances of this function being called, possibly meaning 789 different unique vulnerabilties. Therefore, one could potentially provide a value for a the 'usr' key long enough to overwrite any provided destination buffer.įirst off, we will retrieve the list of the keywords the firmware accepts, by looking for all the cross-references to the above function, and retrieving the passed keywords. The problem here, is that the length of the destination buffer is not provided, let alone check.
INSTEON CAMERA SETUP WITHOUT HUB CODE
Key_val_ptr = strstr(user_URI, ( const char *)&tmp_buff) Īssign_ptr = &key_val_ptr Ĭurrent_char = ( unsigned _int8)assign_ptr Īs we can see, the above code parses a given URI, searches for the GET key (e.g., 'usr'), skips the '=' characters and finally copy the value associate with the considered key in a provided destination buffer. Signed int _fastcall get_value_key( const char *user_URI, const char *key_word, _BYTE *dst_buff)īool v3 // zf signed int counter // r7 char *key_val_ptr // r0 signed int result // r0 const char *assign_ptr // r5 signed int assign_len // r0 int current_char // r3 const char *val_ptr // r5 signed int val_len // r0 signed int i // r3 int c // r2 int tmp_buff // In particular, we looked for the keyword 'usr' as in 'usr=root', and after finding it, we retrieved all the functions refercing such string.Īfter looking at each one of these function, we found the one we were looking for, whose code is reported below. To do this we looked for the known GET keywords we observed during the traffic sniffing phase. Once opened with the IDA decompiler, we proceeded in finding the function parsing the URIs parameters. With these information in mind, we downloaded the firmware and successfully decrypted it with one of the known Foscam used passwords.Īfter looking at the contained binary files, it became clear that the camera mounts an ARM architecture.Īmong these, we identified the binary named webService, as the binary handling the user-provide requests.
We then wanted to get our hands on the firmware mounted on the camera.Īfter some research, we found that: 1) the camera firmware is publicly avilable, though encrypted and 2) the Insteon camera is a rebrand of Foscam. Note also that, the credentials are transmitted in clear text. We then opened wireshark to sniff the traffic between the Insteon app and the camera, and we found, as we can see from the picture below, that the HTTP interface was still active and responding. Traffic AnalysisĪccording on the Insteon WiFI camera manual, this camera provides an HTTP web interface, which can be accessed at Though we tried with all the Internet browsers we could think of (Google Chrome, IE, Firefox, Opera and Safari, lynx), we weren't able to log into the camera to see the video stream.Īfter calling the Insteon support, we were told that the necessary browser plugins to login using a web browser were not maintained anymore. In this brief blogpost we will exploit the Insteon HD Wifi Camera, model 2864-222.
0 kommentar(er)
