Помощь · Поиск · Пользователи · Календарь
Полная версия этой страницы: XSS уязвимости в 215000 флеш файлах
Flash Zone Forum > Flash Zone Team > MustLive/BPG Collections of Fun - Коллекции приколов > MustLive Security
MustLive
Как я написал в своей статье XSS уязвимости в 215000 флеш файлах в ноябре 2008 года, проводя секюрити исследования, я обнаружил в Интернете около 215000 флеш файлов уязвимых к Cross-Site Scripting (на более 200000 сайтах).

Детально о данном исследовании вы можете прочесть на моём сайте: http://websecurity.com.ua/2609/.

Данная статья также доступна на английском языке: XSS vulnerabilities in 215000 flash files.

P.S.

В ближайшее время я планирую опубликовать свои новые исследования на тему уязвимых флешек.
chingachgoog
MustLive, все же я не понял в чем уязвимость и как она достигается.
Ну допустим во флешке есть код
Код
getURL(link)

Примерно такое есть на всех баннерах в приличных рекламных площадках (они так клики считают).
link во флеш они передают обычно через flashvars.

Вы пишите, что link во флеш можно заменить на код JS.
Тут сразу интересно, как злоумышленник это сделает?
А во-вторых, что именно он этим добъется? Вы вроде писали, что он может полазить по кукисам браузера, неужели это так?
MustLive
Цитата
MustLive, все же я не понял в чем уязвимость и как она достигается.

chingachgoog

Чтобы понять в чём здесь уязвимость, нужно понимать, что такое XSS (для этого, в частности, можно прочесть мою статью опубликованную в номере Хакер Спец за февраль 2007). И нужно внимательно прочесть мою статью "XSS уязвимости в 215000 флеш файлах", где я детально описал различные варианты атаки.

Цитата
Ну допустим во флешке есть код
Код
getURL(link)

Это значит, что этой флешке можно передать извне (всеми поддерживаемыми флешем методами) значение link. И тем самым контролировать результат выполнения команды getURL. Что может быть использовано, в частности, для проведения Cross-Site Scripting и Redirector атаки.

В случае если есть обработчик нажатия (onPress или onRelease), то код исполнится при нажатии на баннер, если же код задан без данного обработчика, как в твоём примере, то код исполнится автоматически (в нужном кадре флешки).

Для атаки можно передать параметры флешке непосредственно (через GET), как это показано у меня в статье.

Примеры атак (замечу, что форум вставляет пробел в слово "javascript"):

XSS:
Код
http://site/flash.swf?link=java script:alert('XSS')

Код
http://site/flash.swf?link=java script:alert(document.cookie)

Redirector:
Код
http://site/flash.swf?link=http://badsite

Пользователь который зайдёт на данную флешку (с указанным параметром link) будет атакован. В случае твоего примера AS кода, атака произойдёт автоматически при загрузке флешки.
MustLive
Цитата
Примерно такое есть на всех баннерах в приличных рекламных площадках (они так клики считают).

Так и есть. А также во многих баннерных системах и в некоторых локальных баннерных системах (причём весьма популярных веб приложениях). И все сайты и системы, которые используют подобный код, являются уязвимыми.

Я регулярно провожу исследования уязвимостей во флешках в локальных и глобальных баннерных системах (и регулярно нахожу подобные уязвимости), и в будущем буду публиковать новые статьи на данную тему. Так что после этой статьи о 215000 уязвимых флеш файлах, я напишу ещё много новых статей.

Цитата
link во флеш они передают обычно через flashvars.

Обычно через flashvars. Который является одним из методов передачи данных во флешку. В своих примерах я привожу атаки с использованием метода GET (который позволяет работать непосредственно с флешкой, без использования html).

Цитата
Вы пишите, что link во флеш можно заменить на код JS.
Тут сразу интересно, как злоумышленник это сделает?

Можно заменить на JS код (или на VBS код для IE, но лучше использовать JS, который будет работать во всех браузерах).

Как заменить link на JS я показал на примерах (в частности через GET параметр).

Цитата
А во-вторых, что именно он этим добъется? Вы вроде писали, что он может полазить по кукисам браузера, неужели это так?

Добъётся он того, что сможет проводить XSS и Redirector атаки (чтобы понять имеющиеся риски, нужно знать что такое Cross-Site Scripting и Redirector).

В том числе можно получить доступ к кукисам (на домене где размещена флешка). При этом, как я писал в статье, при указанном target = "_blank" (в getURL), данная атака не работает в IE6 и не позволяет получить доступ к кукисам (в IE6 и Mozilla, зато можно получить доступ к кукисам в Firefox 3 и возможно в других браузерах). Зато любые другие атаки возможны и при target = "_blank".
chingachgoog
MustLive, я не особо силен в сетевом скрипте (я делаю в основном локальные флешки и приложения).
Можно попроще для тупых? smile.gif

Я почитал по XSS, но есть вопросы.
http://ru.wikipedia.org/wiki/Межсайтовый_скриптинг
http://websecurity.com.ua/articles/the_danger_of_xss/

