🥇MCS pilveplatvormi turvaaudit

SkyShip Dusk by SeerLight

Iga teenuse loomine hõlmab vältimatult pidevat tööd turvalisuse nimel. Turvalisus on pidev protsess, mis sisaldab toote kaitse pidevat analüüsi ja parandamist, turvaaukudest teadlikkuse jälgimist ja palju muud. Nende hulka kuuluvad ka auditid. Auditit saab teostada nii sisemiste jõudude kui ka välistest ekspertidest, kes suudavad oluliselt aidata turvalisuse tagamisel, kuna nad ei ole projektiga süvitsi seotud ja näevad seda värske pilguga.

Artikkel käsitleb seda värsket pilku välistelt ekspertidelt, kes aitasid Mail.ru Cloud Solutions (MCS) meeskonnal testida nende pilveteenust, samuti seda, mida nad avastasid. „Välistena“ valis MCS ettevõtte Digital Security, mis on tuntud oma kõrge ekspertiisi poolest infosüsteemide valdkonnas. Käesolevas artiklis vaatleme mõningaid huvitavaid turvaauke, mis leiti välist auditi käigus — et te ei langeks samadesse lõksudesse, kui loote oma pilveteenust.

Toote kirjeldus

Mail.ru Cloud Solutions (MCS) — on pilvialguste virtuaalinfrastruktuuri loomise platvorm. See hõlmab IaaS-e, PaaS-e ning valmis rakenduspiltide turgu arendajatele. Arvestades MCS arhitektuuri, tuli toote turvalisust kontrollida järgmistes suundades:

virtuaalsete keskkondade infrastruktuuri kaitse: hüperviisorid, marsruutimine, tulemüürid;
klientide virtuaalse infrastruktuuri kaitse: üksteisest isoleerimine, sealhulgas võrgu, privaatsed võrgud SDN-is;
OpenStack ja selle avatud komponendid;
ise loodud S3;
IAM: multiteenuste projektid, millel on rollimudel;
Vision (masinõpe): API-d ja haavatavused piltidega töötamisel;
veebiliides ja klassikalised veebirünnakud;
PaaS-komponentide haavatavused;
kõigi komponentide API-d.

Tõenäoliselt on kõik märkimisväärne edasise loo jaoks.

Millised tööd viidi läbi ja miks need on vajalikud?

Turvaauditi eesmärk on tuvastada haavatavusi ja konfiguratsioonivigu, mis võivad viia isikuandmete lekkeni, tundliku teabe muutmiseni või teenuste saadavuse rikkumiseni.

Tööde käigus, mis kestavad keskmiselt 1-2 kuud, kordavad audiitorid potentsiaalsete ründajate samme ja otsivad nõrkusi valitud teenuse kliendi- ja serveripoolsetes osades. MCS-i pilveplatvormi auditi kontekstis on seatud järgmised eesmärgid:

Teenuse autentimise analüüs. Nõrkused selles komponendis võiksid võimaldada kohe pääseda teiste kontode juurde.
Rollimudeli ja juurdepääsu piirangute uurimine erinevate kontode vahel. Ründaja jaoks on soovitav eesmärk pääseda ligi kellegi teise virtuaalsele masinale.
Kliendipoolsete nõrkuste uurimine. XSS/CSRF/CRLF/jne. Kas on võimalus rünnata teisi kasutajaid läbi pahatahtlike linkide?
Serveripoolsete nõrkuste uurimine: RCE ja igasugused süstikud (SQL/XXE/SSRF jne). Serveri nõrkusi on tavaliselt keerulisem leida, kuid need aitavad kompromiteerida korraga mitmeid kasutajaid.
Kasutaja segmentide isolatsiooni analüüs võrgutasandil. Ründaja jaoks suurendab isolatsiooni puudumine oluliselt teiste kasutajate ründepinda.
Äripartneri loogika analüüs. Kas on võimalik petta äri ja luua virtuaalseid masinaid tasuta?

Selles projektis viidi tööd läbi 'Gray-box' mudeli alusel: auditeerijad suheldes teenusega, millega neil olid tavad kasutaja õigused, kuid osaliselt oli neil juurdepääs API algtekstidele ja võimalus arendajatelt detaile täpsustada. See on tavaliselt kõige mugavam ja samas piisavalt realistlik töömudel: siseteavet saab ikkagi kurjategija kätte, see on vaid aja küsimus.

