av SeerLight
Att bygga vilken tjänst som helst innebär nödvändigtvis konstant arbete med säkerhet. Säkerhet är en pågående process som inkluderar ständig analys och förbättring av produktsäkerhet, övervakning av nyheter om sårbarheter och mycket mer. Inklusive revisioner. Revisioner genomförs både av våra egna insatser och av externa experter som kan ge betydande hjälp med säkerheten, eftersom de inte är fördjupade i projektet och har ett nytt perspektiv.
Artikeln handlar om den mest entydiga uppfattningen från externa experter som hjälpte Mail.ru Cloud Solutions (MCS)-teamet att testa molntjänsten, och vad de upptäckte. Som en ”extern kraft” valde MCS Digital Security, ett företag känt för sin höga expertis inom informationssäkerhetskretsar. Och i den här artikeln ska vi analysera några intressanta sårbarheter som hittats under en extern granskning – så att du undviker samma rädsla när du skapar din egen molntjänst.
Описание продукта
— är en plattform för att bygga virtuell infrastruktur i molnet. Det inkluderar IaaS, PaaS och en marknadsplats med färdiga applikationsavbildningar för utvecklare. Med tanke på MCS-arkitekturen var det nödvändigt att kontrollera produktens säkerhet inom följande områden:
- skydd av virtualiseringsmiljöns infrastruktur: hypervisorer, routing, brandväggar;
- skydd av kunders virtuella infrastruktur: isolering från varandra, inklusive nätverk, privata nätverk i SDN;
- OpenStack och dess komponenter med öppen källkod;
- S3 är vår egen utveckling;
- IAM: projekt med flera hyresgäster och en rollbaserad modell;
- Vision (maskinseende): API och sårbarheter vid arbete med bilder;
- webbgränssnitt och klassiska webbattacker;
- sårbarheter hos PaaS-komponenter;
- API för alla komponenter.
Det är nog allt som är viktigt för den fortsatta berättelsen.
Vilken typ av arbete utfördes och varför behövdes det?
En säkerhetsrevision syftar till att identifiera sårbarheter och konfigurationsfel som kan leda till läckage av personuppgifter, modifiering av känslig information eller störningar i tjänstens tillgänglighet.
Under arbetet, som i genomsnitt varar 1–2 månader, upprepar granskare potentiella angripares handlingar och letar efter sårbarheter i klient- och serverdelarna av den valda tjänsten. I samband med granskningen av MCS molnplattform identifierades följande mål:
- Analys av autentisering i tjänsten. Sårbarheter i den här komponenten skulle möjliggöra omedelbar åtkomst till andra personers konton.
- Studie av rollmodellen och åtkomstkontroll mellan olika konton. För en angripare är möjligheten att få åtkomst till någon annans virtuella maskin ett önskvärt mål.
- Sårbarheter på klientsidan. XSS/CSRF/CRLF/etc. Är det möjligt att attackera andra användare via skadliga länkar?
- Sårbarheter på serversidan: RCE och alla typer av injektioner (SQL/XXE/SSRF och så vidare). Serversårbarheter är generellt sett svårare att hitta, men de leder till att flera användare komprometteras samtidigt.
- Analys av användarsegmentisolering på nätverksnivå. För en angripare ökar bristen på isolering attackytan mot andra användare avsevärt.
- Analys av affärslogik. Är det möjligt att lura företag och skapa virtuella maskiner gratis?
I det här projektet utfördes arbetet med hjälp av "Gray-box"-modellen: granskare interagerade med tjänsten med vanliga användares privilegier, men hade delvis tillgång till API-källkoden och hade möjlighet att förtydliga detaljer med utvecklarna. Detta är vanligtvis den mest praktiska och samtidigt ganska realistiska arbetsmodellen: intern information kan fortfarande samlas in av en angripare, det är bara en tidsfråga.
Sårbarheter hittades
Innan en granskare börjar skicka olika nyttolaster (den nyttolast som används för att utföra en attack) till slumpmässiga platser är det nödvändigt att förstå hur allt fungerar och vilken funktionalitet som tillhandahålls. Det kan verka som en meningslös övning, eftersom de flesta av de studerade platserna inte kommer att innehålla några sårbarheter. Men bara att förstå applikationens struktur och logiken i dess funktion gör det möjligt att hitta de mest komplexa attackvektorerna.
Det är viktigt att hitta platser som verkar misstänkta eller är väldigt annorlunda från andra. Och den första farliga sårbarheten hittades på just detta sätt.
IDOR
IDOR-sårbarheter (Insecure Direct Object Reference) är en av de vanligaste typerna av sårbarheter inom affärslogik, vilka på ett eller annat sätt möjliggör åtkomst till objekt som åtkomst faktiskt inte är tillåten. IDOR-sårbarheter skapar möjligheten att erhålla information om användaren av varierande grad av kritikalitet.
Ett av IDOR-alternativen är att utföra åtgärder med systemobjekt (användare, bankkonton, varor i en kundvagn) genom att manipulera åtkomstidentifierare till dessa objekt. Detta leder till de mest oförutsägbara konsekvenserna. Till exempel möjligheten att ersätta avsändarens konto med medel, vilket kan användas för att stjäla dem från andra användare.
När det gäller MCS upptäckte revisorer faktiskt en IDOR-sårbarhet relaterad till osäkra identifierare. I användarens personliga konto användes UUID-identifierare för att komma åt objekt, vilket, enligt säkerhetsexperter, verkade imponerande obrute-säkert (det vill säga skyddat från en brute-force-attack). Men för vissa enheter fann man att vanliga, förutsägbara siffror användes för att få information om appens användare. Jag tror att du kan gissa att det var möjligt att ändra användar-ID:t till ett, skicka om begäran och därmed få information genom att kringgå ACL:n (åtkomstkontrolllista, regler för åtkomst av data för processer och användare).
Serverside Request Forgery (SSRF)
Det bra med OpenSource-produkter är att det finns ett enormt antal forum med detaljerade tekniska beskrivningar av de problem som uppstår och, om du har tur, med en beskrivning av lösningen. Men det finns en nackdel med detta mynt: kända sårbarheter beskrivs också i detalj. Till exempel har OpenStack-forumet några bra beskrivningar av sårbarheter. и , vilket av någon anledning ingen har bråttom att rätta till.
En vanlig funktion i applikationer är möjligheten för användaren att skicka en länk till servern, som servern följer (till exempel för att ladda ner en bild från en specifik källa). Om säkerhetsverktygen inte filtrerar själva länkarna eller svaren som returneras från servern till användarna tillräckligt, kan den här funktionen lätt utnyttjas av angripare.
SSRF-sårbarheter kan avsevärt påskynda utvecklingen av en attack. En angripare kan få:
- begränsad åtkomst till det attackerade lokala nätverket, till exempel endast genom vissa nätverkssegment och via ett visst protokoll;
- fullständig lokal nätverksåtkomst om nedgradering från applikationsnivå till transportnivå är möjlig och, som ett resultat, fullständig lasthantering på applikationsnivå;
- åtkomst att läsa lokala filer på servern (om file:///-schemat stöds);
- и многое другое.
OpenStack har länge varit känt för att ha en SSRF-sårbarhet som är av "blind" natur: när du ansluter till en server får du inget svar från den, men du får olika typer av fel/fördröjningar, beroende på resultatet av begäran. Baserat på detta kan du utföra en portsökning på värdar i det interna nätverket, med alla de konsekvenser som följer och som inte bör underskattas. Till exempel kan en produkt ha ett backoffice-API som endast är tillgängligt från företagsnätverket. Med dokumentation (låt oss inte glömma insiders) kan en angripare använda SSRF för att komma åt interna metoder. Om du till exempel på något sätt lyckades få en ungefärlig lista över användbara webbadresser, kan du med hjälp av SSRF gå igenom dem och utföra en begäran - säg, överför pengar från ett konto till ett annat eller ändra gränser.
Det här är inte första gången en SSRF-sårbarhet har upptäckts i OpenStack. Tidigare var det möjligt att ladda ner ISO-avbildningar av virtuella maskiner via en direktlänk, vilket också ledde till liknande konsekvenser. Den här funktionen har nu tagits bort från OpenStack. Tydligen ansåg samhället att detta var den enklaste och mest pålitliga lösningen på problemet.
Och i I en offentligt tillgänglig rapport från HackerOne-tjänsten (h1) leder utnyttjande av en inte längre blind SSRF med möjlighet att läsa instansmetadata till att man får root-åtkomst till hela Shopify-infrastrukturen.
I MCS hittades SSRF-sårbarheter på två ställen med liknande funktionalitet, men de var nästan omöjliga att utnyttja på grund av brandväggar och andra skydd. Hur som helst åtgärdade MCS-teamet problemet ändå, utan att vänta på communityn.
XSS istället för att ladda "shells"
Trots hundratals studier skrivna är XSS (cross-site scripting attack) fortfarande år efter år den mest använda webbsårbarhet (eller ?).
Filnedladdningar är en favoritplats för alla säkerhetsforskare. Det visar sig ofta att man kan ladda ett godtyckligt skript (asp/jsp/php) och köra OS-kommandon, med pentestares terminologi - "ladda ett skal". Men populariteten hos sådana sårbarheter fungerar åt båda hållen: de blir ihågkomna och verktyg utvecklas mot dem, så att sannolikheten för att "ladda ner ett skal" nyligen tenderar att vara noll.
Det anfallande laget (representerat av Digital Security) hade tur. OK, i MCS kontrollerades innehållet i de uppladdade filerna på serversidan, endast bilder var tillåtna. Men SVG är också en bild. Hur kan SVG-bilder vara farliga? Att du kan bädda in JavaScript-fragment i dem!
Det visade sig att de nedladdade filerna är tillgängliga för alla användare av MCS-tjänsten, vilket innebär att det är möjligt att attackera andra molnanvändare, nämligen administratörer.
Exempel på injicering av ett phishing-inloggningsformulär med hjälp av en XSS-attack
Exempel på utnyttjande av XSS-attacker:
- Varför försöka stjäla en session (särskilt eftersom HTTP-Only-cookies nu finns överallt, skyddade från stöld med hjälp av js-skript), om det laddade skriptet omedelbart kan komma åt resurs-API:et? I det här fallet kan nyttolasten ändra serverkonfigurationen via XHR-förfrågningar, till exempel lägga till angriparens publika SSH-nyckel och få SSH-åtkomst till servern.
- Om CSP-policyn (Content Security Policy) förbjuder JavaScript-injektion kan en angripare klara sig utan den. Skapa ett falskt inloggningsformulär för webbplatsen med hjälp av ren HTML och stjäl administratörens lösenord med hjälp av avancerad nätfiske: användarens nätfiske-sida visas på samma URL, och det är svårare för användaren att upptäcka den.
- Slutligen kan angriparen ordna — ställ in cookies större än 4 KB. Användaren behöver bara öppna länken en gång, och hela webbplatsen blir oåtkomlig tills du bestämmer dig för att rensa webbläsaren: i de allra flesta fall kommer webbservern att vägra att acceptera en sådan klient.
Låt oss titta på ett exempel på ytterligare en upptäckt XSS, den här gången med ett mer sofistikerat angrepp. Med MCS-tjänsten kan du kombinera brandväggsinställningar i grupper. Den XSS som upptäcktes fanns i gruppnamnet. Dess särdrag var att vektorn inte utlöstes omedelbart, inte när man tittade på regellistan, utan när man raderade gruppen:
Det vill säga, scenariot var följande: en angripare skapar en brandväggsregel med en "load" i namnet, administratören märker det efter en tid och initierar borttagningsprocessen. Och det är här den skadliga JS kommer in i bilden.
För MCS-utvecklare, för att skydda mot XSS i uppladdade SVG-bilder (om de inte kan väljas bort), rekommenderade Digital Security-teamet:
- Värdfiler som laddats upp av användare på en separat domän som inte har något att göra med cookiedomänen. Skriptet kommer att köras i kontexten för en annan domän och kommer inte att utgöra ett hot mot MCS.
- Returnera rubriken "Content-disposition: attachment" i serverns HTTP-svar. Då kommer filerna att laddas ner av webbläsaren och inte köras.
Dessutom finns det nu många sätt för utvecklare att minska riskerna med XSS-exploatering:
- Flaggan "Endast HTTP" kan användas för att göra sessionsrubriker för "Cookies" oåtkomliga för skadlig JavaScript-kod;
- kommer att göra det mycket svårare för en angripare att utnyttja XSS;
- Moderna mallmotorer som Angular eller React sanerar automatiskt användardata innan de visas i användarens webbläsare.
Sårbarheter i tvåfaktorsautentisering
För att förbättra kontosäkerheten rekommenderas användare alltid att aktivera 2FA (tvåfaktorsautentisering). Detta är verkligen ett effektivt sätt att förhindra att en angripare får åtkomst till tjänsten om användarens inloggningsuppgifter har äventyrats.
Men garanterar användningen av en andra autentiseringsfaktor alltid kontosäkerhet? Det finns säkerhetsproblem med implementeringen av 2FA:
- Brute force OTP (engångslösenord) kod. Trots användarvänligheten finns fel som bristande skydd mot OTP-brute force även i stora företag: , .
- Svag genereringsalgoritm, såsom förmågan att förutsäga nästa kod.
- Logiska fel, som möjligheten att begära någon annans engångslösenord på din telefon, som detta på Shopify.
När det gäller MCS implementeras 2FA baserat på Google Authenticator och . Själva protokollet har redan testats med tiden, men implementeringen av kodverifiering på applikationssidan är värd att kontrollera.
I MCS används 2FA på flera ställen:
- Vid autentisering av en användare. Det finns skydd mot brute force: användaren har bara några få försök att ange ett engångslösenord, sedan blockeras posten under en tid. Detta blockerar möjligheten till brute-force-val av engångskod.
- Vid generering av offline-backupkoder för 2FA, samt inaktivering av det. Det fanns inget brute force-skydd implementerat här, vilket tillät, om du hade ett lösenord för ditt konto och en giltig session, att generera säkerhetskoder eller inaktivera 2FA helt och hållet.
Med tanke på att reservkoderna var belägna inom samma intervall av strängvärden som de som genererades av OTP-applikationen, var chansen att hitta koden på kort tid mycket högre.
Processen att brute-forcera OTP för att inaktivera 2FA med hjälp av verktyget "Burp: Intruder"
Resultat
Sammantaget har MCS som produkt visat sig vara säker. Under granskningen misslyckades penetrationstestteamet med att få åtkomst till klientens virtuella maskiner och deras data, och de upptäckta sårbarheterna åtgärdades snabbt av MCS-teamet.
Men det är viktigt att notera här att säkerhet är ett kontinuerligt pågående arbete. Tjänster är inte statiska, de utvecklas ständigt. Men det är omöjligt att utveckla en produkt helt utan sårbarheter. Men du kan hitta dem i tid och minimera risken för att de händer igen.
Nu har alla nämnda sårbarheter i MCS redan åtgärdats. Och för att hålla antalet nya till ett minimum och minska deras livslängd fortsätter plattformsteamet att göra detta:
- genomföra regelbundna revisioner av externa företag;
- stödja och utveckla deltagande;
- att hantera säkerheten. 🙂
Källa: will.com
