Asystenci spotkań oparci na AI stają się normalnymi uczestnikami rozmów biznesowych, briefingów rządowych, spotkań z klientami, rozmów rekrutacyjnych i wewnętrznych sesji strategicznych. Dołączają do rozmów, nagrywają dźwięk i obraz, generują transkrypcje, podsumowują decyzje i przechowują przeszukiwalną historię spotkań.
Ta wygoda niesie ze sobą poważne ryzyko: jeśli mechanizm autoryzacji w zapleczu (backendzie) takiego narzędzia zawiedzie, może ono stać się katalogiem prywatnych rozmów.
Niedawne ujawnienie dotyczące tl;dv, asystenta spotkań opartego na AI, pokazuje dokładnie, jak groźne może to być. Według Dark Reading błędna konfiguracja Google Firebase pozwalała uwierzytelnionym użytkownikom tl;dv przeszukiwać informacje o spotkaniach należących do innych użytkowników i potencjalnie dołączać do rozmów, na które nigdy nie zostali zaproszeni.
Co się stało
Badacz bezpieczeństwa BobDaHacker odkrył, że użytkownikom tl;dv przypisywano identyfikator sesji, który zapewniał niezwykle szeroki dostęp do środowiska backendowego aplikacji opartego na Google Firebase / Cloud Firestore. Większość wrażliwych kolekcji, takich jak transkrypcje i nagrania, miała podobno wdrożoną izolację dzierżaw (tenantów). Słabym punktem była kolekcja meetings, w której reguły autoryzacji nie ograniczały prawidłowo użytkowników do rekordów ich własnej organizacji.
Oznaczało to, że ważne konto tl;dv mogło odpytywać rekordy spotkań w całym serwisie.
Ujawnione rekordy nie zawierały automatycznie każdej transkrypcji ani nagrania. Mogły jednak odsłaniać bardzo wrażliwe metadane, w tym adresy e-mail twórców spotkań, dostawcę konferencji, znaczniki czasu, status nagrywania i identyfikatory konferencji, które można było wykorzystać do odnalezienia trwających lub zakończonych spotkań.
To klasyczny błąd autoryzacji: system sprawdzał, czy użytkownik jest zalogowany, ale nie egzekwował tego, do których rekordów wolno mu mieć dostęp.
Dlaczego to takie poważne
Metadane spotkań nie są niegroźne.
Identyfikator konferencji, adres e-mail gospodarza, znacznik czasu i status nagrywania mogą zdradzić, kto się spotyka, kiedy, z jakiej platformy korzysta i czy rozmowa jest w toku. We wrażliwych środowiskach to może wystarczyć do szpiegostwa, socjotechniki, włamania na spotkanie lub ukierunkowanego phishingu.
Według Dark Reading badacz był w stanie zidentyfikować trwające rozmowy i dołączyć do niektórych spotkań, podając się za narzędzie AI do notatek. Część spotkań była publicznie otwarta, a w przypadku spotkań prywatnych uczestnik przypominający bota często był wpuszczany, gdy poprosił o dostęp.
Taka jest niewygodna rzeczywistość narzędzi AI do notatek: ludzie często przestają je kwestionować.
Gdy bot dołącza do spotkania, uczestnicy mogą zakładać, że zaprosił go ktoś inny.
Ujawnione rozmowy rządowe i korporacyjne
Skala ekspozycji była znacząca.
Odrębna analiza podsumowująca ustalenia BobDaHackera wskazała 181 874 rekordy spotkań dotyczące 84 312 użytkowników i 35 003 domen. Ujawnione domeny rządowe obejmowały podobno spotkania rządów z 23 krajów, w tym ze Stanów Zjednoczonych, Japonii, Brazylii, Ukrainy, Malezji, Kataru i Izraela.
Dark Reading podało także, że wśród rekordów znalazły się spotkania powiązane z dużymi korporacjami i uniwersytetami, m.in. HubSpot, Mitsui Fudosan, UC Berkeley i University of Tokyo.
W mniejszej próbce obejmującej ponad 27 000 identyfikatorów spotkań badacz stwierdził, że w otwartym Internecie znajdowało się ponad 1000 ujawnionych adresów e-mail zaproszonych osób oraz transkrypcji rozmów.
To sprawia, że problem przestaje być błędem konfiguracji backendu, a staje się realnym problemem z poufnością.
Pierwotna przyczyna: Broken Object-Level Authorization
Luka nie wynikała ze skomplikowanego exploita.
Przyczyną był brak izolacji dzierżaw w jednej kolekcji backendu.
W aplikacjach opartych na Firebase i Cloud Firestore reguły bezpieczeństwa są kluczowe, ponieważ aplikacje klienckie mogą komunikować się bezpośrednio z danymi w backendzie. Jeśli reguły są poprawnie zakresowane, użytkownicy mają dostęp tylko do rekordów należących do ich własnego konta lub organizacji. Jeśli jedna kolekcja zostanie pominięta, może stać się odczytywalna dla każdego uwierzytelnionego użytkownika.
Zespoły bezpieczeństwa często nazywają tę klasę problemów Broken Object-Level Authorization, czyli BOLA.
Mówiąc prosto: to, że wiemy, kim jest użytkownik, nie oznacza automatycznie, że powinien widzieć każdy obiekt, o który poprosi.
Uwierzytelnianie odpowiada na pytanie: „Kim jesteś?”
Autoryzacja odpowiada na pytanie: „Czy masz prawo uzyskać dostęp do tego konkretnego rekordu?”
To właśnie drugie sprawdzenie zawiodło.
Dlaczego narzędzia AI do notatek to rozwiązania wysokiego ryzyka
Narzędzia AI do notatek nie są zwykłymi aplikacjami SaaS.
Znajdują się w samym środku rozmów, podczas których omawia się lejki sprzedażowe, projekty rządowe, decyzje rekrutacyjne, strategię prawną, umowy z klientami, plany produktowe, incydenty bezpieczeństwa i informacje finansowe.
Wiele z nich łączy się też z kalendarzami, kontaktami, platformami konferencyjnymi, transkrypcjami, nagraniami i wewnętrzną wyszukiwarką. Dark Reading zauważa, że takie boty mogą stać się cichymi uczestnikami z głębokim dostępem do warstwy komunikacyjnej organizacji.
Oznacza to, że poprzeczka bezpieczeństwa powinna być wysoko.
Awaria narzędzia AI do notatek nie powoduje wycieku wyłącznie danych aplikacji. Może ujawnić kontekst prywatnych decyzji organizacji.
Czynnik ludzki: ślepota na boty
Ten incydent uwidacznia również problem społeczny.
Ludzie przywykli do widoku botów AI na spotkaniach. Lista uczestników z kilkoma narzędziami do notatek nie wydaje się już niczym niezwykłym. Czasami boty dołączają w imieniu nieobecnych użytkowników. Czasami użytkownicy zapominają, że włączyli automatyczne nagrywanie. Czasami organizacje dopuszczają zewnętrzne boty bez jasnego procesu zatwierdzania.
To tworzy „ślepotę na boty”.
Atakujący mogą to wykorzystać, dołączając do spotkań z nazwami lub awatarami przypominającymi popularne narzędzia AI do notatek. Jeśli uczestnicy nie zakwestionują takiego bota, obca osoba może po cichu podsłuchiwać.
Techniczna luka ujawniła katalog spotkań, ale ludzka skłonność do akceptowania nieznanych botów zwiększyła praktyczne ryzyko.
Co powinny zrobić organizacje
Organizacje korzystające z narzędzi AI do notatek powinny traktować je jak wrażliwe systemy podmiotów trzecich, a nie wygodne gadżety.
Do ważnych działań należą:
- przegląd tego, które narzędzia AI do notatek są dozwolone na spotkaniach firmowych
- wyłączenie automatycznego dołączania botów, chyba że jest potrzebne
- wymaganie wyraźnej zgody, zanim boty będą mogły nagrywać
- ograniczenie zewnętrznych narzędzi AI do notatek na wrażliwych spotkaniach
- wprowadzenie obowiązkowych poczekalni dla uczestników zewnętrznych
- szkolenie pracowników, by kwestionowali nieznane boty
- domyślne ustawianie nagrań i transkrypcji jako prywatnych
- przegląd ustawień udostępniania transkrypcji i nagrań
- pytanie dostawców, gdzie egzekwowana jest autoryzacja dzierżaw
- pytanie dostawców, jak obsługiwane są zgłoszenia dotyczące bezpieczeństwa
- audyt integracji z kalendarzami, kontaktami i narzędziami konferencyjnymi
Najbezpieczniejsze ustawienie domyślne jest proste: wrażliwe spotkania nie powinny dopuszczać nieoczekiwanych botów AI.
Czego muszą się nauczyć dostawcy narzędzi AI do notatek
Izolacja dzierżaw musi być egzekwowana konsekwentnie w każdej kolekcji backendu, każdym API i każdej ścieżce udostępniania. Jedna pominięta reguła Firestore może ujawnić całą bazę klientów.
Dostawcy narzędzi AI do notatek powinni wdrożyć:
- ścisłe reguły autoryzacji zakresowane do dzierżawy
- zautomatyzowane testy dla każdej kolekcji bazy danych
- kontrole autoryzacji po stronie backendu, a nie tylko założenia po stronie klienta
- rejestrowanie prób zapytań między dzierżawami
- limity zapytań o rekordy spotkań
- przegląd bezpieczeństwa publicznych i wewnętrznych API
- szybkie przyjmowanie zgłoszeń o lukach i reagowanie na nie
- jasne procesy powiadamiania klientów
- domyślnie prywatne dane spotkań
- silniejsze mechanizmy kontroli publicznego udostępniania transkrypcji
Bezpieczeństwo nie może zależeć od tego, czy użytkownicy ustawią właściwą opcję prywatności post factum.
Podsumowanie
Przypadek tl;dv to ostrzeżenie przed ukrytym ryzykiem związanym z asystentami spotkań opartymi na AI.
Narzędzia te są użyteczne, ponieważ znajdują się blisko wrażliwych rozmów. Właśnie dlatego są niebezpieczne, gdy autoryzacja zawodzi.
Jedna błędna konfiguracja backendu sprawiła, że rekordy spotkań rządów, firm, uniwersytetów i innych organizacji mogły być odpytywane przez uwierzytelnionych użytkowników. W niektórych przypadkach te informacje można było wykorzystać do dołączenia do trwających rozmów lub odnalezienia ujawnionych transkrypcji.
Narzędzia AI do notatek są dziś częścią granicy bezpieczeństwa. Organizacje powinny zarządzać nimi jak uprzywilejowanymi narzędziami komunikacji, a dostawcy muszą udowodnić, że każde spotkanie, każda transkrypcja, każde nagranie i każdy rekord metadanych są izolowane już na poziomie projektu.