Leitud haavatavused

Enne kui auditeerija hakkab saatma erinevaid payload'e (ründevahend, millega rünnakut viiakse läbi) juhuslikesse kohtadesse, tuleb aru saada, kuidas kõik töötab, milline funktsionaalsus on olemas. See võib tunduda kasutu tegevusena, kuna enamikes uuritud kohtades ei pruugi ühtegi haavatavust olla. Kuid ainult rakenduse struktuuri ja selle töö loogika arusaamine võimaldab leida kõige keerulisemaid rünnaku vektoreid.

Oluline on leida kohti, mis tunduvad kahtlased või mis erinevad oluliselt ülejäänud eest. Esimene ohtlik haavatavus leiti just sellisel viisil.

IDOR

IDOR-i haavatavused (Insecure Direct Object Reference, ebaturvalised otsesed viidatud objektid) on üks levinumaid haavatavusi äri loogikas, mis võimaldab mingil viisil pääseda objektidele, millele tegelikult ei ole juurdepääsu lubatud. IDOR-i haavatavused loovad võimaluse saada teavet kasutaja kohta erineva taseme kriitilisusega.

Üks IDOR-i variandi näitena on süsteemi objektidega (kasutajad, pangakontod, ostukorvi tooted) tegutsemine juurdepääsu identifikaatorite manipuleerimise kaudu. See toob kaasa täiesti ettearvamatud tagajärjed. Näiteks võib see võimaldada raha saatja konto petmist, millega saab raha teiste kasutajate käest varastada.

MCS-i puhul avastasid auditeerijad IDOR-i haavatavuse, mis on seotud ebaturvaliste identifikaatoritega. Kasutaja isiklikus kabinetis kasutati objektide juurde pääsemiseks UUID identifikaatoreid, mis näisid, nagu öeldakse, turvalised ja purustamatud. Kuid teatud üksuste puhul avastati, et rakenduse kasutajate teabe saamiseks kasutatakse tavalisi, ennustatavaid numbreid. Arvan, et võite arvata, et kasutaja ID-d oli võimalik suurendada ühe võrra, saata päring uuesti ja seega saada teavet ACL-ist mööda minnes.

Serveri külgpäringute suhtes haavatavus (SSRF)

Avaallika tooted on head, sest nendega seotud foorumites on väga palju üksikasjalikke tehnilisi kirjeldusi esinevatest probleemidest ja, kui olete õnnelik, ka lahenduse kirjeldusest. Kuid sellel mündil on ka teine pool: samuti on üksikasjalikult loetletud tuntud haavatavused. Näiteks OpenStacki foorumis on suurepärased kirjeldused haavatavustest. [XSS] ja [SSRF], mida kuidagi keegi ei tükki parandama.

Rakenduste sage funktsionaalsus on võimalus kasutajal saata serverisse link, mille kaudu server liikuda saab (näiteks, et laadida pilti määratud allikast). Kui turvameetmed linkide või serverilt kasutajatele tagastatavate vastuste filtreerimisel on ebapiisavad, saavad kurjategijad seda funktsionaalsust hõlpsasti ära kasutada.

SSRF-haavatavused võivad tunduvalt edendada rünnaku arengut. Kurjategija võib saada:

