Newsgroup: it.comp.sicurezza.varie
Titolo: Attenzione alla condivisione file

Possibile che esistano in giro tanti PC con win95 o winNT collegati a
Internet e con la condivisione attivata e *senza* password?
Facendo una ricerca sistematica (non sto a descrivere i dettagli) solo
sugli IP address collegati al mio stesso nodo (saranno mediamente 50)
trovo sempre almeno un paio di PC in cui posso leggere/scrivere
l'intero disco C !!!
Inoltre usando winNT o win95+winsock2 non serve neanche sniffare il
nome netbios della macchina target, basta scrivere \\123.456.789.123
----------------------------------------------------------------------
Marco Coletti
Network Administrator, Webmaster, Computer Consultant
PGP public key:
http://keys.pgp.com:11371/pks/lookup?op=get&exact=on&search=0x96A79061
Fingerprint: 9F E5 80 61 F6 9F 05 2D  EA 53 6F 2D 82 8B C7 C2
----------------------------------------------------------------------

 l'intero disco C !!!
I migliori alleati dei cracker sono gli utenti sprovveduti, questo
e' noto ed e' una regola aurea.
Un'altra regola aurea della sicurezza e' che la sicurezza non e' mai
un valore assoluto: e' sempre un bilancio tra il valore di cio' che
si protegge e lo sforzo necessario per violare un sistema.
Cio' che "salva" costoro e' che sulle loro macchine non hanno niente
che "valga qualcosa". Questo ovviamente finche' qualche cretino non
decide di fare loro uno scherzo "tanto per il gusto di farlo", e poi
piangono.
Ciao,
-- 
Andrea


Scusa, magari è una Ca...ta, ma se nei bindings la"Condivisione file e
stampanti non è legata a TCP/IP, ma usa un altro protocollo (Netbeui)
non dovrebbe essere possibile accedere a niente, o no?
e questo e tutto
rimuovi -xxx- per rispondermi

non dovrebbe essere possibile accedere a niente, o no?
Esatto.
Credo che pero' continui a funzionare
  nbtstat -A 123.124.125.126
dove 123.124.125.126 e' l'IP address del PC che ha il binding
TCP/IP-Server disattivato.
Con questo comando si reperisce pur sempre qualche info utile
all'hacker, come nome della macchina, nome del dominio, nome
dell'utente loggato...
Per chiudere anche questa minuscola porta bisogna togliere la crocetta
da "...NetBios over TCP/IP".

 da "...NetBios over TCP/IP".
Grazie per le info !
Io ho provato a spuntare la suddetta casella nella finestra
RETE/Proprietà/TCP-IP , ma è "completamente grigia", ovvero non ho modo
di deselezionarla. E' selezionata e sottratta ad un mio intervento. Come
posso fare ? Uso Win95B. Grazie mille !
-- 
                    ~~~~~~  Morfeo  ~~~~~~
       -------------------------------------------------
       |"Entia non sunt multiplicanda sine necessitate"|
       |                             (G. di Ockham)    |   
       |   --PGP Public Key available on request----   |
       -------------------------------------------------

di deselezionarla. E' selezionata e sottratta ad un mio intervento. Come
Si vede che nella scheda adiacente (quella dei binding) c'e' ancora un
qualche binding che coinvolge il NetBios e quindi win95 non ti lascia
accedere alla casella suddetta finche' non disattivi anche tale
binding.


nome netbios della macchina target, basta scrivere \\123.456.789.123
??? Questa, non la sapevo. Sapevo che la directory SYSTEM e' accessibile a
sbafo tramite condivisione stampanti. Se ne impara sempre una nuova. E, di
solito, peggiore :-(
Leonardo
".signature": bad command or file name

l'intero disco C !!!
scusa,  ma stai parlando di una lan o di accessi remoti ?
Se win95 non ha un daemon di login come ci si puo' connettere da remoto ?

Se win95 non ha un daemon di login come ci si puo' connettere da remoto ?
Non si tratta di telnet o rlogin ma di SMB (cioe' condivisione file
secondo il protocollo di Microsoft).  Non porte TCP 23 o 513 ma porta
TCP 139.
Insomma: mica c'e' scritto da nessuna parte che i file si possono
condividere solo su LAN !!


solito, peggiore :-(
Si', la faccenda \\222.222.222.222 era una delle features sbandierate
quando e' uscito NT 4, ma mi sono improvvisamente accorto che adesso
funziona anche sul mio win95 OSR2 e ho dedotto che cio' dipende dal
fatto che ho installato l'update a winsock 2.0.
In mancanza della feature \\222.222.222.222 per vedere una risorsa via
Internet (quindi niente broadcast) era necessario inserire nel file
LMHOSTS il nome NetBIOS del target (diciamo PINCO, che si puo'
ottenere con "nbtstat -A 222.222.222.222") e poi usare \\PINCO.
Non ho mai sentito quella della SYSTEM e stampanti... come funziona?


Scusa se mi intrometto...
    il tuo msg mi ha giustamente preoccupato...Ho provato a fare come dici
tu ed è estremamente facile entrare nel disco di un altro.
Ho allora provato a disattivare Netbios per TCP/IP, ma non so se è
sufficiente: sul mio indirizzo IP io riesco a rientrare via Explorer.
Sbaglio a pensare che anche da fuori sia altrettanto semplice?
Come si attiva la password per un utente che si connette in rete? Tranite lo
User Manager -> Guest?
Grazie
    Giulio
P.S. Per la paura, da questo momento disconnetto tutto, ma durante il giorno
io lavoro in un ufficio dove è necessario mantenere alcune risorse
condivise...
Che succederà se mi connetto ad Internet allora?

Non ho mai sentito quella della SYSTEM e stampanti... come funziona?
Bene, funziona: se hai una stampante 'offerta' in rete, c'e' una share
nascosta, PRINTER$, che equivale alla tua C:\WINDOWS\SYSTEM. Di norma,
e' accessibile in sola lettura per far installare i drivers ad altri.
Ma TUTTI i files sono leggibili, e (si dice) ciappinando abbastanza ed
avendo un smbclient apposito, si puo' avere ugualmente un accesso pure
in scrittura. Microsoft indirettamente ha confermato la cosa, dicendo,
se non ricordo male, che cio' e' dovuto ad un difetto del CLIENT e non
del server (cosa che a me pare assurda, ma tant'e').
A me e' venuto comodo una volta sola, quando mi sono accorto che dalla
stampante di rete lpr-ata sotto Linux non c'era modo di installare per
Windows un driver "vero" (AdobePS12_qualcosa) ma solo l'ADOBEPS.DRV di
serie, che ovviamente funzionava male (non era neanche il suo). Pero',
non c'e' modo di dire "SI', c'e' un driver, e' sul PC tale, prendilo";
va installato a mano... ma sul PC 'sorgente' la share era disattivata,
perche' la stampante sulla parallela era diventata un'altra... 8-(
Leonardo e un incubo ora finito, grazie a Dio


Se win95 non ha un daemon di login come ci si puo' connettere da remoto ?
Perche' alcuni Windows di serie installavano la "condivisione". Non esiste
un daemon di login su Windows 95, non di serie, ma Win 95 si comporta, per
certi versi, come un server NFS.
Leonardo


User Manager -> Guest?
Quando condividi una cartella hai tutte le opzioni del caso per farla
vedere solo a chi vuoi tu...


del server (cosa che a me pare assurda, ma tant'e').
E' chiaro che la debolezza e' nel server... forse Microsoft pensa che
solo lei e' capace di scrivere dei SMB clients?


solo lei e' capace di scrivere dei SMB clients?
Be', di sicuro c'e' che (anche non avendo una password), il PC da remoto
lo si puo' inchiodare con nove righe di Perl: il server Microsoft non fa
controlli su quanta roba arriva, in fase di handshake. Questo l'ho letto
un mese o due fa, ed era vero, allora; non so se MS abbia rilasciato una
patch nel frattempo.
Di regola, QUASI OVUNQUE, se un server Microsoft chiede dei dati, NON FA
controlli su quanta roba gli si manda. O i controlli sono fatti da cani;
per esempio, il counter.dll di Personal Web Server controlla che uno non
mandi kilate di testo alfabetico per farlo esplodere ma non fa controlli
sulla quantita' di CIFRE inviate... e poco sopra il fantastiliardo, ecco
che arriva la morte azzurra 8-(
Tra l'altro, se qualcuno dei presenti ha montato la patch VIPUPD, contro
il nuking da remoto, e ha anche una rete Samba... SMBMOUNT, gli funziona
ancora? A me no. Sono stato costretto ad invertire la patch, ed a tenere
i PC con il culetto alle intemperie, perche' purtroppo mi serve SMBMOUNT
piu' di quanto mi serva un IP piu' solido.


spuntate (default) che rischi corro ?
Relativamente pochi, dal punto di vista del furto dei dati. E' sempre
possibile inchiodare la macchina da remoto; l'ho visto fare a qualche
tizio che tenta di buttare giu' l'intera subnet del POP internet, per
avere per se' solo tutta la banda.
Poi ultimamente m'e' arrivato qualche pacchetto strano da un host che
si connette da Verona via TIN (tentativo di connessione telnet e nuke
Windows; non so se sia la stessa persona o due separate).
Tutto sommato penso convenga tenersi aggiornati al massimo e su tutte
le patches di Microsoft (
www.microsoft.com/software/da_quelle_parti
).
Mi spiace di non avere altri dati ma di solito non e' che passo tanto
tempo a cercare di entrare nel mio stesso computer dall'esterno 8-) a
meno che non stiano succedendo stranezze sulla rete, come adesso (*)
Leonardo
(*) Qualcuno sa di bugs in una stampante Apple LaserWriter 16/600? Ad
    intervalli irregolari quella p**** va in timeout di rete e pianta
    qualsiasi Windows box tenti di stampare. Con la rete isolata 8-(


 ".signature": bad command or file name
No, ma ho avuto delle stampanti viste dal chooser (Mac -> Scelta
Risorse, per chi non sa), che non appena rese visibili sotto NT, sono
sparite dal chooser.
Non so se c'e una correlazione... in ogni caso, sono i miei 2 cents...
Ciao,
-- 
      Ermanno Polli   (INFN-LNF)
    user:      hostname:  subdomain:  domain:  country:
ermanno.polli    N/A        lnf         infn     it

sparite dal chooser.
Intravedo un nesso. Sulle Apple stampano sia Mac che Win. La Apple non
rilascia dettagli su quale protocollo usino i Mac per stampare da rete
(dubito sia LPR), pero' ho visto che Mac + LPR = tutto bene, mentre se
faccio Mac + Win = saltuario hang.
Non vorrei (improvviso dubbio!) che in certe condizioni Windows scordi
di chiudere il socket. Pero' allora dovrebbe andare in timeout sempre,
basta che ci sia una rete Win... Mumble.
Ma mi hai dato un'idea: domani vado di portscanner su quelle maledette
Apple. Hai visto mai ci fossero delle porte di servizio. E se le trovo
guardo come si comportano prima e dopo i timeouts.
Leonardo


 faccio Mac + Win = saltuario hang.
Non rilascia dettagli ?
Veramente se ti interessa ho le specifiche del protocollo EtherTalk
fino all'ultimo bit (EtherTalk = AppleTalk su trasporto Ethernet), 
poi le specifiche del protocollo di comunicazione delle Laserwriter
su AppleTalk.
Quando vuoi fammi un fischio che controllo cosa e' "restricted" e
cosa in pubblica distribuzione e poi ti floddo la mailbox con una
gigata di .pdf ;)
Con un portscan non ci fai niente, non usano IP.
Ritengo verosimile che, poiche' le LW dell'ultima generazione supportano
Win con i suoi protocolli, il citato EtherTalk per i Mac, lpr su IP per
Unix e non so che altro si impalli per qualche motivo l'autoswitch del
protocollo (l'ipotesi del socket lasciato aperto non mi pare 
inverosimile).
Ciao,
-- 
Andrea

L.S...@agora.stm.it
 wrote:
 >Non vorrei (improvviso dubbio!) che in certe condizioni Windows scordi
 >di chiudere il socket. Pero' allora dovrebbe andare in timeout sempre,
tcpdump is your friend.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

inverosimile).
Lo strano e' che una LW 12/640 va OK. La 12/640 e' venuta prima della
16/600, o dopo? Quale dei due numeri conta? 8-D (Esistono upgrades di
firmware?)
Leonardo ignorante crasso


tcpdump is your friend.
Fammi capire bene: io dico a tutti i catrami 95 che la linux box e' il
loro gateway. Poi al Linux dico
tcpdump -l dst host 192.168.0.202
e questo fa si' che tutta la roba diretta al .202 finisca su stdout.
Per gli Applisti: quando dico che la stampante va in "timeout" intendo
che mi sputa fuori un foglio bianco con su scritto "Error: timeout" ed
un dump dello stack PostScript. Dalle ultime prove, succede anche solo
se ci sono SOLTANTO Windows 95 a stampare.
Facendo un portscan (mi avete avvertito troppo tardi che non serviva!)
sulla stampante, succede una cosa misteriosissima: appena un PC tenta,
leggasi "tenta", di accedere alla stampante dal Pannello, si pianta. E
piantato rimane finche' non spengo e riaccendo la stampante. Non funge
neanche CTRL-ALT-DEL (anche se, premuto due volte, resetta bene).
In questa situazione, anche lpr rimane bloccato, abortendo dopo trenta
secondi circa senza segnalare niente (non ho pero' opzioni di debug).
Come DoS non c'e' male 8-| (e pensare, che mi ero opposto alla scatola
per networkizzare ;-) le stampanti perche' fonte di DoS e problemi: lo
avevo trovato scritto sulla BT. Proprio vero, il destino non si ferma)
Leonardo "io quasi quasi cambio semplicemente le stampanti 8-)"


 ".signature": bad command or file name
Ciao,
-- 
      Ermanno "io quasi quasi butto windows 95/NT" Polli (INFN-LNF)


L.S...@agora.stm.it
 wrote:
 >Fammi capire bene: io dico a tutti i catrami 95 che la linux box e' il
 >loro gateway. Poi al Linux dico
No, tu metti sul segmento dove c'e` la stampante una linux box e poi
sniffi tutto quello che e` diretto alla stampante.


Forse mi puoi aiutare,
ho letto il tuo msg e, figurati beata ignoranza, non sapevo neanche che
fosse possibile condividere le risorse via tcp/ip.
A prescindere dagli aspetti negativi legati alla sicurezza sui quali tu,
giustamente, hai posto l'accento, la cosa mi è sembrata interessante. Ho
provato allora condividere l'hd di un amico con il quale mi ero
accordato. Tutti e due collegati ad internet tramite accesso remoto e
con win 95 b.
Quando provo con nbtstat ad avere il nome dell'host per mezzo dell'ip mi
dice HOST NOT FOUND...
Ho installato winsock 2 ed ho provato a mettere direttamente l'ip come
suggerivi... ma non me lo trova ugualmente..
 dove sbaglio?
Grazie
Luigi
--
Automatic posted from 
siti1.regione.toscana.it
 [159.213.32.229]
via Mailgate Server - 
http://www.mailgate.org

suggerivi... ma non me lo trova ugualmente..
I motivi possono essere tanti.
Per esempio puo' darsi che il tuo ISP filtri i pacchetti SMB (porta
139).
Tanto per cominciare verifica se riesci a collegarti sulla porta 139
del tuo amico:
  telnet 222.222.222.222 139
Accertati che sia tu che il tuo amico abbiate attivato le cose
seguenti nelle proprieta' del protocollo TCP/IP:
- binding TCP/IP-condivisione
- binding TCP/IP-client
- NetBIOS su TCP/IP


dice HOST NOT FOUND...
Con Windows 95, credo che tu debba essere nella stessa sottorete. Questo
immagino significhi semplicemente che dovete accedere allo stesso POP di
un medesimo provider.
Leonardo


L.S...@agora.stm.it
 wrote:
 >Con Windows 95, credo che tu debba essere nella stessa sottorete. Questo
 >immagino significhi semplicemente che dovete accedere allo stesso POP di
 >un medesimo provider.
No, i broadcast non passano via ppp... :-)
(A meno di non configurare esplicitamente il terminal server per farlo, ma
non e` questo il caso.)


non e` questo il caso.)
E' ovviamente vero che i pacchetti IP broadcast non passano via terminal
server.
Pero' su win95/NT nbtstat non ha bisogno ne' di broadcast ne' di essere nello
stesso IP network.  Basta fare la prova con un qualsiasi host NT che stia
dall'altra parte dell'Atlantico (tanto per essere sicuri).
Anche la condivisione file si puo' ottenere via Internet dal mio PC al PC di un
utente australiano (quindi niente broadcast e niente IP network in comune).
Il network comune servirebbe su una LAN per far arrivare i pacchetti broadcast
in modo che funzioni SMB, in mancanza di un server WINS.
Se pero' si stabilisce a priori la corrispondenza tra il nome e l'IP address
del PC target (inserendo tale informazione nel file \windows\lmhosts), allora
non c'e' piu' bisogno di broadcast ne' di WINS.  Inoltre con winsock2 si puo'
usare direttamente l'IP address al posto del nome; immagino che winsock2 non
faccia altro che eseguire un simil-nbtstat preventivo.
----------------------------------------------------------------------
Marco Coletti
Network Administrator, Webmaster, Computer Consultant
PGP public key:
http://keys.pgp.com:11371/pks/lookup?op=get&exact=on&search=0x96A79061
finger://
mail.eurofin.it/marco.coletti


non c'e' bisogno?
Se non vuoi farlo ripartire, devi fare
  nbtstat -R
per fare si' che il sistema si rilegga il file lmhosts.
Poi magari puoi fare anche
  nbtstat -c
per controllare che adesso il nome che hai inserito nel file suddetto compaia
nella cache NetBIOS.
