.bank.in: Rejestr stworzony, by chronić – który przez rok chronił... niczyjego

W 2014 roku RBI (Reserve Bank of India) wprowadził domenę .bank.in z prostym celem: stworzyć zweryfikowaną przestrzeń w internecie, gdzie obywatele Indii mogliby bezpiecznie korzystać z usług bankowych. Przez ponad dekadę wszystko wyglądało dobrze. Aż do momentu, gdy badacze bezpieczeństwa odkryli, że przez trzynaście miesięcy z tego samego rejestru wyciekały wrażliwe dane.

Co dokładnie się stało

Eksperci ds. bezpieczeństwa znaleźli API rejestru .bank.in, które nie wymagało żadnego uwierzytelniania. Przez około rok każdy, kto znał podstawy techniczne, mógł pobrać bazę zawierającą:

• Pełne imiona i nazwiska administratorów domen
• Służbowe adresy e-mail
• Numery telefonów
• Dane organizacji – banków i instytucji finansowych

W sumie 5576 rekordów. Ludzie odpowiedzialni za zarządzanie finansową infrastrukturą cyfrową Indii, wystawieni na widok publiczny jak dane na tablicy ogłoszeń na dworcu.

Ironiczny paradoks

Ta sytuacja boli szczególnie z jednego powodu: domeny .bank.in powstały właśnie po to, żeby zwalczać phishing. Cała filozofia RBI była prosta – korzystaj tylko z .bank.in, a masz pewność, że strona jest legalna. Tymczasem ten sam rejestr właśnie dostarczył cyberprzestępcom gotową bazę do... phishingu.

Pomyśl jak atakujący. Zamiast rozsyłać masowe, generyczne e-maile phishingowe, ma teraz zweryfikowane nazwiska, numery telefonów i adresy e-mail prawdziwych administratorów IT w bankach. Kompletny pakiet do ataków typu social engineering. Zamiast szukać igły w stogu siana – dostaje listę wszystkich igieł na tacy.

Co poszło nie tak – spojrzenie techniczne

Dla programistów i osób technicznych: to jest klasyczny przypadek podstawowych błędów, które niestety zdarzają się zbyt często.

Brak uwierzytelniania na endpointach API – API rejestru było de facto publiczne. Proper authentication (klucze API, OAuth tokens, IP whitelisting) powinien być absolutnym minimum dla każdego systemu obsługującego wrażliwe dane.

Brak rate limiting i monitoringu – wystawiony endpoint bez ograniczeń liczby zapytań to zaproszenie do nadużyć. Organizacje muszą wiedzieć, kto i jak często odpytuje ich systemy.

Brak regularnych audytów bezpieczeństwa – trzynaście miesięcy to wieczność. Automatyczne skanowanie podatności i regularne penetration testing powinny wykryć takie expose znacznie szybciej.

Niewystarczające access controls – nawet jeśli API musi być publiczne, zwracane dane powinny podlegać zasadzie least privilege. Po co udostępniać pełne dane kontaktowe, skoro sama nazwa organizacji wystarczyłaby w większości przypadków?

Czego powinni nauczyć się wszyscy

Ta historia nie dotyczy tylko Indii czy sektora bankowego. Każda firma zarządzająca wrażliwymi danymi – od startupu po korporację – powinna wyciągnąć kilka wniosków.

1. Bezpieczeństwo to nie jednorazowa akcja

Rejestr .bank.in nie powstał zaniedbany. Został zaprojektowany z głową. Ale security to nie sprint, to marathon. W momencie, gdy zespół przestał aktywnie monitorować i testować, podatności zaczęły się pojawiać.

2. Twój security posture odzwierciedla to, co masz najcenniejsze

Zespół .bank.in chronił klientów banków przed oszustwami. Szlachetna misja. Ale ironia polega na tym, że być może tak bardzo skupili się na zewnętrznych użytkownikach, że zapomnieli zabezpieczyć własną infrastrukturę administracyjną. Budując systemy bezpieczeństwa, nie zapominaj audytować samych strażników.

3. API security to podstawa

Żyjemy w erze, gdzie wszystko łączy się przez API. Traktowanie ich jak prostych rur przesyłających dane to proszenie się o kłopoty. Każdy endpoint to potencjalny punkt wejścia dla atakujących. Implementuj uwierzytelnianie, szyfrowanie, rate limiting i comprehensive logging. Dla wszystkich API. Nawet tych wewnętrznych.

4. Zakładaj najgorsze – i przygotuj się na to

Nawet przy idealnym zabezpieczeniu, wycieki się zdarzają. Organizacje, których dane wyciekły, powinny zakładać, że cyberprzestępcy już dawno te informacje mają. To oznacza: zwiększona czujność wobec phishingu, potencjalne resetowanie credentials, przygotowanie na bardziej wyrafinowane ataki socjotechniczne.

Co teraz

Rejestr .bank.in rzekomo załatał podatność. Ale ta historia budzi pytania o szersze bezpieczeństwo indyjskiej infrastruktury finansowej. Jeśli flagowy program antyphishingowy może paść ofiarą tak podstawowego błędu, co może kryć się w mniej widocznych systemach?

Dla organizacji zarządzających domenami .bank.in lub podobną infrastrukturą zaufania – niech to będzie alarm. Przeprowadźcie natychmiastowe audyty API endpoints. Wdrożcie comprehensive access controls. Ustanówcie ciągły monitoring. I traktujcie własne systemy tak, jakby ktoś złego próbował się do nich dostać.

Szerszy obraz

Żyjemy w czasach, gdy cyfrowe zaufanie nigdy nie było ważniejsze – i nigdy nie było tak kruche. Rejestry, certificate authorities, infrastruktura zaufania – to one tworzą fundament bezpiecznych interakcji w internecie. Kiedy te systemy zawodzą, konsekwencje rozchodzą się daleko.

Wyciek .bank.in to przestroga o przepaści między intencjami bezpieczeństwa a rzeczywistością. Budowanie zaufania jest trudne. Utrzymywanie go wymaga ciągłej czujności, inwestycji i pokory wobec własnych podatności.

Dla developerów i liderów technicznych: audytujcie swoje systemy. Nie za kwartał. Nie kiedy znajdziecie czas. Teraz. Bo gdzieś tam, w cieniu, lekcje z .bank.in są już studiowane przez ludzi, którzy nie powinni ich studiować.

Cyberbezpieczeństwo internetu zależy od infrastruktury, którą często traktujemy jako oczywistość. Zróbmy lepiej niż trzynaście miesięcy narażenia na szwank.