'Aanvallers kraakten 25.000 servers en Kernel.org om spam te versturen'

Onderzoekers van beveiligingsbedrijf ESET hebben een malware-aanval ontdekt waarbij zeker 25.000 servers zijn gecompromitteerd. Op dit moment staan er nog zeker 10.000 onder controle van de aanvallers. Ook 65 Nederlandse servers zijn getroffen, evenals Kernel.org.

De getroffen systemen worden elke dag gebruikt om 35 miljoen spamberichten te versturen, schrijven de onderzoekers van ESET in hun onderzoek, dat ze samen met een Zweedse onderzoeksinstelling hebben verricht. De getroffen servers draaiden OpenBSD, FreeBSD, Linux en Windows met Cygwin, dat wordt gebruikt om Linux-software op Windows te kunnen draaien. Volgens ESET zijn delen van de aanval, die op zijn vroegst in 2011 begon, al eerder aan het licht gekomen, maar is de omvang ervan nu pas duidelijk. Opvallend is dat de 25.000 servers volgens ESET handmatig zijn geïnfecteerd.

De servers met een webserver werden bovendien van exploitkits voorzien om bezoekers te infecteren met malware, die vervolgens werden gebruikt om documenten te stelen. Dat gebeurde door een http-backdoor, die zowel met Apache, nginx als lighttpd werkt. Daarbij werden alleen Windows-gebruikers aangevallen: bezoekers met OS X kregen advertenties voor datingsites te zien, terwijl iOS-users werden geforward naar pornosites. Via de gekraakte webservers, op dit moment 700, worden dagelijks een half miljoen internetters bereikt, schatten de onderzoekers. Naar schatting één procent van de infectiepogingen was succesvol.

Bij de aanval, die door de onderzoekers Operatie Windigo is genoemd, werden ook 65 Nederlandse servers gehackt. Verder zijn servers van bekende bedrijven en organisaties getroffen. Daaronder valt Kernel.org, een website die wordt gebruikt voor de ontwikkeling van de Linux-kernel. Die aanval kwam in september 2011 al aan het licht; ESET zegt over betrouwbare bronnen te beschikken die bevestigen dat die aanval onderdeel uitmaakte van 'operatie Windigo'. Ook cPanel, software die wordt gebruikt door webhosters, werd getroffen door de aanval.

De aanvallers maken gebruik van een ssh-rootkit, die de aanvallers via een backdoor toegang geeft tot het systeem. Die rootkit maakt geen gebruik van kwetsbaarheden in het besturingssysteem of de openssh-library; de beheerders kregen toegang door het stelen of raden van wachtwoorden. De onderzoekers hebben een paar duizend misbruikte wachtwoorden kunnen onderscheppen; de wachtwoorden varieerden van 3 tot 50 tekens, gemiddeld waren dat er 11,1. Het overgrote deel van de wachtwoorden bevatte enkel cijfers.

Volgens de onderzoekers zijn er aanwijzingen dat er sprake is van één grote aanval, en niet meerdere aanvallen. Zo bevatte een dns-bestand dat de aanvallers op een geïnfecteerde server aantroffen de adressen van 70.000 verschillende domeinnamen die werden gebruikt bij het verzenden van de mail. Bovendien bevatten de gebruikte backdoors overeenkomsten in code.

ESET adviseert beheerders van servers om te controleren of hun systeem ook getroffen is. De onderzoekers hebben een simpel shellscript opgesteld dat kan worden gebruikt om een systeem te controleren op een infectie. Het bedrijf adviseert systeembeheerders van wie servers zijn besmet, om die te wissen en volledig opnieuw te installeren, met nieuwe wachtwoorden of privésleutels. "We realiseren ons dat het wissen van je server en opnieuw beginnen vervelend is, maar als aanvallers toegang hebben gehad tot je systeem, kun je geen risico's nemen", zo zegt onderzoeker Marc-Étienne Léveillé in een verklaring.

Bovendien stellen de onderzoekers dat beheerders geen wachtwoorden zouden moeten gebruiken om zich met een server te authenticeren. In plaats daarvan zouden ze privésleutels kunnen gebruiken om zichzelf aan te melden. "Aanmelden via wachtwoorden op servers zou iets uit het verleden moeten zijn", besluiten ze.

$ ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"

De snippet die sysadmins kunnen gebruiken om te controleren of hun systeem is getroffen.

Reacties (61)

Echt hoe kan het dat er zoveel servers gehacked worden. Slechte beheerders die root/admin login niet uitzetten? Of mallware op de clients?

Het eerste wat ik op een server altijd doe (nadat ik voor mezelf een sudo account heb gemaakt) :
nano /etc/ssh/sshd_config => permit root login no

Volgens de "Key findings" gaat het om gestolen credentials (client malware, inloggen vanaf een al gehackte server). Die credentials kunnen dan gewoon met sudo worden gebruikt.

Alleen al het feit dat SSH van buiten af benaderbaar is al een slecht iets, als je dan toch zo gemakzuchtig wilt doen installeer en configureer voor dat half uurtje extra werk gewoon een openvpn service en laat alleen ssh toegang vanaf een tunnel toe. Dat verkleind dan al weer het risico dat er iemand inbreekt op je systeem.

Zo te zien werden alleen Windows systemen geinfecteerd met malware, laat eigenlijk al zien des te meer de reden om nooit geen Windows in een beheer omgeving te gebruiken. In sommige gevallen kan je er wellicht niet omheen maar een VM kan dan nog uitkomst bieden gewoon puur en alleen voor beheer gebruiken en dan minimaliseer je het risico.

[Reactie gewijzigd door Bjornmeijer935 op 18 maart 2014 20:57]

Volgens mij lees je selectief, het waren de Windows / OSX bezoekers van de getroffen webservers die rommel voorgeschoteld krijgen.

Wat ik persoonlijk uit het artikel niet snap is dat er een SSH rootkit werd gebruikt maar ze de wachtwoorden hadden geraden.. waarom dan de rootkit? Of was die nodig voor het raden van de wachtwoorden?

Uit het artikel lees ik anders toch echt dit: "Daarbij werden alleen Windows-gebruikers aangevallen: bezoekers met OS X kregen advertenties voor datingsites te zien" of te wel enkel en alleen Windows gebruikers zijn hier vatbaar voor geweest. Ja als een Mac user zal je ook wel iets gezien hebben, wat ik me nog meer afvraag er wordt alleen Windows en Mac OSX genoemd maar niet Linux gebruikers..

Die rootkits waren om toegang te houden nadat ze binnen waren.

Volgens mij is SSH veilig genoeg als je gewoon goede wachtwoorden gebruikt. Het liefste sleutels uiteraard.

SSH is wel veilig, ik denk dat een key en wachtwoord combi de veiligste manier is als je alleen SSH gebruikt. Het probleem is dat veel mensen makkelijke wachtwoorden kiezen die in no time te raden zijn. Daarbij is alleen een key nog veel gevaarlijker, als die ooit ontfutseld word dan is het instant access naar je server.

Helaas is onze VPS van het bedrijf geinfecteerd, eigen server is schoon.
*Schuift planning van morgen weg en begint alvast backups te maken*

Even de bash commando uitgelegd:

ssh -G 2>&1 Probeer de -G argument op de 'ssh' binary, en herleid de 'error stream' naar de 'output stream'
| grep -e illegal -e unknown > /dev/null Geef de 'output stream' door aan 'grep' (als input stream), welk gaat zoeken naar 'illegal' of 'unknown' (zoekt of 'ssh' de commando niet vond). Stuur de 'output stream' door naar '/dev/null'
&& echo "System clean" || echo "System infected" Als de vorige commando als resultaat '1' terug gaf, zal het 'System clean' in de console printen, anders 'System infected'.


