Aplikacja wysyła push z cudzymi adresami e-mail: przypadek Sticker Hub i bezpieczeństwo backendu powiadomień

22 lipca 2026 r. użytkownicy StickerHub zaczęli dostawać serię nietypowych powiadomień push. Część komunikatów sugerowała, że dane użytkowników zostały sprzedane, inne próbowały nakłaniać odbiorców do pozostania w aplikacji albo kierowały ich do zewnętrznej strony. Problem nie polegał jednak wyłącznie na tym, że ktoś wysłał kilka kompromitujących wiadomości. Incydent pokazał coś poważniejszego: system powiadomień może stać się kanałem wycieku danych i phishingu, jeśli backend traktuje go jak niewinną funkcję marketingową zamiast elementu infrastruktury bezpieczeństwa.

Według późniejszej aktualizacji dotyczącej incydentu nieautoryzowana osoba uzyskała dostęp do mechanizmu odpowiedzialnego za wysyłanie powiadomień i komunikatów w aplikacji. W toku dochodzenia potwierdzono również ujawnienie części informacji związanych z kontami, w tym adresów e-mail, nazw użytkowników StickerHub, podstawowych metryk konta oraz wybranych parametrów technicznych, takich jak ustawienia języka, wersja aplikacji czy identyfikatory urządzenia. Nie potwierdzono natomiast ujawnienia haseł do kont Apple i Google, danych kart płatniczych, informacji finansowych, zdjęć ani prywatnych plików.

To rozróżnienie jest ważne. Adres e-mail nie jest „niewrażliwą daną”, którą można zignorować tylko dlatego, że wyciek nie obejmuje numeru karty. Adres e-mail połączony z nazwą użytkownika i informacjami technicznymi daje napastnikowi materiał do bardzo wiarygodnego phishingu. A jeśli taki phishing przychodzi jeszcze oficjalnym kanałem push aplikacji, jego skuteczność rośnie.

Push nie jest tylko komunikatem. To uprzywilejowany kanał dostępu do użytkownika

W wielu aplikacjach system powiadomień powstaje na końcu projektu. Backend zapisuje token urządzenia, administrator albo system automatyczny wybiera grupę odbiorców, wpisuje tekst, opcjonalnie dodaje adres URL i wysyła kampanię przez usługę typu Firebase Cloud Messaging lub Apple Push Notification service. Technicznie proste. Bezpieczeństwo bywa więc potraktowane drugorzędnie.

To błąd.

Powiadomienie push ma kilka właściwości, których zwykły e-mail nie posiada. Pojawia się bezpośrednio na ekranie telefonu, używa nazwy i ikony zainstalowanej aplikacji, a użytkownik z reguły zakłada, że pochodzi od jej operatora. Jeżeli atakujący przejmie panel albo API wysyłające push, dostaje praktycznie gotową infrastrukturę do podszywania się pod zaufaną markę.

W przypadku StickerHub nieautoryzowane wiadomości były wysyłane przez kanał kojarzony przez użytkowników z prawdziwą aplikacją. Pierwsze komunikaty pojawiały się 22 lipca w przedziale około 16:00-20:00 czasu wschodniego USA, czyli mniej więcej 22:00-02:00 czasu polskiego. Część użytkowników otrzymywała kolejne powiadomienia nawet po zignorowaniu wcześniejszych.

To ujawnia kilka problemów, które przy audycie backendu powiadomień sprawdziłbym w pierwszej kolejności:

• kto fizycznie może wysłać wiadomość do wszystkich użytkowników, a nie tylko do kont testowych;
• czy dostęp wymaga MFA i czy administratorzy korzystają z indywidualnych kont zamiast wspólnych danych logowania;
• czy kampania obejmująca całą bazę wymaga akceptacji drugiej osoby;
• czy link w pushu może prowadzić do dowolnej domeny;
• czy system posiada limit liczby wiadomości wysłanych w krótkim czasie;
• czy każde wysłanie powiadomienia jest zapisane w nieusuwalnym dzienniku audytowym;
• czy token lub klucz API do wysyłki jest oddzielony od pozostałego backendu.

Najbardziej niebezpieczny model to panel, w którym jedna osoba po zalogowaniu może wpisać dowolny tekst, wkleić dowolny URL, zaznaczyć „wszyscy użytkownicy” i kliknąć „Send”. Taki panel nie jest narzędziem marketingowym. To w praktyce konsola umożliwiająca masową komunikację w imieniu firmy.

Dobrze zaprojektowany system powinien traktować wysyłkę globalną jak operację wysokiego ryzyka. Jeżeli wiadomość ma trafić np. do więcej niż 10-20 proc. aktywnych urządzeń, można wymagać drugiej autoryzacji. Jeżeli zawiera URL spoza listy zatwierdzonych domen, wysyłkę należy zablokować automatycznie. To mniej wygodne dla marketingu, ale właśnie ten dodatkowy opór chroni przed sytuacją, w której jedno przejęte konto zamienia się w megafon atakującego.

Dlaczego pojawienie się cudzych e-maili oznacza problem większy niż kompromitacja panelu

Sama możliwość wysłania nieautoryzowanego pushu nie oznacza jeszcze, że napastnik ma dostęp do bazy użytkowników. System może pozwalać na wysłanie identycznego komunikatu do miliona tokenów urządzeń bez ujawniania administratorowi ani jednego adresu e-mail.

Sytuacja zmienia się, gdy w incydencie pojawiają się rzeczywiste informacje przypisane do konkretnych kont.

Jeżeli system powiadomień potrafi pobierać e-mail odbiorcy, nazwę użytkownika albo inne pola profilu i wstawiać je dynamicznie do treści wiadomości, trzeba sprawdzić architekturę personalizacji. Typowy backend ma wtedy dostęp do rekordów w rodzaju:

user_id → email → username → push_token → language → app_version → device_id

Nie musi to oznaczać pełnego dostępu do głównej bazy. Wystarczy źle zabezpieczony endpoint, eksport danych, cache, panel analityczny albo mikroserwis odpowiedzialny za segmentację kampanii.

To jest właśnie jeden z częstszych błędów architektonicznych: serwis powiadomień otrzymuje więcej danych, niż faktycznie potrzebuje.

Do wysłania komunikatu „Masz nową wiadomość” potrzebny jest zwykle identyfikator użytkownika i token push. E-mail nie jest wymagany. Nazwisko nie jest wymagane. Numer telefonu nie jest wymagany. Jeżeli wszystkie te pola trafiają do serwisu „na wszelki wypadek”, firma zwiększa powierzchnię ataku bez żadnej korzyści dla użytkownika.

Po takim incydencie kolejność prac powinna być konkretna.

Najpierw trzeba ustalić dokładną ścieżkę dostępu: czy napastnik przejął konto operatora, sekret API, sesję administratora, usługę zewnętrzną czy lukę pozwalającą ominąć autoryzację. Następnie należy sprawdzić logi zapytań i odpowiedzieć na znacznie ważniejsze pytanie: jakie rekordy zostały faktycznie odczytane albo wyeksportowane.

Dopiero później ma sens przebudowa interfejsu czy dodawanie kolejnych ekranów ostrzegawczych.

W praktyce dobry model izolacji wygląda tak:

główna baza użytkowników → usługa segmentacji → minimalny zestaw ID → serwis push → FCM/APNs

Serwis push nie powinien dostawać pełnego profilu. Jeżeli potrzebny jest język komunikatu, powinien otrzymać kod pl, en czy de, a nie cały rekord konta. Jeżeli potrzebna jest personalizacja nazwą użytkownika, warto rozważyć, czy korzyść z tekstu „Cześć, Jan123” naprawdę uzasadnia przekazywanie tej informacji do dodatkowego systemu.

Jest też druga rzecz, która często irytuje zespoły operacyjne: restrykcyjne uprawnienia spowalniają pracę. Osoba z marketingu nie może już sama uruchomić dowolnej kampanii w trzy minuty. Trzeba zatwierdzić domenę, czasem poprosić drugą osobę o akceptację, a dostęp produkcyjny może wygasać po kilku godzinach. To niedogodność celowa. System bezpieczeństwa, który nigdy nikomu nie przeszkadza, zazwyczaj niewiele chroni.

Po incydencie liczy się nie komunikat PR, lecz ograniczenie dostępu i obowiązki wobec użytkowników

Z punktu widzenia polskiej firmy podobny przypadek natychmiast wchodzi również na obszar RODO. Adres e-mail przypisany do konta użytkownika jest daną osobową. Jeżeli dochodzi do nieuprawnionego ujawnienia albo dostępu, mamy do czynienia z naruszeniem ochrony danych osobowych.

Administrator danych musi wtedy ocenić ryzyko dla praw i wolności osób, których dane dotyczą. Jeżeli naruszenie może powodować takie ryzyko, zgłoszenie do właściwego organu nadzorczego powinno nastąpić — o ile jest to wykonalne — nie później niż w ciągu 72 godzin od stwierdzenia naruszenia. W Polsce organem właściwym jest Prezes Urzędu Ochrony Danych Osobowych.

Jeżeli ryzyko dla osób jest wysokie, dochodzi dodatkowo obowiązek przekazania informacji samym zainteresowanym. Nie wystarczy komunikat typu „prowadzimy analizę i bezpieczeństwo użytkowników jest dla nas priorytetem”. Użytkownik potrzebuje odpowiedzi na konkretne pytania:

• jakie jego dane zostały ujawnione;
• kiedy doszło do zdarzenia;
• jaki kanał został przejęty;
• jakie działania firma już wykonała;
• czy powinien zmienić hasło;
• czy powinien uważać na wiadomości wykorzystujące jego login lub e-mail;
• gdzie zgłaszać podejrzane wiadomości.

Samo ujawnienie adresu e-mail nie oznacza automatycznie konieczności zmiany wszystkich haseł. Jeżeli hasła nie znalazły się w naruszonym systemie i nie ma śladów przejęcia mechanizmu logowania, masowa zmiana haseł może być niepotrzebna. Inaczej wygląda sytuacja użytkownika, który po otrzymaniu fałszywego pushu przeszedł na podstawioną stronę i wpisał tam hasło. W takim przypadku hasło trzeba zmienić natychmiast, szczególnie jeżeli było używane także w innych usługach.

Jeżeli podano dane karty, trzeba skontaktować się z bankiem lub wydawcą karty, a nie czekać na zakończenie wewnętrznego dochodzenia operatora aplikacji.

Firma po stronie technicznej powinna natomiast wykonać kilka działań w ustalonej kolejności. Najpierw unieważnić wszystkie potencjalnie przejęte sesje, tokeny i klucze dostępowe. Następnie ograniczyć uprawnienia kont związanych z systemem push, przejrzeć logi i dopiero po potwierdzeniu źródła ataku wygenerować nowe sekrety. Rotowanie klucza bez usunięcia drogi, którą atakujący go zdobył, daje tylko chwilową poprawę.

Kolejny priorytet to zablokowanie możliwości kierowania użytkowników z pushy na niezatwierdzone domeny. Najprostsza praktyczna reguła to allowlista domen. Produkcyjny system powiadomień powinien akceptować wyłącznie adresy należące do operatora aplikacji lub wcześniej zatwierdzonych partnerów.

Warto także oddzielić trzy role: przygotowanie kampanii, jej zatwierdzenie i techniczne uruchomienie. Przy krytycznych komunikatach nie powinny należeć do jednego konta.

Dla zespołu bezpieczeństwa użyteczny jest jeszcze jeden test: spróbować odpowiedzieć na pytanie „kto wysłał tę wiadomość?” w mniej niż pięć minut. Jeżeli trzeba przekopywać kilka serwerów, pytać dostawcę pushy i ręcznie porównywać godziny, telemetria jest za słaba. Log powinien zawierać identyfikator operatora lub usługi, czas, segment odbiorców, treść kampanii, link, liczbę urządzeń, wynik autoryzacji oraz identyfikator wdrożenia lub żądania API.

Po takim incydencie warto również wykonać zewnętrzny test penetracyjny, ale nie powinien być pierwszym ruchem. Pentest wykonany przed zamknięciem znanej ścieżki dostępu pochłonie czas na odkrywanie błędu, o którym zespół już wie.

Więcej informacji na: https://sajo.pl

FAQ

Czy sam fakt otrzymania złośliwego powiadomienia push oznacza zainfekowanie telefonu?
Nie. Samo wyświetlenie pushu nie instaluje malware. Ryzyko rośnie po otwarciu zewnętrznego linku, pobraniu pliku, instalacji profilu lub aplikacji albo wpisaniu danych logowania na podstawionej stronie.

Czy po wycieku adresu e-mail trzeba zmienić hasło?
Nie automatycznie. Jeżeli wyciek obejmuje tylko e-mail i nazwę użytkownika, najważniejsze jest zwiększenie czujności na phishing. Hasło należy zmienić od razu, jeśli zostało wpisane na stronie otwartej z podejrzanego powiadomienia albo jeśli istnieją przesłanki, że system uwierzytelniania również został naruszony.

Czy system push powinien mieć dostęp do adresów e-mail użytkowników?
W większości przypadków nie. Do dostarczenia pushu potrzebny jest token urządzenia lub identyfikator powiązany z tokenem. Jeżeli serwis wysyłkowy otrzymuje dodatkowo e-mail, telefon i pełny profil, trzeba wykazać konkretną potrzebę biznesową dla każdego z tych pól.

Czy wyłączenie powiadomień rozwiązuje problem?
Chroni przed kolejnymi złośliwymi pushami, ale nie usuwa przyczyny. Jeśli dane zostały wcześniej ujawnione, pozostają ujawnione. Po stronie operatora konieczne jest zamknięcie przejętego dostępu, rotacja sekretów, analiza logów oraz ograniczenie danych dostępnych dla serwisu powiadomień.

Co powinien zrobić użytkownik, który kliknął fałszywy link?
Jeśli tylko otworzył stronę i niczego nie wpisał ani nie pobrał, powinien ją zamknąć i nie wracać do niej. Jeżeli podał hasło, powinien je natychmiast zmienić wszędzie tam, gdzie było powtórzone, oraz włączyć MFA. Jeżeli podał dane płatnicze, powinien skontaktować się z bankiem.

Jaki błąd należy usunąć jako pierwszy po takim incydencie?
Najpierw trzeba odebrać napastnikowi możliwość dalszego działania: unieważnić podejrzane sesje i klucze, zablokować przejęte konto lub endpoint i odciąć możliwość masowej wysyłki. Dopiero potem analizować zakres danych oraz przebudowywać panel. Jeśli system nadal pozwala nieautoryzowanej osobie wysłać push do wszystkich użytkowników, każda minuta poświęcona na kosmetyczne poprawki jest minutą zmarnowaną.