Każdy mógł być pracownikiem stacji benzynowej MOL dzięki błędom w apce. Firma zignorowała zgłoszenie

Wielokrotnie już powtarzaliśmy, że firmy muszą mieć kanał do bezpiecznego i skutecznego zgłaszania błędów w swoich produktach/usługach cyfrowych. Spółka paliwowa MOL teoretycznie taki kanał ma, ale nie zadziałał poprawnie w przypadku zgłoszenia od naszego Czytelnika.

KSC2 i NIS2 tego wymagają…

Żyjemy w czasach NIS2 i KSC2. To oznacza, że różne firmy (a zwłaszcza te o znaczeniu krytycznym) powinny przyjmować zgłoszenia podatności w swoich produktach od innych instytucji oraz niezależnych badaczy. Warto podkreślić, że skuteczny system przyjmowania zgłoszeń to ważny element procesu zarządzania ryzykiem.

Taki system zgłoszeń w teorii powinien obejmować:

1. opublikowanie jasnych zasad zgłaszenia firmie luk;
2. udostępnienie bezpiecznego kanału do zgłoszeń (np. specjalny formularz lub dedykowany e-mail z możliwością przesłania wiadomości szyfrowanej);
3. gwarancję bezpieczeństwa prawnego dla badacza działającego w dobrej wierze,
4. potwierdzenie odbioru wiadomości,
5. komunikację zwrotną.

Tyle teorii, a jak jest w praktyce? W przypadku niektórych film jest po prostu jeden biurowy ogólny e-mail. Wiadomości z tego maila może czytać ktokolwiek, a jeśli wiadomość wpadnie do spamu to trudno. Tematu nie było 🙂 Przekonał się o tym badacz bezpieczeństwa Filip Dębiński, który znalazł ciekawe luki w aplikacji MOL. Znalazł i niestety nie mógł ich skutecznie zgłosić, dlatego odezwał się do nas. Ale zacznijmy od początku.

Co znalazł Filip?

Filip zauważył, że webowa  aplikacja MOL Move działa na Salesforce Sites. W toku analizy ustalił, że wszystkie customowe pola w Salesforce mają pewien specyficzny suffix. Wyszukując ten suffix w kodzie można było znaleźć interesujące fragmenty kodu zawierające informacje m.in. o typie konta użytkownika. Filip zauważył, że endpoint zapisujący dane profilu akceptował dodatkowe pola przesłane w requeście POST, nawet jeśli nie są one dostępne z poziomu interfejsu użytkownika. Dzięki temu możliwa była nieautoryzowana zmiana adresu e-mail konta, mimo że taka opcja nie jest dostępna nigdzie w systemie. Co więcej, zmiana odbywała się bez żadnej weryfikacji nowego adresu e-mail. Efekt? Można było “zostać pracownikiem” dosyłając pewne pole z określoną wartością.

Dzięki temu trickowi Filip ujrzał jak wygląda konto pracownika.

Filip natrafił też na dostęp do interfejsu Salesforce. Po wyszukaniu własnego konta mógł przejść do widoku swoich rekordów i edytować część danych bezpośrednio z poziomu Salesforce. Nie znalazł możliwości dostępu do danych innych użytkowników.

Podsumowując, możliwa była manipulacja kontem użytkownika, w tym:

• eskalacja uprawnień (zmiana zwykłego konta na konto pracownika),
• zmiana adresu e-mail mimo blokady w ustawieniach,
• modyfikacja referral code (np. na dowolną wartość),
• zmiana kodu karty lojalnościowej,
• zmiana poziomu „Loyalty Tier” (np. z Basic na VIP),
• uzyskanie dostępu do sekcji, które nie powinny być dostępne dla użytkownika (m.in. elementy powiązane z Salesforce).

To wystarczająco dużo błędów aby “przejąć się” i “coś z tym zrobić”.

I co na to MOL?

MOL to przedsiębiorstwo z branży przetwórstwa i dystrybucji paliw. Tego typu firma powinna mieć uporządkowane i dojrzałe podejście do obsługi incydentów cyber. Przede wszystkim powinna przyjąć i obsłużyć zgłoszenie. Tymczsem…

1. Filip zgłosił problemy z aplikacją 27 kwietnia. Nic się nie wydarzyło.
2. Kolejną próbę podjął 15 maja. Brak reakcji.
3. 6 czerwca Filip usiłował zgłosić sprawę węgierskiej centrali firmy. Bez skutku.

Filip przedstawił nam historię “korespondencji” (czy też raczej jednostronnych prób kontaktu). Z powodu braku reakcji spółki, Filip zgłosił się do nas. 24 czerwca spytaliśmy biuro prasowe MOL o tę sprawę. Przesłaliśmy następujące pytania:

1. Czy MOL Polska jako istotny dostawca paliw i również firma ujęta w systemie cyberbezpieczeństwa w ogóle monitoruje zgłaszanie luk bezpieczeństwa w jego produktach?
2. Czy zgłoszenie Pana Filipa Dębińskiego zostało jakkolwiek dostrzeżona A może nasza redakcja ma przekazać jego szczegóły?
3. Jakie reakcje zamierza podjąć MOL Polska w związku z tą sprawą. Jeśli nie zamierza nic robić i akceptuje ryzyko wynikające z błędów w aplikacji to również prosimy o potwierdzenie tego.

Na nasze pytania MOL zareagował 26 czerwca. Otrzymaliśmy telefoniczne potwierdzenie, że dostaniemy jakąś odpowiedź oraz – co ważne – poproszono nas o przesłanie szczegółów sprawy. To sugeruje, że MOL nie był w stanie od razu odnaleźć zgłoszenia Filipa po swojej stronie. Następnie otrzymaliśmy “odpowiedź” następującej treści:

Panie Redaktorze,
Ochrona danych naszych klientów oraz zapewnienie bezpieczeństwa naszych usług cyfrowych należą do najwyższych priorytetów MOL. Nieustannie monitorujemy, testujemy i wzmacniamy nasze systemy cyfrowe, aby proaktywnie identyfikować i zapobiegać potencjalnym zagrożeniom bezpieczeństwa. Ponadto każde zgłoszenie dotyczące potencjalnych podatności jest starannie weryfikowane i analizowane zgodnie z naszymi wewnętrznymi procedurami bezpieczeństwa. W razie potrzeby wdrażane są odpowiednie działania. Prosimy również zauważyć, że MOL nie prowadzi programu typu „bug bounty” i w związku z tym nie oferuje wynagrodzenia finansowego za zgłoszenia podatności. Z wyrazami szacunku, Biuro Prasowe MOL Polska

Właściwie jedyne co z tego wynika, to że MOL nie ma programu “bug bounty”. Nadal jednak nie wiedzieliśmy czy obsłużono zgłoszenie i zrobiono w tej sprawie cokolwiek. Dopytaliśmy więc, a odpowiedzi dostaliśmy 2 lipca. Poniżej nasze pytania i odpowiedzi jakie otrzymaliśmy:

Czy zgłoszona luka została sprawdzona i załatana
Informacja o potencjalnej podatności została przekazana do odpowiednich zespołów w ramach Grupy MOL i jest obsługiwana zgodnie z obowiązującymi procedurami zarządzania bezpieczeństwem. Ze względów bezpieczeństwa nie komunikujemy szczegółów technicznych ani statusu konkretnych zabezpieczeń. Możemy natomiast zapewnić, że każde tego typu zgłoszenie jest weryfikowane, a w przypadku potwierdzenia podatności wdrażane są działania naprawcze.

Nawet jeśli MOL nie prowadzi programu Bug Bounty to w jaki sposób zgłaszać luki, aby to zgłoszenie zostało obsłużone? 
W przypadku MOL Polska podstawowym kanałem kontaktu pozostaje adres: biuro@molpolska.pl. Zgłoszenia są przekazywane do właściwych zespołów w Grupie MOL i podlegają weryfikacji w ramach standardowych procesów bezpieczeństwa.

Dlaczego w przypadku pana Filipa zignorowano zgłoszenie?
Każda informacja dotycząca bezpieczeństwa jest w Grupie MOL traktowana priorytetowo i podlega wnikliwej analizie zgodnie z obowiązującymi standardami. W tym przypadku, niezwłocznie po otrzymaniu pełnych informacji, sprawa została przekazana do właściwych zespołów w Grupie MOL w celu dalszego procedowania. Z przeprowadzonej analizy wynika, że pierwotna informacja trafiła do właściwego kanału obsługi z opóźnieniem, ponieważ korespondencja została zaklasyfikowana przez serwery pocztowe jako spam.

Nie chcę przegapić zgłoszenia o błędzie w moim produkcie/systemie/aplikacji/usłudze — co robić, jak żyć?

I tutaj, na koniec, ważna informacja: zgłoszenia luk czasem trafiają do spamu, niekiedy jest to zrozumiałe (dużo kodu, różne triggerujące systemy bezpieczeństwa keywordy), dlatego dla skrzynki dotyczącej tego typu zgłoszeń warto filtry antyspamowe wyłączyć albo pamiętać o przeglądaniu spamu. W końcu robić będą to “fachowcy”. W naszej opinii Filip zrobił wszystko jak należy, ale zgłoszenie nie zostało obsłużone. MOL nie informuje o innych kanałach kontaktu niż e-mail (nawet biuro prasowe ma tylko taki kanał kontaktu). Owszem, można się dodzwonić do niektórych działów firmy (np. na infolinię karty paliwowej albo do zespołu ds. planowania dostaw), ale zgłaszanie problemu bezpieczeństwa niebezpośredni nie jest najlepszym pomysłem.

Dlatego, jeśli prowadzisz jakąkolwiek firmę, która ma stronę internetową lub aplikację to koniecznie zadbaj o łatwodostępną i czestosprawdzalną drogę zgłaszania Ci błędów — standardem w branży jest umieszczenie pliku security.txt w obrębie swojej domeny w ścieżce /.well-known/security.txt. Zachęcamy wszystkich, aby to zrobili, jeśli jeszcze takiego pliku nie mają.

No i zachęcamy do uporządkowania swoich procesów obsługi incydentów zgodnie z wytycznymi KSC2/NIS2 — a o tym jak to zrobić mówiliśmy podczas tego krótkiego i zwartego szkolenia. Tam zresztą jest o wiele więcej istotnych i praktycznych wskazówek dla osób, które muszą dostosować swoją organizację do wymogów nowej ustawy o Krajowym Systemie Cyberbezpieczeństwa (albo ustalić, czy muszą). Dla przypomnienia, z kodem NIS25 dostęp do tego szkolenia otrzymasz z 25% zniżką. Kod ważny jest tylko do 5 sierpnia 10:00. Tutaj link bezpośrednio do koszyka.