Authors: Simona Musilova (@siimi_m_) and Sebastian Garcia (@eldracote)
This is a follow-up blogpost from the IoT Honeypot Analysis Series we have started earlier (here and here). In this episode we go more into understanding packets sent from and to the Edimax IC-7113W camera by using reverse engineering techniques and some hacking.
Our goals in this part are a little bit different from previous blogposts. In this article we focus on:
Understanding what methods the firmware developers used to encrypt / obfuscate the payload in packets.
Understanding the meaning of packets we captured but have never been mentioned before.
Decrypt all payloads of each packets and reconstruct the communication in plain text.
Encryption methods
The messages sent from or to the camera are in XML format containing different values. On the Figure below you can see an example of such decrypted payload.
This text is not sent unencrypted in the network, but using some type of encryption. There are two different ways of encryption of the payload in the traffic.
Shifting bits
The first method of obfuscation used is based on shifting bits of the payload bytes. To explain this method, take a look at the Figure below, where the payload of the packet is highlighted. As we know, all payloads are in XML format, so the very first character should be ‘<’ (0x3c). The difference between this value and the very first byte in the encrypted payload (0x43 on the Figure below) gives us the number of positions to the left that each bit should be shifted in all the following bytes.
In this example the difference is 0x43 - 0x3c = 7. Now we can shift to the left every bit in the following bytes. The next byte is 0xe0 (= 1110 0000), left shifted by 7 positions in circular gives us 0111 0000 which is 0x70, or character ‘p’ in ASCII. This way we can get the message on the previous Figure.
This method was mentioned before [1]. In this report you can also find a dissection module to add to Wireshark, so you can see the payload in plain text. Another good explanation can be found in other reports [2].
AES-256-CBC
The second method used by the camera to encrypt the payload is the Advanced Encryption Standard (AES) algorithm. The AES is very secure encryption standard used to protect classified information. It is a key-symmetric algorithm, which means there is only one key used for both, encryption and decryption of the payload. There are many different versions of the AES algorithm, but we will focus on the AES-256-CBC which is used by the camera - the number 256 in the AES version name refers to the length of the key in bits and the CBC specifies the method used in the encryption and decryption algorithms.
The Cipher Block Chaining (CBC) method works with blocks of data in each iteration, the length of each block is 128 bits (16 Bytes). If the last block of the plain text is not 128 bits long, then there has to be a padding appended to the last block. After this step, the algorithm can successfully encrypt the plain text.
Another important element of the AES-CBC algorithm is the Initialization Vector (IV) of length 128 bits (16 Bytes). Its purpose is to randomize the encryption and to make sure that for the same input plain text, the algorithm produces different encrypted output. The very same IV should never be used with the very same key as it might leak information about the internal structure of the algorithm. It is not necessary to keep IV in secret the same way as the key. Without having the key, the attacker cannot decrypt the message.
The last, but not least, element of the AES algorithm is the key itself. In this version, the length of the key is 256 bits. The key can be reused, but each time with a new IV. Also, it is important to keep the key secret, but also to share it with the receiver of the message. The key length of 256 bits makes it very difficult to brute force, since we still don’t have such powerful computers or enough time to be meaningful.
Payload
The camera is communicating with two servers, Registration server (122.248.252.67) and Command Relay server (122.248.234.231). Most of the communication is done using the UDP protocol, which means that every packet is sent multiple times and the communication might be interrupted by missing packets. The traffic we captured can be divided into three logical sections.
Registration process
The very first thing the camera does when connected to the internet is the registration to its servers. The process begins with the first packet sent from camera to the Registration server, whose IP address is obtained either by DNS request or, if this fails, one is hardcoded in the source code of the firmware. The server replies with information about the Command Relay server. Then the camera sends a registration packet to this server. As far as we know, from previous work [1] [2], there should be a reply from this server. In our captured traffic, there is no answer. The payload of each packet was obfuscated by the bit shifting method mentioned above. For more details about this process, read our previous blogpost here.
Keep-alive
After the registration process is finished, the camera is sending packets informing the registration server that it’s still online [2][3]. These packets are obfuscated by the bit shifting method. Also, every 20 seconds the camera is sending a packet with the very same payload all the time to the registration server. This packet contains only 4 bytes [22 16 45 80]. It looks like these packets are there only to keep the connection opened in the router [1]. Since there are only 4 bytes and they are always the same, we assume that this value is hardcoded and it’s not obfuscated or encrypted message.
New packets found in the traffic
The last section is about those messages that have never been mentioned before in any other research. We captured new packets without any known meaning so far. The first unknown packet is shown in the following Figure. The payload was obfuscated by the bit shifting method and in the Figure below you can see the plain text. The payload contains ‘<code value=”1090”>’, ‘chk value’, ‘id value’ and ‘vendor value’. The meaning of this packet has been unknown for us until now.
We also found two new subsequent packets with similar payloads. First one is going from the camera to the registration server, the length of its payload is 660 Bytes and the payload starts with bytes [01 40 00 00]. The following packet is going from the registration server to the camera as an answer to the previous packet. The length of this packet’s payload is 228 Bytes and it starts with the very same bytes [01 40 00 00].
The last two packets have been a big mystery at first, but after looking at the source code of the firmware, we found out that part of them had been encrypted with the AES-256-CBC algorithm. We explain how these packets has been put together with an example on the smallest of them, but the process is the same for both. Let’s divide the payload bytes into 4 parts, as can be seen in the Figure below.
The very first 4 Bytes of the packet are always the same. The values [01 40 00 00] are hardcoded in the firmware and it seems like they are an indicator of the payload encrypted by AES algorithm.
The following 16 Bytes of the payload is the Initialization Vector (IV) for the AES algorithm. This value changes with every packet sent as it is not secure to reuse them with the very same key.
The third part, containing 64 Bytes, is the very same string as the ‘id value’ in the previous packet with ‘<code value=”1090”>’ in the payload. This part is the same for all packets containing an encrypted payload by AES. It seems like this part is some kind of an ID of the camera.
The last part is the encrypted payload. As can be seen on the Figure above, it can be divided into blocks of 16 Bytes which fulfils the condition of the AES algorithm.
The AES key
Until now, we identified the algorithm used for encryption and we understood the new type of packets from which we got the IV and the encrypted payload. Now the only thing to get is the AES key. We were able to identify the curl command the camera use for getting the key. The command can be seen below.
curl --cacert curl-ca-bundle.crt -s -d '{"devid":"%s","mac":"%s","vendor":"%d","snType":"%d","chk":"%s"}' https://www.myedimax.com:55443/webs/gk.phpSince the camera is using the HTTPS protocol, we couldn’t read the query or the answer in the captured traffic. The curl command requires a certificate which can be found in the firmware, and correct variables to fill the query in. Until now, we couldn’t get the correct variables to obtain the key, so we couldn’t decrypt the payload.
Conclusion
After analyzing the traffic and the firmware of the camera, we can conclude that the developers at Edimax moved forward with securing the data their devices are sending through the network. Instead of using a simple obfuscation algorithm for all packets the device send, they now also use the AES-256-CBC algorithm to protect any sensitive information that might be in those packets. They also protect the AES key so it cannot be easily sniffed in the network.
[1] http://blog.guntram.de/?p=37
[2] http://jin.ece.ufl.edu/papers/GlobeCom17-CR.pdf
[3] https://www.stratosphereips.org/blog/2019/2/15/iot-honeypot-traffic-analysis-series
Acknowledgement
This research was done as part of our ongoing collaboration with Avast Software in the Aposemat project. The Aposemat project is funded by Avast Software.
