vum SeerLight
Bauen all Service beinhalt onbedéngt konstant Aarbecht op Sécherheet. Sécherheet ass e kontinuéierleche Prozess dee konstant Analyse a Verbesserung vun der Produktsécherheet enthält, Iwwerwaachung vun Neiegkeeten iwwer Schwachstelle a vill méi. Inklusiv Auditen. Audits gi souwuel intern wéi och vun externen Experten duerchgefouert, déi radikal mat der Sécherheet hëllefe kënnen, well se net an de Projet ënnerdaach sinn an en oppene Geescht hunn.
Den Artikel ass iwwer dës einfachst Vue vun externen Experten, déi dem Mail.ru Cloud Solutions (MCS) Team gehollef hunn de Cloud Service ze testen, an iwwer wat se fonnt hunn. Als "extern Kraaft" huet MCS d'Digital Sécherheetsfirma gewielt, bekannt fir seng héich Expertise an Informatiounssécherheetskreesser. An an dësem Artikel wäerte mir e puer interessant Schwachstelle analyséieren, déi als Deel vun engem externen Audit fonnt goufen - sou datt Dir déiselwecht Rake vermeit wann Dir Ären eegene Cloud-Service erstellt.
Produktbeschreiwung
ass eng Plattform fir virtuell Infrastruktur an der Wollek ze bauen. Et enthält IaaS, PaaS, an e Maartplaz vu fäerdege Applikatiounsbiller fir Entwéckler. Mat der MCS Architektur berücksichtegt, war et néideg d'Sécherheet vum Produkt an de folgende Beräicher ze kontrolléieren:
- Schutz vun der Infrastruktur vun der Virtualiséierungsëmfeld: Hypervisoren, Routing, Firewalls;
- Schutz vun de Clienten virtuell Infrastruktur: Isolatioun vun all aner, dorënner Reseau, privat Netzwierker an SDN;
- OpenStack a seng oppe Komponenten;
- S3 vun eisem eegenen Design;
- IAM: Multi-Tenant Projete mat engem Virbild;
- Visioun (Computer Visioun): APIen a Schwachstelle wann Dir mat Biller schafft;
- Web Interface a klassesch Web Attacken;
- Schwachstelle vu PaaS Komponenten;
- API vun all Komponente.
Vläicht ass dat alles wat wesentlech fir weider Geschicht ass.
Wéi eng Aarbecht gouf gemaach a firwat war se gebraucht?
E Sécherheetsaudit zielt fir Schwachstelle a Konfiguratiounsfehler z'identifizéieren, déi zu Leckage vu perséinlechen Donnéeën, Ännere vu sensiblen Informatioun oder Stéierunge vun der Disponibilitéit vum Service féieren.
Wärend der Aarbecht, déi am Duerchschnëtt 1-2 Méint dauert, widderhuelen d'Auditeuren d'Aktiounen vu potenziellen Ugräifer a sichen no Schwachstelle bei de Client- a Serverdeeler vum ausgewielten Service. Am Kontext vum Audit vun der MCS Cloud Plattform goufen déi folgend Ziler identifizéiert:
- Analyse vun Authentifikatioun am Service. Schwachstelle bei dëser Komponent géifen hëllefen, direkt op aner Leit hir Konten ze kommen.
- Studéiert de Rollmodell an Zougangskontroll tëscht verschiddene Konten. Fir en Ugräifer ass d'Fäegkeet Zougang zu enger virtueller Maschinn vun engem aneren ze kréien e wënschenswäert Zil.
- Client Säit Schwachstelle. XSS/CSRF/CRLF/etc. Ass et méiglech aner Benotzer duerch béiswëlleg Linken ze attackéieren?
- Server Säit Schwachstelle: RCE an all Zorte vu Injektiounen (SQL / XXE / SSRF an sou weider). Server Schwachstelle sinn allgemeng méi schwéier ze fannen, awer si féieren zum Kompromëss vu ville Benotzer gläichzäiteg.
- Analyse vun Benotzer Segment Isolatioun um Reseau Niveau. Fir en Ugräifer erhéicht de Mangel un Isolatioun d'Attackfläch géint aner Benotzer staark.
- Business Logik Analyse. Ass et méiglech Geschäfter ze täuschen a virtuelle Maschinnen gratis ze kreéieren?
An dësem Projet gouf d'Aarbecht no dem Modell "Gray-Box" duerchgefouert: Auditeure interagéiert mam Service mat de Privilegien vun normale Benotzer, awer hunn deelweis de Quellcode vun der API besat an haten d'Méiglechkeet Detailer mat den Entwéckler ze klären. Dëst ass normalerweis de bequemste, a gläichzäiteg zimlech realistesche Modell vun der Aarbecht: intern Informatioun kann nach ëmmer vun engem Ugräifer gesammelt ginn, et ass nëmmen eng Fro vun der Zäit.
Schwachstelle fonnt
Ier den Auditeur ufänkt verschidde Notzlaascht ze schécken (d'Notzlaascht déi benotzt gëtt fir den Attack auszeféieren) op zoufälleg Plazen, ass et néideg ze verstoen wéi d'Saache funktionnéieren a wéi eng Funktionalitéit gëtt. Et kann schéngen datt dëst eng nëtzlos Übung ass, well an de meeschte studéierte Plazen gëtt et keng Schwachstelle. Awer nëmmen d'Struktur vun der Applikatioun an d'Logik vu senger Operatioun ze verstoen wäert et méiglech maachen déi komplexst Attackvektoren ze fannen.
Et ass wichteg Plazen ze fannen déi verdächteg schéngen oder op iergendeng Manéier ganz anescht wéi anerer sinn. An déi éischt geféierlech Schwachstelle gouf op dës Manéier fonnt.
IDOR
IDOR (Insecure Direct Object Reference) Schwachstelle sinn eng vun den heefegste Schwächen an der Geschäftslogik, déi et erlaabt een oder aneren Zougang zu Objeten ze kréien, op déi den Zougang tatsächlech net erlaabt ass. IDOR Schwachstelle schafen d'Méiglechkeet Informatiounen iwwer e Benotzer vun ënnerschiddleche Grad vu Kritik ze kréien.
Eng vun den IDOR-Optiounen ass d'Aktioune mat Systemobjekter (Benotzer, Bankkonten, Artikelen am Akafswagen) duerch d'Manipulatioun vun Zougangsidentifizéierer op dës Objeten. Dëst féiert zu den onberechenbaren Konsequenzen. Zum Beispill d'Méiglechkeet fir de Kont vum Sender vu Fongen z'ersetzen, duerch déi Dir se vun anere Benotzer klauen kënnt.
Am Fall vun MCS hunn Auditeuren just eng IDOR Schwachstelle entdeckt, déi mat net-sécheren Identifizéierer verbonne sinn. Am perséinleche Kont vum Benotzer goufen UUID Identifizéierer benotzt fir Zougang zu all Objeten ze kréien, déi schéngen, wéi Sécherheetsexperten soen, beandrockend onsécher (dat ass geschützt vu brute Force Attacken). Awer fir verschidden Entitéite gouf entdeckt datt regelméisseg prévisibel Zuelen benotzt gi fir Informatioun iwwer d'Benotzer vun der Applikatioun ze kréien. Ech mengen Dir kënnt roden datt et méiglech war d'Benotzer ID vun engem z'änneren, d'Ufro erëm ze schécken an domat d'Informatioun vum ACL ze kréien (Zougangskontrolllëscht, Daten Zougangsregele fir Prozesser a Benotzer).
Server Side Request Forgery (SSRF)
Déi gutt Saach iwwer OpenSource Produkter ass datt se eng grouss Zuel vu Foren hunn mat detailléierte technesche Beschreiwunge vun de Probleemer déi entstinn an, wann Dir Gléck hutt, eng Beschreiwung vun der Léisung. Awer dës Mënz huet eng Säit: bekannte Schwachstelle ginn och am Detail beschriwwen. Zum Beispill ginn et wonnerbar Beschreiwunge vu Schwachstelle am OpenStack Forum и , déi aus iergendengem Grond keen presséiert ze fixéieren.
Eng gemeinsam Funktionalitéit vun Uwendungen ass d'Fäegkeet fir de Benotzer e Link op de Server ze schécken, op deen de Server klickt (zum Beispill fir e Bild vun enger spezifizéierter Quell erofzelueden). Wann d'Sécherheetsinstrumenter d'Links net selwer filteren oder d'Äntwerte vum Server un d'Benotzer zréckginn, kann esou Funktionalitéit einfach vun Ugräifer benotzt ginn.
SSRF Schwachstelle kënnen d'Entwécklung vun engem Attack staark förderen. En Ugräifer kann kréien:
- limitéiert Zougang zu der attackéiert lokal Reseau, zum Beispill, nëmmen duerch bestëmmte Reseau Segmenter a mat engem bestëmmte Protokoll;
- vollen Zougang zum lokalen Netzwierk, wann d'Downgradéierung vum Applikatiounsniveau op den Transportniveau méiglech ass an, als Resultat, voll Lastmanagement um Applikatiounsniveau;
- Zougang fir lokal Dateien um Server ze liesen (wann d'Datei:/// Schema ënnerstëtzt gëtt);
- a vill méi.
Eng SSRF Schwachstelle ass laang am OpenStack bekannt, déi "blann" an der Natur ass: wann Dir de Server kontaktéiert, kritt Dir keng Äntwert dovun, awer Dir kritt verschidden Aarte vu Feeler / Verspéidungen, jee no dem Resultat vun der Ufro . Baséierend op dësem, kënnt Dir e Port Scan op Hosten am internen Netzwierk ausféieren, mat all de Konsequenzen déi net ënnerschat solle ginn. Zum Beispill kann e Produkt e Back-Office API hunn deen nëmmen aus dem Firmennetz zougänglech ass. Mat Dokumentatioun (vergiesst net iwwer Insider), kann en Ugräifer SSRF benotze fir intern Methoden ze kréien. Zum Beispill, wann Dir iergendwéi fäeg war eng geschätzte Lëscht vun nëtzlechen URLen ze kréien, da kënnt Dir mat SSRF duerch se goen an eng Ufro ausféieren - relativ gesinn, Sue vu Kont op Kont transferéieren oder Limiten änneren.
Dëst ass net déi éischte Kéier datt eng SSRF Schwachstelle am OpenStack entdeckt gouf. An der Vergaangenheet war et méiglech VM ISO Biller vun engem direkten Link erofzelueden, wat och zu ähnleche Konsequenzen gefouert huet. Dës Feature gouf elo vum OpenStack geläscht. Anscheinend huet d'Gemeinschaft dëst als déi einfachst an zouverlässegst Léisung fir de Problem ugesinn.
An a ëffentlech verfügbare Bericht vum HackerOne Service (h1), Ausbeutung vun engem net méi blannen SSRF mat der Fäegkeet fir Instanz Metadaten ze liesen féiert zum Root Zougang zu der ganzer Shopify Infrastruktur.
Am MCS goufen SSRF Schwachstelle op zwou Plazen mat ähnlecher Funktionalitéit entdeckt, awer si ware bal onméiglech ze exploitéieren wéinst Firewalls an aner Schutz. Op déi eng oder aner Manéier huet d'MCS Team dëse Problem souwisou fixéiert, ouni op d'Communautéit ze waarden.
XSS amplaz Muschelen ze lueden
Trotz Honnerte vu Studien geschriwwen, Joer fir Joer XSS (Cross-Site Scripting) Attack ass ëmmer nach am meeschten Web Schwachstelle (oder ?).
Dateiuploads sinn eng Liiblingsplaz fir all Sécherheetsfuerscher. Et stellt sech dacks eraus datt Dir en arbiträr Skript (asp/jsp/php) luede kënnt an OS Kommandoen ausféieren, an der Terminologie vu Pentesters - "Laascht Shell". Awer d'Popularitéit vun esou Schwachstelle funktionnéiert a béid Richtungen: Si ginn erënnert a Mëttel géint si entwéckelt, sou datt viru kuerzem d'Wahrscheinlechkeet fir "Schuel ze lueden" op Null ass.
D'Attacketeam (vertrueden duerch Digital Security) hat Gléck. OK, am MCS op der Server Säit gouf den Inhalt vun den erofgeluede Dateien iwwerpréift, nëmme Biller waren erlaabt. Awer SVG ass och e Bild. Wéi kënne SVG Biller geféierlech sinn? Well Dir kënnt JavaScript Snippets an hinnen embeden!
Et huet sech erausgestallt datt déi erofgeluede Dateie fir all Benotzer vum MCS Service verfügbar sinn, dat heescht datt et méiglech ass aner Cloud Benotzer, nämlech Administrateuren, ze attackéieren.
E Beispill vun engem XSS Attack op eng Phishing Login Form
Beispiller vun XSS Attack Ausbeutung:
- Firwat probéieren eng Sessioun ze klauen (besonnesch well elo HTTP-Nëmmen Cookien iwwerall sinn, geschützt géint Déif mat js Scripten), wann de geluedene Skript direkt op d'Ressource API Zougang kann? An dësem Fall kann d'Notzlaascht XHR-Ufroe benotzen fir d'Serverkonfiguratioun z'änneren, zum Beispill, den ëffentleche SSH-Schlëssel vum Ugräifer derbäi a kritt SSH Zougang zum Server.
- Wann d'CSP Politik (Inhaltsschutzpolitik) verbueden JavaScript ze injizéieren, kann en Ugräifer ouni et duerchkommen. Benotzt pure HTML, erstellt e gefälschte Loginform fir de Site a klaut dem Administrator säi Passwuert duerch dës fortgeschratt Phishing: d'Phishing Säit fir de Benotzer endet op der selwechter URL, an et ass méi schwéier fir de Benotzer et z'entdecken.
- Endlech kann den Ugräifer arrangéieren - Set Cookies méi grouss wéi 4 KB. De Benotzer muss de Link nëmmen eemol opmaachen, an de ganze Site gëtt onzougänglech bis de Benotzer denkt de Browser speziell ze botzen: an der grousser Majoritéit vu Fäll refuséiert de Webserver sou e Client ze akzeptéieren.
Loosst eis e Beispill vun engem aneren detektéierten XSS kucken, dës Kéier mat engem méi clevere Exploit. De MCS Service erlaabt Iech Firewall Astellungen a Gruppen ze kombinéieren. De Gruppnumm war wou den XSS entdeckt gouf. Seng Besonderheet war datt de Vektor net direkt ausgeléist gouf, net wann Dir d'Lëscht vun de Regelen kuckt, mee wann Dir e Grupp läschen:
Dat ass, de Szenario huet sech als folgend erausgestallt: en Ugräifer erstellt eng Firewall Regel mat "Laascht" am Numm, den Administrateur bemierkt et no enger Zäit an initiéiert de Läschprozess. An dat ass wou déi béiswëlleg JS funktionnéiert.
Fir MCS Entwéckler, fir géint XSS an erofgeluede SVG Biller ze schützen (wann se net kënnen opginn), recommandéiert d'Digital Sécherheetsteam:
- Plaz Dateien, déi vun de Benotzer eropgeluede ginn, op engem separaten Domain, deen näischt mat "Cookien" ze dinn huet. De Skript gëtt am Kontext vun engem aneren Domain ausgefouert a wäert keng Bedrohung fir MCS stellen.
- An der HTTP-Äntwert vum Server, schéckt den Header "Content-Disposition: Attachment". Da ginn d'Dateie vum Browser erofgelueden an net ausgefouert.
Zousätzlech ginn et elo vill Weeër fir Entwéckler verfügbar fir d'Risike vun der XSS Ausbeutung ze reduzéieren:
- andeems Dir den "HTTP Only" Fändel benotzt, kënnt Dir Sessioun "Cookies" Header onzougänglech fir béiswëlleg JavaScript maachen;
- wäert et vill méi schwéier maachen fir en Ugräifer XSS auszenotzen;
- modern Templatemotoren wéi Angular oder React sanitéieren automatesch Benotzerdaten ier se an de Browser vum Benotzer ausginn.
Zwee-Faktor Authentifikatioun Schwachstelle
Fir d'Kontsécherheet ze verbesseren, ginn d'Benotzer ëmmer ugeroden 2FA (Zwee-Faktor Authentifikatioun) z'aktivéieren. Tatsächlech ass dëst en effektive Wee fir ze verhënneren datt en Ugräifer Zougang zu engem Service kritt wann d'Umeldungsinformatioune vum Benotzer kompromittéiert goufen.
Awer garantéiert d'Benotzung vun engem zweeten Authentifikatiounsfaktor ëmmer Kont Sécherheet? Et ginn déi folgend Sécherheetsprobleemer bei der Ëmsetzung vun 2FA:
- Brute-force Sich vum OTP Code (eemol Coden). Trotz der Einfachheet vun der Operatioun, sinn och Feeler wéi Mangel u Schutz géint OTP brute Kraaft begéint vu grousse Firmen: , .
- Schwaach Generatioun Algorithmus, zum Beispill d'Fäegkeet den nächste Code virauszesoen.
- Logesch Feeler, sou wéi d'Fäegkeet fir en aneren säin OTP op Ärem Telefon ze froen, sou aus Shopify.
Am Fall vu MCS gëtt 2FA implementéiert baséiert op Google Authenticator an . De Protokoll selwer ass scho getest ginn, awer d'Ëmsetzung vun der Codeverifizéierung op der Applikatiounssäit ass derwäert ze kontrolléieren.
MCS 2FA gëtt op verschiddene Plazen benotzt:
- Beim Authentifikatioun vum Benotzer. Et gëtt Schutz géint brute Kraaft: de Benotzer huet nëmmen e puer Versuche fir en eemolegt Passwuert anzeginn, da gëtt den Input fir eng Zäit gespaart. Dëst blockéiert d'Méiglechkeet vu brute-force Auswiel vun OTP.
- Wann Dir offline Backupcodes generéiert fir 2FA auszeféieren, souwéi se auszeschalten. Hei gouf kee Brute Force Schutz ëmgesat, wat et méiglech gemaach huet, wann Dir e Passwuert fir de Kont an eng aktiv Sessioun hutt, Backupcodes ze regeneréieren oder 2FA komplett auszeschalten.
Bedenkt datt d'Backupcodes an der selwechter Band vu Stringwäerter waren wéi déi vun der OTP Applikatioun generéiert, war d'Chance fir de Code a kuerzer Zäit ze fannen vill méi héich.
De Prozess vun der Auswiel vun engem OTP fir 2FA auszeschalten mam Tool "Burp: Intruder".
Resultat
Allgemeng schéngt MCS als Produkt sécher ze sinn. Wärend dem Audit konnt d'Pentesting-Team net Zougang zu Client VMs an hir Donnéeën kréien, an déi fonnt Schwachstelle goufe séier vum MCS Team korrigéiert.
Awer hei ass et wichteg ze bemierken datt Sécherheet eng kontinuéierlech Aarbecht ass. D'Servicer sinn net statesch, si entwéckelen sech permanent. An et ass onméiglech e Produkt komplett ouni Schwachstelle z'entwéckelen. Awer Dir kënnt se an der Zäit fannen an d'Chance vun hirem Widderhuelung minimiséieren.
Elo sinn all déi genannte Schwachstelle am MCS scho fixéiert. A fir d'Zuel vun den neien op e Minimum ze halen an hir Liewensdauer ze reduzéieren, mécht d'Plattformteam dëst weider:
- reegelméisseg Auditë vun externe Firmen duerchféieren;
- ënnerstëtzen an entwéckelen Participatioun;
- an Sécherheet engagéieren. 🙂
Source: will.com