GCSA Insights: Szczegółowa analiza i przewodnik obrony przed luką „bez gadżetów” w Fastjson 1.2.83 (0day)

lukabezpieczeństwo cybernetyczneFastjson0dayGCSARCE
23 Godzin temuŹródło: crypto.news
GCSA Insights: Szczegółowa analiza i przewodnik obrony przed luką „bez gadżetów” w Fastjson 1.2.83 (0day)

GCSA Global Cybersecurity Alliance opublikował raport szczegółowo opisujący exploit RCE Fastjson 1.2.83, który został odtworzony na wielu wersjach JDK.

GCSA Global Cybersecurity Alliance wyłącznie dzisiaj opublikował raport z analizą techniczną: Fastjson 1.2.83 może wywołać zdalne wykonanie kodu (RCE) bez polegania na tradycyjnych zależnościach Gadget, nawet przy domyślnym ustawieniu AutoType=false. Ta technika exploita została pomyślnie odtworzona od końca do końca na JDK 8, 17, 21 i 25, a także w środowiskach izolacji Spring Boot Loader.

Ta podatność nie jest tradycyjnym atakiem „obejścia czarnej listy w celu znalezienia lokalnego Gadgetu”. Zamiast tego bezpośrednio podważa logikę wykrywania metadanych klas Fastjson, służąc jako kanał do pozyskiwania zdalnych złośliwych klas. Atakujący, który może kontrolować dane wejściowe JSON analizowane przez Fastjson — z wyłączonym SafeMode i dostępną siecią wychodzącą — może osiągnąć nieuwierzytelnione zdalne wykonanie kodu bez wymagania żadnych wstępnie zainstalowanych tradycyjnych zależności Gadget (takich jak TemplatesImpl, JNDI lub Commons Collections) w docelowej ścieżce klas.

Wyniki reprodukcji potwierdzają, że ten sam ładunek JSON osiąga pomyślne RCE w środowiskach Temurin JDK 8, 17, 21 i 25 z Spring Boot Loader. Podatność jest oceniana jako wysoka: wektor ataku jest zdalny sieciowo, nie wymaga interakcji użytkownika, a wpływ na poufność, integralność i dostępność jest oceniany jako wysoki.

Kluczowe ustalenia

„AutoType jest domyślnie wyłączone, więc jest bezpieczne” — Nieprawda

„Naprawiono drugi parametr parseObject, więc jest bezpieczne” — Nieprawda

„Brak znanych Gadgetów w ścieżce klas, więc jest bezpieczne” — Nieprawda

„JDK 17+ odrzuca wewnętrzne nazwy http://, więc to co najwyżej SSRF” — Nieprawda

Zalecenia obronne

  • Natychmiast włącz SafeMode: ParserConfig.getGlobalInstance().setSafeMode(true);
  • Priorytetowo migruj do Fastjson 2.x i przeprowadź pełne testy regresyjne
  • Ogranicz polityki sieci wychodzącej: zablokuj połączenia HTTP JVM do nieistotnych zewnętrznych adresów
  • Wdróż reguły WAF/bramy, aby blokować żądania JSON, gdzie zdekodowany klucz jest równy @type