door SeerLight
De opbouw van elke service omvat altijd voortdurende arbeid aan beveiliging. Beveiliging is een doorlopend proces dat continue 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 fundamenteel kunnen bijdragen aan de beveiliging, omdat zij niet in het project zijn ondergedompeld en een onbevooroordeeld perspectief hebben.
Dit artikel gaat over dat onbevooroordeeld perspectief van externe experts, die het team van Mail.ru Cloud Solutions (MCS) hebben geholpen om de cloudservice te testen, en wat zij hebben ontdekt. Als 'externe krachten' koos MCS voor het bedrijf Digital Security, dat bekendstaat om zijn hoge expertise binnen de beveiligingskringen. In dit artikel zullen we enkele interessante kwetsbaarheden onderzoeken die in het kader van de externe audit zijn gevonden — zodat u niet tegen dezelfde valkuilen aanloopt wanneer u uw cloudservice bouwt.
Productbeschrijving
is een platform voor het bouwen van virtuele infrastructuur in de cloud. Het omvat IaaS, PaaS, en een marktplaats voor kant-en-klare applicatiebeelden voor ontwikkelaars. Gezien de architectuur van MCS moest de beveiliging van het product op de volgende gebieden worden gecontroleerd:
- beveiliging van de virtualisatieomgeving: hypervisors, routering, firewalls;
- beveiliging van de virtuele infrastructuur van klanten: isolatie van elkaar, inclusief netwerken, privé-netwerken in SDN;
- OpenStack en zijn open componenten;
- S3 van eigen ontwerp;
- IAM: multitenantprojecten met een rollenmodel;
- Vision (machine vision): API en kwetsbaarheden bij het werken met afbeeldingen;
- webinterface en klassieke webaanvallen;
- kwetsbaarheden van PaaS-componenten;
- API van alle componenten.
Misschien is dat alles wat betreft het belangrijke voor het vervolg van het verhaal.
Wat voor werk werd er verricht en waarom is het nodig?
Een beveiligingsaudit is gericht op het identificeren van kwetsbaarheden en configuratiefouten die kunnen leiden tot het lekken van persoonlijke gegevens, het wijzigen van gevoelige informatie of het verstoren 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 zowel de client- als serverzijde van de gekozen dienst. In de context van de audit van het cloudplatform MCS zijn de volgende doelstellingen vastgesteld:
- Analyse van de authenticatie in de dienst. Kwetsbaarheden in deze component zouden het mogelijk maken om direct toegang te krijgen tot andermans accounts.
- Studie van het rolmodel en de toegangsonderverdeling tussen verschillende accounts. Voor een aanvaller is de mogelijkheid om toegang te krijgen tot een vreemde virtuele machine een begeerde doelstelling.
- Kwetsbaarheden aan de clientzijde. XSS/CSRF/CRLF/etc. Bestaat er een mogelijkheid om andere gebruikers aan te vallen via kwaadaardige links?
- Kwetsbaarheden aan de serverzijde: RCE en allerlei injecties (SQL/XXE/SSRF enzovoorts). Serverkwetsbaarheden zijn doorgaans moeilijker te vinden, maar leiden vaak tot de compromittering van vele gebruikers tegelijk.
- Analyse van de isolatie van gebruikerssegmenten op netwerkniveau. Voor een aanvaller vergroot het ontbreken van isolatie de aanvalsvloer aanzienlijk voor andere gebruikers.
- Analyse van de bedrijfslogica. Is het mogelijk om de business te bedriegen en gratis virtuele machines te creëren?
In dit project werd gewerkt volgens het ‘Gray-box’ model: auditors interageerden met de dienst met de privileges van gewone gebruikers, maar hadden gedeeltelijk toegang tot de broncode van de API en konden details verduidelijken met de ontwikkelaars. Dit is doorgaans het meest comfortabele en tegelijkertijd redelijk realistische werkmodel: interne informatie kan nog steeds door een aanvaller worden verzameld, het is slechts een kwestie van tijd.
Gevonden kwetsbaarheden
Voordat de auditor verschillende payloads (de nuttige lading die wordt gebruikt om de aanval uit te voeren) op willekeurige plaatsen verzendt, is het noodzakelijk om te begrijpen hoe alles werkt en welke functionaliteit beschikbaar is. Het kan lijken dat dit een nutteloze bezigheid is, aangezien in de meeste bestudeerde plaatsen geen kwetsbaarheden zullen worden aangetroffen. Maar alleen het begrip van de applicatiestructuur en de logica ervan maakt het mogelijk de meest complexe aanvalsvectoren te vinden.
Het is belangrijk om plekken te vinden die verdacht lijken of sterk afwijken van andere. En de eerste gevaarlijke kwetsbaarheid werd precies op deze manier ontdekt.
IDOR
IDOR-kwetsbaarheden (Insecure Direct Object Reference, onveilige directe verwijzingen naar objecten) zijn een van de meest voorkomende kwetsbaarheden in de bedrijfslogica, die op verschillende manieren toegang kunnen verlenen tot objecten waarvoor de toegang eigenlijk niet is toegestaan. IDOR-kwetsbaarheden maken het mogelijk om informatie over gebruikers van verschillende niveaus van gevoeligheid te verkrijgen.
Een variant van IDOR is het uitvoeren van acties op systeemobjecten (gebruikers, bankrekeningen, artikelen in winkelwagentjes) door manipulatie van de toegangscodes tot deze objecten. Dit kan leiden tot de meest onvoorspelbare gevolgen. Bijvoorbeeld, de mogelijkheid om het account van de verzender van geldtransacties te vervalsen, waardoor het mogelijk is om geld van andere gebruikers te stelen.
In het geval van MCS hebben auditors een IDOR-kwetsbaarheid ontdekt die verband hield met onveilige identificaties. In het gebruikerspaneel werden UUID-identificaties gebruikt om toegang te verkrijgen tot objecten, die volgens beveiligingsexperts indrukwekkend niet te kraken leken (dat wil zeggen, beschermd tegen brute-force aanvallen). Maar voor bepaalde entiteiten werd ontdekt dat er gewone voorspelbare nummers werden gebruikt om informatie over de gebruikers van de applicatie te verkrijgen. Ik denk dat je je kunt voorstellen dat men de gebruikers-ID met één kon verhogen, de aanvraag opnieuw kon indienen en zo informatie kon verkrijgen, waarbij de ACL (access control list, toegangregels voor gegevens voor processen en gebruikers) werd omzeild.
Server Side Request Forgery (SSRF)
OpenSource-producten hebben het voordeel dat er een enorme hoeveelheid forums is met gedetailleerde technische beschrijvingen van de problemen die zich voordoen, en als je geluk hebt, ook met oplossingen. Maar deze medaille heeft een keerzijde: ook bekende kwetsbaarheden zijn zeer gedetailleerd beschreven. Bijvoorbeeld, op het OpenStack-forum zijn er uitstekende beschrijvingen van kwetsbaarheden en , die om de een of andere reden niemand zich haast om te verhelpen.
Een veelvoorkomende functionaliteit van applicaties is de mogelijkheid voor een gebruiker om een link naar de server te sturen, waardoor de server deze link opent (bijvoorbeeld om een afbeelding van de opgegeven bron te laden). Bij onvoldoende filtering door de beveiligingsmiddelen van de links of de antwoorden die door de server aan de gebruikers worden geretourneerd, maken kwaadwillenden gemakkelijk gebruik van deze functionaliteit.
SSRF-kwetsbaarheden kunnen een aanval aanzienlijk vooruit helpen. Een aanvaller kan toegang krijgen tot:
- beperkte toegang tot het aangevallen lokale netwerk, bijvoorbeeld alleen tot bepaalde netwerksegmenten en via een bepaald protocol;
- volledige toegang tot het lokale netwerk, als een downgrade van de toepassingslaag naar de transportlaag mogelijk is, en dus volledige controle over de applicatielaad;
- toegang tot het lezen van lokale bestanden op de server (indien het schema file:// ondersteund wordt);
- en nog veel meer.
In OpenStack is er al geruime tijd een bekende SSRF-kwetsbaarheid die 'blind' van aard is: bij het aanspreken van de server ontvangt men geen antwoord, maar krijgt men verschillende soorten fouten/vertraagingen, afhankelijk van het resultaat van de aanvraag. Op basis hiervan kan men poorten scannen op hosts in het interne netwerk, met alle mogelijke gevolgen van dien, die men niet moet onderschatten. Bijvoorbeeld, een product kan een API voor het backoffice bevatten die alleen toegankelijk is vanuit het bedrijfsnetwerk. Met documentatie (vergeet de insiders niet) kan een aanvaller via SSRF zich richten op interne methoden. Bijvoorbeeld, als men op de een of andere manier een benaderende lijst van nuttige URL's weet te verkrijgen, kan men via SSRF daar langs en een aanvraag doen - grofweg gezegd, geld van de ene rekening naar de andere overmaken of limieten wijzigen.
Dit is niet de eerste keer dat een SSRF-kwetsbaarheid in OpenStack wordt ontdekt. In het verleden was er de mogelijkheid om ISO-images van VM's te uploaden via directe links, wat ook leidde tot soortgelijke gevolgen. Op dit moment is deze functie uit OpenStack verwijderd. Blijkbaar beschouwde de gemeenschap dit als de eenvoudigste en meest betrouwbare oplossing voor het probleem.
En bij In een openbaar rapport van de HackerOne (h1) service leidt de exploitatie van een niet-blinde SSRF met de mogelijkheid om metadata van de instantie te lezen al tot Root-toegang tot de gehele infrastructuur van Shopify.
In MCS zijn op twee plaatsen met vergelijkbare functionaliteit SSRF-kwetsbaarheden ontdekt, maar deze waren bijna niet te exploiteren vanwege firewalls en andere beveiligingen. Hoe dan ook, het MCS-team heeft dit probleem alsnog opgelost, zonder te wachten op de gemeenschap.
XSS in plaats van het uploaden van 'shells'
Ondanks de honderden geschreven onderzoeken is XSS (cross-site scripting) nog steeds de webkwetsbaarheid (of ?).
Bestanden uploaden is een favoriete plek voor iedere beveiligingsonderzoeker. Vaak blijkt dat men een willekeurig script (asp/jsp/php) kan uploaden en opdrachten voor het besturingssysteem kan uitvoeren, in de terminologie van pentesters – 'een shell uploaden'. Maar de populariteit van dergelijke kwetsbaarheden werkt in twee richtingen: ze worden herinnerd en er worden middelen tegen ontwikkeld, dus de kans om 'een shell te uploaden' gaat de laatste tijd naar nul.
Het aanvallende team (in de persoon van Digital Security) had geluk. OK, in MCS werd aan de serverzijde de inhoud van de geüploade bestanden gecontroleerd, alleen afbeeldingen werden toegestaan. Maar SVG is ook een afbeelding. En wat kunnen SVG-afbeeldingen gevaarlijk maken? Het feit dat men fragmenten van JavaScript erin kan inbedden!
Het bleek dat de geüploade bestanden toegankelijk zijn voor alle gebruikers van de MCS-service – dat betekent dat men andere cloudgebruikers kan aanvallen, namelijk de beheerders.
Voorbeeld van insluiting via een XSS-aanval op een phishing loginformulier.
Voorbeelden van XSS-aanvalsuitbuitingen:
- Waarom proberen de sessie te stelen (vooral omdat tegenwoordig overal HTTP-Only cookies zijn, beschermd tegen diefstal door js-scripts), als het geüploade script direct toegang kan krijgen tot de API van de bron? In dit geval kan de payload via XHR-verzoeken de serverconfiguratie wijzigen, bijvoorbeeld een open SSH-sleutel van de aanvaller toevoegen en SSH-toegang tot de server verkrijgen.
- Als het CSP-beleid (content security policy) het insluiten van JavaScript verbiedt, kan de aanvaller zonder het doen. Een nep-loginformulier in puur HTML opzetten en het wachtwoord van de administrator stelen via een geavanceerde phishing: de phishingpagina voor de gebruiker blijkt op dezelfde URL te staan, waardoor het voor de gebruiker moeilijker is om het te ontdekken.
- Ten slotte kan de aanvaller een inrichten door Cookies groter dan 4 KB in te stellen. De gebruiker hoeft maar één keer de link te openen – en de hele site wordt onbereikbaar, totdat men zich realiseert dat het nodig is om de browser speciaal op te schonen: in de overgrote meerderheid van de gevallen zal de webserver weigeren een dergelijke client te accepteren.
Laten we een voorbeeld bekijken van een andere ontdekte XSS, dit keer met een slimmere uitbuiting. De MCS-service staat het combineren van firewallinstellingen in groepen toe. In de naam van de groep is de ontdekte XSS aangetroffen. Het bijzondere was dat de vector niet meteen activateerde, niet bij het bekijken van de regels, maar bij het verwijderen van de groep:
Het scenario verloopt als volgt: een aanvaller creëert een firewallregel met een 'belasting' in de naam, de administrator merkt dit op en initieert het verwijderproces. Op dat moment komt de kwaadaardige JS in actie.
De ontwikkelaars van MCS hebben voor de bescherming tegen XSS in geüploade SVG-afbeeldingen (indien deze niet kunnen worden geweigerd) het team van Digital Security aanbevolen:
- Bestanden die door gebruikers worden geüpload, op een apart domein te plaatsen, dat niets te maken heeft met de 'cookies'. Het script wordt uitgevoerd in de context van een ander domein en vormt geen bedreiging voor MCS.
- In de HTTP-reactie van de server de header 'Content-disposition: attachment' mee te geven. Hierdoor zullen bestanden door de browser worden gedownload, in plaats van uitgevoerd.
Daarnaast zijn er momenteel veel manieren beschikbaar voor ontwikkelaars om de risico's van XSS-exploitatie te mitigeren:
- met de 'HTTP Only'-vlag kunnen sessiekoppen 'Cookies' ontoegankelijk worden gemaakt voor kwaadaardige JavaScript;
- maakt de exploitatie van XSS voor een aanvaller aanzienlijk moeilijker;
- moderne sjablonemachines, zoals Angular of React, maken automatisch gebruikersgegevens schoon voordat ze in de browser van de gebruiker worden weergegeven.
Kwetsbaarheden van tweefactorauthenticatie
Voor het verbeteren van de veiligheid van accounts wordt gebruikers altijd aangeraden om 2FA (tweefactorauthenticatie) in te schakelen. Dit is inderdaad een effectieve manier om te voorkomen dat een aanvaller toegang krijgt tot de service als de inloggegevens van de gebruiker zijn gecompromitteerd.
Maar biedt het gebruik van de tweede authenticatiefactor altijd garantie voor de veiligheid van het account? In de implementatie van 2FA zijn er enkele beveiligingsproblemen:
- Ruwe brute-force van de OTP-code (eenmalige wachtwoorden). Ondanks de eenvoud van exploitatie, komen dergelijke fouten, zoals het ontbreken van bescherming tegen brute-force van OTP, voor, zelfs bij grote bedrijven: , .
- Een zwak generatie-algoritme, bijvoorbeeld de mogelijkheid om de volgende code te voorspellen.
- Logische fouten, zoals de mogelijkheid om een ander OTP op je telefoon aan te vragen, zoals dit bij Shopify.
In het geval van MCS is 2FA geïmplementeerd op basis van Google Authenticator en . Het protocol is inmiddels bewezen, maar de implementatie van de codecontrole aan de applicatiezijde dient gecontroleerd te worden.
In MCS wordt 2FA op verschillende plekken gebruikt:
- Bij de authenticatie van de gebruiker. Hier is bescherming tegen brute force aanvallen: de gebruiker heeft slechts een paar pogingen om de eenmalige wachtwoord in te voeren, daarna wordt invoer tijdelijk geblokkeerd. Dit blokkeert de mogelijkheid om de OTP door middel van brute force te raden.
- Bij het genereren van offline back-upcodes voor het uitvoeren van 2FA, evenals voor het uitschakelen ervan. Hier was er geen bescherming tegen brute force implementatie, waardoor het mogelijk was om, met het wachtwoord van het account en een actieve sessie, de back-upcodes opnieuw te genereren of 2FA volledig uit te schakelen.
Gezien het feit dat de back-upcodes zich binnen dezelfde waarde-ranges bevonden als de door de applicatie gegenereerde OTP's, was de kans om de code snel te raden veel hoger.
Het proces van het raden van OTP om 2FA uit te schakelen met behulp van het 'Burp: Intruder' gereedschap.
Resultaat
Over het geheel genomen bleek MCS als product veilig te zijn. Tijdens de audit is het de pentesterteam niet gelukt om toegang te krijgen tot de klant-VM's en hun gegevens, en de gevonden kwetsbaarheden werden snel verholpen door het MCS-team.
Maar het is belangrijk op te merken dat beveiliging een doorlopend proces is. Diensten zijn niet statisch; ze ontwikkelen zich continu. Het is onmogelijk om een product volledig zonder kwetsbaarheden te ontwikkelen. Maar het is mogelijk om ze tijdig te ontdekken en de kans op herhaling te minimaliseren.
Tegenwoordig zijn alle genoemde kwetsbaarheden in MCS al verholpen. En om het aantal nieuwe kwetsbaarheden tot een minimum te beperken en de tijd van hun bestaan te verkorten, blijft het platformteam het volgende doen:
- regelmatig audits uitvoeren door externe bedrijven;
- de deelname ondersteunen en ontwikkelen;
- zich bezighouden met beveiliging. 🙂
Bron: habr.com
