Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Walidacja wejścia od użytkownika (hackera) tylko po stronie frontendu (tj. w tylko w JavaScript)? Takie rzeczy się cały czas zdarzają i to w polskich systemach rządowych.

28 sierpnia 2024, 10:35 | W biegu | 1 komentarz

Tytułowa ciekawostka z raportu „o stanie bezpieczeństwa cyberprzestrzeni RP” opublikowanego przez ABW:

W aplikacji WWW podlegającej ocenie bezpieczeństwa, w jednym z jej formularzy, istniała możliwość wgrywania plików przez użytkownika. Funkcjonalność weryfikacji rozszerzenia wgrywanych plików zaimplementowana była wyłącznie po stronie frontend-u , tj. przeglądarki.

Przechwycenie pliku JavaScript odpowiedzialnego za ten mechanizm i jego modyfikacja z wykorzystaniem narzędzia np. Burp Suite, pozwoliła na wgranie pliku na serwer z dowolnym rozszerzeniem.

Chyba nie muszę dodawać, że możliwość uploadu pliki PHP w tym przypadku oznaczała możliwość wykonania dowolnego kodu w OS (poprzez wgranie webshella).

Eeee, w PHP to są same dziury – pomyślicie. No więc inny przykład. Wystawiona konsola zarządzająca serwera aplikacyjnego WebLogic:

Niby potrzeba tutaj loginu / hasła. Ale istnieje podatność CVE-2020-14882, którą udało się wyeksploitować. Mamy tutaj dwa w jednym, tj. ominięcie uwierzytelnienia oraz RCE (zobaczcie po lewej stronie na samym dole polecenie id):

Na uwagę zasługuje też wskazana podatność w FortiMail (CVE-2021-43062). W tym przypadku wystarczyło napisać maila z odpowiednio spreparowanym linkiem. Dla odbiorcy wyglądał on jakby prowadził do domeny .gov.pl a tymczasem… docelowa domena była inna:

Jest też coś w świecie IoT:

Zidentyfikowana została podatność w oprogramowaniu zarządzającym kamerami Hikvision, umożliwiająca nieuprawnionej osobie w sposób anonimowy zwiększenie swoich uprawnień w systemie i uzyskanie dostępu do wrażliwych informacji.

Z innych ciekawostek z tego raportu polecam zerknąć np. na podatność opisaną jako:

Stwierdzono występowanie niewłaściwej walidacji pola „From” w mechanizmie bezpieczeństwa serwera pocztowego. Błąd ten umożliwił podszycie się pod subdomenę w domenie badanej instytucji (…) Wykryty błąd był o tyle istotny, że występował pomimo prawidłowej konfiguracji rekordów TXT w DNS, jak również SPF, DMARC oraz DKIM

Jest też trochę informacji o aktywności grup APT nakierowanych na Polskę, gdzie np wykorzystywano takie 'baity’:

Bait1
Bait2

oraz oczywiście masa statystyk:

Przykładowe statystyki

~ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Przemek

    To nie w PHP są dziury tylko w aplikacjach w nim napisanych, lub na źle skonfigurowanym środowisku które umożliwia uruchomienie skyptu w dowolnej lokalizacji co jest karygodne.

    Odpowiedz

Odpowiedz