image

ESET: 400.000 Linux-servers afgelopen jaren besmet met Ebury-malware

donderdag 16 mei 2024, 16:25 door Redactie, 20 reacties

De afgelopen jaren zijn wereldwijd 400.000 Linux-servers besmet geraakt met de Ebury-malware, waaronder servers van Kernel.org, zo stelt antivirusbedrijf ESET in een analyse. Het Ebury-botnet is sinds 2009 actief en in die tijd verschillende keren in het nieuws geweest. Zo werd in 2017 een vermeende beheerder veroordeeld. Eind 2023 bleken nog altijd 100.000 servers besmet te zijn.

In de analyse laten de onderzoekers ook weten hoe de malware zich verspreidt. Lange tijd werd gedacht dat dit gebeurde door middel van gecompromitteerde inloggegevens. Zodra de aanvallers toegang tot een Linux-server hebben worden aanwezige OpenSSH-bestanden aangepast. Wanneer er vanaf de besmette server op een andere server wordt ingelogd, komen de inloggegevens van deze server ook in handen van de aanvallers, die zo het proces kunnen herhalen.

ESET meldt nu dat Linux-servers ook worden gecompromitteerd door middel van credential stuffing-aanvallen, via hypervisors of container hosts waar de aanvallers toegang toe hebben, misbruik van kwetsbaarheden zoals die in Control Web Panel en Dirty COW, het compromitteren van hostingproviders en man-in-the-middle-aanvallen op servers in hetzelfde netwerk. De Ebury-malware kan niet alleen ssh-inlogegevens stelen, maar ook creditcardgegevens en cryptowallets. Daarnaast worden besmette machines gebruikt voor het proxyen van verkeer en spam.

Kernel.org

De onderzoekers stellen ook dat tussen 2009 en 2011 vier servers van Kernel.org, een website van The Linux Foundation, met Ebury waren besmet. De servers werden vermoedelijk gebruikt als mailservers, nameservers, mirrors en source code repositories. Twee van de servers zijn waarschijnlijk twee jaar besmet geweest, een server een jaar en de ander zes maanden.

De aanvallers wisten ook de /etc/shadow bestanden in handen te krijgen, die 551 unieke gebruikersnamen en gehashte wachtwoorden bleken te bevatten. Van deze wachtwoordhashes wisten de aanvallers 275 wachtwoorden in cleartext te achterhalen door middel van brute force en de Ebury credential stealer, aldus de onderzoekers.

Verder werd eind 2019 de infrastructuur van een niet nader genoemde grote Amerikaanse domeinregistrar en hostingprovider gecompromitteerd. Het ging om 2500 fysieke en 60.000 virtuele servers. De machines werden bij elkaar gebruikt voor het hosten van de websites van meer dan 1,5 miljoen accounts. Bij een ander incident vorig jaar werden 70.000 servers van de hostingprovider gecompromitteerd.

"Ebury vormt een serieuze dreiging en uitdaging voor de Linux-gemeenschap", zegt onderzoeker Marc-Etienne Léveillé. "Er is geen eenvoudige oplossing die Ebury ineffectief maakt, maar een aantal mitigaties zijn toe te passen om de verspreiding en de impact te beperken." De onderzoeker benadrukt dat infecties niet alleen bij organisaties en individuen plaatsvinden die minder om security geven. "Veel zeer tech-savy personen en grote organisaties bevinden zich onder de slachtoffers."

Image

Reacties (20)
16-05-2024, 20:15 door Anoniem
MFA met TOTP op je jumphosts gebruiken en updates doorvoeren zodra ze er zijn en dagelijks alles met AIDE en rkhunter testen en loggen?
16-05-2024, 21:49 door Anoniem
Is er ook een Nederlandse vertaling van dit artikel beschikbaar? Dan kan ik er misschien ook wat mee.
16-05-2024, 22:38 door Anoniem
elke maand wordt het serverpark hier herinstalleerd... wanneer ze de boel infecteren is dat hoogstens 31 dagen.
lessons learned na eerste infectie van tomcat in 2011...
17-05-2024, 08:20 door Anoniem
"Er is geen eenvoudige oplossing die Ebury ineffectief maakt, maar een aantal mitigaties zijn toe te passen om de verspreiding en de impact te beperken."

Uhm. Antimalware? Bestaat dat ook niet voor Linux vandaag de dag?
17-05-2024, 10:40 door Anoniem
Door Anoniem: elke maand wordt het serverpark hier herinstalleerd... wanneer ze de boel infecteren is dat hoogstens 31 dagen.
lessons learned na eerste infectie van tomcat in 2011...

Ik hoop dat je een grapje maakt. Er zijn zo veel oplossingen die voorkomen dat je dit soort rigoureuze maatregelen hoeft te nemen. Logging, monitoring en zaken als fail2ban, iptables, se-linux/apparmour. Als je dat goed inregelt hoef je echt niet elke maand je servers te herinstalleren.
17-05-2024, 13:28 door Anoniem
Door Anoniem:
Door Anoniem: elke maand wordt het serverpark hier herinstalleerd... wanneer ze de boel infecteren is dat hoogstens 31 dagen.
lessons learned na eerste infectie van tomcat in 2011...

Ik hoop dat je een grapje maakt. Er zijn zo veel oplossingen die voorkomen dat je dit soort rigoureuze maatregelen hoeft te nemen. Logging, monitoring en zaken als fail2ban, iptables, se-linux/apparmour. Als je dat goed inregelt hoef je echt niet elke maand je servers te herinstalleren.

Wtf je kunt toch gewoon integrity check doen op je file, desnoods op een snapshot

yum verify-rpm gcc
17-05-2024, 14:37 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: elke maand wordt het serverpark hier herinstalleerd... wanneer ze de boel infecteren is dat hoogstens 31 dagen.
lessons learned na eerste infectie van tomcat in 2011...

Ik hoop dat je een grapje maakt. Er zijn zo veel oplossingen die voorkomen dat je dit soort rigoureuze maatregelen hoeft te nemen. Logging, monitoring en zaken als fail2ban, iptables, se-linux/apparmour. Als je dat goed inregelt hoef je echt niet elke maand je servers te herinstalleren.

Wtf je kunt toch gewoon integrity check doen op je file, desnoods op een snapshot

yum verify-rpm gcc

Als je _zeker_ weet dat je rpm gpg keys en hashes nog betrouwbaar zijn, en ook zeker weet dat hetgeen 'gelezen' wordt door de het yum proces ook hetzelfde is wat op disk staat dan kan dat , ja.

En dan weet je dat de files afkomstig van rpm's origineel zijn . Wat er in toegevoegde config files staat (sshd authorized keys, of zo iets) verifieer je niet tegen de 'bron' rpms.
17-05-2024, 16:06 door Joep Lunaar
Snel doorlezend in het rapport zie ik staan
... Another interesting method is the use of adversary in the middle to intercept SSH traffic of interesting targets inside data centers and redirect it to a server used to capture credentials ...
en dat is vreemd omdat SSH authenticatie vaak pubkey gebaseerd is en in zoverre de SSH server de gebruikers autenticieert met bijv PAM of Kerberos is onderschepping van credentials ook niet goed mogelijk (veelal authenticatie met een salted challenge). Kortom: is dit rapport wel serieus ?
17-05-2024, 17:42 door Anoniem
Door Joep Lunaar: Snel doorlezend in het rapport zie ik staan
... Another interesting method is the use of adversary in the middle to intercept SSH traffic of interesting targets inside data centers and redirect it to a server used to capture credentials ...
en dat is vreemd omdat SSH authenticatie vaak pubkey gebaseerd is en in zoverre de SSH server de gebruikers autenticieert met bijv PAM of Kerberos is onderschepping van credentials ook niet goed mogelijk (veelal authenticatie met een salted challenge). Kortom: is dit rapport wel serieus ?

Ah, omdat het in jouw bubbel "veelal" is moet het rapport dat meld dat er elders wel wat te halen was op die manier wel fout zijn ?
17-05-2024, 19:42 door Anoniem
Door Joep Lunaar: Snel doorlezend in het rapport zie ik staan
... Another interesting method is the use of adversary in the middle to intercept SSH traffic of interesting targets inside data centers and redirect it to a server used to capture credentials ...
en dat is vreemd omdat SSH authenticatie vaak pubkey gebaseerd is en in zoverre de SSH server de gebruikers autenticieert met bijv PAM of Kerberos is onderschepping van credentials ook niet goed mogelijk (veelal authenticatie met een salted challenge). Kortom: is dit rapport wel serieus ?

inderdaad! https://goteleport.com/blog/ssh-handshake-explained/
17-05-2024, 23:38 door Anoniem
Door Joep Lunaar: Snel doorlezend in het rapport zie ik staan
... Another interesting method is the use of adversary in the middle to intercept SSH traffic of interesting targets inside data centers and redirect it to a server used to capture credentials ...
en dat is vreemd omdat SSH authenticatie vaak pubkey gebaseerd is en in zoverre de SSH server de gebruikers autenticieert met bijv PAM of Kerberos is onderschepping van credentials ook niet goed mogelijk (veelal authenticatie met een salted challenge). Kortom: is dit rapport wel serieus ?
Die antivirusbedrijven lopen omzet mis vanwege aflopende windows marktaandeel. Daarom proberen ze andere (linux) markt te creeren. Kaspersky komt ook regelmatig met verhalen waar geen bewijzen van zijn.
Niet in trappen. Geen closed source bedrijven root toegang geven!!
SSH verkeer kan je helemaal niet intercepten. Het is encrypted. Wat wel gebeurd is dat er wel eens toegang wordt verkregen via een vmware hypervisor mbv een gehackte windows vCenter. Zelfde geldt voor hyperv omgeving. Daar doe je dus helemaal niets aan omdat men dan toegang heeft tot je disk.
Die kernel.org servers waren jaren geleden gehackt door ene Donald Austin met gestolen login credentials in 2011. Zie: https://s3.documentcloud.org/documents/3038530/Indictment-against-Donald-Ryan-Austin.pdf
18-05-2024, 23:26 door Anoniem
Wel apart dat ze met nieuws komen uit 2009 en 2011, die aanvals methoden zijn al lang en breed gepatcht. Ik vind het een enigszins vaag en samenveraapt verhaal.
19-05-2024, 02:54 door Anoniem
@17-05-2024, 23:38 door Anoniem: get a clue.
@17-05-2024, 16:06 door Joep Lunaar: ze noemen credentials, niet keys. Het gaat om een gehackte versie van SSH.

https://www.theregister.com/2023/12/20/terrapin_attack_ssh/
19-05-2024, 11:03 door Anoniem
Linux goes the windows way. Struisvogel politiek ligt aan de basis van de meeste besmettingen.
19-05-2024, 11:58 door Anoniem
Door Anoniem: elke maand wordt het serverpark hier herinstalleerd... wanneer ze de boel infecteren is dat hoogstens 31 dagen.
lessons learned na eerste infectie van tomcat in 2011...

Je weet toch dat er ook malware aanwezig kan zijn in de gegevens zelf, en niet in het O.S.?
Van zodra je een backup van je gegevens terugzet, raak je weer geïnfecteerd...
19-05-2024, 12:03 door Anoniem
Of iets te intercepten is of niet, heeft helemaal niets met encryptie te maken.

SSH verkeer kan je perfect intercepten. De encryptie zorgt er dan voor dat je niet weet wat er verstuurd wordt, maar toch kan je hier informatie uithalen.
VB: Als je via SSH inlogt met een wachtwoord i.p.v. een key, kan een evesdropper zien uit hoeveel karakters je PW bestaat, etc...
20-05-2024, 10:11 door Anoniem
Door Anoniem: Of iets te intercepten is of niet, heeft helemaal niets met encryptie te maken.

SSH verkeer kan je perfect intercepten. De encryptie zorgt er dan voor dat je niet weet wat er verstuurd wordt, maar toch kan je hier informatie uithalen.
VB: Als je via SSH inlogt met een wachtwoord i.p.v. een key, kan een evesdropper zien uit hoeveel karakters je PW bestaat, etc...

time has moved on https://www.openwall.com/articles/SSH-Traffic-Analysis
20-05-2024, 19:57 door Anoniem
Door Anoniem: Of iets te intercepten is of niet, heeft helemaal niets met encryptie te maken.

SSH verkeer kan je perfect intercepten. De encryptie zorgt er dan voor dat je niet weet wat er verstuurd wordt, maar toch kan je hier informatie uithalen.
VB: Als je via SSH inlogt met een wachtwoord i.p.v. een key, kan een evesdropper zien uit hoeveel karakters je PW bestaat, etc...
SSH verkeer kan je niet intercepten! Mijn passphrase lezen is onmogelijk en mijn private key gaat niet eens de lijn over.
24-05-2024, 11:22 door Joep Lunaar
Door Anoniem: @17-05-2024, 23:38 door Anoniem: get a clue.
@17-05-2024, 16:06 door Joep Lunaar: ze noemen credentials, niet keys. Het gaat om een gehackte versie van SSH.

https://www.theregister.com/2023/12/20/terrapin_attack_ssh/
Interceptie gaat over waarnemen van communicatie, niet over (onbevoegd) gewijzigde programmatuur. In het dat laatste geval gaat het om volledig andere aanvalsvectoren en gaat het bij mitigatie daarvan om isolatie/sandbox, beperkingen van rechten, geen uitvoering van code die niet geverifieerd is en ook niet van code op schrijfbare media of in RAM), enz.
27-05-2024, 19:32 door Anoniem
Door Anoniem:
Door Anoniem: elke maand wordt het serverpark hier herinstalleerd... wanneer ze de boel infecteren is dat hoogstens 31 dagen.
lessons learned na eerste infectie van tomcat in 2011...

Ik hoop dat je een grapje maakt. Er zijn zo veel oplossingen die voorkomen dat je dit soort rigoureuze maatregelen hoeft te nemen. Logging, monitoring en zaken als fail2ban, iptables, se-linux/apparmour. Als je dat goed inregelt hoef je echt niet elke maand je servers te herinstalleren.

Die mening deel ik ook. fail2ban & iptables kan al heel wat zaken tegenhouden, mits goed geconfigureerd. Logging, monitoring heel belangrijk, ook om trends op te sporen. Verder Wazuh & loging. Verder niet te vergeten DMZ, segmenteren en hardware devices welke TCP/IP nodig hebben Switches routers de Mgmt laag via Vlans beschikbaar stellen. Veel bedrijven hebben deze zaken niet goed of zelfs helemaal niet geregeld. Of verkeerd geconfigureerd. En niet getest e.d.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.