ethanhunnt/IoT_vulnerabilities

DEPSTECH WiFi Digital Microscope 3 allows remote attackers to change the SSID and password, and demand a ransom payment from the rightful device owner, because there is no way to reset to Factory Default settings.

Certain Shenzhen PENGLIXIN components on DEPSTECH WiFi Digital Microscope 3, as used by Shekar Endoscope, allow a TELNET connection with the molinkadmin password for the molink account.

DEPSTECH WiFi Digital Microscope 3 has a default SSID of Jetion_xxxxxxxx with a password of 12345678.

The Amcrest IPM-721S Amcrest_IPC-AWXX_Eng_N_V2.420.AC00.17.R.20170322 allows HTTP requests that permit enabling various functionalities of the camera by using HTTP APIs, instead of the web management interface that is provided by the application. This HTTP API receives the credentials as base64 encoded in the Authorization HTTP header. However, a missing length check in the code allows an attacker to send a string of 1024 characters in the password field, and allows an attacker to exploit a memory corruption issue. This can allow an attacker to circumvent the account protection mechanism and brute force the credentials. If the firmware version Amcrest_IPC-AWXX_Eng_N_V2.420.AC00.17.R.20170322 is dissected using the binwalk tool, one obtains a _user-x.squashfs.img.extracted archive which contains the filesystem set up on the device that has many of the binaries in the /usr folder. The binary "sonia" is the one that has the vulnerable function that performs the credential check in the binary for the HTTP API specification. If we open this binary in IDA Pro we will notice that this follows an ARM little-endian format. The function at address 00415364 in IDA Pro starts the HTTP authentication process. This function calls another function at sub_ 0042CCA0 at address 0041549C. This function performs a strchr operation after base64 decoding the credentials, and stores the result on the stack, which results in a stack-based buffer overflow.

On Amcrest IPM-721S V2.420.AC00.16.R.20160909 devices, the users on the device are divided into 2 groups "admin" and "user". However, as a part of security analysis it was identified that a low privileged user who belongs to the "user" group and who has access to login in to the web administrative interface of the device can add a new administrative user to the interface using HTTP APIs provided by the device and perform all the actions as an administrative user by using that account. If the firmware version V2.420.AC00.16.R 9/9/2016 is dissected using binwalk tool, one obtains a _user-x.squashfs.img.extracted archive which contains the filesystem set up on the device that many of the binaries in the /usr folder. The binary "sonia" is the one that has the vulnerable functions that performs the various action described in HTTP APIs. If one opens this binary in IDA-pro one will notice that this follows a ARM little endian format. The function at address 0x00429084 in IDA pro is the one that processes the HTTP API request for "addUser" action. If one traces the calls to this function, it can be clearly seen that the function sub_ 41F38C at address 0x0041F588 parses the call received from the browser and passes it to the "addUser" function without any authorization check.

Amcrest IPM-721S V2.420.AC00.16.R.20160909 devices allow an unauthenticated attacker to download the administrative credentials. If the firmware version V2.420.AC00.16.R 9/9/2016 is dissected using binwalk tool, one obtains a _user-x.squashfs.img.extracted archive which contains the filesystem set up on the device that many of the binaries in the /usr folder. The binary "sonia" is the one that has the vulnerable function that sets up the default credentials on the device. If one opens this binary in IDA-pro one will notice that this follows a ARM little endian format. The function sub_436D6 in IDA pro is identified to be setting up the configuration for the device. If one scrolls to the address 0x000437C2 then one can see that /current_config is being set as an ALIAS for /mnt/mtd/Config folder on the device. If one TELNETs into the device and navigates to /mnt/mtd/Config folder, one can observe that it contains various files such as Account1, Account2, SHAACcount1, etc. This means that if one navigates to http://[IPofcamera]/current_config/Sha1Account1 then one should be able to view the content of the files. The security researchers assumed that this was only possible only after authentication to the device. However, when unauthenticated access tests were performed for the same URL as provided above, it was observed that the device file could be downloaded without any authentication.

Amcrest IPM-721S V2.420.AC00.16.R.20160909 devices mishandle reboots within the past two hours. Amcrest cloud services does not perform a thorough verification when allowing the user to add a new camera to the user's account to ensure that the user actually owns the camera other than knowing the serial number of the camera. This can allow an attacker who knows the serial number to easily add another user's camera to an attacker's cloud account and control it completely. This is possible in case of any camera that is currently not a part of an Amcrest cloud account or has been removed from the user's cloud account. Also, another requirement for a successful attack is that the user should have rebooted the camera in the last two hours. However, both of these conditions are very likely for new cameras that are sold over the Internet at many ecommerce websites or vendors that sell the Amcrest products. The successful attack results in an attacker being able to completely control the camera which includes being able to view and listen on what the camera can see, being able to change the motion detection settings and also be able to turn the camera off without the user being aware of it. Note: The same attack can be executed using the Amcrest Cloud mobile application.

Amcrest IPM-721S V2.420.AC00.16.R.20160909 devices have a timeout policy to wait for 5 minutes in case 30 incorrect password attempts are detected using the Web and HTTP API interface provided by the device. However, if the same brute force attempt is performed using the ONVIF specification (which is supported by the same binary) then there is no account lockout or timeout executed. This can allow an attacker to circumvent the account protection mechanism and brute force the credentials. If the firmware version V2.420.AC00.16.R 9/9/2016 is dissected using binwalk tool, one obtains a _user-x.squashfs.img.extracted archive which contains the filesystem set up on the device that many of the binaries in the /usr folder. The binary "sonia" is the one that has the vulnerable function that performs the credential check in the binary for the ONVIF specification. If one opens this binary in IDA-pro one will notice that this follows a ARM little endian format. The function at address 00671618 in IDA pro is parses the WSSE security token header. The sub_ 603D8 then performs the authentication check and if it is incorrect passes to the function sub_59F4C which prints the value "Sender not authorized."

Amcrest IPM-721S V2.420.AC00.16.R.20160909 devices have default credentials that are hardcoded in the firmware and can be extracted by anyone who reverses the firmware to identify them. If the firmware version V2.420.AC00.16.R 9/9/2016 is dissected using binwalk tool, one obtains a _user-x.squashfs.img.extracted archive which contains the filesystem set up on the device that many of the binaries in the /usr folder. The binary "sonia" is the one that has the vulnerable function that sets up the default credentials on the device. If one opens this binary in IDA-pro, one will notice that this follows a ARM little endian format. The function sub_3DB2FC in IDA pro is identified to be setting up the values at address 0x003DB5A6. The sub_5C057C then sets this value and adds it to the Configuration files in /mnt/mtd/Config/Account1 file.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The device runs a custom daemon on UDP port 5978 which is called "dldps2121" and listens for broadcast packets sent on 255.255.255.255. This daemon handles custom D-Link UDP based protocol that allows D-Link mobile applications and desktop applications to discover D-Link devices on the local network. The binary processes the received UDP packets sent from any device in "main" function. One path in the function traverses towards a block of code that processing of packets which does an unbounded copy operation which allows to overflow the buffer. The custom protocol created by Dlink follows the following pattern: Packetlen, Type of packet; M=MAC address of device or broadcast; D=Device Type;C=base64 encoded command string;test=1111 We can see at address function starting at address 0x0000DBF8 handles the entire UDP packet and performs an insecure copy using strcpy function at address 0x0000DC88. This results in overflowing the stack pointer after 1060 characters and thus allows to control the PC register and results in code execution. The same form of communication can be initiated by any process including an attacker process on the mobile phone or the desktop and this allows a third-party application on the device to execute commands on the device without any authentication by sending just 1 UDP packet with custom base64 encoding.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The device runs a custom daemon on UDP port 5978 which is called "dldps2121" and listens for broadcast packets sent on 255.255.255.255. This daemon handles custom D-Link UDP based protocol that allows D-Link mobile applications and desktop applications to discover D-Link devices on the local network. The binary processes the received UDP packets sent from any device in "main" function. One path in the function traverses towards a block of code that handles commands to be executed on the device. The custom protocol created by D-Link follows the following pattern: Packetlen, Type of packet; M=MAC address of device or broadcast; D=Device Type;C=base64 encoded command string;test=1111. If a packet is received with the packet type being "S" or 0x53 then the string passed in the "C" parameter is base64 decoded and then executed by passing into a System API. We can see at address 0x00009B44 that the string received in packet type subtracts 0x31 or "1" from the packet type and is compared against 0x22 or "double quotes". If that is the case, then the packet is sent towards the block of code that executes a command. Then the value stored in "C" parameter is extracted at address 0x0000A1B0. Finally, the string received is base 64 decoded and passed on to the system API at address 0x0000A2A8 as shown below. The same form of communication can be initiated by any process including an attacker process on the mobile phone or the desktop and this allows a third-party application on the device to execute commands on the device without any authentication by sending just 1 UDP packet with custom base64 encoding.

