CMS / DATA PUBLICZNEGO OGŁOSZENIA
PrestaShop 2022: od SQL injection do wykonania kodu
Połączenie luki SQL injection z błędem w obsłudze pamięci podręcznej Smarty mogło pozwolić na przejęcie sklepu.
Co się wydarzyło?
22 lipca 2022 roku zespół PrestaShop ostrzegł przed atakami na sklepy wykorzystującymi połączenie podatności. W komunikacie opisano możliwość wprowadzania złośliwego kodu i ryzyko kradzieży informacji płatniczych. Formalny komunikat o łańcuchu CVE-2022-31181 opublikowano 25 lipca.
Istotnym elementem była możliwość połączenia SQL injection z mechanizmem pamięci podręcznej Smarty przechowywanej w bazie. Kontrola nad danymi mogła otworzyć drogę do wykonania instrukcji PHP. To przykład, w którym jeden błąd staje się wejściem do kolejnego etapu ataku.
Jakie warunki musiały być spełnione?
Atak wymagał podatności SQL injection w sklepie. W pierwszym ostrzeżeniu producent wskazywał, że także nowszy rdzeń mógł być narażony przy użyciu podatnego modułu lub własnego kodu. Stan bezpieczeństwa należało więc oceniać dla całego sklepu, a nie tylko głównego numeru wersji.
Nie każda instalacja miała identyczną drogę ataku. Znaczenie miały używane wersje, rozszerzenia oraz to, czy atakujący mógł wywołać podatną funkcję. Komunikat GHSA podkreślał warunek istnienia SQL injection.
Poprawka i ocena skutków
Wydanie 1.7.8.7 zawierało historyczną poprawkę opisanego problemu. Naprawa drugiego etapu nie usuwała jednak automatycznie niezależnej podatności SQL injection w module. Każdą przyczynę należało ustalić i usunąć.
Co to oznacza dla administratora?
Przy przejęciu sklepu trzeba zbadać pliki, bazę, konta administracyjne oraz zmiany w obsłudze zamówień i płatności. Wgranie czystych plików rdzenia może nie wystarczyć, jeśli pozostaje podatny moduł lub zmienione dane. Przed przywróceniem kopii zapasowej trzeba sprawdzić, czy pochodzi sprzed włamania i czy nie zawiera zmian wprowadzonych przez napastnika.