door ZienerLicht
Het bouwen van een dienst omvat noodzakelijkerwijs voortdurend werken aan de beveiliging. Beveiliging is een continu proces dat een constante analyse en verbetering van de productbeveiliging omvat, het monitoren van nieuws over kwetsbaarheden en nog veel meer. Inclusief audits. Audits worden zowel intern als door externe experts uitgevoerd, die radicaal kunnen helpen met de beveiliging omdat ze niet in het project zijn ondergedompeld en een open geest hebben.
Het artikel gaat over dit meest duidelijke standpunt van externe experts die het Mail.ru Cloud Solutions (MCS)-team hebben geholpen bij het testen van de cloudservice, en over wat ze hebben gevonden. Als ‘externe kracht’ koos MCS voor het bedrijf Digital Security, bekend om zijn grote expertise op het gebied van informatiebeveiliging. En in dit artikel zullen we enkele interessante kwetsbaarheden analyseren die zijn gevonden als onderdeel van een externe audit - zodat u dezelfde hark vermijdt wanneer u uw eigen cloudservice maakt.
Описание продукта
is een platform voor het bouwen van virtuele infrastructuur in de cloud. Het omvat IaaS, PaaS en een marktplaats met kant-en-klare applicatie-images voor ontwikkelaars. Rekening houdend met de MCS-architectuur was het noodzakelijk om de veiligheid van het product op de volgende gebieden te controleren:
- het beschermen van de infrastructuur van de virtualisatieomgeving: hypervisors, routing, firewalls;
- bescherming van de virtuele infrastructuur van klanten: isolatie van elkaar, inclusief netwerk, privénetwerken in SDN;
- OpenStack en zijn open componenten;
- S3 van ons eigen ontwerp;
- IAM: multi-tenant projecten met een rolmodel;
- Vision (computer vision): API’s en kwetsbaarheden bij het werken met afbeeldingen;
- webinterface en klassieke webaanvallen;
- kwetsbaarheden van PaaS-componenten;
- API van alle componenten.
Misschien is dat alles wat essentieel is voor de verdere geschiedenis.
Welke werkzaamheden zijn uitgevoerd en waarom was dit nodig?
Een beveiligingsaudit is gericht op het identificeren van kwetsbaarheden en configuratiefouten die kunnen leiden tot het lekken van persoonlijke gegevens, wijziging van gevoelige informatie of verstoring van de beschikbaarheid van diensten.
Tijdens de werkzaamheden, die gemiddeld 1-2 maanden duren, herhalen auditors de acties van potentiële aanvallers en zoeken ze naar kwetsbaarheden in de client- en serveronderdelen van de geselecteerde dienst. In het kader van de audit van het MCS-cloudplatform werden de volgende doelstellingen geïdentificeerd:
- Analyse van authenticatie in de dienst. Kwetsbaarheden in dit onderdeel zouden helpen om onmiddellijk in de accounts van anderen te komen.
- Het bestuderen van het rolmodel en de toegangscontrole tussen verschillende accounts. Voor een aanvaller is de mogelijkheid om toegang te krijgen tot de virtuele machine van iemand anders een wenselijk doel.
- Kwetsbaarheden aan de clientzijde. XSS/CSRF/CRLF/etc. Is het mogelijk om andere gebruikers aan te vallen via kwaadaardige links?
- Kwetsbaarheden aan de serverzijde: RCE en allerlei soorten injecties (SQL/XXE/SSRF enzovoort). Kwetsbaarheden in servers zijn over het algemeen moeilijker te vinden, maar ze leiden tot het compromitteren van veel gebruikers tegelijk.
- Analyse van de isolatie van gebruikerssegmenten op netwerkniveau. Voor een aanvaller vergroot het gebrek aan isolatie het aanvalsoppervlak tegen andere gebruikers aanzienlijk.
- Bedrijfslogica-analyse. Is het mogelijk om bedrijven te misleiden en gratis virtuele machines te creëren?
In dit project werd gewerkt volgens het “Gray-box”-model: auditors communiceerden met de dienst met de rechten van gewone gebruikers, maar beschikten gedeeltelijk over de broncode van de API en hadden de mogelijkheid om details met de ontwikkelaars te verduidelijken. Dit is meestal het handigste en tegelijkertijd redelijk realistische werkmodel: interne informatie kan nog steeds door een aanvaller worden verzameld, het is slechts een kwestie van tijd.
Kwetsbaarheden gevonden
Voordat de auditor verschillende payloads (de payload die wordt gebruikt om de aanval uit te voeren) naar willekeurige plaatsen gaat sturen, is het noodzakelijk om te begrijpen hoe dingen werken en welke functionaliteit wordt geboden. Het lijkt misschien dat dit een nutteloze oefening is, omdat er op de meeste onderzochte plaatsen geen kwetsbaarheden zullen zijn. Maar alleen het begrijpen van de structuur van de applicatie en de logica van de werking ervan zal het mogelijk maken om de meest complexe aanvalsvectoren te vinden.
Het is belangrijk om plaatsen te vinden die verdacht lijken of die op de een of andere manier heel anders zijn dan andere. En zo werd de eerste gevaarlijke kwetsbaarheid gevonden.
IDOR
IDOR-kwetsbaarheden (Insecure Direct Object Reference) zijn een van de meest voorkomende kwetsbaarheden in de bedrijfslogica, waardoor de een of de ander toegang kan krijgen tot objecten waartoe feitelijk geen toegang is toegestaan. IDOR-kwetsbaarheden creëren de mogelijkheid om informatie over een gebruiker van verschillende mate van kritiek te verkrijgen.
Eén van de IDOR-opties is het uitvoeren van acties met systeemobjecten (gebruikers, bankrekeningen, artikelen in het winkelwagentje) door toegangsidentificatoren voor deze objecten te manipuleren. Dit leidt tot de meest onvoorspelbare gevolgen. Bijvoorbeeld de mogelijkheid om de rekening van de afzender van geld te vervangen, waardoor u deze van andere gebruikers kunt stelen.
In het geval van MCS hebben auditors zojuist een IDOR-kwetsbaarheid ontdekt die verband houdt met niet-beveiligde identificatiemiddelen. In het persoonlijke account van de gebruiker werden UUID-identificatoren gebruikt om toegang te krijgen tot objecten, die, zoals beveiligingsexperts zeggen, indrukwekkend onveilig leken (dat wil zeggen beschermd tegen brute force-aanvallen). Maar voor bepaalde entiteiten werd ontdekt dat er regelmatig voorspelbare cijfers worden gebruikt om informatie te verkrijgen over de gebruikers van de applicatie. Ik denk dat je wel kunt raden dat het mogelijk was om de gebruikers-ID met één te wijzigen, het verzoek opnieuw te verzenden en zo informatie te verkrijgen die de ACL omzeilde (toegangscontrolelijst, regels voor gegevenstoegang voor processen en gebruikers).
Vervalsing van verzoeken aan serverzijde (SSRF)
Het goede aan OpenSource-producten is dat ze een groot aantal forums hebben met gedetailleerde technische beschrijvingen van de problemen die zich voordoen en, als je geluk hebt, een beschrijving van de oplossing. Maar deze medaille heeft een keerzijde: ook bekende kwetsbaarheden worden uitgebreid beschreven. Op het OpenStack-forum staan bijvoorbeeld prachtige beschrijvingen van kwetsbaarheden и , die om de een of andere reden niemand haast heeft om te repareren.
Een veel voorkomende functionaliteit van applicaties is de mogelijkheid voor de gebruiker om een link naar de server te sturen, waarop de server klikt (bijvoorbeeld om een afbeelding van een opgegeven bron te downloaden). Als beveiligingstools de links zelf of de antwoorden die van de server naar gebruikers worden geretourneerd, niet filteren, kan dergelijke functionaliteit gemakkelijk door aanvallers worden gebruikt.
SSRF-kwetsbaarheden kunnen de ontwikkeling van een aanval aanzienlijk bevorderen. Een aanvaller kan het volgende krijgen:
- beperkte toegang tot het aangevallen lokale netwerk, bijvoorbeeld alleen via bepaalde netwerksegmenten en met behulp van een bepaald protocol;
- volledige toegang tot het lokale netwerk, indien downgraden van applicatieniveau naar transportniveau mogelijk is en daardoor volledig lastbeheer op applicatieniveau;
- toegang om lokale bestanden op de server te lezen (als het file:///-schema wordt ondersteund);
- en vele andere dingen.
Er is al langer een SSRF-kwetsbaarheid bekend in OpenStack, die ‘blind’ van aard is: wanneer je contact opneemt met de server, krijg je daar geen reactie van, maar krijg je verschillende soorten fouten/vertragingen, afhankelijk van het resultaat van het verzoek . Op basis hiervan kun je een poortscan uitvoeren op hosts op het interne netwerk, met alle niet te onderschatten gevolgen van dien. Een product kan bijvoorbeeld een backoffice-API hebben die alleen toegankelijk is vanuit het bedrijfsnetwerk. Met documentatie (vergeet insiders niet) kan een aanvaller SSRF gebruiken om toegang te krijgen tot interne methoden. Als u bijvoorbeeld op de een of andere manier een geschatte lijst met nuttige URL's kunt verkrijgen, kunt u met behulp van SSRF deze doornemen en een verzoek uitvoeren - relatief gesproken, geld overboeken van account naar account of limieten wijzigen.
Dit is niet de eerste keer dat er een SSRF-kwetsbaarheid in OpenStack wordt ontdekt. In het verleden was het mogelijk om VM ISO-images te downloaden via een directe link, wat ook tot soortgelijke gevolgen leidde. Deze functie is nu verwijderd uit OpenStack. Blijkbaar beschouwde de gemeenschap dit als de eenvoudigste en meest betrouwbare oplossing voor het probleem.
En in openbaar beschikbaar rapport van de HackerOne-service (h1), de exploitatie van een niet langer blinde SSRF met de mogelijkheid om metadata van instanties te lezen, leidt tot root-toegang tot de gehele Shopify-infrastructuur.
In MCS werden SSRF-kwetsbaarheden ontdekt op twee plaatsen met vergelijkbare functionaliteit, maar deze waren vrijwel onmogelijk te misbruiken vanwege firewalls en andere beveiligingen. Op de een of andere manier heeft het MCS-team dit probleem toch opgelost, zonder op de community te wachten.
XSS in plaats van laadschalen
Ondanks honderden geschreven onderzoeken is XSS-aanval (cross-site scripting) jaar na jaar nog steeds de meest voorkomende webkwetsbaarheid (of ?).
Bestandsuploads zijn een favoriete plek voor elke beveiligingsonderzoeker. Het blijkt vaak dat je een willekeurig script (asp/jsp/php) kunt laden en OS-opdrachten kunt uitvoeren, in de terminologie van pentesters - "load shell". Maar de populariteit van dergelijke kwetsbaarheden werkt in beide richtingen: ze worden onthouden en er worden oplossingen tegen ontwikkeld, zodat de kans op het “laden van een granaat” recentelijk nul is geworden.
Het aanvallende team (vertegenwoordigd door Digital Security) had geluk. Oké, in MCS aan de serverzijde werd de inhoud van de gedownloade bestanden gecontroleerd, alleen afbeeldingen waren toegestaan. Maar SVG is ook een plaatje. Hoe kunnen SVG-afbeeldingen gevaarlijk zijn? Omdat u JavaScript-fragmenten erin kunt insluiten!
Het bleek dat de gedownloade bestanden beschikbaar zijn voor alle gebruikers van de MCS-dienst, waardoor het mogelijk is om andere cloudgebruikers, namelijk beheerders, aan te vallen.
Een voorbeeld van een XSS-aanval op een phishing-inlogformulier
Voorbeelden van exploitatie van XSS-aanvallen:
- Waarom proberen een sessie te stelen (vooral omdat HTTP-Only-cookies nu overal zijn, beschermd tegen diefstal met behulp van js-scripts), als het geladen script onmiddellijk toegang heeft tot de resource-API? In dit geval kan de payload XHR-verzoeken gebruiken om de serverconfiguratie te wijzigen, bijvoorbeeld door de openbare SSH-sleutel van de aanvaller toe te voegen en SSH-toegang tot de server te verkrijgen.
- Als het CSP-beleid (content protection policy) verbiedt dat JavaScript wordt geïnjecteerd, kan een aanvaller zonder dit beleid rondkomen. Maak met behulp van pure HTML een nep-inlogformulier voor de site en steel het beheerderswachtwoord via deze geavanceerde phishing: de phishing-pagina voor de gebruiker komt op dezelfde URL terecht, en het is voor de gebruiker moeilijker om deze te detecteren.
- Eindelijk kan de aanvaller regelen — cookies groter dan 4 KB instellen. De gebruiker hoeft de link maar één keer te openen en de hele site wordt ontoegankelijk totdat de gebruiker denkt de browser specifiek op te schonen: in de overgrote meerderheid van de gevallen zal de webserver weigeren een dergelijke client te accepteren.
Laten we eens kijken naar een voorbeeld van een andere gedetecteerde XSS, dit keer met een slimmere exploit. Met de MCS-service kunt u firewall-instellingen in groepen combineren. De groepsnaam was waar de XSS werd gedetecteerd. Het bijzondere was dat de vector niet onmiddellijk werd geactiveerd, niet bij het bekijken van de lijst met regels, maar bij het verwijderen van een groep:
Dat wil zeggen, het scenario bleek het volgende: een aanvaller maakt een firewallregel met “load” in de naam, de beheerder merkt dit na een tijdje op en start het verwijderingsproces. En dit is waar de kwaadaardige JS werkt.
Voor MCS-ontwikkelaars heeft het Digital Security-team het volgende aanbevolen om te beschermen tegen XSS in gedownloade SVG-afbeeldingen (als deze niet kunnen worden opgegeven):
- Plaats door gebruikers geüploade bestanden op een apart domein dat niets met “cookies” te maken heeft. Het script zal worden uitgevoerd in de context van een ander domein en zal geen bedreiging vormen voor MCS.
- Stuur in het HTTP-antwoord van de server de header 'Content-disposition: bijlage'. Vervolgens worden de bestanden door de browser gedownload en niet uitgevoerd.
Bovendien zijn er nu veel manieren beschikbaar voor ontwikkelaars om de risico's van XSS-exploitatie te beperken:
- met behulp van de vlag ‘Alleen HTTP’ kunt u de ‘Cookies’-headers van sessies ontoegankelijk maken voor kwaadaardig JavaScript;
- zal het voor een aanvaller veel moeilijker maken om XSS te exploiteren;
- moderne sjabloonengines zoals Angular of React zuiveren automatisch gebruikersgegevens voordat deze naar de browser van de gebruiker worden uitgevoerd.
Kwetsbaarheden in tweefactorauthenticatie
Om de accountbeveiliging te verbeteren, wordt gebruikers altijd geadviseerd om 2FA (tweefactorauthenticatie) in te schakelen. Dit is inderdaad een effectieve manier om te voorkomen dat een aanvaller toegang krijgt tot een dienst als de inloggegevens van de gebruiker zijn gecompromitteerd.
Maar garandeert het gebruik van een tweede authenticatiefactor altijd de accountveiligheid? Er zijn de volgende beveiligingsproblemen bij de implementatie van 2FA:
- Brute force zoeken naar de OTP-code (eenmalige codes). Ondanks de eenvoud van de bediening worden grote bedrijven ook geconfronteerd met fouten zoals een gebrek aan bescherming tegen OTP-brute force: , .
- Zwak generatie-algoritme, bijvoorbeeld het vermogen om de volgende code te voorspellen.
- Logische fouten, zoals de mogelijkheid om het OTP van iemand anders op uw telefoon op te vragen, zoals deze van Shopify.
In het geval van MCS wordt 2FA geïmplementeerd op basis van Google Authenticator en . Het protocol zelf is al beproefd, maar de implementatie van codeverificatie aan de applicatiekant is de moeite waard om te controleren.
MCS 2FA wordt op meerdere plekken toegepast:
- Bij het authenticeren van de gebruiker. Er is bescherming tegen brute kracht: de gebruiker krijgt slechts enkele pogingen om een eenmalig wachtwoord in te voeren, daarna wordt de invoer een tijdje geblokkeerd. Dit blokkeert de mogelijkheid van brute force-selectie van OTP.
- Bij het genereren van offline back-upcodes om 2FA uit te voeren, en bij het uitschakelen ervan. Hier was geen brute force-beveiliging geïmplementeerd, waardoor het mogelijk was om, als je een wachtwoord voor het account en een actieve sessie had, back-upcodes opnieuw te genereren of 2FA volledig uit te schakelen.
Gezien het feit dat de back-upcodes zich in hetzelfde bereik van stringwaarden bevonden als die gegenereerd door de OTP-applicatie, was de kans om de code in korte tijd te vinden veel groter.
Het proces van het selecteren van een OTP om 2FA uit te schakelen met behulp van de tool "Burp: Intruder".
Resultaat
Over het geheel genomen lijkt MCS als product veilig. Tijdens de audit kon het pentestteam geen toegang krijgen tot de VM's van klanten en hun gegevens, en de gevonden kwetsbaarheden werden snel gecorrigeerd door het MCS-team.
Maar hier is het belangrijk op te merken dat beveiliging een continu werk is. Diensten zijn niet statisch, ze evolueren voortdurend. En het is onmogelijk om een product geheel zonder kwetsbaarheden te ontwikkelen. Maar u kunt ze op tijd vinden en de kans op herhaling minimaliseren.
Nu zijn alle genoemde kwetsbaarheden in MCS al verholpen. En om het aantal nieuwe tot een minimum te beperken en hun levensduur te verkorten, blijft het platformteam dit doen:
- regelmatig audits uitvoeren door externe bedrijven;
- ondersteunen en ontwikkelen van participatie;
- bezighouden met veiligheid. 🙂
Bron: www.habr.com