Una di queste è la capacità non solo di rilevare se la porta Tcp (o Udp) è aperta o chiusa, ma anche di capire quale tipo di server è in ascolto sulla porta analizzata. Cosa molto utile, perchè è molto importante in fase di pianificazione di un attacco sapere se il servizio da attaccare è un server Apache o invece, per esempio Microsoft IIS

Di seguito mostro un esempio di come è possibile scoprire il web server di uno dei siti di informazione più noto e frequentato d’Italia, ovvero www.corriere.it. Ovviamente, con la stessa procedura è possibile scoprire il web server di qualsiasi host collegato a Internet.

Il comando da eseguire per ottenere questo risultato è la seguente:

root@diablo:~# nmap www.corriere.it -p 80 -sT -sV -P0 -vv

Il parametro -p 80 è abbastanza chiaro, dice a Nmap di effettuare una scansione sulla porta 80; l’opzione -sT specifica una scansione di tipo Tcp connect; con -P0 diciamo a Nmap di non verificare se il sito è o meno online (in alcuni casi gli host non rispondono ai ping, impedendo così di proseguire con la scansione).

Il parametro “chiave” di questa linea di comando è però -sV: con questo comando ordiniamo allo scanner di controllare non solo se la porta Tcp 80 è aperta, ma di indagare anche il tipo di servizio in ascolto.

Questo è  il risultato:

Nmap scan report for www.corriere.it (194.20.158.241)
Host is up (0.11s latency).
Hostname www.corriere.it resolves to 2 IPs. Only scanned 194.20.158.241
rDNS record for 194.20.158.241: corriere.it
Scanned at 2012-01-25 17:54:22 MSK for 6s
 
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd
 
Nmap done: 1 IP address (1 host up) scanned in 6.62 seconds

Questo report ci mostra che il sito è attivo, che la porta Tcp 80 è aperta e che il server web è Apache. Alcune informazioni di base, apparentemente poche, ma che già ci possono dare alcune indicazioni utili.

Segnala presso:

Oggi effettuare una attacco utilizzando strumenti come Metasploit ed Armitage è scandalosamente semplice. Negli ultimi anni i tools potentissimi a disposizione pubblicamente e gratuitamente hanno reso il penetration test un’attività da script kiddie.

Naturalmente un ethical hacker vero non si limita a lanciare programmi e cliccare a casaccio come una scimmia; un penetration test che abbia valore non può essere portato avanti senza la capacità dell’operatore di osservare e dedurre.

La prima fase, forse quella più critica di un attacco è la ricognizione, effettuata tramite missioni di information gathering. Dicevo che priobabilmente è la più delicata in quanto è da questa fase di intelligence che si svilupperà tutta la strategia d’attacco. Cadere in una trappola di disinformazione in questa fase potrebbe significare compromettere il buon esito dell’operazione e il fallimento dell’obiettivo.

Osservare

La capacità di osservare e dedurre non implica necessariamente il ricorso a sofisticati strumenti. Basta una traccia, anche minima, per ricostruire o tentare di ricostruire la mappa del tesoro di un sistema target.

Faccio un esempio pratico. Interrogando la porta 80 di un host, con nmap (con l’opzione -sV), oppure ancor più semplicemente con netcat  posso ottenere gli header http del server. Ipotizziamo che questi header rivelino l’identità del server:

Apache 2.2.9

Cosa mi dice questo? Due cose: la prima ovvia ed evidente è il tipo e la versione del software, e già questo potrebbe condurmi a trovare vulnerabilità di questa specifica versione. Ma non basta.
Mi dice anche che si tratta di una versione vecchia, uscita nel Giugno del 2008; questo potrebbe suggerirmi che chi si occupa della gestione del sistema non ha una strategia di aggiornamenti, oppure tende a trascurare il problema. E qui casca l’asino.

Dedurre

Queste deduzioni ci portano ad altre intuizioni: probabilmente non solo Apache è stato installato e mai più aggiornato, ma anche gli altri servizi e le altre applicazioni. Ed è probabile che il sistema sia stato installato nel giro di pochi giorni e mai più aggiornato.

In questo caso saremmo in grado di stabilire le versioni degli altri software potenzialmente installati. Potrebbe trattarsi di un server LAMP (qunidi su piattaforma Linux,Apache,MySql e Php).

Seguendo il ragionamento di cui sopra, possiamo immaginare che la versione Php installata sia la 5.2.6 (disponibile dal 2 Maggio 2008, pochi giorni prima l’uscita di Apache 2.2.9).

Potrebbe essere stato installato un software per gestire i database di MySql da remoto, come phpMyAdmin; in questo casola versione compatibile con l’orizzonte temporale di Apache e Php dovrebbe essere la 2.11.7.0.

Cercando nel database di exploit-db, trovo un exploit che potrebbe adattarsi allo scenario illustrato, ovvero un exploit che permette di effettuare code-inection nelle versioni di phpMyAdmin inferiori alla 2.11.9.5.

Conclusioni

Quello che ho esposto è solo un caso ipotetico, ma mostra come sia possibile arrivare lontano anche senza sofisticati strumenti di fingerprinting, e senza usare tools che sono molto comodi, ma che fanno anche tanto “rumore”.

Come? Mi chiedete cosa fare una volta acquisite tutte queste informazioni? Ovvio, si attacca con Metasploit ed Armitage: elementare Watson!

Segnala presso:

Quello del pirata informatico sta diventando un mestiere molto pericoloso. Se fino a ieri il pericolo più grande (seppur remoto) per un hacker era quello di trovarsi la polizia in casa all’alba, da oggi il pericolo sarà quello di trovarsi faccia a faccia con una squadra Kidon. In particolar modo se l’obiettivo dell’attacco fosse un sistema israeliano.

Infatti, secondo quanto afferma il vice ministro degli esteri israeliano  Danny Ayalon: “Un cyber-attacco è una violazione della sovranità paragonabile a un’operazione terroristica, e deve essere trattato come tale”.

E’ stato il libro “Vendetta”,  da cui è stato tratto il film di Steven Spielberg “Munich”, che ha fatto conoscere al grande pubblico nel lontanto 1984 le squadre Kidon del Mossad, team di agenti speciali incaricati di trovare ed eliminare ovunque e in qualsiasi modo i terroristi autori del massacro di Monaco alle Olimpiadi del 1972.

I primi a fare le spese di questo nuovo orientamento delle autorità Stato dello ebraico potrebbero essere gli hacker sauditi del gruppo “Group-Xp”, e in particolar modo il loro membro noto come “0xOmar”, sedicente autore di un furto di carte di credito da un sito israeliano.

Sebbene il danno finanziario dell’attacco non sarebbe ingente (si parla di alcune miglia di carte di credito trafugate), ad indispettire le autorità israeliane sarebbero state le dichiarazioni di “Hamas”, il gruppo palestinese islamista, che avrebbe definito l’azione degli hacker sauditi: “una nuova forma di resistenza” e di Guerra Santa.

Si tratta di un’esagerazione o si apre una nuova pericolosa fase nella storia della pirateria informatica? Dichiarazioni estemporanee dettate dal nervosismo causato dal momento particolarmente delicato che sta attraversando Israele, oppure  veramente i famigerati agenti Mossad inizieranno a dar la caccia agli hacker nemici del tormentato Stato ebraico?

Staremo a vedere. Sicuramente il messaggio è chiaro: è pericoloso scherzare col fuoco, e con i misteriosi agenti del Kidon.

Segnala presso:

ExploitHub è il primo marketplace per armi digitali, dove per armi digitali si intendono gli strumenti (exploit) che permettono agli ethical-hacker di portare a compimento con successo un penetration-test. In particolar modo su ExploitHub, a differenza di altre iniziative simili, sono disponibili exploit non zero-day.

A chi serve, a chi si rivolge questo servizio? Si rivolge ai penetration-tester, che hanno la necessità di arricchire il proprio arsenale digitale per svolgere al meglio il proprio lavoro; ma anche ai ricercatori che trovano vulnerabilità e realizzano i codici in grado di sfruttarle. ExploitHub semplicemente mette in contatto queste due figure complementari del mondo della sicurezza informatica.

Benché il servizio si rivolga agli ethical hacker, nessuno garantisce sull’uso che verrà fatto da questi script da parte degli acquirenti.

Al momento su ExploitHub è possibile trovare exploit scritti appositamente per Metasploit, anche se è prevista per il futuro la disponibilità di exploit stand-alone. E’ possibile trovare script in grado di attaccare piattaforme Windows e Linux, web-servers e database, sia lato client che server-side.

Quanto costa un exploit? Spulciando nel sito ne ho trovati da $100 fino a $1500, più o meno questo dovrebbe essere il range di riferimento.

Se sei un ricercatore, se hai trovato delle vulnerabilità e sei in grado di scrivere exploit che funzionino anche nel mondo reale (fuori dal laboratori), prova a dargli un’occhiata, potrebbe essere una buona opportunità per arrotondare lo stipendio.

Segnala presso:

La raccolta informazioni è di vitale importanza per ogni attacco che abbia la minima pretesa di aver successo; è in questa fase che l’hacker capisce quali sistemi, quali servizi, quali applicazioni sono installate sull’obiettivo da colpire.

Una tecnica di information gathering molto utilizzata è il fingerprinting, ovvero prendere le impronte digitali al sistema, identificarlo. Il fingerprinting può essere effettuato per scoprire un sistema operativo (OS fingerprinting), un servizio web, addirittura è possibile effettuarlo contro un dispositivo Bluetooth. Naturalmente non può mancare il fingerprinting delle applicazioni web.

In questo post vi presento 3 strumenti in grado di rivelare quale CMS sta utilizzando un sito, così che si possa scegliere la giusta strategia (e le giuste armi), per colpirlo:

1. WhatWeb
http://www.morningstarsecurity.com/research/whatweb
Uno script realizzato in Ruby, in grado di riconoscere numerose tecnologie web, quali CMS, piattaforme di blogging, strumenti di analisi e statistica (per esempio Google Analytics), librerie JavaScript, web server. La presenza di oltre 900 plugins probabilmente fa di questo strumento il principe dei web fingerprinter.

2. Wapplyzer
https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/
Caratteristiche molto simili a WhatWeb, solo che in questo caso si tratta di un add-on per Firefox. Anche Wapplyzer è in grado di riconoscere CMS, web server, librerie JavaScript, il tutto comodamente a portata di add-on bar.

3. BlindElephant
http://blindelephant.sourceforge.net/
L’approccio di BlindElephant è leggermente diverso, ma i risultati sono simili agli strumenti precedenti. BlindElephant (che per la cronaca è scritto in Python) tenta di scoprire il numero di versione di web application note (CMS, blog…) confrontando file statici contro hash precalcolati.

Già che ci sono vi suggerisco anche un particolare tipo di fingerprinter, specializzato in WordPress: Plecost. Questo tool tenta di scoprire la versione di WordPress, ma anche dei vari plugin installati, alla ricerca di una vulnerabilità da sfruttare.

Per approfondire l’argomento vi suggerisco la lettura di Web Applications Finger Printing: Methods/Techniques and Prevention, un interessante documento che ha ispirato questo post.

Segnala presso:

Ma se i clienti hanno il diritto di essere dei somari (anzi, forse addirittura il dovere, quasi un attributo antropologico), è incredibile che ancora oggi ci siano developers che non conoscono affatto i principi di programmazione sicura, non conoscono se non in modo superficiale (o per sentito dire) le vulnerabilità più comuni e gli effetti devastanti che esse generano.

Il risultato è che ancora oggi gli attacchi più clamorosi vengono portati a causa di un parametro passato alla query SQL senza essere stato prima bonificato, o di un dato sensibile memorizzato in chiaro, magari in un campo “nascosto” di una pagina html!

Il Mitre, in collaborazione con Sans Institute, ha pubblicato la lista dei 25 errori più comuni e pericolosi che commettono i programmatori, errori che aprono le porte agli attacchi più clamorosi, riportati ormai ampiamente dalla stampa non specializzata e pubblicati nelle prime pagine e nei notiziari più importanti.

Di questa lista ho estrapolato gli 8 errori più comuni commessi dagli sviluppatori nell’ambito dello sviluppo web, presentadoli con alcune note descrittive:

1. SQL-Injection: probabilmente la vulnerabilità più pericolosa degli ultimi anni (e del momento), causa pricipale dei clamorosi hacking degli ultimi tempi. Si tratta della possibilità del pirata di introdurre codice SQL per sovvertire la logica dell’accesso ai dati del database con risultati devastanti.

2. Command Injection: altro problema legato all’insufficiente validazione dell’input utente, che permette al pirata di introdurre comandi che saranno eseguiti direttamente dal sistema operativo.

