без лишних глаз

3APA3A (WWW.SECURITY.NNOV.RU)

Спецвыпуск: Хакер, номер #072, стр. 072-092-2

ПО ЭТОЙ ПРИЧИНЕ IMAP НЕ БУДЕМ РАЗБИРАТЬ ОТДЕЛЬНО, НО К НЕМУ ОТНОСИТСЯ ВСЕ ТО, ЧТО СКАЗАНО О ПРОТОКОЛЕ POP3.

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

Проблема отсутствия безопасности – не единственная проблема устаревших протоколов. Многие другие вещи так же реализованы на стандартах-затычках. Невозможность передавать бинарные данные в почтовых сообщениях привела к появлению различных способов превращения двоичных данных в текстовые, такие как UUEncode на Unix-системах и BinHex на макинтошах. И все это между собой никак не вязалось. Лишь в 1992 году была принята группа стандартов MIME (Multipurpose Internet Mail Extension), позволяющая передавать по электронной почте данные, отличные от ASCII-текста.

Основными проблемами почтовых протоколов являются:

1 ПРОБЛЕМЫ С АУТЕНТИФИКАЦИЕЙ.

2 ПРОБЛЕМЫ С ВОЗМОЖНЫМ ПЕРЕХВАТОМ СООБЩЕНИЯ ПРИ ДОСТАВКЕ НА СЕРВЕР ИЛИ ОТ СЕРВЕРА.

3 ПРОБЛЕМА ВЕРИФИКАЦИИ ОТПРАВИТЕЛЯ СООБЩЕНИЯ.

[открытый текст.]

Протокол POP3 в своем изначальном варианте предусматривал аутентификацию исключительно в открытом тексте с помощью команд USER и PASS. То есть сеанс аутентификации выглядит примерно следующим образом:

<<+OK 3APA3A/POP3-3.0-beta <8231.1158097553@mail.example.com>

>>USER myusername

<<+OK Password Please

>>PASS mystrongpassword

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

[APOP.]

Конечно, такая аутентификация — это просто счастье для любителей подслушивать чужой трафик. В 1996 году обновленная версия стандарта, RFC 1939, вводит новый дополнительный механизм аутентификации APOP. Очень странный и ни с чем не совместимый - основанный на запросе-ответе (Challenge-Response). Сервер, поддерживающий данный механизм аутентификации, должен выдать в приветствии уникальную строку, заключенную в угловые скобки.

<<+OK 3APA3A/POP3-3.0-beta <8231.1158097553@mail.example.com>

Строка 8231.1158097553@mail.example.com является запросом. Чтобы вычислить ответ, почтовый сервер конкатенирует к этой строке пароль пользователя, вычисляет от полученной строки хэш MD5 и далее дает команду APOP с именем пользователя и получившимся хэшем в 16-ричной кодировке. MD5("8231.1158097553@mail.example.commystrongpassword") = 96551da2fa191305810d14c8945c4085.