Cool Folders ® :: Форум Компью@Нет

Конец дней!

№ 1

Автор: Дядя Федор
Дата : 23-04-04, Птн, 07:32:45

Обнаружена брешь в TCP, способная привести к концу Интернета

Конец дней!

№ 2

Автор: Тигра
Дата : 23-04-04, Птн, 07:38:23

ну это ещё на 16 делить надо. тем более что мы на виндах сидим так что личные компы не пострадают

Конец дней!

№ 3

Автор: Дядя Федор
Дата : 23-04-04, Птн, 08:25:59

Автор: Тигра
Дата : 23-04-04, Fri, 14:38:23

ну это ещё на 16 делить надо. тем более что мы на виндах сидим так что личные компы не пострадают

ты сам понял что сказал? причем тут винды и персональные компы? статья то вообще не про это... там говорилось о судьбе глобальной сети и о том что дыра в протоколе TCP дает возможность завалить любой сервер, если завалят раутеры и корневые DNS то как ты в сеть зайдешь? у тя же не один URL не откроется!
в мире существует всего 13 корневых серверов DNS (ну и зеркала еще), без которых Интернета просто НЕ БУДЕТ!!! читай тут
без DNS сервера сохраниться возможность обработки IP адресов - но как быть с переадресовкой?

Общие сведения о системе доменных имен

[ 23-04-04, Fri, 15:30:16 Отредактировано: Дядя Федор ]
[ 23-04-04, Fri, 15:41:07 Отредактировано: Дядя Федор ]

Конец дней!

№ 4

Автор: Tarlog
Дата : 23-04-04, Птн, 10:40:12

TCP Net threat overstated, says security researcher

VANCOUVER, British Columbia--Widespread reports about a flawed communications protocol making the Internet vulnerable to collapse were overblown, according to the researcher credited with uncovering the security problem.

A flaw in the most widely used protocol for sending data over the Net--TCP, or the Transmission Control Protocol--was addressed by most large Internet service providers during the last two weeks and presents little danger to major networks, said Paul Watson, a security specialist for industry automation company Rockwell Automation. If left unfixed, the weakness could have allowed a knowledgeable attacker to shut down connections between certain hardware devices that route data over the Net.

"The actual threat to the Internet is really small right now," Watson said on Wednesday. "You could have isolated attacks against small networks, but they would most likely be able to recover quickly."

Watson was responding to news reports that ran Tuesday, after Britain's national emergency response team, the National Infrastructure Security Co-ordination Centre, released an advisory about the issue based on his research. Watson, who's scheduled to present that research here at the CanSecWest 2004 conference this week, referred to the media reaction as an "inordinate level of attention in respect to the amount of risk."

At greatest risk, he said, may be e-commerce sites that manage their own routers--those sites may not believe they're vulnerable to attack and may not have implemented a fix. Sites that have routers that share information on the most efficient paths through the Internet--using the Border Gateway Protocol, or BGP--are most vulnerable to the attacks.

http://www.linuxsecurity.com/articles/network_security_article-9217.html

Конец дней!

№ 5

Автор: Тигра
Дата : 23-04-04, Птн, 11:19:13

Автор: Дядя Федор
Дата : 23-04-04, Fri, 15:25:59

Автор: Тигра
Дата : 23-04-04, Fri, 14:38:23

ну это ещё на 16 делить надо. тем более что мы на виндах сидим так что личные компы не пострадают

ты сам понял что сказал? причем тут винды и персональные компы? статья то вообще не про это... там говорилось о судьбе глобальной сети и о том что дыра в протоколе TCP дает возможность завалить любой сервер, если завалят раутеры и корневые DNS то как ты в сеть зайдешь? у тя же не один URL не откроется!
в мире существует всего 13 корневых серверов DNS (ну и зеркала еще), без которых Интернета просто НЕ БУДЕТ!!! читай тут
без DNS сервера сохраниться возможность обработки IP адресов - но как быть с переадресовкой?

Общие сведения о системе доменных имен

Я имел ввиду что у людей сидящих на виндах нету угрозы что какой-то хакер залезет кним на комп. А то что есть угроза для сети, это понятно но я думаю что люди нашедшие проблемму знают и её решение, и они просто хотят всех напугать что-бы больше бабок сорвать.

Конец дней!

№ 6

Автор: Tarlog
Дата : 23-04-04, Птн, 11:51:29

Я тут потратил несколько минут на чтение этой статьи, а также очень быстрое чтение первоисточников на которые статья ссылается. Кстатие, оригинал статьи лежит на lenta.ru, которую при всем моем уважении к Антону Носику, нельзя назвать солидным изданием. В любом случае человек писавший статью ничего вообще в ТСР не понимает.
Цитата:

Уотсон нашел, что можно прерывать информационные потоки, удаленно вызывая перезагрузку роутера или любого другого компьютера.

Теперь вот, что нашел Уотсон:

The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.

Другими словами можно "прерывать информационные потоки", но вовсе не перезагрузкой компьютеров, да и вызвать перезагрузку нельзя, можно только прервать поток.
При этом компьютер будет функционировать. Более того все остальные потоки будут жить, да и этот поток будет восстановлен спустя несколько секунд-минут (зависит от настроек).

Более того, даже прервать поток можно только с вероятностью около m/2^32 (m - размер sliding window). Таким образом при достаточно маленьком m, вероятность того, что поток будет прерван ничтожна.

Вобщем это очень коротко о том, что написанно в оригинале документа, по которому писали статью на ленте.ру. Я его прочитал кусками, но кому не лень: http://www.uniras.gov.uk/vuls/2004/236929/index.htm

Конец дней!

№ 7

Автор: Дядя Федор
Дата : 24-04-04, Сбт, 17:29:47

Автор: Tarlog
Дата : 23-04-04, Fri, 18:51:29

Я тут потратил несколько минут на чтение этой статьи, а также очень быстрое чтение первоисточников на которые статья ссылается. Кстатие, оригинал статьи лежит на lenta.ru, которую при всем моем уважении к Антону Носику, нельзя назвать солидным изданием. В любом случае человек писавший статью ничего вообще в ТСР не понимает.
Цитата:

Уотсон нашел, что можно прерывать информационные потоки, удаленно вызывая перезагрузку роутера или любого другого компьютера.

Теперь вот, что нашел Уотсон:
The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.

Другими словами можно "прерывать информационные потоки", но вовсе не перезагрузкой компьютеров, да и вызвать перезагрузку нельзя, можно только прервать поток.
При этом компьютер будет функционировать. Более того все остальные потоки будут жить, да и этот поток будет восстановлен спустя несколько секунд-минут (зависит от настроек).

Более того, даже прервать поток можно только с вероятностью около m/2^32 (m - размер sliding window). Таким образом при достаточно маленьком m, вероятность того, что поток будет прерван ничтожна.

Вобщем это очень коротко о том, что написанно в оригинале документа, по которому писали статью на ленте.ру. Я его прочитал кусками, но кому не лень: http://www.uniras.gov.uk/vuls/2004/236929/index.htm

Ошибка в TCP представляет угрозу для Сети

Роберт Лемос (Robert Lemos), CNET News.com
21 апреля, 2004, 15:48

Брешь в самом популярном коммуникационном протоколе позволяет злоумышленникам нарушать связи между серверами.

Так утверждается в предупреждении, опубликованном во вторник Британской национальной группой реагирования на компьютерные инциденты.

Протокол передачи данных по интернету ТCP (Transmission Control Protocol) содержит ошибку, которая «зависит от поставщика и приложения, но в некоторых реализациях… оценивается как критическая», утверждается в документе Координационного центра по безопасности национальной инфраструктуры Соединенного Королевства. Производитель сетевого оборудования Juniper Networks пришел к выводу, что его продукты уязвимы. Cisco Systems, Hitachi, NEC и другие изучают проблему, говорится в предупреждении.

Уязвимость позволяет реализовать так называемую reset-атаку. Многие сетевые приложения и программы опираются на работу с непрерывным потоком данных из одного источника — или сеансы, — и преждевременное прерывание сеанса может вызвать самые разнообразные проблемы в устройствах. Специалист по безопасности Пол Уотсон описывает способ, который делает нарушение потока данных значительно более простой задачей, чем считалось прежде.

Предупреждение Центра основано на отчете, который Уотсон намерен представить на этой неделе на конференции CanSecWest 2004 и который, по словам организатора конференции, возможно, уже опубликован NISCC. У Уотсона, который ведет прохакерский блог на Terrorist.net, получить комментарии не удалось.

Проблема связанных с ТСР reset-атак возникала и раньше — участники дискуссии в почтовом списке для крупных сетевых операторов, посвященной данной ошибке, называют ее новостью второй свежести — однако раньше считалось, что атакующий должен знать идентификатор следующего пакета данных в сеансе. Вероятность угадать его — один шанс из 4,3 млрд. Согласно предупреждению NISCC, исследование Уотсона показывает, что можно использовать любое число из определенного диапазона значений, а это значительно повышает вероятность успешных атак.
Эффект от прерывания соединения может быть разным в зависимости от приложения и устойчивости сетевого ПО. При определенных условиях атака может серьезно нарушить работу интернет-маршрутизаторов, выбирающих оптимальный путь передачи данных между серверами. Способ обмена информацией о маршрутах, так называемый Border Gateway Protocol (BGP), опирается на длительные сеансы, и нарушение этих соединений может вызвать «среднесрочную недоступность», говорится в предупреждении.
Ошибка может повлиять и на процесс назначения серверами имен цифровых интернет адресов для определенных доменов, таких как cnet.com. Кроме того, атаки могут использоваться для подрыва электронной коммерции, нарушая работу защищенных каналов связи между браузером и сайтом продавца.

Это не лента.ру

Конец дней!

№ 8

Автор: Дядя Федор
Дата : 24-04-04, Сбт, 17:50:32

Вот кое-что еще

Vulnerability Classification: (Классификация Уязвимостей)
Remote/Network Access Required
Local/Shell Access Required
Denial Of Service Attack (DoS - иными словами отказ в обслуживании или просто ЗАВИСАНИЕ!)
Hijacking Attack (атака захвата!)
Infrastructure Attack (атака инфраструктуры!)
Loss Of Availability
Exploit Available
Verified

Products: (системы подверженные этой атаке)
Cisco IOS All Versions
Microsoft Windows All Versions (!!!! - для тех кто еще не верит)
Linux Linux All Versions
Nokia IPSO All Versions
Hewlett-Packard HP-UX All Versions
Juniper Router All Versions
Check Point FireWall-1 Prior to R55 HFA-03
Cray Unicos All Versions
Internet Security Systems Proventia M Series 1.5

источник тут

Конец дней!

№ 9

Автор: Tarlog
Дата : 25-04-04, Вск, 00:34:22

Дядя Федор
Во первых, первая статья, которую ты дал это таки лента.ру.
Во вторых, в конце своего предыдущего поста я дал линк на ОРИГИНАЛ предупреждения от NISCC. Оно кстатие обновлено 23 апреля.
В третих,не надо устраивать панику, особенно без причины. Атаке теоретически подвержены все аппликации, которые используют ТСР. ОС не важен, будь это Windows, Linux, Solaris или OS/2. Кстатие, если не ошибаюсь, DNS использует не TCP, a UDP. BGP использут TCP, ну так что? Вероятность прервать связь, как я уже писал, m/2^32. Ну хорошо, при достаточно большом m (скажем m=2^5) вероятность составит 1/2^27, что приблезительно равно 1/100,000,000. И это вероятность прервать ОДИН (!!!) поток. Прерывание одного потока скорее всего вообще в сети никто не почувтствует.

Конец дней!

№ 10

Автор: Дядя Федор
Дата : 25-04-04, Вск, 15:24:18

Tarlog
У меня такое ощущение, что ты вообще не читаешь посты...

Во первых, первая статья, которую ты дал это таки лента.ру.

Ссылка на статью для ламеров из первого поста - конечно же с лента.ру, в статье так и написано: "Автор:Lenta.ru", но это никто и не оспаривал!

Во вторых, в конце своего предыдущего поста я дал линк на ОРИГИНАЛ предупреждения от NISCC.

если ты прочитаешь мой второй пост, то обнаружишь там линк на серьезную статью с ZDNet.ru, в которой есть ссылка на оригинальное предупреждение от NISCC, которое, я прочитал от начала до конца.

Атаке теоретически подвержены все аппликации, которые используют ТСР. ОС не важен, будь это Windows, Linux, Solaris или OS/2. Кстатие, если не ошибаюсь, DNS использует не TCP, a UDP. BGP использут TCP, ну так что?

ошибаешься, подключение к DNS происходит как по UDP так и по TCP, порт 53
а вот существенно сокращенный список сервисов использующих протокол TCP:
tcpmux 1 tcp
echo 7 tcp
discard 9 tcp sink null
systat 11 tcp users
daytime 13 tcp
netstat 15 tcp
qotd 17 tcp quote
chargen 19 tcp ttytst source
ftp-data 20 tcp
ftp 21 tcp
telnet 23 tcp
smtp 25 tcp mail
time 37 tcp timserver
whois 43 tcp nicname
domain 53 tcp
mtp 57 tcp
gopher 70 tcp
rje 77 tcp
finger 79 tcp
link 87 tcp ttylink
Supdup 95 tcp
hostnames 101 tcp hostname
iso-tsap 102 tcp
x400 103 tcp
x400-snd 104 tcp
csnet-ns 105 tcp
pop-2 109 tcp
pop-3 110 tcp
sunrpc 111 tcp
sunrpc 111 tcp portmapper
auth 113 tcp authentication
sftp 115 tcp
uucp-path 117 tcp
nntp 119 tcp usenet
ntp 123 tcp
и т.д.

Вероятность прервать связь, как я уже писал, m/2^32. Ну хорошо, при достаточно большом m (скажем m=2^5) вероятность составит 1/2^27, что приблезительно равно 1/100,000,000. И это вероятность прервать ОДИН (!!!) поток.

Цитата: "Его выводы было поначалу высмеяны экспертами, которые заявили, что подобная атака займет от 4 до 142 лет, поскольку требует подбора постоянно меняющегося номера из 4 миллиардов возможных комбинаций, но Уотсон доказал, что вычислит необходимый номер максимум с 4 попыток, затратив на это всего несколько секунд."
еще цитата:"Согласно предупреждению NISCC, исследование Уотсона показывает, что можно использовать любое число из определенного диапазона значений, а это значительно повышает вероятность успешных атак. "

Прерывание одного потока скорее всего вообще в сети никто не почувтствует.

гы!! посмотрим, что ты скажешь если опустят DNS твоего прова!!!

ТщательнЕй надо быть...

Конец дней!

№ 11

Автор: Tarlog
Дата : 26-04-04, Пнд, 02:10:14

Блин, ты вообще знаешь, как работает TCP?
Судя по фраже "гы!! посмотрим, что ты скажешь если опустят DNS твоего прова!!!"
Нет. Там может сходишь и почитаешь RFC793 и RFC1323? И тогда будем спорить хотябы на одном языке.
Теперь для дибилов насчет фразы: "гы!! посмотрим, что ты скажешь если опустят DNS твоего прова!!!"
Если будет прерван ОДИН поток DNS от меня к провайдеру или от провадера дальше, то будет создан НОВЫЙ поток, как только я нажму на кнопку REFRESH. Что конечно вызовет "массу неудобств", я зайду на сайт не с первой, а со второй попытки.

На этом я прекращаю спор, до того момента, когда ты перестанешь ссылаться на пугающие статьи хрен знает откуда, а прочитаешь оригинал NISCC, по которому все эти статьи писались, а также узнаешь (хотя бы приблизительно) как устроено TCP.
************************************************************************
Давайте без личных наездов. Будем соблюдать культуру общения. Иначе...
Модератор.
************************************************************************

[ 26-04-04, Mon, 16:26:57 Отредактировано: Модератор ]

Конец дней!

№ 12

Автор: Tarlog
Дата : 26-04-04, Пнд, 03:01:51

Немного математики:

Уотсон доказал, что вычислит необходимый номер максимум с 4 попыток, затратив на это всего несколько секунд

Что-бы угадать номер с 4 попыток надо, что-бы размер окна был 2^30. Но максимальный рамер окна равен 2^16 (RFC 1323), так что Уотсон ничего подобного доказать не мог. Впрочем в NISCC этой фразы (про 4 попытки) нет. Судя по всему это добавили в русском переводе. В оригинале написано:

The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper “Slipping In The Window: TCP Reset Attacks”, presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or “window”) of the expected sequence number.

В продолжении математики:
Так что даже если использовать максимально возможное окно, вероятность прервать ОДИН поток равна 2^16 = 65,536. Что несколько больше 4.
И кстатие, вероятность того, что checksum не найдет ошибку в пакете тоже равна 2^16...

P.S. Когда я пишу "вероятность", я учитываю только колличество вариантов. Естественно есть какое-то статистическое распределение, которое не учитывается.

[ 26-04-04, Mon, 10:16:00 Отредактировано: Tarlog ]
[ 26-04-04, Mon, 10:38:05 Отредактировано: Tarlog ]

Конец дней!

№ 13

Автор: Дядя Федор
Дата : 27-04-04, Втр, 00:43:24

во-первых сопли вытри и не возбухай сильно...
во-вторых, если ты плохо понимаешь английский - это твои личные проблемы, ведь ты приводишь цитаты из консультативного пособия, как доказательство своей правоты, абсолютно не понимая (или не обращая внимания), на то что там написано. Например:

He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or “window”) of the expected sequence number.

что значит - "Он заметил, что вероятность угадать приемлемый порядковый номер - намного выше чем 1/232, потому что принимающие исполнение TCP примет любой порядковый номер в определенном диапазоне (или “window”) ожидаемого порядкового номера."
далее в том же тексте написано - " Window делает атаки TCP реальными."

Теперь на конкретном примере из того же пособия объясню, какие условия выполняющиеся при тройном рукопожатии, позволяют создать условия для успешной атаки:

"RFC 793, p31 states:

“The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion. To deal with this, a special control message, reset, has been devised. […] If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user.”

TCP window sizes are negotiated in the initial 3-way handshake used to set up a TCP connection, with higher values serving to improve throughput in some circumstances. Vendor-chosen defaults also influence the selection. In any case, the larger the window size, the greater is the probability that a randomly chosen TCP sequence number will lie within the window range. This is the basis for the attack.

A TCP connection is defined by a 4-tuple comprising source and destination IP addresses, and source and destination ports. An attacker seeking to disrupt an existing TCP connection must supply the 4-tuple correctly. As the source port varies, additional work is generally called for on the part of the attacker. However, research (referenced below) has shown that the process of source port selection on many platforms includes predictable elements, so that the attack remains practicable. By weighting 'likely' source port values carefully, an attacker can disrupt TCP implementations that employ a range of window sizes."

для ламеров - к завтрашнему дню, постараюсь перевести весь референс на удобочитаемоваримый русский язык... потому что некоторые граждане просто не врубаются.
при тройном рукопожатии создается окно огромного размера для повышения эффективности подключения, что в немеренное число раз повышает вероятность вычисления порядкового номера сегмента... вот и все, теоритечески просто и логично

Конец дней!

№ 14

Автор: Tarlog
Дата : 27-04-04, Втр, 03:11:42

Во первых, ....
Во вторых, ты мои посты вообще читаешь? В посте №6 я написал: прервать поток можно только с вероятностью около m/2^32 (m - размер sliding window). Чем это отличается от фразы, которую ты выделил красным? Или у тебя проблемы со школьной математикой и ты не знаешь, что чем больше числитель в дроби, тем больше дробь?
В третих, немеренное число раз, вполне меренное. И кстатие в посте №12 я посчитал его МИНИМАЛЬНОЕ значение.
В четвертых, переведи и сам заодно прочитай, прежде чем сеять панику.
В пятых, я НЕ спорю, что прервать ОДИН поток реально. Я спорю, что:
1. Это сделать совсем не просто (Есть НЕ МЕНЕЕ 2^16 вариантов при максимальном размере окна и надо знать оба IP, а также намера портов для данного потока, что тоже не всегда тривиально)
2. Прерывание потока не ведет к падению сервера, а только к прерыванию потока. А достаточно умная аппликация возобновит поток уже через несколько секунд.
3. То, что ты написал:

дыра в протоколе TCP дает возможность завалить любой сервер

есть ПОЛНАЯ ЧУШЬ.

[ 27-04-04, Tue, 12:34:15 Отредактировано: Tarlog ]
[ 27-04-04, Tue, 12:38:11 Отредактировано: Tarlog ]

Конец дней!

№ 15

Автор: Винни
Дата : 28-04-04, Срд, 15:23:46

****************************************************************************************
Последний раз предупреждаю - потом начну блокирвать и вытирать - ПЕРЕСТАНЬТЕ НАЕЗЖАТЬ!!!
****************************************************************************************

А кофе на клавиатуру тоже вирус пролил?

Конец дней!

№ 16

Автор: Дядя Федор
Дата : 29-04-04, Чтв, 20:21:55

Винни...

а никто и не наезжает, просто тут жаркая дискуссия, понимаешь...
Я пытаюсь просто объяснить, что теоретически, существует реальная угроза DoS атак (именно атак на отказ в обслуживании!) на интернет сервера, в связи с выявленной уязвимостью протокола TCP. Об этом собственно и говорится изначально в статье, из-за которой разгорелся весь спор...
а вот обещаный, мой ДОСЛОВНЫЙ перевод Консультативной рекомендации NISCC 236929, если найдете там неточности по сравнению с оригиналом - пишите, проверю..

"NISCC Консультация по уязвимости 236929

Проблемы уязвимости в TCP

Информация Версии

Консультативная рекомендация 236929
Дата Выпуска 20 апреля 2004
Последний пересмотр 27 апреля 2004
Номер версии 1.6

На что воздействует?

Уязвимость, описанная в этой консультации воздействует на выполнение Transmission Control Protocol (TCP), который описан в Internet Engineering Task Force's Просьбы о (IETF'S) Requests For Comments (RFCs) для TCP, включая RFC 793, первоначальная спецификация, и RFC 1323, Расширения TCP для высокоэффективной производительности.

TCP - основной сетевой протокол, используемый сегодня, в большинстве компьютерных систем с сетевой структурой. Множество производителей включают поддержку этого протокола в своих продуктах и могут быть подвержены уязвимости в различной степени. Кроме того, любая сетевая служба или приложение, которые основываются на TCP подключении, будут также уязвимы, степень серьезности зависит, прежде всего, от продолжительности сессии TCP.

Степень серьезности

Воздействие этой уязвимости изменяется, в зависимости от конкретного производителя и приложения, но в некоторых сценариях развертывания, оно оценивается, как критическое. Для полной информации, пожалуйста, см. ниже в разделе производителей. Альтернативно свяжитесь с вашим производителем для конкретной информации о продукте.

При выполнении, уязвимость могла бы позволить нападающему создать условие Отказа в обслуживании (Denial of Service) против существующих подключений TCP, приводя к преждевременному завершению сессии. В результате, завершение сессии затронет прикладной уровень, характер и серьезность эффектов, зависят от протокола прикладной программы. Первичная зависимость в продолжительности подключения TCP, с дальнейшей зависимостью, знания сетевых адресов (IP) вершинных пунктов подключения TCP.

Border Gateway Protocol (BGP), как оценивают, является потенциально наиболее затронутым этой уязвимостью.

BGP полагается на постоянную сессию TCP между конечными точками BGP. Сброс подключения может привести к среднесрочной неготовности, из-за потребности восстановить таблицы маршрутизации и к колебанию маршрута. Колебания маршрута могут привести к сбросу маршрута (подавлению), если колебания маршрута происходят часто в короткий интервал времени. Полное воздействие на BGP, скорей всего, будет соразмерно основано на вероятности успешного нападения. Если TCP MD5 Signature Option и меры anti-spoofing используется, тогда воздействие будет низким, поскольку эти меры успешно смягчат уязвимость.

Существует потенциальное воздействие на другие протоколы прикладных программ, типа DNS (Доменная система имен) и SSL (Secure Sockets Layer) в случае перемещения зон и сделок э-коммерции соответственно, но продолжительность сессий относительно коротка, и сессии могут быть перезапущены без особых проблем с недоступностью. В случае с SSL, может быть трудно предположить исходный IP адрес.

Инъекция данных может быть возможна. Однако это не демонстрировалось и кажется, будет проблематично.

Итого

Проблема, описанная в этой консультации - осуществимость сброса установленного подключения TCP, посредством посылки подходящих пакетов TCP с RST (Reset), или SYN (Synchronise) набором флажков.

Пакеты должны иметь IP адреса источника и адресата, которые соответствуют
установленному подключению, также как исходящие и входящие порты TCP.

Факт то, что сессии TCP могут быть сброшены, при посылке подходящих RST и SYN пакетов - это особенность TCP согласно RFC 793, но reset атака возможна вообще, только потому, что исходный адрес IP и порт TCP могут быть подделанными или "обманными".

Хотя отказ в обслуживании, использующий обработанные пакеты TCP - известная слабость TCP, до недавнего времени полагалось, что успешная атака DoS не достижима практически. Причина для этого - то, что принимающее исполнение TCP проверяет порядковый номер RST или SYN пакета, который является 32-разрядным номером, давая вероятность 1/232 угадать порядковый номер правильно (предположение случайного распределения).

Открывшим осуществимость нападения RST был Пол А. Уотсон, который описывает свои исследование в документе "Slipping In The Window: TCP Reset Attacks", представленном на конференции CanSecWest 2004. Он заметил, что вероятность угадать приемлемый порядковый номер - намного выше, чем 1/232, потому что принимающая реализация TCP примет любой порядковый номер в определенном диапазоне (или "window" ) ожидаемого порядкового номера. Window делает атаки TCP реальными.

Любой протокол прикладной программы, который основывается на долгосрочном подключении TCP и для которого известны адреса IP и порты TCP источника и адресата, можно легко предположить, будет уязвим к, по крайней мере, атакам "отказа в обслуживании".

Детали

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

TCP также обеспечивает номер, называемый "номером подтверждения" (acknowledgement number), который используется, чтобы указать порядковый номер следующего ожидаемого пакета. Пакеты повторно собираются принимающей реализацией TCP только, если их порядковые номера выпадают в пределах диапазона номера подтверждения (называемого "Window" ). Номер подтверждения не используется в RST пакете, потому что сброс не ожидает, что пакет вернется. (Чтобы быть полностью точным, последнее заверение истинно также для RST пакета без набора флажков ACK, который указывает, что порт TCP закрыт, RST/ACK используется, чтобы закончить активное подключение в случае ошибки. В RST/ACK пакете номер подтверждения включен в пакет, хотя это не проверяется принимающей реализацией TCP.)

RFC 793, p36, говорит следующее:

" Во всех состояниях кроме SYN-SENT, весь обновляемые (RST) сегменты, подтверждены проверкой их SEQ-областей [порядковые номера]. Сброс имеет силу, если его порядковый номер находится в окне. В SYN-SENT состоянии (RST, полученный в ответ на начальный SYN), RST приемлем, если поле ACK подтверждает SYN. "

Сбросы должны быть обработаны немедленно. RFC 793, p25, сообщает " […] Даже, когда получающееся окно нулевое, TCP должна обработать поля RST И URG всех входящих сегментов. "

Также возможно выполнить, ту же самую атаку с SYN (synchronise) пакетами. Установленное подключение
прервется, при послании RST, если получит дубликат SYN пакета с начальным порядковым номером в пределах
окна TCP.

RFC 793, p31 сообщает:

" Принципиальная причина для тройного рукопожатия, состоит в том, чтобы помешать двойным инициациям подключения, вызывать неразбериху. Чтобы разобраться с этим, специальным контрольным
сообщением и был изобретен reset. […], если TCP находится в одном из синхронизированных состояний
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), это прерывает подключение
и информирует пользователя. "

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

Подключение TCP определено 4-кортежной величиной IP адресов источника и адресата, и исходящим и принимающим портами. Атакующий, стремящийся прерывать существующее подключение TCP должен снабдить 4 величины правильно. Поскольку исходный порт изменяется, дополнительная работа возлагается на атакующего. Однако, исследование (упомянутое ниже) показало, что процесс исходного выбора порта на многих платформах включает предсказуемые элементы, так, что атака на практике - остается реальностью. Взвесив 'вероятные' значения исходящего порта тщательно, Атакующий может прерывать реализацию TCP, которая использует диапазон размеров окна.

Протоколы прикладного уровня, на которые критически отражается уязвимость, те, которые:

• Зависят от долгосрочных подключений TCP
• Имеют известные или легко угадываемые конечные пункты адресов IP
• Имеют простой, легко предполагаемый исходящий TCP порт

Как отмечено выше BGP использует, долгосрочные подключения TCP, и адрес IP и исходный порт (и порт адресата) иногда доступны с помощью BGP зеркал (мультиисточниковые, мультиадресатные инструментальные средства прослеживания маршрута) или записи ресурса DNS. Использование команд отслеживания маршрута “trace route ” может обеспечить информацией относительно IP адресов спариваемых точек. Таким образом, BGP, вероятно, критически подвержен уязвимости TCP.

Эти DoS атаки могут быть выполнены как одиночной машиной, так и множеством кооперирующих систем (формирование распределенных атак "отказа в обслуживании" ).

Также возможно произвести инъекцию пакетов, которые будут обработаны, если они находятся в окне. Трудность атаки с инъекцией данных состоит в том, что получающая реализация TCP повторно соберет полученные пакеты, согласно номеру последовательности, пропуская любые дубликаты.

Специфическая информация о производителях будет публиковаться, как только станет доступной и если будет получено разрешение производителя. Подписчикам советуется регулярно проверять следующий URL на изменения:

http://www.uniras.gov.uk/vuls/2004/236929/index.htm

[ Пожалуйста, обратите внимание, что об изменениях в этой консультации не будет уведомляться по электронной почте.]

Этой уязвимости было назначено название CVE, CAN-2004-0230.

Open Source Vulnerability Database ID номер для этой уязвимости - 4030.

Смягчение

Следующие шаги по смягчению подверженности, все еще в разработке и могут быть неполными. Клиенты должны сотрудничать с производителями для выработки наиболее соответствующего решения по рассматриваемому продукту.

В отсутствии внесения исправлений производителем в реализацию TCP, вот общие шаги по смягчению:

• Реализуйте защиту IP (IPSEC), которая зашифрует трафик на сетевом уровне, так информация TCP не будет видимой
• Уменьшите размер окна TCP (хотя это может повлечь увеличение потери трафика и последующую перепередачу)
• Не публикуйте информацию об исходящем порте TCP
...."

Дальнейшее описание смягчения воздействия уязвимости и решения на базе конкретных продуктов, мною опущенны, ввиду своей нецелесообразности в данной теме...

[ 30-04-04, Fri, 3:31:02 Отредактировано: Дядя Федор ]

Конец дней!

№ 17

Автор: Dimka
Дата : 30-04-04, Птн, 03:27:44

Я конечно далек от этих вещей конкретно, но из того что я видел за последнее время - если есть возможность что нибудь сломать - злобные хуцкеры это ломают. А так как ничего пока не произошло... может на самом деле не стоит паниковать?

Кстати где то наткнулся на статью о том что уже разработали новую версию ТСР, в которой якобы все недоделки и дыры заделаны. Рега, покопаюсь, может найду статю

Все великие истины начинаются как богохульства
Джордж Бернард Шоу

Конец дней!

№ 18

Автор: BlackChaos
Дата : 30-04-04, Птн, 05:09:31

Очередная попытка выбыть деньги на несуществуюшую проблему! Что-то вроде ошибки 2000 года. Точнее проблема есть, но не настолько опасная. Разберусь окончательно - сообщу подробно.

Через пять минут: Где-то я уже читал подобную вещь, лет 5 назад. Поищу...

Птицу видно по полету, добра молодца - по соплям!
(Народная мудрость)
[ 30-04-04, Fri, 12:13:50 Отредактировано: BlackChaos ]

Конец дней!

№ 19

Автор: Винни
Дата : 30-04-04, Птн, 05:21:22

Дядя Федор - я только за, когда дискуссия хорошая. В данном случае о качестве информации я ничего не говорил, только о форме ее изложения.

А кофе на клавиатуру тоже вирус пролил?

Конец дней!

№ 20

Автор: BlackChaos
Дата : 30-04-04, Птн, 06:16:51

• Не публикуйте информацию об исходящем порте TCP

Вот интересно! Как это автор собирается делать? А куда ответ присылать? Чем больше читаю тем больше понимаю, что это очередной бред!

Птицу видно по полету, добра молодца - по соплям!
(Народная мудрость)

Конец дней!

№ 21

Автор: Дядя Федор
Дата : 30-04-04, Птн, 06:39:58

Проблемы в большинстве существующих реализаций TCP

Позволяют легко осуществить ранее считавшиеся малореальными атаки на отказ с использованием флага RST.
Как известно, при передаче информации по протоколу TCP первым делом происходит установка сессии, формируется некий стартовый номер последовательности (ISN, initial sequence number), который в дальнейшем, последовательно увеличиваясь, присутствует в поле Sequence number каждого передаваемого пакета. Угадывание правильного номера последовательности и использование его в поддельных пакетах - голубая мечта атакующего, омрачаемая необходимостью выбора одного из 2 в 32-й степени вариантов.

TCP является протоколом с гарантией доставки, следовательно, для каждого пакета должно быть получено подтверждение его приема. На самом деле все не совсем так - в TCP используется так называемый механизм скользящего окна, позволяющий более эффективно использовать канал, не дожидаясь подтверждения каждого отправленного пакета. Под окном понимается как раз максимальное количество пакетов, которые могут быть отправлены без подтверждения.

В ответ на несколько полученных пакетов с последовательными номерами получатель возвращает отправителю пакет с установленным флагом ACK, занося в поле Acknowledgement number порядковый номер следующего ожидаемого пакета. Комбинация флагов RST и ACK предназначена для обрыва существующего соединения. Обрабатываться пакет с RST должен немедленно, не дожидаясь прихода других пакетов, для проверки его подлинности, согласно RFC 793, могут использоваться как Sequence, так и Acknowledgement number.

Проблема заключается в том, что при получении такого пакета большинство существующих реализаций TCP проверяют его подлинность только по значению Sequence number, причем значение это проверяется на попадание в диапазон, заданный величиной окна, что резко увеличивает вероятность его угадывания. Таким образом, чем больше размер окна, и чем дольше существует установленная сессия, тем больше шансов у злоумышленника осуществить атаку на отказ, отправляя пакеты с флагом RST и поддельным обратным адресом.

Похоже, что самым подходящим кандидатом на роль жертвы для подобных RST-атак являются маршрутизаторы, использующие протокол BGP (практически самый популярный протокол междоменной маршрутизации), в котором для рассылки обновлений таблиц маршрутизации используются постоянные TCP-соединения. Для уменьшения вероятности подобных атак рекомендуется включить режим использования MD5-подписей, а при отсутствии такой возможности - хотя бы снизить размер используемого окна.
Источник: OSVDB

Конец дней!

№ 22

Автор: Дядя Федор
Дата : 30-04-04, Птн, 07:06:41

а вот уже практическая реализация атаки на базе уязвимости "окна", дело в том, что:
"...При создании новых соединений применяется генератор первоначальных номеров очереди (ISN), который выбирает новые 32 битные значения ISN. Генератор привязан к 32-битным часам (вероятно, фиктивным), чье значение меняется каждые 4 микросекунды. Таким образом, полный цикл часов ISN составляет примерно 4.55 часа. Поскольку мы полагаем, что сегменты будут существовать в сети не более максимального времени жизни сегмента (Maximum Segment Lifetime - MSL), и что MSL меньше, чем 4.55 часа, то мы можем с основанием полагать, что номера ISN будут уникальны.

Для каждого соединения существует номер в очереди отправления и номер в очереди получения. Первоначальный номер в очереди отправления (ISS) выбирается программой TCP, посылающей данные в этой очереди, а первоначальный номер в очереди получения (IRS) выясняется во время установления соединения... " (RFC 793)

притом, диапозон предпологаемых номеров сужается, чем больше первоночальный номер - тем меньше предпологаемых вариантов остается:

"...Важно помнить о том, что количество номеров для очереди, хоть и велико, но ограничено. Диапазон номеров - от 0 до 2**32-1. Поскольку набор ограничен, то все арифметические операции с номерами очередей должны осуществляться по модулю 2**32. Это совсем не означает всякий раз предварительную арифметическую проверку номеров очереди на попадание в диапазон от 2**32-1 до 0..." (RFC 793)

"...Суть уязвимости заключается в возможности для хакера определить идентификационный номер пакета, который передает роутер по сети. Пакеты пересылаются по сети, группируясь по сессиям. Теоретически, если злоумышленник сможет угадать, какой идентификатор у очередного пакета, передающегося в рамках данной сессии, он сможет послать свой пакет, имеющий нужный идентификатор, но несущий деструктивную информацию.

Проблема в том, что определить идентификационный номер пакета очень сложно — для этого нужно сделать 4,3 миллиарда переборов. Однако роутеры, использующие протокол BGP, создают более длительную сессию передачи пакетов, из-за этого подобрать нужный номер становится проще — для этого нужно сделать всего 260 000 переборов. Хакер, сидящий на обычном широкополосном соединении, может осуществить атаку, перебрав 260 000 вариантов идентификацилнного номера пакета за 15 секунд.

Это весьма непросто, но эффективно. Вместо того, чтобы втупую заваливать сервер огромным количеством DDoS-запросов, можно сделать точечную атаку и с тем же успехом свалить атакуемый сайт..." (Пол Уатсон)

а вот реальный сценарий, но уже не DoS атаки:

"Предсказание TCP sequence number

Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.

Описание

Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так: После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи. Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения. Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов. Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов. Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант -- использование описанными в следующих разделах методов. После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).

Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.
Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.
Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B.
Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK(заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A).
После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным. Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по электронной почте..." (Источник)

[ 30-04-04, Fri, 14:21:27 Отредактировано: Дядя Федор ]

Конец дней!

№ 23

Автор: Gunslinger
Дата : 03-05-04, Пнд, 02:31:55

После этого, если крэкеру повезло и sequence number сервера был угадан верно

A если не повезло?

И Вообще в этой статье 4 раза используеться слово "предсказать".
К тому же, если все это уже описанно, и на нескольких хакерских сайтах
уже лежат примеры на с++ и на Питоне. То почему еще не "закончился" интернет?
Майкрософт утверждают что нет причин для беспокойства.
А я думаю что там все же не дураки сидят, и они не хотят сесть в лужу.
Так что все это лажа. Да есть дыра, но не такая опасная как здесь описываеться.
Недавно обнаруженная дыра в LSASS* и то посерьезней будет.

* Кто не в курсе, сейчас по сети бродит новый червь, W32.Sasser a/b
который лезет через LSASS.
Patch for WinXP (noSP, SP1):
http://www.microsoft.com/downloads/details.aspx?FamilyId=3549EA9E-DA3F-43B9-A4F1-AF243B6168F3&displaylang=en

У кого стоит второй сервис пак, то патч уже внутри.
Windows 2000, даже со всеми 4 сервис паками, уязвим.

Конец дней!

№ 24

Автор: Dimka
Дата : 03-05-04, Пнд, 02:45:16

Стенки надо ставить, стенки

Ганслингер, см. пост 17

Все великие истины начинаются как богохульства
Джордж Бернард Шоу

Конец дней!

№ 25

Автор: Дядя Федор
Дата : 03-05-04, Пнд, 20:28:37

Автор: Gunslinger
Дата : 03-05-04, Mon, 9:31:55
Майкрософт утверждают что нет причин для беспокойства.
А я думаю что там все же не дураки сидят, и они не хотят сесть в лужу.

ГЫ! харош ламить, мелкософт то тут при чем? большинство раутеров и DNS их продукцию не юзают... а то что они утверждают, дык в англо-русском словаре слово "windows", вместа "окна", давно пора заменить на "дыры"... стоит вспонить лишь баг в TFTP, млин, это что не лужа???...

Конец дней!

№ 26

Автор: Gunslinger
Дата : 04-05-04, Втр, 04:28:34

Вот причем:

Автор: Дядя Федор
Дата : 25-04-04, Sun, 0:50:32
Products: (системы подверженные этой атаке)
Cisco IOS All Versions
Microsoft Windows All Versions (!!!! - для тех кто еще не верит)
...

Ну так я и говорю что мелкомягкие болшие специальсты в дырах.

И Они говорят что беспокоиться не о чем.