Wady API w Lego Marketplace narażają konta użytkowników i dane

Badacze odkryli, że luki API w powszechnie używanym internetowym rynku Lego mogły pozwolić atakującym przejąć konta użytkowników, ujawnić poufne dane przechowywane na platformie, a nawet uzyskać dostęp do wewnętrznych danych produkcyjnych w celu naruszenia usług korporacyjnych.

Badacze z Salt Labs odkryli luki w zabezpieczeniach Bricklink, cyfrowa platforma odsprzedaży, której właścicielem jest Grupa Lego do kupowania i sprzedawania używanych klocków Lego, pokazując, że — w każdym razie pod względem technologicznym — nie wszystkie zabawki firmy pasują idealnie na swoje miejsce.

Dział badawczy Salt Security odkrył obie luki, badając obszary witryny, które obsługują pola wprowadzania danych przez użytkownika, ujawnił Shiran Yodev, badacz bezpieczeństwa Salts Labs w zgłosić opublikowany 15 grudnia.

Badacze znaleźli każdą z podstawowych luk, które można wykorzystać do ataku, w częściach witryny, które umożliwiają wprowadzanie danych przez użytkownika, co, jak twierdzą, często jest miejscem, w którym występują problemy z bezpieczeństwem API — skomplikowany i kosztowny problem dla organizacji — powstań.

Jedną z wad była luka w zabezpieczeniach typu cross-site scripting (XSS), która umożliwiła im wstrzyknięcie i wykonanie kodu na maszynie użytkownika końcowego ofiary za pośrednictwem spreparowanego łącza. Drugi pozwalał na wykonanie ataku typu XML External Entity (XXE), w którym wejście XML zawierające odniesienie do podmiotu zewnętrznego jest przetwarzane przez słabo skonfigurowany parser XML.

Mnożą się słabe strony API

Badacze starali się podkreślić, że nie zamierzali wyróżniać Lego jako szczególnie niedbałego dostawcy technologii — wręcz przeciwnie, powiedzieli, że błędy API w aplikacjach internetowych są niezwykle powszechne.

Jest ku temu kluczowy powód, Yodev mówi Dark Reading: Bez względu na kompetencje zespołu projektowego i programistycznego IT, Bezpieczeństwo interfejsu API to nowa dyscyplina, nad którą wciąż pracują wszyscy programiści i projektanci stron internetowych.

„Z łatwością znajdujemy tego rodzaju poważne luki w interfejsie API we wszelkiego rodzaju usługach online, które badamy” — mówi. „Nawet firmy dysponujące najbardziej niezawodnymi narzędziami do zabezpieczania aplikacji i zaawansowanymi zespołami ds. bezpieczeństwa często mają luki w logice biznesowej API”.

I chociaż obie luki można było łatwo wykryć za pomocą przedprodukcyjnych testów bezpieczeństwa, „Bezpieczeństwo API wciąż jest przedmiotem refleksji wielu organizacji” — zauważa Scott Gerlach, współzałożyciel i CSO w firmie StackHawk, dostawcy testów bezpieczeństwa API.

„Zwykle nie wchodzi w grę, dopóki interfejs API nie zostanie już wdrożony lub w innych przypadkach organizacje używają starszych narzędzi, które nie zostały stworzone do dokładnego testowania interfejsów API, pozostawiając nieodkryte luki w zabezpieczeniach, takie jak skrypty między witrynami i ataki polegające na wstrzykiwaniu” — mówi. .

Osobiste zainteresowanie, szybka reakcja

Badania mające na celu zbadanie Lego BrickLink nie miały na celu zawstydzenia i obwiniania Lego ani „postawienia kogokolwiek w złym świetle”, ale raczej wykazania „jak powszechne są te błędy i edukowania firm, jakie kroki mogą podjąć, aby chronić swoje kluczowe dane i usługi”. mówi Jodew.

Naukowcy stwierdzili, że Grupa Lego jest największą na świecie firmą produkującą zabawki i masowo rozpoznawalną marką, która rzeczywiście może zwrócić uwagę ludzi na ten problem. Firma zarabia miliardy dolarów rocznie, nie tylko dzięki zainteresowaniu dzieci klockami Lego, ale także dzięki całej społeczności dorosłych hobbystów — do której Yodev przyznaje, że jest jednym — która również kolekcjonuje i buduje zestawy Lego.

Ze względu na popularność klocków Lego, BrickLink ma ponad 1 milion członków, którzy korzystają z jego strony.

Badacze odkryli wady 18 października i trzeba przyznać, że Lego szybko zareagowało, gdy Salt Security ujawniło problemy firmie 23 października, potwierdzając ujawnienie w ciągu dwóch dni. Testy przeprowadzone przez Salt Labs potwierdziły wkrótce potem, 10 listopada, że ​​problemy zostały rozwiązane, twierdzą naukowcy.

