Niebezpieczna deserializacja = zdalne wykonanie kodu

Commit To otworzyło tylne drzwi

Dodano nową funkcję do obsługi obiektów przesyłanych przez użytkowników. Wszystko przechodzi testy, ale kilka tygodni później test penetracyjny ujawnia, że atakujący mogą wykonywać polecenia na serwerze; jest to wynik niebezpiecznej deserializacji ukrytej w kodzie. Różnica między deserializacją a zdalnym wykonaniem kodu może być niebezpiecznie mała, zwłaszcza gdy serializowane dane z pakietów open source lub usług wewnętrznych są zaufane bez weryfikacji.

Czym jest deserializacja w kodzie, dlaczego jest ryzykowna i gdzie się ukrywa

Czym jest deserializacja w terminologii programistycznej? To proces polegający na przekształcaniu danych strukturalnych, JSON, XML, formatów binarnych lub obiektów serializowanych specyficznych dla danego języka w obiekty w pamięci.

Na własną rękę, deserializacja jest nieszkodliwy i powszechny, na przykład:

Java:Czytanie obiektów za pomocą Strumień wejściowy obiektu
Python:Ładowanie danych za pomocą pickle.load
node.js:Parsowanie JSON za pomocą JSON.parse

Ryzyko pojawia się, gdy deserializacja jest stosowana do niezaufanych danych bez weryfikacji. Atakujący może stworzyć dane wejściowe, które uruchamiają łańcuch gadżetów, wykorzystując istniejące ścieżki kodu w niezamierzony sposób, co może prowadzić do zdalnego wykonania kodu.

Niebezpieczny deserializacja często występuje w:

Pakiety Open Source z niebezpiecznymi domyślnymi ustawieniami
Kod niestandardowy zakłada, że zserializowane dane wejściowe są wiarygodne
Interfejsy API stron trzecich zwracają obiekty serializowane bez weryfikacji
Twórz artefakty takich jak:
- Java .ser pliki zawierające obiekty wstępnie zserializowane.
- Python .pkl pliki modeli w procesach uczenia maszynowego.
- Obiekty konfiguracji serializowanej osadzone w obrazach Docker lub kontenerach wdrożeniowych

Urządzenia testowe takich jak:
- Stare, zserializowane dane testowe skopiowane ze migawek produkcyjnych.
- Zserializowane ładunki pobrane z zewnętrznych repozytoriów na potrzeby testów wydajnościowych lub regresyjnych.

Pliki te można wprowadzić do repozytorium i automatycznie ładować podczas testów lub wdrożeń, wyzwalając niebezpieczne deserializacja in CI/CD pipelinejeszcze przed wprowadzeniem kodu do produkcji.

Od niebezpiecznej deserializacji do zdalnego wykonywania kodu: ścieżka ataku

Łańcuch eksploatacji luk w zabezpieczeniach deserializacji często przebiega według jednego z poniższych wzorców:

Do aplikacji wprowadzane są niepewne dane wejściowe.
Niebezpieczna deserializacja powoduje ponowne tworzenie obiektów bez ograniczeń.
Łańcuch gadżetów uruchamia istniejące funkcjonalności w niezamierzony sposób.
Atakujący zwiększa uprawnienia i umożliwia zdalne wykonanie kodu.

Warianty:

Sieci gadżetów Java wykorzystują stare biblioteki, takie jak Apache Commons.
Python .pkl ładowanie modelu z osadzonymi złośliwymi obiektami.
Analiza składniowa JSON w Node.js eval () lub dynamiczne importy.

Pływ:

				
					Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution

Jak wykryć niebezpieczną deserializację przed scaleniem

Wykrycie niebezpiecznej deserializacji przed scaleniem kodu jest znacznie tańsze niż jej naprawa po wdrożeniu. Połączenie automatycznej analizy i proaktywnego testowania sprawdza się najlepiej:

Testowanie bezpieczeństwa aplikacji statycznych (SAST):
- Skonfiguruj skanery w celu wykrywania ryzykownych interfejsów API, takich jak Strumień wejściowy obiektu, pickle.load, YAML.load bez bezpiecznego ładownika.
- Przeskanuj kod źródłowy i artefakty kompilacji/testowania pod kątem zagrożeń deserializacja wzorce.
- Wyświetlaj wyniki bezpośrednio w pull requests aby deweloperzy mogli się nimi zająć przed scaleniem.
CI/CD Integracja:

Przykładowy przepływ pracy:

				
					sql

Commit → SAST scan → PR alert → Fix before merge

Łączenie bloków w przypadku wykrycia krytycznych błędów deserializacji zapobiega przedostawaniu się niebezpiecznego kodu do gałęzi produkcyjnych.

Testy jednostkowe z symulowanymi złośliwymi danymi wejściowymi:
- Stwórz nieszkodliwe, kontrolowane ładunki które imitują typowe obiekty ataków seryjnych.
- Przetestuj, jak aplikacja sobie z nimi radzi; powinna odrzucać, oczyszczać lub rejestrować dane wejściowe zamiast przetwarzać je bezmyślnie.
- Uwzględnij te testy w zautomatyzowanych pipeline więc uruchamiają się przy każdym żądaniu żądania (PR), wcześnie wykrywając niebezpieczne zachowania związane z deserializacją.
- Upewnij się, że ładunki testowe są niewykonywalne i można je bezpiecznie przechowywać w repozytorium, koncentrując się wyłącznie na logice wykrywania.

To wielowarstwowe podejście łączy automatyczne skanowanie z testami wykonywanymi przez programistów, co gwarantuje, że niebezpieczne ścieżki deserializacji zostaną zidentyfikowane i usunięte zanim staną się lukami w zabezpieczeniach umożliwiającymi zdalne wykonanie kodu.

Strategie zapobiegawcze dla programistów: zapobieganie przekształcaniu deserializacji w zdalne wykonywanie kodu

Granice zaufania: Deserializuj tylko z uwierzytelnionych, zweryfikowanych źródeł.
Bezpieczne API:
- Java: Bezpieczne biblioteki z walidacją.
- Python: Użyj json.ładuje() koniec pickle.loads() tam, gdzie to możliwe.
- Node.js: Unikaj eval () lub dynamiczne wykonywanie kodu.
Listy dozwolonych i schematy:Ogranicz dozwolone typy obiektów. Wymuś schematy JSON.
Higiena zależności: Monitoruj pod kątem luk CVE wspominających o deserializacji lub zdalnym wykonywaniu kodu.
Recenzje kodu: Dodaj deserializacja szablony kontroli bezpieczeństwa do przeglądu PR.

Uwaga dotycząca narzędzi: Narzędzia takie jak Xygeni skanowanie kodu i zależności pod kątem niebezpiecznej deserializacji przed scaleniem, identyfikacja obszarów wysokiego ryzyka, dzięki czemu programiści mogą je naprawić na wczesnym etapie.

Przykładowe wzorce wykrywania w różnych językach (Bezpieczny pseudokod)

Wszystkie poniższe przykłady to oczyszczony pseudokod pokazujący wzorce wykrywania, a nie działające exploity:

Java – wykrywanie niebezpiecznego użycia API:

				
					java
// BAD: Accepting untrusted input without validation
ObjectInputStream in = new ObjectInputStream(userInputStream);
Object obj = in.readObject(); // Unsafe - no class type checks

// GOOD: Validate allowed classes before processing
if (allowedClasses.contains(obj.getClass().getName())) {
    process(obj); // Safe processing of approved classes
}

Python – unikanie niebezpiecznej deserializacji:

				
					python
import pickle

# BAD: Loading untrusted serialized data directly
data = pickle.loads(untrusted_input)  # Unsafe - arbitrary object execution risk

# GOOD: Use JSON with schema validation
import json
data = json.loads(untrusted_input)  # Safe when validated against schema

Node.js – Zapobieganie dynamicznemu wykonywaniu kodu:

				
					javascript
// BAD: Executing code from parsed data
let obj = JSON.parse(untrustedInput);
eval(obj.code); // Unsafe - allows arbitrary code execution

// GOOD: Use fixed logic without dynamic execution
let safeObj = JSON.parse(untrustedInput);
process(safeObj); // Handle only expected properties and values

Automatyzacja wykrywania w DevSecOps Pipelines: Wykrywanie deserializacji przed dotarciem do produkcji

