DNS security probleem en ADSL/Kabel modems.

On Thu, 24 Jul 2008 10:44:22 +0200, Chel van Gennip
<chel-news@vangennip.nl> wrote:

>Grote DNS-en lopen meer gevaar, maar daarbij zal vaker, omdat dit soort
>problemen al langer spelen, requests alleen vanaf het eigen netwerk
>toegestaan worden,

Een aantal jaren geleden kon je inderdaad nog de xs4all dns gebruiken op
het casema netwerk, en vice versa, maar inmiddels zijn de meeste ISP DNSen
al niet meer van buiten benaderbaar. Wel is dat natuurlijk nul beveiliging
-- iedere grote ISP moet er van uitgaan dat er Mallory's in hun
klantenbestand zitten. Wel is een attack dan terug te tracen en kan de
betreffende persoon netjes gekicked worden.

Op zich is het niet zo moeilijk om dus idd source port randomisation te
gebruiken en daarmee iets meer dan 15 bits extra bescherming bovenop de 16
te hebben.

Daarnaast is detecteren van deze sploit ook redelijk triviaal -- zoek naar
duizenden NXDOMAINS voor subdomains in hetzelfde domain.

Je ziet dat de sploit 140*10^3 tries nodig heeft om een 1-in-2^16 kans te
raken, dus blijkbaar zijn er maar een stuk of 5-7 van de 20 antwoorden die
hij per query stuurt binnen het goede timeframe. Als ie dus 1 op 2^31-2^32
heeft, met source port randomisation, dan duurt het 30-60.000 keer zo
lang, wat je al in de redelijk on-makkelijk sferen brengt.

Wat voor een ISP ook zou kunnen helpen, naast alleen eigen klanten
requests toelaten, is dns answers juist niet accepteren uit hun adsl
ranges[1]. Jammer voor die mensen die een authoritative dns server at home
draaien voor hun thuisdomeintjes, dus niet haalbaar voor Zakelijke
accounts, maar voor gewone ADSL moet dat niet zo'n issue zijn. De sploit
heeft het nodig dat de requests en de answers van dezelfde pc komen, ivm
timing. Als je moet gaan synchroniseren tussen een pc binnen de eigen
klanten en eentje extern om de answers te genereren wordt de timing
inherent gigantisch veel losser en dus moeilijker.

>en de eigen requests via een/enkele ander IP
>nummer(s) lopen dan de binnenkomende requests. Het spoofen van IP
>adressen op het eigen netwerk is normaliter ook al goed afgeschermd. Dat
>zijn eenvoudige regels in de firewall. Alleen dat al maakt dat een
>aanval zeer specifiek moet zijn en vrij lastig is. De voorgestelde
>verdediging (random poortnummer) lijkt mij bij de al aanwezige
>maatregelen ruim voldoende voor dit soort aanvallen op dit soort servers.

In ieder geval voorlopig. Hou wel rekening mee dat iedere keer dat netwerk
traffic 10 keer sneller wordt er weer 3 bits afvallen, dus tegen de 1-10
Tbit links wordt het weer praktisch om binnen een redelijke tijd uit te
voeren.


Jasper

[1] Moet je wel dns out gewoon helemaal blokkeren, want anders zijn de
domeintjes van je klantjes overal te benaderen behalve vanuit je eigen
netwerk, en dat werkt verwarrend.

Jasper Janssen wrote on 25-7-2008 12:58:

> Wat voor een ISP ook zou kunnen helpen, naast alleen eigen klanten
> requests toelaten, is dns answers juist niet accepteren uit hun adsl
> ranges[1]. Jammer voor die mensen die een authoritative dns server at home
> draaien voor hun thuisdomeintjes, dus niet haalbaar voor Zakelijke
> accounts, maar voor gewone ADSL moet dat niet zo'n issue zijn.

Dat helpt niet. De voorbeelden van aanvallen die ik heb gezien maken
gebruik van externe resolvers die reageren als een klant van de ISP
bepaalde websites bezoekt. Er zijn nog voldoende gebruikers die
mailclients gebruiken die automatisch de plaatsjes van de spam ophalen.
Vul de spam met enkele tientallen plaatjes, gooi een stapel redirects
richting die client en je hebt de tijd om de cache te proberen te vervuilen.

> De sploit
> heeft het nodig dat de requests en de answers van dezelfde pc komen, ivm
> timing. Als je moet gaan synchroniseren tussen een pc binnen de eigen
> klanten en eentje extern om de answers te genereren wordt de timing
> inherent gigantisch veel losser en dus moeilijker.

Je kunt de externe exploiter dus gewoon aansturen vanaf een PC "achter"
de kwetsbare nameserver.

Peter

Jasper Janssen schreef:
> On Thu, 24 Jul 2008 10:44:22 +0200, Chel van Gennip
> <chel-news@vangennip.nl> wrote:
>
>> Grote DNS-en lopen meer gevaar, maar daarbij zal vaker, omdat dit soort
>> problemen al langer spelen, requests alleen vanaf het eigen netwerk
>> toegestaan worden,
>
> Een aantal jaren geleden kon je inderdaad nog de xs4all dns gebruiken op
> het casema netwerk, en vice versa, maar inmiddels zijn de meeste ISP DNSen
> al niet meer van buiten benaderbaar. Wel is dat natuurlijk nul beveiliging
> -- iedere grote ISP moet er van uitgaan dat er Mallory's in hun
> klantenbestand zitten. Wel is een attack dan terug te tracen en kan de
> betreffende persoon netjes gekicked worden.
>
> Op zich is het niet zo moeilijk om dus idd source port randomisation te
> gebruiken en daarmee iets meer dan 15 bits extra bescherming bovenop de 16
> te hebben.
>
> Daarnaast is detecteren van deze sploit ook redelijk triviaal -- zoek naar
> duizenden NXDOMAINS voor subdomains in hetzelfde domain.
>
> Je ziet dat de sploit 140*10^3 tries nodig heeft om een 1-in-2^16 kans te
> raken, dus blijkbaar zijn er maar een stuk of 5-7 van de 20 antwoorden die
> hij per query stuurt binnen het goede timeframe. Als ie dus 1 op 2^31-2^32
> heeft, met source port randomisation, dan duurt het 30-60.000 keer zo
> lang, wat je al in de redelijk on-makkelijk sferen brengt.
>
> Wat voor een ISP ook zou kunnen helpen, naast alleen eigen klanten
> requests toelaten, is dns answers juist niet accepteren uit hun adsl
> ranges[1]. Jammer voor die mensen die een authoritative dns server at home
> draaien voor hun thuisdomeintjes, dus niet haalbaar voor Zakelijke
> accounts, maar voor gewone ADSL moet dat niet zo'n issue zijn. De sploit
> heeft het nodig dat de requests en de answers van dezelfde pc komen, ivm
> timing. Als je moet gaan synchroniseren tussen een pc binnen de eigen
> klanten en eentje extern om de answers te genereren wordt de timing
> inherent gigantisch veel losser en dus moeilijker.
>
>> en de eigen requests via een/enkele ander IP
>> nummer(s) lopen dan de binnenkomende requests. Het spoofen van IP
>> adressen op het eigen netwerk is normaliter ook al goed afgeschermd. Dat
>> zijn eenvoudige regels in de firewall. Alleen dat al maakt dat een
>> aanval zeer specifiek moet zijn en vrij lastig is. De voorgestelde
>> verdediging (random poortnummer) lijkt mij bij de al aanwezige
>> maatregelen ruim voldoende voor dit soort aanvallen op dit soort servers.
>
> In ieder geval voorlopig. Hou wel rekening mee dat iedere keer dat netwerk
> traffic 10 keer sneller wordt er weer 3 bits afvallen, dus tegen de 1-10
> Tbit links wordt het weer praktisch om binnen een redelijke tijd uit te
> voeren.
>
>
> Jasper
>
> [1] Moet je wel dns out gewoon helemaal blokkeren, want anders zijn de
> domeintjes van je klantjes overal te benaderen behalve vanuit je eigen
> netwerk, en dat werkt verwarrend.

