11:58
31/12/2020

W marcu tego roku doszło do ujawnienia danych klientów firmy pożyczkowej, a wśród nich były nawet hasła w otwartym tekście. Gdyby zgłoszenie potraktowano poważnie, można było uniknąć zarówno skutków wycieku jak i tej niemałej kary.

Wyciek z MoneyMan.pl

W marcu tego roku pisaliśmy o wycieku z serwisu pożyczkowego MoneyMan.pl. Został on wykryty przez Boba Diachenko, który nie raz donosił o bazach pozostawionych w sieci bez stosownego zabezpieczenia. Sprawa była o tyle niepokojąca, że Diachenko zgłosił wyciek już 3 marca. Reakcji ze strony MoneyMana nie było. 10 marca Diachenko poinformował o wycieku publicznie na Twiterze, uznając iż nie ma innego wyboru.

Niedługo potem bazę ktoś usunął i zostawił na miejscu komunikat o żądaniu okupu.

Wyciek obejmował e-maile i hasła (otwartym tekstem), dane o pożyczkach, numery dokumentów, numery telefonów i adresy.

Milion złotych kary

Dziś UODO poinformował, że na prowadzącą serwis spółkę ID Finance Poland nałożono karę w wysokości 1 mln zł. Powodem nałożenia kary jest niewdrożenie odpowiednich środków technicznych i organizacyjnych, które miałyby zapewnić bezpieczeństwo danych. Te środki nie były wdrożone zarówno w fazie projektowania procesu przetwarzania jak  i w czasie samego przetwarzania.

Dokładna wysokość kary pieniężnej to 1.069.850,00 zł.

Z decyzji UODO (DKN.5130.1354.2020) możemy się dowiedzieć jaka była kolejność zdarzeń związanych z wyciekiem.

Wyciek? Panie! To może być oszustwo!

Zaczęło się od restartu jednego z serwerów, który należał do firmy przetwarzającej dane na rzecz ID Finance. Po tym restarcie podmiot przetwarzający nie zweryfikował prawidłowości konfiguracji zabezpieczeń. Jak wiecie, Bob Diachenko wykrył wyciek i zgłosił go m.in. IOD-owi firmy stojącej za MoneyManem.

IOD przesłał wiadomość m.in. do dyrektora ds. finansów Spółki wraz z zapytaniem o kontakt do firmy IDFT, która jako podmiot przetwarzający świadczyła usługi hostingu dla ID Finance. Dyrektor ds. finansów tego samego dnia przesłał ww. wiadomość do dyrektora IDFT opatrując ją komentarzem sugerującym, że może to być próba wyłudzenia poufnych informacji.

Po części działania dyrektora ds. finansów można zrozumieć. Trzeba ustalać wiarygodność informacji zanim zgłosi się wyciek choćby do UODO, ale… czy nie warto jednocześnie się upewnić, że wycieku nie było? Pewnie nigdy się nie dowiemy czy sugestia oszustwa miała tu kluczowe znaczenie, ale IDFT dokonała kolejnego restartu serwera, po którym niestety konfiguracja była nadal nieprawidłowa.

Już po tych wydarzeniach jakaś nieuprawniona osoba uzyskała dostęp do danych i pobrała je.

Spółka dostała kolejne powiadomienia o wycieku. Zaczęli się nim interesować dziennikarze, Bob Diachenko ujawnił problem publicznie, mleko się rozlało. Niestety doszło do pobrania danych 140699 klientów

Pracownicy IDFT ustalili, że do naruszenia poufności danych osobowych przetwarzanych na serwerze Spółki doszło w wyniku nieprawidłowej konfiguracji zapory sieciowej po restarcie serwera, tj. jeden z portów pozostawał otwarty. Potwierdzono nieuprawnione pobranie danych, ustalono skalę naruszenia oraz podjęto działania zaradcze, tj. m.in. przywrócono prawidłową konfigurację serwera (zamknięcie portu) oraz dokonano resetu haseł użytkowników portalu moneyman.pl. Spółka dokonała również weryfikacji wszystkich używanych przez nią serwerów, celem ustalenia, czy przetwarzane na tych serwerach dane są bezpieczne. Weryfikacja wykazała, że niebezpieczeństwo takie, w szczególności w zakresie nieuprawnionego dostępu, Spółce nie zagraża. Tego samego dnia Spółka dokonała wstępnego zgłoszenia naruszenia ochrony danych osobowych Prezesowi Urzędu Ochrony Danych – czytamy w decyzji UODO.

Co ciekawe, ta ujawniona baza danych nie była główną bazą danych klientów i potencjalnych klientów. W wyjaśnieniach dla UODO ID Finance wskazała, że były tam dane tych klientów, którzy po 1 stycznia 2018 r. w całości lub w części przeszli przez proces rejestracji. Ponadto spółka wyjaśniła, że owszem, baza zawierała hasła użytkowników otwartym tekstem, ale w głównej (produkcyjnej) bazie danych, hasła przechowywane są w postaci niejawnej.

Można było tego uniknąć

W decyzji o nałożeniu kary UODO zauważył, że do naruszenia mogłoby nie dojść gdyby administrator od razu odpowiednio zareagował na informację o tym, iż dane na jego serwerze są niezabezpieczone.  UODO w decyzji podkreślił, że po wykryciu incydentu bezpieczeństwa należy przeprowadzić wstępne postępowanie, które ma doprowadzić do jak najszybszego ustalenia czy doszło do naruszenia.

O ile słusznie Spółka niezwłocznie przekazała wiadomość podmiotowi przetwarzającemu i oparła swoje przekonanie o konieczności zawiadomienia organu nadzorczego dopiero po potwierdzeniu jej wiarygodności, o tyle ze zgromadzonego materiału dowodowego nie wynika, by administrator podejmował inne działania zmierzające do szybkiego  i skutecznego stwierdzenia naruszenia, oprócz skierowania – czytamy w decyzji.

Przypomnijmy, że reakcja firmy była opóźniona m.in. dlatego, że w podmiocie przetwarzającym zgłoszenie problemu uznano za “smart phishing”. To jest bardzo ciekawy wątek. Wydaje się bowiem, że próba oszustwa, w którym ktoś powołuje się na dostęp do chronionych danych, powinna raczej wzmóc czujność niż ją osłabić. Powinna wywołać reakcję w postaci upewnienia się, czy np. oszust nie wie więcej niż wiedzieć powinien. W tym przypadku najwyraźniej tak nie było.

Nie ignoruj wycieków, miej procedury

W pewnym sensie kara dla ID Finance przypomina opisywaną u nas wczoraj karę dla Warty. Nie oszacowano właściwie ryzyka, a przy obsłudze incydentu z bezpieczeństwem danych lepiej jest szacować ryzyko nadmiernie niż negować problem.

Przypominamy też, że najlepiej jest z wyprzedzeniem opracować w firmie procedury dotyczące incydentów bezpieczeństwa i wycieków danych. Każdy pracownik powinien wiedzieć co robić w takich sytuacjach, aby łańcuch reakcji nie urwał się na osobie, która przekaże to innej osobie, która przekaże to jeszcze innej by w końcu sprawą zajął się ktoś taki jak na obrazku.

Na wysokość kary miała wpływ m.in. waga naruszenia oraz czas jego trwania. W tym przypadku wagę naruszenia zwiększało przechowywanie haseł w postaci jawnej. To nigdy nie jest dobry pomysł, nawet jeśli baza danych nie ma charakteru produkcyjnego.

Sprawa MoneyMana kojarzy nam również z opisywanym u nas wyciekiem z firmy sprzedającej ubezpieczenia. W tym przypadku również były zgłoszenia wycieków, ale firma albo nie reagowała, albo wręcz otwarcie zaprzeczała niepodważalnemu faktowi (ba… zaprzeczyła nawet prowadzeniu strony internetowej, która niewątpliwie do niej należała). Nigdy. Nie. Reagujcie. Na. Wycieki. W ten. Sposób.

Przeczytaj także:

27 komentarzy

