Hacking Zyxel IP cameras to gain a root shell part 2

Friday December 30 2022
iot embedded vulnerability

I searched on eBay for a while and eventually located a Zyxel IPC 2605 camera. This is in the same product line as the cameras I was able to previously exploit. After plugging it into my network, I was able to run the same script I had previously developed to compromise these cameras remotely. However it did not grant me remote access. So it was time to do some additional investigation to determine if these cameras had the same vulnerability.

This device has nearly the same web administration interface

I was able to export the profile from the web administration interface, just like the other models. After modifying the crontab contained within the profile I uploaded it back to the device. This granted me a remote shell.

I poked around inside the device and quickly determined that there is an additional filesystem mounted at /etc_ro. The busybox init system starts from the file /etc_ro/inittab. In that file there is an entry for /etc_ro/rcS. That script runs mount -t jffs2 /dev/mtdblock5 /mnt/mtd 2>t to mount the "profile" in the filesystem. Inside this same script are these lines

if [ -f /mnt/mtd/Start.sh ]
then
        /mnt/mtd/Start.sh&
else
        /etc/Start.sh&
fi

So custom code can be injected into the profile at /mnt/mtd/Start.sh. This the same vulnerability as the other devices, just with a slightly different filepath. I was able to modify my previously developed script to exploit this vulnerability.

There is nothing else different about this camera's remote shell vulnerability, so I won't comment any more on that here.

Other remarks about the IPC 2605 model

The IPC 2605 is visually similar to the other models, but actually quite different. After I was able to get a remote shell on the device I realized it a MIPS based computer where the other cameras are ARM based. Despite having done quite a bit of MIPS assembly in an academic setting, this is the first actual MIPS computer I have ever held in my life.

$ cat /proc/cpuinfo
system type             : Ralink SoC
processor               : 0
cpu model               : MIPS 24K V4.12
BogoMIPS                : 239.61
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes
ASEs implemented        : mips16 dsp
VCED exceptions         : not available
VCEI exceptions         : not available

This computer is painfully slow. The web server runs a bunch of cgi scripts to serve each web page. It is so slow that my desktop computer renders the HTML faster than it can serve it to the browser.

I port scanned the device and wasn't able to find a running RTSP server at any port. This was puzzling to me, so I managed to copy most of the filesystem off of the device.

$ nmap -p 1-65535 192.168.166.234

Starting Nmap 7.60 ( https://nmap.org ) at 2022-12-13 20:44 CST
Nmap scan report for 192.168.166.234
Host is up (0.0073s latency).
Not shown: 65532 closed ports
PORT      STATE SERVICE
80/tcp    open  http
5160/tcp  open  unknown
49153/tcp open  unknown

Checking the web administration interface, I was able to grab a snapshot

The camera obviously works, so how do I get to the video stream

Almost everything related to the web interface is mounted at /web. There is some javascript in a file /web/html/EmbedApplet.js that injects an HTML element like this.

<applet name="mjpeg_applet" id="mjpeg_applet" codebase="/" code="compro/player/MJPEGStreaming.class" ARCHIVE="MJPEGStreaming.jar" width='+width+' height='+height+'>

This tries to serve the applet stored at /web/html/MJPEGStreaming.jar to the user's browser. Java applets have been deprecated for a long time. But I was able to decompile the applet with jd. In the java source I found a line of code like this

this.videoURL = new URL("http://" + this.streaming_ip + ":" + this.http_port + "/" + "cgi-bin/push_mjpeg.cgi");

So it appears this device does not support RTSP, only MJPEG streaming. I attempted to curl the URL for the mjpeg stream URL but got this result

$ curl http://192.168.166.234/cgi-bin/push_mjpeg.cgi
            <HTML>
            <HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
            <BODY>
            <H4>We are sorry but only administrator(s) can access the Setup page. If you wish to change the settings, please consult with the system administrator or log-in as the administrator.
</H4>
            </BODY>
            </HTML>

Somewhat interestingly, this mean the IPC 2605 doesn't have exactly the same vulnerability as the other cameras where the video feed is accessible with no authorization.

Running curl --basic --user admin:1234 http://192.168.166.234/cgi-bin/push_mjpeg.cgi > test.mjpeg results in a stream of JPEG images being returned in their own format. If I had to guess, this device has some custom extensions in the MIPS instruction set to accelerate JPEG compression. The later models probably switched to an ARM based CPU simply because this computer does not have enough computational power to compress a video stream. I didn't bother doing anything more with this, but this is the complete applet source if someone wants to save the step of decompiling the JAR file.

compro_mjpeg_applet_source.zip 27.2 kB

Decompiled Java source of the MJPEG streaming applet

Another observation I made was that the Java class files all live at a path of compro.player the Java class hierarchy. I searched the other files on the filesystem for references to "compro". I found this in /bin/frame_server.sh

########################################################### IP Camera Model define
Model="CS530"
###########################################################

This camera appears to be a rebadged Compro CS530. I could not find any pictures of a camera with that model but I did find the manual and found this image in it.

The error from the Zyxel manual that states the default pasword is "admin" (it is not) is also present in this camera's manual!

This camera has built-in WiFi, whereas the other cameras used USB based WiFi addons. This has to do with the fact that FCC type acceptance for the WiFi hardware is more practical to do as a modular approval rather approving the system. Once a specific module is approved, it can be incorporated into any system without further FCC type acceptance.

That's about it for this camera. It is just as vulnerable as the other cameras. This camera will likely live out the remainder of it's life sitting on a shelf somewhere, safely disconnected from power for all time.