Seph|rotH
2004-09-16 22:33:21 UTC
Crossoposto pure su ms.pub.it.sicurezza, visto che l'attinenza mi sembra
notevole.
Struttura sommaria della rete in oggetto:
SERVER:
Sede principale:
1 PDC Win 2k AS SP3 (dominio padre disney.local)
2 altri DC Win 2k AS SP4 in Load Balancing
5 sedi periferiche:
1 DC Win 2K (SP vari) ognuno (domini figli: paperino.disney.local,
topolino.disney.local, pippo.disney.local, paperone.disney.local,
pluto.disney.local).
CLIENT:
misti, 50% Win 2k Pro, 45% Win XP Pro, 5% Win 95/98
ALTRO:
Firewall Cisco Pix 525 in sede centrale + router vari, antivirus eTrust
IncoulateIT su TUTTE le macchine, autoaggiornato tutti i giorni.
Un simpatico venerdì mattina di fine agosto (il 27) improvvisamente alcune
macchine della sede principale e di quella SOLTANTO (soprattutto win 2k,
capirete più tardi il perchè di questa precisazione) lamentano dei problemi
di lentezza spaventosi: un'indagine sommaria mette immediatamente in luce il
fatto che il processore delle suddette è al 100%. Poco male, reboot. Qualche
macchina smette di dar problemi, qualcuna no. Controllo anche i server, che
improvvisamente danno una segnalazione DCOM ogni minuto. In pratica, saddio
perchè, mi ritrovo a dover utilizzare il dcomcnfg.exe e a dare il permesso a
everyone di eseguire documenti word (il DCOM interessato era relativo ai
documenti word). Gli errori sui server spariscono e il problema sui client
sembra ridursi, ma non scompare.
Un'analisi più approfondita mi fa scoprire che anche nell'event viewer dei
client colpiti c'è questo errore DCOM sui documenti word e che il processo
che tiene a palla la cpu è uno dei tanti svchost.exe. In alcuni casi riesco
a terminare il processo manualmente riportando la cpu a livelli normali,
causando però talvolta un reboot della macchina col conto alla rovescia (a
mo di blaster, sasser o quel che era). Ma il problema permane, soprattutto
per le macchine 2000 che sono totalmente inchiodate (quelle XP pur nella
lentezza riescono cmq a lavorare). Faccio il solito giro in modalità
provvisoria e passo l'antivrus: non ci sono virus. Ottimo. Riavvio in
modalità normale e dopo qualche minuto di attività l'svchost sale di nuovo
al 100%. Cercando su google scopro che esiste una sorta di task manager più
avanzato (procexp o una roba del genere) che permette di vedere i
sottoprocessi dei processi del task manager. Lo scarico e lo eseguo sulle
macchine con problemi.
Scopro che il sottoprocesso che manda l'svchost al 100% è sempre l'rpcss.
Cerco qualche soluzione sul sito di M$, qui dentro e su google ma non si
risolve nulla. Scopro tuttavia, sempre tramite il task manager avanzato di
cui sopra, che l'rpcss è mandato in botta da due connessioni TCP che la
macchina in questione apre inspiegabilmente con altre macchine della rete
sulla porta 135. Tutto sembra far pensare al blaster o ad una sua variante,
ma c'è qualcosa che non torna: i server sono patchati, il firewall è più
chiuso di una vergine con la cintura di castità e soprattutto il blaster è
dell'anno scorso: come mai spunta adesso? Una nuova variante non segnalata
da nessuno? Metto patch sui client per qualunque cosa, sasser, blaster,
mydoom, ma non cambia nulla. Tuttavia, terminando quelle connessioni TCP
"strane", il processore torna alla normalità e la gente può lavorare come
prima. Ok, non sappiamo cosa sia ma almeno riusciamo a tamponare il
problema. Ci sono altri errori negli event viewer dei client, qualcuno l'ho
postato qui, se cercate i post a nick Seph|rotH li trovate, ma senza
ricevere aiuto (non incolpo nessuno, ci mancherebbe, è solo una
constatazione).
Passa il weekend, inizia una nuova settimana. Il problema sembra sparire
quasi del tutto, in compenso su alcune macchine (stavolta quasi solo XP),
iniziano a comparire degli errori del sottosistema ms-dos a 16bit, causati
da eseguibili nuovi, tutti residenti sulla root C: dei PC e coi nomi troppo
strani per non far pensare a un virus o una roba del genere. Non provocano
nulla se non fastidio visivo, ma non è normale. E' probabilmente "una roba
del genere", visto che ancora una volta l'antivirus dice che è tutto OK.
Ancora una volta cerco in rete senza troppi risultati. Comunque cancellando
questi eseguibili, i messaggi spariscono e gli stessi cmq non si ricreano al
reboot. Sempre più mistero. Penso a sto punto ad uno spyware o a roba del
genere. In effetti, guardando nel solito
hkey_local_machine\software\microsoft\windows\currentversion\run delle
macchine con problemi, noto una simpatica riga "ioroxxo microsoft sux" che
mi fa partire un file chiamato svichost.exe (notare la i). La stessa è
presente pure in \runasservice.
Termino gli eseguibili, faccio passare HijackThis e elimino le chiavi di
registro. OK, almeno in apparenza. cerco qualcosa di sto ioroxxo in rete, ma
non c'è nulla, tranne un accenno a uno spyware del tardo neolitico. Scopro
però che ci dovrebbe essere un'altra riga incriminata nel \run registro: una
voce Microsft MSN Messenger associata ad un'eseguibile che si chiama
"msnmessenger.exe". Peccato che l'eseguibile del Messenger sia msnmsg.exe (o
una roba del genere). In effetti c'è. Termino pure questo eseguibile,
rilancio HijackThis, rimuovo le stringhe maffe dai PC che avevano i problemi
di cui sopra. Pur continuando a non avere idea nè di cosa sia sta cosa nè di
come sia finita sulle macchine della rete, anche in questo caso riesco a
tapullare.
Il tempo passa, macchine che vanno al 100% non ce n'è praticamente più (e io
resto perlesso), però sta cosa dello ioroxxo si espande subdolamente e
incontrollata a direi 8/10 delle macchine. Arriviamo all'inizio di questa
settimana: una sede esterna, tipo pluto.disney.local. ha dei client che
manifestano dei problemi di stampa. Mi collego in remoto e faccio le solite
prove (pagina di prova, riavvio del servizio di spool, pulizia della
cartella di spool) senza successo. E' qui che scopro che inspiegabilmente le
macchine di pluto non riescono più a sfogliare la rete da risorse di rete,
con un messaggio "server non configurato per le transazioni". Strano, anche
perchè le mappature al server e i programmi continuano a funzionare come se
niente fosse.
Intanto, ricevo una chiamata dalla sede pippo.disney.local: una macchina win
98 non riesce più a entrare in rete, rifiutando la password. Ovviamente un
reset della stessa non produce alcun effetto. Pure dalle macchine di quella
sede risulta impossibile sfogliare la rete. Qui la situazione è più pesante,
perchè le macchine 98 sono ben più di una e alcuna ha il disco condiviso con
altre, che ovviamente risulta pur'esso irraggiungibile. Dopo la solita
ricerca su google scopro che la soluzione più gettonata è provare a rifare
la net share dell'IPC$ che non si sa bene perchè (LOL) talvolta scompare dai
server/client. In effetti sui server coinvolti è sparita, ma da quando la
rimetto a quando riscompare passa sì e no un minuto scarso. Intanto il
problema dello sfoglia rete si espande a tutti i domini figli: stavolta gli
unici "immuni" siamo noi della sede centrale.
Oggi: viene in sede la persona esterna che si occupa di manutenere i router
e il firewall. Si logga al router principale e, sorpresa, la cpu è quasi
sempre al 100%. Un'analisi sommaria del traffico rivela un'attività di
broadcastig devastante da parte di un buon numero di client nostri verso una
serie abnorme d indirizzi, sia intranet che extranet. E' storming massiccio.
Stessa cosa sui router delle sedi distaccate. Ci occupiamo prima della sede
principale, isolando i router esterni e segnandoci gli IP delle macchine
della sede principale (disney) che fanno traffico. Mi si dice di buttarle
subito giù, ma nulla mi toglie dalla testa che il buon ioroxxo o consimili
sono coinvolti in qualche modo nel problema. L'intuizione era giusta.
Difatti, TUTTE le macchine che generano traffico hanno in esecuzione i
famosi svichost.exe e msmessener.exe. Non solo: analizzati col task manager
avanzato, scopro che sono proprio questi due eseguibili a generare questo
numero abnorme di richieste broadcast, occupando lentamente ma
inesorabilmente tutte le porte tcp/udp disponibili. Una volta buttati giù
gli .exe, l'ip in questione smette di fare storming.
Le macchine però sono troppe, come si fa? Semplice: siccome gli eseguibili
sono SEMPRE quei due, vado in active directory, edito la policy di gruppo e
impedisco l'esecuzione di quei due eseguibili (nascosti sotto la system32).
Poi faccio riavviare tutte le macchine che fanno broadcast selvaggio. Che
restano sì infette, ma quantomeno smettono di fare storming visto che i due
eseguibili dimmerda non possono più partire, a logica. La logica una volta
tanto è giusta. Il traffico su disney torna normale e posso mettermi a
pulire le macchine con più tranquillità. I passaggi sono: HiJackThis (non
c'è più bisogno di stoppare gli eseguibili), chiavi di registro,
cancellazione eseguibili, reboot. Dopo il reboot, le stringhe e gli .exe non
ricompaiono (almeno per ora).
Le sedi esterne, però, sono ancora nel dramma. Lentissimamente entro nel
regedit sui server remoti, per scoprire che... lo ioroxxo non c'è. In
compenso, sempre sotto /run e /runasservice, è comparsa una stringa chiamata
Windows Compliant, che è legata ad un eseguibile, diverso per ogni macchina
(O_O). Uno di questi è winole.exe, che scopro sul sito symantec essere parte
di una sorta di virus/trojan, che però è veramente vecchierrimo e non causa
cmq i problemi che causa questo eseguibile. Anche molti client esterni hanno
questa stringa Windows Compliant, però il nome dell'eseguibile è diverso.
Anche in questo caso un'analisi col task manager avanzato mi dice che sti
eseguibili generano broadcast peggio di una macchina dei popcorn. Modifico
anche qui le policy inibendo e pulendo tutti gli eseguibili che trovo man
mano e la situazione finalmente migliora anche se il problema è che le
macchine 98 sono immuni della policy e quindi continuano a broadcastare. Le
puliamo una a una. L'IPC$ finalmente tiene (andava via perchè c'era troppo
traffico, probabilmente) e lo sfoglia rete rifunziona.
A qeusto punto il giro è chiaro: eseguibile-broadcast selvaggio-porte
saturate-IPC$ che crolla-rete impossibile da sfogliare con macchine 98 che
non si autenticano più/problemi di stampa.
Domani ci saranno ancora un sacco di macchine da pulire e la domanda, per
chi ha avuto la pazienza di arrivare fin qui dopo tutto questa pappardella
ovviamente è: cos'è successo, secondo voi? Come può uno spyware causare una
roba del genere? E se è un virus, è talmente nuovo che nessuno ne ha
notizia? Com'è arrivato così in profondità? E basterà pulire le macchine una
volta o si ripresenterà tra qualche tempo? Non possiamo mica fare il giro
giornaliero di tutti i client per verificare che siano a posto.
Commenti? Idee? Soluzioni? A qualcuno è successo qualcosa di simile?
Grazie. Anche solo di aver letto tutto.
Spero quantomeno che se tra una settimana/mese/anno qualcuno farà una
ricerca su google perchè afflitto da un delirio simile, trovi in questo post
almeno una serie di tappulli efficaci da applicare velocemente.
Vi terrò aggiornati. :D
Cla.
notevole.
Struttura sommaria della rete in oggetto:
SERVER:
Sede principale:
1 PDC Win 2k AS SP3 (dominio padre disney.local)
2 altri DC Win 2k AS SP4 in Load Balancing
5 sedi periferiche:
1 DC Win 2K (SP vari) ognuno (domini figli: paperino.disney.local,
topolino.disney.local, pippo.disney.local, paperone.disney.local,
pluto.disney.local).
CLIENT:
misti, 50% Win 2k Pro, 45% Win XP Pro, 5% Win 95/98
ALTRO:
Firewall Cisco Pix 525 in sede centrale + router vari, antivirus eTrust
IncoulateIT su TUTTE le macchine, autoaggiornato tutti i giorni.
Un simpatico venerdì mattina di fine agosto (il 27) improvvisamente alcune
macchine della sede principale e di quella SOLTANTO (soprattutto win 2k,
capirete più tardi il perchè di questa precisazione) lamentano dei problemi
di lentezza spaventosi: un'indagine sommaria mette immediatamente in luce il
fatto che il processore delle suddette è al 100%. Poco male, reboot. Qualche
macchina smette di dar problemi, qualcuna no. Controllo anche i server, che
improvvisamente danno una segnalazione DCOM ogni minuto. In pratica, saddio
perchè, mi ritrovo a dover utilizzare il dcomcnfg.exe e a dare il permesso a
everyone di eseguire documenti word (il DCOM interessato era relativo ai
documenti word). Gli errori sui server spariscono e il problema sui client
sembra ridursi, ma non scompare.
Un'analisi più approfondita mi fa scoprire che anche nell'event viewer dei
client colpiti c'è questo errore DCOM sui documenti word e che il processo
che tiene a palla la cpu è uno dei tanti svchost.exe. In alcuni casi riesco
a terminare il processo manualmente riportando la cpu a livelli normali,
causando però talvolta un reboot della macchina col conto alla rovescia (a
mo di blaster, sasser o quel che era). Ma il problema permane, soprattutto
per le macchine 2000 che sono totalmente inchiodate (quelle XP pur nella
lentezza riescono cmq a lavorare). Faccio il solito giro in modalità
provvisoria e passo l'antivrus: non ci sono virus. Ottimo. Riavvio in
modalità normale e dopo qualche minuto di attività l'svchost sale di nuovo
al 100%. Cercando su google scopro che esiste una sorta di task manager più
avanzato (procexp o una roba del genere) che permette di vedere i
sottoprocessi dei processi del task manager. Lo scarico e lo eseguo sulle
macchine con problemi.
Scopro che il sottoprocesso che manda l'svchost al 100% è sempre l'rpcss.
Cerco qualche soluzione sul sito di M$, qui dentro e su google ma non si
risolve nulla. Scopro tuttavia, sempre tramite il task manager avanzato di
cui sopra, che l'rpcss è mandato in botta da due connessioni TCP che la
macchina in questione apre inspiegabilmente con altre macchine della rete
sulla porta 135. Tutto sembra far pensare al blaster o ad una sua variante,
ma c'è qualcosa che non torna: i server sono patchati, il firewall è più
chiuso di una vergine con la cintura di castità e soprattutto il blaster è
dell'anno scorso: come mai spunta adesso? Una nuova variante non segnalata
da nessuno? Metto patch sui client per qualunque cosa, sasser, blaster,
mydoom, ma non cambia nulla. Tuttavia, terminando quelle connessioni TCP
"strane", il processore torna alla normalità e la gente può lavorare come
prima. Ok, non sappiamo cosa sia ma almeno riusciamo a tamponare il
problema. Ci sono altri errori negli event viewer dei client, qualcuno l'ho
postato qui, se cercate i post a nick Seph|rotH li trovate, ma senza
ricevere aiuto (non incolpo nessuno, ci mancherebbe, è solo una
constatazione).
Passa il weekend, inizia una nuova settimana. Il problema sembra sparire
quasi del tutto, in compenso su alcune macchine (stavolta quasi solo XP),
iniziano a comparire degli errori del sottosistema ms-dos a 16bit, causati
da eseguibili nuovi, tutti residenti sulla root C: dei PC e coi nomi troppo
strani per non far pensare a un virus o una roba del genere. Non provocano
nulla se non fastidio visivo, ma non è normale. E' probabilmente "una roba
del genere", visto che ancora una volta l'antivirus dice che è tutto OK.
Ancora una volta cerco in rete senza troppi risultati. Comunque cancellando
questi eseguibili, i messaggi spariscono e gli stessi cmq non si ricreano al
reboot. Sempre più mistero. Penso a sto punto ad uno spyware o a roba del
genere. In effetti, guardando nel solito
hkey_local_machine\software\microsoft\windows\currentversion\run delle
macchine con problemi, noto una simpatica riga "ioroxxo microsoft sux" che
mi fa partire un file chiamato svichost.exe (notare la i). La stessa è
presente pure in \runasservice.
Termino gli eseguibili, faccio passare HijackThis e elimino le chiavi di
registro. OK, almeno in apparenza. cerco qualcosa di sto ioroxxo in rete, ma
non c'è nulla, tranne un accenno a uno spyware del tardo neolitico. Scopro
però che ci dovrebbe essere un'altra riga incriminata nel \run registro: una
voce Microsft MSN Messenger associata ad un'eseguibile che si chiama
"msnmessenger.exe". Peccato che l'eseguibile del Messenger sia msnmsg.exe (o
una roba del genere). In effetti c'è. Termino pure questo eseguibile,
rilancio HijackThis, rimuovo le stringhe maffe dai PC che avevano i problemi
di cui sopra. Pur continuando a non avere idea nè di cosa sia sta cosa nè di
come sia finita sulle macchine della rete, anche in questo caso riesco a
tapullare.
Il tempo passa, macchine che vanno al 100% non ce n'è praticamente più (e io
resto perlesso), però sta cosa dello ioroxxo si espande subdolamente e
incontrollata a direi 8/10 delle macchine. Arriviamo all'inizio di questa
settimana: una sede esterna, tipo pluto.disney.local. ha dei client che
manifestano dei problemi di stampa. Mi collego in remoto e faccio le solite
prove (pagina di prova, riavvio del servizio di spool, pulizia della
cartella di spool) senza successo. E' qui che scopro che inspiegabilmente le
macchine di pluto non riescono più a sfogliare la rete da risorse di rete,
con un messaggio "server non configurato per le transazioni". Strano, anche
perchè le mappature al server e i programmi continuano a funzionare come se
niente fosse.
Intanto, ricevo una chiamata dalla sede pippo.disney.local: una macchina win
98 non riesce più a entrare in rete, rifiutando la password. Ovviamente un
reset della stessa non produce alcun effetto. Pure dalle macchine di quella
sede risulta impossibile sfogliare la rete. Qui la situazione è più pesante,
perchè le macchine 98 sono ben più di una e alcuna ha il disco condiviso con
altre, che ovviamente risulta pur'esso irraggiungibile. Dopo la solita
ricerca su google scopro che la soluzione più gettonata è provare a rifare
la net share dell'IPC$ che non si sa bene perchè (LOL) talvolta scompare dai
server/client. In effetti sui server coinvolti è sparita, ma da quando la
rimetto a quando riscompare passa sì e no un minuto scarso. Intanto il
problema dello sfoglia rete si espande a tutti i domini figli: stavolta gli
unici "immuni" siamo noi della sede centrale.
Oggi: viene in sede la persona esterna che si occupa di manutenere i router
e il firewall. Si logga al router principale e, sorpresa, la cpu è quasi
sempre al 100%. Un'analisi sommaria del traffico rivela un'attività di
broadcastig devastante da parte di un buon numero di client nostri verso una
serie abnorme d indirizzi, sia intranet che extranet. E' storming massiccio.
Stessa cosa sui router delle sedi distaccate. Ci occupiamo prima della sede
principale, isolando i router esterni e segnandoci gli IP delle macchine
della sede principale (disney) che fanno traffico. Mi si dice di buttarle
subito giù, ma nulla mi toglie dalla testa che il buon ioroxxo o consimili
sono coinvolti in qualche modo nel problema. L'intuizione era giusta.
Difatti, TUTTE le macchine che generano traffico hanno in esecuzione i
famosi svichost.exe e msmessener.exe. Non solo: analizzati col task manager
avanzato, scopro che sono proprio questi due eseguibili a generare questo
numero abnorme di richieste broadcast, occupando lentamente ma
inesorabilmente tutte le porte tcp/udp disponibili. Una volta buttati giù
gli .exe, l'ip in questione smette di fare storming.
Le macchine però sono troppe, come si fa? Semplice: siccome gli eseguibili
sono SEMPRE quei due, vado in active directory, edito la policy di gruppo e
impedisco l'esecuzione di quei due eseguibili (nascosti sotto la system32).
Poi faccio riavviare tutte le macchine che fanno broadcast selvaggio. Che
restano sì infette, ma quantomeno smettono di fare storming visto che i due
eseguibili dimmerda non possono più partire, a logica. La logica una volta
tanto è giusta. Il traffico su disney torna normale e posso mettermi a
pulire le macchine con più tranquillità. I passaggi sono: HiJackThis (non
c'è più bisogno di stoppare gli eseguibili), chiavi di registro,
cancellazione eseguibili, reboot. Dopo il reboot, le stringhe e gli .exe non
ricompaiono (almeno per ora).
Le sedi esterne, però, sono ancora nel dramma. Lentissimamente entro nel
regedit sui server remoti, per scoprire che... lo ioroxxo non c'è. In
compenso, sempre sotto /run e /runasservice, è comparsa una stringa chiamata
Windows Compliant, che è legata ad un eseguibile, diverso per ogni macchina
(O_O). Uno di questi è winole.exe, che scopro sul sito symantec essere parte
di una sorta di virus/trojan, che però è veramente vecchierrimo e non causa
cmq i problemi che causa questo eseguibile. Anche molti client esterni hanno
questa stringa Windows Compliant, però il nome dell'eseguibile è diverso.
Anche in questo caso un'analisi col task manager avanzato mi dice che sti
eseguibili generano broadcast peggio di una macchina dei popcorn. Modifico
anche qui le policy inibendo e pulendo tutti gli eseguibili che trovo man
mano e la situazione finalmente migliora anche se il problema è che le
macchine 98 sono immuni della policy e quindi continuano a broadcastare. Le
puliamo una a una. L'IPC$ finalmente tiene (andava via perchè c'era troppo
traffico, probabilmente) e lo sfoglia rete rifunziona.
A qeusto punto il giro è chiaro: eseguibile-broadcast selvaggio-porte
saturate-IPC$ che crolla-rete impossibile da sfogliare con macchine 98 che
non si autenticano più/problemi di stampa.
Domani ci saranno ancora un sacco di macchine da pulire e la domanda, per
chi ha avuto la pazienza di arrivare fin qui dopo tutto questa pappardella
ovviamente è: cos'è successo, secondo voi? Come può uno spyware causare una
roba del genere? E se è un virus, è talmente nuovo che nessuno ne ha
notizia? Com'è arrivato così in profondità? E basterà pulire le macchine una
volta o si ripresenterà tra qualche tempo? Non possiamo mica fare il giro
giornaliero di tutti i client per verificare che siano a posto.
Commenti? Idee? Soluzioni? A qualcuno è successo qualcosa di simile?
Grazie. Anche solo di aver letto tutto.
Spero quantomeno che se tra una settimana/mese/anno qualcuno farà una
ricerca su google perchè afflitto da un delirio simile, trovi in questo post
almeno una serie di tappulli efficaci da applicare velocemente.
Vi terrò aggiornati. :D
Cla.