tekijä SeerLight
Minkä tahansa palvelun rakentamiseen kuuluu välttämättä jatkuva turvallisuustyö. Tietoturva on jatkuva prosessi, joka sisältää jatkuvan tuoteturvallisuuden analysoinnin ja parantamisen, haavoittuvuuksista uutisten seuraamisen ja paljon muuta. Tarkastukset mukaan lukien. Auditoinnit tehdään sekä talon sisällä että ulkopuolisten asiantuntijoiden toimesta, jotka voivat merkittävästi auttaa turvallisuuteen, koska he eivät ole uppoutunut hankkeeseen ja ovat avoimia.
Artikkeli kertoo tästä yksinkertaisimmasta näkemyksestä ulkopuolisille asiantuntijoille, jotka auttoivat Mail.ru Cloud Solutions (MCS) -tiimiä testaamaan pilvipalvelua, ja siitä, mitä he löysivät. "Ulkoiseksi voimaksi" MCS valitsi Digital Security -yhtiön, joka tunnetaan korkeasta tietoturva-alan osaamisestaan. Ja tässä artikkelissa analysoimme joitain mielenkiintoisia haavoittuvuuksia, jotka on löydetty osana ulkoista auditointia - jotta vältyt samalla rakeelta, kun luot oman pilvipalvelun.
Описание продукта
on alusta virtuaalisen infrastruktuurin rakentamiseen pilvessä. Se sisältää IaaS-, PaaS- ja valmiiden sovelluskuvien markkinapaikan kehittäjille. MCS-arkkitehtuuri huomioon ottaen tuotteen turvallisuus oli tarpeen tarkistaa seuraavilla alueilla:
- virtualisointiympäristön infrastruktuurin suojaaminen: hypervisorit, reititys, palomuurit;
- asiakkaiden virtuaalisen infrastruktuurin suojaaminen: eristäminen toisistaan, mukaan lukien verkko, yksityiset verkot SDN:ssä;
- OpenStack ja sen avoimet komponentit;
- S3 oman suunnittelumme;
- IAM: usean vuokralaisen projektit roolimallilla;
- Visio (tietokonenäkö): API:t ja haavoittuvuudet kuvien käsittelyssä;
- verkkokäyttöliittymä ja klassiset verkkohyökkäykset;
- PaaS-komponenttien haavoittuvuudet;
- Kaikkien komponenttien API.
Ehkä se on kaikki, mikä on välttämätöntä tulevalle historialle.
Millaisia töitä tehtiin ja miksi sitä tarvittiin?
Tietoturvatarkastuksen tarkoituksena on tunnistaa haavoittuvuudet ja konfigurointivirheet, jotka voivat johtaa henkilötietojen vuotamiseen, arkaluonteisten tietojen muuttamiseen tai palvelun saatavuuden häiriintymiseen.
Keskimäärin 1-2 kuukautta kestävän työn aikana auditoijat toistavat mahdollisten hyökkääjien toimia ja etsivät haavoittuvuuksia valitun palvelun asiakas- ja palvelinosista. MCS-pilvialustan auditoinnin yhteydessä tunnistettiin seuraavat tavoitteet:
- Todennuksen analyysi palvelussa. Tämän komponentin haavoittuvuudet auttaisivat pääsemään välittömästi muiden ihmisten tileille.
- Roolimallin ja pääsynhallinnan tutkiminen eri tilien välillä. Hyökkääjälle mahdollisuus päästä jonkun muun virtuaalikoneeseen on toivottava tavoite.
- Asiakaspuolen haavoittuvuudet. XSS/CSRF/CRLF/jne. Onko mahdollista hyökätä muihin käyttäjiin haitallisten linkkien kautta?
- Palvelinpuolen haavoittuvuudet: RCE ja kaikenlaiset injektiot (SQL/XXE/SSRF ja niin edelleen). Palvelimen haavoittuvuuksia on yleensä vaikeampi löytää, mutta ne johtavat useiden käyttäjien vaarantumiseen kerralla.
- Käyttäjäsegmenttien eristyksen analyysi verkkotasolla. Hyökkääjälle eristäytymisen puute lisää huomattavasti hyökkäyspintaa muita käyttäjiä vastaan.
- Liiketoiminnan logiikan analyysi. Onko mahdollista huijata yrityksiä ja luoda virtuaalikoneita ilmaiseksi?
Tässä projektissa työ tehtiin "Gray-box" -mallin mukaisesti: auditoijat olivat vuorovaikutuksessa palvelun kanssa tavallisten käyttäjien oikeuksin, mutta heillä oli osittain hallussaan API:n lähdekoodi ja heillä oli mahdollisuus selvittää yksityiskohtia kehittäjien kanssa. Tämä on yleensä kätevin ja samalla varsin realistinen työmalli: hyökkääjä voi silti kerätä sisäisiä tietoja, se on vain ajan kysymys.
Haavoittuvuuksia löydetty
Ennen kuin tarkastaja alkaa lähettää erilaisia hyötykuormia (hyökkäämiseen käytetty hyötykuorma) satunnaisiin paikkoihin, on ymmärrettävä, miten asiat toimivat ja mitä toimintoja tarjotaan. Saattaa tuntua, että tämä on turha harjoitus, koska useimmissa tutkituissa paikoissa ei ole haavoittuvuuksia. Mutta vain sovelluksen rakenteen ja sen toiminnan logiikan ymmärtäminen mahdollistaa monimutkaisimpien hyökkäysvektorien löytämisen.
On tärkeää löytää paikkoja, jotka vaikuttavat epäilyttävältä tai ovat jollain tavalla hyvin erilaisia kuin muut. Ja ensimmäinen vaarallinen haavoittuvuus löydettiin tällä tavalla.
IDOR
IDOR (Insecure Direct Object Reference) haavoittuvuudet ovat yksi yleisimmistä liiketoimintalogiikan haavoittuvuuksista, joiden avulla toinen tai toinen pääsee käsiksi objekteihin, joihin pääsyä ei todellisuudessa sallita. IDOR-haavoittuvuudet luovat mahdollisuuden saada tietoa käyttäjästä, jonka kriittisyysaste vaihtelee.
Yksi IDOR-vaihtoehdoista on suorittaa toimintoja järjestelmäobjektien (käyttäjät, pankkitilit, ostoskorin kohteet) kanssa käsittelemällä näiden objektien käyttötunnisteita. Tämä johtaa kaikkein arvaamattomimpiin seurauksiin. Esimerkiksi mahdollisuus korvata varojen lähettäjän tili, jonka kautta voit varastaa ne muilta käyttäjiltä.
MCS:n tapauksessa tarkastajat löysivät juuri IDOR-haavoittuvuuden, joka liittyy suojaamattomiin tunnisteisiin. Käyttäjän henkilökohtaisella tilillä UUID-tunnisteita käytettiin pääsyyn kaikkiin objekteihin, jotka näyttivät, kuten tietoturva-asiantuntijat sanovat, vaikuttavan turvattomilta (eli suojatuilta raakoja hyökkäyksiä vastaan). Mutta tietyille kokonaisuuksille havaittiin, että säännöllisiä ennustettavia numeroita käytetään tietojen saamiseksi sovelluksen käyttäjistä. Luulen, että voit arvata, että oli mahdollista muuttaa käyttäjätunnusta yhdellä, lähettää pyyntö uudelleen ja siten saada tietoa ohittamalla ACL:n (pääsynhallintaluettelo, tietojen käyttösäännöt prosesseille ja käyttäjille).
Palvelinpuolen pyyntöväärennös (SSRF)
OpenSource-tuotteissa on se hyvä puoli, että niillä on valtava määrä foorumeja, joissa on yksityiskohtaiset tekniset kuvaukset esiin tulevista ongelmista ja, jos olet onnekas, kuvaus ratkaisusta. Mutta tällä kolikolla on kääntöpuoli: myös tunnetut haavoittuvuudet kuvataan yksityiskohtaisesti. Esimerkiksi OpenStack-foorumilla on upeita kuvauksia haavoittuvuuksista и , jota jostain syystä kenelläkään ei ole kiire korjata.
Sovellusten yleinen toiminto on käyttäjän mahdollisuus lähettää palvelimelle linkki, jota palvelin napsauttaa (esimerkiksi ladata kuvan tietystä lähteestä). Jos suojaustyökalut eivät suodata itse linkkejä tai palvelimelta käyttäjille palautettuja vastauksia, hyökkääjät voivat helposti käyttää kyseisiä toimintoja.
SSRF-haavoittuvuudet voivat edistää suuresti hyökkäyksen kehitystä. Hyökkääjä voi saada:
- rajoitettu pääsy hyökkäyksen kohteena olevaan paikallisverkkoon, esimerkiksi vain tiettyjen verkkosegmenttien kautta ja käyttämällä tiettyä protokollaa;
- täysi pääsy paikalliseen verkkoon, jos alentaminen sovellustasolta siirtotasolle on mahdollista, ja sen seurauksena täysi kuormituksen hallinta sovellustasolla;
- pääsy paikallisten tiedostojen lukemiseen palvelimella (jos tiedosto:///-mallia tuetaan);
- ja paljon muuta.
OpenStackissa on pitkään tunnettu SSRF-haavoittuvuus, joka on luonteeltaan "sokea": kun otat yhteyttä palvelimeen, et saa sieltä vastausta, vaan saat erilaisia virheitä/viiveitä pyynnön tuloksesta riippuen. . Tämän perusteella voit suorittaa porttitarkistuksen sisäisen verkon isännille kaikkine seurauksineen, joita ei pidä aliarvioida. Tuotteella voi esimerkiksi olla back-office API, joka on käytettävissä vain yritysverkosta. Dokumentaation avulla (älä unohda sisäpiiriläisiä) hyökkääjä voi käyttää SSRF:ää päästäkseen sisäisiin menetelmiin. Jos esimerkiksi sait jollakin tavalla likimääräisen luettelon hyödyllisistä URL-osoitteista, voit SSRF:n avulla käydä ne läpi ja suorittaa pyynnön - suhteellisesti sanoen siirtää rahaa tililtä tilille tai muuttaa rajoja.
Tämä ei ole ensimmäinen kerta, kun SSRF-haavoittuvuus on löydetty OpenStackista. Aiemmin VM ISO -kuvia oli mahdollista ladata suorasta linkistä, mikä johti myös vastaaviin seurauksiin. Tämä ominaisuus on nyt poistettu OpenStackista. Ilmeisesti yhteisön mielestä tämä on yksinkertaisin ja luotettavin ratkaisu ongelmaan.
Ja julkisesti saatavilla oleva raportti HackerOne-palvelusta (h1), ei enää sokean SSRF:n hyödyntäminen, jolla on mahdollisuus lukea ilmentymän metatietoja, johtaa pääkäyttöön koko Shopify-infrastruktuuriin.
MCS:ssä SSRF-haavoittuvuuksia löydettiin kahdesta paikasta, joilla oli samanlainen toiminnallisuus, mutta niitä oli lähes mahdotonta hyödyntää palomuurien ja muiden suojausten vuoksi. Tavalla tai toisella MCS-tiimi korjasi tämän ongelman joka tapauksessa, odottamatta yhteisöä.
XSS kuorien lataamisen sijaan
Huolimatta sadoista kirjoitetuista tutkimuksista, vuosi toisensa jälkeen XSS (cross-site scripting) -hyökkäys on edelleen eniten verkkohaavoittuvuus (tai ?).
Tiedostojen lataaminen on jokaisen tietoturvatutkijan suosikkipaikka. Usein käy ilmi, että voit ladata mielivaltaisen komentosarjan (asp/jsp/php) ja suorittaa käyttöjärjestelmäkomentoja, pentestereiden terminologiassa - "load shell". Mutta tällaisten haavoittuvuuksien suosio toimii molempiin suuntiin: ne muistetaan ja niitä vastaan kehitetään korjaustoimenpiteitä, joten viime aikoina "kuoren lataamisen" todennäköisyys on yleensä nolla.
Hyökkäävä joukkue (jota edustaa Digital Security) oli onnekas. OK, palvelinpuolen MCS:ssä tarkistettiin ladattujen tiedostojen sisältö, vain kuvat sallittiin. Mutta SVG on myös kuva. Kuinka SVG-kuvat voivat olla vaarallisia? Koska voit upottaa niihin JavaScript-katkelmia!
Kävi ilmi, että ladatut tiedostot ovat kaikkien MCS-palvelun käyttäjien saatavilla, mikä tarkoittaa, että on mahdollista hyökätä muihin pilvikäyttäjiin, nimittäin ylläpitäjiin.
Esimerkki XSS-hyökkäyksestä phishing-kirjautumislomakkeeseen
Esimerkkejä XSS-hyökkäysten hyödyntämisestä:
- Miksi yrittää varastaa istuntoa (varsinkin kun nyt vain HTTP-evästeet ovat kaikkialla varkailta suojattuina js-skripteillä), jos ladattu komentosarja pääsee välittömästi resurssi-API:hen? Tässä tapauksessa hyötykuorma voi käyttää XHR-pyyntöjä muuttaakseen palvelimen asetuksia, esimerkiksi lisätäkseen hyökkääjän julkisen SSH-avaimen ja saada SSH-käyttöoikeuden palvelimelle.
- Jos CSP-käytäntö (sisällönsuojauskäytäntö) kieltää JavaScriptin lisäämisen, hyökkääjä pärjää ilman sitä. Käytä puhdasta HTML:ää, luo sivustolle väärennetty kirjautumislomake ja varasta järjestelmänvalvojan salasana tämän edistyneen tietojenkalastelun avulla: käyttäjän tietojenkalastelusivu päätyy samaan URL-osoitteeseen, ja käyttäjän on vaikeampi havaita se.
- Lopulta hyökkääjä voi järjestää — aseta evästeet, jotka ovat suurempia kuin 4 kt. Käyttäjän tarvitsee avata linkki vain kerran, ja koko sivusto ei pääse käsiksi, kunnes käyttäjä harkitsee selainta erikseen: useimmissa tapauksissa web-palvelin kieltäytyy hyväksymästä tällaista asiakasta.
Katsotaanpa esimerkkiä toisesta havaitusta XSS:stä, tällä kertaa älykkäämmällä hyväksikäytöllä. MCS-palvelun avulla voit yhdistää palomuuriasetukset ryhmiin. Ryhmän nimi oli paikka, jossa XSS havaittiin. Sen erikoisuus oli, että vektori ei laukaissut heti, ei sääntöluetteloa tarkasteltaessa, vaan ryhmää poistettaessa:
Eli skenaario osoittautui seuraavaksi: hyökkääjä luo palomuurisäännön, jonka nimessä on "load", järjestelmänvalvoja huomaa sen hetken kuluttua ja käynnistää poistoprosessin. Ja tässä haitallinen JS toimii.
Jotta MCS-kehittäjät voivat suojautua XSS:ltä ladatuissa SVG-kuvissa (jos niitä ei voi jättää pois), Digital Security -tiimi suositteli:
- Sijoita käyttäjien lataamat tiedostot erilliseen verkkotunnukseen, jolla ei ole mitään tekemistä "evästeiden" kanssa. Komentosarja suoritetaan eri toimialueen yhteydessä, eikä se aiheuta uhkaa MCS:lle.
- Lähetä palvelimen HTTP-vastauksessa "Content-disposition: attachment" -otsikko. Sitten selain lataa tiedostot, eikä niitä suoriteta.
Lisäksi kehittäjille on nyt tarjolla monia tapoja vähentää XSS-hyödyntämisen riskejä:
- Käyttämällä "Vain HTTP" -lippua voit tehdä istunnon Cookies-otsikoista haitallisen JavaScriptin ulottumattomissa.
- tekee hyökkääjän XSS:n hyödyntämisestä paljon vaikeampaa;
- nykyaikaiset mallimoottorit, kuten Angular tai React, puhdistavat käyttäjätiedot automaattisesti ennen niiden tulostamista käyttäjän selaimeen.
Kaksivaiheiset todennuksen haavoittuvuudet
Tilin turvallisuuden parantamiseksi käyttäjiä kehotetaan aina ottamaan käyttöön 2FA (kaksivaiheinen todennus). Tämä on todellakin tehokas tapa estää hyökkääjää pääsemästä palveluun, jos käyttäjän tunnistetiedot ovat vaarantuneet.
Mutta takaako toisen todennustekijän käyttö aina tilin turvallisuuden? 2FA:n käyttöönotossa on seuraavat tietoturvaongelmat:
- OTP-koodin raakavoimahaku (kertakoodit). Toiminnan yksinkertaisuudesta huolimatta myös suuret yritykset kohtaavat virheitä, kuten suojan puutetta OTP:n raakaa voimaa vastaan: , .
- Heikko generointialgoritmi, esimerkiksi kyky ennustaa seuraava koodi.
- Tällaiset loogiset virheet, kuten mahdollisuus pyytää jonkun muun OTP:tä puhelimeesi Shopifysta.
MCS:n tapauksessa 2FA toteutetaan Google Authenticatorin ja . Itse protokolla on jo aikatestattu, mutta koodin varmennuksen toteutus sovelluspuolella kannattaa tarkistaa.
MCS 2FA:ta käytetään useissa paikoissa:
- Kun käyttäjä todennetaan. Raakaa voimaa vastaan on suojaus: käyttäjä yrittää vain muutaman kerran antaa kertaluonteisen salasanan, jonka jälkeen syöttö estetään hetkeksi. Tämä estää OTP:n raa'an voiman valinnan.
- Kun luodaan offline-varmuuskopiokoodeja 2FA:n suorittamiseksi, sekä sen poistaminen käytöstä. Tässä ei käytetty raa'an voiman suojausta, mikä mahdollisti tilin salasanan ja aktiivisen istunnon luomisen uudelleen tai 2FA:n poistamisen kokonaan käytöstä.
Ottaen huomioon, että varakoodit sijaitsivat samalla merkkijonoarvoalueella kuin OTP-sovelluksen luomat koodit, mahdollisuus löytää koodi lyhyessä ajassa oli paljon suurempi.
OTP:n valinta 2FA:n poistamiseksi käytöstä Burp: Intruder -työkalulla
Tulos
Kaiken kaikkiaan MCS näyttää olevan turvallinen tuotteena. Tarkastuksen aikana testaustiimi ei päässyt käsiksi asiakkaiden virtuaalikoneisiin ja niiden tietoihin, ja MCS-tiimi korjasi löydetyt haavoittuvuudet nopeasti.
Mutta tässä on tärkeää huomata, että turvallisuus on jatkuvaa työtä. Palvelut eivät ole staattisia, vaan ne kehittyvät jatkuvasti. Ja on mahdotonta kehittää tuotetta täysin ilman haavoittuvuuksia. Mutta voit löytää ne ajoissa ja minimoida niiden toistumisen mahdollisuuden.
Nyt kaikki mainitut MCS:n haavoittuvuudet on jo korjattu. Ja pitääkseen uusien määrän mahdollisimman pienenä ja lyhentääkseen niiden käyttöikää, alustatiimi jatkaa näin:
- suorittaa säännöllisesti ulkopuolisten yritysten tarkastuksia;
- tukea ja kehittää osallistumista;
- osallistua turvallisuuteen. 🙂
Lähde: will.com