» »

Kritična ranljivost vprotokolu DNS

Kritična ranljivost vprotokolu DNS

BlueRunner ::

Objaveljeno je na US-CERT, Security Focus, Slashdot, ...

Na vse kar uporablja rekurzivne DNS poizvedbe (strežniki in odjemalci) je potrebno namestiti popravke. Zadeva ni kritična na način, da se bi pričakoval 0-day, je pa še vedno tako zelo kritična, da je zaželjena čim prejšnja namestitev popravkov.

Ne pozabiti na svoje male usmerjevalnike (Level1, SMC, Linksys, Netgear, Buffalo, ...): skratka vse, kar vključuje in uporablja DNS je ranljivo zaradi napake v protokolu.

Pomagajte tudi svojim prijateljem, ki so računalniško manj vešči!

( ... pa lep dan še naprej ...)

blackbfm ::

Ja cel internet se bo sesu zarad tega :)

fiction ::

Kar hoce BlueRunner povedati je najbrz, da ce na vasem racunalniku tece DNS streznik oz.
DNS odjemalec, s pomocjo te napake ni mogoc vdor na ta PC. 0-day je tezko definirati.
Jaz pod tem pojmom razumem, da bo nekdo imel exploit za to stvar se preden bo cel svet vedel
kaj je bistvo napake. To, da je bilo objavljeno da napaka je + skriti popravki zanjo se ne
spremeni vsega skupaj. Ce bi avtor izdal nek PoC ali pa bolj podroben opis, potem kakrsenkoli
exploit ne bi bil vec 0-day.

Je pa napaka kljub temu dokaj kriticna in omogoca "cache poisoning" - torej zastrupljanje
streznikovega medpomnilnika. V praksi to pomeni, da nekdo lahko zastrupi streznik od
dolocenega ISP-ja. Tako se npr. vsem strankam tega ponudnika www.banka.si resolva v 10.0.0.1
namesto v pravilni IP 192.168.0.1.
To pomeni, da bodo stranke pri obisku www.banka.si se zmeraj lahko pristale na lazni (po
moznosti "phishing" strani). S pomocjo SSL se da zagotoviti, da je tisto na drugi strani res
banka, ampak vseeno pa tole precej olajsa delo goljufom.
Najbrz bo kar precej popularnih strani na tak nacin preusmerjenih drugam. Pri tem
se napadalec dejanske tarce niti ne dotakne (ampak samo spremeni kam kaze hostname).

Da ne govorimo o vseh tistih kvazi avtentikacijskih metodah, ki temeljijo na domenah -
recimo OpenID.

Sem na hitro naredil diff med BIND 9.4.2 in popravljenim BIND 9.4.2-P1.

+2375. [security] Fully randomize UDP query ports to improve
+ forgery resilience. [RT #17949]

Izgleda, da je problem v tem, da se uporabljajo vedno isti izvorni UDP naslovi oz.
ti niso dovolj nakljucno izbrani.

Zgodovina sprememb…

  • spremenil: fiction ()

BlueRunner ::

Ja cel internet se bo sesu zarad tega :)


Nope, se bo pa povečalo število zlorab, ki se zanašajo na to, da ti lahko "podtaknejo" napačen IP naslov strežnika pri razreševanju DNS imena. Npr. podtaknem ti IP naslov mojega strežnika za domeno slo-tech.com in si od tebe "izposodim" tvoje geslo.

Za neko obdobje bomo tako trpeli posledice bistvenega povečanje števila zlorab (vdori, phishing, uce/ube, ipd.). Za oceno nevarnosti pa upoštevaj, da je ta "zastrupitev" najlažji način za izvedbo MITM napadov. Hmm.... ali so pri T-2 že poskrbeli za "splošno razpoznana" kvalificirana digitalna potrdila, s katerimi bi lahko uporabniki zaznali, da nekdo tretji prestreza njihovo komunikacijo?

Zgodovina sprememb…

fiction ::

Ravno berem http://www.net-security.org/dl/articles...
Kar mi ni jasno pri vsem tem je, da so ocitno ze leta 2003 vedeli, da server ponovno uporabi isti izvorni port. Kar pomeni, da je samo 16 bitov entropije (transaction id).
Torej kaj je Kaminsky tocno novega pogruntal? Samo to, da ocitno nihce vsega skupaj ni sel popraviti. Ali je odkril se kaksno napako pri generatorju nakljucnih stevil za TID, ki bi
naredil napad se bolj enostaven.
Nasel sem samo http://www.kb.cert.org/vuls/id/252735
Ampak tole je ocitno ze odpravljeno.

Napadalec mora torej spoofati IP od dolocenega nameserverja in odgovarjati drugemu DNS
strezniku v njegovem imenu (ce zadane izvorni port + TID bo ta potem shranil njegov odgovor v
medpomnilnik).

Zgodovina sprememb…

  • spremenil: fiction ()

fiction ::

Eh ja - Kaminsky bo objavil podrobnosti sele avgusta na BlackHat konferenci v Las Vegasu.
Ne vem, ce je to res samo zato, da bo dovolj casa za patchanje, ampak bolj zato da bo njegovo predavanje
popularno. Prov cakam na to, da bo nekdo sam odkril vse skupaj in objavil detajle 1 dan prej :)

Ok - tip govori o tem kako je iz popravka zelo tezko odkriti ranljivost. To, da se sedaj uporablja
random UDP source port pri poizvedbah je dokaj ocitno. S tem se doda nekaj entropije poleg tistih
16 bitov od "transaction-id"-ja. Drugo kar je spremenjeno je pa generator nakljucnih stevil, ki je nadomescen
z ARC4 od OpenBSD-ja (implementacija RC4 pri cemer se zacetne vrednosti zanemarijo, ker niso dovolj nakljucne).
Logicen sklep: nekako se je dalo prej odkriti interno stanje PRNG generatorja nakljucnih stevil ter ugotoviti
naslednjo stevilo (tako mogoce sploh ni treba poskusiti v povprecju 32768 razlicnih vrednosti), ceprav je ze
samo to dovolj kriticno.

The first algorithm is an adaptation of the sequence shuffling
algorithm discovered by Carter Bays and S. D. Durham [ACM Trans. Math.
Software 2 (1976), 59-64], as documented as Algorithm B in Chapter
3.2.2 in Volume 2 of Knuth's "The Art of Computer Programming".

Me prav zanima kaj je problem s tem.

Zgodovina sprememb…

  • spremenil: fiction ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Po pol leta AMD-jevi procesorji še vedno s hroščem (strani: 1 2 )

Oddelek: Novice / Procesorji
5411249 (8381) MrStein
»

Zvočno ribarjenje z asistenco pametnih pomočnikov

Oddelek: Novice / Varnost
153823 (2665) Hermit Bob
»

Odkrita resna ranljivost v DNS sistemih

Oddelek: Novice / Varnost
286632 (4114) denial
»

Odkrita resna varnostna pomankljivost v Debianovem naključnem generatorju števil za O

Oddelek: Novice / Varnost
487527 (4117) poweroff
»

Ali bo Vista SP1 vseboval stranska vrata za NSA?

Oddelek: Novice / Ostala programska oprema
333509 (3509) cryptozaver

Več podobnih tem