Błędy przy autoryzacji i obsłudze sesji w aplikacjach Johnson & Johnson

Badacz bezpieczeństwa o pseudonimie Eaton ujawnił podatności, które znalazł w 2 aplikacjach webowych firmy Johnson & Johnson. Pierwsza umożliwiała dostęp do danych niemal tysiąca studentów, a druga pozwalała na uzyskanie uprawnień administratora w wewnętrznym systemie.

TLDR:

• Badacz bezpieczeństwa Eaton ujawnił dwie podatności w aplikacjach Johnson & Johnson: systemie rekrutacji na kampusach oraz wewnętrznym systemie audytu ATMS.
• W Campus Recruiting możliwy był dostęp do danych niemal 1000 studentów z powodu błędnej implementacji uwierzytelniania.
• W ATMS odkrył brak autoryzacji w API oraz możliwość manipulacji logiką logowania i sesji po stronie klienta, co prowadziło do dostępu do danych pracowników i funkcji administracyjnych.
• W obu przypadkach główną przyczyną była zależność od logiki po stronie frontendu oraz niewystarczające egzekwowanie kontroli dostępu po stronie backendu. Obie aplikacje zostały już załatane.

Rekrutacja studentów

Firma Johnson & Johnson chętnie pojawiała się na targach pracy i wydarzeniach rekrutacyjnych organizowanych na uczelniach. Aby łatwiej zarządzać tymi wydarzeniami, zbudowali stronę “Campus Recruiting”.

Studenci otrzymują klucz danego wydarzenia i z jego użyciem wypełniają formularz rekrutacyjny:

Badacz postanowił przyjrzeć się źródłom strony, gdzie znalazł kilka podstron dla rekruterów:

Po przejściu do /recruiter został przekierowany na stronę logowania Microsoft SSO:

Konfiguracja uwierzytelniania była prosta. Biblioteka Microsoft Authentication Library (MSAL) zintegrowana z frontendem odpowiadała za sprawdzenie, czy pracownik jest zalogowany:

Eaton postanowił sprawdzić, czy uda się zmusić MSAL do uznania, że ktoś jest zalogowany. Pozwala to wykryć nieprawidłową obsługę tokenów API. Wystarczyło zmodyfikować kod, aby zawsze zwracał dane jednego konta, które jest “zalogowane”:

Menu dla rekruterów stało się dostępne. Można było zarządzać wydarzeniami, tworzyć nowe oraz przeglądać informacje wszystkich studentów. Panel rekrutera pozwalał również zobaczyć oceny i notatki przypisane konkretnym studentom, z którymi przeprowadzono rozmowę:

Co poszło nie tak? Token związany z uwierzytelnianiem przez MSAL w rzeczywistości nie był nigdzie używany. Zamiast tego do komunikacji z API AWS używano zapisanego na stałe klucza:

Problem dotknął danych niemal 1000 studentów. Strona Campus Recruiting została od tego czasu zaktualizowana i uwierzytelnianie za pomocą klucza API zastąpiono uwierzytelnianiem za pomocą tokenu Bearer (MSAL).

ATMS – zarządzanie audytami

Audit Tracking Management System (ATMS) to wewnętrzna aplikacja webowa pomagająca w zarządzaniu audytami w całym JnJ oraz w powiązanych z nim firmach:

• LifeScan
• Ethicon, Inc
• Biosense Webster
• ITS
• Depuy
• Ethicon-Endo
• Janssen
• Vistakon
• Acclarent
• JDx
• Sterilmed
• CLS
• JJSV
• Cerenovus
• EQ
• Janssen UK & Ireland
• RAD
• Abiomed Inc.
• CQ MedTech
• V-Wave

Dostanie się do tego systemu wymagało od Eatona nieco więcej pracy niż w przypadku Campus Recruiting. Natychmiast po wejściu na stronę następowało przekierowanie do strony logowania Microsoft SSO. Zanim to nastąpiło, pobierana była aplikacja ReactJS, której kod zawierał wiele interesujących API:

Badacz postanowił sprawdzić API getAllUsers, aby zobaczyć, co się stanie. Otrzymał listę 13,6 tys. pracowników JnJ:

Okazało się więc, że ten endpoint API działa bez uwierzytelnienia i wystarczyło zmodyfikować kod po stronie klienta aby uzyskać pełny dostęp do danych.

Podobnie jak Campus Recruiting strona używała MSAL do uwierzytelnienia użytkownika za pomocą Microsoft SSO, a następnie dokonywała zapisu w local storage:

Aby podszyć się pod uprawnionego użytkownika, Eaton musiał znaleźć nazwę użytkownika i WWID któregoś z pracowników JnJ korzystających z tego systemu. Natrafił na stronę pomocy, która zawierała dane administratora systemu:

Wystarczyło wyszukać nazwisko wśród użytkowników zwróconych przez API getAllUsers, które ujawniło potrzebne informacje i pozwoliło przygotować odpowiedni kod:

W efekcie zamiast przekierowania do logowania ustawiane są odpowiednie wartości w localStorage, tak jakby właśnie nastąpiło prawidłowe logowanie. Pierwsza próba zakończyła się jednak błędem:

Okazało się, że utworzenie sesji to po prostu żądanie GET do API, które zwraca GUID sesji i ustawia znacznik czasu w celu obliczenia, kiedy wygaśnie. Po odwiedzeniu tego endpointu zwrócił on prawidłowy identyfikator sesji:

Wystarczyło wstawić go ręcznie do localStorage i odświeżyć stronę, aby uzyskać dostęp do systemu.

Można było użyć listy rozwijanej do przełączania się między firmami:

Eaton, zalogowany jako administrator, miał też dostęp do specjalnego menu:

Eaton zgłaszał już podatności bezpieczeństwa do JnJ w 2024 roku. Firma podjęła wtedy natychmiastowe działania, a współpracę badacz opisał jako prawdziwą przyjemność. Jednak w przypadku dwóch pokazanych podatności, doświadczenie nie było już tak pozytywne.

Obie podatności zostały zgłoszone w październiku 2025 roku. Do końca miesiąca usunięto lukę w Campus Recruiting. Jednak w ATMS nic się nie zmieniło. Przez kolejne miesiące Eaton ponawiał kontakt aż do kwietnia 2026 roku, kiedy poprosił zaprzyjaźnionego dziennikarza o pomoc. Zgodnie z przewidywaniami jego e-mail do działu relacji z mediami JnJ ostatecznie skłonił firmę do naprawienia problemu.

W obu przypadkach wspólnym problemem była błędna implementacja mechanizmów uwierzytelniania i autoryzacji po stronie backendu. Logika ta była w dużej mierze realizowana po stronie klienta, a więc łatwo było nią manipulować. Z kolei API nie egzekwowało odpowiednich uprawnień. Stosowanie zapisanych na stałe kluczy sprawiło, że to nie serwer, a przeglądarka stała się “źródłem prawdy”.

Programistom polecamy zwracać uwagę na spójne wdrażanie mechanizmów uwierzytelniania i autoryzacji – zarówno w warstwie front-endu (np. wyświetlenie odpowiedniej treści/menu w zależności od uprawnień) jak i backendu (zwrócenie przez API konkretnych danych, lub błędu jeśli brak uprawnień).

Pełna oś czasu:

• 6 października 2025: zgłoszenie do programu zgłaszania podatności JnJ
• 16 października 2025: ponowny kontakt po braku odpowiedzi i braku działań
• 17 października 2025: pierwsza odpowiedź od JnJ z potwierdzeniem, że zajmą się ustaleniami
• 31 października 2025: naprawiona podatność Campus Recruiting; pytanie o ATMS
• 17 listopada 2025: ponowny kontakt po braku odpowiedzi i działań
• 22 grudnia 2025: ponowny kontakt po braku odpowiedzi i działań
• 22 stycznia 2026: ponowny kontakt po braku odpowiedzi i działań
• 8 kwietnia 2026: kontakt się z dziennikarzem
• 21 kwietnia 2026: podatność ATMS została ostatecznie naprawiona
• 24 czerwca 2026: publikacja badacza

Źródło: eaton-works.com

~Tymoteusz Jóźwiak