🥇Audit sigurnosti oblaka platforme MCS

SkyShip Dusk od SeerLight

Izgradnja bilo koje usluge svakako uključuje kontinuirani rad na sigurnosti. Sigurnost je neprekidan proces koji podrazumijeva stalnu analizu i unapređenje zaštite proizvoda, praćenje vijesti o ranjivostima i još mnogo toga. U to spadaju i revizije. Revizije provode kako vlastitim snagama, tako i snagama vanjskih stručnjaka koji mogu bitno pomoći u sigurnosti, jer nisu uronjeni u projekt i imaju neiskvaren pogled.

Članak je o tom neiskvarenom pogledu vanjskih stručnjaka koji su pomogli timu Mail.ru Cloud Solutions (MCS) da testiraju oblačnu uslugu, te o tome što su pronašli. Kao 'vanjske snage', MCS je odabrala tvrtku Digital Security, poznatu po svom visokom stručnom znanju u krugovima informatičke sigurnosti. U ovom članku razmotrit ćemo neke zanimljive ranjivosti koje su pronađene tijekom vanjske revizije - kako biste izbjegli iste zamke kada budete gradili svoju oblačnu uslugu.

Opis proizvoda

Mail.ru Cloud Solutions (MCS) je platforma za izgradnju virtualne infrastrukture u oblaku. Uključuje IaaS-ove, PaaS-ove, tržište gotovih slika aplikacija za developere. S obzirom na arhitekturu MCS, trebalo je provjeriti sigurnost proizvoda u sljedećim područjima:

zaštita infrastrukture okruženja virtualizacije: hipervizori, usmjeravanje, vatrozidi;
zaštita virtualne infrastrukture klijenata: izolacija jedni od drugih, uključujući mrežnu, privatne mreže u SDN;
OpenStack i njegovi otvoreni komponente;
S3 vlastite izrade;
IAM: višekorisnički projekti s modelom uloga;
Vision (strojno viđenje): API i ranjivosti prilikom rada s slikama;
web-sučelje i klasični web-napadi;
ranjivosti PaaS-komponenti;
API svih komponenti.

Vjerojatno je to sve što je bitno za daljnju priču.

Koje su aktivnosti provedene i zašto su potrebne?

Revizija sigurnosti usmjerena je na otkrivanje ranjivosti i grešaka u konfiguraciji koje mogu dovesti do curenja osobnih podataka, modifikacije osjetljivih informacija ili do kršenja dostupnosti usluga.

Tijekom radova, koji traju u prosjeku 1-2 mjeseca, auditoriji ponavljaju radnje potencijalnih napadača i traže ranjivosti u klijentskom i serverskom dijelu odabranog servisa. U kontekstu audita oblaka MCS postavljeni su sljedeći ciljevi:

Analiza autentifikacije u servisu. Ranjivosti u ovom komponentu omogućile bi pristup tuđim računima.
Istraživanje modela uloga i ograničenja pristupa među različitim računima. Za napadača, mogućnost pristupa tuđoj virtualnoj mašini je poželjna meta.
Ranjivosti klijentskog dijela. XSS/CSRF/CRLF/itd. Postoji li mogućnost napada na druge korisnike putem zlonamjernih linkova?
Ranjivosti serverskog dijela: RCE i razne injekcije (SQL/XXE/SSRF itd.). Serverske ranjivosti su obično teže pronaći, ali dovode do kompromitacije većeg broja korisnika.
Analiza izolacije korisničkih segmenata na razini mreže. Za napadača, nedostatak izolacije znatno povećava površinu napada na druge korisnike.
Analiza poslovne logike. Može li se prevariti sustav i besplatno stvarati virtualne mašine?

U ovom projektu radovi su provedeni po modelu „Gray-box”: auditoriji su surađivali s servisom s privilegijama običnih korisnika, ali su djelomično imali izvorne tekstove API-ja i mogućnost pojašnjavanja detalja s programerima. Obično je to najprikladniji, a istovremeno dovoljno realističan model rada: unutarnje informacije ipak mogu biti prikupljene od strane napadača, to je samo pitanje vremena.

Pronađene ranjivosti

Prije nego što auditor počne slati različite payloadove (korisne terete pomoću kojih se provodi napad) na slučajna mjesta, potrebno je razumjeti kako što funkcionira, koja su dostupna funkcionalnosti. Može se činiti da je to beskorisno, jer u većini proučenih mjesta neće biti ranjivosti. No, samo razumijevanje strukture aplikacije i logike njezina rada omogućit će pronalaženje najtežih vektora napada.

Važno je pronaći mjesta koja se čine sumnjivima ili se na neki način značajno razlikuju od drugih. Prva opasna ranjivost pronađena je upravo na taj način.

IDOR

IDOR ranjivosti (Insecure Direct Object Reference, nesigurne direktne reference na objekte) su jedan od najčešćih oblika ranjivosti u poslovnoj logici, koji omogućuje pristup objektima koji nisu na raspolaganju. IDOR ranjivosti stvaraju mogućnost pristupa informacijama o korisniku različitog stupnja kritičnosti.

Jedan od oblika IDOR-a je izvođenje radnji s objektima sustava (korisnicima, bankovnim računima, proizvodima u košarici) manipulacijom identifikatorima pristupa tim objektima. To može dovesti do nepredvidivih posljedica. Na primjer, može se zamijeniti račun pošiljatelja novčanih sredstava, što omogućuje krađu od drugih korisnika.

U slučaju MCS, revizori su otkrili IDOR ranjivost povezana s nesigurnim identifikatorima. U korisničkom području za pristup svim objektima korišteni su UUID identifikatori, koji su se činili, kao što kažu stručnjaci za sigurnost, impresionirajuće nepristupačnima (tj. zaštićenima od napada brute force). No, otkriveno je da za određene entitete informacije o korisnicima aplikacije koriste obične predvidljive brojeve. Mislim da možete pretpostaviti da je bilo moguće promijeniti ID korisnika za jedan, ponovo poslati upit i na taj način dobiti informacije mimo ACL (access control list, pravila pristupa podacima za procese i korisnike).

Server Side Request Forgery (SSRF)

OpenSource proizvodi su dobri jer postoje brojne forumi s detaljnim tehničkim opisima nastalih problema i, ako imate sreće, s opisima rješenja. No, s druge strane, ova medalja ima i svoju mračnu stranu: poznate ranjivosti su također temeljito opisane. Na primjer, na OpenStack forumu postoje sjajni opisi ranjivosti [XSS] i [SSRF], koje iz nekog razloga nitko ne žuri ispraviti.

Česta funkcionalnost aplikacija je mogućnost da korisnik pošalje vezu na server, na koju server prelazi (na primjer, kako bi učitao sliku iz navedenog izvora). U slučaju nedovoljne filtracije sigurnosnim sredstvima samih veza ili odgovora koje server vraća korisnicima, takvu funkcionalnost lako koriste zlonamjerni akteri.

SSRF ranjivosti mogu znatno unaprijediti razvoj napada. Napadač može dobiti:

