Newsgroup: it.comp.sicurezza.varie
Titolo: domanda

Tratto da un tristissimo testo sull'hacking preso non-so-dove dal web..
"Sure, you can telnet into your shell account from another
ISP account. But unless you have software that allows you to send your
password in an encrypted form, someone may sniff your password and break
into your account."
Dal momento che questo testo ha l'aria di essere piuttosto vecchiotto e
quindi antecedente ai vari netbus, bo ecc... mi chiedo come sia
possibile sniffare la password che qualcuno sta inviando ad un server
qualsiasi senza che la vittima abbia un trojan nel sistema...
Grazie
Francesco

Credo tu stia facendo un pò di confusione.
Potrei stare per dire un sacco di cazzate per cui correggetemi se sbaglio.
Quando tu ti connetti al tuo isp con il ppp rimani interno alla sua LAN, per
cui i tuoi pacchetti che contengono la psw non possono essere sniffati dall'
esterno(forse dalla segretaria???).
Quando ti connetti al tuo account da un' altro ISP i pacchetti con la tua
psw vengono inviati broadcast fino al tuo ISP, ciò comporta che qualcuno
possa sniffare i suddetti pacchetti, e se hai lasciato tutto in chiaro
buonanotte e sogni d'oro.
ciao ci...

qualsiasi senza che la vittima abbia un trojan nel sistema...
Sniffare durante il transito in rete,non sulla tua macchina.
Il succo era quello: tra il tuo modem e il tuo provider, salvo mamma
telecom, nessuno puo' leggerti il traffico.
Qualunque login ad un punto piu' lontano, che deve atraversare svariati
server, senza crittatura, il traffico e' a rischio.
Dal punto di ingresso in rete alla destinazione, i dati sono *catturabili*
da malintenzionati che abbiano accesso alla linea.
Ciao.roberto
-- 
Save our planet!
Save wildlife;
For your E-MAIL use only recycled Bytes !!
roberto poggi  
rpo...@usa.net

 qualsiasi senza che la vittima abbia un trojan nel sistema...
E' piuttosto difficile, ma non impossibile: basta che ci sia una macchina
con installato un fiutatore (magistrale traduzione della parola "sniffer" 
;)))) ) sulla stessa sottorete nella quale si trovano la macchina telnettante
o la macchina telnettata e a condizione che la macchina che sniffa sia
collegata via ethernet con la solita schedina di rete: nelle connessioni
dialup in PPP, le macchine ricevono solo i dati a loro diretti.
Inoltre, per piazzare uno sniffer, l' utente deve avere privilegi di root.
Ciao
P.S.: Se la rete che vuoi hackare è sufficientemente seria e l' admin è ben 
      preparato, non useranno certo un aggeggio pericoloso come telnet, ma 
      qualcosa di più sicuro come il buon SSH, quindi snifferai solo roba 
      inutile... :)))

 Inoltre, per piazzare uno sniffer, l' utente deve avere privilegi di root.
Dimmi se ho capito bene ... io posso (se ho il root) sniffare soltanto dati che
arrivano ad un server collegato ad una rete ethernet di cui fa parte anche il mio
pc?In pratica se qualcuno invia dati ad un server che sa per certo che non fa
parte di una rete ethernet puo' stare tranquillo che i suddetti dati non possano
essere rubati da terzi?
Infine : se l'unico modo per sniffare dati diretti verso un altro pc è quello di
essere in rete ethernet con quest'ultimo..ogni volta che questo accade non
dovrebbe essere difficile rintracciare il malfattore o no? a che serve allora
criptare i dati?? Dov'è che sbaglio?:)
Saluti
Francesco

criptare i dati?? Dov'è che sbaglio?:)
Sbagli candeggio: in uno qualsiasi dei passaggi, ci puo' essere lo sniffer,
e per siti oltreoceano, ho avuto un record di 34 server intermedi, una
volta, ti lascio immaginare la velocita' di risposta :-(


 traffico.
Si ma i miei dati non passano per il pc del mio vicino di casa, passano cmq attraverso
server che dovrebbero instradare i pacchetti non sniffarli tipo server di provider o
cmq di organizzazioni che non dovrebbero fare cose del genere (sbaglio?) ... mi fido
troppo del mio prossimo??:)Abbiate pazienza, sono ancora alle prime armi....:)
Saluti
Francesco

problema diverso, ma non e' certo
Senza manomissione fisica degli apparati telecom? 
Senza cimici sul telefono di uno dei due corrispondenti?
Parlavamo di cavo, non di cellet su cellulare, mi sembra.
E di sniffatura, non di intercettazioni.
Se poi parli di tempest.....
Comunque, vai con il problema diverso.


ragionevolmente sicuri?
Mai approfondito troppo, in rete di solito faccio passare poco piu' che
cazzate, non mi preoccupa troppo il rischio che corro.
Poi, il ragionevole e' un concetto poco matematico :-) [*]
Bisogna vedere a quale livello di ssl di puo' arrivare, e come sempre, quale
appetito cio' che circola va a stuzzicare.
Altri piu' studiosi di me avranno di certo info al riguardo, sul tipo di
crittatura, il livello dei certificati, la lunghezza delle chiavi,....
Quello che e' certo e' che una password cifrata, pone alcune difficolta'
ulteriori a chi intercettasse il messaggio, se il livello di crittografia e'
sufficientemente alto,(non chiedetemi quanto ci vuole per un 1024 bit, con
un sestium IV a 1,2Ghz, non ne ho la piu' pallida idea) e la password non e'
*pippo* , il tempo di forzatura potrebbe essere piu' alto del tempo di
rinnovo di tale password.
Ciao.roberto
[*] che comunque sembra sufficiente, visto che l'e-commerce sta prendendo
piede, e le statistiche di rischio, sembrano umane.
Morale: la truffa ogni tanto, si becca, ma ha una probabilita' talmente
bassa, che gli analisti dicono fisiologica e sopportabile.
Probabilmente la definiscono sopportabile, perche' a loro non hanno mai
vuotato il conto corrente :-)


Non mi menare per la domanda.
Se nessuno mena me per la risposta, figurati.
Ciao.roberto.
[*] Da qui, come vedi, ci si potrebbe accorgere che qualcuno sta
sniffando.....


Ti vorrei chiedere non  c'è modo di rilevare lo sniffer?
Se sei nella stessa sottorete si', ma naturalmente c'e' anche modo di
nascondersi ad un esame.
Per es., se usi tcpdump -i eth0 su una box Linux, ti posso beccare.
Pero' c'e' gia', credo, l'apposita patch nel kernel 8-)
E' un po' come sapere chi sta ricevendo la trasmissione del satellite
stando sul satellite. Basta che uno abbia una parabola e riceva solo,
ed ecco che - come fai a beccarlo?
Leonardo
".signature": bad command or file name

 "chiave di lettura"? se č cosě non č possibile sniffare questo "accordo" tra le 2 parti in modo da poter ugualmente decriptare i dati?
Sono quanto di piu` lontano da un esperto, ma esistono vari tipi di
crittografia.
A chiave simmetrica: la stessa chiave critta/decritta il messaggio,
quindi andra` in un qualche modo passata tramite canale sicuro, se
non si vuol correre il rischio di intercettazioni.
A chiave asimmetrica, tipo pgp, in cui entrambe le parti rendono
pubblica una delle loro *due* chiavi. La chiave pubblica di A, serve
a decifrare cio` che e` stato scritto con la chiave privata di A,
quindi basta che B abbia la chiave pubblica di A, che non e` un
segreto; es pratico: A critta un mex con la chiave pubblica di B
e glielo manda, il mex anche se intercettato puo` essere letto solo
da B, che ha la corrispondente chiave privata; non c'e` modo di
ricavare (in tempi ragionevoli) una chiave privata da una pubblica;
in piu` A puo` "firmare" il mex che invia usando la propria chiave
privata, in modo che B, usando la chiave pubblica di A, possa avere
la certezza che A e` il vero mittente. Il prob e` che devi essere
certo che ad una data chiave pubblica corrisponda il proprietario
"vero" (posso pure farmi una chiave a nome Bill Clinton... qualcuno
deve autenticarne la validita` - Monica, per esempio)
Altro sistema e` l'utilizzo di chiavi temporanee (tipo kerberos?),
ma qui e` meglio se parla qualcuno che sa realmente come funzionano
ste cose :-)
-- 
Davide   |`. /\    
albe...@usa.togli.questo.net
   | PGP KeyID:
Alberani |__)~~\ 
http://members.xoom.com/alberanid/
 | 0xD0354739

>>[...]
Fammi capire quindi i simpaticoni che si intromettono nella comunicazione
tra due macchine desincronizzando il numero di seq e l'ack dei pacchetti che
si scambiano il server  ed il client, risultano praticamente trasparenti?.

 non si vuol correre il rischio di intercettazioni.
Ma da quanto detto in precedenza non esistono canali sicuri via internet o si?
Se la risposta è si allora non ho capito niente:)
Saluti
Francesco

 Se la risposta è si allora non ho capito niente:)
Hai ragione, ma dipende da quanto sei paranoico :-)
Puoi passare la chiave con una telefonata diretta (e sperare che
qualcuno non intercetti la telefonata), tramite corriere (e sperare
che nessuno legga la tua posta), via piccione viaggiatore (e sperare che
nessuno abbia miglio migliore del tuo). Internet in se` non e` un
canale sicuro, pero` perche` qualcuno si intrufoli nei fatti tuoi
devi essere un potenziale bersaglio (nel qual caso lo sai, e prendi le
dovute precauzioni) o devi avere tanta sfiga (e mi chiedo cosa se ne
fara` - poniamo - un giapponese della password della tua mailbox
su hotmail ;)


sen...@tin.it
 wrote:
 >Fammi capire quindi i simpaticoni che si intromettono nella comunicazione
 >tra due macchine desincronizzando il numero di seq e l'ack dei pacchetti che
 >si scambiano il server  ed il client, risultano praticamente trasparenti?.
Lo scrivi come se fosse facile...
(Ok, con windows *e`* facile...)
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

 qualsiasi senza che la vittima abbia un trojan nel sistema...
un troyan non serve ad un fico in questo caso :)
quando batti sulla tastiera per inserire qualche bella letterina in un bel
box di una pagina web, ad esempio, che non usi SSL, sempre ad esempio,
invii pacchetti che contengono proprio quello che hai scritto in giro per
la rete, precisamente dal tuo IP a quello del server WWW. Non essendoci
route prefissate, stabili, e sicure tra due IP non puoi sapere con
certezza dove andranno tutti i tuoi byte prima di arrivare al server. Non
pui sapere con certezza se qualcuno li reindirizzi o meno. L'unica cosa
che sai e' che NON li hai criptati :) Quindi chiunque abbia accesso fisico
al layer datalink puo' guardare dentro ai pacchetti IP mentre passano
lungo i cavi su cui ha accesso in qualche modo (non necessariamente
fisico) ed intercettare tranquillamente quanto tu scrivi.
bye
invy
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------

       inutile... :)))
e poi utilizzeranno tranquillamente Netbios, POP3, FTP e compagnia bella,
soprattutto laddove esistano molti utenti NON esperti e consci. Proprio
per evenienze di questo tipo e' in dirittura d'arrivo ufficiale IPSec.


 password.
Ahhhhhhh :) ecco perche' fanno tanta notizia quando sono gli ISP ad essere
compromessi :PPPPP
a mio modo di vedere ogni tipo di connessione andrebbe criptata. Se un ISP
ha centianai di POP non e' ipotizzabile che ogni terminal server abbia
accesso in hardware a tutte le coppie login/password. Se esistono dei
canali di comunicazione tra i server e i DB utenti, allora un ISP
compromesso e' un altro settore rosso.
L'unica parte del percorso sicura e' tra PC e modem.
<paranoia>
ma ricordiamo che dopo la tastiera ci sono anche i keylogger :))))
</paranoia>
invy :)


pazienza, sono ancora alle prime armi....:)
oh mamma :) ..... mai sentito di intrusioni non autorizzate ? e di
impiegati licenziati e vendicativi ? e di talpe in frodi bancarie ? e di
tutta la parafernalia di leggende metropolitane in merito ?
non sei alle prime armi :)
sei al primo giorno di scuola all' Istituto Essere Umano .... :)
invy


 hai , no ma chefai!! noooooooo...........
non ti meno :) ma mi chiedo:
qualcuno sa qui che cosa sia uno sniffer ?! :P
postdesincronizzazione per metterli in circolo ?
gesu' se da quando ci sono i computer non avessero ancora trovato il modo
di implementare il semplice concetto della copia di aree di memoria
staremmo freschi ...
uno sniffer NON interviene in alcun modo sul flusso dei pacchetti. Ne
richiede, mediante servizi host specifici del kernel, una copia sulla
quale opera come preferisce. Per questo non e' possibile capire dai
pacchetti se siano stati sniffati. E in un route '''oceanico''' neanche da
qualche presunto lag. Un hint:
promiscuita'.


 ragionevolmente sicuri?
ragionevolmente si .... ma la ragione dipende anche da cosa tu debba
proteggere. un punto spesso sorvolato dai piu' e' il concetto di
tempo/resa che FA PARTE delle considerazioni sugli algoritmi
criptografici. Se devi proteggere un numero di carta di credito che fa
capo ad un conto con 5milioni in banca ed un limite mensile magari non
molto piu' alto, allora infrangere SSL (usato da netscape e co) in qualche
settimana (magari .....) con migliaia di macchine oppure in poco tempo ma
avendo pagato per una macchina apposita cifre ben piu' alte NON E'
CONVENIENTE per un attaccante. Molto meglio tentare un'intrusione nel
server con il DB delle carte di tutti gli utenti e clienti.
Diverso discorso per transazioni differenti, in cui strati concentrici di
criptazione mediante differenti chiavi possono auGmentare tali dislivelli.


 sniffando.....
no. in quanto, per come e' strutturata ethernet, cmq tutti i nodi ricevono
i pacchetti, solo che il kernel non li degna di uno sguardo se non sono
per lui o se non e' in mod. promiscua. una volta invece degnati :) possono
essere manipolati mentre gli altri nodi fanno quel che vogliono con tale
pacchetto. Questo per sniffer on-route. Se invece il route venisse
alterato per lo sniff di connessioni normalmente non raggiungibili allora
in quel caso potremmo accorgercene da differenti (statisticamente) ttl ad
esempio, ma la questione si farebbe dura nell'intervallo di tempo in cui
accade. la flag piu' ovvia e' la promiscuita'.


decriptare i dati?
questa e' la prima domanda interessante del thread :)
il concetto che tu esponi e' intuitivo ed esatto. Ovviamente pero', grandi
matematici e ricercatori 'che non avevano la ragazza la sera'(C)Newbie1.1
:PPP ci offrono sistemi per lo scambio di chiavi pubbliche mediante
exchange di calcoli sui numeri primi, in modo da non compromettere le
chiavi stesse. Diffie-Hellman ne e' un esempio.


 ed ecco che - come fai a beccarlo?
teoricamente semplice :) SE, in tv digitale in un canale interattivo, un
segnale permetta di ricevere risposte dalle parabole contenenti il numero
di serie della smart card, SE lo invio solo ad alcuni di cui conosco il
numero e me ne torna uno indietro in piu' ..... EHI quello li ha sniffato
quello che non doveva !
QUESTO NON E' VERO :) con la tv via sat ma e' una interessante analogia
del modo da usare per trovare interfacce promiscue in rete :)


 si scambiano il server  ed il client, risultano praticamente trasparenti?.
premessa: che c'entra con lo sniff dei dati ?! :)
ad ogni modo: dipende.
in una connessione all'interno della stessa LAN non sono trasparenti
neanche pregando in dieci lingue :) per vari motivi, che spaziano dalle
tempeste di ACK, ai pacchetti persi per spoof del MAC, alle connessioni
cadute, agli stati veri e propri di desincronia.
Ma, ipotizziamo, in una connessione oltre una trentina di hop, magari
anche 10, e' possibile per l'attaccante, nel caso si trovi vicino ad uno
degli estremi della connessione, poter mantenere lo stato per entrambi in
un tipico man-in-the-middle trasparente (quasi).


 Se la risposta è si allora non ho capito niente:)
in questo caso hai capito. infatti la chiave simmetrica si usa per
transazioni tra macchine/utenti che gia' dispongano della chiave. per
passaggi e accordi online sulla chiave si predilige il binomio
pubblico/privato.
Un ottimo libro e' Applied Cryptography di Bruce Shneier, inventore di
Blowfish.



a parte le paranoie , il maggiore rischio e'  nel tratto router ->serverISP ,
perche' negli altri tratti il rapporto costo / beneficio e' molto piu' basso.

 perche' negli altri tratti il rapporto costo / beneficio e' molto piu' basso.
yes, concordo. effettivamente ho quotato male, editando tutta la riga
invece dell'ultimo tratto. E per quanto potesse essere chiaro a me non
l'ho reso agli altri :P ...


 l'ho reso agli altri :P ...
Visto che sei  abbastanza rodato in quanto a  sicurezza su reti , conosci anche
cose di sicurezza in relazione ad ambienti Object Oriented?

</paranoia>
Si', ma devi essere gia' compromesso di tuo.
[paranoia-joke]
Guardati alle spalle, quella macchiolina sul muro,no, non li', un po' piu' a
sinistra,ecco,si', quella li',  e' una microtelecamera che registra tutto
cio' che scrivi e lo invia nell'etere.
[/paranoia-joke]
Ciao.roberto


si scambiano il server  ed il client, risultano praticamente trasparenti?.
Nooo! Io parlavo di mettere la scheda in modo puttan^H^H^H^H promiscuo
e leggere quel che passa. Server e client non desincronizzano niente.
I pacchetti in locale sono broadcast, chi li vuole se li piglia.


in...@echelon.net
 wrote:
 >ma ricordiamo che dopo la tastiera ci sono anche i keylogger :))))
Infatti abitualmente non faccio mai login da computer di sconosciuti,
anche usando ssh, se non ho la mia lista di password usa e getta.


 sei al primo giorno di scuola all' Istituto Essere Umano .... :)
Molto buono....:)

in...@echelon.net
 wrote:
 >lo sniffer puo' anche trovarsi su di un HOP intermedio. Famosi gli
 >attacchi ai gateway dei provider di grandi dorsali sulle quali transitano
 >la maggior parte delle connessioni di quasi tutti :)
Saranno anche famosi, ma non ho mai visto prove della loro esistenza.
I gateway di grandi dorsali sono router accessibili solo dall'interno
del provider e anche ammettendo di riuscire ad accedervi e` decisamente
impossibile configurarli in modo che facciano un "forward" dei pacchtti
che ti interessano senza che qualcuno se ne accorga.
Se ti riferisci a host su cui attaccare sniffer allora tieni presente
che i backbone non sono certo reti shared (a parte quelli FDDI) e di
sicuro non hanno host (sopratutto se insicuri) direttamente collegati.
 >esistono anche sniffer hardware inseriti lungo le cablature (spesso questo
Temo che ci voglia un bel po' di elettronica custom per decodificare
ethernet e prendere solo la parte che serve. Non dico che e`
impossibile, solo che non e` alla portata degli attaccanti non
istituzionali.



centra eccome, centra con la mia abissale ignoranza.
P.S. le tempeste di ACK consistono nell' improvviso aumento di pacchetti ACK
vuoti inviati dalla macchina che ha dovuto riggettare il pacchetto
desincronizzato?


Proviamo un' attimo a resettare il thread, così mi mandi definitivamente a
quel paese.
Supponiamo che io mi sia collegato con una banca(non esistono vero?) dove ho
il conto, per fare dei movimenti; un fetentone per mettersi in mezzo prima
forza la comunicazione  tra me e la banca in uno stato di desincronizzazione
e poi si mette ad acchiappare i pacchetti riggettati dal(posso dire server?)
della banca manco fosse babbonatale il 25 dicembre. Ilserver della banca
riggetta i pacchetti ovviamente perchè hanno il numero  sequenza sbagliato.
Babbo Natale intanto(con lo sniffer immagino) scarta i pacchetti riggettati,
e poi che ci fà?.Li modifica, ci attacca qualcosa e li rimanda al server con
stavolta il numero di seq corretto?, se li magna?, li offre agli amici?
l' ignoranza genera le cazzate
le cazzate generano fastidio
il fastidio genera violenza
la violenza mi genererà lunghi giorni di ricovero, già lo sò.

--
insomma da quello che dite il dirottamento TCP(ho detto un' altra cazzata?)
non č qualcosa di cui
preoccuparsi realmente a meno di non essere nel mirino della CIA o della
mafia.
Per farmi perdonare delle cazzate dette vi invito a cena tutti e tre, a
patto
che le mazza da baseball le lasciate fuori dalla porta(penso io pure alle
donne)
attento d'Itri che a rispondermi rischi che Serni ed invy ti tolgano il
saluto hihihihi

 cose di sicurezza in relazione ad ambienti Object Oriented?
hmm direi non sia il mio campo. intendi tipo lasciar sfuggire
permessi o buchi durante eredita' e polimorfismi ? al momento gli studi
migliori derivano dall'approccio alla sicurezza del java team. ti conviene
cominciare da quelle pagine web che ne trattino. 


 istituzionali.
perfettamente d'accordo.


 desincronizzato?
quando lo stato e' desincronizzato una delle due parti risponde ad un
pacchetto 'errato' con i numeri di sequenza attesi usando il PROPRIO
numero. Ma questo sara' errato per la parte desincronizzata che quindi
mandera' una ACK con i 'suoi' numeri che saranno pero' errati .... :)
Teoricamente un loop per OGNI pacchetto. Linux invece determina una morte
annunciata per tali storm mediante un timeout basato sul rate di pacchetti
errati: tanti piu' sono tanto prima muoiono, dimunendo l'entita' della
storm.
Nota che questo e' il tipico segno dell'hijack senza man-in-the-middle
trasparente e NON c'entra con lo spoofing classico (se non per
l'implementazione dell'attacco in se)


 saluto hihihihi
e xche' mai ?! a me piacciono le risposte di marco :)


 l' ignoranza genera le cazzate
genera semre domande. sta a te fare in modo che non generi SOLO quelle ...


 Se la risposta è si allora non ho capito niente:)
Per canale sicuro non si intende sempre la rete, puoi anche consegnare di
persona un biglietto con la chiave a chi la deve conoscere, chiaramente
potrebbe sempre esserci un ninja travestito da appendiabiti pronto a spiare
il contenuto del biglietto.
Non esiste niente di sicuro al 100% nella sicurezza in rete.
-- 
--
Punk' s not dead!

 donne)
Ma da quel che ho capito, le mazze da baseball erano riservate agli
amministratori di 1000 pc... quindi dovresti stare tranquillo :-)))
Ciao, Max.
-- 
Emma for President: 
http://www.emmaforpresident.it/
--ICQ: 14816698---Campagna NOTUT: 
http://www.notut.cjb.net-----
Home Pages: 
http://www.agora.stm.it/M.Baldinelli/home.htm
 
http://www.tifonet.it/free/ancona/index.html
 
M.Bald...@agora.stm.it
---------------------------------------------------------------