We can get around this issue by injecting a call to the dhcp client appliction ("udhcpc") - this will cause the device to use dhcp to get its network information bypassing the previous "ppp" config. First in order to use this vector for command injection you must configure the device to use "ppp" - this will cause the device to go offline and we will not be able to interact with it further :(. "sprintf" with user input into a "system", that'll do it.
I created a small PoC in python that will pull the password from a vulnerable device: The next thing I saw was a bit shocking.when you access the application user accounts page the device sends the application all the information about the accounts stored on the device. I imagine the activeX application that is used to connect to the device could be patched to just skip the login screen, but that seems like a lot of work, especially when there are much easier ways in.
The first thing that I found with this lovely device is that the comms channel (9000) did not appear to do any authentication on requests made to it.Strike 1.
The first item I looked at was the web application that is used to view the video streams remotely and configure the device. One of the ports that it will expose is for the web (activeX) application and the other is the actual comms channel the device uses (port 9000). Now for the real fun.looking at the device the default configuration is setup to auto-magically use the power of the dark lord satan (uPnP) to map a few ports on your router (if it supports uPnP). Telnet now works, but what fun is that when these devices don't normally expose telnet to the internet :). Once the device is booted up in single user mode, the root password can be reset and the device can be rebooted.
0 kommentar(er)
