Tenable Nessus 10.12.1 naprawia lukę SQL Injection przy imporcie plików .nessus - Security Bez Tabu

Tenable Nessus 10.12.1 naprawia lukę SQL Injection przy imporcie plików .nessus

Cybersecurity news

Wprowadzenie do problemu / definicja

W Tenable Nessus ujawniono podatność typu SQL Injection związaną z mechanizmem importu wyników skanowania zapisanych w formacie .nessus. Problem dotyczy przetwarzania specjalnie spreparowanego pliku XML, który po zaimportowaniu przez użytkownika z odpowiednimi uprawnieniami może doprowadzić do wykonania nieautoryzowanych zapytań SQL wobec backendowej bazy danych. Luka została oznaczona jako CVE-2026-57588 i usunięta w wersji Nessus 10.12.1.

W skrócie

Podatność dotyczy procesu importu plików wynikowych .nessus, które mogą zawierać złośliwie przygotowane pola XML. Atak wymaga dostarczenia takiego pliku administratorowi lub innemu użytkownikowi z uprawnieniami do importu oraz nakłonienia go do wykonania tej operacji.

  • Podatne są starsze wydania, w tym 10.12.0 i wcześniejsze.
  • Skutkiem udanego ataku może być odczyt danych z backendowej bazy danych.
  • Publiczny proof-of-concept wskazuje możliwość enumeracji schematu i pozyskania metadanych.
  • Producent usunął problem w wersji 10.12.1.

Kontekst / historia

Nessus należy do najczęściej używanych skanerów podatności w środowiskach enterprise, dlatego każda luka dotycząca przetwarzania danych wejściowych ma wysokie znaczenie operacyjne. W tym przypadku wektor ataku nie opiera się na bezpośrednim ruchu sieciowym do usługi, lecz na zaufaniu do importowanych artefaktów roboczych.

To ważne z perspektywy praktyki bezpieczeństwa, ponieważ wiele organizacji wymienia wyniki skanów między zespołami, środowiskami i instancjami produktu. Taki model pracy zwiększa ryzyko, że spreparowany plik zostanie potraktowany jako wiarygodny raport i zaimportowany bez dodatkowej weryfikacji.

Opis podatności wskazuje na scenariusz wymagający udziału użytkownika uprzywilejowanego. Publiczny materiał PoC pojawił się 7 lipca 2026 roku, a producent równolegle udostępnił poprawkę oraz komunikat bezpieczeństwa dla wersji 10.12.1.

Analiza techniczna

Mechanizm importu pliku .nessus opiera się na przetwarzaniu danych XML opisujących hosty, ich właściwości oraz elementy raportu. W opublikowanym proof-of-concept wykorzystano pola tekstowe, takie jak znaczniki hosta oraz zawartość plugin_output, do umieszczenia ciągów przypominających fragmenty zapytań SQL.

Jeżeli aplikacja po stronie serwera buduje operacje bazodanowe w sposób niebezpieczny, bez właściwej walidacji i parametryzacji, złośliwe dane wejściowe mogą zmienić logikę wykonywanego zapytania. W praktyce jest to wariant second-order SQL injection lub import-time SQL injection, ponieważ ładunek trafia do systemu jako zawartość pliku i jest wykonywany dopiero w wewnętrznym pipeline importu.

Taki model bywa trudniejszy do wykrycia niż klasyczne ataki na formularze webowe, ponieważ organizacje często skupiają mechanizmy ochronne na interfejsach HTTP, pomijając parsery plików i procesy ETL. PoC sugeruje możliwość wykonywania zapytań typu UNION SELECT, enumeracji information_schema, prób odczytu informacji o bazie, wersji silnika i użytkowniku, a także wymuszenia opóźnień czasowych charakterystycznych dla testów blind SQL injection.

Materiał techniczny wskazuje również, że atak najlepiej działa przeciwko backendowi PostgreSQL, który jest domyślnie używany przez Nessus. Nie oznacza to automatycznie pełnego przejęcia hosta ani zdalnego wykonania kodu, ale potwierdza realne ryzyko naruszenia poufności danych przechowywanych w bazie aplikacji.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem podatności jest możliwość eksfiltracji danych z bazy obsługującej skaner. W zależności od konfiguracji może to obejmować metadane skanów, informacje o zasobach, fragmenty wyników, strukturę tabel, a także dane pomocne w dalszym rozpoznaniu środowiska.

Nawet jeśli luka nie prowadzi od razu do przejęcia systemu operacyjnego, ujawnienie danych z narzędzia do zarządzania podatnościami ma dużą wartość dla napastnika. Tego typu platformy zawierają informacje o stanie zabezpieczeń infrastruktury, podatnych hostach, konfiguracji usług i priorytetach zespołów bezpieczeństwa.

  • Ryzyko rośnie tam, gdzie importuje się pliki .nessus z zewnętrznych źródeł.
  • Istotnym czynnikiem jest rozproszony obieg raportów bezpieczeństwa.
  • Zagrożenie zwiększa się, gdy wielu administratorów może ręcznie importować artefakty.
  • Brak monitoringu logów aplikacyjnych i bazodanowych utrudnia wykrycie nadużyć.

W praktyce podatność może być elementem szerszego łańcucha ataku łączącego socjotechnikę z technicznym nadużyciem zaufanego workflow administracyjnego.

Rekomendacje

Najważniejszym działaniem jest aktualizacja do Tenable Nessus 10.12.1 lub nowszej wersji. Organizacje korzystające ze starszych wydań powinny potraktować wdrożenie poprawki jako priorytet, szczególnie jeśli import plików .nessus jest częścią codziennych procesów operacyjnych.

  • Ograniczyć możliwość importu plików wynikowych do minimalnej liczby zaufanych administratorów.
  • Blokować lub kierować do kwarantanny pliki pochodzące spoza kontrolowanego łańcucha dostaw.
  • Weryfikować pochodzenie i integralność importowanych raportów.
  • Monitorować logi aplikacyjne i bazodanowe pod kątem anomalii, błędów SQL oraz nietypowych opóźnień.
  • Stosować segmentację sieciową i zasadę najmniejszych uprawnień dla serwera skanera oraz jego bazy danych.
  • Przejrzeć historię wcześniejszych importów, jeśli istnieje podejrzenie użycia niezweryfikowanych plików.

Z perspektywy deweloperskiej przypadek ten ponownie pokazuje znaczenie pełnej parametryzacji zapytań, rygorystycznej walidacji danych pochodzących z plików oraz defensywnego projektowania parserów i mechanizmów importu.

Podsumowanie

CVE-2026-57588 to podatność SQL Injection w Tenable Nessus związana z importem złośliwego pliku .nessus. Choć atak wymaga interakcji uprzywilejowanego użytkownika, scenariusz jest w pełni realistyczny w organizacjach, które przenoszą raporty skanów między zespołami i systemami. Publiczny PoC pokazuje możliwość eksfiltracji danych z backendowej bazy, dlatego szybka aktualizacja do wersji 10.12.1+, ograniczenie importu do zaufanych źródeł oraz wzmożone monitorowanie operacji administracyjnych powinny być traktowane jako podstawowe działania obronne.

Źródła