Безопасность электронной почты

Корпоративная переписка всегда интересовала конкурентов, и в связи с этим возникает естественный вопрос: «А как обстоят дела с безопасностью?»

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

ОБЩАЯ ДИСПОЗИЦИЯ

В типичной ситуации отправитель пытается послать письмо Получателю, Злоумышленник - перехватить сообщение. Выбор Злоумышленником методики перехвата зависит от взаимного расположения жертв и атакующего. Ниже мы рассмотрим следующие комбинации.

1. Злоумышленник находится в одном сегменте локальной сети Ethernet либо с Отправителем, либо с Получателем, либо с их почтовым сервером.
2. Отправитель и Получатель находятся в одной локальной сети, к которой злоумышленник имеет доступ через Internet.
3. Отправитель, Получатель и Злоумышленник находятся в различных подсетях, подключенных к Internet.

ПЕРЕХВАТ С ИСПОЛЬЗОВАНИЕМ ШИРОКОВЕЩАТЕЛЬНОЙ ПРИРОДЫ ETHERNET

Уязвимость локальных сетей Ethernet объясняется тем, что они функционируют по принципу множественного доступа (Carrier Sense Multiple Access/ Collision Detection, CSMA/CD) - все устройства взаимодействуют по одной среде, и пакеты одного устройства принимают все остальные. Образно такую схему можно уподобить телеконференции - даже если сообщение направлено к некоему конкретному лицу, его получит каждый подписчик конференции. Разумеется, передача секретных данных по такому каналу невозможна, если, конечно, их предварительно не зашифровать.

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

Единственная проблема, стоящая перед Злоумышленником, - как проникнуть в локальную сеть, да еще и оказаться в одном сегменте с жертвой? Чаще всего атакующий находится вне локальной сети, в лучшем случае имеет к ней доступ через Internet.

ПЕРЕХВАТ ПОЧТЫ С ИСПОЛЬЗОВАНИЕМ УЯЗВИМОСТИ ПОЧТОВОГО СЕРВЕРА

Для атаки почтового сервера Злоумышленник может использовать ошибки его реализации, например, у некоторых серверов в файле /etc/aliases присутствует строка decode: |/usr/bin/uudecode автоматического запуска программы uudecode для распаковки сообщений UUE.

Многие расшифровщики помещают раскодированный текст в файл, указанный в заголовке UUE, допуская его перезапись без запроса подтверждения от пользователя. Если, как часто и бывает, почтовый сервер обладает наивысшими привилегиями, программа uudecode унаследует их при запуске, а Злоумышленник получает возможность перезаписи любого файла в системе.

Например, он может внести в файл /.forward строку вида oot, root@somehost.org, eva@hotmail.ru - для организации дублирования почты администратора на свой собственный адрес.

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

Другая уязвимость заключается в возможности выполнить код на удаленном сервере, используя неявную поддержку конвейера в полях MAIL FROM и RCPT TO у некоторых реализаций почтового сервера. Порой даже сами разработчики не подозревают об этом, поскольку такая возможность не всегда очевидна. Например, команда open языка Perl может не только открывать файл, но и запускать его, если в имени присутствует символ «|», обозначающий вызов конвейера.

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

По этой причине многие почтовые серверы оказываются уязвимы перед тривиальным переполнением стека. Например, в феврале 2000 г., в SMTP - сервере MMDF версии 2.44a-B4, работающей под управлением SCO-UNIX, обнаружилась ошибка переполнения буфера в полях MAIL FROM и RPPT TO, используя которую злоумышленник мог выполнить любой код с привилегиями root. А несколькими месяцами ранее - в ноябре 1999 г., ошибка переполнения была обнаружена в POP3SMTP-сервере ZetaMail версии 2.1. Передаваемый командой PASS пароль помещался в буфер фиксированного размера, и слишком длинная строка не укладывалась в его границы. В ноябре того же 1999 г. появилось сообщение о наличие аналогичной уязвимости в версиях 3.2x SMTP-шлюза Interscan VirusWall, работающего под управлением Windows NT. На этот раз переполнение буфера происходило во время приветствия сервера командой HELLO (если это приветствие оказывалось чересчур многословным). Примерно в то же самое время была выявлена уязвимость POP3-сервера IMAIL. Версии 5.07, 5.05 и 5.06 не контролировали длину имени пользователя, передаваемую командой USER. Такая же участь постигла Avirt Mail Server (версии 3.3a, 3.5). Сообщение о возможности переполнения буфера командой PASS появилось в начале ноября все того же 1999 г. Универсальной защиты от ошибок реализации нет. Администратору можно только посоветовать оперативно устанавливать свежие «заплатки» и обновления.

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

ПЕРЕХВАТ С ИСПОЛЬЗОВАНИЕМ УЯЗВИМОСТИ СЕРВЕРОВ DNS

Не все адресаты находятся в рамках одной локальной сети, и в некоторых случаях с ними приходится связываться через Internet. Для установления соединения с удаленным узлом необходимо знать его IP-адрес, но в адресах электронной почты обычно используются не IP-адреса, а доменные имена почтовых серверов абонентов. Для того чтобы узнать адрес узла по его доменному имени, обычно программа и пользователи обращаются к службе DNS - распределенной базе данных, чаще всего функционирующей на базе протокола UDP.

Такой выбор объясняется тем, что протокол UDP работает без установления соединения и поэтому имеет лучшую производительность по сравнению с TCP. Расплатой за скорость становятся отсутствие контроля доставки пакетов, невозможность определения подлинности отправителя, неспособность противостоять сбоям и выявлять повторяющиеся пакеты.

Узел, получивший пакет UDP, не может достоверно установить его истинного отправителя, следовательно, у Злоумышленника существует возможность послать сообщение от чужого имени. Для перехвата корреспонденции серверу Отправителя достаточно послать фальсифицированное послание, замаскировав его под ответ настоящего сервера DNS. Если сервер не распознает обмана, он установит соединение не с почтовым ящиком Получателя, а с указанным Злоумышленником узлом, и передаст ему сообщение.

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

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

Как пишет Илья Медведовский с соавтором в своей книге «Атака через Internet», «начальное значение «порта отправителя» в UDP-пакете >=1023 и увеличивается с каждым переданным запросом DNS», а «значение идентификатора (ID) запроса DNS устанавливается следующим образом. В случае передачи запроса DNS с хоста оно зависит от конкретного сетевого приложения, вырабатывающего запрос DNS. Эксперименты показали, что если запрос посылается из оболочки командного интерпретатора (SHELL) операционных систем Linux и Windows 95 (например, ftp nic.funet.fi), то это значение всегда равняется единице. Если же запрос DNS передается из Netscape Navigator или его посылает непосредственно DNS-сервер, то с каждым новым запросом сам браузер или сервер увеличивает значение идентификатора на единицу».

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

Злоумышленник должен не только правдоподобно фальсифицировать пакет, но и доставить его жертве раньше, чем та получит ответ от настоящего сервера DNS. Проще всего этого добиться, на какое-то время блокировав сервер DNS Отправителя, к примеру, направив на него шквал запросов DNS, обработка которых должна занять все свободное время сервера, или же попытаться «заблокировать» его каким-нибудь другим способом (а такие способы в арсенале злоумышленников наличествуют в изобилии).

Таким образом, Злоумышленник должен знать не только адреса Отправителя и Получателя, но и адрес сервера DNS Отправителя. А вот это уже представляет определенную проблему! В простейшем случае, когда при отправке используется предоставленный провайдером сервер DNS, выяснить его адрес можно без труда: достаточно осведомиться об этом у провайдера, а его, в свою очередь, можно определить по IP-адресу Отправителя.

Провести атаку на корпоративного пользователя значительно сложнее, поскольку он использует собственный сервер DNS, для надежности закрытый извне межсетевым экраном. Создать непреодолимую защиту теоретически вполне возможно. Первой задачей атакующего станет определение адреса сервера DNS (а точнее, серверов DNS, поскольку их может быть и больше одного). Сканирование IP-адресов на предмет открытого 53 порта предотвращает тот же межсетевой экран, блокирующий прием пакетов с внешних IP-адресов.

Впрочем, с этой проблемой атакующий может справиться («может» следует понимать двояко - т. е. может справиться, а может и не справиться) - любой межсетевой экран без встроенного искусственного интеллекта действует по однажды заложенной в него схеме, а тем временем появляются новые все более и более изощренные алгоритмы сканирования, которые ему не так-то просто будет распознать!

Однако если администратор сети внедрит множество фальшивых серверов DNS, не совершающих никаких действий, кроме «прослушивания» 53-го порта, дезориентированный Злоумышленник будет вынужден либо блокировать их все до единого (при этом не зная наверняка, присутствует ли среди них настоящий сервер DNS), либо атаковать жертву каким-нибудь другим способом.

Даже если Злоумышленник каким-то образом обойдет межсетевой экран, ему неизвестно точное время отправки письма — ведь не может же он бесконечно долго забрасывать Отправителя пакетами: такое поведение быстро обратит на себя внимание и демаскирует атакующего. Если Отправитель отвечает Получателю в абсолютно непредсказуемое время, и у Злоумышленника нет никаких, даже косвенных зацепок, позволяющих хотя бы приблизительно определить время пересылки письма, то ему придется изменить свою тактику и атаковать сам сервер DNS.

Такая возможность базируется на незащищенности взаимодействия серверов DNS друг с другом. Для этой цели используется все тот же уязвимый протокол UDP, не позволяющий установить подлинность отправителя. В общих чертах работа типичного сервера DNS выглядит так: получив запрос клиента, сервер просматривает содержимое своего локального кэша, и в случае отрицательного результата перенаправляет запрос на сервер DNS более высокого уровня. Для ускорения работы его ответ помещается в кэш, и в дальнейшем необходимость прибегать к посторонней помощи отпадает.

Если Отправитель ранее уже отправлял корреспонденцию данному адресату, то адрес узла Получателя давным-давно находится в кэше сервера DNS, и на первый взгляд у Злоумышленника нет никакой возможности подменить его своим. Однако такое предположение не совсем верно. Злоумышленник может воздействовать на содержимое кэша стандартными средствами: посылая множество разнородных запросов, атакующий рано или поздно вытеснит из кэша все старые записи, в том числе и адрес узла Получателя (при этом важно отметить тот факт, что все запрошенные доменные имена должны реально существовать, отсутствовать в кэше, и, наконец, размер кэша не должен быть слишком велик, иначе будет очень трудно, а то и невозможно, добиться его заполнения).

На втором этапе атаки Злоумышленник самостоятельно пошлет серверу DNS запрос, содержащий имя узла получателя, и тут же обрушит на сервер шквал подложных ответов. Если хотя бы один из них будет принят за подлинный, фальшивый адрес попадет в кэш! Здесь, правда, мы молчаливо предполагали, что при каждом запросе DNS Отправитель получает ответ от самого сервера DNS. На практике же, по соображениям производительности, предыдущие запросы могут кэшироваться как узлом самого Отправителя, так и одним из промежуточных хостов на пути к серверу DNS. Однако старая информация не может оставаться в кэше бесконечно долго, так как это привело бы к очевидным проблемам, в частности к невозможности отслеживать изменения адресов доменных имен (такое хоть и редко, но происходит), поэтому хранящиеся в кэше данные периодически «освежаются». Определенными действиями Злоумышленник может ускорить развязку, но, возможно, этого и не потребуется, так как в большинстве случаев срок обновления содержащейся в кэше информации невелик, и если Злоумышленник не очень спешит, то ему нет никакой нужны что-либо предпринимать.

Как оградить себя от таких атак? Теоретически администратор сервера DNS может кое-что предпринять для повышения защищенности своих клиентов. Например, некоторые руководства по безопасности рекомендуют отказаться от использования протокола UDP и перейти на TCP. Протокол TCP выгодно отличается тем, что работает с установлением соединения и позволяет идентифицировать отправителей. Падение производительности компенсируется повышенной защищенностью.

Впрочем, первое, с чем придется столкнуться администратору при переходе на TCP, — отсутствие в документации сведений о том, как такой трюк проделать (правда, на эту тему имеется масса прекрасной литературы). Например, в описании демона named, работающего под управлением Linux, возможность выбора протокола TCP не упоминается вообще! Но даже если администратор сумеет связаться с разработчиками и ценой бессонных ночей научит свой сервер «разговаривать» на TCP, то это не снимет угрозу атаки.

Во-первых, протокол TCP вовсе не такой защищенный, каким кажется. Некоторые программные реализации TCP/IP генерируют предсказуемые идентификаторы, позволяя Злоумышленнику посылать пакеты от чужого имени. Именно это обстоятельство использовал небезызвестный Кевин Митник в своей атаке против Цутомы Шимомуры (сам Цутому по данному поводу сказал следующее: «Проблема не в Кевине, проблема в том, что большинство систем действительно плохо защищено; то, что делал Митник, остается осуществимым и сейчас»). Впервые на указанную уязвимость обратил внимание еще Моррис-старший, опубликовав в февральском номере журнала Bell Labs за 1985 г. (за десятилетие до Митника!) подробный технический отчет по данной проблеме. Но даже сегодня, спустя пятнадцать лет после публикации, она остается актуальной.

Во-вторых, популярные операционные системы содержат одну малоизвестную тонкость (о том, что не все из них умеют формировать запросы TCP к DNS, приходится вообще молчать): посылая запрос DNS, они не знают, по какому именно протоколу работает сервер, и предполагают, что по умолчанию выбран UDP (во всяком случае так настроены LINUX и Windows). Поэтому в названных случаях сеанс обмена начинается с посылки пакета UDP. При нормальном ходе вещей сервер может дать клиенту указание перейти на протокол TCP, но если Злоумышленник сумеет послать жертве подложный ответ раньше, чем это успеет сделать настоящий сервер, то клиент окажется введенным в заблуждение со всеми вытекающими отсюда последствиями.

Тем не менее, несмотря на указанную уязвимость DNS, реализовать такую атаку на практике чрезвычайно затруднительно - слишком много препятствий придется преодолеть взломщику прежде, чем он достигнет цели. Но невысокая вероятность успешной атаки - еще не защищенность! В критических случаях для обеспечения собственной безопасности при соединении с узлом можно использовать его IP-адрес, а не доменное имя.

Если Отправитель пошлет сообщение по адресу: bob@123.456.789.1, никакие манипуляции с сервером DNS не позволят Злоумышленнику перехватить такое письмо, поскольку в этом случае обращений к DNS не происходит! С неудобствами же запоминания ряда бессмысленных цифр вполне можно смириться, особенно если вспомнить, что популярные почтовые клиенты поддерживают адресные книги и автоматически подставляют адрес Получателя по его имени.

Однако такой подход не лишен недостатков. Во-первых, Отправитель скорее всего не знает IP-адреса узла Получателя и будет вынужден обратиться за ним к DNS. А как было показано выше, сервер DNS мог быть атакован Злоумышленником, навязавшим ему ложный IP-адрес доменного имени почтового сервера Получателя.

Во-вторых, с одним доменным именем может быть связано множество IP-адресов. Это позволяет равномерно распределить нагрузку между несколькими серверами и значительно увеличивает надежность системы: если на одном из серверов произойдет сбой, то обработку запросов продолжат все остальные. В принципе отправитель может выбрать какой-то один, понравившейся ему IP-адрес, но это приведет к существенному снижению надежности связи, что в ряде случаев неприемлемо.

Таким образом, лучшее, что можно предпринять, - это установить межсетевой экран, при необходимости перевести сервер DNS на протокол TCP, запретить клиенту DNS принимать пакеты UDP, установить максимально возможный размер кэша DNS для предотвращения его переполнения, не использовать генерирующих предсказуемые идентификаторы реализаций протокола TCP/IP и, по возможности, попросить выполнить эти требования администратора сервера DNS более высокого уровня.

НАРУШЕНИЕ РАБОТОСПОСОБНОСТИ РАБОЧЕЙ СТАНЦИИ ПОЛУЧАТЕЛЯ

Угроза перехвата конфиденциальной корреспонденции - не единственная проблема. Злоумышленник может послать Отправителю особое зловредное сообщение, чтение которого в лучшем случае испортит Отправителю настроение, а в худшем - приведет к краже секретной информации или даже форматированию жесткого диска.

В начале октября 2000 г. некий злоумышленник, имени которого история не сохранила, послал автору этой статьи прелюбопытное письмо, которое, по его замыслу, предназначалось для блокирования работы почтового клиента. В теле сообщения, переданного в формате HTML, присутствовал следующий тривиальный код Java: «while (1) { alert («Hello, Kris I love your!»); }».

При попытке просмотра письма на экране появлялся модальный диалог, до закрытия которого весь интерфейс почтового приложения блокировался. А поскольку диалог выдавался в бесконечном цикле, закрыть его не было никакой возможности (т. е. закрыть-то можно было, но он тут же появлялся вновь). После перезагрузки (или снятия процесса с помощью Alt-Ctrl-Del) и повторного запуска почтового клиента все повторялось вновь. Суть атаки заключалась в том, что для удаления письма приходилось переходить в папку «Входящие», после чего в области предварительного просмотра отображалось последнее полученное сообщение, а вместе с ним запускался зловредный сценарий. Впрочем, автор статьи ничуть не пострадал, поскольку из соображений безопасности машина Java была отключена.

Пришедшее через пару дней сообщение на этот раз открывало в бесконечном цикле множество окон размером миллион на миллион пикселов, что в очень короткое время могло привести к зависанию Windows 9x, но установленная на компьютере автора операционная система Windows NT такую атаку благополучно пережила.

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

Подобные шутки неприятны, но не более того. Куда большую опасность представляют сценарии для кражи секретных файлов с локального диска пользователя. Такие атаки становятся возможны благодаря многочисленным ошибкам в браузерах и виртуальных машинах Java. Даже пятая версия браузера Internet Explorer, последняя на момент написания статьи, запущенная под управлением Windows 2000, остается небезопасной. Вызов windows.open() в сочетании с функцией location() позволяет выполнить апплет Java в контексте локального документа, вследствие чего сценарий Злоумышленника получает доступ к содержимому файла.

Поддержка плавающих форм в Internet Explorer 5.01 (и в некоторых других версиях) реализована с ошибкой. Событие NavigateComplete2, извещающее о завершении перемещения документа на новое место, открывает доступ к нему, даже если документ расположен на локальном диске клиента. Приведенный ниже код демонстрирует чтение файла «C: est.txt» с выводом его содержимого в диалоговом окне:

Но на этом поток ошибок не заканчивается. Злоумышленник может вставить в письмо HTML файл подсказки Windows в формате chm с командами вызова исполняемых файлов, причем последние не обязательно должны находиться на локальном диске жертвы и вполне могут располагаться на компьютере взломщика - ведь благодаря встроенной в Windows поддержке общей межсетевой файловой системы (Common Internet File System, CIFS) различия между локальными и удаленными файлами нивелируются!

Опасность такой атаки заключается в том, что от Отправителя не требуется выполнения никаких дополнительных действий - Получателю достаточно просмотреть содержимое письма, и код Злоумышленника тут же получит управление. На фоне этой угрозы, нашумевший вирус I LOVE YOUR и все прочие насекомые, требующие для своего запуска открытия прикрепленного к письму вложения, выглядят детской игрушкой.

Недавно в Outlook Express 5.х была обнаружена серьезная ошибка, состоящая в том, что слишком длинное поле заголовка письма может переполнить буфер и передать управление коду злоумышленника еще на стадии получения письма с сервера, т. е. задолго до того, как его успеют проверить все существующие антивирусы! Нетрудно вообразить себе, как это могло бы быть использовано расторопными злоумышленниками (окажись они не такими ленивыми)! Впрочем, такая возможность у них еще есть - ведь не все пользователи заботятся об обновлении своих приложений, и уязвимый Outlook Express 5.x до сих пор широко распространен.

В шутку можно сказать: письма, особенно присланные в формате HTML, лучше вообще не читать, а уж тем более, полученные в пятницу, приходящуюся на тринадцатое число тринадцатого месяца.

ПРОНИКНОВЕНИЕ В ПОЧТОВЫЙ ЯЩИК ПОЛУЧАТЕЛЯ

Еще одной целью атаки Злоумышленника может быть почтовый ящик Получателя. Если взломщик сумеет каким-то образом подобрать к нему пароль, то он получит доступ ко всей хранящейся в нем корреспонденции. Первый способ обезопасить себя - использовать очень длинный, бессмысленный, иррегулярный пароль, найти который лобовым перебором Злоумышленник не сможет даже за всю оставшуюся жизнь. Выбирая такой пароль, Получатель должен учитывать, что многие почтовые службы поддерживают опцию «забыли пароль?». В общих чертах суть ее состоит в следующем: регистрируясь в системе, пользователь сообщает некоторую дополнительную информацию о себе, например дату рожденья любимой крысы свой подруги. Если пароль забыт, то, введя эту информацию, можно получить новый. Из самых общих соображений следует: контрольная информация должна быть столько же непредсказуема, как и сам пароль, иначе это облегчит Злоумышленнику проникновение в систему. Например, всевозможных дат в диапазоне между 1950 и 2000 гг. существует немногим более десяти тысяч, и для их перебора не потребуется много времени, поэтому использование какой-либо даты в качестве контрольной информации неразумно!

Предположим, Получатель правильно отнесся к выбору пароля и контрольной информации. Может ли он теперь чувствовать себя в безопасности? Если используемая почтовая служба не содержит ошибок реализации, позволяющих Злоумышленнику получить доступ к содержимому чужих ящиков (вообще-то системы без ошибок сегодня большая редкость), то на первый взгляд ему ничто не угрожает.

Между тем протокол POP3, используемый для доставки почты с сервера на компьютер клиента, передает имя пользователя и пароль в открытом, незашифрованном виде. Злоумышленнику достаточно перехватить сетевой трафик и извлечь соответствующие пакеты. Широковещательная среда локальных сетей Ethernet позволит осуществить эту операцию без труда, а межсегментная атака может быть реализована компрометацией DNS.

В спецификации протокола POP3 можно обнаружить необязательную для реализации команду APOP для шифрования пароля перед его отправкой на сервер. Однако ее поддерживают не все почтовые службы и не все почтовые клиенты. Выяснить, как обстоят дела в конкретном случае можно у администратора системы (например, популярный сервер mail.ru применяет такой метод аутентификации пользователей).

ВЫВОДЫ

Проанализировав сложившуюся ситуацию, приходится констатировать: конфиденциальность электронной переписки на сегодняшний день не гарантируется. Угроза исходит не только от спецслужб, наподобие СОРМ, но и от обычных подростков, вооруженных одним лишь модемом, простеньким персональным компьютером и базовыми техническими знаниями. Все атаки, описанные выше, не представляют никакого секрета и хорошо известны как специалистам по безопасности, так и злоумышленникам. Отсутствие громких прецедентов, связанных с хищением почты, не дает повода надевать розовые очки. В отличие от украшения страничек Web своим графити, перехват корреспонденции происходит незаметно, а жертвам невыгодно разглашать факт свершившейся атаки, особенно если злоумышленникам удалось похитить действительно ценную информацию.

В идеальном случае следовало бы посоветовать отказаться от пересылки почты на удаленные узлы Internet, а если такая операция неизбежна, - обязательно шифровать содержимое послания с помощью таких утилит, как PGP.

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

Строго говоря, любой протокол Internet, основанный на TCP/IP, принципиально уязвим для взлома, а переход на новые защищенные протоколы по некоторым причинам затягивается и происходит не так быстро, как хотелось бы.

В то же время необходимо отметить относительную малочисленность описанных выше атак в связи с трудностями их реализации. Так что не стоит впадать в панику - несмотря на проблемы с безопасностью Internet живет и работает, его защищенность постепенно улучшается.

ПЕРЕХВАТ С ИСПОЛЬЗОВАНИЕМ УЯЗВИМОСТИ ТРАНЗИТНЫХ УЗЛОВ

В идеальном случае сервер отправителя устанавливает прямое соединение с почтовым ящиком получателя и опускает в него конверт. Но такая схема очень редко соответствует реальной действительности. Огромные объемы ежесекундно обрабатываемой корреспонденции заставили разбить процесс доставки сообщений на множество этапов и создать узкоспециализированные узлы, занимающиеся исключительно транспортировкой почты от одного сервера к другому.

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

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

Выяснить маршрут письма можно несколькими способами. Если сервер Отправителя допускает отправку корреспонденции без аутентификации клиента (такие серверы, хотя и редко, но все же встречаются), то Злоумышленник сможет соединиться с ним и послать письмо самому себе. Все промежуточные узлы оставят свои адреса в его заголовке. Не факт, что к Получателю корреспонденция пересылаться тем же самым путем, но адреса первых одного-двух узлов обычно идентичны независимо от конечного получателя.

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

Адрес сервера DNS можно выяснить тривиальным сканированием — большинство крупных транзитных узлов имеют свои собственные серверы DNS, расположенные в той же подсети. Конечно, администратор атакуемого узла мог установить межсетевой экран, препятствующий определению адреса его сервера DNS, но не все промежуточные узлы снабжены такой защитой.

Для обеспечения конфиденциальности переписки Отправителю придется либо полностью отказаться от транзитной пересылки, либо доверять ее только надежным узлам. И то и другое можно реализовать клиентскими средствами, не обращаясь за помощью к администратору. Специальные программы позволяют осуществлять так называемую директивную рассылку. Они не нуждаются в серверах исходящей почты и при отправке сообщения устанавливают соединение непосредственно с почтовым ящиком получателя. Если ни одной такой программы под рукой нет, то на худой конец сойдет и штатный почтовый клиент — достаточно в поле адреса сервера исходящей почты прописать адрес почтового ящика получателя сообщения.

Для переписки с одним лишь Получателем предложенная выше схема вполне приемлема, но если Отправитель переписывается с огромным количеством респондентов, то возникают определенные сложности. Например, ящики некоторых получателей на момент отправки сообщения могут не работать (или работать нестабильно), и отправку корреспонденции придется повторять вновь и вновь. Как возложить эту задачу на чужие плечи и при этом не ухудшить безопасность (вариант нанять секретаря здесь не рассматривается)?

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

В системах UNIX для этой цели использовался лес восклицательных знаков для перечисления всех промежуточных узлов один за другим. Разработчики протокола SMTP заменили восклицательные знаки на удобочитаемые запятые, отчего полный адрес получателя стал выглядеть приблизительно так: «<@one, @two:Bob@mail.ru>», где one и two адреса промежуточных узлов, пересылающих почту друг другу по цепочке. Если ни один промежуточный узел не указан, сервер-отправитель самостоятельно определяет маршрут передачи сообщения. Когда прямое соединение между узлами one и two невозможно, письмо либо возвратится назад к отправителю, либо узел one передаст его через посредника, которого выберет самостоятельно. Т. е. при условии соблюдения стандартов гарантируется, что письмо посетит все перечисленные узлы в указанном порядке, но не факт, что оно пройдет только через перечисленные узлы.

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

Если Отправитель успешно справится с подбором транзитных серверов, то ему останется решить одну маленькую проблему, а именно: отказ популярных почтовых клиентов принять такой адрес, поскольку они посчитают его «неправильным». Выход из ситуации состоит в использовании специализированных клиентов, которых нетрудно найти в сети.