На главную

Библиотека Интернет Индустрии I2R.ru

Rambler's Top100

Малобюджетные сайты...

Продвижение веб-сайта...

Контент и авторское право...

Забобрить эту страницу! Забобрить! Блог Библиотека Сайтостроительства на toodoo
  Поиск:   
Рассылки для занятых...»
I2R » Хакеры и безопасность » Хакеры

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

Евы предназначалось для блокирования работы почтового клиента. В теле сообщения, переданного в HTML формате, присутствовал следующий тривиальный Java-код: "while (1) { alert ("Hello, Kris\nI love your!"); }".

При попытке просмотра письма на экране появлялся модальный диалог до закрытия которого весь интерфейс почтового приложения блокировался. А поскольку диалог выдавался в бесконечном цикле, закрыть его никакой возможности не было (т.е. закрыть-то возможность была, но он тут же появлялся вновь). После перезагрузки (или снятия процесса по 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:\test.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, принципиально уязвим для взлома, а переход на новые защищенные протоколы по некоторым причинам затягивается и происходит не так быстро, как хотелось бы.

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

Крис Касперски
Industrial safety

Другие разделы
Прочие опасности
Вирусы
Хакеры
Киберпреступность
Уязвимость ПО
Новое в разделе
Защита данных
I2R-Журналы
I2R Business
I2R Web Creation
I2R Computer
рассылки библиотеки +
И2Р Программы
Всё о Windows
Программирование
Софт
Мир Linux
Галерея Попова
Каталог I2R
Партнеры
Amicus Studio
NunDesign
Горящие путевки, идеи путешествийMegaTIS.Ru

2000-2008 г.   
Все авторские права соблюдены.
Rambler's Top100