Insanely News

Diffusione di informazioni obiettive e costruttive.

Insanely News

Categoria: Hacking

Session Hijacking

Session Hijacking – “Dalla saga Man-In-The-Middle”

Session Hijacking

[InsanelyNews] Nei primi due articoli di questa serie sugli attacchi man-in-the-middle abbiamo esaminato l’ avvelenamento della cache ARP e lo spoofing del DNS. Come abbiamo dimostrato con questi esempi, gli attacchi MITM sono incredibilmente efficaci e sempre più difficili da rilevare. Nella terza parte di questo articolo esamineremo il Session Hijacking, che non è diverso. Come per i due precedenti articoli, descriverò la teoria dietro il dirottamento di sessione, dimostrerò la tecnica nella pratica e discuterò i suggerimenti per la rilevazione e la prevenzione.

Il termine dirottamento di sessione viene usato frequentemente e comprende una varietà di attacchi diversi. In generale, qualsiasi attacco che implichi lo sfruttamento di una sessione tra dispositivi è il dirottamento di sessione. Quando facciamo riferimento a una sessione, stiamo parlando di una connessione tra dispositivi in ​​cui è presente lo stato. Cioè, c’è un dialogo stabilito in cui una connessione è stata formalmente impostata, la connessione viene mantenuta e un processo definito deve essere utilizzato per terminare la connessione. Quando parliamo di sessioni teoricamente è un po ‘confuso, quindi può essere utile pensare a una sessione in un senso più pratico.

 

In questo articolo parleremo di session hijacking tramite sottrazione di cookie, che prevede sessioni HTTP. Se si pensa ad alcuni dei siti Web comuni visitati che richiedono credenziali di accesso, questi sono ottimi esempi di connessioni orientate alla sessione. È necessario essere autenticati dal sito Web con il proprio nome utente e password per configurare formalmente la sessione, il sito Web mantiene una qualche forma di tracciamento della sessione per assicurarsi di essere ancora loggato e di accedere alle risorse (spesso fatto con un cookie), e quando la sessione sta terminando, le credenziali vengono cancellate e la sessione finisce. Questo è un esempio molto specifico di una sessione e anche se non sempre ce ne rendiamo conto, le sessioni si verificano costantemente e la maggior parte delle comunicazioni si basa su una qualche forma di sessione o attività basata sullo stato.


Figura 1: una sessione normale

Come abbiamo visto in precedenti attacchi, nulla che attraversi la rete è sicuro e i dati di sessione non sono diversi. Il principio alla base della maggior parte delle forme di dirottamento di sessione è che se è possibile intercettare alcune parti della creazione della sessione, è possibile utilizzare tali dati per impersonare una delle parti coinvolte nella comunicazione in modo da poter accedere alle informazioni sulla sessione. Nel caso del nostro esempio precedente, ciò significa che se dovessimo acquisire il cookie utilizzato per mantenere lo stato della sessione tra il browser e il sito Web al quale si sta effettuando l’accesso, potremmo presentare tale cookie al server Web e impersonare la connessione. . Se sembra troppo bello per essere vero dal punto di vista degli attaccanti, beh … lo è.


Figura 2: Session Hijacking

Ora che abbiamo un po ‘di teoria, esaminiamo un esempio pratico.

Rubare i cookie con Hamster e Ferret

Nel nostro scenario pratico eseguiremo un attacco di dirottamento di sessione intercettando la comunicazione di un utente che accede al suo account Gmail. Usando questa comunicazione intercettata, impersoneremo quell’utente e accediamo all’account dalla nostra macchina attaccante.

Per eseguire questo attacco useremo due strumenti direttamente dal negozio di animali, chiamato Hamster e Ferret. Entrambi gli strumenti possono essere scaricati da qui . Questi sono entrambi strumenti da riga di comando in modo che la cartella Hamster possa essere estratta in una posizione facile da raggiungere.

In alternativa, è possibile scaricare e utilizzare Kali Linux. Kali Linux è una distribuzione di live-CD Linux progettata specificamente per i test di hacking e penetration che viene fornito con una miriade di strumenti preinstallati e precompilati, con Hamster / Ferret come due.  Troverai Hamster nella cartella / pentest / sniffers / hamster. Gli esempi di schermate usati nel resto di questo tutorial sono presi da BT4.

Il primo passo in questa forma di dirottamento di sessione è quello di catturare il traffico dell’utente vittima mentre naviga su Facebook. Questo traffico può essere effettivamente catturato utilizzando qualsiasi applicazione di sniffing dei pacchetti come TCPDump o Wireshark, ma per acquisire i pacchetti giusti è necessario impiegare una tecnica come l’avvelenamento della cache ARP (discusso nel primo articolo di questa serie).


Figura 3: acquisizione del traffico dell’utente durante la navigazione in Gmail

Una volta catturato il traffico dell’utente della vittima che sta navigando su Gmail, dovrai salvare il file catturato nella directory Hamster. Per gli scopi di questo esempio, abbiamo chiamato il nostro file victim_gmail.pcap. Quando quel file è a posto, useremo Ferret per elaborare il file. Questo viene fatto sfogliando la cartella Hamster ed eseguendo il comando, ferret -r victim_gmail.pcap. Ferret elaborerà il file e creerà un file hamster.txt che potrebbe essere utilizzato da Hamster per l’effettivo dirottamento della sessione.


Figura 4: elaborazione del file di acquisizione con Ferret

Con i nostri dati HTTP intercettati e preparati per l’uso, possiamo usare Hamster per eseguire effettivamente l’attacco. Lo stesso Hamster funziona come proxy che fornisce un’interfaccia per la navigazione e l’uso di cookie di sessione rubati. Per avviare il proxy Hamster puoi semplicemente eseguire Hamster senza opzioni della riga di comando.


Figura 5: Avvio Hamster

Una volta eseguito, sarà necessario aprire il browser e configurare le sue impostazioni proxy in modo che corrispondano a quelle fornite dall’output di Hamster. Per impostazione predefinita, ciò significa che si configureranno le impostazioni proxy per utilizzare l’indirizzo di loopback locale 127.0.0.1 sulla porta 1234. È possibile accedere a queste impostazioni in Internet Explorer selezionando Strumenti, Opzioni Internet, Connessioni, Impostazioni LAN e inserendo una casella di controllo in Utilizza un server proxy per la tua casella LAN.


Figura 6: configurazione delle impostazioni proxy da utilizzare con Hamster

Ora che le impostazioni proxy sono state applicate, puoi accedere alla console di Hamster nel tuo browser sfogliando http: // hamster. Hamster utilizzerà il file creato da Ferret per produrre un elenco di indirizzi IP per i quali le informazioni sulla sessione sono state intercettate e visualizzare tali indirizzi IP nel riquadro destro del browser. Il nostro file che abbiamo creato contiene solo un singolo indirizzo IP della vittima, quindi se clicchiamo che il pannello di sinistra verrà popolato con le sessioni disponibili per il dirottamento.


Figura 7: La GUI di Hamster

Vediamo che facebook.com è presente nell’elenco e se clicchi su quel link sarai lieto di presentarti una nuova finestra che ti ha fatto accedere all’account Facebook delle vittime!


Figura 8:
 account Gmail con successo dirottato!

Difesa contro il dirottamento della sessione

Ci sono molte diverse forme di dirottamento delle sessioni, quindi le difese per esse possono variare. Proprio come gli altri attacchi MITM che abbiamo valutato, il dirottamento di sessione è difficile da individuare e anche più difficile da difendere perché è un attacco prevalentemente passivo. A meno che l’utente malintenzionato non esegua un tipo di azione ovvia quando accede alla sessione che viene dirottata, non si può mai sapere che erano lì. Ecco alcune cose che puoi fare per difendere meglio dal dirottamento di sessione:

  • Salva Online Banking per Home – La possibilità che qualcuno intercetti il ​​tuo traffico sulla tua rete domestica è molto inferiore rispetto alla tua rete di lavoro. Non è perché il tuo computer di casa è più sicuro (diciamocelo, è probabilmente meno sicuro), ma la semplice questione di fatto è che se hai solo uno o due computer a casa, il massimo devi preoccuparti in termini di session hijacking è se tuo figlio di 14 anni inizia a guardare video di hacking su YouTube. Su una rete aziendale non si sa cosa succede in fondo al corridoio o nella filiale a 200 miglia di distanza, quindi le potenziali fonti di attacco si moltiplicano. Uno dei maggiori obiettivi per il dirottamento di sessione è il banking online, ma questo principio si applica a qualsiasi cosa.
  • Be Cognizant – Gli aggressori intelligenti non lasceranno alcuna prova di essere stati in uno dei tuoi account sicuri, ma anche gli hacker più esperti commettono errori. Essere consapevoli quando si è connessi a servizi basati sulla sessione può aiutare a determinare se qualcun altro sta camminando nella tua ombra. Tieni d’occhio le cose che sembrano fuori posto e presta attenzione ai campi “Ultimo accesso” per assicurarti che tutto corrisponda.
  • Proteggi le tue macchine interne – Ancora una volta, attacchi come questi vengono eseguiti più comunemente all’interno della rete. Se i tuoi dispositivi di rete sono sicuri, c’è meno possibilità che questi host compromessi vengano utilizzati per lanciare un attacco di dirottamento di sessione.

Incartare

Abbiamo ora coperto tre tipi di attacco MITM molto letali che potrebbero avere conseguenze molto gravi se eseguiti con successo contro una vittima. L’utilizzo del dirottamento di sessione con intenzioni malintenzionate potrebbe accedere a servizi bancari online, e-mail o persino a un’applicazione intranet sensibile. Nel prossimo articolo di questa serie vedremo un altro attacco MITM letale, lo spoofing SSL.

dns-spoofing

DNS Spoofing – “Dalla saga Man-In-The-Middle”

[InsanelyNews] DNS SPOOFING

Nella prima parte di questa saga abbiamo esaminato la normale comunicazione ARP e come la cache ARP di un dispositivo può essere avvelenata al fine di reindirizzare il traffico di rete delle macchine attraverso un’altra macchina con possibile intento malevolo. Questo attacco apparentemente avanzato man-in-the-middle (MITM) noto come avvelenamento da cache ARP viene fatto facilmente con il software giusto. In questo articolo discuteremo di un tipo simile di attacco MITM chiamato DNS Spoofing. Se non hai letto l’articolo precedente sulla cache ARP, allora ti consiglio di farlo ora, poiché questo articolo si basa sulle tecniche apprese in quell’articolo.

DNS Spoofing

Lo spoofing del DNS è una tecnica MITM utilizzata per fornire false informazioni DNS a un host in modo che quando tentano di navigare, ad esempio www.bankofamerica.com all’indirizzo IP XXX.XX.XX.XX, vengano effettivamente inviati a un falso www .bankofamerica.com residente all’indirizzo IP YYY.YY.YY.YY che un utente malintenzionato ha creato per rubare credenziali di banking online e informazioni sull’account da utenti ignari. Questo in realtà è fatto abbastanza facilmente e qui vedremo come funziona, come è fatto e come difenderci.

Comunicazione DNS normale

Il protocollo Domain Naming System (DNS) come definito nella RFC 1034/1035 è quello che alcuni considerano uno dei più importanti protocolli in uso su Internet. In poche parole, ogni volta che digiti un indirizzo web come http://www.google.com nel tuo browser, viene effettuata una richiesta DNS a un server DNS per scoprire a quale indirizzo IP viene assegnato il nome. Questo perché i router e i dispositivi che interconnettono Internet non comprendono google.com, ma comprendono solo indirizzi come 74.125.95.103.

Un server DNS stesso funziona memorizzando un database di voci (chiamate record di risorse) di indirizzi IP a nomi di nomi DNS, comunicando tali record di risorse ai client e comunicando tali record di risorse ad altri server DNS. L’architettura dei server DNS in tutte le aziende e in Internet è qualcosa che può essere un po ‘complicato. In effetti, ci sono interi libri dedicati all’architettura DNS. Non copriremo aspetti architettonici o anche tutti i diversi tipi di traffico DNS (è possibile rivedere le varie RFC relative al DNS qui ), ma esamineremo una transazione DNS di base, illustrata nella Figura 1.


Figura 1: una query e una risposta DNS

Funzioni DNS in un formato di tipo query / risposta.

Un client che desidera risolvere un nome DNS in un indirizzo IP invia una query a un server DNS e il server invia le informazioni richieste nella sua risposta.

Dal punto di vista dei clienti, gli unici due pacchetti visualizzati sono questa query e risposta.


Figura 2: query DNS e pacchetti di risposta

Questo scenario diventa un po ‘più complesso quando si considera la ricorsione DNS. A causa della natura gerarchica della struttura DNS di Internet, i server DNS hanno bisogno della capacità di comunicare tra loro al fine di individuare le risposte per le domande inviate dai clienti. Dopo tutto, potrebbe essere corretto aspettarsi che il nostro server DNS interno conosca il nome della mappatura degli indirizzi IP del nostro server intranet locale, ma non possiamo aspettarci che conosca l’indirizzo IP correlato a Google o Dell. È qui che entra in gioco la ricorsione. La ricorsione è quando un server DNS interroga un altro server DNS per conto di un cliente che ha fatto una richiesta. Fondamentalmente, questo trasforma un server DNS in un client stesso, visto in Figura 3.


Figura 3: query e risposta DNS mediante ricorsione

Spoofing DNS

C’è sicuramente più di un metodo disponibile per eseguire lo spoofing del DNS. Useremo una tecnica chiamata spoofing ID DNS.

Ogni query DNS che viene inviata in rete contiene un numero di identificazione generato in modo univoco che ha lo scopo di identificare query e risposte e legarle insieme. Ciò significa che se il nostro computer in attacco può intercettare una query DNS inviata da un dispositivo di destinazione, tutto ciò che dobbiamo fare è creare un pacchetto falso che contenga quel numero identificativo affinché quel pacchetto possa essere accettato da quel target.

Completeremo questo processo facendo due passaggi con un unico strumento. In primo luogo, ARP cache avvelenerà il dispositivo di destinazione per reindirizzare il traffico attraverso il nostro host in modo che possiamo intercettare la richiesta DNS, e quindi invieremo effettivamente il pacchetto contraffatto. L’obiettivo di questo scenario è far sì che gli utenti della rete di destinazione visitino il nostro sito Web dannoso anziché il sito Web a cui stanno tentando di accedere. Una rappresentazione di questo attacco è vista in Figura 4.


Figura 4: DNS Spoofing Attack Utilizzo del metodo di spoofing ID DNS

Esistono alcuni strumenti diversi che possono essere utilizzati per eseguire lo spoofing del DNS. Useremo Ettercap, che ha sia versioni Windows che Linux. Puoi scaricare Ettercap da qui .

Se stai installando Ettercap su una macchina Windows noterai che ha una GUI che funziona perfettamente, ma per questo esempio useremo l’interfaccia della riga di comando.

Prima di eseguire Ettercap, è necessario un po ‘di configurazione.

Ettercap è uno sniffer di pacchetti che utilizza vari plug-in per eseguire i vari attacchi che può eseguire.

Il plug-in dns_spoof è ciò che farà l’attacco in questo esempio, quindi dobbiamo modificare il file di configurazione associato a quel plug-in. Su un sistema Windows, questo file può trovarsi in C: \ Programmi (x86) \ EttercapNG \ share \ etter.dns e in /usr/share/ettercap/etter.dns. Questo file è abbastanza semplice e contiene i record DNS che desideri spoofare. Per i nostri scopi, vorremmo che qualsiasi utente che tentasse di andare su yahoo.com venisse indirizzato a un host sulla rete locale, quindi aggiungeremo la voce evidenziata nella Figura 5.


Figura 5: aggiunta di un record DNS falsificato a etter.dns

Queste voci in pratica indicano al plug-in dns_spoof che quando visualizza una query DNS per yahoo.com o www.yahoo.com (per un record di risorse di tipo A) deve fornire l’indirizzo IP 172.16.16.100 in risposta. In uno scenario realistico, il dispositivo 172.16.16.100 eseguiva una qualche forma di software per server Web che presentasse all’utente il sito Web falso.

Una volta che il file è stato configurato e salvato, siamo liberi di eseguire la stringa di comando che avvierà l’attacco. La stringa di comando utilizza le seguenti opzioni:

  • -T – Specifica l’uso dell’interfaccia basata su testo
  • -q – Esegue i comandi in modalità silenziosa in modo che i pacchetti catturati non vengano trasmessi allo schermo
  • -P dns_spoof – Specifica l’uso del plug-in dns_spoof
  • -M arp – Inizia un attacco di avvelenamento da Arp MITM per intercettare i pacchetti tra gli host
  • // // – Specifica l’intera rete come target dell’attacco

La stringa di comando finale per i nostri scopi sarebbe:

Ettercap.exe -T -q -P dns_spoof -M arp // //

L’esecuzione del comando inizierebbe il doppio attacco a fasi, avvelenando prima la cache ARP dei dispositivi sulla rete e quindi trasmettendo le risposte false alle query DNS.


Figura 6: Ettercap ascolta attivamente le query DNS

Una volta avviato, chiunque tenti di accedere a www.yahoo.com viene reindirizzato al nostro sito dannoso.

Difendersi dallo spoofing DNS

Lo spoofing del DNS è difficile da difendere perché gli attacchi sono per lo più passivi. In genere, non si saprà mai che il tuo DNS è stato falsificato fino a quando non è successo. Quello che ottieni è una pagina web diversa da quella che ti aspetti. In attacchi molto mirati è molto probabile che tu non possa mai sapere che sei stato ingannato a inserire le tue credenziali in un sito falso finché non ricevi una chiamata dalla tua banca chiedendoti perché hai appena acquistato una nuova barca al largo della Grecia. Detto questo, ci sono ancora alcune cose che possono essere fatte per difendersi da questi tipi di attacchi:

  • Proteggi le tue macchine interne: attacchi come questi sono eseguiti più comunemente all’interno della rete. Se i dispositivi di rete sono sicuri, c’è meno possibilità che questi host compromessi vengano utilizzati per lanciare un attacco di spoofing.
  • Non fare affidamento su DNS per sistemi sicuri: su sistemi altamente sensibili e sicuri che in genere non si naviga su Internet è spesso una buona pratica non utilizzare DNS. Se si dispone di un software che si basa su nomi host per funzionare, questi possono essere specificati manualmente nel file host dispositivi.
  • Usa IDS: un sistema di rilevamento delle intrusioni, quando posizionato e distribuito correttamente, in genere può rilevare la maggior parte delle forme di avvelenamento della cache ARP e di spoofing del DNS.
  • Usa DNSSEC: DNSSEC è una nuova alternativa al DNS che utilizza i record DNS con firma digitale per garantire la validità di una risposta alla query. DNSSEC non è ancora in ampia distribuzione ma è stato ampiamente accettato come “il futuro del DNS”. Questo è così tanto che il DOD degli Stati Uniti ha incaricato tutti i domini MIL e GOV di iniziare a utilizzare DNSSEC entro il prossimo anno. Puoi leggere ulteriori informazioni su DNSSEC qui .

Incartare

DNS Spoofing è una forma molto letale di un attacco MITM quando abbinato al giusto livello di abilità e intenzioni malevole. Usando questa tecnica possiamo utilizzare tecniche di phishing per rubare credenzialmente le credenziali, installare malware con un exploit drive-by o addirittura causare una condizione di negazione del servizio.

arp

ARP – ADDRESS RESOLUTION PROTOCOL “Dalla saga Man-In-The-Middle”

 ARP – ADDRESS RESOLUTION PROTOCOL

[InsanelyNews] ARP – Come professionista IT, a volte mi soffermo a pensare alle comunicazioni di rete in termini di indirizzamento IP.

Come tutti sappiamo, tuttavia, gli indirizzi IP sono solo un meccanismo per identificare un nodo su una rete.

I nodi di rete possono anche essere identificati dal loro indirizzo di controllo di accesso ai media o dall’indirizzo MAC.

Un indirizzo MAC è un indirizzo a livello hardware che identifica in modo univoco un’interfaccia di rete sulla rete. Esistono anche indirizzi MAC virtuali, ma questa discussione si concentrerà sugli indirizzi fisici.

Come funziona ARP

Quando un dispositivo deve inviare dati a un altro dispositivo su una rete IP, deve essere in grado di determinare l’indirizzo MAC del dispositivo ricevente. 

È qui che entra in gioco l’Address Resolution Protocol, o ARP. Il lavoro di ARP è determinare l’indirizzo MAC che corrisponde a un dato indirizzo IP.

Naturalmente, le comunicazioni di rete sarebbero molto lente se fosse necessario eseguire una traduzione ARP per ogni singolo pacchetto inviato attraverso una rete.

Per migliorare le prestazioni, i dispositivi utilizzano una cache ARP.

La cache ARP è semplicemente un elenco di indirizzi IP noti ai mapping degli indirizzi MAC.

Pertanto, se un dispositivo deve determinare l’indirizzo MAC che corrisponde a un particolare indirizzo IP,

esamina la cache ARP per determinare se l’indirizzo MAC del destinatario è già noto.

MAC mancante

Se l’indirizzo MAC del destinatario non viene visualizzato nella cache ARP,

il dispositivo che deve trasmettere i dati a un determinato destinatario invia una richiesta ARP attraverso la sottorete locale.

La richiesta ARP è essenzialmente una richiesta per il destinatario di rispondere con il suo indirizzo MAC.

In che modo il mittente è in grado di inviare una richiesta ARP al destinatario quando non conosce l’indirizzo MAC del destinatario?

Il motivo per cui il mittente ha bisogno dell’indirizzo MAC del destinatario, in primo luogo, è che il mittente possa inviare dati al destinatario.

Se l’indirizzo MAC del destinatario è sconosciuto, il mittente non può trasmettere i dati direttamente al destinatario.

In pratica, il mittente trasmette un messaggio broadcast attraverso la sottorete locale.

I messaggi broadcast sono diversi dalle normali comunicazioni IP perché vengono inviati a tutti gli host nella subnet.

Pertanto, una richiesta ARP comporta la trasmissione dell’indirizzo IP del destinatario e chiede agli host della subnet di

verificare se stanno utilizzando l’indirizzo IP contenuto nella richiesta ARP.

L’host il cui indirizzo IP è referenziato all’interno della richiesta ARP risponde con una risposta ARP, contenente il suo indirizzo MAC. 

Dopo aver ricevuto questa risposta, il dispositivo che ha avviato la richiesta aggiorna la sua cache ARP e può iniziare a comunicare con il destinatario.

In superficie, il funzionamento di ARP può sembrare completamente teorico. Tuttavia, il sistema operativo Windows espone molte di queste funzionalità tramite un comando che viene chiamato ARP in modo appropriato. In effetti, il comando ARP è stato una parte del sistema operativo Windows per decenni.

 Il Comando ARP

Il comando ARP consente di visualizzare e modificare la cache ARP di un dispositivo.

Per mostrarti come funziona, considera che prima di iniziare a scrivere questo articolo,

ho trascorso un po ‘di tempo a comunicare con un server sulla mia rete con un indirizzo IP di 147.100.100.151. Poiché il mio PC ha recentemente comunicato con questo server, le informazioni del server dovrebbero essere nella cache ARP del mio PC. Pertanto, se volessi cercare l’indirizzo MAC del server, potrei farlo inserendo il seguente comando:

ARP -A 147.100.100.151

Puoi vedere l’output del comando nella figura seguente:

arp

In questo caso, ho specificato l’indirizzo IP di un particolare server, ma è possibile esaminare la cache ARP nella sua interezza. Per fare ciò, basta inserire il comando ARP -A senza specificare un indirizzo IP. Fare così farà sì che l’intera cache venga visualizzata.

 

OK,  ti starai chiedendo se ci sia un uso pratico e reale per questa utility…

Che ci crediate o no, c’è qualcosa per cui il comando ARP funziona davvero bene.

Supponiamo per un momento che si verifichi un conflitto di indirizzi IP sulla rete, a causa del fatto che a due host viene assegnato lo stesso indirizzo IP.

Supponiamo anche che tu riesca a rintracciare l’host incriminato e assegnargli un nuovo indirizzo IP, ma che un dispositivo Windows sulla tua rete stia riscontrando problemi nella comunicazione con uno di questi host anche se il conflitto dell’indirizzo IP è stato risolto.

Il problema è probabilmente correlato alla scrittura di una voce non valida nella cache ARP come risultato del conflitto dell’indirizzo IP.

È quindi possibile utilizzare il comando ARP per verificare e correggere il problema.

Un attimo fa, ti ho mostrato come usare il comando ARP per guardare un particolare indirizzo IP all’interno della cache ARP.

Le informazioni visualizzate per questo indirizzo nella cattura della schermata precedente erano corrette, poiché nessun conflitto di indirizzi IP si è verificato sulla mia rete.

Per ragioni di discussione, tuttavia, facciamo finta che le informazioni restituite dalla ricerca cache non siano corrette. In tale situazione, potrei usare l’opzione -D per rimuovere la voce dalla cache ARP. Il comando effettivo sarebbe:

ARP -D 147.100.100.151

Se volevo creare una nuova voce della cache ARP con l’indirizzo MAC corretto, potrei usare l’opzione -S per creare una voce statica. Le voci statiche sono voci aggiunte manualmente alla cache ARP. Vale la pena notare, tuttavia, che le voci statiche vengono rimosse al riavvio del sistema.

Devo essere onesto con te in quanto non ho mai dovuto creare una voce di tabella ARP statica.

Ricordare che le voci della tabella ARP vengono create automaticamente come risultato del tentativo di comunicare con un host.

Pertanto, se si rimuove una voce in conflitto dalla cache ARP, una nuova voce prenderà il suo posto la prossima volta che si tenterà di comunicare con l’host.

Supponendo che il conflitto dell’indirizzo IP sia stato risolto, la nuova voce della cache ARP dovrebbe contenere informazioni corrette.

Pulisci dopo il conflitto

Il comando ARP probabilmente non è una di quelle cose che ti sorprenderesti ad usare quotidianamente. Anche così, questo comando può fornire informazioni sul modo in cui funziona il processo di risoluzione degli indirizzi. È utile per ripulire dopo un conflitto di indirizzi IP, ma potrebbe essere ancora più utile come strumento di formazione educativa per chi è nuovo al networking.

hacking malware

Malware: i russi hanno creato un sistema per colpire le reti elettriche

(InsanelyNews) L’arma, progettata da esperti informatici russi e da hacker che collaborano con il Cremlino, è stata denominata “CrashOverride”, ed è un malware che potrebbe avere effetti devastanti nei sistemi elettrici civili e militari delle prossime guerre in cui sono impegnate le forze di sicurezza russa.

Secondo le analisi di Dragos, riprese anche dal Washington Post, il malware sarebbe già stato testato a dicembre del 2015 sul fronte ucraino. Lo scorso inverno, il malware avrebbe penetrato i sistemi di sicurezza del gestore dell’energia elettrica ucraino Ukrenergo, provocando un blackout che ha lasciato per ore al buio molte zone di Kiev.

Il malware creato dalle forze russe non sarebbe il primo appositamente progettato per attaccare le reti elettriche di uno Stato.

Già negli anni precedenti, Stuxnet, malware generato da Israele e Stati Uniti, fu utilizzato per colpire il progetto nucleare iraniano attaccando i sistemi delle centrifughe per l’arricchimento dell’uranio nelle centrali di Teheran. Se però Stuxnet era un malware malevolo teso a sabotare un particolare tipo di sistemi all’interno delle centrali elettriche, tendenzialmente idoneo a danneggiare silenziosamente un particolare obiettivo, CrashOverride avrebbe al contrario l’obiettivo di colpire manifestamente le reti elettriche dei gestori privati. In sostanza, sarebbe stato creato con l’apposito scopo di sabotare il sistema per colpire i servizi essenziali di una città o direttamente provocare blackout che colpirebbero la popolazione.

Il malware ha destato preoccupazione soprattutto negli Stati Uniti, perché il malware avrebbe la particolarità di colpire esclusivamente i sistemi di controllo di apparati industriali e di gestione delle reti elettriche di uno Stato.

E perché basterebbero soltanto piccole modifiche al virus per renderlo letale anche per le reti elettriche degli Stati Uniti. Un pericolo che la difesa nazionale americana ha già da tempo posto in cima alla lista degli aggiornamenti al sistema di sicurezza degli Stati Uniti e in cui sembra che gli avversari sullo scenario internazionale, cioè Cina e Russia, siano molto più avanti.

Chi ci sia dietro la creazione di questo nuovo malware è ancora, evidentemente, un mistero.

La società Dragos, citata dal Washinton Post, ha ritenuto che dietro questa nuova arma informatica vi possa essere lo stesso gruppo che tra il 2015 e il 2016 attaccò le reti ucraine con il virus BlackEnergy. In quelle settimane, il malware lasciò mezzo milione di ucraini senza corrente elettrica per molte ore, e fu un segnale notevolmente sottovalutato da parte delle intelligence occidentali. In quell’occasione, BlackEnergy colpì in particolare la rete elettrica dell’oblast di Ivano-Frankivskz, nella zona occidentale del Paese.

L’intelligence ucraina additò immediatamente i russi come artefici dell’attacco,

ma la notizia fu liquidata in breve come un attacco facilmente neutralizzabile. In realtà, non era così semplice come avevano creduto. L’attacco alle reti elettriche, con un particolare sistema d’infezioni che usavano per tramite Microsoft Office, doveva essere il segnale di una crescita di know-how da parte di chiunque fosse stato l’autore dell’attacco, perché a detta dei maggiori esperti, l’essersi inseriti all’interno delle reti dell’energia elettrica dimostrava un’abilità degna dei migliori pirati informatici a livello mondiale.

 

Oggi, la notizia della creazione di CrashOverride mette di nuovo in allarme tutti i Paesi occidentali, che si sentono particolarmente vulnerabili in tema di attacchi alla cyber-sicurezza.

Negli ultimi mesi, i Paesi colpiti dal malware Wannacry hanno già ampiamente dimostrato l’impreparazione dei loro sistemi di sicurezza di fronte a questo tipo di minaccia. In quel caso, la Russia fu uno dei Paesi maggiormente colpiti dall’attacco hacker, nonostante i media si siano concentrati sul Regno Unito e sulla Spagna. Segno che la cosiddetta cyber-war è una guerra internazionale che miete vittime in ogni Paese e che non ha, attualmente, vincitori né vinti. Il problema, tuttavia, è che in questi mesi gli attacchi di pirateria informatica sembrano concentrarsi non più su obiettivi militari o di strutture statali in particolare, ma su servizi essenziali che vanno a ledere la vita dei cittadini. Una forma di assedio 2.0 in cui Russia, Stati Uniti, Cina e loro alleati stanno conducendo passi da gigante. per rendersi pronti in caso di conflitto.

Fonte

kali

Kali Linux, setup your own web application pentesting lab

Without any preface, let me get straight to the point. In this tutorial, we will be installing Damn Vulnerable Web Application (DVWA) on a Ubuntu virtual machine. Our attacker machine would be Kali Linux, which is also installed as a virtual machine (or virtual box). The host can be any OS, and doesn’t matter since we won’t be using it at all. An alternate configuration is when your host is either Kali or Ubuntu, in which case you need only one VM, to install their the other OS. Alternatively, you could just use a single Kali machine both as attacker as well as victim (running the vulnerable application). However, that makes things less realistic.

Contents

  1. Pre-requisites
  2. Installing DVWA

Disclaimer : No cool stuff in this tutorial, just straightforward installation.

Pre-requisites

You need to have Kali Linux (rolling release) and Ubuntu (I’m using 16.04) up and running. If you aren’t familiar with virtual machines and stuff, then take a break of a few days, get familiar with them, install and run a few Linux (any flavour) VMs, drink some coffee, etc. Once you’re comfortable with virtual machines (and have Kali & Ubuntu up nd running), proceed onward.

You also need some minimal knowledge of linux, networking, and web applications. As an exercise, you could try getting some free web host (a pathetic one will suffice, since you are only doing this for learning and won’t need anyone to use your website), and deploy a wordpress site. Tinker around the website, install themes and stuff to get a feel for it. Then, go one step further and deploy a wordpress instance on your linux virtual machine. This time, don’t use the wordpress UI to do things, but instead try and figure out stuff manually. Install themes, modules, etc. on your own by placing them in the correct directory. Just tinker away, in short, till you have some level of familiarity with web applications.

Now, you are familiar with web apps, virtual machines, and linux (not networking though). The task above were pretty simple but for now you can move ahead with the tutorial with the given amount of expertise. Also, the pre-reqs listed above are for the entire web pentesting series, and most probably you’ll be able to follow this tutorial without completing some of them, since this is the first and very basic installation tutorial.

Important: Make sure you use the same version of stuff as me. This will avoid scenarios where our systems behave differently (in which case you’ll have to use google-fu to figure our how to deal with unexpected stuff happening).

Ubuntu Version – 16.04.1 LTS
XAMPP Version – 7.1.1 (you’ll install this later in the tut)

Installing DVWA

This is a fairly simple procedure.  Below are screenshots with explanation. At the end of the tutorial, I have listed commands that you need to type to get all this done (you can simply copy paste the commands). The unnecessary steps are not present in list of commands (in screenshots they are there to enhance your understanding oh what’s going on).

Overview-

  1. First we will download DVWA.
  2. Then we read it’s doc and find out what to do.
  3. After reading doc, we realize we need to install XAMPP, we do that.
  4. After installing XAMPP, we test if it works by starting it and opening localhost on our machine.
  5. Once we’re sure that XAMPP works, we will proceed and copy DVWA files to htdocs folder of XAMPP.
  6. Now we check if localhost/DVWA-master leads us to the vulnerable app. If it does, then we did everything right.
Open Damn Vulnerable Web App website in your browser. Click on download. You’ll get an archive, extract it.
Navigate to the extracted archive. Get a lay of the land. You’ll find that there is documentation available in docs folder.
Here is the relevant section of the documentation. We need to install XAMPP. You can get it to work
with any other equivalent software bundle, but for ease, let’s stick to the recommended way.
Proceed to download the XAMPP bundle. I went with the latest version (going with latest version
poses a slight problem for us, while DVWA is flawed, our PHP version is perfectly patched. For now, let’s
ignore this. If this cause hinderance at a later stage, then we’ll deal with it)
Navigate to downloads directory and run the installer for XAMPP
Realise that you forgot to run the installer as root! (kudos if you ran as root and didn’t make the
same mistake as me)
Run installer as root
It’s a simple installer. You’d know what to do.
Wait for it to finish.
Start the XAMPP server (note that the directory is lampp in linux systems)
Check if your server is running by typing 127.0.0.1 or localhost on your browser. XAMPP is now up
and running properly. Let’s run our vulnerable app on XAMPP now.
As suggested by the documentation, we simply move our folder into the htdocs directory.
Open the localhost/DVWA-master URL and you’ll see that everything works as expected. Our initial
setup is successfully done.

There is still further configuration to be done, but I don’t want to extend the tutorial any further. After the next section, there is link to part 2 of this series.

Commands

For below commands to work, ensure the following-

  • xampp-linux-x64-VERSION-installer.run – this file downloaded and is located in Downloads folder
  • DWVA-master directory is located in home folder (the archive to be downloaded and extracted to obtain this directory).
  • Replace VERSION with the version you have downloaded (7.1.1.0 in my case)
Here are the commands-
  1. cd ~/Downloads
  2. chmod a+x xampp-linux-x64-VERSION-installer.run
  3. cd ~
  4. sudo ./xampp-linux-x64-VERSION-installer.run
  5. sudo mv ~/DWVA-master/ /opt/lampp/htdocs/

Part 2 : fixing the problems and finishing the configuration. Here’s the link –

Configuring DVWA

Extras

  1. Read about localhost (what does this URL signify – 127.0.0.1)
  2. Commands used – ls, cd, mv, sudo. Use man pages to find out what these mean (eg. type man mv into the terminal)

Powered by WordPress & Theme by Anders Norén

English English Italian Italian