Уязвимость в фильтрах AdBlock и uBlock позволяет выполнять произвольный код на стороне пользователя

При соблюдении ряда условий, опция фильтра $rewrite, внедренная в AdBlock, AdBlock Plus и uBlock с обновлением 3.2 от 17 июля 2018 года ^[1], позволяет выполнять произвольный код на отображаемой пользователю веб-странице, сообщается в блоге armin.dev ^[2].

Вот как описывается проблемная функция в самом патчноуте AdBlock:

В этом патче реализована новая опция фильтра $rewrite, которая позволяет авторам списков фильтров предотвращать показ (в основном это касается видео) рекламных объявлений, которые ранее не могли быть заблокированы на ряде веб-сайтов.

Описываемая уязвимость затрагивает все три упомянутых блокировщика рекламы, суммарная аудитория которых превышает 100 млн пользователей. Использовать ее можно для атаки на любой веб-сервис, включая и не ограничиваясь, например, любым из ресурсов Google. Проблема носит повсеместный характер, то есть атака с одинаковой успешностью может быть проведена на любом популярном браузере и не зависит от его версии.

Уязвимость просуществовала почти 9 месяцев и была найдена только сейчас.

Суть атаки

Автор блогозаписи-первоисточника поясняет, что опция $rewrite используется в AdBlock и других упомянутых блокировщиках для избежания отслеживания пользователя и блокирования рекламы путем перенаправления запросов от посещаемой веб-страницы. Так, $rewrite позволяет перенаправлять и не обрабатывать запросы типа SCRIPT, SUBDOCUMENT, OBJECT и OBJECT_SUBREQUEST.

Атака может состояться в том случае, если веб-сайт использует XMLHttpRequest или Fetch для загрузки и исполнения фрагментов (сниппетов) кода, одновременно позволяя совершать произвольные запросы.

То есть, для совершения атаки должно соблюдаться три условия:

1. Веб-страница должна загрузить строку JS с использованием XMLHttpRequest или Fetch и выполнить возвращенный код.
2. Веб-страница не должна использовать директивы проверки Content Security Policy ^[3] и не должна проверять окончательный URL-адрес перед выполнением загруженного кода.
3. Источник извлеченного кода должен поддерживать редирект на стороне сервера или должен содержать произвольный пользовательский контент.

Казалось бы, условий достаточно много, да и CSP — далеко не новинка в мире веб-разработки. Однако основная угроза найденной уязвимости не в том, как она работает, а в том, как распространяется.

Так как уязвимости подвержена система фильтров AdBlock, AdBlock Plus и uBlock, то путь «заражения» конечно жертвы крайне прост — через систему автообновления фильтров. Не секрет, что огромная часть пользователей пользуется готовыми фильтрами, а не настраивает их самостоятельно. При этом автор пакета фильтров может выкатить вредоносное обновление, провести атаку, а потом «перекатить» пакет, тем самым «заметая следы».

Способы борьбы

Наиболее простой способ обезопасить себя от упомянутой уязвимости — перейти на uBlock Origin. Этот блокировщик рекламы не поддерживает функцию $rewrite, то есть реализовать через него описанную атаку невозможно.

В противном случае на свой страх и риск стоит ждать следующего обновления AdBlock. В официальном блоге блокировщика буквально через несколько часов после публикации в блоге armin.dev появилась эта запись ^[4] с реакцией на уязвимость $rewrite.

В ней администрация AdBlock уверяет, что хоть уязвимость и специфическая, они крайне внимательно относятся к безопасности своей аудитории и уже в следующем обновлении ^[5] функция $rewrite будет выпилена из AdBlock.

Также, по заверениям администрации, они проверяют все списки фильтров и перепроверили их сейчас. По результатам проведенной проверки администрация рапортует, что ни один из существующих списков фильтров описанный метод атаки на пользователя в себе не содержал. С учетом того, что между моментом публикации исходной записи и ответа в блоге AdBlock прошло всего около четырех часов, только порадуемся оперативности команды блокировщика.

При этом удаление функции $rewrite из проекта — шаг назад для AbBlock, так как изначальна она создавалась для борьбы с всплывающей видеорекламой. Теперь она вернется ради всеобщей безопасности. Кроме этого, оперативность, с которой было принято решение полностью удалить $rewrite из проекта показывает, что хоть атака и специфична, но уж слишком жутко выглядят последствия ее массового проведения.

Автор: ITSumma

Источник ^[6]