ФБР пытается найти след NSO Group во взломе главы Amazon

ФБР пытается найти след NSO Group во взломе главы Amazon

ФБР пытается найти след NSO Group во взломе главы Amazon

ФБР приступило к расследованию взлома личного смартфона главы и основателя Amazon Джеффа Безоса. На данном этапе источником атаки принято считать Саудовскую Аравию.

Сотрудники спецслужбы прорабатывают версию, согласно которой мобильное устройство Безоса мог взломать наследный принц Саудовской Аравии Мухаммед ибн Салман Аль Сауд.

Известно, что инцидент произошёл в мае 2018 года, а в атаке использовалась свежая на тот момент уязвимость мессенджера WhatsApp.

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

Если верить словам самого пострадавшего, в результате взлома утекли его личные файлы. Более того, Безос обвинил National Enquirer в шантаже — издание располагало фотографиями интимного характера, на которых были изображены уже женатый Безос и его подружка.

Теперь ФБР изучает имеющиеся в деле улики и пытается выяснить, были ли задействованы в ходе атаки программы, разработанные израильской компанией NSO Group. Напомним, что NSO Group славится своими методами взлома мобильных устройств.

Например, известно, что вредонос «Pegasus», созданный NSO Group, способен перехватывать хранящиеся на смартфонах данные, включая зашифрованные сообщения. Эта программа может избегать детектирования и автоматически удалять себя из системы.

Представители NSO Group отрицают своё участие в этой истории.

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

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

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

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

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

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

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

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

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

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