R:R: PenTestL2

>Non colgo bene quest'ultimo punto. A che punto puoi usare un ping per
capire in che VLAN ti trovi? Hai dei link al riguardo?

Hai perfettamente ragione, se ci  fosse stato il trio Medusa nel ML il
coro ci sarebbe stato tutto.
In effetti, con un ping è impossibile effettuare alcun tipo di discovery
ID vlan tag. Chiedo perdono. Come attenuante ho un massiccio uso di
antibiotici. Speriamo che sia sempre valido il detto sbagliando si
impara.
Cmq, il punto 2.1.3 resta valido come concetto, nel senso che uno switch
che ospita più “workgroup eterogenei” devono per forza di cose essere
separati da ACL.

Invece in merito alla tua richiesta di approfondire come può essere
violata la sicurezza tramite la gestione dei frame L2 taggati nei trunk.
Bhe, cercando un po’ ho notato che di effettivo c’è un solo argomento
basato su scenari di misconfiguration o condizioni volontariamente
realizzate per effettuare dei test, per dimostrare come rendere
vulnerabile il core switch  e di conseguenza l’utilizzo di soluzioni
firewall L2 integrati, tipo NetScreen. A onor della cronaca però non ho
trovato nessun documento di test effettuati direttamente sui NetScreen
eccetto uno fornito da loro, dove cmq informano che la soluzione e
valida solamente sulla base che non ci siano misconfiguration.

A proposito che ti ha detto il Francese???

Diciamo che uno scenario possibile che mi viene in mente e perciò tutto
da verificare, è quello di recuperare l’arp table del Core switch,
sfruttando delle leggerezze che si verificano molto spesso nei SNM di
certe dimensioni, anche con l’SNMP v2 configurato.
In pratica la community SNMP v2, correggetemi se sbaglio, transita in
modo criptato ma è salvata in chiaro nel snmpd.conf, a questo punto
possiamo aspettarci di trovare una community qualsiasi, non
obbligatoriamente PUBLIC, che magari corrisponde a tutti i server della
farm(vedi 2.1.3) sotto monitoring e magari anche all’infrastruttura di
rete…BINGO…
Inoltre, ci vorrebbe la coincidenza di un altra leggerezza fondamentale,
vale a dire che nel core switch non ci sia un ACL che limiti le query
snmp ad un unico manager o a un ristretto gruppo…
Dopo aver adeguatamente ringraziato il responsabile del SNM e del
NETWORK per scarsa fantasia e pigrizia, sempre in teoria, tramite un MIB
browser, navigare l’albero alla ricerca dell’arp table da scaricare e da
leggere in tranquillità, con la dovuta privacy :)
(Sulla possibilità che questa esista mi prendo il beneficio
d’inventario, perché non sono proprio sicuro, ma in passato ricordo che
sicuramente a livello di tabelle di routing c’era tutto e mi sembra di
ricordare anche a livello di arp:).
Cmq una navigatina o il download completo(snmpwalk <host>) per post
analisi è sempre utile, altro che information leakage, con queste
piccole coincidenze ti leggi praticamente tutto e non devi preoccuparti
di fare grandi pulizie di tracce almeno che non ci siano debug attivi
sull’apparato, ma in quel caso se non è già seduto potremmo fornirgli il
colpo di grazia.
Inoltre, il massimo della goduria sarebbe, sempre in teoria, quella di
tentare di verificare qualche SET(write), se la community coincidesse
con quella RW.

Ottenute in qualche modo tutte queste belle info, da una qualsiasi porta
non trunk si potrebbe forgiare del traffico taggato per tentare degli
“hop” indisturbati…e poi chi più ne ha più ne metta la mia fantasia si è
esaurita.

Sull’argomento security vlan vi consiglio di cercare info sul supporto
del Virtual Private LAN Services (VPLS). Provate a cercare questo file:
draft-knight-l2vpn-lpe-ad-00.txt

>A me sembra piu' buon senso che "ulteriori check" ;-)

Il buon senso se viene trascritto è ancora più efficace, poi se
condiviso è ancora meglio.
Ciaos
_CaT_  

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List