This blog post has been created for completing the requirements of the SecurityTube Offensive Internet of Things course.
Student ID: IoTE-728
My web camera can be used with MyDLink Lite android application. It can search web cameras on local network, but it can also connect to a cloud service and display a registered camera view.
When I test a mobile application, I create an Access Point and connect the mobile to this AP. I redirect the network traffic through the Burp Suite Proxy, so that I can examine it with Burp. I can also use Wireshark to examine the network packets the mobile application sends. I use 2 bash scripts to start and stop the AP. The start and stop scripts and the steps of installation can be found here. (It is important to set the Burp Proxy as invisible!)
If the mobile application does not check the validity of the server certificate, this configuration works without any modification. This is a serious issue (insecure communication), because an attacker can perform MitM attack.
However if the mobile application checks the validity of the server certificate (improper handling of SSL certificates), then the Burp Suite certificate should be installed into the trust store of the device. An attacker can use a social engineering attack or other trick to convince the user to install the attacker’s certificate into the trust store. If this attack is successful, then a MitM attack is also feasible. (Another solution is compromising a Certificate Authority.) In this solution the application trusts in the trust store of the device. Since only the user can install certificates into the trust store, the application trusts in the user of the device.
The most secure solution is when the application checks the validity of the server certificate and accepts only a certain certificate. This is called certificate pinning. In this case the application does not trust in the user and the trust store of the device. In this case the fake Access Point works only if we can bypass the certificate pinning somehow.
With this configuration I was able to perform MitM attack after I installed the certificate of Burp into the trust store of the device. The application checks the validity of the server certificate but there is no certificate pinning. I managed to log the network traffic, when I logged in to the cloud account.
I concluded that the whole network went through HTTPS, which is a good pratice. However I was able to position myself between the mobile device and the cloud service, because there was no checking of certificates. This is a serious issue, because an attacker can eavesdrop or even modify the traffic.
I also noticed, that the android application sent the username and password in the URL. According to the best practice sensitive information should not be sent in the URL, but in the body of a POST method, because the URLs might be logged or stored somewhere and the attacker could find it.Moreover the password value in the query string was the MD5 of the actual password. MD5 is easy to crack especially if the password is not complex.
After the android application successfully logged in, it received an access_token, which was included in the URL of all subsequent requests.
I also examined the network traffic with Wireshark. In case the network is not an HTTP or HTTPS traffic, Burp Suite will not show anything, however Wireshark will log everything.
When I searched local cameras with the android application, I saw that UDP packets was sent by my mobile device. The destination UDP port was 5978.
I downloaded the apk file from the device.
I opened a shell with adb and went to the application folder.
Under the files folder I found a file dcs_930lb1.png. The name of this file reveals the type of the device I have. The id_user_data file is a binary file, but I could read the cloud username from it. Probably the password is also stored in it.
There is no root detection in the application. An attacker can root a stolen device and get these information.
I checked the system log. Sometimes the application writes sensitive information into the log, such as login usernames and passwords. I did not find any vulnerability this way.
I decompiled the apk file with jadx-gui. I noticed, that the application was obfuscated (The class and method names are replaced with one character).
I searched key strings in JADX, like password, secret, aes, crypto, etc. I found that the com.dlink.mydlink.lite20.a.f obfuscated class is used for encryption/decryption. The static function marked with green arrow is used to generate keys for the AES-256 algorithm. (AES-256 is an acceptable algorithm as the key length is large enough to provide decent protection against brute-force attack. However ECB does not have any chaining, so it can be used only for short messages.)
I right-clicked on the static method and selected the option which showed the places where this function is used. I noticed that a hardcoded string is passed always as a parameter. This string is a base64 encoded string and the AES key can be calculated from it. With these information an attacker can reverse engineer the cryptosystem used by this application.
I decompiled the base64 encoded string. It seemed to be a random number.