Прокачати SNMP на пристроях Huawei і H3C

Нескінченно можна робити три речі: дивитися, як горить вогонь, дивитися, як тече вода, — і говорити про безпеку небезпечних протоколів. Ми вже розповідали про скануванні корпоративних мереж, мережевих пристроїв і Cisco IOS. На цей раз пропонуємо вам історію про протоколі SNMP, а точніше — про роботу з цього протоколу з мережевим обладнанням HP/H3C і Huawei. Дані пристрої дозволяють отримати доступ до критично важливої інформації, володіючи мінімальними правами. Експлуатація уразливості дозволяє зловмисникові проникнути в корпоративні мережі комерційних компаній і технологічні мережі операторів зв'язку, які використовують ці широко поширені пристрої.

image

У 2003 році Huawei Technologies і 3Com заснували спільне підприємство H3C. У 2007 році компанія 3Com викупила у Huawei її частку, а в 2010 році увійшла до складу HP, яка автоматично отримала і H3C. Таким чином, вразливим виявилося мережеве обладнання відразу кількох вендорів — 3Com, H3C і HP, Huawei. Ці пристрої використовуються в тисячах компаній, від невеликих підприємств до найбільших провайдерів.

Яку ж критично важливу інформацію вони видають? Мова йде про користувальницьких даних, що зберігаються в базах h3c-user.mib і hh3c-user.mib. Ці mib визначають об'єкти для «Manage Monitor configuration and 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 maximum is. default is 0.

У наведеному нижче прикладі snmpwalk викликається з ключем-Cc, так як робота йде з динамічними індексами. Якщо виконати запит без цього ключа, може виникнути помилка «Error: OID not increasing».

image

Цікава деталь: в налаштуваннях зазначено, що пароль повинен бути зашифрований. І при перегляді конфігурації так воно і є:

image

Але при цьому через SNMP пароль все одно вказується у відкритому вигляді (ймовірно, це залежить від конкретного пристрою):

image

Отже, ми змогли отримати облікові дані локальних користувачів, в тому числі і з максимальним рівнем привілеїв (користувач «admin» з рівнем привілеїв «3»). Тепер залишається лише спробувати підключитися до пристрою через SSH або Telnet:

image

Нам пощастило і доступ на сервер SSH не був заборонений. Але якщо раптом по SSH або Telnet зайти не вдається…

image

… завжди можна спробувати зайти через web (картинка кликабельна):

image

image

Тепер подивимося на інший приклад.

image

В даному випадку ми отримали паролі в зашифрованому вигляді. Huawei може використовувати для шифрування паролів алгоритми AES256 або DES. При цьому в схемі з алгоритмом DES використовується однаковий ключ шифрування на всіх вразливих пристроях та не використовується сіль при шифруванні. В результаті пароль може бути легко дешифрован, про що написали Roberto Paleari і Ivan Speziale з компанії Emaze Networks в 2012 році.

image

image

Отже, можна відкривати улюблену консоль і намагатися підключитися з отриманими даними по SSH або Telnet:

image

Або, як ми вже сказали, якщо доступ по цим протоколам обмежений, завжди можна спробувати зайти через інший протокол:

image

Слід зауважити, що в схемі з шифруванням AES256 теж є проблеми: у 2014 році ті ж хлопці з Emaze Networks опублікували ще одну заметк, в якій розповідають про те, як все погано.

Результати пошуку Shodan наочно демонструють, наскільки популярна дана уразливість:

image

image

image

Так як Huawei — китайська компанія, не дивно, що більша частина всіх доступних пристроїв знаходиться в Китаї. Але в Росії теж не все гладко:

image

image

image

Треба сказати, що першим про дану уразливості написав Kurt Grutzmacher ще в 2012 році. У тому ж році він виступав на конференції Bay Threat, де докладно описав проблему і те, чим вона загрожує. Виробники обладнання випустили патчі для своїх пристроїв — але, як це зазвичай буває з мережевим обладнанням, велика кількість пристроїв залишається уразливим до цих пір.

Експлуатація даної уразливості дозволяє зловмисникові проникнути в корпоративну мережу комерційної компанії, технологічну мережу оператора зв'язку і будь-який інший організації. Отримання контролю над прикордонним мережевим обладнанням надає можливість зловмиснику будь-яким чином розпоряджатися проходить через пристрій трафіком і відкриває шлях для розвитку атаки на внутрішньомережеві автоматизовані системи.

Все це ще раз підтверджує прописну істину: небезпечні протоколи несуть у собі велику небезпеку. Для того щоб потрапити в корпоративну мережу, не треба використовувати хитрі схеми зі складними експлойта: достатньо одного протоколу SNMP зі стандартною community string з мінімальними правами read-only і ще одного протоколу для доступу на пристрої — SSH, Telnet або web. Причому, як показала практика, якщо доступ Telnet або SSH на більшості пристроїв обмежений, то по HTTP — заходь хто хоче.

І ще один «приємний бонус». При налагодженому сервісі реєстрації спробу зайти на пристрій по SSH, Telnet або web можна буде побачити, наприклад, на Syslog-сервері. Але для запитів по SNMP подібних повідомлень не буде, і можна навіть не дізнатися, що хтось отримав облікові дані або накоїв що-небудь ще (наприклад, змінив конфігурацію пристрою).

Як захищатися

Досить просто. По-перше, треба вимкнути сервіс SNMP.

image

Якщо цей протокол все ж таки необхідний, то використовувати SNMPv3. Якщо і це неможливо, уникайте використання стандартних community string — public і private.

image

Можна виключити об'єкти таблиці (H)H3cUserInfoEntry з доступу за допомогою команди excluded, а також заборонити доступ до пристрою з правами read-write.

І звичайно, необхідно обмежувати доступ до пристрою за допомогою списків дозволених адрес або списків доступу.

image

Автор: Євген Строєв дослідний центр Positive Technologies

Посилання:
securityvulns.ua/docs28680.html
веб.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3268
www.slideshare.net/grutz/huaweih3chp-snmp-weakness-and-deciphering-the-cipher
blog.emaze.net/2012/11/weak-password-encryption-on-huawei.html
blog.emaze.net/2014/01/yet-another-huawei-weak-password.html
веб.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4960
support.huawei.com/enterprise/ReadLatestNewsAction.action?contentId=NEWS1000001141
h20566.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03515685
support.huawei.com/enterprise/NewsReadAction.action?newType=0301&contentId=NEWS1000001165&idAbsPath=0301_10001&nameAbsPath=Services%2520News

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.