Баг Zoom позволял брутфорсить пароли, которыми защищены видеоконференции

Баг Zoom позволял брутфорсить пароли, которыми защищены видеоконференции

Баг Zoom позволял брутфорсить пароли, которыми защищены видеоконференции

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

Этот баг обнаружил Том Энтони, отвечающий за развитие продуктов в компании SearchPilot.

«Видеособрания в Zoom по умолчанию защищены 6-значным паролем. Это значит, что потенциальному злоумышленнику потребуется не более одного миллиона попыток подбора этого пароля», — объясняет Энтони.

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

«Возникает вполне логичный вопрос: использовали ли эту уязвимость злоумышленники для прослушивания чужих защищённых видеовстреч».

Проблема отягощается тем, что повторяющиеся видеособрания и идентификаторы Personal Meeting постоянно используют один пароль. Это значит, что атакующему лишь один раз нужно взломать встречу, чтобы впоследствии без труда получать доступ к другим звонкам.

Сам Энтони продемонстрировал взлом пароля, на который у него ушло 25 минут (после подбора 91 тыс. вариаций). Однако злоумышленники, по словам эксперта, будут использовать более мощные средства, поэтому у них брутфорс должен занять несколько минут.

Разработчики Zoom уже разобрались с этим багом. Теперь пользователи защищены от этой уязвимости.

Подпишитесь на новости

1,8 ТБ и вагон ошибок: как выгрузка с Яндекс Диска превратилась в квест

Пользователь «Яндекс Диска» решил сделать резервную копию 1,8 ТБ файлов, а также примерно 160 ГБ фотографий и получил приключение с ошибками API, зависшими загрузками и собственными скриптами.

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

Подробности инженер Сергей Терёхин, известный как KenGuru66, описал  в собственном разборе на Хабре.

План был такой: rclone, сервер в Нидерландах, копия в Google Drive. Но стандартная аутентификация позволяла получить сведения о диске, а обращения к файлам возвращали ошибку 410. Доступ удалось наладить с другим OAuth-токеном.

Фотографии из безлимитной автозагрузки добавили веселья: для копирования через выбранный API их пришлось переместить в обычную папку. После этого они начали занимать место в тарифе. Более 30 тысяч снимков переносились около шести часов.

В выборке из 300 случайных файлов автор смог получить начало только 146. По важной папке с документами он скопировал и проверил по MD5 2315 файлов; ещё 3079 на момент публикации оставались недоступны.

Потерю данных автор не утверждает, он продолжает повторные загрузки. Скрипты опубликованы на GitHub.

RSS: Новости на портале Anti-Malware.ru