Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W sektorze finansowym tradycyjny model corocznych testów penetracyjnych coraz częściej nie nadąża za tempem zmian w infrastrukturze, integracjach i usługach wystawionych do internetu. Problem „345 dni niezweryfikowanej ekspozycji” opisuje lukę pomiędzy krótkim okresem aktywnego testowania a rzeczywistym, całorocznym funkcjonowaniem środowiska produkcyjnego.
W praktyce oznacza to, że organizacja może dysponować aktualnym raportem z pentestu, a jednocześnie przez większość roku działać z nowymi, nieprzetestowanymi zasobami, błędami konfiguracyjnymi i ryzykami pojawiającymi się po wdrożeniach, zmianach DNS czy integracjach zewnętrznych.
W skrócie
- Coroczny pentest obejmuje zwykle jedynie krótki wycinek czasu, a nie pełny cykl życia środowiska.
- Pojedyncza podatność u dostawcy może przełożyć się na ekspozycję danych wielu instytucji jednocześnie.
- Zasoby utrzymywane przez strony trzecie, ale publikowane pod subdomeną banku, często wypadają poza realny zakres testów.
- Zgodność formalna z wymaganiami audytowymi nie gwarantuje pełnej kontroli nad rzeczywistą powierzchnią ataku.
Kontekst / historia
Współczesna bankowość cyfrowa działa w warunkach ciągłej zmiany. Migracje do chmury, wdrożenia portali samoobsługowych, połączenia z fintechami, modernizacje aplikacji oraz przejęcia powodują, że zewnętrzna powierzchnia ataku zmienia się znacznie szybciej niż roczny harmonogram testów bezpieczeństwa.
W analizowanym przypadku wskazano, że skutki pojedynczej podatności mogły objąć dziesiątki instytucji finansowych korzystających ze wspólnej platformy. To pokazuje, że nawet jeśli poprawka dla znanej klasy problemu już istnieje, ryzyko może utrzymywać się długo, jeśli organizacja nie posiada procesu ciągłego wykrywania zmian i ponownej walidacji ekspozycji.
Istotny jest również wymiar regulacyjny. Wymagania sektora finansowego od dawna podkreślają, że testowanie bezpieczeństwa powinno być powiązane ze zmianami infrastruktury, aplikacji i konfiguracji, a nie traktowane wyłącznie jako coroczny obowiązek zgodnościowy.
Analiza techniczna
Opisany scenariusz dotyczył portalu obsługującego procesy kredytowe, dostępnego pod subdomeną banku, lecz utrzymywanego przez zewnętrznego dostawcę platformy. Taka architektura jest dziś powszechna: użytkownik widzi domenę i markę banku, ale aplikacja, logika biznesowa oraz wdrożenia pozostają po stronie partnera technologicznego.
W trakcie testów zidentyfikowano endpoint API zwracający rekordy organizacyjne na podstawie identyfikatora tenant. Kluczowym problemem był brak uwierzytelnienia oraz brak wymaganej sesji użytkownika, co umożliwiało wykonywanie żądań anonimowo. Dodatkowo polityka CORS została skonfigurowana zbyt liberalnie, co zwiększało potencjał nadużycia z poziomu zewnętrznych witryn.
Kolejnym elementem łańcucha ataku była dostępność identyfikatora tenant w publicznie dostępnych zasobach portalu. Atakujący nie musiał więc przełamywać zabezpieczeń ani zgadywać wartości początkowej. Wystarczało odczytać identyfikator, a następnie iterować kolejne wartości. Taka sekwencyjna enumeracja tenantów prowadziła do uzyskiwania rekordów innych instytucji korzystających z tej samej platformy.
Zwracane dane obejmowały informacje o pracownikach, w tym imiona i nazwiska, służbowe adresy e-mail, numery telefonów, stanowiska oraz wewnętrzny kod przypisujący zgłoszenia do konkretnych osób. Ten ostatni element miał szczególne znaczenie, ponieważ mógł posłużyć do tworzenia fałszywych zgłoszeń lub wniosków przypisywanych do określonego pracownika i organizacji.
Z perspektywy bezpieczeństwa był to klasyczny przykład łańcucha kilku pozornie umiarkowanych problemów, które razem tworzą poważną ekspozycję.
- Brak kontroli dostępu do endpointu API.
- Nadmiernie liberalna polityka międzydomenowa.
- Ujawnienie identyfikatora tenant w publicznych zasobach.
- Przewidywalność identyfikatorów.
- Możliwość wykorzystania danych zwrotnych do dalszych operacji biznesowych.
Tego typu scenariusze są trudne do pełnego wychwycenia przez standardowe skanery podatności. Automatyzacja może wykryć brak autoryzacji czy błędne nagłówki, ale zwykle nie potwierdza skutków biznesowych, nie bada logiki wielodostępności i nie analizuje zależności między danymi a procesami operacyjnymi. Do tego potrzebne są testy manualne oraz zrozumienie architektury multi-tenant.
Konsekwencje / ryzyko
Ryzyko w takim przypadku wykracza daleko poza pojedynczą podatność aplikacyjną. Przede wszystkim dochodzi do naruszenia izolacji między tenantami, czyli jednego z najpoważniejszych błędów w architekturze współdzielonych platform. Taka wada podważa podstawowe założenie, że dane jednej instytucji są odseparowane od danych innej.
Ekspozycja danych pracowników tworzy również dogodne warunki do kampanii phishingowych, spear phishingu, oszustw telefonicznych oraz podszywania się pod personel bankowy. Dla przestępców są to dane o wysokiej wartości operacyjnej, ponieważ pozwalają budować wiarygodne scenariusze socjotechniczne.
Dodatkowo możliwość generowania zgłoszeń lub wniosków z użyciem wewnętrznych kodów przypisania może prowadzić do nadużyć procesowych, zakłóceń operacyjnych, prób fraudowych i zanieczyszczenia systemów obsługi klientów. W praktyce oznacza to ryzyko strat wizerunkowych, kosztów operacyjnych oraz konieczność działań zgodnościowych i incydent response.
Warto też pamiętać, że odpowiedzialność reputacyjna zwykle spada na instytucję widoczną w domenie lub adresie URL, nawet jeśli źródłem błędu jest dostawca. Klient, regulator i partner biznesowy postrzegają usługę jako element oferty banku, a nie jako wydzielony komponent strony trzeciej.
Rekomendacje
Organizacje finansowe powinny przejść od modelu punktowego do modelu ciągłej walidacji ekspozycji. Nie chodzi wyłącznie o częstsze zamawianie pentestów, ale o wdrożenie procesu reagującego na zmianę infrastruktury, konfiguracji i usług zewnętrznych.
- Utrzymywać aktualny rejestr zewnętrznej powierzchni ataku, obejmujący domeny, subdomeny, portale partnerów i usługi publikowane pod marką organizacji.
- Traktować migracje, nowe hosty, zmiany DNS, wdrożenia aplikacji i integracje API jako zdarzenia wyzwalające ponowną ocenę bezpieczeństwa.
- Włączać do zakresu testów wszystkie publicznie dostępne zasoby funkcjonujące pod domeną instytucji, nawet jeśli są utrzymywane przez dostawcę.
- Rozszerzać wymagania wobec partnerów o testy izolacji tenantów, kontrolę dostępu do API, bezpieczeństwo logiki biznesowej i walidację konfiguracji CORS.
- Uzupełniać skanowanie automatyczne o testy manualne ukierunkowane na nadużycia wielodostępności, przewidywalność identyfikatorów i brak autoryzacji obiektowej.
- Weryfikować, czy identyfikatory tenantów, klientów lub procesów wewnętrznych nie są ujawniane w zasobach publicznych aplikacji.
- Wdrożyć monitoring zmian ekspozycji zewnętrznej, aby nowe hosty i usługi były wykrywane możliwie blisko momentu publikacji.
- Uporządkować umowy z dostawcami tak, aby zakres testów, obowiązki remediacyjne i wymagania notyfikacyjne były jednoznaczne.
Dobrą praktyką staje się model continuous security validation, w którym automatyczna obserwacja zasobów jest łączona z regularnym testowaniem manualnym elementów, które faktycznie się zmieniły lub pojawiły się w środowisku.
Podsumowanie
Przypadek „345 dni niezweryfikowanej ekspozycji” dobrze pokazuje ograniczenia tradycyjnego, corocznego podejścia do testów penetracyjnych w sektorze finansowym. W nowoczesnym środowisku bankowym ryzyko pojawia się nie tylko w kodzie własnym, ale także w portalach partnerów, integracjach API i usługach działających pod domeną instytucji.
Największym problemem nie jest sam brak testu, lecz brak mechanizmu, który nadąża za zmianą. Organizacje, które nadal opierają bezpieczeństwo wyłącznie na corocznym raporcie z pentestu, ryzykują, że ich rzeczywista ekspozycja przez większość roku pozostanie po prostu nieznana.
Źródła
- What 345 Days of Untested Exposure Looks Like at a Bank — https://www.bleepingcomputer.com/news/security/what-345-days-of-untested-exposure-looks-like-at-a-bank/
- M-Trends 2026 Special Report — https://cloud.google.com/resources/content/m-trends
- CrowdStrike Global Threat Report 2026 — https://www.crowdstrike.com/en-us/global-threat-report/
- NYDFS Cybersecurity Regulation, 23 NYCRR Part 500 — https://www.dfs.ny.gov/industry_guidance/cybersecurity
- FFIEC Information Security Booklet — https://ithandbook.ffiec.gov/