troch SeerLight
It bouwen fan elke tsjinst omfettet needsaaklik konstant wurk oan feiligens. Feiligens is in trochgeand proses dat konstante analyze en ferbettering fan produktfeiligens omfettet, it kontrolearjen fan nijs oer kwetsberens en folle mear. Ynklusyf audits. Audits wurde útfierd sawol yn eigen hûs as troch eksterne saakkundigen, dy't kinne radikaal helpe mei feiligens omdat se net ûnderdompele yn it projekt en hawwe in iepen geast.
It artikel giet oer dizze meast rjochtlinige werjefte fan eksterne saakkundigen dy't holpen it Mail.ru Cloud Solutions (MCS) team test de wolk tsjinst, en oer wat se fûn. As "eksterne krêft" keas MCS it bedriuw Digital Security, bekend om har hege saakkundigens yn sirkels fan ynformaasjefeiligens. En yn dit artikel sille wy wat nijsgjirrige kwetsberens analysearje fûn as ûnderdiel fan in eksterne kontrôle - sadat jo deselde rake foarkomme as jo jo eigen wolktsjinst oanmeitsje.
Produkt Description
is in platfoarm foar it bouwen fan firtuele ynfrastruktuer yn 'e wolk. It omfettet IaaS, PaaS, en in merkplak fan klearmakke applikaasjeôfbyldings foar ûntwikkelders. Mei it rekkenjen fan de MCS-arsjitektuer wie it nedich om de feiligens fan it produkt te kontrolearjen yn 'e folgjende gebieten:
- it beskermjen fan de ynfrastruktuer fan 'e virtualisaasjeomjouwing: hypervisors, routing, firewalls;
- beskerming fan de firtuele ynfrastruktuer fan klanten: isolaasje fan elkoar, ynklusyf netwurk, privee netwurken yn SDN;
- OpenStack en syn iepen komponinten;
- S3 fan ús eigen ûntwerp;
- IAM: projekten mei meardere hierders mei in rolmodel;
- Fyzje (kompjûterfisy): API's en kwetsberens by it wurkjen mei ôfbyldings;
- webynterface en klassike weboanfallen;
- kwetsberens fan PaaS-komponinten;
- API fan alle komponinten.
Miskien is dat alles wat essinsjeel is foar fierdere skiednis.
Wat foar wurk waard útfierd en wêrom wie it nedich?
In befeiligingskontrôle is rjochte op it identifisearjen fan kwetsberens en konfiguraasjeflaters dy't liede kinne ta lekkage fan persoanlike gegevens, wiziging fan gefoelige ynformaasje, of fersteuring fan beskikberens fan tsjinsten.
Tidens it wurk, dat yn trochsneed 1-2 moannen duorret, werhelje auditors de aksjes fan potensjele oanfallers en sykje nei kwetsberens yn 'e kliïnt- en serverdielen fan' e selekteare tsjinst. Yn it ramt fan 'e kontrôle fan it MCS-wolkplatfoarm waarden de folgjende doelen identifisearre:
- Analyse fan autentikaasje yn 'e tsjinst. Kwetsberheden yn dizze komponint soene helpe om fuortendaliks yn 'e akkounts fan oaren te kommen.
- It studearjen fan it rolmodel en tagongskontrôle tusken ferskate akkounts. Foar in oanfaller is de mooglikheid om tagong te krijen ta de firtuele masine fan in oar in winsklik doel.
- Kwetsberheden oan de kant fan de klant. XSS/CSRF/CRLF/etc. Is it mooglik om oare brûkers oan te fallen fia kweade keppelings?
- Tsjinnerside-kwetsberheden: RCE en alle soarten ynjeksjes (SQL / XXE / SSRF ensafuorthinne). Tsjinner-kwetsberheden binne oer it algemien dreger te finen, mar se liede ta it kompromis fan in protte brûkers tagelyk.
- Analyse fan brûker segment isolaasje op it netwurk nivo. Foar in oanfaller fergruttet it gebrek oan isolemint it oanfalsflak tsjin oare brûkers sterk.
- Business logika analyze. Is it mooglik om bedriuwen te ferrifeljen en firtuele masines fergees te meitsjen?
Yn dit projekt waard wurk útfierd neffens it model "Gray-box": auditors hawwe ynteraksje mei de tsjinst mei de privileezjes fan gewoane brûkers, mar hawwe foar in part de boarnekoade fan 'e API en hiene de kâns om details te ferdúdlikjen mei de ûntwikkelders. Dit is meastal it meast handige, en tagelyk frij realistyske model fan wurk: ynterne ynformaasje kin noch wurde sammele troch in oanfaller, it is mar in kwestje fan tiid.
Kwetsberheden fûn
Foardat de auditor begjint mei it ferstjoeren fan ferskate ladingen (de lading dy't brûkt wurdt om de oanfal út te fieren) nei willekeurige plakken, is it nedich om te begripen hoe't dingen wurkje en hokker funksjonaliteit wurdt levere. It kin lykje dat dit in nutteleaze oefening is, om't yn 'e measte ûndersochte plakken gjin kwetsberens sille wêze. Mar allinich it begripen fan 'e struktuer fan' e applikaasje en de logika fan har wurking sil it mooglik meitsje om de meast komplekse oanfalfektors te finen.
It is wichtich om plakken te finen dy't fertocht lykje of op ien of oare manier hiel oars binne fan oaren. En de earste gefaarlike kwetsberens waard op dizze manier fûn.
IDOR
IDOR (Insecure Direct Object Reference)-kwetsberheden binne ien fan 'e meast foarkommende kwetsberens yn bedriuwslogika, wêrtroch ien of oare tagong kin krije ta objekten dêr't tagong eins net tastien is. IDOR-kwetsberheden meitsje de mooglikheid om ynformaasje te krijen oer in brûker fan ferskate graden fan krityk.
Ien fan 'e IDOR-opsjes is om aksjes út te fieren mei systeemobjekten (brûkers, bankrekken, items yn' e winkelkarre) troch tagongsidentifikatoren foar dizze objekten te manipulearjen. Dit liedt ta de meast ûnfoarspelbere gefolgen. Bygelyks de mooglikheid om it akkount fan 'e stjoerder fan fûnsen te ferfangen, wêrmei jo se fan oare brûkers kinne stelle.
Yn it gefal fan MCS ûntdutsen auditors krekt in IDOR-kwetsberens ferbûn mei net-feilige identifiers. Yn it persoanlike akkount fan 'e brûker waarden UUID-identifikaasjes brûkt om tagong te krijen ta alle objekten, dy't, lykas feiligenseksperts sizze, yndrukwekkend ûnfeilich like (dat is, beskerme tsjin brute krêft oanfallen). Mar foar bepaalde entiteiten waard ûntdutsen dat reguliere foarsisbere nûmers wurde brûkt om ynformaasje te krijen oer de brûkers fan 'e applikaasje. Ik tink dat jo kinne riede dat it mooglik wie om de brûkers-ID troch ien te feroarjen, it fersyk opnij te stjoeren en sadwaande ynformaasje te krijen dy't de ACL (tagongskontrôlelist, regels foar gegevenstagong foar prosessen en brûkers) omgean.
Server Side Request Forgery (SSRF)
It goede ding oer OpenSource-produkten is dat se in enoarm oantal foarums hawwe mei detaillearre technyske beskriuwingen fan 'e problemen dy't ûntsteane en, as jo gelok binne, in beskriuwing fan' e oplossing. Mar dizze munt hat in oare kant: bekende kwetsberens wurde ek yn detail beskreaun. Bygelyks binne d'r prachtige beskriuwingen fan kwetsberens op it OpenStack-foarum и , dy't om ien of oare reden gjinien hat haast om te reparearjen.
In mienskiplike funksjonaliteit fan applikaasjes is de mooglikheid foar de brûker om in keppeling nei de tsjinner te stjoeren, dêr't de tsjinner op klikt (bygelyks om in ôfbylding te downloaden fan in opjûne boarne). As befeiligingsynstruminten de keppelings sels net filterje of de antwurden dy't fan 'e tsjinner nei brûkers weromkomme, kin sokke funksjonaliteit maklik brûkt wurde troch oanfallers.
SSRF-kwetsberheden kinne de ûntwikkeling fan in oanfal sterk befoarderje. In oanfaller kin krije:
- beheinde tagong ta it oanfallen lokale netwurk, bygelyks allinich troch bepaalde netwurksegminten en mei in bepaald protokol;
- folsleine tagong ta it lokale netwurk, as downgrading fan it tapassingsnivo nei it ferfiernivo mooglik is en, as gefolch, folsleine ladingbehear op it tapassingsnivo;
- tagong ta it lêzen fan lokale bestannen op 'e tsjinner (as it triem:///-skema wurdt stipe);
- en folle mear.
In SSRF-kwetsberens is al lang bekend yn OpenStack, dy't "blyn" fan aard is: as jo kontakt opnimme mei de tsjinner, krije jo gjin antwurd derfan, mar jo krije ferskate soarten flaters / fertragingen, ôfhinklik fan it resultaat fan it fersyk . Op grûn dêrfan kinne jo in poarte-scan útfiere op hosts op it ynterne netwurk, mei alle dêropfolgjende gefolgen dy't net ûnderskat wurde moatte. Bygelyks, in produkt kin in back-office API hawwe dy't allinich tagonklik is fan it bedriuwsnetwurk. Mei dokumintaasje (ferjit net oer ynsiders), kin in oanfaller SSRF brûke om tagong te krijen ta ynterne metoaden. Bygelyks, as jo op ien of oare manier in ûngefear list mei nuttige URL's kinne krije, dan kinne jo mei SSRF troch har gean en in fersyk útfiere - relatyf sprutsen, jild oermeitsje fan akkount nei akkount of limiten feroarje.
Dit is net de earste kear dat in SSRF-kwetsberens is ûntdutsen yn OpenStack. Yn it ferline wie it mooglik om VM ISO-ôfbyldings te downloaden fan in direkte keppeling, wat ek liede ta ferlykbere gefolgen. Dizze funksje is no fuortsmiten fan OpenStack. Blykber beskôge de mienskip dit de ienfâldichste en betrouberste oplossing foar it probleem.
En yn iepenbier beskikber rapport fan de HackerOne tsjinst (h1), eksploitaasje fan in net langer bline SSRF mei de mooglikheid om te lêzen eksimplaar metadata liedt ta Root tagong ta de hiele Shopify ynfrastruktuer.
Yn MCS waarden SSRF-kwetsberheden ûntdutsen op twa plakken mei ferlykbere funksjonaliteit, mar se wiene hast ûnmooglik om te eksploitearjen fanwege firewalls en oare beskermingen. Op ien of oare manier reparearre it MCS-team dit probleem dochs, sûnder op de mienskip te wachtsjen.
XSS ynstee fan it laden fan skelpen
Nettsjinsteande hûnderten stúdzjes skreaun, jier nei jier XSS (cross-site scripting) oanfal is noch altyd it meast web kwetsberens (of ?).
Bestânsuploads binne in favoryt plak foar elke feiligensûndersiker. It docht faak bliken dat jo in willekeurige skript (asp/jsp/php) kinne lade en OS-kommando's útfiere, yn 'e terminology fan pentesters - "load shell". Mar de populariteit fan sokke kwetsberens wurket yn beide rjochtingen: se wurde ûnthâlden en remedies wurde ûntwikkele tsjin harren, sadat koartlyn de kâns fan "laden in shell" tend to nul.
It oanfalsteam (fertsjintwurdige troch Digital Security) hie gelok. OK, yn MCS oan 'e serverkant waard de ynhâld fan' e ynladen bestannen kontrolearre, allinich ôfbyldings waarden tastien. Mar SVG is ek in foto. Hoe kinne SVG-ôfbyldings gefaarlik wêze? Om't jo JavaScript-snippets yn har kinne ynbêde!
It die bliken dat de ynladen bestannen beskikber binne foar alle brûkers fan 'e MCS-tsjinst, wat betsjut dat it mooglik is om oare wolkbrûkers oan te fallen, nammentlik behearders.
In foarbyld fan in XSS-oanfal op in phishing-oanmeldingsformulier
Foarbylden fan eksploitaasje fan XSS-oanfal:
- Wêrom besykje in sesje te stellen (benammen om't no HTTP-allinich cookies oeral binne, beskerme tsjin stellerij mei js-skripts), as it laden skript direkt tagong kin ta de boarne API? Yn dit gefal kin de loadload XHR-oanfragen brûke om de serverkonfiguraasje te feroarjen, bygelyks de iepenbiere SSH-kaai fan 'e oanfaller taheakje en SSH tagong krije ta de tsjinner.
- As it CSP-belied (belied foar ynhâldbeskerming) it ynjeksje fan JavaSkript ferbiedt, kin in oanfaller sûnder it trochkomme. Mei help fan suver HTML, meitsje in falsk oanmeldformulier foar de side en stelle it wachtwurd fan de behearder fia dizze avansearre phishing: de phishing-side foar de brûker einiget op deselde URL, en it is dreger foar de brûker om it te ûntdekken.
- Uteinlik kin de oanfaller regelje - ynstelle Cookies grutter dan 4 KB. De brûker moat de keppeling mar ien kear iepenje, en de heule side wurdt ûnberikber oant de brûker tinkt om spesifyk de blêder skjin te meitsjen: yn 'e grutte mearderheid fan' e gefallen sil de webtsjinner wegerje sa'n kliïnt te akseptearjen.
Litte wy nei in foarbyld sjen fan in oare ûntdutsen XSS, dizze kear mei in slimmer eksploitaasje. De MCS-tsjinst lit jo firewallynstellingen kombinearje yn groepen. De groepnamme wie wêr't de XSS waard ûntdutsen. De eigenaardichheid dêrfan wie dat de fektor net fuortendaliks aktivearre waard, net by it besjen fan de list mei regels, mar by it wiskjen fan in groep:
Dat is, it senario blykte it folgjende te wêzen: in oanfaller makket in firewall-regel mei "load" yn 'e namme, de behearder merkt it nei in skoftke op en begjint it wiskjen. En dit is wêr't de kweade JS wurket.
Foar MCS-ûntwikkelders, om te beskermjen tsjin XSS yn ynladen SVG-ôfbyldings (as se net kinne wurde ferlitten), advisearre it Digital Security-team:
- Plak bestannen uploade troch brûkers op in apart domein dat neat te krijen hat mei "cookies". It skript sil wurde útfierd yn 'e kontekst fan in oar domein en sil gjin bedriging foar MCS foarmje.
- Stjoer yn it HTTP-antwurd fan 'e tsjinner de koptekst "Ynhâld-disposysje: taheaksel". Dan wurde de bestannen ynladen troch de browser en net útfierd.
Derneist binne d'r no in protte manieren beskikber foar ûntwikkelders om de risiko's fan XSS-eksploitaasje te ferminderjen:
- mei help fan de "HTTP Only" flagge, kinne jo meitsje sesje "Cookies" headers ûnberikber foar kweade JavaSkript;
- sil it folle dreger meitsje foar in oanfaller om XSS te eksploitearjen;
- moderne sjabloanmotoren lykas Angular of React reinigje brûkersgegevens automatysk foardat se it útfiere nei de browser fan 'e brûker.
Twa-faktor autentikaasje kwetsberens
Om akkountfeiligens te ferbetterjen, wurde brûkers altyd advisearre om 2FA (twa-faktor-autentikaasje) yn te skeakeljen. Ja, dit is in effektive manier om te foarkommen dat in oanfaller tagong krijt ta in tsjinst as de referinsjes fan 'e brûker kompromittearre binne.
Mar garandearret it brûken fan in twadde autentikaasjefaktor altyd accountfeiligens? D'r binne de folgjende feiligensproblemen yn 'e ymplemintaasje fan 2FA:
- Brute-force sykjen fan 'e OTP-koade (ienmalige koades). Nettsjinsteande de ienfâld fan operaasje, flaters lykas gebrek oan beskerming tsjin OTP brute krêft wurde ek tsjinkaam troch grutte bedriuwen: , .
- Swak generaasje algoritme, bygelyks de mooglikheid om foarsizze de folgjende koade.
- Logyske flaters, lykas de mooglikheid om in oar syn OTP op jo tillefoan oan te freegjen, lykas dit fan Shopify.
Yn it gefal fan MCS wurdt 2FA ymplementearre basearre op Google Authenticator en . It protokol sels is al yn 'e tiid hifke, mar de ymplemintaasje fan koadeferifikaasje oan' e applikaasjekant is it wurdich te kontrolearjen.
MCS 2FA wurdt op ferskate plakken brûkt:
- By it ferifiearjen fan de brûker. D'r is beskerming tsjin brute krêft: de brûker hat mar in pear besykjen om in ienmalige wachtwurd yn te fieren, dan wurdt de ynfier foar in skoft blokkearre. Dit blokkearret de mooglikheid fan brute-force seleksje fan OTP.
- By it generearjen fan offline backupkoades om 2FA út te fieren, lykas it útskeakelje. Hjir waard gjin brute krêft beskerming ymplementearre, wat it mooglik makke, as jo in wachtwurd foar it akkount en in aktive sesje hiene, om reservekopykoades te regenerearjen of 2FA folslein út te skeakeljen.
Yn betinken nommen dat de reservekopy koades wiene te finen yn itselde berik fan string wearden as dy generearre troch de OTP applikaasje, de kâns om te finen de koade yn in koarte tiid wie folle heger.
It proses fan it selektearjen fan in OTP om 2FA út te skeakeljen mei it ark "Burp: Intruder".
resultaat
Oer it algemien liket MCS feilich te wêzen as produkt. Tidens de kontrôle koe it pentestingteam gjin tagong krije ta VM's fan kliïnten en har gegevens, en de fûnearingen waarden rap korrizjearre troch it MCS-team.
Mar hjir is it wichtich om te merken dat feiligens in kontinu wurk is. Tsjinsten binne net statysk, se wurde hieltyd yn ûntwikkeling. En it is ûnmooglik om in produkt folslein te ûntwikkeljen sûnder kwetsberens. Mar jo kinne se op 'e tiid fine en de kâns op har werhelling minimalisearje.
No binne alle neamde kwetsberens yn MCS al reparearre. En om it oantal nijen op in minimum te hâlden en har libben te ferminderjen, bliuwt it platfoarmteam dit dwaan:
- regelmjittich audits útfiere troch eksterne bedriuwen;
- stypje en ûntwikkeljen fan partisipaasje;
- dwaande hâlde mei feiligens. 🙂
Boarne: www.habr.com