Podsumowanie decyzji UODO w sprawie nałożenia kary na Morele.net

Ostatnio dużo mówi się o rekordowej w kraju karze administracyjnej wynikającej z RODO (ogólnego rozporządzenia o ochronie danych osobowych. Artykuły które m.in.. warto poczytać to:

Z artykułów wiemy, że wyciekły dane, wiemy że z bazy danych,  bo mowa jest o haszach haseł. Sekurak odnotował, że może chodzić o "brak procedur reagowania na wypadek pojawienia się nietypowego ruchu w sieci" i sugeruje, że może chodzić "np. brak WAF-a czy IDS-a, ale też np. systemów pokazujących nagły skok w ilości wysyłanych z infrastruktury danych (który zapewne wystąpił podczas kradzieży bazy)".

Decyzja organu nadzorczego w tej sprawie opublikowana jest pod adresem https://uodo.gov.pl/decyzje/ZSPR.421.2.2019 - zachęcam do lektury!

Przede wszystkim Morele.net, to nie tylko Morele.net - to cała masa różnych witryn:

Przedmiotem działalności Spółki jest sprzedaż detaliczna prowadzona przez domy sprzedaży wysyłkowej lub Internet. Spółka prowadzi sklepy internetowe: morele.net, hulahop.pl, amfora.pl, pupilo.pl, trenujesz.pl, motoria.pl, digitalo.pl, ubieramy.pl, meblujesz.pl, sklep-presto.pl, budujesz.pl. (…) Liczba osób, których dane są przetwarzane przez Spółkę wynosi ok. 2 200 000 (ok dwa miliony dwieście tysięcy) . Zakres tych danych obejmuje: imię, nazwisko, adres poczty elektronicznej (e-mail), numer telefonu i adres do doręczeń.

Co ciekawe spółka jeszcze przetwarzała dane "z wniosków ratalnych. Zakres tych danych obejmował: imię, nazwisko, adres poczty elektronicznej (e-mail), numer telefonu, numer PESEL, seria i numer dokumentu tożsamości, data wydania dokumentu tożsamości, data ważności dokumentu tożsamości, wykształcenie, adres zameldowania, adres do korespondencji, źródło dochodu, miesięczny dochód netto, koszty utrzymania gospodarstwa domowego, liczba osób na utrzymaniu, stan cywilny, wysokość miesięcznych innych zobowiązań w instytucjach finansowych, informacja o wysokości zobowiązań alimentacyjnych i innych wynikających z wyroków sądowych (gromadzone od 2016 r.). Ich łączna liczba wynosiła ok 35 000". Dane te - wnioskuję z decyzji - zostały usunięte  przed kontrolą.

Kontrola obejmuje stan faktyczny, ten w dniu kontroli, zatem jeśli coś zostało "załatane" to kontrola tego nie obejmuje, ale w decyzji czytamy, że:

Odnosząc się do uwagi Prezesa Urzędu Ochrony Danych Osobowych, że Spółka nie udokumentowała usunięcia danych, Spółka wskazuje, że w związku z zamknięciem procesu przetwarzania danych, proces został usunięty z Rejestru Czynności Przetwarzania. Usunięcie bazy danych zostało również udokumentowane […]. Ponadto, Prezes Urzędu Ochrony Danych Osobowych nie wskazał przepisu, który Spółka miałaby naruszyć w związku z usunięciem bazy danych.

oraz

Z materiału dowodowego wynika, że około […] grudnia 2018 r. Spółka, na ustne polecenie […], usunęła bazę danych zawierającą dane klientów z tzw. „wniosków ratalnych”. Nie przeprowadzono w tym zakresie szczegółowej analizy oraz nie udokumentowano usunięcia danych. (…) Z uwagi na to, że zgody były pozyskiwane po rozpoczęciu obowiązywania rozporządzenia 2016/679, a sam proces trwał od 2016 r. (wyjaśnienia Spółki), należy założyć, że w usuniętej bazie danych znajdowały się dane zebrane bez podstawy prawnej. […].

a także

Z tych względów wyjaśnienia Spółki dotyczące zakończonego procesu przetwarzania danych wobec braku innych dowodów, nie są wystarczające aby uznać, że samo przetwarzanie odbywało się zgodnie z przepisami prawa, w tym na podstawie prawidłowo sformułowanej przesłanki zgody.

Wynikałoby z tego, że (zdaniem organu) usuwanie danych należałoby poprzedzić oceną ryzyka, a samo usuwanie danych dokumentować. Jest to dość ciekawy wniosek. Zwykłem uważać, że jeśli cel przetwarzania zakończył się i dane zostały usunięte, to nie ma obowiązku przechowywać danych historycznych na ten temat.

Podejrzewam, że kontrolerzy chcieli kontrolować ten obszar, a kontrolowany usunął dane i zakomunikował, że nie ma czego kontrolować… A Ci na to:

Takie podejście Spółki do procesu przetwarzania danych, pomimo, że sam proces uważany jest za zamknięty (dane zostały usunięte), godzi w podstawowe zasady przetwarzania danych. (…) decyzja administratora o usunięciu danych, która nie została poprzedzona utrwaloną analizą świadczy o nierespektowaniu podstawowych zasad ochrony danych osobowych, o których mowa powyżej.

Wracając jednak do tematu -  głównym powodem nałożenia kary jest:

Spółka nie dopełniła obowiązku zastosowania odpowiednich środków technicznych i organizacyjnych, by zapewnić stopień bezpieczeństwa odpowiadający ryzyku nieuprawnionego dostępu do danych osobowych jej klientów, co skutkowało dwukrotnym uzyskaniem dostępu do […] przez osobę bądź osoby nieuprawnione, a w konsekwencji również i dostępu do bazy danych wszystkich klientów Spółki w łącznej liczbie około 2 200 000 (około dwóch milionów dwustu tysięcy) osób;

oraz

stwierdzone w niniejszej sprawie naruszenie (…)  polegające na uzyskaniu nieuprawnionego dostępu do panelu pracownika Spółki przez osobę bądź osoby nieuprawnione, a w konsekwencji również i dostępu do bazy danych klientów Spółki

Organ pisze o "panelu pracownika", a z drugiej strony wiemy, że atakujący uzyskał dostęp do bazy, znał m.in. hasze wygenerowane z haseł użytkowników (na portalu Niebezpiecznik.pl czytamy, że "włamywacz informuje o złamaniu haseł 350 tysięcy użytkowników Morele") - zwykły pracownik nie ma raczej do nich dostępu. Może to był panel "specjalnego" pracownika tj. administratora? Wcale nie jest wykluczone, że z internetu był dostępny jakiś PHPMyAdmin, DirectAdmin lub coś podobnego.

To czego nie znalazłem w decyzji to odniesienia się do sposobu haszowania haseł, wydaje się, że sposób generowania haszy raczej nie był zbyt wyrafinowany, skoro udało się względnie szybko "złamać hasła" (złamanie polega na generowaniu haseł, haszowaniu ich i sprawdzaniu czy jest taki hasz w "pozyskanej" bazie - jak jest, to znaczy, że wygenerowane hasło "działa") -- to oczywiście podwyższyło "ryzyko dla praw i wolności osób fizycznych":

naruszenie przez Spółkę obowiązków zastosowania środków zapewniających bezpieczeństwo przetwarzanych danych, przed ich udostępnieniem osobom nieupoważnionym, pociąga za sobą  potencjalną, ale realną możliwość wykorzystania tych danych przez podmioty trzecie bez wiedzy i wbrew woli osób, których dane dotyczą, (…) np. w celu zawarcia stosunków prawnych lub zaciągnięcia zobowiązań w imieniu osób

oraz

w stosunku do ww. liczby osób w dalszym ciągu istnieje wysokie ryzyko niezgodnego z prawem posłużenia się ich danymi osobowymi, albowiem nieznany jest cel, dla którego osoba nieuprawniona podjęła działania zmierzające do uzyskania dostępu do tychże informacji.

Nic w tym dziwnego, znając adres poczty elektronicznej i hasło, wiedząc iż znakomita większość ludzi używa tego samego hasła wszędzie - można dostać się do innych usług, w tym pewnie nawet poczty. A mając dostęp do poczty elektronicznej - można dalej resetować hasła.

Z perspektywy ryzyka - w przypadku tego wycieku słabe hasze w mojej ocenie stanowią największe ryzyko, większe niż pozostadane adresowe, kontaktowe i informacja o zakupach.

Urząd podkreśla bardzo mocno, że

na Spółce, przetwarzającej dane osobowe w sposób profesjonalny, w ramach jej działalności, ciąży większa odpowiedzialność i większe wymagania niż na podmiocie przetwarzającym dane osobowe w ramach działalności ubocznej, incydentalnie lub na niewielką skalę; prowadząc działalność komercyjną, a przy tym gromadząc dane za pośrednictwem sieci Internet, Spółka jako administrator tych danych powinna podjąć wszelkie niezbędne działania i dochować należytej staranności w doborze środków technicznych i organizacyjnych, zapewniających bezpieczeństwo i poufność danych; poczynione przez Prezesa Urzędu Ochrony Danych Osobowych ustalenia faktyczne dowodzą, iż Spółka w chwili wystąpienia stwierdzonych naruszeń zadaniu temu nie sprostała;

Jest to bardzo ważne stwierdzenie, które można tłumaczyć tak, że jeśli chce się robić biznes na większą skalę, to trzeba myśleć poważnie o bezpieczeństwie. Bez wątpienia - cenna lekcja dla wszystkich  e-commerce'ów.

W decyzji negatywnie ocenia się system "monitorowania sieciowego":

na szczególnie naganną ocenę zasługuje przy tym okoliczność, iż Spółka, pomimo deklaracji monitorowania systemu sieciowego i reagowania w systemie 24/7 (dwadzieścia cztery godziny, siedem dni w tygodniu), nie stwierdziła w czasie rzeczywistym, tj. w dniach 07.10.2018 - 14.10.2018 r., zwiększonego ruchu na bramie sieciowej serwera i nie podjęła w tym czasie żadnych działań zaradczych, celem uniemożliwienia dostępu do danych około 2.200.000 (ok. dwóch milinów dwustu tysięcy) osób fizycznych, będących klientami Spółki. W tym stanie rzeczy, zaniedbanie Spółki należy uznać za rażące

W mojej ocenie "prawidłowy" monitoring zwiększyłby szanse na wykrycie, ale bardzo prawdopodobne, że byłoby za późno -  przecież eksport bazy czy tabeli bazy danych do pliku trwa w zasadzie chwilę, spakowany nie będzie miał też dużego rozmiaru, więc pobranie też będzie trwało chwilę. Jeśli atakujący korzystał z konta pracownika (a najpewniej administratora), to monitoring  niewiele by dał -  pracownik pewnie w oczach monitoringu wykonywał normalną pracę. Jeśli był to panel administracyjny (np. Direct Admin i podobne), to aktywność w postaci kopii zapasowej bazy, plików, ściągania ich, wrzucania pewnie byłaby "normalną aktywnością".

Ale tu nie o monitoring chodzi, wydaje się, że źródłem problemów był "panel pracownika" dostępny z internetu z jednoskładnikowym uwierzytelnianiem (nazwa użytkownika i hasłem) - zatem "pracownik" mógł korzystać z dowolnego urządzenia, choćby i w kafejce internetowej, mógł też na jakimś urządzeniu zapisać dane do logowania bądź mogły zostać przechwycone w jakiś sposób (np.. phishing, keylogger, etc). 

Uwierzytelnianie dwuskładnikowe (organ pisze o dwu etapowym - ale ja to  rozróżniam - dwuskładnikowe i dwuetapowe  to są różne rzeczy - pierwszy oznacza, że składniki nie mogą być takie same, a drugi że mogę - np. hasło i SMS to uwierzytelnianie dwuskładnikowe - coś co osoba i wie tj. hasło i coś co ma - telefon z kartą SIM; dwuetapowe to dwa składniki, które zna - hasło, a później jakiś kod albo odpowiedź na jakieś pytanie) bez wątpienia by utrudniło atak, bo pozyskaniu obu składników do logowania nie byłoby tak trywialnie łatwe.

Organ kontrolę dostępu i uwierzytelnianie uznaje za podstawowe środki bezpieczeństwa. Przy okazji dowiadujemy się, co rozmieć przez "stan wiedzy technicznej":

kontrola dostępu i uwierzytelnianie to podstawowe środki bezpieczeństwa mające na celu ochronę przed nieautoryzowanym dostępem do systemu informatycznego wykorzystywanego do przetwarzania danych osobowych. Zapewnienie dostępu uprawnionym użytkownikom i zapobieganie nieuprawnionemu dostępowi do systemów i usług to jeden z wzorcowych elementów bezpieczeństwa, na którą wskazuje m.in. norma PN-EN ISO/IEC 27001:2017-06. Jak wynika z art. 32 ust. 1 rozporządzenia 2016/679, jednym z czynników jakie należy brać pod uwagę przy doborze właściwych środków technicznych i organizacyjnych, jest stan wiedzy technicznej, który powinno się oceniać z uwzględnieniem warunków rynkowych, w szczególności dostępności i akceptowalności rynkowej danego rozwiązania technicznego. Wskazówek konkretyzujących w tym przedmiocie dostarczają obowiązujące standardy i normy, w szczególności normy ISO, które ulegają również ciągłym przeglądom i zmianom warunkowanym postępem technologicznym.

Zdaniem organu "wybór odpowiedniego środka uwierzytelniania powinien opierać się na ocenie ryzyka realizowanej za jej pomocą transakcji lub usługi" - jeśli to był panel administracyjny, to nawet oceny wyrafinowanej oceny ryzyka nie potrzeba, aby stwierdzić, że trzeba więcej zabezpieczeń.

Sprawa dla kontrolerów była chyba oczywista, bo

pełnomocnik Spółki zwrócił się do Prezesa Urzędu Ochrony Danych Osobowych o:  (…) dopuszczenie i przeprowadzenie dowodu z opinii biegłego w zakresie bezpieczeństwa systemów informatycznych w celu: a) ustalenia standardów technicznych i organizacyjnych środków bezpieczeństwa w działalności gospodarczej przedsiębiorców w obszarze e-commerce o skali i charakterze podobnym do skali i charakterze działalności Spółki w 2018 r.; b) oceny, czy środki techniczne i organizacyjne stosowane przez Spółkę odpowiadały standardom środków bezpieczeństwa w działalności gospodarczej przedsiębiorców w obszarze e-commerce o skali i charakterze podobnym do skali i charakterze działalności Spółki w 2018 r.; c) oceny, czy środki techniczne i organizacyjne stosowane przez Spółkę były odpowiednie uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie wystąpienia i wadze zagrożenia;

