Akuvox – Intercom and Doorbell (IoT Case Study)

They are powered by the operating system Android and apart from the hardware equipment and their purpose of use, they are not so much different when it comes to software. They share all security findings, as if the devices were copying from each other.

Physical security

The key to every IoT device is finding the service port – currently, the most common one is UART interface providing access to the console of the proprietary Linux-based system. Since our devices had OS Android inside, it was to be expected that the console could be accessed through ADB interface with USB port. Therefore, we dismantled both devices and before long, we found the micro USB connector we were searching for.

Is the connector functional? Is the system protected against unauthorised access?

The connector was more than functional; after connecting it, we immediately discovered that the system’s ADB debugging for USB is on and it offered trust to our hacking notebook:

The command line also enables elevating the privileges to the root user level:

What does this indicate? It means that the devices are rooted (unlocked) from the factory, and anyone connecting to the console connector gains complete control over the operating system. Very dangerous configuration. Given the fact that the Akuvox R29F device should be protecting entrance door to a secure building as well, we don't have to explain that by drilling a small hole and connecting a USB cable, an uninvited guest can open the door. But more on that later.

Operating system

As we already mentioned, the devices are powered by the Android operating system. Namely version 6.0.1 in case of Akuvox IT83 and 5.1.1 in case of the Akuvox R29F device, which was almost four years old even at the time when the doorbell was launched. New versions of firmware are still available for download at the manufacturer’s website, however, we found out that even after updating to the newest version, the Android version staid the same.

If the attacker has a debug interface on Android, he can access the parts of the system inaccessible to a common user. For example it is possible to call up the system setup by starting the following activity in the Settings application:

am start -a android.settings.SETTINGS

Let’s talk about debugging some more. Each Android device has a so-called logcat console. Here, the system and apps write info/debug/warning/error information. It is an analogy to a Linux syslog. Various information of interest to a potential attacker may (but need not and should not) be present in this console.

We had the following setting on our devices during the testing: PIN for the door unlocking is 33334444 and PIN after the device setting was unlocked is 3888. After entering the PIN, the following information was shown in the logcat:

01-07 14:32:00.120: E/BluetoothAvrcpController(834): at android.bluetooth.BluetoothAvrcpController$1.onBluetoothStateChange(BluetoothAvrcpController.java:80)
01-07 14:32:07.544: E/BluetoothAvrcpController(834): at android.bluetooth.BluetoothAvrcpController$1.onBluetoothStateChange(BluetoothAvrcpController.java:80)
01-07 14:35:01.804: E/isDoorphoneUserSettingKey(1103): Controller.java: isDoorphoneUserSettingKey(1922): [3338][3888]
01-07 14:35:07.974: E/isDoorphoneUserSettingKey(1103): Controller.java: isDoorphoneUserSettingKey(1922): [3338][3888]
01-07 14:35:12.224: E/isDoorphoneUserSettingKey(1103): Controller.java: isDoorphoneUserSettingKey(1922): [3888][3888]
01-07 14:53:02.975: E/isDoorphonePublicKey(1103): Controller.java: isDoorphonePublicKey(1909): [33334444][33334444]
01-07 14:54:20.029: E/isDoorphonePublicKey(1103): Controller.java: isDoorphonePublicKey(1909): [22222222][33334444][1]
01-07 14:55:31.640: E/isDoorphonePublicKey(1103): Controller.java: isDoorphonePublicKey(1909): [28888888][33334444][1]
01-07 14:55:38.855: E/isDoorphonePublicKey(1103): Controller.java: isDoorphonePublicKey(1909): [33334444][33334444][1]
01-07 14:57:56.680: E/isDoorphoneUserSettingKey(1103): Controller.java: isDoorphoneUserSettingKey(1922): [3888][3888]

Thus, the system is not only logging which PINs the user enters for unlocking, but, at the same time, it lists which are the correct ones! Example: the attacker enters wrong PIN 22222222 and the console shows the following information: “22222222 was entered but 33334444 is correct”. We have not come across such behaviour (thanks god) in all our years of testing IoT devices and we see it as totally alarming!

Let’s stay for a while with the passwords and PINs. Because they are stored in configuration files in the folder structure in the flash memory. Did we discover some lapses here as well? Yes, two of those.

First one: some PINs (e.g. the one to the settings or the one for the door opening) are stored in a plaintext, unencrypted format.

...
[ PASSWORD ]
ProjectKey=9999
UserSettingKey=3888
SystemSettingKey=9999
PublicKey=33334444
PublicKeyEnable=1

[ MOTION_DETECT ]
ImageCapture=0
ImageCaptureShow=1
MotionDectect=0
Interval=10
SendType=0
DetectDelay=60
CaptureDelay=10
DetectAccuracy=20
FtpServer=test.ftp.com
FtpPort=21
FtpUser=root
FtpPwd=QYeEnIlewrY/j3F8XJphaJsykAjE8bM3LcVQlQihQcOEkqH1MzNBQ0GGaLM3
...

Passwords, such as the one for SMTP (sending notification e-mails) or to the FTP storage are correctly encrypted.

Second one: the rights to the files in the filesystem are set to 777 (rwx) for all users. This means that is it easy to access configuration files, read passwords from them and change them. All that even in cases when the devices are not rooted. The manufacturer made its work during development much easier, but at the expense of security.

The last reference to the insufficient security within the operating system is about passwords, various codes, and PINs once again. There are no checks for brute force attacks whatsoever within any of the login dialogues for entering the password or PIN (including the web administration). Therefore, an attacker has an unlimited number of attempts to try and guess these passwords and on top of that, there is no complexity check when the passwords are being set up.

Network services

Another area requiring attention during the IoT testing is the device’s communication with the surrounding world. Here we have a wired communication over the LAN network (the devices do not support Wi-Fi). There is some chance that the login details may be stolen (access to the web administration is unencrypted, connection to FTP and SMTP is unencrypted…) but it is very small, because the attacker would have to gain access to the network as the Man in the Middle.

The security of live stream from the camera requires a special comment. This concerns the Akuvox R29F doorbell only. Its stream is implemented with the so-called ONVIF interface, which is the current standard for all modern IoT cameras. This ONVIF interface then provides streaming of the image from the camera.

We could access the ONVIF interface at this URL: http://IP_ADDRESS:8090/onvif/device_service and it was protected by a name and a password. However, in this case, the camera could be accessed also directly, the ONVIF authentication could be bypassed and the RTSP stream could be opened directly at this link: rtsp://IP_ADDRESS/live/ch00_0. The RTSP stream itself was not protected by authentication. If you wonder how the exact URL of the RTSP stream can be discovered, let us tell you that it can be simply guessed, since the majority of cameras by the same manufacturers has a similar one. URLs for different manufacturers can be also found out for example here: https://www.ispyconnect.com/man.aspx?n=H.264

Web interface

Leaving aside the fact that for an access to the administration an encrypted TLS channel is not required on any of the devices, it must be said that, unfortunately, they also possess the most critical vulnerabilities existing in the web applications.

For example, we can find here the following:

• Remote Code Execution, enabling the remote attacker to run system commands the same as in ADB console.

POST /fcgi/do?id=4&id=3 HTTP/1.1
Host: 10.12.0.191
Cookie: RebootUserName=admin; SessionId=99856
...
Connection: close

SubmitData=begin%26cDeleteFile%3D0.wav';ping –c 1 10.50.42.24;'%26Operation%3DDelete%26SubmitData%3Dend

• Authentication bypass – simply load the following page http://IP_ADDRESS//fcgi/do?id=6&id=2&Operation=GetDivContent&DivName=divUpgradeStatus and a valid administrator’s Session ID will return as an answer from the server.

HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
Date: Fri, 24 Jan 2020 09:45:07 GMT
Server: lighttpd/1.4.30
Content-Length: 200

<form name='hiddenValForm_Div'>
<input id=hcAutoPFaildReason_Div type=hidden value='2;'>
<input id=hcAutoPStatus_Div type=hidden value='1'>
<input id=hcSessionIdNow type=hidden value='44782'>
</form>

Please note that the Session ID consist only of five numeric characters, i.e. to guess right any of the valid ones, it is enough to send out a few thousand requests to the server and it is possible to find it even without the said bypass.

• Cross Site Scripting – when the form field “Web Title” at the link http://IP_ADDRESS/fcgi/do?id=889 is not checking the access for the presence of the javascript code.

Conclusion

In this case, our verdict is uncompromising – the condition of security on both devices is very poor and the users should avoid them like a plague. User data, the operated services, and even the system itself are not protected.

Let’s repeat what we said several times before. These are devices connected to the network, in worse cases, to the Internet. We entrust them with our data, we use them to protect our property. Especially nowadays, the manufacturers have to pay great attention to the security of their devices, take care of their quality, and not simply go and try to develop the cheapest possible device that will bring them the highest sales margin.