Бесконечно можно делать три вещи: смотреть, как горит огонь, смотреть, как течет вода, — и говорить о безопасности небезопасных протоколов. Мы уже рассказывали о сканировании корпоративных сетей, сетевых устройств и Cisco IOS. На этот раз предлагаем вам историю о протоколе SNMP, а точнее — о работе по этому протоколу с сетевым оборудованием HP/H3C и Huawei. Данные устройства позволяют получить доступ к критически важной информации, обладая минимальными правами. Эксплуатация уязвимости позволяет злоумышленнику проникнуть в корпоративные сети коммерческих компаний и технологические сети операторов связи, использующих эти широко распространенные устройства.
В 2003 году Huawei Technologies и 3Com основали совместное предприятие H3C. В 2007 году компания 3Com выкупила у Huawei ее долю, а в 2010 году вошла в состав HP, которая автоматически получила и H3C. Таким образом, уязвимым оказалось сетевое оборудование сразу нескольких вендоров — 3Com, H3C и HP, Huawei. Устройства эти используются в тысячах компаний, от небольших предприятий до крупнейших провайдеров.
Какую же критически важную информацию они выдают? Речь идет о пользовательских данных, хранящихся в базах h3c-user.mib и hh3c-user.mib. Эти mib определяют объекты для «Manage configuration and Monitor running state for userlog feature». В новой версии ОС доступ к ним должен был быть разрешен только с read-write community string. Однако этого не было сделано, и получить информацию можно и с community string с правами read-only.
В этих базах содержится следующая информация:
И чтобы все это узнать, необходимо лишь угадать read-only community string, которая очень часто настроена по умолчанию как «public».
За эту информацию на устройствах отвечает OID: 1.3.4.1.4.1.2011.10 и OID: 1.3.6.1.4.1.25506.
Непосредственно за саму информацию о настроенных локальных пользователях отвечает OID: 1.3.6.1.4.1.2011.10.2.12.1.1.1 и 1.3.6.1.4.1.25506.2.12.1.1.1.
В ответ на запрос с этими OID мы получим (H)H3cUserInfoEntry, которая содержит следующие значения:
• (h)h3cUserName — The name of local user, it must be unique
• (h)h3cUserPassword — The password of local user, default is null
• (h)h3cAuthMode — The encrypting type of password:
• (h)h3cUserLevel The privilege of local user the value range is from 0 to 3, and 0 is minimum, 3 is maximum. default is 0.
В приведенном ниже примере snmpwalk вызывается с ключом –Cc, так как работа идет с динамическими индексами. Если выполнить запрос без этого ключа, может возникнуть ошибка «Error: OID not increasing».
Любопытная деталь: в настройках указано, что пароль должен быть зашифрован. И при просмотре конфигурации так оно и есть:
Но при этом через SNMP пароль все равно указывается в открытом виде (вероятно, это зависит от конкретного устройства):
Итак, мы смогли получить учетные данные локальных пользователей, в том числе и с максимальным уровнем привилегий (пользователь «admin» с уровнем привилегий «3»). Теперь остается лишь попробовать подключиться к устройству через SSH или Telnet:
Нам повезло и доступ на сервер по SSH не был запрещен. Но если вдруг по SSH или Telnet зайти не удается…
… всегда можно попробовать зайти через web (картинка кликабельна):
Теперь посмотрим на другой пример.
В данном случае мы получили пароли в зашифрованном виде. Huawei может использовать для шифрования паролей алгоритмы AES256 или DES. При этом в схеме с алгоритмом DES используется одинаковый ключ шифрования на всех уязвимых устройствах и не используется соль при шифровании. В результате пароль может быть легко дешифрован, о чем написали Roberto Paleari и Ivan Speziale из компании Emaze Networks в 2012 году.
Итак, можно открывать любимую консоль и пытаться подключиться с полученными данными по SSH или Telnet:
Или, как мы уже сказали, если доступ по этим протоколам ограничен, всегда можно попробовать зайти через другой протокол:
Следует заметить, что в схеме шифрованием с AES256 тоже есть проблемы: в 2014 году те же ребята из Emaze Networks опубликовали еще одну заметку, в которой рассказывают о том, как все плохо.
Результаты поиска в Shodan наглядно демонстрируют, насколько популярна данная уязвимость:
Так как Huawei — компания китайская, неудивительно, что большая часть всех доступных устройств находится в Китае. Но в России тоже не все гладко:
Надо сказать, что первым о данной уязвимости написал Kurt Grutzmacher еще в 2012 году. В том же году он выступал на конференции Bay Threat, где подробно описал проблему и то, чем она грозит. Производители оборудования выпустили патчи для своих устройств — но, как это обычно бывает с сетевым оборудованием, большое количество устройств остается уязвимым до сих пор.
Эксплуатация данной уязвимости позволяет злоумышленнику проникнуть в корпоративную сеть коммерческой компании, в технологическую сеть оператора связи и любой другой организации. Получение контроля над пограничным сетевым оборудованием предоставляет злоумышленнику возможность любым образом распоряжаться проходящим через устройство трафиком и открывает путь для развития атаки на внутрисетевые автоматизированные системы.
Все это еще раз подтверждает прописную истину: небезопасные протоколы несут в себе большую опасность. Для того чтобы попасть в корпоративную сеть, не нужно использовать хитрые схемы со сложными эксплойтами: достаточно одного протокола SNMP со стандартной community string с минимальными правами read-only и еще одного протокола для доступа на устройства — SSH, Telnet или web. Причем, как показала практика, если доступ по Telnet или SSH на большинстве устройств ограничен, то по HTTP — входи кто хочет.
И еще один «приятный бонус». При настроенном сервисе регистрации попытку зайти на устройство по SSH, Telnet или web можно будет увидеть, например, на Syslog-сервере. Но для запросов по SNMP подобных сообщений не будет, и можно даже не узнать, что кто-то получил учетные данные или натворил что-нибудь еще (например, изменил конфигурацию устройства).
Достаточно просто. Во-первых, надо выключить сервис SNMP.
Если этот протокол все же необходим, то использовать SNMPv3. Если и это невозможно, избегайте использования стандартных community string — public и private.
Можно исключить объекты таблицы (H)H3cUserInfoEntry из доступа с помощью команды excluded, а также запретить доступ к устройству с правами read-write.
И конечно, необходимо ограничивать доступ к устройству с помощью списков разрешенных адресов или списков доступа.
Автор: Евгений Строев, исследовательский центр Positive Technologies
В 2003 году Huawei Technologies и 3Com основали совместное предприятие H3C. В 2007 году компания 3Com выкупила у Huawei ее долю, а в 2010 году вошла в состав HP, которая автоматически получила и H3C. Таким образом, уязвимым оказалось сетевое оборудование сразу нескольких вендоров — 3Com, H3C и HP, Huawei. Устройства эти используются в тысячах компаний, от небольших предприятий до крупнейших провайдеров.
Какую же критически важную информацию они выдают? Речь идет о пользовательских данных, хранящихся в базах h3c-user.mib и hh3c-user.mib. Эти mib определяют объекты для «Manage configuration and Monitor running state for userlog feature». В новой версии ОС доступ к ним должен был быть разрешен только с read-write community string. Однако этого не было сделано, и получить информацию можно и с community string с правами read-only.
В этих базах содержится следующая информация:
- имена локальных пользователей,
- их пароли,
- тип шифрования пароля,
- уровень привилегий, которым обладает пользователь.
И чтобы все это узнать, необходимо лишь угадать read-only community string, которая очень часто настроена по умолчанию как «public».
За эту информацию на устройствах отвечает OID: 1.3.4.1.4.1.2011.10 и OID: 1.3.6.1.4.1.25506.
Непосредственно за саму информацию о настроенных локальных пользователях отвечает OID: 1.3.6.1.4.1.2011.10.2.12.1.1.1 и 1.3.6.1.4.1.25506.2.12.1.1.1.
В ответ на запрос с этими OID мы получим (H)H3cUserInfoEntry, которая содержит следующие значения:
• (h)h3cUserName — The name of local user, it must be unique
• (h)h3cUserPassword — The password of local user, default is null
• (h)h3cAuthMode — The encrypting type of password:
- 0: password simple, means password is clean text.
- 7: password cipher, means password is encrypted text.
- default is 0
• (h)h3cUserLevel The privilege of local user the value range is from 0 to 3, and 0 is minimum, 3 is maximum. default is 0.
В приведенном ниже примере snmpwalk вызывается с ключом –Cc, так как работа идет с динамическими индексами. Если выполнить запрос без этого ключа, может возникнуть ошибка «Error: OID not increasing».
Любопытная деталь: в настройках указано, что пароль должен быть зашифрован. И при просмотре конфигурации так оно и есть:
Но при этом через SNMP пароль все равно указывается в открытом виде (вероятно, это зависит от конкретного устройства):
Итак, мы смогли получить учетные данные локальных пользователей, в том числе и с максимальным уровнем привилегий (пользователь «admin» с уровнем привилегий «3»). Теперь остается лишь попробовать подключиться к устройству через SSH или Telnet:
Нам повезло и доступ на сервер по SSH не был запрещен. Но если вдруг по SSH или Telnet зайти не удается…
… всегда можно попробовать зайти через web (картинка кликабельна):
Теперь посмотрим на другой пример.
В данном случае мы получили пароли в зашифрованном виде. Huawei может использовать для шифрования паролей алгоритмы AES256 или DES. При этом в схеме с алгоритмом DES используется одинаковый ключ шифрования на всех уязвимых устройствах и не используется соль при шифровании. В результате пароль может быть легко дешифрован, о чем написали Roberto Paleari и Ivan Speziale из компании Emaze Networks в 2012 году.
Итак, можно открывать любимую консоль и пытаться подключиться с полученными данными по SSH или Telnet:
Или, как мы уже сказали, если доступ по этим протоколам ограничен, всегда можно попробовать зайти через другой протокол:
Следует заметить, что в схеме шифрованием с AES256 тоже есть проблемы: в 2014 году те же ребята из Emaze Networks опубликовали еще одну заметку, в которой рассказывают о том, как все плохо.
Результаты поиска в Shodan наглядно демонстрируют, насколько популярна данная уязвимость:
Так как Huawei — компания китайская, неудивительно, что большая часть всех доступных устройств находится в Китае. Но в России тоже не все гладко:
Надо сказать, что первым о данной уязвимости написал Kurt Grutzmacher еще в 2012 году. В том же году он выступал на конференции Bay Threat, где подробно описал проблему и то, чем она грозит. Производители оборудования выпустили патчи для своих устройств — но, как это обычно бывает с сетевым оборудованием, большое количество устройств остается уязвимым до сих пор.
Эксплуатация данной уязвимости позволяет злоумышленнику проникнуть в корпоративную сеть коммерческой компании, в технологическую сеть оператора связи и любой другой организации. Получение контроля над пограничным сетевым оборудованием предоставляет злоумышленнику возможность любым образом распоряжаться проходящим через устройство трафиком и открывает путь для развития атаки на внутрисетевые автоматизированные системы.
Все это еще раз подтверждает прописную истину: небезопасные протоколы несут в себе большую опасность. Для того чтобы попасть в корпоративную сеть, не нужно использовать хитрые схемы со сложными эксплойтами: достаточно одного протокола SNMP со стандартной community string с минимальными правами read-only и еще одного протокола для доступа на устройства — SSH, Telnet или web. Причем, как показала практика, если доступ по Telnet или SSH на большинстве устройств ограничен, то по HTTP — входи кто хочет.
И еще один «приятный бонус». При настроенном сервисе регистрации попытку зайти на устройство по SSH, Telnet или web можно будет увидеть, например, на Syslog-сервере. Но для запросов по SNMP подобных сообщений не будет, и можно даже не узнать, что кто-то получил учетные данные или натворил что-нибудь еще (например, изменил конфигурацию устройства).
Как защищаться
Достаточно просто. Во-первых, надо выключить сервис SNMP.
Если этот протокол все же необходим, то использовать SNMPv3. Если и это невозможно, избегайте использования стандартных community string — public и private.
Можно исключить объекты таблицы (H)H3cUserInfoEntry из доступа с помощью команды excluded, а также запретить доступ к устройству с правами read-write.
И конечно, необходимо ограничивать доступ к устройству с помощью списков разрешенных адресов или списков доступа.
Автор: Евгений Строев, исследовательский центр Positive Technologies
