WiFi Camera

Connect – Enter – Explore.

Your IoT devices may be more powerful than you think.

Intro
Recently a friend of mine came to visit me with a dusty security camera in his hand. He explained that he had that thing since quite some time and the camera was only gathering dust because he was not able to get any understandable documentation from the Chinese manufacturer and he heard that the camera was “insecure” without being able to elaborate what exactly was insecure about it.

Connect
I looked at the cheap looking plastic thing and decided to help. The camera had wifi antenna and LAN adapter so I  connected it to my local network and waited to see if it will get an IP address via DHCP. Which after some seconds( you have to be patient with these cameras) turned out to work.

The next thing that I did was to run nmap and scan the camera.

sudo nmap -O <camera-ip>

Much to my surprise the camera had telnet, ftp and http daemons running.

21/tcp   open     ftp
23/tcp   open     telnet
..
80/tcp   open     http
..


And its operating system was most probably based on Linux:

Aggressive OS guesses: Linux 2.6.30 (88%), Linux 2.6.11 (88%),...

At that moment my interest rose and I thought that actually this camera might be more useful than it looks if I am able to login as privileged user and compile or run other programs than the ones coming by default from the manufacturer.

Enter
The next challenge was to log in with a valid telnet user. There were two options:

• Either run some brute force tool which may take unknown number of hours or weeks if the password is difficult to guess.
• Or search in Internet for factory default settings for that type of camera.

I decided to try the second option. For my search I used the printed information on the bottom of the camera and with a bit of luck I found one suggestion which was saying: “The admin password is: 12….”. I tried it and it just worked.

So now I understood what my friend meant when he said that the camera is “insecure”. This camera and all other cameras from the same brand had the same credentials – privileged user and password. Of course you could change the password but almost no one does it. Which means that if you know the credentials for one device you can log in any other device connected to Internet. To make things worse the default password is easy to guess and on the top of the list of passwords that should be avoided.

That is one part of the problem with the security. The other part is that even if you have changed your password when you use protocols like Telnet and FTP the password is transferred as clear text and anyone who is sniffing the traffic can read it. Therefore I decided to see if I can compile a SSH server for that device and be able to stop the Telnet and FTP services.

Explore
Once I logged in I was ready to explore the camera. In the PC world 80% of the devices are quite common. Intel or ARM CPU with hardware for which there are already drivers. Unfortunately that is not true for embedded devices. And that camera was no exception. Which means that I had to find out the kernel that was used, the compiler and its version, the CPU type, the main libraries and their versions and most importantly the format of the compiled executables that were present. That information can help finding out the current software and gain insights how to improve it.

To get information about the kernel you can type:

cat /proc/version

Which gave me something like this as a result:

Linux version 2.6.10_hikws (...@localhost.localdomain) gcc version 3.4.6


The above states that the camera is using Linux kernel 2.6.10, pretty close to what nmap guessed (Linux 2.6.11). The C compiler that was used is GCC and its version is 3.4.6.

To get information about the CPU you can type the following command:

cat /proc/cpuinfo

I got the following information which hinted me at using an ARM processor:

CPU:
Processor       : ARM926EJ-Sid(wb) rev 5 (v5l)
BogoMIPS        : 148.27
Features        : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 5
...
Revision        : 0000
Serial          : 0000000000000000


To get information about the available libraries I listed the  /lib directory and I got the following result:

ls -lha /lib

lrwxrwxrwx    1 root     root           19 Jan  1 06:06 ld-linux.so.2 -> ld-uClibc-0.9.28.so
-rwxr-xr-x    1 root     root        18.5k Jan  1 06:06 ld-uClibc-0.9.28.so
lrwxrwxrwx    1 root     root           19 Jan  1 06:06 libc.so.0 -> libuClibc-0.9.28.so
-rwxr-xr-x    1 root     root        10.4k Jan  1 06:06 libcrypt.so.0
-rwxr-xr-x    1 root     root        53.9k Jan  1 06:06 libgcc_s_soft-float.so.1
...
-rwxr-xr-x    1 root     root        84.2k Jan  1 06:06 libuClibc++.so.0
-rwxr-xr-x    1 root     root       283.0k Jan  1 06:06 libuClibc-0.9.28.so


Which gave me information that the C library is actually uclibc which is very light-weight C library that is perfectly fitted for devices with limited RAM and ROM like the camera that I had in front of me. In addition from the information above I also assumed that the uclibc version is 0.9.28.

The final step for the day was to get information about the executable format that was used. For that I needed to copy one of the executable files on my local computer and analyze it. I copied the busybox executable into the FTP server folder and from there I was able to copy it to my machine. For the camera that I had the command looked something like this:

cp /bin/busybox /mnt/ftp/data/.

After the file was moved to the visible FTP folder I just needed to copy it on my laptop and go on with the analysis.

There were two things that I wanted to do:

1. See the executable format
2. See dynamic libraries used in the executable file

For the first part I used the file command.  Running

file busybox


gave me the following information:

ELF 32-bit LSB  executable, ARM, version 1, dynamically linked (uses shared libs), stripped


For the second part I used the readelf command which allowed me to see the used shared libraries in this executable:

readelf -d busybox


Dynamic section at offset 0x3e790 contains 22 entries:
Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libcrypt.so.0]
0x00000001 (NEEDED)                     Shared library: [libgcc_s_soft-float.so.1]
0x00000001 (NEEDED)                     Shared library: [libc.so.0]
0x0000000c (INIT)                       0xaefc
0x0000000d (FINI)                       0x3cbcc
0x00000004 (HASH)                       0x80e8
0x00000005 (STRTAB)                     0x9b3c
0x00000006 (SYMTAB)                     0x897c
0x0000000a (STRSZ)                      2270 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000015 (DEBUG)                      0x0
0x00000003 (PLTGOT)                     0x4e868
0x00000002 (PLTRELSZ)                   2072 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0xa6e4
0x00000011 (REL)                        0xa674
0x00000012 (RELSZ)                      112 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x6ffffffe (VERNEED)                    0xa654
0x6fffffff (VERNEEDNUM)                 1
0x6ffffff0 (VERSYM)                     0xa41a
0x00000000 (NULL)                       0x0


From that point on I was ready to go to the next big step: add new software to the camera, test it and make the camera more secure. That is something that you will learn in the next article. Now remove the dust from your Medion or No-Name security/baby-sitter camera and see what you have. You might be pleasantly surprised the there is already some Linux running.

You can share your analysis as comments to this article.