Как ошибка в Lenovo ID позволила взломать около 5 000 аккаунтов Dropbox

Что произошло с аккаунтами Dropbox

Dropbox сообщил о несанкционированном доступе примерно к 5 000 аккаунтов в период с 4 по 21 августа 2026 года. Злоумышленники просматривали и скачивали содержимое облачных хранилищ, однако файлы были затронуты менее чем в трети скомпрометированных аккаунтов. 146

Главная особенность инцидента в том, что атакующим, по имеющимся данным, не понадобились ни пароли Dropbox, ни доступ к почтовым ящикам пользователей. Они использовали слабость в цепочке доверия между Lenovo ID — внешним сервисом идентификации — и Dropbox.

Как работала схема взлома

Атака, судя по опубликованным описаниям, состояла из трёх этапов:

1. Злоумышленник регистрировал Lenovo ID, указывая чужой адрес электронной почты.
2. Дефект в процедуре проверки email позволял такой учётной записи выглядеть подтверждённой, хотя атакующий не контролировал почтовый ящик.
3. Старая интеграция Dropbox с системой единого входа (SSO) сопоставляла адрес из утверждения Lenovo ID с уже существующим аккаунтом Dropbox и предоставляла доступ без ввода прежнего пароля Dropbox. 3511

Иными словами, хакерам не пришлось взламывать систему паролей Dropbox или обходить защиту электронной почты. Они воспользовались тем, как два сервиса трактовали один и тот же адрес: как идентификатор и одновременно как доказательство права владения аккаунтом.

Почему двухфакторная аутентификация помогла бы

Уязвимыми оказались аккаунты, связанные с Lenovo ID, но не защищённые многофакторной аутентификацией Dropbox. 11012

При федеративной авторизации успешный вход через стороннего провайдера может сразу создать сессию в сервисе, которому он доверяет. Дополнительная проверка Dropbox — например, код или подтверждение в приложении — добавила бы ещё один этап, контролируемый самой компанией. Поэтому инцидент затронул прежде всего аккаунты без двухэтапной защиты: это не означает, что MFA была обойдена, а показывает, что она могла остановить одну лишь поддельную учётную запись Lenovo. 1015

Какие данные могли увидеть атакующие

Dropbox заявил, что злоумышленники просматривали и скачивали материалы, хранившиеся в затронутых аккаунтах. Публичные сообщения указывают, что файлы были открыты менее чем в трети из примерно 5 000 скомпрометированных аккаунтов. 145

Доступные источники не позволяют установить единый тип файлов, общий объём скачанных данных или одинаковый уровень чувствительности информации для всех пострадавших. Некоторые пользователи получили уведомления о несанкционированном входе, но Dropbox не обнаружил в журналах признаков просмотра или загрузки их файлов. 2

Что заметили пользователи и исследователь Yoni Levy

Некоторые пострадавшие пользователи обнаружили неизвестные Lenovo ID, привязанные к их адресам электронной почты. Исследователь безопасности Yoni Levy опубликовал копию уведомления Dropbox, в котором компания описывала несанкционированный доступ в период с 4 по 21 августа и связывала проблему с интеграцией Lenovo SSO. 23

В сообщениях также упоминалась активность входа, связанная с Дублином. Это согласуется с версией о том, что поддельные учётные записи у провайдера идентификации использовались как точка входа. Однако само по себе такое наблюдение не доказывает местонахождение каждого атакующего и не означает, что все аккаунты были взломаны абсолютно одинаковым способом.

Когда Dropbox уведомил пользователей и регуляторов

Компания начала рассылать уведомления пострадавшим примерно 31 августа — 1 сентября после выявления несанкционированного доступа. Dropbox также сообщил, что уведомил регуляторов по вопросам защиты данных. 346

Среди заявленных мер компании были завершение затронутых сессий, удаление или разрыв связей с аккаунтами Lenovo, рекомендации сменить пароли и включить двухэтапную проверку, а также ограничение или усиление защиты соответствующего способа входа. 101230

Кто несёт ответственность — Dropbox или Lenovo

Это был не обычный взлом только одной компании, а сбой в связке двух систем.

• Проблема Lenovo: устаревший процесс идентификации, по имеющимся данным, позволял создать Lenovo ID с адресом, которым регистрирующийся человек не владел. То есть система недостаточно проверяла право на почтовый ящик. 3512
• Проблема Dropbox: сервис принимал внешнее утверждение Lenovo ID как достаточное основание для подключения к существующему аккаунту Dropbox, не требуя прежний пароль, повторную аутентификацию или более строгую процедуру привязки. 3911
• Реакция компаний: Lenovo назвал ситуацию связанной с устаревшей интеграцией и сообщил, что устранил соответствующую проблему проверки. Dropbox заявил, что обнаружил и исправил уязвимость, завершил затронутые сессии, изменил работу интеграции и уведомил пользователей и регуляторов. 101214

Разделение ответственности здесь принципиально важно. Слабая проверка Lenovo создавала ложное утверждение о личности, но именно логика Dropbox решала, сможет ли это утверждение открыть уже существующее облачное хранилище.

Как инцидент повлиял на акции Dropbox

После публикации информации о взломе акции Dropbox снизились во внебиржевой торговле, однако точный масштаб движения зависит от источника и выбранной точки отсчёта.

В одном сообщении со ссылкой на Reuters говорилось о снижении примерно на 2,4%, а Investing.com указывал на падение на 1,8% после закрытия рынка. 69 Другой материал сообщал о снижении более чем на 6%. 8 Конкретная цифра 6,6% доступными материалами не подтверждается и может относиться к другому периоду или уровню сравнения.

Чему этот случай учит в вопросах федеративной идентификации

Адрес электронной почты — это идентификатор. Он не является автоматическим доказательством того, что человек контролирует соответствующий почтовый ящик или имеет право на аккаунт, связанный с этим адресом.

Единый вход упрощает авторизацию: пользователю не приходится создавать отдельный пароль для каждого сервиса. Но такая модель становится опасной, если сервис-получатель:

• принимает заявление провайдера о принадлежности email без независимой проверки;
• автоматически связывает новую стороннюю учётную запись со старым аккаунтом;
• позволяет обойти прежний пароль, MFA или подтверждённый канал восстановления;
• рассматривает изменение привязки аккаунта как обычный вход, а не как событие высокого риска.

Более надёжная схема должна требовать явного подтверждения от владельца существующего аккаунта перед подключением нового провайдера идентификации. Это может быть повторный вход, проверка через подтверждённый канал восстановления или устойчивый к фишингу метод аутентификации.

Инцидент Dropbox показывает: доверие между системами идентификации и механизм привязки аккаунтов требуют не меньшего внимания, чем сами пароли. Ошибка в одном сервисе может превратиться в прямой путь к данным в другом.