Итак есть флешка с относительной ссылкой (переменной):
Код
getURL(link)


Вредоносный код надо в эту переменную link как-то передать.
Т.е. речь не идет, скорее всего, об изначальной вредоносности самой swf (хотя это, наверное, не стоит исключать).
Значит внедрение вредоносного кода в link должно быть на стороне сервера, откуда флешка скачивается? Т.е. речь о втором типе XSS - активном?

Цитата(MustLive @ 9.05.2009 - 21:53) *
В том числе можно получить доступ к кукисам (на домене где размещена флешка).


Вот тут нужен ликбез smile.gif
Значит JS позволяет добраться до кукисов хранимым браузером? И каковы тут ограничения? Насколько глубоко можно ожидать потерю кукисов? Можно ли похитить сторонние куки?
MustLive
Цитата
я не особо силен в сетевом скрипте

chingachgoog

Это не сетевой скрипт smile.gif, а межсайтовый скриптинг (Cross-Site Scripting). К тому же XSS уязвимости могут использоваться и для локальной атаки (существуют отдельные подклассы XSS). В том числе и для удалённого исполнения кода на локальном компьютере пользователя.

Цитата
Я почитал по XSS, но есть вопросы.

Значит стоило ещё почитать информации wink.gif. Хорошо, что ты догадался почитать статью на википедии, ещё в 2006 я у себя на сайте давал ссылку на статью про XSS на википедии (на английскую статью). Но стоило почитать английскую статью, в ней гораздо больше информации чем в русской, и сама статья более качественно сделана.

Цитата
Вредоносный код надо в эту переменную link как-то передать.

Естественно, и в своей статье и ранее в этой теме я привёл множество примеров, как происходит этот процесс. Передача осуществляется через GET параметр.

Повторю пример XSS атаки:
Код
http://site/flash.swf?link=java script:alert(document.cookie)

Это reflected XSS (пассивный XSS).

Цитата
Т.е. речь не идет, скорее всего, об изначальной вредоносности самой swf (хотя это, наверное, не стоит исключать).

Если флешка будет изначально содержать атакующий код, и её можно будет разместить на сервере, то тогда это также будет XSS уязвимость, но уже persistent XSS (активный XSS).

Цитата
Т.е. речь о втором типе XSS - активном?

В своих примерах уязвимых флешек, где атака происходит через параметр link, я вёл речь только о пассивном XSS.

К примеру в другой теме форума я рассказывал об активном XSS (через загрузку атакующих флешек на сервер).
MustLive
Цитата
Вот тут нужен ликбез

Как я уже сказал, через данную атаку (как через XSS через флеш, так и вообще через XSS) можно получить доступ к кукисам, но лишь на домене где размещена флешка. Это обусловлено SOP (Same Origin Policy) реализуемой всеми браузерами.

Цитата
Значит JS позволяет добраться до кукисов хранимым браузером?

Естественно, доступ к кукисам (чтение/запись) является частью функционала JavaScript. А так как XSS атака подразумевает использование JS, то соответственно при данной атаке можно похитить кукисы пользователя.

Цитата
И каковы тут ограничения? Насколько глубоко можно ожидать потерю кукисов?

Ограничение только доменом, где находится XSS уязвимость (в том числе уязвимая флешка). Также возможна утечка кукисов из поддоменов данного домена, если данные кукисы были соответственным образом настроены (для доступности на всех поддоменах).

Поэтому похищены могут быть кукисы любого пользователя (который атакуется) в рамках конкретного домена (в некоторых случаях и поддоменов), где находится XSS уязвимость.

Цитата
Можно ли похитить сторонние куки?

Похитить можно только кукисы того, кого атакуют через XSS. Учитывая, что эти кукисы не принадлежат злоумышленнику (пока он их не похитит), то их можно назвать сторонними smile.gif.

Чтобы обойти SOP и похитить кукисы с другого домена, для этого можно воспользоваться уязвимостями в браузерах, которые позволяют обходить Same Origin Policy. Подобные уязвимости периодически находят в разных браузерах.
chingachgoog
Цитата(MustLive @ 24.05.2009 - 01:24) *
Значит стоило ещё почитать информации wink.gif.


Читаю...

Цитата(MustLive @ 24.05.2009 - 01:24) *
Передача осуществляется через GET параметр.
Повторю пример XSS атаки:
Код
http://site/flash.swf?link=java script:alert(document.cookie)

Это reflected XSS (пассивный XSS).


Вот тут у меня затык.
Никак не пойму sad.gif
Если можно на пальцах:

Есть некий сайт фигандекс.ру - легальный известный поисковик, сдающий места под баннеры.
Есть флешер, который кодирует кнопку с относительной ссылкой-переменной link.
Верстальщики фигандекс.ру  в коде html задают (через flashvar, например) эту переменную link под свой движок подсчета кликов.

Т.е. переменная link УЖЕ передана флешке, когда пользователь зашел на фигандекс.ру . Что теперь может задать/переопределить переменную link?

