Archivio

Posts Tagged ‘security’

WINDOWS UNIVERSAL PRIVILEGE ESCALATION EXPLOIT

Privilege Escalation universale per tutte le versioni di Windows. Watch the Video !!!

CISCO D.A.I. Module – Sopravvivere al Layer 2

31 ottobre 2009 2 commenti

Ciao a tutti cari lettori, immagino che ormai vi stavate chiedendo che fine avevo fatto e come mai non scrivevo più nulla sul mio blog; ma tra lavoro, corsi di aggiornamento e master  il tempo per bloggare e condividere in rete un pò delle proprie esperienze risulta veramente poco ormai.

Oggi però ho deciso di trovare il tempo (ad un’orario pazzo tra l’altro) per parlare del CISCO D.A.I. Module.

Dieci giorni fa mi è capitato, durante una consulenza per un’azienda della mia zona (eseguita nel dopo lavoro), di controllare come mai ultimamente ci fosse la loro rete lenta, e talmente tanto sovvracaricata da rendere lunghissima qualsiasi comunicazione host to host all’interno della LAN. Fortunatamente la mia fida amica sonda IDS, configurata su una VDI predisposta temporaneamente come segugio sul server aziendale, ha rilevato un eccesso di traffico arp e molti tentativi di arp poisoning da parte di alcuni indirizzi IP che dovrebbero solitamente essere liberi .

Controllando i log, mi sono accorto che gli IP sorgenti cambiavano senza un rigor di logica preciso e senza essere registrati nel database DHCP del server aziendale; segno quindi che qualcuno configurava a random la NIC del proprio PC in static mode e lanciava questi tentativi di avvelenamento ARP.

A questo punto per professionalità( visto che mi pagano per risolvere i problemi) e buon senso civico ho deciso di risolvere la situazione definitivamente; anche se ho deciso di risolverla a modo mio, in quanto ora questa era diventata una sfida personale tra me e lo script kiddie che stava giocando con ettercap. Poi ovviamente ho notificato al responsabile di piano questa bravata affinchè prendesse provvedimenti disciplinari verso costui.

A questo punto entra in gioco come una manna dal cielo il CISCO D.A.I. Module; ovvero il CISCO DYNAMIC ARP INSPECTION MODULE.

Questo modulo, implementato e disponibile nel firmware di molti switch CISCO Catalyst, permette di ispezionare il traffico ARP di determinate VLAN e di verificare che le arp request siano conformi. Faccio un’esempio….se sulla porta 1 l’indirizzo di MAC 00-50-56-C0-00-01 corrisponde all’IP 172.16.10.134, e tale host invia o riceve 200 arp request  D.A.I. entra in  funzione loggando poi l’accaduto.

Voi adesso vi starete chiedendo…. VERY GOOD !!! Ma come si implementa questa cosa? Che scrivevo questo post a fare sennò? Nella rete di questa azienda c’era un server DHCP dedicato, che distribuiva quindi gli indirizzamenti e le configurazioni di networking generali(DNS, WPAD, GW ecc ecc) rendendo così la cosa ancora più semplice e meno macchinosa del previsto.

Mi sono collegato sullo switch via telnet, e entrato nella console ho cominciato la mia missione come da policies seguenti:

switch-p01(config)# configure terminal

switch-p01(config)# ip dhcp snooping

switch-p01(config)# ip dhcp snooping vlan 1-32 (se volete potete modificare il range di VLAN in base alla vostra rete)

switch-p01(config)# ip dhcp snooping information option

switch-p01(config)# interface 12

switch-p01(config)# ip dhcp snooping trust

switch-p01(config)# exit

switch-p01(config)# ip dhcp snooping verify mac-address

switch-p01(config)# ip arp inspection vlan 1-32 (se volete potete modificare il range di VLAN in base alla vostra rete)

switch-p01(config)# ip arp inspection limit 15

switch-p01(config)# errdisable recovery cause arp-inspection interval 300

switch-p01(config)# ip arp inspection validate dst-mac src-mac ip

switch-p01(config)# end

switch-p01(config)# copy running-config startup-config

Cosa succede ora al nostro caro script kiddie che si stava divertendo con ettercap? Ecco qua un piccolo log della console dello switch salvato proprio per voi durante il suo tentativo massiccio che rallentava tutto.

switch-p01# Oct 20 16:42:51.873: %SW_DAI-4-PACKET_RATE_EXCEEDED: 16 packets received in 252 milliseconds on Fa0/3.
switch-p01# Oct 20 16:42:51.873: %PM-4-ERR_DISABLE: arp-inspection error detected on Fa0/3, putting Fa0/3 in err-disable state
switch-p01# Oct 20 16:42:52.877: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
switch-p01# Oct 20 16:42:53.881: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down