Blipcare Wifi blood pressure monitor BP700 10.1 devices allow memory corruption that results in Denial of Service. When connected to the "Blip" open wireless connection provided by the device, if a large string is sent as a part of the HTTP request in any part of the HTTP headers, the device could become completely unresponsive. Presumably this happens as the memory footprint provided to this device is very small. According to the specs from Rezolt, the Wi-Fi module only has 256k of memory. As a result, an incorrect string copy operation using either memcpy, strcpy, or any of their other variants could result in filling up the memory space allocated to the function executing and this would result in memory corruption. To test the theory, one can modify the demo application provided by the Cypress WICED SDK and introduce an incorrect "memcpy" operation and use the compiled application on the evaluation board provided by Cypress semiconductors with exactly the same Wi-Fi SOC. The results were identical where the device would completely stop responding to any of the ping or web requests.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The device has a custom telnet daemon as a part of the busybox and retrieves the password from the shadow file using the function getspnam at address 0x00053894. Then performs a crypt operation on the password retrieved from the user at address 0x000538E0 and performs a strcmp at address 0x00053908 to check if the password is correct or incorrect. However, the /etc/shadow file is a part of CRAM-FS filesystem which means that the user cannot change the password and hence a hardcoded hash in /etc/shadow is used to match the credentials provided by the user. This is a salted hash of the string "admin" and hence it acts as a password to the device which cannot be changed as the whole filesystem is read only.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The device requires that a user logging into the device provide a username and password. However, the device allows D-Link apps on the mobile devices and desktop to communicate with the device without any authentication. As a part of that communication, the device uses custom version of base64 encoding to pass data back and forth between the apps and the device. However, the same form of communication can be initiated by any process including an attacker process on the mobile phone or the desktop and this allows a third party to retrieve the device's password without any authentication by sending just 1 UDP packet with custom base64 encoding. The severity of this attack is enlarged by the fact that there more than 100,000 D-Link devices out there.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The device has a custom binary called mp4ts under the /var/www/video folder. It seems that this binary dumps the HTTP VERB in the system logs. As a part of doing that it retrieves the HTTP VERB sent by the user and uses a vulnerable sprintf function at address 0x0000C3D4 in the function sub_C210 to copy the value into a string and then into a log file. Since there is no bounds check being performed on the environment variable at address 0x0000C360 this results in a stack overflow and overwrites the PC register allowing an attacker to execute buffer overflow or even a command injection attack.

In the most recent firmware for Blipcare, the device provides an open Wireless network called "Blip" for communicating with the device. The user connects to this open Wireless network and uses the web management interface of the device to provide the user's Wi-Fi credentials so that the device can connect to it and have Internet access. This device acts as a Wireless Blood pressure monitor and is used to measure blood pressure levels of a person. This allows an attacker who is in vicinity of Wireless signal generated by the Blipcare device to easily sniff the credentials. Also, an attacker can connect to the open wireless network "Blip" exposed by the device and modify the HTTP response presented to the user by the device to execute other attacks such as convincing the user to download and execute a malicious binary that would infect a user's computer or mobile device with malware.

It was discovered as a part of the research on IoT devices in the most recent firmware for Blipcare device that the device allows to connect to web management interface on a non-SSL connection using plain text HTTP protocol. The user uses the web management interface of the device to provide the user's Wi-Fi credentials so that the device can connect to it and have Internet access. This device acts as a Wireless Blood pressure monitor and is used to measure blood pressure levels of a person. This allows an attacker who is connected to the Blipcare's device wireless network to easily sniff these values using a MITM attack.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The binary orthrus in /sbin folder of the device handles all the UPnP connections received by the device. It seems that the binary performs a sprintf operation at address 0x0000A3E4 with the value in the command line parameter "-f" and stores it on the stack. Since there is no length check, this results in corrupting the registers for the function sub_A098 which results in memory corruption.

An issue was discovered on D-Link DCS-1100 and DCS-1130 devices. The binary rtspd in /sbin folder of the device handles all the rtsp connections received by the device. It seems that the binary performs a memcpy operation at address 0x00011E34 with the value sent in the "Authorization: Basic" RTSP header and stores it on the stack. The number of bytes to be copied are calculated based on the length of the string sent in the RTSP header by the client. As a result, memcpy copies more data then it can hold on stack and this results in corrupting the registers for the caller function sub_F6CC which results in memory corruption. The severity of this attack is enlarged by the fact that the same value is then copied on the stack in the function 0x00011378 and this allows to overflow the buffer allocated and thus control the PC register which will result in arbitrary code execution on the device.

An issue was discovered on D-Link DCS-1130 devices. The device requires that a user logging to the device to provide a username and password. However, the device does not enforce the same restriction on a specific URL thereby allowing any attacker in possession of that to view the live video feed. The severity of this attack is enlarged by the fact that there more than 100,000 D-Link devices out there.

An issue was discovered on D-Link DCS-1130 and DCS-1100 devices. The binary rtspd in /sbin folder of the device handles all the rtsp connections received by the device. It seems that the binary loads at address 0x00012CF4 a flag called "Authenticate" that indicates whether a user should be authenticated or not before allowing access to the video feed. By default, the value for this flag is zero and can be set/unset using the HTTP interface and network settings tab as shown below. The device requires that a user logging to the HTTP management interface of the device to provide a valid username and password. However, the device does not enforce the same restriction by default on RTSP URL due to the checkbox unchecked by default, thereby allowing any attacker in possession of external IP address of the camera to view the live video feed. The severity of this attack is enlarged by the fact that there more than 100,000 D-Link devices out there.

An issue was discovered on D-Link DCS-1130 devices. The device provides a crossdomain.xml file with no restrictions on who can access the webserver. This allows an hosted flash file on any domain to make calls to the device's webserver and pull any information that is stored on the device. In this case, user's credentials are stored in clear text on the device and can be pulled easily. It also seems that the device does not implement any cross-site scripting forgery protection mechanism which allows an attacker to trick a user who is logged in to the web management interface into executing a cross-site flashing attack on the user's browser and execute any action on the device provided by the web management interface which steals the credentials from tools_admin.cgi file's response and displays it inside a Textfield.

An issue was discovered on D-Link DCS-1130 devices. The device provides a user with the capability of setting a SMB folder for the video clippings recorded by the device. It seems that the POST parameters passed in this request (to test if email credentials and hostname sent to the device work properly) result in being passed as commands to a "system" API in the function and thus result in command injection on the device. If the firmware version is dissected using binwalk tool, we obtain a cramfs-root archive which contains the filesystem set up on the device that contains all the binaries. The library "libmailutils.so" is the one that has the vulnerable function "sub_1FC4" that receives the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows an ARM little endian format. The function sub_1FC4 in IDA pro is identified to be receiving the values sent in the POST request and the value set in POST parameter "receiver1" is extracted in function "sub_15AC" which is then passed to the vulnerable system API call. The vulnerable library function is accessed in "cgibox" binary at address 0x0008F598 which calls the "mailLoginTest" function in "libmailutils.so" binary as shown below which results in the vulnerable POST parameter being passed to the library which results in the command injection issue.

An issue was discovered on D-Link DCS-1130 devices. The device provides a user with the capability of changing the administrative password for the web management interface. It seems that the device does not implement any cross-site request forgery protection mechanism which allows an attacker to trick a user who is logged in to the web management interface to change the user's password.

An issue was discovered on D-Link DCS-1130 devices. The device provides a user with the capability of setting a SMB folder for the video clippings recorded by the device. It seems that the POST parameters passed in this request (to test if email credentials and hostname sent to the device work properly) result in being passed as commands to a "system" API in the function and thus result in command injection on the device. If the firmware version is dissected using binwalk tool, we obtain a cramfs-root archive which contains the filesystem set up on the device that contains all the binaries. The library "libmailutils.so" is the one that has the vulnerable function "sub_1FC4" that receives the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows an ARM little endian format. The function sub_1FC4 in IDA pro is identified to be receiving the values sent in the POST request and the value set in POST parameter "receiver1" is extracted in function "sub_15AC" which is then passed to the vulnerable system API call. The vulnerable library function is accessed in "cgibox" binary at address 0x00023BCC which calls the "Send_mail" function in "libmailutils.so" binary as shown below which results in the vulnerable POST parameter being passed to the library which results in the command injection issue.

An issue was discovered on D-Link DCS-1130 devices. The device provides a user with the capability of setting a SMB folder for the video clippings recorded by the device. It seems that the GET parameters passed in this request (to test if SMB credentials and hostname sent to the device work properly) result in being passed as commands to a "system" API in the function and thus result in command injection on the device. If the firmware version is dissected using binwalk tool, we obtain a cramfs-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "cgibox" is the one that has the vulnerable function "sub_7EAFC" that receives the values sent by the GET request. If we open this binary in IDA-pro we will notice that this follows a ARM little endian format. The function sub_7EAFC in IDA pro is identified to be receiving the values sent in the GET request and the value set in GET parameter "user" is extracted in function sub_7E49C which is then passed to the vulnerable system API call.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of blocking key words passing in the web traffic to prevent kids from watching content that might be deemed unsafe using the web management interface. It seems that the device does not implement any cross-site scripting protection mechanism which allows an attacker to trick a user who is logged in to the web management interface into executing a stored cross-site scripting payload on the user's browser and execute any action on the device provided by the web management interface.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of executing various actions on the web management interface. It seems that the device does not implement any Origin header check which allows an attacker who can trick a user to navigate to an attacker's webpage to exploit this issue and brute force the password for the web management interface. It also allows an attacker to then execute any other actions which include management if rules, sensors attached to the devices using the websocket requests.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of changing the administrative password for the web management interface. It seems that the device does not implement any cross site request forgery protection mechanism which allows an attacker to trick a user who is logged in to the web management interface to change a user's password. Also this is a systemic issue.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a UPnP functionality for devices to interface with the router and interact with the device. It seems that the "NewInMessage" SOAP parameter passed with a huge payload results in crashing the process. If the firmware version AL-R096 is dissected using binwalk tool, we obtain a cpio-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "miniupnpd" is the one that has the vulnerable function that receives the values sent by the SOAP request. If we open this binary in IDA-pro we will notice that this follows a MIPS little endian format. The function WscDevPutMessage at address 0x0041DBB8 in IDA pro is identified to be receiving the values sent in the SOAP request. The SOAP parameter "NewInMesage" received at address 0x0041DC30 causes the miniupnpd process to finally crash when a second request is sent to the same process.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of blocking IP addresses using the web management interface. It seems that the device does not implement any cross-site scripting forgery protection mechanism which allows an attacker to trick a user who is logged in to the web management interface into executing a cross-site scripting payload on the user's browser and execute any action on the device provided by the web management interface.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of adding new routes to the device. It seems that the POST parameters passed in this request to set up routes on the device can be set in such a way that would result in passing commands to a "popen" API in the function and thus result in command injection on the device. If the firmware version AL-R096 is dissected using binwalk tool, we obtain a cpio-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "goahead" is the one that has the vulnerable function that receives the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows a MIPS little endian format. The function sub_00420F38 in IDA pro is identified to be receiving the values sent in the POST request and the value set in POST parameter "dest" is extracted at address 0x00420FC4. The POST parameter "dest is concatenated in a route add command and this is passed to a "popen" function at address 0x00421220. This allows an attacker to provide the payload of his/her choice and finally take control of the device.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of adding new port forwarding rules to the device. It seems that the POST parameters passed in this request to set up routes on the device can be set in such a way that would result in passing commands to a "system" API in the function and thus result in command injection on the device. If the firmware version AL-R096 is dissected using binwalk tool, we obtain a cpio-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "goahead" is the one that has the vulnerable function that recieves the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows a MIPS little endian format. The function sub_43C280in IDA pro is identified to be receiving the values sent in the POST request and the value set in POST parameter "ip_address" is extracted at address 0x0043C2F0. The POST parameter "ipaddress" is concatenated at address 0x0043C958 and this is passed to a "system" function at address 0x00437284. This allows an attacker to provide the payload of his/her choice and finally take control of the device.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of setting a name for the wireless network. These values are stored by the device in NVRAM (Non-volatile RAM). It seems that the POST parameters passed in this request to set up names on the device do not have a string length check on them. This allows an attacker to send a large payload in the "mssid_1" POST parameter. The device also allows a user to view the name of the Wifi Network set by the user. While processing this request, the device calls a function at address 0x00412CE4 (routerSummary) in the binary "webServer" located in Almond folder, which retrieves the value set earlier by "mssid_1" parameter as SSID2 and this value then results in overflowing the stack set up for this function and allows an attacker to control $ra register value on the stack which allows an attacker to control the device by executing a payload of an attacker's choice. If the firmware version AL-R096 is dissected using binwalk tool, we obtain a cpio-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "goahead" is the one that has the vulnerable function that receives the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows a MIPS little endian format. The function sub_00420F38 in IDA pro is identified to be receiving the values sent in the POST parameter "mssid_1" at address 0x0042BA00 and then sets in the NVRAM at address 0x0042C314. The value is later retrieved in the function at address 0x00412EAC and this results in overflowing the buffer as the function copies the value directly on the stack.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of adding new routes to the device. It seems that the POST parameters passed in this request to set up routes on the device can be set in such a way that would result in overflowing the stack set up and allow an attacker to control the $ra register stored on the stack. If the firmware version AL-R096 is dissected using binwalk tool, we obtain a cpio-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "goahead" is the one that has the vulnerable function that recieves the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows a MIPS little endian format. The function sub_00420F38 in IDA pro is identified to be receiving the values sent in the POST request. The POST parameter "gateway" allows to overflow the stack and control the $ra register after 1546 characters. The value from this post parameter is then copied on the stack at address 0x00421348 as shown below. This allows an attacker to provide the payload of his/her choice and finally take control of the device.

