API-feil i en mye brukt Lego-markedsplass på nett kunne ha tillatt angripere å overta brukerkontoer, lekke sensitive data som er lagret på plattformen, og til og med få tilgang til interne produksjonsdata for å kompromittere bedriftstjenester, har forskere funnet.
Forskere fra Salt Labs oppdaget sårbarhetene i Bricklink, en digital videresalgsplattform som eies av Lego-gruppen for kjøp og salg av brukte Legos, som demonstrerer at – teknologimessig uansett – ikke alle selskapets leketøy klikker perfekt på plass.
Salt Securitys forskningsarm oppdaget begge sårbarhetene ved å undersøke områder på nettstedet som støtter brukerinndatafelt, avslørte Shiran Yodev, sikkerhetsforsker fra Salts Labs i en rapport publisert 15. desember.
Forskerne fant hver av kjernefeilene som kunne utnyttes til angrep i deler av nettstedet som tillater brukerinndata, som de sa ofte er et sted hvor API-sikkerhetsproblemer – et komplekst og kostbart problem for organisasjoner — oppstå.
En feil var en sårbarhet for skripting på tvers av nettsteder (XSS) som gjorde dem i stand til å injisere og utføre kode på en sluttbrukers maskin til et offer gjennom en laget lenke, sa de. Den andre tillot utførelse av et XML External Entity (XXE) injeksjonsangrep, der en XML-inndata som inneholder en referanse til en ekstern enhet behandles av en svakt konfigurert XML-parser.
API-svakheter er mange
Forskerne var nøye med å understreke at de ikke hadde til hensikt å skille ut Lego som en spesielt uaktsom teknologileverandør – tvert imot, API-feil i applikasjoner som vender mot Internett er utrolig vanlige, sa de.
Det er en nøkkelgrunn til det, sier Yodev til Dark Reading: Uansett kompetansen til et IT-design- og utviklingsteam, API-sikkerhet er en ny disiplin som alle webutviklere og designere fortsatt finner ut av.
"Vi finner lett slike alvorlige API-sårbarheter i alle slags nettjenester vi undersøker," sier han. "Selv selskaper med det mest robuste applikasjonssikkerhetsverktøyet og avanserte sikkerhetsteam har ofte hull i deres API-forretningslogikk."
Og selv om begge feilene lett kunne blitt oppdaget gjennom førproduksjonssikkerhetstesting, er "API-sikkerhet fortsatt en ettertanke for mange organisasjoner," bemerker Scott Gerlach, medgründer og CSO hos StackHawk, en leverandør av API-sikkerhetstesting.
"Det kommer vanligvis ikke inn før etter at et API allerede er distribuert, eller i andre tilfeller bruker organisasjoner eldre verktøy som ikke er bygget for å teste API-er grundig, noe som etterlater sårbarheter som skripting på tvers av nettsteder og injeksjonsangrep uoppdaget," sier han .
Personlig interesse, rask respons
Forskningen for å undersøke Legos BrickLink var ikke ment å skamme og skylde på Lego eller «få noen til å se dårlige ut», men snarere å demonstrere «hvor vanlige disse feilene er og å utdanne bedrifter om trinn de kan ta for å beskytte nøkkeldataene og tjenestene deres» sier Yodev.
Lego Group er verdens største leketøysselskap og et massivt gjenkjennelig merke som faktisk kan trekke folks oppmerksomhet til problemet, sa forskerne. Selskapet tjener milliarder av dollar i inntekter per år, ikke bare på grunn av barns interesse for å bruke Legos, men også som et resultat av et helt voksent hobbymiljø – som Yodev innrømmer at han er en av – som også samler inn og bygger Lego-sett.
På grunn av populariteten til Legos har BrickLink mer enn 1 million medlemmer som bruker nettstedet.
Forskerne oppdaget feilene 18. oktober, og Lego svarte raskt da Salt Security avslørte problemene for selskapet 23. oktober, og bekreftet avsløringen innen to dager. Tester utført av Salt Labs bekreftet kort tid etter, 10. november, at problemene var løst, sa forskerne.
"På grunn av Legos interne retningslinjer kan de imidlertid ikke dele noen informasjon om rapporterte sårbarheter, og vi kan derfor ikke bekrefte positivt," erkjenner Yodev. Dessuten forhindrer denne policyen også Salt Labs fra å bekrefte eller avkrefte om angripere utnyttet en av feilene i naturen, sier han.
Ta sammen sårbarhetene
Forskere fant XSS-feilen i "Finn brukernavn"-dialogboksen til BrickLinks' kupongsøkefunksjonalitet, noe som førte til en angrepskjede ved å bruke en økt-ID eksponert på en annen side, sa de.
"I 'Finn brukernavn'-dialogboksen kan en bruker skrive en fritekst som til slutt ender opp i nettsidens HTML," skrev Yodev. "Brukere kan misbruke dette åpne feltet til å legge inn tekst som kan føre til en XSS-tilstand."
Selv om forskerne ikke kunne bruke feilen alene til å sette i gang et angrep, fant de en eksponert økt-ID på en annen side som de kunne kombinere med XSS-feilen for å kapre en brukers økt og oppnå kontoovertakelse (ATO), forklarte de. .
"Dårlige skuespillere kunne ha brukt disse taktikkene for full kontoovertakelse eller for å stjele sensitive brukerdata," skrev Yodev.
Forskere avdekket den andre feilen i en annen del av plattformen som mottar direkte brukerinndata, kalt "Last opp til ønsket liste", som lar BrickLink-brukere laste opp en liste over ønskede Lego-deler og/eller sett i XML-format, sa de.
Sårbarheten var tilstede på grunn av hvordan nettstedets XML-parser bruker XML External Entities, en del av XML-standarden som definerer et konsept kalt en entitet, eller en lagringsenhet av en eller annen type, forklarte Yodev i innlegget. Når det gjelder BrickLinks-siden, var implementeringen sårbar for en tilstand der XML-prosessoren kan avsløre konfidensiell informasjon som vanligvis ikke er tilgjengelig for applikasjonen, skrev han.
Forskere utnyttet feilen til å montere et XXE-injeksjonsangrep som lar en systemfil leses med tillatelsene til den kjørende brukeren. Denne typen angrep kan også tillate en ekstra angrepsvektor ved å bruke serverside-forespørselsforfalskning, noe som kan gjøre det mulig for en angriper å få legitimasjon for en applikasjon som kjører på Amazon Web Services og dermed bryte et internt nettverk, sa forskerne.
Unngå lignende API-feil
Forskere delte noen råd for å hjelpe bedrifter med å unngå å lage lignende API-problemer som kan utnyttes på Internett-vendte applikasjoner i deres egne miljøer.
Når det gjelder API-sårbarheter, kan angripere påføre mest skade hvis de kombinerer angrep på ulike saker eller utfører dem i rask rekkefølge, skrev Yodev, noe forskerne viste er tilfellet med Lego-feilene.
For å unngå scenariet skapt med XSS-feilen, bør organisasjoner følge tommelfingerregelen «å aldri stole på brukerinnspill», skrev Yodev. "Inndata bør renses ordentlig og unngås," la han til, og refererte organisasjoner til XSS Prevention Cheat Sheet av Åpne sikkerhetsprosjekt for webapplikasjoner (OWASP) for mer informasjon om dette emnet.
Organisasjoner bør også være forsiktige med implementeringen av økt-ID på web-vendte nettsteder fordi det er "et vanlig mål for hackere", som kan utnytte det for øktkapring og kontoovertakelse, skrev Yodev.
"Det er viktig å være veldig forsiktig når du håndterer den og ikke eksponere eller misbruke den til andre formål," forklarte han.
Til slutt, den enkleste måten å stoppe XXE-injeksjonsangrep som den forskerne viste, er å fullstendig deaktivere eksterne enheter i XML-parserens konfigurasjon, sa forskerne. OWASP har en annen nyttig ressurs kalt XXE Prevention Cheat Sheet som kan veilede organisasjoner i denne oppgaven, la de til.
