Znalazł podatność, oni znaleźli prawnika

Yannick Dixken nurkuje przy Wyspie Cocos od czternastu dni. To jedno z najbardziej odizolowanych miejsc na Ziemi - kawałek skały na Oceanie Spokojnym, 550 kilometrów od wybrzeży Kostaryki, bez stałych mieszkańców, za to z rekinami młotogłowymi i prądami morskimi, które potrafią zaskoczyć nawet doświadczonych nurków.

Ale nie o nurkowanie tu chodzi.

Dixken rejestruje ich właśnie w portalu swojego ubezpieczyciela nurkowego — wpisuje dane osobowe, system tworzy konta. Studenci patrzą na swoje skrzynki. Dostaną login i hasło.

I wtedy Dixken patrzy na numery ID.

Kolejne. Jeden po drugim.

Ile kosztuje wejście do cudzego konta? Zero złotych, zero umiejętności

Żeby zrozumieć, dlaczego to, co zobaczył Dixken, jest tak poważne, muszę wyjaśnić jedną rzecz.

Wyobraź sobie, że mieszkasz w bloku. Każde mieszkanie ma numer - 1, 2, 3, 4. I wyobraź sobie, że wszystkie drzwi w tym bloku otwierają ten sam klucz (ale mieszkańcy o tym nie wiedzą). Jeden klucz dla wszystkich, wydany przez administratora w dniu przeprowadzki. Administrator zakłada, że każdy zmieni zamek we własnym zakresie.

Większość nie zmienia.

Dokładnie tak działał portal ubezpieczyciela. Kolejne, sekwencyjne ID użytkowników jako login. Jedno domyślne hasło przyznawane przy zakładaniu konta - takie samo dla każdego konta, bez wymuszenia zmiany przy pierwszym logowaniu. Brak rate limiting. Brak lockoutu po błędnych próbach. Brak MFA.

Dixken napisał skrypt w Selenium - narzędziu do automatyzacji przeglądarki. Żadnych exploitów, żadnych buffer overflow, żadnych zero-dayów. Po prostu: numer, hasło, enter. Numer, hasło, enter.

To, co wychodziło na ekranie, wyglądało mniej więcej tak:

Member ID: XXXXXXX E-Mail: [email protected] First name: Jane / Last Name: Doe Date of birth: 2011 Address: Calle Example No. 54, 35140, Sometown, Spain Mobile: [redacted]

Przeczytajcie tę datę urodzenia jeszcze raz.

2011.

Czternaście lat w chwili odkrycia. Pełne imię i nazwisko, adres domowy, numer telefonu, e-mail, obywatelstwo. Dostępne dla każdego, kto wpisze właściwy numer i to samo hasło, które dostał każdy inny użytkownik.

I to nie był jeden przypadek. W próbce Dixkena znacząca część kont wciąż używała domyślnego hasła. Wśród nich - konta nieletnich.

Disclosure jak z podręcznika

28 kwietnia 2025 roku Dixken wysyła e-mail. Do firmy ubezpieczeniowej i - zgodnie z maltańską polityką NCVDP (National Coordinated Vulnerability Disclosure Policy) - do CSIRT Malta, czyli krajowego zespołu reagowania na incydenty bezpieczeństwa.

To nie był przypadkowy wybór. Maltańska polityka NCVDP wprost wymaga zgłoszenia podatności zarówno do organizacji odpowiedzialnej, jak i do CSIRT. Dixken zrobił dokładnie to, co powinien.

W e-mailu: opis techniczny, kluczowe szczegóły podatności, prośba o potwierdzenie w ciągu 7 dni, 30-dniowe embargo na publiczne ujawnienie. Standard branżowy. Jeśli cokolwiek - hojny. Google Project Zero daje 90 dni. Niektórzy badacze dają mniej.

Dwa dni później przyszła odpowiedź.

Nie od działu IT. Nie od CTO. Od kancelarii prawnej reprezentującej Data Privacy Officers firmy.

A teraz zaczyna się naprawdę ciekawe

List otwierał się uprzejmie. Przyznali, że problem istnieje. Powiedzieli, że resetują domyślne hasła i planują wdrożyć 2FA.

Dobra wiadomość.

Ale potem ton się zmienił. Zacytuję, bo tego nie da się sparafrazować bez utraty istoty:

„While we genuinely appreciate your seemingly good intentions and transparency in highlighting this matter to our attention, we must respectfully note that notifying the authorities prior to contacting the Group creates additional complexities in how the matter is perceived and addressed and also exposes us to unfair liability."

(Choć doceniamy Pana pozornie dobre intencje i transparentność w zwróceniu uwagi na tę sprawę, musimy z szacunkiem zauważyć, że powiadomienie władz przed skontaktowaniem się z Grupą stwarza dodatkowe komplikacje w tym, jak sprawa jest postrzegana i rozwiązywana, a także naraża nas na nieuzasadnioną odpowiedzialność.)

Przetłumaczę: „Szkoda, że powiedziałeś rządowi o naszej dziurze bezpieczeństwa. To dla nas kłopotliwe."

I dalej:

„We also do not appreciate your threat to make this matter public [...] and remind you that you may be held accountable for any damage we, or the data subjects, may suffer as a result of your own actions, which actions likely constitute a criminal offence under Maltese law."

(Nie akceptujemy również Pana groźby upublicznienia tej sprawy [...] i przypominamy, że może Pan zostać pociągnięty do odpowiedzialności za wszelkie szkody, które my lub podmioty których dotyczą dane mogą ponieść w wyniku Pana działań, które najprawdopodobniej stanowią przestępstwo zgodnie z prawem maltańskim.)

Zatrzymajmy się tutaj.

Portal miał domyślne hasło na każdym koncie. Portal ujawniał dane osobowe nieletnich. Portal nie wymuszał zmiany hasła. Portal nie miał rate limitingu.

Do listu dołączono deklarację do podpisania - z terminem do końca dnia roboczego tego samego dnia. Dixken miał potwierdzić usunięcie danych, zobowiązać się do nieujawniania czegokolwiek i - tu jest wisienka na torcie:

„I also declare that I shall keep the content of this declaration strictly confidential."

(Oświadczam również, że zachowam treść niniejszej deklaracji w ścisłej tajemnicy.)

NDA, który zakazuje mówienia o istnieniu NDA. Klasyk.

Kiedy Dixken odmówił i zaproponował własną, okrojoną wersję deklaracji - tylko potwierdzenie usunięcia danych, nic więcej - firma odpowiedziała kolejnym listem. Tym razem z artykułem 337E maltańskiego kodeksu karnego, regulującym computer misuse, i uprzejmą informacją, że prawo to ma zastosowanie eksterytorialne.

Czyli: nawet jeśli jesteś Niemcem, w Niemczech, to co zrobiłeś może być uznane za przestępstwo popełnione na Malcie.

Kto tu jest winny? Odpowiedź firmy cię zaskoczy

Jest jeden fragment tej historii, przy którym musiałem odłożyć kawę.

Kiedy Dixken wskazał, że firma narusza RODO — konkretnie art. 5(1)(f), który nakłada na kontrolera danych obowiązek zapewnienia odpowiednich środków technicznych i organizacyjnych — firma odpowiedziała argumentem, który jest małym arcydziełem prawniczej ekwilibrystyki:

„We contend that it is the responsibility of users to change their own password (after we allocate a default one)." (Twierdzimy, że to obowiązkiem użytkowników jest zmiana własnego hasła - po tym, jak my przydzielimy im hasło domyślne.)

Przeczytajcie to uważnie.

Firma, która przydzieliła identyczne hasło domyślne każdemu kontu, nie wymusiła jego zmiany, używała sekwencyjnych ID jako loginów i nie wdrożyła żadnego mechanizmu ochrony przed enumeracją — twierdzi, że to użytkownicy są odpowiedzialni za bezpieczeństwo swoich kont.

Kont, które zakładali w ich imieniu instruktorzy nurkowania.

Kont, które obejmowały nieletnich.

Artykuł 24(1) RODO mówi wyraźnie: to kontroler wdraża odpowiednie środki techniczne i organizacyjne, aby zapewnić zgodność przetwarzania z rozporządzeniem. Artykuł 34(1) nakłada obowiązek powiadomienia podmiotów, gdy naruszenie może skutkować wysokim ryzykiem dla ich praw i wolności.

Do dziś Dixken nie otrzymał potwierdzenia, że użytkownicy zostali powiadomieni o incydencie.

Malta już to przerabiała. I to gorzej.

Zanim przejdę dalej - muszę się zatrzymać przy kontekście, który zmienia całą optykę tej historii.

Październik 2022. Trzech studentów informatyki Uniwersytetu Maltańskiego - Michael Debono, Giorgio Grigolo i Luke Bjorn Scerri - odkrywa poważne podatności w FreeHour. To najpopularniejsza aplikacja studencka na Malcie, używana przez ponad 90% tamtejszych studentów. Endpointy administracyjne bez autoryzacji. Ekspozycja danych użytkowników przez manipulację parametrami. Brak walidacji inputu.

Studenci dokumentują wszystko zgodnie z ISO/IEC 29147. Piszą e-mail do założyciela FreeHour z technicznym opisem, krokami reprodukcji, rekomendacjami. Proszą o bug bounty.

FreeHour odpowiada trzy dni później. Nie do studentów. Do maltańskiej policji.

3 listopada 2022 roku uzbrojeni policjanci przeprowadzają jednoczesne przeszukania w domach. Konfiskata wszystkich urządzeń - laptopy, telefony, sprzęt IoT. Przeszukanie osobiste na komendzie. 48 godzin zatrzymania bez dostępu do adwokata.

Zarzuty, które pojawiły się w lutym 2024:

• Debono: nieautoryzowany dostęp do systemu komputerowego + utrudnianie działania systemu komputerowego. Do 4 lat.
• Grigolo: nieautoryzowana modyfikacja danych + nielegalne kopiowanie danych. Do 6 lat.
• Scerri: nieautoryzowany dostęp do systemu komputerowego + spisek w celu popełnienia cyberprzestępstwa. Do 4 lat.
• Wykładowca Vella, który przejrzał e-mail pod kątem językowym: pomocnictwo + wymuszenie drogą elektroniczną. Do 7 lat..

Prokuratura zarzuciła, że ujawnienie podatności stanowiło próbę wymuszenia płatności przez groźbę publicznego ujawnienia.

Tak, bug bounty = wymuszenie.

Sprawa skończyła się formalnie ułaskawieniem prezydenckim w lipcu 2025 - premier Robert Abela przyznał, że prawo nie nadążyło za technologią. Czternaście urządzeń pozostało skonfiskowanych przez 28 miesięcy. U dwóch studentów stwierdzono PTSD. Maltański raport o cyberbezpieczeństwie z 2023 roku odnotował 43-procentowy spadek uczestnictwa w bug bounty. Dwa startupy security przeniosły się do UK.

FreeHour nie poniosło żadnych konsekwencji.

Jeden z maltańskich badaczy bezpieczeństwa napisał w komentarzu pod artykułem Dixkena coś, co zostało ze mną:

„I'm sitting on another issue I discovered. After a long conversation with CSIRT we figured the only way I can actually anonymously report it is by snail mailing it to them. I can't pull together the energy to complete it - I don't have the time right now in my life for another legal melodramatic situation."

(Siedzę nad kolejną podatnością, którą odkryłem. Po długiej rozmowie z CSIRT ustaliliśmy, że jedyną opcją anonimowego zgłoszenia jest wysłanie listu pocztą. Nie mam energii, żeby to domknąć - nie mam teraz w życiu czasu na kolejną prawną melodramę.)

Ktoś znalazł podatność. Wie jak ją zgłosić. Rozmawiał z właściwymi ludźmi. I w końcu mówi: nie, dziękuję.

Podatność zostaje. Dane użytkowników zostają niezabezpieczone. Bo biały kapelusz boi się czarnej togi.

To nie jest błąd programisty. To jest błąd systemu.

Ktoś na Hacker News - przy okazji dyskusji o tej sprawie - zadał pytanie, które warto postawić głośno:

„If you make legal disclosure too hard, the only way you will find out is via criminals."
(Jeśli zgłaszanie podatności zrobisz wystarczająco trudnym prawnie, jedyni, od których się o nich dowiesz, będą przestępcy.)

I tu jest sedno.

Firmy, które reagują na vulnerability disclosure prawnikami zamiast inżynierami, wysyłają do świata bardzo konkretny sygnał: nie chcemy wiedzieć o swoich problemach. Przynajmniej nie od was.

Ktoś inny w tym samym wątku sformułował to jeszcze ostrzej:

„At this point 'responsible disclosure' just means 'giving a company a head start on hiring a lawyer before you go public.'"
(W tym momencie 'responsible disclosure' oznacza już tylko tyle, że dajesz firmie przewagę czasową na zatrudnienie prawnika, zanim pójdziesz do mediów.)

Istnieje analogia z inżynierią budowlaną, którą lubię. Kiedy architekt podpisuje się pod projektem mostu, bierze za niego odpowiedzialność prawną. Jeśli most się posypie - to jego głowa... spadnie. Dlatego architekci mają interes w tym, żeby mosty były bezpieczne, i dlatego chętnie słuchają, kiedy ktoś wskazuje pęknięcie w fundamencie.

Programiści nie muszą się pod niczym podpisywać. Projekt idzie na produkcję, dane użytkowników trafiają do systemu, a gdy system zawodzi - odpowiedzialność rozmywa się w nieskończoność korporacyjnych warstw. I właśnie dlatego wciąż mamy w 2026 roku portale z kolejnymi ID i jednym hasłem dla wszystkich.

Co powinno było się stać

Dixken w swoim artykule opisuje to wprost. Firma powinna była podziękować. Powinna była naprawić błąd - co zrobiła. Powinna była powiadomić użytkowników - czego, wedle jego wiedzy, nie zrobiła. I powinna była mieć politykę CVD, żeby badacze wiedzieli, jak zgłaszać problemy i czego się spodziewać.

Zamiast tego dostał NDA z terminem do końca dnia i artykuł z maltańskiego kodeksu karnego.

Podatności zdarzają się każdemu. To nie hańba. Hańbą jest odpowiedź.

I jeszcze jedno - bo Dixken był na tyle uczciwy, żeby to napisać: luka została załatana. Domyślne hasła zresetowane. 2FA w drodze. Coś dobrego z tego wyszło, mimo wszystko.

Ale Dixken do dziś nie dostał potwierdzenia, że rodzice 14-latków, których dane były dostępne dla każdego z numerem i cierpliwością, zostali o tym powiadomieni.

Źródła

• Yannick Dixken, I found a Vulnerability. They found a Lawyer
• Dyskusja na Hacker News
• Wikipedia, 2022 FreeHour ethical hacking case
• Newsbook Malta, Presidential pardon for students who uncovered app vulnerabilities
• Times of Malta, 'We wanted to help' - students arrested for exposing FreeHour security flaw