Bekijk Volledige Versie : 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 (http://seclists.org/oss-sec/2013/q1/326) wordt als mogelijke oorzaak gezien, connectie nog niet bewezen
dreamhost_nl
17/02/13, 19:04
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.
Yourwebhoster
18/02/13, 13:55
Linkje: http://www.webhostingtalk.com/showthread.php?p=8561821#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 (http://configserver.com/free/csf/changelog.txt))
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.
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.
systemdeveloper
18/02/13, 19:46
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 ;)
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
dreamhost_nl
19/02/13, 10:31
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.
systemdeveloper
19/02/13, 11:13
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.
dennis0162
19/02/13, 14:51
Is er al een fix of lees ik daar nu overheen?
rensariens
19/02/13, 14:57
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.
Is er al een fix of lees ik daar nu overheen?
Dat vraag ik me ook af!
EDIT: Rens heeft het antwoordt al gegeven ;)
rensariens
19/02/13, 15:06
Dat vraag ik me ook af!
EDIT: Rens heeft het antwoordt al gegeven ;)
Zie ook: http://webwereld.nl/nieuws/113443/linux-servers-geroot-en-geplunderd-via-0-day.html
dennis0162
19/02/13, 15:10
Als ik het zo lees bestaat libkeyutils.so.1.9 standaard niet.
Wellicht als tijdelijke dirty fix is libkeyutils.so.1.9 zelf aanmaken en deze locken met chattr?
Daar zal een automatisch script niet mee overweg kunnen en dan voorkom je iig tijdelijk dat deze niet aangemaakt wordt?
upgraden naar Debian? :eek: :surrender: :innocent:
rensariens
19/02/13, 15:45
upgraden naar Debian? :eek: :surrender: :innocent:
Denk dat je daar bij CentOS fans niet mee hoeft aan te komen. Onder linux toch wel de meeste problemen gehad met Debian hier, al komt dat natuurlijk ook doordat ik er minder bekend mee ben dan CentOS. Al zou dit dan ook moeten gelden voor BSD varianten en daar heb ik eigenlijk nooit problemen mee. Ik vind Debian iig helemaal niks en zeker geen "upgrade" :)
Ik ben Debian fan, maar moet bekennen dat ook Debian vulnerable zou zijn: https://security-tracker.debian.org/tracker/CVE-2013-0871 ;)
(onze dienst verder overigens niet extern voor zover we dat hebben kunnen uitzoeken met de beschikbare informatie)
De fix voor CVE-2013-0871 is het upgraden van je kernel naar 3.7.5. Waarmee niet is gezegd dat die kwetsbaarheid iets te maken heeft met die libkeyutils.so.1.9-rootkit. Overigens heeft het natuurlijk niet zo gek veel zin om deze specifieke rootkit proberen te zoeken of blokkeren: als je machine geroot is dan kunnen ze ermee doen wat ze willen en moet je 'm gewoon herinstalleren.
Men zit op wht.com aardig te bakkeleien over van alles en nog wat en komt vrij weinig uit. Totdat duidelijk is waar nu het lek zit lijkt me herinstallatie met de zelfde setup niet veel zin hebben. Dan zou je inderdaad beter naar Debian over kunnen ;)
Gezien Debian ook vatbaar is voor het ptrace lek en naar het schijnt lastig te exploiten lijkt dit 0day lek er inderdaad totaal los van te staan.
Je stapt dus over naar freebsd... so far so good and off topic =)
Wat ik me afvraag en nergens kan terug vinden. Hadden de gehackte servers SELINUX actief?
Wat ik me afvraag en nergens kan terug vinden. Hadden de gehackte servers SELINUX actief?
Nu even een dom antwoord, maar welke invloed denk je dat SELINUX op een root user heeft.
Wat ik me afvraag en nergens kan terug vinden. Hadden de gehackte servers SELINUX actief?
In de snoopy log die door een van de thread contributors word getoond gebruikt de hacker het commando "restorecon" .. ofwel ik denk niet dat SELINUX je zoveel zal helpen. Toegegeven dit is op een reeds gehackte machine.
Na die 52 pagina's van WHT.com gelezen te hebben lijkt mij persoonlijk het meest waarschijnlijke scenario dat de management machines van de administrators gehacked zijn.
Gewoon door een 0day op java/flash/pdf en dat een simpele keylogger de hackers toegang heeft gegeven tot ssh op de bewuste servers met password logins.
Maar het is lastig analyseren met alle aanwezige misinformatie van self proclaimed professionals in de thread op WHT.com.
Nu even een dom antwoord, maar welke invloed denk je dat SELINUX op een root user heeft.
SELinux _kan_ inderdaad zodanig ingesteld zijn dat ook een user/proces met uid 0 dingen niet kan.
Zo'n systeem is wel erg vervelend om te beheren, en het is ongebruikelijk. Redhat/CentOS geven een root user op de console wel de 'gewone' root rechten als selinux aan staat, maar goed, in principe biedt selinux de mogelijkheid om ook een root user dingen te verbieden.
upgraden naar Debian?
Ook geen optie meer zojn ook gehackt
Yourwebhoster
21/02/13, 08:03
De thread is nogal lang te noemen op wht.com maar in het kort is de conclusie dat de PC's waarmee is verbonden naar de geïnfecteerde servers zelf waren geïnfecteerd (vermoedelijk via de java/flash exploits). Door na inloggen de libkeyutils aan te passen kan de aanvaller ook met wachtwoord inloggen (ook als deze in de config is uitgeschakeld).
Debian is ook als geïnfecteerd gerapporteerd maar of dit echt zo is...
<ramnet> nenolod, how did you find that windows rootkit earlier? where was it's payload located?
<nenolod> ramnet, i just ran malware bytes anti malware, and it was a file in C:\Windows\System32 running as LOCAL_SERVICE permissions
http://www.webhostingtalk.com/showpost.php?p=8567905&postcount=1000
De thread zit vol onzin en het is mij nog steeds niet duidelijk of het Windows only is (de PC kant infectie dan). In de thread is ook uitleg aanwezig hoe je de rootkit kan verwijderen maar de eigenlijke aanrader is om je server opnieuw te installeren (wie weet wat nog meer op de server is geplaatst).
Enjoy als je nog leesvoer zoekt: de thread (http://www.webhostingtalk.com/showthread.php?t=1235797)
Ik sluit me volledig aan bij Yourwebhoster. Dit is de meest logische verklaring, en zien we al jaren. Lijkt eerder een uitbreiding op het al bekende virus wat FTP / SMTP auth gegevens e.d. opvist. Lijkt erop dat er ook stukjes netwerk verkeer worden gelogd (wel mooi geschreven natuurlijk :sweatdrop:) en daardoor ook direct met juiste poort wordt ingelogd.
Goede reden om de klant zonder VPN geen toegang meer te geven tot SSH.
Redhat heeft wel een update uitgebracht :
http://secunia.com/advisories/52312/
Red Hat has issued an update for openssh. This fixes a vulnerability, which can be exploited by malicious, local users to gain escalated privileges.
The vulnerability is caused due to the application calling the glibc "error()" function instead of the pam_ssh_agent_auth "error()" function and can be exploited to e.g. execute arbitrary code with root privileges.
De laatste update van csf:
5.79 - Modified csf error routine to store failing error in csf.error and
display an instructional message
Check for libkeyutils-1.2.so.2 in LF_EXPLOIT option SSHDSPAM
Modified the Server Report proxysubdomains check on cPanel servers
Added new options CC_DENY_PORTS, CC_DENY_PORTS_TCP,
CC_DENY_PORTS_UDP. This feature denies access from the countries
listed in CC_DENY_PORTS to listed TCP/UDP ports. For example, using
this FTP access port 21 could be blocked to only the specified
countries
Interessant. http://www.webhostingtalk.com/showpost.php?p=8568975&postcount=1117
After really some helpful data from flopunctro I was able to gather some info that added up to what I have already here is what I got so far :
1-we are facing an advanced version of this exploit/patch :
Where the username/password is send hashes via UDP port 53 instantly (ONLY in case of password login not via pub/priv key)
UDP Packets sent look like this :
7741e5e70c67b9c0737dd0a1467fbec5557afbfc48.XX.XX.X X.XX.XX: type A, class IN
6214f8fc6a5ab0a13727c3a05658d9c9376ddba7537edee26a XX.XX.XX.XX.XX: type A, class IN
Where XX.XX.XX.XX.XX is the connecting IP
* That was root login btw if it may help anyone decoding the hash
2- This were inserted in openssh package includes.h
EXTLIB_KEY Kw4DC88AXa0yScbrMZsbb5WPa2M7Gptp
EXTLIB_FILE_NAME /tmp/.socks
SERVER 205.134.160.54 (Thats an Older version IP that was used)
super_password XXXxCfWmZyl
super_password_pr_mask XXXxCfWmZylXcat
super_password_ver_mask XXXxCfWmZylXver
LCH_SUBSTR_1 *different*
LCH_SUBSTR_2 *fingerprint*
LCH_SUBSTR_3 *connecting*
LCH_SUBSTR_4 *authenticity*
LCH_SUBSTR_5 *Please type*
LCH_SUBSTR_6 abcdefghijklmnopqrstuvwxyz
LCH_SUBSTR_7 biz
LCH_SUBSTR_8 info
LCH_SUBSTR_9 net
LCH_SUBSTR_10 Version 0.4.4-5.5p1
LIB_LENGTH Guess_Length_Of_LCH_SUBSTR_10
which matches the strings pattern that was captured on they files found though they are not added in plain text rather obfuscated using xor like this :
#define EXTLIB_KEY {75,119,52,68,67,56,56,65,88,97,48,121,83,99,98,11 4,77,90,115,98,98,53,87,80,97,50,77,55,71,112,116, 112,0}
#define EXTLIB_FILE_NAME {100,3,89,52,108,22,75,46,59,10,67,0}
#define SERVER {121,71,1,106,114,11,12,111,105,87,0,87,102,87,0}
#define super_password {19,47,108,60,0,94,111,44,2,24,92,0}
#define super_password_pr_mask {19,47,108,60,0,94,111,44,2,24,92,33,48,2,22,0}
#define super_password_ver_mask {19,47,108,60,0,94,111,44,2,24,92,33,37,6,16,0}
#define LCH_SUBSTR_1 {97,19,93,34,37,93,74,36,54,21,26,0}
#define LCH_SUBSTR_2 {97,17,93,42,36,93,74,49,42,8,94,13,121,0}
#define LCH_SUBSTR_3 {97,20,91,42,45,93,91,53,49,15,87,83,0}
#define LCH_SUBSTR_4 {97,22,65,48,43,93,86,53,49,2,89,13,42,73,0}
#define LCH_SUBSTR_5 {97,39,88,33,34,75,93,97,44,24,64,28,121,0}
#define LCH_SUBSTR_6 {42,21,87,32,38,94,95,41,49,11,91,21,62,13,13,2,60 ,40,0,22,23,67,32,40,24,72,0}
#define LCH_SUBSTR_7 {41,30,78,0}
#define LCH_SUBSTR_8 {34,25,82,43,0}
#define LCH_SUBSTR_9 {37,18,64,0}
#define LCH_SUBSTR_10 {29,18,70,55,42,87,86,97,104,79,4,87,103,78,87,92, 120,42,66,0}
#define LIB_LENGTH {11,14,11,15,15,11,13,12,14,13,26,3,4,3,19,0}
here is the xor routine :
sub _xor{@Arr=split(//,$_[0]);@Key=split(//,$_[1]);$j=0; $keylen=scalar(@Key);for($i=0;$i<scalar(@Arr);$i++)
{$_[2][$i]=ord($Arr[$i])^ord($Key[$j]);$j++;$j=0 if($j>=$keylen);};};
3- This is not a privilege escalation exploit rather a "Maintaining access" exploit
4- Ips found associated with this so far if you want block/report them are :
205.134.160.54
124.224.178.154
15.229.164.97
178.162.248.74
188.165.129.30
218.94.149.83
250.159.28.33
46.105.108.166
46.105.20.166
5.199.133.226
72.156.139.154
78.47.139.110
86.35.214.22
87.230.54.65
94.23.23.153
94.23.72.193
5- the best route if you got this files reported is OS reload and force password changes afterwards as most if not all services login credentials are affected by this
6- it is suspected *till now* that super_password variable is used to spawn a reverse shell to attacker IP if he telnet to ssh port and pastes the super password though this has not been confirmed yet , hope somone can confirm/deny this .
* While in process of fixing you can prevent ongoing password leaks by prohibiting access to outgoing port 53 for only a predefined IP lets say google ns 8.8.8.8
Hope this helps anyone working on this .
Ik sluit me volledig aan bij Yourwebhoster. Dit is de meest logische verklaring, en zien we al jaren. Lijkt eerder een uitbreiding op het al bekende virus wat FTP / SMTP auth gegevens e.d. opvist. Lijkt erop dat er ook stukjes netwerk verkeer worden gelogd (wel mooi geschreven natuurlijk :sweatdrop:) en daardoor ook direct met juiste poort wordt ingelogd.
Goede reden om de klant zonder VPN geen toegang meer te geven tot SSH.
Tja dan kunnen ze net zo goed ook vpn gegevens opvangen in hun exploit en heb je hetzelfde probleem of gewoon de server via de client benaderen.
Yourwebhoster
22/02/13, 07:05
Tja dan kunnen ze net zo goed ook vpn gegevens opvangen in hun exploit en heb je hetzelfde probleem of gewoon de server via de client benaderen.
Dit script is gericht op de grootste doelgroep en slechts een beperkt aantal maken gebruik van VPN. Het zou dus zeker een extra beveiliging kunnen geven omdat externe servers proberen te connecten met je SSH van je servers (wat zonder VPN dus niet kan). Ook een jumphost zou in dit geval geïnfecteerd zijn maar vermoedelijk niet de servers waarmee verbonden zou worden vanaf de jumphost (tenzij dit een Windows machine is, ik ga er van uit dat het een Linux machine zal zijn).
Al met al het is geen echte beveiliging als iemand je specifiek wilt aanvallen maar tegen dit soort dingen ben je wel een stukje veiliger dan een normale setup.
Jammer dat ze op wht.com zoveel zitten te bashen.
Hier vind je een korte samenvatting van wat er op wht.com wordt besproken en een check voor je server
https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229
Parallels heeft zojuist een Security Advisory verzonden:
SECURITY ADVISORY FOR LINUX-BASED SSHD-ENABLED SYSTEMS
Parallels Customer,
Please read this message in its entirety and take the recommended actions.
Situation
External: Recent reports indicate a vulnerability for SSHD-enabled systems. This issue is not related to Parallels products as all SSHD-enabled systems are at risk.
In de mail wordt gewezen op een KB artikel: http://kb.parallels.com/en/115589
Dit script is gericht op de grootste doelgroep en slechts een beperkt aantal maken gebruik van VPN. Het zou dus zeker een extra beveiliging kunnen geven omdat externe servers proberen te connecten met je SSH van je servers (wat zonder VPN dus niet kan). Ook een jumphost zou in dit geval geïnfecteerd zijn maar vermoedelijk niet de servers waarmee verbonden zou worden vanaf de jumphost (tenzij dit een Windows machine is, ik ga er van uit dat het een Linux machine zal zijn).
Al met al het is geen echte beveiliging als iemand je specifiek wilt aanvallen maar tegen dit soort dingen ben je wel een stukje veiliger dan een normale setup.
Jammer dat ze op wht.com zoveel zitten te bashen.
Tja en als iedereen een vpn begint te gebruiken passen ze hun exploits gewoon aan of open ze gewoon een reverse shell op de geinfecteerde client. Dat het in dit geval kan helpen is een feit, maar dan moet je je ook afvragen waarom het in de eerst plaats zo ver is kunnen komen.
systemdeveloper
23/02/13, 01:35
No offense, maar heeft ook maar 1 iemand van de beetje ervaren hosters hier met dit probleem te maken gehad?
lol, ik denk niet dat je vraag -op deze manier- uitnodigt tot veel bekentenissen. :)
Even serieus, ook al ben je een ervaren hoster, een werkstation kan natuurlijk nog steeds besmet raken. Er zijn een hoop manieren om de risicovlakken te verminderen door te beschermen in lagen, maar niemand is 100% perfect veilig.
Er waren ook rapporten op het forum waarbij de hacker ingelogd had via de IP van het kantoor waar het besmette werkstation stond (veel geluk dan met je VPN setup)
Een ontdekking zoals deze rootkit die geplaatst wordt nadat ssh inloggevens worden verzonden geeft een goed signaal af om nog een keer goed je verdediging te bekijken. Bescherming is niet een definitieve oplossing, maar iets dat regelmatig dient te worden geinspecteerd en verbeterd.
Het antwoord op je vraag, nee, niet besmet. :)
systemdeveloper
23/02/13, 03:25
Nou, ik bedoelde meer of iemand hier het überhaupt al is tegengekomen of het in de logs gezien heeft, of ie nu besmet is of niet. Hoeft niet eens aan de hoster te liggen tenslotte, maar kan ook een onvoorzichtige klant zijn op een dedi/colo bakkie of zo. Persoonlijk vind ik het allemaal een beetje veel poeha aangezien rootkits met vrijwel elke remote/local root exploit geinstalleerd kunnen worden.
'even' een libje vervangen is dan al zo oud als de weg naar Rome.
In het kader van de vele distributed brute force attacks die wij de laatste tijd zien, lijkt me dit vooralsnog meer een standaard security issue dan iets echt nieuws.
Dat servers die bv. even cpanel/da installeren en er verder een jaar niet meer naar omkijken op zo'n manier het haasje zijn kan ik me dan wel voorstellen.
Was alleen een beetje benieuwd of het ook voorkomt op servers bij mensen die de boel redelijk op orde hebben. (je weet wel, beetje de servers beveiligd, firewalletjes, ids, niet op de werkpc kloten met java, legale software gebruiken etc.)
Gisteren de scan gemaakt en gelukkig niets tegen gekomen.
Persoonlijk vind ik het allemaal een beetje veel poeha aangezien rootkits met vrijwel elke remote/local root exploit geinstalleerd kunnen worden.
'even' een libje vervangen is dan al zo oud als de weg naar Rome.
Als het een makelijke was dan was het draadje niet zolang op WHT.com
systemdeveloper
24/02/13, 12:50
Gisteren de scan gemaakt en gelukkig niets tegen gekomen.
Als het een makelijke was dan was het draadje niet zolang op WHT.com
Mja, zolang mensen niet weten wat de attack vector is kunnen draadjes erg lang worden natuurlijk. Als blijkt dat het puur komt door een root password te sniffen vanaf beheer pc's, dan is het zelfs niet meer echt een exploit te noemen, hooguit een doordacht opgezet libje, toch?