Текст книги "Атака на Internet"
Автор книги: Илья Медведовский
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 12 (всего у книги 27 страниц) [доступный отрывок для чтения: 12 страниц]
В основу данного метода легли некоторые тонкости реализации протокола TCP в различных сетевых ОС: на передаваемый TCP FIN-запрос закрытые порты отвечают пакетом с флагом RST, а открытые порты данное сообщение игнорируют. Однако сетевые ОС фирмы Microsoft таким методом просканировать не удастся, так как в их реализации протокола TCP передача пакета TCP RST в ответ на подобный запрос не предусмотрена. Детально данный метод описал Уриэль Маймон (Uriel Maimon) в Phrack 49, article 15.
Этот метод служит логическим продолжением предыдущих двух методов, отличаясь от них усложнением задачи обнаружения сканирования. Суть его состоит в разбиении TCP SYN– или TCP FIN-запроса на несколько маленьких IP-фрагментов (минимальный размер поля данных в IP-фрагменте 8 байт, следовательно, TCP SYN-запрос, имеющий минимальный размер 20 байт, можно разбить на три фрагмента). Однако у этого метода сканирования может быть незапланированный побочный эффект: некоторые некорректные реализации TCP/IP, получив подобные маленькие IP-фрагменты, вызывают сбой операционной системы.
Большинство UNIX-систем по умолчанию используют TAP IDENT сервис на 113-м порту, задача которого заключается в предоставлении удаленным пользователям информации о существующих на сервере в данный момент соединениях. Входными параметрами TAP-сервера являются
Выходными параметрами TAP-сервера являются сообщения вида
Пример выходных данных TAP-сервера:
6191 , 23 : USERID : UNIX : joe
6191 , 23 : USERID : MULTICS : StJohns.DODCSC.a
6191 , 23 : USERID : OTHER : StJohns.DODCSC.a
6191 , 23 : USERID : TAC : MCSJ-MITMUL
6191 , 23 : USERID : UNIX : a6X#-Yp,3147,2910
6191 , 23 : USERID : OTHER: wewishyouamerrychristmasand
6191 , 23 : ERROR : NO-USER
Подробнее о выходных данных TAP-сервера вы можете узнать в RFC1413, а мы лишь заметим, что для определения активности одного порта на сервере требуется перебор портов клиента
Внимательный читатель, наверное, заметил, что все вышеописанные методы открытого сканирования перечислялись «от простого к сложному». К чему все эти сложности? Ответ очевиден: создатели методов имели вполне понятное желание обойти появляющиеся автоматизированные системы обнаружения сканирования. Поэтому до тех пор, пока не были разработаны все эти методы, имела место «гонка» между системами атаки и системами обнаружения и последовательно появлялись новые (на тот момент) методы сканирования.
Методы «невидимого» анонимного сканированияПервым методом анонимного сканирования является метод, получивший название FTP Bounce Attack (скрытая атака по FTP). Протокол FTP (RFC 959) имеет ряд, как нам кажется, чрезвычайно интересных и недостаточно описанных функций, одна из которых – возможность создания так называемых «proxy» ftp-соединений с FTP-сервера. Если программная реализация FTP-сервера поддерживает режим proxy, то любой пользователь (и анонимный в том числе) может, подключившись к серверу, создать процесс DTP-server (Data Transfer Process – процесс передачи данных) для передачи файла с этого FTP-сервера на любой другой сервер в Internet. Функциональность данной возможности протокола FTP вызывает некоторое сомнение, так как в обычной ситуации ftp-клиент, подключающийся к серверу, передает и получает файлы либо непосредственно от себя, либо для себя. Представить иной вариант действий, на наш взгляд, достаточно сложно, но, видимо, создатели протокола FTP для его «будущего» развития предусмотрели подобную возможность, которая теперь выглядит несколько архаичной и отнюдь не безопасной.
Эта особенность протокола FTP позволяет предложить метод TCP-сканирования с использованием proxy ftp-сервера, состоящий в следующем: ftp-серверу после подключения выдается команда PORT с параметрами IP-адреса и TCP-порта объекта сканирования. Далее следует выполнить команду LIST, по которой FTP-сервер попытается прочитать текущий каталог на объекте, посылая на указанный в команде PORT порт назначения TCP SYN-запрос. Если порт на объекте открыт, то на сервер приходит ответ TCP SYN ACK и FTP-клиент получает ответы «150» и «226», если же порт закрыт, то ответ будет таким:
425. Can't Build Data Connection: Connection Refused
(425. Невозможно установить соединение: в соединении отказано).
Далее в цикле FTP-серверу последовательно выдаются команды PORT и LIST и осуществляется сканирование разных портов.
Данный метод вплоть до конца 1998 года был единственным и поистине уникальным методом «невидимого» анонимного сканирования (уникальным он остается и по сей день). Основная проблема взломщиков всегда состояла в невозможности скрыть источник сканирования, так как требовалось получать ответы на передаваемые запросы. Кроме того, в некоторых случаях межсетевой экран (МЭ) мог фильтровать запросы с неизвестных IP-адресов, поэтому данный метод совершил революцию в сканировании, так как, во-первых, позволял скрыть адрес кракера и, во-вторых, давал возможность сканировать контролируемую МЭ подсеть, используя внутренний расположенный за МЭ ftp-сервер.
Приведем список появляющихся при подключении заставок, генерируемых программами реализации FTP-серверов, которые поддерживают режим proxy и на которых данный метод работает.
220 xxxxxxx.com FTP server (Version wu-2.4(3) Wed Dec 14 ...) ready.
220 xxx.xxx.xxx.edu FTP server ready.
220 xx.Telcom.xxxx.EDU FTP server (Version wu-2.4(3) Tue Jun 11 ...) ready.
220 lem FTP server (SunOS 4.1) ready.
220 xxx.xxx.es FTP server (Version wu-2.4(11) Sat Apr 27 ...) ready.
220 elios FTP server (SunOS 4.1) ready
Следующие версии реализации FTP не поддерживают proxy, и метод соответственно не работает.
220 wcarchive.cdrom.com FTP server (Version DG-2.0.39 Sun May 4 ...) ready.
220 xxx.xx.xxxxx.EDU Version wu-2.4.2-academ[BETA-12](1) Fri Feb 7
220 ftp Microsoft FTP Service (Version 3.0).
220 xxx FTP server (Version wu-2.4.2-academ[BETA-11](1) Tue Sep 3 ...) ready.
220 xxx.unc.edu FTP server (Version wu-2.4.2-academ[BETA-13](6) ...) ready.
Сальвадор Санфилиппо (Salvatore Sanfilippo) из Intesis Security Lab впервые заявил об этом методе 18 декабря 1998 года в конференции BUGTRAQ. Оригинальное название метода Dumb host scan переводится как «сканирование с использованием «немого» хоста». Основные положения, лежащие в основе метода (рис. 5.1), состоят в следующем:
Рис. 5.1. Сканирование методом Dumb host scan с открытым (слева) и закрытым (справа) портом Х на хосте С
• хост отвечает на TCP SYN-запрос TCP SYN ACK, если порт открыт; и TCP RST, если порт закрыт;
• существует возможность узнать количество пакетов, переданных хостом, по параметру ID в заголовке IP;
С каждым переданным пакетом значение ID в заголовке IP-пакета обычно увеличивается на 1.
• хост отвечает TCP RST на TCP SYN ACK и ничего не отвечает на TCP RST.
Естественно, это происходит только в случае «неожиданного» прихода таких пакетов (при ip spoofing, например).
Рассмотрим, как работает данный метод.
Пусть X-Hacker – хост атакующего, откуда осуществляется сканирование, объект В – «тихий» хост (обычный хост, который не будет передавать пакеты, пока происходит сканирование хоста C; таких хостов вполне достаточно в Internet), а хост C – объект сканирования. Хост X-Hacker при помощи, например, утилиты hping контролирует число исходящих от хоста B пакетов по ID из заголовка IP, имеющего вид:
#hping B -r
HPING B (eth0 194.94.94.94): no flags are set, 40 data bytes
60 bytes from 194.94.94.94: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2 ms
60 bytes from 194.94.94.94: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms
60 bytes from 194.94.94.94: flags=RA seq=2 ttl=64 id=+1 win=0 time=91 ms
60 bytes from 194.94.94.94: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
60 bytes from 194.94.94.94: flags=RA seq=4 ttl=64 id=+1 win=0 time=91 ms
60 bytes from 194.94.94.94: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms
Как видно, ID увеличивается с каждым пакетом на 1, следовательно, хост B – именно тот «тихий» хост, который нужен кракеру.
X-Hacker посылает TCP SYN-запрос на порт X хоста С от имени B (автор метода предлагает для этого использовать утилиту hping с его сайта http://www.kyuzz.org/antirez, но можно применять и любые другие программные средства). Если порт X хоста C открыт, то хост C пошлет на хост B ответ TCP SYN ACK (хост C не может знать, что этот пакет на самом деле пришел от X-Hacker). В этом случае объект B в ответ на TCP SYN ACK ответит на C пакетом TCP RST. Если атакующий пошлет на C определенное количество TCP SYN от имени хоста B, то B, получив несколько TCP SYN ACK, ответит столькими же TCP RST, и на хосте X-Hacker будет видно, что B посылает пакеты, следовательно, порт X открыт. Выглядит это следующим образом:
60 bytes from 194.94.94.94: flags=RA seq=17 ttl=64 id=+1 win=0 time=96 ms
60 bytes from 194.94.94.94: flags=RA seq=18 ttl=64 id=+1 win=0 time=80 ms
60 bytes from 194.94.94.94: flags=RA seq=19 ttl=64 id=+2 win=0 time=83 ms
60 bytes from 194.94.94.94: flags=RA seq=20 ttl=64 id=+3 win=0 time=94 ms
60 bytes from 194.94.94.94: flags=RA seq=21 ttl=64 id=+1 win=0 time=92 ms
60 bytes from 194.94.94.94: flags=RA seq=22 ttl=64 id=+2 win=0 time=82 ms
Порт открыт!
В том случае, если порт X хоста C закрыт, то передача на C нескольких TCP SYN-пакетов от имени B вызовет ответный пакет TCP RST. Хост B, получив от хоста C такой пакет, проигнорирует его. Выглядит это так:
60 bytes from 194.94.94.94: flags=RA seq=52 ttl=64 id=+1 win=0 time=85 ms
60 bytes from 194.94.94.94: flags=RA seq=53 ttl=64 id=+1 win=0 time=83 ms
60 bytes from 194.94.94.94: flags=RA seq=54 ttl=64 id=+1 win=0 time=93 ms
60 bytes from 194.94.94.94: flags=RA seq=55 ttl=64 id=+1 win=0 time=74 ms
60 bytes from 194.94.94.94: flags=RA seq=56 ttl=64 id=+1 win=0 time=95 ms
60 bytes from 194.94.94.94: flags=RA seq=57 ttl=64 id=+1 win=0 time=81 ms
Порт закрыт!
Еще один метод или, скорее, способ сканирования объекта, при котором можно остаться анонимным, – сканирование с использованием промежуточного хоста (или цепочки хостов, что еще более надежно). В данном случае предлагаем действовать следующими двумя способами.
Первый способ состоит в использовании анонимных Free Telnet Account (свободный Telnet-доступ) которых в Internet довольно много. При помощи telnet можно, подключившись к данному хосту, от его имени вести сканирование любого хоста в Internet. Для этого пишется небольшой скрипт, который, последовательно изменяя порт назначения, будет выдавать следующую команду: telnet Scan_Host_Name Target_TCP_Port.
Если порт закрыт, telnet вернет сообщение Connection Refused (В соединении отказано) или не вернет ничего. Если же порт открыт, появится заставка соответствующей службы.
Второй способ заключается в использовании любимых всеми кракерами WinGate-серверов. WinGate – это обычная proxy-программа, позволяющая через сервер такого типа выходить в Internet, где можно найти немало WinGate-серверов, администраторы которых разрешают анонимное подключение к ним с любых IP-адресов. Это приводит к тому, что кракер получает прекрасный промежуточный хост, от имени (с IP-адреса) которого, используя различные прикладные службы (telnet, ftp и т. д.), он может вести работу с любыми объектами в Internet, сохраняя при этом полную и столь желанную для него анонимность. WinGate-сервер можно использовать для сканирования по той же «telnet-методике», которая описана выше.
В заключение хотелось бы отметить неадекватную, на наш взгляд, реакцию многих сетевых администраторов, обнаруживших сканирование их сетей: обычно реакция на него практически ничем не отличается от реакции на уже осуществленное воздействие. Да, безусловно, удаленный анализ может являться предвестником атаки, но может и не являться. Сам же по себе он не причиняет никакого вреда и не наносит никакого ущерба объекту. Кроме того, описанные выше методы позволяют взломщику скрыть свой IP-адрес и подставить вместо себя ничего не подозревающего администратора хоста, от имени которого осуществлялось сканирование. Следовательно, обвинять кого-то в попытке сканирования бессмысленно: во-первых, это не атака, а, во-вторых, доказать злой умысел из-за методов «невидимого» сканирования невозможно.
В 1996 году произошел небольшой инцидент, связанный с нашей попыткой сканирования одной из подсетей. Желая узнать, что за хосты находятся в нашей подсети, мы воспользовались последней версией программы SATAN (см. главу 9). В результате наша невинная попытка сканирования была обнаружена бдительным администратором одного из хостов, принадлежащих, видимо, какой-то спецслужбе, и мы получили гневные письма с угрозами скорой хакерской расправы и фразами типа: «Хакер являлся пользователем root и действовал с такого-то хоста». Было довольно смешно читать подобные гневные письма и объяснять, что если бы у нас был злой умысел (хотя откуда он мог взяться?), то уж, наверное, мы бы сделали так, чтобы нас невозможно было вычислить.
Несмотря на то, что эта история довольно старая, но, на наш взгляд, очень поучительная, так как и на сегодняшний день вряд ли что-либо в данной области принципиально изменилось, и сканирование до сих пор многими приравнивается к атаке. Поэтому все желающие осуществлять сканирование должны быть готовы к подобной неадекватной реакции сетевых администраторов.
Глава 6
Причины успеха удаленных атак
«То, что изобретено одним человеком, может быть понято другим», – сказал Холмс.
А. Конан Дойл. Пляшущие человечки
В двух предыдущих главах было показано, что общие принципы построения распределенных ВС позволяют выделить целый класс угроз, характеризующих только распределенные системы. Было введено такое понятие, как типовая угроза безопасности, предложены описание, характеристика, классификация и модели основных типов угроз. Все это позволяет говорить о практической методике исследования безопасности РВС, основой которой является последовательное осуществление угроз всех типов в соответствии с разработанными моделями их реализации. В этой главе подробно рассматриваются основные причины успеха угроз безопасности РВС. Наша цель состоит в том, чтобы сформулировать те принципы и требования, которые ликвидировали бы причины успеха угроз и на основе которых было бы возможно построение распределенной ВС с защищенным сетевым взаимодействием ее удаленных компонент.
Причины успеха угроз безопасности РВСАнализ механизмов реализации типовых угроз безопасности РВС (глава 3) и их практическое осуществление на примере сети Internet (глава 4) позволили сформулировать причины, по которым реализация данных угроз оказалась возможной. Особо отметим, что рассмотренные ниже причины основываются на базовых принципах построения сетевого взаимодействия объектов распределенной ВС.
Для устранения причин атак на инфраструктуру и базовые протоколы сети (см. главу 4) зачастую необходимо либо отказаться от определенных служб (например, DNS), либо изменить конфигурацию системы (наличие широковещательной среды приводит к возможности программного прослушивания канала), либо изменить систему в целом. Причины успеха таких удаленных атак кроются в инфраструктуре распределенной ВС, поэтому создание систематизации причин их успеха представляется весьма важной задачей, решение которой позволит выработать принципы построения защищенного взаимодействия в РВС.
Итак, рассмотрим возможные причины успеха угроз, направленных на инфраструктуру и базовые протоколы распределенных ВС.
В главе 3 была рассмотрена типовая удаленная атака «анализ сетевого трафика». Напомним, что данная атака заключается в прослушивании канала передачи сообщений в сети. Результат этого воздействия – во-первых, выяснение логики работы распределенной ВС и, во-вторых, перехват потока информации, которой обмениваются объекты системы. Такая атака программно возможна только в случае, если кракер находится в сетис физически широковещательной средой передачи данных, как, например, всем известная среда Ethernet (в отличие от Token Ring, которая не является широковещательной, но и не имеет достаточного распространения). Очевидно, что данное воздействие было бы невозможно, если бы у каждого объекта системы для связи с любым другим объектом имелся выделенный канал (вариант физического прослушивания такого канала не рассматривается, так как без специфических аппаратных средств подключение к нему невозможно).
Следовательно, причина успеха данной типовой атаки – наличие широковещательной среды передачи данных или отсутствие выделенного канала связи между объектами РВС.
Как уже подчеркивалось, проблема идентификации и аутентификации субъектов и объектов РВС имеет чрезвычайно важное значение. От ее решения зависит безопасность распределенной ВС в целом. Примеры успешно осуществленных удаленных атак, рассмотренные в предыдущих главах, доказывают, что отсутствие у разработчиков заранее определенной концепции и принципов идентификации объектов РВС оставляют кракеру потенциальную возможность компрометации объектов системы. Стандартными способами компрометации субъектов и объектов РВС являются:
• выдача себя за какой-либо объект или субъект с присвоением его прав и полномочий для доступа в систему (например, типовая угроза «подмена доверенного субъекта или объекта РВС»);
• внедрение в систему ложного объекта, выдающего себя за доверенный объект системы (например, типовая угроза «ложный объект РВС»).
Взаимодействие объектов без установления виртуального канала
Одним из важнейших вопросов, на которые необходимо ответить, говоря об идентификации и аутентификации объектов и субъектов РВС, является вопрос о видах взаимодействия между субъектами и объектами в распределенной ВС. Как отмечалось в главе 3, взаимодействие между субъектами и объектами РВС бывает двух видов:
• с использованием виртуального канала;
• без использования виртуального канала.
Практика показывает, что 99 % взаимодействий между объектами в сети Internet проходит с установлением такого канала (при любом FTP, TELNET-, HTTP-и т. п. подключении используется протокол TCP, а следовательно, создается ВК). Это происходит потому, что взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого соединения объектов РВС: в процессе создания ВК объекты РВС обмениваются динамически вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал. В противном случае для распознавания объектов распределенной системы пришлось бы использовать массив статической идентификационной информации, уникальный для каждого объекта. А это означает, что мы получаем стандартную проблему статического распределения ключей (матрица №N), которая решается только на ограниченном подмножестве объектов, но не в Internet.
Итак, мы показали, что идентификация объектов РВС при отсутствии статической ключевой информации возможна только при взаимодействии объектов с использованием виртуального канала. Следовательно, взаимодействие без установления ВК является одной из возможных причин успеха удаленных атак на РВС.
Однако ошибочно считать распределенную вычислительную систему безопасной, даже если все взаимодействие объектов происходит с созданием ВК. Об этом речь пойдет в следующем разделе.
Использование нестойких алгоритмов идентификации
К сожалению, взаимодействие объектов по виртуальному каналу в распределенной ВС не является панацеей от всех проблем, связанных с идентификацией объектов РВС. ВК – необходимое, но не достаточное условие безопасного взаимодействия. Чрезвычайно важным в данном случае становится выбор алгоритма идентификации при создании виртуального канала. Основное требование, предъявляемое к этим алгоритмам, состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК, не должен позволить атакующему получить итоговые идентификаторы канала и объектов (см. раздел «Причины успеха удаленных атак в сети Internet»). Однако в базовых алгоритмах идентификации, используемых при создании ВК в большинстве существующих сетевых ОС, это требование практически не учитывается. Так, например, в ОС Novell NetWare 3.12-4.1 идентификатор канала – число в диапазоне 0-FFh, идентификатор объекта (рабочей станции или файл-сервера) – также число от 0 до FFh; в протоколе TCP идентификаторами канала и объектов являются два 32-битных числа, формируемых в процессе создания TCP-соединения (см. раздел «Подмена одного из субъектов TCP-соединения в сети Internet»).
Очевидно, что создание виртуального канала с использованием нестойкого алгоритма идентификации не позволяет надежно обезопасить РВС от подмены объектов взаимодействия и выступает в качестве одной из причин успеха удаленных атак на распределенные вычислительные системы.