An issue was discovered on Securifi Almond, Almond+, and Almond 2015 devices with firmware AL-R096. The device provides a user with the capability of setting name for wireless network. These values are stored by the device in NVRAM (Non-volatile RAM). It seems that the POST parameters passed in this request to set up names on the device do not have a string length check on them. This allows an attacker to send a large payload in the "mssid_1" POST parameter. The device also allows a user to view the name of the Wifi Network set by the user. While processing this request, the device calls a function named "getCfgToHTML" at address 0x004268A8 which retrieves the value set earlier by "mssid_1" parameter as SSID2 and this value then results in overflowing the stack set up for this function and allows an attacker to control $ra register value on the stack which allows an attacker to control the device by executing a payload of an attacker's choice. If the firmware version AL-R096 is dissected using binwalk tool, we obtain a cpio-root archive which contains the filesystem set up on the device that contains all the binaries. The binary "goahead" is the one that has the vulnerable function that recieves the values sent by the POST request. If we open this binary in IDA-pro we will notice that this follows a MIPS little endian format. The function sub_00420F38 in IDA pro is identified to be receiving the values sent in the POST parameter "mssid_1" at address 0x0042BA00 and then sets in the NVRAM at address 0x0042C314. The value is later retrieved in the function "getCfgToHTML" at address 0x00426924 and this results in overflowing the buffer due to "strcat" function that is utilized by this function.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that an attacker connected to the device Wi-Fi SSID can exploit a memory corruption issue and execute remote code on the device. This device acts as an Endoscope camera that allows its users to use it in various industrial systems and settings, car garages, and also in some cases in the medical clinics to get access to areas that are difficult for a human being to reach. Any breach of this system can allow an attacker to get access to video feed and pictures viewed by that user and might allow them to get a foot hold in air gapped networks especially in case of nation critical infrastructure/industries. The firmware contains binary uvc_stream that is the UDP daemon which is responsible for handling all the UDP requests that the device receives. The client application sends a UDP request to change the Wi-Fi name which contains the following format: "SETCMD0001+0002+[2 byte length of wifipassword]+[Wifipassword]. This request is handled by "control_Dev_thread" function which at address "0x00409AE4" compares the incoming request and determines if the 10th byte is 02 and if it is then it redirects to 0x0040A7D8, which calls the function "setwifipassword". The function "setwifipassword" uses a memcpy function but uses the length of the payload obtained by using strlen function as the third parameter which is the number of bytes to copy and this allows an attacker to overflow the function and control the $PC value.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that an attacker connected to the device Wi-Fi SSID can exploit a memory corruption issue and execute remote code on the device. This device acts as an Endoscope camera that allows its users to use it in various industrial systems and settings, car garages, and also in some cases in the medical clinics to get access to areas that are difficult for a human being to reach. Any breach of this system can allow an attacker to get access to video feed and pictures viewed by that user and might allow them to get a foot hold in air gapped networks especially in case of nation critical infrastructure/industries. The firmware contains binary uvc_stream that is the UDP daemon which is responsible for handling all the UDP requests that the device receives. The client application sends a UDP request to change the Wi-Fi name which contains the following format: "SETCMD0001+0001+[2 byte length of wifiname]+[Wifiname]. This request is handled by "control_Dev_thread" function which at address "0x00409AE0" compares the incoming request and determines if the 10th byte is 01 and if it is then it redirects to 0x0040A74C which calls the function "setwifiname". The function "setwifiname" uses a memcpy function but uses the length of the payload obtained by using strlen function as the third parameter which is the number of bytes to copy and this allows an attacker to overflow the function and control the $PC value.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the desktop application used to connect to the device suffers from a stack overflow if more than 26 characters are passed to it as the Wi-Fi password. This application is installed on the device and an attacker who can provide the right payload can execute code on the user's system directly. Any breach of this system can allow an attacker to get access to all the data that the user has access too. The application uses a dynamic link library(DLL) called "avilib.dll" which is used by the application to send binary packets to the device that allow to control the device. One such action that the DLL provides is change password in the function "sendchangepass" which allows a user to change the Wi-Fi password on the device. This function calls a sub function "sub_75876EA0" at address 0x7587857C. The function determines which action to execute based on the parameters sent to it. The "sendchangepass" passes the datastring as the second argument which is the password we enter in the textbox and integer 2 as first argument. The rest of the 3 arguments are set to 0. The function "sub_75876EA0" at address 0x75876F19 uses the first argument received and to determine which block to jump to. Since the argument passed is 2, it jumps to 0x7587718C and proceeds from there to address 0x758771C2 which calculates the length of the data string passed as the first parameter.This length and the first argument are then passed to the address 0x7587726F which calls a memmove function which uses a stack address as the destination where the password typed by us is passed as the source and length calculated above is passed as the number of bytes to copy which leads to a stack overflow.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the desktop application used to connect to the device suffers from a stack overflow if more than 26 characters are passed to it as the Wi-Fi name. This application is installed on the device and an attacker who can provide the right payload can execute code on the user's system directly. Any breach of this system can allow an attacker to get access to all the data that the user has access too. The application uses a dynamic link library(DLL) called "avilib.dll" which is used by the application to send binary packets to the device that allow to control the device. One such action that the DLL provides is change password in the function "sendchangename" which allows a user to change the Wi-Fi name on the device. This function calls a sub function "sub_75876EA0" at address 0x758784F8. The function determines which action to execute based on the parameters sent to it. The "sendchangename" passes the datastring as the second argument which is the name we enter in the textbox and integer 1 as first argument. The rest of the 3 arguments are set to 0. The function "sub_75876EA0" at address 0x75876F19 uses the first argument received and to determine which block to jump to. Since the argument passed is 1, it jumps to 0x75876F20 and proceeds from there to address 0x75876F56 which calculates the length of the data string passed as the first parameter. This length and the first argument are then passed to the address 0x75877001 which calls the memmove function which uses a stack address as the destination where the password typed by us is passed as the source and length calculated above is passed as the number of bytes to copy which leads to a stack overflow.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the device has Telnet functionality enabled by default. This device acts as an Endoscope camera that allows its users to use it in various industrial systems and settings, car garages, and also in some cases in the medical clinics to get access to areas that are difficult for a human being to reach. Any breach of this system can allow an attacker to get access to video feed and pictures viewed by that user and might allow them to get a foot hold in air gapped networks especially in case of nation critical infrastructure/industries.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the device has default Wi-Fi credentials that are exactly the same for every device. This device acts as an Endoscope camera that allows its users to use it in various industrial systems and settings, car garages, and also in some cases in the medical clinics to get access to areas that are difficult for a human being to reach. Any breach of this system can allow an attacker to get access to video feed and pictures viewed by that user and might allow them to get a foot hold in air gapped networks especially in case of nation critical infrastructure/industries.

Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that any malicious user connecting to the device can change the default SSID and password thereby denying the owner an access to his/her own device. This device acts as an Endoscope camera that allows its users to use it in various industrial systems and settings, car garages, and also in some cases in the medical clinics to get access to areas that are difficult for a human being to reach. Any breach of this system can allow an attacker to get access to video feed and pictures viewed by that user and might allow them to get a foot hold in air gapped networks especially in case of nation critical infrastructure/industries.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "request_image" as one of the service actions for a normal user to retrieve an image from a camera that is controlled by the controller. It seems that the "URL" parameter passed in the query string is not sanitized and is stored on the stack which allows an attacker to overflow the buffer. The function "LU::Generic_IP_Camera_Manager::REQ_Image" is activated when the lu_request_image is passed as the "id" parameter in query string. This function then calls "LU::Generic_IP_Camera_Manager::GetUrlFromArguments" and passes a "pointer" to the function where it will be allowed to store the value from the URL parameter. This pointer is passed as the second parameter $a2 to the function "LU::Generic_IP_Camera_Manager::GetUrlFromArguments". However, neither the callee or the caller in this case performs a simple length check and as a result an attacker who is able to send more than 1336 characters can easily overflow the values stored on the stack including the $RA value and thus execute code on the device.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "request_image" as one of the service actions for a normal user to retrieve an image from a camera that is controlled by the controller. It seems that the "res" (resolution) parameter passed in the query string is not sanitized and is stored on the stack which allows an attacker to overflow the buffer. The function "LU::Generic_IP_Camera_Manager::REQ_Image" is activated when the lu_request_image is passed as the "id" parameter in the query string. This function then calls "LU::Generic_IP_Camera_Manager::GetUrlFromArguments". This function retrieves all the parameters passed in the query string including "res" and then uses the value passed in it to fill up buffer using the sprintf function. However, the function in this case lacks a simple length check and as a result an attacker who is able to send more than 184 characters can easily overflow the values stored on the stack including the $RA value and thus execute code on the device.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a script file called "get_file.sh" which allows a user to retrieve any file stored in the "cmh-ext" folder on the device. However, the "filename" parameter is not validated correctly and this allows an attacker to directory traverse outside the /cmh-ext folder and read any file on the device. It is necessary to create the folder "cmh-ext" on the device which can be executed by an attacker first in an unauthenticated fashion and then execute a directory traversal attack.

An issue was discovered on Vera Veralite 1.7.481 devices. The device has an additional OpenWRT interface in addition to the standard web interface which allows the highest privileges a user can obtain on the device. This web interface uses root as the username and the password in the /etc/cmh/cmh.conf file which can be extracted by an attacker using a directory traversal attack, and then log in to the device with the highest privileges.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a shell script called relay.sh which is used for creating new SSH relays for the device so that the device connects to Vera servers. All the parameters passed in this specific script are logged to a log file called log.relay in the /tmp folder. The user can also read all the log files from the device using a script called log.sh. However, when the script loads the log files it displays them with content-type text/html and passes all the logs through the ansi2html binary which converts all the character text including HTML meta-characters correctly to be displayed in the browser. This allows an attacker to use the log files as a storing mechanism for the XSS payload and thus whenever a user navigates to that log.sh script, it enables the XSS payload and allows an attacker to execute his malicious payload on the user's browser.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device allows a user to install applications written in the Lua programming language. Also the interface allows any user to write his/her application in the Lua language. However, this functionality is not protected by authentication and this allows an attacker to run arbitrary Lua code on the device. The POST request is forwarded to LuaUPNP daemon on the device. This binary handles the received Lua code in the function "LU::JobHandler_LuaUPnP::RunLua(LU::JobHandler_LuaUPnP *__hidden this, LU::UPnPActionWrapper *)". The value in the "code" parameter is then passed to the function "LU::LuaInterface::RunCode(char const*)" which actually loads the Lua engine and runs the code.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a shell script called connect.sh which is supposed to return a specific cookie for the user when the user is authenticated to https://home.getvera.com. One of the parameters retrieved by this script is "RedirectURL". However, the application lacks strict input validation of this parameter and this allows an attacker to execute the client-side code on this application.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "wget" as one of the service actions for a normal user to connect the device to an external website. It retrieves the parameter "URL" from the query string and then passes it to an internal function that uses the curl module on the device to retrieve the contents of the website.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "file" as one of the service actions for a normal user to read a file that is stored under the /etc/cmh-lu folder. It retrieves the value from the "parameters" query string variable and then passes it to an internal function "FileUtils::ReadFileIntoBuffer" which is a library function that does not perform any sanitization on the value submitted and this allows an attacker to use directory traversal characters "../" and read files from other folders within the device.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device firmware file contains a file known as relay.sh which allows the device to create relay ports and connect the device to Vera servers. This is primarily used as a method of communication between the device and Vera servers so the devices can be communicated with even when the user is not at home. One of the parameters retrieved by this specific script is "remote_host". This parameter is not sanitized by the script correctly and is passed in a call to "eval" to execute another script where remote_host is concatenated to be passed a parameter to the second script. This allows an attacker to escape from the executed command and then execute any commands of his/her choice.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a user with the capability of installing or deleting apps on the device using the web management interface. It seems that the device does not implement any cross-site request forgery protection mechanism which allows an attacker to trick a user who navigates to an attacker controlled page to install or delete an application on the device. Note: The cross-site request forgery is a systemic issue across all other functionalities of the device.

An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device firmware file contains a file known as proxy.sh which allows the device to proxy a specific request to and from from another website. This is primarily used as a method of communication between the device and Vera website when the user is logged in to the https://home.getvera.com and allows the device to communicate between the device and website. One of the parameters retrieved by this specific script is "url". This parameter is not sanitized by the script correctly and is passed in a call to "eval" to execute "curl" functionality. This allows an attacker to escape from the executed command and then execute any commands of his/her choice.

The HTTP API supported by Starry Station (aka Starry Router) allows brute forcing the PIN setup by the user on the device, and this allows an attacker to change the Wi-Fi settings and PIN, as well as port forward and expose any internal device's port to the Internet. It was identified that the device uses custom Python code called "rodman" that allows the mobile appication to interact with the device. The APIs that are a part of this rodman Python file allow the mobile application to interact with the device using a secret, which is a uuid4 based session identifier generated by the device the first time it is set up. However, in some cases, these APIs can also use a security code. This security code is nothing but the PIN number set by the user to interact with the device when using the touch interface on the router. This allows an attacker on the Internet to interact with the router's HTTP interface when a user navigates to the attacker's website, and brute force the credentials. Also, since the device's server sets the Access-Control-Allow-Origin header to "*", an attacker can easily interact with the JSON payload returned by the device and steal sensitive information about the device.

Starry Station (aka Starry Router) sets the Access-Control-Allow-Origin header to "*". This allows any hosted file on any domain to make calls to the device's webserver and brute force the credentials and pull any information that is stored on the device. In this case, a user's Wi-Fi credentials are stored in clear text on the device and can be pulled easily.