Kas iš tikrųjų yra RCE ir kodėl tai turėtų jus jaudinti
Remote Code Execution – tai skamba gąsdinančiai, ir tiesą sakant, taip ir turėtų. Įsivaizduokite, kad kažkas gali įsibrovęs į jūsų kompiuterį ar serverį vykdyti bet kokias komandas, tarsi sėdėtų prie klaviatūros. Būtent tai ir yra RCE spraga – saugumo skylė, leidžianti piktavaliams nuotoliniu būdu paleisti savo kodą jūsų sistemoje.
Skirtingai nuo kitų pažeidžiamumų, kurie galbūt leidžia tik pažiūrėti duomenis ar juos pakeisti, RCE suteikia pilną kontrolę. Užpuolikas gali įdiegti virusus, pavogti slaptažodžius, užšifruoti failus reikalaudamas išpirkos, ar net panaudoti jūsų sistemą kaip tramplyną tolimesniems išpuoliams.
Problema ta, kad tokios spragos atsiranda dažniau nei norėtume pripažinti. Kiekviena programinė įranga, kuri priima ir apdoroja išorinius duomenis – ar tai būtų web aplikacija, CMS sistema, ar net paprastas failų įkėlimo funkcionalumas – gali tapti potencialia RCE ataka. Ir kai kurios iš jų būna tikrai banalios – kartais pakanka netinkamai apdoroto vartotojo įvesties lauko.
Kaip užpuolikai išnaudoja RCE spragas praktikoje
Pažvelkime į realybę. Dažniausiai RCE atakos prasideda nuo paprasto testavimo – užpuolikas ieško vietų, kur sistema priima vartotojo duomenis. Tai gali būti paieškos laukas, kontaktų forma, failų įkėlimo funkcija ar net URL parametrai.
Klasikinis pavyzdys – nesaugus failų įkėlimas. Tarkime, turite svetainę, kur vartotojai gali įkelti profilio nuotraukas. Jei sistema netikrina, kas iš tikrųjų įkeliama, užpuolikas gali įkelti ne JPEG failą, o PHP scriptą. Kai šis failas bus pasiekiamas per naršyklę, serveris jį vykdys kaip kodą. Voila – turime RCE.
Kitas populiarus metodas – injection atakos. SQL injection jau seniai žinomas, bet egzistuoja ir command injection, code injection, LDAP injection ir daugybė kitų. Esmė ta pati: į sistemą įvedami specialūs simboliai ar komandos, kurios vėliau vykdomos serverio lygmenyje. Pavyzdžiui, jei svetainė leidžia vartotojui įvesti IP adresą „ping” komandai, o sistema tiesiog sujungia šį įvedimą su komanda nepatikrinus, užpuolikas gali įvesti: `8.8.8.8; rm -rf /` ir sukurti rimtų problemų.
Deserialization atakos taip pat yra dažnas RCE šaltinis. Kai aplikacija priima serializuotus objektus iš nepatikimų šaltinių ir juos deserializuoja be validacijos, užpuolikas gali sukurti specialų objektą, kuris vykdymo metu paleis kenkėjišką kodą. Java, Python, PHP, Ruby – visos šios kalbos turėjo rimtų deserialization problemų.
Garsiausios RCE atakos ir jų pamokos
Equifax duomenų nutekėjimas 2017 metais yra puikus pavyzdys, kaip viena RCE spraga gali sugriauti įmonės reputaciją. Apache Struts framework’e buvo rasta kritinė spraga, leidžianti vykdyti nuotolinį kodą. Nors pataisymas buvo išleistas, Equifax jį neįdiegė laiku. Rezultatas? 147 milijonų žmonių asmeniniai duomenys buvo pavogti.
Log4Shell – 2021 metų pabaigoje aptikta spraga Java logging bibliotekoje Log4j – buvo tikras košmaras. Ši biblioteka naudojama milijonuose aplikacijų visame pasaulyje. Spraga buvo tokia paprasta išnaudoti, kad pakako įterpti specialią tekstinę eilutę į bet kurį lauką, kuris buvo loginamas. Minecraft serveriai, Apple iCloud, Twitter, Amazon – visi buvo pažeidžiami. Tai parodė, kaip trečiųjų šalių bibliotekos gali tapti labiausiai pažeidžiamu tašku.
WannaCry ransomware ataka 2017 metais, nors ir ne grynai RCE pavyzdys, išnaudojo EternalBlue – NSA sukurtą exploit’ą, leidžiantį vykdyti kodą per Windows SMB protokolą. Per kelias dienas buvo užkrėsta daugiau nei 200,000 kompiuterių 150 šalių. Britanijos sveikatos sistema NHS buvo paralizuota, Renault sustabdė gamybą, FedEx patyrė rimtų sutrikimų.
Kodėl RCE spragos atsiranda ir kas už tai atsakingas
Atsakymas paprastas – žmonės. Programuotojai dirba po spaudimu, turi terminus, kartais tiesiog nežino apie saugumo geriausias praktikas arba mano, kad „mūsų sistema per maža, kad kas nors ją atakuotų”. Spoiler alert: ne.
Viena didžiausių problemų – legacy kodas. Sistemos, kurios buvo sukurtos prieš 10-15 metų, kai saugumo reikalavimai buvo kitokie. Dabar jos vis dar veikia, bet niekas nenori jų liesti, nes „jei veikia, nekeisk”. O tuo tarpu ten slypi spragų arsenalai.
Trečiųjų šalių bibliotekos ir framework’ai taip pat yra didelis rizikos faktorius. Modernus projektas gali turėti šimtus priklausomybių, ir kiekviena iš jų gali turėti savo pažeidžiamumų. Problema ta, kad dažnai net nežinome, kokias bibliotekas naudojame netiesiogiai – jos ateina kaip kitų bibliotekų priklausomybės.
Nepakankamas testavimas – dar viena akivaizdi priežastis. Security testing dažnai paliekamas paskutiniam momentui arba visai praleidžiamas. „Funkcionuoja mano kompiuteryje” – garsus programuotojų posakis, bet ar funkcionuoja saugiai?
Kaip apsisaugoti: praktiniai patarimai kūrėjams
Pirmas ir svarbiausias dalykas – validuokite VISKĄ, kas ateina iš išorės. Niekada nepasitikėkite vartotojo įvestimi. Net jei tai atrodo kaip paprastas skaičius ar el. pašto adresas. Naudokite whitelist’us vietoj blacklist’ų – apibrėžkite, kas yra leistina, o ne bandykite išvardinti, kas draudžiama.
Failų įkėlimo funkcionalumas reikalauja ypatingos atidos. Netikrinkite tik failo plėtinio – jį lengva suklastoti. Tikrinkite failo turinį, naudokite MIME type validaciją, saugokite įkeltus failus už web root direktorijos, pervadinkit juos, neleiskite tiesioginio prieigos. Ir jei įmanoma, naudokite atskirą domeną ar subdomeną įkeltiems failams.
Parametrizuotos užklausos – jūsų geriausias draugas kovojant su injection atakomis. Niekada nekonstruokite SQL užklausų tiesiog sujungdami string’us. Naudokite prepared statements ar ORM, kuris tai daro už jus. Tas pats taikytina ir OS komandom – jei tikrai reikia jas vykdyti, naudokite saugias bibliotekas, kurios tinkamai escape’ina parametrus.
Deserialization – jei galite jos išvengti, išvenkite. Jei ne, niekada nedeserializuokite duomenų iš nepatikimų šaltinių be griežtos validacijos. Naudokite saugius serializacijos formatus kaip JSON vietoj native object serialization, kur įmanoma.
Įrankiai ir metodai RCE spragų aptikimui
Automatizuoti skaneriai gali padėti rasti akivaizdžias spragas. OWASP ZAP, Burp Suite, Nessus, Acunetix – visi šie įrankiai turi RCE aptikimo galimybes. Bet nesitikėkite, kad jie ras viską. Automatizuoti įrankiai geri aptinkant žinomus pažeidžiamumų šablonus, bet praleidžia sudėtingesnius ar konteksto reikalaujančius atvejus.
Static Application Security Testing (SAST) įrankiai analizuoja jūsų kodą ieškodami potencialių problemų. SonarQube, Checkmarx, Fortify – šie įrankiai gali identifikuoti nesaugius kodo šablonus dar prieš paleidžiant aplikaciją. Integruokite juos į CI/CD pipeline’ą, kad problemos būtų aptinkamos anksti.
Dynamic Application Security Testing (DAST) testuoja veikiančią aplikaciją iš išorės, tarsi būtų užpuolikas. Tai papildo SAST, nes randa problemas, kurios pasireiškia tik runtime’e.
Penetration testing – profesionalūs ethical hackers’ai, bandantys įsilaužti į jūsų sistemą – vis dar yra auksinis standartas. Jie mąsto kaip tikri užpuolikai ir gali rasti spragas, kurių automatizuoti įrankiai niekada neaptiks. Taip, tai brangu, bet duomenų nutekėjimas kainuoja daug brangiau.
Bug bounty programos – leiskite saugumo tyrinėtojams visame pasaulyje ieškoti spragų jūsų sistemose ir mokėkite jiems už radinių ataskaitą. HackerOne, Bugcrowd – platformos, kurios tai palengvina. Daugelis didžiųjų kompanijų jau seniai tai daro.
Kas daryti, kai RCE spraga jau rasta
Pirma – nesipanikuokite, bet ir nevilkinkite. Jei spraga rasta jūsų sistemoje (ar kas nors ją pranešė), turite veikti greitai bet apgalvotai.
Įvertinkite situaciją: ar spraga jau buvo išnaudota? Patikrinkite logus, ieškokite įtartinos veiklos. Ar užpuolikai galėjo gauti prieigą prie duomenų? Ar sistema vis dar kompromituota?
Izoliuokite problemą: jei įmanoma, laikinai išjunkite pažeistą funkcionalumą. Geriau turėti neveikiančią funkciją nei saugumą kompromituojančią spragą. Jei tai neįmanoma, įdiekite laikinus workaround’us – papildomus validacijos lygius, WAF taisykles, rate limiting.
Sukurkite ir ištestuokite pataisymą: neužtenka tiesiog „užtaisyti” akivaizdžią problemą. Įsitikinkite, kad suprantate pagrindinę priežastį ir kad jūsų sprendimas tikrai veikia. Testuokite ne tik happy path, bet ir visus galimus edge case’us.
Diekite pataisymą greitai: turite incident response planą, tiesa? Jei ne, dabar geras laikas jį sukurti. Žinokite, kaip greitai galite išleisti hot fix’ą į produkciją.
Komunikuokite: jei tai viešai prieinama sistema ir spraga buvo rimta, galbūt reikės informuoti vartotojus. Būkite skaidrūs, bet neatskleidinėkite technišų detalių, kurios galėtų padėti kitiems užpuolikams.
Saugumo kultūra kaip geriausias prevencijos būdas
Technologijos ir įrankiai yra svarbūs, bet svarbiausia – tai žmonės ir kultūra. Jei jūsų organizacijoje saugumas laikomas „IT skyriaus problema” ar „kažkuo, ką padarysime vėliau”, jūs jau pralaimėjote.
Saugumo mokymai turėtų būti reguliarūs ir privalomi visiems, kas liečia kodą. Ne nuobodžios paskaitos kartą per metus, o praktiniai workshop’ai, CTF (Capture The Flag) varžybos, code review sesijos, kur aptariami realūs saugumo incidentai.
Secure coding guidelines – turėkite aiškias taisykles, kaip rašyti saugų kodą jūsų technologijų steke. Ir ne tik turėti – užtikrinti, kad visi jas žino ir laikosi. Code review procesas turėtų įtraukti saugumo aspektų tikrinimą.
Security champions programa – turėkite žmonių kiekvienoje komandoje, kurie yra labiau įsigilinę į saugumą ir gali būti pirmuoju kontaktiniu tašku saugumo klausimais. Jie nėra saugumo ekspertai, bet žino pakankamai, kad pastebėtų problemas ir žinotų, kada kreiptis pagalbos.
Threat modeling – prieš kurdami naują funkciją, pagalvokite, kaip ji galėtų būti išnaudota. Kas yra potencialūs užpuolikai? Kokie jų tikslai? Kokios atakos vektoriai? Tai padeda identifikuoti saugumo reikalavimus anksti, kai juos įgyvendinti pigiau ir paprasčiau.
Zero trust architektūra – nepasitikėkite niekuo automatiškai, net jei tai atrodo esant jūsų tinkle. Kiekviena užklausa turėtų būti autentifikuota ir autorizuota. Mažiausių privilegijų principas – suteikite tik tas teises, kurios tikrai reikalingos.
Reguliarūs atnaujinimai ir patch management – tai skamba nuobodžiai, bet būtent tai apsaugo nuo daugelio žinomų RCE spragų. Turėkite procesą, kaip greitai įdiegti saugumo pataisymus. Stebėkite CVE (Common Vulnerabilities and Exposures) duomenų bazes, prenumeruokite saugumo biuletenius dėl naudojamų technologijų.
RCE spragos niekur nedingsta – jos evoliucionuoja kartu su technologijomis. Kiekviena nauja framework’o versija, kiekviena nauja biblioteka, kiekviena nauja funkcija – tai potencialus naujas atakos vektorius. Bet tai nereiškia, kad turime gyventi nuolatinėje baimėje. Suprasdami, kaip šios spragos atsiranda, kaip jos išnaudojamos ir kaip nuo jų apsisaugoti, galime statyti saugesnes sistemas. Svarbu prisiminti, kad saugumas – tai ne vienkartinis projektas, o nuolatinis procesas. Investicija į saugumą šiandien – tai išvengtos katastrofos rytoj.
