Ručna detekcija i otklanjanje malicioznih spam skripti na Windows web poslužiteljima

Ovaj članak je više namijenjen kolegama administratorima koji rade s Windows web poslužiteljima, no i našim korisnicima VPS i dedicated servera koji administriraju web poslužitelje bazirane na Microsoft Windows platformi.

Naime, web poslužitelj može hostati od jedne do na tisuće web stranica, naravno ovisno o kapacitetu i raspoloživim resursima na serveru. Svaka web stranica je (web) aplikacija sama po sebi, pisana u nekom od programskih jezika od kojih su najčešći ASP, ASP.NET i PHP. Samim time se i web aplikacije pisane u tim jezicima često nalaze na web poslužiteljima diljem svijeta te su iste česta meta svakakvih napada. Razni su uzroci napada, no najčešći su oni zbog sigurnosnih propusta unutar same web aplikacije, propusti unutar raznih dodataka (plug-ina) koji se vežu na sam kôd aplikacije, no i zbog same nebrige korisnika koji ih održavaju – bilo da se radi o neredovitim nadogradnjama, nepoštovanjem osnovnih sigurnosnih metoda zaštite, ostavljenim standardnim setupom, ili sl. Neke od tih web aplikacija su CMS (Content Management System) sustavi: WordPress (PHP), Joomla (PHP), Drupal (PHP), DotNetNuke (ASP.NET), Umbraco (ASP.NET), Sitefinity (ASP.NET), itd.

Velika većina tih aplikacija, odnosno web stranica, naravno i one koje su potekle iz vlastitog programiranja, sadrže nekakve web forme, kontakt obrasce, i sl. putem kojih posjetitelji kontaktiraju vlasnika stranice ili tvrtku, bilo zbog proizvoda koji se nalazi na stranici, bilo zbog članstva na stranici, i sl. Zbog čega se takve kontakt forme nalaze na stranici, svatko ima svoj razlog pa neću ovdje puno nabrajati primjere, no poanta je u tome da se u većini slučajeva takav unos podataka prosljeđuje putem e-maila na e-mail adresu kome je već potrebno, no često i na e-mail adresu onoga tko popunjava kontakt formu u obliku kopije popunjenog obrasca, potvrde o slanju ispunjenog obrasca, linka na aktivaciju i sl.

Web programeri, dizajneri i korisnici web aplikacija, često u samom kôdu aplikacije ili kroz sučelje CMS-a, web forme ili kontakt obrasce povezuju sa servisom koji će isporučiti taj e-mail, ili pak web aplikacija po defaultu poziva funkciju koja poziva lokalni servis za slanje e-mailova. Kombinacija je puno, pa ću se u narednom tekstu fokusirati na taj servis kroz koji često svašta prolazi i odlazi s takvih formi i obrazaca 😉 No prije nego krenem u te vode, bitno je napomenuti da se takvi obrasci i forme ponekad ne nalaze “legalno” na nekoj vidljivoj lokaciji na web stranici i diskovnoj lokaciji web stranice, već su duboko skrivene i teško prepoznatljive u raznim oblicima, ponekad u obliku kôda u nekoj legitimnoj datoteci ili u zasebnoj datoteci. Samim tim ih je teško detektirati kojekakvim anti-malware alatima ili automatizmom.

S obzirom na to da web poslužitelji često znaju biti krcati web aplikacijama koje pak ukupno sadržavaju milijune datoteke na diskovnom prostoru, uloviti se u koštac s tim često nije lagan zadatak, već iziskuje dobro poznavanje i funkcioniranje sustava i sistemskih procesa od strane administratora, a u ovom tekstu ću vam pokušati cijeli proces olakšati i objasniti.

Servis o kojem govorim je SMTP servis i često je instaliran na samom web poslužitelju radi olakšavanja pristupa od strane web aplikacija. Naravno, nije nužno koristiti lokalni servis već aplikacija može pozivati bilo koji vanjski SMTP servis, s autentifikacijom ili bez, no sve ovisi o tome kako je sve podešeno ili dopušteno. O samom korisniku web aplikacije ovisi što će i na koji način koristiti, no naravno postoje određena pravila.

