ESET: 400.000 Linux-servers afgelopen jaren besmet met Ebury-malware
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."
lessons learned na eerste infectie van tomcat in 2011...
Uhm. Antimalware? Bestaat dat ook niet voor Linux vandaag de dag?
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.
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
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.
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 ?
inderdaad! https://goteleport.com/blog/ssh-handshake-explained/
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
@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/
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...
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 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
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...
@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/
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.
Je bent niet ingelogd 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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
