készítette: SeerLight
Bármely szolgáltatás kiépítése szükségszerűen magában foglalja a biztonsággal kapcsolatos folyamatos munkát. A biztonság egy folyamatos folyamat, amely magában foglalja a termékbiztonság folyamatos elemzését és javítását, a sebezhetőségekkel kapcsolatos hírek figyelését és még sok mást. Beleértve az auditokat. Az auditokat házon belül és külső szakértők is végzik, akik radikálisan segíthetnek a biztonságban, mivel nincsenek belemerülve a projektbe, és nyitottak.
A cikk a Mail.ru Cloud Solutions (MCS) csapatának a felhőszolgáltatás tesztelésében segített külső szakértők legegyszerűbb véleményéről szól, és arról, hogy mit találtak. Az MCS „külső erőként” az információbiztonsági körökben szerzett nagy szakértelméről ismert Digital Security céget választotta. Ebben a cikkben pedig néhány érdekes biztonsági rést elemezünk, amelyeket egy külső audit során találtak, hogy elkerülje ugyanazt a rake-ot, amikor létrehozza saját felhőszolgáltatását.
Описание продукта
egy platform virtuális infrastruktúra felhőben történő kiépítéséhez. Tartalmazza az IaaS-t, a PaaS-t és a fejlesztők számára kész alkalmazásképek piacterét. Figyelembe véve az MCS architektúrát, a termék biztonságát a következő területeken kellett ellenőrizni:
- a virtualizációs környezet infrastruktúrájának védelme: hipervizorok, útválasztás, tűzfalak;
- az ügyfelek virtuális infrastruktúrájának védelme: elkülönítés egymástól, beleértve a hálózatot, a magánhálózatokat az SDN-ben;
- OpenStack és nyílt összetevői;
- S3 saját tervezésű;
- IAM: több bérlős projektek példaképekkel;
- Vision (számítógépes látás): API-k és sebezhetőségek a képekkel való munka során;
- webes felület és klasszikus webes támadások;
- a PaaS összetevőinek sebezhetőségei;
- Az összes összetevő API-ja.
Talán ez minden, ami elengedhetetlen a további történelemhez.
Milyen munkát végeztek és miért volt rá szükség?
A biztonsági audit célja a biztonsági rések és konfigurációs hibák azonosítása, amelyek személyes adatok kiszivárgásához, érzékeny információk módosításához vagy a szolgáltatás elérhetőségének megzavarásához vezethetnek.
Az átlagosan 1-2 hónapig tartó munka során az auditorok megismétlik a potenciális támadók akcióit, és a kiválasztott szolgáltatás kliens és szerver részeiben keresik a sebezhetőségeket. Az MCS felhőplatform auditja során a következő célokat határoztuk meg:
- A hitelesítés elemzése a szolgáltatásban. Az összetevő sérülékenységei segítenének azonnal bejutni mások fiókjaiba.
- A példakép és a hozzáférés szabályozása a különböző fiókok között. Egy támadó számára kívánatos cél, hogy valaki más virtuális gépéhez hozzáférhessen.
- Ügyféloldali sebezhetőségek. XSS/CSRF/CRLF/stb. Lehetséges rosszindulatú hivatkozásokon keresztül más felhasználókat támadni?
- Szerveroldali sebezhetőségek: RCE és mindenféle injekció (SQL/XXE/SSRF és így tovább). A szerver sebezhetőségeit általában nehezebb megtalálni, de egyszerre több felhasználó kompromittálásához vezetnek.
- A felhasználói szegmens izoláció elemzése hálózati szinten. Egy támadó számára az elszigeteltség hiánya nagymértékben megnöveli a támadási felületet más felhasználókkal szemben.
- Üzleti logikai elemzés. Lehetséges a vállalkozások megtévesztése és virtuális gépek létrehozása ingyen?
Ebben a projektben a munka a „Gray-box” modell szerint zajlott: az auditorok a hétköznapi felhasználók jogosultságaival léptek kapcsolatba a szolgáltatással, de részben birtokolták az API forráskódját, és lehetőségük volt a részleteket tisztázni a fejlesztőkkel. Általában ez a legkényelmesebb, ugyanakkor meglehetősen reális munkamodell: belső információkat a támadó továbbra is gyűjthet, ez csak idő kérdése.
Sebezhetőséget találtak
Mielőtt az auditor különféle hasznos terheket (a támadás végrehajtásához használt hasznos terhet) véletlenszerű helyekre küldene, meg kell értenie, hogyan működnek a dolgok és milyen funkciókat biztosítanak. Úgy tűnhet, hogy ez egy haszontalan gyakorlat, mert a legtöbb vizsgált helyen nem lesz sebezhetőség. De csak az alkalmazás szerkezetének és működési logikájának megértése teszi lehetővé a legösszetettebb támadási vektorok megtalálását.
Fontos, hogy olyan helyeket találjunk, amelyek gyanúsnak tűnnek, vagy valamiben nagyon különböznek a többiektől. Az első veszélyes sebezhetőséget pedig így találták meg.
IDOR
Az IDOR (Insecure Direct Object Reference) biztonsági rések az üzleti logika egyik leggyakrabban előforduló sérülékenysége, amely lehetővé teszi, hogy egyik-másik hozzáférjen olyan objektumokhoz, amelyekhez a hozzáférés valójában nem engedélyezett. Az IDOR sérülékenységei lehetőséget adnak arra, hogy különböző kritikus fokú felhasználókról információkat szerezzenek.
Az egyik IDOR opció a rendszerobjektumokkal (felhasználók, bankszámlák, kosárban lévő tételek) végzett műveletek végrehajtása az objektumok hozzáférési azonosítóinak manipulálásával. Ez a legbeláthatatlanabb következményekhez vezet. Például a pénzküldő számlájának cseréjének lehetősége, amelyen keresztül ellophatja azokat más felhasználóktól.
Az MCS esetében az auditorok most fedezték fel a nem biztonságos azonosítókhoz kapcsolódó IDOR-sebezhetőséget. A felhasználó személyes fiókjában UUID azonosítók segítségével lehetett hozzáférni minden olyan objektumhoz, amely – ahogy a biztonsági szakértők mondják – lenyűgözően bizonytalannak tűnt (vagyis védett a brutális támadásoktól). De bizonyos entitások esetében felfedezték, hogy szabályos, kiszámítható számokat használnak az alkalmazás felhasználóira vonatkozó információk megszerzésére. Gondolom sejthető, hogy lehetett eggyel módosítani a felhasználói azonosítót, újra elküldeni a kérést és így az ACL-t (access control list, adathozzáférési szabályok a folyamatok és felhasználók számára) megkerülve szerezni információkat.
Szerveroldali kérelem-hamisítás (SSRF)
Az OpenSource termékekben az a jó, hogy rengeteg fórum van bennük, ahol részletes technikai leírások találhatók a felmerülő problémákról, és szerencsés esetben a megoldás leírása is. De ennek az éremnek van egy másik oldala is: az ismert sebezhetőségeket is részletesen leírják. Például az OpenStack fórumon csodálatos leírások találhatók a sebezhetőségekről и , melynek kijavítását valamiért senki sem siet.
Az alkalmazások gyakori funkcionalitása, hogy a felhasználó linket küldhet a szervernek, amelyre a szerver rákattint (például egy kép letöltéséhez egy megadott forrásból). Ha a biztonsági eszközök nem szűrik magukat a hivatkozásokat vagy a kiszolgálóról a felhasználóknak visszaküldött válaszokat, akkor ezeket a funkciókat könnyen használhatják a támadók.
Az SSRF sebezhetőségei nagymértékben előmozdíthatják a támadások kialakulását. A támadó a következőket kaphatja:
- korlátozott hozzáférés a megtámadott helyi hálózathoz, például csak bizonyos hálózati szegmenseken keresztül és egy bizonyos protokoll használatával;
- teljes hozzáférés a helyi hálózathoz, ha lehetséges az alkalmazási szintről a szállítási szintre való leminősítés, és ennek eredményeként teljes körű terheléskezelés az alkalmazás szintjén;
- hozzáférés a kiszolgálón lévő helyi fájlok olvasásához (ha a file:/// séma támogatott);
- és még sok más.
Az OpenStackben már régóta ismert egy SSRF sebezhetőség, amely „vak” jellegű: amikor kapcsolatba lép a szerverrel, nem kap választ tőle, hanem a kérés eredményétől függően különböző típusú hibákat/késéseket kap. . Ennek alapján portvizsgálatot végezhet a belső hálózaton lévő gazdagépeken, az ebből eredő összes következménnyel, amit nem szabad alábecsülni. Például egy terméknek lehet egy háttér-API-ja, amely csak a vállalati hálózatról érhető el. A dokumentációval (ne feledkezzünk meg a bennfentesekről) a támadó SSRF-t használhat a belső metódusokhoz való hozzáféréshez. Például, ha valamilyen módon sikerült megszereznie a hasznos URL-ek hozzávetőleges listáját, akkor az SSRF segítségével átnézheti őket, és végrehajthat egy kérést - viszonylagos szóval pénzt utalhat át számláról számlára, vagy módosíthatja a limiteket.
Nem ez az első alkalom, hogy SSRF-sebezhetőséget fedeztek fel az OpenStackben. Régebben közvetlen linkről lehetett VM ISO-képeket letölteni, ami szintén hasonló következményekkel járt. Ezt a funkciót eltávolítottuk az OpenStackből. Úgy tűnik, a közösség ezt tartotta a probléma legegyszerűbb és legmegbízhatóbb megoldásának.
És nyilvánosan elérhető jelentés a HackerOne szolgáltatásból (h1), a már nem vak SSRF kihasználása a példány metaadatainak olvasására a teljes Shopify infrastruktúrához való root hozzáféréshez vezet.
Az MCS-ben két helyen fedeztek fel SSRF sebezhetőséget hasonló funkcionalitással, de ezeket a tűzfalak és egyéb védelem miatt szinte lehetetlen volt kihasználni. Így vagy úgy, de az MCS csapata mindenesetre megoldotta ezt a problémát, anélkül, hogy megvárta volna a közösséget.
XSS parancsértelmezők betöltése helyett
A több száz megírt tanulmány ellenére évről évre még mindig az XSS (cross-site scripting) támadás a legtöbb webes sebezhetőség (vagy ?).
A fájlfeltöltés minden biztonsági kutató kedvenc helye. Gyakran kiderül, hogy betölthet egy tetszőleges szkriptet (asp/jsp/php), és végrehajthat operációs rendszer-parancsokat, a pentesterek terminológiája szerint - „load shell”. De az ilyen sebezhetőségek népszerűsége mindkét irányban működik: emlékeznek rájuk, és jogorvoslatokat dolgoznak ki ellenük, így a közelmúltban a „héj betöltésének” valószínűsége nulla.
A támadócsapat (amelyet a Digital Security képvisel) szerencsés volt. OK, a szerveroldali MCS-ben ellenőrizték a letöltött fájlok tartalmát, csak a képeket engedélyezték. De az SVG is kép. Hogyan lehetnek veszélyesek az SVG-képek? Mert JavaScript-részleteket ágyazhat beléjük!
Kiderült, hogy a letöltött fájlok az MCS szolgáltatás minden felhasználója számára elérhetőek, ami azt jelenti, hogy meg lehet támadni más felhőfelhasználókat, nevezetesen a rendszergazdákat.
Példa egy adathalász bejelentkezési űrlap elleni XSS-támadásra
Példák az XSS támadások kihasználására:
- Miért próbáljunk meg ellopni egy munkamenetet (főleg, hogy ma már mindenhol HTTP-Csak cookie-k vannak, js scriptekkel védve a lopás ellen), ha a betöltött szkript azonnal hozzáférhet az erőforrás API-hoz? Ebben az esetben a rakomány XHR-kérelmekkel módosíthatja a kiszolgáló konfigurációját, például hozzáadhatja a támadó nyilvános SSH-kulcsát, és SSH-hozzáférést kaphat a kiszolgálóhoz.
- Ha a CSP-házirend (tartalomvédelmi szabályzat) tiltja a JavaScript beillesztését, a támadó megúszhatja anélkül. Tiszta HTML használatával hozzon létre egy hamis bejelentkezési űrlapot a webhelyhez, és lopja el a rendszergazda jelszavát ezen a fejlett adathalászattal: a felhasználó adathalász oldala ugyanarra az URL-címre kerül, és a felhasználó számára nehezebb észlelni.
- Végül a támadó intézkedhet — 4 KB-nál nagyobb cookie-k beállítása. A felhasználónak csak egyszer kell megnyitnia a linket, és az egész oldal elérhetetlenné válik mindaddig, amíg a felhasználónak nem jut eszébe konkrétan a böngésző tisztítása: az esetek túlnyomó többségében a webszerver nem hajlandó elfogadni egy ilyen klienst.
Nézzünk egy példát egy másik észlelt XSS-re, ezúttal egy ügyesebb kihasználással. Az MCS szolgáltatás lehetővé teszi a tűzfalbeállítások csoportokba foglalását. A csoportnév volt az, ahol az XSS-t észlelték. Különlegessége az volt, hogy a vektor nem aktiválódott azonnal, nem a szabálylista megtekintésekor, hanem egy csoport törlésekor:
Vagyis a forgatókönyv a következőképpen alakult: a támadó létrehoz egy tűzfalszabályt, amelynek nevében a „load” szerepel, a rendszergazda ezt egy idő után észreveszi, és elindítja a törlési folyamatot. És itt működik a rosszindulatú JS.
Az MCS-fejlesztők számára a feltöltött SVG képek XSS elleni védelme érdekében (ha nem hagyhatók ki), a Digital Security csapata a következőket javasolta:
- Helyezze el a felhasználók által feltöltött fájlokat egy külön domainre, amelynek semmi köze a „cookie-khoz”. A szkript egy másik tartomány kontextusában fut le, és nem jelent veszélyt az MCS-re.
- A szerver HTTP-válaszában küldje el a „Content-disposition: attachment” fejlécet. Ezután a fájlokat a böngésző letölti, és nem hajtja végre.
Ezen túlmenően ma már számos mód áll a fejlesztők rendelkezésére az XSS-kihasználás kockázatának csökkentésére:
- a „Csak HTTP” jelző használatával elérhetetlenné teheti a „Cookies” munkamenet fejléceit a rosszindulatú JavaScript számára;
- sokkal nehezebbé teszi a támadók számára az XSS kihasználását;
- a modern sablonmotorok, például az Angular vagy a React, automatikusan megtisztítják a felhasználói adatokat, mielőtt kiküldenék azokat a felhasználó böngészőjébe.
Kéttényezős hitelesítési biztonsági rések
A fiók biztonságának javítása érdekében a felhasználóknak mindig javasoljuk a 2FA (kéttényezős hitelesítés) engedélyezését. Ez valóban hatékony módja annak, hogy a támadó ne férhessen hozzá egy szolgáltatáshoz, ha a felhasználó hitelesítő adatait feltörték.
De vajon egy második hitelesítési tényező használata mindig garantálja a fiók biztonságát? A 2FA megvalósítása során a következő biztonsági problémák merülnek fel:
- Brute-force keresés az OTP kódban (egyszeri kódok). A működés egyszerűsége ellenére olyan hibákkal, mint az OTP nyers erő elleni védelem hiánya, a nagyvállalatok is találkoznak: , .
- Gyenge generálási algoritmus, például a következő kód előrejelzésének képessége.
- Ilyen logikai hibák, például valaki más OTP-jének lekérése a telefonján a Shopify-tól.
Az MCS esetében a 2FA a Google Authenticator és a . Magát a protokollt már időben tesztelték, de a kódellenőrzés alkalmazásoldali megvalósítását érdemes ellenőrizni.
Az MCS 2FA-t több helyen használják:
- A felhasználó hitelesítésekor. Van védelem a brutális erőszak ellen: a felhasználónak csak néhány próbálkozása van az egyszeri jelszó megadásával, majd a bevitel egy ideig blokkolva van. Ez blokkolja az OTP brute force kiválasztásának lehetőségét.
- Amikor offline biztonsági mentési kódokat generál a 2FA végrehajtásához, valamint letiltja azt. Itt nem került bevezetésre a brute force védelem, ami lehetővé tette a fiókhoz tartozó jelszó és aktív munkamenet esetén a biztonsági kódok újragenerálását vagy a 2FA teljes letiltását.
Tekintettel arra, hogy a biztonsági kódok ugyanabban a karakterlánc-érték tartományban helyezkedtek el, mint az OTP-alkalmazás által generáltak, sokkal nagyobb volt az esélye annak, hogy rövid időn belül megtalálják a kódot.
Az OTP kiválasztásának folyamata a 2FA letiltásához a „Burp: Intruder” eszköz segítségével
Eredmény
Összességében az MCS termékként biztonságosnak tűnik. Az ellenőrzés során a pentesting csapat nem tudott hozzáférni az ügyfelek virtuális gépeihez és adataihoz, a talált sebezhetőségeket pedig az MCS csapata gyorsan kijavította.
De itt fontos megjegyezni, hogy a biztonság folyamatos munka. A szolgáltatások nem statikusak, folyamatosan fejlődnek. Teljesen sebezhetőség nélkül pedig lehetetlen terméket fejleszteni. De időben megtalálhatja őket, és minimálisra csökkentheti megismétlődésük esélyét.
Most már az összes említett sebezhetőséget javították az MCS-ben. Az újak számának minimálisra csökkentése és élettartamuk csökkentése érdekében a platform csapata továbbra is ezt teszi:
- rendszeresen végez auditot külső társaságok által;
- a részvétel támogatása és fejlesztése;
- vegyenek részt a biztonságban. 🙂
Forrás: will.com