deur SeerLight
Om enige diens te bou, sluit noodwendig konstante werk aan sekuriteit in. Sekuriteit is 'n deurlopende proses wat konstante ontleding en verbetering van produksekuriteit, monitering van nuus oor kwesbaarhede en nog baie meer insluit. Oudits ingesluit. Oudits word sowel intern as deur eksterne kundiges uitgevoer, wat radikaal kan help met sekuriteit omdat hulle nie in die projek gedompel is nie en 'n oop gemoed het.
Die artikel handel oor hierdie eenvoudigste siening van eksterne kundiges wat die Mail.ru Cloud Solutions (MCS)-span gehelp het om die wolkdiens te toets, en oor wat hulle gevind het. As 'n "eksterne mag" het MCS die Digital Security-maatskappy gekies, bekend vir sy hoë kundigheid in inligtingsekuriteitskringe. En in hierdie artikel sal ons 'n paar interessante kwesbaarhede ontleed wat as deel van 'n eksterne oudit gevind is - sodat jy dieselfde hark vermy wanneer jy jou eie wolkdiens skep.
Описание продукта
is 'n platform vir die bou van virtuele infrastruktuur in die wolk. Dit sluit IaaS, PaaS en 'n markplek van klaargemaakte toepassingsbeelde vir ontwikkelaars in. Met inagneming van die MCS-argitektuur, was dit nodig om die veiligheid van die produk op die volgende gebiede na te gaan:
- die beskerming van die infrastruktuur van die virtualiseringsomgewing: hiperviseerders, roetering, brandmure;
- beskerming van kliënte se virtuele infrastruktuur: isolasie van mekaar, insluitend netwerk, private netwerke in SDN;
- OpenStack en sy oop komponente;
- S3 van ons eie ontwerp;
- IAM: multi-huurder projekte met 'n rolmodel;
- Visie (rekenaarvisie): API's en kwesbaarhede wanneer daar met beelde gewerk word;
- webkoppelvlak en klassieke webaanvalle;
- kwesbaarhede van PaaS-komponente;
- API van alle komponente.
Miskien is dit al wat noodsaaklik is vir verdere geskiedenis.
Watter soort werk is uitgevoer en hoekom was dit nodig?
’n Sekuriteitsoudit is daarop gemik om kwesbaarhede en konfigurasiefoute te identifiseer wat kan lei tot lekkasie van persoonlike data, wysiging van sensitiewe inligting of ontwrigting van diensbeskikbaarheid.
Tydens die werk, wat gemiddeld 1-2 maande duur, herhaal ouditeure die optrede van potensiële aanvallers en soek na kwesbaarhede in die kliënt- en bedienerdele van die geselekteerde diens. In die konteks van die oudit van die MCS-wolkplatform is die volgende doelwitte geïdentifiseer:
- Ontleding van verifikasie in die diens. Kwesbaarhede in hierdie komponent sal help om onmiddellik in ander mense se rekeninge te kom.
- Bestudeer die rolmodel en toegangsbeheer tussen verskillende rekeninge. Vir 'n aanvaller is die vermoë om toegang tot iemand anders se virtuele masjien te kry 'n wenslike doelwit.
- Kliëntkant kwesbaarhede. XSS/CSRF/CRLF/ens. Is dit moontlik om ander gebruikers aan te val deur middel van kwaadwillige skakels?
- Bedienerkant-kwesbaarhede: RCE en alle soorte inspuitings (SQL/XXE/SSRF ensovoorts). Bedienerkwesbaarhede is oor die algemeen moeiliker om te vind, maar dit lei tot die kompromie van baie gebruikers gelyktydig.
- Ontleding van gebruikerssegment-isolasie op netwerkvlak. Vir 'n aanvaller verhoog die gebrek aan isolasie die aanvaloppervlak teen ander gebruikers aansienlik.
- Besigheidslogika-analise. Is dit moontlik om besighede te mislei en virtuele masjiene gratis te skep?
In hierdie projek is werk volgens die "Grey-box"-model uitgevoer: ouditeure het interaksie met die diens gehad met die voorregte van gewone gebruikers, maar het gedeeltelik die bronkode van die API besit en het die geleentheid gehad om besonderhede met die ontwikkelaars uit te klaar. Dit is gewoonlik die gerieflikste, en terselfdertyd redelik realistiese werksmodel: interne inligting kan steeds deur 'n aanvaller ingesamel word, dit is net 'n kwessie van tyd.
Kwesbaarhede gevind
Voordat die ouditeur verskeie loonvragte (die loonvrag wat gebruik word om die aanval uit te voer) na ewekansige plekke begin stuur, is dit nodig om te verstaan hoe dinge werk en watter funksionaliteit verskaf word. Dit mag lyk asof dit 'n nuttelose oefening is, want in die meeste van die bestudeerde plekke sal daar geen kwesbaarhede wees nie. Maar slegs om die struktuur van die toepassing en die logika van die werking daarvan te verstaan, sal dit moontlik maak om die mees komplekse aanvalsvektore te vind.
Dit is belangrik om plekke te vind wat verdag lyk of op een of ander manier baie verskil van ander. En die eerste gevaarlike kwesbaarheid is op hierdie manier gevind.
IDOR
IDOR (Insecure Direct Object Reference) kwesbaarhede is een van die mees algemene kwesbaarhede in besigheidslogika, wat die een of ander toelaat om toegang te verkry tot voorwerpe waartoe toegang nie eintlik toegelaat word nie. IDOR-kwesbaarhede skep die moontlikheid om inligting oor 'n gebruiker van verskillende grade van kritiek te bekom.
Een van die IDOR-opsies is om aksies met stelselvoorwerpe (gebruikers, bankrekeninge, items in die inkopiemandjie) uit te voer deur toegangsidentifiseerders tot hierdie voorwerpe te manipuleer. Dit lei tot die mees onvoorspelbare gevolge. Byvoorbeeld, die moontlikheid om die rekening van die sender van fondse te vervang, waardeur u dit van ander gebruikers kan steel.
In die geval van MCS het ouditeure sopas 'n IDOR-kwesbaarheid ontdek wat verband hou met nie-veilige identifiseerders. In die gebruiker se persoonlike rekening is UUID-identifiseerders gebruik om toegang tot enige voorwerpe te verkry, wat, soos sekuriteitskenners sê, indrukwekkend onseker gelyk het (dit wil sê, beskerm teen brute kragaanvalle). Maar vir sekere entiteite is ontdek dat gereelde voorspelbare getalle gebruik word om inligting oor die gebruikers van die toepassing te bekom. Ek dink jy kan raai dat dit moontlik was om die gebruikers-ID met een te verander, die versoek weer te stuur en sodoende inligting te verkry wat die ACL (toegangsbeheerlys, datatoegangsreëls vir prosesse en gebruikers) omseil.
Server Side Request Forgery (SSRF)
Die goeie ding van OpenSource-produkte is dat hulle 'n groot aantal forums het met gedetailleerde tegniese beskrywings van die probleme wat opduik en, as jy gelukkig is, 'n beskrywing van die oplossing. Maar hierdie muntstuk het 'n keersy: bekende kwesbaarhede word ook in detail beskryf. Daar is byvoorbeeld wonderlike beskrywings van kwesbaarhede op die OpenStack-forum и , wat om een of ander rede niemand haastig is om reg te maak nie.
'n Algemene funksionaliteit van toepassings is die vermoë vir die gebruiker om 'n skakel na die bediener te stuur, waarop die bediener klik (byvoorbeeld om 'n prent van 'n gespesifiseerde bron af te laai). As sekuriteitsnutsmiddels nie die skakels self filtreer of die antwoorde wat van die bediener af aan gebruikers teruggestuur word nie, kan sulke funksionaliteit maklik deur aanvallers gebruik word.
SSRF-kwesbaarhede kan die ontwikkeling van 'n aanval aansienlik bevorder. 'n Aanvaller kan kry:
- beperkte toegang tot die aangeval plaaslike netwerk, byvoorbeeld slegs deur sekere netwerksegmente en met behulp van 'n sekere protokol;
- volle toegang tot die plaaslike netwerk, indien afgradering van toepassingsvlak na vervoervlak moontlik is en gevolglik volle vragbestuur op toepassingsvlak;
- toegang om plaaslike lêers op die bediener te lees (indien die lêer:///-skema ondersteun word);
- en nog baie meer.
'n SSRF-kwesbaarheid is lank reeds bekend in OpenStack, wat "blind" van aard is: wanneer jy die bediener kontak, ontvang jy nie 'n reaksie daarvan nie, maar jy ontvang verskillende tipes foute/vertragings, afhangende van die resultaat van die versoek . Op grond hiervan kan u 'n poortskandering op gashere op die interne netwerk uitvoer, met al die gevolge wat nie onderskat moet word nie. Byvoorbeeld, 'n produk kan 'n back-office API hê wat slegs vanaf die korporatiewe netwerk toeganklik is. Met dokumentasie (moenie van insiders vergeet nie), kan 'n aanvaller SSRF gebruik om toegang tot interne metodes te verkry. Byvoorbeeld, as jy op een of ander manier in staat was om 'n benaderde lys van nuttige URL's te kry, dan kan jy met behulp van SSRF deur hulle gaan en 'n versoek uitvoer - relatief gesproke, geld van rekening na rekening oordra of limiete verander.
Dit is nie die eerste keer dat 'n SSRF-kwesbaarheid in OpenStack ontdek is nie. In die verlede was dit moontlik om VM ISO-beelde vanaf 'n direkte skakel af te laai, wat ook tot soortgelyke gevolge gelei het. Hierdie kenmerk is nou van OpenStack verwyder. Blykbaar het die gemeenskap dit as die eenvoudigste en betroubaarste oplossing vir die probleem beskou.
En in publiek beskikbare verslag van die HackerOne-diens (h1), uitbuiting van 'n nie meer blinde SSRF met die vermoë om instansie-metadata te lees, lei tot worteltoegang tot die hele Shopify-infrastruktuur.
In MCS is SSRF-kwesbaarhede op twee plekke met soortgelyke funksionaliteit ontdek, maar dit was byna onmoontlik om te ontgin as gevolg van brandmure en ander beskerming. Op die een of ander manier het die MCS-span hierdie probleem in elk geval opgelos, sonder om vir die gemeenskap te wag.
XSS in plaas van om skulpe te laai
Ten spyte van honderde studies geskryf, jaar na jaar is XSS (cross-site scripting) aanval steeds die meeste webkwesbaarheid (of ?).
Lêeroplaaie is 'n gunstelingplek vir enige sekuriteitsnavorser. Dit blyk dikwels dat jy 'n arbitrêre skrif (asp/jsp/php) kan laai en OS-opdragte kan uitvoer, in die terminologie van pentesters - "load shell". Maar die gewildheid van sulke kwesbaarhede werk in beide rigtings: hulle word onthou en middels word daarteen ontwikkel, sodat die waarskynlikheid onlangs om "'n dop te laai" neig na nul.
Die aanvallende span (verteenwoordig deur Digital Security) was gelukkig. OK, in MCS aan die bedienerkant is die inhoud van die afgelaaide lêers nagegaan, slegs beelde is toegelaat. Maar SVG is ook 'n prentjie. Hoe kan SVG-beelde gevaarlik wees? Omdat jy JavaScript-brokkies daarin kan insluit!
Dit het geblyk dat die afgelaaide lêers vir alle gebruikers van die MCS-diens beskikbaar is, wat beteken dat dit moontlik is om ander wolkgebruikers, naamlik administrateurs, aan te val.
'n Voorbeeld van 'n XSS-aanval op 'n phishing-aanmeldvorm
Voorbeelde van XSS-aanval-uitbuiting:
- Hoekom probeer om 'n sessie te steel (veral aangesien HTTP-Net-koekies nou oral is, beskerm teen diefstal met behulp van js-skrifte), as die gelaaide skrip onmiddellik toegang tot die hulpbron-API het? In hierdie geval kan die loonvrag XHR-versoeke gebruik om die bedienerkonfigurasie te verander, byvoorbeeld, voeg die aanvaller se publieke SSH-sleutel by en kry SSH-toegang tot die bediener.
- As die CSP-beleid (inhoudbeskermingsbeleid) verbied dat JavaScript ingespuit word, kan 'n aanvaller daarsonder klaarkom. Gebruik suiwer HTML, skep 'n vals aanmeldvorm vir die webwerf en steel die administrateur se wagwoord deur hierdie gevorderde uitvissing: die uitvissingbladsy vir die gebruiker eindig op dieselfde URL, en dit is moeiliker vir die gebruiker om dit op te spoor.
- Uiteindelik kan die aanvaller reël - stel koekies groter as 4 KB. Die gebruiker hoef die skakel net een keer oop te maak, en die hele webwerf word ontoeganklik totdat die gebruiker dink om spesifiek die blaaier skoon te maak: in die oorgrote meerderheid van gevalle sal die webbediener weier om so 'n kliënt te aanvaar.
Kom ons kyk na 'n voorbeeld van 'n ander bespeurde XSS, hierdie keer met 'n meer slim uitbuiting. Die MCS-diens laat jou toe om firewall-instellings in groepe te kombineer. Die groepnaam was waar die XSS opgespoor is. Die eienaardigheid daarvan was dat die vektor nie onmiddellik geaktiveer is nie, nie wanneer die lys reëls bekyk word nie, maar wanneer 'n groep uitgevee is:
Dit wil sê, die scenario blyk die volgende te wees: 'n aanvaller skep 'n firewall-reël met "load" in die naam, die administrateur merk dit na 'n rukkie op en begin die uitveeproses. En dit is waar die kwaadwillige JS werk.
Vir MCS-ontwikkelaars, om teen XSS in afgelaaide SVG-beelde te beskerm (indien hulle nie laat vaar kan word nie), het die Digital Security-span aanbeveel:
- Plaas lêers wat deur gebruikers opgelaai is op 'n aparte domein wat niks met "koekies" te doen het nie. Die skrip sal in die konteks van 'n ander domein uitgevoer word en sal nie 'n bedreiging vir MCS inhou nie.
- In die bediener se HTTP-antwoord, stuur die "Content-disposition: attachment"-kopskrif. Dan sal die lêers deur die blaaier afgelaai word en nie uitgevoer word nie.
Daarbenewens is daar nou baie maniere beskikbaar vir ontwikkelaars om die risiko's van XSS-uitbuiting te versag:
- deur die “Slegs HTTP-vlag” te gebruik, kan jy sessie-“Koekies”-opskrifte ontoeganklik maak vir kwaadwillige JavaScript;
- sal dit vir 'n aanvaller baie moeiliker maak om XSS uit te buit;
- moderne sjabloonenjins soos Angular of React ontsmet outomaties gebruikersdata voordat dit na die gebruiker se blaaier uitgestuur word.
Twee-faktor verifikasie kwesbaarhede
Om rekeningsekuriteit te verbeter, word gebruikers altyd aangeraai om 2FA (tweefaktor-verifikasie) te aktiveer. Inderdaad, dit is 'n effektiewe manier om te verhoed dat 'n aanvaller toegang tot 'n diens kry as die gebruiker se geloofsbriewe gekompromitteer is.
Maar waarborg die gebruik van 'n tweede verifikasiefaktor altyd rekeningveiligheid? Daar is die volgende sekuriteitskwessies in die implementering van 2FA:
- Brute-force soektog van die OTP-kode (eenmalige kodes). Ten spyte van die eenvoud van operasie, word foute soos 'n gebrek aan beskerming teen OTP brute force ook deur groot maatskappye teëgekom: , .
- Swak generasie algoritme, byvoorbeeld die vermoë om die volgende kode te voorspel.
- Logiese foute, soos die vermoë om iemand anders se OTP op jou foon aan te vra, soos hierdie van Shopify.
In die geval van MCS word 2FA geïmplementeer op grond van Google Authenticator en . Die protokol self is reeds tydgetoets, maar die implementering van kodeverifikasie aan die toepassingskant is die moeite werd om na te gaan.
MCS 2FA word op verskeie plekke gebruik:
- Wanneer die gebruiker staaf. Daar is beskerming teen brute geweld: die gebruiker het net 'n paar pogings om 'n eenmalige wagwoord in te voer, dan word die invoer vir 'n rukkie geblokkeer. Dit blokkeer die moontlikheid van brute-force seleksie van OTP.
- Wanneer vanlyn rugsteunkodes gegenereer word om 2FA uit te voer, sowel as om dit te deaktiveer. Hier is geen brute force-beskerming geïmplementeer nie, wat dit moontlik gemaak het, as jy 'n wagwoord vir die rekening en 'n aktiewe sessie gehad het, om rugsteunkodes te herstel of 2FA heeltemal te deaktiveer.
As in ag geneem word dat die rugsteunkodes in dieselfde reeks stringwaardes geleë was as dié wat deur die OTP-toepassing gegenereer is, was die kans om die kode binne 'n kort tydjie te vind baie groter.
Die proses om 'n OTP te kies om 2FA te deaktiveer met die "Burp: Intruder"-nutsding
Gevolg
Oor die algemeen blyk MCS veilig te wees as 'n produk. Tydens die oudit kon die ondersoekende span nie toegang tot kliënt-VM'e en hul data verkry nie, en die kwesbaarhede wat gevind is, is vinnig deur die MCS-span reggestel.
Maar hier is dit belangrik om daarop te let dat sekuriteit 'n deurlopende werk is. Dienste is nie staties nie, hulle ontwikkel voortdurend. En dit is onmoontlik om 'n produk heeltemal sonder kwesbaarhede te ontwikkel. Maar jy kan hulle betyds vind en die kans op herhaling verminder.
Nou is al die genoemde kwesbaarhede in MCS reeds reggestel. En om die aantal nuwes tot 'n minimum te beperk en hul leeftyd te verminder, gaan die platformspan voort om dit te doen:
- gereeld oudits deur eksterne maatskappye uitvoer;
- ondersteun en ontwikkel deelname;
- by sekuriteit betrokke raak. 🙂
Bron: will.com