Authors: Simona Musilova (@siimi_m_) and Sebastian Garcia (@eldracote)
In this IoT Honeypot Analysis Series, we focus on the traffic analysis of the Edimax IC-7113W camera. In this episode, we will continue with the analysis of the encrypted packets mentioned in the previous episode [here]. Our goals for this blog post are:
to obtain the AES key from the Edimax server
to understand what happens with the communication after we obtain the AES key
to get a plaintext of the encrypted payload sent from the camera to the server
The AES Key
In the previous part of this series, we mentioned two different ways of encoding/encrypting the payload in the network traffic. The first method is a simple bit-shifting algorithm while the second method is the AES-256-CBC algorithm.
We were able to identify the Initiation Vector for the AES algorithm, but we couldn’t find the correct AES key. By using reverse engineering techniques we found a curl command used to download the AES key from the Edimax server:
The correct certificate can be found in the firmware of the camera. We tried to send this command to the Edimax server, but we were not able to correctly fill in all the parameters to get any reply from the Edimax server. We continued with the analysis of the camera firmware. Our goal was to find out if the parameters in the curl command mentioned above are also used in other commands that we can already decode.
In the previous part of this series, we mentioned a packet that we could decode by the simple bit-shifting algorithm, but we didn’t fully understand its meaning. It was the following packet with the <code value=”1090” /> parameter. We found out that the ‘id value’ is an identification of the camera and it is also a part of the payload of the new packets, where part of the payload is encrypted by the AES-256-CBC algorithm. The meaning of the ‘chk value’ and ‘vendor value’ were unknown for us.
We found out that three of the parameters in the payload of this packet are used in the curl command to obtain the AES key.
the string value of <chk value=”..”> equals to the string value of ‘chk’ in the curl command
the string value of <id value=”..”> equals to the string value of ‘devid’ in the curl command
the integer value of <vendor value=”0”> equals to the integer value of vendor in ‘curl’ command
The string value of the ‘mac’ parameter in the curl command equals to the MAC address of the camera, which is a known value. The integer value of the ‘snType’ parameter is the only unknown value in the curl command.
The integer value of the ‘snType’ parameter can be easily brute-forced. After a couple of tries, we found the correct value, ‘snType’:’1’. After sending the curl command with correct parameters, the server replied with an AES key in the following format.
The key we obtained from the server cannot be used to decrypt payload in packets captured before. Every time any device requests an AES key, the Edimax server generates a new one and sends it back to the device.
Camera Behaviour
From the previous analysis of the captured traffic, we could identify some patterns in normal camera traffic.
Right after booting up the camera and then every 24 hours we can see a TLS connection to the Edimax server, port 55443/TCP. This is the camera asking for a new AES key sending the curl command mentioned above and the Edimax server replying back.
Every 20 minutes there is a packet with a payload of length 660 Bytes going from the camera to the Edimax server. Then the server replies with a payload of length 228 Bytes back to the camera. The payload of both of those packets starts with 01 40 00 00 bytes. Those two packets contain the IV for the AES algorithm, identification of the camera and the payload encrypted by the AES algorithm.
This pattern can be seen in the traffic if everything works accurately. Once we sent the curl command to the Edimax server with correct values from a different device, the server generated a new AES key that was sent back to us. From that moment, the server was using a new AES key, but the camera was still using the previous one.
The communication between the Edimax camera and the Edimax server was interrupted. Each device was using a different AES key, so none of them could decrypt and understand what the other device had sent. The camera, not knowing that the key had changed, tried to send a packet with encrypted payload to the Edimax server. The server, using a new AES key, couldn't decrypt the payload and understand it, so it didn’t reply at all. The behaviour of the camera changed as well.
After the camera sent the encrypted payload, it was waiting for an answer from the server. When the answer didn’t arrive in 10 seconds after sending the first encrypted packet, the camera sent a new packet with the same payload length (660 Bytes) containing only 0x00 Bytes. Again, the Edimax server didn’t reply. After another 10 seconds, the camera sends the packet with only 0x00 Bytes in the payload again. This packet is followed by no answer from the server. 10 seconds later, the camera tried to register itself in the server again. This process finished successfully.
After that, the camera tried to send the encrypted payload to the server again. But it still had an old key, so the server didn’t reply. This whole cycle of the camera sending an encrypted payload to the server, waiting for an answer, then sending two packets with 0x00 Bytes and followed by a registration process was happening every 60 seconds.
This cycle of unsuccessful communication with the Edimax server ended at the moment when the camera asked for a new AES key. The server generated a new key and sent it back to the camera. From that moment, the Edimax server and the Edimax camera had the same shared key and they could communicate together again.
The issue is, that the camera is asking for a new AES key once in 24 hours, no matter what. It didn’t ask for a new key before this 24 hours cycle was over even when it couldn’t communicate with the server anymore.
The Encrypted Payload
When analysing the firmware on the camera, we could identify the part of the code where the encrypted payload is created and sent to the Edimax server. The plain text of the encrypted part is as follows:
Some of the needed parameters to fill in this command are hardcoded in the firmware, some of them are known to us as they are used in other packets’ payload. From the values we could understand we know that the camera is sharing some statistics to the server:
information about the camera: model of the camera, firmware version, hardware version
information about the network: internal IP address of the camera, opened port in the camera
other information: time zone where the camera is located
So far we couldn’t identify all of the parameters needed to fill in this payload and to send it to the Edimax server. We also didn’t decrypt the answer from the server, so we don’t know yet what it is sending.
Conclusions
The security of the Edimax camera and the payload it is sending to the network is full of questions. The camera is using two different algorithms to manage its data - a very simple bit-shifting algorithm and the AES-256-CBC. From our point of view, the developers of the firmware are trying to secure the payload sent to the network. The approach they used looks secure at first sight, but the fact that some of the parameters can be easily brute-forced doesn’t make it reliable. We will continue with our research to see what we can find.
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.
