Arnes - Kot poročajo številni varnostni portali, med drugim tudi Arnesov SI-CERT in Slashdot je raziskovalec Dan Kaminsky v DNS protokolu odkril resno ranljivost, ki omogočajo izvedbo tim. zastrupljanja predpomnilnika (ang. cache poisoning), posledično pa napadalec lahko s pomočjo DNS predpomnilnika izvede napad z ribarjenjem (tim. phishing).
Kaminsky je o ranljivosti obvestil 81 proizvajalcev programja za DNS strežnike, večina pa jih je danes izdala koordiniran popravek ranljivosti. Podrobnosti o ranljivosti sicer še niso javno znane, jih bo pa Kaminsky objavil avgusta letos na Black Hat konferenci. Na voljo je tudi on-line program za preverjanje ranljivosti vašega DNS-ja.
Pa še opozorilo: poleg nadgradnje DNS programske opreme na vaših strežnikih (če jih imate) pa ne pozabite nadgraditi tudi programske opreme na napravah kot so domači brezžični usmerjevalniki.
Novice » Varnost » Odkrita resna ranljivost v DNS sistemih
Tilen ::
Your name server, at 212.18.x.x, appears to be safe. 
Your name server, at 213.161.0.10, appears vulnerable to DNS Cache Poisoning.
Your name server, at 213.161.0.10, appears vulnerable to DNS Cache Poisoning.
413120536c6f76656e696a612c20642e642e
Griffith ::
Men je tole napisal.
Your name server, at 193.000.000.000, appears vulnerable to DNS Cache Poisoning.
All requests came from the following source port: 53
Do not be concerned at this time. IT administrators have only recently been apprised of this issue, and should have some time to safely evaluate and deploy a fix.
Your name server, at 193.000.000.000, appears vulnerable to DNS Cache Poisoning.
All requests came from the following source port: 53
Do not be concerned at this time. IT administrators have only recently been apprised of this issue, and should have some time to safely evaluate and deploy a fix.
r5r ::
Joj, jaz imam pa ravno nastavljeno v bindu: query-source address * port 53; 
And it makes me wonder.
fiction ::
<offtopic>
...v ostalih novicah od vceraj: tragedija pri HE Blanca... :p
Kritična ranljivost vprotokolu DNS
</offtopic>
Gre za DNS cache poisoning problem.
Ga ne - to ni namenjeno temu, da skeniras za ranljivimi DNS strezniki, ampak zato da vidis ce je tvoj server oz. tisti od tvojega ISP-ja ranljiv. Sam sem sprobal domac streznik in se server od ponudnika tako, da sem enkrat v named.conf vkljucil forwarders {} drugic pa ne.
V vsakem primeru moras biti avtoriziran da DNS server za tebe izvaja rekurzivne poizvedbe (kar ponavadi pomeni da ne mores preizkusiti DNS od drugega ponudnika).
Itak pa tale stvar deluje tako, da poskusa resolvati neko nakljucno poddomeno in potem gleda
s katerih izvornih UDP portov prihajajo requesti
(streznik, ki je odgovoren za tisto domeno je pod njegovim nadzorom).
Ce imajo vsi enak izvorni port, rece da je slabo, sicer pa da si varen. Torej tudi ce sam implementiras to preverjanje, ne bos dosegel nicesar.
Da vecina DNS serverjev ponavadi uporablja ista izvorna vrata je bilo ze kar nekaj casa
znano. Tako da, kljub temu, da so v sklopu tega popravka vse skupaj odpravili, to definitivno
ni zasluga Dana Kaminskya. Je pa nakljucnost tukaj pomembna, ker to zmanjsa moznost da nekdo
ponaredi odgovor od streznika. Dejansko sta dve 16 bitni vrednosti, ki sta nakljucni - transaction id in izvorni port.
S tem ko druga ni cisto nakljucna, je napad dosti lazji.
Treba je poslati samo 2^16 razlicnih odgovorov, namesto 2^32.
Se ena stvar, ki je bila potihem spremenjena v popravku za BIND je generator nakljucnih
stevil. Namesto tistega prej se sedaj uporablja OpenBSD-jeva implementacija RC4 algoritma kot
neke vrste PRNG, ki za seed uporablja neinicializiran pomnilnik.
To bi se lahko skladalo s tistim kar pravi Kaminsky - da so se potrudili da je napako tezko
najti z reverse engineeringom. Tukaj to drzi - ne vidi se tocno kaj je problem, ker je bilo
vse skupaj spremenjeno in ne samo popravljeno. Samo po drugi strani pa trdi, da gre
za problem z DNS protokolom kot takim. Najbrz nimajo vse implementacije predvidljivega
generatorja nakljucnih stevil ali pac?
Ali je tukaj misljeno tisto z enakim izvornim portom in da tistih 16 bitov entropije od
transaction id-ja v praksi ni dovolj? To bi pomenilo, da tip sploh ni nic novega pogruntal,
ampak samo zganja paniko, ker problem se zmeraj ni bil odpravljen.
Ce je res odkril kaksno napako v generatorju nakljucnih stevil, bi pa to lahko povedal. Se
zmeraj mu ne bi bilo treba razkriti kaj tocno je problem, bi pa vse skupaj vseeno delovalo veliko bolj verodostojno.
Vedno bolj se mi dozdeva da tukaj ne gre le za security-through-obcurity, ampak za
promotion-through-obscurity.
...v ostalih novicah od vceraj: tragedija pri HE Blanca... :p
Kritična ranljivost vprotokolu DNS
</offtopic>
Gre za DNS cache poisoning problem.
Kako pri tem preverjanju izberem poljubni DNS strežnik?
Ga ne - to ni namenjeno temu, da skeniras za ranljivimi DNS strezniki, ampak zato da vidis ce je tvoj server oz. tisti od tvojega ISP-ja ranljiv. Sam sem sprobal domac streznik in se server od ponudnika tako, da sem enkrat v named.conf vkljucil forwarders {} drugic pa ne.
V vsakem primeru moras biti avtoriziran da DNS server za tebe izvaja rekurzivne poizvedbe (kar ponavadi pomeni da ne mores preizkusiti DNS od drugega ponudnika).
Itak pa tale stvar deluje tako, da poskusa resolvati neko nakljucno poddomeno in potem gleda
s katerih izvornih UDP portov prihajajo requesti
(streznik, ki je odgovoren za tisto domeno je pod njegovim nadzorom).
Ce imajo vsi enak izvorni port, rece da je slabo, sicer pa da si varen. Torej tudi ce sam implementiras to preverjanje, ne bos dosegel nicesar.
Da vecina DNS serverjev ponavadi uporablja ista izvorna vrata je bilo ze kar nekaj casa
znano. Tako da, kljub temu, da so v sklopu tega popravka vse skupaj odpravili, to definitivno
ni zasluga Dana Kaminskya. Je pa nakljucnost tukaj pomembna, ker to zmanjsa moznost da nekdo
ponaredi odgovor od streznika. Dejansko sta dve 16 bitni vrednosti, ki sta nakljucni - transaction id in izvorni port.
S tem ko druga ni cisto nakljucna, je napad dosti lazji.
Treba je poslati samo 2^16 razlicnih odgovorov, namesto 2^32.
Se ena stvar, ki je bila potihem spremenjena v popravku za BIND je generator nakljucnih
stevil. Namesto tistega prej se sedaj uporablja OpenBSD-jeva implementacija RC4 algoritma kot
neke vrste PRNG, ki za seed uporablja neinicializiran pomnilnik.
To bi se lahko skladalo s tistim kar pravi Kaminsky - da so se potrudili da je napako tezko
najti z reverse engineeringom. Tukaj to drzi - ne vidi se tocno kaj je problem, ker je bilo
vse skupaj spremenjeno in ne samo popravljeno. Samo po drugi strani pa trdi, da gre
za problem z DNS protokolom kot takim. Najbrz nimajo vse implementacije predvidljivega
generatorja nakljucnih stevil ali pac?
Ali je tukaj misljeno tisto z enakim izvornim portom in da tistih 16 bitov entropije od
transaction id-ja v praksi ni dovolj? To bi pomenilo, da tip sploh ni nic novega pogruntal,
ampak samo zganja paniko, ker problem se zmeraj ni bil odpravljen.
Ce je res odkril kaksno napako v generatorju nakljucnih stevil, bi pa to lahko povedal. Se
zmeraj mu ne bi bilo treba razkriti kaj tocno je problem, bi pa vse skupaj vseeno delovalo veliko bolj verodostojno.
Vedno bolj se mi dozdeva da tukaj ne gre le za security-through-obcurity, ampak za
promotion-through-obscurity.
Zgodovina sprememb…
- spremenil: fiction ()
samek ::
Me prav zanima koliko časa bo preteklo preden bojo slovenski ISPji updejtal svoje DNS strežnike. Zaenkrat vidim, da siol še nich ni naredil v tej smeri..
/dev/null
fiction ::
T-2 je upgradal streznike ze danes zjutraj. Pohvale.
Sem jih pa jaz vseeno za kar nekaj casa prehitel. :)
Ker se za enkrat se ne ve tocno kaj je dejanski problem, ni bojazni da bi se tole na veliko
izkoriscalo. SiOL ima torej se do avgusta cas - oz. ok vsaj dokler kaksen blackhat ne pogrunta
problema in zacne z izkoriscanjem, kar se bo prej ali slej odkrilo. V interesu zlobneza je
namrec da cimvec ljudi obisce njegovo phishing stran.
Sem jih pa jaz vseeno za kar nekaj casa prehitel. :)
Ker se za enkrat se ne ve tocno kaj je dejanski problem, ni bojazni da bi se tole na veliko
izkoriscalo. SiOL ima torej se do avgusta cas - oz. ok vsaj dokler kaksen blackhat ne pogrunta
problema in zacne z izkoriscanjem, kar se bo prej ali slej odkrilo. V interesu zlobneza je
namrec da cimvec ljudi obisce njegovo phishing stran.
poweroff ::
fiction - tisto sem videl že včeraj, pa sem se potem zvečer odločil, da je morda vseeno dobro napisat novico. Morda pa kdo za problem še ni vedel...
Kar se Kaminskya tiče pa - počakajmo do BlackHata, pa bomo videli. Je pa definitivno njegovo ravnanje precej etično.
Kar se Kaminskya tiče pa - počakajmo do BlackHata, pa bomo videli. Je pa definitivno njegovo ravnanje precej etično.
sudo poweroff
krho ::
Mnja. Bi upgrejdal, pa mi na asusu dd-wrt v24 dela ne spljoh.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
misek ::
A tu se gleda samo DNS strežnike? Kaj pa klienti, ki dajejo povpraševanja DNS strežniku? Je tu isti problem?
necromncr ::
Gentoo še nima popravka..
Edit: my bad - ima 9.4.2-P1
Edit: my bad - ima 9.4.2-P1
Zgodovina sprememb…
- spremenilo: necromncr ()
preem ::
Djbdns strežnik ni ranljiv za ta bug, ker uporablja random porte za DNS resolving.
Jaz uporabljam tega, na kar ene par strežnikih, sem vedel da nekoč bo prišlo prav da se izogibam največjega mainstream strežnika, bind-a ;)
Jaz uporabljam tega, na kar ene par strežnikih, sem vedel da nekoč bo prišlo prav da se izogibam največjega mainstream strežnika, bind-a ;)
Bakunin ::
preem
kaj ima "random port" zveze s tem?
ko bo imel djb sistem uradno podporo za ipv6/cidr/xfr/dnssec ter predvsem SYSLOG, potem se bo uporaben.
sicer pa si poglej se NSD
kaj ima "random port" zveze s tem?
ko bo imel djb sistem uradno podporo za ipv6/cidr/xfr/dnssec ter predvsem SYSLOG, potem se bo uporaben.
sicer pa si poglej se NSD
fiction ::
Komaj cakam da tip pove kaj je dejansko odkril.
Bakunin: Jah ce je random dober in DJBDNS uporablja 32 bitno nakljucno vrednost, namesto
tistih 16 pri ostalih DNS streznikih, potem se to pozna in najbrz onemogoci napade.
misek: Ja, pri clientih je v principu isti problem. Razlika je samo v tem, da
se mora napadalec v primeru caching nameserverja potruditi samo enkrat in dokler ima ta
napacno stvar v cachu, bodo vsi uporabniki dobivali spremenjen rezultat. Drugace mora
napadalec napadati vsakega odjemalca posebej. Pa za client tudi ne ves tocno kdaj bo poslal
request tako da je bolj tezko poslati nazaj ponarejen odgovor, medtem ko server dejansko ti
vprasas in mu istocasno posljes se fake odgovor.
BTW: ZoneAlarm z Microsoftovim popravkom za resolver ne deluje vec - ker ne pricakuje da se
za DNS uporabljajo nakljucni izvorni porti. :)
Bakunin: Jah ce je random dober in DJBDNS uporablja 32 bitno nakljucno vrednost, namesto
tistih 16 pri ostalih DNS streznikih, potem se to pozna in najbrz onemogoci napade.
misek: Ja, pri clientih je v principu isti problem. Razlika je samo v tem, da
se mora napadalec v primeru caching nameserverja potruditi samo enkrat in dokler ima ta
napacno stvar v cachu, bodo vsi uporabniki dobivali spremenjen rezultat. Drugace mora
napadalec napadati vsakega odjemalca posebej. Pa za client tudi ne ves tocno kdaj bo poslal
request tako da je bolj tezko poslati nazaj ponarejen odgovor, medtem ko server dejansko ti
vprasas in mu istocasno posljes se fake odgovor.
BTW: ZoneAlarm z Microsoftovim popravkom za resolver ne deluje vec - ker ne pricakuje da se
za DNS uporabljajo nakljucni izvorni porti. :)
denial ::
Čisto mogoče, da Kaminsky ni odkril nič novega, temveč je le izkoristil splošno znan in dokumentiran "design flaw" za katerega se nihče ni zmenil. Mogoče pa je njegovo odkritje le nadgradnja Amit Kleinovega raziskovalnega dela?
Kakorkoli, nekateri skeptiki in kritiki, med drugim tudi izredno cenjeni varnostni raziskovalci Zovi, Ptacek in Mogul so imeli ta privilegij, da so lahko videli Kaminskyjevo BH prezentacijo - in bili so impresionirani.
Tudi, če se bo izkazalo, da je Kaminsky le attention whore pa je njegovo dejanje hvalevredno: exploita ni prodal temveč je obvestil razvijalce in (več mesecev) počakal na koordinirano objavo. Svaka čast.
Kakorkoli, nekateri skeptiki in kritiki, med drugim tudi izredno cenjeni varnostni raziskovalci Zovi, Ptacek in Mogul so imeli ta privilegij, da so lahko videli Kaminskyjevo BH prezentacijo - in bili so impresionirani.
Tudi, če se bo izkazalo, da je Kaminsky le attention whore pa je njegovo dejanje hvalevredno: exploita ni prodal temveč je obvestil razvijalce in (več mesecev) počakal na koordinirano objavo. Svaka čast.
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
Bakunin ::
16, 32...whatever random...
Edini nacin da dobis VERODOSTOJEN podatek od DNS [authoritive ali resolving] je DNSSEC. Lani je imel RIPE enodnevni "tecaj" na to temo v hotelu Lev [Ljubljana].
Zal porabi vec pomnilnika ter prostora na disku kot "normalen" DNS zapis, ampak si pa lahko 100% o verodostojnosti DNS zapisa.
do takrat (splosne uporabe DNSSEC) pa... plič patch. :-/
Edini nacin da dobis VERODOSTOJEN podatek od DNS [authoritive ali resolving] je DNSSEC. Lani je imel RIPE enodnevni "tecaj" na to temo v hotelu Lev [Ljubljana].
Zal porabi vec pomnilnika ter prostora na disku kot "normalen" DNS zapis, ampak si pa lahko 100% o verodostojnosti DNS zapisa.
do takrat (splosne uporabe DNSSEC) pa... plič patch. :-/
Zgodovina sprememb…
- spremenil: Bakunin ()
denial ::
Kako pri tem preverjanju izberem poljubni DNS strežnik?
TCP/IP properties -> Use the following DNS server addresses (deluje le v primeru, ko izbrani DNS dovoljuje "zunanje" queryje). Recheck...
Kako lahko delno preprečimo DNS cache poisoning? V datoteko hosts vnesemo par IP/hostname najbolj kritičnih/zaupnih strani npr. spletna banka, webmail, e-uprava, e-student itd.
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
CyberPunk ::
BTW: ZoneAlarm z Microsoftovim popravkom za resolver ne deluje vec - ker ne pricakuje da se
za DNS uporabljajo nakljucni izvorni porti. :)
Ja, to je ze cel dan big news.
http://download.zonealarm.com/bin/free/...
Ampak blokira pa vse. Tudi cajta mi ni pustilo sinhronizirati. Traceroute po IPju je se nekako sel skozi.
fiction ::
Edini nacin da dobis VERODOSTOJEN podatek od DNS [authoritive ali resolving] je DNSSEC.
Se strinjam. Tam dobis odgovor od streznika podpisan.
Samo DNSSEC ima tudi svoje slabosti.
Ker je bolj kompleksen (mogoce po nepotrebnem) je vecja verjetnost za napake.
Pa recimo to da izdaja vse zapise za dolocen zone (Sicer obstaja sedaj NSEC3, ampak vseeno).
Lani je imel RIPE enodnevni "tecaj" na to temo v hotelu Lev [Ljubljana].
Aja RIPE je imel "tecaj"? Sounds interesting. Povej kaj vec o tem prosim.
Tudi, če se bo izkazalo, da je Kaminsky le attention whore pa je njegovo dejanje hvalevredno: exploita ni prodal temveč je obvestil razvijalce in (več mesecev) počakal na koordinirano objavo. Svaka čast.
Ja, to kako je bila izdaja patcha koordinirana je res hvalevredno.
Prodaja exploita ni nujno najbolj dobickonosna varianta tukaj. S tem "ne-razkritjem"
si je zelo zvisal ceno. Vprasanje pa je a to pocne zaradi etike ali dobicka.
Kako lahko delno preprečimo DNS cache poisoning?
Kako preprecimo DNS cache poisoning? Ne uporabljamo DNS-a. ;)
fiction ::
Zelo zanimiva se mi zdi ideja, ki sem jo prebral na enem forumu:
65536 razlicnih "transaction-id"-jev ni tako veliko, da se ne bi dalo v razumnem casu
preizkusiti vseh (medtem ko bi s port randomization-om potreboval par 10 GB podatkov).
Problem pri vsem tem je le, da tekmujes z realnim DNS streznikom, ki bo
poslal veljaven odgovor (da bo tvoj ponaredek upostevan more priti na cilj pred tistim).
Resitev za to tekmo je lahko bolj otrocja - izvajas DoS napad nad tistim streznikom, ki naj bi poslal odgovor.
Ampak mozno pa je, da je Kaminsky odkril kaj bolj elegantnega. Recimo da lahko tistemu DNS2
strezniku z neko posebno poizvedbo reces ignoriraj dolocene requeste od DNS1. Potem pa
poskusas zastrupiti predpomnilnik od DNS1 (ker DNS2 nikoli ne poslje odgovora te torej ne
ovira) kar pomeni, da lahko poskusis vse moznosti dokler DNS1 ni "zastrupljen".
Ali pa da DNS1 reces naj ignorira veljaven odgovor od DNS2.
Druga varianta je pa seveda da je treba poizkusiti veliko manj moznosti in zato odgovor od
DNS2 ni problematicen. Pod to pa spadajo razne napake v PRNG generatorju. V prid temu sicer
govori sprememba algoritma - ampak vse skupaj je vseeno malo prevec ocitno.
65536 razlicnih "transaction-id"-jev ni tako veliko, da se ne bi dalo v razumnem casu
preizkusiti vseh (medtem ko bi s port randomization-om potreboval par 10 GB podatkov).
Problem pri vsem tem je le, da tekmujes z realnim DNS streznikom, ki bo
poslal veljaven odgovor (da bo tvoj ponaredek upostevan more priti na cilj pred tistim).
Resitev za to tekmo je lahko bolj otrocja - izvajas DoS napad nad tistim streznikom, ki naj bi poslal odgovor.
Ampak mozno pa je, da je Kaminsky odkril kaj bolj elegantnega. Recimo da lahko tistemu DNS2
strezniku z neko posebno poizvedbo reces ignoriraj dolocene requeste od DNS1. Potem pa
poskusas zastrupiti predpomnilnik od DNS1 (ker DNS2 nikoli ne poslje odgovora te torej ne
ovira) kar pomeni, da lahko poskusis vse moznosti dokler DNS1 ni "zastrupljen".
Ali pa da DNS1 reces naj ignorira veljaven odgovor od DNS2.
Druga varianta je pa seveda da je treba poizkusiti veliko manj moznosti in zato odgovor od
DNS2 ni problematicen. Pod to pa spadajo razne napake v PRNG generatorju. V prid temu sicer
govori sprememba algoritma - ampak vse skupaj je vseeno malo prevec ocitno.
denial ::
Vse bolj se mi dozdeva, da Kaminsky ni odkril nič pretresljivo novega temveč je le do skrajnosti oplemenitil že znane zadeve. Po domače, DNS poisoning je pripeljal do "point and click" nivoja. Just my 5 cents anyway...
Na plano pa prihajajo tudi nova odkritja:
- PowerDNS ni ranljiv
- nekatere NAT naprave izničijo source port randomization XID-jev čeprav prihajajo s patchanih strežnikov
- Predictable XID client-side patch (MS08-020)
Kako globoke korenine ima DNS poisoning? Zelo (ADM/1999).
Na plano pa prihajajo tudi nova odkritja:
- PowerDNS ni ranljiv
- nekatere NAT naprave izničijo source port randomization XID-jev čeprav prihajajo s patchanih strežnikov
- Predictable XID client-side patch (MS08-020)
Kako globoke korenine ima DNS poisoning? Zelo (ADM/1999).
SELECT finger FROM hand WHERE id=3;
Zgodovina sprememb…
- spremenil: denial ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Odkritih 13 kritičnih ranljivosti AMD Ryzen in EPYC procesorjev (strani: 1 2 3 )Oddelek: Novice / Procesorji | 35576 (28905) | rdecaluc |
| » | Hekerska meka v Las VegasuOddelek: Novice / Varnost | 7566 (6215) | MrStein |
| » | Uporaba DNS-a za (prikrito) komuniciranjeOddelek: Novice / Zasebnost | 4269 (3677) | fiction |
| » | Odkrita resna ranljivost v DNS sistemihOddelek: Novice / Varnost | 6756 (4238) | denial |
| » | Kritična ranljivost vprotokolu DNSOddelek: Informacijska varnost | 2218 (2069) | fiction |