Freshmail upublicznił dane 1000+ klientów. Poinformował UODO, ale nie ofiary

Katalog na webserwerze zawierający poufne informacje został omyłkowo udostępniony publicznie i zindeksowany w Google — takich historii znamy sporo. Wbrew pozorom zdarzają się one nie tylko małym firmom bez zaplecza IT. Podobną wpadkę zaliczył także Freshmail.pl, bardzo dobrze znany dostawca usług z zakresu e-mail marketingu.

Głębokie ukrycie bazy danych

Ta historia zaczyna się w październiku 2018 roku. Jeden z naszych Czytelników (Mariusz) przyjrzał się stronie Freshmail.pl pracującej na WordPressie, bo zmusiła go do tego sytuacja zawodowa.

mój obecny pracodawca właśnie z [Freshmaila] migruje do konkurencji – tak właśnie trafiłem na powyższy błąd (weryfikując za i przeciw) oraz studiując dokładniej API (…) systemu.

Oto jeden z katalogów na który trafił Mariusz, a który był publicznie dostępny:

Po nitce do kłębka… i można było trafić na:

W którym to Mariusza najbardziej zainteresował katalog backups. Tam znajdował się interesujący plik SQL.

Znamy tę wtyczkę do “backupu” WordPressa. To pełna kopia bazy serwisu.

Natychmiastowe zgłoszenie i błyskawiczna odpowiedź

Mariusz postanowił zgłosić sprawę Freshmailowi. Oto co napisał w swoim zgłoszeniu:

Z powyższych plików można wyciągnąć kilka ciekawych informacji odnośnie struktury firmowej strony, adresy email itd. Myślę, że dla średnio ogarniętego script kiddie wystarczy aby trochę namieszać na Państwa stronie (wstrzyknąć niebezpieczny kod, złamać hasło administratora – baza z 5 lipca 2018 r. lub wykorzystać stronę do kampanii phishingowej – bazując na Państwa marce. Scenariuszy może być naprawdę sporo, mimo bezpośredniego połączenia z systemem freshmail). Nie upubliczniam tego znaleziska – google to już zrobiło za mnie;) Każdemu zdarzają się błędy – pierwsza dewiza nie szkodzić 😉 Dlatego proszę o załatanie luki oraz informację gdy strona będzie już “bezpieczna”, a powyższy przypadek możliwy do opisania.

Mariusz miał rację. Plik z backupem bazy jest kompletną kopią tego, do czego dostęp ma WordPress. A Freshmailowa instancja WordPressa miała kilka formularzy, w których klienci mogli zostawiać swoje dane. Mariusz pokazał nam zrzuty, które zrobił na własny użytek i przyznał, że Freshmail szybko i profesjonalnie zareagował. Oto cytat z e-maila, jaki Mariusz otrzymał od CEO Freshmaila, Pawła Sali:

Jeszcze raz chciałem Panu podziękować za profesjonalne zgłoszenie naszej luki bezpieczeństwa. Podjęliśmy następujące kroki:
– Analiza dziennika logów serwera WWW
– Analiza wszystkich plików i danych przechowywanych w bazie danych w ramach bloga oraz strony firmowej
– Zabezpieczenie wszystkich plików zawierających wrażliwe danych poprzez usunięcie do nich dostępu
– Wprowadzenie dodatkowych reguł bezpieczeństwa w dostępie do plików serwera z poziomu firmy zapewniającej hosting
– Aktualizacja silnika bloga (WordPress) oraz używanych pluginów do najnowszych wersji narazie w środowisku deweloperskim, następnie w produkcyjnym
– Zmiana kluczy API używanych do integracji z pozostałymi serwisami (np. systemem FreshMail)
– Wyłączenie wszystkich nieużywanych kont użytkowników
– Wymuszenie zmiany haseł dla wszystkich pozostałych użytkowników
– Ograniczenie dostępu do panelu administratora strony internetowej do połączeń z adresów IP biura firmy FreshMail Sp. z o. o.
– Powiadomienie Prezesa Urzędu Ochrony Danych Osobowych zgodnie z art 33 RODO.

Dodatkowo przygotowujemy konkurs na audyt bezpieczeństwa strony Internetowej ze stron firm zajmujących się bezpieczeństwem oraz rozpatrujemy przeniesienie strony na inne, bardziej bezpieczne, środowisko. Jednocześnie pragnę poinformować o programie bug bounty, który posiadamy u nas w firmie. Chcielibyśmy się z Panem skontaktować w celu ustalenia szczegółów wysokości i formy wynagrodzenia.

Bez dwóch zdań, reakcja jest poprawna. Hardening, reset kluczy i wymuszenie zmiany haseł użytkownikom. Miłym akcentem jest oferta wynagrodzenia zgłaszającego. Nie każdą firmę stać na taki gest! Brawo Freshmail!

Niestety, jak poinformował nas Mariusz, po tej wiadomości “kontakt z Freshmailem umarł“… Firma miała procesować jego zgłoszenie w ramach bug-bounty, ale przestała odpowiadać na próby kontaktu Mariusza, choć ten próbował uderzać i na adresy działów i do poszczególnych pracowników firmy.

Postanowiliśmy więc pomóc Mariuszowi w odnowieniu kontaktu, a przy okazji spytaliśmy Freshmail m.in. co było w pliku SQL znalezionym przez Mariusza.

Freshmail powiadomił UODO ale nie klientów

CEO Freshmaila, Paweł Sala, odpowiedział nam, że publicznie dostępnym backupie bazy znajdowało się…

