Egilea: SeerLight
Edozein zerbitzu eraikitzeak segurtasunari buruzko etengabeko lana dakar nahitaez. Segurtasuna etengabeko prozesu bat da, produktuen segurtasunaren etengabeko azterketa eta hobekuntza, ahultasunei buruzko albisteen jarraipena eta askoz gehiago barne hartzen dituena. Auditoretzak barne. Auditoriak barnean zein kanpoko adituek egiten dituzte, eta segurtasunarekin errotik lagundu dezakete, proiektuan murgilduta ez daudelako eta gogo irekia dutelako.
Artikulua Mail.ru Cloud Solutions (MCS) taldeari hodeiko zerbitzua probatzen lagundu dioten kanpoko adituen ikuspegirik zuzenenari buruzkoa da eta aurkitu dutenari buruz. "Kanpoko indar" gisa, MCSk Segurtasun Digitalaren konpainia aukeratu zuen, informazio-segurtasun zirkuluetan duen esperientzia handiagatik ezaguna. Eta artikulu honetan kanpoko auditoria baten baitan aurkitutako ahultasun interesgarri batzuk aztertuko ditugu, zure hodeiko zerbitzu propioa sortzen duzunean arrasto bera saihesteko.
Описание продукта
hodeian azpiegitura birtualak eraikitzeko plataforma bat da. IaaS, PaaS eta garatzaileentzako prest dauden aplikazioen irudien merkatua biltzen ditu. MCS arkitektura kontuan hartuta, beharrezkoa izan zen produktuaren segurtasuna egiaztatzea arlo hauetan:
- birtualizazio ingurunearen azpiegitura babestea: hiperbistoreak, bideraketa, suebakiak;
- bezeroen azpiegitura birtualen babesa: elkarrengandik isolatzea, sarea barne, sare pribatuak SDNn;
- OpenStack eta bere osagai irekiak;
- Gure diseinuko S3;
- IAM: eredu bat duten maizter anitzeko proiektuak;
- Ikusmena (ordenagailu bidezko ikusmena): irudiekin lan egitean APIak eta ahultasunak;
- web interfazea eta web eraso klasikoak;
- PaaS osagaien ahultasunak;
- Osagai guztien APIa.
Beharbada hori da historia aurreragorako ezinbestekoa dena.
Nolako lana egin zen eta zergatik behar zen?
Segurtasun-ikuskaritzak datu pertsonalak isurtzea, informazio sentikorra aldatzea edo zerbitzuaren erabilgarritasuna eten dezaketen ahultasunak eta konfigurazio-akatsak identifikatzea du helburu.
Batez beste 1-2 hilabete irauten duen lanean zehar, ikuskariek erasotzaile potentzialen ekintzak errepikatzen dituzte eta aukeratutako zerbitzuaren bezero eta zerbitzarietan ahultasunak bilatzen dituzte. MCS hodeiko plataformaren auditoretzaren testuinguruan, helburu hauek identifikatu ziren:
- Zerbitzuan autentifikazioaren analisia. Osagai honen ahultasunek besteen kontuetan berehala sartzen lagunduko lukete.
- Kontu ezberdinen arteko eredua eta sarbide-kontrola aztertzea. Erasotzaile batentzat, beste norbaiten makina birtualera sarbidea lortzeko gaitasuna helburu desiragarria da.
- Bezeroaren aldeko ahultasunak. XSS/CSRF/CRLF/etab. Posible al da beste erabiltzaileei esteka maltzurren bidez erasotzea?
- Zerbitzariaren aldeko ahultasunak: RCE eta mota guztietako injekzioak (SQL/XXE/SSRF eta abar). Zerbitzariaren ahultasunak, oro har, zailagoak dira aurkitzea, baina erabiltzaile askoren arriskua dakar aldi berean.
- Erabiltzaile-segmentuaren isolamenduaren analisia sare mailan. Erasotzaile batentzat, isolamendu faltak asko handitzen du beste erabiltzaile batzuen aurkako eraso-azalera.
- Negozio-logika analisia. Posible al da negozioak engainatzea eta makina birtualak doan sortzea?
Proiektu honetan, "Gray-box" ereduaren arabera egin zen lana: ikuskariek zerbitzuarekin elkarreragin zuten erabiltzaile arrunten pribilegioekin, baina partzialki APIaren iturburu kodearen jabe ziren eta garatzaileekin xehetasunak argitzeko aukera izan zuten. Hau izan ohi da lan-eredu erosoena, eta aldi berean nahiko errealista: erasotzaile batek barne informazioa jaso dezake oraindik, denbora kontua baino ez da.
Ahuleziak aurkitu dira
Ikuskaria hainbat karga erabilgarria (erasoa egiteko erabiltzen den karga) ausazko lekuetara bidaltzen hasi baino lehen, beharrezkoa da gauzak nola funtzionatzen duten eta zer funtzionaltasun ematen duen ulertu. Alferrikako ariketa dela dirudi, aztertutako leku gehienetan ez baita ahultasunik egongo. Baina aplikazioaren egitura eta funtzionamenduaren logika ulertzeak eraso-bektore konplexuenak aurkitzea ahalbidetuko du.
Garrantzitsua da susmagarriak diruditen edo nolabait besteekiko oso desberdinak diren tokiak aurkitzea. Eta lehen ahultasun arriskutsua horrela aurkitu zen.
IDOR
IDOR (Insecure Direct Object Reference) ahultasunak negozio-logikan ohikoenetako bat dira, eta horri esker, batek edo besteek benetan sarbidea onartzen ez duten objektuetara sarbidea izango dute. IDOR ahultasunek kritikotasun maila ezberdineko erabiltzaile bati buruzko informazioa lortzeko aukera sortzen dute.
IDOR aukeretako bat sistemaren objektuekin ekintzak egitea da (erabiltzaileak, banku-kontuak, erosketa saskiko elementuak) objektu horietarako sarbide-identifikatzaileak manipulatuz. Horrek ondoriorik ezustekoenak dakartza. Esaterako, funtsen igorlearen kontua ordezkatzeko aukera, eta horren bidez beste erabiltzaile batzuei lapur diezaiekezu.
MCS-ren kasuan, auditoreek identifikatzaile ez-seguruekin lotutako IDOR ahultasun bat aurkitu berri dute. Erabiltzailearen kontu pertsonalean, UUID identifikatzaileak erabiltzen ziren edozein objektu atzitzeko, eta segurtasun-adituek diotenez, izugarri ez segurua zirudien (hau da, indar gordinaren erasoetatik babestuta). Baina entitate jakin batzuentzat, aplikazioaren erabiltzaileei buruzko informazioa lortzeko ohiko aurreikusten diren zenbakiak erabiltzen direla aurkitu zen. Uste dut posible zela erabiltzailearen IDa bat aldatzea, eskaera berriro bidaltzea eta horrela informazioa lortzea ACL-a saihestuz (sarbide-kontrol-zerrenda, prozesuen eta erabiltzaileen datuak sartzeko arauak).
Zerbitzariaren aldeko eskaera faltsutzea (SSRF)
OpenSource produktuen gauza ona da foro ugari dituztela, sortzen diren arazoen deskribapen tekniko zehatza eta, zortea izanez gero, irtenbidearen deskribapena. Baina txanpon honek alde bat du: ezagutzen diren ahuleziak ere zehatz deskribatzen dira. Adibidez, OpenStack foroan ahultasunen deskribapen zoragarriak daude и , arrazoiren batengatik inork konpontzeko presarik ez duena.
Aplikazioen ohiko funtzionalitate bat erabiltzaileak zerbitzariari esteka bat bidaltzeko duen gaitasuna da, zeina zerbitzariak klik egiten duen (adibidez, zehaztutako iturri batetik irudi bat deskargatzeko). Segurtasun tresnek ez badituzte estekak beraiek iragazten edo zerbitzaritik erabiltzaileei itzultzen zaizkien erantzunak, funtzionalitate hori erraz erabil dezakete erasotzaileek.
SSRF ahultasunek asko aurrera dezakete eraso baten garapena. Erasotzaileak lor ditzake:
- Erasotako sare lokalerako sarbide mugatua, adibidez, sare-segmentu jakin batzuen bidez soilik eta protokolo jakin bat erabiliz;
- sare lokalerako sarbide osoa, aplikazio mailatik garraio mailara jaistea posible bada eta, ondorioz, aplikazio mailan karga osoa kudeatzea;
- zerbitzarian tokiko fitxategiak irakurtzeko sarbidea (fitxategia:/// eskema onartzen bada);
- eta askoz gehiago.
OpenStack-en aspalditik ezagutzen da SSRF ahultasun bat, izaera “itsua” duena: zerbitzariarekin harremanetan jartzen zarenean, ez duzu erantzunik jasotzen, baina akats/atzerapen mota desberdinak jasotzen dituzu, eskaeraren emaitzaren arabera. . Horretan oinarrituta, barne sareko ostalarietan portuak eskaneatu ditzakezu, gutxietsi behar ez diren ondorio guztiekin. Adibidez, produktu batek sare korporatibotik soilik eskura daitekeen back-office API bat izan dezake. Dokumentazioarekin (ez ahaztu barrukoei buruz), erasotzaileak SSRF erabil dezake barne metodoetara sartzeko. Esate baterako, nolabait URL erabilgarrien gutxi gorabeherako zerrenda bat lortzeko gai izan bazenu, SSRF erabiliz haiek zeharkatu eta eskaera bat exekutatu dezakezu - nahiko hitz eginez, dirua kontu batetik bestera transferitu edo mugak aldatu.
Hau ez da OpenStack-en SSRF ahultasun bat aurkitzen den lehen aldia. Iraganean, posible zen VM ISO irudiak esteka zuzen batetik deskargatzea, eta horrek ere antzeko ondorioak ekarri zituen. Ezaugarri hau OpenStack-etik kendu da. Dirudienez, komunitateak arazoaren irtenbiderik errazena eta fidagarriena zela uste zuen.
Eta HackerOne zerbitzuaren jendaurrean eskuragarri dagoen txostena (h1), instantzia metadatuak irakurtzeko gaitasuna duen SSRF itsu bat ustiatzeak Shopify azpiegitura osorako root sarbidea dakar.
MCSn, SSRF ahultasunak antzeko funtzionalitateak zituzten bi lekutan aurkitu ziren, baina ia ezinezkoak ziren ustiatzea suebakien eta beste babes batzuengatik. Nola edo hala, MCS taldeak arazo hau konpondu zuen hala ere, komunitatearen zain egon gabe.
XSS shellak kargatu beharrean
Ehunka ikerketa idatzi arren, urtez urte XSS (cross-site scripting) erasoa da oraindik gehien web ahultasuna (edo ?).
Fitxategiak kargatzea segurtasun ikertzaile guztientzat gogokoena da. Sarritan gertatzen da script arbitrario bat (asp/jsp/php) kargatu eta OS komandoak exekutatu ditzakezula, pentesterren terminologian - "load shell". Baina ahultasun horien ospeak bi norabideetan funtzionatzen du: gogoratzen dira eta haien aurkako erremedioak garatzen dira, eta, beraz, duela gutxi "shell bat kargatzeko" probabilitatea zerora jotzen du.
Erasoko taldea (Segurtasun Digitalak ordezkatua) zortea izan zuen. Ados, zerbitzariaren MCSn deskargatutako fitxategien edukia egiaztatu zen, irudiak bakarrik onartzen ziren. Baina SVG argazki bat ere bada. Nola izan daitezke SVG irudiak arriskutsuak? JavaScript zatiak txerta ditzakezulako horietan!
Agertu zen deskargatutako fitxategiak MCS zerbitzuko erabiltzaile guztientzat eskuragarri daudela, eta horrek esan nahi du hodeiko beste erabiltzaile batzuei erasotzea posible dela, hau da, administratzaileei.
XSS eraso baten adibidea phishing saioa hasteko inprimaki batean
XSS erasoen ustiapenaren adibideak:
- Zergatik saiatu saio bat lapurtzen (batez ere gaur egun HTTP-Only cookieak nonahi daudelako, js script-en bidez lapurretatik babestuta), kargatutako scriptak baliabideen APIra berehala atzi dezake? Kasu honetan, kargak XHR eskaerak erabil ditzake zerbitzariaren konfigurazioa aldatzeko, adibidez, erasotzailearen SSH gako publikoa gehitu eta zerbitzarirako SSH sarbidea lortzeko.
- CSP politikak (edukia babesteko politika) JavaScript injektatzea debekatzen badu, erasotzaile batek hori gabe atera dezake. HTML hutsa erabiliz, webgunerako saio-inprimaki faltsu bat sortu eta administratzailearen pasahitza lapurtu phishing aurreratu honen bidez: erabiltzailearen phishing orria URL berean amaitzen da, eta erabiltzaileak detektatzeko zailagoa da.
- Azkenik, erasotzaileak antolatu dezake — ezarri Cookieak 4 KB baino handiagoak. Erabiltzaileak esteka behin baino ez du ireki behar, eta gune osoa eskuraezin bihurtzen da erabiltzaileak nabigatzailea berariaz garbitzea pentsatu arte: kasu gehienetan, web zerbitzariak uko egingo dio bezero hori onartzeari.
Ikus dezagun detektaturiko beste XSS baten adibide bat, oraingoan ustiapen adimentsuago batekin. MCS zerbitzuak suebakiaren ezarpenak taldeetan konbinatzeko aukera ematen du. Taldearen izena XSS detektatu zen lekuan. Bere berezitasuna zen bektorea ez zela berehala abiarazten, ez arauen zerrenda ikustean, talde bat ezabatzean baizik:
Hau da, eszenatokia honakoa izan zen: erasotzaile batek suebaki-arau bat sortzen du izenean "karga" duela, administratzaileak denbora gutxira ohartu eta ezabatze-prozesua hasten du. Eta hemen funtzionatzen du JS gaiztoak.
MCS garatzaileentzat, deskargatutako SVG irudietan XSS-en aurka babesteko (ezin badira bertan behera utzi), Segurtasun Digitaleko taldeak gomendatu du:
- Jarri erabiltzaileek kargatutako fitxategiak "cookieekin" zerikusirik ez duen domeinu bereizi batean. Script-a beste domeinu baten testuinguruan exekutatuko da eta ez du mehatxurik izango MCSrentzat.
- Zerbitzariaren HTTP erantzunean, bidali "Content-disposition: attachment" goiburua. Ondoren, fitxategiak arakatzaileak deskargatuko ditu eta ez dira exekutatu.
Horrez gain, orain garatzaileentzako modu asko daude eskuragarri XSS ustiapenaren arriskuak arintzeko:
- "HTTP Bakarrik" bandera erabiliz, saioko "Cookieak" goiburuak JavaScript gaiztoentzat eskuraezinak izan ditzakezu;
- askoz zailagoa izango da erasotzaile bati XSS ustiatzea;
- Angular edo React bezalako txantiloi-motor modernoek automatikoki garbitzen dituzte erabiltzailearen datuak erabiltzailearen nabigatzailean atera aurretik.
Bi faktoreko autentifikazioaren ahultasunak
Kontuaren segurtasuna hobetzeko, erabiltzaileei beti gomendatzen zaie 2FA (bi faktoreko autentifikazioa) gaitzea. Izan ere, modu eraginkorra da erasotzaile batek zerbitzu batera sartzea saihesteko, erabiltzailearen kredentzialak arriskuan jarri badira.
Baina bigarren autentifikazio-faktore bat erabiltzeak beti bermatzen al du kontuaren segurtasuna? 2FA ezarpenean segurtasun-arazo hauek daude:
- OTP kodearen indar gordinaren bilaketa (aldi bakarreko kodeak). Eragiketa sinplea izan arren, OTP indar gordinaren aurkako babes falta bezalako akatsak ere aurkitzen dituzte enpresa handiek: , .
- Sortze algoritmo ahula, adibidez hurrengo kodea aurreikusteko gaitasuna.
- Akats logikoak, hala nola, zure telefonoan beste norbaiten OTP eskatzeko gaitasuna, esaterako Shopify-tik.
MCS-ren kasuan, 2FA inplementatzen da Google Authenticator-en eta . Protokoloa bera dagoeneko denbora probatu da, baina aplikazioaren aldean kodea egiaztatzea egiaztatzea merezi du.
MCS 2FA hainbat lekutan erabiltzen da:
- Erabiltzailea autentifikatzean. Indar gordinaren aurkako babesa dago: erabiltzaileak behin-behineko pasahitza idazteko saiakera batzuk baino ez ditu egiten, eta, ondoren, sarrera blokeatzen da denbora batez. Horrek OTP indar gordina hautatzearen aukera blokeatzen du.
- Lineaz kanpoko segurtasun-kodeak sortzean 2FA egiteko, baita desgaitu ere. Hemen, ez zen indar gordineko babesik ezarri, eta horri esker, konturako pasahitza eta saio aktibo bat bazenuen, segurtasun kopiak birsortzea edo 2FA erabat desgaitzea posible zen.
Kontuan hartuta segurtasun kopiak OTP aplikazioak sortutako kate-balioen tarte berean kokatzen zirela, denbora laburrean kodea aurkitzeko aukera askoz handiagoa zen.
2FA desgaitzeko OTP bat hautatzeko prozesua "Burp: Intruder" tresna erabiliz
Emaitza
Orokorrean, MCS produktu gisa segurua dela dirudi. Ikuskaritzan zehar, pentesting-taldeak ezin izan ditu bezeroen VM-ak eta haien datuak atzitu, eta aurkitutako ahuleziak azkar zuzendu ditu MCS taldeak.
Baina hemen garrantzitsua da segurtasuna etengabeko lan bat dela. Zerbitzuak ez dira estatikoak, etengabe garatzen ari dira. Eta ezinezkoa da produktu bat erabat garatzea ahultasunik gabe. Baina garaiz aurki ditzakezu eta errepikatzeko aukera gutxitu.
Orain MCSn aipatutako ahultasun guztiak konpondu dira dagoeneko. Eta berrien kopurua murrizteko eta haien bizitza murrizteko, plataformako taldeak hau egiten jarraitzen du:
- aldizka kanpoko enpresen auditoriak egitea;
- parte-hartzea lagundu eta garatzea;
- segurtasunean aritzea. 🙂
Iturria: www.habr.com