a

Postanowieniem z dnia […] sierpnia 2019 r. Prezes Urzędu Ochrony Danych Osobowych odmówił uwzględnienia wniosku Spółki o dopuszczenie i przeprowadzenie wniosku z opinii biegłego.

Odrzucenie wniosku skłania do zastanowienia. Dlaczego miałby być odrzucony? W artykule https://www.rp.pl/Dane-osobowe/309209957-28-mln-zl-kary-dla-Morelenet-od... czytamy, że "Spółka będzie się odwoływała od tej decyzji do wojewódzkiego sądu administracyjnego – komentuje dr Maciej Kawecki z kancelarii Maruta Wachta, reprezentującej Morele.net. – W postępowaniu w UODO nie został bowiem chociażby uwzględniony wniosek o opinię biegłego, która mogłaby rzucić nowe światło na przebieg ataku hakerskiego, którego ofiarą padła spółka Morele.net".

Jest to gdybanie, ale jeśli sprawa była oczywista (bo przykładowo wyciek wynikał z udostępnionego w internecie panelu administracyjnego, który pozwalał na administrowanie bazami, a dostęp był jednoskładnikowy - tylko z pomocą nazwy użytkownika i hasła), to być może biegły niewiele by wniósł…

Można by rozważać, czy panel miał podatności, które zostały wykorzystane do ataku, ale to ryzyko było minimalizowane :

