Zwykłe konto.
Dostęp do sekretów.

Serwer administracyjny też potrzebuje pentestu

Narzędzie do zarządzania infrastrukturą przechowuje informacje, które mogą być równie cenne jak dane w aplikacji biznesowej: konfiguracje urządzeń, poświadczenia integracji i materiały diagnostyczne. W jednym z ostatnich autoryzowanych testów sprawdziliśmy taki serwer z poziomu zwykłego konta systemowego. Interesowało nas, jakie granice bezpieczeństwa istnieją po zalogowaniu i czy aplikacja otrzymuje tylko niezbędne uprawnienia.

To zanonimizowane studium przypadku. Pomijamy nazwę klienta, produkt, wersje, adresy, nazwy hostów i wartości sekretów. Potwierdzony wynik to odczyt produkcyjnej konfiguracji przez nieuprzywilejowane konto oraz błędy konfiguracji usług. Nie deklarujemy przejęcia bazy, wykonania kodu ani pobrania plików z innego hosta, bo takich prób w tym zakresie nie wykonywaliśmy.

Plik .env był czytelny dla zwykłego użytkownika

Konfiguracja aplikacji była przechowywana w pliku, który mogli odczytać także użytkownicy spoza konta aplikacyjnego. Sprawdziliśmy prawa rzeczywistego pliku docelowego i katalogów na jego ścieżce. Było to istotne, ponieważ sama nazwa lub lokalizacja dowiązania nie wyjaśnia, kto ostatecznie ma dostęp do danych.

Potwierdziliśmy obecność sekretów produkcyjnych, w tym poświadczeń związanych z bazą i integracjami. Ich wartości nie są potrzebne do publicznego wyjaśnienia problemu. Dla właściciela systemu ważniejszy jest wniosek: użytkownik z ograniczonym kontem mógł zdobyć informacje przeznaczone dla procesu aplikacji.

MariaDB nasłuchiwała szerzej, niż potrzebowała aplikacja

Na tym samym hoście baza nasłuchiwała na wszystkich interfejsach IPv4. W połączeniu z ujawnieniem hasła aplikacyjnego tworzyło to istotny scenariusz do dalszej weryfikacji. Ustaliliśmy jednak oddzielnie, co wynikało z konfiguracji, a co wymagałoby połączenia z konkretnej strefy sieciowej.

Nasłuch na wszystkich interfejsach nie jest dowodem publicznej dostępności z internetu. Nie potwierdza również, że ujawnione hasło wystarcza do logowania: znaczenie mają reguły sieciowe, konto bazy i jego uprawnienia. Dlatego opisaliśmy nadmierną powierzchnię nasłuchu oraz kompromitację sekretu, bez dopisywania nieprzeprowadzonego dostępu do danych.

TFTP i katalog z konfiguracjami oraz przechwyceniami ruchu

Aktywna usługa TFTP wskazywała katalog zawierający konfiguracje urządzeń i pliki PCAP. W takim miejscu mogą znajdować się informacje o sieci i dane administracyjne. Zawartości tych plików nie analizowaliśmy, dlatego nie przypisujemy im konkretnych haseł ani danych osobowych.

Potwierdziliśmy uruchomioną usługę i obecność materiału wymagającego kontroli dostępu. Nie wykonywaliśmy zdalnego transferu. Rekomendacja obejmowała weryfikację osiągalności ze stref sieciowych, ograniczenie dostępu, uporządkowanie retencji i rozważenie bezpieczniejszego sposobu dystrybucji plików. Folder diagnostyczny również musi mieć właściciela i zasady przechowywania.

Redis był lokalny, ale bez uwierzytelnienia

Redis odpowiadał na podstawowe sprawdzenie bez uwierzytelnienia. Jednocześnie nasłuchiwał wyłącznie na interfejsie lokalnym. To ważna różnica: nie opisaliśmy otwartego na internet serwera Redis. Ryzyko dotyczyło lokalnych procesów i użytkowników na hoście.

Konfiguracja aplikacji wskazywała użycie Redis do przechowywania stanu aplikacyjnego. Nie przeglądaliśmy kluczy ani ich wartości. Zalecono rozdzielenie uprawnień i ograniczenie dostępnych operacji, z zachowaniem ograniczonej powierzchni sieciowej. Dokumentacja producenta opisuje rolę izolacji sieciowej i ACL w ochronie Redis.

Procesy kolejki działały jako root

Przegląd procesów wykazał, że workery obsługujące zadania aplikacyjne działały z uprawnieniami administratora systemu. Taka konfiguracja powiększa skutki ewentualnego błędu w zadaniu. Jest istotna nawet wtedy, gdy sam test nie obejmuje wstrzykiwania komunikatów ani wykonywania poleceń.

Oddzieliliśmy ją od typowej architektury PHP-FPM: uprawniony proces nadrzędny nie oznacza automatycznie, że każde żądanie WWW wykonuje się jako root. W tym środowisku procesy robocze WWW miały inne konto. Raport powinien wskazywać właściwy proces i rzeczywistą granicę uprawnień.

Jak przekładamy ustalenia na działania

Najpierw sekrety i dostęp. Ograniczenie praw do konfiguracji, kontrolowana rotacja ujawnionych poświadczeń i sprawdzenie, które procesy muszą je odczytywać.

Następnie usługi i konta. Zmniejszenie powierzchni nasłuchu bazy, ocena dostępności TFTP, dedykowane konto dla workerów i ograniczone uprawnienia Redis.

Na końcu weryfikacja skuteczności. Retest z perspektywy zwykłego konta i uzgodnionych stref sieciowych. Sprawdzamy, czy zabezpieczenia działają po restarcie i kolejnym wdrożeniu. Ogólne zasady cyklu życia i rotacji sekretów opisuje OWASP Secrets Management Cheat Sheet.

O co pytają właściciele i zespoły IT?