API-puutteet Lego Marketplacessa vaarantavat käyttäjätilit ja tiedot

Tutkijat ovat havainneet, että laajasti käytetyn Lego-verkkomarkkinapaikan API-virheet olisivat voineet antaa hyökkääjille mahdollisuuden ottaa haltuunsa käyttäjätilejä, vuotaa alustalle tallennettuja arkaluonteisia tietoja ja jopa päästä käsiksi sisäisiin tuotantotietoihin vaarantaakseen yrityksen palvelut.

Salt Labsin tutkijat löysivät haavoittuvuudet Bricklink, jonka omistaa digitaalinen jälleenmyyntialusta Lego-ryhmä käytettyjen legojen ostamiseen ja myymiseen, mikä osoittaa, että - joka tapauksessa tekniikan kannalta - kaikki yrityksen lelukappaleet eivät napsahda täydellisesti paikoilleen.

Salt Securityn tutkimusosasto löysi molemmat haavoittuvuudet tutkimalla sivuston alueita, jotka tukevat käyttäjän syöttökenttiä, Salts Labsin tietoturvatutkija Shiran Yodev paljasti raportti julkaistu 15. joulukuuta.

Tutkijat löysivät jokaisen ydinvirheen, joita voitaisiin hyödyntää hyökkäyksiin sellaisissa sivuston osissa, jotka mahdollistavat käyttäjän syötteen, mikä heidän mukaansa on usein paikka, jossa API-tietoturvaongelmat - monimutkainen ja kallis ongelma organisaatioille — syntyy.

He sanoivat, että yksi puute oli cross-site scripting (XSS) -haavoittuvuus, jonka ansiosta he pystyivät syöttämään ja suorittamaan koodia uhrin loppukäyttäjän koneelle muotoillun linkin kautta. Toinen salli XML External Entity (XXE) -injektiohyökkäyksen suorittamisen, jossa heikosti konfiguroitu XML-jäsennin käsittelee XML-syötettä, joka sisältää viittauksen ulkoiseen entiteettiin.

API-heikkouksia on runsaasti

Tutkijat olivat varovaisia ​​korostaakseen, etteivät he aikoneet nostaa Legoa erityisen huolimattomaksi teknologian tarjoajaksi - päinvastoin, API-virheet Internetiin päin olevissa sovelluksissa ovat uskomattoman yleisiä, he sanoivat.

Siihen on keskeinen syy, Yodev kertoo Dark Readingille: Riippumatta IT-suunnittelu- ja kehitystiimin pätevyydestä, API-suojaus on uusi tieteenala, jota kaikki web-kehittäjät ja suunnittelijat ovat edelleen selvittämässä.

"Löydämme helposti tällaisia ​​vakavia API-haavoittuvuuksia kaikenlaisista tutkimistamme verkkopalveluista", hän sanoo. "Jopa yrityksissä, joilla on vankimmat sovellusten suojaustyökalut ja kehittyneet tietoturvatiimit, on usein aukkoja API-liikelogiikassa."

Ja vaikka molemmat puutteet olisi voitu havaita helposti tuotantoa edeltävän tietoturvatestauksen avulla, "API-suojaus on edelleen monille organisaatioille jälkikäteen", huomauttaa Scott Gerlach, yksi perustajista ja CSO StackHawkissa, API-tietoturvatestauspalvelussa.

"Se tulee yleensä käyttöön vasta sen jälkeen, kun API on jo otettu käyttöön, tai muissa tapauksissa organisaatiot käyttävät vanhoja työkaluja, joita ei ole luotu testaamaan sovellusliittymiä perusteellisesti, jolloin haavoittuvuudet, kuten sivustojen välinen komentosarja ja injektiohyökkäykset, jäävät huomaamatta", hän sanoo. .

Henkilökohtainen kiinnostus, nopea vastaus

Legon BrickLinkiä tutkivan tutkimuksen tarkoituksena ei ollut häpeä ja syyttää Legoa tai "saada ketään näyttämään huonolta", vaan pikemminkin osoittamaan "kuinka yleisiä nämä virheet ovat ja kouluttamaan yrityksiä toimista, joilla ne voivat suojata keskeisiä tietojaan ja palvelujaan". Yodev sanoo.

Lego Group on maailman suurin leluyritys ja massiivisesti tunnistettava brändi, joka voi todellakin kiinnittää ihmisten huomion asiaan, tutkijat sanoivat. Yritys ansaitsee miljardeja dollareita vuodessa, ei pelkästään lasten kiinnostuksen vuoksi legojen käyttöä kohtaan, vaan myös koko aikuisten harrastajayhteisön ansiosta – johon Yodev myöntää kuuluvansa – joka myös kerää ja rakentaa Lego-sarjoja.

Legojen suosion vuoksi BrickLinkillä on yli miljoona jäsentä, jotka käyttävät sen sivustoa.

Tutkijat havaitsivat puutteet 18. lokakuuta, ja ansiokkaasti Lego reagoi nopeasti, kun Salt Security paljasti ongelmat yritykselle 23. lokakuuta ja vahvisti paljastamisen kahden päivän kuluessa. Salt Labsin suorittamat testit vahvistivat pian sen jälkeen, 10. marraskuuta, että ongelmat oli ratkaistu, tutkijat sanoivat.