… 1106 rekordów danych osobowych osób biorących udział w eventach organizowanych przez FreshMail – swego czasu rejestracja na eventy była robiona za pomocą platformy WordPress. Zakres danych to:
– imię, nazwisko,
– adres email,
– numer telefonu,
– stanowisko,
– nazwa firmy,
– adres IP.

Paweł Sala zapewnił nas, że wyciek został zgłoszony do UODO w terminie 72 godzin, natomiast nie poinformowano o wycieku osób, których dane wyciekły.

Czy to dobra decyzja?

Wielu z Was pewnie teraz odczuwa chęć krzyknięcia “Skandal! Hańba!” 😉 Ale powoli… Pamiętajcie, że obowiązek informowania “ofiar” istnieje tylko wówczas, jeśli wyciek wiąże się z wysokim ryzykiem naruszenia praw i wolności. Tutaj, wedle Freshmaila taka sytuacja nie nastąpiła. I Paweł Sala sensownie tłumaczy to w ten sposób:

Po przeanalizowaniu zdarzenia określiliśmy poziom ryzyka na „średni” w związku z powyższym nie informowaliśmy osoby znajdujące się ww. backupie. Jedocześnie poprosiliśmy osobę która pobrała o skasowanie ww. pliku – wyjaśnił Paweł Sala.

Jesteśmy w stanie zaakceptować taką decyzję. Raz, że dane w wycieku to dane przede wszystkim różnych pracowników firm (firmowe e-maile i numery telefonów), więc są to informacje, które nierzadko są znane szerszemu kręgowi osób. Dwa, że wedle analizy Freshmaila, dostęp do pliku z bazą, choć był publiczny, to nie został wykorzystany przez nikogo poza Mariuszem. I jeszcze jednym adresem IP.

Luka w zabezpieczeniu strony została wykryta przez naszego klienta, który zgłosił na takie naruszenie jednocześnie informując redakcje serwisu niebezpiecznik.pl o takim fakcie. Odnotowaliśmy dwukrotne pobranie ww. pliku. Zakładamy, że pobranie zatem nastąpiło przez Was (redakcję Niebezpiecznika) oraz osobę zgłaszającą.

Interesujące założenie, choć wydaje nam się, że Freshmail nie ma 100% pewności, czy to byliśmy my. Nawet my takiej pewności nie mamy. Pytaliśmy co prawda w redakcji, czy ktokolwiek pobierał ten plik. Ale nikt się do tego nie przyznał. Nie znamy też adresu IP, który pojawił się w logu serwera — wtedy być może łatwiej byłoby nam potwierdzić, czy należy do nas.

Wracając do rzeczy — nasz kontakt sprawił, że Mariusz znów jest zadowolony ze współpracy z Freshmailem i jak nam właśnie napisał,

Muszę przyznać, że działacie bardzo sprawnie 🙂 Gratuluje. Sprawa ruszyła z kopyta. Będzie parę uśmiechów więcej na tym świecie. Dzięki i pozdrowienia dla całej redakcji.

Głębokie ukrycie to …płytki błąd

Katalogi niezabezpieczone przed publicznym dostępem to problem, który wraca jak bumerang. Często pisaliśmy o nich w naszych zestawieniach wpadek na uczelniach. Zdarza się to również sklepom (na co bardzo ciekawie reagują ich “administratorzy”), a nawet firmom obsługującym szpitale i przetwarzającym wrażliwe dane medyczne. Ciekawy był też przypadek ujawnienia folderu dostępnego przez FTP w systemu dla szkół.

Tych i wielu innych błędów można łatwo uniknąć.

Jak zabezpieczyć webaplikację przed wyciekami?

Wystarczy w odpowiedni sposób podejść do budowy swojej webaplikacji i regularnie ją testować. Łatwo powiedzieć, trudniej zrobić. Ale nie od razu oznacza to, że trzeba wynająć profesjonalnego zespołu pentesterów i wydać kilkadziesiąt tysięcy na gruntowną analizę zabezpieczeń.

W zabezpieczeniu webaplikacji całkiem nieźle radę dać mogą “wewnętrzni”, firmowi testerzy QA i programiści. Przy użyciu odpowiednich narzędzi i łatwych do wdrożenia w cykl rozwoju oprogramowania metodyk, które — zgodnie z zasadą Pareto — przekują 20% wysiłek pracowników w spełnienie 80% wymogów bezpieczeństwa.

O tych narzędziach, metodykach i innych quick-winach (oraz o tym jak uzyskać brakujące 20% security) opowiadamy na naszym bestsellerowym szkoleniu z Atakowania i Ochrony Webaplikacji. Niebawem odbędzie się ono w Warszawie (23-24 stycznia) i Krakowie (6-7 lutego). Na oba terminy zostało jeszcze tylko kilka wolnych miejsc, a zapisać się warto. To szkolenie realizujemy od 9 lat i jest naprawdę mocno dopieszczone.

Przez 2 dni dostaniecie od nas masę praktycznej wiedzy i porad z tematu bezpieczeństwa webaplikacji, które pozwolą skutecznie zabezpieczyć Waszą webaplikację przed atakami i wyciekami. Trochę się też spocicie, bo 80% szkolenia to warsztaty, gdzie na żywo hackujemy “dziurawy” sklep internetowy. Zresztą, sami poczytajcie opinie uczestników ostatnich edycji tego szkolenia one mówią same za siebie 🙂

Źródło: niebezpiecznik.pl