Илья Медведовский - Атака на Internet

В итоге rsh-сервер на хосте В считает, что к нему подключился пользователь с доверенного объекта А, тогда как на самом деле это атакующий с хоста X-Hacker. И хотя взломщик никогда не получит пакеты с хоста В, он сможет выполнять на нем r-команды.

В заключение авторам хотелось бы привести пример реального инцидента, произошедшего в компьютерном центре Сан-Диего 12 декабря 1994 года, когда взломщик (небезызвестный Кевин Митник) использовал такую схему удаленной атаки. Этот инцидент представляет, как нам кажется, исторический интерес и показывает, что опасности, описанные в нашей книге, являются отнюдь не мнимыми угрозами из Internet, а той реальностью, над которой большинство пользователей просто не задумывается, но которая в любой момент может пожаловать к ним в гости.

Все приведенные ниже сведения взяты из письма эксперта по информационной безопасности Цутому Шимомуры (Tsutomu Shimomura) в различные эхо-конференции.

« From: [email protected] (Tsutomu Shimomura)

Newsgroups: comp.security.misc,comp.protocols.tcp-ip,alt.security

Subject: Technical details of the attack described by Markoff in NYT

Date: 25 Jan 1995 04:36:37 -0800

Organization: San Diego Supercomputer Center

Message-ID: <[email protected]>

NNTP-Posting-Host: ariel.sdsc.edu

Привет с озера Тахо. В статье Джона Маркоффа от 23.01.95 в газете «Нью-Йорк Таймс» и в рекомендациях CERT CA-95:01, кажется, было довольно много путаницы насчет того, что такое на самом деле атака с использованием подмены IP-адреса с целью подмены одного из абонентов соединения.

Имеется в виду статья в New York Times под названием «Data Network Is Found Open To New Threat». Следующая статья была опубликована 28 января 1995 года под названием «Taking a Computer Crime to Heart». Заключительная статья «A Most-Wanted Cyberthief Is Caught In His Own Web» появилась 16 февраля того же года. Time Magazine напечатал две статьи под следующими громкими заголовками: «KEVIN MITNICK'S DIGITAL OBSESSION» и «CRACKS IN THE NET: America's most wanted hacker has been arrested, but the Internet is more vulnerable than ever». Шумиха, поднятая американской прессой по этому поводу, была столь велика, что нам остается только вспомнить крылатую фразу Шекспира: «Много шума из ничего». Хотя это можно объяснить тем, что, во-первых, в США благодаря стараниям прессы сложился образ злобного суперхакера, этакого «монстра» киберпространства – Кевина Митника; во-вторых, это был один из редких случаев обнародования информации о реальной удаленной атаке; в-третьих, ее осуществление удалось проследить и запротоколировать, что обычно очень непросто; и, в-четвертых, с нашей точки зрения, это, пожалуй, единственная известная, и при этом довольно красивая, удаленная атака на TCP-соединение (истории о «тупых» атаках с перехватом пароля или попытками его подбора читателю уже, видимо, надоели).

Здесь приведены некоторые технические подробности из моей презентации 11.01.95 в CMAD 3 в Сономе, Калифорния. Надеюсь, это поможет снять всяческое непонимание природы этих атак.

Для атаки использовалось два различных механизма. Подмена IP-адреса отправителя и математическое предсказание начального значения идентификатора TCP-соединения позволили получить доступ к бездисковой рабочей станции, которая использовалась как X-терминал.

В письмо включен log-файл, полученный с помощью программы tcpdump, с записью всех пакетов, посланных атакующим. Для краткости этот файл приводится с сокращением некоторых несущественных подробностей.

Моя конфигурация:

server = SPARC с ОС Solaris 1, обслуживающий х-terminal;

х-terminal = бездисковая рабочая станция SPARC с ОС Solaris 1;

target = основная цель атаки.

Атака началась 25 декабря 1994 года в 14:09:32. Первые попытки зондирования осуществлялись с хоста toad.com (информация взята из log-файла).

14:09:32 toad.com# finger -l @target

14:10:21 toad.com# finger -l @server

14:10:50 toad.com# finger -l [email protected]

14:11:07 toad.com# finger -l @x-terminal

14:11:38 toad.com# showmount -e x-terminal

14:11:49 toad.com# rpcinfo -p x-terminal

Зондирование системы позволило определить, есть ли у нее другие доверенные системы для дальнейшей атаки. То, что атакующий смог запустить программы showmount и rpcinfo, означало, что он является пользователем root на хосте toad.com.

Через шесть минут мы видим шторм TCP-запросов на создание соединения с адреса 130.92.6.97 на 513-й порт (login) хоста server. При этом основная цель атакующего – этими однонаправленными TCP-запросами переполнить очередь на 513-ом порту сервера так, чтобы он не смог отвечать на новые запросы на создание соединения. Особенно важно, чтобы сервер не смог сгенерировать TCP-пакет с битом RST в ответ на неожиданно пришедший TCP-пакет с битами SYN и ACK.

Шимомура здесь и далее после имени или IP-адреса хоста через точку указывает порт назначения. Поэтому запись server.login означает хост server и порт login (513). Соответственно, например, первая из распечатки log-файла запись 130.92.6.97.600 означает, что пакет передается с IP-адреса 130.92.6.97 с 600-го порта.

IP-адрес 130.92.6.97 атакующий выбрал случайным образом из неиспользуемых адресов (ему не нужно получать пакеты, передаваемые на этот адрес).

14:18:22.516699 130.92.6.97.600 > server.login: S 1382726960:1382726960(0) win 4096

14:18:22.566069 130.92.6.97.601 > server.login: S 1382726961:1382726961(0) win 4096

14:18:22.744477 130.92.6.97.602 > server.login: S 1382726962:1382726962(0) win 4096

14:18:22.830111 130.92.6.97.603 > server.login: S 1382726963:1382726963(0) win 4096

14:18:22.886128 130.92.6.97.604 > server.login: S 1382726964:1382726964(0) win 4096

14:18:22.943514 130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win 4096

14:18:23.002715 130.92.6.97.606 > server.login: S 1382726966:1382726966(0) win 4096

14:18:23.103275 130.92.6.97.607 > server.login: S 1382726967:1382726967(0) win 4096

14:18:23.162781 130.92.6.97.608 > server.login: S 1382726968:1382726968(0) win 4096

14:18:23.225384 130.92.6.97.609 > server.login: S 1382726969:1382726969(0) win 4096

14:18:23.282625 130.92.6.97.610 > server.login: S 1382726970:1382726970(0) win 4096

14:18:23.342657 130.92.6.97.611 > server.login: S 1382726971:1382726971(0) win 4096

14:18:23.403083 130.92.6.97.612 > server.login: S 1382726972:1382726972(0) win 4096

14:18:23.903700 130.92.6.97.613 > server.login: S 1382726973:1382726973(0) win 4096

14:18:24.003252 130.92.6.97.614 > server.login: S 1382726974:1382726974(0) win 4096

14:18:24.084827 130.92.6.97.615 > server.login: S 1382726975:1382726975(0) win 4096

14:18:24.142774 130.92.6.97.616 > server.login: S 1382726976:1382726976(0) win 4096

14:18:24.203195 130.92.6.97.617 > server.login: S 1382726977:1382726977(0) win 4096

14:18:24.294773 130.92.6.97.618 > server.login: S 1382726978:1382726978(0) win 4096

14:18:24.382841 130.92.6.97.619 > server.login: S 1382726979:1382726979(0) win 4096

14:18:24.443309 130.92.6.97.620 > server.login: S 1382726980:1382726980(0) win 4096

14:18:24.643249 130.92.6.97.621 > server.login: S 1382726981:1382726981(0) win 4096

14:18:24.906546 130.92.6.97.622 > server.login: S 1382726982:1382726982(0) win 4096

14:18:24.963768 130.92.6.97.623 > server.login: S 1382726983:1382726983(0) win 4096

14:18:25.022853 130.92.6.97.624 > server.login: S 1382726984:1382726984(0) win 4096

14:18:25.153536 130.92.6.97.625 > server.login: S 1382726985:1382726985(0) win 4096

14:18:25.400869 130.92.6.97.626 > server.login: S 1382726986:1382726986(0) win 4096

14:18:25.483127 130.92.6.97.627 > server.login: S 1382726987:1382726987(0) win 4096

14:18:25.599582 130.92.6.97.628 > server.login: S 1382726988:1382726988(0) win 4096

Хост server на первые восемь запросов генерирует соответственно восемь ответов, после чего очередь переполняется. Хост server периодически будет посылать эти ответы, но так и не дождется на них никакой реакции.

Кстати, наши эксперименты, описанные в разделе «Направленный шторм ложных TCP-запросов на создание соединения», это подтвердили.

Далее мы видим 20 попыток создания соединения с хоста apollo.it.luc.edu на x-terminal.shell. Основная цель этих запросов – определить закон изменения начального значения идентификатора TCP-соединения на хосте x-terminal. Так как значение ISN увеличивается на единицу с каждым вновь посылаемым запросом, следовательно, эти запросы генерирует не ядро сетевой ОС. При этом очередь запросов на хосте x-terminal не переполняется, так как атакующий после каждого запроса передает пакет с битом RST, что означает «закрыть соединение».

14:18:25.906002 apollo.it.luc.edu.1000 > x-terminal.shell: S 1382726990:1382726990(0) win 4096

14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack 1382726991 win 4096

14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0

14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:1382726991(0) win 4096

14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack 1382726992 win 4096

14:18:26.775037 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0

14:18:26.775395 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0

14:18:27.014050 apollo.it.luc.edu.998 > x-terminal.shell: S 1382726992:1382726992(0) win 4096

14:18:27.174846 x-terminal.shell > apollo.it.luc.edu.998: S 2022080000:2022080000(0) ack 1382726993 win 4096

14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R 1382726993:1382726993(0) win 0