Как я написал в своей статье XSS уязвимости в 215000 флеш файлах в ноябре 2008 года, проводя секюрити исследования, я обнаружил в Интернете около 215000 флеш файлов уязвимых к Cross-Site Scripting (на более 200000 сайтах).

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

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

P.S.

В ближайшее время я планирую опубликовать свои новые исследования на тему уязвимых флешек.

MustLive, все же я не понял в чем уязвимость и как она достигается.
Ну допустим во флешке есть код

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

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

chingachgoog

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


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

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

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

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

XSS:


Redirector:

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

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

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


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


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

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


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

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

MustLive, я не особо силен в сетевом скрипте (я делаю в основном локальные флешки и приложения).
Можно попроще для тупых?

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

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


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



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

chingachgoog

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


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


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

Повторю пример XSS атаки:

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


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


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

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

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


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


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

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


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

Чтобы обойти SOP и похитить кукисы с другого домена, для этого можно воспользоваться уязвимостями в браузерах, которые позволяют обходить Same Origin Policy. Подобные уязвимости периодически находят в разных браузерах.

Читаю...



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

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

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

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

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


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


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


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

Наконец-то я допер 
http://kb2.adobe.com/cps/407/kb407748.html

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

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

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

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

chingachgoog

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

Также недавно я писал о моём последнем интервью посвящённому данному исследованию.

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

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


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

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


Как я уже сказал это обходится (в том числе возможны редиректор атаки). К тому же тот факт, что JS код (без доступа к кукисам) он выполнил, говорит о том, что и с текущим кодом возможны другие XSS атаки (помимо кражи кукисов), что наглядно демонстрирует слабость данного фильтра в IE8.