Radi “komocije” naših korisnika na većini naših web poslužitelja je omogućen lokalni SMTP servis prema kojem korisnici mogu podesiti svoje web aplikacije da šalju e-mailove s kontakt formi ili obrazaca. Servis je omogućen samo za lokalne aplikacije, dakle nipošto nije open-relay, pa prema tome samo aplikacije koje dolaze s lokalnih adresa web servera na kojem su smještene imaju dopuštenje slati putem istog. Kada govorimo o komociji, u funkciji je dovoljno zadati slanje putem “localhosta”, par osnovnih parametara oko e-mail adresa, nije potrebna autentifikacija i u principu, ako je kôd u funkciji ispravan, skripta će odaslati e-mail putem lokalnog servisa.

Banalan primjer je slanje e-maila putem ugrađene ASP komponente CDOSYS (Collaboration Data Objects) putem lokalnog servisa:

<%
Set myMail=CreateObject(“CDO.Message”)
myMail.Subject=”Slanje poruke pute CDO komponente”
myMail.From=”posiljatelj@domena.tld”
myMail.To=”primatelj@domena.tld”
myMail.TextBody=”Tijelo poruke”
myMail.Configuration.Fields.Item _
(“http://schemas.microsoft.com/cdo/configuration/sendusing”)=2
‘Ime ili IP adresa SMTP servera
myMail.Configuration.Fields.Item _
(“http://schemas.microsoft.com/cdo/configuration/smtpserver”)=”localhost”
‘Broj porta SMTP servisa
myMail.Configuration.Fields.Item _
(“http://schemas.microsoft.com/cdo/configuration/smtpserverport”)=25
myMail.Configuration.Fields.Update
myMail.Send
set myMail=nothing
%>

Možda nije najbolja praksa dopuštati “anonymous” konekcije čak niti s ograničenih lokalnih adresa, no gledamo da korištenje bude jednostavnije, pa je to iz tog razloga omogućeno.
Nažalost, ponekad se omogućavanje takve komocije obija o glavu, te se u slučaju gore spomenutih malicioznih skripti to koristi u ilegalne svrhe, odnosno te skripte znaju poslati na tisuće, ako ne i milijune spam poruka, a to svakako nije dobro.

Krenimo sada na tehnikalije. Ako maliciozne skripte ne pronađete nekakvim automatizmom sadržanim u raznim anti-malware alatima, primite se ručnog posla prije no što se preko vašeg web poslužitelja pošalje još XY spam poruka.

Recimo da je na Windows web poslužitelju instaliran (i primjereno podešen) nativno podržan SMTP servis. Radi se o Internet Information Services (IIS) SMTP servisu verzije 6 koji se na toj platformi pojavljuje od Microsoft Windows Server 2003 edicije pa sve do najnovije a to je Microsoft Windows Server 2012.

Nije nužno da se radi o native IIS SMTP servisu, moguće je koristiti i bilo koji third-party na kojem je ovo troubleshootanje možda i jednostavnije, no to u ovom primjeru nije slučaj, pa neću ulaziti u druge scenarije.

Promet koji prolazi kroz taj servis je mrežni promet pa ga samim time možemo “loviti” raznim packet anaylizer alatima poput Wiresharka ili Network Monitora. Moja osobna praksa nije instalirati third-party alate na server dok to nije nužno, jer oni znaju “opteretiti” sustav raznim svojim stvarima, pa se tako nisam odlučio ni na Wireshark ili Network Monitor na serveru, već ću promet koji prolazi kroz gore spomenuti servis loviti s malim command-line alatom težine par kilobyte-a zvanim RawCap (detalji na linku). S njime ću zapravo pakete koji prolaze kroz SMTP snimiti u PCAP datoteku koju ću kasnije na lokalnom računalu otvoriti s Wireshark-om i potom analizirati.

Sintaksa alata je vrlo jednostavna:
# RawCap <interface_nr> <target_pcap_file>
– <interface_nr> predstavlja broj mrežnog adaptera na serveru, a bitno je da je IP adresa na tom adapteru dodijeljena SMTP servisu, odnosno da je to ujedno i adresa na kojem SMTP servis “sluša” ili prihvaća dolazne konekcije

Nakon što smo “ulovili” određeni broj paketa, među kojima su vjerojatno i sporne spam poruke, “smtp_packets.pcap” prebacimo na računalo i otvorimo u Wiresharku.

Filtriramo prikaz paketa po SMTP protokolu, nađemo u nizu IMF (Internet Message format) paket, odnosno paket sa samim sadržajem poruke i vidjet ćemo “Originating-Script” (označeno zelenom bojom). Potražimo tu datoteku na diskovnom sustavu i nepovratno je uništimo 😉

Nažalost, postoje slučajevi dok se u “Originating-Script” nalazi datoteka koja je sadržana unutar stotina web aplikacija smještenih na web serveru, svaka od drugog korisnika, nešto poput “X-PHP-Originating-Script: 0:phpmailer.php“, tada se pojavljuje problem prepoznavanja koja je od tih stotinu datoteka uzrok generiranja SPAM poruka. Konkretno, ovdje spomenuta datoteka je legitimna PHP skripta sadržana u stotinama instalacija WordPress CMS-a, a njezina funkcionalnost je, zbog loše ili nikakve zaštite od strane samog korisnika, često iskorištena u ilegalne svrhe kao što je masovno spamiranje. Osnovna zaštita je korištenje CAPTCHA provjere u kontakt obrascima, no nažalost korisnici to često ne učine i tu dolazi do problema.  

To nas vodi u nadzor aktivnosti samih procesa, mreže i diskovnog sistema unutar Windows operativnog sustava pri čemu moramo upotrebljavati alate koji tome služe. Najpoznatiji alat kojim možemo provjeravati sve te aktivnosti dolazi iz Sysinternalsovog paketa, a zove se Process Monitor. Dakle, isti se primjenjuje kao nadzorni alat koji pokazuje “real-time” aktivnost datotečnog sustava, procesa i mreže.

Najprije moramo odrediti neke osnovne parametre oko kojih ovisi ispis aktivnosti operativnog sustava unutar alata, kako bismo “u šumi mogli vidjeti drvo”. Dakle, nije nam u interesu hvatati (engl. capture) svaku aktivnost jer bi smo time mogli opteretiti operativni sustav koji će u kratkom vremenu vrlo lako probati ispisati milijarde threadova u alatu, a samim time ne bi gotovo sigurno pronašli ono što nas zanima. Vidjet ćete niže na slici da je se u vrlo kratkom roku dogodilo 648 980 evenata a parametriziranjem smo ih filtrirali na svega 36.

Neke od tih parametara znamo. Dakle, znamo da tražimo datoteku “phpmailer.php”, znamo da je pokreće PHP proces i znamo da ona generira mrežni promet prema SMTP servisu.
Sukladno tome, unutar Process Monitor alata određujemo filtre. Želimo nadzirati “File System Activity” s putanjom koja u sebi sadrži “phpmailer.php” (označeno crvenom bojom), te želimo nadzirati “Network Activity” koji u sebi sadrži “smtp”, odnosno port/servis/protokol na koji se se ta mrežna aktivnost odnosi (označeno ljubičastom bojom). Također u filtar stavljamo proces koji pokreće “*.php” ekstenziju, a to je “php-cgi.exe”.

Nakon toga krećemo u capture procesa i dobivamo ovakav ispis. Vidimo koji PID (Process ID) pokreće datoteku i na kojoj je datoteka putanji (Path).

No što ako je ova aktivnost legitimna, odnosno što ako je u tom trenutku dok smo mi hvatali aktivnost baš netko popunio web obrazac ili kontakt formu želeći kupiti neki proizvod na web stranici ili pak kontaktirati agenciju za prodaju nekretnina!? To nas pak dalje vodi u pregled logova web stranice.

Naime, ukoliko u logovima sumnjive web stranice na kojoj se nalazi ranije detektirana “phpmailer.php” datoteka nalazimo veliki broj HTTP “POST” upita s različitih IP adresa u vrlo kratkim vremenskim intervalima, vrlo vjerojatno se radi o distribuiranom napadu koji uzrokuje generiranje velikog broja SPAM poruka. Većinom se radi o, npr. “kontakt.php”, “contact-us.php”, pa ili čak “index2.php” datoteci (kao u našem slučaju) koja u sebi sadrži kontakt formu ili obrazac koji opet poziva “phpmailer.php” funkcijsku datoteku.

Za takve napade postoje rješenja koja ih detektiraju, ublažuju ili potpuno uklanjaju, no to je tema za sebe pa bi ovime bi završio članak a sve ostale slučajeve i scenarije, metode detekcije i zaštite prepuštam vama na maštu 😉