Oto błąd, który pozwalał za darmo zamawiać jedzenie z cateringu “Kuchnia Vikinga” i z jeszcze jednego

Istotne błędy bezpieczeństwa można znaleźć nawet jeśli nie jest się zawodowym pentesterem. Przekonał się o tym nasz Czytelnik Tomek Stojanov, który przekonał aplikację do zamawiania dietetycznego cateringu by w nieskończoność zwiększała mu saldo. Tomek to jednak uczciwy klient, więc postanowił błąd ujawnić. I dobrze się stało, bo – jak wykazała analiza – z tego samego błędu korzystał ktoś jeszcze. Już nie taki etyczny.

Chcecie darmowy obiad, śniadanie i kolację od Vikinga?

W połowie listopada do naszej redakcji zgłosił się Tomek, który nie jest ani programistą ani specjalistą od bezpieczeństwa, ale jest człowiekiem spostrzegawczym. W czasie korzystania z aplikacji cateringu dietetycznego o nazwie “Kuchnia Vikinga” zauważył coś dziwnego… Aplikacja pozwalała na złożenie zamówienia i anulowanie go. Po anulowaniu użytkownikowi naliczały się punkty lojalnościowe o równowartości kwoty zamówienia. Punkty mogły być wykorzystywane do opłacenia kolejnych zamówień. I teraz ważna rzecz:

Proces anulowania trochę trwał, a użytkownik mógł w trakcie tego “trwania” anulować dostawę po raz kolejny. I kolejny. I kolejny, zanim to pierwsze anulowanie dobiegło końca.

Poniżej film z akcji nagrany przez Tomka:

Błąd jak widzicie poważny. Mógł powodować straty finansowe po stronie dostawcy cateringu.

Tomek błąd chciał zgłosić, ale miał z tym problem…

Odezwał się do firmy MasterLife Solutions, która jest dostawcą aplikacji mobilnej dla Kuchni Vikinga. Ta odesłała go do serwisu Intigriti (służącego do obsługi zgłoszeń typu bug bounty), który dla osoby nietechnicznej był trudny w obsłudze. Tomek nie bardzo wiedział jak dokonać zgłoszenia. W związku z tym, Tomek postanowił napisać nam e-maila. Tu pojawia się ciekawe pytanie: czy programy Bug Bounty nie powinny mieć jakiejś ścieżki zgłoszenia dla zwykłych użytkowników, którzy zobaczyli błąd nie tyle w kodzie co w działaniu aplikacji? To pozostawiamy do przemyślenia twórcom takich programów.

Tę lukę wykorzystywali inni odbiorcy pudeł

My, podobnie jak Tomek, zgłosiliśmy informację o błędzie do MasterLife Solutions i Kuchni Vikinga. Na początku grudnia Kuchnia Vikinga potwierdziła, że błąd został naprawiony. Chcieliśmy jednak wiedzieć więcej m.in. czy błąd mógł obejmować innych dostawców cateringu i zależało nam na bardziej technicznym wyjaśnieniu tego co się stało. Tu musimy przyznać, że CEO Dietly.pl Przemek Skokowski od początku bardzo rzeczowo z nami rozmawiał i obiecał też przesłać dokładniejsze wyjaśnienia. Dodał nawet, że kontakt ze strony Niebezpiecznik.pl jest “pewnego rodzaju wyróżnieniem”. (Gdybyście więc, Drodzy Czytelnicy, mieli jakieś informacje, dzięki którym moglibyśmy “wyróżnić” także inne firmy, to dajcie nam znać ;D)

16 grudnia dostaliśmy następującą wiadomość:

Błąd dotyczył aplikacji sprzedawanej B2B w modelu “white label” (w tym cateringu Kuchnia Vikinga, które korzysta z tego rozwiązania) oraz aplikacji Dietly. Wprawdzie błąd występował po stronie back-endu, ale realnie możliwość jego wywołania istniała wyłącznie w wersji przeglądarkowej (przez osobę, bez konkretnych kompetencji technicznych / która nie szukała na siłę).
Błąd wynikał z braku odpowiedniej izolacji transakcji, co doprowadziło do błędu typu Race Condition. Aplikacja zezwalała na współbieżny odczyt i modyfikację stanu punktów lojalnościowych, co umożliwiało ich wielokrotny zapis. Jak namierzyliśmy błąd to jego naprawa polegała na wdrożeniu pesymistycznego blokowania na poziomie bazy danych co sprawiło, że dziura została załatana i błąd już nie występuje.
W przypadku omawianego błędu:

• użytkownik miał możliwość anulowania wcześniej zamówionej dostawy – w efekcie czego naliczały mu się punkty lojalnościowe o równowartości kwoty tej dostawy, które mogły być wykorzystywane później przy składaniu kolejnych zamówień;
• wykorzystanie podatności polegało na kilkukrotnym (w przeważającej części przypadków dwukrotnym) anulowaniu tej samej dostawy – co powodowało podwójne naliczanie punktów lojalnościowych.

Pierwszą informację o błędzie mogącym mieć krytyczne znaczenie dla działania naszych aplikacji (bez wskazania jego szczegółów, a jedynie informacją, że “można składać zamówienia za darmo”) otrzymaliśmy  13.11.2025 r. Po tej informacji poprosiliśmy użytkownika zgłaszającego błąd o dodanie go do otwartego programu “Vulnerability Disclosure Program”. Jednocześnie tego samego dnia otrzymaliśmy sygnał od Kuchni Vikinga o wykrytej przez nich podatności/błędzie ze wskazaniem jego szczegółów. Dzięki tej informacji byliśmy w stanie szybko naprawić go już dzień później tj. 14.11.2025 r. Dodatkowo, po analizie skali problemu do Kuchni Vikinga (25.11.2025 r.) zostało wysłane zestawienie historycznej częstotliwości wykorzystania podatności. Skala błędu i jego występowania została podana do wiadomości redakcji niebezpiecznik.pl i wynika z niej, że były to wartości rzędu kilkunastu tysięcy złotych w tym dwóch użytkowników, którzy intencjonalnie korzystali z błędu i nabili straty wysokości ok. dwóch tysięcy złotych

Tu trzeba podkreślić, że Przemek Skokowski i firma Dietly wykazali się nie tylko sprawną reakcją, ale także bardzo dużą otwartością w wyjaśnianiu sprawy i jest to praktyka godna pochwały. Doceniamy. I odbieramy to jako pewnego rodzaju wyróżnienie ;)

White Label == Multiple Victims

Przemek przyznał też, że u innych firm korzystających z tej aplikacji mobilnej w modelu White Label (5 firm) ta luka również istniała. Ale tylko w przypadku jednej obecność tego błędu poskutkowała naliczeniem nienależnych środków na sumę kilkuset złotych.

Co miał z tego Tomek?

Tomek, który błąd zauważył i postanowił zgłosić został nagrodzony. Co prawda, dopiero po naszej interwencji, 16 grudnia. Nagroda? Kod rabatowy od Vikinga na kwotę 2000 zł. Doceniamy ten gest, bo trzeba przyznać, że było za co dziękować.

Zauważyłem błąd w apce — co robić, jak żyć?

Wszystkim z Was, którzy znają jakaś lukę lub dziurę polecamy dwa razy zastanowić się, zanim wykorzystacie ją do “wzbogacenia się” lub nieautoryzowanego dostępu do cudzych danych. Tzw. nieautoryzowane testy penetracyjne są do pewnego stopnia (są wyłączenia!) dopuszczone w polskim kodeksie karnym, ale prawda jest taka, że są to działania z niezerowym ryzykiem i reakcja na nie w dużej mierze zależy od dojrzałości właściciela infrastruktury, na której takie testy realizujecie. Łatwo jest popełnić błąd, który może Was kosztować pobudkę o 6 rano i stratę sprzętu, nie mówiąc już o tymczasowej utracie wolności.

Krótko mówiąc: widzisz błąd, to go zgłoś. I nie szantażuj (“szczegóły zdradzę jak otrzymam…”). Jeśli boisz się reakcji, to błąd możesz zgłosić przez nas. Po pierwsze, masz wtedy większą ochronę: jako prasa, mamy obowiązek pod rygorem odpowiedzialności prawnej, nie ujawniać Twojej tożsamości — obowiązuje nas tajemnica dziennikarska i nawet na przesłuchaniach odmawiamy podawania danych naszych informatorów, choć zawsze jesteśmy o to proszeni. Po drugie: nie da się ukryć, że na zgłoszenia błędów dokonywane przez nas firmy reagują trochę szybciej i sprawniej, nadając im “odpowiedni priorytet”. Więc, polecamy się!

PS. Jeśli chcecie nauczyć się jak profesjonalnie znajdować błędy i dziury w różnego rodzaju aplikacjach (mobilnych, webowych) to zapraszamy na nasze turbo-praktyczne szkolenie z Atakowania i Ochrony Aplikacji, gdzie przez 2 dni w praktycznym labie pokazujemy jak namierzać różne błędy i co robić, żeby nie pojawiły się w Waszych aplikacjach. Najbliższe terminy tego szkolenia poniżej. Zapisując się podajcie kod OBIAD, to dostaniecie 200 PLN zniżki (kod działa do 31.12.2025):