[pingz]

Уважаемые коллеги!

 

Из Ситуационного центра Роскомнадзора поступила информация, что на оборудовании Juniper была обнаружена уязвимость (CVE-2018-0020) позволяющая провести атаку типа DoS. Злоумышленник при отправке неверно сформированного запроса BGP UPDATE может вызвать сбой и перезапуск процесса маршрутизации (rpd). Получение повторяющихся неверно сформированных BGP UPDATE может привести к отказу в обслуживании устройства.

 Уязвимые версии Juniper Networks Junos OS:

 14.1X53 versions prior to 14.1X53-D47;

15.1 versions prior to 15.1F6-S10, 15.1R4-S9, 15.1R6-S6, 15.1R7;

15.1X49 versions prior to 15.1X49-D130 on SRX;

15.1X53 versions prior to 15.1X53-D66 on QFX10K;

15.1X53 versions prior to 15.1X53-D58 on EX2300/EX3400;

15.1X53 versions prior to 15.1X53-D233 on QFX5200/QFX5110;

15.1X53 versions prior to 15.1X53-D471 on NFX;
 

16.1 versions prior to 16.1R3-S8, 16.1R4-S9, 16.1R5-S3, 16.1R6-S3, 16.1R7;

16.1X65 versions prior to 16.1X65-D47;

16.2 versions prior to 16.2R1-S6, 16.2R2-S5, 16.2R3;

17.1 versions prior to 17.1R2-S3, 17.1R3;

17.2 versions prior to 17.2R1-S3, 17.2R2-S1, 17.2R3;

17.2X75 versions prior to 17.2X75-D70;

Versions prior to 13.2R1 are not affected.

 

Ссылка: https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10848&actp=METADATA

[vvertexx]

И как ты представляешь эксплуатирование этой уязвимости?

[vurd]

45 минут назад, vvertexx сказал:

И как ты представляешь эксплуатирование этой уязвимости?

 

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

[smart85]

Ну как-то так:

set policy-options prefix-list BGP-locals-v4 apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>"
set policy-options prefix-list BGP-neighbors-v4 apply-path "protocols bgp group <*> neighbor <*.*>"

 

set firewall filter accept-bgp interface-specific
set firewall filter accept-bgp term accept-bgp from source-prefix-list BGP-neighbors-v4
set firewall filter accept-bgp term accept-bgp from destination-prefix-list BGP-locals-v4
set firewall filter accept-bgp term accept-bgp from protocol tcp
set firewall filter accept-bgp term accept-bgp from port bgp
set firewall filter accept-bgp term accept-bgp then count accept-bgp
set firewall filter accept-bgp term accept-bgp then accept

 

Остальное зарезать и на lo0.0 повесить.

 

ЗЫ: https://radar.qrator.net/ - тут можно посмотреть, есть ли в AS какие-то Vulnerable Ports

 

3 часа назад, vvertexx сказал:

И как ты представляешь эксплуатирование этой уязвимости?

Если порт bgp не закрыт, то логи обычно содержат записи а-ля

	bgp_listen_accept: Connection attempt from unconfigured neighbor: 60.191.38.78+50099
	bgp_listen_accept: Connection attempt from unconfigured neighbor: 60.191.38.78+40330
	bgp_listen_accept: Connection attempt from unconfigured neighbor: 60.191.38.78+14279

т.е. пакет так или иначе обработался на re, видимо сабжевый пакет крошит rpd в таком случае.

[vurd]

Да походу тут от пиров прилететь может только разве что. А не просто из мира по портам bgp.

Да и передан такой апдейт дальше не будет. Мелкая проблема, может быть эксплуатирована только в определенном специфичном случае.

[smart85]

1 минуту назад, vurd сказал:

Да походу тут от пиров прилететь может только разве что. А не просто из мира по портам bgp.

Да и передан такой апдейт дальше не будет. Мелкая проблема, может быть эксплуатирована только в определенном специфичном случае.

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