waarom typ ik dit eigenlijk, we zijn toch tweakers?

Omdat het - net als alle andere Linux commando's - nodeloos ingewikkeld is.
Je kunt namelijk ook alleen "ssh -G" invoeren en dan zelf de output lezen.
Als er dan staat "ssh: illegal option -- G" of woorden van gelijke strekking dan ben je clean.
En anders ben je geïnfecteerd.

En natuurlijk een waardeloze constructie, die hackers in kwestie gaan vanaf nu een versie van ssh gebruiken die de -G optie zogenaamd niet accepteert, maar 'm ondertussen wel uitvoert

Nou, zojuist maar eens even al mijn VPS systemen bekeken, gelukkig System clean

Waar ik nogal van onder de indruk ben is dat wachtwoorden tot 50 karakters 'geraden' zijn.
Of dat moet onder de categorie 'gestolen' vallen, want hoe ze dit anders hebben gedaan vraag ik me wel af.

Tevens begrijp ik het verschil tussen een wachtwoord en een privésleutel niet echt.

Een wachtwoord moet je telkens opgeven. Bij public-key authentication zet je eenmaal jouw publiekelijke sleutel in .ssh/authorized_hosts op de server en dan wordt die gebruikt om in te loggen.

Indien je niet veel user wissels hebt kan je zelfs wachtwoord login compleet blokkeren na het instellen van de sleutels.

En een ander voordeel is dat je een sleutel per machine kan maken. Wordt bijvoorbeeld je laptop gejat trek je de sleutel van je laptop in en klaar.

[Reactie gewijzigd door hackerhater op 18 maart 2014 18:02]

Bij een wachtwoord moet je de vertrouwensband tussen host en client nog aangaan. Bij een sleutel kan je al vanaf de eerste bit met versleuteling werken. Kwam onlangs nog ergens een bericht tegen (maar ben er toen niet verder op ingegaan) dat het relatief eenvoudig zou zijn om ssh wachtwoorden te onderscheppen met een man-in-the-middle.

SSH werkt AFAIK met een challange-respons systeem (gebaseerd op public-key cryptografie) en is dus is er geen replay of afvangen mogelijk. Anders zou zelfs HTTP-auth met digest nog veiliger zijn dan SSH

Anyway, het artikel raad dus het gebruik van wachtwoorden af, maar ik log nogal vaak met een 'vreemde' computer in, dus voor mij werkt dat niet. Voor anderen die zich hier zorgen om maken, port knocking is een fantastische optie hiervoor! Bijvoorbeeld dat je eerst een telnet moet doen naar de server over een 'geheim' poortnummer voordat de ssh-poort open gaat in de firewall, en dan nog enkel voor jouw IP. Het beperken van het aantal inlogpogingen tot 1 per 10 seconde per IP werkt ook fantastisch.

[Reactie gewijzigd door ktf op 18 maart 2014 15:40]

Die sleutels kun je gewoon meenemen hoor, gewoon op een usbstick aan je sleutelhanger naast je gewone sleutels. Op een vreemde computer heb je natuurlijk het risico dat die de sleutels buit maakt, maar als je een wachtwoord gebruikt loop je veel meer risico. Zowiezo moet je je sleutel met een wachtwoord beveiligen en geen ssh verbindingen maken vanaf een machine die je niet vertrouwt.

Afgezien daarvan. poort knocking is leuk en de rate van nieuwe ssh verbindingen limiteren is nuttig, maar als je je ssh server veiliger wilt maken, dan zou je (naar mijn mening) als eerste denyhosts moeten installeren. Die "merkt" dat iemand op je ssh service probeert in te breken en blacklist die dan voor een bepaalde tijd.

Relatief eenvoudig voor wie? Voor mensen die dit soort nieuws bereiken waarschijnlijk.
Het idee van SSH lijkt me nou juist veiligheid.

Mijn ssh versie kent geen optie -G...

Hoeveel tijd ben je kwijt om 25000 servers handmatig te infecteren? Weegt dat op tegen de verdienste, ervan uitgaande dat sysadmins sneller een systeem schoonmaken t.o.v. 'gewone' gebruikers?

-g Allows remote hosts to connect to local forwarded ports.

Dat is het niet, dat script checkt alleen of de -G optie bestaat en is daarbij case-sensitive. Die -g was er al: http://www.linuxmanpages.com/man1/ssh.1.php
Mijn ssh heeft -G niet, maar als ik hem zou hebben zou ik iig direct de authorisatie logs en die van ssh/sshd + de CLI-history eens bekijken.

Dat is het niet, dat script checkt alleen of de -G optie bestaat en is daarbij case-sensitive.

Dank! Kennelijk is een ssh met de optie -G (hoofdletter) een besmette versie.

Ah, dat kon ik niet helemaal uit het commando opmaken. Ik had alleen even snel een google search gedaan. Thanks

Het gaat hier om de hoofdletter G niet om de kleine letter g

Dank! Kennelijk is een ssh met de optie -G (hoofdletter) een besmette versie.

het idee van het "script" is juist dat als je ssh client een error geeft op de -G optie dat je een cleane client hebt, als hij de -G optie accepteerd gaat het om een (mogenlijk) geinfecteerde versie.

Waar haal jij vandaan dat sysAdmins sneller een systeem zouden schoonmaken?
't Stikt ondertussen van de server(tje)s die beheerd worden door iemand die net weet hoe je'm moet rebooten. Die kijkt wel uit met dat schoonmaken

De getroffen servers zijn handmatig geinfecteerd? Dus handmatig zijn er 2.500.000 servers aangevallen (met 1% succes)? Dat lijkt me amper mogelijk.

De 1 procent success rate lijkt te slaan op het infecteren van de gebruikers van de servers met malware.

Ik vind 25.000 servers handmatig infecteren al een prestatie van formaat. Ze waren vast niet met maar 10 man...

Tien man, dus 2500 servers pp, dat is 7 per dag in één jaar tijd. Spreid dat uit over meerdere jaren, en het valt te overzien.

"Geef me 100 chinezen en ik doe het in mn eentje."
Rings a bell ?

Toevallig vorige week nog een bot tegengekomen in de logs. Probeerde ook in te loggen op de SMTP server met allerlij standaard gebruikersnamen zoals admin, administrator, user, guest maar ook dingen als bob en george. Gelukkig worden die ip's automatisch gebant door de server

Toevallig vorige week nog een bot tegengekomen in de logs. Probeerde ook in te loggen op de SMTP server met allerlij standaard gebruikersnamen zoals admin, administrator, user, guest maar ook dingen als bob en george. Gelukkig worden die ip's automatisch gebant door de server

Dit gebeurt aan de lopende band?

Alleen vandaag en gisteren al:

Mar 17 04:54:21 localhost sshd[11011]: input_userauth_request: invalid user root [preauth]
Mar 17 04:54:24 localhost sshd[11015]: input_userauth_request: invalid user root [preauth]
Mar 17 06:47:13 localhost sshd[11717]: input_userauth_request: invalid user root [preauth]
Mar 17 06:47:14 localhost sshd[11721]: input_userauth_request: invalid user root [preauth]
Mar 17 06:47:15 localhost sshd[11725]: input_userauth_request: invalid user root [preauth]
Mar 17 06:47:16 localhost sshd[11729]: input_userauth_request: invalid user root [preauth]
Mar 17 06:47:17 localhost sshd[11733]: input_userauth_request: invalid user root [preauth]
Mar 17 06:47:18 localhost sshd[11737]: input_userauth_request: invalid user root [preauth]
Mar 17 07:48:20 localhost sshd[12129]: input_userauth_request: invalid user root [preauth]
Mar 17 11:17:58 localhost sshd[13473]: input_userauth_request: invalid user root [preauth]
Mar 17 11:18:01 localhost sshd[13480]: input_userauth_request: invalid user root [preauth]
Mar 17 11:18:03 localhost sshd[13484]: input_userauth_request: invalid user root [preauth]
Mar 17 11:18:06 localhost sshd[13488]: input_userauth_request: invalid user root [preauth]
Mar 17 11:18:09 localhost sshd[13492]: input_userauth_request: invalid user root [preauth]
Mar 17 15:48:40 localhost sshd[5625]: input_userauth_request: invalid user root [preauth]
Mar 17 15:48:44 localhost sshd[5821]: input_userauth_request: invalid user root [preauth]
Mar 17 15:48:45 localhost sshd[5660]: input_userauth_request: invalid user root [preauth]
Mar 17 15:48:55 localhost sshd[5943]: input_userauth_request: invalid user root [preauth]
Mar 17 15:49:00 localhost sshd[6071]: input_userauth_request: invalid user root [preauth]
Mar 17 16:22:35 localhost sshd[1363]: input_userauth_request: invalid user test [preauth]
Mar 17 16:22:37 localhost sshd[1369]: input_userauth_request: invalid user test [preauth]
Mar 17 16:22:38 localhost sshd[1373]: input_userauth_request: invalid user test [preauth]
Mar 17 16:22:40 localhost sshd[1377]: input_userauth_request: invalid user test [preauth]
Mar 17 16:22:42 localhost sshd[1382]: input_userauth_request: invalid user test [preauth]
Mar 17 18:12:36 localhost sshd[2224]: input_userauth_request: invalid user root [preauth]
Mar 18 00:41:30 localhost sshd[5039]: input_userauth_request: invalid user root [preauth]
Mar 18 03:23:47 localhost sshd[6227]: input_userauth_request: invalid user root [preauth]
Mar 18 03:23:49 localhost sshd[6233]: input_userauth_request: invalid user root [preauth]
Mar 18 03:23:53 localhost sshd[6237]: input_userauth_request: invalid user root [preauth]
Mar 18 03:23:54 localhost sshd[6241]: input_userauth_request: invalid user root [preauth]
Mar 18 03:24:00 localhost sshd[6246]: input_userauth_request: invalid user root [preauth]
Mar 18 09:16:46 localhost sshd[8640]: input_userauth_request: invalid user root [preauth]
Mar 18 09:17:13 localhost sshd[8646]: input_userauth_request: invalid user root [preauth]
Mar 18 14:25:41 localhost sshd[10741]: input_userauth_request: invalid user root [preauth]
Mar 18 14:25:42 localhost sshd[10745]: input_userauth_request: invalid user root [preauth]
Mar 18 14:25:43 localhost sshd[10749]: input_userauth_request: invalid user root [preauth]
Mar 18 14:25:44 localhost sshd[10753]: input_userauth_request: invalid user root [preauth]
Mar 18 14:25:45 localhost sshd[10758]: input_userauth_request: invalid user root [preauth]
Mar 18 14:25:46 localhost sshd[10762]: input_userauth_request: invalid user root [preauth]

In dit geval is root populair, echter zie ik vaak inderdaad standaard logins voorbij komen. Ach ja, dual factor HOTP token authenticatie en fail2ban.. Zeg nooit nooit maar zelfs zonder cert auth is het niet zo gemakkelijk lijkt me..

root login via SSH sowiezo uitzetten, zelfde geld voor ieder account wat een standaard naam gebruikt? Daarnaast doet fail2ban prima zijn werk, ook een token koop je voor niet al te veel geld. Is wel aan te raden als je je spulletjes enigsinds prive wilt houden. En de password complexiteit uiteraard.

O fijn :

unknown option -- G
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port]
[-Q cipher | cipher-auth | mac | kex | key]
[-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] [user@]hostname [command]

[Reactie gewijzigd door Pakjebakmeel op 18 maart 2014 16:18]

idd, fail2ban staat nu ook weer actief op die server. Daarnaast werken we alleen met whitelists, scheelt een hoop

Aanrader naast fail2ban, is een simpel stukje iptables:

#-----------------------------------------------------------------------------#
# Limit SSH connections to 3 per 10 minutes per host
#-----------------------------------------------------------------------------#
-A INPUT -m state --state NEW -p tcp --dport 22 -m recent --set
-A INPUT -m state --state NEW -p tcp --dport 22 -m recent --update --seconds 600 --hitcount 4 -j DROP

Zet dat stuk config voor de accept rule voor SSH:

#-----------------------------------------------------------------------------#
# Allow SSH
#-----------------------------------------------------------------------------#
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Het resultaat is dat je vanaf de hele wereld met SSH in kan loggen, maar dat bruteforce attacks na 3 pogingen naar /dev/null gaan. En ik kan toch vanaf een hotel/publiek netwerk even op mn server inloggen.

Waarom gebruik je poort 22? Dat is toch het eerste wat je moet veranderen als je geen last wilt hebben van randomtools die rondscannen en je server bezighouden. Ik zie trouwens ook genoeg bots die na een half uurtje terugkomen om het volgende exploit in hun lijstje uit te proberen.

Persoonlijk gebruik ik DenyHost, dat terzijde met dit stukje iptables
maak je het wel moeilijk voor fail2ban of denyhosts om iets te moeten doen.
Waarom het dan nog extra draaien ? Persoonlijk hou ik niet zo van rate limiting in netfilter.

Wat is er in jouw optiek mis met rate limiting in netfilter?

Ik gebruik persoonlijk geen fail2ban of denyhosts omdat ik deze oplossing flexibeler vind. Ik vind het niet noodzakelijk om direct een IP in hosts.deny te planten, vaak is 10minuutjes naar /dev/null meer dan genoeg, en ik moet nogal eens vanaf publieke netwerken naar mijn server connecten, en dan is het toch vrij jammer als fail2ban/denyhosts net besloten heeft dat dat IP niet meer mag connecten (been there).

Ik heb wel een eigen tool draaien die periodiek door de logs fietst en de repeated-offenders eruit filtert en mij de optie geeft om ze wel of niet in een blacklist te zetten. Op basis van o.a. whois informatie worden IP adressen in die 'optie lijst' gecorreleerd, en zo kan ik indien nodig een compleet IP block op de blacklist zetten als dat nodig is.

Het is niet voor iedereen de perfecte oplossing, maar voor mijn specifieke toepassing vond ik denyhosts en fail2ban simpelweg niet ideaal. Die zeldzame keer dat ik daadwerkelijk een SSH daemon ontsluit naar het internet, dan is dat doorgaans ook omdat ik er _altijd_ bij moet kunnen

Hoe kun je met de ssh client controleren of je ssh daemon kwetsbaar is?

Het script controleert of optie -G bestaat, hetgeen gebruikt werd voor deze "aanval".

Ja maar de client (ssh) en niet de daemon (sshd).

True, maar als je beheerders rechten hebt en jouw client is besmet kan je er donder op zeggen dat de server ook geinfecteerd is.

waarbij zeker 25.000 servers zijn gecompromitteerd. Op dit moment staan er nog zeker 10.000 onder controle van de aanvallers.

Via de gekraakte webservers, op dit moment 700

Ik ben de draad een beetje kwijt... Hoeveel servers gaat het nou om? Of is "onder controle van aanvallers" iets anders dan "gekraakt" en "gecompromitteerd"?

Wellicht verschil tussen de fysieke server en websites die gehost worden?

De servers met een webserver werden bovendien van exploitkits...

Dus 10.000 server zijn nog gecompromitteerd, waarvan 700 webservers.

[Reactie gewijzigd door curumir op 18 maart 2014 15:48]