Apple заблокировала смену пароля AppleID по телефону

Apple заблокировала смену пароля AppleID по телефону

После фееричного взлома журналиста Мэт Хонана, когда хакеры завладели его аккаунтом AppleID и в удалённом режиме стёрли файлы с его ноутбука, планшета и телефона iPhone, компания Apple заблокировала смену пароля AppleID по телефону.

Apple ничего официально не объявляла и отказалась комментировать ситуацию, но один из сотрудников компании на условиях анонимности сообщил, что соответствующее распоряжение поступило во все службы поддержки пользователей AppleCare. Теперь пользователей направляют на онлайновый сервис iforgot.apple.com.

Напомним, что в минувшую пятницу неизвестный злоумышленник сумел выдать себя за Мэта Хонана, позвонив в службу поддержки и назвав имя, адрес и последние четыре цифры кредитной карты. Этой информации оказалось достаточно, чтобы служба поддержки Apple предоставила временный пароль для аккаунта @me.com, а уже там можно сделать что угодно, в том числе и воспользоваться удобным сервисом для удаления информации на всех устройствах Apple, привязанных к этому аккаунту, пишет xakep.ru.

История получила широкий резонанс в прессе. В понедельник Мэт Хонан в дополнение к своему пятничному посту опубликовал более подробную информацию. Оказывается, до звонка в Apple злоумышленник предварительно получил доступ к его аккаунту на Amazon, чтобы узнать там четыре последние цифры кредитной карточки. Для получения доступа к аккаунту Amazon он позвонил в службу техподдержки Amazon, назвал имя, домашний адрес и email — и попросил добавить новую кредитную карту к своему аккаунту. После этого он позвонил туда ещё раз, и сказал, что забыл пароль. Ему сгенерировали новый пароль, когда он назвал имя, адрес и номер кредитной карты (только что добавленной).

Интересно, что перед публикацией статьи журналисты Wired успешно проделали этот фокус несколько раз. Говорят, что в последние пару дней тысячи пользователей Amazon неожиданно поменяли пароли к своим аккаунтам. Правда, некоторым не удавалось это сделать, потому что они говорили с сильным русским акцентом. Вчера компания Amazon тоже ужесточила процедуру смены пароля для своих сервисов.

В других СМИ опубликованы статьи в стиле «Что делать, чтобы не стать Мэтом Хонаном» с рекомендациями по безопасности, которые сам журналист легкомысленно игнорировал. Главный из них — использовать двухфакторную аутентификацию и не слишком-то доверять облачным сервисам. Тем более, что не все из них поддерживают двухфакторную аутентификацию.

Хакеры спрятали команды для WordPress-зловреда в комментариях Steam

Исследователи GoDaddy обнаружили необычную вредоносную кампанию, жертвами которой стали почти 2000 сайтов на WordPress. Вместо традиционной инфраструктуры управления злоумышленники использовали комментарии в профилях Steam Community.

Схема выглядит настолько странно, что сначала напоминает шутку. Однако всё вполне серьёзно.

После заражения WordPress-сайта вредоносный код обращался к определённым профилям Steam и считывал комментарии пользователей. На первый взгляд они выглядели как обычный текст или даже ASCII-арт. Но внутри были спрятаны невидимые Unicode-символы.

 

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

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

После расшифровки сайт получал адрес внешнего сервера и загружал оттуда JavaScript под видом обычных библиотек. Для маскировки использовались названия вроде asahi-jquery-min-bundle или lodash.core.min.js, чтобы не вызывать подозрений у администраторов.

 

Финальной стадией атаки становилась установка бэкдора. Он позволял злоумышленникам удалённо выполнять PHP-код через специально сформированные POST-запросы и фактически получать контроль над сайтом.

По данным GoDaddy, кампания действует как минимум с июля 2025 года. Всего специалисты обнаружили признаки заражения примерно на 1980 WordPress-ресурсах.

Как именно происходило первоначальное заражение, пока неизвестно. Среди возможных вариантов называются украденные учётные данные администраторов, компрометация доступа по FTP / SFTP, уязвимости в темах и плагинах WordPress или атаки через цепочки поставок.

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

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