Электронная почта и безопасность DNS
 
Автор Крис Касперски (Все статьи)
Опубликовано27.10.2002
Источник http://www.insafe.ru/
РазделХакеры
Просмотров7142
Оцените статью!
  • Рейтинг статьи - 4.00 из 5
  • 1
  • 2
  • 3
  • 4
  • 5
Как-то раз пришло мне письмо. В теле сообщения, переданного в HTML формате, присутствовал следующий тривиальный Java-код: "while (1) { alert ("Hello, KrisnI love you!"); }".

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

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

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

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

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

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

<IFRAME ID="Z"></IFRAME>

<SCRIPT for=Z event="NavigateComplete2(x)">

       alert(x.document.body.innerText);

</SCRIPT>

<SCRIPT>

       Z.navigate("file://c:/test.txt");

</SCRIPT>

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

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

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

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

Проникновение в почтовый ящик получателя

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

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

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

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

Выводы

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

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

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

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

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

Отзывы о статье Электронная почта и безопасность DNS

delta2 [02-05-2006]

GeserX а ты смог бы провести нейрохерургическую операцию?
| | Ответить

Vic [31-03-2006]

странная статья.... какое отношение виртуальная java-машина имеет отношение к javascript'у?!
| | Ответить

GeserX [11-11-2005]

Хорошая статья. Особенно для двух ламеров, высказавшихся под ней (я имею ввиду чайника и СКИФа).
| | Ответить

Смотреть все отзывы (4) / Добавить отзыв
 
Категории
Hardware
SOFT Обозрение
Игры
Общие темы
Операционки
Программирование
Раскрутка сайтов
Сотовые
STAR LABS
Безопасность
Защита от взлома
 
Лучшие авторы
SoftPortal.com
Security Lab
Gray
AMS Software
Павел Ряйкконен
Все авторы
Наш канал на YouTube
Новые Macbook Pro 16" - обнаружены серьезные проблемы! Выпуск нового Huawei Mi Band 4 Pro