Avendo tentato di Poisonare tutta la LAN con ettercap, per protezione la sua interfaccia è stata messa in stato di shutdown per 300 secondi; cioè per cinque minuti esatti. Sono stato cattivo vero? Lo so, però mi sembrava un tempo utile per farlo desistere dal ritentare ancora con questi giochetti 😉

Molti di voi si staranno chiedendo….” Cosa succede se invece di poisonare tutta la LAN lo script kiddie ha già un elenco di host da poisonare oppure imposta un rate limit inferiore a quello massimo che hai impostato sopra??? ” Domanda corretta e lecita da parte vostra. Come avrete già intuito dalle righe di configurazione precedentemente descritte non ho di certo sottovalutato lo script kiddie, cercando di tener conto di tutte le varie modalità alternative con cui egli poteva eseguire l’attacco. Questo consapevole che il nostro amico ci avrebbe riprovato ancora, magari tentando di bypassare tale protezione o policy. Per sua sfortuna però, secondo le righe di sintassi che ho inserito prima, viene fatto pure un check-up sul MAC e l’indirizzo IP di sorgente/destinazione(la ciliegina sulla torta) sia a livello di ARP che di DHCP entries passanti sulle VLAN untrusted. In questo modo viene pure costruito un database in base agli indirizzi IP richiesti & poi rilasciati dal server DHCP della LAN. Insomma il suo attacco non ha più successo.

Infatti ecco a voi cosa succede sulla console dello switch a conferma di quanto detto

switch-p01# Oct 20 16:47:44.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/000c.2957.6b39/192.168.69.112/16:47:44 UTC Tue Oct 20 2009])
switch-p01# Oct 20 16:47:44.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/0016.cb97.3e33/192.168.69.31/16:47:44 UTC Tue Oct 20 2009])
switch-p01# Oct 20 16:47:45.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/000c.2957.6b39/192.168.69.31/16:47.44 UTC Tue Oct 20 2009])

Insomma come avrete visto dal secondo log, anche se le arp request fasulle sono in uscita lo switch le rileva e droppa tali pacchetti “manipolati” facendo passare solo le arp request/response valide originate dal client aziendale e non da ettercap.

Bene…. Anche questa volta abbiamo risolto il problema rendendo pure inoffensivo lo script kiddie e i suoi giochetti ARP. Spero che tale tutorial scritto in modo narrativo informale vi abbia soddisfatto, o comunque abbia incuriosito i colleghi in merito a tali features contro questi tipi di attacchi MITM che spesso sono un grattacapo per tanti network admin. Nel caso abbiate domande o dubbi io sono qui a disposizione; tempo permettendo.

Ciauz e alla prossima

MultiLayered Network Security

Voglio annunciarvi che è uscito il secondo whitepaper del progetto NetSecurity & Security Systems. In questo nuovo paper si parlerà dell’approccio logico / teorico alle tecniche di Multilayered Network Security; per il resto non voglio anticiparvi niente e preferisco che scoprite tutti i dettagli leggendo attentamente il PDF.

Il paper è scaricabile dall’apposita sezione apposita del blog che trovate qui

Finora coloro che l’hanno letto hanno dato un feedback positivo; spero che anche tutti voi visitatori siate dello stesso parere o che possiate aiutarmi a migliorare la qualità del suddetto argomento eventualmente.Ovviamente ogni consiglio, dubbio e domanda sono leciti e ben accetti. Sono qui a vostra disposizione come sempre 😉

Colgo l’occasione per augurarvi un buon week end

Ciauz

Windows TCP/IP Stack Hardening

Mi sembra doveroso ribadire, dopo aver spesso dato risposta in giro sui vari forum, che un metodo per proteggere il proprio pc sia proprio l’irrobustimento del sistema stesso e quindi anche delle varie aree che lo caratterizzano e che sono esposte a pericoli e bugs
Proprio in quest’ottica ci viene in aiuto l’hardening, ovvero l’insieme di tutte quelle procedure di irrobustimento di un sistema operativo,  che comprende anche l’hardening dello stack TCP/IP  che spesso viene lasciato configurato di default esponendo comunque la nostra macchina a pericoli e insidie.

Lo stack TCP/IP è il responsabile del trasporto di pacchetti di dati da una sorgente (identificata da un indirizzo IP) ad una destinazione (identificata da un altro indirizzo IP). Se necessario, questo livello del protocollo si occupa di spezzettare i pacchetti troppo grandi in pacchetti di dimensione adatta alla rete da utilizzare.

Sostanzialmente tutte le applicazioni che fanno uso di Internet e tutte le applicazioni tradizionali che si riferiscono a LAN utilizzano IP, benché teoricamente siano possibili altre soluzioni.
Il protocollo IP è per impostazione predefinita privo di protezione. Tuttavia con l’uso e la configurazione di vari parametri nel registro di Windows è possibile aumentare il livello di protezione della rete da attacchi di tipo Denial of Service, inclusi attacchi SYS, ICMP e SNMP. Le chiavi del Registro di sistema possono essere configurate per:

– Attivare la protezione dagli attacchi di tipo SYN quando viene rilevato un attacco
– Impostare valori limite utilizzati per determinare ciò che costituisce un attacco.

Alcune chiavi e valori cui si fa riferimento in questa procedura potrebbero non essere disponibili per impostazione predefinita, in questi casi è necessario creare chiavi, valori e dati valore.

Gli interventi che ci apprestiamo a compiere potrebbero essere, se non eseguiti nel modo corretto, dannosi, per cui è importantissimo, prima di compiere qualunque azione sul registro, premunirsi di farne una copia completa.

Iniziamo : Entriamo in regedit e posizioniamoci alla seguente chiave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters

Valore: EnableDeadGWDetect – Valore consigliato: 0 [Valori validi: 0 (disabilitato), 1 (abilitato)]

1 : se si imposta EnableDeadGWDetect su 1, il protocollo TCP può rilevare i gateway inattivi. Quando il rilevamento dei gateway inattivi è abilitato, TCP può chiedere al protocollo IP (Internet Protocol) di passare a un gateway di backup se per alcune connessioni ci sono dei problemi. I gateway di backup possono essere definiti nella sezione Avanzate della finestra di dialogo di configurazione del protocollo TCP/IP tramite lo strumento Rete nel Pannello di controllo.

0 : è consigliabile impostare il valore di EnableDeadGWDetect su 0, in caso contrario un eventuale attacco potrebbe obbligare il server a cambiare gateway imponendogli di passare a un gateway indesiderato.

Valore: SynAttackProtect – Valore consigliato: 1 [Valori validi: 0 – 2]
Questo valore del Registro di sistema fa sì che il protocollo TCP regoli la ritrasmissione di SYN-ACKS. Quando lo si configura, le risposte di connessione scadono più rapidamente durante un attacco SYN (un tipo di attacco “Denial of Service”).

I seguenti parametri possono essere utilizzati con questo valore del Registro di sistema:
– 0 (valore predefinito): nessuna protezione dagli attacchi SYN
– 1: impostare SynAttackProtect su 1 per una migliore protezione dagli attacchi SYN.

Questo parametro fa sì che il protocollo TCP regoli la ritrasmissione di SYN-ACKS. Se si imposta SynAttackProtect su 1, il timeout delle risposte di connessione è più veloce qualora il sistema rilevi un attacco SYN in corso. Per determinare se è in corso un attacco, Windows utilizza i valori seguenti:
– TcpMaxPortsExhausted
– TCPMaxHalfOpen
– TCPMaxHalfOpenRetried

Nome valore: TcpMaxPortsExhausted – Valore consigliato: 0 [Valori validi: 0 – 65535]
specifica il limite di richieste di connessione TCP che deve essere superato prima di attivare la protezione dagli attacchi SYN.

Nome valore: TcpMaxHalfOpen – Valore consigliato: 64 [Valori validi: 100 – 65535]
quando SynAttackProtect è attivato, questo valore specifica il limite di connessioni TCP nello stato SYN_RCVD. Al superamento del valore SynAttackProtect viene attivata la protezione dagli attacchi di tipo SYN.

Nome valore: TcpMaxHalfOpenRetried – Valore consigliato: 400 [Valori validi: 80 – 65535]
quando SynAttackProtect è attivato, questo valore specifica il limite di connessioni TCP nello stato SYN_RCVD per cui è stata inviata almeno una ritrasmissione. Al superamento del valore SynAttackProtect viene attivata la protezione dagli attacchi di tipo SYN.

Nome valore: TcpMaxConnectResponseRetransmissions
– Valore consigliato: 2 [Valori validi: 0 – 255]
controlla il numero di ritrasmissioni di un SYN-ACK prima di annullare il tentativo di risposta a una richiesta SYN.

Nome valore: TcpMaxDataRetransmissions – Valore consigliato: 3 [Valori validi: 0 – 65535]
specifica il numero di volte in cui TCP ritrasmetterà un singolo segmento di dati (non di connessione) prima di annullare la connessione

