A széles körben használt Lego online piactér API-hibái lehetővé tették volna a támadók számára, hogy átvegyék a felhasználói fiókokat, kiszivárogtassák a platformon tárolt érzékeny adatokat, és akár a belső gyártási adatokhoz is hozzáférhessenek a vállalati szolgáltatások veszélyeztetése érdekében – állapították meg a kutatók.
A Salt Labs kutatói felfedezték a sebezhetőséget Bricklink, a tulajdonában lévő digitális viszonteladói platform a Lego csoport használt Legók vásárlására és eladására, ami azt bizonyítja, hogy – technológiailag mindenesetre – a cég játékai közül nem minden pattan a helyére.
Shiran Yodev, a Salts Labs biztonsági kutatója a Salt Security kutatócsoportja mindkét sérülékenységet az oldal felhasználói beviteli mezőket támogató területeinek vizsgálatával fedezte fel. jelentés december 15-én jelent meg.
A kutatók megtalálták a támadásokra kihasználható alapvető hibákat a webhely azon részein, amelyek lehetővé teszik a felhasználói bevitelt, mivel ezek gyakran olyan helyek, ahol API biztonsági problémák merülnek fel. összetett és költséges probléma szervezetek számára – felmerülnek.
Az egyik hiba egy XSS (cross-site scripting) sérülékenység volt, amely lehetővé tette számukra, hogy kódot fecskendezzenek be és hajtsanak végre egy áldozat végfelhasználó gépén egy kialakított hivatkozáson keresztül. A másik egy XML External Entity (XXE) injekciós támadás végrehajtását tette lehetővé, ahol egy külső entitásra való hivatkozást tartalmazó XML-bemenetet egy gyengén konfigurált XML-elemző dolgoz fel.
API-gyengeségek bővelkednek
A kutatók óvatosan hangsúlyozták, hogy nem áll szándékukban kiemelni a Legót, mint egy különösen hanyag technológiai szolgáltatót – éppen ellenkezőleg, az API-hibák hihetetlenül gyakoriak az internetes alkalmazásokban.
Ennek alapvető oka van, mondja Yodev a Dark Readingnek: Függetlenül attól, hogy egy IT tervező és fejlesztő csapat milyen kompetenciával rendelkezik, API biztonság egy új tudományág, amelyen még mindig minden webfejlesztő és tervező dolgozik.
„Könnyen találunk ilyen súlyos API-sebezhetőségeket minden olyan online szolgáltatásban, amelyet vizsgálunk” – mondja. "Még a legrobusztusabb alkalmazásbiztonsági eszközökkel és fejlett biztonsági csapatokkal rendelkező vállalatok is gyakran hiányosak az API üzleti logikájukban."
És bár mindkét hiba könnyen felfedezhető lett volna a gyártás előtti biztonsági teszteléssel, „Az API biztonsága sok szervezet számára még mindig utólag” – jegyzi meg Scott Gerlach, a StackHawk, az API biztonsági tesztelési szolgáltató társalapítója és CSO.
„Általában csak azután lép életbe, hogy egy API-t már telepítettek, vagy más esetekben a szervezetek olyan régebbi eszközöket használnak, amelyeket nem az API-k alapos tesztelésére építettek, így felderítetlenül hagyják a sebezhetőségeket, például a több telephelyen futó parancsfájlokat és az injekciós támadásokat” – mondja. .
Személyes érdeklődés, gyors reagálás
A Lego's BrickLink-et vizsgáló kutatásnak nem az volt a célja, hogy megszégyenítse és hibáztassa a Legót, vagy hogy „bárkinek rosszul nézzen ki”, hanem hogy bemutassa, „milyen gyakoriak ezek a hibák, és hogy felvilágosítsa a vállalatokat a kulcsfontosságú adataik és szolgáltatásaik védelmében megtehető lépésekről”. – mondja Yodev.
A Lego Group a világ legnagyobb játékgyártó cége, és egy masszívan felismerhető márka, amely valóban képes felhívni az emberek figyelmét a problémára – mondták a kutatók. A cég több milliárd dolláros bevételre tesz szert évente, nemcsak azért, mert a gyerekek érdeklődnek a Lego-használat iránt, hanem egy egész felnőtt hobbiközösség eredményeként is – amelyből Yodev bevallja, hogy ő is –, amely Lego készleteket is gyűjt és épít.
A Legos népszerűsége miatt a BrickLink több mint 1 millió tagja használja webhelyét.
A kutatók október 18-án fedezték fel a hibákat, és becsületére legyen mondva, a Lego gyorsan reagált, amikor a Salt Security október 23-án felfedte a problémákat a cégnek, és két napon belül megerősítette a feltárást. A Salt Labs által végzett tesztek nem sokkal később, november 10-én megerősítették, hogy a problémák megoldódtak - közölték a kutatók.
"A Lego belső politikája miatt azonban nem oszthatnak meg semmilyen információt a jelentett sebezhetőségekről, ezért nem tudjuk pozitívan megerősíteni" - nyugtázza Yodev. Sőt, ez az irányelv azt is megakadályozza, hogy a Salt Labs megerősítse vagy cáfolja, ha a támadók a vadonban kihasználták a hibák valamelyikét, mondja.
A sebezhetőségek összegyűjtése
A kutatók az XSS-hibát a BrickLinks kuponkereső funkciójának „Felhasználónév keresése” párbeszédpanelében találták meg, ami egy másik oldalon közzétett munkamenet-azonosítót használó támadási lánchoz vezetett.
„A „Felhasználónév keresése” párbeszédpanelen a felhasználó szabad szöveget írhat, amely végül a weboldal HTML-kódjába kerül” – írta Yodev. "A felhasználók visszaélhetnek ezzel a nyitott mezővel olyan szöveg bevitelére, amely XSS-feltételhez vezethet."
Bár a kutatók a hibát önmagában nem tudták támadás indítására használni, egy másik oldalon találtak egy fedetlen munkamenet-azonosítót, amelyet az XSS-hibával kombinálva eltéríthetik a felhasználói munkamenetet és elérhetik a fiók átvételét (ATO) – magyarázták. .
"A rossz szereplők használhatták ezeket a taktikákat a fiókok teljes átvételére vagy érzékeny felhasználói adatok ellopására" - írta Yodev.
A kutatók a platform másik, közvetlen felhasználói bevitelt fogadó részében fedezték fel a második hibát, az úgynevezett „Feltöltés a keresett listára”, amely lehetővé teszi a BrickLink felhasználók számára, hogy XML formátumban töltsék fel a keresett Lego alkatrészek és/vagy készletek listáját.
A sérülékenység annak köszönhető, hogy az oldal XML-elemzője XML External Entities-t használ, amely az XML-szabvány része, amely egy entitásnak nevezett fogalmat definiál, vagy valamilyen típusú tárolóegységet - magyarázta Yodev a bejegyzésben. A BrickLinks oldal esetében a megvalósítás sebezhető volt egy olyan állapottal szemben, amelyben az XML processzor olyan bizalmas információkat közölhet, amelyekhez általában nem fér hozzá az alkalmazás – írta.
A kutatók a hibát kihasználva XXE injekciós támadást hajtottak végre, amely lehetővé teszi a rendszerfájlok olvasását a futó felhasználó engedélyével. Ez a fajta támadás egy további támadási vektort is lehetővé tesz szerveroldali kéréshamisítás használatával, ami lehetővé teheti a támadó számára, hogy hitelesítő adatokat szerezzen egy Amazon Web Services-en futó alkalmazáshoz, és ezáltal áttörjön egy belső hálózatot – mondták a kutatók.
Hasonló API hibák elkerülése
A kutatók megosztottak néhány tanácsot, amelyek segíthetnek a vállalkozásoknak abban, hogy ne hozzanak létre hasonló API-problémákat, amelyek kihasználhatók a saját környezetükben az internetre néző alkalmazásokban.
Az API sebezhetősége esetén a támadók akkor tudják a legtöbb kárt okozni, ha különböző kérdésekben kombinálják a támadásokat, vagy gyors egymásutánban hajtják végre azokat, írta Yodev, amit a kutatók kimutattak a Lego hibáival.
Az XSS-hibával létrehozott forgatókönyv elkerülése érdekében a szervezeteknek követniük kell azt az ökölszabályt, hogy „sose bízzanak a felhasználói bevitelben” – írta Yodev. "A bevitt adatokat megfelelően meg kell tisztítani, és el kell hagyni" - tette hozzá, utalva a szervezeteknek az XSS Prevention Cheat Sheet-re. Nyissa meg a Webalkalmazás biztonsági projektet (OWASP) a témával kapcsolatos további információkért.
A szervezeteknek óvatosnak kell lenniük a munkamenet-azonosító alkalmazásánál a webes oldalakon, mert ez „a hackerek gyakori célpontja”, akik felhasználhatják munkamenet-eltérítésre és fiókok átvételére, írta Yodev.
„Fontos, hogy nagyon óvatosan kezeljük, és ne tegyük ki vagy használjuk vissza más célra” – magyarázta.
Végül, a kutatók szerint az XXE injekciós támadások megállításának legegyszerűbb módja, ha teljesen letiltja a külső entitásokat az XML-elemző konfigurációjában. Az OWASP-nek van egy másik hasznos forrása, az XXE Prevention Cheat Sheet, amely segítséget nyújthat a szervezetek számára ebben a feladatban – tették hozzá.
