My Zero Day to Get Inside the Network of a D-Link WiFi Camera Customer (And Takeover the IoT Device)
This write-up will talk about how I found a zero-day by reverse engineering an IoT device that I bought in Amazon called D-Link DCS-8300LHV2 mydlink Full HD Wi-Fi Camera and gained the following capability after doing so:
- Get the encoded (that can be easily decoded) WiFi password where the IoT device is connected which gives another attack vector for the hackers (hacking the customer via internal network)
- Get the dev account username and password then PIN code in plaintext to fully control the IoT device remotely
Fortunately, D-Link’s security team is fast to respond and quickly accepted and confirmed the vulnerability for versions 1.02.03 which is still widely being sold to the market as you can see in the Amazon link above. They are kind to let me have a public disclosure of this and use my blog for their announcement regarding this vulnerability.
Steps to Reproduce:
- Opening the Hardware:
Open up the WiFi camera like a surgeon, for real, I have to use a plastic knife that looks like a scalpel just to open it up since it does not use screws in the round part, only in the stand.
2. Identifying the Debugging Interface
In this case, it is a UART as show in the image below. I assumed that it is a UART since it has a label of R, T and G which is translatable to Tx, Rx and GND that is the usual pins for UART. However, I still double check the voltage using digital multi-meter to make sure it is what it is.
3. Calculate the Baud Rate
Then we determined the baud rate by analyzing the logic of this device. The calculation of the baud rate is shown below in the first image so based on it, we need to determine first the microseconds. We can determine the microseconds by connecting our logic analyzer to the UART and observe the 0’s and 1’s. In our case, the microseconds that we gained is 8.667 so all in all we have around ~115,384 which we can convert to 115200 which is the nearest common baud rate for UART.
4. Problem with Very Small Wholes
There is a big problem that I encounter here, the wholes in the UART is super small where no any existing pins that I currently have fits in it. So I just creatively used a hooked clip that is normally used for firmware extraction and put the tip of it inside since it only has tiny wires. The hook handles that you see in the image below have plastic around them so even if they touch each other, there will be no problem.
5. Connecting to the UART via HydraBus
We can now connect via HydraBus with the following settings: ‘uart’ then ‘device 2’ (since I put the Tx and Rx in PA2 and PA3) and then ‘speed 115200’ then lastly ‘bridge’ and I get to see the activities of the device which we will analyze later.
6. Decoding the WiFi Password Where It Is Connected
While analyzing the boot logs, you can see the logs where it is automatically connects to their WiFi where they were previously connected. In the first image below, you can see the “x” as the WiFi SSID and the “aGVsbG9oZWxsbw==” as the WiFi Password. Looking at it, it is obviously encoded using Base64 because of the equal signs at the last character so in the 2nd image below, you see that we got “hellohello” as the password in plaintext!
Why this is important? If a hacker hacked this device within the vicinity of the customer stealthily, then the hacker will have the capability to get inside the WiFi or network of the customer for later attacks. Having access to the private network of the customer who used this kind of device will give hackers a new whole attack vector to play with in compromising the D-Link customer.
7. Control the Device Remotely
In the first image below, you can also see the logs the plaintext developer account and password of the device. In the second image below, you can also see the unique PIN that can be used to remotely control the device in their mobile app. However, I didn’t include the PIN part since it was previously found by SinSinology in CVE-2023–51629
Realistic Scenario:
- There is a shop who uses this D-Link WiFi camera
- The hacker stealthily get the device at night and check the WiFi password of that shop by analyzing the logs in UART (and the Unique PIN if possible)
- He put it back the D-Link WiFi camera to where it is
- Next day, the hacker parked or stayed nearby the shop and hacked a lot of other devices inside including the device used by cashier, payment terminal, and many other things.
- The hacker may also watch the shop to see activities such as when the employees type their password in the keyboard which a hacker can slow motion so he can see each character you type.
- A lot of possible attack vector opens up when the hacker got access to the WiFi of the shop, what if it is not just a mere shop but a bank? a government? and many other more critical infrastructure? This can go worse than what we are expecting.
Fix:
This attack is visible in firmware version 1.02.03 so by upgrading the firmware of your D-Link Camera to the latest version, as per the D-Link team, these should be fixed.
Conclusion:
You might be thinking “that’s it?”. Well, this is my first time submitting a CVE but I am working on a more complex might-be-bug in some of the IoT devices I am working on and hopefully were able to disclose it publicly some of those in the near future.
Until next time! Happy Hacking!
UPDATE:
D-Link already had a security announcement regarding this vulnerability here where they recognized me as the researcher and they also linked this blog as reference: https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10421
