MCS pilveplatvormi turvaaruanne

SkyShip Dusk by SeerLight

Igasse kõigi teenuste loomine hõlmab pidevat tööd turvalisuse nimel. Turvalisus on pidev protsess, mis sisaldab toote kaitse pidevat analüüsi ja täiustamist, haavatavuste uudiste jälgimist ja palju muud. Nende hulgas on ka auditid. Auditid viiakse läbi nii omakäeliselt kui ka välistest ekspertidest, kes saavad turvalisust oluliselt parandada, kuna nad ei ole projektiga süvitsi seotud ning neil on värske vaatenurk.

Artikkel käsitleb just seda värsket vaatenurka välistelt ekspertidelt, kes aitasid Mail.ru Cloud Solutions (MCS) meeskonnal pilveteenust testida ja seda, mida nad avastasid. MCS valis "välistena" Digital Security, mis on tuntud oma kõrge ekspertiisi poolest infotehnoloogia ringkondades. Selles artiklis käsitleme mõned huvitavad haavatavused, mis leiti välishindamise käigus - nii et te ei satuks sarnastesse probleemidesse, kui loote oma pilveteenuse.

Toote kirjeldus

Mail.ru Cloud Solutions (MCS) on platvorm virtuaalse infrastruktuuri loomiseks pilves. See hõlmab IaaS-e, PaaS-e ja valmistehtud rakenduste poodide turgu arendajatele. Arvestades MCS-i arhitektuuri, tuli toote turvalisust kontrollida järgmistes suundades:

• virtualiseerimiskeskkonna infrastruktuuri kaitse: hüperviisorid, marsruutimine, tulemüürid;
• kliendi virtuaalse infrastruktuuri kaitse: isolatsioon üksteisest, sealhulgas võrgu, privaatsete võrkude ja SDN;
• OpenStack ja selle avatud komponendid;
• enda loodud S3;
• IAM: mitmeüürilised projektid rolli mudeliga;
• Vision (masinõpe): API ja haavatavused piltidega töötamisel;
• veebiliides ja klassikalised veebirünnakud;
• PaaS-komponentide haavatavused;
• kõigi komponentide API.

Võib-olla on oluline edasise loo jaoks kõik.

Milliseid töid viidi läbi ja miks need on vajalikud?

Turvaaudit on suunatud haavatavuste ja konfiguratsioonivigade tuvastamisele, mis võivad põhjustada isikuandmete lekkimist, tundlike andmete muutmist või teenuste kättesaadavuse katkemist.

Töötamise käigus, mis kestab keskmiselt 1-2 kuud, kordavad audiitorid potentsiaalsete ründajate tegevusi ja otsivad valitud teenuse kliendi- ja serveripoolsetes osades haavatavusi. MCS-i pilveplatvormi auditi kontekstis on seatud järgmised eesmärgid:

1. Teenuse autentimise analüüs. Selle komponendi haavatavused võimaldaksid kohe sisse pääseda teiste kontodele.
2. Rollimudeli ja ligipääsu piirangu uurimine erinevate kontode vahel. Ründaja jaoks on juurdepääs teiste virtuaalmasinatele ihatud eesmärk.
3. Kliendipoolsete haavatavuste tundmine. XSS/CSRF/CRLF/jne. Kas on olemas võimalus rünnata teisi kasutajaid pahatahtlike linkide kaudu?
4. Serveripoolsete haavatavuste analüüs: RCE ja igasugused sisestused (SQL/XXE/SSRF jne). Serveri haavatavused on tavaliselt keerulisemad leida, kuid need võivad paljusid kasutajaid kohe kompromiteerida.
5. Kasutajasegmentide isolatsiooni analüüs võrgu tasandil. Ründaja jaoks suurendab isolatsiooni puudumine oluliselt rünnakupinda teistele kasutajatele.
6. Äriloogika analüüs. Kas on võimalik petta äri ja luua virtuaalmasinaid tasuta?

Käesolevas projektis tehti töid „Gray-box” mudeli kohaselt: audiitorid suhtlesid teenusega tavakasutajate õigustes, kuid olid osaliselt tutvunud API lähtekoodidega ja said arendajatelt detaile küsida. Üldiselt on see kõige mugavam ja samas piisavalt realistlik töömeetod: siseinformatsiooni saab ründaja nagunii koguda, see on vaid aja küsimus.

Leitud haavatavused

Enne kui audiitor hakkab saatma erinevaid payload’e (ründeluba, mille abil rünnak toimub) juhuslikesse kohtadesse, on oluline aru saada, kuidas kõik töötab, millised funktsioonid on esindatud. See võib tunduda mõttetu tegevusena, kuna enamikus uuritud kohtades ei pruugi olla haavatavusi. Kuid alles rakenduse struktuuri ja selle tööloogika mõistmine võimaldab leida kõige keerulisemaid rünnakusuundi.

Oluline on leida kohad, mis tunduvad kahtlased või mis erinevad märkimisväärselt teistest. Ja esimene ohtlik haavatavus leiti just sellisel moel.

IDOR

IDOR-haavat (Insecure Direct Object Reference, ebaturvalised otseviidatud objektid) on üks levinumaid haavatavusi äriloogikas, mis võimaldab mingil viisil pääseda objektidele, millele tegelikult juurdepääs pole lubatud. IDOR-haavatavused loovad võimaluse saada kasutaja teavet erineva kriitilisuse tasemega.

Üks IDOR-i variante on toimingute tegemine süsteemi objektidega (kasutajate, pangakontode, ostukorvis olevate kaupade) juurdepääsuidentifikaatoritega manipuleerimise kaudu. See viib kõige ettearvamatumate tagajärgedeni. Näiteks saab see võimaldada raha saatja konto vahetamist, mille kaudu on võimalik teistelt kasutajatelt raha varastada.

MCS-i juhtumil avastasid audiitorid just IDOR-haavatavuse, mis oli seotud turvamata identifikaatoritega. Kasutaja isiklikus kontoris kasutati igasuguste objektide juurde pääsemiseks UUID identifikaatoreid, mis tundusid, nagu ütlevad turvaeksperdid, muljetavaldavalt purustamatud (st kaitstuna brute force rünnakute eest). Kuid teatud üksuste jaoks tuvastati, et rakenduse kasutajate teabe saamiseks kasutati tavapäraseid ettearvatavaid numbreid. Arvan, et te juba aimate, et kasutaja ID-d oli võimalik muuta ühe võrra, uuesti päring saata ja seega saada teavet ACL-i (access control list, andmetele juurdepääsu reeglid protsesside ja kasutajate jaoks) piirangutest mööda.

Serveri külgpäringu valevormistamine (SSRF)

Avatud lähtekoodiga tooted on head selle poolest, et nende kohta on tohutult foorumeid, kus on põhjalikud tehnilised kirjelduse probleeme ja, kui teil vedas, ka lahenduste kirjeldusi. Kuid selle mündi on ka teine külg: sama detailselt on kirja pandud ka tuntud haavatavused. Näiteks OpenStacki foorumis on suurepärased kirjeldused haavatavustest. [XSS] ja [SSRF], mida kuidagi keegi ei kiirusta parandama.

Rakenduste sage funktsionaalsus on võimalus, et kasutaja saadab serverisse lingi, mille kaudu server liigub (näiteks pildi laadimiseks määratud allikast). Kui linkide või serveri kasutajatele tagastatavate vastuste piisavat filtreerimist ei tehta, saavad pahatahtlikud isikud sellist funktsionaalsust hõlpsasti ära kasutada.

SSRF-haavat võivad oluliselt edendada rünnaku arengut. Ründaja võib saada:

• piiratud juurdepääsu rünnatud kohalikule võrgule, näiteks vaid teatud võrgu segmentidele ja teatud protokolli kaudu;
• täielikku juurdepääsu kohalikule võrgule, kui on võimalik rakendustaseme allapoole viimine transporttasemele ja seega täielik rakendustaseme koormuse juhtimine;
• juurdepääsu kohalikele failidele serveris (kui toetatakse skeemi file://);
• ja palju muud.

OpenStackis on soovmõtlemisega SSRF-haavatavus teada ammu: serverile pöördudes ei saa sa temalt vastust, kuid saad erinevaid tüüpe vigu/viivitusi, sõltuvalt päringu tulemusest. Selle põhjal on võimalik skaneerida porte sisemiste võrkude hostidel, millel on kõikvõimalikud tagajärjed, mida ei tohiks alahinnata. Näiteks võiks tootel olla API tagasipöördlusalal, mis on kergesti ligipääsetav ainult ettevõtte võrgust. Dokumentide (ärge unustage siseringi) olemasolul võib ründaja kasutada SSRF-i, et pöörduda sisemiste meetodite poole. Näiteks, kui on mingil viisil saanud ligikaudse kasulike URL-ide nimekirja, saab SSRF-i abil nendega liikuda ja esitada päringu – tinglikult öeldes, kanda raha kontolt teisele või muuta limiite.

See ei ole esimene kord, kui OpenStackis avastatakse SSRF-haavatavus. Eelmine kord oli võimalus laadida ISO-pilte VM-ide jaoks otse lingi kaudu, mis tõi kaasa sarnased tagajärjed. Praegu on see funktsioon OpenStackist eemaldatud. Tundub, et kogukond pidas seda kõige lihtsamaks ja usaldusväärsemaks lahenduseks probleemile.

Ja selles avaliku juurdepääsuga raportis teenusest HackerOne (h1) ei näita pime SSRF-i ekspluateerimine koos metadata lugemise võimalusega juurdepääsu saamise Root- õigustele kogu Shopify infrastruktuurile.

MCS-is leidis kaks kohta sarnase funktsiooniga SSRF-haavatavusi, kuid nende ärakasutamine oli praktiliselt võimatu tulekahjukaitsete ja teiste turvameetmete tõttu. Igal juhul parandas MCS selle probleemi, ilma et oleks oodanud kogukonda.

XSS asemel „shellide“ laadimist

Hoolimata sadadest kirjutatud uuringutest on aastast aastasse XSS (cross-site scripting rünnak) endiselt kõige tihedamini esinev veeb-haavatavus (või rünnak?).

Failide üleslaadimine on iga turva-uuringu tegija lemmikoht. Sageli on võimalik laadida üles suvaline skript (asp/jsp/php) ja käivitada operatsioonisüsteemi käske, pentesterite terminoloogias - "shell'i üleslaadimine". Kuid sarnaste haavatavuste populaarsus toimib mõlemas suunas: neid meenutatakse ja arendatakse nende vastu vahendeid, nii et viimasel ajal on tõenäosus "shell'i üleslaadimiseks" lähemas nullile.

Ründemeeskond, keda esindab Digital Security, oli õnnelik. Okei, MCS serveripoolne sisu kontrollis üleslaaditud failide sisu, lubatud olid vaid pildid. Kuid SVG on samuti pilt. Kuidas võivad SVG pildid ohtlikud olla? Selle poolest, et neid saab integreerida JavaScripti fragmente!

Selgus, et üleslaaditud failid on kõigi MCS teenuse kasutajate jaoks kergesti ligipääsetavad - see tähendab, et saab rünnata teisi pilvekasutajaid, sealhulgas administraatoreid.

XSS-rünnaku kaudu toimimise näide varguse vormi kaudu

XSS-rünnaku kasutamise näited:

• Miks püüda sessiooni varastada (veel enam, et praegu on igal pool HTTP-Only küpsised, mis on kaitstud JS-skriptide varastamise eest), kui üleslaaditud skript saab kohe suhelda ressursi API-ga? Sellisel juhul võib koormus XHR-päringute kaudu muuta serveri konfiguratsiooni, näiteks lisada ründaja avaliku SSH-võtme ja saada SSH-juurdepääsu serverile.
• Kui CSP-poliitika (sisu kaitse poliitika) keelab JavaScripti sisestamise, saab ründaja ilma selleta hakkama. Puhta HTMLiga saab luua vale sisestusvormi ja varastada administraatori parooli sellise arenenud petmise kaudu: petusait on kasutaja jaoks samal URL-il, ja on keerulisem seda tuvastada.
• Lõpuks võib ründaja korraldada kliendi DoS — seadistades küpsised, mis on suuremad kui 4 Kb. Kasutajale piisab, kui ta avab lingi - ja terve sait muutub kättesaamatuks, kuni ta ei mõtle spetsiaalselt oma brauseri puhastamise peale: suuremas enamuses juhtudest keeldub veebiserver sellist kasutajat vastu võtma.

Vaadakem veel ühte avastatud XSS-i näidet, seekord keerulisema ärakasutamisega. Teenus MCS võimaldab tulemüüri seadistusi rühmadena liita. Rühma nimedes avastati XSS. Selle eripära seisnes selles, et vektor ei töötanud kohe, mitte reeglite nimekirja vaatamise ajal, vaid rühma kustutamise ajal:

See, the scenario unfolds like this: an attacker creates a firewall rule with a "load" in its name, the administrator notices it after some time, initiates the deletion process. And that’s when the malicious JS kicks in.

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

• Host files uploaded by users on a separate domain unrelated to the "cookie". The script will execute in the context of another domain and will not pose a threat to MCS.
• In the server's HTTP response, return the header "Content-disposition: attachment". Then files will be downloaded by the browser, not executed.

Moreover, there are many ways available for developers to mitigate XSS exploitation risks:

• using the "HTTP Only" flag to make session 'Cookies' headers inaccessible to malicious JavaScript;
• a properly implemented CSP policy will significantly complicate XSS exploitation for an attacker;
• modern templating engines, such as Angular or React, automatically sanitize user data before it’s displayed in the user’s browser.

Two-factor authentication vulnerabilities

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

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

• Brute force of OTP code (one-time codes). Despite the simplicity of exploitation, such mistakes as lack of brute force protection for OTP are found even in large companies: the Slack case, the Facebook case.
• Weak generation algorithm, for instance, predictability of the next code.
• Logical errors, for example, the ability to request someone else's OTP on your phone, like this oli in Shopify.

In MCS, 2FA is implemented based on Google Authenticator and Duo. The protocol itself has stood the test of time, but the implementation of code verification on the application side should be checked.

In MCS, 2FA is used in several places:

• Kasutaja autentimise korral. Siin on olemas kaitse bruteforce'i rünnakute vastu: kasutajal on vaid mõned katsetused ühekordse parooli sisestamiseks, pärast mida blokeeritakse sisestamine mõneks ajaks. See takistab OTP-d brute-force meetodil kindlaks määrata.
• Offlines backup-koodide genereerimise ajal 2FA täitmiseks ning selle väljalülitamisel. Siin ei olnud bruteforce'i kaitset, mis võimaldas, kui kontol oli parool ja aktiivne sessioon, backup-koodide uuesti genereerimist või 2FA täielikku väljalülitamist.

Arvestades, et backup-koodid paiknesid samas väärtuste vahemikus nagu rakenduse poolt genereeritud OTP-d, oli võimalus koode lühikese aja jooksul ära arvata märkimisväärselt suurem.

OTP proovimise protsess 2FA väljalülitamiseks tööriista "Burp: Intruder" abil.

Tulemus

Üldiselt osutus MCS toode turvaliseks. Auditite ajal ei suutnud pen-testerite meeskond klientide virtuaalmasinatele ja nende andmetele juurde pääseda ning MCS meeskond parandas leitud haavatavused kiiresti.

Kuid siinkohal on oluline märkida, et turvalisus on pidev töö. Teenused ei ole staatilised, need arenevad pidevalt. Toodet, mis oleks täielikult haavatavusteta, on võimatu välja töötada. Kuid neid saab õigeaegselt tuvastada ja kordumise võimalust vähendada.

Kõik eelnevalt mainitud haavatavused MCS-is on nüüdseks parandatud. Uute haavatavuste arvu vähendamiseks ja nende eksisteerimise aja lühendamiseks jätkab platvormi meeskond järgmistega:

• regulaarselt teostama auditeid välistelt ettevõtetelt;
• toetama ja arendama osalemist Mail.ru Group Bug Bounty programmis;;
• tegelema turvalisusega. 🙂

Allikas: habr.com