Не успели в MikroTik запатчить уязвимость озвученную в статье из хак тулзов ЦРУ, как была обнаружена возможность совершения Denial Of Service на удаленное оборудование работающее на RouterOS (предварительно — атаке подвержены все версии OS).

Уязвимость позволяет загрузить ЦП 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).

Пример рабочего эксплоита есть в открытом доступе.



Официальный представитель MikroTik советует отключить в меню Ip service все сервисы (будьте внимательны), сменить стандартные порты, использовать маршрутизатор, ограничить доступ к этим сервисам только из внутренней сети через vpn на стороннем устройстве, или же купить более производительный роутер. Да и вообще это с его слов «нормальная ситуация», что производительности ЦП не хватает для обработки такого кол-ва пакетов…
Поделиться с друзьями
-->

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


  1. Contriver
    13.04.2017 11:41
    +1

    Да и вообще это с его слов «нормальная ситуация», что производительности ЦП не хватает для обработки такого кол-ва пакетов…

    или же купить более производительный роутер

    CCR1036 куда уж мощнее 36 ядер 1,2ГГЦ
    Неплохая позиция производителя, некто ожирает ресурсы роутера — так купите новый мощнее, мы с вас щё и прибыль получим. Зачем им патчить прошивку!
    MikroTik советует отключить в меню Ip service все сервисы — они встали на безликий путь остальных производителей роутеров.
    MikroTik как раз хорош универсальностью.
    С таким отношением завтра найдут ещё кучу уязвимостей приводящих к перегрузке и что получим ответ производителя в духе… так как уязвимость не критическая(не приводит к взлому) купите более производительный!
    Неплохой маркетинг, производитель сливает уязвимость и предлагает купить более мощный, заявляя это всё ЦРУ и злые ХАКЕРЫ виноваты!


    1. vasilevkirill
      13.04.2017 12:30
      +4

      А что вы собственно ожидали от 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 проверять


      1. Fess
        14.04.2017 10:19
        +1

        Не поможет. Вы пытаетесь дропнуть пакет, который не имеет смысла дропать в принципе. Соединения, как такового, нет, но прилетает пакет о его закрытии. Вы его ещё и дропаете, добавляя нагрузку на CPU. Причём, могу уточнить, что пакеты можно слать на ЛЮБОЙ порт, даже с отсутствующими сервисами. Т.е. на 8888, если он у вас не обслуживается. Тупо, лупите роутер пакетами. Это не уязвимость конкретного роутера, — тот же эксплоит работает на других софтроутерах.


        1. vasilevkirill
          14.04.2017 11:10

          Вперёд 5.19.245.3 Версия 6.38.5
          http://5.19.245.3/graphs/


          1. Fess
            14.04.2017 11:22

            Ну уж будьте любезны, атакуйте свой маршрутизатор сами?


            1. vasilevkirill
              14.04.2017 12:12

              =) RAW отрабатывает до connection-tracker


              1. Fess
                14.04.2017 14:04

                Безусловно, но я не о том.
                Производительность конкретного роутера:
                https://routerboard.com/RB951G-2HnD#perf
                При размере кадра 64 байта(а именно столько и формируется), максимально, маршрутизатор прожует 269600 пакетов в секунду. Достаточно 18 mbps, чтобы завалить конкретно этот маршрутизатор пакетами. Вы же предлагаете ещё и обработать каждый из этих пакетов. Я и говорю, что не поможет. Это просто ограничения конкретного железа(?).


                1. vasilevkirill
                  21.04.2017 11:57

                  Если нечего не делать, то конечно помрёт, но у нас есть возможность по крайней мере слегка разгрузить нагрузку, за счёт прерывания трафика в цепочки Prerouting


                  1. vasilevkirill
                    21.04.2017 12:02

                    Иначе на следующем этапе будет попытка установить статус соединения (Established, related или invalid), а это уже выборка из памяти connection-tracker-a


                    1. Fess
                      21.04.2017 13:55

                      Что мёртвому припарка. Проблема в том, что маршрутизатор закидывают огромным количеством пакетов и он просто не справляется с их количеством. О чём производитель говорит в спецификации оборудования, на которую я Вам привёл ссылку. Да, Ваше правило спасло бы, если бы не тот факт, что атака производится на мощности оборудования, которые Вы не способны защитить изнутри и средствами самого маршрутизатора. Вообще никак!
                      Защититься возможно, если Вы поставите перед ним какой-нибудь IDS и порежете такого рода пакеты. И, в свою очередь, у этого IDS тоже будет ограничение по количеству обрабатываемых пакетов.
                      Ещё интересно, как защититься от такого количества RST, если злоумышленник решит рандомно менять ip.src в каждом пакете?


      1. NiTr0_ua
        14.04.2017 20:08

        ну и кто помешает слать RST пакеты с рандомным src ip? заспуфить сорс ип — много ума не надо, тут ведь не требуется установленная tcp сессия (т.е. получение какого-либо ответа на заспуфленый ip)…


        1. vasilevkirill
          21.04.2017 11:50

          Конечно можно, поэтому это проблема не только MikroTik-а


      1. SolarW
        19.04.2017 18:50

        Что-то не все так просто с таким правилом…
        Поставил для теста только первую часть, которая собирает айпишки в адрес-лист.
        За полчаса насобиралось под полсотни апишек в список…
        Сомнения у меня что это атакующие…


        1. vasilevkirill
          21.04.2017 11:47

          Можно сделать и так. Но небольшая модификация эксплоита и уже работать не будет

          /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


          1. SolarW
            21.04.2017 16:09

            Проблема похоже в том, что я кажется не совсем правильно понимаю кусок первоначального правила
            limit=1k,5:packet
            Предполагал что это имеется в виду тысяча пакетов данного вида в секунду.
            Но судя по количеству айпишек которые за ночь в список набились (порядка 500 штук) — взяло большое сомнение…
            Неужели с каждой из этих айпишек более чем по 1000 TSP RST per sec на меня валило?


  1. IgorGIV
    13.04.2017 12:00

    Не совсем понятно, для чего оставлять данный порт смотрящим наружу? Проще поднять VPN на самом маршуртизаторе, и только полключившись к нему уже ходить в админку.


    1. gromka
      13.04.2017 12:01

      На это представитель сказал, что VPN поднятый на этом же микротике — это тоже ip service по этому проблема будет актуальна.


      1. IgorGIV
        13.04.2017 12:04

        О! Спасибо за уточнение. В самой статье этого не увидел. Что ж, это грустно.


  1. vesper-bot
    13.04.2017 16:00

    Интересно, если зафлудить микротик, на котором поднят IPsec в каком-то виде, пакетами IKE (TCP/500, UDP/500) — он тоже подвиснет?


  1. institor
    13.04.2017 17:47
    +1

    Я вообще не понимаю, при чем тут микротик? Это обычный DoS.


    1. NiTr0_ua
      14.04.2017 17:11

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


  1. nApoBo3
    13.04.2017 18:48

    Не понятно где здесь уязвимость микротика. Т.е. если любое другое оборудование с поднятым сервисом загрузить специально сформированными пакетами у него не будет загрузки процессора?


    1. Mystray
      13.04.2017 23:02
      +2

      Это проблема любого т.н. софт-роутера без сильного разделения data и control. Даже правила INPUT цепочки вполне себе доходят до ядра и обрабатываются теми же механизмами, что и транзитные.
      Старшие хардварные братья имеют вполне себе защиту контрол-плейна, вроде COPP/LPTS, ddos-protection или аналогов. Да даже более-менее серьезные виртуальные роутеры вроде J vMX, C CSR1000v или HP VSR имеют более сильное разделение, и обработка фаервола/полиси происходит не в том же самом месте, где обработка control-plane сервисов, а сильно раньше и с большей эффективностью


      1. NiTr0_ua
        14.04.2017 19:47

        нет, в данном случае — это не проблема софт-роутера как такового. это проблема вполне конкретной реализации софт-роутера. которой почему-то плохеет при получении RST пакета на открытый tcp порт (что-то не то напатчевали латыши или нанятые ними индусы в линукс ядре)…


    1. NiTr0_ua
      14.04.2017 19:41

      микротик складывается от смешного pps, сгенеренного перловым скриптом. даже 8-ядерный зион, который вполне себе нормально эдак несколько Мппс обычного трафика жует (а то и десяток-другой Мппс).

      т.е. любой пользователь, имеющий дома 100мбит (а скорее — даже меньше) канал, может положить любой микротик, на котором открыт хоть 1 tcp порт. это не уязвимость, не? :)


      1. dimsoft
        19.04.2017 18:50

        А если не открыт а port knocking — тоже ляжет?


  1. Chupaka
    19.04.2017 18:50

    Даже эксплойт не нужен, hping3 SYN-пакетами заваливает ЦПУ отлично. В качестве контрмеры и в raw prerouting, и в filter input всё прекрасно дропается.


    Из интересного — на виртуалке SYN-flood'ил порт 21 (в сервисах FTP был включен) — роутер практически сразу уходил в перезагрузку.