"Legon sisäisen politiikan vuoksi he eivät kuitenkaan voi jakaa tietoja raportoiduista haavoittuvuuksista, emmekä siksi voi vahvistaa positiivisesti", Yodev myöntää. Lisäksi tämä käytäntö estää myös Salt Labsia vahvistamasta tai kieltämästä, jos hyökkääjät käyttivät hyväkseen jotakin puutteita luonnossa, hän sanoo.

Haavoittuvuuksien löytäminen yhdessä

Tutkijat löysivät XSS-virheen BrickLinksin kuponkihakutoiminnon "Etsi käyttäjätunnus" -valintaikkunasta, mikä johti hyökkäysketjuun, jossa käytettiin istuntotunnusta, joka paljastettiin eri sivulla, he sanoivat.

"Etsi käyttäjätunnus" -valintaikkunassa käyttäjä voi kirjoittaa vapaata tekstiä, joka lopulta päätyy verkkosivun HTML-koodiin, Yodev kirjoitti. "Käyttäjät voivat väärinkäyttää tätä avointa kenttää syöttääkseen tekstiä, joka voi johtaa XSS-tilaan."

Vaikka tutkijat eivät voineet käyttää virhettä yksinään hyökkäykseen, he löysivät paljastetun istuntotunnuksen toiselta sivulta, jonka he voisivat yhdistää XSS-virheeseen käyttäjän istunnon kaappaamiseksi ja tilin haltuunoton (ATO) saavuttamiseksi, he selittivät. .

"Huonot toimijat olisivat voineet käyttää näitä taktiikoita tilin täydelliseen haltuunottoon tai arkaluonteisten käyttäjätietojen varastamiseen", Yodev kirjoitti.

Tutkijat paljastivat toisen puutteen alustan toisesta osasta, joka vastaanottaa suoran käyttäjän syötteen, nimeltään "Upload to Wanted List", jonka avulla BrickLinkin käyttäjät voivat ladata listan halutuista Lego-osista ja/tai -sarjoista XML-muodossa, he sanoivat.

Haavoittuvuus johtui siitä, kuinka sivuston XML-jäsennin käyttää XML External Entities -elementtejä, jotka ovat osa XML-standardia, joka määrittelee käsitteen nimeltä entiteetti, tai jonkinlaista tallennusyksikköä, Yodev selitti viestissä. BrickLinks-sivun tapauksessa toteutus oli alttiina tilalle, jossa XML-prosessori saattaa paljastaa luottamuksellisia tietoja, joihin sovellus ei yleensä pääse käsiksi, hän kirjoitti.

Tutkijat käyttivät virhettä hyväkseen asentaakseen XXE-injektiohyökkäyksen, joka mahdollistaa järjestelmätiedoston lukemisen käynnissä olevan käyttäjän luvalla. Tämäntyyppinen hyökkäys voi myös mahdollistaa ylimääräisen hyökkäysvektorin käyttämällä palvelinpuolen pyyntöväärennöstä, mikä saattaa antaa hyökkääjälle mahdollisuuden saada tunnistetiedot Amazon Web Services -palvelussa toimivaan sovellukseen ja siten murtaa sisäinen verkko, tutkijat sanoivat.

Samankaltaisten API-virheiden välttäminen

Tutkijat jakoivat neuvoja, joiden avulla yritykset voivat välttää luomasta samanlaisia ​​API-ongelmia, joita voidaan hyödyntää Internetiin päin olevissa sovelluksissa omassa ympäristössään.

API-haavoittuvuuksien tapauksessa hyökkääjät voivat aiheuttaa eniten vahinkoa, jos he yhdistävät hyökkäyksiä eri asioihin tai suorittavat ne nopeasti peräkkäin, Yodev kirjoitti, mitä tutkijat osoittivat, että Lego-puutteiden tapauksessa.

Välttääkseen XSS-virheen aiheuttaman skenaarion organisaatioiden tulee noudattaa nyrkkisääntöä "ei koskaan luota käyttäjän syötteeseen", Yodev kirjoitti. "Syöte tulee desinfioida kunnolla ja paeta", hän lisäsi viitaten organisaatioihin XSS Prevention -huijauslehteen. Avaa Web-sovellusten suojausprojekti (OWASP) saadaksesi lisätietoja tästä aiheesta.

Organisaatioiden tulee myös olla varovaisia ​​istuntotunnuksen käyttöönotossa Web-sivustoilla, koska se on "yleinen kohde hakkereille", jotka voivat hyödyntää sitä istuntojen kaappaamiseen ja tilin haltuunottoon, Yodev kirjoitti.

"On tärkeää olla erittäin varovainen käsiteltäessä sitä ja olla paljastamatta tai käyttämättä sitä väärin muihin tarkoituksiin", hän selitti.

Lopuksi, helpoin tapa pysäyttää tutkijoiden osoittaman kaltaiset XXE-injektiohyökkäykset on poistaa ulkoiset entiteetit kokonaan käytöstä XML-jäsentimen määrityksistä, tutkijat sanoivat. OWASP:llä on toinen hyödyllinen resurssi nimeltä XXE Prevention Cheat Sheet, joka voi ohjata organisaatioita tässä tehtävässä, he lisäsivät.