6[1]В этой статье не будет рассказываться о том, что такое XSS и с чем его едят. Все мы уже большие дяденьки (ну и тётеньки). Это статья о том, что внедрение произвольного кода бывает всегда и везде. Я покажу вам, что к таким видам атак уязвима самая популярная социальная сеть России и СНГ, а так же сайт президента РФ. Уязвимости закрыты и мы можем начать.
Вы всё еще запускаете флешки из браузера? Тогда мы идем к вам.

ВКонтакте

Одной светлой ночью, выпив еще одну кружку кофе, решил заняться поиском XSS уязвимостей. Вбил в Гугль что-то похожее на: filetype:php inurl:”*.php?search=*” и в ответ получил ~ 1 500 000 000 страниц. Каждая третья была уязвима…печально.

Не об этом, изменив свой запрос к «Великому и Могучему» нашёл swf, который отсылал GET запрос в корень сайта.
Недолго думая, изменил запрос и подал на вход данные вида: *.swf?[переменная]=http://127.0.0.1/. Видя ошибку 404 на crossdomain, я ругнулся, но GET запрос ушел на локалхост. Быстро подделав crossdomain, я увидел тот милый alert(). А сейчас несколько подробней.

crossdomain.xml я написал самый банальный:

<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
</cross-domain-policy>

Решив проблему с crossdomain, я увидел следующую картину:

Далее я пытался внедрить теги body, script, но это не вызвало ровным счетом ничего, кроме упадка настроения, а потом-то только до меня допёрло, что ссылки кликабельны!
В итоге теги a, img всё же могли встраиваться в страницу.

HREF, твое время!

Хорошо, ссылки кликабельны, следовательно мы должны использовать href=«javascript:» OR href=«data:,».
Но data нам не поможет, нам же нужен контроль за vk.com (хотя, возможно, можно было получить доступ через window.opener).

Для демонстрации атаки, я решил создать фейк ВКонтакте.
Рука потянулась к консоли и вот уже wget закачал index.html, как нечто, внутри меня, шевельнулось.
Ведь ссылка будет иметь вид:

<a href="javascript: (html код)">click-click</a>

А теперь самое страшное: в js используется два вида кавычек(всем понятно каких), одни мы уже использовали, остались еще одни.
Но как тогда помещать в переменные текстовые данные?
Предположим, вот это наш злокод:

var a="<html><h1>Site.com</h1>\n"+
"<!— Бла-бла-бла -->\n"+ 
"<div id='lga' style='height:231px;margin-top:-22px'>\n"+
"<!—Еще что-то -->\n"+
"</html>";

C точки зрения js, всё нормально, но вот html будет ругаться.

<a href=" javascript: var a="<html><h1>Site.com</h1>
<!— Бла-бла-бла --> 
<div id="lga" style='height:231px;margin-top:-22px'>
<!—Еще что-то -->
</html>"; ">FAIL</a>


Но тут нужно вспомнить ASCII.
Кодируем символы в ASCII и наш код приобретает совсем другой вид, браузер не ругается на синтаксис и код работает (мини-хак такой).

Осталось только разместить crossdomain.xml и наш фейк в корне сайта.

Перенаправляем пользователя на нашу ссылку:

И получаем логин и пароль:

Исправили же уязвимость, как мне кажется, добавив пару строк в .htaccess, но уязвимость всё еще жива, Flash’ку не поправили, хотя я её декомпильнул и fla файл отправил.


Павел смотрит на нас свысока, что-то не так…

А мы просто создаём html страничку и встраиваем в нее swf файл.

Кремлин.ру

Так же, как и Вконтакте, Кремлин был уязвим. Но тут события развивались немного по-другому.

XML бредни

Итак, в нашем расположении было аж две уязвимые флешки.
Схема работы была аналогична схеме ВКонтакте:
SWF –> GET /crossdomain.xml –> GET /file

На вход они просили путь до xml файла, обрабатывали его и отмечали данные с xml на картинке.

Поддельный xml выглядел так:

За секунду до клика…

И вот он, alert мечты:

Второй алерт, флешка №2:

XML:

О результате клика можно догадаться.

ЗЛОКЛЮЧЕНИЕ

Уязвимости были всегда и везде, просто иногда они могут быть в самом неожиданном месте.
Надеюсь, статья была интересна и полезна.

By Ruslan Novikov

Интернет-предприниматель. Фулстек разработчик. Маркетолог. Наставник.