Het zou goed zijn als DNS servers eindelijk eens stopten met het
accepteren van ongevraagde antwoorden. Deze bug is er weer een in de
trant van: hacker vraagt asqw1.eendomein.com
De DNS zoekt op asqw1.eendomein.com en krijgt een geforged antwoord:
asqw1.eendomein.com moet je vragen aan www.eendomein.com, en die heeft
het adres 123.45.67.89 met een TTL van heel lang.
Dat was een leuke performance winst in de tijd dat verbindingen 1200
baud waren, en er geen kwetsbare gegevens op het internet stonden.

DNS servers nu horen alleen het gevraagde antwoord te gebruiken, dus
"asqw1.eendomein.com moet je vragen aan www.eendomein.com" en daarna te
besluiten: Ik zoek zelf wel uit waar www.eendomein.com uithangt. Dus
gewoon ongevraagde informatie weggooien en alleen expliciet gevraagde
informatie te gebruiken. Dat kan internet bruin met gigabit verbindingen
best trekken. Dit gedrag mag volgens het protocol, en als men daar jaren
geleden al op overgestapt was, dan hadden we heel wat minder problemen
gehad. We moeten gewoon dit soort optimalisaties schrappen. Verder moet
een server naa één onjuist antwoord op een vraag, bijvoorbeeld verkeerd
sequence nummer, gelijk de vraag af te sluiten met NXDOMAIN, en de
hacker niet een tiental keren laten raden naar het juiste antwoord. Ook
UDP is foutvrij, dus één fout antwoord betekent stoppen met deze vraag.
Vrijwel alle fouten in DNS tot nu toe hadden te maken met het accepteren
van ongevraagde antwoorden en tolerantie bij fouten. Daarnaast kan het
geen kwaad de mogelijkheden van het protocol correct te gebruiken, dus
echte random getallen, en random poorten waar mogelijk. Ook moet alles
gecheckt worden wat gecheckt worden kan, dus komt het antwoord ook echt
van het IP adres waaraan ik de vraag gesteld heb?

--
Chel van Gennip (chel vangennip nl)

Chel van Gennip wrote on 25-7-2008 17:06:

> DNS servers nu horen alleen het gevraagde antwoord te gebruiken, dus
> "asqw1.eendomein.com moet je vragen aan www.eendomein.com" en daarna te
> besluiten: Ik zoek zelf wel uit waar www.eendomein.com uithangt. Dus
> gewoon ongevraagde informatie weggooien en alleen expliciet gevraagde
> informatie te gebruiken. Dat kan internet bruin met gigabit verbindingen
> best trekken. Dit gedrag mag volgens het protocol, en als men daar jaren
> geleden al op overgestapt was, dan hadden we heel wat minder problemen
> gehad.

Het is niet een soort optimalisatie. Natuurlijk krijgt je nameserver
bericht "voor eendomein.com moet je bij ns.eendomein.com zijn" (en niet,
zoals jij aangeeft "voor www.eendomein.com moet je bij ns.eendomein.com
zijn") En vervolgens vraagt hij aan ns.eendomein.com naar www.eendomein.com.

Maar bij grote organisaties (met veel nameservers) wil je toch een
load-balancing van je nameservers doen. Bij veel registries kun je maar
een beperkt aantal namesevers opgeven (meestal 3). Als je er echter veel
meer hebt, kun je je nameserver laten vertellen dat er naast de 3 die je
van de .com nameservers hebt gekregen er nog 10 zijn. Waarvan er
misschien wel een paar veel dichterbij.

Daarnaast kun je als bedrijf (van het formaat Google, Amazon e.d.) zelfs
besluiten om de vrager een lijstje IP adressen te geven die in zijn
buurt zitten. Zo hou je verkeer van en naar (bijvoorbeeld) Nederlandse
vragers in Nederland voor zowel de website als de nameserver queries.

> We moeten gewoon dit soort optimalisaties schrappen. Verder moet
> een server naa één onjuist antwoord op een vraag, bijvoorbeeld verkeerd
> sequence nummer, gelijk de vraag af te sluiten met NXDOMAIN, en de
> hacker niet een tiental keren laten raden naar het juiste antwoord.

Dat is een oplossing. Maar dan maak je het die hacker weer heel
eenvoudig om een DoS uit te voeren. Hij hoeft niet uit te kijken naar
welk antwoord hij geeft. Zolang hij er maar voor zorgt dat het verkeerde
antwoord eerder komt, krijgt jou nameserver het goede antwoord niet meer.

> Vrijwel alle fouten in DNS tot nu toe hadden te maken met het accepteren
> van ongevraagde antwoorden en tolerantie bij fouten. Daarnaast kan het
> geen kwaad de mogelijkheden van het protocol correct te gebruiken, dus
> echte random getallen, en random poorten waar mogelijk. Ook moet alles
> gecheckt worden wat gecheckt worden kan, dus komt het antwoord ook echt
> van het IP adres waaraan ik de vraag gesteld heb?

Dat is tegenwoordig de beste test. Firewalls werken ook op die manier.
Als ik aan IP adres 1.2.3.4 een query heb gedaan, laat de firewall
alleen maar nameserver antwoorden door vanaf 1.2.3.4.

Vroeger zag je nog regelmatig dat (bij loadbalanced nameservers met
backend database) een andere machine (of IP adres) het antwoord gaf dan
de machine waar je het aan vroeg. Vanwege een toenemend aantal firewalls
neemt dat aantal af.

Maar het helpt niet. UDP is connectionless, dus iemand kan eenvoudig het
IP adres van de nameserver waar jij je vraag aan stelt gebruiken. Dan
lijkt het toch weer van die partij af te komen. En ja, IP spoofing zou
dat tegen moeten houden, maar alleen uitgaand. En 80% van de providers
(of in ieder geval de providers met 80% van de aansluitingen) doen dat
niet. Vanwege hun grootte is het lastig om die spoofing regels bij te
houden iedere keer als ze een nieuwe IP range aanvragen en/of in gebruik
nemen.

Tot hoe diep wil je hier trouwens mee gaan? Ik weet dat sommige
(Nederlandse) providers dat tot op hun ADSL router hebben
geconfigureerd. Je komt het ADSL netwerk niet af als je niet je eigen IP
adres gebruikt. Maar veel grote providers weten niet altijd waar welk IP
adres uithangt. En weten soms ook niet hoe dat automatisch te
configureren is. ;)

Peter

On Fri, 25 Jul 2008 13:48:57 +0200, Peter Peters <p.g.m.peters@utwente.nl>
wrote:
>Jasper Janssen wrote on 25-7-2008 12:58:
>
>> Wat voor een ISP ook zou kunnen helpen, naast alleen eigen klanten
>> requests toelaten, is dns answers juist niet accepteren uit hun adsl
>> ranges[1]. Jammer voor die mensen die een authoritative dns server at home
>> draaien voor hun thuisdomeintjes, dus niet haalbaar voor Zakelijke
>> accounts, maar voor gewone ADSL moet dat niet zo'n issue zijn.
>
>Dat helpt niet. De voorbeelden van aanvallen die ik heb gezien maken
>gebruik van externe resolvers die reageren als een klant van de ISP
>bepaalde websites bezoekt. Er zijn nog voldoende gebruikers die
>mailclients gebruiken die automatisch de plaatsjes van de spam ophalen.
>Vul de spam met enkele tientallen plaatjes, gooi een stapel redirects
>richting die client en je hebt de tijd om de cache te proberen te vervuilen.

>> De sploit
>> heeft het nodig dat de requests en de answers van dezelfde pc komen, ivm
>> timing. Als je moet gaan synchroniseren tussen een pc binnen de eigen
>> klanten en eentje extern om de answers te genereren wordt de timing
>> inherent gigantisch veel losser en dus moeilijker.
>
>Je kunt de externe exploiter dus gewoon aansturen vanaf een PC "achter"
>de kwetsbare nameserver.

Dat zou kunnen, maar niet met *deze* sploit waar iedereen nu bang van is.

Deze sploit heeft in het voorbeeld dat wordt gegeven door de hacker zelf
7.000 requests nodig (allemaal verschillend) en stuurt per request 20
poison attempts.

Dit is *niet* praktisch met 20 requests uit een mailtje (want dan weet je
al heelmaal niet wanneer je je valse answers moet sturen) en *niet*
praktisch met een opgedeelde aanval omdat, zoals ik al zei, je timing dan
geheel in de soep loopt.

Jasper

On Fri, 25 Jul 2008 17:06:13 +0200, Chel van Gennip
<chel-news@vangennip.nl> wrote:
>Jasper Janssen schreef:

>Het zou goed zijn als DNS servers eindelijk eens stopten met het
>accepteren van ongevraagde antwoorden. Deze bug is er weer een in de
>trant van: hacker vraagt asqw1.eendomein.com
>De DNS zoekt op asqw1.eendomein.com en krijgt een geforged antwoord:
>asqw1.eendomein.com moet je vragen aan www.eendomein.com, en die heeft
>het adres 123.45.67.89 met een TTL van heel lang.
>Dat was een leuke performance winst in de tijd dat verbindingen 1200
>baud waren, en er geen kwetsbare gegevens op het internet stonden.

En dat is het nu nog steeds. Een query kan heel goed per level een ms of
100-200 kosten, als ie van ver moet komen, en dan is
www.sub1.sub2.domein.com al een halve seconde vertraging die je weg kunt
werken.

>DNS servers nu horen alleen het gevraagde antwoord te gebruiken, dus
>"asqw1.eendomein.com moet je vragen aan www.eendomein.com" en daarna te
>besluiten: Ik zoek zelf wel uit waar www.eendomein.com uithangt. Dus

Als jij op zoek gaat naar www.sub1.sub2.domein.com, dan krijg je van .com
door "domein.com moet je vinden bij ns1.domein.com". Maar je weet niet wie
ns1.domein.com is, want je bent nu net op zoek domein.com. Dus levert .com
je een glue record mee "ns1.domein.com heeft ip x". En dat kun je niet
zomaar negeren.

De aanval in kwestie gaat juist handig om met de bailiwick checking en
komt zo netjes binnen de bailiwick uit. Zelfs als je de bailiwick checking
sterker maakt kun je met een triviale aanpassing

>gewoon ongevraagde informatie weggooien en alleen expliciet gevraagde
>informatie te gebruiken. Dat kan internet bruin met gigabit verbindingen
>best trekken. Dit gedrag mag volgens het protocol, en als men daar jaren
>geleden al op overgestapt was, dan hadden we heel wat minder problemen
>gehad. We moeten gewoon dit soort optimalisaties schrappen. Verder moet
>een server naa één onjuist antwoord op een vraag, bijvoorbeeld verkeerd
>sequence nummer, gelijk de vraag af te sluiten met NXDOMAIN, en de
>hacker niet een tiental keren laten raden naar het juiste antwoord. Ook

Dat doen ze ook. Het is alleen niet alsof er maar 1 query gegenereerd
wordt.

>UDP is foutvrij,

No it isn't.

>dus één fout antwoord betekent stoppen met deze vraag.

DoSserts maak je het inderdaad meteen wel heel makkelijk.

>Vrijwel alle fouten in DNS tot nu toe hadden te maken met het accepteren
>van ongevraagde antwoorden en tolerantie bij fouten.

a) deze dus niet meer b) fouttolerantie is nog steeds *ontzettend*
belangrijk voor dns. Het internet as we know it kan niet zonder.

>Daarnaast kan het
>geen kwaad de mogelijkheden van het protocol correct te gebruiken, dus
>echte random getallen, en random poorten waar mogelijk.

Het eerste is ook iets waar iedereen het over eens is, maar er zijn wel
meer encryptie/security schemas die door een gebrekkige RNG gekraakt zijn.
Het laatste is pas recent nuttig geworden. De aanval die hier gedaan wordt
is een echte brute-force aanval die wordt mogelijk gemaakt door de zeer
snelle internet links van vandaag de dag.

>Ook moet alles
>gecheckt worden wat gecheckt worden kan, dus komt het antwoord ook echt
>van het IP adres waaraan ik de vraag gesteld heb?

Het gaat hier sowieso om antwoorden die geforged worden als zijnde van een
bepaald source IP. Het is niet alsof ze van ieder random IP een answer
accepteren. Maar source IPs forgen is nu eenmaal niet zo moeilijk (binnen
bepaalde beperkingen).


Jasper