ograničen pristup napadnutoj lokalnoj mreži, na primjer samo prema određenim segmentima mreže i određenom protokolu;
puni pristup lokalnoj mreži, ako je moguć downgrade s razine aplikacija na razinu transporta i, kao posljedica, potpuno upravljanje opterećenjem na razini aplikacija;
pristup čitanju lokalnih datoteka na poslužitelju (ako se podržava shema file://);
i još mnogo toga.

U OpenStacku je davno poznata SSRF ranjivost koja ima 'slijepo' svojstvo: prilikom pozivanja poslužitelja ne dobivate odgovor od njega, ali dobijate različite vrste grešaka/odgoda, ovisno o rezultatu zahtjeva. Na temelju toga se može izvršiti skeniranje portova na hostovima unutar mreže, sa svim posljedicama koje ne treba podcjenjivati. Na primjer, proizvod može imati API za back-office koji je dostupan samo iz korporativne mreže. Imajući dokumentaciju (ne zaboravljajući na insidere), napadač može putem SSRF pristupiti unutarnjim metodama. Na primjer, ako je na neki način uspio dobiti približan popis korisnih URL-ova, uz pomoć SSRF može se proći kroz njih i izvršiti zahtjev — uvjetno rečeno, prebaciti novac s računa na račun ili promijeniti limite.

To nije prvi slučaj otkrivanja SSRF ranjivosti u OpenStacku. U prošlosti je postojala mogućnost učitavanja ISO slika VM-a putem izravne veze, što je također dovelo do sličnih posljedica. Trenutno je ova funkcija uklonjena iz OpenStacka. Očigledno, zajednica je smatrala da je to najjednostavnije i najsigurnije rješenje problema.

A u ovom u javno dostupnom izvještaju sa servisa HackerOne (h1) eksploatacija više nije slijepa SSRF s mogućnošću čitanja metapodataka instance dovodi do stjecanja Root pristupa cijeloj infrastrukturi Shopifya.

U MCS-u su na dva mjesta slične funkcionalnosti otkrivene SSRF ranjivosti, ali ih je praktički bilo nemoguće iskoristiti zbog vatrozida i drugih zaštita. Ipak, tim MCS-a je riješio ovaj problem, ne čekajući zajednicu.

XSS umjesto učitavanja 'šellova'

Unatoč stotinama napisanih istraživanja, iz godine u godinu XSS (napad međusajtnog skriptiranja) i dalje je najčešće susrećena web ranjivost (ili napad?).

Učitavanje datoteka je omiljeno mesto za svakog istraživača sigurnosti. Često se može preneti proizvoljni skript (asp/jsp/php) i izvršiti komande operativnog sistema, što se u terminologiji pentestera naziva "upload shell". Međutim, popularnost ovih ranjivosti deluje u oba pravca: ljudi se sećaju njih i razvijaju sredstva protiv njih, tako da u poslednje vreme verovatnoća za "upload shell" teži nuli.

Napadačkom timu (u ličnosti Digital Security) je pošlo za rukom. U redu, u MCS-u se na serverskoj strani proveravala sadržina učitavanih datoteka, a dozvoljene su bile samo slike. Međutim, SVG je takođe slika. A kako SVG slike mogu biti opasne? Zato što se u njih mogu ugrađivati delovi JavaScript-a!

Ispostavilo se da su učitane datoteke dostupne svim korisnicima MCS usluge – to znači da mogu napadati druge korisnike u oblaku, posebno administratore.

Primer ugrađivanja putem XSS napada u phishing formu za prijavu

Primeri eksploatacije XSS napada:

Zašto pokušavati ukrasti sesiju (pogotovo kada svuda postoje HTTP-Only kolačići, zaštićeni od krađe putem js skripti), kada učitani skript može odmah da se obrati API-ju resursa? U tom slučaju, korisna opterećenja putem XHR zahteva mogu promeniti konfiguraciju servera, na primer, dodati otvoreni SSH ključ napadača i dobiti SSH pristup serveru.
Ako CSP politika (politika zaštite sadržaja) zabranjuje ugrađivanje JavaScript-a, napadač se može snaći bez njega. U čistom HTML-u može se napraviti lažna forma za prijavu na sajt i ukrasti lozinku administratora putem naprednog phishinga: phishing stranica za korisnika se pojavljuje na istoj URL adresi, pa je korisniku teže da je otkrije.
Konačno, napadač može napraviti klijentski DoS – postaviti kolačiće veće od 4 KB. Korisniku je dovoljno jednom otvoriti link – i cela stranica postaje nedostupna, sve dok ne shvati da treba da očisti pretraživač: u pretežno većini slučajeva, veb server će odbiti da primi takvog klijenta.

Razmotrićemo primer još jednog otkrivenog XSS-a, ovaj put sa složenijom eksploatacijom. Usluga MCS omogućava grupisanje podešavanja vatrozida. U imenu grupe pronađena je XSS. Njena karakteristika je bila u tome što vektor nije delovao odmah, ne prilikom pregleda liste pravila, već prilikom brisanja grupe:

Dakle, scenarij je bio sljedeći: napadač stvara pravilo vatrozida s 'opterećenjem' u nazivu, administrator to primijeti nakon nekog vremena i pokreće postupak brisanja. I tada zlonamjerni JS počinje djelovati.

Za zaštitu od XSS napada unutar učitanih SVG slika (ako se od njih ne može odustati), tim Digital Security preporučuje programerima MCS:

Smjestiti datoteke koje korisnici učitavaju na zasebnu domenu koja nema nikakve veze s 'kolačićima'. Skripta će se izvršavati u kontekstu druge domene i neće predstavljati prijetnju za MCS.
U HTTP odgovoru poslužitelja postaviti zaglavlje 'Content-disposition: attachment'. Tada će se datoteke preuzimati putem preglednika, a ne izvršavati.

Osim toga, sada je dostupno mnogo načina za ublažavanje rizika od XSS napada za programere:

pomoću 'HTTP Only' oznake može se učiniti da sesijski 'Cookies' zaglavlja budu nedostupni za zlonamjenski JavaScript;
ispravno implementirana CSP politika značajno otežava iskorištavanje XSS napada za napadača;
moderne biblioteke, poput Angular ili React, automatski čiste korisničke podatke prije nego što ih prikazuju u pregledniku korisnika.

Ranljivosti dvofazne autentifikacije

Kako bi se povećala sigurnost računa, korisnicima se uvijek preporučuje uključivanje 2FA (dvofazna autentifikacija). To je doista učinkovit način da se spriječi napadač u pristupu servisu ako su korisnički podaci kompromitirani.

Ali, da li uvijek korištenje drugog faktora autentifikacije jamči sigurnost računa? U implementaciji 2FA mogu se pojaviti sljedeći sigurnosni problemi:

Brutalno pogađanje OTP koda (jednokratnih kodova). Unatoč jednostavnosti iskorištavanja, ovakve greške, poput nedostatka zaštite od bruteforce napada na OTP, pojavljuju se i kod velikih tvrtki: slučaj Slacka, slučaj Facebooka.
Slab algoritam generiranja, na primjer mogućnost predviđanja sljedećeg koda.
Logičke greške, kao što je mogućnost traženja tuđeg OTP-a na svom telefonu, kao što je to je bilo u Shopifyu.

U slučaju MCS, 2FA je implementirana na osnovi Google Authenticatora i Duo. Sam protokol je već potvrđen vremenom, ali implementaciju provjere koda na strani aplikacije trebalo bi provjeriti.

U MCS-u se 2FA koristi na nekoliko mjesta:

Prilikom autentifikacije korisnika. Ovdje postoji zaštita od probijanja: korisnik ima samo nekoliko pokušaja unosa jednokratne lozinke, nakon čega je unos na određeno vrijeme blokiran. To onemogućava mogućnost probijanja OTP-a.
Prilikom generiranja offline backup-kodova za izvođenje 2FA, kao i za njegovo isključivanje. Ovdje nije implementirana zaštita od probijanja, što je omogućilo, u prisutnosti lozinke za račun i aktivne sesije, ponovno generiranje backup-kodova ili potpuno isključivanje 2FA.

S obzirom na to da su backup-kodovi bili smješteni u istom rasponu vrijednosti kao i OTP-ovi generirani putem aplikacije, šansa za proboj kodova u kratkom vremenu bila je znatno veća.

Proces probijanja OTP-a za isključivanje 2FA putem alata „Burp: Intruder“

Rezultat

Općenito, MCS kao proizvod se pokazao sigurnim. Tijekom audita, timu za pentestiranje nije uspjelo dobiti pristup korisničkim VM-ovima i njihovim podacima, a pronađene ranjivosti brzo su ispravljene od strane MCS-a.

No, važno je napomenuti da je sigurnost kontinuirani proces. Servisi nisu statični, oni se stalno razvijaju. Razviti proizvod potpuno bez ranjivosti nije moguće. Ali je moguće pravovremeno ih otkriti i minimizirati šanse za njihovo ponavljanje.

Sada su sve spomenute ranjivosti u MCS-u već ispravljene. Kako bi se smanjio broj novih i skratio vrijeme njihovog postojanja, tim platforme nastavlja raditi na tome: