Poważna luka w zabezpieczeniach witryn PrestaShop

NOWO WYKRYTY EXPLOIT MOŻE UMOŻLIWIĆ ZDALNYM ATAKUJĄCYM PRZEJĘCIE KONTROLI NAD TWOIM SKLEPEM.

Zabezpieczenie sklepu przed atakiem: Zabezpieczenie sklepu przed atkiem

Odbudowa sklepu po ataku: Odbudowa Prestashop po ataku

Atakujący znaleźli sposób na wykorzystanie luki w zabezpieczeniach do wykonania dowolnego kodu na serwerach, na których działają witryny PrestaShop. Aby uzyskać szczegółowe informacje, przeczytaj cały artykuł.

Co się dzieje

Okazuje się, że hakerzy wykorzystują kombinację znanych i nieznanych luk w zabezpieczeniach, aby wstrzyknąć złośliwy kod na stronach PrestaShop, umożliwiając im wykonanie dowolnych instrukcji i potencjalnie kradzież informacji o płatnościach klienta.

Podczas badania tego ataku znaleziony został nieznany wcześniej łańcuch luk w zabezpieczeniach. W tej chwili nie można jednak być pewnym, że to jedyny sposób, w jaki mogą wykonać atak. Ten problem wydaje się dotyczyć sklepów opartych na wersji 1.6.0.10 lub nowszych, które są objęte lukami w iniekcjach SQL. Wersje 1.7.8.2 i nowsze nie są podatne, chyba że uruchamiają moduł lub niestandardowy kod, który sam zawiera lukę typu SQL injection. Zauważ, że wersje 2.0.0~2.1.0 modułu Lista życzeń (blockwishlist) są podatne na ataki.

Jeżeli sklep jest już zarażony, na stronie płatności wyświetla własny moduł nie zależnie od tego czy jest on zainstalowany w sklepie (np: PayPal) - przykład takiej strony poniżej:

Jak działa atak

Atak wymaga, aby sklep był podatny na ataki typu SQL injection. Zgodnie z najlepszą wiedzą najnowsza wersja PrestaShop i jej moduły są wolne od tych luk. Atakujący biorą na cel sklepy korzystające z przestarzałego oprogramowania lub modułów, podatnych modułów stron trzecich lub jeszcze nieodkrytej luki.

Z badań wynika, że ​​powtarzający się modus operandi wygląda tak:

1. Atakujący przesyła żądanie POST do punktu końcowego podatnego na wstrzyknięcie SQL.
2. Po około jednej sekundzie atakujący wysyła na stronę główną żądanie GET bez parametrów. Powoduje to utworzenie pliku PHP o nazwie blm.phpw katalogu głównym sklepu.
3. Atakujący przesyła teraz żądanie GET do nowo utworzonego pliku blm.php, umożliwiając mu wykonanie dowolnych instrukcji.

Po tym, jak atakujący z powodzeniem przejmą kontrolę nad sklepem, wprowadzają fałszywą formę płatności na stronę płatności w sklepie. W tym scenariuszu klienci sklepu mogą wprowadzić informacje o swojej karcie kredytowej w fałszywym formularzu i nieświadomie wysłać je atakującym.

Chociaż wydaje się, że jest to powszechny wzorzec, atakujący mogą używać innego, umieszczając inną nazwę pliku, modyfikując inne części oprogramowania, umieszczając złośliwy kod w innym miejscu, a nawet usuwając ślady po udanym ataku.

Co zrobić, aby Twój sklep był bezpieczny?

Przede wszystkim upewnij się, że Twój sklep i wszystkie moduły są zaktualizowane do najnowszej wersji. Powinno to zapobiec narażeniu Twojego sklepu na znane i aktywnie wykorzystywane luki typu SQL injection.

Zgodnie z naszą obecną wiedzą na temat exploita, osoby atakujące mogą używać funkcji przechowywania pamięci podręcznej MySQL Smarty jako części wektora ataku. Ta funkcja jest rzadko używana i jest domyślnie wyłączona, ale atakujący może ją włączyć zdalnie. Do czasu opublikowania łatki zaleca się przeprowadzenie profesjonalnego audytu sklepy w celu przerwania łańcucha ataków.

Jak stwierdzić, czy Twój sklep został zaatakowany?

Rozważ przejrzenie dziennika logów serwera w poszukiwaniu opisanego powyżej wzorca ataków. Oto przykład udostępniony przez członka społeczności:

- [14/Jul/2022:16:20:56 +0200] "POST /modules/XXX/XXX.php HTTP/1.1" 200 82772 "-" 
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) 
Version/10.0.1 Safari/602.2.14"
 
- [14/Jul/2022:16:20:57 +0200] "GET / HTTP/1.1" 200 63011 "-" 
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/54.0.2840.98 Safari/537.36"
 
- [14/Jul/2022:16:20:58 +0200] "POST /blm.php HTTP/1.1" 200 82696 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"

(Uwaga: ścieżka podatnego modułu została zmodyfikowana ze względów bezpieczeństwa)

Pamiętaj, że nieznalezienie tego wzorca w dziennikach nie musi oznaczać, że Twój sklep nie został dotknięty atakiem: złożoność exploita oznacza, że ​​istnieje kilka sposobów na jego wykonanie, a osoby atakujące mogą również próbować ukryć ślady ingerencji w kod sklepu.

Rozważ skontaktowanie się ze specjalistą w celu przeprowadzenia pełnego audytu witryny i upewnienia się, że żaden plik nie został zmodyfikowany ani nie został dodany żaden złośliwy kod.

Poniżej link do naszej usługi, która zabezpieczy sklep przed tym atakiem (robimy audyt plików sklepu i zabezpieczany go przed działaniem tego exploida):

Poważna luka w PrestaShop exploit - naprawa