Wprowadzenie do problemu / definicja
W produkcie N-able Passportal wykryto poważną lukę bezpieczeństwa, która mogła umożliwić przejęcie tokenów dostępowych powiązanych z sejfem haseł. Problem dotyczył rozwiązania używanego przez dostawców usług IT oraz firmy z sektora MSP do przechowywania i zarządzania wrażliwymi poświadczeniami. W praktyce oznaczało to, że użytkownik mógł narazić zapisane dane uwierzytelniające już po odwiedzeniu złośliwej strony internetowej.
Skala ryzyka była szczególnie istotna ze względu na charakter samego produktu. Passportal obsługuje dane uprzywilejowane i często działa w środowiskach wieloklienckich, gdzie kompromitacja jednego konta lub operatora może otworzyć drogę do wielu organizacji jednocześnie.
W skrócie
Badacz bezpieczeństwa wykazał, że rozszerzenie przeglądarkowe Passportal akceptowało komunikaty bez odpowiedniej walidacji źródła. To pozwalało atakującemu wykorzystać mechanizm komunikacji przeglądarkowej do wyłudzenia tokenów sesyjnych.
- atak mógł prowadzić do przejęcia tokenów dostępowych i odświeżających,
- uzyskane tokeny umożliwiały enumerację oraz odczyt rekordów z sejfu,
- zagrożone były także kody TOTP wykorzystywane w MFA,
- producent wdrożył poprawkę ograniczającą bezpośredni wektor nadużycia,
- architektura rozwiązania nadal budzi pytania o model zaufania i bezpieczeństwo odszyfrowywania po stronie serwera.
Kontekst / historia
Passportal to narzędzie do zarządzania hasłami i dostępami, szeroko stosowane przez operatorów MSP oraz organizacje obsługujące wielu klientów. W jednym systemie mogą znajdować się dane administracyjne do środowisk wewnętrznych, usług chmurowych, urządzeń sieciowych, paneli zarządzania i kont klientów końcowych.
To właśnie koncentracja tak dużej liczby sekretów sprawia, że podatność w tego typu produkcie ma wyjątkowo wysoką wartość operacyjną dla napastników. W modelu MSP przejęcie jednego podmiotu może oznaczać dostęp do dziesiątek lub setek odrębnych środowisk. Dlatego incydenty dotyczące menedżerów haseł używanych przez operatorów usług zarządzanych mają znaczenie nie tylko lokalne, ale również systemowe.
Analiza techniczna
Istota problemu wynikała z działania rozszerzenia przeglądarkowego oraz sposobu obsługi materiału uwierzytelniającego przez usługę. W bezpieczniejszym modelu menedżera haseł najważniejsze operacje kryptograficzne odbywają się lokalnie na urządzeniu użytkownika, a klucze pochodne nie opuszczają stacji roboczej. W omawianym przypadku architektura opierała się na wykorzystaniu tokenów, które umożliwiały odzyskanie danych z sejfu.
Kluczową słabością był brak odpowiedniej kontroli komunikatów przychodzących do rozszerzenia. Mechanizm komunikacji typu postMessage akceptował wiadomości bez wystarczającej weryfikacji ich pochodzenia. Złośliwa strona, reklama lub osadzony komponent mogły więc wysłać spreparowane żądanie, a rozszerzenie odpowiadało ujawnieniem danych sesyjnych.
Po przejęciu tokenu dostępowego atakujący mógł pobierać rekordy z sejfu i odzyskiwać zapisane poświadczenia. Jeszcze groźniejszy był token odświeżający, który pozwalał utrzymać dostęp także po wygaśnięciu krótkotrwałej sesji. W efekcie ryzyko nie kończyło się na jednorazowym wycieku, lecz mogło przerodzić się w długotrwałą kompromitację.
N-able wdrożył poprawkę polegającą na sprawdzaniu pochodzenia żądań kierowanych do rozszerzenia. Taka zmiana ogranicza możliwość pozyskania tokenów przez dowolną stronę WWW. Nie usuwa jednak szerszej dyskusji o bezpieczeństwie modelu, w którym odszyfrowywanie danych pozostaje zależne od infrastruktury usługodawcy i ochrony sesji.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją luki była możliwość pełnej kompromitacji sejfu haseł. Napastnik mógł uzyskać dostęp do poświadczeń użytkowników i administratorów, danych klientów, kodów TOTP oraz materiału pozwalającego utrzymać trwały dostęp do usługi.
W środowiskach MSP skutki takiego incydentu są szczególnie rozległe. Jedno naruszenie może przełożyć się na dostęp do wielu tenantów, systemów RMM, poczty, VPN, usług SaaS i infrastruktury zarządzanej. Taki scenariusz zwiększa ryzyko ataków łańcucha dostaw, ransomware, eskalacji uprawnień i ruchu bocznego pomiędzy organizacjami.
Dodatkowe obawy budzi sama architektura rozwiązania. Nawet po usunięciu konkretnej podatności pozostaje pytanie o odporność na inne klasy ataków, takie jak przejęcie sesji, nadużycia API czy kompromitacja elementów pośredniczących. Z perspektywy obrońcy oznacza to, że sam status poprawki nie powinien kończyć analizy ryzyka.
Rekomendacje
Organizacje korzystające z Passportal lub podobnych rozwiązań powinny potraktować ten przypadek jako sygnał do przeglądu zarówno konfiguracji operacyjnej, jak i założeń architektonicznych.
- zweryfikować wersje rozszerzeń przeglądarkowych i potwierdzić wdrożenie poprawek na wszystkich stacjach roboczych,
- przeanalizować aktywne sesje i w razie potrzeby unieważnić tokeny dostępowe oraz odświeżające,
- przeprowadzić rotację haseł, sekretów aplikacyjnych i danych TOTP przechowywanych w sejfie,
- zbadać logi pod kątem masowej enumeracji wpisów, nietypowych żądań i anomalii sesyjnych,
- ograniczyć liczbę sekretów uprzywilejowanych przechowywanych w jednym miejscu,
- stosować zasadę najmniejszych uprawnień oraz rozdzielać konta administracyjne od kont codziennego użytku,
- przy wyborze nowych narzędzi preferować architekturę z pełnym szyfrowaniem end-to-end i lokalnym odszyfrowywaniem danych.
Podsumowanie
Luka w N-able Passportal pokazała, jak niebezpieczne mogą być błędy w rozszerzeniach przeglądarkowych obsługujących dane uprzywilejowane. W tym przypadku przejęcie tokenów mogło prowadzić do pełnej kompromitacji sejfu haseł, a znaczenie incydentu rosło wraz z wykorzystaniem produktu w środowiskach MSP i modelu wieloklienckim.
Choć producent załatał bezpośredni wektor ataku, sprawa zwraca uwagę na szerszy problem projektowania menedżerów haseł i granic zaufania pomiędzy klientem, rozszerzeniem oraz backendem dostawcy. Dla zespołów bezpieczeństwa najważniejsza lekcja pozostaje niezmienna: należy oceniać nie tylko pojedyncze błędy, ale również cały model kryptograficzny i skutki ewentualnej kompromitacji sesji.
Źródła
- Dark Reading — N-able Bug Exposes Password Vault Master Keys — https://www.darkreading.com/vulnerabilities-threats/n-able-bug-password-vault-master-keys
- N-able — Passportal — https://www.n-able.com/products/passportal
- SearchSecurity — End-to-end encryption (E2EE) definition — https://www.techtarget.com/searchsecurity/definition/end-to-end-encryption-E2EE