Błędy w MOL Move pozwalały zmienić konto w pracownika

29 lipca 2026 roku Niebezpiecznik opisał zgłoszenie badacza Filipa Dębińskiego dotyczące aplikacji MOL Move. Zgodnie z udokumentowanym opisem endpoint zapisujący profil przyjmował dodatkowe pola przesłane w żądaniu POST, mimo że użytkownik nie mógł edytować ich w interfejsie. Pozwalało to między innymi zmienić zwykłe konto w konto pracownika, zmodyfikować adres e-mail bez weryfikacji, kod polecający, numer karty lojalnościowej i poziom programu lojalnościowego.

To nie jest historia o „włamaniu do całego Salesforce” ani potwierdzonym wycieku bazy klientów. Badacz uzyskał rozszerzony widok własnego konta i dostęp do części interfejsu Salesforce, lecz według publikacji nie znalazł dostępu do danych innych użytkowników. Równie ważna jest druga część sprawy: pierwsze próby odpowiedzialnego zgłoszenia nie doprowadziły do skutecznej reakcji, a MOL wyjaśnił później, że pierwotna wiadomość została zaklasyfikowana jako spam.

Co zostało potwierdzone 29 lipca

Publikacja Niebezpiecznika jest źródłem pierwotnego opisu badania, chronologii zgłoszenia oraz odpowiedzi biura prasowego MOL Polska. Na jej podstawie można potwierdzić następujące zachowania:

endpoint aktualizacji profilu akceptował pola niewidoczne w interfejsie;
możliwa była zmiana adresu e-mail bez potwierdzenia nowego adresu;
odpowiednio dobrana wartość pola pozwalała oznaczyć konto jako pracownicze;
użytkownik mógł zmienić referral code, kod karty lojalnościowej i poziom „Loyalty Tier”;
pojawiał się dostęp do elementów powiązanych z Salesforce oraz możliwość edycji części własnych rekordów;
badacz nie potwierdził odczytu lub modyfikacji rekordów innych klientów.

MOL odpowiedział redakcji, że informacja została przekazana odpowiednim zespołom Grupy MOL i jest obsługiwana zgodnie z procedurami. Firma nie ujawniła statusu konkretnej poprawki, powołując się na względy bezpieczeństwa. Dlatego nie wolno pisać, że podatność na pewno nadal działa, ale nie ma też publicznego dowodu pozwalającego ogłosić jej skuteczne usunięcie.

Techniczna przyczyna: klient nie wyznacza granicy uprawnień

Interfejs aplikacji może ukryć pole employee, email, tier albo cardCode, lecz nie tworzy to kontroli bezpieczeństwa. Atakujący nie musi korzystać z formularza. Może odtworzyć żądanie HTTP, dopisać parametry i wysłać je bezpośrednio do API. Backend musi więc posiadać jawną listę pól, które dana rola może zmienić.

Opis pasuje do klasy problemów określanej jako mass assignment, over-posting lub improper authorization of object fields. Framework mapuje obiekt JSON albo dane formularza na model aplikacji, a programista zakłada, że klient prześle wyłącznie pola pokazane na ekranie. Jeżeli serializator przyjmie wszystko, granica zaufania zostaje przeniesiona do przeglądarki, którą użytkownik w pełni kontroluje.

Prawidłowy wzorzec nie polega na blokowaniu kilku „niebezpiecznych” nazw. Bezpieczniejsza jest osobna struktura wejściowa dla każdej operacji:

UpdateCustomerProfile = {
  displayName,
  phoneNumber,
  marketingConsent
}

Pola roli, statusu pracownika, identyfikatora karty i poziomu lojalnościowego powinny być ustawiane przez odrębne procesy z osobną autoryzacją, rejestrem zmian i walidacją reguł biznesowych. Gdy jedno ogólne updateProfile() zapisuje dowolne właściwości modelu, test powinien zakładać, że prędzej czy później ktoś prześle pole spoza interfejsu.

Dlaczego to nie jest zwykły błąd formularza

Zmiana roli użytkownika jest pionową eskalacją uprawnień. Zmiana e-maila bez weryfikacji może natomiast stać się etapem przejęcia konta, jeżeli mechanizm odzyskiwania hasła ufa nowemu adresowi. Modyfikowanie poziomu lojalnościowego lub kodu karty wpływa na integralność programu, rozliczenia partnerów i potencjalne korzyści finansowe.

Każde z tych pól ma inny skutek, ale wspólną przyczynę: serwer autoryzuje operację „edytuj swój profil”, nie sprawdzając osobno, które właściwości użytkownik może zmieniać. To bliski krewny problemów opisanych w naszym przewodniku o IDOR i BOLA w API. IDOR dotyczy zwykle wyboru cudzego obiektu, a mass assignment — niedozwolonej właściwości obiektu własnego. Dojrzały pentest sprawdza obie osie.