Spółka korzystała z zewnętrznych audytorów bezpieczeństwa (Załącznik B11 i B12 do protokołu kontroli) i wdrażała ich rekomendacje w zakresie zidentyfikowanych podatności w kodzie oprogramowania, który służy do przetwarzania danych osobowych. 

Na pewno problem był ze środkami bezpieczeństwa, bo w decyzji czytamy:

Wskazać należy, że wcześniejsze zastosowanie wdrożonego […] grudnia 2018 r. […] oraz wdrożona […] znacząco obniżyłoby ryzyko uzyskania nieuprawnionego dostępu przez osobę nieupoważnioną

Wydaje się, że wdrożono MFA (ang. multifactor authentication) oraz jeszcze coś np. ograniczono dostęp do panelu do wskazanych numerów IP lub jakieś poprawki z monitoringiem. To, że chodzi o MFA wynika z wypowiedzi Zastępcy Prezesa Urzędu Ochrony Danych Osobowych:

W obecnych czasach mechanizm dwuetapowego zabezpieczenia dostępu jest już powszechnie zalecanym standardem.

Pamiętajmy, że ciągle "gdybamy" - do czasu jeśli któraś ze stron nie wyjawi, co naprawdę się stało, nie wiemy co dokładnie było powodem  - poza tym, że "atakujący uzyskał dostęp do panelu pracownika".

Z dużym prawdopodobieństwem można uznać, że sprawa była chyba oczywista dla kontroli skoro uznano, że biegły by nic nie wniósł, to pozwala domniemywać, że

  • dane wyciekły przez "panel pracownika", a panel pozwalał też na dostęp administracyjny lub podobny
  • panel był dostępny z internetu
  • panel posiadał jednoskładnikowe uwierzytelnianie

Na Twitterze pod postem dr. Macieja Kaweckiego -  - napisałem, że "Podzielam stanowisko. Tak wysokie kary mogą odnieść skutek odwrotny od zamierzonego - naruszenia będą ukrywane, nie dość że strata z powodu ataku to jeszcze kara administracyjne. A ukrywanie naruszeń będzie ze szkodą dla osób fizycznych".

Wówczas jeszcze decyzja nie była opublikowana, a teraz po jej lekturze, już jestem skłonny popierać to stanowisko mniej. Jeśli rzeczywiście jakiś panel administracyjny albo interfejs bazy danych był dostępny z internetu i uwierzytelnianie jednoskładnikowe - to kara ma sens, bo nawet nie trzeba wykonywać formalnej analizy ryzyk, "gołym okiem" widać , że to zbyt duże ryzyko.  Zresztą sama spółka wskazała, że

„nie jest celem omawianej regulacji wyeliminowanie ryzyka w pełni, czego uczynić się nie da a jedynie wdrożenie rozwiązań technicznych i organizacyjnych odpowiednich i proporcjonalnych, przy uwzględnieniu ocenianych kryteriów” oraz, że rozporządzenie 2016/679 „nakłada na administratorów obowiązek odpowiednich (do zagrożeń) zabezpieczeń, a nie zabezpieczeń skutecznych w każdych okolicznościach”.

Stąd też przy nakładaniu kary organ uznał, że okoliczności obciążające to:

  • Zabezpieczenia niedopasowane do ryzyka (kontrola dostępu, ale rykoszetem też oberwał monitoring)
  • Duże ryzko dla praw i wolnosci osób
  • Duża skala przetwarzania (ponad 2 mln klientów)

Kara wyniosła 660 000 EUR. Byłaby wyższa, ale

  • Morele współpracowało
  • Klienci nie doznali szkód majątkowych (chociaż doznali krzywdy)
  • Nie była to recydywa ("nie zostało stwierdzone, żeby Spółka uprzednio dopuściła się naruszenia przepisów rozporządzenia 2016/679, które miałoby istotne znaczenie dla niniejszego postepowania")

Kara ma być skuteczna, proporcjonalna i odstraszająca. Na pewno będzie odstraszająca - bez wątpienia niższym kosztem byłoby wdrożyć MFA niż zapłacić 660 tys. EUR, że nie wspomnę o tym, jak ucierpiał wizerunek marki. Kara ma też stanowić przykład dla innych organizacji, jak postępować nie należy:

(…) administracyjna kara pieniężna spełni w tych konkretnych okolicznościach funkcję represyjną, jako że stanowić będzie odpowiedź na naruszenie przez Spółkę przepisów rozporządzenia 2016/679, ale i prewencyjną, jako że sama Spółka, jak i inni administratorzy będą skutecznie zniechęceni do naruszania przepisów o ochrony danych osobowych w przyszłości.

Organ uznaje też, że

