Publicznie dostępne wyniki badań na koronawirusa – czyli jak nie zabezpieczać danych

TL;DR – data urodzenia czy numer pesel nie stanowi dobrego pomysłu na zabezpieczenie dostępu do danych.

Zagadka – co różni dwa poniższe obrazki?

Zacznijmy jednak od początku. Niestety jak to często w świecie IT bywa, wygoda nie idzie w parze z bezpieczeństwem. Myślę, że tym razem było podobnie. Istnieje jednak zbiór danych wrażliwych, gdzie nie wolno iść na kompromisy. Takimi danymi są między innymi informacje o naszym stanie zdrowia.

Zaalarmowany wiadomością od mojego przyjaciela Kacpra dotyczącą tego, w jaki sposób udzielany jest dostęp do wyników badań laboratoryjnych, postanowiłem dokładniej zbadać rozwiązanie za to odpowiedzialne.

Jak widać na powyższych grafikach – aby uzyskać dostęp do swojego wyniku poprzez funkcjonalność „uproszczonego logowania” potrzebne są dwie informacje:

  • identyfikator zlecenia, gdzie kolejne numery zleceń są rosnące;
  • datę urodzenia osoby zlecającej [day=X&month=X&year=X]

Przy pewnych założeniach ilość kombinacji dat urodzeń możliwych do przypisania do identyfikatora zlecenia, wynosi jedynie około 19 tys. kombinacji. Nie trudno się domyślić, że nie stanowi większego problemu wygenerowanie wszystkich takich kombinacji i sprawdzeniu, czy pasują one do numeru zlecenia.

Okazało się, że moje przypuszczenia są prawidłowe i po kilkuset enumeracjach udało się dopasować dane dostępowe:

intruder enumeration

Pozwoliło to na uzyskanie informacji wrażliwych pacjenta takich jak:

  • imię;
  • nazwisko;
  • pesel;
  • data urodzenia;
  • adres zamieszkania;
  • wynik badań;
wyniki badań koronawirus
wyniki badań koronawirus

Kolejny przykład udanej próby enumeracji:

enumeracja burp intruder
wyniki badań koronawirus

Niezwłocznie po potwierdzeniu moich przypuszczeń dotyczących podatności zgłosiłem ten błąd osobom odpowiedzialnym za oprogramowanie wraz z rekomendacjami naprawy:

mail z zgłoszeniem błędu bezpieczeństwa

Co zrobić, jak żyć?

Jednym z najczęściej stosowanych zabezpieczeń przed tego typu atakami jest wdrożenie mechanizmu captcha. Użytkownik aplikacji po kilku (np. trzech) nieudanych próbach uzyskania dostępu do danych zlecenia będzie poproszony o przepisanie wyświetlanego kodu captcha. Należy jednak pamiętać, że wdrożenie takiego mechanizmu stanowi jedynie (albo aż) spowolnienie atakującego, który w najprostszych przypadkach będzie mógł dalej brutforsować datę urodzenia przy pomocy skanerów OCR lub dedykowanych usług odczytu captcha.

Lepszym i rekomendowanym przeze mnie zabezpieczeniem jest uzyskiwanie dostępu do wyników zlecenia poprzez odpowiednio długie, losowe hasło, które będzie przychodzić na numer telefonu zleceniodawcy.

Błąd na szczęście został dosyć szybko naprawiony, poprzez wdrożenie mechanizmu reCAPTCHA od google:

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Otagowano , , , , , , , , , , , , .Dodaj do zakładek Link.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *