Infecting SSH Public Keys with backdoors
Hallo zusammen, sofern nicht selber schon gesehen/-lesen hier [0] FYI "Infecting SSH Public Keys with backdoors VG Bernd [0] https://blog.thc.org/infecting-ssh-public-keys-with-backdoors -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler@itc.rwth-aachen.de https://www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ
Ohai, On 25.05.23 15:31, Bernd Kohler wrote:
"Infecting SSH Public Keys with backdoors mein tl;dc (too long, didn't click - oder auf /r/de auch neumodisch "habe euch den Klick erspart"): Die authorized_keys kann für einen Key auch einen beim connect auszuführenden Befehl definieren, wenn man ihn mit dem passenden Parameter vor den Key (command="") reinschreibt. Ist halt doof, wenn das dann eine zusätzliche backdoor enthält.
Ein Problem ist das aber auch nur, wenn man die Kontrolle über seine authorized_keys verloren hat - dann hat man aber so oder so verloren. Sinnvolle Nutzung dieser Möglichkeit ist z.B. ssh-restrict[0], was sich u.a. ganz gut macht, wenn man noch icinga(2) im Einsatz hat und auf remote hosts wohldefinierte check commands auch mit variablen Parametern laufen lassen möchte. Viele Grüße Markus [0] <https://github.com/mxey/ssh-restrict> - es gibt auch mindestens einen fork mit python3-Support. Nutzen diverse bekannte Webseiten™ im Hintergrund :)
participants (2)
-
Bernd Kohler
-
Markus Witt