od SeerLight
Izgradnja bilo koje usluge nužno uključuje stalan rad na sigurnosti. Sigurnost je kontinuirani proces koji uključuje stalnu analizu i poboljšanje sigurnosti proizvoda, praćenje vijesti o ranjivosti 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 projekat i imaju otvoren um.
Članak govori o ovom najjednostavnijem pogledu vanjskih stručnjaka koji su pomogli timu Mail.ru Cloud Solutions (MCS) da testira uslugu u oblaku i o tome šta su otkrili. Kao „spoljnu silu“, MCS je odabrao kompaniju Digital Security, poznatu po visokoj stručnosti u krugovima informacione bezbednosti. I u ovom članku ćemo analizirati neke zanimljive propuste pronađene u sklopu eksterne revizije - tako da izbjegnete istu grabu kada kreirate vlastiti cloud servis.
Описание продукта
je platforma za izgradnju virtuelne 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 virtuelizacionog okruženja: hipervizori, rutiranje, zaštitni zidovi;
- zaštita virtuelne infrastrukture korisnika: izolacija jedne od drugih, uključujući mrežu, privatne mreže u SDN-u;
- OpenStack i njegove otvorene komponente;
- S3 našeg vlastitog dizajna;
- IAM: projekti sa više zakupaca sa uzorom;
- Vizija (računarska vizija): 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 dalju istoriju.
Kakav je posao obavljen i zašto je bio potreban?
Sigurnosna revizija ima za cilj identifikovanje ranjivosti i grešaka u konfiguraciji koje bi mogle dovesti do curenja ličnih podataka, modifikacije osjetljivih informacija ili poremećaja dostupnosti usluge.
Tokom rada, koji u prosjeku traje 1-2 mjeseca, revizori ponavljaju radnje potencijalnih napadača i traže propuste u klijentskim i serverskim dijelovima odabranog servisa. U kontekstu revizije MCS cloud platforme, identifikovani su sljedeći ciljevi:
- Analiza autentifikacije u servisu. Ranjivosti u ovoj komponenti bi pomogle da se odmah uđe na tuđe račune.
- Proučavanje uzora i kontrole pristupa između različitih naloga. Za napadača, mogućnost da dobije pristup tuđoj virtuelnoj mašini je poželjan cilj.
- Ranjivosti na strani klijenta. XSS/CSRF/CRLF/itd. Da li je moguće napasti druge korisnike putem zlonamjernih veza?
- Ranjivosti na strani servera: RCE i sve vrste injekcija (SQL/XXE/SSRF i tako dalje). Ranjivosti servera generalno je teže pronaći, ali one dovode do kompromitovanja velikog broja korisnika odjednom.
- Analiza izolacije segmenta korisnika na nivou mreže. Za napadača, nedostatak izolacije uvelike povećava površinu napada na druge korisnike.
- Analiza poslovne logike. Da li je moguće prevariti preduzeća i besplatno kreirati virtuelne mašine?
U ovom projektu se radilo po modelu “Gray-box”: revizori su komunicirali sa uslugom uz privilegije običnih korisnika, ali su djelimično posjedovali izvorni kod API-ja i imali su priliku da razjasne detalje sa programerima. Ovo je obično najpogodniji, a ujedno i prilično realan model rada: interne informacije napadač još uvijek može prikupiti, samo je pitanje vremena.
Pronađene ranjivosti
Prije nego što revizor počne slati različite korisne podatke (korisni teret koji se koristi za izvođenje napada) na nasumična mjesta, potrebno je razumjeti kako stvari funkcioniraju i koja je funkcionalnost pružena. 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 njenog rada omogućit će pronalaženje najsloženijih vektora napada.
Važno je pronaći mjesta koja izgledaju sumnjivo ili se na neki način veoma razlikuju od drugih. I na ovaj način je pronađena prva opasna ranjivost.
IDOR
IDOR (Insecure Direct Object Reference) ranjivosti su jedna od najčešćih ranjivosti u poslovnoj logici, koja omogućava jednom ili drugom pristup objektima kojima pristup zapravo nije dozvoljen. IDOR ranjivosti stvaraju mogućnost dobijanja informacija o korisniku različitog stepena kritičnosti.
Jedna od opcija IDOR-a je izvođenje radnji sa sistemskim objektima (korisnici, bankovni računi, artikli u korpi) manipuliranjem identifikatorima pristupa ovim objektima. To dovodi do najnepredvidivijih posljedica. Na primjer, mogućnost zamjene računa pošiljaoca sredstava, preko kojeg ih možete ukrasti od drugih korisnika.
U slučaju MCS-a, revizori su upravo otkrili IDOR ranjivost povezanu sa nebezbednim identifikatorima. U ličnom računu korisnika, UUID identifikatori su korišteni za pristup svim objektima, koji su se činili, kako stručnjaci za sigurnost kažu, impresivno nesigurni (odnosno zaštićeni od napada grube sile). Ali za određene entitete je otkriveno da se uobičajeni predvidljivi brojevi koriste za dobijanje informacija o korisnicima aplikacije. Mislim da možete pretpostaviti da je bilo moguće promijeniti korisnički ID za jedan, poslati zahtjev ponovo i tako dobiti informacije zaobilazeći ACL (lista kontrole pristupa, pravila pristupa podacima za procese i korisnike).
Krivotvorenje zahtjeva na strani servera (SSRF)
Dobra stvar kod OpenSource proizvoda je što imaju ogroman broj foruma sa detaljnim tehničkim opisima problema koji se javljaju i, ako imate sreće, opisom rješenja. Ali ovaj novčić ima i drugu stranu: poznate ranjivosti su također detaljno opisane. Na primjer, postoje prekrasni opisi ranjivosti na OpenStack forumu и , koji iz nekog razloga nikome ne žuri da popravi.
Uobičajena funkcionalnost aplikacija je mogućnost da korisnik pošalje link na server, na koji server klikne (na primjer, da preuzme sliku sa određenog izvora). Ako sigurnosni alati ne filtriraju same veze ili odgovore koje server vraća korisnicima, takvu funkcionalnost mogu lako koristiti napadači.
SSRF ranjivosti mogu uvelike unaprijediti razvoj napada. Napadač može dobiti:
- ograničen pristup napadnutoj lokalnoj mreži, na primjer, samo kroz određene segmente mreže i korištenjem određenog protokola;
- pun pristup lokalnoj mreži, ako je moguće spuštanje sa nivoa aplikacije na nivo transporta i, kao rezultat, potpuno upravljanje opterećenjem na nivou aplikacije;
- pristup čitanju lokalnih datoteka na serveru (ako je podržana shema file:///);
- i još mnogo toga.
SSRF ranjivost je odavno poznata u OpenStack-u, koja je “slijepe” po prirodi: kada kontaktirate server, ne dobijate odgovor od njega, ali dobijate različite vrste grešaka/kašnjenja, ovisno o rezultatu zahtjeva. . Na osnovu toga možete izvršiti skeniranje portova na hostovima na internoj mreži, sa svim posljedicama koje iz toga proizlaze koje ne treba potcijeniti. Na primjer, proizvod može imati back-office API koji je dostupan samo iz korporativne mreže. Uz dokumentaciju (ne zaboravite na insajdere), napadač može koristiti SSRF za pristup internim metodama. Na primjer, ako ste nekako uspjeli da dobijete približnu listu korisnih URL-ova, onda pomoću SSRF-a možete proći kroz njih i izvršiti zahtjev - relativno govoreći, prebaciti novac sa računa na račun ili promijeniti limite.
Ovo nije prvi put da je SSRF ranjivost otkrivena u OpenStack-u. U prošlosti je bilo moguće preuzeti VM ISO slike sa direktne veze, što je takođe dovelo do sličnih posledica. Ova funkcija je sada uklonjena iz OpenStack-a. Očigledno, zajednica je ovo smatrala najjednostavnijim i najpouzdanijim rješenjem problema.
I unutra javno dostupan izvještaj sa usluge HackerOne (h1), eksploatacija više ne slijepog SSRF-a sa mogućnošću čitanja metapodataka instance dovodi do Root pristupa cijeloj Shopify infrastrukturi.
U MCS-u, SSRF ranjivosti su otkrivene na dva mjesta sa sličnom funkcionalnošću, ali ih je bilo gotovo nemoguće iskoristiti zbog zaštitnih zidova 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 školjki
Uprkos stotinama napisanih studija, iz godine u godinu XSS (cross-site scripting) napadi su i dalje najveći web ranjivost (ili ?).
Otpremanje datoteka je omiljeno mjesto za svakog istraživača sigurnosti. Često se ispostavi da možete učitati proizvoljnu skriptu (asp/jsp/php) i izvršiti naredbe OS-a, u terminologiji pentestera - "učitavanje ljuske". Ali popularnost takvih ranjivosti djeluje u oba smjera: oni se pamte i razvijaju se lijekovi protiv njih, tako da je u posljednje vrijeme vjerovatnoća „učitavanja ljuske“ teži nuli.
Napadački tim (koji je predstavljao Digital Security) imao je sreće. OK, u MCS-u na strani servera je provjeren sadržaj preuzetih datoteka, dozvoljene su samo slike. Ali SVG je takođe slika. Kako SVG slike mogu biti opasne? Zato što u njih možete ugraditi JavaScript isječke!
Ispostavilo se da su preuzeti fajlovi dostupni svim korisnicima MCS servisa, što znači da je moguć napad na druge korisnike oblaka, odnosno administratore.
Primjer XSS napada na phishing obrazac za prijavu
Primjeri eksploatacije XSS napada:
- Zašto pokušavati ukrasti sesiju (posebno jer su sada kolačići samo za HTTP svuda, 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, teret može koristiti XHR zahtjeve za promjenu konfiguracije servera, na primjer, dodati napadačev javni SSH ključ i dobiti SSH pristup serveru.
- Ako CSP politika (politika zaštite sadržaja) zabranjuje ubacivanje JavaScripta, napadač može proći i bez njega. Koristeći čisti HTML, kreirajte lažni obrazac za prijavu na web lokaciju i ukradite lozinku administratora putem ovog naprednog phishinga: stranica za krađu identiteta za korisnika završava na istom URL-u i korisniku je teže da je otkrije.
- Konačno, napadač se može dogovoriti — postavite kolačiće veće od 4 KB. Korisnik treba samo jednom otvoriti link, a cijela stranica postaje nedostupna sve dok korisnik ne pomisli da posebno očisti pretraživač: u velikoj većini slučajeva, web server će odbiti prihvatiti takvog klijenta.
Pogledajmo primjer još jednog otkrivenog XSS-a, ovog puta s pametnijim eksploatacijom. MCS usluga vam omogućava da kombinujete postavke zaštitnog zida u grupe. Naziv grupe je bio mjesto gdje je XSS otkriven. Njegova posebnost bila je u tome što se vektor nije aktivirao odmah, ne prilikom pregleda liste pravila, već prilikom brisanja grupe:
Odnosno, ispostavilo se da je scenario sledeći: napadač kreira pravilo firewall-a sa "učitavanjem" u imenu, administrator to primeti nakon nekog vremena i pokreće proces brisanja. I tu radi zlonamjerni JS.
Za MCS programere, radi zaštite od XSS-a u preuzetim SVG slikama (ako se ne mogu napustiti), tim za digitalnu sigurnost je preporučio:
- Postavite fajlove koje su korisnici postavili na zasebnu domenu koja nema nikakve veze sa „kolačićima“. Skripta će se izvršiti u kontekstu drugog domena i neće predstavljati prijetnju za MCS.
- U HTTP odgovoru servera pošaljite zaglavlje "Content-disposition: attachment". Zatim će datoteke biti preuzete od strane pretraživača i neće biti izvršene.
Osim toga, programerima je sada na raspolaganju mnogo načina za ublažavanje rizika od eksploatacije XSS-a:
- koristeći oznaku „Samo HTTP“, možete učiniti zaglavlja „kolačića“ sesije nedostupnim zlonamernom JavaScriptu;
- će otežati napadaču da iskoristi XSS;
- moderni predlošci kao što su Angular ili React automatski saniraju korisničke podatke prije nego što ih iznesu u korisnikov pretraživač.
Ranjivosti dvofaktorske autentifikacije
Kako bi poboljšali sigurnost naloga, korisnicima se uvijek savjetuje da omoguće 2FA (dvofaktorska autentikacija). Zaista, ovo je efikasan način da se spriječi napadač da dobije pristup servisu ako su akreditivi korisnika kompromitovani.
Ali da li korištenje drugog faktora autentifikacije uvijek garantuje sigurnost računa? Postoje sljedeća sigurnosna pitanja u implementaciji 2FA:
- Brute force pretraga OTP koda (jednokratni kodovi). Uprkos jednostavnosti rada, velike kompanije nailaze i na greške kao što je nedostatak zaštite od OTP grube sile: , .
- Slab algoritam generiranja, na primjer sposobnost predviđanja sljedećeg koda.
- Logičke greške, kao što je mogućnost da zatražite tuđi OTP na svom telefonu, poput ove od Shopify.
U slučaju MCS-a, 2FA je implementiran na osnovu Google Authenticator i . Sam protokol je već 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 grube sile: korisnik ima samo nekoliko pokušaja da unese jednokratnu lozinku, a zatim je unos blokiran neko vrijeme. Ovo blokira mogućnost brutalne selekcije OTP-a.
- Prilikom generiranja offline rezervnih kodova za izvođenje 2FA, kao i onemogućavanja. Ovdje nije implementirana nikakva brute force zaštita, što je omogućilo, ako ste imali lozinku za nalog i aktivnu sesiju, da regenerirate rezervne kodove ili potpuno onemogućite 2FA.
S obzirom da su rezervni kodovi bili locirani u istom rasponu vrijednosti niza kao i oni koje je generirala OTP aplikacija, šansa da se kod pronađe u kratkom vremenu bila je mnogo veća.
Proces odabira OTP-a za onemogućavanje 2FA pomoću alata “Burp: Intruder”.
rezultat
Sve u svemu, čini se da je MCS siguran kao proizvod. Tokom revizije, tim za pentestiranje nije bio u mogućnosti da dobije pristup klijentskim VM-ovima i njihovim podacima, a MCS tim je brzo ispravio pronađene ranjivosti.
Ali ovdje je važno napomenuti da je sigurnost kontinuirani rad. Usluge nisu statične, one se stalno razvijaju. A nemoguće je razviti proizvod u potpunosti 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ć otklonjene. A kako bi se broj novih sveo na minimum i skratio njihov vijek trajanja, tim platforme nastavlja raditi ovo:
- redovno sprovodi revizije od strane eksternih kompanija;
- podržavaju i razvijaju učešće;
- baviti se bezbednošću. 🙂
izvor: www.habr.com