Internet: La grande falla del Web non ha più segreti, si ricorre ai ripari

[Giorgius]

If your DNS is vulnerable, you should inform your ISP or network administrator about it. However a better and faster approach is to change your DNS to OpenDNS.

DNS Checker Test: http://www.doxpara.com/

Panda Labs DnsTester: http://pandalabs.pandasecurity.com/b.../dnstester.zip

...È il caso di una società specializzata nella sicurezza informatica, che nella giornata di ieri ha inavvertitamente pubblicato numerosi dettagli su una falla riscontrata nel Domain Name System (DNS) della Rete con alcune settimane di anticipo rispetto a quanto precedentemente previsto...

Leggi: http://www.webnews.it/news/leggi/885...a-piu-segreti/

[Giorgius]

...Se la falla fosse sfruttata da malintenzionati, il dirottamento degli utenti verso siti fasulli aumenterebbe a dismisura. I server Dns traducono gli indirizzi Web in indirizzi numerici, e viceversa, semplificando a noi la navigazione su Url facili da ricordare...

Leggi: http://www.vnunet.it/it/vnunet/news/..._patch_urgente

[Giorgius]

Dopo la scoperta della vulnerabilità presente nelle varie implementazioni del servizio DNS, un nuovo avviso: nuove patch di sicurezza nei prossimi giorni...

Leggi: http://www.01net.it/01NET/HP/0,1254,...tml?lw=10000;7

[RNicoletto]

Inviato da Giorgius

DNS Checker Test: http://www.doxpara.com/

...È il caso di una società specializzata nella sicurezza informatica, che nella giornata di ieri ha inavvertitamente pubblicato numerosi dettagli su una falla riscontrata nel Domain Name System (DNS) della Rete con alcune settimane di anticipo rispetto a quanto precedentemente previsto...

"inavvertitamente pubblicato"??!!

Sono degli idioti, spero falliscano.

[LoryOne]

E se invece tale falla sia stata pubblicata andando contro ogni previsione di "disastro" ?

[Giorgius]

...As has been discussed on a number of follow-on blogs and articles, the threat emerges from two different issues with DNS protocol...

Leggi: http://www.avertlabs.com/research/blog/

[Giorgius]

The exploit is here. Metasploit has developed a module to trigger the last DNS vulnerability (announced by Dan Kaminsky two weeks ago). The DNS system translates names to numbers the Internet can use (www.pandasecurity.com -> 88.221.26.28). This threat allows malicious people to redirect any website or domain to a system controlled by the attacker. The full vulnerability description would be described at BlackHat, however it was published (by mistake) in a very known blog. Although It was removed, nevertheless it was already accessible with Google cache or Google Reader...

Leggi: http://pandalabs.pandasecurity.com/a...21002100_.aspx

[cippico]

ho fatto il test su url segnalato ad inizio thread...

http://www.doxpara.com/

e mi segnala il seguente messaggio:

Your name server, at xx.xx.xxx.xxx, appears vulnerable to DNS Cache Poisoning.


All requests came from the following source port: 32770

Due to events outside our control, details of the vulnerability have been leaked. Please consider using a safe DNS server, such as OpenDNS. Note: Comcast users should not worry.

ho guardato sul sito di opendns e ho visto che i dns sono chiaramente diversi dai miei di telecom...

consigliate di fare il cambio?

potrei avere rallentamenti rispetto ad ora?

grazie e ciaooo

[LoryOne]

Vediamo perchè dovrebbe bastare una connessione a banda larga per dare ragione all' attaccante (Mallory) sulla potenziale vulnerabilità del protocollo ed analizziamone il proof of concept: Prendendo spunto da cio che in rete "non dovrebbe più essere disponibile", facendo una sorta di sunto sulle informazioni salienti, mostrando informazioni su come effettivamente avviene il processo query-answer del protocollo ed infine commentando.

First, QIDs.
Bob’s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
If I’m Mallory and I’m attacking Bob, how can he distinguish my packets from Alice’s? Because I can’t see the QID in his request, and the QID in my response won’t match. The QID is the only thing protecting the DNS from Mallory (me).
QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here’s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses.
But there’s a bunch more problems here:
If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she’ll break the RNG and be able to predict its outputs.

Che vuol dire tutto ciò ? Vuol dire che sparando a raffica pacchetti UDP appositamente forgiati con QIDs a casaccio ed IP sorgente spoofato, cioè corrispondente all' IP del DNS interrogato ed IP destinatario conosciuto, esiste una probabilità di indovinare il pacchetto di risposta accettato che è direttamente proporzionale alla quantità di pacchetti faked immessi in rete.
Badate bene che indipendentemente dall'algoritmo di random generation utilizzato per generare il QID che dovrebbe in teoria eludere la possibilità di prediction (che ha poco senso qui, mentre ne ha parecchio sul dirottamento di sessioni o reset basato su TCP) tale concetto continua ad essere valido ... ma c'è di più perchè il protocollo per il DNS è mooooolto vecchio e nel corso del tempo ha subito migliorie ed affinamenti.
Lo scopo principe dell' attacco, però, non è quello di intervenire sul tratto che divide il server DNS dal client, ma tra server DNS e server DNS durante le interrogazioni ricorsive, cioè durante quella fase che è utile ad ogni DNS (anche a quello del vostro ISP) per scambiarsi informazioni che mancano al richiedente e che sono reperibili da qualche altra parte, facendo in modo di essere un po meno ignornati e un po più edotti su cio che è stato richiesto.
Pertanto, let's take a look to the following ...

Your computer’s resolver is probably a stub. Which means it won’t really save the response. You don’t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn’t know everything. It can’t, and shouldn’t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this “recursion”.
Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.

Che vuol dire tutto ciò ? Vuol dire che sparando a raffica pacchetti UDP appositamente forgiati con QIDs a casaccio ed IP sorgente spoofato, cioè corrispondente all' IP del DNS interrogato, IP destinatario conosciuto, valore di TTL (badate bene non è il TTL del TCP) molto alto, esiste una probabilità di indovinare il pacchetto di risposta accettato che è direttamente proporzionale alla quantità di pacchetti faked immessi in rete. Non solo, tale pacchetto faked, grazie al Time To Live elevato, può rimanere in cache per parecchio tempo prima che un'ulteriore interrogazione ricorsiva tenti di ottenere informazioni fresche ed aggiornate.
A questo punto, però, all'osservatore attento non sarà sfuggito il problema principale che è quello di giungere al server DNS richiedente con la risposta faked prima di quella corretta. Ovviamente non è cosa facile, poichè il solito attacco MITM deve essere effettuato tra tutti i server DNS sparsi sul globo che dialogano tra loro con interrogazioni ricorsive. C'è di più perchè il protocollo per il DNS è mooooolto vecchio e nel corso del tempo ha subito migliorie ed affinamenti.
Quale miglioria è così utile nel nostro caso ? I resource records addizionali perchè è possibile fornire informazioni da archiviare senza che queste abbiano la minima attinenza con quanto richiesto.
Pertanto, let's take a look to the following ...

DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are:
Answer RR’s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)
Authority RR’s, which tell resolvers which name servers to refer to to get the complete answer for a question
Additional RR’s, sometimes called “glue”, which contain any additional information needed to make the response effective.
A word about the Additional RR’s. Think about an NS record, like the one that COM’s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to know, but it’s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1.

Che vuol dire tutto ciò ? Vuol dire che sparando a raffica pacchetti UDP appositamente forgiati con QIDs a casaccio ed IP sorgente spoofato, cioè corrispondente all' IP del DNS interrogato, IP destinatario conosciuto, valore di TTL (badate bene non è il TTL del TCP) molto alto, informazioni addizionali da archiviare se prese in considerazione grazie alle corrette credenziali previste, esiste una probabilità di indovinare il pacchetto di risposta accettato che è direttamente proporzionale alla quantità di pacchetti faked immessi in rete. Non solo, tale pacchetto faked, grazie al Time To Live elevato, può rimanere in cache per parecchio tempo prima che un'ulteriore interrogazione ricorsiva tenti di ottenere informazioni fresche ed aggiornate.
Fin'ora abbiamo trattato una miglioria piuttosto pericolosa, sempre che si abbia la solita fortuna che fa in modo che l'attacco sia portato a termine con successo, ma che dire degli affinamenti a cui ho accennato prima ? Beh, le cose sono rese ancora più difficili e sempre più dipendenti dalla dea bendata in caso di riuscita nell'intento ... Per andare incontro alla richiesta di Cippico, let's take a look to the following ...

Fix 1:
The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won’t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess.
Fix 2:
The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction.
Remember how these fixes work. They’re very important.

L'osservatore attento avrà sicuramente notato che entrambi i fix non sono affatto fix, perchè nella grande quantità di pacchetti immessi in rete, almeno uno prima o poi sarà preso in considerazione come attendibile e quindi archiviato.
Certo ma ... abbiamo dato un'altra scaldata all' acqua che era già calda ? Cosa si dimostrerà al BlackHat di quest anno ? Fin troppo facile a parer mio dimostrare che si ha ragione in un ambiente controllato e predisposto ad-hoc. Funzionerà su rete WAN ?
Io nutro dubbi a proposito. Nel frattempo, attendo il rilascio di questa famigerata patch che tutti noi a cominciare dai gestori dei domini di primo livello, fino ad arrivare al nostro ISP dovremo installare.
In ultimo, vorrei sottolinerare che i miei commenti non sono tanto un iniziativa per spronare qualche inetto a scaricare l'exploit dal solito sito, a compilarlo ed a immetterlo in rete, quanto a provare a ragionare sulla reale portata di questa "falla latente" ed a leggere eventuali commenti da parte dei wintickers che vorranno partecipare per dire la loro.

Come al solito, ringrazio Wintricks per lo spazio dedicato all' intervento odierno, soprattutto per la pazienza dimostrata nel tempo a non falcidiare le mie fulminate elucubrazioni mentali , lasciando al buon Billow ad ai moderatori la facoltà di chiudere o meno il 3d.
Un sentito grazie a Giorgius per averlo aperto ed aggiornato

Ps: Magari ho sparato un mare di cazzate e se anche me lo diceste non mi offenderei mica, anzi

[LoryOne]

valore di TTL (badate bene non è il TTL del TCP) molto alto

Per dIANA, ho scritto una vaccata.
Correggo:
valore di TTL (badate bene non è il TTL dell' IP) molto alto

[cippico]

che bella spiegazione...

alla fine...cosa dovremmo fare...aspettare altra correzione? o lasciare tutto cosi' e rimanere in balia?

grazie e ciaoo

[RNicoletto]

Si sa com'è la situazione per i principali ISP italiani??