При соблюдении ряда условий, опция фильтра
Вот как описывается проблемная функция в самом патчноуте AdBlock:
Уязвимость просуществовала почти 9 месяцев и была найдена только сейчас.
Автор блогозаписи-первоисточника поясняет, что опция
Атака может состояться в том случае, если веб-сайт использует
То есть, для совершения атаки должно соблюдаться три условия:
Казалось бы, условий достаточно много, да и CSP — далеко не новинка в мире веб-разработки. Однако основная угроза найденной уязвимости не в том, как она работает, а в том, как распространяется.
Так как уязвимости подвержена система фильтров AdBlock, AdBlock Plus и uBlock, то путь «заражения» конечной жертвы крайне прост — через систему автообновления фильтров. Не секрет, что огромная часть пользователей пользуется готовыми фильтрами, а не настраивает их самостоятельно. При этом автор пакета фильтров может выкатить вредоносное обновление, провести атаку, а потом «перекатить» пакет, тем самым «заметая следы».
Наиболее простой способ обезопасить себя от упомянутой уязвимости — перейти на uBlock Origin. Этот блокировщик рекламы не поддерживает функцию
В противном случае на свой страх и риск стоит ждать следующего обновления AdBlock. В официальном блоге блокировщика буквально через несколько часов после публикации в блоге armin.dev появилась эта запись с реакцией на уязвимость
В ней администрация AdBlock уверяет, что хоть уязвимость и специфическая, они крайне внимательно относятся к безопасности своей аудитории и уже в следующем обновлении функция
Также, по заверениям администрации, они проверяют все списки фильтров и перепроверили их сейчас. По результатам проведенной проверки администрация рапортует, что ни один из существующих списков фильтров описанный метод атаки на пользователя в себе не содержал. С учетом того, что между моментом публикации исходной записи и ответа в блоге AdBlock прошло всего около четырех часов, только порадуемся оперативности команды блокировщика.
При этом удаление функции
$rewrite
, внедренная в AdBlock, AdBlock Plus и uBlock с обновлением 3.2 от 17 июля 2018 года, позволяет выполнять произвольный код на отображаемой пользователю веб-странице, сообщается в блоге armin.dev.Вот как описывается проблемная функция в самом патчноуте AdBlock:
В этом патче реализована новая опция фильтра $rewrite
, которая позволяет авторам списков фильтров предотвращать показ (в основном это касается видео) рекламных объявлений, которые ранее не могли быть заблокированы на ряде веб-сайтов.
Описываемая уязвимость затрагивает все три упомянутых блокировщика рекламы, суммарная аудитория которых превышает 100 млн пользователей. Использовать ее можно для атаки на любой веб-сервис, включая и не ограничиваясь, например, любым из ресурсов Google. Проблема носит повсеместный характер, то есть атака с одинаковой успешностью может быть проведена на любом популярном браузере и не зависит от его версии. Уязвимость просуществовала почти 9 месяцев и была найдена только сейчас.
Суть атаки
Автор блогозаписи-первоисточника поясняет, что опция
$rewrite
используется в AdBlock и других упомянутых блокировщиках для избежания отслеживания пользователя и блокирования рекламы путем перенаправления запросов от посещаемой веб-страницы. Так, $rewrite
позволяет перенаправлять и не обрабатывать запросы типа SCRIPT
, SUBDOCUMENT
, OBJECT
и OBJECT_SUBREQUEST
.Атака может состояться в том случае, если веб-сайт использует
XMLHttpRequest
или Fetch
для загрузки и исполнения фрагментов (сниппетов) кода, одновременно позволяя совершать произвольные запросы.То есть, для совершения атаки должно соблюдаться три условия:
- Веб-страница должна загрузить строку JS с использованием
XMLHttpRequest
илиFetch
и выполнить возвращенный код. - Веб-страница не должна использовать директивы проверки Content Security Policy и не должна проверять окончательный URL-адрес перед выполнением загруженного кода.
- Источник извлеченного кода должен поддерживать редирект на стороне сервера или должен содержать произвольный пользовательский контент.
Казалось бы, условий достаточно много, да и CSP — далеко не новинка в мире веб-разработки. Однако основная угроза найденной уязвимости не в том, как она работает, а в том, как распространяется.
Так как уязвимости подвержена система фильтров AdBlock, AdBlock Plus и uBlock, то путь «заражения» конечной жертвы крайне прост — через систему автообновления фильтров. Не секрет, что огромная часть пользователей пользуется готовыми фильтрами, а не настраивает их самостоятельно. При этом автор пакета фильтров может выкатить вредоносное обновление, провести атаку, а потом «перекатить» пакет, тем самым «заметая следы».
Способы борьбы
Наиболее простой способ обезопасить себя от упомянутой уязвимости — перейти на uBlock Origin. Этот блокировщик рекламы не поддерживает функцию
$rewrite
, то есть реализовать через него описанную атаку невозможно. В противном случае на свой страх и риск стоит ждать следующего обновления AdBlock. В официальном блоге блокировщика буквально через несколько часов после публикации в блоге armin.dev появилась эта запись с реакцией на уязвимость
$rewrite
.В ней администрация AdBlock уверяет, что хоть уязвимость и специфическая, они крайне внимательно относятся к безопасности своей аудитории и уже в следующем обновлении функция
$rewrite
будет выпилена из AdBlock.Также, по заверениям администрации, они проверяют все списки фильтров и перепроверили их сейчас. По результатам проведенной проверки администрация рапортует, что ни один из существующих списков фильтров описанный метод атаки на пользователя в себе не содержал. С учетом того, что между моментом публикации исходной записи и ответа в блоге AdBlock прошло всего около четырех часов, только порадуемся оперативности команды блокировщика.
При этом удаление функции
$rewrite
из проекта — шаг назад для AbBlock, так как изначально она создавалась для борьбы с всплывающей видеорекламой. Теперь она вернется ради всеобщей безопасности. Кроме этого, оперативность, с которой было принято решение полностью удалить $rewrite
из проекта показывает, что хоть атака и специфична, но уж слишком жутко выглядят последствия ее массового проведения. Комментарии (2)
catharsis
17.04.2019 11:23например, любым из ресурсов Google
не должна использовать директивы проверки Content Security Policy
Разве на сервисах Google нет CSP?
nobodysu
Нужно сразу писать что Origin не подвержен. Обычный хайджакнутый никто не использует. Также, почти год назад:
github.com/uBlockOrigin/uBlock-issues/issues/46#issuecomment-391303700