autor SeerLight
Mis tahes teenuse loomine hõlmab tingimata pidevat tööd turvalisuse kallal. Turvalisus on pidev protsess, mis hõlmab pidevat tooteturbe analüüsi ja täiustamist, turvaaukude uudiste jälgimist ja palju muud. Sealhulgas auditid. Auditeid viivad läbi nii ettevõttesisesed kui ka väliseksperdid, kes saavad turvalisusele radikaalselt kaasa aidata, kuna nad ei ole projektiga süvenenud ja on avatud meelega.
Artikkel käsitleb välisekspertide kõige arusaadavamat seisukohta, kes aitasid Mail.ru pilvelahenduste (MCS) meeskonnal pilveteenust testida, ja sellest, mida nad leidsid. "Välise jõuna" valis MCS ettevõtte Digital Security, mis on tuntud oma kõrgete teadmiste poolest infoturbe valdkonnas. Ja selles artiklis analüüsime mõnda huvitavat välisauditi käigus leitud turvaauku, et vältida samasugust reha oma pilveteenuse loomisel.
Описание продукта
on platvorm virtuaalse infrastruktuuri ehitamiseks pilves. See sisaldab IaaS-i, PaaS-i ja arendajatele mõeldud valmisrakenduste piltide turgu. Võttes arvesse MCS-i arhitektuuri, oli vaja kontrollida toote ohutust järgmistes valdkondades:
- virtualiseerimiskeskkonna infrastruktuuri kaitsmine: hüperviisorid, marsruutimine, tulemüürid;
- klientide virtuaalse infrastruktuuri kaitse: üksteisest eraldamine, sealhulgas võrk, privaatvõrgud SDN-is;
- OpenStack ja selle avatud komponendid;
- Meie enda disainitud S3;
- IAM: mitme üürniku projektid koos eeskujuga;
- Visioon (arvutinägemine): API-d ja haavatavused piltidega töötamisel;
- veebiliides ja klassikalised veebirünnakud;
- PaaS-i komponentide haavatavused;
- Kõikide komponentide API.
Võib-olla on see kõik, mis on edasise ajaloo jaoks hädavajalik.
Milliseid töid tehti ja milleks seda vaja oli?
Turvaauditi eesmärk on tuvastada haavatavusi ja konfiguratsioonivigu, mis võivad viia isikuandmete lekkimiseni, tundliku teabe muutmiseni või teenuse kättesaadavuse katkemiseni.
Töö käigus, mis kestab keskmiselt 1-2 kuud, kordavad audiitorid potentsiaalsete ründajate tegevust ja otsivad haavatavusi valitud teenuse kliendi- ja serveriosades. MCS-i pilveplatvormi auditi raames tuvastati järgmised eesmärgid:
- Autentimise analüüs teenuses. Selle komponendi haavatavused aitaksid koheselt teiste inimeste kontodele pääseda.
- Eeskuju ja juurdepääsu kontrolli uurimine erinevate kontode vahel. Ründaja jaoks on ihaldusväärne eesmärk juurdepääs kellegi teise virtuaalmasinale.
- Kliendipoolsed haavatavused. XSS/CSRF/CRLF/jne. Kas pahatahtlike linkide kaudu on võimalik rünnata teisi kasutajaid?
- Serveripoolsed haavatavused: RCE ja igasugused süstid (SQL/XXE/SSRF ja nii edasi). Serveri haavatavusi on üldiselt raskem leida, kuid need viivad korraga paljude kasutajate ohtu sattumiseni.
- Kasutajasegmendi isolatsiooni analüüs võrgu tasandil. Ründaja jaoks suurendab isolatsiooni puudumine oluliselt rünnakupinda teiste kasutajate vastu.
- Äriloogika analüüs. Kas on võimalik ettevõtteid petta ja virtuaalseid masinaid tasuta luua?
Selles projektis tehti tööd “Gray-box” mudeli järgi: audiitorid suhtlesid teenusega tavakasutajate õigustega, kuid omasid osaliselt API lähtekoodi ja neil oli võimalus arendajatega üksikasju täpsustada. See on tavaliselt kõige mugavam ja samal ajal üsna realistlik töömudel: sisemist teavet saab ründaja ikkagi koguda, see on ainult aja küsimus.
Leitud haavatavused
Enne kui audiitor hakkab erinevaid kasulikke koormusi (ründe sooritamiseks kasutatud koormust) suvalistesse kohtadesse saatma, tuleb aru saada, kuidas asjad käivad ja mis funktsionaalsust pakutakse. Võib tunduda, et see on kasutu harjutus, sest enamikus uuritud kohtades pole haavatavust. Kuid ainult rakenduse struktuuri ja selle toimimise loogika mõistmine võimaldab leida kõige keerulisemaid rünnakuvektoriid.
Oluline on leida kohad, mis tunduvad kahtlased või millegi poolest teistest väga erinevad. Ja esimene ohtlik haavatavus leiti sel viisil.
IDOR
IDOR (Insecure Direct Object Reference) haavatavused on üks levinumaid turvaauke äriloogikas, mis võimaldab ühel või teisel ligi pääseda objektidele, millele ligipääs tegelikult ei ole lubatud. IDOR-i haavatavused loovad võimaluse hankida erineva kriitilisuse astmega teavet kasutaja kohta.
Üks IDOR-i valikutest on teha toiminguid süsteemiobjektidega (kasutajad, pangakontod, ostukorvis olevad kaubad), manipuleerides nende objektide juurdepääsuidentifikaatoritega. See toob kaasa kõige ettearvamatumad tagajärjed. Näiteks võimalus raha saatja kontot asendada, mille kaudu saate need teistelt kasutajatelt varastada.
MCS-i puhul avastasid audiitorid just IDOR-i haavatavuse, mis on seotud mitteturvaliste identifikaatoritega. Kasutaja isiklikul kontol kasutati UUID-identifikaatoreid, et pääseda juurde mis tahes objektidele, mis tundusid, nagu turvaeksperdid ütlevad, muljetavaldavalt ebaturvalised (st kaitstud toore jõu rünnakute eest). Kuid teatud üksuste puhul avastati, et rakenduse kasutajate kohta teabe saamiseks kasutatakse tavalisi ennustatavaid numbreid. Arvan, et võite aimata, et oli võimalik muuta kasutajatunnust ühe võrra, saata päring uuesti ja saada seeläbi teavet ACL-ist (juurdepääsu kontrolli loendist, andmetele juurdepääsu reeglitest protsessidele ja kasutajatele) mööda minnes.
Serveripoolse päringu võltsimine (SSRF)
OpenSource toodete hea külg on see, et neil on tohutult palju foorumeid, kus on üksikasjalikud tehnilised kirjeldused tekkivatest probleemidest ja hea õnne korral ka lahenduse kirjeldus. Kuid sellel mündil on ka tagakülg: üksikasjalikult kirjeldatakse ka teadaolevaid turvaauke. Näiteks on OpenStacki foorumis suurepärased haavatavuste kirjeldused и , mille parandamisega millegipärast keegi ei kiirusta.
Rakenduste levinud funktsionaalsus on kasutaja võimalus saata serverisse link, millele server klõpsab (näiteks pildi allalaadimiseks määratud allikast). Kui turvatööriistad ei filtreeri linke ise ega serverist kasutajatele tagastatavaid vastuseid, saavad ründajad seda funktsiooni hõlpsasti kasutada.
SSRF-i haavatavused võivad rünnaku arengut oluliselt edendada. Ründaja võib saada:
- piiratud juurdepääs rünnatavale kohtvõrgule, näiteks ainult teatud võrgusegmentide kaudu ja teatud protokolli kasutades;
- täielik juurdepääs kohalikule võrgule, kui on võimalik alandada rakenduse tasemelt transporditasemele, ja selle tulemusena täielik koormuse haldamine rakenduse tasemel;
- juurdepääs serveris olevate kohalike failide lugemiseks (kui skeemi file:/// toetatakse);
- jpm.
OpenStackis on ammu teada SSRF-i haavatavus, mis on oma olemuselt “pime”: serveriga ühendust võttes ei saa te sealt vastust, kuid saate olenevalt päringu tulemusest erinevat tüüpi tõrkeid/viivitusi. . Selle põhjal saate teha sisevõrgu hostide pordi skannimist koos kõigi sellest tulenevate tagajärgedega, mida ei tohiks alahinnata. Näiteks võib tootel olla back-office API, millele pääseb juurde ainult ettevõtte võrgust. Dokumentatsiooniga (ärge unustage siseringi) saab ründaja kasutada sisemiste meetodite juurdepääsuks SSRF-i. Näiteks kui teil õnnestus kuidagi hankida ligikaudne nimekiri kasulikest URL-idest, siis SSRF-i abil saate need läbi käia ja päringu täita - suhteliselt öeldes raha kontolt kontole kanda või limiite muuta.
See pole esimene kord, kui OpenStackis avastatakse SSRF-i haavatavus. Varem oli võimalik VM ISO-pilte alla laadida otselingilt, mis tõi samuti kaasa sarnased tagajärjed. See funktsioon on nüüd OpenStackist eemaldatud. Ilmselt pidas kogukond seda probleemi lihtsaimaks ja usaldusväärseimaks lahenduseks.
Ja HackerOne'i teenuse avalikult kättesaadav aruanne (h1), mitte enam pimeda SSRF-i kasutamine koos võimalusega lugeda eksemplari metaandmeid viib juurjuurdepääsuni kogu Shopify infrastruktuurile.
MCS-is avastati kahes sarnase funktsionaalsusega kohas SSRF-i haavatavused, kuid neid oli tulemüüride ja muude kaitsemeetmete tõttu peaaegu võimatu ära kasutada. Ühel või teisel viisil lahendas MCS-i meeskond selle probleemi igatahes, kogukonda ootamata.
XSS kestade laadimise asemel
Vaatamata sadadele kirjutatud uurimustele on aasta-aastalt XSS-i (saitideülene skriptimine) rünnak endiselt kõige levinum veebi haavatavus (või ?).
Failide üleslaadimine on iga turvauurija lemmikkoht. Sageli selgub, et saate laadida suvalise skripti (asp/jsp/php) ja täita OS-i käske, pentesteride terminoloogias - “load shell”. Kuid selliste haavatavuste populaarsus toimib mõlemas suunas: need jäetakse meelde ja nende vastu töötatakse välja abinõud, nii et viimasel ajal kipub "kesta laadimise" tõenäosus nulli.
Ründaval meeskonnal (mida esindas Digital Security) vedas. OK, serveripoolses MCS-is kontrolliti allalaaditud failide sisu, lubatud olid ainult pildid. Aga SVG on ka pilt. Kuidas saavad SVG-pildid ohtlikud olla? Sest saate neisse manustada JavaScripti katkendeid!
Selgus, et allalaaditud failid on kättesaadavad kõigile MCS-teenuse kasutajatele, mis tähendab, et on võimalik rünnata teisi pilve kasutajaid, nimelt administraatoreid.
Näide XSS-i rünnakust andmepüügi sisselogimisvormi vastu
Näited XSS-i rünnakute ärakasutamisest:
- Miks püüda varastada seanssi (eriti kuna praegu on kõikjal HTTP-Only küpsised, mis on kaitstud varguse eest js-skriptide abil), kui laaditud skript pääseb kohe ligi ressursi API-le? Sel juhul saab kasulik koormus kasutada XHR-i päringuid serveri konfiguratsiooni muutmiseks, näiteks lisada ründaja avalikku SSH-võtit ja saada serverile SSH-juurdepääs.
- Kui CSP-poliitika (sisukaitsepoliitika) keelab JavaScripti sisestamise, saab ründaja ilma selleta hakkama. Kasutades puhast HTML-i, looge saidile võltssisselogimisvorm ja varastage administraatori parool selle täiustatud andmepüügi kaudu: kasutaja andmepüügileht jõuab samale URL-ile ja kasutajal on seda keerulisem tuvastada.
- Lõpuks saab ründaja korraldada — määrake küpsised, mis on suuremad kui 4 KB. Kasutajal tuleb link avada vaid üks kord ja kogu sait muutub ligipääsmatuks, kuni kasutaja mõtleb brauserit spetsiaalselt puhastada: enamikul juhtudel keeldub veebiserver sellist klienti vastu võtmast.
Vaatame näidet teisest tuvastatud XSS-ist, seekord nutikama ärakasutamisega. MCS-teenus võimaldab kombineerida tulemüüri sätteid rühmadesse. Rühma nimi oli koht, kus XSS tuvastati. Selle eripära oli see, et vektorit ei käivitatud kohe, mitte reeglite loendi vaatamisel, vaid rühma kustutamisel:
St stsenaarium kujunes järgmiseks: ründaja loob tulemüürireegli, mille nimes on “load”, administraator märkab seda mõne aja pärast ja algatab kustutamisprotsessi. Ja siin töötab pahatahtlik JS.
MCS-i arendajatele, et kaitsta üleslaaditud SVG-piltide XSS-i eest (kui neid ei saa välja jätta), soovitas Digital Security meeskond:
- Asetage kasutajate üleslaaditud failid eraldi domeenile, millel pole küpsistega midagi pistmist. Skript käivitatakse teise domeeni kontekstis ja see ei ohusta MCS-i.
- Saatke serveri HTTP vastuses päis „Content-disposition: attachment”. Seejärel laadib brauser failid alla ja neid ei käivitata.
Lisaks on nüüd arendajatele saadaval palju võimalusi XSS-i ärakasutamise riskide maandamiseks:
- lipu "Ainult HTTP" abil saate muuta seansi "Cookies" päised pahatahtliku JavaScripti jaoks kättesaamatuks;
- muudab ründaja jaoks XSS-i ärakasutamise palju keerulisemaks;
- kaasaegsed mallimootorid, nagu Angular või React, desinfitseerivad kasutajaandmed automaatselt enne nende väljastamist kasutaja brauserisse.
Kahefaktorilise autentimise haavatavused
Konto turvalisuse parandamiseks soovitatakse kasutajatel alati lubada 2FA (kahefaktoriline autentimine). Tõepoolest, see on tõhus viis takistada ründajal teenusele juurdepääsu saamast, kui kasutaja mandaadid on rikutud.
Kuid kas teise autentimisteguri kasutamine tagab alati konto ohutuse? 2FA rakendamisel on järgmised turvaprobleemid:
- OTP-koodi jõhker otsing (ühekordsed koodid). Hoolimata toimimise lihtsusest kohtavad suured ettevõtted ka selliseid vigu nagu kaitse puudumine OTP toore jõu eest: , .
- Nõrk genereerimisalgoritm, näiteks võime ennustada järgmist koodi.
- Sellised loogikavead, nagu võimalus taotleda oma telefonis kellegi teise ühekordset protokolli Shopifyst.
MCS-i puhul rakendatakse 2FA-d Google Authenticatori ja . Protokoll ise on juba ajaliselt testitud, kuid koodi kinnitamise rakendamine rakenduse poolel on kontrollimist väärt.
MCS 2FA-d kasutatakse mitmes kohas:
- Kasutaja autentimisel. Toore jõu eest on kaitse olemas: kasutajal on vaid paar katset ühekordset parooli sisestada, seejärel on sisend mõneks ajaks blokeeritud. See blokeerib OTP toore jõuga valimise võimaluse.
- Võrguühenduseta varukoodide genereerimisel 2FA teostamiseks, samuti selle keelamisel. Siin ei rakendatud julma jõu kaitset, mis võimaldas konto parooli ja aktiivse seansi olemasolul varukoodid uuesti luua või 2FA täielikult keelata.
Arvestades, et varukoodid asusid samas stringiväärtuste vahemikus kui OTP-rakenduse genereeritud, oli võimalus koodi lühikese aja jooksul leida palju suurem.
OTP valimine 2FA keelamiseks, kasutades tööriista „Burp: Intruder”.
Tulemus
Üldiselt näib MCS tootena olevat ohutu. Auditi käigus ei õnnestunud eeltestimismeeskonnal pääseda ligi klientide VM-idele ja nende andmetele ning leitud haavatavused parandas MCS-i meeskond kiiresti.
Kuid siin on oluline märkida, et turvalisus on pidev töö. Teenused ei ole staatilised, vaid arenevad pidevalt. Ja toodet on võimatu täielikult ilma haavatavuseta välja töötada. Kuid saate need õigeaegselt leida ja minimeerida nende kordumise võimalust.
Nüüd on kõik mainitud haavatavused MCS-is juba parandatud. Ja selleks, et hoida uute arvu miinimumini ja lühendada nende eluiga, jätkab platvormi meeskond seda:
- regulaarselt läbi viia auditeid välisettevõtete poolt;
- osalemist toetada ja arendada;
- turvalisusega tegelema. 🙂
Allikas: www.habr.com