Как был взломан Designforum.ru
Как правило, в приложениях электронной коммерции конфиденциальные данные передаются с использованием протокола SSL. На его основе между Web-броузером и Web-сервером устанавливается зашифрованное соединение, в рамках которого передаваемые данные защищены от прослушивания. При разработке протокола SSL преследовалась единственная цель: обеспечить невозможность перехвата пакетов с помощью сетевых анализаторов пакетов. С использованием этих средств злоумышленники извлекают из передаваемых данных конфиденциальную информацию. Для выявления вторжений протокол SSL является единственным существенным препятствием. В большинстве систем SSL для сбора данных о сетевой деятельности используются средства анализа пакетов. Если передаваемые данные зашифрованы, то их анализ и проверку на "благонадежность" выполнить уже невозможно. Все IDS, работа которых основана на анализе сетевых пакетов, "не замечают" атаки на базе SSL.
Пример:
Чтобы проиллюстрировать "возможности" IDS по выявлению атак, основанных на использовании протокола SSL, рассмотрим пример такой атаки на узел под управле- нием Windows, на котором установлен также Web-сервер IIS 4.0. В рамках примера рассматривается следующая сетевая конфигурация:
• Сервер IIS прослушивает порты 80 и 443 узла 192.168.7.203.
• Система выявления вторжений Snort запущена на узле webspy, прослушивающем тот же cетевой сегмент, в котором находится и узел 192.168.7.203.
• Взломщик # 1 располагается на узле 10.0.0.1.
• Взломщик #2 располагается на узле 10.0.0.2. Против узла 192.168.7.203 было инициировано четыре атаки: две атаки МDАС RDS с узла 10.0.0.1 и две атаки Unicode cmd.exe с узла 10.0.0.2. Надо сказать, что один из хакеров в отличие от второго не пользовался SSL - протоколом. Если просмотреть все записи журнала сервера IIS узла 192.168.7.203 после хакерских атак, можно увидеть, что все Get- запросы были зарегистрированы. Но при этом в журналах системы Snort, запущенной на системе webspy, содержится только две записи (сохранились только те запросы, которые осуществлялись без использования SSL). В итоге, две атаки через безопасный протокол остались ВНЕ поля зрения IDS!
Туннелирование атак посредством протокола SSL
Для реализации НТТР-атак с использованием протокола SSL можно без проблем воспользоваться броузером. Для этого достаточно указать в адресе URL префикс https, а не http. Далее броузер сам позаботится о согласовании параметров SSL-сеанса и шифровании данных. Однако, если для реализации атаки взломщику нужно воспользоваться сценарием или утилитой, в которых отсутствует встроенная поддержка протокола SSL, придется прибегнуть к SSL- туннелированию. Этот метод подразумевает использование специальной программы, которая прослушивает порт 80 и при поступлении на него стандартных НТТР-запросов передает их через зашифрованное SSL- соединение указанному узлу. В рамках такой схемы передаваемые данные будут автоматически шифроваться и передаваться целевой системе. Построить SSL-туннель на базе пакета ОрепSSL совсем несложно, особенно в системе Unix, в которой используется демон inetd. Рассмотрим пример, когда злоумышленник находится на узле 10.0.0.1, а целевой Web -сервер установлен на узле 192.168.7.203 и прослушивает порт 443. Предположим, что взломщик хочет запустить на целевом Web-сервере такую программу поиска изъянов, как Whisker. Для реализации задуманного плана злоумышленник создает SSL- туннель на другой системе, 10.0.0.2. При этом в файл /etc/inetd.conf на узле 10.0.0.2 он добавляет следующую запись: www stream tcp nowait root /usr/sbin/tcpd /tmp/sslconnect.sh Подобное изменение конфигурации приведёт к тому, что демон inetd будет передавать сценарию /tmp/sslconnect.sh весь TCP-траффик, приходящий на порт 80. В файле /tmp/sslconnect.sh содержится примерно такой код: #!/bin/sh openssl s_client -no_tls1 -quiet -connect 192.168.7.203:443 2> /dev/null Поскольку сценарий /tmp/sslconnect.sh запускается демоном inetd, все данные, подающие на ТСР-порт 80, воспринимаются утилитой openssl как данные, поступающие из стандартного входного потока. IР-адрес 192.168.7.203 целевого сервера жестко задан в самом сценарии. Один такой SSL-туннель одновременно можно использовать для взаимодействия только с одной системой. Параметры -no_tls1 -quiet предназначены для подавления вывода на экран заголовков SSL и обхода предупреждений SSL-аутентификации, генерируемых при использовании неподписанных сертификатов узлов. Все возвращаемые утилитой opensll данные отсылаются обратно через входящее ТСР-соединение демона inetd, поскольку сценарий передает все данные в стандартный выходной поток. Теперь в качестве целевого сервера утилиты Whisker взломщик может задать узел 10.0.0,2 и порт 80, а не узел 192.168.7.203. При этом шифрование и передача данных на узел 192.168.7.203, а также передача ответов по адресу 10.0.0.1 будут обеспечиваться SSL-туннелем. Более удачный и надежный SSL.-туннель можно организовать с использованием утилиты stunnel. Ее исполняемую версию для системы Windows, разработанную на базе библиотек OpenSSL, можно найти по адресу http://www.stunnel.org
Что делать, если протокол SSL сводит на нет все попытки выявления вторжений? Простого ответа на этот вопрос не существует, хотя рядом специалистов были предложены различные решения, в которых учитывалась специфика конкретных ситуаций. Оказалось, что наилучший вариант связан с использованием реверсивного НТТP посредника (reverse НТТР ргоху). При этом система выявления вторжений размещается между реверсивным НТТР- посредником И Веб-сервером и позволяет выделять в НТТР-трафике сигнатуры атак. Единственный недостаток такой архитектуры заключается в том, что исходный адрес системы, с которой была инициирована атака, заменяется IР-адресом реверсивного НТТР-посредника. Для получения исходного IР-адреса придется сопоставить журналы НТТР-посредника и IDS.