Ebury SSH Rootkit - Operation Windigo

Dis de dimineata m-am trezit cu ceva batai de cap din cauza nenorocirii de Ebury, era prea frumos sa am parte de mintrubbing la serviciu, asa mi-am petrecut ziua plus ceva migrare de siteuri: http://www.howtodoit...sh-rootkit.html
In principiu niste baieti destepti au lucrat vreme indelungata si-au gasit metode inedite (eh, sau poate nu) de-a face viata infernala sysadminilor.
Aparent 25000 servere au fost atacate si se presupune ca 500 000 sisteme sunt afectate zilnic din aceasta cauza.
Pentru cei care n-au timp sa citeasca in totalitate articolele sau raportul tehnic facut de cei de la ESET Ebury implica obtinerea accesului de administrare asupra unui sistem si modificarea anumitor biblioteci, cel mai des intalnit caz este modificarea libkeyutils. Metoda e foarte inteligenta, nu ataca binarele, se stie ca acestea sunt monitorizate, de ex cPanel verifica checksumul acestora si primesti alerte daca s-a modificat ceva, sau cel putin mesaje de genul "Suspicious File Alert". Cine dracu s-ar gandi sa verifice bibliotecile?
Metoda simpla e reinstall si ia-o de la 0 cu sistemul, dar in cazul asta era exclus asa ca am fost nevoit s-o iau pas cu pas sa vad unde e buba si cum pot s-o pansez, sunt curios daca ati dat si voi peste Ebury si cum ati rezolvat problema sau daca aveti sugestii despre alte metode de depistare si eliminare.
Pentru mine e un mister cum mama dracu au reusit sa obtina acces la masini, pe masina fizica mai intrau si alti useri, dar la containerul OpenVZ am avut acces numai eu, clientul si cei de la sucuri.net (si pe care nu vreau sa-i suspectez c-ar fi capabili de prostii).
Mult mai interesant a fost atacul asupra nginx, iti vena sa-ti dai palme ca nu intelegeai ce mama dracu redirectioneaza si era si infernal sistemul ca nu redirectiona decat utilizatorii din US si doar 1 data/ip, stiu c-am intrat si eu nu eram redirectionat nicaieri. Am zis initial ca-i tampit clientul si are ceva virus dar cand am vazut ca vin zeci de complaints am zis ca trebuie verificat in amanunt.
In final i-am dat de cap cu un VPN din state si strace, modificasera nginx-ul, puteam lasa directorul site-ului gol complet si tot eram redirectionat, evident nu era nici un rewrite in conf, acum pare asa simplu dar mi-am batut un pic capu sa caut in mysql, in fisierele site-urilor, pana cand am ras tot site-ul si-am vazut ca tot ma trimite la dracu-n papusoi.

Huza, on 20 martie 2014 - 02:13, said:

Cateodata nu trebuie sa vrei sa faci prostii, e suficient sa ai un keylogger instalat si sa nu stii.

Ce aveai permis in exterior, din firewall? SSH-ul era public? Am vazut ca in ultimul timp s-au inmultit atacurile de bruteforce pe SSH.

SSH-ul era public, dar cel putin parola de root nu era keyword based si cam greu sa faci bruteforce la 20+ caractere random. Tot la keylogger m-am gandit si eu, mai ales ca nu cu mult timp in urma acelasi client a avut surprize cu ceva conturi personale hacked, si-a mai schimbat odata toate credentialele din cauza asta. Preventiv l-am obligat sa schimbe si toate parolele la celelalte servere, dar inainte sa-si faca un reinstall la propriul OS.

Nici nu ar trebui sa fie posibil bruteforce pe SSH... La 3 incercari gresite deja ar trebui introdus delay de 1 minut.

Nici nu era posibil pe serverele astea, problema e ca utilizatorii (in cazul asta clientul) au prostul obicei sa refoloseasca parolele sau sa le distribuie si altor persoane, evident nu pot sa stiu unde altundeva le-a mai folosit, mai ales ca nu e un client care sa aiba servicii de management la mine, altfel nu afla el vreodata parola de root, in teorie el isi administreaza serverul, dar imi trimite mie intrebarile prin ticket/email, eu ii ofer solutia, el o aplica iar la sfarsitul lunii il taxez, dar asta il face pe el sa se simta important, ca el e administratorul
Intr-o alta situatie nu stateam la discutii cu fixuri de genul asta, reinstalam OS-ul si restore din backup, evident nu-mi puneam problema cum a intrat cineva, el este chiar un caz fericit, nu odata am vazut parole stupid de simple setate chiar de profesori universitari pe super sisteme cu resurse cacalau, nu pe jucarii d-astea "micute".

Mda, asta ar putea explica valul relativ mare de ssh brute force attack vazut in ultima vreme de a trebuit sa-l rog pe baiatul de la backbone sa trimita la sf. /dev/null citeva ip-uri cind incercau sa ajunga la unul din DC-uri.

Ca regula generala PermitRootLogin no si daca se poate Port != 22.

Ca un plus de securitate, unde chiar se tine cont de asta, accesul la consola nu-i permis decat printr-un gateway anume, la care in prealabil ai acces doar prin VPN, dar cele spuse de mufa + fail2ban sunt cam primele masuri de luat in calcul. Deasemenea numele utilizatorilor sa nu fie dictionary based, pe userul gigel poti face bruteforce, in schimb pe userul bgcrnmt87f e cam greu sa gasesti userul, chiar daca parola e 123456.