Jak błąd w Lenovo ID dał hakerom dostęp do około 5000 kont Dropbox

Dropbox poinformował, że hakerzy uzyskali dostęp do około 5000 kont za pośrednictwem luki związanej z Lenovo ID — zewnętrzną usługą jednokrotnego logowania (SSO). Nieuprawniony dostęp trwał od 4 do 21 sierpnia 2026 roku. Według informacji cytowanych przez media pliki przeglądano lub pobierano w mniej niż jednej trzeciej zaatakowanych kont. 146

Incydent był szczególnie istotny, ponieważ napastnicy najwyraźniej nie potrzebowali ani haseł do Dropboxa, ani dostępu do skrzynek e-mail ofiar. Wykorzystali sposób, w jaki systemy tożsamości obu firm traktowały adres e-mail jako dowód prawa do konta.

Jak doszło do przejęcia kont

Łańcuch ataku wyglądał następująco:

1. Napastnik rejestrował Lenovo ID, wpisując adres e-mail należący do innej osoby.
2. Błąd w procesie weryfikacji adresu e-mail firmy Lenovo sprawiał, że taka tożsamość mogła wyglądać na prawidłowo potwierdzoną, mimo że napastnik nie kontrolował skrzynki.
3. Starsza integracja SSO Dropboxa porównywała adres e-mail przekazany w komunikacie tożsamości Lenovo z istniejącym kontem Dropbox i przyznawała dostęp bez żądania dotychczasowego hasła do tego konta. 3511

Atakujący nie musieli więc łamać systemu haseł Dropboxa ani omijać zabezpieczeń poczty. Wykorzystali relację zaufania między dostawcą tożsamości — Lenovo ID — a Dropboxem, czyli usługą, która ufała przedstawionym przez niego informacjom.

Dlaczego uwierzytelnianie wieloskładnikowe miało znaczenie

Zaatakowane konta były połączone z Lenovo ID, ale nie miały włączonego uwierzytelniania wieloskładnikowego Dropboxa. 11012

W federacyjnym procesie logowania udane uwierzytelnienie u zewnętrznego dostawcy może ustanowić sesję także w usłudze, do której użytkownik się loguje. MFA Dropboxa dodałoby po tym etapie jeszcze jeden krok kontrolowany przez Dropbox. Fałszywe Lenovo ID nie wystarczyłoby wtedy do uzyskania dostępu.

Nie oznacza to, że napastnicy ominęli samo MFA. Incydent dotknął przede wszystkim kont bez włączonej weryfikacji dwuetapowej. 1015

Jakie dane mogły zostać ujawnione

Dropbox przekazał, że napastnicy przeglądali i pobierali treści przechowywane na zaatakowanych kontach. Z publicznych informacji wynika, że pliki uzyskano z mniej niż jednej trzeciej spośród około 5000 przejętych kont. 145

Dostępne raporty nie wskazują jednego rodzaju plików, łącznego rozmiaru pobranych danych ani wspólnego poziomu ich wrażliwości. Niektórzy użytkownicy otrzymali informację, że logi Dropboxa potwierdzają nieuprawnione logowanie, ale nie ma dowodów na przeglądanie lub pobieranie ich plików. 2

Co zauważyli użytkownicy i badacze

Część poszkodowanych użytkowników odkryła nieznane Lenovo ID powiązane z ich adresami e-mail. Badacz bezpieczeństwa Yoni Levy opublikował kopię powiadomienia Dropboxa opisującego nieuprawniony dostęp w okresie od 4 do 21 sierpnia oraz wskazującego na problem z logowaniem SSO Lenovo. 23

Raporty wspominały również o aktywności logowania powiązanej z Dublinem. Jest to zgodne ze scenariuszem, w którym fałszywe konta u dostawcy tożsamości służyły jako punkt wejścia. Sam fakt pojawienia się Dublina w logach nie dowodzi jednak, gdzie znajdował się każdy z napastników ani że wszystkie konta przejęto dokładnie w ten sam sposób.

Kiedy Dropbox powiadomił użytkowników i organy nadzorcze

Dropbox zaczął informować poszkodowanych użytkowników około 31 sierpnia i 1 września, po wykryciu nieuprawnionego dostępu. Firma przekazała również, że zawiadomiła organy ochrony danych. 346

Według opisów reakcji Dropbox zakończył aktywne sesje, usunął lub rozłączył powiązania z kontami Lenovo, zalecił zmianę haseł i włączenie weryfikacji dwuetapowej, a także ograniczył lub dodatkowo zabezpieczył wadliwą ścieżkę logowania. 101230

Odpowiedzialność Dropboxa i Lenovo

Nie był to typowy przypadek włamania wyłącznie do jednej firmy. Incydent wynikał z awarii systemu współdzielonego przez oba przedsiębiorstwa.

• Problem po stronie Lenovo: starszy mechanizm tożsamości najwyraźniej pozwalał utworzyć Lenovo ID z adresem e-mail, nad którym rejestrujący nie miał kontroli. Zabrakło wystarczającego dowodu własności adresu. 3512
• Problem po stronie Dropboxa: usługa uznawała zewnętrzne potwierdzenie Lenovo za wystarczające do połączenia z istniejącym kontem Dropbox, bez dodatkowego potwierdzenia dotychczasowym hasłem, ponownego uwierzytelnienia lub bezpieczniejszej procedury łączenia kont. 3911
• Reakcja obu firm: Lenovo opisało sprawę jako problem dotyczący starszej integracji i poinformowało o usunięciu odpowiedniej luki w weryfikacji. Dropbox przekazał, że wykrył i naprawił problem, zakończył sesje, zmienił działanie integracji oraz powiadomił użytkowników i organy nadzorcze. 101214

To rozróżnienie jest ważne. Błąd w weryfikacji Lenovo stworzył fałszywe potwierdzenie tożsamości, ale to logika Dropboxa dotycząca łączenia kont zdecydowała, czy takie potwierdzenie wystarczy do odblokowania istniejącego konta w chmurze.

Co stało się z akcjami Dropboxa

Po ujawnieniu incydentu akcje Dropboxa spadły w handlu posesyjnym, ale dokładna skala ruchu jest niejasna.

W raporcie Reutersa cytowanym przez kilka serwisów mowa o spadku o około 2,4 proc., natomiast Investing.com podał zniżkę o 1,8 proc. w handlu po zamknięciu sesji. 69 Inny materiał informował o spadku przekraczającym 6 proc. 8 Dostępne dane nie potwierdzają jednak konkretnej wartości 6,6 proc. — mogła ona odnosić się do innego punktu odniesienia lub innej części sesji.

Lekcja dla systemów federacyjnego logowania

Adres e-mail jest identyfikatorem. Nie stanowi automatycznie dowodu, że osoba, która go podaje, kontroluje skrzynkę albo ma prawo do powiązanego z nim konta.

Logowanie federacyjne upraszcza korzystanie z usług, ponieważ pozwala uwierzytelniać się za pośrednictwem innego dostawcy. Wygoda tworzy jednak ryzyko, gdy usługa:

• przyjmuje deklarację dostawcy tożsamości o adresie e-mail bez niezależnej weryfikacji;
• automatycznie łączy nową zewnętrzną tożsamość ze starym kontem;
• pomija dotychczasowe hasło, wyzwanie MFA lub zweryfikowany kanał odzyskiwania dostępu;
• traktuje zmianę powiązań konta jak zwykłe logowanie, zamiast jak operację wysokiego ryzyka.

Bezpieczniejszy projekt wymagałby wyraźnego potwierdzenia od właściciela istniejącego konta przed dodaniem nowego dostawcy tożsamości. Może to oznaczać ponowne uwierzytelnienie, użycie zweryfikowanego kanału odzyskiwania albo zastosowanie odpornego na phishing mechanizmu uwierzytelniania.

Przypadek Dropboxa pokazuje, że relacje zaufania między dostawcami tożsamości i usługami wymagają takiej samej uwagi jak hasła. Luka w jednym systemie może stać się drogą dostępu do konta w zupełnie innej usłudze.