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

Gasparfx

Источник: http://www.lenta.ru/internet/2004/04/21/hacker/
Обнаружена брешь в TCP, способная привести к концу Интернета
Исследователи обнаружили серьезный изъян в технологии, лежащей в основе движения всех информационных потоков в Интернете - TCP (transmission control protocol) - протоколе контроля передачи данных. Это открытие заставило интернет-сообщество принимать срочные меры для поддержания работоспособности всех основных протоколов Всемирной паутины.
Британское правительство объявило о найденной в базовой интернет-технологии уязвимости во вторник, 20 апреля. Эксперты заявили, что обнаруженная брешь позволяет хакерам выводить удаленные компьютеры в оффлайн, а также нарушать работу роутеров - специальных узлов перенаправления потоков данных между разными группами компьютеров, своеобразных связных между разрозненными сетями, входящих в состав Интернета. Успешная атака может перевести роутеры в режим ожидания, и прервать связь во Всемирной паутине на несколько часов.
"Использование этой уязвимости может разрушить своеобразный "клей", который скреплял Интернет воедино", - сказал Роджер Камминг, директор National Infrastructure Security Coordination Centre (NISCC). Пока что, к счастью, не обнаружено атак с использованием бреши в TCP.
"Риск очень значителен. Очень важно вовремя залатать замеченную дыру, пока плохие парни не стали использовать ее для развлечения или перехвата данных", - заявил Пол Викси (Paul Vixie) из Internet Systems Consortium.
Впервые об уязвимости TCP заговорил в прошлом году компьютерный эксперт Пол Уотсон (Paul Watson). Уотсон нашел, что можно прерывать информационные потоки, удаленно вызывая перезагрузку роутера или любого другого компьютера.
Его выводы было поначалу высмеяны экспертами, которые заявили, что подобная атака займет от 4 до 142 лет, поскольку требует подбора постоянно меняющегося номера из 4 миллиардов возможных комбинаций, но Уотсон доказал, что вычислит необходимый номер максимум с 4 попыток, затратив на это всего несколько секунд.
Cisco Systems, известная своими роутерами, стала срочно обновлять программное обеспечение на своей продукции, чтобы защитить пользователей. Корпорация Microsoft заявила, что для пользователей Windows никакой угрозы нет, и компания не собирается принимать никаких экстренных мер. "Будет очень сложно атаковать компьютер под управлением Windows, используя метод Уотсона", - заявил Стив Липнер, директор центра Microsoft по безопасности продуктов.
Оглашение всех результатов исследований Уотсона ожидается в четверг, 22 апреля, на конференции по вопросам сетевой безопасности в Ванкувере (Vancouver). Исследователь предупредил, что хакеры поймут, как именно нужно организовать атаку "спустя буквально пять минут после выхода из зала".
------------------------------
P.S. Особенно мне понравилось вот это: "Корпорация Microsoft заявила, что для пользователей Windows никакой угрозы нет, и компания не собирается принимать никаких экстренных мер."

maksimy

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

Я, конечно, не эксперт, но, по-моему, 4 варианта - это бред. Это либо слишком много (на два порядка больше 1 либо слишком мало...

state7401281

tcp - проклят

evgen5555

для пользователей Windows никакой угрозы нет,
Естественно, ведь самый стремный этап - установка ОС Windows - уже позади...

evgen5555

Я, конечно, не эксперт
...но твои заявки уже реально канают за экспертизу

sergei1969

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

ну не бред?

Marinavo_0507

Я хренею, модератор удалил единственный пост, содержащий полезную информацию --
ссылку на security advisory от Cisco
Вот вам от CERT, менее ангажированный имхо доклад:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Technical Cyber Security Alert TA04-111A archive
Vulnerabilities in TCP
Original release date: April 20, 2004
Last revised: --
Source: US-CERT
Systems Affected
* Systems that rely on persistent TCP connections, for example
routers supporting BGP
Overview
Most implementations of the Border Gateway Protocol (BGP) rely on the
Transmission Control Protocol (TCP) to maintain persistent
unauthenticated network sessions. There is a vulnerability in TCP
which allows remote attackers to terminate network sessions. Sustained
exploitation of this vulnerability could lead to a denial of service
condition; in the case of BGP systems, portions of the Internet
community may be affected. Routing operations would recover quickly
after such attacks ended.
I. Description
In 2001, the CERT Coordination Center released CA-2001-09, describing
statistical weaknesses in various TCP/IP Initial Sequence generators.
In that document (<http://www.cert.org/advisories/CA-2001-09.html>
it was noted by Tim Newsham:
[I]f a sequence number within the receive window is known, an
attacker can inject data into the session stream or terminate the
connection. If the ISN value is known and the number of bytes sent
already sent is known, an attacker can send a simple packet to
inject data or kill the session. If these values are not known
exactly, but an attacker can guess a suitable range of values, he
can send out a number of packets with different sequence numbers in
the range until one is accepted. The attacker need not send a
packet for every sequence number, but can send packets with
sequence numbers a window-size apart. If the appropriate range of
sequence numbers is covered, one of these packets will be accepted.
The total number of packets that needs to be sent is then given by
the range to be covered divided by the fraction of the window size
that is used as an increment.
Paul Watson has performed the statistical analysis of this attack
when the ISN is not known and has pointed out that such an attack
could be viable when specifically taking into account the TCP
Window size. He has also created a proof-of-concept tool
demonstrating the practicality of the attack. The National
Infrastructure Security Co-Ordination Centre (NISCC) has published
an advisory summarizing Paul Watson's analysis in "NISCC
Vulnerability Advisory 236929," available at
<http://www.uniras.gov.uk/vuls/2004/236929/index.htm>.
Since TCP is an insecure protocol, it is possible to inject
transport-layer packets into sessions between hosts given the right
preconditions. The TCP/IP Initial Sequence Number vulnerability
(http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is
one example of how an attacker could inject TCP packets into a
session. If an attacker were to send a Reset (RST) packet for
example, they would cause the TCP session between two endpoints to
terminate without any further communication.
The Border Gateway Protocol (BGP) is used to exchange routing
information for the Internet and is primarily used by Internet
Service Providers (ISPs). For detailed information about BGP and
some tips for securing it, please see Cisco System's documentation
(<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm>
or Team Cymru (<http://www.cymru.com/>). A vulnerable situation
arises due to the fact that BGP relies on long-lived persistent TCP
sessions with larger window sizes to function. When a BGP session
is disrupted, the BGP application restarts and attempts to
re-establish a connection to its peers. This may result in a brief
loss of service until the fresh routing tables are created.
In a TCP session, the endpoints can negotiate a TCP Window size. When
this is taken into account, instead of attempting to send a spoofed
packet with all potential sequence numbers, the attacker would only
need to calculate an valid sequence number that falls within the next
expected ISN plus or minus half the window size. Therefore, the larger
the TCP Window size, the the larger the range of sequence numbers that
will be accepted in the TCP stream. According to Paul Watson's report,
with a typical SL data connection (80 Kbps, upstream) capable of
sending of 250 packets per second (pps) to a session with a TCP Window
size of 65,535 bytes, it would be possible to inject a TCP packet
approximately every 5 minutes. It would take approximately 15 seconds
with a T-1 (1.544 Mbps) connection. These numbers are significant when
large numbers of compromised machines (often called "botnets" or
"zombies") can be used to generate large amounts of packets that can
be directed at a particular host.
To protect against such injections, RFC 2385 provides a method of
using MD5 signatures on the TCP Headers. If this form of verification
is supported and enabled between two peers, then an attacker would
have to obtain the key used to transmit the packet in order to
successfully inject a packet into the TCP session. Another alternative
would be to tunnel BGP over IPSec. Again, this would provide a form of
authentication between the BGP peers and the data that they transmit.
The lack of authentication when using TCP for BGP makes this type of
attack more viable.
US-CERT is tracking this issue as VU#415294. This reference number
corresponds to CVE candidate CAN-2004-0230. NISCC is tracking this
issue as Advisory 236929.
II. Impact
Sustained exploitation of the TCP injection vulnerability with regard
to the BGP vulnerability could lead to a denial-of-service condition
that could affect a large segment of the Internet community. Normal
operations would most likely resume shortly after the attack stopped.
Since the TCP/IP Initial Sequence Number vulnerability (VU#498440) has
been proven more viable of an attack, any services or sites that rely
on persistent TCP sessions could also be affected by this
vulnerability. Impacts could range from data corruption or session
hijacking to a denial-of-service condition.
III. Solution
Apply a patch from your vendor
Please see you vendor's statement regarding the availability of
patches, updates and mitigation strategies.
Workaround
Deploy and Use Cryptographically Secure Protocols
TCP initial sequence numbers were not designed to provide proof
against TCP connection attacks. The lack of cryptographically-strong
security options for the TCP header itself is a deficiency that
technologies l

sergey_m

Вчера весь день над этим смеялись. Вообще к лентесру нельзя относиться серьезно. Вот сейчас прикола ради я на неё зайду и выпишу названия статей.....
Через два года пропадут все данные, записанные на CD-R
Динозавры вымерли из-за отсутствия самок
Яичница с беконом превращает людей в хищников и наркоманов
МВД России доживает последние дни

sergey_m

Most implementations of the Border Gateway Protocol (BGP) rely on the
Transmission Control Protocol (TCP) to maintain persistent
unauthenticated network sessions. There is a vulnerability in TCP
which allows remote attackers to terminate network sessions. Sustained
exploitation of this vulnerability could lead to a denial of service
condition; in the case of BGP systems, portions of the Internet
community may be affected. Routing operations would recover quickly
after such attacks ended.
Интересно, почему я всегда файрволлом разрешал траффик на 179 порт только пирам? Предвидел такое advisory?

Marinavo_0507

> Интересно, почему я всегда файрволлом разрешал траффик на 179 порт только пирам?
Каким образом спуфы отличал?
Я так понимаю, речь про это:
X --- [router A, AS 1] (10.0.0.1) -- EBGP -- (10.0.0.2)[router B, AS 2]
соответственно из интернета (точки Х) приходит пакет src=10.0.0.1 dst=10.0.0.2
роутер B никак не отличит его от настоящего, это только роутер A может сделать,
или фильтр где-то раньше.
так уже давно делали, для этого Cisco придумало уродский TCP-MD5,
потому что за IPSec они хотят сильно отдельные деньги, поэтому
не хотят решать эту проблему once and for all, forever and ever,
а выпускают заплатку на заплатке.

sergey_m

Спуфы фильтруются само собой. Вот только фильтруются ли они у пиров?
Разве TCP-MD5 придумала Cisco? Вообще IPSEC слишком тяжел, TCP-MD5 по-моему хорошая опция.

Marinavo_0507

> Вот только фильтруются ли они у пиров?
посмотри на схему
предположи, что роутер A - это Cisco
как ты будешь настраивать фильтр?
поэтому ответ - нет, у пиров не фильтруются
> Вообще IPSEC слишком тяжел,
обработать AH - разве сложнее, чем MD5 посчитать? примерно то же самое и есть
> TCP-MD5 по-моему хорошая опция.
от спуфа ICMP-ошибок не защищает, поэтому их либо игнорировать (плохо либо они точно к такому же DoS приводят

sergey_m

посмотри на схему
предположи, что роутер A - это Cisco
как ты будешь настраивать фильтр?

10.0.0.1/30 только через внешний интерфейс. Таким образом ни меня ни его не заспуфят с моей стороны. Если он сделает то же самое - то никак не заспуфить.

Marinavo_0507

> 10.0.0.1/30 только через внешний интерфейс.
всмысле c src in 10.0.0.1/30 принимать только с одного интерфейса?
на cisco тебе ведь придётся на каждом интерфейсе запрещать эту сеть,
и так для всех пиров, это много правил и большая нагрузка, и большой гемор
(без автоматического генератора точно ошибёшься)

margadon

Извиняюсь что встреваю, решил восстановить справедливость :
http://www.cisco.com/en/US/products/products_security_advisory09186a00801d2d9d.shtml

maksimy

...но твои заявки уже реально канают за экспертизу
Это просто из логики следует. Подбор 4 вариантов - это не подбор, разве что для 2-значного числа , но там ведь врядли 2-значные числа, правильно?

sergey_m

Да, вообще со спуфом бороться - геморр. Может на это забить? Кстати, можно обойтись verrevpath, так-как EBGP пиры либо connected либо static.

Marinavo_0507

> Да, вообще со спуфом бороться - геморр.
Ну вот лучше бы cisco выпустила патч, облегчающий это дело.
Для *nix цикл в скрипте настройки можно наваять...
А вот такой момент остался непонятным: что именно эти патчи из advisory делают,
неужели размер окна уменьшают?

sergey_m

К NetBSD тоже патч вышел. Надо позырить.

Volkulak

Да вообще, с чего сыр-бор разгорелся? Это ж не глобальный баг ТСР. Да и глобальный пропатчить можно бы было...

sergey_m

From: Andre Oppermann <freebsd.org>
To: securityfocus.com
Subject: Re: NetBSD Security Advisory 2004-006: TCP protocol and
implementation vulnerability
Date: Thu, 22 Apr 2004 15:16:36 +0200
X-Mozilla-Status2: 00000000
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
The additional implementation flaw of BSD based TCP/IP stacks has
been fixed in FreeBSD in revision 1.81 of tcp_input.c in 1998 for
FreeBSD 2.2 and 3.0 and all releases since about six years ago.
--
Andre

eee1

круто вот это "X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)"
Оставить комментарий
Имя или ник:
Комментарий: