The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимость, позволяющая вклиниться в стороннее TCP-соединение

11.08.2016 08:59

На конференции Usenix Security Symposium группа исследователей из Калифорнийского университета в Риверсайде и исследовательской лаборатории армии США обнародовали сведения о возможности совершения пассивных атак на TCP, позволяющих удалённо инициировать разрыв сетевого соединения или осуществить подстановку своих пакетов в TCP-поток к клиенту или серверу.

В отличие от MITM-атак, новый метод не требует контроля за коммуникациями - для атаки достаточно знать IP-адрес сервера, IP-адрес клиента и сетевой порт сервера. В рамках доклада был продемонстрирован рабочий пример атаки, в результате которой в запрошенную одним из пользователей web-страницу с известного новостного сайта была осуществлена подстановка стороннего блока данных. Кроме того упомянута возможность применения атаки для обрыва подключения пользователя с входящим шлюзам Tor, нарушения связи между узлами Tor и модификации незашифрованного трафика между выходящим узлом Tor и целевым сайтом.

Суть проблемы в недоработке механизмов ограничения интенсивности обработки ACK-пакетов, описанных в спецификации RFC 5961, что позволяет вычислить информацию о номере последовательности, идентифицирующей поток в TCP-соединении, и со стороны отправить подставные пакеты, которые будут обработаны как часть атакуемого TCP-соединения. Представленный метод не специфичен для конкретных TCP-стеков и проявляется при наличии расширений ограничения интенсивности обработки пакетов (RFC 5961), реализованных для борьбы с подбором номера последовательности TCP.

Суть атаки в наводнении хоста запросами для срабатывания ограничения в обработчике ACK-пакетов, который манипулирует общим для всей системы счётчиком, параметры которого можно получить меняя характер нагрузки. Атакующий может создать "шумовую завесу" для определения значения общего счётчика ограничения интенсивности ACK-ответов, после чего на основании оценки изменения числа отправленных пакетов, укладывающихся в лимит, определить номер клиентского порта и осуществить подбор номера последовательности для конкретного TCP-соединения (при совпадении счётчик лимита ACK уменьшится при неизменном потоке). Метод существенно упрощает подбор, позволяя осуществить его менее чем за минуту. В зависимости от условий успешность атаки составляет от 88 до 97 процентов.

Проблема уже подтверждена в Linux (CVE-2016-5696) и проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7. В качестве обходного метода защиты рекомендуется увеличить лимит на число одновременно обрабатываемых ACK-пакетов, установив переменную /proc/sys/net/ipv4/tcp_challenge_ack_limit в очень большое значение. Для новых ядер значение по умолчанию увеличено со 100 до 1000 и добавлена дополнительная рандомизация для снижения предсказуемости параметров работы системы ограничения ACK-пакетов.

Дополнение: По мотивам доклада подготовлен прототип скрипта, определяющего исходный порт клиентского соединения (внимание, скрипт генерирует около 700 пакетов в секунду).

  1. Главная ссылка к новости (http://arstechnica.com/securit...)
  2. OpenNews: Уязвимость в TCP-стеке FreeBSD, позволяющая обрывать чужие TCP-соединения
  3. OpenNews: Исследователи нашли фундаментальную уязвимость во всех TCP/IP стеках
  4. OpenNews: Текущее состояние генераторов "TCP Initial Sequence Numbers" в различных ОС.
  5. A Security Assessment of the Internet Protocol
  6. OpenNews: Google исправил ошибку, около 10 лет присутствующую в TCP-стеке ядра Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/44945-tcp
Ключевые слова: tcp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (60) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:24, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Проверил у себя...

    @sidbox:~$ cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    1000

     
  • 1.2, AS (??), 10:29, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Fedora21 -
    [root@sef21 ~]# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    100
    [root@sef21 ~]#

    Fedora24server -
    [root@asterisk001 filter.d]# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    1000
    [root@asterisk001 filter.d]#

    они знали !

     
     
  • 2.4, eRIC (ok), 10:50, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Fedora24server -
    > [root@asterisk001 filter.d]# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    > 1000

    1000 vs 999999999

    1- Open /etc/sysctl.conf, append a command “net.ipv4.tcp_challenge_ack_limit = 999999999”.
    2- Use “sysctl -p” to update the configuration.


     
     
  • 3.39, Аноним (39), 19:27, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В Linux Mint не пашет. Все-равно 100 определяет.
     
     
  • 4.45, Аноним (45), 00:42, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой! :)) Теперь так:
    cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    999999999
     
     
  • 5.55, Аноним (-), 21:25, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ой! :)) Теперь так:
    > cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    > 999999999

    Как ты думаешь, твоя система реально прожует 999 миллионов записей в очереди? Мысль налить тебе таких пакетов побольше, чтобы проверить это - тоже вариант атаки :)

     
     
  • 6.57, Аноним (57), 23:47, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ладно, уговорили. Оставил 1000. :)
     

  • 1.3, Нанобот (ok), 10:33, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    судя по последней ссылке, там не просто увеличение tcp_challenge_ack_limit со 100 до 1000, а ещё какие-то изменения в коде
     
     
  • 2.56, Аноним (-), 22:29, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да, я б даже сказал само собой или очевидно.
     
  • 2.58, parad (ok), 04:13, 13/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ну так в новости написано и про изменения в коде.
     

  • 1.5, t28 (?), 10:54, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    > проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7

    Всё ясно.

     
     
  • 2.53, Аноним (-), 21:10, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7
    > Всё ясно.

    Новость не читал, но Linux осуждаешь? Казалось бы, при чем тут RFC...

     

  • 1.6, Ващенаглухо (ok), 11:10, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А в grsecurity давным давно есть фича Truly random TCP ISN.
     
  • 1.7, Moomintroll (ok), 11:28, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Напомнило дедушкины страшилки про Кевина Митника...
     
  • 1.9, Аноним (-), 12:03, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    root@www01:/# cat /etc/lsb-release
    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=16.04
    DISTRIB_CODENAME=xenial
    DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
    root@www01:/# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    100
     
  • 1.10, freehck (ok), 12:08, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    % cat /etc/debian_version
    8.3
    % cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    100
     
     
  • 2.46, _KUL (ok), 04:33, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это'ж Вам не винда, что бы версию оси смотреть ... Нужно сразу ядро!

    # apt-cache policy linux-image-4.6.0-1-amd64
    linux-image-4.6.0-1-amd64:
      Установлен: 4.6.4-1
      Кандидат:   4.6.4-1
      Таблица версий:
    *** 4.6.4-1 990
            990 http://ftp.debian.org/debian testing/main amd64 Packages
            100 /var/lib/dpkg/status
    # cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
    100

     
     
  • 3.47, freehck (ok), 11:49, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это'ж Вам не винда, что бы версию оси смотреть ... Нужно сразу ядро!

    Тогда уж "uname -a". А то мало ли какие ядра у вас там стоят в системе... :)

    Но вернее всё же версию дистрибутива, поскольку речь идёт о его дефолтах. По версии дистра, к тому же, можно в некотором роде и о ядре. Вот например в Debian 8 сейчас 3.16.7.

     
     
  • 4.61, _KUL (ok), 09:22, 13/08/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Иногда на бизнес-критичных узлах, админы собирают ручками ядро, с тонкой настройкой под специальные драйвера или стевой стек, и жить такое ядро может отдельно от дистрибутива долгое время ... Но да, вы правы, для чистоты нужно было сделать сначала dpkg -l | linux-image и ll /boot
     
  • 2.64, snmp agent (?), 17:36, 15/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    % cat /etc/debian_version
    8.3

    Обновляться? Зачем?

     

  • 1.11, Аноним (-), 12:16, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    # cat /etc/centos-release
    CentOS Linux release 7.2.1511 (Core)

    # uname -r
    3.10.0-327.28.2.el7.x86_64

    # cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    100

     
  • 1.12, слакварявод (ok), 12:18, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    bash-4.3# cat /etc/slackware-version
    Slackware 14.2
    bash-4.3#  cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    1000
     
     
  • 2.13, слакварявод (ok), 12:22, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    и довесок:
    bash-4.3# uname -a
    Linux 7-21a-226-o1182 4.7.0 #1 SMP PREEMPT Wed Jul 27 12:41:05 SAMT 2016 x86_64 Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz GenuineIntel GNU/Linux


    а вот на дефолтных серверах:
    root@serslack:~# uname -a
    Linux serslack 4.4.14 #2 SMP Fri Jun 24 13:38:27 CDT 2016 x86_64 Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz GenuineIntel GNU/Linux

    root@serslack:~# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    100

    вот так что...

     

  • 1.14, angra (ok), 12:29, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Уязвимость конечно серьезная, но надо по дефолту исходить, что интернет не является безопасной средой передачи и tcp пакеты могут быть подменены или просто прочитаны сторонними лицами. Собственно ssh, https и прочая придуманы именно ради этого и на тех, кто их применяет, данная уязвимость не скажется.

    P.S. даешь еще сотню сообщений о том, у кого какое значение в net.ipv4.tcp_challenge_ack_limit

     
  • 1.15, aurved (?), 12:41, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А как насчет FreeBSD?

    Пишут что вроде ни OSX, ни Windows, ни FreeBSD не подвержены этой уязвимости,
    так как в них не реализован RFC 5961. Хотя в тоже время пишут что чувак разрабатывавший этот RFC -- Randal Stewart, is a FreeBSD source committer.

     
     
  • 2.16, Аноним (-), 12:43, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > чувак разрабатывавший этот RFC -- Randal Stewart, is a FreeBSD source committer

    Красиво уделал конкурентов, те готовы кушать все эксперементы на собственной шкуре.

     
     
  • 3.18, aurved (?), 12:45, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ))) ну все-таки линукс и фрюха не совсем конкуренты, линукс уже давно в другой весовой категории...


     
     
  • 4.59, parad (ok), 04:20, 13/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > ))) ну все-таки линукс и фрюха не совсем конкуренты, линукс уже давно
    > в другой весовой категории...

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

     
  • 2.23, zanswer (?), 13:54, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Мы с вами можем говорить о том, что FreeBSD имеет частичную поддержку: https://wiki.freebsd.org/TransportProtocols/tcp_rfc_compliance
     
  • 2.24, Аноним (-), 14:02, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >  Randal Stewart, is a
    > FreeBSD source committer.

    Угу. Упоминание в каммитах 2010, поддержка мипсов в 2008,
    а потом



    Date:   Tue Dec 20 09:24:04 2005 +0000

        Add protocol number for SCTP.
        
        Submitted by:   Randall Stewart rrs at cisco.com




    И все.

     
  • 2.66, rvs2016 (ok), 19:15, 24/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А как насчет FreeBSD?
    > Пишут что вроде ни OSX, ни Windows, ни FreeBSD не подвержены этой
    > уязвимости

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

     

  • 1.20, Аноним (-), 13:42, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ничоси бывает :)
    Рандумность - не рандумна!

    Еще можно подключить фургончик начиненный ФСБ'шниками и следить за генерацией случайности помех на клавиатуре жертв

     
     
  • 2.25, Ъ (?), 14:11, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > следить за генерацией случайности помех на клавиатуре жертв

    Излучения то вовсе не случайные и вполне неплохо декодируются.

    Compromising electromagnetic emanations of wired and wireless keyboards
    http://lasecwww.epfl.ch/keyboard/

    Оборудование для этого по сути доступно любому (при условии, что есть несколько десятков тысяч $ на него), а не только спецслужбам.

     

  • 1.22, Аноним (-), 13:51, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > и проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7

    Почему по? В 4.7 устранена же.

     
     
  • 2.26, pkdr (ok), 14:34, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Вообще-то с "3.6 по 4.7" означает "больше, чем 3.6, меньше чем 4.7, но не включая их". Так что правильно, иначе там должно стоять слово "включительно".
    Этому учат на уроках математики даже в школе.
     
     
  • 3.30, Sluggard (ok), 15:00, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз включая 3.6, но не включая 4.7, математик.
     
     
  • 4.65, fx (ok), 09:30, 22/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    "по 4.7" = "включая 4.7", гуманитарий. это "до" обычно не включая.
     
  • 2.27, Аноним (-), 14:40, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Linux (≥  3.6 || < 4.7)
     
     
  • 3.28, Аноним (-), 14:41, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Linux (≥  3.6 || < 4.7)

    Спасибо капитан!

     
     
  • 4.33, Evolve32 (ok), 16:48, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Капитан вообще-то прокапитанил
    (≥  3.6 && < 4.7)
     
     
  • 5.35, Аноним (-), 17:11, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо граммар-капитан я вас ждал, редактировать нельзя!

    С любовью ваш искренний поклонник #22 #27

     
     
  • 6.38, MPEG LA (ok), 18:48, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ты снова попутал, он буль-капитан, а не граммар
     
  • 3.40, Аноним (-), 19:35, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Linux (≥  3.6 || < 4.7)

    [3.6..4.7)
    Или вообще
    {x € Linuxversion| Linuxversion <: R, x >= 3.6,  x<4.7}
    Как-то так.

     
     
  • 4.48, freehck (ok), 11:58, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Евро. Евро, блин. :)

    > {x € Linuxversion| Linuxversion <: R, x >= 3.6,  x<4.7}

    s/€/∈/

     

  • 1.29, Аноним (-), 14:48, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    rhel6 подвержен, 5 - нет.
     
  • 1.31, Аноним (-), 15:17, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    offtop: @gOldfisk и @rancidbacon открыли для мира анальные зонды, в прямом и переносном смысле
     
  • 1.32, Аноним (-), 16:10, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > в выпусках ядра Linux c 3.6 по 4.7

    Тогда почему RHEL 5 и 6 подвержены? Там ядра 2.6.

     
     
  • 2.41, Аноним (-), 19:54, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Бэкпортов много.
     
  • 2.44, angra (ok), 00:32, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во-первых, только RHEL6, но не RHEL5
    Во-вторых, номер ядра у RHEL показывает только от какой версии был изначальный fork, но никак не из каких версий в нем бекпорты. Там в 2.6.32 могут быть фичи и драйверы хоть из 4.x.
     

  • 1.36, j3qq4 (??), 17:27, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    интересно, уязвим ли ТОР за НАТ-ом...
     
     
  • 2.43, h31 (ok), 23:17, 11/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Смотря где. Соединение между узлами Tor-сети - там должна быть защита от инъекции пакетов, так что по идее нет. Между exit node-ой и сервером - уязвимо, если не используешь TLS или другое шифрование.
     

  • 1.42, Анончик (?), 21:28, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    # uname -r
    4.7.0-gentoo

    # cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
    1000

     
  • 1.49, Аноним (-), 19:17, 12/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сайт может сбрасывать суммы страницы браузеру через Тор.
    2 соединения: Прямое и Через Тор - работают как одно.

    Можно попытаться заменить Тор чем-то более лёгким и быстрым, да хотя бы VPN-switcher cо случайными из списка адресами.

     
     
  • 2.51, Аноним (-), 19:23, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Суммы не совпадают - браузер не показывает пользователю сайт и временно блочит до решения пользователя: "Попробовать снова" "Уходим Отсюда" "Добавить в личный фаервол" "Добавить комментарий"
     
     
  • 3.52, Аноним (-), 19:25, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и разумеется: "Отправить Жалобу"
     
  • 2.54, Аноним (-), 21:21, 12/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно попытаться заменить Тор чем-то более лёгким и быстрым, да хотя бы
    > VPN-switcher cо случайными из списка адресами.

    Это еще что за левый софт? Алсо, приватность VPN ниже, т.к. нет цепочки хостов, а справиться с dns leak и пр может не каждый. А главное толку мало: атакующие могут с тем же успехом атаковать траффик выходящий с vpn серверов (а также траффик с проксей и проч).

     
     
  • 3.62, Аноним (-), 16:17, 13/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Они должны знать, что именно им нужно атаковать, в этом и фишка.
     
  • 3.63, Аноним (-), 16:22, 13/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я вот тут подумал, а ведь список всех Tor nodes открыт и всем известен.
    Почему бы не атаковать их постоянно. И это не говоря о том, что треть или больше уже принадлежат спецлужбам.
     

  • 1.50, Аноним (-), 19:21, 12/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Я думаю в нашем любимом Интернете ещё море фундаментальных уязвимостей, о которых пока никто или хотя бы массы уж точно не знают.
     
  • 1.60, Аноним (-), 05:40, 13/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    та-же фигня с SynCookie, который при должной вычислительной мощи и что важнее физической близости к цели - вполне эксплоитируем в сетевом оборудовании. вот для чего заказывают корпорациям строить дата-центры их стран "ведомства" по всему миру, с гротескнуым опережением и фактических и перспективных потребностей, ибо под своей крышей - оно тяжко а так - запросто )
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру