TCP ISN prediction: страсти африканские >8-()
Я не удивлюсь, если скоро услышу:
"Эксперты по безопасности были шокированы, узнав,
что FTP можно использовать для передачи файлов..."
Мнение читателя ZDNet
Забавные вещи пишут иногда в одной из любимых мной новостных служб ZDNet...
12 марта мировое сетевое сообщество припугнули страшной-престрашной проблемой в протоколе транспортного уровня стека TCP/IP. Мировое сообщество встретило это курьезное заявление дружным хохотом. "СР" просто не могла не отреагировать на этот триллер с юмористическим уклоном, а сделать это было решено следующим образом: мы публикуем as-is оба материала ZDNet на эту тему, затем — комментарии читателей ZDNet и свои собственные. И, наконец, для тех, кто пока не знает "в чем прикол", на соседней странице предлагается подробнейшее, сугубо техническое описание этой, с позволения сказать, "проблемы".
публикация на ZDNet №1
проблема, выявленная в TCP, стара как мир
специалисты объявили об изъяне в одной из главных программных магистралей интернета
Впрочем, несмотря на распространенное в понедельник предупреждение, эту ошибку вряд ли можно считать новой. Архитекторы интернета еще в 80-х годах понимали, что псевдослучайность выбора INS (Initial Sequence Numbers) может вызвать проблемы, и предупреждали об этом потенциальных последователей. В 1996 году специалисты AT&T передали в Internet Engineering Task Force документ, в котором предлагалось заняться решением этой проблемы.
В понедельник производитель ПО сетевой защиты компания Guardent объявила о том, что она выявила опасную проблему во внутренних механизмах TCP (Transmission Control Protocol), входящего в стандарт TCP/IP, в соответствии с которым происходит передача интернет-трафика в разнородных сетях. Проблема почти идентична той, которая две недели назад была обнаружена в некоторых реализациях ПО Cisco IOS, и связана с тем, каким образом TCP выбирает ISN. Эти произвольные числа, известные только двум машинам, участвующим в каждом сеансе связи TCP, помогают идентифицировать легитимные пакеты и предотвращать возможность вмешательства посторонних данных. Предполагается, что ISN выбирается случайным образом, а каждый последующий пакет содержит порядковый номер, отсчитываемый от ISN, и число передаваемых байтов. Если же ISN выбирается не случайно или если в последовательных сеансах он увеличивается не на случайное число, злоумышленник может определить ISN и перехватить трафик, вставить в поток подложные пакеты и даже вывести из строя веб-сервер.
Однако любой, кто пожелает воспользоваться этой лазейкой, должен проделать колоссальную работу, не говоря уже о том, что выявить машины с этим дефектом очень трудно. Учитывая, что лазейка известна очень давно, вряд ли найдется много реализаций TCP, не учитывающих возможности подобных атак.
"Это теоретическая возможность, ее очень трудно реализовать, — говорит эксперт по защите данных из компании Gibson Research Стив Гибсон (Steve Gibson). — Странно, что об этом заговорили сейчас. Эта проблема стара как мир".
Признавая, что воспользоваться дефектом TCP может только очень опытный крекер, Guardent не сомневается в своевременности своего предупреждения; появление соответствующего набора инструментов в интернете, считает компания, лишь вопрос времени. "Сделать шаг от теории к практике трудно, — говорит вице-президент по исследованиям и разработкам Guardent Джерри Брэди (Jerry Brady). — Но если кто-нибудь создаст такой инструмент, то предпринять атаку сможет и не очень опытный специалист".
Прежде чем сделать публичное заявление, Guardent официально предупредила о проблеме CERT и заинтересованных производителей ПО. "Мы стараемся найти новое решение, — сказал Брэди. — Мы специально не вдаемся в технические подробности проблемы, но готовы сотрудничать с производителями над ее преодолением".
глас народа
За исключением мелких недоразумений с терминологией, на форуме ZDNet на сей раз царило полное единодушие. Приведем лишь несколько сообщений, наиболее точно выражающих общестенное мнение на эту тему (лексика, правописание и пунктуация — авторские).
13.03.01 16:36 mike — Ну дают! Да об этом всегда все знали! Эти дыры пофиксены во всех приличных ОС еще лет 5 тому назад. Небось продать что-нибудь хотят, вот и поднимают волну.
13.03.01 18:31 vlad vul — Эта атака называется TCP hijecking, именно так Кевин Митник ломанул какого-то японца, за что его и поймали. Дыра не пофиксена, и пофиксить ее практически невозможно — нужно вставлять крипто в тсп протокол. Правда в том что совершить это трудно — должно совпасть много условий чтобы дырой можно было воспользоваться. Думаю проблема решится когда на прикладном уровне все протоколы будут шифроваться и авторизоваться.
13.03.01 23:25 TOM — это давно все знали! НУ ДАЕТЕ
14.03.01 06:33 Harry — Все б этим буржуям растаявший снег продавать:))
14.03.01 06:48 eXOR — Блин, круче всего фраза, что эту атаку сможет осуществить только опытный крекер;-))) (прочтение 2 RFC'шек и знание любого языка програмирования — это показатель опытности)
Но наиболее остроумным, да и просто умным мне показалось следующее мнение, с которым мое IMHO полностью солидарно:
14.03.01 06:54 rGlory — Ну дают, уже проблему раздули. Глядишь новую проблему а-ля 2000 высасут из пальца. А "Если же ISN выбирается не случайно..." это вообще перл. Тот, кто это писал — вообще понимал, о чем пишет? Не номер пакета, а криптоключ какой-то. А кто им когда-нибудь говорил, что TCP предоставляет защиту от подмены или конфиденциальность? Номера пакетов были разработаны для защиты от НЕПРЕДНАМЕРЕННОГО искажения данных. Так, например, один и тот же пакет IP может прийти два раза или не в том порядке итд. И со своей задачей TCP справляется. А если нужна защита — так используйте тот же IpSec: и зашифруете и от подмены защититесь, по необходимости.
Если идти и дальше в этом направлении, нужно начинать движение: "Найдена проблема в защите телефонных разговоров!!! Оказывается, если подключиться параллельно к телефонной паре, можно прослушать чужой разговор!!! А если пару обрезать и подключить свой телефон, то можно исказить информацию!!!" Бред какой-то...
..."что выявить машины с этим дефектом очень трудно". Вот это да! Очень трудно выявить машину, на которой стоит TCP/IP:)) Дожились!
Мне понравился комментарий на английском ZDNet: "Я не удивлюсь, если скоро услышу: "Эксперты по безопсности были шокированы, узнав, что FTP можно использовать для передачи файлов".
И что вы думаете? Буквально через 3 дня ZDNet радует нас новым заявлением, почти полностью дублирующим предыдущее, разве что с некоторыми, не менее забавными нюансами и перлами. Вот оно:
публикация на ZDNet №2
TCP-лазейка не блажь, уверяет заклеванный специалист
Спустя два дня после того, как компания Guardent объявила об обнаружении слабого места в защите TCP и тут же подверглась обвинениям в выдаче за новость старой проблемы, автор статьи выступил в защиту правильности своего решения о ее публикации.
Тим Ньюсэм (Tim Newsham), старший специалист Guardent, утверждает, что, хотя обнаруженная в Transmission Control Protocol лазейка очень близка к той, которая в 1985 году была вскрыта другим исследователем, между ними есть несколько важных различий.
Первая проблема, выявленная Робертом Моррисом (Robert Morris) из AT&T, заключалась в том, что номера ISN (Initial Sequence Numbers), генерируемые в начале сеансов TCP для обозначения последовательных пакетов, в принципе предсказуемы и могут использоваться для создания подставного канала связи. После этого многие производители отредактировали свое ПО таким образом, что номера ISN стали увеличиваться на случайное число. Это не позволяет злоумышленнику угадать ISN, однако Ньюсэм обнаружил, что по нескольким сеансам связи TCP между хостами опытный хакер все же может собрать достаточно информации, чтобы определить значение ISN. "Я утверждаю, что и существующие соединения [TCP], даже если они наращиваются случайным образом, все равно недостаточно защищены, — заявил он. — Причем безразлично, случайные это числа или псевдослучайные".
Простого решения нет
В 1996 году специалист из AT&T Стив Белловин (Steve Bellovin) передал в Internet Engineering Task Force предложение по решению проблемы. Однако некоторые производители нашли его слишком ресурсоемким и остановились на методе случайных приращений. Белловин отмечает, что в свете находки Ньюсэма единственным надежным способом защиты сеансов TCP остается шифрование либо использование его поправки, которая предусматривает построение ISN на базе сложной комбинации генерируемых каждой машиной случайных чисел, задаваемой администратором секретной фразы и IP-адресов машин.
В настоящее время Guardent совместно с центром CERT при Университете Карнеги-Меллона и несколькими другими производителями ПО работает над решением этой проблемы.
делаем выводы
Приведенные выше комментарии читателей, а также высказывания по этому поводу других сетевых специалистов и мое личное IMHO вкупе дают следующий "букет" мнений и предположений:
• business style — Guardent либо готовит к выпуску в ближайшее время какое-то решение, либо просто делает себе рекламу таким вот забавным способом.
• philosophic style — разобравшись с проблемой 2000 года, общественность заскучала без "массовго психоза". Свято место пусто не бывает: надо придумать новую напасть, чтоб было над чем поработать ученым, инженерам, программистам, чего попугаться рядовым юзерам и руководящим работникам. Кому это нужно — пока не понятно:)
• cinic style — уровень современных сетевых и security-специалистов очень низок: классиков не читают, но думают, что самые умные:)
• journalistic style — тема информацмонной безопасности — слабое место ZDNet. Перлы в терминологии, слабое понимание предмета, жуткие журналистские штампы типа "изъяна в одной из главных программных магистралей интернета" дискредитируют уважаемое новостное агентство.
• anti-paranoid style — данная проблема была весьма актуальна в те далекие времена непуганных администраторов, когда r-сервисы не использовали никакой аутентификации клиента кроме как по его IP-адресу (подробнее о доверительных отношениях и доверенных хостах — в статье о TCP-hijacking'е). На сегодняшний день такие вещи в системе оставит разве что полный идиот, а таким не место в гордых рядах современных сетевых специалистов. Поскольку в нынешних системах для входа куда бы то ни было требуется хотя бы минимальная аутентификация, остается ничтожная вероятность вклинивания злоумышленника в уже существующее соединение. Но немного подумав, мы приходим к выводу, что для такой атаки, помимо упомянутого уже профессинализма, злоумышленнику потребуется наличие некоторых определенных условий (в зависимости от вида условий он может а) с таким же успехом получить доступ к системе более простым способом и б) ждать их до старости или тратить на это 24 часа в сутки своего драгоценного времени), недюжего везения и неслабых вычислительных мощностей и каналов связи. Опытности и ума тут, как раз таки, особенно не требуется.
По всей видимости именно этой вероятностью и стращает нас компания Guardent. Это их паранойя — пусть ее кормят и лелеят, а мы пока сосредоточимся на вещах более практического свойства.
Alice D. Saemon
alice@nestor.minsk.by
"Эксперты по безопасности были шокированы, узнав,
что FTP можно использовать для передачи файлов..."
Мнение читателя ZDNet
Забавные вещи пишут иногда в одной из любимых мной новостных служб ZDNet...
12 марта мировое сетевое сообщество припугнули страшной-престрашной проблемой в протоколе транспортного уровня стека TCP/IP. Мировое сообщество встретило это курьезное заявление дружным хохотом. "СР" просто не могла не отреагировать на этот триллер с юмористическим уклоном, а сделать это было решено следующим образом: мы публикуем as-is оба материала ZDNet на эту тему, затем — комментарии читателей ZDNet и свои собственные. И, наконец, для тех, кто пока не знает "в чем прикол", на соседней странице предлагается подробнейшее, сугубо техническое описание этой, с позволения сказать, "проблемы".
публикация на ZDNet №1
проблема, выявленная в TCP, стара как мир
специалисты объявили об изъяне в одной из главных программных магистралей интернета
Впрочем, несмотря на распространенное в понедельник предупреждение, эту ошибку вряд ли можно считать новой. Архитекторы интернета еще в 80-х годах понимали, что псевдослучайность выбора INS (Initial Sequence Numbers) может вызвать проблемы, и предупреждали об этом потенциальных последователей. В 1996 году специалисты AT&T передали в Internet Engineering Task Force документ, в котором предлагалось заняться решением этой проблемы.
В понедельник производитель ПО сетевой защиты компания Guardent объявила о том, что она выявила опасную проблему во внутренних механизмах TCP (Transmission Control Protocol), входящего в стандарт TCP/IP, в соответствии с которым происходит передача интернет-трафика в разнородных сетях. Проблема почти идентична той, которая две недели назад была обнаружена в некоторых реализациях ПО Cisco IOS, и связана с тем, каким образом TCP выбирает ISN. Эти произвольные числа, известные только двум машинам, участвующим в каждом сеансе связи TCP, помогают идентифицировать легитимные пакеты и предотвращать возможность вмешательства посторонних данных. Предполагается, что ISN выбирается случайным образом, а каждый последующий пакет содержит порядковый номер, отсчитываемый от ISN, и число передаваемых байтов. Если же ISN выбирается не случайно или если в последовательных сеансах он увеличивается не на случайное число, злоумышленник может определить ISN и перехватить трафик, вставить в поток подложные пакеты и даже вывести из строя веб-сервер.
Однако любой, кто пожелает воспользоваться этой лазейкой, должен проделать колоссальную работу, не говоря уже о том, что выявить машины с этим дефектом очень трудно. Учитывая, что лазейка известна очень давно, вряд ли найдется много реализаций TCP, не учитывающих возможности подобных атак.
"Это теоретическая возможность, ее очень трудно реализовать, — говорит эксперт по защите данных из компании Gibson Research Стив Гибсон (Steve Gibson). — Странно, что об этом заговорили сейчас. Эта проблема стара как мир".
Признавая, что воспользоваться дефектом TCP может только очень опытный крекер, Guardent не сомневается в своевременности своего предупреждения; появление соответствующего набора инструментов в интернете, считает компания, лишь вопрос времени. "Сделать шаг от теории к практике трудно, — говорит вице-президент по исследованиям и разработкам Guardent Джерри Брэди (Jerry Brady). — Но если кто-нибудь создаст такой инструмент, то предпринять атаку сможет и не очень опытный специалист".
Прежде чем сделать публичное заявление, Guardent официально предупредила о проблеме CERT и заинтересованных производителей ПО. "Мы стараемся найти новое решение, — сказал Брэди. — Мы специально не вдаемся в технические подробности проблемы, но готовы сотрудничать с производителями над ее преодолением".
глас народа
За исключением мелких недоразумений с терминологией, на форуме ZDNet на сей раз царило полное единодушие. Приведем лишь несколько сообщений, наиболее точно выражающих общестенное мнение на эту тему (лексика, правописание и пунктуация — авторские).
13.03.01 16:36 mike — Ну дают! Да об этом всегда все знали! Эти дыры пофиксены во всех приличных ОС еще лет 5 тому назад. Небось продать что-нибудь хотят, вот и поднимают волну.
13.03.01 18:31 vlad vul — Эта атака называется TCP hijecking, именно так Кевин Митник ломанул какого-то японца, за что его и поймали. Дыра не пофиксена, и пофиксить ее практически невозможно — нужно вставлять крипто в тсп протокол. Правда в том что совершить это трудно — должно совпасть много условий чтобы дырой можно было воспользоваться. Думаю проблема решится когда на прикладном уровне все протоколы будут шифроваться и авторизоваться.
13.03.01 23:25 TOM — это давно все знали! НУ ДАЕТЕ
14.03.01 06:33 Harry — Все б этим буржуям растаявший снег продавать:))
14.03.01 06:48 eXOR — Блин, круче всего фраза, что эту атаку сможет осуществить только опытный крекер;-))) (прочтение 2 RFC'шек и знание любого языка програмирования — это показатель опытности)
Но наиболее остроумным, да и просто умным мне показалось следующее мнение, с которым мое IMHO полностью солидарно:
14.03.01 06:54 rGlory — Ну дают, уже проблему раздули. Глядишь новую проблему а-ля 2000 высасут из пальца. А "Если же ISN выбирается не случайно..." это вообще перл. Тот, кто это писал — вообще понимал, о чем пишет? Не номер пакета, а криптоключ какой-то. А кто им когда-нибудь говорил, что TCP предоставляет защиту от подмены или конфиденциальность? Номера пакетов были разработаны для защиты от НЕПРЕДНАМЕРЕННОГО искажения данных. Так, например, один и тот же пакет IP может прийти два раза или не в том порядке итд. И со своей задачей TCP справляется. А если нужна защита — так используйте тот же IpSec: и зашифруете и от подмены защититесь, по необходимости.
Если идти и дальше в этом направлении, нужно начинать движение: "Найдена проблема в защите телефонных разговоров!!! Оказывается, если подключиться параллельно к телефонной паре, можно прослушать чужой разговор!!! А если пару обрезать и подключить свой телефон, то можно исказить информацию!!!" Бред какой-то...
..."что выявить машины с этим дефектом очень трудно". Вот это да! Очень трудно выявить машину, на которой стоит TCP/IP:)) Дожились!
Мне понравился комментарий на английском ZDNet: "Я не удивлюсь, если скоро услышу: "Эксперты по безопсности были шокированы, узнав, что FTP можно использовать для передачи файлов".
И что вы думаете? Буквально через 3 дня ZDNet радует нас новым заявлением, почти полностью дублирующим предыдущее, разве что с некоторыми, не менее забавными нюансами и перлами. Вот оно:
публикация на ZDNet №2
TCP-лазейка не блажь, уверяет заклеванный специалист
Спустя два дня после того, как компания Guardent объявила об обнаружении слабого места в защите TCP и тут же подверглась обвинениям в выдаче за новость старой проблемы, автор статьи выступил в защиту правильности своего решения о ее публикации.
Тим Ньюсэм (Tim Newsham), старший специалист Guardent, утверждает, что, хотя обнаруженная в Transmission Control Protocol лазейка очень близка к той, которая в 1985 году была вскрыта другим исследователем, между ними есть несколько важных различий.
Первая проблема, выявленная Робертом Моррисом (Robert Morris) из AT&T, заключалась в том, что номера ISN (Initial Sequence Numbers), генерируемые в начале сеансов TCP для обозначения последовательных пакетов, в принципе предсказуемы и могут использоваться для создания подставного канала связи. После этого многие производители отредактировали свое ПО таким образом, что номера ISN стали увеличиваться на случайное число. Это не позволяет злоумышленнику угадать ISN, однако Ньюсэм обнаружил, что по нескольким сеансам связи TCP между хостами опытный хакер все же может собрать достаточно информации, чтобы определить значение ISN. "Я утверждаю, что и существующие соединения [TCP], даже если они наращиваются случайным образом, все равно недостаточно защищены, — заявил он. — Причем безразлично, случайные это числа или псевдослучайные".
Простого решения нет
В 1996 году специалист из AT&T Стив Белловин (Steve Bellovin) передал в Internet Engineering Task Force предложение по решению проблемы. Однако некоторые производители нашли его слишком ресурсоемким и остановились на методе случайных приращений. Белловин отмечает, что в свете находки Ньюсэма единственным надежным способом защиты сеансов TCP остается шифрование либо использование его поправки, которая предусматривает построение ISN на базе сложной комбинации генерируемых каждой машиной случайных чисел, задаваемой администратором секретной фразы и IP-адресов машин.
В настоящее время Guardent совместно с центром CERT при Университете Карнеги-Меллона и несколькими другими производителями ПО работает над решением этой проблемы.
делаем выводы
Приведенные выше комментарии читателей, а также высказывания по этому поводу других сетевых специалистов и мое личное IMHO вкупе дают следующий "букет" мнений и предположений:
• business style — Guardent либо готовит к выпуску в ближайшее время какое-то решение, либо просто делает себе рекламу таким вот забавным способом.
• philosophic style — разобравшись с проблемой 2000 года, общественность заскучала без "массовго психоза". Свято место пусто не бывает: надо придумать новую напасть, чтоб было над чем поработать ученым, инженерам, программистам, чего попугаться рядовым юзерам и руководящим работникам. Кому это нужно — пока не понятно:)
• cinic style — уровень современных сетевых и security-специалистов очень низок: классиков не читают, но думают, что самые умные:)
• journalistic style — тема информацмонной безопасности — слабое место ZDNet. Перлы в терминологии, слабое понимание предмета, жуткие журналистские штампы типа "изъяна в одной из главных программных магистралей интернета" дискредитируют уважаемое новостное агентство.
• anti-paranoid style — данная проблема была весьма актуальна в те далекие времена непуганных администраторов, когда r-сервисы не использовали никакой аутентификации клиента кроме как по его IP-адресу (подробнее о доверительных отношениях и доверенных хостах — в статье о TCP-hijacking'е). На сегодняшний день такие вещи в системе оставит разве что полный идиот, а таким не место в гордых рядах современных сетевых специалистов. Поскольку в нынешних системах для входа куда бы то ни было требуется хотя бы минимальная аутентификация, остается ничтожная вероятность вклинивания злоумышленника в уже существующее соединение. Но немного подумав, мы приходим к выводу, что для такой атаки, помимо упомянутого уже профессинализма, злоумышленнику потребуется наличие некоторых определенных условий (в зависимости от вида условий он может а) с таким же успехом получить доступ к системе более простым способом и б) ждать их до старости или тратить на это 24 часа в сутки своего драгоценного времени), недюжего везения и неслабых вычислительных мощностей и каналов связи. Опытности и ума тут, как раз таки, особенно не требуется.
По всей видимости именно этой вероятностью и стращает нас компания Guardent. Это их паранойя — пусть ее кормят и лелеят, а мы пока сосредоточимся на вещах более практического свойства.
Alice D. Saemon
alice@nestor.minsk.by
Сетевые решения. Статья была опубликована в номере 04 за 2001 год в рубрике save ass…
