This contains two vulnerabilities for uc-http daemon, which, when paired together, can result in full compromise of the affected system. uc-httpd is used primarily for DVR devices such as security cameras. Primarily there was an estimate of 3,000,000 vulnerable devices, although (sadly) after our inital release, some script kiddies attempted to abuse this vulnerability to create a mirai-like botnet, which forced an associate of ours to brick more than 1,500,000 devices in order to prevent the malicious abuse of this. Now the current count (on shodan.io at least) of vulnerable devices lays at around half a million.
uc-httpd is vulnerable to local file disclosure through means of sending a single HTTP GET request to the affected server. It is also vulnerable to an attack vector that (we believe) has no name. In the past when coming across this vector, we've referred to it as "dynamic directory/path traversal" (if you can think of a more fitting name, let us know!) - this vulnerability alone can be used to achieve full device compromise. This can be achieved either reading /etc/passwd (which symlinks frahm shadowfiles GG!! also no SHA encryption) or if some reason you can't get SSH access or the root password is invalid, then alternatively you can read /mnt/mtd/Config/Account1 which will give you the admin user/pass for the web panel (found on port 80) - If neither of the above methods are working, then instead this vulnerability can be used to bypass ASLR via reading procfiles and utilizing the seperate Buffer Overflow in order to gain access that way.
uc-httpd's web portal is vulnerable to a buffer overflow. Although ASLR is in place, it is extremely trivial to bypass this provided that you have access to the first vulnerability. This can be achieved by sifting through /proc entries in order to snag the relevant memory address. Without the first vulnerability, another method would be required to bypass ASLR. This technique is only necessary if for some reason the method listed above fails.
This is an n-day vulnerability, wherein the vendor has been notified but failed to act at all. While they've acknowledged our notification and disclosure, a patch has still not been implemnted. At first, we were very confused as to why they would not roll out a patch for their vulnerable devices, but we've now been given some insight into this. A potential reason for why patches aren't being rolled out is because it would require the (often inexperienced) vendors to need physical access to the devices, some cases to modify firmware and in many other cases just because they merely don't have access to - We will be taking this into account when we come across other zero-day vulnerabilities affecting DVR software, and decide whether full disclosure after the deadline is up is really the best route or not.