Table of Contents
В этой статье не будет рассказываться о том, что такое 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:
О результате клика можно догадаться.
ЗЛОКЛЮЧЕНИЕ
Уязвимости были всегда и везде, просто иногда они могут быть в самом неожиданном месте.
Надеюсь, статья была интересна и полезна.