The OpenNET Project / Index page

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

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

На конференции 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
Тип: Интересно / Проблемы безопасности
Ключевые слова: tcp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 +/
    1000 vs 999999999 1- Open etc sysctl conf, append a command 8220 net ipv4 tcp... весь текст скрыт [показать]
     
     
  • 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 +/
    Как ты думаешь, твоя система реально прожует 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 DISTR... весь текст скрыт [показать]
     
  • 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... весь текст скрыт [показать]
     
     
  • 3.47, freehck (ok), 11:49, 12/08/2016 [^] [ответить]     [к модератору]  
  • +1 +/
    Тогда уж uname -a А то мало ли какие ядра у вас там стоят в системе Но ... весь текст скрыт [показать]
     
     
  • 4.61, _KUL (ok), 09:22, 13/08/2016 [^] [ответить]     [к модератору]  
  • –1 +/
    Иногда на бизнес-критичных узлах, админы собирают ручками ядро, с тонкой настрой... весь текст скрыт [показать]
     
  • 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... весь текст скрыт [показать]
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Угу Упоминание в каммитах 2010, поддержка мипсов в 2008, а потом code Date ... весь текст скрыт [показать]
     
  • 2.66, rvs2016 (ok), 19:15, 24/09/2016 [^] [ответить]     [к модератору]  
  • +/
    Да-да Но интересует только FreeBSD Остальные винды там всякие сидят у меня вну... весь текст скрыт [показать]
     
  • 1.20, Аноним (-), 13:42, 11/08/2016 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Ничоси бывает :)
    Рандумность - не рандумна!

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

     
     
  • 2.25, Ъ (?), 14:11, 11/08/2016 [^] [ответить]     [к модератору]  
  • +1 +/
    Излучения то вовсе не случайные и вполне неплохо декодируются Compromising elec... весь текст скрыт [показать]
     
  • 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 соединения Прямое и ... весь текст скрыт [показать]
     
     
  • 2.51, Аноним (-), 19:23, 12/08/2016 [^] [ответить]    [к модератору]  
  • +/
    Суммы не совпадают - браузер не показывает пользователю сайт и временно блочит до решения пользователя: "Попробовать снова" "Уходим Отсюда" "Добавить в личный фаервол" "Добавить комментарий"
     
     
  • 3.52, Аноним (-), 19:25, 12/08/2016 [^] [ответить]    [к модератору]  
  • +/
    Ну и разумеется: "Отправить Жалобу"
     
  • 2.54, Аноним (-), 21:21, 12/08/2016 [^] [ответить]     [к модератору]  
  • +/
    Это еще что за левый софт Алсо, приватность 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:
    Заголовок:
    Текст:


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