Дом с привидениями: уязвимости в ИИУП

    Недавно, просматривая один из своих любимых англоязычных блогов, я наткнулся на статью Дэна Фармера (того самого, что создал один из первых сканеров уязвимостей в истории), название которой можно (пусть несколько вольно) перевести как «ИИУП: паровозик отправляется в АД».

    Осмотрев милый моему сердцу Хабр, я не обнаружил упоминаний об этой похвальной статье и решил исправить это упущение, тем более что моим интересам она вполне соответствует (расследования тут как такового не потребовалось — Дэн все расследовал до нас, а вот скандалоинтриги вполне прослеживаются).
    Итак, обо всем по порядку. Кто такой ИИУП и зачем он отправил в ад какой-то-там поезд?

    Те из хабровчан, кто работает в больших и красивых датацентрах знают, что это такое (и наверняка пользуются во всю), для тех же, кому не повезло работать в большом и красивом датацентре, замечу, что ИИУП (в народе IPMI, сиречь Intellectual Platform Management Interface) это интеллектуальный интерфейс управления платформой. Он присутствует у всех серверных матплат, и представляет собой нечто вроде встроенного KVM «на стероидах».
    Эта похвальная вещица позволяет администратору получать доступ к серверу вне зависимости от капризов BIOS, ОС, и даже ЦП – а это значит что компонент, ответственный за работу ИИУП (BMC, Baseboard Management Controller, Контроллер Управления Матплатой) продолжает работать, даже когда сам сервер выключен (но не обесточен) или завис.
    Собственно, ИИУП вообще крайне устойчив к различным «неприятностям», и может передавать данные (и обеспечивать доступ) в очень разнообразных «катастрофических» ситуациях. Разумеется, помимо собственно управления, BMC также осуществляет мониторинг, журналирование, эротический массаж, приготовление кофе и много других добрых и похвальных дел.

    Вкусно? Не совсем…

    Например, встает резонный вопрос – а как этот замечательный агрегат решает вопросы аутентификации?
    И вот тут начинаются проблемы.
    Аутентификация происходит по паре username/password, длинна пароля не превышает 20 знаков, при этом у некоторых BMC они тупо хранятся в нативном виде (Dell, правда, хеширует… но без соли. Двадцать первый век, однако…).
    Многие из них поддерживают RADIUS и.т.п. (не всегда адекватно), но практически всегда присутствует возможность перехода на «аварийную» базовую аутентификацию (что на самом деле вполне логично – ИИУП должен продолжать работать в условиях чрезвычайных ситуаций, при которых аутентификационный сервер может сам оказаться недоступен).

    Но самое, пожалуй, интересное – если некто залогинен на конкретном сервере с администраторскими правами, он автоматически получает полные админские права в отношении BMC этого конкретного сервера.

    Таким образом, если некто (ну… Мэллори там, например) root’нул сервер, то сей злоумышленник может дополнительно насолить жертве, «творчески переработав» список ИИУП-пользователей машины или, что еще лучше, украсть ИИУП логины/пароли (я кажется уже говорил, что хранение паролей в ВМС зачастую не то чтобы очень хорошо продумано, да?), ведь архитектура ИИУП такова, что повторное использование паролей вероятно. В принципе, проблема с повторным использованием паролей может быть до некоторой степени решена с помощью RAKP (специальный протокол обмена ключами), однако его применение требует нешуточных навыков, и не очень хорошо описано в литературе (стоит также помнить, что RAKP никак не поможет не допустить Мэллори в BMC сервера, на котором Мэллори уже получил администраторские права).

    Многие ВМС имеют собственный веб-сервер (потому что, конечно, куда же без него, в низкоуровневой-то системе мониторинга и администрирования…), что теоретически расширяет возможный репертуар «дружеских розыгрышей», которые Мэлори может произвести после захвата BMC на отдельно взятой машине.

    Обновление прошивок BMC тоже не слишком хорошо продумано – во-первых, «в норме» прошит может быть только специально подписанный образ от поставщика (а это значит что если в вашем варианте ИИУП нашли «дыру», то вам ничего не остается, кроме как ждать когда вендор соблаговолит написать официальный апдейт), а во-вторых, для ряда «сравнительно бюджетных» серверных матплат сами ВМС произведены третьей стороной, что превращает апдейт в задачу с уже двумя (а то и больше, ведь прошивку тоже могли «аутсорснуть») неизвестными.

    Тут стоит заметить, что в ходе подготовки своего материала Фармер нашел эксплоит, позволяющий по SSH получить root на BMC «крупного вендора» (подробности пока не разглашены, ибо будучи человеком ответственным, он решил дать вендору возможность выпустить обновление)

    Подводить итог пока рано – как ни удивительно, статья Фармера чуть ли не первый материал, пытающийся обощить информацию о проблемах безопасности ИИУП (более того, материал активно обновляется, обрастая интересными подробностями, так что watch this space), однако одно можно сказать наверняка – безопасность ИИУП это чертовски интересно.

    Надеюсь, дорогие хабровчане, мой скромный, беглый пересказ замечательной статьи не только развеселил вас, но и, быть может, заинтересовал еще одной веселой и необычной проблемой.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 34

      +10
      Я уже давно писал, что на многих матерях supermicro есть возможность получить шелловый доступ к BMC (IPMI) и запустить там свой бинарник, собранный под арм. Таким образом, можно обеспечить malware возможность выживания переустановки ОС (достаточно потом будет отправить через клавиатуру нужные наборы команд), перезагрузку и даже выключение. Более того, большинство ipmi'ев шьётся, и в отличие от биосов, там обычный пакованный линукс с cramfs или чем-то подобным, то есть внедрение в такой код не выглядит нереальным.

      • НЛО прилетело и опубликовало эту надпись здесь
          +3
          Конечно глупо! Но из-за (ИМХО) дурацкой фишки с автомагическим доступом локального root к локальному BMC изолировать IPMI от «нехороших сетей» становится заметно сложнее
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Насколько я понимаю большинство современных реализаций не предполагают «жесткого» выделения отдельного порта.
              Цитата из inFAQ первоисточника:
              All the versions of IPMI I've seen can talk just fine piggybacked on any generic Ethernet interface; the specifically labeled ones are for convenience so you don't plug an IPMI port into your main network. Indeed the net seems full of people complaining of various versions of IPMI grabbing the main Ethernet interface when they don't want it to
                0
                На сколько я понимаю — предполагают. И даже если он не жестко выделенный — он отдельный. Т.е. может тот, а может этот (если это можно настроить), но не один и тот же для обычной сетки и менеджмента. Разделяемых вообще лично никогда не видел. На HP с его ILO2 в частности. Есть еще в хозяйстве супермикро. Тоже отдельный помеченный порт. И естественно он при нормальном администрировании подключается в специальный манаджмент-влан, доступ к которому строго ограничен.
                  0
                  Я возможно что-то недопонимаю (errare humanum est и все такое), но его отдельность не очень помогает в случае описанного первоисточником и пересказанного мной сценария, когда злоумышленник получает root на сервере, проникнув туда через «грязную» сетку, поскольку в этом случае злоумышленник имеет возможность распоряжаться BCM данного конкретного сервера по своему усмотрению.

                  А распоряжаясь им по своему усмотрению он получает доступ и в манаджмент-влан (не говоря уже о том, что в ряде случаев еще и пароли к IPMI серверов в той же группе получает), разве не так?
                    0
                    Тогда возможно не понял я. Это действительно крайне скверный сценарий. Не зря я разделял управляющие вланы для групп серверов разной степени критичности. Как чувствовал :(
                      0
                      Да, это довольно мрачно. Но вы молодец что их разделили :-)

                      P.S.:
                      собственно, мне непонятно, зачем стандарт написали так, что возникает ситуация вида
                      «if you can get any of these three items — root access on a server, have an IPMI administrative account, or shell access to the BMC, you can compromise the other two»


                      Странно это както. Нелогично.
                        0
                        Собственно типовой сценарий, почти то же самое, что с виртуализацией. Ломается гостевая, юзается уязвимость, попадаем в другие гостевые или имеем гипервизор и оттуда в приватные сети. Лишний раз убеждаюсь, что даже в серверных сегментах имеет смысл изолировать в пределах одного широковещательного домена сервера друг от друга той или иной технологией (когда серверам, конечно, не нужно общаться, но очень часто — не нужно, для того же управляющего сегмента).
                          0
                          Ну с виртуализацией эскейпы хотя бы признаются за «глюк»

                          Тут это (отсутствие аутентификации на KCS-интерфейсе ВМС) считается нормой

                          Кстати, вчера ниже по течению этого треда зародилась мысль придушить OpenIPMI device driver. Если получится это сделать, не нарушив «удаленные» возможности IPMI и/или работу сервера, то local root окажется отрезан от local BMC и фокус с «рутнуть бокс, затем влезть в его ВМС» работать перестанет…
                            0
                            Кстать, если верить www.securitylab.ru/contest/437841.php у Интел как раз сейчас все плохо в другую сторону. Минимальные возможности контроллировать BMC из ОС. И максимальные в обратном направлении.

                            «В третьих, оборудование МЕ и ВМС не изолировано от основного оборудования вычислительной установки через стандартный интерфейс IPMI. Оборудование на прямую подключено к оперативной памяти и системной шине. Соответственно оно может контролировать информационные ресурсы (например дисковую систему, ОП) и управлять вычислительными процессами на основном оборудовании вычислительной системы.
                            В четвертых, сервисный сетевой трафик пропускается не через специальный выделенный сетевой адаптер, а туннелируется сквозь сетевые адаптеры общего назначения размещенные на материнской плате либо подключенные через слоты расширения (PCI-E).
                            В пятых, сервисный сетевой трафик можно контролировать только на внешнем оборудовании, легальные средства контроля уровня операционной системы пакеты сервисного трафика просто не видят, они через средства контроля ОС не проходят. И если сетевой адаптер работает на локальную сеть или на доступ в Интернет, то программное обеспечение функционирующее в недрах МЕ и ВМС автоматически получает доступ в такую информационную сеть.
                            И в шестых, аппаратура МЕ и ВМС не контролируется с уровня операционной системы, нет возможности вмешаться в ее работу или просто проконтролировать ее текущее состояние. Та информация которая получается через официальный драйвер АМТ не в счет, это не система независимого контроля.»
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Ога, уже скоро и унитазы прошьют — как ж без этого?
              0
              Где-то видел опрос «От каких благ цивилизации Вы не можете отказаться» — большинство выбрало… унитаз. Так что не за горами прошивки, root и т.д для данного девайса.
                0
                "… Ваш унитаз хакнут! Отправти 500 рублей на этот номер 8-xxx-yyyyyyy… "
            +1
            Простите, но в грамотно настроенной схеме сети IPMI/RDAC/iLO бегает:
            а) в отдельной подсети.
            б) в отдельном влане. Dell'овские сервера у меня прямо в биосе спрашивали, Vlan с каким ID слушать для IPMI, и не зная влана, пока будешь все 4096 вланов перебирать при физическом включении в порт, скорее всего к тебе уже придут суровые дяденьки и спросят — а какого, собственно, чёрта ты сюда полез (а попасть в серверную еще никто не отменял).
            с) имея ACL доступа на самих IPMI (пускать 192.168.0.1, остальные в бан)
            д) имея ACL на маршрутизаторе (ты куда? в 192.168.250.0/24? а откуда? 192.168.0.1? ладно, проходи! ты не 192.168.0.1? Ну свободен, следующий!)
            другие более высокоуровневые в т.ч варианты физическо и логической защиты.

            И пусть там, в IPMI, будет хоть тыщапицот дырок, это никого, кроме Hardware Administrator волновать не должно и не будет.
            Более того, не важно что это за нода и из какого кластера — iLO, Drac, другая реализация, в связи с отдельным, как правило, линуксом, на отдельной hw плате/чипе, обновляется отдельно от операционки. Я, по хорошему, ответственного за сервер администратора могу не дергать по поводу «дядька, мне тут надо iLO обновить, выведи сервер из эксплуатации минут на 15 или когда там у тебя запланированные работы, я к тебе присоседиться хочу на maintenance»/
            Я выдал администратору ip/логин пароль, на этом моя зона ответственности закончена, как HW Admin. А администратор системы/сервиса дальше развлекается- поставил нужную ось, подсунул ей нужные драйвера, развернул сервер/сервис и т.п.
              0
              Я возможно что-то недопонимаю за на предмет выделения в отдельную подсеть и влан в контексте «фичи» с предоставлением доступа к локальному BCM локальному руту, см. выше ветку с casperrr, а вот ACL тут определенно насыпят Мэлори соли на глазок.

              Плюсую.
                0
                Ну в грамотно построенной сети топологию знает очень ограниченный круг лиц, администратора сервиса вообще не должно волновать, как он подключается к своему серверу с сервисом и как этот сервисс сервером видит локальную сеть либо же интернет, если сервер торчит наружу. Особенно в больших конторах, где те же вланы могут использоваться на уровне 50-60% из 4096, и 10 подсеть может быть заполнена по подсетям на теже 50-60%. про транспортных ISP вообще молчу…
                  +1
                  Мне несколько боязно даже обсуждать «грамотно построенную» сеть (ибо, каюсь, редко доводилось своими глазами видеть, опыта мало-сс), но не является ли такой взгляд на поднятую Фармером проблему чем-то вроде «security by obscurity» («не знаешь топологию — не сожрешь!»)?
                    0
                    Я недавно работал в небольшом мобильном операторе Украины (полная сеть включая трафик от конечных пользователей до ператорского шлюза в интернет), котороя строилась одним умным дядькой без ВО, имеющим на тот момент шикарный пакет сертификатов от Cisco. Сеть была построена грамотно. И да, кроме него всю топологию сейчас знает только он и документация, им написанная. PS — факапов падения полностью всей сети с момента разворачивания оператора насколько я знаю, не было.
                    А как говорила моя знакомая, работавшая когда-то в билинговом отделе другого мобильного оператора, тоже Украины, тамошний бекбон тоже был построен шарящим дядькой с цисковскими сертификатами.

                    А вообще — до работы в данном опсосе я грамотные сети видел аж два раза за всю работу сисадмином начиная с 2003 года. на последнем месте работы я эту самую сеть с нуля переделывал уже самостоятельно, фактически осваивая циску с нуля
                      0
                      И да, кроме него всю топологию сейчас знает только он и документация, им написанная.


                      Я было сначала испугался, а потом вспомнил что я не пользуюсь мобильными операторами Украины.

                      А вообще моя реплика была не о распространенности Грамотных Сетей (мой опыт мал и нерепрезентативен, вероятно), сколько о том что подходы основанные на незнании злоумышленником топологии — не совсем… корректные.

                      То есть лучше конечно, чем никакие, но все же… Все же было бы лучше если бы поставщики чуть больше думали о защите IPMI (история с паролями в плейнтексте это, согласитесь, срам...).

                      Кстати, меня вот мучает вопрос — зачем вообще эта фишка с «автоматичным» предоставлением полных прав на BCM локальному руту?
                        0
                        Ну во первых — документация по сетям обычно закрыта для ограниченного списка лиц.
                        Попытки просканить тоже можно отмониторить, а дальше — передача дела в отдел физической безопасности или руководству. Такое в крупных и не только, конторах, не редкость — сам был участником.
                        А так — ну придётся злоумышленнику перебирать, например, 10 сеть. Только вот проблема, пока он будет перебирать 10.х сеть, к месту попытки перебора придет злой бородатый админ с лопатой(реальный инцидент у товарища). ну или вообще, мне как сетевику никто не мешает держать сервера не в 10, а в 192.168. например.
                        Вообще, есть много интересных технологий по выявлению инсайдера/злоумышленника. и ручное вычитывание логов прокси тут на уровне «админу есть что почитать при совсем скуке».
                        Мониторинг, мониторинг и еще раз мониторинг. Ну и аналитика мониторинга, да.
                          0
                          То есть по большому счету, при Грамотном Мониторинге в Грамотной Сети, Мэллори спалится раньше, чем сумеет «операционализировать» факт успешного захвата отдельно взятого сервера (и его ВСМ), так получается?

                          Не спорю ;-)

                          Но… согласитесь же, что все эти «ляпы» (зачастую «недоброкачественное» хранение паролей, уязвимости по SSH, итд итп) и «странности» (вроде «root всегда может достучаться до ВСМ той машины на которой он root») — не к добру (сеть и или анализ данных мониторинга ведь могут оказаться чуть менее чем полностью грамотными, не так ли?)
                            0
                            Стоп стоп…
                            Простите, я возможно туплю, но… а почему злоумышленник будет перебирать ?
                            Root accounts on a server can create local administrative IPMI accounts without any additional authentication

                            А имея таковой, злоумышленник заполучивший сервер сможет оперативно добыть сведения о настройках «чистой» админской сети, разве не так?
                              0
                              Эм. вообще-то пароль на настройки биоса и IPMI настраивается при первичной установке сервера в использование. Ну а дальше сервер запускается в работу
                                0
                                Насколько я понимаю, локальный рут может без дополнительных аутентификационных заморочек досыпать в (локальную) ВМС произвольных учетных записей с правами IPMI-админскими, и это не глюк, а фишка стандарта IPMI.

                                Насколько я понимаю, без этой фишки «злоумышленный» рут отдельного сервера не грозил бы ничем ВМС/IPMI (не знаешь IPMI-админские credentials? Иди на… юг)

                                Наличие данной фишки меня, признаться, несколько конфузит ибо я вообще не вижу подобному «законного» юзкейса
                                  0
                                  в Dell'ах bios закрывается на пароль, а функционал IPMI входит в настройку биоса. Так точно было на стареньких R320, или 300, не помню уже, я на этих серверах на последней работы\е видел их только один раз — зайти на машину, обновить биос и проставить ESXi, причём IPMI там можно было выделить в shared, я не проверял, но мне кажется, что IPMI будет слушаться просрачно для хост-ос на обоих сетевых интерфейсах.
                                  Соответственно, чтобы что-то настроить надо при физическом доступе в серверной — потушить сервер, сбросить его настройки, и только тогда получить рут в биосе/IPMI. А учитывая, что это врядли пройдет мимо мониторинга — со всеми вытекающими.
                                  Тоже самое, если я не ошибаюсь, в серверах HP, выделенного iLO
                                  Насчёт супермикры — судя по тем серверам, что я щупал (старенькие ксеончики) на тот момент я вообще в последней версии BIOS'а IPMI не нашел, возможно там это реализовано либо отдельной платой либо в более новых версий материнских плат, я не владею информацией по линейке супермикровских материнских плат.
                                  Насчёт Sun/IBM тоже не могу сказать, есть ли там что-то такое, но по Sun'у могу уточнить у билингистов с прошлой работы.
                                  тот IBM, что стоял на прошлой работе в продакшене имел выделенный IPMI порт, но, поскольку это был mission critical функционал, сервера вообще не трогались
                                    0
                                    Хм — я попробую уточнить для всех ли версий IPMI есть возможность «прикрутить» новую локальную IPMI учетку из-под локального рута.

                                    Dell PowerEdge R300 имел IPMI v1.5, может эти приколы только в 2.0…
                                      0
                                      Попробуйте позвонить по горячей линии Dell на 8-800, у них шикарно подкованный саппорт, к сожалению у меня было мало опыта возни с R300, поэтому я банально не знаю. Только помню что биос был закрыт на пароль и IPMI настраивался в основном экране биоса
                                        0
                                        Звонок подруге оказался более оперативен.
                                        Узнать удалось следующее:

                                        «В мане на IPMItool что шла с PowerEdgeами написано, что при обмене данными между ipmitool и локальным ВМС через интерфейс KCS аутентификации не требуется. Так что если root может запустить ipmitool и подключиться к open (keyboard controller style) interface поставляемому BMC, то он может делать с ВМС практически что угодно, не выходя в BIOS. Можно осложнить этот процесс, но пока жив OpenIPMI device driver предотвратить это нельзя»
                                          0
                                          Спасибо, буду знать
                                            0
                                            Интересно, OpenIPMI device driver он делает чтонибудь, кроме как давать руту возможность лазить в ВМС «нахаляву»?

                                            Просто если нет, то его, вероятно, имеет смысл того… упокоить…

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

              Самое читаемое