Pochta.ru – Технология взлома.
Вчера один мой знакомый поинтересовался у меня, возможно ли получить доступ к почтовому ящику, прописанному на Почте.ру. Я об уязвимостях этого сервиса на тот момент ничего не знала и поэтому решила посмотреть что там к чему. Зайдя на главную страницу, я тут же заметила первый глюк - счетчик, показывающий количество принятых за день писем был нулевым, в то время как отправленных писем было более десяти тысяч. Зарегистрировав себе ящик, я убедилась, что это был не глюк системы подсчета пересылаемых писем, просто-напросто письма в тот день на Почту.ру вообще не доходили. То же самое я увидела и на следующий день. К чему я клоню? Просто хочу намекнуть тебе, не использовать данную почтовую службу для пересылки почты стратегической важности.
Впрочем, перейдем к делу. Я знала, что человек, в ящик которого нужно было попасть, использует веб-интерфейс для входа, и весьма высока вероятность того, что исполнение javascript'ов в его браузере разрешено. Понятное дело, разумным будет тогда попробовать найти XSS на сайте и угнать его куки. Решив взглянуть на содержимое cookies, которые передает сайт, я обнаружила, что по умолчанию куки не приходят - нужно при входе в ящик разрешить прием плюшек. Повторив вход, таким образом, я обнаружила целых четыре печенюшки, залетевшие мне на комп. Их содержимое меня, в принципе, мало интересовало. По названиям было видно, что там находятся зашифрованные логин и пароль - в общем, все, что нужно для быстрого входа в ящик. Срок их действия составляет аж целый год. Конечно, далеко не каждый пользователь использует подобный способ аутентификации, но все же стоило попробовать.
Баг 1. XSS
Осмотрев свой почтовый ящик, я принялась экспериментировать с ним, разыскивая наличие XSS. Разыскивать долго не пришлось, точнее не пришлось совсем. Представь мое удивление, когда я обнаружила баг уже с первой попытки! Уязвимым оказался сценарий mailbox.php, служащий для перемещений по папкам почтового ящика. Данному скрипту передается параметр mailb, который содержит название папки, в которую необходимо осуществить переход. Если подставить в этот параметр значение, не совпадающее с имеющейся в данном ящике папкой, то получаем переход на несуществующую папку, название которой попадает в html-код странице. Вставив небольшой кусочек javascript-кода в качестве значения mailb, я увидела в выскочившем окошке содержимое своих кукисов:
http://www9.pochta.ru/mailbox.php?id=Nd … t>alert(Document.cookie)</script>
Но, как ты уже видишь, помимо этого скрипту так же передается параметр id, содержащий идентификатор сессии пользователя. Данный параметр, создаваемый при входе в ящик, уникален для каждого входа, и узнать каким он должен быть у человека, который получит ссылку, отравленную XSS, попросту невозможно. Понимая это, я принялась искать брешь там, где данный идентификатор не используется, т.е. за пределами ящика. Но, как и следовало ожидать, ничего не нашла. Возникло предположение, что именно наличием параметра id руководствовались программисты, создавшие скрипт, совершенно не фильтрующий ввод (могли бы хоть спецсимволы запретить). Как оказалось, нет - просто видать не доделали чего-то.
Баг 2. SQL-inj
Если сценарий никак не фильтрует ввод, то и сам параметр id может быть уязвим, решила я. И не ошиблась. Конечно, значения идентификаторов сессий хранятся в БД. Проверим на скуль-иньекцию. Подставив кавычку в конец идентификатора, я вылетела из своего ящика, затем я дописала конструкцию вида "'or'1=1" (без кавычек, ясное дело):
-
Вот тут началось самое интересное - я оказалась в чужом ящике! Это было уже действительно забавно. Немного порывшись в настройках, заглянув на сайт, я задалась вопросом, почему меня перенесло именно на этот ящик? Логика подставленного значения параметра id означает, что в теории я могла попасть на любой из ящиков, для которых в БД хранится идентификатор сессии, т.е. на любой из ящиков, которые в это время кто-нибудь просматривает. Я стала различными способами видоизменять вышеприведенный запрос, в итоге, обнаружив, что "1=1" писать необязательно, достаточно написать просто "1" (или любое число >0). Кроме того, значение идентификатора теперь перестало иметь свой смысл, нужно было оставить только букву "N" в начале (с таким id не получалось зайти на сайт, прилагаемый к данному ящику, но мне это было и не нужно). В итоге, запрос сократился до следующего вида:
-
Набрав эту ссылку в адресной строке браузера, можно было сходу попасть в чей-нибудь ящик. И тут я поняла, что с ящиком, в который я попадаю, все не так просто. Несколько раз обновив страницу в браузере, я заметила, что в ящике появляются новые папки, меняется цвет фона и т.п. Я зашла в папку "Входящие" и начала обновлять страницу. Тут все уже прояснилось - сначала мне казалось, что я попадаю в какой-то конкретный ящик, но на деле все оказалось так, как и диктовала логика запроса - мне были видны письма всех (хотя я в этом до конца не уверена) пользователей, идентифицировавшихся в системе. Причем, обновляя страницу, были видны последние, судя по дате, письма отправляемые/получаемые данной почтовой системой. Правда, оказалось, что прочитать удается далеко не каждое из них. Все это действовало, но весьма глючно.
Теперь у меня возникло еще одно предположение, которое не могло быть неверным: если я начну с таким значением id, вносить какие-то изменения в настройки, создавать папки и т.д., то это отразится и на всех остальных ящиках, для которых в данный момент создан идентификатор сессии. Так оно и оказалось и даже более того: другие пользователи во время моего вмешательства в работу базы данных идентификаторов текущих сессий, при заходе в ящик видели примерно то же, что и я при входе с id=N'or'1. Все это происходило очень весело: кто-то создал папку под названием "Кто_нибудь_знает_что_происходит", и понеслись ответы-предположения. Получился своеобразный чат, где каждый мог выразить свою мысль в названии созданной им папки . После многих кликов на кнопку обновления страницы, я увидела, что ящик, в который я попадаю, все же меняется время от времени на другой (по всей видимости, по истечению действия его id).
После этого я еще несколько раз заходила на сайт Почты.ру с таким значением id в URL. В итоге решила, что не нужно лишний раз палиться, ведь юзеры почты могут отписать админам, и эту багу залатают. А у меня уже возникла идея, как применить ее для решения задачи, которую я изначально ставила перед собой - захвата ящика.
Добываем куки
Итак, мы имеем два уязвимых параметра в скрипте. Сразу приходит на ум идея проэксплуатировать их вместе:
-[здесь скрипт, угоняющий куки]
Отличная идея! Такой ядовитый урл можно кинуть жертве в аську, конечно, надежнее замаскировав его, и куки с почты полетят на твой сниффер, а если быть более точным, прилетят куки всех зашедших на свой ящик пользователей почты. Повозившись немного, я составила следующий xss-сплоит:
-
Здесь, "http://ccl.whiteacid.org/log.php?123456" - адрес сниффера (см. врезку), "%2B" - это знак "+" в url-кодировке (дело в том, что скрипт перед попаданием в тело страницы декодируется из URL-кодировки, и "+" заменяется пробелом). Используемый скрипт далеко не идеален, он открывает сайт почты, а затем переносит на чистую страницу сниффера. Как показала практика, обычно, на это юзеры реагируют нажатием кнопки "обновить" или "назад". Конечно, на загрузку сайта почты, многие отреагируют подозрительно. С подозрением отнесутся и к предложению кликнуть по присланной тобою ссылке, даже по-максимуму замаскированной. И тут мне вспомнилась еще одна вещь, которую я заметила раньше. Фишка в том, что если я вносила javascript-код в тело страницы:
http://www9.pochta.ru/mailbox.php?id=Nd … t>alert('xss')</script>
То при переходе по ссылке
http://www9.pochta.ru/mailbox.php?id=Nd … 5210dca983
он вновь исполнялся. Пока не будет осуществлен выход из ящика, т.е. завершение сессии. Аналогично, запустив вышеописанный сплоит на своем компе, я могла просто переслать ссылку
-
вместо сплоита! Тут даже продвинутый юзер ни о чем не догадается, а если хоть немного владеть СИ, то и подавно.
Угон ящика
После всего этого я составила план похищения ящика:
1. Вступить в контакт с жертвой по icq.
2. Заставить приемами СИ жертву зайти по ссылке - перед этим, самой зайти на сайт по ссылке со сплоитом.
3. Отыскать среди кучи логов запись, принадлежащую жертве, при этом, не прекращая общаться через аську, чтоб тот не успел сообразить, что его поимели.
4. Если куки есть, то это очень круто. Осталось вставить их вместо собственных и зайти в ящик. Времени терять не стоит, нужно будет подсмотреть ответ на секретный вопрос, который хранится в открытом виде (весьма часто встречающаяся недоработка создателей почтовых систем, не так ли . Все. Остается только сменить пароль на почтовый ящик .
ccl.whiteacid.org - это сайт проекта Community cookie logger, представляющего собой общедоступный логгер запросов, аналогичный тому, что висит, например, на Античате. Но, в отличие от многих других подобных проектов, каждый пользователь здесь имеет свой собственный уникальный идентификатор, для которого ведется отдельный лог. Доступ к логу закрыт паролем, поэтому собранная тобою инфа будет доступна тебе одной. В ситуации, когда нет времени/возможности/желания использовать собственный сниффер данный сайт сможет оказать неоценимую помощь.