Jak można było czytać listę połączeń klientów sieci Verizon

Evan Connelly zaprezentował odkrytą przez siebie podatność w aplikacji  Verizon Call Filter na urządzenia z systemem iOS. Co prawda problem dotyczy klientów tej amerykańskiej sieci GSM, jednak postanowiliśmy opisać błąd leżący u podstaw tej podatności, ponieważ z doświadczenia wiemy, że luki klasy IDOR (ang. Insecure Direct Object Reference) pojawiają się stosunkowo często.

Aplikacja Verizon Call Filter ma za zadanie ułatwić blokowanie podejrzanych połączeń przychodzących. Pozwala między innymi blokować niechciane połączenia, raportować numery jako uciążliwe i nie tylko. Umożliwia też między innymi sprawdzenie listy ostatnich połączeń przychodzących. 

W tym celu realizowane jest zapytanie do serwera www. Użytkownik uwierzytelnia się przy pomocy tokena JWT. W jego nagłówku znajduje się informacja o numerze telefonu klienta.

{
    "sub": "SIGNED_IN_USER_PHONE_NUMBER_HERE",
    "iat": "1740253712",
    "iss": "df88f1ed1dfd9a903e4c8dca7f00089e134c6c4e0a566cd565147ba1dadf78a6",
    "secret": "REDACTED",
    "alg": "ECDSA-256",
    "exp": "1740255512"
}

Listing 1. Ładunek tokenu JWT. Numer zalogowanego abonenta znajduje się w kluczu “sub” (źródło: https://evanconnelly.github.io/post/hacking-call-records/)

Oprócz tego, w zapytaniu znajduje się nagłówek X-Ceq-MDN, który służy do zdefiniowania numeru, dla którego ma zostać zwrócona historia połączeń. 

Okazuje się jednak, że pole X-Ceq-MDN nie jest weryfikowane pod kątem uprawnień użytkownika przedstawiającego się poprawnym tokenem JWT (tzn. takim, który został poprawnie podpisany). A to oznacza, że manipulując jedynie tym nagłówkiem, dowolny zalogowany użytkownik usługi Verizon Wireless, mógł uzyskać historię połączeń przychodzących dla innego klienta firmy Verizon. W najprostszej implementacji łatki, wystarczyłoby walidować X-Ceq-MDN z zawartością JWT (jeśli oczywiście użytkownik ma mieć dostęp tylko do historii jednego swojego numeru).

Tym trywialnym brakiem sprawdzenia, programiści otworzyli możliwość pozyskania całkiem znaczących informacji (wiadomo kto z kim się kontaktował) na temat abonentów. Problem został zgłoszony przez badacza w lutym tego roku. Operator potraktował sprawę poważnie i naprawił błąd, co zostało potwierdzone przez Evana podczas retestu.

Błędy bezpieczeństwa wynikające ze ślepego zaufania do wartości pochodzących od użytkownika są niestety wciąż popularnym wektorem ataku, podobnie jak niedostateczna weryfikacja uprawnień przy bezpośrednim dostępie do danych. W tym przypadku pomoże edukacja deweloperów oraz szczególny nacisk na sprawdzanie wartości, które pochodzą z niezaufanych źródeł. 

~Black Hat Logan