ISC Diary: sshd rootkit szabadon

Titkosítás, biztonság, privát szféra

Az ISC Diary arról ír, hogy egy főként RPM-alapú Linux disztribúciókat érintő, feltehetően sshd rootkit bukkan fel egyre több rendszeren. Egyelőre még nincs pontos információjuk arról, hogy mi a kezdeti támadási vektor (találgatások már vannak), de amint bővebb információjuk lesz, a bejegyzés frissítését ígérik.

( wowbagger v | 2013. 02. 24., v – 09:30 )

sub.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.37 | 2.6.39.3-janos

( aga_et v | 2013. 02. 24., v – 10:33 )

Marhára örülök. Lehet, hogy ezen jött be hozzám az exploit, nem a régi envídia driver miatt?
Javam direkt nincs.
--
AGA@
Fork portal és az egyik logóm :)

Egyelőre nem tiszta minden körülmény, de nem úgy tűnik, hogy az sshd lenne sebezhető. Sokan local exploitra gyanakodnak. Az exploit ledob egy preparált lib-et, ami belemászik az sshd agyába, és beregisztrál a PAM-ba is, és így megszerzi az username/password párokat, és DNS kérések formájában elkódolva ki tudja küldeni a támadónak. A fertőzött gépeket spammelésre is használják.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.37 | 2.6.39.3-janos

http://en.wikipedia.org/wiki/OPIE_Authentication_System
Egyszerhasznalatos jelszavas authentikacio.

Mas kerdes, hogy mennyit er, ha az sshd-be beepulnek. Akkor siman telepitheto olyan backdoor, ami mindig beengedi a tamadot, fuggetlenul attol, hogy ismerik-e a tenyleges jelszot, vagy sem.

--
akkor most free tibet vagy delete tibet a jó?? - falu

Attól függ, hogy hova épül be az authentikációs folyamatba - az biztos, hogy ha a pam-os "ágat" viszi, és van jelszavas azonosítás, akkor gáz van - nem is kicsit (újrafelhasnzált jelszavak n+1 rendszerben, vagy egyszerűen egy közös ldap-ból authentikál n+1 rendszer), viszont a kulcsos auth (a pam-ból csak account és session használata) ekkor jó is lehet.

Nem ne felejtsük el - és azt is meg kell határozni, hogy milyen módon lop adatot, illetve engedi be a "gazdáját" a trójai. A jelszólopásnak keresztbe lehet tenni a ténylegesen otp megoldásokkal (az időkorlátos jelszó nem ilyen), a bedrótozott hozzáférésnek ezzel természetesen nem.

A milyen módon lop nagyjából megvan: telepít egy /lib/libkey-1.2.so vagy /lib64/libkey-1.2.so libet, amit be is tölt. Ez hookol egy rakat függvényt (PEM_write_RSAPrivateKey, PEM_write_DSAPrivateKey, MD5_Init, MD5_Update, and MD5_Final), majd az ezeken keresztül megkapott információkat DNS query formájában továbbküldi.

( johans | 2013. 02. 24., v – 12:37 )

A kommunikációhoz shared memóriát használ, ezért a leggyorsabb detektálási módszer:

for i in `ipcs -mp | grep -v cpid | awk {'print $3'} | uniq`; do ps aux | grep $i | grep -v grep;done

Ha ebben van olyan process, ami jellemzően nem használ shared memóriát (ssh, sshd) akkor fertőzött a gép.

OT
A detektalas tobb sebbol is verzik :-), es meg foloslegesen eroforraspazarlo.
a grep -v cpid szuper, de Linuxon van meg egy tartalommal biro fejlec sor (ahol ki is irja hogy mi a cpid/lpid) azaz en inkabb irnek helyette egy grep -vi -e cpid -e 'shared memory' -t. Az meg meg ennel is inkabb szorszalhasogatas, h ps auxw | grep $i |grep -v grep helyett akar ps up $i is eleg lenne ;-)

A detektalas amugy igen szellemes, es nyilvan en vagyok kelloen elmaradott, hogy fejbol ne tudjam, h amit kaptam kimenetnek a nemikeppen javitott verzioval, azok vajon megfelelnek-e az elvarasoknak. (ssh* nem volt koztuk :-) )

( sh4d0w808 | 2013. 02. 25., h – 09:09 )

sub

-------------------------
Trust is a weakness...