The OpenNET Project / Index page

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

Атака NAT slipstreaming для отправки запросов на внутренний IP

10.11.2020 11:04

Сами Камкар (Samy Kamkar), исследователь безопасности, известный созданием различных замысловатых устройств для проведения атак, таких как кейлоггер в USB-зарядке телефона, представил новую технику атаки "NAT slipstreaming". Атака позволяет при открытии страницы в браузере организовать соединение сервера атакующего с любым портом UDP или TCP на системе пользователя, находящейся за транслятором адресов. Инструментарий для проведения атаки опубликован на GitHub.

Метод основан на обмане механизма отслеживания соединений ALG (Application Level Gateways) в трансляторах адресов или межсетевых экранах, который применяется для организации проброса через NAT протоколов, в которых используется несколько сетевых портов (один для данных, а другой для управления), таких как SIP, H323, IRC DCC и FTP. Атака применима к пользователям, выходящим в сеть с использованием внутренних адресов из интранет диапазона (192.168.x.x, 10.x.x.x) и позволяет отправить на любой порт любые данные (без заголовков HTTP).

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

На втором этапе выполняемый в браузере жертвы JavaScript-код генерирует большой (не вмещающийся в один пакет) запрос HTTP POST на сервер атакующего, используя нестандартный номер сетевого порта для инициирования настройки параметров сегментирования TCP и размера MTU в TCP-стеке жертвы. В ответ сервер атакующего возвращает TCP-пакет с опцией MSS (Maximum Segment Size), определяющей максимальный размер принимаемого пакета. В случае UDP манипуляция похожа, но основана на отправке крупного запроса WebRTC TURN для вызова фрагментации на уровне IP.

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

На третьем этапе, при помощи вышеописанной манипуляции, JavaScript-код генерирует и отправляет на TCP-порт 5060 сервера атакующего специально подобранный HTTP-запрос (или TURN для UDP), который после фрагментации разделится на два пакета - пакет с HTTP-заголовками и частью данных и корректный SIP-пакет, в котором указан внутренний IP жертвы. Система отслеживания соединений в сетевом стеке посчитает, что данный пакет является началом сеанса по протоколу SIP и включит проброс пакетов для любого выбранного атакующим порта, считая, что данный порт используется для канала передачи данных.

Атака может быть совершена независимо от используемого браузера. Для решения проблемы разработчики Mozilla предложили заблокировать возможность отправки HTTP-запросов на сетевые порты 5060 и 5061, связанные с протоколом SIP. Аналогичную меру защиты также намерены реализовать разработчики Chromium, а также движков Blink и WebKit.

  1. Главная ссылка к новости (https://groups.google.com/a/ch...)
  2. OpenNews: Уязвимость в Apache открывает двери к внутренним ресурсам на другой стороне обратного прокси
  3. OpenNews: Уязвимость, позволяющая совершить MITM-атаку через манипуляцию с HTTP-заголовком Proxy
  4. OpenNews: RangeAmp - серия атак на CDN, манипулирующая HTTP-заголовком Range
  5. OpenNews: Атака Cable Haunt, позволяющая получить контроль над кабельными модемами
  6. OpenNews: Представлен инструмент для проведения атак "DNS rebinding"
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/54058-nat
Ключевые слова: nat, attack, sip, browser
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (126) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 11:36, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    >WebRTC

    Ой, как неожиданно!

     
     
  • 2.25, Lex (??), 12:47, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > если WebRTC отключен, через перебор адресов с измерением времени отклика

    Действительно, неожиданно

     
     
  • 3.41, Аноним (2), 14:51, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –6 +/
    WebRTC всё упрощает в разы. Даже перебирать не надо. Но ты дальше давай сиди на дырявом стуле.
     
     
  • 4.61, Lex (??), 17:13, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > дальше давай сиди на дырявом стуле.

    Кто о чем, как говорится :) Ну это, давай, поосторожней там.. а то уже главная суть статей на опеннете доходить перестает

     
  • 2.60, anonymous (??), 17:13, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Скорее javaScript. Ой как неожиданно!
     
     
  • 3.114, Аноним (114), 02:30, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Атака может быть совершена независимо от используемого браузера

    Как неожиданно и приятно

     

  • 1.3, Аноним (3), 11:37, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    Почему всегда костыли? Причём тут SIP? Почему только его? Почему 5060? А если у меня сервер на этом порту, то как мне зайти? Переходить на сафари?
    Почему проблему в ALG решают в браузере?
     
     
  • 2.9, Аноним (9), 11:55, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тут ошибка не в самом НАТе или АЛГ, тут ошибка в самом браузере, который запускает код, который может открывать порты и т.д. Может следует отключить джаваскрипт?
     
     
  • 3.11, Аноним (3), 12:00, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Код в браузере не открывает порты. Браузер лишь делает запросы - то что и должен делать. Это NAT доверяет любому коду в запросе и начинает пробрасывать порты изнаружи вовнутрь.
     
     
  • 4.28, Аноним (28), 13:07, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Давайте еще и в NAT обязательные сертификаты добавим, сгорел сарай гори и хата.
     
  • 4.47, Аноним (47), 15:33, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Браузер должен открывать страницы и их рендерить. И нечего пихать в браузер системные функции, вроде открытия портов и т.д. А так же выполнять недоверенный по умолчанию код и не надо будет потом в браузер подписать костылями в виде загрубления таймеров и т.д.
     
     
  • 5.95, 1 (??), 01:59, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А как ему их рендерить если кода нет? опять упихаться в 5 стандартных тегов и заставлять юзера закликивать их, было такое да не взлетело.

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

     
     
  • 6.96, gogo (?), 04:14, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это не пользователи хотят видеть такими браузеры, а разработчики.
    html оброс раковыми опухолями со всех сторон.
    жду не дождусь, когда волны упрощений докатится и до веба. и сделают какой-нибудь simple html без скриптов и прочих свистоперделок.
     
     
  • 7.102, mustdie (?), 10:38, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И даже не разработчики, а менеджеры корпораций. "Веб это платформа" и вот это всё.
     
     
  • 8.117, 1 (??), 11:10, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    пфф, вэб это среда и ей нужны свисторверделки, так же как этим вашим питонам руб... текст свёрнут, показать
     
  • 3.99, Аноним (99), 08:19, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хоть кто-то на opennet понимает как все работает и почему.
    Вам нужно полностью запретить браузеру открывать порты, чтобы спасти себя от уязвимостей и бэкдоров.
     
     
  • 4.108, srgazh (ok), 17:02, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    На редкость уникальный аноном)) 80 Да?? Ржу не могу
     
     
  • 5.112, Аноним (112), 00:13, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И 443. Если проблема вызвана тем что браузер умеет открывать порты, то ему нужно запретить открывать порты и проблема решится.
    Вы же не будете отрицать что запрет открывать приведет к невозможности совершить указанную в новости атаку. И любую другу заодно.
     
  • 2.119, Аноним (119), 02:26, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ух какие сложные вопросы у вас По историческим причинам Изначально протокол ... большой текст свёрнут, показать
     
     
  • 3.121, Другой Аноним (?), 16:24, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо за ликбез. Прочитал с интересом.
     

  • 1.4, Cyber100 (ok), 11:39, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –12 +/
    бгага, лол какой == у меня внутренняя сетка 1.0.0.0/24

    согласен - не правильно. но, как оказалось, я не подвержен данной атаке.)

     
     
  • 2.10, Аноним (9), 11:56, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Бугага, теперь тебе не доступны сервисы из CDN cloudflare
     
     
  • 3.12, Аноним (12), 12:00, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Идея, использую-ка я у себя в локалке адреса Netflix'а.
     
     
  • 4.20, Рева RarogCmex Денис (?), 12:19, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это не защищает от атаки, просто атакующему нужно будет цзнать твою сетку заранее
     
  • 4.48, Аноним (47), 15:38, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Адреса гугла надо пользовать, чтоб ютуб не показывал.
     
  • 3.23, Cyber100 (ok), 12:39, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    да ты чЁ, правда? вот это да)
     

  • 1.5, Аноним (5), 11:42, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >зная параметры фрагментации

    В BSD есть scrub, а что делать в линуксе?

     
  • 1.6, Аноним (3), 11:46, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    ЧЁРНЫЙ список
         587,   // smtp (outgoing)
         601,   // syslog-conn
         636,   // ldap+ssl
         993,   // imap+ssl
         995,   // pop3+ssl
         2049,  // nfs
         3659,  // apple-sasl
         4045,  // lockd
    +    5060,  // sip
    +    5061,  // sips
         6000,  // x11
         6665,  // irc (alternate)
         6666,  // irc (alternate)
         6667,  // irc (default)
         6668,  // irc (alternate)
         6669,  // irc (alternate)
         6697,  // irc+tls
     
     
  • 2.8, Аноним (3), 11:47, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +16 +/
    Эй гугл, мозилла! Я у себя разместил сервис SIP на 80 и 443 порту. Заблокируйте их пожалуйста в своих браузерах немедленно!!!!!
     
     
  • 3.37, InuYasha (??), 14:24, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    мне тоже это понравилось. Надеюсь, в коммит пойдёт с комментерием HACK )
     
  • 3.86, Аноним (86), 20:08, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Эй, аноним! Ваш SIP-сервис на нестандартных портах не представляет никакой опасности, поскольку модуль ядра nf_nat_sip, используемый в данной атаке, не смотрит на пакеты на этих портах. Поэтому основания для блокировки указанных портов в браузерах нет.
     
  • 3.126, Витя_Витя (?), 19:55, 19/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Закрытие, жесткая привязка и проброс портов - это хорошо, но не является панацеей от атак на дырявый линукс ... Делать постоянные рекавери диска и посматривать в директорию /usr/... дабы обнаружить там чужие программные файлы будет не лишним.
     
  • 2.58, Аноним (58), 17:03, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    network.security.ports.banned
     
     
  • 3.101, Аноним (-), 10:35, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Давайте сразу добавим 443й порт как самый опасный . Сколько же через него вредоносов проходит, ужас просто !
     

  • 1.7, КО (?), 11:46, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
    Перестал читать
     
     
  • 2.19, DildoZilla (?), 12:17, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Перестал читать

    И перестал пользоваться интернетиком?

     
     
  • 3.26, Аноним (3), 12:54, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +13 +/
    И перестал писать комментарии.. Он теперь не может вам ответить.
     
  • 2.55, Аноним (55), 16:19, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
    > Перестал читать

    Предлагаю все новости начинать с предложения: "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
    Число неадекватов в комментариях должно резко сократится

     
     
  • 3.63, fuzzi (ok), 17:29, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это вряд ли, скорее, наоборот!
    аноним выше перестал читать,
    но писать не перестал...
     
  • 3.69, Аноним (-), 17:45, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    учитывая, что js обычно надо при посещении 702FAA-сервисов, можно сказать что пользователь сам запускает чужие программы (хоть на си, хоть на обфускрипте), альтернативы заботливо вытираются из памяти. неадекватна это как раз глобальная социопатия, а не, например, словарный перевод (овладение языком) вместо js cloud api.
     

  • 1.13, Аноним (3), 12:03, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    RFC 2616
    The default port is TCP 80 [19], but other ports can be used.
    Своим фиксом они нарушают это. Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления. Но им плевать.
     
     
  • 2.66, Аноним (66), 17:37, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  RFC 2616
    > The default port is TCP 80 [19], but other ports can be used.
    > Своим фиксом они нарушают это.

    Нет.
    > Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports. The standard has been fixed and other browsers are implementing this block as well.

    https://github.com/whatwg/fetch/issues/1108

    > Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления.

    Не могут. Достаточно не использовать порты из блеклиста.

     
     
  • 3.84, Аноним (3), 19:58, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поправьте меня, но насколько я понял  https://fetch.spec.whatwg.org/ описывает поведение fetch JS API а также политики загрузки картинок CSS и прочего. Но это не относится к самим HTML страницам.
    Что касается "Не могут. Достаточно не использовать порты из блеклиста." Дело в том что достаточно не использовать уязвимые реализации NAT. А вот сайты на портах из блеклиста не уязвимы и порты менять никому не обязаны. Недефолтные порты популярны на разных админках, роутерах и т д. И вот однажды вы не сможете зайти на них потому что хром захотел решить проблемы SIPa c NATом.
     

  • 1.15, Аноним (12), 12:09, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не понял необходимости хвостоманипуляции с HTTP-запросом. Далее говорится, что JavaScript-код генерирует корректный SIP-пакет, в котором указан внутренний IP жертвы, и отправляет его на TCP-порт 5060 сервера атакующего. А сразу нельзя послать пакет с компа жертвы на TCP-порт 5060 сервера, если уж отправка на этот порт явно не заблокирована в исходящей цепочке файервола?
     
     
  • 2.17, Аноним (3), 12:14, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Я так понял что из браузера можно послать только HTTP запрос. Браузер сам добавит заголовки, куки и т д. Поэтому делается большой запрос, который фрагментируется на два. Первая часть с этим мусором, а вторая начинается с SIP REGISTER на которую доверчивые NAT ALG и клюют.
     
     
  • 3.123, Аноним (12), 11:59, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но вторая часть не будет иметь в заголовке установленного флага SYN. Поэтому принимающая сторона не будет воспринимать это как новое TCP-соединение и отбросит этот пакет, как не принадлежащий какому-либо сеансу.
     

  • 1.16, Аноним (16), 12:10, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Замотали изолентой и типа норм. Лол.
     
     
  • 2.18, Аноним (3), 12:16, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    У них там уже 15 портов закрыты изолентой. Поэтому на 16-ый раз даже думать не стали, достали заготовленный рулон. Только я бы это не изолентой, а туалетной бумагой назвал. Ну или пищевой плёнкой.
     

  • 1.21, Аноним (21), 12:22, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Может, просто хватит уже считать, что NAT защищает от чего-то?
     
     
  • 2.31, Аноним (31), 13:24, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    локалхост может эмулировать сеть любой сложности и глубины, а неуловимые джо за пачкой роутеров и связкой телефонов навряд читают провокации в комментах под блэком, ходящим по краю.
     
  • 2.32, pofigist (?), 13:33, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Может просто надо прочитать не только заголовок?
    И то что NAT не защищает - расскажи ка Cisco ASA...
     
     
  • 3.40, Аноним (40), 14:50, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты баклажан. Cisco ASA делает не только NAT. NAT сам по себе даже у Cisco ни от чего не защищает.
     
     
  • 4.105, pofigist (?), 15:37, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вообще-то вся защита в Cisco ASA - сделана именно на NAT. Есть трансляция - трифак проходит, нет трансляции - не проходит :)
     
  • 3.71, Аноним (71), 18:15, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Циска в Иран уже поставляла своё поделие...
     
     
  • 4.74, Аноним (-), 19:04, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    workstation->airgap->fpg(General_Purpose_Device_With_Ability_To_Plug-In_ Removable_Drive_and_Siemens_Step_7_PLC-Programming_Software_?Win95/98?)->plc->ics
    realtek/jmicron-devcerts, ms{spoolsv,rpc,smb}.
    Циска только пушистая жертва, после того как дракон развернулся в ответ, или вы не про stuxnet?
     
     
  • 5.81, Аноним (-), 19:32, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.schneier.com/blog/archives/2014/01/jetplow_nsa_exp.html
    ага, нашёл, устанавливался только на целевые экземпляры, "случайно" попавшие в Иран? и прям так в видимости центрифуг?
     
  • 4.82, Michael Shigorin (ok), 19:50, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Циска в Иран уже поставляла своё поделие...

    Циски и в 2008 году отваливались "где нужно"...

     
     
  • 5.106, pofigist (?), 15:39, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Циска в Иран уже поставляла своё поделие...
    > Циски и в 2008 году отваливались "где нужно"...

    И не только кошки... но это к делу отношения не имеет.

     

  • 1.22, none (??), 12:22, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Проблема в косых NAT ALG - не нужно открывать канал только по фрагменту.
     
     
  • 2.24, К. О. (?), 12:43, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пакетный фильтр разбирает пакеты по отдельности. Для него просто не существует чего-то более целого, чем "фрагменты".
     
     
  • 3.35, Crazy Alex (ok), 13:51, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну значит придётся учить.
     
     
  • 4.62, Аноним (58), 17:14, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну значит дыры надо пробивать не через отслеживание соединений, а через upnp явно.
     
  • 4.67, К. О. (?), 17:38, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пакетный фильтр ты этому не научишь. То есть, если научишь, он уже перестанет быть пакетным фильтром. Ну и ресурсов станет жрать больше на несколько порядков, конечно же.
     
  • 3.36, Аноним (36), 13:59, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет, см conntrack
     
     
  • 4.64, К. О. (?), 17:36, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да. Conntrack, грубо говоря, поворачивает ручку, ориентируясь на содержимое единственного пакета.
     
  • 3.38, BorichL (?), 14:31, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/

    fwcmd="/sbin/ipfw"
    ${fwcmd} add reass all from any to any in
    ${fwcmd} add deny  all from any to any frag
     

  • 1.27, Аноним (27), 13:05, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем без перехода на ipv6. Или кто-то все ещё думает, что нат, он для безопасности?
     
     
  • 2.33, pofigist (?), 13:35, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Cisco ASA знаешь? NAT однако... Как у большинства сетевых фаерволов
     
  • 2.50, JL2001 (ok), 15:47, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем
    > без перехода на ipv6. Или кто-то все ещё думает, что нат,
    > он для безопасности?

    это не проход ната, инициируемый снаружи, для подключения, это очередной WebRTC - требуется действие, инициируемое изнутри ната

     

  • 1.29, ryoken (ok), 13:07, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?
     
     
  • 2.52, JL2001 (ok), 15:48, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?

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

     

  • 1.30, vitalif (ok), 13:17, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Эм, что-то я не понял. При чём тут SIP? И при чём тут данные? Я думал, что NAT пробрасывает соединения по заголовкам пакета, а не по данным...

    // А, понял, это как раз ALG так делают. Ну и изврат.

     
     
  • 2.39, Аноним (39), 14:32, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А я вот не до конца понял... Linux подвержен?

    Там не просто "содержимое пакета"! В iptables (conntrack) вообще-то есть "состояние": new, established, related и еще можно counters добавить, если не хватает.

    Может нужно более корректные conntrack-обработчики протоколов написать? Или пофиксить проблему более жёсткими правилами iptables на стороне NAT?

     
     
  • 3.70, vitalif (ok), 17:58, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сам по себе нет, это работает только если на роутере стоит ALG - софт, который анализирует содержимое пакетов, смотрит, когда, скажем, FTP просит открыть входящий порт, и открывает ему этот порт автоматом сквозь NAT. Чтобы типа работали соединения FTP через NAT. То есть, по-видимому, чтобы работали FTP ACTIVE соединения, т.к. PASSIVE-то и так работают.

    А анализ получается смотрит на отдельные пакеты и поэтому уязвим к фрагментации.

    Ну и аналогично видимо с SIP. В OpenWrt, например, как я понял, это реализовано через siproxd. Если такой или подобной хрени в роутере нет - то и дырки такой нет... По ссылке в статье у автора в каком-то нетгире это через какие-то модули ядра вообще работает.

     
     
  • 4.83, Аноним (39), 19:57, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот с ftp отличный пример. В том же nf_conntrack_ftp учтено, что PORT может оказаться между двух пакетов и еще много разных "состояний" пакета учтено - "будущие" (перепутанные) пакеты не сразу анализируются, соединения должны быть установлены и т.д. Внедрить PORT посреди HTTP-пакета (в какие-нибудь заголовки) вполне можно и conntrack на это вполне может среагировать, ждать "начала пакета" не нужно...

    А здесь... - либо определение MSS в уязвимости надо нафиг выкинуть, либо поправить реализацию CONFIG_NF_CONNTRACK_SIP в ядре... либо я чего-то не понимаю (или очень замороченный этот протокол SIP, да еще и поверх TCP).

     
     
  • 5.107, Павел Отредиез (?), 15:55, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Приехали, statefull файерволы обманывают. Возвращаемся на stateless - NO TRACK!!!
     

  • 1.34, Аноним (34), 13:45, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну что где там то махровое профрепригодное ламерьё что не любит IPv6 потому что привыкло защищаться NAT'ом?
     
     
  • 2.42, Аноним (2), 14:54, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А он тут каким боком вообще?
     
     
  • 3.53, JL2001 (ok), 15:52, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А он тут каким боком вообще?

    так главный аргумент у них против ipv6 - "нат нас защищает!! нат вороги не пройдут!!1"

    хотя в обсуждениях ipv4+nat vs ipv6 регулярно приводят даже методы открытия ната снаружи

     
     
  • 4.54, Аноним (2), 15:57, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вполне себе защищает, что не так то? Ломают через троян в виде браузера.
     
     
  • 5.72, Аноним (34), 18:28, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Интересно посмотреть где этого "трояна" нету.

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

     
     
  • 6.73, Аноним (2), 19:01, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет браузера - нет трояна. Найти другой способ выполнить свой код на стороне клиента за натом ещё постараться надо.
     
  • 2.51, Michael Shigorin (ok), 15:48, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Справжнє(tm) махровое профнепригодное ламерьё даже статью не осилило и вектор атаки не осознало, а уже в каминаут ринулось.
     
     
  • 3.89, Урри (ok), 20:30, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А сейчас Шигорин удалит комментарий Шигорина как офтопик. Хотя нет, не удалит, кто бы сомневался...
     
     
  • 4.90, Michael Shigorin (ok), 21:06, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А сейчас Шигорин удалит комментарий Шигорина как офтопик.
    > Хотя нет, не удалит, кто бы сомневался...

    Не, пока есть шанс, что человек уязвится, но намёк поймёт, что не те три буквы полез рубить -- не офтопик.  Но в целом Вы, конечно, правы (и по теме).

     
  • 3.120, OpenVMS (?), 22:37, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я смотрю, шигорин на парашу убежал, но даже там его антиукраинская анусная боль не отпускает. Это хорошо.
     
  • 2.122, Аноним (12), 11:51, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >что не любит IPv6 потому что привыкло защищаться NAT'ом

    Как-будто для IPv6 нету NAT'а.

     

  • 1.43, Аноним (43), 14:58, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    UPnP выключайте в роутере и будет вам счастье
    Тоже дыра дырой
    А еще у меня NAT провайдера и потом NAT роутера и firewall в убунточке включен (и в десяточке), так что давайте вперед!
     
  • 1.44, Аноним (44), 15:00, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Насколько я понимаю, тот факт, что PF по умолчанию работает в stateful-режиме уже не первый год, делает маршрутизаторы на базе OpenBSD по умолчанию (пока кто-то специально не начнёт использовать no state) неуязвимыми к данной атаке?
     
     
  • 2.49, Аноним (47), 15:41, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Там вообще alg нет. Поэтому и защищает 😁
     

  • 1.45, An (??), 15:01, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ну так дропать соединения по портам 5060(1) в наружу от пользаков, не?
     
     
  • 2.85, Аноним (3), 20:04, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На всякий случай лучше все порты заблочить.
     
  • 2.124, aaaa (??), 10:53, 18/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно только 5060/5061 TCP закрыть, UDP можно для SIP оставить.
     

  • 1.46, YetAnotherOnanym (ok), 15:03, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > пакет с HTTP-заголовками и частью данных и корректный SIP-пакет, в котором указан внутренний IP жертвы

    А что, NATящий шлюз не смотрит, что у "корректного SIP-пакета" в заголовке Sequence Number field указывает на его принадлежность к другому соединению, и обрабатывать его как пакет SIP не следует?

     
     
  • 2.77, Ordu (ok), 19:17, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не, не смотрит. Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять, а вот какой там номер будет у первого пакета ему пофигу. То есть этот номер _не_ говорит о принадлежности к другому соединению, соединение идентифицируется адресами и портами источника/приёмника. Тут занятно иное -- файрволл по идее должен отслеживать состояние как-то, и наверное должен помнить, что это вроде http был, но он "не помнит". Непонятно как там это сделано так: тут помню, а тут не помню.
     
     
  • 3.109, Аноним (109), 17:58, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять

    Путаешь. Таки TCP.

     
     
  • 4.110, Ordu (ok), 17:59, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять
    > Путаешь. Таки TCP.

    А, ну да, точно. Путаю.

     
  • 3.125, aaaa (??), 10:55, 18/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Firewall без DPI зачастую вообще не знает что там за трафик, обычно по портам ориентируется.
     
  • 2.78, Аноним (78), 19:25, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Видимо, кривые реализации ALG этого не учитывают.
     

  • 1.56, Аноним (56), 16:31, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Многие сервисы, банки эту какаху юзают, что тут НОВОГО ?

     
  • 1.57, Аноним (57), 17:02, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ой да ладно вам - замажут заплаткой
     
  • 1.59, Аноним (59), 17:13, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну, правильное решение это настроенный как для сервера файрвол локалхоста. Либо запускать браузер из ВМ. Рутковская это предвидела.
     
     
  • 2.65, OpenEcho (?), 17:37, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, и так для всей локалки и всем пользователям...

    Не проще, запретить весь исходящий трафик на гейте, и выпускать машины с браузерами через прокси с аутенфикацией?

     
     
  • 3.75, Аноним (75), 19:11, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше поставить терминальный сервер приложений и запускать браузер на нем. А на машинах конечных пользователей интернет ни к чему.
     
     
  • 4.79, Аноним (79), 19:27, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В самом деле. Чтобы если проломили терминальный сервер - проломили всех сразу.
     
  • 4.87, OpenEcho (?), 20:11, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Терминальный сервер ? В домаших и малых бизнесах сетках? А вы знаете толк как экономить чужие деньги!
    Не проще и дешевле поставить + прокси ?
     
     
  • 5.88, OpenEcho (?), 20:12, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Не проще и дешевле поставить pfsense/opnsense/any-linux+ прокси ?
     
  • 3.97, Аноним (59), 06:05, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И чем это решение проще для рядовых пользователей? Более того, на гейте же тоже надо настраивать файрвол. Ваше решение норм, но кому как удобнее...
     
     
  • 4.113, OpenEcho (?), 00:46, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >И чем это решение проще для рядовых пользователей?

    Тем, что проксик на бесплатном pfsense, который взлетит на любом старом компе (который в свою очередь будет значительно мощнее чем самая расфуфыренная мыльница) в отличие он терминального сервера на который еще и CAL прикупить будет надо, плюс клиентам в любом случае нужен комп, смысл их превращать в тонких клиентов?

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

     

  • 1.68, Аноним (68), 17:44, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А ничего, что SIP висит на UDP-порту 5060? Каким образом хвост HTTP-запроса, отправляемого по TCP, превратится в отдельный UDP-пакет на порт 5060? Я чего-то не понял в этой уязвимости.
     
     
  • 2.76, Аноним (76), 19:13, 10/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    SIP может работать как через TCP, так и через UDP порт 5060. При отправке по UDP используется WebRTC TURN, о чем в скобках написано.
     

  • 1.80, Аноним (79), 19:29, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В общем случае данная "атака" упрётся в файрвол на машине пользователя.
    Да, роутер-то пакет обратно пробросит. Но поскольку файрвол на машине пользователя коннектов снаружи не разрешает, а об открытом в сторону сервера атакующего коннекте ничего не знает - давай, до свидания.
     
  • 1.91, Аноним (71), 21:57, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ребята, подскажите, надо ли мне бояться, есть у меня безайпишное pppoe соединение без NAT-а, локалка подключена через вторую сетевуху, а все пакеты, входящие по первой карте на адрес второй карты, дропятся?
     
  • 1.92, Аноним (92), 22:52, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    При использовании ufw на https://2ip.ru/privacy/ всё хорошо. При использовании nftables с аналогичными правилами - утечка IP адресa через заголовки HTTP proxy  и определение туннеля (двусторонний пинг) совсем не радует. Профи, пару дополнительных правил подскажите, плиз...
     
  • 1.93, Ivan_83 (ok), 00:23, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    0. Этот ALG вообще мало где включен.

    1. Зачем держать у себя запущенными сервисы которые слушают за пределами lo чтото и при этом не безопасны?

    2. Почему просто не выставить TTL=1 для всех сервисов которые не должны покидать локалку?

    3. Зачем вообще что то фильтровать после этого или думать что NAT не пустит?

     
     
  • 2.116, Аноним (112), 22:18, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Очевидно что разработчики браузеров и сетевых сервисов слишком глупы чтобы догадаться то такой простой вещи как установка ttl=1 для всех сервисов которые не должны покидать локалку.
    Скорее всего они даже не в состоянии додуматься какие сервисы не должны покидать локалку, а какие должны. Вот дурачки, да?
     
     
  • 3.118, Ivan_83 (ok), 20:14, 13/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, потому что мало кто вообще умеет пользоваться сетевым API в операнционках, обычно дальше socket()/connect()/send()/close() не идут.
    А через setsockopt() можно очень много всего накрутить, что кардинально меняет некоторые аспекты и влияет на производительность.

    Потому да, авторы браузеров и сервисов - идиоты, в большинстве своём.
    Если сервис больше пары строчек и без setsockopt() - значит авторы таки недалёкие люди, или в лучшем случае не осознали потребности либо руки ещё не дошли.

    В том же nginx - setsockopt() используется активно, но до ttl руки там не дошли.

    Авторы UPnP/DLNA серверов - идиоты, потому что там TTL=1 просто мастхэв не только для мультикаста но и для порта с http.
    Притом они часто юзают старое корявое API для мультикаста, я вообще мало видел софта где используется setsockopt(MCAST_JOIN_GROUP).

     

  • 1.94, Аноним (112), 01:13, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Некоторое время назад думалось по поводу NAT Traversal между двумя компьютерами за nat засчет имитации ftp сеанса, но казалось что это никак не сделать
     
  • 1.98, Аноним (98), 07:18, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    "Система отслеживания соединений в сетевом стеке посчитает"
    Разве ошибка не тут?
     
     
  • 2.100, Ordu (ok), 10:18, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Может быть, а может и нет. Сложно сказать. NAT -- это костыль, который, забивая на идеи заложенные в модель и уровни OSI, работает сразу на нескольких уровнях OSI. В этом смысле, он сам весь с начала и до конца большое архитектурное недоразумение. Ну или ошибка, если тебе это слово больше нравится. Если мы не считаем это ошибкой, то тогда процесс назначения ответственных размазывается и виноватым может оказаться кто угодно.
     
     
  • 3.103, Аноним (27), 12:33, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Модель OSI в принципе плохо применима к стеку протоколов интернета, т.к. он был разработан "конкурирующей" организацией с другого континента. Да, и там, и там используются похожие принципы, но все же, интернет изначально проектировался вовсе не теми людьми, что изобрели OSI где-то параллельно.
     
     
  • 4.104, Ordu (ok), 13:12, 11/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Какая разница? NAT не вписывается также и в модель с уровнями TCP/IP.
     

  • 1.111, Аноним (111), 18:50, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Может быть получиться проделать эти манипуляции без javascript
    на втором этапе можно установить клиенту "большой" cookie, нужно то всего чуть больше килобайта. Потом клиент отправит его и получится превышение

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

     
     
  • 2.115, Аноним (71), 07:40, 12/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > потребуется чтобы пользователь кликнул

    да легко, пишешь на странице: "Ваш браузер устарел", и кнопка "обновить до Хром ver. 100500".

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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