API-fejl på en meget brugt Lego online markedsplads kunne have gjort det muligt for angribere at overtage brugerkonti, lække følsomme data gemt på platformen og endda få adgang til interne produktionsdata for at kompromittere virksomhedens tjenester, har forskere fundet.
Forskere fra Salt Labs opdagede sårbarhederne i Bricklink, en digital videresalgsplatform ejet af Lego-koncernen for køb og salg af brugte Legos, hvilket demonstrerer, at - teknologimæssigt i hvert fald - ikke alle virksomhedens legetøjsstykker klikker perfekt på plads.
Salt Securitys forskningsarm opdagede begge sårbarheder ved at undersøge områder af webstedet, der understøtter brugerinputfelter, afslørede Shiran Yodev, Salts Labs sikkerhedsforsker, i en rapport offentliggjort den 15. dec.
Forskerne fandt hver af de kernefejl, der kunne udnyttes til angreb i dele af webstedet, der giver mulighed for brugerinput, som de sagde ofte er et sted, hvor API-sikkerhedsproblemer - et komplekst og dyrt problem for organisationer — opstå.
En fejl var en cross-site scripting (XSS) sårbarhed, der gjorde det muligt for dem at injicere og udføre kode på et offer slutbrugers maskine gennem et udformet link, sagde de. Den anden tillod udførelse af et XML External Entity (XXE) injektionsangreb, hvor et XML-input indeholdende en reference til en ekstern enhed behandles af en svagt konfigureret XML-parser.
API-svagheder er mange
Forskerne var omhyggelige med at understrege, at de ikke havde til hensigt at udpege Lego som en særlig uagtsom teknologiudbyder - tværtimod er API-fejl i internetvendte applikationer utroligt almindelige, sagde de.
Det er der en nøgleårsag til, siger Yodev til Dark Reading: Uanset kompetencen hos et it-design- og udviklingsteam, API-sikkerhed er en ny disciplin, som alle webudviklere og designere stadig er ved at finde ud af.
"Vi finder let den slags alvorlige API-sårbarheder i alle mulige onlinetjenester, vi undersøger," siger han. "Selv virksomheder med det mest robuste applikationssikkerhedsværktøj og avancerede sikkerhedsteams har ofte huller i deres API-forretningslogik."
Og selvom begge fejl nemt kunne have været opdaget gennem førproduktionssikkerhedstest, "API-sikkerhed er stadig en eftertanke for mange organisationer," bemærker Scott Gerlach, medstifter og CSO hos StackHawk, en API-sikkerhedstestudbyder.
"Det kommer normalt ikke i spil, før efter en API allerede er blevet implementeret, eller i andre tilfælde bruger organisationer ældre værktøjer, der ikke er bygget til at teste API'er grundigt, hvilket efterlader sårbarheder som cross-site scripting og injektionsangreb uopdagede," siger han .
Personlig interesse, hurtig reaktion
Forskningen til at undersøge Legos BrickLink var ikke beregnet til at skamme og bebrejde Lego eller "få nogen til at se dårlige ud", men snarere for at demonstrere "hvor almindelige disse fejl er, og at uddanne virksomheder om trin, de kan tage for at beskytte deres nøgledata og tjenester," siger Yodev.
Lego Group er verdens største legetøjsvirksomhed og et massivt genkendeligt mærke, der faktisk kan henlede folks opmærksomhed på problemet, sagde forskerne. Virksomheden tjener milliarder af dollars i omsætning om året, ikke kun på grund af børns interesse i at bruge Lego, men også som følge af et helt voksent hobbymiljø – som Yodev indrømmer, at han er en af – der også indsamler og bygger Lego-sæt.
På grund af Legos popularitet har BrickLink mere end 1 million medlemmer, der bruger dets websted.
Forskerne opdagede fejlene den 18. oktober, og til sin ære svarede Lego hurtigt, da Salt Security afslørede problemerne for virksomheden den 23. oktober, hvilket bekræftede afsløringen inden for to dage. Tests udført af Salt Labs bekræftede kort efter, den 10. november, at problemerne var blevet løst, sagde forskerne.
"På grund af Legos interne politik kan de dog ikke dele nogen information om rapporterede sårbarheder, og vi er derfor ikke i stand til at bekræfte positivt," erkender Yodev. Desuden forhindrer denne politik også Salt Labs i at bekræfte eller afvise, hvis angribere udnyttede en af fejlene i naturen, siger han.
Snakker sårbarhederne sammen
Forskere fandt XSS-fejlen i "Find brugernavn"-dialogboksen i BrickLinks' kuponsøgefunktionalitet, hvilket førte til en angrebskæde ved hjælp af et sessions-id, der blev afsløret på en anden side, sagde de.
"I dialogboksen 'Find brugernavn' kan en bruger skrive en fri tekst, der til sidst ender med at blive gengivet i websidens HTML," skrev Yodev. "Brugere kan misbruge dette åbne felt til at indtaste tekst, der kan føre til en XSS-tilstand."
Selvom forskerne ikke kunne bruge fejlen alene til at starte et angreb, fandt de et eksponeret sessions-id på en anden side, som de kunne kombinere med XSS-fejlen for at kapre en brugers session og opnå kontoovertagelse (ATO), forklarede de. .
"Dårlige skuespillere kunne have brugt denne taktik til fuld kontoovertagelse eller til at stjæle følsomme brugerdata," skrev Yodev.
Forskere afslørede den anden fejl i en anden del af platformen, der modtager direkte brugerinput, kaldet "Upload til Wanted List", som giver BrickLink-brugere mulighed for at uploade en liste over ønskede Lego-dele og/eller -sæt i XML-format, sagde de.
Sårbarheden var til stede på grund af, hvordan webstedets XML-parser bruger XML External Entities, en del af XML-standarden, der definerer et koncept kaldet en entitet, eller en lagerenhed af en eller anden type, forklarede Yodev i indlægget. I tilfældet med BrickLinks-siden var implementeringen sårbar over for en tilstand, hvor XML-processoren kan afsløre fortrolige oplysninger, der typisk ikke er tilgængelige for applikationen, skrev han.
Forskere udnyttede fejlen til at montere et XXE-injektionsangreb, der tillader en systemfil at læse med den kørende brugers tilladelser. Denne type angreb kan også give mulighed for en yderligere angrebsvektor ved hjælp af server-side anmodningsforfalskning, hvilket kan gøre det muligt for en angriber at få legitimationsoplysninger til en applikation, der kører på Amazon Web Services og dermed bryde et internt netværk, sagde forskerne.
Undgå lignende API-fejl
Forskere delte nogle råd til at hjælpe virksomheder med at undgå at skabe lignende API-problemer, som kan udnyttes på internetvendte applikationer i deres egne miljøer.
I tilfælde af API-sårbarheder kan angribere påføre mest skade, hvis de kombinerer angreb på forskellige emner eller udfører dem i hurtig rækkefølge, skrev Yodev, noget forskerne påviste er tilfældet med Lego-fejlene.
For at undgå scenariet skabt med XSS-fejlen, bør organisationer følge tommelfingerreglen "for aldrig at stole på brugerinput," skrev Yodev. "Input bør renses ordentligt og undslippes," tilføjede han og henviste organisationer til XSS Prevention Cheat Sheet af Åbn webapplikationssikkerhedsprojekt (OWASP) for mere information om dette emne.
Organisationer bør også være forsigtige i deres implementering af sessions-id på websteder, der vender mod nettet, fordi det er "et fælles mål for hackere", som kan udnytte det til sessionskapring og kontoovertagelse, skrev Yodev.
"Det er vigtigt at være meget forsigtig, når du håndterer det og ikke udsætte eller misbruge det til andre formål," forklarede han.
Endelig er den nemmeste måde at stoppe XXE-injektionsangreb, som det forskerne demonstrerede, fuldstændigt at deaktivere eksterne entiteter i din XML-parsers konfiguration, sagde forskerne. OWASP'en har en anden nyttig ressource kaldet XXE Prevention Cheat Sheet, som kan vejlede organisationer i denne opgave, tilføjede de.
