Collega's die Exim-versies 4.87...4.91 op hun mailservers gebruiken, updaten dringend naar versie 4.92, nadat ze Exim zelf eerst hebben gestopt om hacking via CVE-2019-10149 te voorkomen.
Enkele miljoenen servers over de hele wereld zijn potentieel kwetsbaar; de kwetsbaarheid wordt als kritiek beoordeeld (CVSS 3.0-basisscore = 9.8/10). Aanvallers kunnen willekeurige opdrachten uitvoeren op uw server, in veel gevallen vanaf de root.
Zorg ervoor dat u een vaste versie (4.92) gebruikt of een versie waarvoor al een patch is aangebracht.
Of patch de bestaande, zie draad .
Bijwerken voor CentOS 6: cm. — voor centos 7 werkt het ook, als het nog niet rechtstreeks vanuit epel is aangekomen.
UPD: Ubuntu wordt getroffen 18.04 en 18.10, er is een update voor hen uitgebracht. Versies 16.04 en 19.04 worden niet beïnvloed tenzij er aangepaste opties op zijn geïnstalleerd. Meer details .
Nu het daar beschreven probleem actief wordt uitgebuit (vermoedelijk door een bot), heb ik een infectie opgemerkt op sommige servers (die draaien op 4.91).
Verder lezen is alleen relevant voor degenen die het al hebben 'begrepen' - je moet alles naar een schone VPS met nieuwe software transporteren, of op zoek gaan naar een oplossing. Zullen we het proberen? Schrijf of iemand deze malware kan overwinnen.
Als u, als Exim-gebruiker en dit leest, nog steeds niet hebt bijgewerkt (niet zeker weet of 4.92 of een gepatchte versie beschikbaar is), stop dan en voer de update uit.
Voor degenen die er al zijn, laten we doorgaan...
UPD: en geeft het juiste advies:
Er kan een grote verscheidenheid aan malware bestaan. Door het medicijn voor het verkeerde te lanceren en de wachtrij te wissen, zal de gebruiker niet genezen en weet hij mogelijk niet waarvoor hij behandeld moet worden.
De infectie is als volgt merkbaar: [kthrotlds] laadt de processor; op een zwakke VDS is het 100%, op servers is het zwakker maar merkbaar.
Na infectie verwijdert de malware cron-vermeldingen en registreert zichzelf daar alleen om elke 4 minuten te worden uitgevoerd, terwijl het crontab-bestand onveranderlijk wordt gemaakt. Crontab-e kan de wijzigingen niet opslaan, geeft een foutmelding.
Onveranderlijk kan bijvoorbeeld op deze manier worden verwijderd en vervolgens de opdrachtregel (1.5 kb) verwijderen:
chattr -i /var/spool/cron/root
crontab -e
Verwijder vervolgens in de crontab-editor (vim) de regel en sla deze op:dd
:wq
Sommige van de actieve processen worden echter opnieuw overschreven, ik ben het aan het uitzoeken.
Tegelijkertijd hangen er een aantal actieve wgets (of krullen) aan de adressen van het installatiescript (zie hieronder), ik haal ze voorlopig zo neer, maar ze beginnen opnieuw:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Ik heb het Trojan-installatiescript hier gevonden (centos): /usr/local/bin/nptd... Ik plaats het niet om het te vermijden, maar als iemand geïnfecteerd is en shell-scripts begrijpt, bestudeer het dan zorgvuldiger.
Ik zal toevoegen zodra de informatie wordt bijgewerkt.
UPD 1: Het verwijderen van bestanden (met voorlopig chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hielp niet, en het stoppen van de service ook niet - ik moest crontab volledig, scheur het voorlopig uit (hernoem het bin-bestand).
UPD 2: Het Trojan-installatieprogramma slingerde soms ook op andere plaatsen rond, zoeken op grootte hielp:
vondst / -maat 19825c
UPD3: Waarschuwing! Naast het uitschakelen van selinux, voegt de Trojan ook zijn eigen Trojan toe SSH-sleutel in ${sshdir}/authorized_keys! En activeert de volgende velden in /etc/ssh/sshd_config, als ze nog niet op YES zijn ingesteld:
PermitRootLogin ja
RSAAuthenticatie ja
PubkeyAuthentication ja
echo GebruikPAM ja
Wachtwoordverificatie ja
UPD 4: Om voor nu samen te vatten: schakel Exim uit, cron (met root), verwijder dringend de Trojan-sleutel uit ssh en bewerk de sshd-configuratie, start sshd opnieuw op! En het is nog niet duidelijk dat dit zal helpen, maar zonder dit is er een probleem.
Ik heb belangrijke informatie uit de opmerkingen over patches/updates naar het begin van de notitie verplaatst, zodat lezers ermee kunnen beginnen.
UPD5: dat de malware wachtwoorden in WordPress heeft gewijzigd.
UPD6: , laten we testen! Na een herstart of afsluiting lijkt het medicijn te verdwijnen, maar voorlopig is dat alles.
Iedereen die een stabiele oplossing maakt (of vindt), schrijf alstublieft, u zult velen helpen.
UPD7: schrijft:
Als u nog niet heeft gezegd dat het virus weer tot leven is gewekt dankzij een niet-verzonden brief in Exim, wordt deze hersteld wanneer u de brief opnieuw probeert te verzenden. Kijk in /var/spool/exim4
U kunt de volledige Exim-wachtrij als volgt wissen:
exipick -i | xargs exim-Mrm
Het aantal vermeldingen in de wachtrij controleren:
exim-bpc
UPD 8: Opnieuw : FirstVDS heeft hun versie van het behandelscript aangeboden, laten we het testen!
UPD 9: Het lijkt erop werken, Met dank voor het script!
Het belangrijkste is om niet te vergeten dat de server al gecompromitteerd was en dat de aanvallers erin geslaagd waren wat meer atypische vervelende dingen te plaatsen (niet vermeld in de dropper).
Daarom is het beter om naar een volledig geïnstalleerde server (vds) te gaan, of in ieder geval het onderwerp te blijven volgen - als er iets nieuws is, schrijf dan hier in de reacties, want uiteraard zal niet iedereen overstappen naar een nieuwe installatie...
UPD 10: Nogmaals bedankt : het herinnert eraan dat niet alleen servers zijn geïnfecteerd, maar ook Raspberry Pi, en allerlei soorten virtuele machines... Vergeet dus na het opslaan van de servers niet uw videoconsoles, robots, enz. op te slaan.
UPD 11: Van Belangrijke opmerking voor manuele genezers:
(na gebruik van een of andere methode om deze malware te bestrijden)
Je moet zeker opnieuw opstarten - de malware bevindt zich ergens in open processen en dus in het geheugen, en schrijft zichzelf elke 30 seconden een nieuwe naar de cron
UPD12: Exim heeft nog een (?) malware in de wachtrij staan en adviseert u eerst uw specifieke probleem te onderzoeken voordat u met de behandeling begint.
UPD13: ga liever naar een schoon systeem en breng de bestanden uiterst voorzichtig over, omdat De malware is al openbaar beschikbaar en kan op andere, minder voor de hand liggende en gevaarlijkere manieren worden gebruikt.
UPD 14: onszelf geruststellen dat slimme mensen niet van de wortel weglopen – nog één ding :
Zelfs als het niet vanuit de root werkt, vindt er toch hacking plaats... Ik heb debian jessie UPD: stretch op mijn OrangePi, Exim draait vanuit Debian-exim en er gebeurde nog steeds hacking, verloren kronen, enz.
UPD 15: wanneer u van een gecompromitteerde server overstapt naar een schone server, vergeet dan de hygiëne niet, :
Let bij het overbrengen van gegevens niet alleen op uitvoerbare bestanden of configuratiebestanden, maar ook op alles dat kwaadaardige opdrachten kan bevatten (in MySQL kan dit bijvoorbeeld CREATE TRIGGER of CREATE EVENT zijn). Vergeet ook .html, .js, .php, .py en andere openbare bestanden niet (idealiter zouden deze bestanden, net als andere gegevens, moeten worden hersteld vanuit lokale of andere vertrouwde opslag).
UPD16: и : op het systeem was één versie van Exim in de poorten geïnstalleerd, maar in werkelijkheid draaide het een andere versie.
Dus iedereen na de update moet u er zeker van zijn dat u de nieuwe versie gebruikt!
exim --versionSamen hebben we hun specifieke situatie in kaart gebracht.
De server gebruikte DirectAdmin en zijn oude da_exim pakket (oude versie, zonder kwetsbaarheid).
Tegelijkertijd werd er met behulp van de custombuild pakketbeheerder van DirectAdmin feitelijk een nieuwere versie van Exim geïnstalleerd, die al kwetsbaar was.
In deze specifieke situatie hielp het updaten via custombuild ook.
Vergeet niet om vóór dergelijke experimenten back-ups te maken, en zorg er ook voor dat voor/na de update alle Exim-processen van de oude versie zijn en niet “vast” in het geheugen.
Bron: www.habr.com