Nome valore: EnablePMTUDiscovery – Valore consigliato: 1 [Valori validi: 0, 1]
se questo valore è impostato su 1 (valore predefinito), il protocollo TCP deve individuare l’unità massima di trasmissione o il pacchetto con la dimensione maggiore nel percorso di un host remoto. Un pirata informatico può forzare la frammentazione del pacchetto e quindi sovraccaricare lo stack. Specificando il valore 0, verrà imposta la MTU di 576 byte per le connessioni da host non inclusi nella subnet locale.

Nome valore: KeepAliveTime – Valore consigliato: 300000 [Valori validi: 80 – 4294967295]
specifica la frequenza con cui il protocollo TCP tenta di verificare se una connessione inattiva è ancora intatta inviando un pacchetto keep-alive

Nome valore: NoNameReleaseOnDemand – Valore consigliato: 1 [Valori validi: 0, 1]
specifica che il computer non deve rivelare il nome NetBIOS quando riceve una richiesta di rilascio dei nomi.

Nome Valore: DisableIPSourceRouting – Valore consigliato: 1 [Valori validi: 0, 1, 2]
disattiva l’origine routing IP, che consente a un mittente di determinare la route che un datagramma deve seguire attraverso la rete.

Nome Valore: EnableFragmentChecking – Valore consigliato: 1 [Valori validi: 0 (disabilitato), 1 (abilitato)]
impedisce allo stack IP di accettare pacchetti frammentati

Nome Valore: EnableMulticastForwarding – Valore consigliato: 0 [Intervallo valido: 0 (false), 1 (true)]
il servizio di routing si basa su questo parametro per determinare se i pacchetti multicst IP debbano essere inoltrati o meno. Questo parametro viene creato dal servizio Routing e accesso remoto.

Nome Valore: IPEnableRouter – Valore consigliato: 0 [Intervallo valido: 0 (false), 1 (true)]
l’impostazione di questo parametro su 1 (true) consente al sistema di inoltrare i pacchetti IP alle reti a cui è connesso.

Nome Valore: EnableAddrMaskReply – Valore consigliato: 0 [Intervallo valido: 0 (false), 1 (true)]
questo parametro stabilisce se il computer deve rispondere a una richiesta di maschera indirizzo ICMP.

Ora rechiamoci alla chiave:

HKLM\System\CurrentControlSet\Services\AFD\Parameters

Nome Valore: EnableICMPRedirect – Valore consigliato: 0 [Valori validi: 0, 1]
se si modifica questo valore su 0, viene impedita la creazione di route host dispendiose in seguito alla ricezione di un pacchetto di reindirizzamento ICMP.

Nome Valore: EnableDynamicBacklog – Valore consigliato: 1 [Valori validi: 0 (disabilitato), 1 (abilitato)]
specifica che la funzionalità AFD.SYS dovrà gestire un numero elevato di connessioni SYN_RCVD in modo efficace.

Nome valore: MinimumDynamicBacklog – Valore consigliato: 0 [Valori validi: 0 – 4294967295]
specifica il numero minimo di connessioni disponibili consentito per un endpoint in ascolto. Se il numero di connessioni disponibili risulta inferiore a questo valore, viene inserito un thread nella coda per creare altre connessioni disponibili.

Nome valore: MaximumDynamicBacklog – Valore consigliato: 20 [Valori validi: 0 – 4294967295]
specifica il numero totale delle connessioni disponibili e di quelle in stato SYN_RCVD.

Nome valore: DynamicBacklogGrowthDelta – Valore consigliato: 0 [Valori validi: 0 – 4294967295]
quando sono necessarie altre connessioni, specifica il numero di connessioni disponibili che devono essere create.

Articolo formatted by:  PIANETAPC.IT

IL FIREWALLING

20 luglio 2008 2 commenti

Allora, visto che Cyber ha postato la sua guida alle VPN sul forum di RBT – 4, e visto che come gli ho fatto notare ha tralasciato alcuni particolari importanti, voglio postarvi la mia Tesi d’Esame che ho dato in merito al Firewalling e alla sicurezza di Rete.

Ovviamente questo pezzo riguarda solo alla parte teorica, perchè la parte pratica che ho dimostrato durante il colloquio è un lavoro a parte che ovviamente non posso allegare per motivi fisici 😉

Spero vi piaccia, visto che dalla commissione è stata valutata 35 sia dal punto di vista teorico che pratico dopo un’ora d’esame.

Spero che possa chiarire molti dubbi a tante persone che ancora oggi non hanno ben chiaro come funzioni il firewalling in un ottica di rete…..argomento tanto discusso ma mai chiaro a tantissime persone.

LEGGI ARTICOLO

Per eventuali critiche o chiarimenti io sono qui 😉

Ciauz