piiratud juurdepääsu rünnatavale lokaalsele võrgule, näiteks ainult teatud võrgu segmentidele ja kindlatele protokollidele;
täieliku juurdepääsu lokaalsele võrgule, kui on võimalik taanduda rakenduste tasemelt transporttasemele ning seega täielik kontroll rakendustaseme koormuse üle;
juurdepääsu lugeda lokaalseid faile serveris (kui on toetatud skeem file://).
ja palju muud.

OpenStackis on juba pikka aega tuntud SSRF-haavatavuse, millel on "pime" iseloom: serverisse pöördudes ei saa sa temalt vastust, kuid saad erinevaid vigu/viivitusi vastavalt päringu tulemusele. Selle alusel on võimalik teostada sadamate skannimist sisemistes võrkudes, mistõttu võivad tekkida tõsised tagajärjed, mida ei tohiks alahinnata. Näiteks võib tootel olla API tagaruumile, mis on saadaval ainult ettevõtte võrgus. Omades dokumentatsiooni (ärge unustage siseringlehti), saab kurjategija kasutada SSRF-i, et pöörduda sisemiste meetodite poole. Näiteks, kui õnnestub kuidagi saada ligikaudne nimekiri kasulikest URL-idest, siis saab SSRF-i abil nende kaudu minna ja päringu esitada – näiteks kanda raha arvelt arvele või muuta limiite.

See ei ole esimene juhtum SSRF-haavatavuse avastamisest OpenStackis. Varasemalt oli võimalik laadida VM-i ISO-pilte otse lingi kaudu, mis tõi samuti kaasa sarnaseid tagajärgi. Praegu on see funktsioon OpenStackist eemaldatud. Tundub, et kogukond pidas seda kõige lihtsamaks ja usaldusväärsemaks lahenduseks probleemile.

Ja selles HackerOne teenitatud avalikus aruandes (h1) ei ole enam pime SSRF, mis võimaldab instantsi metaandmete lugemist, viinud kogu Shopify infrastruktuuri juurkasutaja õiguste saamiseni.

MCS-is avastati kahes sarnaselt toimivas kohas SSRF-haavatavused, kuid neid oli praktiliselt võimatu kasutada tulemüüride ja muude kaitsete tõttu. Sellegipoolest lahendas MCS-i meeskond selle probleemi, ootamata kogukonda.

XSS mitte 'shellide' laadimise asemel

Hoolimata sadadest kirjutatud uurimistest on iga aasta XSS (kliendi-sivust scriptimise rünnak) endiselt kõige tihedamini esinev veebihäiritus (või rünnak)?).

Failide laadimine on iga turva-uuringu tegija lemmikkoht. Sageli on võimalik üles laadida suvaline skript (asp/jsp/php) ja käivitada OS-i käske, pentsestide terminoloogias 'shelli laadimine'. Kuid selliste haavatavuste populaarsus toimib ka kahe suuna vahel: neid mäletatakse ja arendatakse nende vastu kaitsevahendeid, nii et viimasel ajal on 'shelli laadimise' tõenäosus suundunud nulli.

Ründeteame (Digital Security'i näol) läks hästi. MCS-is kontrolliti serveripoolt üleslaaditavate failide sisu, lubatud olid vaid pildifailid. Kuid SVG on ka pilt. Kuidas võivad SVG pildid ohtlikud olla? Sellepärast, et neisse saab sisse embedida JavaScripti fragmente!

Selgus, et üleslaaditavad failid on kõigile MCS teenuse kasutajatele ligipääsetavad — see tähendab, et teisi pilveteenuse kasutajaid on võimalik rünnata, sealhulgas administraatoreid.

XSS-rünnaku abil sisse imbumise näide phishing'i sisselogimisvormist

XSS-rünnaku ärakasutamise näited:

Miks proovida seanssi varastada (veel enam, et praegu on igal pool HTTP-Only küpsised, mis on kaitstud js-skriptide varguse eest), kui üleslaaditud skript saab kohe API-le juurde pääseda? Sel juhul võib kasulik koormus XHR-päringute kaudu muuta serveri konfiguratsiooni, näiteks lisada ründaja avatud SSH-võtme ning saada SSH-juurdepääsu serverile.
Kui CSP-poliitika (sisu kaitse poliitika) keelab JavaScripti sisestamise, võib kuritegelik isik sellest loobuda. Puhta HTML-i abil saab luua vale sisselogimisvormi ning häkkida administraatori parooli läbi sellise arenenud kalastamise: kasutajale kuvatakse phishingu leht samal URL-il, mistõttu on kasutajal seda keerulisem avastada.
Lõpuks võib kuritegelik isik korraldada klientdoosi (DoS) — saata küpsiseid, mille suurus ületab 4 KB. Kasutajale piisab, kui avada link üks kord — ja kogu veebisait muutub kättesaamatuks, kuni ta ei arvata eraldi brauserit puhastada: enamikul juhtudel keeldub veebiserver sellise kliendi vastuvõtmisest.

Vaatame veel ühte avastatud XSS-i näidet, seekord koos nutikamate ekspluateerimisvõimetega. Teenus MCS võimaldab tulekindlate seadetega rühmade loomist. Rühma nime kohta avastati XSS. Selle eripära oli see, et vektor aktiveerus mitte kohe, mitte reeglite loendi vaatamisel, vaid rühma kustutamisel:

See, the scenario unfolds as follows: the attacker creates a firewall rule with a 'payload' in the name, the administrator notices it after a while and initiates the deletion process. And that's when the malicious JS executes.

For MCS developers, to guard against XSS in uploaded SVG images (if they cannot be avoided), the Digital Security team recommended:

Host user-uploaded files on a separate domain, not related to 'cookies'. The script will run in the context of another domain and will not pose a threat to MCS.
In the server's HTTP response, include the header 'Content-disposition: attachment'. This way, files will be downloaded by the browser instead of being executed.

Additionally, there are many ways available now for developers to mitigate the risks of XSS exploitation:

using the 'HTTP Only' flag can make session 'Cookies' headers inaccessible to malicious JavaScript;
a well-implemented CSP policy significantly complicates XSS exploitation for the attacker;
modern templating engines like Angular or React automatically sanitize user data before rendering it in the user's browser.

Kahefaasiline autentimine

Kasutajatel soovitatakse alati seadistada 2FA (kahefaasiline autentimine), et suurendada oma kontode turvalisust. See on tõhus viis, et takistada ründajal pääsemast teenusele, kui kasutaja andmed on kompromiteeritud.

Aga kas kahefaasilise autentimise kasutamine tagab alati konto turvalisuse? 2FA rakendamisel esineb mitmeid turvaprobleeme:

OTP-koodi (ühekordsete koodide) bruteforcing. Kuigi see on lihtsasti kasutatav, esinevad sellised vead, nagu bruteforce-tou tšatasuotus OTP-le, ka suurtes ettevõtetes: Slack'i juhtum, Facebook'i juhtum.
Nõrk genereerimisalgoritm, näiteks võimalus ennustada järgmist koodi.
Loogilised vead, näiteks võimalus küsida kellegi teise OTP-d oma telefonile, nagu see on oli Shopify's.

MCS-is on 2FA rakendatud Google Authenticator'i ja Duo. Protokoll ise on ajaga tõestatud, kuid koodi kontrollimise rakenduse küljes tasub üle vaadata.

MCS-is kasutatakse 2FA mitmes kohas:

Kasutaja autentimise käigus. Siin on kaitse bruteforce'i vastu: kasutajal on vaid mõned katsetused ühekordse parooli sisestamiseks, pärast mida sisestamine blokeeritakse teatud ajaks. See takistab OTP-de bruteforce'iga valimise võimalust.
Kui genereerida offline backup-koode 2FA täitmiseks või selle keelamiseks. Siin ei olnud bruteforce'i kaitset rakendatud, mis võimaldas parooli olemasolu ja kehtiva seansi korral backup-koode taasgenereerida või 2FA täielikult keelata.

Arvestades, et backup-koodid olid samas väärtuste vahemikus nagu rakenduse genereeritud OTP-d, oli koodi lühikese aja jooksul leidmise tõenäosus oluliselt kõrgem.

OTP bruteforce'i protsess 2FA keelamiseks tööriista «Burp: Intruder» abil.

Tulemus

Kokkuvõttes osutus MCS tootena turvaliseks. Auditiperioodi jooksul ei suutnud pentestide meeskond pääseda klientide virtuaalmasinatele ja nende andmetele, ning leitud haavatavused parandati kiiresti MCS meeskonna poolt.

Siiski on oluline märkida, et turvalisus on pidev töö. Teenused ei ole staatilised, need arenevad pidevalt. Tootet täiesti haavatusteta välja töötada ei ole võimalik. Kuid neid on võimalik õigeaegselt tuvastada ja uute kordumise võimalust vähendada.

Kogu eespool mainitud haavatavused MCS-is on nüüdseks parandatud. Uute haavatavuste arvu minimeerimiseks ja nende eksisteerimise aja lühendamiseks jätkab platvormi meeskond järgmiste tegevuste tegemist: