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

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

Adobe, grave la falla di Acrobat

Roma – La scorsa settimana Adobe ha avvisato i suoi utenti della presenza, in tutte le versioni ancora supportate di Adobe Reader e Adobe Acrobat, di una seria vulnerabilità già sfruttata dai creatori di malware.

L’azienda ha comunicato in questo post che rilascerà una patch domani, 13 ottobre. Nel frattempo, Adobe raccomanda agli utenti di disattivare il supporto JavaScript nei propri browser: gli exploit attualmente in circolazione utilizzano il noto linguaggio di scripting per trarre vantaggio dal bug di Reader e Acrobat. Adobe ha però ammesso che i cracker potrebbero sviluppare exploit che non si basano su JavaScript: per tale ragione viene suggerito di tenere il proprio antivirus costantemente aggiornato.

Stando all’advisory di Adobe, gli utenti di Windows Vista con la funzione di sicurezza DEP (Data Execution Prevention) attivata dovrebbero dormire sonni tranquilli.

Trend Micro ha battezzato il primo exploit per la nuova vulnerabilità di Reader e Acrobat Troj_Pidief.Uo, spiegando che questo arriva in un file PDF contenente due malware: lo script Js_Agent.Dt, capace di scaricare e installare nel sistema altri malware, e Bkdr_Protux.Bd, che crea una backdoor e tenta di connettersi ad uno specifico indirizzo IP.

Confermando quanto detto da Adobe, Troj_Pidief.Uo può infettare tutte le versioni ancora supportate di Windows tranne Vista e Windows Server 2008. Nel succitato post di Trend Micro vengono forniti altri dettagli sul codice maligno e su come questo funziona.

Agli utenti di Adobe Reader e Adobe Acrobat non resta che attendere domani, quando l’azienda ha promesso il rilascio di versioni aggiornate delle sue due applicazioni per Windows, Mac OS X e Unix. Vale la pena ricordare come domani sarà lo stesso giorno in cui Microsoft ha programmato il rilascio di un numero record di patch.

In occasione della recente conferenza Adobe MAX 2009, la mamma del formato PDF ha ammesso che negli ultimi tempi gli attacchi diretti verso Reader, Acrobat e Flash Player sono aumentati considerevolmente: l’azienda ha tuttavia rassicurato il pubblico affermando che “un eccellente team di esperti di sicurezza sta lavorando sul problema, inoltre abbiamo un team di pronto intervento capace di attivarsi immediatamente non appena sorge una difficoltà”.

FONTE : PUNTO – INFORMATICO.IT

Microsoft, una valanga di patch per il prossimo mese

Tredici bollettini di sicurezza, di cui otto critici e cinque importanti, che risolvono complessivamente 34 vulnerabilità. Sarà questo il “bilancio di guerra” degli aggiornamenti di sicurezza di Microsoft previsti per martedì prossimo.

I software interessati dalle prossime patch di sicurezza comprendono Windows, Internet Explorer, Office, Silverlight, Forefront, Developer Tools e SQL Server. In molti casi, dopo l’applicazione dei fix occorrerà riavviare il sistema operativo.

Tra le vulnerabilità che verranno corrette dai prossimi bollettini vi saranno quella relativa al protocollo di rete SMB2, di cui proprio di recente è emerso un nuovo exploit, e quella relativa al servizio FTP di Internet Information Services (IIS), che Microsoft non aveva fatto in tempo a sistemare lo scorso mese. Entrambe le falle sono zero-day, in altre parole sono già state sfruttate in certi attacchi.

La falla che interessa l’implementazione di SMB2 è stata divulgata circa un mese fa e, secondo Microsoft, è contenuta in Windows Vista, Server 2008 e le versioni di Windows 7 precedenti alla RTM. Sono immuni al problema Windows Server 2008 R2, XP e 2000. Anticipando il rilascio della patch ufficiale, tre settimane fa Microsoft ha fornito una soluzione temporanea Fix it che disattiva il supporto a SMB2 in Windows.

FONTE:  PUNTO-INFORMATICO.IT

Fuga di Password da Hotmail

Roma – “Durante lo scorso fine settimana Microsoft ha appreso che migliaia di credenziali d’accesso relative agli utenti di Windows Live Hotmail sono state rivelate su un sito terzo a causa di un probabile attacco di phishing”. Così un recente post sul blog ufficiale di Windows Live che ha immediatamente suggerito ai suoi iscritti di aggiornare al più presto i dati personali di account, cambiando in particolare la password. “Abbiamo determinato – ha continuato il post – che non si tratta di una fuga di dati interna”.

A contattare per primo il Microsoft Security Response Center era stato Neowin, accortosi di corpose liste di account presenti nel forum di Pastebin, utilizzato in genere da sviluppatori per condividere snippet di codice. Più nel dettaglio, era stato un utente anonimo a mettere in condivisione oltre 10mila credenziali d’accesso, in particolare di account @hotmail.com, @msn.com e @live.com.

La fuga incontrollata dei dati, relativi nella specie a nomi utente che iniziano per A e per B, era stata confermata in seguito da BBC News che aveva contattato Graham Cluley, consulente di Sophos, azienda nel settore sicurezza. Cluley aveva specificato come le liste pubblicate potessero far parte di gruppi più vasti di account ormai compromessi, suggerendo di modificare le proprie password anche perché il 40 per cento delle persone utilizza sempre la stessa parola per ogni sito a cui si registra.

Redmond ha quindi confermato l’intera vicenda, nonostante le liste incriminate siano ormai sparite dal forum. Si è trattato di phishing e Microsoft ha dichiarato sul blog il suo impegno a restituire il controllo delle credenziali d’accesso ai suoi utenti: “Stiamo adottando tutte le misure per bloccare l’accesso a tutti gli account che sono stati rivelati, per aiutare quegli utenti a recuperare le loro credenziali”.

Fonte: PUNTO-INFORMATICO

Un bug in Windows coinvolge Internet Explorer, Safari e Chrome

Sono passate nove settimane è stata pubblicata la dimostrazione di come sfruttare un bug in CrptoApi – una libreria usata da Internet Explorer, Chrome e Safari per la gestione dei certificati Ssl – e ancora non c’è in vista una patch.

“Ci sono migliaia di prodotti che girano sotto Windows che, proprio in questo momento, sono ancora vulnerabili a questo attacco Ssl” ha spiegato Moxie Malinkspike, uno degli hacker che hanno scovato la vulnerabilità e messo pubblicamente in guardia Microsoft durante la Black Hat Security Conference.

In pratica il bug può essere usato per far credere al browser che si sta usando un certificato Ssl per accedere al legittimo sito cui è collegato, mentre in realtà ci si connette a un sito fraudolento.

Per ora Microsoft ha fatto soltanto sapere che sta “investigando su una possibile vulnerabilità” e che “prenderà le misure necessarie per proteggere i clienti” quando avrà concluso.

Finché Microsoft non avrà rilasciato una patch è consigliabile usare un browser alternativo come Firefox: il team di Mozilla ha risolto la vulnerabilità già pochi giorni dopo la sua rivelazione.

Da sottolineare che i browser Opera e Lynx non sono soggetti a tale bug in quanto non utilizzano Crypto-Api per i certificati SSL; mentre Mozilla ha fixato l’anomalia subito.

Fonte: ZeusNews

Mozilla forgia uno scudo antiXSS

Talvolta l’uso di un firewall e di un buon antivirus non è sufficiente a proteggere i PC dalle minacce che provengono da Internet, soprattutto quando queste minacce prendono di mira le debolezze presenti sui siti web: in questi casi le protezioni più efficaci sono quelle offerte dal browser.

È per tale ragione che Mozilla sta lavorando all’implementazione, in Firefox, della specifica Content Security Policy (CSP), un framework studiato per proteggere i siti – e di conseguenza anche gli utenti finali – dai famigerati attacchi Cross-Site Scripting (XSS). Stilata lo scorso anno, la specifica CSP è appena entrata a far parte di alcune build preliminari di Firefox, e la sua efficacia può essere messa alla prova con i test pubblicati in questa pagina. CSP consente a webmaster e web designer di definire delle policy che stabiliscano in che modo un sito esterno può interagire con una certa pagina web: ad esempio, gli amministratori di un sito possono restringere il tipo di script eseguiti sulle loro pagine e le fonti da cui questi provengono; nel caso più drastico, possono anche scegliere di disattivare del tutto l’esecuzione di codice JavaScript. Tali accorgimenti, secondo Mozilla, possono contribuire a ridurre in modo determinante il numero di attacchi XSS e Cross Site Request Forgery (CSRF) con cui i cracker tentano ogni giorno di sottrarre informazioni sensibili agli utenti o inoculare malware nei loro PC. Brandon Sterne, security program manager di Mozilla, ha spiegato in questo post che il suo team ha trascorso gli ultimi mesi a tradurre la specifica CSP in codice.

Tale codice è ora stato integrato in alcune versioni sperimentali di Firefox 3.7, così che sviluppatori, esperti di sicurezza e amministratori di server possano cominciare a testarlo e fornire il proprio feedback. Sterne avverte però che questa prima implementazione di CSP è ancora incompleta, e manca ad esempio del supporto agli HTTP redirect. “Siamo entusiasti di aver ricevuto così tanti feedback positivi dagli altri vendor di browser, dagli amministratori di siti web e dai ricercatori di sicurezza, e siamo davvero orgogliosi del design scaturito da questo confronto”, ha commentato Sterne. L’esperto di sicurezza di Mozilla non ha fornito alcuna stima sui tempi necessari a completare l’implementazione di CSP. L’ipotesi più plausibile è che tale tecnologia entrerà a far parte delle versioni pubbliche di Firefox entro il rilascio della futura release 4.0, il cui debutto è previsto tra circa un anno.

Fonte: PUNTO-INFORMATICO