Linux/SSHDoor.A, SSH server kradoucí hesla

ESET zveřejnil analýzu zákeřného SSH serveru Linux/SSHDoor.A. Ten ve spolupráci se škodlivým modulem pro webový server Apache Linux/Chapro.A posílal uživatelská jména a hesla na Island na servery openssh.info a linuxrepository.org (82.221.99.69). Server obsahoval také zadní vrátka (backdoor). Útočník se mohl přihlásit napevno nastaveným heslem nebo SSH klíčem (Slashdot).

26.1.2013 17:32 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[maddoxik]

N+jak mi chybí informace jak se na ten konkrétní server dostal backdoor + apache modul. Nebo využili honeypot s nějakou "naschvál" nastrčenou chybkou a schválně to nerozmazávají?

[nikola3]

Osobně si myslím, že zrovna tenhle zákeřný server mnoho škody nenadělal. Prostě úsměvná záležitost.

[Petr Ježek]

Eset? Aha :)))

[drizzt]

A co tak si to rozkliknut dalej?

http://blog.eset.com/2013/01/24/linux-sshdoor-a-backdoored-ssh-daemon-that-steals-passwords

http://blog.sucuri.net/2013/01/server-side-iframe-injections-via-apache-modules-and-sshd-backdoor.html

[maddoxik]

Nějak se na server ten apache modul a SSH backdoor dostat musel, ne? Přeci se tam nezjevil jen tak. To se někde píše?

[pepe_]

Konspirace : "A Eset to zjistil jak ? Není náhodou součást jeho produktu backdoor pro instalaci backdoorů a vyvolání nejistoty ? "

[Ladislav Hagara]

Předpokládám, že ESET získal binární soubor od Sucuri, pravděpodobně přes VirusTotal. Dle Sucuri se tento SSH server nacházel na několika nabouraných počítačích. Podrobnější informace zatím nejsou.

[VM]

Jak to může krást hesla, když ta SSH protokol vůbec neposílá?

[martin-ux]

ta spravicka je napisana tak,ze vlastne nevieme nic.

ale sshd "vidi" heslo, teda vlastny daemon moze posielat hesla mimo.

[VM]

Jaktože SSHD vidí heslo? Protokol je navržen tak, aby démon heslo vůbec nedostal. Stejně tak nedostane soukromou část klíče.

[SPM]

Autentizace klíčem a heslem funguje dost jinak. V případě klíče doopravdy soukromou část do ruky nedostane. Nicméně to heslo nějak vidět musí - zvlášť pokud server u sebe ho má zahashované a tedy nečitelné. Jinak to moc udělat nejde. To heslo nicméně putuje zašifrovaným kanálem, takže odposlechnout po síti se nedá.

[smazáno]

Slo by to poresit tak, ze by sshd rekl klientovy jakou hash funkci heslo zasifrovat pred poslanim a plaintext heslo pouzit jako fallback.

[azurIt]

Potom by ale heslom bol dany hash a nie povodne heslo :) takze si tam, kde si bol.

[Petr Tomasek]

Ne, pokud by se to radne osolilo

[SPM]

To ti nepomůže. Ty na straně daemona máš hash hesla a samotný heslo neznáš. Pokud se někdo autentizuje, tak to potřebuješ porovnat. Takže ti protistrana pošle buď heslo nebo zahashovaný heslo po tom, co jí pošleš jak to přesně má zahashovat. Ve chvíli kdy do toho namotáš jinou sůl, tak ti vyjde zase jinej hash a nemáš co porovnat.

[VM]

Jo, je to pravda, SSH server dostává plaintext heslo, byť v šifrovaném kanále, takže ho může zneužívat jak chce: http://tools.ietf.org/html/rfc4252#section-8

O důvod víc používat zásadně klíče.

[martin-ux]

Tak ako ti v podstate odpovedal @SPM. Heslo ide sifrovanym kanalom, tot vsjo. Ty ako klient predsa nevies v akej forme (cim) su kryptovane hesla na strane servera (a kam sa ma authorizovat). A to nevie ani SSH daemon na serveri.

Ostatne over si sam:

server:

# psg sshd
 1134 ?        Ss     0:00 /usr/sbin/sshd
#

client:

$ ssh foo@192.168.253.1

# strace -fp 1134
...
...
[pid  1237] read(4,  <unfinished ...>
[pid  1236] <... read resumed> "\0\0\0\10", 4) = 4
[pid  1236] read(6, "\v\0\0\0\3bar", 8) = 8
[pid  1236] getuid()                    = 0
[pid  1236] open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 4
[pid  1236] lseek(4, 0, SEEK_CUR)       = 0
...

guess my password :)

[azurIt]

ziadne heslo sa neposiela iba v pripade overenia klucom

[pekac]

Bulvár Hagara opět zasahuje...

[Jendа]

Co je na tom bulvárního?

[pekac]

Hagara.