Уязвимость позволяет загрузить ЦП RouterOS на 100% путем отправки кучи TCP RST пакетов на порт 8291 который по дефолту используется Winbox'ом. По дефолту, доступ к этому порту закрыт фаерволом, но если вы его открывали для управления вашими тиками через интернет, следует как можно скорее хотя бы сменить дефолтовый порт, а в лучшем случае прописать разрешение на доступ к порту winbox только для определенных ip (хотя не факт что это спасет):
ip firewall filter add chain=input action=accept protocol=tcp src-address=ADMIN_IP dst-port=8291 comment=Allow_Winbox
По данным из обсуждения на офф. сайте уязвимости подвержены как аппаратные устройства (протестировано на: RB751, hEX lite, RB951, RB2011, CCR1036 и даже RB3011) так и виртуальные CHR (проверено на 8x Xeon).
Пример рабочего эксплоита есть в открытом доступе.
![](https://habrastorage.org/files/5ab/68b/9f2/5ab68b9f2d1440b891e4c8ec961a4b0d.png)
Официальный представитель MikroTik советует отключить в меню Ip service все сервисы (будьте внимательны), сменить стандартные порты, использовать маршрутизатор, ограничить доступ к этим сервисам только из внутренней сети через vpn на стороннем устройстве, или же купить более производительный роутер. Да и вообще это с его слов «нормальная ситуация», что производительности ЦП не хватает для обработки такого кол-ва пакетов…
Комментарии (27)
IgorGIV
13.04.2017 12:00Не совсем понятно, для чего оставлять данный порт смотрящим наружу? Проще поднять VPN на самом маршуртизаторе, и только полключившись к нему уже ходить в админку.
vesper-bot
13.04.2017 16:00Интересно, если зафлудить микротик, на котором поднят IPsec в каком-то виде, пакетами IKE (TCP/500, UDP/500) — он тоже подвиснет?
nApoBo3
13.04.2017 18:48Не понятно где здесь уязвимость микротика. Т.е. если любое другое оборудование с поднятым сервисом загрузить специально сформированными пакетами у него не будет загрузки процессора?
Mystray
13.04.2017 23:02+2Это проблема любого т.н. софт-роутера без сильного разделения data и control. Даже правила INPUT цепочки вполне себе доходят до ядра и обрабатываются теми же механизмами, что и транзитные.
Старшие хардварные братья имеют вполне себе защиту контрол-плейна, вроде COPP/LPTS, ddos-protection или аналогов. Да даже более-менее серьезные виртуальные роутеры вроде J vMX, C CSR1000v или HP VSR имеют более сильное разделение, и обработка фаервола/полиси происходит не в том же самом месте, где обработка control-plane сервисов, а сильно раньше и с большей эффективностьюNiTr0_ua
14.04.2017 19:47нет, в данном случае — это не проблема софт-роутера как такового. это проблема вполне конкретной реализации софт-роутера. которой почему-то плохеет при получении RST пакета на открытый tcp порт (что-то не то напатчевали латыши или нанятые ними индусы в линукс ядре)…
NiTr0_ua
14.04.2017 19:41микротик складывается от смешного pps, сгенеренного перловым скриптом. даже 8-ядерный зион, который вполне себе нормально эдак несколько Мппс обычного трафика жует (а то и десяток-другой Мппс).
т.е. любой пользователь, имеющий дома 100мбит (а скорее — даже меньше) канал, может положить любой микротик, на котором открыт хоть 1 tcp порт. это не уязвимость, не? :)
Chupaka
19.04.2017 18:50Даже эксплойт не нужен, hping3 SYN-пакетами заваливает ЦПУ отлично. В качестве контрмеры и в raw prerouting, и в filter input всё прекрасно дропается.
Из интересного — на виртуалке SYN-flood'ил порт 21 (в сервисах FTP был включен) — роутер практически сразу уходил в перезагрузку.
Contriver
CCR1036 куда уж мощнее 36 ядер 1,2ГГЦ
Неплохая позиция производителя, некто ожирает ресурсы роутера — так купите новый мощнее, мы с вас щё и прибыль получим. Зачем им патчить прошивку!
MikroTik советует отключить в меню Ip service все сервисы — они встали на безликий путь остальных производителей роутеров.
MikroTik как раз хорош универсальностью.
С таким отношением завтра найдут ещё кучу уязвимостей приводящих к перегрузке и что получим ответ производителя в духе… так как уязвимость не критическая(не приводит к взлому) купите более производительный!
Неплохой маркетинг, производитель сливает уязвимость и предлагает купить более мощный, заявляя это всё ЦРУ и злые ХАКЕРЫ виноваты!
vasilevkirill
А что вы собственно ожидали от MikroTik? чтобы они за вас создали правила в фаерволе?
Так как это не проблема MikroTik это проблема протокола.
Если вы завтра создадите пару сотен правил фаервола и пропускная способность будет ниже чем ширина канала и вы получите на входе полную загрузку канала, в итоге вы получите 100% загрузку CPU и все вытекающие последствия…
Создавайте правила фаервола которое смотрит количество пакетов RST за N время и добавляйте src адрес в адрес лист, после чего добавьте это адрес в дроп а таблице RAW
/ip firewall filter
add action=add-src-to-address-list address-list=DDOS address-list-timeout=1d chain=input limit=1k,5:packet protocol=tcp src-address-list=!DDOS tcp-flags=rst
/ip firewall raw
add action=drop chain=prerouting src-address-list=DDOS
Естественно указать интерфейсы входящие откуда ожидаете проблему (обычно со стороны провайдера)
Также можете указать конкретно порты сервисов, чтобы не весь трафик rst проверять
Fess
Не поможет. Вы пытаетесь дропнуть пакет, который не имеет смысла дропать в принципе. Соединения, как такового, нет, но прилетает пакет о его закрытии. Вы его ещё и дропаете, добавляя нагрузку на CPU. Причём, могу уточнить, что пакеты можно слать на ЛЮБОЙ порт, даже с отсутствующими сервисами. Т.е. на 8888, если он у вас не обслуживается. Тупо, лупите роутер пакетами. Это не уязвимость конкретного роутера, — тот же эксплоит работает на других софтроутерах.
vasilevkirill
Вперёд 5.19.245.3 Версия 6.38.5
http://5.19.245.3/graphs/
Fess
Ну уж будьте любезны, атакуйте свой маршрутизатор сами?
vasilevkirill
=) RAW отрабатывает до connection-tracker
Fess
Безусловно, но я не о том.
Производительность конкретного роутера:
https://routerboard.com/RB951G-2HnD#perf
При размере кадра 64 байта(а именно столько и формируется), максимально, маршрутизатор прожует 269600 пакетов в секунду. Достаточно 18 mbps, чтобы завалить конкретно этот маршрутизатор пакетами. Вы же предлагаете ещё и обработать каждый из этих пакетов. Я и говорю, что не поможет. Это просто ограничения конкретного железа(?).
vasilevkirill
Если нечего не делать, то конечно помрёт, но у нас есть возможность по крайней мере слегка разгрузить нагрузку, за счёт прерывания трафика в цепочки Prerouting
![](https://habrastorage.org/files/1b7/49e/352/1b749e3520de42a6a73e81aa88784ae0.png)
vasilevkirill
Иначе на следующем этапе будет попытка установить статус соединения (Established, related или invalid), а это уже выборка из памяти connection-tracker-a
Fess
Что мёртвому припарка. Проблема в том, что маршрутизатор закидывают огромным количеством пакетов и он просто не справляется с их количеством. О чём производитель говорит в спецификации оборудования, на которую я Вам привёл ссылку. Да, Ваше правило спасло бы, если бы не тот факт, что атака производится на мощности оборудования, которые Вы не способны защитить изнутри и средствами самого маршрутизатора. Вообще никак!
Защититься возможно, если Вы поставите перед ним какой-нибудь IDS и порежете такого рода пакеты. И, в свою очередь, у этого IDS тоже будет ограничение по количеству обрабатываемых пакетов.
Ещё интересно, как защититься от такого количества RST, если злоумышленник решит рандомно менять ip.src в каждом пакете?
NiTr0_ua
ну и кто помешает слать RST пакеты с рандомным src ip? заспуфить сорс ип — много ума не надо, тут ведь не требуется установленная tcp сессия (т.е. получение какого-либо ответа на заспуфленый ip)…
vasilevkirill
Конечно можно, поэтому это проблема не только MikroTik-а
SolarW
Что-то не все так просто с таким правилом…
Поставил для теста только первую часть, которая собирает айпишки в адрес-лист.
За полчаса насобиралось под полсотни апишек в список…
Сомнения у меня что это атакующие…
vasilevkirill
Можно сделать и так. Но небольшая модификация эксплоита и уже работать не будет
/ip firewall filter
add action=add-src-to-address-list address-list=TEST_DDOS address-list-timeout=1d chain=input connection-state=invalid dst-port=8291 in-interface=ether5 limit=1k,5:packet protocol=tcp tcp-flags=rst
SolarW
Проблема похоже в том, что я кажется не совсем правильно понимаю кусок первоначального правила
limit=1k,5:packet
Предполагал что это имеется в виду тысяча пакетов данного вида в секунду.
Но судя по количеству айпишек которые за ночь в список набились (порядка 500 штук) — взяло большое сомнение…
Неужели с каждой из этих айпишек более чем по 1000 TSP RST per sec на меня валило?