8 ms·

Breaking the D-Link DIR3060 Firmware Encryption – Recon – Part 1

86 points by dvaun 6y ago

dvaun 6y ago
For those who are interested and found the article interesting there are additional posts in this series. The second[0] and third[1] posts are quite neat. [0]: https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encryption-static-analysis-of-the-decryption-routine-part-2-1/ https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encr... [1]: https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encryption-static-analysis-part-2/ https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encr...
scohesc 6y ago
I'm not an expert (so I might be wrong here question-wise), but it seems to me that using the same type of encryption "key" to lock down firmware on various devices sounds like a very ill-advised way to do things. It seems like it would be possible that once you find the "key" for one router, you could potentially exploit a bunch of other router/switch models as well. Am I incorrect in this thinking?
- dvaun 6y ago
  IIRC there have been similar issues in the past with other hardware (what comes to mind are "smart" items such as locks, wifi cameras, etc.). As for software, there was an issue earlier this year with Exchange Server failing to generate unique keys [0] (prev. discussion[1]). [0]: https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-c... [1]: https://news.ycombinator.com/item?id=22424260 https://news.ycombinator.com/item?id=22424260
- stefan_ 6y ago
  Encryption for firmware updates is only to obscure the contents. The imgdecrypt binary here also references RSA_verify and similarly public-key cryptography sounding names so I assume they are using that to authenticate the firmware images (checking for a D-Link signature). Of course this is D-Link and the product is an embedded garbage router, so chances are high they are doing it entirely wrong.
  - 0xricksanchez 6y ago
    You're right with your assumptions! If you go to part 3 pretty much to the bottom of the article there's a good summary of what fields are included in their firmware verification headers. TL;DR: They verify the length of the encrypted and decrypted firmware as well as multiple RSA signatures. As much as I like pushing security vectors on embedded/IoT devices... This approach of obscuring what is being pushed in an update may not be the right approach imo.
nneonneo 6y ago
Cool! One question: I wonder why they didn’t just use GHIDRA to reverse engineer the MIPS binary? GHIDRA can decompile MIPS and does quite a passable job. IDA is an awesome tool (and still edges out GHIDRA for ARM/x86 if you have the decompiler), but my experience is that GHIDRA is way nicer for pretty much any other architecture. YMMV. I appreciated the writeup, especially since I’ve done some firmware decryption and repacking myself (although in my case, the encryption was just repeating-XOR!).
- stefan_ 6y ago
  Particularly since this is a dynamically linked executable that does exactly one job.
- 0xricksanchez 6y ago
  Hi, As much as I have to give credit to Ghidra and its capabilities and I just don't like using it. I find the UI/UX very awful. So I decided to just reverse it in IDA. After I was done with everything I double-checked what I had re-constructed from the disassembly with what Ghidra suggested the decompilation may look like. To be honest they were pretty similar. So again, Ghidra is really powerful tool, I just dislike it :)
rbecker 6y ago
> the firmware encryption that was put in place to prevent tampering and static analysis Code signing is enough to prevent tampering, so D-Link obviously doesn't want their users to know how their own hardware works. Does D-Link view their users as the adversary? If so, should the users view D-Link as hostile?
- rstat1 6y ago
  I was initially thinking it was to prevent security research so they don't end up getting fined again for pushing buggy insecure garbage. I quickly reversed that thinking, knowing DLink's rep for pushing buggy insecure garbage.
