SeerLight által
Bármely szolgáltatás felépítése elengedhetetlenül magában foglalja a biztonság folyamatos fejlesztését. A biztonság egy folytonos folyamat, amely magában foglalja a termék védelmének folyamatos elemzését és javítását, a sebezhetőségekről szóló hírek figyelemmel kísérését és sok egyebet. Ide tartoznak az auditok is. Az auditokat végezhetjük saját erőkkel, vagy külső szakértők segítségével, akik drámaian javíthatják a biztonságot, mivel nem dolgoznak a projekten, és friss szemmel néznek a dolgokra.
A cikk azokról a friss szemű külső szakértőkről szól, akik segítettek a Mail.ru Cloud Solutions (MCS) csapatának tesztelni a felhőszolgáltatást, és arról, amit felfedeztek. A „külső erőként” az MCS a Digital Security céget választotta, amely a kibervédelem körében ismert magas szintű szakértelméről. Ebben a cikkben áttekintünk néhány érdekes sebezhetőséget, amelyeket a külső audit keretében találtak — hogy elkerülhessétek az ilyen buktatókat, amikor a saját felhőszolgáltatásotokkal foglalkoztok.
Termék leírása
egy platform a virtuális infrastruktúra felépítésére a felhőben. IaaS-t, PaaS-t, a fejlesztők számára kész alkalmazásképeket tartalmazó piacteret foglal magában. Az MCS architektúrájának figyelembevételével a termék biztonságát a következő irányokban kellett ellenőrizni:
- a virtualizációs környezet infrastruktúrájának védelme: hipervizorok, irányítás, tűzfalak;
- az ügyfelek virtuális infrastruktúrájának védelme: egymástól való elszigetelés, beleértve a hálózati elszigetelést, privát hálózatok az SDN-ben;
- OpenStack és nyílt komponensei;
- saját fejlesztésű S3;
- IAM: multi-tenant projektek szerepkör-alapú modell alapján;
- Vision (gépészeti látás): API és sebezhetőségek képkidolgozás közben;
- webes felület és klasszikus webes támadások;
- PaaS komponensek sebezhetőségei;
- minden komponens API-ja.
Talán a legfontosabbak a jövő történetéhez — ennyi.
Milyen munkákat végeztek és miért van rá szükség?
A biztonsági audit célja a sebezhetőségek és konfigurációs hibák feltárása, amelyek személyes adatok szivárgásához, érzékeny információk módosításához vagy a szolgáltatások elérhetőségének megsértéséhez vezethetnek.
A munkálatok során, amelyek átlagosan 1-2 hónapig tartanak, az audítorok megismétlik a potenciális támadók lépéseit, és keresik a sebezhetőségeket a kiválasztott szolgáltatás kliens- és szerveroldalán. Az MCS felhőplatform audit keretében a következő célokat határozták meg:
- Az autentikáció elemzése a szolgáltatásban. A sebezhetőségek ebben az összetevőben lehetővé tennék, hogy azonnal belépjenek mások fiókjába.
- A szerepkörmodell és a hozzáférés korlátozásának vizsgálata a különböző fiókok között. A támadónak a lehetőség, hogy hozzáférjen egy másik virtuális géphez – vonzó cél.
- A kliensoldali sebezhetőségek. XSS/CSRF/CRLF/stb. Lehet, hogy van lehetőség más felhasználók megtámadására rosszindulatú linkeken keresztül?
- A szerveroldali sebezhetőségek: RCE és különböző injekciók (SQL/XXE/SSRF stb.). A szerversebezhetőségek általában nehezebben találhatók meg, de azonnali tömeges felhasználói kompromittálódáshoz vezetnek.
- A felhasználói szegmensek hálózati szintű izolációjának elemzése. A támadónak az izoláció hiánya jelentősen megnöveli a támadási felületet más felhasználók ellen.
- Az üzleti logika elemzése. Lehet-e átverni a vállalkozást, és ingyenes virtuális gépeket létrehozni?
A projekt keretében a munkálatokat „Gray-box” modellen végezték: az audítorok a szolgáltatással a szokásos felhasználói jogosultságokkal léptek kapcsolatba, de részben hozzáfértek az API forráshoz, és lehetőségük volt további részleteket elkérni a fejlesztőktől. Ez általában a legkényelmesebb, és ugyanakkor elég reális munkamódszer: a belső információkat a támadók úgyis összegyűjthetik, ez csupán idő kérdése.
Felfedezett sebezhetőségek
Mielőtt az auditor különböző payloadokat (azokat a hasznos terheket, amelyekkel a támadást végrehajtják) indítana véletlenszerű helyekre, először át kell nézni, hogy mi hogyan működik, milyen funkciók vannak jelen. Elsőre haszontalannak tűnhet, mivel a legtöbb vizsgált helyen nem található sebezhetőség. De csak az alkalmazás felépítésének és működési logikájának megértése ad lehetőséget a legbonyolultabb támadási vektorok felfedezésére.
Fontos megtalálni azokat a helyeket, amelyek gyanúsnak tűnnek, vagy valamilyen szempontból eltérnek másoktól. És az első veszélyes sebezhetőséget pontosan így találták meg.
IDOR
Az IDOR sebezhetőség (Insecure Direct Object Reference, nem biztonságos közvetlen objektumreferencia) a leggyakoribb sebezhetőségek egyike az üzleti logikában, amely lehetővé teszi, hogy valamilyen módon hozzáférést nyerjünk olyan objektumokhoz, amelyekhez valójában nem engedélyezett a hozzáférés. Az IDOR sebezhetőségek lehetőséget biztosítanak különböző fokú érzékeny felhasználói adatok megszerzésére.
Az IDOR egyik változata az, amikor a felhasználók, bankszámlák, bevásárlókocsik objektumaival végzett műveleteket manipulación által hajtják végre, amelyek a hozzáférési azonosítók manipulálásával valósulnak meg. Ez a legváratlanabb következményekhez vezethet. Például lehetővé válhat egy pénzátutaló fiók megváltoztatása, aminek segítségével pénzt lehet lopni más felhasználóktól.
A MCS esetében az auditorok éppen az IDOR sebezhetőséget fedezték fel, amely a nem biztonságos azonosítókhoz kapcsolódott. A felhasználói fiókban bármilyen objektumhoz való hozzáféréshez UUID azonosítókat használtak, amelyek a biztonsági szakemberek szerint lenyűgözően nem voltak feltörhetők (tehát védettek a bruteforce támadásokkal szemben). De egyes entitások esetében kiderült, hogy a felhasználói információk megszerzéséhez egyszerűen előre meghatározott számokat használnak. Gondolom, kitalálja, hogy a felhasználó ID-ját eggyel meg lehetett változtatni, azaz megismételni a kérdést, így megkerülve az ACL-t (hozzáférés-ellenőrző lista, mely a folyamatok és felhasználók adat hozzáférési szabályaival foglalkozik).
Server Side Request Forgery (SSRF)
Az OpenSource termékek előnye, hogy óriási mennyiségű fórum áll rendelkezésre a felmerült problémák részletes technikai leírásával, és ha szerencséd van, a megoldás leírásával is. De ennek a dolognak van egy másik oldala is: a részletesen leírt ismert sebezhetőségek. Például az OpenStack fórumon nagyszerű leírások találhatók sebezhetőségekről és , amelyeket valamiért senki sem siet javítani.
A gyakori alkalmazási funkció, hogy a felhasználó linket küld a szervernek, amelyen a szerver navigál (például, hogy egy képet töltsön le a megadott forrásból). Ha a biztonsági eszközök nem megfelelően szűrik a linkeket vagy a felhasználóknak visszaküldött válaszokat, akkor ezt a funkciót a támadók könnyen kihasználják.
Az SSRF sebezhetőségek jelentősen előre mozdíthatják a támadások fejlődését. A támadó hozzáférést szerezhet:
- korlátozott hozzáférést a támadott helyi hálózathoz, például csak bizonyos hálózati szegmensekhez és egy meghatározott protokollal;
- teljes hozzáférést a helyi hálózathoz, ha lehetséges a csökkentés az alkalmazási szintről a szállítási szintre, és ennek következményeként a teljes irányítás a terhelés fölött az alkalmazási szinten;
- hozzáférést a helyi fájlok olvasásához a szerveren (ha támogatott a file://// séma);
- Őszintén szólva, nem értem, hogyan került el ez a hír a Habr elől. Ebben a cikkben röviden leírjuk, hogyan használhatjuk az API-t, és bemutatunk néhány gyakorlati példát
Az OpenStackben régóta ismert egy "vak" jellegű SSRF sebezhetőség: a szerverhez való hozzáféréskor nem kapsz választ tőle, de különböző hibákat vagy késlekedéseket kapsz a kérés eredményétől függően. Ezen alapjain végrehajtható a portok beolvasása a belső hálózaton lévő gazdagépeken, minden azt követő következménnyel, amit nem szabad alábecsülni. Például, egy terméknek lehet API-ja a háttérben, amely csak a vállalati hálózatból érhető el. Ha a dokumentáció a birtokunkban van (ne feledkezzünk meg a belső informátorokról), a támadó SSRF segítségével hozzáférhet a belső metódusokhoz. Például, ha valamilyen módon sikerült megszerezni egy hozzávetőleges hasznos URL-ek listáját, akkor az SSRF segítségével végigmehet rajtuk és kérdést indíthat — mondjuk, pénzt átutalni egyik számláról a másikra vagy megváltoztatni a limiteket.
Ez nem az első eset, hogy SSRF sebezhetőséget fedeztek fel az OpenStackben. A múltban volt lehetőség közvetlen hivatkozásról ISO-képeket betölteni, ami szintén hasonló következményekhez vezetett. Jelenleg ez a funkció eltávolításra került az OpenStackből. Nyilvánvalóan a közösség ezt tartotta a legegyszerűbb és legmegbízhatóbb megoldásnak a problémára.
És a A HackerOne (h1) szolgáltatásából származó nyilvános jelentésben a nem vak SSRF kihasználása, amely lehetőséget biztosít az instance metainformációk olvasására, hozzáférést biztosít a Shopify teljes infrastruktúrához.
Az MCS-ben két hasonló funkcionalitású helyen fedeztek fel SSRF sebezhetőségeket, de gyakorlatilag kibővítetlenek voltak a tűzfalak és más védelmek miatt. Akárhogy is, az MCS csapata megoldotta ezt a problémát anélkül, hogy a közösségre várt volna.
XSS a "shell" betöltése helyett
Annak ellenére, hogy több száz tanulmány készült, évről évre az XSS (keresztoldali szkriptelési támadás) még mindig a leg webes sebezhetőség (vagy ?).
A fájlok feltöltése a biztonsági kutatók kedvenc helye. Gyakran előfordul, hogy tetszőleges szkriptet (asp/jsp/php) tölthetünk fel, és parancsokat hajthatunk végre az operációs rendszeren, amit a pentesterek a „shell feltöltése” terminológiával illetnek. De az ilyen sebezhetőségek népszerűsége kétélű fegyver: emlékeznek rájuk és fejlesztenek ellenük eszközöket, így az utóbbi időben a „shell feltöltésének” valószínűsége közel nullához közelít.
A támadó csapatnak (a Digital Security képviseletében) szerencséje volt. Rendben, az MCS szerveroldalon ellenőrizték a feltöltött fájlok tartalmát, csak képek voltak engedélyezve. De az SVG is egy kép. Milyen veszélyt rejthetnek az SVG képek? Azért, mert JavaScript-fragmensek ágyazhatók beléjük!
Kiderült, hogy a feltöltött fájlok minden MCS szolgáltatás felhasználó számára hozzáférhetők — vagyis támadhatjuk a felhő más felhasználóit, nevezetesen — az adminisztrátorokat.
XSS-támadással történő beépítés példa egy phishing bejelentkezési űrlapra
XSS-támadás kihasználásának példái:
- Miért próbáljunk meg ellopni egy munkamenetet (főleg, mivel manapság mindenhol HTTP-Only cookie-k vannak, amelyek védve vannak a js-skriptek által végzett lopásokkal), ha a feltöltött szkript azonnal hívhatja az erőforrás API-ját? Ilyen esetben a hasznos terhelés XHR-kéréseken keresztül megváltoztathatja a szerver konfigurációját, például hozzáadhatja a támadó nyílt SSH-kulcsát, és SSH-hozzáférést kaphat a szerverhez.
- Ha a CSP-politika (tartalomvédelmi politika) megtiltja a JavaScript beépítését, a támadó nélküle is megoldhatja. Tiszta HTML-ben elkészíthet egy hamis bejelentkezési űrlapot, és így lophatja el az adminisztrátor jelszavát egy fejlett phishing módszerrel: a felhasználó számára a phishing oldal ugyanazon az URL-en jelenik meg, így nehezebben észlelhető.
- Végül a támadó megvalósíthatja — olyan sütiket állít ki, amelyek nagyobbak 4 KB-nál. A felhasználónak csupán annyit kell tennie, hogy egyszer megnyit egy hivatkozást — és az egész webhely elérhetetlenné válik, amíg fel nem ismeri, hogy külön kell törölnie a böngészőt: a többségében a webkiszolgáló visszautasítja az ilyen klienst.
Nézzük meg egy másik felfedezett XSS példáját, ezúttal egy ügyesebb kihasználással. Az MCS szolgáltatás lehetővé teszi a tűzfalbeállítások csoportosítását. A csoport nevében volt a felfedezett XSS. Az volt a jellemzője, hogy a vektor nem azonnal lépett működésbe, nem a szabályok listájának megtekintésekor, hanem a csoport törlésekor:
Tehát a következő forgatókönyv alakult ki: a támadó tűzfal szabályt hoz létre "terheléssel" a nevében, az adminisztrátor egy idő után észreveszi, elindítja az eltávolítási folyamatot. És ekkor lép működésbe a rosszindulatú JS.
A MCS fejlesztőinek a Digital Security csapata azt javasolta, hogy XSS támadások elleni védekezés érdekében az SVG-fájlok feltöltésénél (ha azoktól nem lehet eltekinteni):
- A felhasználók által feltöltött fájlokat külön domain-en tárolják, amelynek nincs köze a "sütikhez". A skript más domain keretein belül fog futni, így nem jelenthet fenyegetést a MCS-re.
- A szerver HTTP-válaszában hozzá kell adni a "Content-disposition: attachment" fejlécet. Így a fájlok a böngésző által letöltésre kerülnek, nem futtatásra.
Továbbá, a fejlesztők számára ma már számos mód áll rendelkezésre a XSS kihasználás kockázatainak csökkentésére:
- a "HTTP Only" jelzőt használva a "Cookies" munkameneti fejlécet hozzáférhetetlenné tehetjük a rosszindulatú JavaScript számára;
- jelentősen megnehezítheti a XSS kihasználását a támadók számára;
- a modern sablonmotorok, mint az Angular vagy a React, automatikusan megtisztítják a felhasználói adatokat, mielőtt a böngészőbe továbbítják őket.
A kétfaktoros hitelesítés sebezhetőségei
A felhasználóknak mindig ajánlott bekapcsolni a 2FA-t (kétfaktoros hitelesítést) a fiókjaik biztonsága érdekében. Valóban, ez egy hatékony módja a támadó hozzáférésének megakadályozására a szolgáltatáshoz, ha a felhasználói adatok kompromittálódtak.
De vajon mindig garantálja a második hitelesítési tényező használata a fiók védelmét? A 2FA megvalósításában olyan biztonsági problémák merülhetnek fel:
- Az OTP kód (egyszeri jelszavak) durva brute force támadása. Ennek ellenére az OTP brute force védelme hiánya, ilyen hibák még a nagy cégeknél is előfordulnak: , .
- Gyenge generálási algoritmus, például a következő kód előrejelzésének lehetősége.
- Logikai hibák, például a lehetőség, hogy más OTP-jét kérje a saját telefonszámára, ahogy ez a Shopify esetében.
A MCS esetében a 2FA a Google Authenticator és A protokoll már kiválóan bevált, de az alkalmazáson belüli kód ellenőrzés implementálását érdemes ellenőrizni.
A MCS-nél a 2FA több helyen is használható:
- A felhasználó hitelesítésekor. Itt van védelmi mechanizmus a bruteforce támadások ellen: a felhasználónak csupán néhány próbálkozása van az egyszer használatos jelszó megadására, ezt követően a belépés egy időre le lesz blokkolva. Ez megakadályozza az OTP-k bruteforce módszerrel történő kitalálását.
- Offline backup kódok generálásakor a 2FA végrehajtásához, valamint annak letiltásakor. Itt a bruteforce kontrollt nem implementálták, ami lehetővé tette, hogy egy fiók jelszavának és egy aktív munkamenetnek a birtokában a backup kódokat újragenerálják vagy teljesen letiltsák a 2FA-t.
Tekintettel arra, hogy a backup kódok ugyanabban a számérték-tartományban helyezkedtek el, mint az alkalmazás által generált OTP-k, a kódok rövid időn belüli kitalálásának esélye jelentősen magasabb volt.
Az OTP kitalálásának folyamata a 2FA letiltásához a „Burp: Intruder” eszköz segítségével.
Eredmény
Összességében a MCS termék biztonságosnak bizonyult. A tesztelés során a pentest csapatnak nem sikerült hozzáférnie az ügyfél virtuális gépeihez és adataikhoz, a feltárt sebezhetőségeket pedig a MCS csapata gyorsan javította.
Fontos megjegyezni, hogy a biztonság egy folyamatos munka. A szolgáltatások nem statikusak, folyamatosan fejlődnek. Teljesen olyan terméket fejleszteni, amely mentes a sebezhetőségektől, lehetetlen. De időben fel lehet ismerni őket és minimalizálni a megismétlődésük esélyét.
Jelenleg az összes említett sebezhetőség már ki lett javítva a MCS-ben. Annak érdekében, hogy az új sebezhetőségek száma minimalizálódjon és a létezésük időtartama csökkenjen, a platform csapata folyamatosan ezt teszi:
- rendszeresen auditokat végez külső cégekkel;
- fenntartja és fejleszti a részvételt;
- biztonsággal foglalkozik. 🙂
Forrás: habr.com