Automatyzacja wykrywania niebezpiecznej deserializacji zapewnia luki są wykrywane i naprawiane zanim doprowadzą do zdalnego wykonania kodu w środowisku produkcyjnym.

Pipeline Skanowanie

Uruchom SAST na kodzie źródłowym, plikach konfiguracyjnych i artefaktach kompilacji na każdym etapie commit.
Wykrywaj niebezpieczne wzorce deserializacji w kodzie aplikacji i Zależności.

Inspekcja artefaktów

Scan .ser, .pkl, i inne zserializowane pliki w poszukiwaniu niebezpiecznych wzorców przed wdrożeniem lub uruchomieniem testów.

Pull Request Blokowanie

Bloki zostaną scalone, jeśli wykryto niebezpieczną deserializację.
Pokaż w PR-ach informacje zwrotne umożliwiające podjęcie działań, aby przyspieszyć działania naprawcze.

Wymuszanie testów jednostkowych

Uwzględnij testy jednostkowe z symulowanymi złośliwymi danymi wejściowymi CI/CD pipeline
Kompilacja kończy się niepowodzeniem, jeśli aplikacja przetwarza niebezpieczne dane serializowane zamiast je odrzucać.

Unikanie wyników fałszywie pozytywnych bez osłabiania reguł

Nie należy wyłączać reguł wykrywania w celu „wyciszenia” alertów; może to spowodować, że prawdziwie niebezpieczna deserializacja nie zostanie wykryta.
Użyj kontrolowanej białej listy (listy dozwolonych) dla znanych, bezpiecznych wzorców lub zależności.
Wymagaj weryfikacji bezpieczeństwa przed zatwierdzeniem wpisów na białej liście.
Utrzymuj białą listę pod kontrolą wersji i okresowo ją przeglądaj, aby mieć pewność, że wszystkie wyjątki są uzasadnione i bezpieczne.

Rola Xygeni

Integruje się bezpośrednio z CI/CD pipelines do skanowania zarówno kodu źródłowego, jak i artefaktów kompilacji.
Wykrywa niebezpieczne wzorce deserializacji i ryzykowne zależności na wczesnym etapie cyklu życia.
Obsługuje białą listę opartą na zasadach i obowiązkową kontrolę bezpieczeństwa, równoważąc dokładność wykrywania z produktywnością programistów.

Wyprzedzenie zdalnego wykonywania kodu dzięki bezpiecznej deserializacji

Niebezpieczna deserializacja może pozostać niezauważona, dopóki nie stanie się bezpośrednią ścieżką do zdalnego wykonania kodu. Aby jej zapobiec, należy:

Czym jest deserializacja i jak można ją nadużyć.
Wprowadzanie automatycznego wykrywania do procesu prac programistycznych.
Regularne przeglądanie zależności, artefaktów kompilacji i danych serializowanych używanych w testach.

Praktyczna rola Xygeni w tym procesie:

Skanowanie kodu źródłowego: Identyfikuje niebezpieczne wzorce deserializacji w wielu językach przed scaleniem kodu.
Analiza artefaktów i zależności: Wykrywa ryzykowne pliki serializowane (.ser, .pkl, konfiguracja osadzona) i komponenty innych firm, które mają znane luki w zabezpieczeniach.
Kontrola oparta na zasadach:Obsługuje kontrolowaną listę dozwolonych elementów z weryfikacją bezpieczeństwa, zapewniając, że konieczne wyjątki nie spowodują realnego ryzyka.
Opinie programistów w kontekście:Oznacza dokładną lokalizację i przyczynę niebezpiecznej deserializacji wewnątrz pull requests, co pozwala programistom na natychmiastowe rozwiązywanie problemów i potwierdzanie ich złagodzenia poprzez ponowne skanowanie.

Dzięki bezpośredniej integracji takich kontroli z CI/CDzespoły mogą wykrywać i naprawiać niebezpieczne deserializacji zanim zdąży ona przekształcić się w zdalne wykonanie kodu w środowisku produkcyjnym.

Jak niebezpieczna deserializacja staje się zdalnym wykonaniem kodu (i jak to wykryć przed scaleniem)

Posty, które musisz przeczytać