Newsgroup: it.comp.sicurezza.varie
Titolo: Leggerezza del S.O. nell'assegnamento delle porte agli utenti

Per chiunque conoscesse o ignorasse questa metodologia di attacco,
invito comunque ad una lettura non superficiale e grossolana.
Il documento originale è reperibile presso il seguente indirizizzo:
http://www.rosiello.org
 (sezione bugs)
*******************************************************************************
Abstract
Questo documento evidenzia la possibilità per un utente di ottenere
l'assegnamento di una porta, precedentemente usata da un altro utente
del sistema, con scopi malevoli.
I. BACKGROUND
Il problema viene affrontato attraverso un approccio pratico della
situazione, al fine di ottenere un'idea chiara dell'essenza
dell'argomento in questione. A questo punto, questa tipologia di
attacco può essere estesa in tutti i contesti simili a quello
analizzato.
Per esemplificare il tutto è stato scelto un irc bouncer o irc bot. 
Gli irc bouncer sono utilizzati come "gateway" per collegarsi sui
server irc. Vi sono molti vantaggi nell'impiegarli quali ad esempio
quello di non mostrare il proprio indirizzo ip in rete, esponendosi ad
attacchi indesiderati e quant'altro di simile.
II. DESCRIZIONE
Sfruttando le impostazioni di default degli irc bouncer (porta in
ascolto, banner, noti messaggi di risposta, etc.), è possibile
simularne l'interazione con l'utente, al fine di ottenere dati della
vittima, come ad esempio la sua password.
III. ANALISI 
I presupposti per attuare un simile attacco sono i seguenti: 
1) conoscere la porta del bouncer della vittima;
2) conoscere i messaggi di risposta del bouncer;
3) disporre di un account sulla stessa macchina della vittima;
L'attaccante potrebbe a questo punto realizzare un simulatore del
bouncer usato dalla vittima, che si porrà in ascolto sulla stessa
porta del vero bouncer. Dato che la porta risulterà occupata, in
quanto usata dal vero bouncer, il simulatore non riuscirà a partire,
ma basterà aggiungerlo in crontab per assicurarsi che "prima o poi"
partirà. Quando la macchina effettuerà un reboot (accidentale,
volontario o doloso) il programma simulatore partirà prima del vero
bouncer, registrando i dati dell'ignara vittima che penserà di
collegarsi al suo software.
IV. DETENZIONE
La maggior parte dei sistemi operativi sono vulnerabili a questa
metodologia di attacco. Infatti esso non è un bug vero e proprio. Un
intervento venne realizzato per difendere le porte del root (gli
utenti non possono eseguire una bind() per le porte <1024) ma non
quelle degli utenti.
Le principali vittime potrebbero essere gli shell provider o chi vende
servizi internet.
V. FIX
Il problema esiste perchè gli utenti possono ottenere qualsiasi porta
maggiore alla 1024.
Una possibile soluzione, proposta da Rosiello Security, è quella di
assegnare un range di porte per ogni utente, attraverso una semplice
funzione.
Fixbind non è "la soluzione" ma solo un esempio di come sia possibile
controllare la SYS_bind call per i nostri scopi. La scelta di fermarsi
all' uid<555 è una scelta di design (non essendo un prodotto
commerciale ma solo un programma d'esempio), e non sono ben accette
critiche demenziali al riguardo.
Definizione della soluzione proposta con linguaggio logico matematico
del primo ordine:
A1. base_port = first_port+(step*uid) => base_port-1 < port_range <
base_port+step
A2. assign_port(uid, port) <=> base_port-1 < port < base_port+step &&
uid < 555
Il software proposto è reperibile presso il seguente indirizzo:
http://www.rosiello.org/archivio/fixbind.c
VI. CREDITI 
Angelo Rosiello 
ang...@rosiello.org
 
Rosiello Security
http://www.rosiello.org

 piuttosto che un'altra.
Aggiungo che il prof of concept riportato e` nonsense. Un programma
binda una porta non privilegiata. Una porta puo` essere bindata da un
programma. Quando il "fake bouncer", dopo un reboot, come suggerisce il
proof, prende "possesso" della porta, cmq, il bouncer regolare, genera
un errore, per lo stesso principio per cui, si deve aspettare il reboot
della macchina.
Francamente, mi pare un non problema, o un problema alla stregua che rm
rimuove dei file.
Per altro anche il fix proposto non mi pare molto significativo. Le
unprivileged, sono _gia`_ un sottoinsieme delle porte disponibili. Fare
le priviled delle unpriviled non mi sembra che significhi molto.
My 0.2 cents
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Lottery: a tax on people who are bad at math.

 le priviled delle unpriviled non mi sembra che significhi molto.
La scelta di design era stata ben specificata...

 se non riesce a collegarsi al bouncer... ma essendo attivo il fake...)
Se permetti, il problema è dell'utente minchione, mica dell'OS...
Tutto obviously IMHO...
-- 
The Skull says:
A Linux machine! Because an (i386|ppc|alpha|PA-RISC)
is a terrible thing to waste!

 lettura grossolana.
Prendo per buono il fatto che chi ha un opinione diversa dalla tua, ce
l'ha per forza a causa di una "lettura grossolana". Costruttivo.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Ethernet works in practice, but not in theory.


e decisamente "divulgativo-oriented", aggiungo io.

 l'ha per forza a causa di una "lettura grossolana". Costruttivo.
Non era mia intenzione offendere ma la problematica è stata trattata
anche con Symantec i quali mi hanno suggerito il post su vuln-dev.
Che possa essere ritenuta banale agli occhi di un amministratore (una
volta spiegato l'attacco) concordo (anche i bof o i DoS lo sono) ma il
problema è garantire la sicurezza a "tutti" a priori (per quanto possa
farsi) non a posteriori.
Per questo rigiravo il problema al S.O.... (se lo gestisce lui siamo
tutti garantiti), ma come SPECIFICATO nel documento non è la soluzione
ma un modo di interpretare la soluzione.

 essere attivato dal kernel o comunque da uno specialista e non da un
No. Deve essere implementata dal *programma* e dai protocolli da esso
utilizzati. Proprio per la struttura a layer su cui è progettato tutto il
networking.
Hola..


 Hola..
Non entro nel merito mi limito a dire che dovrebbe mailare qualche
milione di programmatori che implementano software tutti i giorni.

 Nel qual caso dovrebbe essere root, sig. Skull, ci ha pensato?
Cosa non e' chiaro nella locuzione "tratta di transito"?

 Cosa non e' chiaro nella locuzione "tratta di transito"?
Perchè mentre leggevo la sua mi si è palesata la stessa *identica* frase?
Ah... le cattive compagnie...
-- 
cat: .signature: No such file or directory

 milione di programmatori che implementano software tutti i giorni.
Non mi pare di essere io quello che ha trovato il clamoroso baco presente in
tutte le implementazioni tcp/ip degli ultimi trent'anni e lo deve divulgare
al mondo insieme alla soluzione...


ERRATA CORRIGE
In linea di principio concordo che la scelta di rimandare il problema
al S.O. potrebbe essere del tutto opinabile, per cui non considerate
la parte "S.O." del topic. In effetti non è facile trovare un titolo
che riassuma perfettamente la problematica esposta (almeno dal mio
punto di vista).


Questo e` un "dietro front", molto saggio.
Io rivedrei la natura della cosa, sotto forma di "informazione", del
tipo:
"cari utenti di $ciaffi (bouncer e similari), sapete che? <bla bla>.
Sapete invece che potete/dovete fare <bla bla>".
Io credo che sarebbe molto piu` utile.
Qualche spunto su cosa inserire nella parte "potete/dovete fare",
ritengo, si sia ricevuta anche in questa sede.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Lusers: can't live with them, don't get paid without them.

 ritengo, si sia ricevuta anche in questa sede.
Lo penso anche io, tutte le discussioni portano quasi sempre a
qualcosa di positivo. La categoria di appartenza è secondo me comunque
quella dello shadow software.
Per quanto concerne l'uso di SSL, con forza ribadito da skull,
continuo ad affermare che in linea di principio condivido la sua tesi,
ma è un problema che vedo più idoneo per un amministratore o un utente
esperto (nel caso in cui non venga supportato di default). Ma anche
questo è un punto di vista (e di esperienza)! Statisticamente il 90 %
degli attacchi informatici ha successo, vi sarà un motivo...
Il mio documento faceva riferimento a situazioni di default di norma,
e  non a sistemi di difesa elaborati. Questo non sminuisce le
potenzialità dell'attaco però.. se c'è qualcuno da attaccare è buona
norma informare.

 Questo e` un "dietro front", molto saggio.
In linea di principio questo non č un "dietro front" ma al piů un
voler convergere in un punto comune, per non snaturare l'essenza della
problematica trattata (qualcuno deve pur farlo se non vogliamo stare a
parlare di tutt'altro).
Non ho proposto infatti alcuna soluzione ottima. Il fixbind era un
esempio, molto lontano dalla soluzione ottima, come da me affermato
nel primo post.
Grazie comunque per l'apprezzamento rivoltomi.

 al mondo insieme alla soluzione...
Non sempre le cose che sembrano difficili ed eclatanti sono le più
fastidiose.
E' molto spesso il contrario.
(Si sbaglia piu' spesso a risolvere una divisione anzichè una
equazione alle differenze...)
Con questo concludo questo ramo di discussione.
Angelo

 Con questo concludo questo ramo di discussione.
Molto facile e molto poco conclusivo o propositivo.
D'altra parte mi pare che di conclusivo e propositivo non vi sia rimasto
nulla, da parte sua, visto che rinnega anche la sua discutibile "soluzione
proposta con linguaggio logico matematico del primo ordine"...
Cordiali saluti...


 (è di questa natura l'origine del post).
Francamente, non pareva. La natura del post, pareva (si noti l'uso del
condizionale), un "al lupo, al lupo" su una presunta debolezza di
assegnazione delle risorse tcp/ip da parte del sistema operativo.
Quando _invece_ pare evidente, anche confermato nei suoi recenti
messaggi, che il problema e` legato ad "alcuni software" di qualita`
discutibile (quindi _semmai_ la notifica va fatta a questi ultimi), ed
all'uso "leggero" da parte di alcuni utenti che, pur non informatizzati,
si prendono la briga di installare servizi in background.
Come a dire: voglio la porche, ma non voglio la patente, perche` sono un
"utente" e sta roba di voi tecnici non mi interessa.
Mi pare un punto di vista poco condivisibile, poco educativo, e in
generale da stigmatizzare.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Use SATANIX 1.0, an OS42K. When the Rapture comes, will YOU have root?


voglio le porche sulla porsche, casomai ;-)
(era per "sdrammatizzare un po' " :)

 voglio le porche sulla porsche, casomai ;-)
Freudiano, era ora di pranzo. :)
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If computers get too powerful, we can organize them into a committee.

 linguaggio logico matematico del primo ordine"...
Intervengo solo perchè lei sembra ostinato a non volere intendere
quanto da me detto precedentemente.
La soluzione proposta era solo un esempio di utilizzo della sys_bind()
per gli scopi citati.
La logica matematica è impiegata per descriverne il comportamento in
maniera formale dell'algoritmo e null'altro...
Comunque, qualunque cosa io le dica o scriva, credo che lei continuerà
ad ostinarsi in questo senso, ecco perchè ho deciso di chiudere questo
ramo di interventi.
Con il dovuto rispetto.
cordiali saluti


parlar come si mangia no, eh ?

 generale da stigmatizzare.
Per quanto poco condivisibile il mercato gira in questo modo.

 quanto da me detto precedentemente.
Non è questione di ostinazione. Proprio non ci arrivo.
A parte il pomposo primo intervento, ha passato il tempo a spiegar(m|c)i
cosa *non* intendeva dire.
Purgato del metacodice in kernelspace -da lei rinnegato come soluzione- ,
il suo intervento si limita, ai miei occhi, alla segnalazione della
possibilità, da parte di un processo utente, di bindare una porta di sua
scelta, purchè non occupata.
Molto utile, grazie...


se non riesce a collegarsi al bouncer... ma essendo attivo il fake...)
In quel caso il problema non e' nel SO ma e' nel processo... occorre una
identificazione del processo.
Brutalmente, si puo' avere una shared key nel processo buono: io invio a
quella porta la stringa CHALLENGE PIPPO, la shared key e' PLUTO, calcolo
l'md5sum, e se il processo non risponde 86589c3acf05818887bf0642ef33a3f0
lo ammazzo in quanto traditore.
Il processo traditore, al massimo puo' leggere il mio PIPPO, ma non puo'
certo indovinare la chiave PLUTO.
Potrebbe tentare un MiM attack, e io potrei usare l'md5 di shared key ed
indirizzo:porta; a quel punto ti serve un evilbot con supporto VMWare; e
non e' che non si possa fare, ma e' un'azienda di nulla... 8-D (inoltre,
potrei pensare che il processo *non si attivi* se non riceve a sua volta
un challenge-response valido. L'evilbot non ha la password, e quindi non
puo' fare partire il processo ne' sniffare la shared key.
(E' ancora possibile un doppio MiM attack; il livello di compromissione,
pero', e' equivalente al dover lottare contro root. E root vince sempre)
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 identificazione del processo.
Nell'altro thread potrà notare che c'è stato una "correzione" circa il
topic del post.
La problematica è nata perchè non tutti i software adottano sistemi di
controllo. Il tentativo era di cercare di garantire il maggior grado
di sicurezza anche in tali occasioni senza "rimproverare i software".

di sicurezza anche in tali occasioni senza "rimproverare i software".
La mia considerazione e': ne vale la pena?
In quelle occasioni IMHO la soluzione c'e', e la deve implementare il
software. Tentare di ovviare a basso livello alle pecche di piu' alto
livello e' una strategia commercialmente valida ma IMHO non elegante,
e poco pratica sulla lunga distanza.
E' un po' come un arbitratore SQL che rimedi al programmatore che non
gestisce per benino le transazioni (ogni riferimento...). Finisce che
le applicazioni si comportano sempre peggio, alla fine lo strato piu'
basso non ce la fa piu' a rimediare e si prende le colpe.
Volendo metterci mano a questa cosa dei socket, io penserei a qualche
sistema per dimostrare all'OS di gestire correttamente un'autentifica
di qualche genere (kerberos? con ssl? ipsec? challenge/response?); l'
OS ha facolta' di operare in modalita' normale o sicura. In modalita'
sicura, i processi che NON usano socket blindati non girano proprio e
necessitano di opportuni moduli proxy.
Poi l'utente decidera' in che modalita' lavorare.
Cosi', i programmi usati piu' spesso e scritti peggio riceveranno una
considerevole pressione per essere modificati opportunamente, e - con
un po' di fortuna - ...
