🥇Revizija varnosti oblačne platforme MCS

SkyShip Dusk od SeerLight

Izgradnja bilo koje usluge uključuje kontinuirani rad na sigurnosti. Sigurnost je neprekidan proces koji podrazumeva stalnu analizu i poboljšanje zaštite proizvoda, praćenje vesti o ranjivostima i još mnogo toga. Takođe, tu su i revizije. Revizije se sprovode kako internim snagama, tako i uz pomoć spoljnih stručnjaka koji mogu drastično poboljšati sigurnost, jer nisu uronjeni u projekat i imaju bistar pogled.

Ovaj članak govori o tom bistrim pogledu spoljašnjih stručnjaka koji su pomogli timu Mail.ru Cloud Solutions (MCS) da testira cloud servis, kao i o tome šta su pronašli. Kao 'spoljne snage', MCS je odabrao kompaniju Digital Security, poznatu po svojoj visokoj stručnosti u IT bezbednosti. U ovom članku razmotrićemo neke zanimljive ranjivosti otkrivene tokom spoljne revizije - kako biste izbegli iste zamke kada budete kreirali svoj cloud servis.

Opis proizvoda

Mail.ru Cloud Solutions (MCS) je platforma za izgradnju virtuelne infrastrukture u cloud-u. Uključuje IaaS, PaaS, kao i tržište gotovih aplikativnih obrazaca za programere. S obzirom na arhitekturu MCS, bilo je potrebno proveriti sigurnost proizvoda u sledećim oblastima:

zaštita infrastrukture virtuelizacije: hipervizori, rutiranje, vatrozidi;
zaštita virtuelne infrastrukture klijenata: međusobna izolacija, uključujući mrežnu, privatne mreže u SDN;
OpenStack i njegovi otvoreni komponente;
S3 razvijen u vlastitoj režiji;
IAM: multitenant projekti sa ulogama;
Vision (mašinsko učenje): API i ranjivosti u radu sa slikama;
web interfejs i klasični web napadi;
ranjivosti PaaS komponenti;
API svih komponenti.

Verovatno, od bitnih stvari za dalju priču - to je sve.

Koje su aktivnosti sprovedene i zašto su potrebne?

Revizija sigurnosti je usmerena na otkrivanje ranjivosti i grešaka u konfiguraciji koje mogu dovesti do curenja ličnih podataka, modifikacije osetljivih informacija ili do prekida dostupnosti servisa.

Med delom, ki traja v povprečju 1-2 meseca, revizorji ponavljajo dejanja potencialnih napadalcev in iščejo ranljivosti na strani stranke in strežnika izbrane storitve. V kontekstu revizije oblačne platforme MCS so bile postavljene naslednje cilje:

Analiza identifikacije v storitvi. Ranljivosti v tej komponenti bi takoj omogočile dostop do tujih računov.
Preučitev modela vlog in omejevanja dostopa med različnimi računi. Za napadalca je dostop do tuje virtualne naprave želen cilj.
Ranljivosti na strani stranke. XSS/CSRF/CRLF/itd. Ali obstaja možnost, da napadete druge uporabnike preko zlonamernih povezav?
Ranljivosti na strani strežnika: RCE in vse možne injekcije (SQL/XXE/SSRF itd.). Ranljivosti na strežniku so običajno težje odkriti, vendar lahko povzročijo kompromitacijo velikega števila uporabnikov.
Analiza izolacije uporabniških segmentov na ravni omrežja. Za napadalca pomanjkanje izolacije znatno povečuje površino napada na druge uporabnike.
Analiza poslovne logike. Ali je mogoče prevarati sistem in ustvarjati virtualne naprave brezplačno?

V tem projektu so bila dela izvedena po modelu 'Gray-box': revizorji so komunicirali s storitvijo s privilegiji navadnih uporabnikov, vendar so delno imeli izvorne kode API in so lahko pojasnili podrobnosti s programerji. Običajno je to najprimernejši in dovolj realističen delovni model: notranje informacije lahko vseeno zbere napadalec, gre le za vprašanje časa.