Dodaj komentarz
  1. I tej kary to już nie zapłacą :P Zobaczcie stopkę – “ID Finance Poland spółka z ograniczoną odpowiedzialnością w likwidacji”, czyli już zwijają interes :P

    • Mimo wszystko prezesi i zarząd będą mieli mokro, bo ich można ścigać, a być może nawet z prywatnego majątku (z wielu powodów).

    • @Kenjiro No właśnie nie. Jeśli prezes, nie zarząd ogłosi upadłość jak tylko będą ku temu przesłanki, to jego majątek prywatny jest bezpieczny.

      Jeśli natomiast sprawę pokpi i jego decyzja przełoży się nie zwiększenie strat firmy, firm współpracujących lub po prostu zwykłych osób to wtedy oi owszem odpowiada swoim prywatnym majątkiem.

      Nie znam konkretnie tej firmy, ale jednak w tej branży często robią cwaniacy. Nie zdziwiłbym się jakby faktyczni właściciele firmy nie byli nawet w zarządzie, a jedynie posiadali pełnomocnictwa do reprezentowania firmy. Sam zarząd i prezes to słupy.

      Zakładam że firma zniknie, a jej biznes przejmie firma ID Finance 2.

    • bo te firemki pożyczkowe to firmy krzaki. pożyczają kasę, potem ogłaszają upadłość i ktoś umówiony wykupuje taką firemkę. to takie jednorazówki.

      w artykule zabolało mnie jedno. z opisu wynika, ze ten host był zapięty bezpośrednio do neta, i polegał jedynie na swoim własnym firewallu. kto tak konfiguruje serwery ????? tak to można skonfigurować webhosty hobbistyczne.
      główna zasada brzmi: blokujemy wszystko jak leci, a wybrane usługi w sposób jawny wypuszczamy w świat. to jest jeden z elementów tzw. dobrych praktyk.

      dodatkowo …… jak oni wleźli w bazę danych? jakieś proste hasło? czemu baza danych była tak otwarta że wszystkie tabele były na patelni? żadnych uprawnień na bazie? żadnych triggerów? żadnych procedur bazodanowych ukrywających prawdziwą strukturę bazy? albo wręcz usługa dostępu do danych za którą showana byłaby baza?

      głupota po prostu poraża.

  2. I bardzo dobrze, każdy taki parabank jest dziurawy jak sito i powinien być surowo karany. Handlują danymi na prawo i lewo. IDFinanse Poland sp zoo w likwidacji, pewnie sprzedali portfolio klientów, brudne długi na giełdzie i za nic nie odpowiadają…

    • na jakiej giełdzie? takie firmy krzaki są maksylanie tanie, z minimalizacją kosztów. dlatego zabezpieczenia IT są takie a nie inne. zwykle już w momencie tworzenia takiego krzaka, już jest umówiony kupiec który oczyści wizerunek i umyje monety.

  3. Wyciekły im dane 140699 razy większej liczby klientów niż wczorajszej Warcie, a dostali tylko 12,5x większa karę. Dziwne.

    Bob by lepiej zrobił, gdyby im zaorał bazę. Przynajmniej nikt by nie ukradł :)

  4. Niestety tak się postępuje w it w pl. “Wyluzuj chłopie, co się spinasz, daj se siana” .
    Niestety tak to wygląda. Kiedy w poprzednich 2 firmach powiedziałem że nie może być tak że wszyscy pracują na koncie sa i wszyscy znają hasło, mimo iż większość robiła jakieś podstawowe rzeczy, i należy założyć osobne konta z odpowiednimi ograniczeniami , to zrobiło się takie poruszenie , pojawiły się takie komentarze i wyśmiewki że czacha dymi. “Ptfuuu co? Ty się dobrze czujesz? Wyluzuj”. No i mamy tego efekty co jakiś czas.

    • @Jol

      Znam to. Nierzadki przypadek w małych firmach. Żeby przeprowadzić zmianę którą słusznie zaproponowałeś, trzeba mieć dobre umocowanie we władzach firmy. Inaczej to się nie udaje. Albo zrobić fakt dokonany, tzn samemu przekonfigurować i przekazać innym dostępy (jeśli jest się wystarczająco aroganckim, jak np ja). Tyle że jak są mocno przyzwyczajeni, to i na to znajdą sposób – przykładowo w opisanej przeze mnie sytuacji poprzekazywali sobie hasła. A na klucze sprzętowe nie udało się szefa namówić. Oczywiście już z nimi nie współpracuję ;)

    • Tym samym w innej firmie jako DEV (tylko ja z zespołu) miałem ograniczenie na userze na bazie wyłączające dane księgowo-kadrowe na wniosek dyrektor finansów… do której i tak miałem dostęp przez bazę produkcyjną (sic!). Jak spytałem o to admina to kazał siedzieć cicho bo to tylko by mu komplikowało pracę :D

    • Maszynę produkcyjną, nie bazę*

    • też to przerabiałem, zwłaszcza kompletny brak umiejętności samodzielnej zmiany hasła, wypowiadanie hasła na głos w czasie wpisywania i okrzyki z za pleców “to jest moje!!! hasło!” :D

    • Nie wiem w jakiej to firmie pracowales, ale wyglada na niepowazna. Dementuje zarzut jako by to bylo popularne zjawisko. Co pol roku sie przechodzi szkolenie i zdaje test z zarzadzania i ochrony danych.

  5. Mozna sie ekscytowac wysokimi karami tylko jaki ich niby jest cel? To po prostu jeszcze jeden ukryty para-podatek.

    Ochrona klientow jak lezala tak lezy, chodzi mi o to, ze nadal zbyt latwo w (para) bankach wziac lewy kredyt w cudzym imieniu.

    • Cel kar jest taki, że inne podmioty widząc kary przywiązują większa uwagę do bezpieczeństwa danych u siebie. Praktycznie każdy pojawiający się klient podaje za przykład jakąś karę UODO ze swojej branży. Kara ma więc tutaj działanie dwukierunkowe: z jednej strony podmiot odpowiedzialny dostaje “po tyłku” co zazwyczaj prowadzi do otwarcia oczu zarządowi który przestaje zlecać administrację “Kaziowi (przykładowy syn, przykładowej księgowej)”, a rozgląda się za profesjonalną firmą lub zespołem; z drugiej natomiast takie sprawy szybko rozchodzą się po branży, wiele osób dopiero wówczas się budzi i zadaje sobie pytanie czy u niego w firmie jest wszystko zrobione jak być powinno.

    • Lt@ bajeczki dla grzecznych dzieci.

    • @p0k3m0n
      Czyli “niech żyje anarchia!” – mandaty za prędkość i jazdę po pijaku też zlikwidować?
      Niestety, niektórych powstrzymuje tylko wizja nieuchronnej kary.

    • @asdsad
      Przeciwnie. Należy wprowadzić kary za udzielanie kredytów na niezweryfikowane dane. Firmy płacą za wycieki, ale dlaczego pracownicy banków nie płacą za swoje (celowe) pomyłki?

    • @p0k3m0n – tak to niestety działa i nie są to bajeczki. Ochronę danych wszyscy mają w głębokim poważaniu. 11 lat DG, w tym 9 w temacie bezpieczeństwa danych i pojawiło się może 4-5 klientów którzy ot tak po prostu chcieli zająć się bezpieczeństwem (nie tylko danych osobowych). Wszyscy inni pojawiają się bo obudziła ich kara dla kogoś z branży. Jedziesz do firmy gdzie parking zarządu to wystawa klasy E, a nakłady na IT w skali roku niewiele wykraczają poza pół etatu dla gościa, który przychodzi ogarnąć toner w drukarkach i niewiele ponadto.

  6. https://www.moneyman.pl/o-nas/kontakt/
    ID Finance Poland spółka z ograniczoną odpowiedzialnością w likwidacji
    o kapitale zakładowym w wysokości 1.500.000,00 zł

  7. A czy UODO wskazał w swojej decyzji, jakie konkretnie działania jego zdaniem winna podjąć ukarana firma, a ich nie uczyniła? Czy tylko dialektycznie stwierdza, że “skoro do wycieku doszło, to nie zrobiono tego właściwie”?

    • jakie to ma znaczenie skoro z artykułu wynika że nie zastosowali podstawowych elementów bezpieczeństwa?

  8. Czyli karę poniesie nie firma “zewnętrzna”, do której należał serwer i która tym zarządza, tylko klient, który to zlecił “Administrator danych osobowych”?

    • Tak, tak właśnie są zdefiniowane role i odpowiedzialność w GDPR.

  9. “Ponadto spółka wyjaśniła, że owszem, baza zawierała hasła użytkowników otwartym tekstem, ale w głównej (produkcyjnej) bazie danych, hasła przechowywane są w postaci niejawnej.”

    Uff… Ulga normalnie :)

  10. Pracuję w korpo z branży finansowej jako dev. Jako że jestem autorem kilku poważnych rozwiązań – z tym związanych z bezpieczeństwem – mam wjazd na produkcję w kilku projektach (i nie mam na myśli “tylko” bazy danych, ale całą infrastrukturę), nikt nie robi mi code review, w zasadzie jakbym nie był uczciwy, to spokojnie byłbym w stanie wytransferować od klientów parę baniek i się przeprowadzić na Kajmany. A nawet jeśli nie, to przynajmniej “pożyczyć” bazę klientów. Hasła mamy dobrze zahashowane (niesymetryczny algorytm, salt i te sprawy), ale… Jako że mam dostępy, to wiem, jak je “odhashować”. Ale jestem uczciwy, więc tego nie robię.

    Pytanie: czy to jest normalne, czy jednak jest to naruszenie kwestii bezpieczeństwa? Jak ograniczyć programistom możliwość tworzenia backdoorów i kradzieży danych?

    • trzeba im obciąć ręce, nie będą kombinować

Odpowiadasz na komentarz Łukasz

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: