2009. augusztus 26., szerda

SNMP - Security Not My Problem

Az SNMP igazából a Simple Network Management Protocol rövidítése, a célja pedig a nevéből kitalálható - elsősorban hálózatra kötött eszközök kezelését, monitorozását lehet megoldani a segítségével. Általánosságban elmondható róla, hogy rendkívül sok mindenre használható, viszont meglehetősen keveset foglalkoznak vele a hálózatok beállításakor, a hálózati eszközök beásásakor az integrátorcégek: a tesztelési jelentések túlnyomó részében található valamilyen SNMP-vel kapcsolatos rés - ilyen értelemben az SNMP-t biztonsági szempontból szükséges rosszként aposztrofálhatjuk. Ahhoz, hogy megfelelően alakítsanak ki SNMP-t, rengeteg apróságra kell figyelni.

Az SNMP hagyományosan az UDP-s 161-es porton fut: a hálózati eszközökön futó SNMP agent mindenfélét megmond az eszközök lelkivilágával kapcsolatosan a menedzsment konzolnak. SNMP-n keresztül (is) működnek a nagy hálózatmenedzsment eszközök, mint például a Tivoli vagy a CiscoWorks. Az SNMP jó, hasznos, de mik a tipikus problémák?

Insecure by default.
Az SNMP 1988-ban kezdte meg a pályafutását. Eredeti kiadása, az SNMPv1 kialakítása során a korabeli szellemiségnek megfelelően nulla, azaz totálisan zéró biztonsági megfontolást vettek figyelembe: minden cleartextben megy, ezért némi sniffelés után tetszőlegesen lehet állítgatni az eszközök lelkivilágát - ennek megfelelően ma már a v1 használata önmagában is biztonsági kockázatot jelent.

Az SNMPv2 1993-ban jelent meg, és számos biztonsági funkciót terveztek bele, például az MD5-ön alapuló authentikációt a korábbi clear-text helyett. Igenám, azonban az IETF-ben nem tudtak megegyezni arról, hogy pontosan mi is kerüljön bele a kötelezően implementálandó részbe, ezért a gyártók különbözőképp implementálták az SNMPv2-t: a betűhíven implementált SNMPv2 számos funkciót biztosít, ami a korábbiban nem volt benne, viszont biztonságilag semmivel sem jobb, mint a v1. Ennek következtében megjelent az SNMPv2c, és végül is ez terjedt el nagy gyártók termékeiben.

A fenti történet némi kavarodást okozott a tipikusan nem egy-két évre vásárolt hálózati eszközök piacán: sok mai hálózatban keverve találhatunk v1, v2, illetve v2c protokollokat támogató eszközöket. A teljesség kedvéért meg kell említenünk, hogy létezik v3 is, azonban ez nem teljes protokoll olyan értelemben, hogy leginkább biztonsági funkciókat definiál az eddigi v2(c)-hez, például már használható SHA1-es/AES-es hitelesítés is. Persze ezt külön be kell kapcsolni.

Community és Private stringek
Az SNMP részleteibe nem mennénk bele (az érdeklődők nyugodtan fussák át a wikipedia szócikkét), a továbbiak megértéséhez elég annyi, hogy az egyes eszközökről (network element) egy Management Information Base nevű faszerkezetben lehet információkat kérni. A biztosított faszerkezetet a gyártó eszközspecifikus leírása alapján lehet teljes mértékben bejárni, azonban hagyományosan vannak olyan információk, amiket a legtöbb eszköz ugyanoda tesz a fában.

Ahhoz, hogy használni tudjuk az SNMP-t egy eszközön, szükséges egy "jelszó": ebből mindjárt van kettő is, a community string és a private. Ez elméleti szinten nagyon szép, viszont a gyakorlatban sokszor használnak triviális stringeket (pl. "community", illetve "private"), illetve az adott menedzsmenteszköz használatát megkönnyítendő, kényelmi okokból ugyanazt a stringet használják mindenhová.