WORKAROUND:

While there is no workaround, the risk associated with this issue can be mitigated by limiting BGP sessions only from trusted peers.

 

 

[Mystray]

14 минут назад, vurd сказал:

Да походу тут от пиров прилететь может только разве что. А не просто из мира по портам bgp.

Да и передан такой апдейт дальше не будет. Мелкая проблема, может быть эксплуатирована только в определенном специфичном случае.

От кастомера с сессией вполне может прилететь - тут уж никак не защититься. Но это надо кому-то насолить сильно.

Если бы "malformed BGP UPDATE" передавался дальше в таком же побитом виде какими-нибудь бирдами или кваггами - то и из обменников могло бы прилететь, хотя этот расклад, конечно, намного менее вероятен.

[vurd]

2 минуты назад, Mystray сказал:

От кастомера с сессией вполне может прилететь - тут уж никак не защититься. Но это надо кому-то насолить сильно.

Если бы "malformed BGP UPDATE" передавался дальше в таком же побитом виде какими-нибудь бирдами или кваггами - то и из обменников могло бы прилететь, хотя этот расклад, конечно, намного менее вероятен.

А мне вот кажется, что как раз наиболее вероятен такой апдейт с обменника. Что они имеют в виду под malformed можно только догадываться. По сути oversized какой-нибудь это тоже malformed, хотя он корректен по полям - такие пакеты bird может и перекинуть.

[Butch3r]

Ну а чё норм. Сидит такой ваш аплинк и думает - а завалю ка я своего абонента ))))))

[smelnik]

Я так понимаю 15.1R5 не подвержена?

[s.lobanov]

Так экслуатировать-то элементарно. На MSK-IX гугл пирится приватно с кучей операторов, вот туда они и зарядят апдейты в час X

 

А сколько наших магистралов пристутсвует на куче IX потенциального противника? Там-то всю внешку и положат

[Ivan_83]

1 час назад, s.lobanov сказал:

На MSK-IX гугл пирится приватно с кучей операторов, вот туда они и зарядят апдейты в час X

И зачем это кому то нужно?

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

[Butch3r]

Кто-нибудь писал авторам письма чтоб помогли скачать софт?

[pingz]

@Butch3r  Да это тяжело сделать, но реально. 

[JohnnyL]

В 17.04.2018 в 16:40, Butch3r сказал:

Кто-нибудь писал авторам письма чтоб помогли скачать софт?

Пишите в личку - постараюсь помочь.

[taf_321]

https://doublepulsar.com/hijack-of-amazons-internet-domain-service-used-to-reroute-web-traffic-for-two-hours-unnoticed-3a6f0dda6a6f

 

Случайно не полевое применение уязвимости?

[YuryD]

 Не подскажете, что стоит на роутсерверах ttk,rtk и ihome ? Вчера вечером была невнятная совершенно ситуация c бгп, трафик закрутился меж трёх ног, кладя каналы в полки. Ну и брокада отребутилась, потеряв логи...

[rdc]

В 17.04.2018 в 10:26, s.lobanov сказал:

На MSK-IX гугл пирится приватно с кучей операторов

С тех пор, как msk-ix перестал быть виден в as-path, нужды в приватном пиринге больше нет.

[s.lobanov]

13 минут назад, rdc сказал:

С тех пор, как msk-ix перестал быть виден в as-path, нужды в приватном пиринге больше нет.

нужды может и нет, но гугл на msk-ix ведёт себя именно так. хочешь пириться с нами - пирься приватно через заявку на isp.google.com

 

с теоретической точки зрения не очень понятно зачем это надо с учётом того, что контроллировать распространение префиксов можно через msk-ix комьюнити.

с практической точки зрения, комьюнити msk-ix вещь не универсальная и на других IX другие community, а приватный пиринг штука универсальная и может работать на любом IX

[rdc]

гугл же присутствует на RS

 

> show arp | grep google

2e:21:31:2b:6c:ca 195.208.208.232 msk-ix-gw1.google.com     xe-0/0/0.0              none

f6:b5:2f:71:58:cb 195.208.208.250 msk-ix-gw3.google.com     xe-0/0/0.0              none

 

> show route google.com    

173.194.0.0/16     *[BGP/150] 1w1d 11:39:43, MED 0, localpref 100, from 195.208.208.100

                      AS path: 15169 I, validation-state: unverified

                    > to 195.208.208.250 via xe-0/0/0.0

[s.lobanov]

@rdc 

только они там анонсируют одни префиксы, а приватно - другие

[rdc]

конкретнее?

 

я через RS вижу следующее:

8.8.4.0/24 8.8.8.0/24 8.34.208.0/21 8.34.216.0/21 8.35.192.0/21 8.35.200.0/21 23.236.48.0/20 23.251.128.0/19 35.184.0.0/13 35.192.0.0/13 35.200.0.0/14 35.204.0.0/15 35.224.0.0/14 35.228.0.0/14 35.232.0.0/14 35.236.0.0/14 35.240.0.0/14 35.244.0.0/14 64.233.160.0/19 66.102.0.0/20 66.249.64.0/19 70.32.128.0/19 70.32.131.0/24 70.32.133.0/24 70.32.145.0/24 70.32.146.0/23 70.32.151.0/24 72.14.192.0/18 74.114.24.0/21 74.125.0.0/16 104.132.0.0/23 104.132.5.0/24 104.132.7.0/24 104.132.8.0/24 104.132.11.0/24 104.132.34.0/24 104.133.2.0/23 104.154.0.0/15 104.196.0.0/14 107.167.160.0/19 107.178.192.0/18 108.59.80.0/20 108.170.192.0/18 108.177.0.0/17 108.177.20.0/23 108.177.22.0/24 130.211.0.0/16 142.250.0.0/15 146.148.0.0/17 162.216.148.0/22 162.222.176.0/21 172.102.8.0/21 172.110.32.0/21 172.217.0.0/16 172.253.0.0/16 173.194.0.0/16 173.255.112.0/20 185.150.148.0/22 192.104.160.0/23 192.158.28.0/22 192.178.0.0/15 199.192.112.0/22 199.223.232.0/21 207.223.160.0/20 208.68.108.0/22 208.81.188.0/22 209.85.128.0/17 209.107.176.0/20 216.58.192.0/19 216.73.80.0/20 216.239.32.0/19 216.252.220.0/22

[s.lobanov]

6 минут назад, rdc сказал:

конкретнее?

Ну смотрите, на MSK-IX гугл анонсирует большие префиксы

 

Берём IP google.com 209.85.233.139. смотрим его на lg.msk-ix.ru, там он 209.85.128.0/17, а на lg, например, Мегафона, он виден как /24 , т.е. 209.85.233.0/24

 

Если вы хотите получить префиксы гугла как морспецифики, то нужно запириться с ними приватно на msk-ix

 

+ отдельная логика по отношению к вашим префиксаму них - если вы их отдаёте гуглы через RS или если вы их отдаёте приватно. Логика эта нигде явно не описана, но на пути хождения трафика от них к вам, оно в общем случае, влияет.

[rdc]

a. я понял, в чём дело.

я давно отфильтровал эти специфики с аплинков, чтобы оттуда не лился трафик их GGC

[s.lobanov]

@rdc 

Суть-то даже совсем не в том что сделали конкретно Вы. Гугл делает прямые пиринги с РФ-операторами, а не с роут-сервером лишь ради того, чтобы в час X прислать специально сформированный анонс, которые отключит эти маршрутизаторы или передаст управление потенциальному противнику. В случае когда вы пиритесь через посрединка в виде RS (=ПО bird), шансов на успешность такой атаки чуть меньше (зависит от того, пройдёт ли "специальный" анонс через bird или нет)