24 ms·

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 dev

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.

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.