autor SeerLight
Izgradnja bilo koje usluge nužno uključuje stalni rad na sigurnosti. Sigurnost je kontinuirani proces koji uključuje stalnu analizu i poboljšanje sigurnosti proizvoda, praćenje vijesti o ranjivostima i još mnogo toga. Uključujući revizije. Revizije provode i interni i vanjski stručnjaci, koji mogu radikalno pomoći u sigurnosti jer nisu uronjeni u projekt i otvorenog su uma.
Članak govori o ovom najjednostavnijem stajalištu vanjskih stručnjaka koji su pomogli timu Mail.ru Cloud Solutions (MCS) testirati uslugu u oblaku i o tome što su otkrili. Kao “vanjsku silu” MCS je odabrao tvrtku Digital Security, poznatu po visokoj stručnosti u krugovima informacijske sigurnosti. U ovom ćemo članku analizirati neke zanimljive ranjivosti pronađene u sklopu eksterne revizije - kako biste izbjegli iste žrtve kada kreirate vlastitu uslugu u oblaku.
Описание продукта
je platforma za izgradnju virtualne infrastrukture u oblaku. Uključuje IaaS, PaaS i tržište gotovih slika aplikacija za programere. Uzimajući u obzir MCS arhitekturu, bilo je potrebno provjeriti sigurnost proizvoda u sljedećim područjima:
- zaštita infrastrukture virtualizacijskog okruženja: hipervizori, usmjeravanje, vatrozidi;
- zaštita virtualne infrastrukture korisnika: izolacija jedna od druge, uključujući mrežu, privatne mreže u SDN-u;
- OpenStack i njegove otvorene komponente;
- S3 vlastitog dizajna;
- IAM: projekti s više stanara s uzorom;
- Vid (računalni vid): API-ji i ranjivosti pri radu sa slikama;
- web sučelje i klasični web napadi;
- ranjivosti PaaS komponenti;
- API svih komponenti.
Možda je to sve što je bitno za daljnju povijest.
Kakav je posao obavljen i zašto je bio potreban?
Sigurnosna revizija usmjerena je na prepoznavanje ranjivosti i konfiguracijskih pogrešaka koje bi mogle dovesti do curenja osobnih podataka, izmjene osjetljivih informacija ili prekida dostupnosti usluge.
Tijekom rada, koji u prosjeku traje 1-2 mjeseca, revizori ponavljaju radnje potencijalnih napadača i traže ranjivosti u klijentskim i poslužiteljskim dijelovima odabranog servisa. U kontekstu revizije MCS cloud platforme identificirani su sljedeći ciljevi:
- Analiza autentifikacije u servisu. Ranjivosti u ovoj komponenti pomogle bi da se odmah uđe u račune drugih ljudi.
- Proučavanje uzora i kontrole pristupa između različitih računa. Za napadača je mogućnost pristupa tuđem virtualnom računalu poželjan cilj.
- Ranjivosti na strani klijenta. XSS/CSRF/CRLF/itd. Je li moguće napasti druge korisnike putem zlonamjernih poveznica?
- Ranjivosti na strani poslužitelja: RCE i sve vrste injekcija (SQL/XXE/SSRF i tako dalje). Ranjive točke poslužitelja općenito je teže pronaći, ali dovode do ugrožavanja više korisnika odjednom.
- Analiza izolacije korisničkog segmenta na razini mreže. Za napadača, nedostatak izolacije uvelike povećava površinu napada protiv drugih korisnika.
- Analiza poslovne logike. Je li moguće prevariti tvrtke i besplatno kreirati virtualne strojeve?
U ovom projektu rad se odvijao prema modelu "Gray-box": revizori su komunicirali s uslugom s privilegijama običnih korisnika, ali su djelomično posjedovali izvorni kod API-ja i imali su priliku razjasniti detalje s programerima. Ovo je obično najprikladniji, au isto vrijeme i sasvim realan model rada: interne informacije još uvijek mogu prikupiti napadači, samo je pitanje vremena.
Pronađene ranjivosti
Prije nego što revizor počne slati različite korisnie terete (korisne terete koji se koriste za izvođenje napada) na nasumična mjesta, potrebno je razumjeti kako stvari funkcioniraju i koje su funkcionalnosti omogućene. Može se činiti da je ovo beskorisna vježba, jer na većini proučavanih mjesta neće biti ranjivosti. Ali samo razumijevanje strukture aplikacije i logike njezina rada omogućit će pronalaženje najsloženijih vektora napada.
Važno je pronaći mjesta koja se čine sumnjiva ili su na neki način vrlo različita od drugih. I prva opasna ranjivost je pronađena na ovaj način.
IDOR
Ranjivosti IDOR (Insecure Direct Object Reference) jedna su od najčešćih ranjivosti u poslovnoj logici, koja omogućuje jednom ili drugom pristup objektima kojima pristup zapravo nije dopušten. IDOR ranjivosti stvaraju mogućnost dobivanja informacija o korisniku različitih stupnjeva kritičnosti.
Jedna od opcija IDOR-a je izvršavanje radnji s objektima sustava (korisnici, bankovni računi, artikli u košarici) manipuliranjem pristupnih identifikatora tim objektima. To dovodi do najnepredvidljivijih posljedica. Na primjer, mogućnost zamjene računa pošiljatelja sredstava, putem koje ih možete ukrasti od drugih korisnika.
U slučaju MCS-a, revizori su upravo otkrili IDOR ranjivost povezanu s nesigurnim identifikatorima. U osobnom računu korisnika UUID identifikatori korišteni su za pristup bilo kojim objektima, koji su se činili, kako stručnjaci za sigurnost kažu, impresivno nesigurnim (to jest, zaštićeni od brutalnih napada). Ali za određene subjekte otkriveno je da se uobičajeni predvidljivi brojevi koriste za dobivanje informacija o korisnicima aplikacije. Mislim da možete pogoditi da je bilo moguće promijeniti korisnički ID za jedan, ponovno poslati zahtjev i tako dobiti informacije zaobilazeći ACL (access control list, data access rules za procese i korisnike).
Krivotvorenje zahtjeva na strani poslužitelja (SSRF)
Dobra stvar kod OpenSource proizvoda je što imaju ogroman broj foruma s detaljnim tehničkim opisima problema koji se javljaju i, ako imate sreće, opisom rješenja. Ali ovaj novčić ima i naličje: poznate ranjivosti također su detaljno opisane. Na primjer, na forumu OpenStack postoje prekrasni opisi ranjivosti и , koji iz nekog razloga nitko ne žuri popraviti.
Uobičajena funkcionalnost aplikacija je mogućnost da korisnik pošalje poveznicu na poslužitelj, na koju poslužitelj klikne (na primjer, za preuzimanje slike iz određenog izvora). Ako sigurnosni alati ne filtriraju same veze ili odgovore koje server vraća korisnicima, napadači mogu lako koristiti takvu funkcionalnost.
SSRF ranjivosti mogu uvelike pospješiti razvoj napada. Napadač može dobiti:
- ograničen pristup napadnutoj lokalnoj mreži, na primjer, samo kroz određene mrežne segmente i korištenjem određenog protokola;
- puni pristup lokalnoj mreži, ako je moguće spuštanje s aplikativne razine na transportnu razinu i, kao rezultat, upravljanje punim opterećenjem na aplikativnoj razini;
- pristup čitanju lokalnih datoteka na poslužitelju (ako je podržana shema file:///);
- i još mnogo toga.
U OpenStacku je odavno poznata SSRF ranjivost, koja je po prirodi "slijepa": kada kontaktirate poslužitelj, ne dobivate odgovor od njega, ali dobivate različite vrste pogrešaka/kašnjenja, ovisno o rezultatu zahtjeva. . Na temelju toga možete izvršiti skeniranje portova na hostovima na internoj mreži, sa svim posljedicama koje ne treba podcjenjivati. Na primjer, proizvod može imati back-office API koji je dostupan samo iz korporativne mreže. S dokumentacijom (ne zaboravite na insajdere), napadač može koristiti SSRF za pristup internim metodama. Na primjer, ako ste nekako uspjeli dobiti približan popis korisnih URL-ova, tada pomoću SSRF-a možete proći kroz njih i izvršiti zahtjev - relativno govoreći, prebaciti novac s računa na račun ili promijeniti ograničenja.
Ovo nije prvi put da je SSRF ranjivost otkrivena u OpenStacku. U prošlosti je bilo moguće preuzeti VM ISO slike s izravne veze, što je također dovodilo do sličnih posljedica. Ova značajka sada je uklonjena iz OpenStacka. Očito je zajednica ovo smatrala najjednostavnijim i najpouzdanijim rješenjem problema.
I u javno dostupno izvješće usluge HackerOne (h1), iskorištavanje SSRF-a koji više nije slijep s mogućnošću čitanja metapodataka instance dovodi do Root pristupa cijeloj Shopify infrastrukturi.
U MCS-u su SSRF ranjivosti otkrivene na dva mjesta sa sličnom funkcionalnošću, ali ih je bilo gotovo nemoguće iskoristiti zbog vatrozida i drugih zaštita. Na ovaj ili onaj način, MCS tim je ipak riješio ovaj problem, ne čekajući zajednicu.
XSS umjesto učitavanja ljuski
Unatoč stotinama napisanih studija, iz godine u godinu XSS (cross-site scripting) napad i dalje je najveći web ranjivost (ili ?).
Prijenos datoteka omiljeno je mjesto svakog istraživača sigurnosti. Često se pokaže da možete učitati proizvoljnu skriptu (asp/jsp/php) i izvršavati naredbe OS-a, u terminologiji pentestera - "učitaj ljusku". Ali popularnost takvih ranjivosti djeluje u oba smjera: pamte se i protiv njih se razvijaju lijekovi, tako da je nedavno vjerojatnost "učitavanja ljuske" ravna nuli.
Napadački tim (koji predstavlja Digital Security) je imao sreće. U redu, u MCS-u na strani poslužitelja provjeravan je sadržaj preuzetih datoteka, dopuštene su samo slike. Ali SVG je također slika. Kako SVG slike mogu biti opasne? Jer u njih možete ugraditi JavaScript isječke!
Ispostavilo se da su preuzete datoteke dostupne svim korisnicima MCS usluge, što znači da je moguće napasti i druge korisnike clouda, odnosno administratore.
Primjer XSS napada na phishing obrazac za prijavu
Primjeri iskorištavanja XSS napada:
- Zašto pokušavati ukrasti sesiju (posebno zato što su sada HTTP-Only kolačići posvuda, zaštićeni od krađe pomoću js skripti), ako učitana skripta može odmah pristupiti API-ju resursa? U ovom slučaju, korisni teret može koristiti XHR zahtjeve za promjenu konfiguracije poslužitelja, na primjer, dodavanje javnog SSH ključa napadača i dobivanje SSH pristupa poslužitelju.
- Ako CSP politika (pravila zaštite sadržaja) zabranjuje ubacivanje JavaScripta, napadač može proći i bez njega. Koristeći čisti HTML, izradite lažni obrazac za prijavu na web-mjesto i ukradite administratorsku lozinku putem ovog naprednog krađe identiteta: korisnikova stranica za krađu identiteta završava na istom URL-u, a korisniku ju je teže otkriti.
- Konačno, napadač se može dogovoriti — postavite kolačiće veće od 4 KB. Korisnik samo jednom treba otvoriti poveznicu i cijela stranica postaje nedostupna sve dok se korisnik ne dosjeti posebno očistiti preglednik: u velikoj većini slučajeva web poslužitelj će odbiti prihvatiti takvog klijenta.
Pogledajmo primjer još jednog otkrivenog XSS-a, ovaj put s pametnijim iskorištavanjem. MCS usluga vam omogućuje kombiniranje postavki vatrozida u grupe. Naziv grupe bio je mjesto gdje je otkriven XSS. Njegova je posebnost bila u tome što se vektor nije pokrenuo odmah, ne prilikom pregledavanja popisa pravila, već prilikom brisanja grupe:
Odnosno, scenarij je bio sljedeći: napadač kreira pravilo vatrozida s "load" u nazivu, administrator to primijeti nakon nekog vremena i pokrene proces brisanja. I tu radi zlonamjerni JS.
Za MCS programere, za zaštitu od XSS-a u preuzetim SVG slikama (ako se ne mogu napustiti), Digital Security tim preporučuje:
- Datoteke koje su učitali korisnici postavite na zasebnu domenu koja nema nikakve veze s domenom "kolačića". Skripta će se izvršiti u kontekstu druge domene i neće predstavljati prijetnju MCS-u.
- U HTTP odgovoru poslužitelja pošaljite zaglavlje "Content-disposition: attachment". Zatim će preglednik preuzeti datoteke i neće ih izvršiti.
Osim toga, programerima je sada na raspolaganju mnogo načina za ublažavanje rizika iskorištavanja XSS-a:
- koristeći zastavu “Samo HTTP”, možete učiniti da zaglavlja “Kolačići” sesije budu nedostupna zlonamjernom JavaScriptu;
- znatno će otežati napadaču iskorištavanje XSS-a;
- moderni predlošci kao što su Angular ili React automatski dezinficiraju korisničke podatke prije nego što ih izbace u korisnički preglednik.
Ranjivost dvofaktorske autentifikacije
Kako bi poboljšali sigurnost računa, korisnicima se uvijek savjetuje da omoguće 2FA (dvofaktorsku autentifikaciju). Doista, ovo je učinkovit način da se spriječi napadača da dobije pristup usluzi ako su korisničke vjerodajnice ugrožene.
Ali jamči li korištenje drugog faktora provjere autentičnosti uvijek sigurnost računa? Postoje sljedeći sigurnosni problemi u implementaciji 2FA:
- Brute-force pretraživanje OTP koda (jednokratni kodovi). Unatoč jednostavnosti rada, velike tvrtke također se susreću s greškama poput nedostatka zaštite od OTP grube sile: , .
- Slab algoritam generiranja, na primjer mogućnost predviđanja sljedećeg koda.
- Logičke pogreške, kao što je mogućnost traženja tuđeg OTP-a na vašem telefonu, poput ove iz Shopifyja.
U slučaju MCS-a, 2FA je implementiran na temelju Google Authenticator i . Sam protokol već je vremenski testiran, ali vrijedi provjeriti implementaciju provjere koda na strani aplikacije.
MCS 2FA se koristi na nekoliko mjesta:
- Prilikom autentifikacije korisnika. Postoji zaštita od brutalne sile: korisnik ima samo nekoliko pokušaja da unese jednokratnu lozinku, a zatim se unos neko vrijeme blokira. Ovo blokira mogućnost grubog odabira OTP-a.
- Prilikom generiranja izvanmrežnih pričuvnih kodova za izvođenje 2FA, kao i za njegovo onemogućavanje. Ovdje nije implementirana brute force zaštita, što je omogućilo, ako ste imali lozinku za račun i aktivnu sesiju, ponovno generiranje pričuvnih kodova ili potpuno onemogućavanje 2FA.
S obzirom da su se rezervni kodovi nalazili u istom rasponu string vrijednosti kao i oni koje je generirala OTP aplikacija, šansa da se kod pronađe u kratkom vremenu bila je puno veća.
Proces odabira OTP-a za onemogućavanje 2FA pomoću alata "Burp: Intruder".
Rezultirati
Općenito, MCS se čini sigurnim kao proizvod. Tijekom revizije tim za pentestiranje nije mogao dobiti pristup klijentskim VM-ovima i njihovim podacima, a pronađene ranjivosti brzo je ispravio MCS tim.
Ali ovdje je važno napomenuti da je sigurnost kontinuirani rad. Usluge nisu statične, one se stalno razvijaju. I nemoguće je razviti proizvod potpuno bez ranjivosti. Ali možete ih pronaći na vrijeme i smanjiti mogućnost njihovog ponovnog pojavljivanja.
Sada su sve navedene ranjivosti u MCS-u već popravljene. A kako bi se broj novih sveo na minimum i smanjio njihov životni vijek, tim platforme nastavlja raditi ovo:
- redovito provoditi revizije od strane vanjskih tvrtki;
- podržati i razviti sudjelovanje;
- baviti se osiguranjem. 🙂
Izvor: www.habr.com