Slashdot Mirror
AVTECH Shuns Security Firm and Leaves All Products Vulnerable Without a Patch (softpedia.com)
An anonymous reader writes: AVTECH, a Taiwanese CCTV equipment manufacturer, has failed to respond to Search-Lab, a Hungarian security firm, who spent more than a year trying to inform the company about 14 security bugs affecting the firmware of ALL its products. Almost a year after it first contacted the hardware maker, Search-Lab published a public advisory about the vulnerabilities it discovered, warning sysadmins that their AVTECH products may be in danger of exploitation and remote takeover. Search-Lab says their researchers is not the only one that spotted these issues. Currently, the term "AVTECH" is the second most popular search term on Shodan, where anyone can find more than 130,000 of these devices available online. Taking into account the recent attacks from IoT botnets, AVTECH is now on the same level of incompetence and indifference as other CCTV hardware makers such as AVer, Dahua, and TVT, all Chinese and Taiwanese companies. A list of confirmed affected firmware versions is available here, proof of concept exploitation code is available on GitHub, and an exploitation video is available here.
Sometimes they even get less security than they pay for!
My eyes reflect the stars and a smile lights up my face.
Nothing specific; though some IP cameras are incidentally supported because they are built on the same SoCs as routers.
Just by way of example, since one is on my desk, the D-Link DCS-930L is essentially a Ralink RT5350F with a lousy webcam attached to its USB host port; all integrated into a single PCB. Since the RT5350 shows up in all kinds of little routers, it has OpenWRT support; and since it is primarily a router SoC, the camera is a USB device rather than some MIPI CSI atrocity.
More generally, it just varies. A lot of the higher end DVRs are just x86s, since that's a cheap and easy way to get a punchy CPU, as much storage as you deem necessary; and optionally a bunch of PCI/PCIe capture cards to handle legacy analog devices; so putting your own OS on them isn't a terribly heroic endeavor(though support for the capture cards might be, what little support their is is typically aimed either at consumer entertainment devices or scientific/industrial framegrabbers, since the former has the biggest userbase and the latter has the deeper pockets). The cheap seats tend to be some ARM or MIPS SoC running a truly shoddy linux port(and have fun getting GPL compliance out of the vendor, not that you'd want see their kernel 2.4 hackjob anyway...); and so could be supported; but are likely to be a somewhat heroic undertaking unless enough interested people have the same hardware to work on it together.
And more worrisome:
Most of these devices use specialized ARM processors with additional opcodes for the video encoding/decoding operations with proprietary software handling the image generation.
Meaning: you can't simply replace it with an all open source stack, and in many cases can't even replace the system library with an alternative (musl just got switched out for uClibc in OpenWRT, having both a smaller profile and more complete modern conformance than either uClibc or glibc, albeit without legacy development compatibility (which is broken in many cases on glibc, and doesn't exist on uClibc anyway.)
Point being: Unless somebody makes a concerted effort to reverse engineering those undocuemnted opcodes, or gets ahold of the proprietary datasheets/architecture manuals for those ip camera processors, making a complete open source distro for those devices will be difficult and time consuming, for something that is a nominalyl not for profit venture requiring greater than workday level effort for all but the intellectually advanced of programmers/embedded systems designers/reverse engineers/laypeople.