„Jednak ze względu na wewnętrzną politykę Lego nie mogą udostępniać żadnych informacji dotyczących zgłoszonych luk w zabezpieczeniach, dlatego nie jesteśmy w stanie pozytywnie potwierdzić” — przyznaje Yodev. Co więcej, ta polityka uniemożliwia również Salt Labs potwierdzanie lub zaprzeczanie, czy atakujący wykorzystali którąkolwiek z luk w środowisku naturalnym, mówi.

Łączenie luk w zabezpieczeniach

Naukowcy odkryli lukę XSS w oknie dialogowym „Znajdź nazwę użytkownika” funkcji wyszukiwania kuponów BrickLinks, prowadzącą do łańcucha ataków z użyciem identyfikatora sesji ujawnionego na innej stronie.

„W oknie dialogowym „Znajdź nazwę użytkownika” użytkownik może napisać dowolny tekst, który ostatecznie zostanie wyświetlony w kodzie HTML strony internetowej” — napisał Yodev. „Użytkownicy mogą nadużywać tego otwartego pola do wprowadzania tekstu, co może prowadzić do warunku XSS”.

Chociaż badacze nie mogli samodzielnie wykorzystać tej luki do przeprowadzenia ataku, znaleźli ujawniony identyfikator sesji na innej stronie, który mogli połączyć z luką XSS w celu przejęcia sesji użytkownika i przejęcia konta (ATO). .

„Źli aktorzy mogli wykorzystać te taktyki do pełnego przejęcia konta lub kradzieży poufnych danych użytkownika” – napisał Yodev.

Badacze odkryli drugą lukę w innej części platformy, która otrzymuje bezpośrednie dane wejściowe użytkownika, o nazwie „Prześlij do listy poszukiwanych”, która umożliwia użytkownikom BrickLink przesyłanie listy poszukiwanych części i / lub zestawów Lego w formacie XML.

Luka w zabezpieczeniach była związana ze sposobem, w jaki parser XML witryny wykorzystuje zewnętrzne jednostki XML, część standardu XML, która definiuje koncepcję zwaną jednostką lub jednostką pamięci pewnego typu, wyjaśnił Yodev w poście. Napisał, że w przypadku strony BrickLinks implementacja była podatna na sytuację, w której procesor XML może ujawnić poufne informacje, które zazwyczaj nie są dostępne dla aplikacji.

Badacze wykorzystali tę lukę, aby przeprowadzić atak wstrzykiwania XXE, który umożliwia odczyt pliku systemowego z uprawnieniami uruchomionego użytkownika. Ten rodzaj ataku może również pozwolić na dodatkowy wektor ataku z wykorzystaniem fałszowania żądań po stronie serwera, co może umożliwić atakującemu uzyskanie danych uwierzytelniających dla aplikacji działającej w Amazon Web Services, a tym samym naruszenie sieci wewnętrznej, stwierdzili naukowcy.

Unikanie podobnych błędów API

Badacze podzielili się radami, które pomogą przedsiębiorstwom uniknąć tworzenia podobnych problemów z API, które mogą być wykorzystywane w aplikacjach internetowych w ich własnych środowiskach.

W przypadku luk w interfejsie API atakujący mogą wyrządzić największe szkody, łącząc ataki na różne problemy lub przeprowadzając je w krótkich odstępach czasu.

Aby uniknąć scenariusza stworzonego z luką XSS, organizacje powinny postępować zgodnie z praktyczną zasadą „nigdy nie ufać wprowadzaniu danych przez użytkownika”, napisał Yodev. „Wejście powinno być odpowiednio oczyszczone i zabezpieczone” — dodał, odsyłając organizacje do ściągawki dotyczącej zapobiegania XSS opracowanej przez Otwórz projekt bezpieczeństwa aplikacji sieci Web (OWASP), aby uzyskać więcej informacji na ten temat.

Organizacje powinny również zachować ostrożność przy wdrażaniu identyfikatora sesji na stronach internetowych, ponieważ jest to „powszechny cel hakerów”, którzy mogą go wykorzystać do przejęcia sesji i konta, napisał Yodev.

„Ważne jest, aby zachować ostrożność podczas obchodzenia się z nim i nie wystawiać go ani nie wykorzystywać niewłaściwie do innych celów” – wyjaśnił.

Wreszcie, zdaniem naukowców najłatwiejszym sposobem powstrzymania ataków polegających na wstrzykiwaniu XXE, takich jak ten, który wykazali badacze, jest całkowite wyłączenie jednostek zewnętrznych w konfiguracji parsera XML. Dodali, że OWASP ma inny przydatny zasób o nazwie Ściągawka zapobiegawcza XXE, który może pomóc organizacjom w tym zadaniu.