AviationAtom 6y ago
Secure through obscurity, the age old security solution!
notaplumber 6y ago
At least a few models of Linksys/Cisco home routers I own had their firmware "encrypted" using GnuPG. They had the extension .gpg.img but could simply be decrypted with: $ gpg --output decrypted.img --decrypt <model><ver>.gpg.img binwalk can handle the rest. It looks like they mainly did this for verification, as there is an RSA public key embedded on the device. It unfortunately does make it nearly impossible to flash any modified firmware such as OpenWRT, which is very frustrating. I say nearly as I haven't fully investigated the models that I own. Some routers have a emergency recovery flash method that may bypass the PGP check, I recall older D-Link models having a web flasher integrated into u-boot.
- xfer 6y ago
  Embedded where? If it is on a writable flash then you can probably rewrite with your own public key?
  - 0xricksanchez 6y ago
    They make use of /etc_ro/public.pem to verify the integrity of a firmware update. So flashing a custom firmware (e.g.: OpenWRT) will fail all checks they put in place. I did not investigate how one could circumvent the update mechanism yet but if you're interested in doing so for these particular models my GitHub repo (https://github.com/0xricksanchez/dlink-decrypt https://github.com/0xricksanchez/dlink-decrypt) has a decryption script for these firmware images so you can snoop around the file system for further clues.
    - notaplumber 6y ago
      I think they were replying to me about the Linksys/Cisco routers, but it is similar in that the public key is contained on the filesystem and prevents flashing any firmware not signed with it. What's worse is they added this after the fact to several models in later firmware versions, making it impossible to downgrade to older unsigned versions. Unlike with yours, no decryption script is required, gnupg can decrypt them as-is.
  - notaplumber 6y ago
sloshnmosh 6y ago
I LOVE this kind of stuff! I was able to finally extract the squashfs file from my routers firmware using dd and program I found on github called “sasquash” which patches decompression tools and can also flip endianness.
- 0xricksanchez 6y ago
  Thanks! Much appreciated :)
0xricksanchez 6y ago
Hey, I'm the author of this series (see my Twitter "rant": https://twitter.com/0xricksanchez/status/1290291267914563585 https://twitter.com/0xricksanchez/status/1290291267914563585 or my repo with the re-constructed source code here: https://github.com/0xricksanchez/dlink-decrypt/blob/master/src/imgdecrypt.c https://github.com/0xricksanchez/dlink-decrypt/blob/master/s... ) All your thoughts and feedback are much appreciated :). I'm happy if you guys liked it! cheers
- sschueller 6y ago
  Thank you for doing this.

86 points by dvaun 6y ago

For those who are interested and found the article interesting there are additional posts in this series. The second[0] and third[1] posts are quite neat. [0]: https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encryption-static-analysis-of-the-decryption-routine-part-2-1/ https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encr... [1]: https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encryption-static-analysis-part-2/ https://0x434b.dev/breaking-the-d-link-dir3060-firmware-encr...

scohesc 6y ago

I'm not an expert (so I might be wrong here question-wise), but it seems to me that using the same type of encryption "key" to lock down firmware on various devices sounds like a very ill-advised way to do things. It seems like it would be possible that once you find the "key" for one router, you could potentially exploit a bunch of other router/switch models as well. Am I incorrect in this thinking?

dvaun 6y ago
IIRC there have been similar issues in the past with other hardware (what comes to mind are "smart" items such as locks, wifi cameras, etc.). As for software, there was an issue earlier this year with Exchange Server failing to generate unique keys [0] (prev. discussion[1]). [0]: https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-c... [1]: https://news.ycombinator.com/item?id=22424260 https://news.ycombinator.com/item?id=22424260
stefan_ 6y ago
Encryption for firmware updates is only to obscure the contents. The imgdecrypt binary here also references RSA_verify and similarly public-key cryptography sounding names so I assume they are using that to authenticate the firmware images (checking for a D-Link signature). Of course this is D-Link and the product is an embedded garbage router, so chances are high they are doing it entirely wrong.
- 0xricksanchez 6y ago
  You're right with your assumptions! If you go to part 3 pretty much to the bottom of the article there's a good summary of what fields are included in their firmware verification headers. TL;DR: They verify the length of the encrypted and decrypted firmware as well as multiple RSA signatures. As much as I like pushing security vectors on embedded/IoT devices... This approach of obscuring what is being pushed in an update may not be the right approach imo.

nneonneo 6y ago

Cool! One question: I wonder why they didn’t just use GHIDRA to reverse engineer the MIPS binary? GHIDRA can decompile MIPS and does quite a passable job. IDA is an awesome tool (and still edges out GHIDRA for ARM/x86 if you have the decompiler), but my experience is that GHIDRA is way nicer for pretty much any other architecture. YMMV. I appreciated the writeup, especially since I’ve done some firmware decryption and repacking myself (although in my case, the encryption was just repeating-XOR!).

stefan_ 6y ago
Particularly since this is a dynamically linked executable that does exactly one job.
0xricksanchez 6y ago
Hi, As much as I have to give credit to Ghidra and its capabilities and I just don't like using it. I find the UI/UX very awful. So I decided to just reverse it in IDA. After I was done with everything I double-checked what I had re-constructed from the disassembly with what Ghidra suggested the decompilation may look like. To be honest they were pretty similar. So again, Ghidra is really powerful tool, I just dislike it :)

rbecker 6y ago

> the firmware encryption that was put in place to prevent tampering and static analysis Code signing is enough to prevent tampering, so D-Link obviously doesn't want their users to know how their own hardware works. Does D-Link view their users as the adversary? If so, should the users view D-Link as hostile?

rstat1 6y ago
I was initially thinking it was to prevent security research so they don't end up getting fined again for pushing buggy insecure garbage. I quickly reversed that thinking, knowing DLink's rep for pushing buggy insecure garbage.

AviationAtom 6y ago

Secure through obscurity, the age old security solution!

notaplumber 6y ago

At least a few models of Linksys/Cisco home routers I own had their firmware "encrypted" using GnuPG. They had the extension .gpg.img but could simply be decrypted with: $ gpg --output decrypted.img --decrypt <model><ver>.gpg.img binwalk can handle the rest. It looks like they mainly did this for verification, as there is an RSA public key embedded on the device. It unfortunately does make it nearly impossible to flash any modified firmware such as OpenWRT, which is very frustrating. I say nearly as I haven't fully investigated the models that I own. Some routers have a emergency recovery flash method that may bypass the PGP check, I recall older D-Link models having a web flasher integrated into u-boot.

xfer 6y ago
Embedded where? If it is on a writable flash then you can probably rewrite with your own public key?
- 0xricksanchez 6y ago
  They make use of /etc_ro/public.pem to verify the integrity of a firmware update. So flashing a custom firmware (e.g.: OpenWRT) will fail all checks they put in place. I did not investigate how one could circumvent the update mechanism yet but if you're interested in doing so for these particular models my GitHub repo (https://github.com/0xricksanchez/dlink-decrypt https://github.com/0xricksanchez/dlink-decrypt) has a decryption script for these firmware images so you can snoop around the file system for further clues.
  - notaplumber 6y ago
    I think they were replying to me about the Linksys/Cisco routers, but it is similar in that the public key is contained on the filesystem and prevents flashing any firmware not signed with it. What's worse is they added this after the fact to several models in later firmware versions, making it impossible to downgrade to older unsigned versions. Unlike with yours, no decryption script is required, gnupg can decrypt them as-is.
- notaplumber 6y ago

sloshnmosh 6y ago

I LOVE this kind of stuff! I was able to finally extract the squashfs file from my routers firmware using dd and program I found on github called “sasquash” which patches decompression tools and can also flip endianness.

0xricksanchez 6y ago
Thanks! Much appreciated :)

0xricksanchez 6y ago

Hey, I'm the author of this series (see my Twitter "rant": https://twitter.com/0xricksanchez/status/1290291267914563585 https://twitter.com/0xricksanchez/status/1290291267914563585 or my repo with the re-constructed source code here: https://github.com/0xricksanchez/dlink-decrypt/blob/master/src/imgdecrypt.c https://github.com/0xricksanchez/dlink-decrypt/blob/master/s... ) All your thoughts and feedback are much appreciated :). I'm happy if you guys liked it! cheers

sschueller 6y ago
Thank you for doing this.