Hacker News new | past | comments | ask | show | jobs | submit login

Isn’t that more or less impossible since the payload is a private RSA key?



See https://en.wikipedia.org/wiki/Dual_EC_DRBG for another backdoor requiring a private key, in which the key was simply replaced in a subsequent supply chain attack(!) with a key known to the attacker:

"In December 2015, Juniper Networks announced[55] that some revisions of their ScreenOS firmware used Dual_EC_DRBG with the suspect P and Q points, creating a backdoor in their firewall. Originally it was supposed to use a Q point chosen by Juniper which may or may not have been generated in provably safe way. Dual_EC_DRBG was then used to seed ANSI X9.17 PRNG. This would have obfuscated the Dual_EC_DRBG output thus killing the backdoor. However, a "bug" in the code exposed the raw output of the Dual_EC_DRBG, hence compromising the security of the system. This backdoor was then backdoored itself by an unknown party which changed the Q point and some test vectors.[56][57][58] Allegations that the NSA had persistent backdoor access through Juniper firewalls had already been published in 2013 by Der Spiegel.[59] The kleptographic backdoor is an example of NSA's NOBUS policy, of having security holes that only they can exploit."


From my understanding, the command payload is not an RSA private key. It is an SSH certificate's public key field, a section of which contains the signed command to be executed.


If it is known to belong to a widely deployed backdoor that can't be patched away in time, then it is worth to recover the key by brute force using supercomputers. Of course, such capabilities are rather restricted to nation states.


That sort of assumes that the backdoor in question is free of all bugs (for example, buffer overflows).




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: