de SeerLight
Konstrui ajnan servon nepre inkluzivas konstantan laboron pri sekureco. Sekureco estas kontinua procezo, kiu inkluzivas konstantan analizon kaj plibonigon de produkta sekureco, monitorado de novaĵoj pri vundeblecoj kaj multe pli. Inkluzive de revizioj. Aŭditoroj estas faritaj kaj endome kaj de eksteraj spertuloj, kiuj povas radikale helpi pri sekureco ĉar ili ne estas mergitaj en la projekto kaj havas malferman menson.
La artikolo temas pri ĉi tiu plej simpla vido de eksteraj spertuloj, kiuj helpis la teamon Mail.ru Cloud Solutions (MCS) testi la nuban servon, kaj pri tio, kion ili trovis. Kiel "ekstera forto", MCS elektis la kompanion de Cifereca Sekureco, konatan pro ĝia alta kompetenteco en rondoj pri informa sekureco. Kaj en ĉi tiu artikolo ni analizos kelkajn interesajn vundeblecojn trovitajn kiel parto de ekstera revizio - por ke vi evitu la saman rastilon kiam vi kreas vian propran nuban servon.
Описание продукта
estas platformo por konstrui virtualan infrastrukturon en la nubo. Ĝi inkluzivas IaaS, PaaS kaj vendoplacon de pretaj aplikaĵbildoj por programistoj. Konsiderante la MCS-arkitekturon, estis necese kontroli la sekurecon de la produkto en la sekvaj areoj:
- protektante la infrastrukturon de la virtualiga medio: hiperviziiloj, vojigo, fajroŝirmiloj;
- protekto de la virtuala infrastrukturo de klientoj: izolado unu de la alia, inkluzive de reto, privataj retoj en SDN;
- OpenStack kaj ĝiaj malfermitaj komponantoj;
- S3 de nia propra dezajno;
- IAM: multi-luantprojektoj kun rolmodelo;
- Vizio (komputila vizio): APIoj kaj vundeblecoj kiam vi laboras kun bildoj;
- TTT-interfaco kaj klasikaj TTT-atakoj;
- vundeblecoj de PaaS-komponentoj;
- API de ĉiuj komponantoj.
Eble tio estas ĉio esenca por plua historio.
Kia laboro estis farita kaj kial ĝi estis bezonata?
Sekureca revizio celas identigi vundeblecojn kaj agordajn erarojn, kiuj povus konduki al elfluado de personaj datumoj, modifo de sentemaj informoj aŭ interrompo de servo-havebleco.
Dum la laboro, kiu daŭras averaĝe 1-2 monatojn, revizoroj ripetas la agojn de eblaj atakantoj kaj serĉas vundeblecojn en la kliento kaj servilo partoj de la elektita servo. En la kunteksto de la revizio de la MCS-nuba platformo, la sekvaj celoj estis identigitaj:
- Analizo de aŭtentigo en la servo. Vundeblecoj en ĉi tiu komponanto helpus tuj eniri la kontojn de aliaj homoj.
- Studante la rolmodelon kaj alirkontrolon inter malsamaj kontoj. Por atakanto, la kapablo akiri aliron al la virtuala maŝino de iu alia estas dezirinda celo.
- Klienta flanko vundeblecoj. XSS/CSRF/CRLF/ktp. Ĉu eblas ataki aliajn uzantojn per malicaj ligiloj?
- Servilflankaj vundeblecoj: RCE kaj ĉiaj injektoj (SQL/XXE/SSRF kaj tiel plu). Servilaj vundeblecoj estas ĝenerale pli malfacile troveblaj, sed ili kondukas al kompromiso de multaj uzantoj samtempe.
- Analizo de uzantsegmentizolado sur la retonivelo. Por atakanto, la manko de izolado multe pliigas la ataksurfacon kontraŭ aliaj uzantoj.
- Komerca logika analizo. Ĉu eblas trompi entreprenojn kaj krei virtualajn maŝinojn senpage?
En ĉi tiu projekto, laboro estis farita laŭ la modelo "Gray-box": revizoroj interagis kun la servo kun la privilegioj de ordinaraj uzantoj, sed parte posedis la fontkodon de la API kaj havis la ŝancon klarigi detalojn kun la programistoj. Ĉi tio kutime estas la plej oportuna, kaj samtempe sufiĉe realisma modelo de laboro: internaj informoj ankoraŭ povas esti kolektitaj de atakanto, ĝi estas nur demando de tempo.
Vundeblecoj trovitaj
Antaŭ ol la revizoro komencas sendi diversajn utilajn ŝarĝojn (la utila ŝarĝo uzata por efektivigi la atakon) al hazardaj lokoj, necesas kompreni kiel funkcias aferoj kaj kia funkcieco estas provizita. Povas ŝajni, ke ĉi tio estas senutila ekzerco, ĉar en la plej multaj el la studitaj lokoj ne estos vundeblecoj. Sed nur kompreni la strukturon de la aplikaĵo kaj la logikon de ĝia funkciado ebligos trovi la plej kompleksajn atakvektorojn.
Gravas trovi lokojn kiuj ŝajnas suspektindaj aŭ estas tre malsamaj de aliaj iel. Kaj la unua danĝera vundebleco estis trovita tiamaniere.
IDOR
IDOR (Insecure Direct Object Reference) vundeblecoj estas unu el la plej oftaj vundeblecoj en komerca logiko, kiu permesas al unu aŭ alia akiri aliron al objektoj al kiuj aliro ne estas fakte permesita. IDOR-vundeblecoj kreas la eblecon akiri informojn pri uzanto de diversaj gradoj de kritikeco.
Unu el la IDOR-opcioj estas fari agojn kun sistemaj objektoj (uzantoj, bankkontoj, eroj en la aĉetĉaro) manipulante aliridentigilojn al ĉi tiuj objektoj. Ĉi tio kondukas al la plej neantaŭvideblaj sekvoj. Ekzemple, la ebleco anstataŭigi la konton de la sendinto de financoj, per kiu vi povas ŝteli ilin de aliaj uzantoj.
En la kazo de MCS, revizoroj ĵus malkovris IDOR-vundeblecon asociitan kun ne-sekuraj identigiloj. En la persona konto de la uzanto, UUID-identigiloj estis uzataj por aliri iujn ajn objektojn, kiuj ŝajnis, kiel diras sekurecaj fakuloj, impone nesekuraj (tio estas protektitaj kontraŭ krudfortaj atakoj). Sed por certaj estaĵoj, oni malkovris, ke regulaj antaŭvideblaj nombroj estas uzataj por akiri informojn pri la uzantoj de la aplikaĵo. Mi pensas, ke vi povas diveni, ke eblis ŝanĝi la uzantidentigilon per unu, sendi la peton denove kaj tiel akiri informojn preterpasante la ACL (alirkontrollisto, reguloj de aliro de datumoj por procezoj kaj uzantoj).
Servila Flanka Peto Falsiĝo (SSRF)
La bona afero pri OpenSource-produktoj estas, ke ili havas grandegan nombron da forumoj kun detalaj teknikaj priskriboj de la problemoj kiuj aperas kaj, se vi bonŝancas, priskribo de la solvo. Sed ĉi tiu monero havas flankon: konataj vundeblecoj ankaŭ estas priskribitaj detale. Ekzemple, estas mirindaj priskriboj de vundeblecoj en la OpenStack-forumo и , kiun ial neniu rapidas ripari.
Ofta funkcieco de aplikaĵoj estas la kapablo por la uzanto sendi ligon al la servilo, kiun la servilo alklakas (ekzemple, por elŝuti bildon de specifita fonto). Se sekurecaj iloj ne filtras la ligilojn mem aŭ la respondojn resenditajn de la servilo al uzantoj, tia funkcio povas facile esti uzata de atakantoj.
SSRF-vundeblecoj povas multe antaŭenigi la evoluon de atako. Atakanto povas ricevi:
- limigita aliro al la atakita loka reto, ekzemple, nur tra certaj retsegmentoj kaj uzante certan protokolon;
- plena aliro al la loka reto, se eblas malaltigi de la aplika nivelo al la transportnivelo kaj, kiel rezulto, plena ŝarĝa administrado ĉe la aplika nivelo;
- aliro por legi lokajn dosierojn sur la servilo (se la skemo file:/// estas subtenata);
- kaj multe pli.
SSRF-vunerebleco estas delonge konata en OpenStack, kiu estas "blinda" en naturo: kiam vi kontaktas la servilon, vi ne ricevas respondon de ĝi, sed vi ricevas malsamajn specojn de eraroj/malfruoj, depende de la rezulto de la peto. . Surbaze de ĉi tio, vi povas fari havenskanadon ĉe gastigantoj en la interna reto, kun ĉiuj sekvaj sekvoj, kiuj ne devus esti subtaksitaj. Ekzemple, produkto povas havi back-officejan API kiu estas nur alirebla de la kompania reto. Kun dokumentado (ne forgesu pri internuloj), atakanto povas uzi SSRF por aliri internajn metodojn. Ekzemple, se vi iel povis akiri proksimuman liston de utilaj URL-oj, tiam uzante SSRF vi povas trarigardi ilin kaj plenumi peton - relative parolante, translokigi monon de konto al konto aŭ ŝanĝi limojn.
Ĉi tio ne estas la unua fojo, kiam SSRF-vundebleco estas malkovrita en OpenStack. En la pasinteco, eblis elŝuti VM ISO-bildojn de rekta ligo, kio ankaŭ kaŭzis similajn sekvojn. Ĉi tiu funkcio nun estis forigita de OpenStack. Ŝajne, la komunumo konsideris tion la plej simpla kaj fidinda solvo de la problemo.
Kaj en publike disponebla raporto de la servo HackerOne (h1), ekspluatado de ne plu blinda SSRF kun la kapablo legi metadatumojn kondukas al Radika aliro al la tuta Shopify-infrastrukturo.
En MCS, SSRF-vundeblecoj estis malkovritaj en du lokoj kun simila funkcieco, sed ili estis preskaŭ neeble ekspluati pro fajroŝirmiloj kaj aliaj protektoj. Unu maniero aŭ alia, la MCS-teamo riparis ĉi tiun problemon ĉiuokaze, sen atendi la komunumon.
XSS anstataŭ ŝarĝi ŝelojn
Malgraŭ centoj da studoj skribitaj, jaro post jaro XSS (trans-site scripting) atako daŭre estas la plej Reta vundebleco (aŭ ?).
Dosieraj alŝutoj estas plej ŝatata loko por iu ajn sekureca esploristo. Ofte rezultas, ke vi povas ŝarĝi arbitran skripton (asp/jsp/php) kaj plenumi OS-komandojn, en la terminologio de pentesters - "ŝarĝi ŝelon". Sed la populareco de tiaj vundeblecoj funkcias ambaŭdirekte: ili estas memoritaj kaj rimedoj estas disvolvitaj kontraŭ ili, tiel ke lastatempe la probablo de "ŝarĝi ŝelon" tendencas al nulo.
La ataka teamo (reprezentita de Cifereca Sekureco) estis bonŝanca. Bone, en MCS ĉe la servilo la enhavo de la elŝutitaj dosieroj estis kontrolita, nur bildoj estis permesitaj. Sed SVG ankaŭ estas bildo. Kiel SVG-bildoj povas esti danĝeraj? Ĉar vi povas enmeti JavaScript-fragmentojn en ilin!
Montriĝis, ke la elŝutitaj dosieroj estas disponeblaj por ĉiuj uzantoj de la servo MCS, kio signifas, ke eblas ataki aliajn nubajn uzantojn, nome administrantojn.
Ekzemplo de XSS-atako sur phishing ensalutformularo
Ekzemploj de XSS-ataka ekspluato:
- Kial provi ŝteli seancon (precipe ĉar nun HTTP-Nur-kuketoj estas ĉie, protektitaj kontraŭ ŝtelado per js-skriptoj), se la ŝarĝita skripto povas tuj aliri la rimedan API? En ĉi tiu kazo, la utila ŝarĝo povas uzi XHR-petojn por ŝanĝi la servilan agordon, ekzemple, aldoni la publikan SSH-ŝlosilon de la atakanto kaj akiri SSH-aliron al la servilo.
- Se la CSP-politiko (politiko pri enhava protekto) malpermesas la injekton de JavaScript, atakanto povas eliri sen ĝi. Uzante puran HTML, kreu falsan ensalutan formularon por la retejo kaj ŝtelu la pasvorton de la administranto per ĉi tiu progresinta phishing: la phishing paĝo por la uzanto finas ĉe la sama URL, kaj estas pli malfacile por la uzanto detekti ĝin.
- Fine, la atakanto povas aranĝi — agordi Kuketojn pli grandajn ol 4 KB. La uzanto bezonas malfermi la ligilon nur unufoje, kaj la tuta retejo fariĝas nealirebla ĝis la uzanto pensas specife purigi la retumilon: en la granda plimulto de kazoj, la retservilo rifuzos akcepti tian klienton.
Ni rigardu ekzemplon de alia detektita XSS, ĉi-foje kun pli lerta ekspluato. La MCS-servo permesas vin kombini fajroŝirmilojn en grupojn. La grupnomo estis kie la XSS estis detektita. Ĝia propreco estis, ke la vektoro ne estis ekfunkciigita tuj, ne dum rigardado de la listo de reguloj, sed dum forigo de grupo:
Tio estas, la scenaro rezultis esti la sekva: atakanto kreas fajroŝirmilan regulon kun "ŝarĝo" en la nomo, la administranto rimarkas ĝin post iom da tempo kaj komencas la forigon. Kaj ĉi tie funkcias la malica JS.
Por MCS-programistoj, por protekti kontraŭ XSS en elŝutitaj SVG-bildoj (se ili ne povas esti forlasitaj), la teamo de Cifereca Sekureco rekomendis:
- Metu dosierojn alŝutitajn de uzantoj sur aparta domajno, kiu havas nenion komunan kun "kuketoj". La skripto estos efektivigita en la kunteksto de malsama domajno kaj ne prezentos minacon al MCS.
- En la HTTP-respondo de la servilo, sendu la kaplinion "Content-disposition: attachment". Tiam la dosieroj estos elŝutitaj de la retumilo kaj ne ekzekutitaj.
Krome, ekzistas nun multaj manieroj disponeblaj por programistoj por mildigi la riskojn de XSS-ekspluato:
- uzante la flagon "Nur HTTP", vi povas fari seancajn titolojn "Kuketojn" nealireblaj por malica JavaScript;
- multe pli malfacilas por atakanto ekspluati XSS;
- modernaj ŝablonmotoroj kiel ekzemple Angular aŭ React aŭtomate malpurigas uzantdatenojn antaŭ ol eligi ĝin al la retumilo de la uzanto.
Dufaktoraj aŭtentigaj vundeblecoj
Por plibonigi kontan sekurecon, uzantoj ĉiam konsilas ebligi 2FA (dufaktora aŭtentigo). Efektive, ĉi tio estas efika maniero malhelpi atakanton akiri aliron al servo se la akreditaĵoj de la uzanto estis endanĝerigitaj.
Sed ĉu uzi duan aŭtentikigfaktoron ĉiam garantias konton sekureco? Estas la sekvaj sekurecaj problemoj en la efektivigo de 2FA:
- Brutforta serĉo de la OTP-kodo (unufojaj kodoj). Malgraŭ la simpleco de operacio, eraroj kiel manko de protekto kontraŭ OTP-krudforto ankaŭ estas renkontitaj fare de grandaj kompanioj: , .
- Malforta generacia algoritmo, ekzemple la kapablo antaŭdiri la sekvan kodon.
- Logikaj eraroj, kiel la kapablo peti alies OTP en via telefono, tiel de Shopify.
En la kazo de MCS, 2FA estas efektivigita surbaze de Google Authenticator kaj . La protokolo mem jam estis temp-testita, sed la efektivigo de koda konfirmo ĉe la aplikaĵo indas kontroli.
MCS 2FA estas uzata en pluraj lokoj:
- Kiam oni aŭtentikigas la uzanton. Estas protekto kontraŭ krudforto: la uzanto havas nur kelkajn provojn enigi unufojan pasvorton, tiam la enigo estas blokita dum kelka tempo. Ĉi tio blokas la eblecon de brutforta elekto de OTP.
- Kiam vi generas eksterretajn rezervajn kodojn por plenumi 2FA, kaj ankaŭ malŝalti ĝin. Ĉi tie, neniu krudforta protekto estis efektivigita, kio ebligis, se vi havis pasvorton por la konto kaj aktivan seancon, regeneri rezervajn kodojn aŭ tute malŝalti 2FA.
Konsiderante, ke la rezervaj kodoj troviĝis en la sama gamo de kordaj valoroj kiel tiuj generitaj de la OTP-apliko, la ŝanco trovi la kodon en mallonga tempo estis multe pli alta.
La procezo elekti OTP por malŝalti 2FA uzante la ilon "Burp: Entrudiĝinto".
rezulto
Ĝenerale, MCS ŝajnas esti sekura kiel produkto. Dum la revizio, la pentesting-teamo ne povis akiri aliron al klientaj VMs kaj iliaj datumoj, kaj la vundeblecoj trovitaj estis rapide korektitaj de la MCS-teamo.
Sed ĉi tie gravas noti, ke sekureco estas kontinua laboro. Servoj ne estas senmovaj, ili konstante evoluas. Kaj estas neeble disvolvi produkton tute sen vundeblecoj. Sed vi povas trovi ilin ĝustatempe kaj minimumigi la ŝancon de ilia ripetiĝo.
Nun ĉiuj menciitaj vundeblecoj en MCS jam estis riparitaj. Kaj por minimumigi la nombron da novaj kaj redukti ilian vivdaŭron, la platforma teamo daŭre faras tion:
- regule fari reviziojn de eksteraj kompanioj;
- subteni kaj disvolvi partoprenon;
- okupiĝi pri sekureco. 🙂
fonto: www.habr.com