Bekijk Volledige Versie : Nieuw soort hack, de cryptocoin miner installeren
stefantriep
21/02/18, 22:40
Laatst had ik ineens dat een server continue een bepaald proces draaide, waarbij ik dacht dat de klant gewoon iets fout had gedaan en het proces bleef "hangen". Maar het gekke was hoe vaak ik het proces ook beëindigde, het kwam telkens weer terug.
Het proces bleef ook CPU draaien op 1000% (zie ik in top), maar het gekke was het proces draaide onder de root user met een commando van een programma wat helemaal niet geïnstalleerd was, maar wel tot de basis van de disto hoort (om niet op te vallen).
Vond uiteindelijk een bestand dat door een ander bestand werd aangeroepen en dat weer een ander bestand.
Nu zie ik het net weer op een andere server (waar de CPU maar 100% draait), maar ik kan er niet echt achter komen, hoe ze dat als root kunnen draaien en hoe ze dit installeren. Iemand die dit herkend?
Aangezien het niks doet dan alleen CPU gebruiken gok ik gewoon een of andere crypto miner draaien.
Voor de duidelijkheid, de root user kan niet via SSH inloggen (alleen sudo of su) en er wordt niet via SSH ingelogd, anders krijg ik namelijk een melding per mail en moet ik iets in de logs zien.
Zelfde issue; gehad op twee verschillende servers.
Ben er (nog) niet achter hoe of wat; maar waar ik / we wel achter zijn gekomen is dat er een uitgaande verbinding naar een bepaald domein wordt gedaan. Deze is als temp-fix via de hosts file ge-nullroute naar localhost en bijbehorend ip in CSF gezet. Na dit gedaan te hebben viel load en cpu terug naar normaal. De aanroep in rc.local verwijderd.
Maar het hoe en wat? Raadsel.
stefantriep
21/02/18, 23:37
Ik sprak net een bekende, blijkt niets met cryptocoins te zijn die gemined worden, maar de server wordt onderdeel van een botnet vermoedde hij. Helaas is de code encrypted, anders had ik het graag voor anderen uitgezocht.
Blijkt te maken te hebben met een lekke kernel in combinatie met verouderde services. Tijd voor een reinstall met de laatste OS, kernel en services dus.
Hoop dat ik anderen hiermee heb kunnen helpen die dit ook tegenkomen.
Dit stond er in /etc/rc.local :
/usr/sbin/eixm > /dev/null 2>&1
/usr/bin/chgae > /dev/null 2>&1
Ik heb het volgende in de host-file gezet voor als je wat tijd wilt winnen
0.0.0.0 pixeldgarui.xyz hifdyfduguigyu.xyz
Draaien jullie toevallig DirectAdmin? Zo ja, is die helemaal up to date? We hebben dit gezien bij een klant en daar zijn ze voor 99% zeker binnen gekomen via https://www.directadmin.com/features.php?id=2036.
Als je het proces start wat dit doet zie je onder andere een login inclusief wachtwoord.
30502 write(15, "{\"id\":1,\"jsonrpc\":\"2.0\",\"method\":\"login\",\"params\":{\"login\":\"B0aKo3T\",\"pass\":\"x\",\"agent\":\"Mozilla/5.0 (X11; CentOS; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36\"}}\n", 205) = 205
Correct. En inderdaad nog niet op 1.52.
Edit:
Heel toevallig kreeg ik zojuist op een derde server last van exact dit probleem. Na het updaten van DA (naar 1.52100) zijn de vreemde processen verdwenen. Heel gek.
Je moet sowieso de server opnieuw installeren. Het is niet leuk, maar anders weet je nooit 100% zeker of het weg is of wat ze verder nog kunnen.
Meer info over wat er tot nu toe bekend is:
https://www.virustotal.com/#/file/a1668ded16c6028d692ac8fcb8fc5f59c983dbe6d0c22ec0fb 8cd7ba127c7501/detection
Wij hebben het bestand op 16 januari al bij ze geupload en ook meteen aangemeld bij ClamAV en Sophos. Sophos had me al bericht dat ze het hebben opgepakt, ClamAV gaf aan dat ze dachten dat het een schoon bestand was.
Met Ansible hebben we snel alle servers gescand op rare verzoeken.
---
- hosts: "{{ target|default('test') }}"
serial: 10
max_fail_percentage: 20
tasks:
- name: "Check DirectAdmin installation"
stat: path=/usr/local/directadmin/conf/directadmin.conf
register: directadmin
- name: "Get output from directadmin logs"
command: "/bin/bash -c 'grep CMD_CHANGE_FTP_PASSWORD /var/log/directadmin/*.log'"
when: directadmin.stat.exists == True
failed_when: False
changed_when: False
register: ftp
- debug: var=ftp.stdout_lines
when: ftp.rc|default(1) == 0
Dit doet niets bijzonders zoals je ziet, je moet nog wel zelf even nadenken of wat je terug krijgt klopt, maar het heeft ons geholpen om snel even alle logs te doorzoeken op alle servers (o.a. van klanten). Misschien heeft iemand anders er ook nog wat aan.
Wij hebben het ook zien gebeuren en het is een bug in Directadmin. We hebben dit bij Directadmin gemeld en zij hebben er toen op ons verzoek een CVE van gemaakt: https://www.directadmin.com/features.php?id=2036
- Update Directadmin en of pas de genoemde workaround toe
- Check files in /usr/bin/ die met 'ch' beginnen
- Check /etc/rc.local
- Beter nog; doe een frisse installatie
- Wijzig al je wachtwoorden - we hebben traces gemaakt van de code en er gebeuren dingen met wachtwoorden
Ik sluit ook niet uit dat er een miner in zit, maar het kan ook een password bruteforce mechanisme zijn.
Ik sprak net een bekende, blijkt niets met cryptocoins te zijn die gemined worden, maar de server wordt onderdeel van een botnet vermoedde hij. Helaas is de code encrypted, anders had ik het graag voor anderen uitgezocht.
Blijkt te maken te hebben met een lekke kernel in combinatie met verouderde services. Tijd voor een reinstall met de laatste OS, kernel en services dus.
Hoop dat ik anderen hiermee heb kunnen helpen die dit ook tegenkomen.
Dit stond er in /etc/rc.local :
/usr/sbin/eixm > /dev/null 2>&1
/usr/bin/chgae > /dev/null 2>&1
Daar ben ik het niet mee eens wbt kernel, de service die getarget wordt is directadmin, en deze draait welliswaar onder zijn eigen user, maar wordt gestart vanuit root. Je ziet namelijk tentijde van je infectie in je logs ook dat er een sigterm voorbij komt.
Wat betreft de files, als je in de dir /urs/bin een ls -la doet, valt het bestand op doordat hij rood is en in veel gevallen lijkt op een bestand wat erboven of eronder staat qua naam. Maar namen als ta / at zijn ook in gebruik.
De services zelf worden weggeschreven, gestart en vervolgens weer verwijderd zodat ze niet terug te vinden zijn. Voor wie zijn box nog niet gerestart heeft kan aan de hand van de process id refererend aan de file in /usr/bin in /proc gaan kijken. Daar vind je de env file van je proces en zie je dat de basis voortkomt uit de binary van directadmin.
Wij hebben het ook zien gebeuren en het is een bug in Directadmin. We hebben dit bij Directadmin gemeld en zij hebben er toen op ons verzoek een CVE van gemaakt: https://www.directadmin.com/features.php?id=2036
- Update Directadmin en of pas de genoemde workaround toe
- Check files in /usr/bin/ die met 'ch' beginnen
- Check /etc/rc.local
- Beter nog; doe een frisse installatie
- Wijzig al je wachtwoorden - we hebben traces gemaakt van de code en er gebeuren dingen met wachtwoorden
Ik sluit ook niet uit dat er een miner in zit, maar het kan ook een password bruteforce mechanisme zijn.
Bedoel je admin / root passwords of ook voor alle FTP-accounts (lees: DA users)
Bedoel je admin / root passwords of ook voor alle FTP-accounts (lees: DA users)
Admin, root, gebruikers en alle MySQL wachtwoorden
stefantriep
22/02/18, 10:17
Wij hebben het ook zien gebeuren en het is een bug in Directadmin. We hebben dit bij Directadmin gemeld en zij hebben er toen op ons verzoek een CVE van gemaakt: https://www.directadmin.com/features.php?id=2036
- Update Directadmin en of pas de genoemde workaround toe
- Check files in /usr/bin/ die met 'ch' beginnen
- Check /etc/rc.local
- Beter nog; doe een frisse installatie
- Wijzig al je wachtwoorden - we hebben traces gemaakt van de code en er gebeuren dingen met wachtwoorden
Ik sluit ook niet uit dat er een miner in zit, maar het kan ook een password bruteforce mechanisme zijn.
Gisterenavond toen de vraag kwam of er toevallig DirectAdmin draaide alle DA installaties met spoed geupdate, maar de 2 servers krijgen nog een reinstall
Wat betreft de files, als je in de dir /urs/bin een ls -la doet, valt het bestand op doordat hij rood is en in veel gevallen lijkt op een bestand wat erboven of eronder staat qua naam. Maar namen als ta / at zijn ook in gebruik.
Er zijn ook legitieme bestanden rood gekleurd, dus niet zomaar wat verwijderen ;-)
Wel zeker van je zaak zijn alvorens wat te trashen. Ook legitieme rode en niet rode lijken soms aardig op elkaar, zeker als je denkt snel snel :-)
Er zijn ook legitieme bestanden rood gekleurd, dus niet zomaar wat verwijderen ;-)
Wel zeker van je zaak zijn alvorens wat te trashen. Ook legitieme rode en niet rode lijken soms aardig op elkaar, zeker als je denkt snel snel :-)
hier was de filesize overal hetzelfde: 831584
Yourwebhoster
22/02/18, 20:58
Ik heb wat details op https://www.yourwebhoster.eu/en/2018/02/22/important-details-regarding-directadmin-cve-2017-18045-segfault/ beschreven. Aanvullingen zijn welkom (check op spelling komt nog).
Ik hoop niet dat iemand de legitieme ch* bestanden weg gaat gooien n.a.v. die post. Beter hulp inschakelen als je twijfelt.
Yourwebhoster
22/02/18, 21:50
Ik hoop niet dat iemand de legitieme ch* bestanden weg gaat gooien n.a.v. die post. Beter hulp inschakelen als je twijfelt.
Thanks, ik heb het voor de zekerheid er uit gehaald omdat ik geen verder bewijs heb of duidelijkheid over welke bestanden het exact zijn.
Als ik terug lees is dit probleem opgelost in versie 1.52
Ik heb hier een DirectAdmin met versie 1.52.1 laatste versie als ik op de website van DirectAdmin (https://www.directadmin.com/versions.php ) en volgens mij heeft DirectAdmin zichzelf geupdate om dit probleem op te lossen.
Hebben jullie standaard de update functie uitstaan?
http://forum.directadmin.com/showthread.php?t=54305
Ja, automatisch updaten is not done mij inziens. Eerst een update checken en dan pas uitrollen.
Yourwebhoster
23/02/18, 10:38
Als ik terug lees is dit probleem opgelost in versie 1.52
Ik heb hier een DirectAdmin met versie 1.52.1 laatste versie als ik op de website van DirectAdmin (https://www.directadmin.com/versions.php ) en volgens mij heeft DirectAdmin zichzelf geupdate om dit probleem op te lossen.
Hebben jullie standaard de update functie uitstaan?
http://forum.directadmin.com/showthread.php?t=54305
Automatisch updaten is sowieso een no-go. Overigens zijn er voldoende tools om het semi-automatisch te doen (denk aan Ansible, Puppet icm Foreman, etc) en toch voldoende controle te houden. Vaak komt bij software een minor update met bugfixes uit. Scheelt weer troubleshooten en stel het updaten gaat fout (Custombuild is mooi maar zeker niet foutloos) dan sta je stand-by en weet je dat een update de oorzaak kan zijn.
Overigens is de update oud en zie ik dat klanten die zelf managen veel-al oude versies draaien.
Ik hoop niet dat iemand de legitieme ch* bestanden weg gaat gooien n.a.v. die post. Beter hulp inschakelen als je twijfelt.
Dat zijn dezelfde personen die zonder probleem een fork bom in hun shell plakken. Ik heb daar niet zo moeite mee. Wie twijfelt en toch verwijderd is 1) niet capable om een live omgeving te beheren en 2) verdient bij de verkeerde keuze gewoon een lintje en een oorkonde. Ongeacht mijn post.
bofh :TLW
Dat zijn dezelfde personen die zonder probleem een fork bom in hun shell plakken. Ik heb daar niet zo moeite mee. Wie twijfelt en toch verwijderd is 1) niet capable om een live omgeving te beheren en 2) verdient bij de verkeerde keuze gewoon een lintje en een oorkonde. Ongeacht mijn post.
bofh :TLW
True, je moet weten wat je doet of hulp vragen. Dat was ook mijn strekking.
Ik heb wat details op https://www.yourwebhoster.eu/en/2018/02/22/important-details-regarding-directadmin-cve-2017-18045-segfault/ beschreven. Aanvullingen zijn welkom (check op spelling komt nog).
Aan de hand van je cpu stats kun je je window vinden waar je infectie heeft plaats gevonden.
En voor de roeptoeters die gelijk hun systemen gaan herinstallen... Wellicht dat een pakketje zoals AIDE je uit de brand helpt de volgende keer.
Yourwebhoster
23/02/18, 14:21
Aan de hand van je cpu stats kun je je window vinden waar je infectie heeft plaats gevonden.
Tsja, dan moet je dat wel bijhouden. Grote kans dat klanten die het niet updaten ook de lak aan monitoring hebben.
En voor de roeptoeters die gelijk hun systemen gaan herinstallen... Wellicht dat een pakketje zoals AIDE je uit de brand helpt de volgende keer.
AIDE kan voor een deel helpen maar dan moet je er wel actief mee aan de slag en niets geeft 100% zekerheid. Soms is het, al is het maar voor je gevoel, beter om een systeem opnieuw op te bouwen en door die zure appel heen te bijten. Alle servers staan in configuratie management, toch, toch? ;)
CPU stats zijn in dit geval trouwens niet altijd een betrouwbare manier om te constateren wanneer de infectie heeft plaats gevonden. De CPU belasting hoeft niet te starten op het moment van de hack. Dat is niet wat we zelf hebben geconstateerd in ieder geval. Je kunt beter de log files van DirectAdmin controleren. Ze komen altijd op dezelfde wijze binnen.
AIDE kan voor een deel helpen maar dan moet je er wel actief mee aan de slag en niets geeft 100% zekerheid. Soms is het, al is het maar voor je gevoel, beter om een systeem opnieuw op te bouwen en door die zure appel heen te bijten. Alle servers staan in configuratie management, toch, toch? ;)
CPU stats zijn in dit geval trouwens niet altijd een betrouwbare manier om te constateren wanneer de infectie heeft plaats gevonden. De CPU belasting hoeft niet te starten op het moment van de hack. Dat is niet wat we zelf hebben geconstateerd in ieder geval. Je kunt beter de log files van DirectAdmin controleren. Ze komen altijd op dezelfde wijze binnen.
Je zult wel gelijk hebben :)
Ik heb het op mijn servers nog niet meegemaakt maar zie hier nuttige info voor als het wel gaat gebeuren. Bedankt voor de kennisdeling!