3. Buffer Overflow: in questo caso ad essere prese alla leggera sono le dimensioni dell’input; se il pirata riesce a sfruttare un buffer-overflow può (fornendo un payload appositamente creato) iniettare codice macchina nel computer colpito, costringedolo a eseguire le istruzioni da lui inserite. Per approfondimenti rimando all’articolo sul buffer overflow che scrissi alcuni anni fa.

4. Cross-site Scripting: questa volta la validazione dell’input porta all’inserimento da parte del pirata di codice (per esempio Javascript) che verrà eseguito nel browser dell’utente al momento della visualizzazione della pagina web, azione che potrebbe per esempio finalizzarsi con il furto di un cookie di autenticazione, cosa che permetterebbe al pirata di accedere ad un servizio web (come una webmail per esempio) senza conoscere la password della vittima.

5. Mancanza di autenticazione: gli ingressi principali di un’azienda o di un edificio pubblico sono presidiati da agenti, da dispositivi biometrici o tornelli; altri accessi secondari invece vengono lasciati sguarniti (“chi vuoi che ci passi qui?”). In una web application spesso i programmatori adottano le corrette misure di autenticazione sulle pagine di front-end, ma dimenticano di adottarle su altri canali, cosa assai gradita ai pirati.

6. Mancanza di autorizzazione: non basta autenticare un utente, bisogna anche assicurarsi che abbia le necessarie autorizzazioni per compiere particolari azioni. Il fatto che abbia effettuato il login correttamente non gli conferisce il diritto di accedere anche ad aree riservate, di amministrazione e di sistema.

7. Informazioni sensibili non cifrate: altro grave errore che viene ancora commesso dai programmatori è quello di non proteggere con la crittografia informazioni sensibili. Tutto ciò che è dato sensibili che viaggi attraverso la rete o venga memorizzato da qualche parte, deve essere cifrato. Per esempio, le password devono essere memorizzate nel database in formato cifrato, tramite un algoritmo di hash non reversibile e possibilmente salted.

8. Errori nella gestione dell’upload: uno degli incubi più grandi per i programmatori di web-applications è quello di gestire gli upload di file da parte degli utenti, cercando di evitare che l’utente invii al server documenti non autorizzati, per esempio script che potrebbero contenere backdoor sfruttabili dal pirata per accedere al sistema.

A questi errori si aggiungono le ingenuità, di chi per esempio pretende di proteggeere i propri dati sviluppando da zero un algoritmo crittografico, o di chi testardamente decide di reinventare la ruota, ignorando che probabilmente la ruota è già stata inventata, e ottenendo spesso risultati poco efficienti (tipo ruota quadrata…).

Come si vede, gran parte degli errori di programmazione elencati qui sopra possono essere riassunti in 3 categorie: validazione degli input, autenticazione/autorizzazione, crittografia.

Considerando che la rete, le applicazioni web e mobili sono sempre più al centro dello sviluppo della civiltà globale, sarebbe opportuno accrescere il livello di sicurezza dei software partendo dalla base, ovvero lo sviluppo, sensibilizzando gli sviluppatori e includendo le tematiche di programmazione sicura nei percorsi formativi dei programmatori di domani.

Segnala presso:

Durante un penetration test, una volta effettuata un’intrusione su di  una macchina target, può tornare utile sniffare il traffico in transito sulla macchina stessa per poter intercettare credenziali per poter elevare i privilegi o per accedere ad altri host più preziosi. Per svolgere questo compito ci vuole  uno sniffer.

Esistono diversi potenti sniffer, commerciali e gratuiti, che però in genere necessitano di essere installati e necessitano pure driver aggiuntivi. Un penetration tester, oppure chi abbia l’esigenza di effettuare attività di incident response in condizioni critiche o difficili, ha bisogno di uno strumento tattico, facile da dispiegare e da impiegare.

RawCap è un network sniffer free per Windows, ha dimensioni ridotte (17K) e non necessita di installazione. Si tratta di un ideale tool tattico, da utilizzare durante un penetration test o in un’attività di incident response.

Tra i punti di forza:

• Può intercettare anche localhost (127.0.0.1)
• Non necessita di DLL esterne e non è necessario installarlo
• Può intercettare anche le interfacce Wifi e PPP
• Impiega poca memoria
• E’ semplice da usare

La semplicità è forse la caratteristica più evidente di RawCap. Per iniziare ad intercettare traffico basta eseguire il programma invocandolo da linea di comando e specificando l’indirizzo IP dell’interfaccia da sottoporre a controllo e il file dove memorizzare i pacchetti sniffati:

RawCap.exe 192.168.13.37 dumpfile.pcap

Una volta terminata la sessione sarà possibile decodificare il dump file con Wireshark. In alternativa è possibile anche avviare il programma senza specificare parametri; apparirà la lista numerata delle interfacce disponibili e successivamente verrà chiesto il nome del file di dump. Tutto qui.

Ho parlato degli aspetti positivi, ma naturalmente esistono anche i contro. Intanto, è vero che non necessita DLL e installazione, ma è anche vero che è basato su framework .NET2.0; certo,oggi dovrebbe essere disponibile su praticamente tutti i Windows in circolazione, però è corretto segnalarlo.

Altro limite, a detta dell’autore stesso, è l’affidabilità: se funziona perfettamente su XP, la stessa cosa non si può dire per Vista e Win7, a causa della tecnica utilizzata dal programma per effettuare lo sniffing, ovvero le raw socket, che nelle ultime versioni di Windows non sarebbero affidabili come nelle versioni precedenti.

Tirando le somme, RawCap è un ottimo strumento semplice e leggero (e gratuito) da usare in condizioni difficili o critiche, meglio se su Windows XP.

RawCap può essere scaricato dal sito ufficiale:  http://www.netresec.com/

Segnala presso:

Ebbene, questa volta Fastweb ci ricasca lasciando semi-aperta la porta dei pannelli di controllo degli utenti. La vulnerabilità, sfruttabile tramite XSS, è stata individuata da Emilio Pinna, appassionato di sicurezza informatica e laureando al Politecnico di Torino.

Riporto dal blog post di Emilio:

“Sono certo che altri service provider italiani abbiano problemi simili vista la cattiva abitudine adottata da molti provider di far accedere l’utente ai pannelli di controllo di abbonamento e modem automaticamente, senza autenticazione con user e password, a patto che la richiesta provenga dalla rete casalinga del proprietario dell’abbonamento. Questa sempificazione indebolisce l’infrastruttura, e rende vulnerabilità comuni come XSS, CSRF, DNS rebinding catastrofiche per la privacy e la sicurezza dell’utente finale. “

Per chi volesse approfondire il funzionamento della vulnerabilità, sul sito di Emilio può trovare un POC e un documento tecnico in Pdf che spiega il bug nel dettaglio.

Fastweb stia attenta, non sottovaluti gli hacker, impari dalla vicenda Sony…

Segnala presso:

Bruce Sterling nel suo libro “Giro di vite contro gli hacker”, racconta che il 15 gennaio 1990 gli Stati Uniti furono vittima di un clamoroso blackout del sistema telefonico che  coinvolse 60000 utenti. La causa di quel DoS non fu un attacco, ma un aggiornamento software, aggiornamento che però introdusse un bug, facendo collassare il sistema.

Contrariamente a quanto comunemente creduto, il Denial of Service (DoS) non è un attacco informatico, ma una condizione (la condizione di “negazione del servizio”) che può avere origini disparate (errore di programmazione, errore di configurazione, guasto hardware). Il DoS può essere sfruttato, ma può anche anche essere indotto: in questo caso si può parlare propriamente di attacco DoS.

Come tutti gli attacchi informatici, l’attacco DoS deve essere pianificato. La raccolta di informazioni sull’obiettivo e la conoscenza delle tecniche idonee, unitamente alle circostantze tattiche, alle finalità strategiche e alle risorse a disposizione determinano il tipo di attacco da portare contro il target prestabilito e determinano la riuscita dell’azione.

Se restringiamo la gamma di attacchi DoS che possono essere portati attraverso Internet, possiamo identificare tre categorie principali. In questo articolo presento alcune tecniche che seppur superate e non più funzionanti, sono di fatto archetipi che si possono ritrovare anche negli attacchi DoS attuali, e possono indicare la via che conduce alla scoperta di nuove tecniche che funzioneranno in futuro.

Attacchi basati sulle vulnerabilità
Questi attacchi si basano su bug di applicazioni e/o sistemi operativi. Alcuni anni fa erano celebri il  Ping of Death e il Teardrop, che sfruttavano in modo diverso errori di implementazione del protocollo Ip, per essere più precisi sulle dimensioni di pacchetti ICMP Echo, e sulla ricomposizione di pacchetti Ip frammentati.

Esaurimento di risorse
Altra categoria di attacchi DoS è quello dell’esaurimenti di risorse. Nel caso di Syn Flooding, l’attacco viene portato sfruttando il meccanismo di handshake del protocollo Tcp che si svolge in tre fasi; una connessione Tcp viene stabilità al termine dell’ultima fase della negoziazione. Il Syn Flooding invia richieste di connessione (con il flag SYN attivato) da più host (spoofing), senza mai portarle a termine. Questo fa si che l’host sotto attacco continui a riservare risorse dove parcheggiare le richieste di connessione incomplete. Una volte esaurite le risorse disponibili, il server smette di rispondere e le ulteriori richieste (anche di utenti legittimi), vengonoo rifiutate.

Esaurimento di banda
Si tratta forse dell’attacco più rozzo da portare, l’obiettivo è saturare la banda dell’host “nemico”. In questo campo l’attacco più diffuso è probabilmente il Ping Flooding: basta inviare continuamentr pacchetti ping corposi per tentare di occupare tutta la banda dell’avversario. Chiaramente vince chi ha più “potenza di fuoco”.

Amplificatori
Se i Ping Flooding, ovvero gli attacchi ad esaurimento di banda sono abbastanza grezzi e necessitano di una potenza di fuoco superiore all’avversario per poter aver successo, esistono varianti più sofisticate che consentono di “floodare” connessioni di portata assai maggiore di quella a disposizione dell’attacker. Sto parlando dei DRDoS (Distribuited Reflected Denial of Service). Questi attacchi asimmetrici sfruttano “amplificatori” e tecniche di spoofing per sommergere la vittima di traffico sorverchiante in grado di saturare la banda.

Smurf
Il più celebre di questo tipo di attacchi è noto come Smurf. Il cugino meno noto, l’attacco Fraggle, al posto del protocollo ICMP è basato sull’UDP, ma si tratta sostanzialmente delle stessa cosa. Il funzionamento è il seguente: il pirata invia pacchetti ICMP verso un amplificatore; ma questi pacchetti sono spoofati ed hanno come indirizzo sorgente (al quale l’amplificatore risponde) l’indirizzo Ip della vittima. Un amplificatore è qualsiasi cosa escogitabile che funga da fattore di moltiplicazione. Nel caso dell’attacco Smurf si tratta di router che restituiscono risposte ad un’interrogazione broadcast: per ogni singolo pacchetto dati (spoofato con l’indirizzo della vittima), l’amplificatore risponde con una quantità di pacchetti pari al numero degli host collegati a quella rete (broadcast). Quindi inviando un pacchetto all’indirizzo di broadcast dell’amplificatore, la vittima riceverà decine o centinaia di pacchetti di risposta.

DDoS
Il Distribuited Denila of Service è probabilmente il tipo di attacco più noto e quello più impiegato nelle attuali cyberwarfare, dall’attacco all’Estonia alle recenti peripezie di Anonymous Group.
Questo tipo di attacco si basa banalmente sulla quantità: più la botnet (rete di droni controllati dal botmaster) è vasta, più alte sono le probabilità che l’attacco abbia successo.

Finalità degli attacchi DoS
A cosa servono gli attacchi DoS? Nella maggior parte dei casi servono semplicemente per portare un disagio a qualcuno, o come forma di protesta (hacktivism). In alcuni casi l’attacco DoS può essere accompagnato da richieste di denaro, veri e propri ricatti in stile mafioso: finchè la vittima non paga, l’atatcco continua e il servizio rimane inaccessibile.
Infine gli attacchi DoS possono far parte di una strategia articolata, sabotaggio di particolari servizi come elemento di un’operazione più vasta. Nel celebre attacco di natale, Kevin Mitnick sfrutto un attacco di Syn Flooding per mettere fuori gioco un host che il Condor stesso stava “impersonando” tramite blind spoofing.

Segnala presso:

Un tunnel SSH è un canale di comunicazione cifrato che parte dal proprio computer ed ha come terminale un gateway verso Internet. Il traffico in transito in questo canale è nascosto e inaccessibile agli estranei, quindi le comunicazioni che passano su questa connessione sono riservate e non possono essere censurate.

E’ concettualmente simile a una VPN, ma è meno invasivo (non servono particolari privilegi per installare driver o altri software speciali), e  si usa come un normale proxy. Qualsiasi programma in grado di navigare tramite proxy (Socks per la precisione),  come browser, programmi di ftp, chat, può sfruttare questo tipo di connessione protetta.

Per creare un tunnel SSH servono due cose: un programma che permetta di creare il servizio sul proprio pc, e un gateway remoto verso Internet. Il programma che suggerisco per la creazione del tunnel è PuTTY Tray, per quanto riguarda il gateway consiglio di usare una shell gratuita come quelle che offre Cjb.

La Shell
Ogni h4x0r che si rispetti ha almeno una shell, ovvero un terminale remoto col quale giocherellare. A cosa serve? A nulla, però è fiko. Anzi, a qualcosa può servire. In questo caso la useremo come punto terminale del nostro tunnel, e come gateway verso Internet. Per crearsi una shell gratuita bisogna andare su http://www.cjb.net/shell.html e iscriversi. Una caratteristica interessante di queste shell è che escono su Internet tramite Tor, questo aggiunge un’ulteriore grado di riservatezza al nostro tunnel. Per la creazione del tunnel non serve null’altro, non serve neppure conoscere comandi Unix. Basta solo sapersi loggare tramite user e password, il resto lo fa il programma PuTTY Tray.

PuTTY Tray
Chi usa Windows ed ha la necessità di accedere a terminali SSH conosce sicuramente PuTTY, un software free che serve appunto per creare connessioni sicure con shell remote. PuTTY Tray è una versione modificata di PuTTY, che aggiunge alcune interessanti caratteristiche al già utile programma. La cosa che più ci interessa in questa sede è la possibilità, a differenza della versione originale, di iconizzarsi nella tray area, cosa che probabilmente i più perspicaci avevano già intuito.

Questa caratteristica si rivela assai comoda perchè una volta lanciato il tunnel, si può “abbassare” il programma e parcheggiarlo nella tray cosicchè non rompa le scatole mentre usiamo la connessione proxy cifrata.  PuTTY Tray lo potete scaricare qui: http://haanstra.eu/putty/

Creare il Tunnel
Creare il tunnel è facile, basta seguire questi semplici punti:

1. Lanciare il programma PuTTY Tray

2. Andare nella sezione Session (aperta di default quando viene lanciato il programma) e inserire shell.cjb.net nello spazio contrassegnato con ‘Hostname (or Ip address)’.

3. Nella sezione Connection, selezionare SSH e quindi Tunnel.

4. Nella casella Source port ci potete mettere un valore qualsiasi, purchè non sia quello di una porta Tcp già utilizzata (evitare qundi 25,80 etc.). Potete mettere per esempio i classici 1080,3128,8080.

5. Nella casella ‘Destination’.scrivete ‘localhost’

6. Scegliete il radio button ‘dynamic’ e cliccate ‘Add’.

7. Salvate la sessione (potreste chiamarla “Tunnel SSH”).

Fletto i Muscoli e Sono Invisibile nella Rete
E’ ora di testare il tunnel Per farlo basta lanciare la sessione PuTTY Tray appena salvata. Si aprirà la shell Cjb. Quando appare la richiesta di credenziali, inserite username e password scelti durante la fase di iscrizione al servizio. Una volta aperta la shell è possibile mettere PuTTY nella tray area. Avete creato un canale cifrato tra in vostro computer e la shell; allo stesso tempo una porta Tcp si è aperta in ascolto sul vostro computer, in attesa di connessioni verso il tunnel.

Per collegarsi a questo tunnel col browser è facile: la procedura, che varia da browser a browser è la stessa di quando vi collegate tramite proxy, solo che come host dovrete indicare ‘localhost’, e come porta il valore indicato al punto 4.

Ricapitoliamo. Un tunnel SSH è un canale cifrato non intercettabile che garantisce un alto grado di riservatezza. Crearlo è relativamente semplice, non sono necessari permessi amministrativi e si appoggia ad un servizio di shell free. Navigando tramite questo tunnel, non solo i dati sono sicuri, ma anche l’indirizzo Ip risulta essere mascherato.

Quindi, anonimi si, ma non abusate: non bastano un paio di programmini per trasformarvi nel Condor. Se fate una pirlata vengono a prendervi i cattivoni col distintivo.

Segnala presso: