Никто не заметил, но Apple тоже ограничила блокировщики рекламы

Никто не заметил, но Apple тоже ограничила блокировщики рекламы

Никто не заметил, но Apple тоже ограничила блокировщики рекламы

Многие пользователи возмутились, когда узнали, что Google планирует ограничить возможности блокировщиков рекламы в браузере Chrome. Однако мало кто заметил, что схожие меры уже ввели в Safari, при этом Apple даже не подверглась критике.

На протяжении последних полутора лет Apple постепенно нивелировала работу блокировщиков рекламы в браузере Safari. Именно к такому подходу многие пользователи выразили резко негативное отношение в случае с Google.

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

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

Все началось с того, что Apple несколько лет назад представила App Extensions — механизм, с помощью которого приложения могут внедрить свои возможности в другие программы.

По словам компании из Купертино, App Extensions должен работать в тандеме с технологией Content Blocker, которая была представлена в iOS 9 в 2013 году. 

На деле это значит, что приложения и расширения могут использовать API Content Blocker, который будет диктовать Safari, какой контент блокировать перед отображением веб-страницы. Блокировка будет осуществляться на основании набора правил.

После того как Apple на протяжении нескольких лет опробовала эти две функции, в компании поняли: разработчики, создающие расширения для Safari, больше не нужны. Вместо этого они могут просто задействовать приложения в App Store, чтобы обеспечить пользователей Safari дополнительными функциями.

Таким образом, предыдущая экосистема расширений оказалась устаревшей. В результате в середине 2018 Apple объявила окончание поддержки «устаревших» расширений.

К концу 2018 года Safari начал выводить следующее предупреждение: «Safari отключил расширения, которые могут замедлить работу вашего браузера».

Естественно, одними из таких «устаревших» расширений оказались и блокировщики рекламы. При этом большинство пользователей даже не обратили на это внимание, так как им рассказывали только о преимуществах нововведений.

В начале месяца стало известно, что Mozilla решила не следовать примеру Google в отношении новой политики блокировки рекламы. Компания-разработчик браузера Firefox продолжит поддерживать расширения для блокировки рекламного контента.

Python-пакет pyronut превращает Telegram-ботов в точку входа для атакующих

В репозитории PyPI обнаружили вредоносный Python-пакет pyronut, который маскировался под библиотеку для работы с Telegram и превращал ботов в удобную точку входа для атакующих. Исследователи из Endor Labs пишут, что пакет выдавал себя за альтернативу популярному Pyrogram — фреймворку для Telegram MTProto API, который используется довольно широко.

Схема была не совсем классическим тайпсквоттингом: названия pyrogram и pyronut не так уж похожи.

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

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

Пакет прожил недолго, но этого вполне хватило. На PyPI успели появиться только три версии — 2.0.184, 2.0.185 и 2.0.186, обе были вредоносными. По данным исследователей, их обнаружили и отправили в карантин 18 марта 2026 года, так что окно заражения оказалось сравнительно коротким.

Особенно неприятно то, как именно работал pyronut. В отличие от многих зловредных пакетов, которые срабатывают ещё во время установки, здесь полезная нагрузка активировалась только при запуске Telegram.

Злоумышленник модифицировал метод Client.start() так, чтобы тот незаметно подтягивал скрытый модуль и запускал бэкдор, при этом все ошибки молча подавлялись, а приложение со стороны выглядело нормально.

Дальше начиналось самое интересное. Бэкдор регистрировал скрытые обработчики команд /e и /shell, которые принимались только от двух заранее зашитых Telegram-аккаунтов атакующего.

Команда /e фактически превращала заражённого бота в удалённую Python-консоль с доступом к объектам клиента, чатам, контактам, истории сообщений и низкоуровневым API Telegram. А /shell давала уже более привычный доступ к системе: произвольные команды передавались в /bin/bash -c, а результаты возвращались злоумышленнику через сам Telegram.

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

Специалисты рекомендуют проверить зависимости на наличие pyronut этих версий, посмотреть, не подтягивалась ли библиотека meval, и отдельно поискать подозрительные дочерние процессы вида /bin/bash -c, запущенные из Python-приложений. Если пакет всё же оказался в окружении, исследователи советуют отзывать Telegram-сессии, перевыпускать токены ботов и менять все потенциально засвеченные секреты.

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