Najdene ranljivosti

Preden auditor začne pošiljati različne payloade (koristna obremenitev, s katero se izvede napad) na naključne kraje, je treba razumeti, kako vse deluje in katera funkcionalnost je na voljo. Morda se zdi, da je to brezsmiselno opravilo, saj v večini pregledanih mest ne bo ranljivosti. Samo razumevanje strukture aplikacije in logike njenega delovanja bo omogočilo iskanje najbolj zapletenih napadalnih vektorjev.

Pomembno je najti mesta, ki se zdijo sumljiva ali se močno razlikujejo od drugih. Prva nevarna ranljivost je bila najdena prav na tak način.

IDOR

IDOR ranljivosti (Insecure Direct Object Reference, nevarne neposredne povezave do objektov) so ena od najpogostejših vrst ranljivosti v poslovni logiki, ki omogoča pridobitev dostopa do objektov, do katerih v resnici ni dovoljen dostop. IDOR ranljivosti omogočajo pridobivanje informacij o uporabniku različne resnosti.

Ena od različic IDOR je izvajanje dejanj z objekti sistema (uporabniki, bančnimi računi, izdelki v košarici) s manipulacijo s identifikatorji za dostop do teh objektov. To lahko privede do najbolj nepredvidljivih posledic. Na primer, lahko povzroči zamenjavo računa pošiljatelja finančnih sredstev, kar omogoča krajo sredstev od drugih uporabnikov.

V primeru MCS so revizorji odkrili IDOR ranljivost, povezano z nezavarovanimi identifikatorji. V uporabniškem računu so se za dostop do vseh objektov uporabljali identifikatorji UUID, ki so se zdeli, kot pravijo varnostni strokovnjaki, impresivno neobvladljivi (torej zaščiteni pred napadi s preizkušanjem). Vendar je bilo za nekatere entitete ugotovljeno, da se za pridobitev informacij o uporabnikih aplikacije uporabljajo običajne predvidljive številke. Mislim, da se domislite, da bi lahko spremenili ID uporabnika za ena, ponovno poslali zahtevo in na ta način pridobili informacije ob obhodu ACL (seznam pravil dostopa, ki določa pravila dostopa do podatkov za postopke in uporabnike).

Server Side Request Forgery (SSRF)

OpenSource izdelki so dobri v tem, da obstaja ogromno forumov z podrobnimi tehničnimi opisi težav, ki se pojavijo, in, če imate srečo, tudi z opisi rešitev. Toda ta medalja ima tudi drugo stran: prav tako so podrobno opisane znane ranljivosti. Na primer, na forumu OpenStack so odlični opisi ranljivosti. [XSS] in [SSRF], ki jih nekako nihče ne mudi popraviti.

Pogosta funkcionalnost aplikacij je možnost, da uporabnik pošlje povezavo strežniku, po kateri strežnik preide (na primer za nalaganje slike iz navedene lokacije). Pri nezadostni filtraciji s sredstvi varnosti samih povezav ali odgovorov, ki jih strežnik vrača uporabnikom, lahko to funkcionalnost enostavno izkoristijo napadalci.

SSRF ranljive točke lahko znatno napredujejo napad. Napadalec lahko pridobi:

omejen dostop do napadene lokalne mreže, na primer le do določenih segmentov ter po določenem protokolu;
popolen dostop do lokalne mreže, če je možna nadgradnja z aplikacijske ravni na transportno raven in posledično popolno upravljanje obremenitve na ravni aplikacij;
dostop do branja lokalnih datotek na strežniku (če je podprta shema file:///);
in še mnogo več.

V OpenStacku je že dolgo znana SSRF ranljivost, ki ima 'slepo' naravo: ob povezavi s strežnikom ne prejmeš odgovora, ampak dobiš različne vrste napak/zamud, odvisno od rezultata poizvedbe. Na podlagi tega lahko izvedeš skeniranje vrat na gostiteljih v notranji mreži, z vsemi posledicami, ki jih ne smemo podcenjevati. Na primer, produkt lahko vsebuje API za back office, dostopen le iz korporativne mreže. Z dokumentacijo (ne pozabimo na insiderje) lahko napadalec preko SSRF dostopa do notranjih metod. Na primer, če je na nek način mogoče pridobiti približen seznam uporabnih URL-jev, se lahko z SSRF od njih premakneš in izvedeš poizvedbo – denimo, preneseš denar z računa na račun ali spremeniš meje.

To ni prvi primer odkritja SSRF ranljivosti v OpenStacku. V preteklosti je obstajala možnost nalaganja ISO slik VM preko neposredne povezave, kar je prav tako pripeljalo do podobnih posledic. Ta funkcionalnost je trenutno odstranjena iz OpenStacka. Zdi se, da je skupnost to smatrala za najbolj preprosto in zanesljivo rešitev problema.

In ovom javnem poročilu storitve HackerOne (h1) izkoriščanje že ne slepe SSRF z možnostjo branja metapodatkov inštance vodi do pridobitve Root dostopa do celotne infrastrukture Shopify.

V MCS so na dveh mestih s podobno funkcionalnostjo odkrili SSRF ranljivosti, vendar jih je praktično nemogoče bilo izkoristiti zaradi požarnih zidov in drugih zaščit. Tako ali drugače, ekipa MCS je vseeno popravila to težavo, ne da bi čakala na skupnost.

XSS namesto nalaganja 'shellov'

Kljub stotinam napisanih raziskav, leto za letom XSS (napad medstranskega skriptiranja) ostaja najpogosteje srečana spletna ranljivost (ali napad?).

Prenos datotek je priljubljeno mesto za vsakogar, ki se ukvarja z varnostjo. Pogosto se izkaže, da je mogoče naložiti poljuben skript (asp/jsp/php) in izvajati ukaze operacijskega sistema, kar pišoči testovalci imenujejo "naložiti lupino". Vendar pa priljubljenost takšnihranljivosti deluje v obe smeri: spomnijo se jih in razvijajo sredstva proti njim, tako da v zadnjem času verjetnost, da bi "naložili lupino", teži proti ničli.

Napadalni skupini (v imenu Digital Security) je uspelo. V redu, na strani strežnika v MCS so preverili vsebino nalaganih datotek, dovoljene so bile le slike. Ampak SVG je tudi slika. Kakšna je torej nevarnost slik SVG? Da lahko v njih vključimo dele JavaScripta!

Ugotovili smo, da so naložene datoteke dostopne vsem uporabnikom storitve MCS — kar pomeni, da lahko napadamo druge uporabnike oblaka, zlasti skrbnike.

Primer vključitve z XSS- napadom s phishing prijavno obliko

Primeri izkoriščanja XSS- napada:

Zakaj poskušati ukrasti sejo (zlasti ker imamo zdaj povsod HTTP-Only piškotke, zaščitene pred krajo s pomočjo js-skriptov), če lahko naloženi skript takoj dostopa do API- ja virov? V tem primeru lahko vloga prek XHR- poizvedb spremeni konfiguracijo strežnika, na primer doda odprti SSH-ključ zločinca in pridobi SSH- dostop do strežnika.
Če CSP politika (politika zaščite vsebine) prepoveduje vključitev JavaScripta, se zločinec lahko izogne brez njega. Na čistem HTML-ju lahko ustvari lažno prijavno obliko in ukrade geslo skrbnika s tako naprednim phishingom: phishing stran za uporabnika se prikaže na istem URL-ju, in uporabniku je težje odkriti.
Nazadnje lahko zločinec izvede odjemalski DoS — postavi piškotke velikosti več kot 4 KByte. Uporabnik mora enkrat odpreti povezavo — in celotna stran postane nedostopna, dokler ne ugotovi, da mora posebej očistiti brskalnik: v večini primerov bo spletni strežnik zavrnil takšnega odjemalca.

Poglejmo primer še enega odkritja XSS, tokrat z bolj prefinjeno izkoriščanjem. Storitev MCS omogoča združevanje nastavitev požarnih zidov v skupine. XSS je bila odkrita v imenu skupine. Njena posebnost je bila v tem, da ni bila sprožena takoj, ne pri ogledovanju seznama pravil, temveč pri brisanju skupine:

To summarize, the scenario unfolded as follows: the attacker creates a firewall rule with a 'load' in the name, the administrator notices it after some time, and initiates the deletion process. This is when the malicious JS activates.

For protection against XSS in uploaded SVG images (if they cannot be avoided), the Digital Security team recommended to MCS developers:

Host user-uploaded files on a separate domain that is unrelated to the 'cookie' domain. The script will execute in the context of another domain and will not pose a threat to MCS.
In the server's HTTP response, include the header 'Content-disposition: attachment'. This way, files will be downloaded by the browser rather than executed.

Furthermore, there are now many ways for developers to mitigate XSS exploitation risks:

using the 'HTTP Only' flag can make session 'Cookies' headers inaccessible to malicious JavaScript;
a properly implemented CSP policy will significantly complicate XSS exploitation for the attacker;
modern templating engines like Angular or React automatically sanitize user data before outputting it to the user's browser.

Vulnerabilities in two-factor authentication

To enhance account security, users are always advised to enable 2FA (two-factor authentication). Indeed, this is an effective way to prevent attackers from accessing a service if the user's credentials have been compromised.

But does the use of a second authentication factor always guarantee the safety of the account? There can be security issues in 2FA implementations:

Brute-forcing the OTP code (one-time codes). Despite the simplicity of exploitation, such errors as lack of brute force protection for OTP are found even in large companies: the Slack case, the Facebook case.
Weak generation algorithms, such as the ability to predict the next code.
Logical errors, such as the ability to request someone else's OTP on one's own phone, as it was at Shopify.

In the case of MCS, 2FA is implemented based on Google Authenticator and Duo. The protocol itself is time-tested, but the implementation of code verification on the application side should be verified.

In MCS, 2FA is used in several places:

Pri prijavi uporabnika. Tu je zaščita pred napadi s poskusi: uporabnik ima le nekaj poskusov za vnos enkratne gesla, nato je vnos za določeno časovno obdobje blokiran. To preprečuje možnost napada z ugibanjem OTP.
Pri generiranju offline rezervnih kod za izvajanje 2FA, pa tudi za njeno izklopitev. Tu zaščite pred napadi s poskusi ni bilo, kar je omogočilo, da smo ob poznavanju gesla za račun in aktivni seji lahko regenerirali rezervne kode ali popolnoma izklopili 2FA.

Glede na to, da so rezervne kode obsegale isto območje vrednosti kot generirane aplikacijo OTP, je bila verjetnost, da bi kodo uganili v kratkem času, znatno večja.

Postopek ugibanja OTP za izklop 2FA s pomočjo orodja „Burp: Intruder“

Результат.

Na splošno je izdelek MCS izkazal za varen. Med revizijo ekipi pentesterjev ni uspelo dostopati do odjemalskih VM in njihovih podatkov, odkrite ranljivosti pa je ekipa MCS hitro odpravila.

Vendar pa je pomembno poudariti, da je varnost stalno delo. Storitve niso statične, nenehno se razvijajo. Razviti izdelka popolnoma brez ranljivosti ni mogoče. Toda mogoče je pravočasno jih odkriti in zmanjšati možnost njihove ponovitve.

Trenutno so vse omenjene ranljivosti v MCS že odpravljene. Da bi zmanjšali število novih in skrajšali njihovo obstojnost, ekipa platforme nadaljuje s tem: