Самое простое, что используют злоумышленники: указывают в поле “Reply‑To” адрес, отличный от адреса отправителя. Если жертва не обратит на это обстоятельство внимание[1], то она окажется введена в заблуждение и вполне способна сообщить требуемую информацию. Но это слишком известный примем, представляющий сегодня не более чем исторический интерес.
Защититься от такой атаки можно использованием шифрованных паролей (если клиент и сервер пользователя поддерживают такой сервис), либо же прописыванием IP‑адреса почтового сервера в настойках клиента.
Протокол POP3 разрабатывался в те незапамятные времена, когда никаких секретов в Internet не существовало, и защита электронных почтовых ящиков была столь же символичной, как и примитивные запоры, охраняющие ящики для бумажной почты. Никакой шифровки паролей предусмотрено не было, и они передавались по сети в открытом виде.
Если посчитать время, необходимое для подбора шестисимвольного пароля, состоящего только из заглавных латинских символов, то получится 0+1+262+263+264+265+266 = 321 272 407 секунд или около 3 719 дней[1]. Срок, заведомо нереальный для взлома. Поэтому, злоумышленники практически никогда подбирают пароли. Вместо этого они пытаются похитить их у клиента.
Развитие электронной почты привело к резкому усложнению программного обеспечения. Современный почтовый клиент представляет собой очень сложную систему, поддерживающую несколько протоколов, способную отображать HTML и знающую множество разнообразных алгоритмов кодировки текста. Механизмам же защиты и качеству тестирования кода до сих пор не уделяется должного внимания, поэтому большинство пользователей электронной почты могут быть легко атакованы.
Но настоящей чумой почтовых серверов становятся не злобные взломщики, а вездесущие спамеры. Рассылая письма по десяткам (а порой и сотням) тысяч адресов, они плотно загружают сервер интенсивной работой. Поскольку, все отправляемые письма обрабатываются в порядке «социалистической очереди», пока эта очередь не опустеет (а спамеры создают очень длинную очередь) отправка корреспонденции остальными пользователями становится невозможна. Весьма вероятно, что сервер, не выдержав такой сумасшедшей нагрузки, повиснет.
В том же ноябре 1999 появилось сообщение о наличие аналогичной уязвимости в версиях 3.2x SMTP-шлюза Interscan VirusWall, работающего под управлением Windows NT. На этот раз переполнение буфера происходило во время приветствия сервера командой “HELO” (если это приветствие оказывалось через чур многословным).
Ошибка проявлялась только в том случае, когда команда “DATA” использовалась после задания несуществующего получателя в поле “RCPT TO”. С точки зрения нормального человека такое сочетание не имеет никакого смысла, поэтому разработчикам и в голову не приходило протестировать его. Ошибки подобного типа очень сложно обнаружить как самим разработчикам, так и злоумышленникам. Но злоумышленники часто имеют неограниченное время для бесконечных экспериментов и самых причудливых манипуляций, которые рано или поздно приносят плоды.
Разработчики, использующие в свой программе библиотеки сторонних поставщиков, не всегда проверяют, как поведет себя та или иная функция, обнаружив символ конвейера, особенно если об этом ничего не написано в документации. Похожая проблема возникает и при разработке совместных проектов: один разработчик не может знать всех тонкостей функционирования модулей другого разработчика, а в результате такой нестыковки полученная программа может неявным образом поддерживать конвейер.
Теперь злоумышленник (и не только он – любой пользователь с любого узла) сможет зайти на сервер и, в лучшем случае, оставить администратору свое graffiti (автограф, то есть) на видном месте. В худшем же…
Слово “filename”, стоящее в заголовке, обозначает ни что иное, как имя файла, в который отправитель предлагает записать раскодированный текст. Большинство расшифровщиков не проверяют наличие файла на существование и затирают его содержимое без запроса подтверждения пользователя.
Вскоре после атаки лаз был закрыт, но червь Морриса послужил наглядным доказательством принципиальной возможности атак и стал хорошим стимулом к поиску других, еще никем не обнаруженных ошибок. В том, что они существуют, – никто не сомневался. Так оно и получилось.
Первый громкий прецедент произошел осенью 1988 года, когда по сети расползся червь Морриса. Один из способов распространения заключался в использовании отладочного режима в программе SendMail. Отладочный режим служил для удаленного управления почтовым демоном и позволял выполнить команды, передаваемые в теле письма. Остальное, как говорится, было делом техники. Вирус посылал «затравку» на языке Си с указанием откомпилировать ее и запустить. «Затравка» стирала заголовки почты, способные пролить свет на ее происхождение, и, связавшись с отправителем, «перетягивала» на сервер все остальные модули червя.
В большинстве случаев протокол DNS реализован поверх UDP‑протокола, а протокол UDP работает без установки соединения, принимая пакеты от кого бы то ни было на заданный порт. Для определения личности отправителя предусмотрен специальный идентификатор, который не известен злоумышленнику[1]. Идентификатор представляет собой 16‑битовое значение, поэтому, послав всего лишь 216 пакетов, Ева может быть уверена, что один из них жертва воспримет как ответ от настоящего DNS. А если идентификатор не абсолютно случайное число (как это часто и случается), то количество требуемых попыток существенно уменьшается.
Почтовый сервис – один из древнейших ресурсов Internet, еще в семидесятых годах ставший как объектом, так и орудием атак злоумышленников. Десяток-другой лет назад почтовые сервера содержали огромное количество дыр, некоторые из которых остались открытыми и по сей день.
Библиотека poplib скрывает от пользователя механизмы взаимодействия клиента с POP3‑сервером, однако, значительно упрощает процесс программирования. Минимально функциональная программа, читающая все письма, поступившие к этому моменту в почтовый ящик, может выглядеть так:
При получении почты обычным способом сервер определяет (а некоторых случаях и запоминает) IP‑адрес подключившегося клиента. Но иногда получателю нежелательно раскрывать свой адрес, даже если он динамический. Провайдер, выделяя абоненту IP, запоминает (может запоминать) время, в которое он был выдан и имя пользователя, которому он был выдан. Поэтому, существует возможность установить личность получателя письма.
Обеспечить уникальность помогает привязка ко времени пересылки письма. Некоторые алгоритмы генерации идентификатора позволяют его обратить и узнать время, когда он был выдан. Это позволяет выявить поддельные идентификаторы, а вместе с ними и поддельные поля в заголовке письма.
Получатель, скорее всего, решит, что письмо пришло с сервера mail.pets.ja, и вряд ли обратит внимание на ретрансляторы. Выявление истинного получателя можно значительно затруднить, если не класть письмо непосредственно в почтовый ящик клиента, а переслать его через несколько транзитных серверов. В этом помогут возможности управления маршрутизацией доставки сообщения, поддерживаемые SMTP‑протоколом. Если задействовать несколько десятков узлов и вставить в письмо несколько десятков подложных строк “Received”, то установить истинного отправителя сообщения станет практически невозможно, вернее сказать, нецелесообразно.
Для этого достаточно вставить в заголовок одно (или несколько) полей «Received», например, так “Received: from mail.pets.ja”[1]. Модифицированный вариант smtp.pl находится на прилагаемом к книге диске под именем smtp1.pl, и от оригинального файла отличается следующими строками: