Onderwerp: DNS security probleem en ADSL/Kabel modems.

Er is sinds enige tijd een DNS probleem bekend:

http://www.us-cert.gov/cas/techalerts/TA08-190B.html

Systems Affected Systems implementing:
* Caching DNS resolvers
* DNS stub resolvers

Affected systems include both client and server systems, and any other
networked systems that include this functionality.

Overview:
Deficiencies in the DNS protocol and common DNS implementations
facilitate DNS cache poisoning attacks. Effective attack techniques
against these vulnerabilities have been demonstrated.

Modems/routers die ook een "Caching DNS resolver" of "DNS stub resolver"
voor gebruik op het LAN aan boord hebben, hebben waarschijnlijk ook een
update nodig.

Ik heb tot nu toe nog niet zo veel updates van modem leveranciers gezien.

--
Chel van Gennip (chel vangennip nl)

In article <6ej6ieF791gjU1@mid.individual.net>,
Chel van Gennip <chel-news@vangennip.nl> writes:
> Er is sinds enige tijd een DNS probleem bekend:

Dat is al sinds mensenheugenis bekend, anders was al het werk aan DNSsec
een oefening in futiliteit. Het nieuwtje is dat er nu een echte exploit
voor is.

>
> Systems Affected Systems implementing:
> * Caching DNS resolvers
> * DNS stub resolvers

Dat laatste maakt me erg nieuwsgierig naar de komende onthullingen.
Dat je een cache kunt vervuilen geloof ik wel, als je een antwoord
kunt spoofen kun je ook een query spoofen die door de allow-recursion
ACL gaat. Echter, dat verklaart niet hoe je een client kun vervuilen,
fascinerend. Nog maar 14 nachtjes slapen, dan weten we het.

> Modems/routers die ook een "Caching DNS resolver" of "DNS stub resolver"
> voor gebruik op het LAN aan boord hebben, hebben waarschijnlijk ook een
> update nodig.

Er is meer. Een domme PAT implementatie kan ook roet in het eten gooien.
Als je je bind (of wat dan ook) hebt geupgraded naar een versie die
random source ports gebruikt en de PAT vertaalt dat vervolgens naar
een voorspelbare sequentie dan ben je nog steeds kwetsbaar.

Dick Wesseling schreef:
> In article <6ej6ieF791gjU1@mid.individual.net>,
> Chel van Gennip <chel-news@vangennip.nl> writes:
>> Er is sinds enige tijd een DNS probleem bekend:
>
> Dat is al sinds mensenheugenis bekend, anders was al het werk aan DNSsec
> een oefening in futiliteit. Het nieuwtje is dat er nu een echte exploit
> voor is.
>
>> Systems Affected Systems implementing:
>> * Caching DNS resolvers
>> * DNS stub resolvers
>
> Dat laatste maakt me erg nieuwsgierig naar de komende onthullingen.
> Dat je een cache kunt vervuilen geloof ik wel, als je een antwoord
> kunt spoofen kun je ook een query spoofen die door de allow-recursion
> ACL gaat. Echter, dat verklaart niet hoe je een client kun vervuilen,
> fascinerend. Nog maar 14 nachtjes slapen, dan weten we het.

De CERT is vrij duidelijk, en volgens Paul Vixie, die redelijk bekend is
met het DNS protocol en die wat voorinformatie kreeg, moeten we de
waarschuwing zeer serieus nemen: "Please do the following. First, take
the advisory seriously—we're not just a bunch of n00b alarmists, if we
tell you your DNS house is on fire, and we hand you a fire hose, take
it. Second, take Secure DNS seriously, even though there are intractable
problems in its business and governance model—deploy it locally and push
on your vendors for the tools and services you need. Third, stop
complaining, we've all got a lot of work to do by August 7 and it's a
little silly to spend any time arguing when we need to be patching."

>> Modems/routers die ook een "Caching DNS resolver" of "DNS stub resolver"
>> voor gebruik op het LAN aan boord hebben, hebben waarschijnlijk ook een
>> update nodig.
>
> Er is meer. Een domme PAT implementatie kan ook roet in het eten gooien.
> Als je je bind (of wat dan ook) hebt geupgraded naar een versie die
> random source ports gebruikt en de PAT vertaalt dat vervolgens naar
> een voorspelbare sequentie dan ben je nog steeds kwetsbaar.

Nog een extra reden om goed te kijken naar de diverse modems/routers.
Het probleem daarbij is wel dat er flink wat matig beheerde modems
staan, en het zou vervelend zijn als een "man in the middle" extra
filialen van de Postbank of zo zou kunnen openen.

--
Chel van Gennip (chel vangennip nl)

Het is mij nog steeds niet duidelijk hoe het internet ineens overspoeld
kan worden met "men in the middle" met foute intenties.
Ik ga er vanuit dat mijn DNS request voor www.postbank.nl op de weg
tussen mijn provider en ns1.ing.nl voornamelijk langs "betrouwbare"
partijen komt (zo te zien xs4all, eurorings, kpn) dus waar ligt nou
die boze inbreker die het request oppakt en molesteert?

Een request voor een of andere duistere site misschien niet, maar who
cares als dat verkeerd beantwoord wordt?

En dan nog iets: die resolver van je eigen router die zal in 99.99% van
de gevallen wijzen naar de resolver van je provider (gekregen via PPP of
DHCP auto-configuratie) en zal dus al zijn packets daar heen sturen, niet
naar willekeurige DNS servers op de wereld.
Hoe moet een man-in-the-middle zich voegen tussen je provider's DNS resolver
en je ADSL modem? Dat moet dan een bad guy bij de provider zijn, is niet?
Die kan net zo goed een maladfide resolver installeren en daar iedeeen
gebruik van laten maken...

On 21 Jul 2008 18:07:55 GMT, Rob <nomail@example.com> wrote:

>En dan nog iets: die resolver van je eigen router die zal in 99.99% van
>de gevallen wijzen naar de resolver van je provider (gekregen via PPP of
>DHCP auto-configuratie) en zal dus al zijn packets daar heen sturen, niet
>naar willekeurige DNS servers op de wereld.
>Hoe moet een man-in-the-middle zich voegen tussen je provider's DNS resolver
>en je ADSL modem? Dat moet dan een bad guy bij de provider zijn, is niet?
>Die kan net zo goed een maladfide resolver installeren en daar iedeeen
>gebruik van laten maken...

De MitM refereert aan de attack nadat je eenmaal de dns gepoisoned hebt,
dwz dat je bijvoorbeeld zorgt dat postbank.nl voor klanten van een
bepaalde isp wijst naar je eigen website, en vervolgens ga jij de
user/pass gebruiken die de klanten dan ingeven om zelf in te loggen op de
internet banking, en naast de legitieme opdrachten die de klant ingeeft
(en jij doorgeeft) geef je opdrachten voor jezelf. Dat is het MitM
gedeelte.

Het DNS cache poisoning (gezien ook het feit dat source port randomisation
de oplossing is) werkt blijkbaar door een bepaald domein te requesten, en
vervolgens een forged antwoord te sturen naar de dns server wat een hogere
prioriteit heeft cq eerder binnenkomt dan het antwoord van de echte
relevante dns server.

Op die manier kan een klant van Telfort, in combo met een willekeurig
ander netwerkadres, dus de DNS server van Telfort zover krijgen dat ie
postbank klanten naar een frauduleuze website stuurt.

ADSL modems is dit allemaal niet zo relevant voor. Pas als je controle
hebt over een systeem binnen het eigen netwerk werkt dit type aanval, en
daarnaast zijn de dns resolvers in adsl modems eigenlijk alleen
forwarders, volgens mij zonder een echte lokale cache (maar net genoeg
functionaliteit om "adsl-modem.lan" te implementeren).

Jasper

Jasper Janssen schreef:
> On 21 Jul 2008 18:07:55 GMT, Rob <nomail@example.com> wrote:

> Het DNS cache poisoning (gezien ook het feit dat source port randomisation
> de oplossing is) werkt blijkbaar door een bepaald domein te requesten, en
> vervolgens een forged antwoord te sturen naar de dns server wat een hogere
> prioriteit heeft cq eerder binnenkomt dan het antwoord van de echte
> relevante dns server.

Als ik in de CERT lees:
"Recent research into these and other related vulnerabilities has
produced extremely effective exploitation methods to achieve cache
poisoning. Tools and techniques have been developed that can reliably
poison a domain of the attacker's choosing on most current
implementations. As a result, the consensus of DNS software implementers
is to implement source port randomization in their resolvers as a
mitigation."
dan lijkt mij een andere techniek waarschijnlijk. Vooral het "poison a
domain of the attacker's choosing" wijst in een andere richting dan wat
jij aangeeft. Misschien wat handigheidjes met serial numbers of TTL's.
Source port randomisation betekent ook dat de caching DNS op
willekeurige en wisselende poorten luistert, wat ongewenste communicatie
van buitenaf moeilijker maakt (behalve voor een getimed forged
antwoord), en daardoor helpt.

Ik hecht voorlopig nog meer waarde aan Paul's (kwart eeuw DNS ervaring
en kennis van de exploit) "if we tell you your DNS house is on fire, and
we hand you a fire hose, take it" dan aan Rob's "Het is mij nog steeds
niet duidelijk hoe.."

Ik denk daarom dat we de waarschuwing: "Affected systems include both
client and server systems, and any other networked systems that include
this functionality. " gewoon serieus moeten nemen.

--
Chel van Gennip (chel vangennip nl)

Chel van Gennip <chel-news@vangennip.nl> wrote:
> Ik hecht voorlopig nog meer waarde aan Paul's (kwart eeuw DNS ervaring
> en kennis van de exploit) "if we tell you your DNS house is on fire, and
> we hand you a fire hose, take it" dan aan Rob's "Het is mij nog steeds
> niet duidelijk hoe.."

Ik snap niet hoe daar meer of minder waarde aan te hechten is.
Ik schrijf niet dat er geen probleem is maar dat het me niet duidelijk
is wat het probleem is.
Er is een waarschuwing, maar het is niet duidelijk waarvoor die waarschuwt.
In die situatie is het lastig om te bepalen of je iets moet doen of dat
dat overbodig is.

Rob schreef:
> Chel van Gennip <chel-news@vangennip.nl> wrote:
>> Ik hecht voorlopig nog meer waarde aan Paul's (kwart eeuw DNS ervaring
>> en kennis van de exploit) "if we tell you your DNS house is on fire, and
>> we hand you a fire hose, take it" dan aan Rob's "Het is mij nog steeds
>> niet duidelijk hoe.."
>
> Ik snap niet hoe daar meer of minder waarde aan te hechten is.
> Ik schrijf niet dat er geen probleem is maar dat het me niet duidelijk
> is wat het probleem is.
> Er is een waarschuwing, maar het is niet duidelijk waarvoor die waarschuwt.
> In die situatie is het lastig om te bepalen of je iets moet doen of dat
> dat overbodig is.

Er wordt duidelijk gewaarschuwd voor een zwakke plek in het DNS
protocol, waarvoor een exploit gedemonstreerd is, en die kan leiden tot
het manipuleren van buitenaf van DNS informatie. De exploit is slechts
gecommuniceerd met een beperkt aantal deskundigen, zodat het versterken
van de zwakke plek mogelijk is voordat de exploit breed bekend wordt.
Dat lijkt mij een correcte gang van zaken.

Voor mij telt in zo'n geval de beoordeling door Paul Vixie, die alom
bekend staat als een expert op het gebied van DNS en die inzage heeft
gehad in de mogelijke exploits, zwaarder dan jouw "het is mij nog steeds
niet duidelijk"

--
Chel van Gennip (chel vangennip nl)

Chel van Gennip <chel-news@vangennip.nl> wrote:
> Voor mij telt in zo'n geval de beoordeling door Paul Vixie, die alom
> bekend staat als een expert op het gebied van DNS en die inzage heeft
> gehad in de mogelijke exploits, zwaarder dan jouw "het is mij nog steeds
> niet duidelijk"

Dat vind ik prima hoor. Alleen heb ik het niet over het al of niet
bestaan van een probleem, maar over dat het niet duidelijk is wat het
probleem is.

Zolang het niet duidelijk is onder welke omstandigheden er een probleem
is ga ik geen overdreven moeite doen om het te bestrijden. In mijn geval
bijvoorbeeld een DNS resolver die draait op een Linux versie waar geen
security updates meer voor uitkomen gaan proberen te vervangen door een van
source gecompileerde versie. Dat levert ook risico's op, en als straks
de aap uit de mouw komt en het in mijn netwerkconfiguratie helemaal niet
exploitabel is dan is alle moeite voor niks.

Bovendien wijst alles er op dat dit een probleem is waar een actieve
attack voor nodig is. Je moet een doelwit zijn. Dat is heel wat anders
dan een virus, worm of andere dreiging die zichzelf verspreidt naar
willekeurige slachtoffers. De kans dat je een doelwit bent is voorlopig
heel klein.

Kortom, met dit geheimzinnige gedoe en overdreven gewaarschuw bereik je
zeker niet iedereen. Mij niet, bijvoorbeeld.

Rob schreef:
> Chel van Gennip <chel-news@vangennip.nl> wrote:
>> Voor mij telt in zo'n geval de beoordeling door Paul Vixie, die alom
>> bekend staat als een expert op het gebied van DNS en die inzage heeft
>> gehad in de mogelijke exploits, zwaarder dan jouw "het is mij nog steeds
>> niet duidelijk"
>
> Dat vind ik prima hoor. Alleen heb ik het niet over het al of niet
> bestaan van een probleem, maar over dat het niet duidelijk is wat het
> probleem is.
>
> Zolang het niet duidelijk is onder welke omstandigheden er een probleem
> is ga ik geen overdreven moeite doen om het te bestrijden. In mijn geval
> bijvoorbeeld een DNS resolver die draait op een Linux versie waar geen
> security updates meer voor uitkomen gaan proberen te vervangen door een van
> source gecompileerde versie. Dat levert ook risico's op, en als straks
> de aap uit de mouw komt en het in mijn netwerkconfiguratie helemaal niet
> exploitabel is dan is alle moeite voor niks.
>
> Bovendien wijst alles er op dat dit een probleem is waar een actieve
> attack voor nodig is. Je moet een doelwit zijn. Dat is heel wat anders
> dan een virus, worm of andere dreiging die zichzelf verspreidt naar
> willekeurige slachtoffers. De kans dat je een doelwit bent is voorlopig
> heel klein.
>
> Kortom, met dit geheimzinnige gedoe en overdreven gewaarschuw bereik je
> zeker niet iedereen. Mij niet, bijvoorbeeld.

Dat de dreiging NIET geldt voor willekeurige slachtoffers, lijkt mij een
wat voorbarige conclusie. We hebben het hier over een op statistiek
gebaseerde aanval. Dan is het gebruik van een botnet om veel
eindgebruikers aan te vallen en een zeker percentage te oogsten een
realistische mogelijkheid. Waarschijnlijk zelfs kansrijker dan phishing
aanval via email op Postbank klanten die momenteel woedt.

--
Chel van Gennip (chel vangennip nl)

Chel van Gennip wrote on 21-7-2008 23:05:

> Dat de dreiging NIET geldt voor willekeurige slachtoffers, lijkt mij een
> wat voorbarige conclusie. We hebben het hier over een op statistiek
> gebaseerde aanval. Dan is het gebruik van een botnet om veel
> eindgebruikers aan te vallen en een zeker percentage te oogsten een
> realistische mogelijkheid. Waarschijnlijk zelfs kansrijker dan phishing
> aanval via email op Postbank klanten die momenteel woedt.

Omdat veel Nederlands thuisbankier zijn, zal het voor een aanvaller (met
een groot botnet) eenvoudig zijn om de nameservers in al die ADSL/kabel
modems te vergiftigen. Jij vraagt www.postbank.nl op en op een gegeven
moment komt de nameserver in je modem in de situatie dat informatie van
iets anders dan de nameserver van de Postbank wordt geaccepteerd als
juiste, edoch foute, antwoord. En met een zeer grote TTL zal jouw modem
je dat foute antwoord de komende dagen of weken blijven geven.

In het kort en a-technisch uitgelegd. De exacte manier waarop ga ik nog
niet publiek maken. Dat heeft iemand anders (per ongeluk?) al gedaan.

Peter

Peter Peters <p.g.m.peters@utwente.nl> wrote:
> Omdat veel Nederlands thuisbankier zijn, zal het voor een aanvaller (met
> een groot botnet) eenvoudig zijn om de nameservers in al die ADSL/kabel
> modems te vergiftigen. Jij vraagt www.postbank.nl op en op een gegeven
> moment komt de nameserver in je modem in de situatie dat informatie van
> iets anders dan de nameserver van de Postbank wordt geaccepteerd als
> juiste, edoch foute, antwoord. En met een zeer grote TTL zal jouw modem
> je dat foute antwoord de komende dagen of weken blijven geven.
>
> In het kort en a-technisch uitgelegd. De exacte manier waarop ga ik nog
> niet publiek maken. Dat heeft iemand anders (per ongeluk?) al gedaan.

Als ik het verhaal van CERT goed begrijp is het daarvoor nog steeds nodig
dat de attacker een request bij je caching DNS server kan doen. In geval
van een kabel of adsl modem is het niet zo waarschijnlijk dat hij dat kan
doen. Het enige wat eventueel zou kunnen is op een site van een hacker
een plaatje van de postbank site neer te zetten en dan als de site geladen
wordt meteen een DNS record te sturen. Maar dan moet je eerst die gebruiker
naar deze malafide site weten te lokken, en zelfs dan nog moet je heel goed
weten te timen want als het juiste antwoord eenmaal is gearriveerd zal je
modem dat doorsturen naar de gebruiker PC en als het allemaal goed
geprogrammeerd is zal hij daarna geen verdere antwoorden meer
aanpakken.
(ik neem aan dat dat wel goed zit anders was men niet met die port
randomization oplossing gekomen, maar was "fix eerst maar eens je
administratie van openstaande requests en validatie van de antwoorden"
een veel logischer fix geweest)

Ik denk dan ook dat de modems geen al te voor de hand liggend target zijn.
Een publiek toegankelijke caching resolver is een veel aannemelijker doel,
daar heeft CERT het ook over. Dan kan die attacker op een door hem uitgekozen
tijdstip een request en een reply sturen die met elkaar matchen, en dan zou
die cache het bewaren. Zelfs dan nog is er een parameter die aangeeft hoe
lang de cache het maximaal mag bewaren, die ik locaal al jaren op 2 uur heb
staan. Juist om onjuiste informatie spoedig te wissen, ook in geval van
niet malafide fouten. Ik neem aan dat veel beheerders van dergelijke machines
wel minstens net zo slim zijn.

Tenslotte is dit voor thuisbankieren niet echt een probleem. Thuisbankier
sites zijn altijd SSL sites en als je de DNS weet te verzieken dan komt
meteen de waarschuwing in beeld dat het certificaat niet klopt als er een
man-in-the-middle is.
Bovendien werken de banken hier allemaal met two-factor authenticatie. Zelfs
al weet je iemands Postbank user en password te ontfutselen dan nog kun je
niet overboeken want daarvoor heb je een TAN code nodig die per SMS of TAN
code sheet wordt verstuurd, waar je niet bij kunt. En in die SMS staat
ook het bedrag en cijfers van het rekeningnummer.

Om hiermee iets te doen heb je een behoorlijk onzorgvuldige gebruiker nodig
als slachtoffer. Dan kun je netzogoed gewoon een automatische afschrijving
doen of een factuur sturen "van het energiebedrijf" en dan maar afwachten
of men dit toelaat. Daar zullen ook wel mensen intrappen.

Als consumenten modems en routers een probleem waren dan had CERT die wel
nader genoemd.

On 2008-07-22, Rob <nomail@example.com> wrote:

> Ik neem aan dat veel beheerders van dergelijke machines wel minstens net
> zo slim zijn.

Die zijn veel slimmer. Die weten dat met je tengels aan dat soort parameters
zitten leidt tot het soort DNS waar A2000 infameus mee geworden is, en
blijven er dus met hun fikken af.

Als ik de TTL voor een RR op 300 seconden zet heb ik daar een reden voor. Dat jij
denkt het beter te weten is prima, maar je klanten zitten met de gebakken
peren. Die proberen bijna twee uur lang tegen een gecrashte machine uit mijn
loadbalancing cluster te kletsen.

--
Ruben

Harrison's Postulate: For every action, there is an equal and opposite criticism.

Rob wrote on 22-7-2008 13:51:

> Als ik het verhaal van CERT goed begrijp is het daarvoor nog steeds nodig
> dat de attacker een request bij je caching DNS server kan doen.

Dat is als de aanvaller zeker wil weten dat jij op dat moment een domein
opvraagt dat hij vergiftigd aan jou wil presenteren. Maar in dat geval
zul je te maken hebben met een aanvaller op je interne netwerk (want
alleen daar vandaan zou je toch requests moeten mogen doen?).

> In geval
> van een kabel of adsl modem is het niet zo waarschijnlijk dat hij dat kan
> doen.

Er zou zomaar een virus kunnen komen dat je dns vraagt om een bepaalde
site en dat direct meldt aan een machine in het botnet zodat die je de
verkeerde informatie kan voeren.

> (ik neem aan dat dat wel goed zit anders was men niet met die port
> randomization oplossing gekomen, maar was "fix eerst maar eens je
> administratie van openstaande requests en validatie van de antwoorden"
> een veel logischer fix geweest)

Bij DNS is het redelijk normaal dat je geen antwoord krijgt van de
server waar je de vraag aan stelt. Mede vanwege allerlei truucs om het
netwerk redundant, robust en snel te houden. En, zoals CERT/CC al zegt,
is DNSSEC (t.a.v. de validatie) de oplossing. Maar dan heb je een
wereldwijde PKI nodig.

> Tenslotte is dit voor thuisbankieren niet echt een probleem. Thuisbankier
> sites zijn altijd SSL sites en als je de DNS weet te verzieken dan komt
> meteen de waarschuwing in beeld dat het certificaat niet klopt als er een
> man-in-the-middle is.

Als je naar de nep postbank site gaat krijg je een nep certificaat
gekoppeld aan de postbank site. En omdat naam en certificaat hetzelfde
vertellen is de kans klein dat een gebruiker hier een probleem mee heeft.

En zelfs tegenwoordig worden gebruikers (zelfs door Microsoft) geleerd
dat self-signed certificaten geen enkel probleem zijn.

> Bovendien werken de banken hier allemaal met two-factor authenticatie. Zelfs
> al weet je iemands Postbank user en password te ontfutselen dan nog kun je
> niet overboeken want daarvoor heb je een TAN code nodig die per SMS of TAN
> code sheet wordt verstuurd, waar je niet bij kunt. En in die SMS staat
> ook het bedrag en cijfers van het rekeningnummer.

Het staat de beheerder van die nepsite volkomen vrij om de informatie
die jij denkt op te sturen naar de postbank ook echt daar naartoe te
sturen. Dus inclusief de door jou ingetoetste TAN-code. Dat is iets dat
al regelmatig gebruikt wordt door proxy's die op geinfecteerde machines
worden geinstalleerd.

Oja, er wordt natuurlijk ook een extra afschrijving naar de postbank
gestuurd. Die wordt weer verwijderd van de pagina die de postbank naar
jou terug stuurt.

> Om hiermee iets te doen heb je een behoorlijk onzorgvuldige gebruiker nodig
> als slachtoffer. Dan kun je netzogoed gewoon een automatische afschrijving
> doen of een factuur sturen "van het energiebedrijf" en dan maar afwachten
> of men dit toelaat. Daar zullen ook wel mensen intrappen.

Dan moet je weer lokaal aan de slag. Daarnaast is het net zo gemakkelijk
om reguliere download sites in je nameserver te proppen. Die sites
worden meestal wel vertrouwd, maar het is eenvoudig om die spullen dan
te infecteren voor ze bij jou uitkomen.

Peter