Salesforce Sites nie jest sam w sobie dowodem błędu platformy

Według opisu MOL Move korzystało z Salesforce Sites, a nazwy niestandardowych pól można było rozpoznać po charakterystycznym sufiksie w kodzie. Nie oznacza to, że Salesforce automatycznie nadał użytkownikom rolę pracownika. Platforma udostępnia mechanizmy danych i API, ale aplikacja nadal musi prawidłowo skonfigurować dostęp do obiektów, pól, profili i własnych endpointów.

W analizie powdrożeniowej trzeba oddzielić:

uprawnienia profilu lub guest usera w Salesforce;
walidację wejścia w kontrolerze lub Apex;
reguły dostępu do rekordów;
mechanizm aktualizacji adresu e-mail;
logikę biznesową programu lojalnościowego;
widoczność interfejsów administracyjnych.

Naprawienie jednego endpointu bez przeglądu podobnych kontrolerów może zostawić ten sam wzorzec w innych ścieżkach. Pomaga przegląd wszystkich operacji, które deserializują dane klienta do obiektów domenowych, oraz test ról wykonywany na poziomie pola.

Jak bezpiecznie potwierdzić naprawę

Retest nie powinien polegać na ponownym nadaniu sobie realnych korzyści lub ingerencji w dane produkcyjne. Można użyć dedykowanych kont testowych i nieszkodliwych wartości kontrolnych. Zespół powinien potwierdzić, że:

pola spoza allowlisty są ignorowane lub żądanie jest odrzucane;
zmiana e-maila wymaga potwierdzenia pod starym i/lub nowym adresem zgodnie z modelem ryzyka;
rola pracownika może być nadana wyłącznie przez kontrolowany proces administracyjny;
backend ponownie oblicza poziom lojalnościowy na podstawie zaufanych zdarzeń;
każde podwyższenie roli i zmiana identyfikatora lojalnościowego trafiają do niezmienialnego logu;
alert wykrywa nietypową masową zmianę profili lub pól uprzywilejowanych;
podobne endpointy nie powielają tego samego wzorca.

Automatyczny skaner może zauważyć publiczny endpoint, ale nie rozumie, że Loyalty Tier albo flaga pracownika ma znaczenie biznesowe. Właśnie dlatego ręczny test penetracyjny aplikacji webowej i API powinien obejmować role, przepływy i znaczenie pól, a nie tylko klasyczne payloady.

Druga podatność: nieskuteczny kanał disclosure

Badacz próbował zgłosić problem 27 kwietnia, 15 maja i 6 czerwca. Po kontakcie Niebezpiecznika z biurem prasowym firma poprosiła o szczegóły. MOL wyjaśnił później, że pierwotna wiadomość dotarła do właściwego kanału z opóźnieniem, ponieważ serwery pocztowe oznaczyły ją jako spam.

Brak programu bug bounty nie ma tu decydującego znaczenia. Bug bounty to program wynagrodzeń. Vulnerability Disclosure Program określa bezpieczny kanał, zakres, zasady działania w dobrej wierze, oczekiwany czas potwierdzenia i sposób koordynacji. Organizacja może nie płacić nagród, a nadal profesjonalnie odbierać zgłoszenia. Różnicę opisujemy w materiale VDP a bug bounty.

Minimalny proces powinien obejmować:

/.well-known/security.txt z aktualnym kontaktem i datą wygaśnięcia;
skrzynkę obsługiwaną przez zespół bezpieczeństwa, nie ogólny adres biurowy;
szyfrowany kanał i mechanizm bezpiecznego przekazywania załączników;
automatyczne potwierdzenie z numerem sprawy;
zastępstwo właściciela podczas urlopu i monitoring folderu spam;
SLA triage zależne od możliwego wpływu;
jasną politykę safe harbor dla działań w dobrej wierze;
ewidencję od zgłoszenia przez poprawkę po retest.

W organizacjach objętych KSC/NIS2 przyjmowanie i obsługa informacji o podatnościach jest częścią zarządzania ryzykiem, a nie uprzejmością wobec badaczy. Sam plik security.txt też nie wystarczy, jeżeli prowadzi do niepilnowanej skrzynki.

Co powinien zrobić właściciel podobnej aplikacji

Najpierw zinwentaryzuj endpointy aktualizujące użytkownika, organizację, subskrypcję, program lojalnościowy i role. Następnie porównaj pola przyjmowane przez backend z polami, które dana rola faktycznie ma prawo modyfikować. Test powinien obejmować JSON, formularze, GraphQL, operacje bulk, import CSV oraz interfejsy mobilne korzystające z tego samego API.

Potem przejrzyj logi historyczne. Szukaj zmian pól uprzywilejowanych z sesji klientów, nagłych podwyższeń statusu, modyfikacji e-maila bez odpowiadającego zdarzenia weryfikacji oraz sekwencji, w której zwykłe konto otwiera interfejs pracowniczy. Brak logu nie dowodzi braku nadużycia — jest luką dowodową, którą trzeba formalnie opisać.

Na koniec przeprowadź ćwiczenie disclosure: wyślij kontrolowane zgłoszenie z zewnętrznego adresu, sprawdź potwierdzenie, eskalację, szyfrowanie i czas dotarcia do właściciela produktu. To dobry scenariusz szkoleniowy dla zespołu. Szkolenia cyberbezpieczeństwa dla pracowników powinny obejmować nie tylko phishing, ale też rozpoznawanie wiadomości, których automatyczne odrzucenie może zwiększyć ryzyko firmy.

Źródła i granice wnioskowania

Źródłem faktów o zachowaniu aplikacji, próbach kontaktu i odpowiedziach MOL jest publikacja Niebezpiecznika z 29 lipca 2026. Informacja, że badacz nie uzyskał danych innych użytkowników, pochodzi z tego samego opisu i nie jest gwarancją, że żadna inna ścieżka nie istniała.

Wnioski o mass assignment, allowlistach pól, detekcji, retestach i procesie VDP są analizą BreachRoad opartą na publicznie opisanym mechanizmie. Nie twierdzimy, że doszło do wycieku danych, że wykorzystano błąd przestępczo ani że podatność pozostaje aktywna. Najważniejszy wniosek jest praktyczny: kontrolę pola i obsługę zgłoszeń trzeba traktować jak dwa elementy tego samego systemu bezpieczeństwa.

Jak zmierzyć, czy poprawka naprawdę działa

Samo usunięcie kilku pól z odpowiedzi aplikacji mobilnej nie jest retestem. Zespół powinien przygotować macierz ról i operacji: klient anonimowy, zalogowany użytkownik programu, pracownik stacji, administrator oraz integracja systemowa. Dla każdej roli należy wskazać pola możliwe do odczytu i zapisu, a następnie sprawdzić backend bez pośrednictwa interfejsu. Takie podejście jest częścią dobrego testu bezpieczeństwa aplikacji i API.

Warto zachować dowód dla trzech warstw:

negatywnej: nieautoryzowane pole zostaje odrzucone, a stan rekordu się nie zmienia;
pozytywnej: legalna aktualizacja profilu nadal działa;
obserwowalności: próba manipulacji tworzy czytelne zdarzenie z użytkownikiem, rolą, nazwą pola i wynikiem kontroli.

Test musi uwzględnić różne reprezentacje tej samej operacji. Jeżeli aplikacja ma kilka wersji API, endpoint bulk albo integrację z Salesforce, poprawa jednej ścieżki nie zamyka problemu. Dobrą praktyką jest też test regresyjny wykonywany przy każdej zmianie modelu użytkownika. Dodanie nowego pola uprzywilejowanego nie powinno automatycznie czynić go zapisywalnym dla klienta.

Lekcja dla projektowania procesu ujawniania

Opisany przypadek pokazuje również ryzyko operacyjne poczty. Filtr antyspamowy jest potrzebny, lecz zgłoszenia zawierające słowa „podatność”, fragmenty JSON lub nietypowe załączniki mogą wyglądać podejrzanie. Kanał bezpieczeństwa powinien mieć monitorowaną kolejkę, automatyczne potwierdzenie i zastępstwo właściciela. Organizacja może opublikować security.txt, zasady bezpiecznych testów oraz sposób szyfrowania zgłoszeń.

Mierniki nie powinny ograniczać się do czasu zamknięcia. Warto śledzić czas pierwszego potwierdzenia, dotarcia do właściciela systemu, odtworzenia problemu, ograniczenia ryzyka i retestu. Przewodnik o zarządzaniu podatnościami jako procesie pokazuje, jak połączyć priorytet techniczny z odpowiedzialnością biznesową, a Akademia Breachroad porządkuje podstawy bezpiecznej analizy bez potrzeby uruchamiania ryzykownych testów na cudzych systemach.

Końcowym rezultatem nie jest więc tylko łatka. To udokumentowana reguła autoryzacji, test regresyjny, alarm na próbę nadużycia i sprawny kanał, którym kolejny badacz może bezpiecznie ostrzec firmę.