Akamai: slagkracht van 'BillGates'-botnet van Linux-machines neemt toe

Een botnet bestaande uit Linux-systemen die geïnfecteerd zijn met zogenoemde BillGates-malware is bezig met een opmars, claimt Akamai op basis van onderzoek. Het botnet zou ingezet worden voor ddos-aanvallen en aan kracht gewonnen hebben na eerdere acties tegen het XOR-botnet.

Akamai plakt in zijn beveiligingsadvies van het Security Intelligence Research Team het stempel 'hoog risicofactor' op het BillGates-botnet. Volgens Akamai werd de malware die ingezet wordt voor het botnet voor het eerst in 2014 ontdekt door een Russische it-site en bouwt de malware voort op de broncode van de Elknot-malware. De oorsprong zou in Azië liggen en het botnet richt met zijn ddos-aanvallen ook op het platleggen van met name Aziatische gamebedrijven, staat in het rapport.

De aanvallen vertonen gelijkenissen met die van het XOR-botnet, dat eerder onder Aziatische bedrijven huishield maar vorig jaar werd ontmanteld. De kans is aanwezig dat de beheerders van XOR met het BillGates-netwerk de draad weer opgepakt hebben, vermoedt Akamai.

De malware ontstaat bij een builder, waarmee kwaadwillenden eigen varianten van BillGates kunnen maken. De resulterende toolkit kan ddos-aanvallen uitvoeren, poorten openen en een heel systeem overnemen. Eind 2015 detecteerde het onderzoeksteam een aanval met een totale, gedistribueerde, bandbreeddte 308Gbit/s. De BillGates-malware infecteert Linux-systemen net als XOR niet direct via kwetsbaarheden maar door op internet naar minimaal beveiligde ssh-servers te zoeken en via bruteforce achter wachtwoorden te komen.

Zoals vaak bij beveiligingsonderzoeken kan de uitkomst niet los gezien worden van het commercieel belang van de onderzoekende partij, in dit geval levert Akamai diensten ter bescherming tegen ddos-aanvallen.

BillGates malware Linux

Door Olaf van Miltenburg

Nieuwscoördinator

07-04-2016 • 19:51

82

Reacties (82)

82
80
54
7
0
4
Wijzig sortering
Ik vraag me af waarom er dan nog zo veel brakke SSH servers open staan in het wild... Op z'n minst ratelimiting staat by default relatief laag wat dit soort brute force aanvallen al tegen gaat. Is er een of ander populair stuk software dat standaard een gemodificeerde brakke SSH configuratie aflevert ofzo?
Zet maar eens een Linux server op met ssh publiek op poort 22 (default poort) en kijk voor de lol eens de verbose logging na. De ene geautomatiseerde brute force poging na de andere vanuit Azië en Rusland. Ik raad altijd aan om ssh naar de buitenwereld af te blokken en via VPN te verbinden naar je netwerk en dan pas intern te SSH'en naar je server. Scheelt enorm veel nutteloze netwerk traffiek en CPU cycles.
Mijn VPN services worden anders net zo goed gebombardeerd met fake auth requests. Daarnaast is SSH-over-VPN eigenlijk totaal geen oplossing; het is niet alsof inbreken op SSH makkelijker is dan inbreken op VPN, in allebei de gevallen is het puur afhankelijk van je configuratie. Oh, en wat doe je als je VPN daemon op z'n gat gaat? Kan dan niet via SSH even een service restart doen ;-)

Zelf heb ik natuurlijk logging waarin ik met een query in kibana toch altijd wel de nodige SSH tests langs zie komen, maar om dat ik voor nagenoeg alle toegang vanuit Azie, Zuid-Amerika, Oost-Europa en Afrika toch nagenoeg nooit legitieme requests verwacht is by default elk IP van de RIR's die dat coveren standaard geblokkeerd. Zowel voor VPN als voor SSH. De rate limits hebben ook een stuk minder marge voor die landen, en als het even kan dump ik ook verkeer van meer dan 10Mbit van die regio. Nagenoeg geen enkele site of interface van de diensten die ik beheer krijgen meer dan 1 legitieme verbinding per maand van de landen daar.

Je kan het ook veel simpeler opzetten:

- SSH op non-standaard poort
- SSH key only auth
- SSH met alleen maar sterke ciphers
- netwerk-layer rate limiting (bijv. iptables of pf)

De enige reden dat je op SSH2 nog gehackt wordt is als je de default config van een gerenommeerde distro verneukt of een slecht wachtwoord gebruikt.

[Reactie gewijzigd door johnkeates op 22 juli 2024 22:47]

Ik maak altijd een Iptables rule dat de toegang tot port 22 alleen vanaf een specifiek Ip adress is toegestaan en vervolgens draait op dit specifieke ip een vpn waar ik op kan inloggen. werkt tot nog toe uitstekend.
Ik maak iptable rules aan voor een specifiek IP adres op de standaard poort en daarnaast geef ik alle overige IP adressen SSH toegang via een non-standard poort. Tot nu toe werkt dit prima. Ik heb nog nooit last gehad van aanvallen en ik kan altijd overal vandaan inloggen indien nodig.
Ik draai SSH altijd op poort 22, maar verder precies zoals jij aan geeft.

Password authentication moet gewoon uit! Dan vang je bijna alles af.

VPN vind ik zelf een drama, altijd een hel om te configgen. Vermijd het zo veel mogelijk.
Nee, daar ben ik serieus over. Een VPN maakt de boel vaak alleen maar complexer, maar niet direct veiliger.

Een OpenSSH server kan met de juiste instellingen, zoals passwords uit, gewoon aan het internet.

Doe ik nu al ruim 13 jaar, nog geen problemen mee gehad.
Dit doe ik ook al jaren, gewoon op poort 22.
Wel met GeoLocatie blocking (alleen NL mogelijk), een heel sterk wachtwoord en dan ook nog eens, twee keer fout inloggen binnen 10 minuten en het originating IP wordt voor 60 dagen geblokkeerd. Ik heb ongeveer een keer per maand een poging en trek daarna het IP na en als het bekend staat als spammer of hacker, gaat het IP in de permanente bloklist.

Heeft tot nu toe altijd nog gewerkt.
Zelfs "dropbear" (kleinere implementatie voor embedded systemen van SSH server) kun je ongebreideld aan het internet hangen. Is intrinsiek veilig, ook na een nieuwe flash (inloggen is pas mogelijk als het account een password heeft) voordat de configuratie wordt terug gezet.
Anoniem: 149075 @Snow_King8 april 2016 08:59
Voor OOB kan ik het me voorstellen maar voor de rest echt totaal niet.

Zorg gewoon dat je je skills update, dit is echt niet profi
Ik denk dat password uit betekend dat men gebruik maakt van public en private keys... dan heeft de post van Rinaldootje juist alle wind mee... en anders ben ik het overduidelijk met je eens dat security through obscurity écht niet kan met SSH.
Private key maakt het niet meer secure mijn inziens.

Een VPN is een tunnel, als die faalt kom je er gewoon niet op.

Ik heb ook een OOB open staan hoor op 22 maarja, daar zit nog wal meer security achter. Tis puur dat ik buiten een Firewall om ergens op een commandline kan komen.
Jij gaat van een lek in OpenSSH uit, maar bijv OpenVPN vertrouw je wel?

OpenSSH is een veilige en goede daemon wanneer je hem goed in zet.

Uiteraard met alles zorgen dat hij up to date is.
Anoniem: 149075 @Snow_King8 april 2016 10:53
Nee ik ga er vanuit dat je direct op een commandline zit welke wellicht access heeft to je gehele netwerk.

OpenVPN kan een lek hebben maar dat betekent niet dat je meteen vol op je netwerk zit, dit gezien je ACL's en andere subnets handteert op VPN.
Ik werd ook lijp van die brute force aanvallen uit China, UK, Oekraïne.
Oplossing is Fail2ban met permanente ban na 2 pogingen.
2 pogingen is zeer weing.

Naar mijzelf gekeken, 1 keer caps lock, 1 keer type fout.
En dan nog zoveel verschillende wachtwoorden dat ik me daar ook nog wel eens in vergis.

[Reactie gewijzigd door Emunator op 22 juli 2024 22:47]

Fail2ban inderdaad top. als je 2 te weinig vindt zet je 'm toch op 3 :)

Pakt ook brute-force mailaccount pogingen prima aan (die zou ik bij bestaan van externe klanten overigens zeker op 10+ pogingen per uur zetten).

F2B heeft veel services voorgedefinieerd, ontbrekende kun je F2b leren hoe de logs te interpreteren.

Als je F2B nog niet kent als Linux beheerder wordt het hoog tijd! :)
Als je F2B dan ook nog koppelt met www.blocklist.de dan zit je in een groot collectief van F2B gebruikers en deel je de data waardoor veel bots het niet eens 1 keer kunnen proberen. Daarnaast verstuurt blocklist.de ook nog abuse reports om zoveel mogelijk van die bots down te halen.
Een andere oplossing is knockd Hiermee kan je bv een script koppelen voor de blocklist te clearen. Of voor bv de iptables aan te passen en het ip van de knocks toe te voegen.
Ik heb altijd nog via een browser applet direct toegang tot de VPS als last resort. Maar ik heb overigens 3 attempts. Had permanent bannen uit, bleef ik veel mailtjes krijgen, wordt nu een stuk minder. Ik kijk daardoor wel bewuster naar m'n caps-lock voor ik een poging doe via SSH. Liever van zoveel mogelijk van die *** brute-forces af dan zelf veel fouten kunnen maken bij inloggen.
Die last resort met toegang naar de VPS klinkt toch weer als een extra mogelijkheid voor een beveiligings lek.

En in plaats van permanente bans zou ik voor steeds langere time outs gaan zodat je eventueel later nog steeds in kan loggen als je de goede gegevens weer bij de hand hebt.
Dit is in de VPS management portaal bij mijn hoster. Als je ingelogd bent (waar ik ook domeinnamen etc beheer) dan kan je een applet inladen (op commando). Deze wordt ook gebruikt om op de blanco VPS het OS te installeren tot je openssh-server erop hebt, dan kun je met je favoriete terminal er naartoe en gebruik je die applet nooit meer. Daarom zou een 'perma-ban' niet zo heel veel uitmaken. Ik kan er altijd voor nood bij.
Als je fail2ban met geoip kan combineren is het niet zo erg ;)
Bespaar je de moeite en log in met je private key. Password authenticatie is het eerste wat ik uitschakel op mijn servers.
Ik denk dat het vooral appliances zijn zoals consumentenroutertjes en printservers enzo. Daarnaast zijn er nog altijd veel mensen die slechte wachtwoorden gebruiken. Ook worden tijdelijke accounts ("test", "test") nogal eens vergeten.
Wanneer malware een dergelijke naam heeft zou ik toch wel willen lezen, waarom het die naam heeft. Dat is namelijk niet echt voor de handliggend aangezien de malware Linux-systemen treft.
Malware krijgt (mits het een beetje groot is) een naampje op basis van wat het ongeveer is/doet/kan. In dit geval is er een module die Bill is genoemd, en die locked een file genaamd 'gate' (of 'gates'). Dus ja, vervolgens wordt dit dus Bill Gates botnet genoemd.

Het is meestal een signature van de maker, in dit geval lijkt het mij om een beetje te grappen c.q. de spot te drijven met Bill. Welk platform het daadwerkelijk draait maak dan eigenlijk ook niet uit.

Net zoals Flame (onderdeel / kind van) stuxnet was een 'string' (stukje tekst) uit de code. Love Letters, zowat het oudste virus was ook puur liefdes brieven :+
Thanks voor de verklaring.
Lijkt me juist de naam die je het meest verwacht ;)
Een virus wat Linux systemen infecteerd noemen naar de concurrent, *nogal* voorspelbare naam wat dat betreft :)
Dus het volgende Windows-virus heet het Tim Cook-virus.
Of steve jobs natuurlijk.
Jobs virus heeft al eens bestaan.
En het volgende Mac Os-virus Linus Torvalds-virus
Dus dit botnet had verkomen kunnen worden door je ssh server beter te beveiligen?
Gewoon een goed wachtwoord instellen is in dit geval genoeg. Trouwens, gebruik als het even kan sshkeys en schakel wachtwoord-logins helemaal uit, dat is nog veel veiliger.
Als je met die keys slordig omspringt vanwege gebruiksvriendelijkheid denk ik dat je met een wachtwoord + fail2ban nog veiliger bent.
Je kan het altijd verkeerd doen, maar als je je key beveiligd met een wachtwoord ben je volgens mij in alle realistische gevallen beter af. Het simpele feit dat je zonder de private key niks begint maakt je imuun voor 99.9% van de aanvallen. Pas als iemand jouw private key in handen krijgt wordt het spannend. Dan moet het wachtwoord op je key nog gekraakt worden.

Je public key mag je (de naam zegt het al) vrij verspreiden, iedereen mag hem weten. Dat is erg handig. Bij een traditionele wachtwoord-login moet de server namelijk altijd je wachtwoord weten. Op een of andere manier moet je op enig moment je wachtwoord aan de server doorgeven. Dat kan worden afgeluisterd. In praktijk gaat dat vaakl per (unencrypted) e-mail die dan ook nog eens voor eeuwig in de inbox blijft staan. Een public key heeft dat probleem niet. Die kun je in alle openheid delen en hoeft niet geheim te blijven.

Naast dat fundamentele voordeel is er ook nog de realiteit dat de meeste wachtwoorden nu eenmaal niet zo goed zijn. Zelfs als je zelf wel een heel goed wachtwoord hebt dan weet je niet zeker of andere gebruikers van die server wel een goed wachtwoord hebben.

Dan is er nog het "oeps, verkeerde veldje"-syndroom. Ik ben vast niet de enige die wel eens z'n wachtwoord op de verkeerde plek heeft ingevuld. Met een key kan dat niet. Zelfs al je het wachtwoord van je key per ongeluk op internet post is dat nog niet direct schadelijk zolang je private key maar veilig is.
Daarom heb ik mijn inlogkeys altijd op een OpenPGP smartcard. Daar kan je de key niet vanaf kopiëren en de kaart blokkeert zichzelf na 3x een verkeerde pincode. Werkt eigenlijk net zoals een bankpas of sim kaart.

Het is iets lastiger in het gebruik al valt het erg mee als je een laptop hebt met smartcard reader. En het voorkomt dat iemand je key gewoon vanaf je laptop kopieert.
Klinkt eerder als een soort token als je het mij vraagt.
Zo zou je het kunnen noemen. Maar het zijn gewoon RSA keys op een kaart. Waarbij de chip op de kaart de crypto berekeningen (signing in dit geval) uitvoert. Het gebruikt hetzelfde mechanisme als public key inlog op SSH. De server weet niet eens of je een smartcard gebruikt of een key die gewoon op schijf staat opgeslagen.
Tot op zekere hoogte zijn keys misschien veiliger, echter blijf ik er altijd nog een wachtwoord over de keyfile voeren om een halve 2 factor authorisation mogelijk te maken bij ssh.
Je kan ook nog een mac filter instellen, maar dat doen waarschijnlijk weinig particulieren..
Na je router (of eerste switch) ziet dus niemand je MAC adres meer.

[Reactie gewijzigd door Lye op 22 juli 2024 22:47]

Ehm. Na een router niet. Na een switch wel.
Edit: Excuses, was niet wakker :)

[Reactie gewijzigd door MartijnHavinga op 22 juli 2024 22:47]

Vind ik persoonlijk onhandig. Als mijn server moppert, en ik ben bij m'n ouders bijvoorbeeld, dan is het prettig als ik hun laptop ff kan pakken om in te loggen met SSH. (Ik gebruik het ook op m'n telefoon, maar soms heb je gewoon ff een desktop omgeving nodig)
Een mac filter, hoe zie je dat voor je via internet?
mac adress kan je over het algemeen spoofen

en misschien port knocking toevoegen

[Reactie gewijzigd door Tha_Butcha op 22 juli 2024 22:47]

En hoe dacht je een mac filter over das internetz te doen?
plus fail2ban tegen bruteforcing.
Jep. Die wou ik ook nog noemen. Zeer belangrijk als je eender wat voor aanmeld scherm toont aan de buitenwereld.

Ik had destijds mijn linux bak opnieuw geïnstalleerd en was die even vergeten. Na anderhalve week waren ze al aan het brute forcen. Weliswaar op de root account. Dus als je er voor zorgt dat je root niet aan te melden is via ssh en je jezelf geen standaard naam geeft kunnen ze ook blijven proberen...
Na anderhalve week pas? Mazzeltje dan :)
Ja, maar gewoon thuis, een dynamisch ip adres. Ik was toch een beetje verschoten dat je zo snel gevonden bent.
ik heb mijn root naam gewoon veranderd naar mijn naam, probleem opgelost.
Ook een idee, inderdaad. Maar in de linux wereld is een root account continu gebruiken nogal taboe.
op mijn vps stond standaard een user (niet root) en die heb ik veranderd.

Gelukkig niet root.
Dacht er nu pas overna want ik moet wel gewoon sudo gebruiken wil ik iets down. Dus dan ben je geen root he.
Serieus? Dat is alles? Als het zo makkelijk is om te voorkomen dat je deel uitmaakt van het botnet, dan heb je er bijna om gevraagd als je computer ermee is geïnfecteerd.
Ik zit dit wel te overwegen. Ik gebruik vooral mijn laptop, heel soms die van m'n ouders als 't even moet, maar dat is eens in het jaar.
Klopt veel devices zijn uitgerust met default passwords.

Zie ook http://internetcensus2012.bitbucket.org/paper.html voor meer informatie :o
Dat is het vervelende van al die IOT apparaten en standaard Raspberri Pi images.
Het wordt geinstalleerd, mensen passen de wachtwoorden niet aan (want dat is niet nodig), prikken het ding vervolgens aan internet en het resultaat is inderdaad malware op je Linux machine.
Raspberry PI images zijn niet het probleem want die hangen meestal achter een modem met NAT translatie dus die zijn niet te benaderen vanaf het Internet. Dit bovenstaande verhaal gaat meer over embedded devices die een Linux variant draaien.
En de standaard poort wijzigen, scheelt een massa's pogingen.
Dat soort dingen doe ik wel voor o.a. DirectAdmin. Hoeveel aanvallen ik wel niet krijg op poort 2222. Gelukkig gebruik ik Fail2Ban. Na 3 foutieve pogingen wordt een IP permanent banned.
Check dit even, met integratie in DirectAdmin control panel:
http://configserver.com/cp/csf.html
Klopt, ik gebruik al CSF + Fail2ban + DirectAdmin. Moet je alleen wel de poort van DirectAdmin goed zetten in CSF.
Anoniem: 718569 7 april 2016 21:03
Bruteforce wachtwoorden zoeken? How very oldschool. Eigenlijk wel een beetje respect voor op zo'n manier. Wat nou kwetsbaarheden? Gewoon de grootste kwetsbaarheid van allemaal misbruiken -- de menselijke factor!

Enfin, laat ten zoveelste male inderdaad wel weer zien hoe groot het belang is en blijft van een sterk wachtwoord. Bovenop andere maatregelen uiteraard.
Fail2ban installeren. Kan je aangeven na hoeveel foutieve pogingen je de aanvaller blokkeert en voor hoe lang. Standaard na 5 pogingen 10 minuten blokkeren dacht ik. Bij mij na 3 pogingen permanent blokkeren :+
Anoniem: 718569 @xoniq7 april 2016 21:33
Fail2ban installeren. Kan je aangeven na hoeveel foutieve pogingen je de aanvaller blokkeert en voor hoe lang. Standaard na 5 pogingen 10 minuten blokkeren dacht ik. Bij mij na 3 pogingen permanent blokkeren :+
Ooit een keer een soortgelijke mod geschreven voor phpBB maar dan niet tegen inlogpogingen maar tegen het creeeren van spam accounts.
Heb ik 'vroegah' ook gedaan met Invision. Voordeel van Fail2ban is dat deze goed kan samenwerken met CSF (Firewall).
Hij is zo te zien wel extreem lastig om te vinden?
Ben ik nou gek, of kijkt nooit iemand of er "shit" draait vanuit een tmp folder? Lijkt me sowieso niet echt de bedoeling...
Euhm nee, maar ik heb /tmp sowieso op no-excequte gemount. Veel plezier daar wat uit te draaien.
Tijd om, als je dat nog niet gedaan had, fail2ban te installeren. Of SSH keus gebruiken ipv wachtwoorden.
Bij onze servers hebben we het zo ingericht :

1) Sudo-accounts aangemaakt en root-login geblokkeerd
2) Alleen vanuit ons kantoor mag er via wachtwoorden ingelogd worden, de rest van de wereld heeft public keys nodig
3) fail2ban erop gezet om de logs niet te groot te laten worden.
Ik werd er schijt ziek van, keer op keer SSH/FTP brute force pogingen vrijwel dagelijks.
Ru en/of Chi en vreemd genoeg vaak Sierra Leone, vast en zeker achter een proxy

Maar wat aardig lijkt te werken is een honeypot server (met foto's van kittens)
PFsense als hardware firewall & ESET op cliënt machines

En als nog krijg ik altijd keer op keer even een hartverzakking als ik Rundeck failed login pogingen krijg in me mail. Maar tot nu toe gelukkig geen "successful authorization"
Een botnet genaamd BillGates op Linux-systemen. Hilarisch. :D
Bill Gates weet wel wat goed is, hij werkt er al tijdje mee (2014 [2])
op github staat een tracker; alleen geen idee hoe actueel dat nog is

[Reactie gewijzigd door himlims_ op 22 juli 2024 22:47]

Net zoals de Amd nano test pc met een i7 er in :)
Anoniem: 145867 @Indir7 april 2016 20:58
Een botnet genaamd BillGates op Linux-systemen. Hilarisch. :D
Leuke manier om Linux liefhebbers kwaad te maken. :) haha
Zo te zien een Linux power user :+

Op dit item kan niet meer gereageerd worden.