Т.е. в html коде на страничке фигандекс.ру  мы имеем легальную прописанную ссылку link. Как она станет нелегальной? Я так понимаю, что должен быть взломан сервер и переписан html код странички фигандекс.ру  - но тогда это уже никак не пассивный XSS. Либо может быть, должен быть левый заход на страничку фигандекс.ру  где добавлен вредоносный GET-параметр? Т.е. заход с заведомо вредоносного сайта? Это имелось ввиду? (хотя я не знаю, что будет главнее: GET-параметр или уже прописанный flashvar в html коде странички???)
MustLive
Цитата
Вот тут у меня затык.
Никак не пойму

chingachgoog, там всё просто. Особенно, если один раз увидеть это в действии (что ты можешь сделать самостоятельно на своей флешке или любой другой флешке размещённой на сайте, которые будут иметь данную уязвимость).

Цитата
Если можно на пальцах:

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

Цитата
Т.е. переменная link УЖЕ передана флешке, когда пользователь зашел на фигандекс.ру . Что теперь может задать/переопределить переменную link?

Как видно из приведённых мною примеров, для атаки нужно обратиться напрямую к флешке. Т.е. нет передаваемого из flashvars значения link, только через GET параметр. И при передаче баннеру JS-кода именно он и выполнится (в данном случае при нажатии на баннер). Т.е. для атаки нужна лишь сама флешка, без каких-либо отдельных html-страниц с внедрением в них этой флешки (использование отдельных веб страниц м.б. использовано для маскировки, чтобы пользователь не видел URL, как и некоторые другие методы маскировки).

Цитата
Т.е. заход с заведомо вредоносного сайта?

Это может быть заход с любого сайта, в том числе полностью безопасного. Подобные ссылки м.б. размещены в гостевых книгах, форумах и комментариях на сайтах. А также их могут послать по электронной почте и через IM-клиенты.
chingachgoog
Наконец-то я допер smile.gif
http://kb2.adobe.com/cps/407/kb407748.html

Дело именно в том, ГДЕ ЛЕЖИТ ФИЗИЧЕСКИ та флешка, на которую мы даем ссылку.
Тогда мы получим куки пользователя для ЭТОГО МЕСТА.

Т.е., например, нам надо получить куки пользователя с сайта ФИГАНДЕКС.
Тогда надо сделать следующее:
1) Разместить нашу флешку (swf) на сайте ФИГАНДЕКС.
2) Подсунуть пользователю путь (ссылку) для ИСПОЛНЕНИЯ этой флешки (например, заманить на сайт ЗАМАНКА, где будет ИСПОЛНЯТЬСЯ флешка, ФИЗИЧЕСКИ размещенная на сайте ФИГАНДЕКС)
3) Если у пользователя есть куки с сайта ФИГАНДЕКС, то флешка сможет эти куки прочитать и... (далее неясно)

add:
8-й ИЕ очень умный что ли?
Код
alert(document.cookie)

Не хочет выполнять! Молодец. Говорит "нет доступа", тогда как просто строку в алерт выдает.
(пересылку на другой сайт, конечно, делает - это же и есть основное предназначение всех флеш-баннеров).
Т.е. ИЕ8 не подвержен уязвимости с похищением куков? Или просто-напросто более хитрый JS-код подсовывается и все - куки доступны?
MustLive
chingachgoog

Относительно данной темы полторы недели назад я писал о моей новой статье XSS уязвимости в 8 миллионах флеш файлах. Это моё новое исследование данной темы.

Также недавно я писал о моём последнем интервью посвящённому данному исследованию.
MustLive
Цитата
Дело именно в том, ГДЕ ЛЕЖИТ ФИЗИЧЕСКИ та флешка, на которую мы даем ссылку.
Тогда мы получим куки пользователя для ЭТОГО МЕСТА.

chingachgoog, да, получим кукисы с этого домена (тех атакованных пользователей, которые имели кукисы для данного домена). Это один вектор атаки.

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

Цитата
8-й ИЕ очень умный что ли?

В IE8 Майкрософт добавили анти-XSS фильтр. Поэтому данная атака (в таком виде) и не сработала. Фильтр слабый, о чём секюрити исследователи немало писали в Сети, поэтому его можно будет обойти для данных атак через флешки.

В частности от атак редирекции (на злоумышленные сайты) IE8 не защитит. О данных атаках я писал ранее в этой теме и в своей новой статье (и обращал внимание, что рекомендации Адоба не помогут от данных атак).

Цитата
Не хочет выполнять! Молодец. Говорит "нет доступа", тогда как просто строку в алерт выдает.

Как я уже сказал это обходится (в том числе возможны редиректор атаки). К тому же тот факт, что JS код (без доступа к кукисам) он выполнил, говорит о том, что и с текущим кодом возможны другие XSS атаки (помимо кражи кукисов), что наглядно демонстрирует слабость данного фильтра в IE8.
Русская версия IP.Board © 2001-2017 IPS, Inc.