Kontekst i cel analizy
W ramach wewnętrznych testów skuteczności narzędzia TestSec, przeanalizowano aplikację webową udostępnioną pod adresem IP 185.X.X.57. Celem było sprawdzenie, jak system radzi sobie z wykrywaniem realnych zagrożeń, które mogłyby wystąpić w środowisku produkcyjnym. W szczególności skupiono się na potencjalnych wyciekach danych uwierzytelniających oraz nienależycie zabezpieczonych zasobach publicznych.
Wykryta podatność
Podczas rekonesansu TestSec zidentyfikował publicznie dostępny katalog:https://185.X.X.57/zgloszenia/
Dostęp do katalogu nie był objęty żadnym mechanizmem autoryzacji. Znajdował się tam formularz zgłoszeniowy, który w kodzie HTML zawierał odwołanie do zewnętrznego pliku JavaScript:https://185.X.X.57/zgloszenia/script/script.js
Analiza zawartości pliku script.js ujawniła funkcję sendEmails(), która implementowała zapytania CORS (Cross-Origin Resource Sharing) oraz wykorzystywała nagłówek Authorization z metodą Basic Auth. Co kluczowe, dane uwierzytelniające zostały zakodowane w base64 i umieszczone bezpośrednio w kodzie klienta.
Po odszyfrowaniu ujawniono:
Login: klaudiusz.XXXXXXX
Hasło: c@mXXXXXX11
Struktura loginu wskazywała na powiązanie z kontem w domenie Active Directory, co oznaczało, że dane te mogły mieć zastosowanie nie tylko w kontekście testowanej aplikacji, ale również w szerszym zakresie systemów organizacyjnych.
Ocena ryzyka – CVSS 8.3
Zidentyfikowana luka została zakwalifikowana jako wysokiego ryzyka, z oceną:
CVSS: 3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L
czyli 8.3 – High Severity.
Kluczowe zagrożenia obejmowały:
Możliwość nieautoryzowanego dostępu do systemu
Naruszenie poufności i integralności danych
Ryzyko eskalacji przywilejów i lateralnego ruchu w sieci
Niezgodność z wymaganiami regulacyjnymi (np. NIS2, DORA)
Tego rodzaju podatność nie generuje standardowych alertów i mogłaby pozostać niewykryta przez klasyczne narzędzia skanujące.
Rekomendacje naprawcze
Zespół TestSec przygotował następujące zalecenia:
1. Usunięcie danych uwierzytelniających z kodu źródłowego
Pliki frontendowe nie powinny zawierać żadnych poświadczeń — ani zakodowanych, ani jawnym tekstem. Należy je natychmiast usunąć i wdrożyć proces audytu kodu pod kątem występowania tego typu danych.
2. Wyłączenie publicznego dostępu do katalogu /zgloszenia/
Zaleca się zastosowanie mechanizmów kontroli dostępu:
Dla Apache (ograniczenie do konkretnego IP):
Dla Nginx (ograniczenie do IP):
Dla pełnej blokady dostępu (Apache):
Dla pełnej blokady dostępu (Nginx):
3. Zmiana hasła użytkownika
Hasło konta klaudiusz.XXXXXXX powinno zostać niezwłocznie zmienione i zastąpione silnym, unikalnym hasłem zgodnym z polityką bezpieczeństwa organizacji.
4. Przegląd bezpieczeństwa kodu
Zaleca się cykliczne przeprowadzanie manualnych testów bezpieczeństwa oraz wdrożenie procesu secure code review dla całej aplikacji.
Zidentyfikowana podatność miała potencjalnie poważne konsekwencje — mimo że jej przyczyna wydawała się prozaiczna: pozostałość po środowisku testowym lub niedopilnowany fragment kodu wdrożony na produkcję.
TestSec udowodnił swoją skuteczność w wykrywaniu luk, które nie pojawią się w wynikach automatycznych skanerów, ale mogą zostać wykorzystane przez atakującego. Dzięki połączeniu rozpoznania struktury aplikacji, analizy kodu klienta i kontekstowego zrozumienia działania systemu, możliwe było pełne zidentyfikowanie i ocenienie ryzyka.
