Chrome заблокировал TCP-порты 69, 137, 161, 1719, 1720, 1723 и 6566 / forpes.ru

Главная
Chrome заблокировал TCP-порты 69, 137, 161, 1719, 1720, 1723 и 6566

Chrome заблокировал TCP-порты 69, 137, 161, 1719, 1720, 1723 и 6566 +10

29.01.2021 12:01

alizar 32 23600 Источник

Для защиты от уязвимости NAT Slipstreaming 2.0 браузер Chrome заблокировал доступ к сайтам ещё на семи портах: 69, 137, 161, 1719, 1720, 1723 и 6566.

Почти во всех маршрутизаторах есть функция Network Address Translation (NAT), которая позволяет преобразовывать IP-адреса транзитных пакетов. То есть роутер принимает пакет от устройства во внутренней сети с внутренним IP-адресом — и перенаправляет этот запрос во внешнюю сеть со своим собственным обратным адресом, видимым из интернета.

В декабре 2020 года исследователи безопасности Сэмми Камкар, Бен Сери и Григорий Вишнипольский обнаружили новую версию уязвимости с обходом NAT. Она предусматривает, что на сайте размещаются вредоносные скрипты, возвращающие маршрутизатору специально сконструированный пакет, который обходит маршрутизатор и напрямую отправляется на любой порт TCP/UDP во внутренней сети пользователя, который прислал запрос.

Когда уязвимость впервые раскрыли, Google заявила, что заблокирует TCP-порты 5060 и 5061 в Chrome 87. А сегодня добавила к ним ещё 69, 137, 161, 1719, 1720, 1723, и 6566.

В настоящее время вредоносные скрипты работают по порту 1720 (стандарт передачи мультимедиа H.323, используется в IP-телефонии), но разработчики из Google предусмотрительно заблокировали и другие порты, которые проверяются устройствами NAT и могут подвергаться аналогичной эксплуатации.

При попытке подключиться по одному из этих портов Chrome теперь выводит сообщение об ошибке ERR_UNSAFE_PORT.

Firefox, Edge и Safari 14.0.3 тоже добавили меры для защиты от уязвимости с обходом NAT. В списке изменений браузеров указано, что данная уязвимость закрыта, но пока неизвестно, какие именно порты они заблокировали.

Комментарии (32)

dartraiden
29.01.2021 15:57
#22610942
Подробности атаки

Amoled
29.01.2021 17:07
#22611278
Интересно, есть ли подобные сценарии использования nf_conntrack_ftp на Linux-серверах для обхода iptables.

amarao
29.01.2021 17:13
#22611306
+1
После сообщения исследователя Н. Пелосси об уязвимости к атакам сената, Гугуль заблокировал пользователей по следующему набору регулярных выражений:
t.{4}
.r.{3}
.{2}u.{2}
.{3}m.
.{4}p.

Действие такого же порядка. Софт в нарушение RFC начинает отказываться работать по случайному набору портов.
1. salnicoff
  29.01.2021 18:47
  #22611666
  Тогда уж надо было (.*) банить…
1. Sunny-s
  29.01.2021 19:38
  #22611834
  potus прорвался через блокировки
  1. amarao
    31.01.2021 18:48
    #22617410
    Но это же уже другой потус.

Catslinger
29.01.2021 17:17
#22611320
Не пойму, а что, на любой другой порт вредоносный сайт не может перенаправить?
1. Mur81
  29.01.2021 18:13
  #22611508
  Если я правильно понял (а это не факт), то атака происходит через механизм ALG в NAT. И расчёт на то, что этот ALG работает только со стандартными портами тех протоколов через которые атака происходит. Т.е. по любому порту атака не пройдёт.

Mur81
29.01.2021 18:22
#22611550
К вопросу о том зачем опытные админы открывают с юзерских машин только 80 и 443 порты.
1. yurror
  29.01.2021 18:54
  #22611690
  Скорее это к тем кто кричит что NAT их очень сильно защищает и «IPv6 не нужен!!!111»
  1. MTyrz
    29.01.2021 21:01
    #22612110
    Вы не могли бы пояснить непросвещенному мне, чем IPv6 лучше с этой точки зрения?
    
    yurror
    29.01.2021 21:25
    #22612166
    Защищает файрвол а не NAT (этот наоборот дырявит его). IPv6 хорош тем что адресов хватает и необходимости в NAT'е нету. Следовательно нету необходимости городить обходные пути. Меньше городьбы — проще и надежнее файрвол.
    Ну и еще там по мелочи докидываются некоторые плюшки по безопасности в новом протоколе.
    
    MTyrz
    30.01.2021 21:59
    #22612272
    Адресов хватает, каждый айпишник реальный и торчит наружу. Фактически вы говорите, что система из исключительно белых адресов безопаснее, чем из групп серых, скрытых за белыми. Мне это утверждение представляется неочевидным, как и то, что файрволл станет проще (разве что устранится группа правил, отсекающих обращения из интернета с серыми обратными адресами — но это слезы).
    
    Но я действительно могу многого не знать, и еще многое не учитывать.
    
    gecube
    30.01.2021 22:08
    #22612294
    Решается целый класс атак, связанных с тем, как работает NAT и routing. То же переполнение nf contrack таблиц (иначе нат и не работает).
    Второй момент — очень многие думают, что нат от чего-то защищает. Переход на ipv6 этих балбесов заставил бы настроить файрволл нормально, что в общем — привело бы к ПОВЫШЕНИЕ безопасности
    
    MTyrz
    30.01.2021 22:21
    #22612348
    То же переполнение nf contrack таблиц (иначе нат и не работает).
    Гм…
    Видимо, я плохо понимаю суть проблемы: вы хотите сказать, что конечный хост не подвержен этой атаке? Что-то мне сомневательно.
    Переход на ipv6 этих балбесов заставил бы настроить файрволл нормально
    Скорее, оставил бы их даже без этой эфемерной защиты. Вы переоцениваете человеческие способности.
    Но да, психологические причины, наверное, валидны.
    
    gecube
    30.01.2021 22:33
    #22612380
    Ну, есть разные топологии сети ) например, самое страшное — когда на роутере не только DST, но и SRC NAT. И тогда, например, РДП сервер ВНУТРИ периметра не может полагаться на фильтры СВОЕГО файрволла и акцес листы. Короче, НАТ — это костыль из старых лет.
    
    Или, не знаю, роутер получает адрес по дхцп и в какой-то момент времени снаружи стала прилетать серая сетка… Дальше какие-нибудь форвард правила неудачные и приплыли (мы же за НАТом, нам все равно! гы).
    
    Еще, кстати, очень занятно лечить проблемы с доскером, который по умолчанию сажается на 172.12.x.x, а это бывает вполне валидной корпоративной сеткой. Трафик начинает хитро заруливаться и приплыли )))) Сколько раз устранял эту проблему :-) Так что количество кривых комбинаций невообразимо и к каким последствиям они могут привести — тоже.
    
    Кто там говорил, что сети — это просто? :-)
    
    MTyrz
    30.01.2021 04:23
    #22613036
    Точно не я такое говорил.
    
    Просто идея, что устранение NAT само по себе повысит безопасность… по мне весьма схожа с идеей, что демонтаж входной двери в подъезд заставит жителей поставить себе железные двери в квартирах.
    
    Но я, еще раз, могу чего-то не знать и ошибаться.
    
    amarao
    31.01.2021 18:51
    #22617424
    Устранение nat не повысит безопасность, а устранит ложное ощущение безопасности. Ну, грубо говоря, у вас была сеть, в которой стоит файрвол с правилами allow * в обе стороны, плюс специальная IDS образца 2002 года, которая умеет детектить tear drop и ping of death для windows 98. Какая сеть безопаснее? С такой IDS или без?
    
    Очевидно, что без IDS, потому что уровень базовой безопасности хостов остался тот же, а кода (образца 2002 года) с сетевым exposure стало меньше.
    
    MTyrz
    04.02.2021 10:11
    #22632752
    Про психологические причины я уже оговорился выше, с ними согласен.
    
    IDS не является неотъемлемой частью NAT'а, так что этот случай не очень чистый. Если вы хотите сказать, что защита не пойми от чего, настроенная непонятно как во времена Очакова и покоренья Крыма, может не уменьшать, а увеличивать угрозы безопасности — так я с этим не спорю.
    
    Сам по себе nat в сравнении с просто открытым хостом с белым айпишником угроз не увеличивает, а чуть-чуть уменьшает — по моему скромному. «Чуть-чуть» — это на уровне отсечь соседского школьника от захода на вашу сетевую шару через «Сетевое окружение» в винде.
    
    amarao
    04.02.2021 12:22
    #22633434
    А в моём представлении — увеличивает. Причина в том, что вместо простого stateless стека маршрутизации, у нас теперь появляется сложная stateful штука, которая может подглядывать в протоколы, менять своё поведение в зависимости от того, что она там нашла и делать странное. Когда у вас в сети сетевое устройство, которое делает странное (потому что в природе есть такой странный протокол с тремя связными портами) — оно усложняет картину происходящего.
    
    Что проще охранять — пустое поле или отдельно стоящие куски заборов с неизвестным количеством дверок?
    
    Carburn
    03.02.2021 19:24
    #22630760
    Зато будут сразу взламывать прикладные протоколы на машине, что хорошего?
    
    gecube
    03.02.2021 20:15
    #22631006
    Файрволл от взлома прикладного протокола не помогает. Не публикуйте то, что не должно быть опубликовано — и все будет в порядке. Нат то тут причём? )
    
    Carburn
    03.02.2021 20:16
    #22631014
    Помогает, доступа к портам не будет.
    
    gecube
    03.02.2021 20:54
    #22631196
    +1
    Ну, так продолжайте использовать файрволл дальше — в чем проблема?
    Ещё раз — NAT не является защитой. Что настоящая статья и доказывает
    
    MTyrz
    04.02.2021 10:19
    #22632802
    Я тоже не очень понял, к чему вы это.
    Я сравнивал чистый нат с чистым же хостом с белым адресом. Полагая надежды моего оппонента на то, что отсутствие ната немедленно заставит всех взять и настроить файрволлы… несколько безосновательными.
    
    mvv-rus
    30.01.2021 21:52
    #22612254
    IMHO, разве что, тем, что он не дает такого ощущения безопасности (ложного, как выясняется), как IPv4 с NAT.
    
    MTyrz
    30.01.2021 22:08
    #22612298
    IPv4 с NAT отсечет кучу неспецифических атак, вроде соседского ребенка, задумчиво разглядывающего список компьютеров в «сетевом окружении». Но кстати, это уже кое-что, помню я районные локалки, три раза «ха».
    
    Все остальное требует отдельных усилий, и это понятно. Но если говорить про сугубую психологию… наверное да, эта причина возможна. Спасибо.

sergey-b
30.01.2021 22:10
#22612306
Поясните, пожалуйста, кто разобрался в подробностях, в чем суть уязвимости? В том, что у моего телевизора адрес 192.168.1.2 вроде бы и так не является секретом.
1. sergey-b
  30.01.2021 22:13
  #22612316
  Снаружи что ли может что-нибудь до телевизора долететь?
  1. gecube
    30.01.2021 22:18
    #22612342
    При неудачном раскладе — да.
    При удачном ( для вас ) — вероятность эксплуатации, кмк, не очень высока.
    Но там, если что, интересные атаки и с ДНС есть. Когда Джаваскрипт может «взломать» устройство из локальной сети.
    
    innovaIT
    30.01.2021 23:40
    #22612538
    А можно перевести на русский, то что на русском написано. Я на микротиках замучался что с фтп что с сипом с заворачиванием трафика. В чем конечная суть атаки? При чем здесь alg?
1. mvv-rus
  30.01.2021 01:45
  #22612800
  Уязвимость активирует на шлюзе NAT переадресацию входящего подключения из интернета к шлюзу на выбранный злоумышленником порт вашего телевизора во внутренней сети. После это на телевизор к этому порту может долететь снаружи то, что захочется злоумышленнику.
  Трансляция настраивается с использованием шлюза прикладного уровня (ALG) на шлюзе NAT, который нужен для работы протокола H.323. Именно в этом протоколе можно указать необходимость входящео подключения на другое устройство (для переадресации звонка). Есть и другие протоколы (FTP, например), для работы которых их ALG настраивает прием входящего подключение на шлюзе NAT, но для остальных, кроме H.323, возможна настройка переадресации подключения только на тот же хост внутренней сети, который инциировал настройку.