Niebezpiecznik

W poniedziałek jako pierwsi informowaliśmy o wycieku danych pacjentów wrocławskiej kliniki DCG Centrum Medyczne. Wskazaliśmy, że źródłem tego wycieku były serwery firmy Medily, która dostarcza oprogramowanie Aurero do zarządzania wizytami różnym klinikom w całej Polsce. Medily w swoich oświadczeniach informowało, że stosowało wiele warstw zabezpieczeń i że zhackowano im serwer testowy a nie produkcyjny. Ale to właśnie na tym testowym serwerze znajdowały się dane pacjentów, które spółka powinna była usunąć jeszcze w 2021 roku. A włamywacz najwyraźniej nie wiedział o “wielu warstwach zabezpieczeń”, bo — co zaraz pokażemy — na serwer dostał się w dość banalny sposób.

Jak doszło do włamania?

W odpowiedzi na nasze pytania, Medily poinformowało, że o włamaniu na swoje serwery spółka dowiedziała się 19 marca 2024:

Informację o naruszeniu bezpieczeństwa danych otrzymaliśmy od CERT NASK, który wskazał, że na forum cyberprzestępczym dostępnym w sieci TOR opublikowano dane pochodzące z systemu Aurero.

Jak jednak ustaliliśmy, spółka o tym, że ktoś oferuje dostęp do ich serwera na sprzedaż została poinformowana 4 dni wcześniej — 14 marca 2024. Skąd to wiemy? Po pierwszej publikacji dotyczącej tego incydentu skontaktował się z nami Mateusz z firmy RexNet. Poinformował nas, że na jednym z kanałów na Telegramie 14 marca 2024 zobaczył ofertę sprzedaży bazy danych za cenę… 150 dolarów. Mateusz napisał o tym do Medily, ale do dziś nie otrzymał na swoje zgłoszenie żadnej odpowiedzi.

Dodajmy jednak, że brak odpowiedzi Medily, choć smutny — bo na takie zgłoszenia należy reagować — niczego by nie zmienił. 14 marca dane były już wykradzione i wystawione na sprzedaż. Jeśli wierzyć timestampom plików baz danych udostępnionych w internecie przez włamywacza, kradzieży danych dokonano 11 marca o godzinie 18:00. Znaczniki czasowe to jednak dowód tylko poszlakowy — faktyczną datę wksazać może jedynie administrator serwera. Dlatego zapytaliśmy Medily, czy ustaliła, kiedy dane zrzucono z jej serwerów. Medily potwierdziło, że:

“naruszeni[e] naszych zabezpieczeń (…) to 11 marca 2024. Pomimo zastosowania wielu warstw zabezpieczeń (długie bezpieczne hasła, niestandardowe nazwy użytkowników, zabezpieczenia antyspamowe i inne), wciąż ustalamy jak ktoś mógł dokonać ich przełamania.”

Wiele warstw zabezpieczeń…

Medily podkreśla, że korzystało z wielu warstw zabezpieczeń. Ale Mateusz rozmawiał z osobą, która wystawiła bazę na sprzedaż na Telegramie i osoba ta odpisała mu, że — usiądźcie —

hasło do serwera bazodanowego znalazła w publicznie dostępnym kodzie jednej ze stron internetowych Medily, a serwer nie znajdował się za żadnym VPN-em (dodatkowym uwierzytelnieniem — dop. red.)

Wszystko wskazuje na to, że jedyne co zrobił włamywacz, to:

• Zauważył, że jedna ze stron internetowych oprogramowania Aurero pluje błędami
• Z błędów, jak to często bywa, odczytał wartościowe informacje. Takie, które pozwoliły mu namierzyć zarówno serwer bazodanowy, jak i dane logowania
• Za pomocą tych danych był w stanie skłonić serwer bazodanowy do przesłania mu zawartości baz (czyt. wpisał IP i się zalogował przeklejonym z pkt. 2 hasłem)

Oczywiście, zawsze z dystansem należy podchodzić do opowieści złodziejów i włamywaczy. Ale taka ścieżka ataku brzmi wiarygodnie. Szczęście w nieszczęściu, że z relacji Mateusza wynika, iż włamywacz chyba nie do końca był świadomy wartości tego, co wykradł. Wydawać by się mogło, że po incydencie w Morele, nie znajdziemy już serwerów z publicznym dostępem do bazy. Ale jak widać, nie jest to prawda.

Co robić, jak żyć?

Jeśli jesteś pacjentem, wszystkie porady odnośnie tego, co zrobić po tym wycieku wskazaliśmy w pierwszym artykule. Ten dotyczy kwestii technicznych, więc dziś 3 rady dla programistów:

1. Nie wystawiajcie portów serwerów bazodanowych (czy w ogóle – środowisk deweloperskich) na świat. Chowajcie je za VPN, tunelami ssh, whitelistujcie IPki adminów.
2. Chowajcie komunikaty błędów, bo we wprawnych rękach to skarbnica wiedzy na temat nie tylko Waszej aplikacji, ale niekiedy całej infrastruktury.
3. Jeśli chcecie dowiedzieć się jak poprawnie zabezpieczać swoje serwisy internetowe i aplikacje webowe przed atakami, to zapraszamy na nasze szkolenie “Atakowanie i Ochrona Webaplikacji“. W 2 dni pokażemy Wam dziesiątki technik i narzędzi, które pomogą uszczelnić Waszą aplikację.

   

   Po tym szkoleniu będziecie mogli sami przeprowadzać testy bezpieczeństwa webaplikacji. A nawet najprostsze testy są w stanie wychwycić błędy, które opisaliśmy powyżej i uchronić firmę przed tragedią związaną z wyciekiem danych (lub ujawnieniem, że przetwarzała to, czego już nie powinna była przetwarzać). Zapiszcie się z kodem SQLI (wpisanym w uwagach) to zhackujemy Wam cenę za udział ;) To szkolenie idealnie nadaje się do sfinansowania z firmowego budżetu szkoleniowego — jakbyście potrzebowali argumentów dla szefa, to możemy Wam podesłać PDF z ich listą. Odezwijcie się tutaj. Pełną agendę naszego szkolenia znajdziecie na jego podstronie, a najbliższe terminy podajemy poniżej:

   ZDALNIE: 21-22 maja 2024r. — UWAGA: zostały tylko 3 wolne miejsca
   Ostatnio ktoś zarejestrował się 23 kwietnia 2024r. → zarejestruj się na to szkolenie

   2399 PLN netto (do 3 maja)
   2699 PLN netto (od 4 maja)

   Warszawa: 27-28 maja 2024r. — zostało 5 wolnych miejsc
   Ostatnio ktoś zarejestrował się 23 kwietnia 2024r. → zarejestruj się na to szkolenie

   2399 PLN netto (do 3 maja)
   2699 PLN netto (od 4 maja)

   Poznań: 12-13 czerwca 2024r. — zostało 7 wolnych miejsc
   Ostatnio ktoś zarejestrował się 18 kwietnia 2024r. → zarejestruj się na to szkolenie

   2399 PLN netto (do 10 maja)
   2699 PLN netto (od 11 maja)

   Gdańsk: 17-18 czerwca 2024r. — zostało 8 wolnych miejsc
   Ostatnio ktoś zarejestrował się 22 kwietnia 2024r. → zarejestruj się na to szkolenie

   2399 PLN netto (do 10 maja)
   2699 PLN netto (od 11 maja)

   Kraków: 15-16 lipca 2024r. — zostało 9 wolnych miejsc
   Ostatnio ktoś zarejestrował się 27 kwietnia 2024r. → zarejestruj się na to szkolenie

   2399 PLN netto (do 10 maja)
   2699 PLN netto (od 11 maja)

 
Aha, powyższe rady warto zastosować nawet wtedy, kiedy w swojej aplikacji nie przetwarza się danych medycznych…