На днях исследователь безопасности Скотт Хельм обнаружил, что сторонний плагин для реализации доступности (accessibility) под названием Browsealoud скомпрометировал серверы их компании. Плагину требовался Javascript для своей работы. В результате этого более 4000 сайтов оказались скомпрометированными, что привело к выполнению вредоносного кода для майнинга криптовалют.

Вредоносная программа использовала CPU посетителя сайта для майнинга криптовалюты Monero. Среди сайтов, использующих плагин Browsealoud, значились и такие крупные ресурсы, как Information Commissioner’s Office в Великобритании, UK National Health Service, а также региональный правительственный веб-сайт Австралии и многие другие ресурсы.

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

Атаки с майнингом криптовалют находятся на пике популярности

В ноябре уже упоминался плагин WordPress, который был забанен за включение кода для майнинга криптовалют, в частности кода CoinHive, который позволяет майнить валюту Monero. В данном случае, если на сайте стоял запрещенный плагин, любой посетитель сайта мог видеть, как утекают его процессорные ресурсы. Вырученная сумма пересылалась владельцам плагина. Вместе с увеличением рабочей нагрузки от майнинга Monero увеличивалась и скорость вентилятора на процессоре.

В декабре также была атака, нацеленная на WordPress и связанная с майнингом Monero.

Скотт сообщил, что текущая атака также использовала код CoinHive для майнинга Monero и отправляла средства злоумышленнику.

Атаки на цепи поставок растут в объемах

2 января мой коллега Дэн Моэн написал о растущей угрозе атак на цепи поставок (supply chain attacks). Вполне вероятно, что в 2018 году будет наблюдаться еще больше подобных атак, затрагивающих владельцев сайтов.

В индустрии программного обеспечения атаки на цепи поставок эксплуатируют доверительные отношения между поставщиками (или разработчиками) ПО и их клиентами. Если говорить про наш случай: вы доверяете безопасность вашего сайта сервису, распространяющему Javascript. Если этот сервис будет скомпрометирован, атака затронет все сайты, использующие данный код – потенциально тысячи веб-сайтов. Как и в случае с WordPress плагинами, атаки на цепи поставок Javascript позволяют атакующему скомпрометировать тысячи сайтов с помощью одного взлома.

В случае с Browsealoud последствия могли быть и более серьезными. Злоумышленник мог украсть персональные данные с сайтов правительств в нескольких странах. Но вместо этого злоумышленники эксплуатировали процессорные ресурсы для майнинга криптовалюты Monero.

Как защитить себя и посетителей своего сайта от атак на цепи поставок JS

Есть простой способ защиты от атаки на цепи поставок JS. Делается это с помощью возможности Subresource Integrity (SRI). Если вы добавляете Javascript код со стороннего ресурса с помощью тега SCRIPT, просто добавьте атрибут integrity, который заставит браузеры не загружать скрипт, если он был модифицирован по сравнению с оригинальной версией.

Обычно вы подключаете скрипты следующим образом:

Чтобы защитить свой сайт от атак на цепи поставок JS, измените код на:

Достаточно простое изменение. Вы можете посетить следующую страницу для генерации хэша и кода включения на базе URL скрипта.

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

Как только вы воспользуетесь SRI и включите хэш для своих скриптов, при любом своем изменении скрипт не будет загружаться. Это полезно для защиты посетителей сайта, когда взломщик скомпрометировал сайт поставщика и внедрил вредоносный код в загружаемый вами Javascript. Однако это имеет и побочный эффект: если поставщик обновит свой код по тому же самому URL-адресу, ваш скрипт больше не будет загружаться.

Некоторые поставщики полагаются на возможность обновления кода по URL, внося изменения в любой момент времени, и в результате этого ваш сайт просто подгружает новый код без каких-либо дополнительных действий. Если поставщик включает номер версии в URL скрипта, как в jQuery URL выше, то в таком случае вам не о чем волноваться. Но если URL-адрес имеет вид //example.com/source/code/lives/here.js, и в нем не указана версия, то в таком случае обратитесь к поставщику, чтобы понять, планирует ли он обновлять скрипт, который вы используете. Поставщик может уведомлять вас, когда именно он планирует провести обновление, чтобы избежать перебоев в работе.

В общем, я бы избегал поставщиков, которые настаивают на возможности удаленного обновления кода без внесения изменений в код вашего сайта. Это риск для безопасности, как и показывает данный случай.

Атаки на цепи поставок JS выполняются в реальном времени

Что отличает атаку на цепи поставок JS от других типов атак: после того, как злоумышленник инъецирует свой вредоносный код, жертвы страдают мгновенно. Администратору сайта или посетителям сайта не требуется предпринимать никаких действий. Код загружается с сервера во время посещения сайта и на момент своего изменения он является активным в браузерах жертв.

Это отличается от атак на цепи поставок приложений или атак на цепи поставок WordPress плагинов. Атака на цепь поставок приложения требует, чтобы уязвимое приложение было распространено по пользователям, прежде чем начать их эксплуатацию. Пользователи десктопов или мобильных устройств должны обновить приложение до новой версии, чтобы запустить атаку. Даже если автообновление будет каким-либо образом выполнено злоумышленником, все равно будет иметься некоторая задержка перед тем, как атака начнет приносить свои плоды.

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

Источник: https://www.wordfence.com