Na otwartej platformie do organizacji handlu elektronicznego , która zajmuje około rynku systemów do tworzenia sklepów internetowych, luki, których kombinacja pozwala na przeprowadzenie ataku w celu wykonania własnego kodu na serwerze, uzyskania pełnej kontroli nad sklepem internetowym oraz zorganizowania przekierowania płatności. Luki te w wersjach Magento 2.3.2, 2.2.9 i 2.1.18, w których łącznie usunięto 75 problemów związanych z bezpieczeństwem.
Jednym z problemów jest to, że nieautoryzowany użytkownik może umieścić kod JavaScript (XSS), który może być wykonany podczas przeglądania historii anulowanych zakupów w interfejsie administratora. Istota podatności polega na możliwości ominięcia operacji czyszczenia tekstu za pomocą funkcji escapeHtmlWithLinks() podczas przetwarzania uwagi w formularzu anulacji na ekranie początkowym zakupu (użycie tagu „a href=http://onmouseover=... w innym tagu). Problem występuje przy użyciu wbudowanego modułu Authorize.Net, za pomocą którego realizowane są płatności kartą kredytową.
Aby uzyskać pełną kontrolę za pomocą kodu JavaScript w kontekście bieżącej sesji pracownika sklepu, wykorzystuje się drugą lukę, która pozwala na załadowanie pliku phar pod postacią obrazka ( „Deserializacja Phar”). Plik Phar może być przesyłany za pomocą formularza wstawiania obrazków w wbudowanym edytorze WYSIWYG. Po wykonaniu swojego kodu PHP atakujący może następnie zmienić szczegóły płatności lub przechwycić informacje o kartach kredytowych klientów.
Ciekawe, że informacje o problemie XSS zostały przesłane do programistów Magento jeszcze we wrześniu 2018 roku, po czym pod koniec listopada wydano poprawkę, która, jak się okazało, usuwa tylko jeden z przypadków i jest łatwa do obejścia. W styczniu dodatkowo zgłoszono możliwość załadowania pliku Phar pod postacią obrazu i pokazano, jak połączenie dwóch luk może być wykorzystywane do kompromitacji sklepów internetowych. Pod koniec marca w Magento 2.3.1,
2.2.8 i 2.1.17 usunięto problem z plikami Phar, ale zapomniano o poprawce XSS, choć zgłoszenie problemu zostało zamknięte. W kwietniu analiza XSS została wznowiona i problem został rozwiązany w wersjach 2.3.2, 2.2.9 i 2.1.18.
Należy zauważyć, że w podanych wydaniach usunięto również 75 luk w zabezpieczeniach, z których 16 ma poziom niebezpieczeństwa oznaczony jako krytyczny, a 20 problemów może prowadzić do wykonania kodu PHP lub wstrzyknięcia operacji SQL. Większość krytycznych problemów może być zrealizowana tylko przez uwierzytelnionego użytkownika, ale jak pokazano powyżej, wykonanie uwierzytelnionych operacji nie jest trudne do osiągnięcia dzięki lukom XSS, z których w wymienionych wydaniach usunięto kilkadziesiąt.
Źródło: opennet.ru
