API-brister i Lego Marketplace Placera användarkonton, data i riskzonen PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.

API-brister i Lego Marketplace sätter användarkonton, data i riskzonen

API-brister på en allmänt använd Lego-marknadsplats på nätet kunde ha gjort det möjligt för angripare att ta över användarkonton, läcka känslig data lagrad på plattformen och till och med få tillgång till intern produktionsdata för att äventyra företagstjänster, har forskare funnit.

Forskare från Salt Labs upptäckte sårbarheterna i Bricklink, en digital återförsäljningsplattform som ägs av Legogruppen för att köpa och sälja begagnade Legos, vilket visar att - tekniskt sett i alla fall - inte alla företagets leksaksbitar snäpper perfekt på plats.

Salt Securitys forskningsarm upptäckte båda sårbarheterna genom att undersöka områden på webbplatsen som stöder användarinmatningsfält, avslöjade Shiran Yodev, Salts Labs säkerhetsforskare, i en rapport publicerad den 15 dec.

Forskarna fann var och en av de centrala bristerna som kunde utnyttjas för attack i delar av webbplatsen som tillåter användarinmatning, som de sa ofta är en plats där API-säkerhetsproblem — ett komplext och kostsamt problem för organisationer — uppstå.

En brist var en sårbarhet för cross-site scripting (XSS) som gjorde det möjligt för dem att injicera och exekvera kod på en slutanvändares dator via en skapad länk, sa de. Den andra tillät exekvering av en XML External Entity (XXE)-injektionsattack, där en XML-ingång som innehåller en referens till en extern entitet bearbetas av en svagt konfigurerad XML-parser.

API-svagheter finns i överflöd

Forskarna var noga med att betona att de inte hade för avsikt att peka ut Lego som en särskilt försumlig teknikleverantör – tvärtom, API-brister i applikationer som riktar sig till Internet är otroligt vanliga, sa de.

Det finns en viktig anledning till det, säger Yodev till Dark Reading: Oavsett kompetensen hos ett IT-design- och utvecklingsteam, API-säkerhet är en ny disciplin som alla webbutvecklare och designers fortfarande klurar på.

"Vi hittar lätt den här typen av allvarliga API-sårbarheter i alla typer av onlinetjänster vi undersöker", säger han. "Även företag med de mest robusta applikationssäkerhetsverktygen och avancerade säkerhetsteam har ofta luckor i sin API-affärslogik."

Och även om båda bristerna lätt kunde ha upptäckts genom säkerhetstestning före produktion, är "API-säkerhet fortfarande en eftertanke för många organisationer", konstaterar Scott Gerlach, medgrundare och CSO på StackHawk, en leverantör av API-säkerhetstestning.

"Det kommer vanligtvis inte till spel förrän efter att ett API redan har distribuerats, eller i andra fall, organisationer använder äldre verktyg som inte är byggda för att testa API:er grundligt, vilket lämnar sårbarheter som cross-site scripting och injektionsattacker oupptäckta", säger han .

Personligt intresse, snabb respons

Forskningen för att undersöka Legos BrickLink var inte menad att skämma bort och skylla på Lego eller "få någon att se dålig ut", utan snarare att visa "hur vanliga dessa misstag är och att utbilda företag om steg de kan vidta för att skydda sina nyckeldata och tjänster." säger Yodev.

Lego Group är världens största leksaksföretag och ett massivt igenkännligt varumärke som verkligen kan dra folks uppmärksamhet på frågan, sa forskarna. Företaget tjänar miljarder dollar i intäkter per år, inte bara på grund av barns intresse av att använda Legos utan också som ett resultat av en hel vuxen hobbygemenskap – som Yodev erkänner att han är en av – som också samlar in och bygger Lego-set.

På grund av Legos popularitet har BrickLink mer än 1 miljon medlemmar som använder dess webbplats.

Forskarna upptäckte bristerna den 18 oktober och, till dess kredit, svarade Lego snabbt när Salt Security avslöjade problemen för företaget den 23 oktober, vilket bekräftade avslöjandet inom två dagar. Tester utförda av Salt Labs bekräftade kort efter, den 10 november, att problemen hade lösts, sa forskarna.

"Men på grund av Legos interna policy kan de inte dela någon information om rapporterade sårbarheter, och vi kan därför inte bekräfta positivt", erkänner Yodev. Dessutom förhindrar denna policy också Salt Labs från att bekräfta eller förneka om angripare utnyttjade någon av bristerna i det vilda, säger han.

Snäppa ihop sårbarheterna

Forskare fann XSS-felet i dialogrutan "Hitta användarnamn" i BrickLinks kupongsökningsfunktion, vilket ledde till en attackkedja med ett sessions-ID exponerat på en annan sida, sa de.

"I dialogrutan "Hitta användarnamn" kan en användare skriva en fri text som så småningom hamnar i webbsidans HTML, skrev Yodev. "Användare kan missbruka detta öppna fält för att mata in text som kan leda till ett XSS-tillstånd."

Även om forskarna inte kunde använda felet på egen hand för att starta en attack, hittade de ett exponerat sessions-ID på en annan sida som de kunde kombinera med XSS-felet för att kapa en användares session och uppnå kontoövertagande (ATO), förklarade de. .

"Dåliga skådespelare kunde ha använt den här taktiken för att ta över hela kontot eller för att stjäla känslig användardata", skrev Yodev.

Forskare avslöjade den andra bristen i en annan del av plattformen som tar emot direkt användarinput, kallad "Ladda upp till efterlyst lista", som gör att BrickLink-användare kan ladda upp en lista över önskade Lego-delar och/eller set i XML-format, sa de.

Sårbarheten var närvarande på grund av hur webbplatsens XML-parser använder XML External Entities, en del av XML-standarden som definierar ett koncept som kallas en entitet, eller en lagringsenhet av någon typ, förklarade Yodev i inlägget. När det gäller sidan BrickLinks var implementeringen sårbar för ett tillstånd där XML-processorn kan avslöja konfidentiell information som vanligtvis inte är tillgänglig för applikationen, skrev han.

Forskare utnyttjade bristen för att montera en XXE-injektionsattack som gör att en systemfil kan läsas med behörighet från den körande användaren. Den här typen av attack kan också tillåta ytterligare en attackvektor genom att använda server-side request förfalskning, vilket kan göra det möjligt för en angripare att få referenser för en applikation som körs på Amazon Web Services och därmed bryta mot ett internt nätverk, sa forskarna.

Undviker liknande API-brister

Forskare delade med sig av några råd för att hjälpa företag att undvika att skapa liknande API-problem som kan utnyttjas på Internetanvändande applikationer i deras egna miljöer.

I fallet med API-sårbarheter kan angripare orsaka störst skada om de kombinerar attacker på olika frågor eller utför dem i snabb följd, skrev Yodev, något som forskarna visade är fallet med Lego-bristerna.

För att undvika scenariot som skapats med XSS-felet bör organisationer följa tumregeln "att aldrig lita på användarinput", skrev Yodev. "Indata bör saneras ordentligt och undvikas," tillade han och hänvisade organisationer till XSS Prevention Cheat Sheet av Öppna webbapplikationssäkerhetsprojekt (OWASP) för mer information om detta ämne.

Organisationer bör också vara försiktiga i sin implementering av sessions-ID på webbsidor eftersom det är "ett vanligt mål för hackare", som kan utnyttja det för sessionskapning och kontoövertagande, skrev Yodev.

"Det är viktigt att vara mycket försiktig när du hanterar det och inte exponera eller missbruka det för andra ändamål", förklarade han.

Slutligen, det enklaste sättet att stoppa XXE-injektionsattacker som den som forskare visade är att helt inaktivera Externa Entities i din XML-parsers konfiguration, sa forskarna. OWASP har en annan användbar resurs som heter XXE Prevention Cheat Sheet som kan vägleda organisationer i denna uppgift, tillade de.

Tidsstämpel:

Mer från Mörk läsning