Zastosowana kara pieniężna jest również proporcjonalna do stwierdzonego naruszenia, w tym zwłaszcza jego wagi, kręgu dotkniętych nim osób fizycznych oraz ryzyka, jakie w związku z naruszeniem ponoszą.  (…)  nałożona na Spółkę kara pieniężna jest również proporcjonalna do jej sytuacji finansowej i nie będzie stanowiła nadmiernego dla niej obciążenia. Wysokość kary została bowiem określona na takim poziomie, aby z jednej strony stanowiła adekwatną reakcję organu nadzorczego na stopień naruszenia obowiązków administratora, z drugiej jednak strony nie powodowała sytuacji, w której konieczność uiszczenia kary finansowej pociągnie za sobą negatywne następstwa, w postaci znaczącej redukcji zatrudnienia bądź istotnego spadku obrotów Spółki. Zdaniem Prezesa Urzędu Ochrony Danych Osobowych, Spółka powinna i jest w stanie ponieść konsekwencje swoich zaniedbań w sferze ochrony danych, stąd nałożenie kary w wysokości 2 830 410 PLN jest w pełni uzasadnione.

Z tej decyzji wyciągam następujące najważniejsze wnioski:

  • Trzeba mieć dobry proces zarządzania dostępem uprzywilejowanym - wiedzieć kto ma taki dostęp, skąd i dokąd, czy jest adekwatny do wykonywanych obowiązków, itd. Owszem, zwykły pracownik też by pewnie wyciągnął informacje o wszystkich klientach i ich zamówieniach, ale raczej nie miałby dostępu do haszy haseł, poza tym powinny być ograniczenia, że na raz widzi tylko pojedyncze rekordy klientów, a wyświetlanie więcej niż jednego rekordu w ciągu sekundy powinno generować alarm, że chyba jakiś automat jest "w grze".
  • Panele administracyjne nie mogą być dostępne z internetu  - najlepiej aby dostęp był wyłącznie z sieci lokalnej (wewnętrznej) lub przez VPN. Dostęp z sieci publicznych to bardzo zła praktyka. Oczywiście łatwo powiedzieć, ale co mają zrobić małe firmy, korzystające z hostingu? Większość narzędzi, jakie udostępniają hostingodawcy swoim klientom  nie wspiera uwierzytelniania dwuskładnikowego lub nie jest ono włączone - mam na myśli rozwiązania takie jak phpMyAdmin, DirectAdmin, dostęp do poczty (domyślnie jakiś RoundCube). To samo tyczy się interfejsów baz danych - nie powinny być dostępne z internetu lub powinny być ograniczone - czasami tak bywa, że baza danych postawiona jest na innym "hoście".
  • Należy monitorować co się dzieje w sieci. Łatwo powiedzieć, a wykonać nie tak wcale łatwo. Trudno powiedzieć co dokładnie powinno być zaimplementowane, aby wykryć atak i go zatrzymać. Bo jeśli użyto konta uprawnionego pracownika, to system monitorowania pewnie by zauważył by zwiększony ruch, ale obsługa monitoringu by stwierdziła, że to nie problem - że to pewnie typowe działanie w przypadku administratora. Nie mówiąc o tym, że jeśli było jakieś rozwiązanie typu SIEM, to musiał być zdefiniowany taki przypadek w nim do wygenerowania alertu. Sam z siebie SIEM nie będzie wiedział, co jest podejrzane. Owszem, są rozwiązania typu DarkTrace - https://www.darktrace.com - które uczą się ruchu z pomocą sztucznej inteligencji, a później już same potrafią wykryć niezwykłe zdarzenia, ale są wciąż dość drogie…
  • generować "porządnie" hasze  - rekomenduje się używać się tych, które "spowalniają" ataki typu brute-force.W teorii najlepiej pozostać przy PBKDF2, bcrypt i scrypt, ale stosowanie popularnych funcji prawidłowo "solonych" powinno wystarczyć (warto poczytać sobie o tym na stronie witryny sekurak.pl)

I jeszcze wniosek trochę mniej "informatyczny"

  • zakończenie procesu przetwarzania należy udokumentować, przykładowo w rejestrze czynności przetwarzania - aby można było wykazać, że chociaż już proces przetwarzania nie istnieje, ale gdy był - to był zgodny z przepisami. Wiem, to dość zaskakujące, kontrola powinna oceniać stan faktyczny, a nie przeszły. Ale jednak wniosek jest.

EDIT (9.10.2019 r.): 

To była na pewno cenna lekcja dla Morele.net. Nie rezygnuję z zakupów w tym sklepie, wręcz przeciwnie, liczę na to, że będą przykładać się teraz do zabezpieczeń. 
 

 

Obrazek: