Collega's, wie Exim-versies 4.87…4.91 op hun mailservers gebruikt — update onmiddellijk naar versie 4.92, stop eerst Exim om hacking via CVE-2019-10149 te voorkomen.
Potentieel zijn er miljoenen servers wereldwijd kwetsbaar, de kwetsbaarheid wordt als kritiek beoordeeld (CVSS 3.0 basis score = 9.8/10). Aanvallers kunnen willekeurige commando's op uw server uitvoeren, in veel gevallen met root-rechten.
Zorg ervoor dat u de gecorrigeerde versie (4.92) gebruikt of al gepatcht bent.
Of patch uw bestaande versie, zie de thread .
Update voor centos 6: zie — voor centos 7 werkt het ook, als het nog niet rechtstreeks uit EPEL is gekomen.
UPD: Ubuntu is getroffen 18.04 en 18.10, er is een update voor hen uitgebracht. Versies 16.04 en 19.04 zijn niet getroffen, tenzij er aangepaste versies op zijn geïnstalleerd. Meer details .
Het probleem dat daar wordt beschreven, wordt momenteel actief geëxploiteerd (door een bot, vermoed ik), ik heb besmetting op sommige servers (die op 4.91 draaiden) opgemerkt.
Verder lezen is alleen relevant voor degenen die al "in de problemen" zijn — u moet ofwel alles verplaatsen naar een schone VPS met frisse software, of een oplossing zoeken. Proberen we? Laat het weten als iemand deze malware kan bestrijden.
Als u een Exim-gebruiker bent en dit leest, en u bent nog niet geüpdatet (en niet bent verzekerd van versie 4.92 of een gepatchte versie), stop dan alstublieft en ga snel updaten.
Voor degenen die al besmet zijn — laten we verdergaan...
UPD: en geeft correct advies:
Er kunnen talloze malware zijn. Door een verkeerd medicijn te draaien en de wachtrij schoon te maken, zal de gebruiker niet beter worden en mogelijk niet eens weten waarvoor hij moet worden behandeld.
Besmetting is merkbaar als volgt: [kthrotlds] belast de processor; op een zwakke VDS tot 100%, op zwakkere servers, maar merkbaar.
Na besmetting verwijdert de malware cron-invoer, waarbij alleen zichzelf elke 4 minuten aanroept, en maakt daarbij het crontab-bestand immutable. Crontab -e kan geen wijzigingen opslaan en geeft een foutmelding.
Immutable kan bijvoorbeeld zo worden opgeheven, waarna de commando-regel (1,5 KB) kan worden verwijderd:
chattr -i /var/spool/cron/root
crontab -e Daarna verwijderen we in de crontab-editor (vim) de regel en slaan op:dd
:wq
Echter, een van de actieve processen schrijft opnieuw over, ik ben aan het uitzoeken.
Er zijn veel actieve wget's (of curl's) naar de adressen in het installatiescript (zie hieronder), ik schakel ze voorlopig zo uit, maar ze starten weer op:
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}'`
Het installatiescript van de trojan vond ik hier (centos): /usr/local/bin/nptd… ik publiceer het niet om veiligheidsredenen, maar als iemand besmet is en kennis heeft van shellscripts, bestudeer het dan alsjeblieft nauwkeurig.
Ik zal aanvullen naarmate ik meer informatie heb.
UPD 1: Verwijderen van bestanden (na voorafgaand chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hielp niet, net als het stoppen van de service — ik moest de crontab voorlopig helemaal verwijderen (bin-bestand hernoemen).
UPD 2: De installateur van de trojan lag soms ook op andere plaatsen, de zoektocht op grootte hielp:
find / -size 19825c
UPD 3: Let op! Naast het uitschakelen van selinux voegt de trojan ook zijn SSH-sleutel toe aan ${sshdir}/authorized_keys! En activeert de volgende velden in /etc/ssh/sshd_config, als deze nog niet als YES waren opgenomen:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Samenvattend tot nu toe: schakelen we exim, cron (met root toegang) uit, verwijderen we dringend de trojan sleutel uit ssh en corrigeren we de sshd-config, herstarten we sshd! En het is nog niet zeker of dit zal helpen, maar zonder dit is het echt een probleem.
Belangrijke informatie uit de reacties over patches/updates heb ik naar het begin van de notitie verplaatst, zodat degenen die vanaf daar lezen, beginnen.
UPD 5: dat malware de wachtwoorden in WordPress heeft veranderd.
UPD 6: , we testen! Na herstart of uitschakeling lijkt het te verdwijnen, maar voor nu is dit een tijdelijke oplossing.
Wie een stabiele oplossing maakt (of vindt), laat het alsjeblieft weten, het zal veel mensen helpen.
UPD 7: schrijft:
Als het nog niet is gezegd, herleeft het virus door een niet-verzonden e-mail in exim, bij een hernieuwde poging om de e-mail te verzenden, herstelt het zichzelf, kijk in /var/spool/exim4
Je kunt de hele exim-queue zo leegmaken:
exipick -i | xargs exim -Mrm
Controleer het aantal records in de wachtrij:
exim -bpc
UPD 8: Nogmaals : FirstVDS heeft zijn versie van het script voor de behandeling aangeboden, laten we testen!
UPD 9: Het lijkt erop dat slechts met één thread werkt., bedankt voor het script!
Vergeet niet dat de server al gecompromitteerd was en dat aanvallers mogelijk nog andere atypische troep (niet opgenomen in de dropper) hebben geïnstalleerd.
Het is daarom beter om naar een schoon geïnstalleerde server (vds) over te stappen, of in ieder geval het onderwerp te blijven volgen — als er iets nieuws is, laat dan een reactie hier achter, omdat duidelijk niet iedereen zal overstappen naar een nieuwe installatie...
UPD 10: Nogmaals bedankt : het herinnert eraan dat niet alleen servers geïnfecteerd raken, maar bijvoorbeeld ook Raspberry Pi, en allerlei virtuele machines… Vergeet dus niet, na het herstellen van servers, ook je videogameconsoles, robots, enz. te redden.
UPD 11: Van een belangrijke opmerking voor degenen die handmatig 'genezen':
(na het toepassen van een bepaalde methode tegen deze kwaadaardige software)
het is absoluut noodzakelijk om opnieuw op te starten — malware blijft ergens in de actieve processen en dus in het geheugen zitten, en schrijft zichzelf elke 30 seconden opnieuw in cron
UPD 12: bij zich in de wachtrij een andere(?) kwaadaardige software via exim en adviseert om eerst je specifieke probleem grondig te bestuderen voordat je met de behandeling begint.
UPD 13: om sneller over te stappen naar een schoon systeem, en bestanden uiterst voorzichtig te verplaatsen, omdat malware al openbaar toegankelijk is en door anderen op minder voor de hand liggende en gevaarlijkere manieren kan worden gebruikt.
UPD 14: geruststellend voor jezelf dat slimme mensen niet van root draaien — nog een :
Zelfs als het niet onder root draait, vindt er een hack plaats… Op mijn OrangePi draait debian jessie UPD: stretch, exim is gestart door Debian-exim en er vond nog steeds een hack plaats, cron en andere zaken zijn gewist.
UPD 15: bij het overstappen naar een schone server van een gecompromitteerde vergeet niet de hygiëne, :
Bij het overzetten van gegevens, let niet alleen op uitvoerbare of configuratiebestanden, maar ook op alles wat kwaadaardige opdrachten kan bevatten (bijvoorbeeld in MySQL kan dit CREATE TRIGGER of CREATE EVENT zijn). Vergeet ook niet de .html, .js, .php, .py en andere openbare bestanden (ideaal gesproken moeten deze bestanden, net als andere gegevens, worden hersteld uit een lokale of andere vertrouwde opslag).
UPD 16: en : de versie van exim was op de poorten in het systeem, maar in werkelijkheid werd er een andere uitgevoerd.
Dus iedereen moet na de update ervoor zorgen dat ze echt de nieuwe versie gebruiken!
exim --versionWe hebben gezamenlijk hun situatie opgelost.
Op de server werd DirectAdmin gebruikt en was er zijn oude package da_exim (oude versie, zonder kwetsbaarheid).
Met behulp van de package manager van DirectAdmin, custombuild, werd uiteindelijk een nieuwere, kwetsbare versie van exim geïnstalleerd.
In deze specifieke situatie hielp een update via custombuild ook.
Vergeet niet om backups te maken voor dergelijke experimenten en zorg ervoor dat alle processen van de oude versie van exim voor en na de update zijn gestopt. en niet in het geheugen 'vastzaten'.
Bron: habr.com