Praktikus támadás lehet a stringek megszerzésére a hálózat sniffelése, MiTM elkövetése a menedzsment interfész és az eszközök között. Ezek elég egyszerűek, viszont ha bonyolítani akarjuk a dolgot, lehet azt is csinálni, hogy CDP (Cisco Discovery Protocol, Cisco eszközök ezen keresztül is tudnak meg sok mindent egymásról) keretek injektálásával létrehozunk egy nem létező hálózati eszközt a menedzsment konzolon. Ha (a támadó szempontjából) megfelelően van bekonfigurálva a menedzsment konzol, akkor készségesen csatlakozni fog a hamis eszközünkhöz, elárulva a stringet. Megjegyezzük, hogy ha nagyon csavarni akarjuk a dolgot, akkor akár XSS-t is lehetne művelni a webes menedzsment interfész megfelelő verzióin...

Ha ismerjük valamelyik stringet, akkor egy MIB browserrel rácsatlakozva az eszközre, kényelmesen lehet nézegetni mindenféle beállításait. Teszteltünk egyszer olyan hálózatot, ahol a TCP-s portok szigorúan voltak szűrve, komoly küzdelem volt alávinni az nmap intenzitását az IPS-ének - viszont UDP161-en elérhető volt egy SNMP szerver, ami készségesen megmondta, mely portokon milyen szolgáltatás fut.

Eszköz feletti root hozzáférést SNMP-n keresztül nagyon nehézkes szerezni: a legtöbb típusban közvetlenül nem érhető el sem a rootjelszó, sem az enable jelszava: meg lehet mondani viszont, hogy honnét töltse le a konfigot TFTP-n például az eszközünk induláskor - ez pedig már majdnem ugyanolyan jó. Ha már jelszó, lehet tippelgetni is: a hydra például tud SNMP-t brute-force-olni.

SNMP keresése - tű a szénakazalban
A TCP jó, az UDP rossz portscannelési szempontból, ugyanis a TCP állapot alapján könnyű követni a vizsgált portok állapotát, viszont UDP-n ez nem működik: vagy timeoutol a próbálkozás, vagy visszakapunk egy ICMP hibaüzenetet - ha szerencsés napunk van. Emiatt UDP-t scannelni tipikusan egész éjszakás munka nagy hálózatokban, és ekkor sem árt némi finomhangolás az nmap időzítési beállításain.

Mi mindent lehet beállítani SNMP-n?
Mindent. Kicsit bővebben álljon itt néhány lehetőség, gondolatébresztőnek. Ahhoz, hogy a lentiek véghezvihetőek legyenek, nyilván szükséges az, hogy ismerjünk egy SNMP stringet. Konkrét parancsokat, eszközöket a lelkes, fiatal, ám nem kikezdhetetlen tudású IT-biztonsági szakemberpalánták kedvéért nem írunk.
  • VLAN-ok konfigurációjának kinyerése.
  • MAC címtábla kinyerése.
  • A switch melyik lábán milyen MAC cím lakik?
  • VLAN-ok átállítása.
  • DoS.
Hogy lehet mindezt kivédeni?
Nehezen. A legjobb megoldás az, ha kikapcsoljuk az SNMP-t azokon az eszközökön, amelyeken nincs szükség rá, azonban ez nagyon nagy hálózatokban iszonyatosan körülményessé teszi menedzsmentet. Másodszor érdemes nem kitalálható community stringeket használni. Érdemes továbbá különböző stringeket használni a különféle típusú SNMP-s műveletekhez, valamint az sem lehetetlen, hogy tűzfalallal az SNMP forgalmat csak a menedzsment konzol és a hálózati eszközök között engedélyezzük. Sok eszköz lehetőséget ad arra is, hogy csak bizonyos IP-kről lehessen elérni az SNMP-t (az UDP "fire-and-forget" tulajdonságai miatt ez lehet, hogy nem sokat ér - bár ezzel kapcsolatban nem végeztünk még vizsgálatokat).

2 megjegyzés:

  1. Ezek a rövidítések nagyon ütnek amúgy! ;)

    VálaszTörlés
  2. egy kis komment: imho a "private" is community string. amire gondolsz (vagy amivel kevered), az a "public" community string

    VálaszTörlés

Kommentek