Un subiect care se pare că a fost, este şi va fi de actualitate … din păcate.

Metodele şi tehnicile de atac probabil că se perfecţionează mult mai repede decât putem percepe. Oamenii din spatele lor sunt din ce în ce mai ingenioşi dar au de cele mai multe ori acelaşi scop aparent banal: faima. Am încercat de multe ori să îi înţeleg dar nu am reuşit prea mult. E clar că marea majoritate este reprezentată de skidiots dar mica minoritate e mult mai de temut decât toţi micii la un loc.

De curând am avut de a face cu un prof şi nu a fost plăcut deloc, dar a fost o lecţie învăţată.

Într-o seară mă sună un prieten că nu îi mai merge site-ul: o mini afacere de nişă dar cu o concurenţă acerbă datorită potenţialului viitor. Aşadar lupta se dă pe toate fronturile şi cu toate armele posibile. Şi iată cum din faimă se transformă totul în foloase cu caracter mercantilist.

Având în vedere că conectarea Remote prin 3389 nu funcţiona (unul din servere este găzduit într-o altă ţară) am rugat suportul tehnic de acolo să instaleze un VNC pentru conectare pe server.

Prima constatare: aproape nici un serviciu Windows nu funcţiona. Tot ceea ce depinde de RPC, Server şi Workstation precum şi celelate dependenţe între ele erau moarte. La încercarea de a porni oricare dintre ele primeam mesajul binecunoscut că serviciile de care depinde acesta nu se pot porni. Hm! Mi-a plăcut chestia mai ales că nu ştiam care dintre ele depinde de altul…Din aproape în aproape prin comparaţie mai mult cu un system curat am identificat un serviciul COM+ Event Log cu calea de executabil către C:\WINDOWS\system32\svchost.exe!

Am verificat în Event Viewer şi am văzut tristul mesaj de la sursa Windows File Protection prin care mi se transmitea că fişierele svchost.exe, lsass.exe, taskkill.exe şi tasklist.exe au fost înlocuite…Era la mintea cocoşului că sistemul fusese spart. Şi cum emfaziştii lasă urme am găsit şi câţiva Gb de filme porno nemţeşti (nu le-am vizionat [:)]… a nici după nume nu le cunoşteam[:)]) şi un Top 100 pe ani a muzicii Pop germane. Serverul era găurit din august…M-am uitat la antivirus… Nu am găsit nici măcar un loc cald unde ar fi trebuit să fie… Firewall? Nimic.

Am dat cu RootkitRevealer şi se pare că chiar lsass şi svchost erau declarate ca hidden process. Problema majoră era totuşi punerea în viaţă a sistemului. Ca să pot porni Server şi Workstation, Net Logon şi serviciile conexe trebuia să pornesc serviciul bizar. Asta datorită acelei dependinţe. Şi cum MS nu recomandă să ne băgăm prea mult nasul prin regiştri nu am făcut-o decât după ce m-am gândit o miime de secundă la asta.

În mod normal cheile HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver, lanmanworkstation şi RpcSs nu trebuie să aibă nici o dependinţă către alte servicii. Aşadar am şters valoarea DependOnService şi după repornire totul a funcţionat perfect. Cum se făcuse târziu în noapte m-am culcat liniştit pe ambele urechi că am făcut o faptă bună [:)] mai ales că descoperisem tone de fişiere şi bat-uri care-mi spuneau care fişiere şi locaţiile pe unde au fost copiate.

A doua zi totul părea să funcţioneze Ok aşa că am semnat contract de mentenanţă (prima împlinire a unui vis mai vechi). Nici bine nu s-a uscat cerneala pe contract că la ora 22 a sunat din nou telefonul: aceeaşi poveste. Numai că de data aceasta apăreau 3 noi servicii sub cu tot alte nume. Şi cum managerial vorbind trebuie să identifici o conexiune şi de unde eşti atacat am deschis consola şi la primul net m-am trezit într-o altă consolă de comand prompt. Asta chiar n-am înţeles-o: de ce mi-a modificat şi fişierele net şi net1?

Aşadar am curăţat din nou regiştri, am mai scos câteva tone de fişiere mi-am adus înapoi comenzile net care erau tot în system32 sub un alt nume şi am lansat un TCPView. Mare mi-a mai fost mirarea cânt am văzut sute de conexiuni pe 1433 din sute de locaţii. Specificul aplicaţiei Web era ca SQL Server să fie accesibil doar din local nu şi din afară. Am reactivat ICS şi am făcut filtrarea doar pe 3389, 80 şi 443.

După ce s-au mai liniştit şi aceste probleme am lansat de curiozitate şi un ProcesXP şi am avut o nouă surpriză. Am identificat două fişiere lsass.exe şi svchost.exe care nu se verificau ca fiind produse de MS. M-am uitat în system32 şi am văzut că erau într-adevăr două fişiere cu aceleaşi nume şi aceeaşi extensie, ceea ce pare puţin cam absurd. Problema era că cele două fişiere (non-MS) aveau după extensia EXE un spaţiu care la drept vorbind este destul de greu de depistat dintr-o privire injectată de ora târzie din noapte.

A mai mers o săptămână după care povestea s-a repetat la un nivel mult mai mare: 7 servicii cu nume de stai cruciş până le identifici, fişiere prin toate directoarele de pe calculator, Serv-U FTP, conexiuni din toată lumea, filme de filme şi muzică pop din nou…

Am ajuns la concluzia că o formatare mi-ar salva obrazul dar… o ultimă încercare nu strica, aşa că am pus ISA Server 2004, după o nouă curăţare manuală pentru că antivirusul era pe drum…

Paroxismul apare în momentul în care a doua zi serviciul Microsoft Firewall era Disabled! Iar singura metodă de acces pe server se putea face prin FTP pentru anonimii care doreau să descarce ceva filme pentru adulţi.
Cum se putea ca însuşi ISA să fie spart… ? Eu personal nu am auzit de aşa ceva dar se pare că mai am încă multe de învăţat. Şi totuşi întâmplător “nemaiavând loc” pe server a trebuit să intru în Terminal Service Manager unde surprinzător am găsit userul IUSR_numeserver cu statusul Active. Din câte ştiam IUSR nu are dreptul să se conecteze pe server remote, aşa că l-am deconectat rapid şi am deschis un dsa.msc şi am declarat disable IUSR_numeserver. Am ocupat şi cea de-a doua sesiune de RDP şi am verificat dacă IUSR era cumva membru la Administrators. Stupoare! Nu era! Am verificat dacă în grupul Administrators există IUSR şi era… Cum treaba mirosea de la o poştă am făcut un Find rapid în AD şi am descoperit că există într-adevăr un IUSR în plus, şi desigur avea în logon name un spaţiu la final. Cine se uită în Active Directory tot timpul în mod Advanced Features şi cine stă să verifice permanent ce useri se află în numedomeniu/System/Policies/{237BAB5B-64A3-4C1D-B8ED-D63E6E992784}? Sau cine s-ar fi aşteptat că se pot crea obiecte de tip user acolo şi mai ales atât de multe…. Implicit nimeni nu are dreptul de a crea obiecte în cheia System dar cum există un buton Security acolo, cineva se pare că s-a folosit de el.

Şi totuşi trebuia să fie nişte scripturi pentru crearea userilor respectivi pentru că nici un hacker oricât de experimentat ar fi nu credc că are răbdare să creeze manual 53 de useri!. Le-am găsit stocate adânc în nişte directoare din RECYCLER şi în System Volume Information. Lecţii de Shell pe gratis.

Problema este că în timp ce mă uitam prin minunăţiile de fişiere şi bucurându-mă de sutele de Denied connection de la ISA am constat că sistemul din biroul meu mergea din ce în ce mai greu. Am crezut că este de la atacurile pe serverul de la distanţă. În Outlook zeci de mesaje de la ISA meu: SYN attack. Şi continuau să vină e-mailuri peste e-mailuri. ISA avea la un moment dat peste 100 de IP-uri de la care primea atacuri de genul acesta. Surprinzător este că nu a murit cu toate că la un moment dat procesoarele erau peste 100% asistând neputincios şi la un Virtual Memory Low. După 45 de minute s-a oprit într-un honeypot (un server virtual pe care l-am ridicat în perioada respectivă).

Cât mai ţine povestea asta? Păi dacă am în sfârşit timp să scriu din nou înseamnă că e de bine. A trecut aproape o săptămână fără nici o schimbare, fără format, fără antivirus, cu management mulţumit, cu prima factură…

Acum ce să fac să-i mulţumesc tipului sau să dorm cu ochii pe log-uri? [8-|]