Onderwerp: SSHD Rootkit in omloop

Voor de genen die het nog niet meegekregen hadden, er is er al enige tijd een draadje op wht.com over.

http://www.webhostingtalk.com/showthread.php?t=1235797
http://forums.cpanel.net/f185/sshd-rootkit-323962.html

Action required:
------------------------------

1. SSH to server
2. Run 'updatedb'
3. Run 'locate libkeyutils.so.1.9
4) Delete the file if exists.
5) reinstall the keyutils-libs(do: yum reinstall keyutils-libs)

Wat ik zoal begrepen heb:
- Er wordt spam verstuurd met geïnfecteerde servers
- root pass wordt verstuurd via poort 53
- CentOS/CL/ (RHEL?) vatbaar
- control panel onafhankelijk (cPanel/DA/ISPconfig etc)
- Deze 0day wordt als mogelijke oorzaak gezien, connectie nog niet bewezen

https://bugzilla.redhat.com/show_bug.cgi?id=911937
Door RedHat is bevestigd dat dit probleem ook voorkomt op servers met RHEL 5 en 6.

Statement:

This issue did affect the versions of the kernel package as shipped with Red Hat Enterprise Linux 5, 6 and Red Hat Enterprise MRG 2. Future updates may address this issue.

Iemand van jullie die al is gestuit op deze rootkit?

Hier iemand die een script heeft gemaakt om de file (/lib/libkeyutils.so.1.9) te verwijderen.
Het loont de moeite om even de hele thread te lezen.

Linkje: http://www.webhostingtalk.com/showth...21#post8561821

Die link was ik vergeten te posten. Thanks Daniel!

http://pastebin.com/WgXrebLq
http://www.tamonten.com/how-not-to-exploit-a-box

Zeer ernstig, maar ik zie dat de exploit gelukkig alleen werkt als de SSH poort ook daadwerkelijk openstaat. Een goede webhost heeft deze natuurlijk netjes afgeschermd.

CVE 2013-0871 heeft niets te maken met SSH-toegang helaas, als je processen kunt draaien dan kun je de exploit uitvoeren. Machines met ongepatchte kernels zijn (theoretisch althans) kwetsbaar. De exploit lijkt me nogal lastig (exacte timing is vereist) maar het is zeker niet zo dat je veilig bent als je SSH maar firewallt.

Er zijn overigens ook webhosters die hun klanten SSH-toegang geven om hun site beheren. SSH dichtzetten voor root en/of op machines waar publieke toegang niet nodig is firewallen is natuurlijk wel handig.

CSF 5.76 (changelog)

Geeft nu een signaal af indien je "de zak" bent:

Added new LF_EXPLOIT check SSHDSPAM to check for the existence of /lib64/libkeyutils.so.1.9 or /lib/libkeyutils.so.1.9, See: http://www.webhostingtalk.com/showthread.php?t=1235797

Als ik het goed begrijp ben je dus "nog" niet gepakt indien je geen signaal krijgt van CSF, maar ben je nog wel vulnerable.

Oorspronkelijk geplaatst door NederHost

Er zijn overigens ook webhosters die hun klanten SSH-toegang geven om hun site beheren. SSH dichtzetten voor root en/of op machines waar publieke toegang niet nodig is firewallen is natuurlijk wel handig.

Ik schrik me altijd te pletter als ik machines zie waar PermitRootLogin op aan staat, vooral gezien de grote hoeveelheid scans alleen op root.

Oorspronkelijk geplaatst door vDong

Ik schrik me altijd te pletter als ik machines zie waar PermitRootLogin op aan staat, vooral gezien de grote hoeveelheid scans alleen op root.

Ik zet het standaard ook uit, maar in principe maakt dat niks uit. Met een non-priviliged account is het ook maar een kwestie van tijd voor je een root shell hebt.
Het beste wat je kunt doen is lange random passwords gebruiken of keys, niet op default poorten draaien, firewallen indien mogelijk en erg snel blokken bij foute loginpoginingen.
De meeste hackers/scripts hebben namelijk helemaal geen root login nodig om shit te veroorzaken. Kijk maar eens wat je kunt doen met een eenvoudig non-priviliged ftp login van bv. nu.nl

Oorspronkelijk geplaatst door systemdeveloper

Ik zet het standaard ook uit, maar in principe maakt dat niks uit. Met een non-priviliged account is het ook maar een kwestie van tijd voor je een root shell hebt.
Het beste wat je kunt doen is lange random passwords gebruiken of keys, niet op default poorten draaien, firewallen indien mogelijk en erg snel blokken bij foute loginpoginingen.

Een niet random poort geeft naar mijn idee nauwelijks meer security dan een geen root toestaan. Het lijkt mij makkelijker om een andere poort te detecteren dan een andere user. Ik bedoel uiteraard niet root uit en iedereen als "admin" of "beheer" inloggen

Met SSH over een andere poort dan de standaard hou je in ieder geval de meldingen tot een minimum van alle scriptkiddies die Brute force proberen in te loggen, maar dat is een andere discussie lijkt me.

Oorspronkelijk geplaatst door vDong

Een niet random poort geeft naar mijn idee nauwelijks meer security dan een geen root toestaan. Het lijkt mij makkelijker om een andere poort te detecteren dan een andere user. Ik bedoel uiteraard niet root uit en iedereen als "admin" of "beheer" inloggen

In een wereld zonder firewalls of ids geeft een andere poort helemaal geen security, maar in combinatie met blocken na een portscan op enkele poorten spaart het toch weer wat ellende. Als je daarnaast ook nog blocked bij enkele foute login pogingen is het nog beter.
Beveiliging is niet alleen je zooi dichttimmeren, het is meestal een zaak van attackers frustreren zodat ze je met rust laten.
Net zoals je zooi totaal up2date houden je totaal niet beveiligt tegen 0-days, is het wel een goede manier om je te beschermen tegen oude exploits.
Het blijft een combinatie van veel dingen om een attacker de pis lauw te maken.

Is er al een fix of lees ik daar nu overheen?

Oorspronkelijk geplaatst door dennis0162

Is er al een fix of lees ik daar nu overheen?

Nee, het is zelfs niet bekend waar het probleem zit. Hier nog geen problemen gehad, maar met de hoeveelheid CentOS nodes is dat een kwestie van tijd vermoed ik. Schijnt ook met SSH dicht gehacked te kunnen worden, dus het probleem zal in een van de veel gebruikte packages zitten.