HPING e tools sicurezza

[NS-1]

Ciao a tutti,
ho installato a casa un server che offre diversi servizi, ora per testarne la sicurezza e affinare le configurazioni di protezione sto smanettando con diversi tools.

Avete degli esempi o delle guide per l'utilizzo di HPING?
altri tools per floodare con rispettive guide di utilizzo?

già che ci siamo, con iptables ho scritto questa riga:
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset

che dovrebbe servire per bloccare le NULL SCAN di nmap, ma anche loggando tutto, questa è il tipo di scansione che non riesco a rilevare, sapete aiutarmi?

Grazie

[LoryOne]

Aspe, aspe ... con calma :D

nmap è utilissimo in tre casi:

1 - fingerprinting attivo dello stack per ottenere con buona approssimazione il S.O. installato sulla macchina bersaglio
2 - portscanning per ottenere porte aperte/chiuse/filtrate, quindi utile per identificare servizi offerti,router o firewall
3 - ottenimento dei banner su server Web che spesso e volentieri forniscono indicazioni sulla versione installata

visto che hai citato nmap, ti suggerisco di leggerti i seguenti files allegati al pacchetto software che hai sicuramente scaricato:
nmap-os-db
nmap-os-fingerprints
nmap-...

Nmap forgia pacchetti (RAW socket) che spedisce al target specificato ed analizza le risposte ottenute in accordo con le specifiche dei files sopra citati

Un ottima strategia, oltre a quella di tenere sempre aggiornato il tuo server con le patch più recenti, è quella di falsificare le risposte del tuo server, facendo credere che le porte siano tutte aperte, che il S.O. sia Linux invece di Windows (o viceversa) e modificando opportunamente i banner restituiti in seguito ad interrogazioni su porte specifiche.
Focalizza la tua attenzione su RPC.
Mi raccomando ... Installa un IDS e verifica sovente i log

Ps: Spesso basta poco per prendere in giro chi vuole prendere in giro te ;)

[NS-1]

grazie mille Lory...
...non è che hai qualche documento specifico? qualche guida avanzata?

per quanto riguarda le risposte fasulle da parte di un server attaccato, ci sto lavorando... =) ... tutte le porte sembrano aperte, a tentativi di connessione ssh appare il messaggio di login che in realtà non lo è... etc...


grazie...

[LoryOne]

grazie mille Lory...
...non è che hai qualche documento specifico? qualche guida avanzata?


No perchè non ne esistono.
Esistono solo la pratica e l'esperienza che nascono dalla eterogeneità delle diverse configurazioni di protezione impostate da amministratori di sistema con diversi gradi di conoscenza sull' argomento.
L' importante è che tu abbia un' ottima conoscenza della struttura dei protocolli.
Se vuoi ho un po di documentazione per creare tu stesso i tool che t'interessano, cominciando dagli sniffer, passando per il port scanning, fino ad arrivare all' enumerating resources ed infine ai buffer overflow su stack ed heap per modificare a tuo piacimento l'Instruction Pointer ed ottenere shell remote in base ai privilegi d'accesso sul server che t'interessa.
Non ti fornirò mai codice in merito ... quello è tuo compito.
Posso solo darti la conoscenza che ti serve. Approfondirai tu stesso.

Per quanto riguarda nmap, il sito di insecure.org è veramente ben fatto e la guida sul portscanning è ottima.

[NS-1]

Se vuoi ho un po di documentazione per creare tu stesso i tool che t'interessano, cominciando dagli sniffer, passando per il port scanning, fino ad arrivare all' enumerating resources ed infine ai buffer overflow su stack ed heap per modificare a tuo piacimento l'Instruction Pointer ed ottenere shell remote in base ai privilegi d'accesso sul server che t'interessa.

puoi darmi qualcosa in privato se ti mando il mio indirizzo mail?


Non ti fornirò mai codice in merito ... quello è tuo compito.
Posso solo darti la conoscenza che ti serve. Approfondirai tu stesso.

(Y) e altrimenti il bello dove starebbe? :) col tempo ho imparato che le cose già fatte sono noioso e servono molto poco

grazie
Ns-1

[LoryOne]

Perchè in privato ?
Niente di quello che vorrei postare è così pericoloso da essere postato in privato. Certo, può diventarlo ma dipende solo dal fine che vuoi ottenere.
Più tardi invierò qualcosa.

[Thor]

bene bene :)

se metti un bel linkello, scarico pure io ;)

[LoryOne]

Bene.
Prima di tutto avete bisogno di un generatore di pacchetti e di uno sniffer.

Collegatevi al sito www.komodia.com e scaricate il software PacketCrafter, così creerete voi stessi i pacchetti che verificherete con lo sniffer che scaricherete da qui: www.microolap.com/products/network/tcpdump
Aspettate ad utilizzarli, almeno fino a quando non avrete una conoscenza completa di tutto cio che vi si presenta a video.

Segnalo un' importante considerazionie: tcpdump non utilizza i socket per sniffare i pacchetti ma le API ben note di Windows Writefile, DeviceIOControl e ReadFile, in modo da ottenere accesso diretto alla scheda di rete o al modem che utilizzate per collegarvi. I dati sono grezzi, quindi le strutture dei protocolli, non appena sarete in grado di generare un frame, dovrete crearle voi stessi. NON servono, qiundi, le WindowPacketCapture (WinPCap) utili al funzionamento ad esempio di windump

Avendo già parlato di frame e protocolli, la prima cosa che dovrete fare è quella di imparare come viene generato un frame ed in cosa consiste la struttura di un protocollo, sia esso IP, ICMP, ARP, TCP o UDP.
Io vi ho trovato un' ottima guida qui: www.rhyshaden.com, ma cercate voi stessi il sito che vi sembra maggiormente esplicativo. Leggetevi con attenzione la parte sul protocollo TCP e l'instaurazione di una sessione con scambio dati e chiusura sessione. Saranno illuminanti per comprendere concetti quali il dirottamento di sessione e/o l' IP forwarding in attacchi di tipo MIM (Man in the middle), smurfing, fraggle e SYN flooding
Impararte bene anche l' ICMP perchè soggetto a tunneling

Seguirà un piccolo script commentato di uno scheletro di sniffer in C utile a gettar le basi per tutti i tool che vorrete sviluppare in futuro, quando vi sarà chiaro che non vi è nulla di particolarmente complesso ne di magico.

[LoryOne]

I più impazienti potrebbero collegarsi qui http://unsecure.altervista.org/rawsocket/rawsocket.htm. E' per Linux ma in windows le cose cambiano di poco. ;)

[NS-1]

grazie e....
...se è per linux è meglio.... (Y)

[LoryOne]

Allego il piccolo file in C come promesso. C'è da lavorarci un po su ma il più è fatto, credetemi.
Ammetto che non è farina del mio sacco (mia è quel che segue e che potreste ottenere) ma fornisco alcune spiegazioni come è doveroso dare:
1 - La struttura definita è quella del solo Header IP
2 - SockAddr.sin_addr.s_addr = inet_addr("127.0.0.1") indica l'indirizzo di loopback, dovrete assegnare il corretto indirizzo IP
3 - SIO_RCVALL non esiste ma è stato definito per ottenere la modalità promiscua

Ecco cio che segue, ossia la struttura di un ipotetico frame TCP/IP comprensivo del MAC delle due schede di rete impiegate nel trasferimento su porta 23 (telnet)

ether: =================Ethernet Datalink Layer==================
Station: 00-00-C0-DD-14-5C ----> 00-A0-24-AB-D1-E6
Type: 0x0800 (Internet Protocol)
ip: ====================Internet Protocol=====================
Station: 144.19.74.44 ----> 144.19.74.201
Protocol: 06 (TCP)
Version: 4
Header Length (32 bit words): 5
ToS: 00000000 (Precedence:Normal Delay:Normal Throughput:N
Reliability:Normal Cost:Normal MBZ:0)
Total length : 44
Identification: 1
Fragmentation: (DF:0 Allowed MF:0 Last fragment)
Offset: 0
Time to Live: 100
Checksum: 0xA1AF
tcp: ================Transfer Control Protocol=================
Source port: 6295
Destination port: 23
Sequence number: 25784320
Acknowledgement number: 0
Data offset (32 bit words): 6
Control bits: 010010 (URG:0 ACK:1 PSH:0 RST:0 SYN:1 FIN:0)
Window: 30719
Checksum: 0xFB8A
Urgent pointer: 0
Option: 02 (Maximum Segment Size)
Option Length: 4
Maximum Segment size: 1024

Ecco come si presenta il frame nel buffer del dispositivo di rete (in Hex):
00a024abd1e60000c0DD145C08004500002c000100006406a1 af90134a2c90134ac9189700170189700000000000601277ff b8ae000002040400

Manca la parte relativa ai dati trasmessi ma, visto che in C avete la possibilità di spostarvi facilmente tramite puntatori al buffer, non vi sarà difficile andare a leggere anche quello.
Di quanto ci si deve spostare ? Beh, la dimensione dei pacchetti la conoscete, la struttura dei protocolli anche. Guardate i flag del protocollo TCP: SYN ed ACk a 1 ... in quale fase dell' handshake a tre vie ci troviamo con questo pacchetto ?

Bene.
Ora potete fare quello che volete. La fantasia è vostra ;)
Avevo parlato anche di buffer overflow ma su questo non posterò nessun codice, sebbene ci sia parecchio su Internet (soprattutto dal punto di vista teorico), basta saper cosa cercare.
Se cercate ad esempio "Hack Proofing your Network" otterrete un PDF estremamente illuminante sull'argomento, così come "Smashing The Stack For Fun And Profit"
Adesso mi limiterò a spiegare una delle tecniche più semplici (overflow dello stack) adottata da quei malefici cracker che forgiano pacchetti ad hoc per compromettere la sicurezza di prodotti creati da programmatori poco attenti e frettolosi :D
Ma come fanno queste persone geniali ?
Semplice, prima provano in locale, poi con l'ausilio di un debugger ed una discreta conoscenza di assembly compilano porzioni di codice che poi trasformano in sequenze di bytes da spedire al server di turno :D ;) (Ricaviamo il banner e vediamo che versione di IIS gira su 'sta macchina, per esempio)

Avete mai provato a disassemblare un file di testo ?
Se lo faceste, vi sorprendereste nel vedere che anche questo tipo di file conterrebbe istruzioni assembly, ma ovviamente, la cosa vi sembrerebbe alquanto strana.
In realtà di strano non ci sarebbe niente, visto che un file di testo altro non è che una sequenza di caratteri il cui codice ASCII può essere trasformato in binario.
Se questa sequenza si riferisse ad un programma, se questa sequenza contenesse istruzioni valide ed infine fosse memorizzata in un corretto segmento di memoria, il computer eseguirebbe la sequenza interpretando correttamente dati ed istruzioni.
Come fa un computer a comprendere quali sequenze di bit sono da considerare dati e quali istruzioni in un flusso sequenziale di bytes ?
La risposta risiede in una porzione di CPU adibita a codificare dati ed istruzioni in base a sequenze prestabilite in accordo con l'architettura interna del processore stesso (CISC oppure RISC) e che costituiscono il suo set di istruzioni.

La memoria atta a contenere un programma è suddivisa in porzioni e ad ognuna di queste vengono assegnate parti specifiche (segmenti) del programma che si chiamano Text, Data, Bss, Heap e Stack.
Il primo segmento contiene le istruzioni in codice macchina
Il secondo ed il terzo segmento contengono le variabili globali e statiche inizializzate e non.
Il quarto segmento è adibito all'allocazione dinamica della memoria
Il quinto ed ultimo segmento contiene gli indirizzi di ritorno di funzioni e parametri di funzione

La CPU esegue un programma passando in rassegna ogni istruzione attraverso l'utilizzo di un puntatore (Instruction Pointer) ad una nuova istruzione in questo modo:
1 Legge l'istruzione puntata da IP
2 Aggiunge ad IP la lunghezza in byte della nuova istruzione in modo da sapere qual'è la prox. posizione in memoria per procedere
3 Esegue l'istruzione
4 Ritorna al passaggio 1 e via di seguito.
Nei processori a 32 bit e successivi, l'IP ha preso il nome di EIP o Extended Instruction Pointer.

A questo punto dovrebbe esservi chiaro che conoscere a priori il nuovo indirizzo a cui punta l' IP potrebbe darvi la possibilità di intervenire sul normale flusso di istruzioni eseguite.
Qualunque programma che si rispetti acquisisce, elabora ed infine restituisce risultati; solitamente i dati in input hanno una lunghezza fissa, basti pensare alla lunghezza massima di cui si compongono i pacchetti che viaggiano ogni giorno su Internet (Maximum Receive Unit) ed i programmatori utilizzano istruzioni tali per cui, in situazioni normali, il programma gira senza problemi di sorta.

Cosa succederebbe se in un buffer predisposto per contenere un numero di bytes fisso giungessero dati di dimensioni molto maggiori e le istruzioni utilizzate per gestirlo consentissero ai bytes in eccesso di straripare (buffer overflow) sovrascrivendo l' EIP e la porzione di memoria atta a contenere le istruzioni normalmente eseguite ?
E se parte dei bytes straripati contenessero sequenze di bytes corrette al fine di eseguire comandi arbitrari ?

L'unico scoglio da superare sarebbe quindi quello di conoscere esattamente l' indirizzo corretto al quale punterebbe l' IP dopo lo straripamento, ma basterebbe inserire una sequenza abbastanza lunga di istruzioni "inutili" come i NOP in prossimità dell' indirizzo presunto, in modo da far slittare l' EIP fino al bytecode ed eseguirlo.
Questa tecnica viene chiamata NOP Sled, letteralmente slitta di NOP, ed è una delle tecniche basate sull'overflow dello stack, ma ne esistono altre basate sull' heap ed addirittura sulle variabili d'ambiente.
Fortunatamente molti IDS sono in grado di prevenire un buffer overflow basandosi sul riconoscimento di sequenze ripetute di caratteri (le Sled, appunto) ma esistono bytecode polimorfici in grado spesso di passare inosservati.

Il tempo ha lasciato spazio a numerosi crackers per inventarsi bytecode temibili eseguiti in seguito ad overflow del buffer basati sia su stack sia su heap e malauguratamente, considerata la complessità dei software ed il tempo sempre più ridotto per essere i primi sul mercato, gli errori di implementazione nel codice saranno sempre presenti e difficili da prevedere.
Chi si sentirebbe sicuro sapendo che non solo gli overflow ma anche gli underflow possono consentire l'esecuzione di codice arbitrario ?
Se trovate interessante l'argomento, allora potreste approfondire fino al punto di dover scegliere tra due strade: il cracking oppure l'hacking. La differenza sta solo nello svelare l' exploit e collaborare per patcharlo, oppure sfruttare il baco per scopi fraudolenti.

[NS-1]

:)
grazie di tutto e... sei una bestia!!! (Y)

[cippico]

:)
grazie di tutto e... sei una bestia!!! (Y)

che gran discussione...tecnicissima... :act:

complimenti...

ciao

[NS-1]

che gran discussione...tecnicissima... :act:

complimenti...

ciao

spiegati meglio così prima di mandarti a quel paese ne ho la conferma.

[NS-1]

...

già che ci siamo, con iptables ho scritto questa riga:
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset

che dovrebbe servire per bloccare le NULL SCAN di nmap, ma anche loggando tutto, questa è il tipo di scansione che non riesco a rilevare, sapete aiutarmi?

Grazie

sapete darmi una spiegazione?
se eseguo:

nmap -sN -F -sV -O -T5 ipDelServer

questo tipo di scansione non riesco a loggarla...

[LoryOne]

Lo stack TCP non è lo stesso su tutti i S.O.
Quello di Windows potrebbe essere differente da quello implementato su Linux.
E' ovvio che apertura, controllo dei flussi e chiusura di connessioni devono essere rispettate da qualunque S.O. che utilizzi TCP per lo scambio d'informazioni, ma sollecitare lo stack in modo non convenzionale da adito a diverse interpretazioni.
Nel tuo caso, a detta della RFC 793 (Request For Comment), avendo disabilitato tutti i flags, la risposta dovrebbe essere RST per tutte le porte chiuse.
TCPDump ti serve appositamente per verificare quanto accade ;)
La disussione è davvero molto tecnica.

[cippico]

spiegati meglio così prima di mandarti a quel paese ne ho la conferma.

piu'...spiegato di cosi'...mi sembrava chiaro che si trattava di un complimento...visto come e' stato trattato e spiegato l'argomento...

ciaooo

[NS-1]

adesso faccio qualche test con wireshark e poi vi dico che succede... (Y)

[NS-1]

queste sono le regole impostate per loggare le scan:
(politiche di default di iptables per INPUT, FORWARD e OUTPUT --> DROP)

iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti che non hanno flag attivi
iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti SYN,FIN
iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti SYN,RST
iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags FIN,RST FIN,RST -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti FIN,RST
iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags ACK,FIN FIN -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti FIN senza ACK
iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags ACK,PSH PSH -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti PSH senza ACK
iptables -A INPUT -m limit --limit 10/min -p tcp --tcp-flags ACK,URG URG -j LOG --log-prefix "SCAN: "
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j REJECT --reject-with tcp-reset #Scartiamo i pacchetti URG senza ACK

con i tipi di scansione classici, loggavo tutto a parte il tipo NULL. Nmap riportava alcune porte come 'sospette' a differenza delle altre scansioni che come esito venivano viste come chiuse....
...poi ho controllato i log in uscita e ho visto che i pacchetti di risposta alla scansione NULL con flag ACK,RST attivi venivano bloccati.

ho aggiunto questa regola:

iptables -A OUTPUT -o eth0 -p tcp --tcp-flags ALL ACK,RST -j ACCEPT #RESET CONNESSIONI

ora anche la scansione NULL dà come risultato lo stesso delle altre...
però non capisco una cosa, "-j REJECT --reject-with tcp-reset" non fa la stessa cosa?