Onderwerp: DNS security probleem en ADSL/Kabel modems.

Chel van Gennip in nl.internet.providers (Wed, 23 Jul 2008 12:32:46
+0200):
>Onzin, TAN's op papier zijn veiliger op te bergen dan een mobiel, nog
>even los van de mogelijkheden om mobiel telefoonverkeer om te leiden of
>af te luisteren.

Dat is precies de reden, waarom ik zelf nog mijn TAN's op papier
ontvang. Maar Rob's argument was nu juist dat TAN's via een mobiel extra
zekerheid boden:

>In dat geval kloppen het rekeningnummer en/of het bedrag in de TAN SMS niet.

En kennelijk bevatten die elektronische Tannetjes niet eens het
rekeningnummer, getuige de reactie van Jasper Janssen.

Jan

The wise Chel van Gennip enlightened me with:
>
> Onzin, TAN's op papier zijn veiliger op te bergen dan een mobiel, nog
> even los van de mogelijkheden om mobiel telefoonverkeer om te leiden of
> af te luisteren.

Nou, dat is nu ook weer kort door de bocht. Een blaadje TAN codes hoef
je maar 1x te kopieren om een tijdje vooruit te kunnen. En
ongetwijfeld zijn er ook mensen die die dingen scannen en op een disk
zetten van een hackbare computer.
Ook kan je de SMS'jes vermoedelijk minder goed voorspellen. Die van de
blaadjes zullen vermoedelijk niet veel meer zijn dan een bepaalde random
number generator en een bepaalde seed die opgeslagen wordt per klant.
Maar dat staat dan ook 100 transacties vast.

Mark

Mark Huizer schreef:
> The wise Chel van Gennip enlightened me with:
>> Onzin, TAN's op papier zijn veiliger op te bergen dan een mobiel, nog
>> even los van de mogelijkheden om mobiel telefoonverkeer om te leiden of
>> af te luisteren.
>
> Nou, dat is nu ook weer kort door de bocht. Een blaadje TAN codes hoef
> je maar 1x te kopieren om een tijdje vooruit te kunnen. En
> ongetwijfeld zijn er ook mensen die die dingen scannen en op een disk
> zetten van een hackbare computer.

Ik schreef: "TAN's op papier zijn veiliger op te bergen" je kan er
natuurlijk ook slordig mee om gaan. In de praktijk gaan mensen echter
vaker slordig om met hun mobiel. Het is bijvoorbeeld hoogst
ongebruikelijk om een mobiel in een kluis te leggen. Bovendien, als we
het toch over domme fouten hebben, er zijn ook mensen die hun inlog
gegevens op hun mobiel opslaan, want dan heb je ze altijd eenvoudig bij
de hand.

> Ook kan je de SMS'jes vermoedelijk minder goed voorspellen. Die van de
> blaadjes zullen vermoedelijk niet veel meer zijn dan een bepaalde random
> number generator en een bepaalde seed die opgeslagen wordt per klant.
> Maar dat staat dan ook 100 transacties vast.

Het is een random nummer van 4 cijfers. Wat jij er verder bij vermoedt
doet niet ter zake. (Jouw vermoedens zijn niet onderbouwd door feiten en
wekken een vrij onzinnige indruk.)

--
Chel van Gennip (chel vangennip nl)

Jan Ehrhardt wrote:
> Chel van Gennip wrote:
> >In dat geval kloppen het rekeningnummer en/of het bedrag in de
> >TAN SMS niet.
>
> En kennelijk bevatten die elektronische Tannetjes niet eens
> het rekeningnummer, getuige de reactie van Jasper Janssen.

Bedoeld werd niet het rekeningnummer, maar het volgordenummer
van de transactie. Dat moet overeenstemmen met het transactie-
nummer op het scherm. Zo niet, dan is er stront aan de knikker.

-p

Piet Beertema wrote on 23-7-2008 14:57:
> Jan Ehrhardt wrote:
>> Chel van Gennip wrote:
>>> In dat geval kloppen het rekeningnummer en/of het bedrag in de
>>> TAN SMS niet.
>> En kennelijk bevatten die elektronische Tannetjes niet eens
>> het rekeningnummer, getuige de reactie van Jasper Janssen.
>
> Bedoeld werd niet het rekeningnummer, maar het volgordenummer
> van de transactie. Dat moet overeenstemmen met het transactie-
> nummer op het scherm. Zo niet, dan is er stront aan de knikker.

Als je in 1 keer 10 overboekingen indient, is dat dan 1 transactie?

Want in dat geval wil een crimineeltje nog wel eens een 11e overboeking
er tussendoor gooien via een MitM aanval. Hij filtert in de richting van
de klant die 11e overboeking eruit. Misschien dat hij bij het totaal wel
alle 11 telt. Wie gaat de optelling controleren? Dan klopt het
transactienummer en het totaalbedrag. Ik weet niet of er het aantal
overboekingen in wordt genoemd.

Peter

The wise Chel van Gennip enlightened me with:
>
> Ik schreef: "TAN's op papier zijn veiliger op te bergen" je kan er
> natuurlijk ook slordig mee om gaan. In de praktijk gaan mensen echter
> vaker slordig om met hun mobiel. Het is bijvoorbeeld hoogst
> ongebruikelijk om een mobiel in een kluis te leggen. Bovendien, als we
> het toch over domme fouten hebben, er zijn ook mensen die hun inlog
> gegevens op hun mobiel opslaan, want dan heb je ze altijd eenvoudig bij
> de hand.

Dat mobieltje hoef je maar een paar minuten goed te bewaken. Namelijk op
het moment dat je dat SMSje verwacht. De tijd ervoor en erna in principe
niet, want dan is dat token al weer irrelevant.
Waarom zou je het in een kluis willen opbergen in de tussentijd?

Of bedoel je "je raakt mobiel kwijt en ook je inlog gegevens aan
dezelfde persoon"? Da's inderdaad waar.

>> Ook kan je de SMS'jes vermoedelijk minder goed voorspellen. Die van de
>> blaadjes zullen vermoedelijk niet veel meer zijn dan een bepaalde random
>> number generator en een bepaalde seed die opgeslagen wordt per klant.
>> Maar dat staat dan ook 100 transacties vast.
>
> Het is een random nummer van 4 cijfers. Wat jij er verder bij vermoedt
> doet niet ter zake. (Jouw vermoedens zijn niet onderbouwd door feiten en
> wekken een vrij onzinnige indruk.)

Tsja, zo kan je het ook formuleren. Dat betekent dat jij beter weet hoe
dat zit. Leg het vooral even uit, ik ben wel geinteresseerd

Mark

Mark Huizer schreef:
> The wise Chel van Gennip enlightened me with:
>> Ik schreef: "TAN's op papier zijn veiliger op te bergen" je kan er
>> natuurlijk ook slordig mee om gaan. In de praktijk gaan mensen echter
>> vaker slordig om met hun mobiel. Het is bijvoorbeeld hoogst
>> ongebruikelijk om een mobiel in een kluis te leggen. Bovendien, als we
>> het toch over domme fouten hebben, er zijn ook mensen die hun inlog
>> gegevens op hun mobiel opslaan, want dan heb je ze altijd eenvoudig bij
>> de hand.
>
> Dat mobieltje hoef je maar een paar minuten goed te bewaken. Namelijk op
> het moment dat je dat SMSje verwacht. De tijd ervoor en erna in principe
> niet, want dan is dat token al weer irrelevant.
> Waarom zou je het in een kluis willen opbergen in de tussentijd?
>
> Of bedoel je "je raakt mobiel kwijt en ook je inlog gegevens aan
> dezelfde persoon"? Da's inderdaad waar.

Tja, dat lijkt een onwaarschijnlijk toeval, hoe zou dat kunnen?

Stel er is een DNS probleem, waardoor een buitenstaander inlog gegevens
kan achterhalen. Met die inloggegevens log je in. Als de saldi van
rekeningen of spaarrekeningen interessant genoeg zijn klikt je even op
"Service en instellingen" en daarna "06 gegevens" om te kijken of de
codes op een mobiel komen en om het nummer van het mobieltje te
achterhalen en daarna op "Adresgegevens" en je weet waar dat mobieltje
mogelijk te vinden is, en voor de zekerheid ook nog even op af- en
bijschrijvingen om te kijken wanneer het salaris gestort wordt. Je hebt
dan bij elkaar de inlog gegevens van een goed gevulde rekening, een
adres, de beste datum en het 06-nummer. Wat er daarna kan gebeuren kan
je nauwelijks meer toeval noemen.

Het lijkt mij een moment dat ik blij ben dat mijn TAN lijst veilig is
opgeborgen, en niet ergens in een lader staat.

--
Chel van Gennip (chel vangennip nl)

The wise Chel van Gennip enlightened me with:
> Mark Huizer schreef:
>> The wise Chel van Gennip enlightened me with:
>>> Ik schreef: "TAN's op papier zijn veiliger op te bergen" je kan er
>>> natuurlijk ook slordig mee om gaan. In de praktijk gaan mensen echter
>>> vaker slordig om met hun mobiel. Het is bijvoorbeeld hoogst
>>> ongebruikelijk om een mobiel in een kluis te leggen. Bovendien, als we
>>> het toch over domme fouten hebben, er zijn ook mensen die hun inlog
>>> gegevens op hun mobiel opslaan, want dan heb je ze altijd eenvoudig bij
>>> de hand.
>>
>> Dat mobieltje hoef je maar een paar minuten goed te bewaken. Namelijk op
>> het moment dat je dat SMSje verwacht. De tijd ervoor en erna in principe
>> niet, want dan is dat token al weer irrelevant.
>> Waarom zou je het in een kluis willen opbergen in de tussentijd?
>>
>> Of bedoel je "je raakt mobiel kwijt en ook je inlog gegevens aan
>> dezelfde persoon"? Da's inderdaad waar.
>
> Tja, dat lijkt een onwaarschijnlijk toeval, hoe zou dat kunnen?

Kan het ook zonder sarcasme? Dan krijg je namelijk gewoon gelijk,
aangezien ik nog niet aan die mogelijkheid gedacht had.

Mark

In article <4884abd7$0$49588$e4fe514c@news.xs4all.nl>, schreef ik:

> Echter, dat verklaart niet hoe je een client kun vervuilen,
> fascinerend. Nog maar 14 nachtjes slapen, dan weten we het.
>

Zo lang hoeven we niet slapen, zie <g688t2$pgs$1@sf1.isc.org>

Het is een beetje een anticlimax. De truuk is om mbv random subdomains
talloze queries te genereren die niet in de cache van de resolver zitten
en zodoende de resolver het net op te sturen. Elke query gaat vergezeld
van een nepantwoord met een leuke additional section en vroeg of laat heb
je dan beet.

Als je een ISP of zo bent en voor jan en alleman in recursie moet dan is
dit inderdaad een probleem, maar voor de rest van ons volstaat het om
allow-recursion af te knijpen en te zorgen dat de firewall geen queries
met gefingeerde afzender doorlaat.

In dit licht beschouwd is het niet echt urgent om modems die ook een
"Caching DNS resolver" of "DNS stub resolver" VOOR GEBRUIK OP HET LAN
aan boord hebben, te updaten, zolang ze alleen maar vanaf het LAN te
benaderen zijn.

In theorie kun je natuurlijk queries vanaf een LAN genereren door een
gebruiker op dat LAN naar een wegpagina te sturen die ongeveer dit doet:

<img src="hierkomtweerzonsukkel.badguy.biz">
<img src="sub1.targetdomain.tld">
<img src="sub2.targetdomain.tld">
..
<img src="sub9999.targetdomain.tld">

Maar op die manier is het lastig - maar niet onmogelijk - om de timing
van de responses goed te krijgen. Versie twee doet al een beetje aan
timing:


<img src="hierkomtweerzonsukkel.badguy.biz">
<img src="sub1.targetdomain.tld">
<img src="sub2.targetdomain.tld">
<img src="timingmark1.badguy.biz">
<img src="sub3.targetdomain.tld">
<img src="sub4.targetdomain.tld">
<img src="timingmark2.badguy.biz">
...
<img src="sub9999.targetdomain.tld">

Chel van Gennip wrote on 23-7-2008 20:15:
> Stel er is een DNS probleem, waardoor een buitenstaander inlog gegevens
> kan achterhalen. Met die inloggegevens log je in. Als de saldi van
> rekeningen of spaarrekeningen interessant genoeg zijn klikt je even op
> "Service en instellingen" en daarna "06 gegevens" om te kijken of de
> codes op een mobiel komen en om het nummer van het mobieltje te
> achterhalen en daarna op "Adresgegevens" en je weet waar dat mobieltje
> mogelijk te vinden is, en voor de zekerheid ook nog even op af- en
> bijschrijvingen om te kijken wanneer het salaris gestort wordt. Je hebt
> dan bij elkaar de inlog gegevens van een goed gevulde rekening, een
> adres, de beste datum en het 06-nummer. Wat er daarna kan gebeuren kan
> je nauwelijks meer toeval noemen.

Met de inloggegevens wijzig je toch gewoon even het 06 nummer. Voordat
je slachtoffer merkt dat het gewijzigd is, heb jij zijn rekening geleegd.

Peter

Dick Wesseling schreef:
> In article <4884abd7$0$49588$e4fe514c@news.xs4all.nl>, schreef ik:
>
>> Echter, dat verklaart niet hoe je een client kun vervuilen,
>> fascinerend. Nog maar 14 nachtjes slapen, dan weten we het.
>>
>
> Zo lang hoeven we niet slapen, zie <g688t2$pgs$1@sf1.isc.org>
>
> Het is een beetje een anticlimax. De truuk is om mbv random subdomains
> talloze queries te genereren die niet in de cache van de resolver zitten
> en zodoende de resolver het net op te sturen. Elke query gaat vergezeld
> van een nepantwoord met een leuke additional section en vroeg of laat heb
> je dan beet.
>
> Als je een ISP of zo bent en voor jan en alleman in recursie moet dan is
> dit inderdaad een probleem, maar voor de rest van ons volstaat het om
> allow-recursion af te knijpen en te zorgen dat de firewall geen queries
> met gefingeerde afzender doorlaat.
>
> In dit licht beschouwd is het niet echt urgent om modems die ook een
> "Caching DNS resolver" of "DNS stub resolver" VOOR GEBRUIK OP HET LAN
> aan boord hebben, te updaten, zolang ze alleen maar vanaf het LAN te
> benaderen zijn.
>
> In theorie kun je natuurlijk queries vanaf een LAN genereren door een
> gebruiker op dat LAN naar een wegpagina te sturen die ongeveer dit doet:
>
> <img src="hierkomtweerzonsukkel.badguy.biz">
> <img src="sub1.targetdomain.tld">
> <img src="sub2.targetdomain.tld">
> ..
> <img src="sub9999.targetdomain.tld">
>
> Maar op die manier is het lastig - maar niet onmogelijk - om de timing
> van de responses goed te krijgen. Versie twee doet al een beetje aan
> timing:
>
>
> <img src="hierkomtweerzonsukkel.badguy.biz">
> <img src="sub1.targetdomain.tld">
> <img src="sub2.targetdomain.tld">
> <img src="timingmark1.badguy.biz">
> <img src="sub3.targetdomain.tld">
> <img src="sub4.targetdomain.tld">
> <img src="timingmark2.badguy.biz">
> ...
> <img src="sub9999.targetdomain.tld">

Als dit inderdaad HET PROBLEEM is, dan zie ik niet zo veel problemen
voor modems. Mijn Fritz heeft een cache van 16kB en bewaart mislukte
request tot 5 minuten, is niet recursief en niet van buitenaf te
benaderen. Zelfs als het al zou lukken om een foute vertaling in de
cache te krijgen wordt die er door hetzelfde mechanisme (tienduizenden
requests voor niet bestaande domeinen) er razendsnel ook weer
uitgegooid. De gebruikte software dnsmasq-2.15 is inderdaad wel oud maar
niet zo kwetsbaar als je van de CERT zou moeten denken:
http://www.kb.cert.org/vuls/id/AAMN-7GDV56

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, 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.

--
Chel van Gennip (chel vangennip nl)

Peter Peters schreef:
> Chel van Gennip wrote on 23-7-2008 20:15:
>> Stel er is een DNS probleem, waardoor een buitenstaander inlog gegevens
>> kan achterhalen. Met die inloggegevens log je in. Als de saldi van
>> rekeningen of spaarrekeningen interessant genoeg zijn klikt je even op
>> "Service en instellingen" en daarna "06 gegevens" om te kijken of de
>> codes op een mobiel komen en om het nummer van het mobieltje te
>> achterhalen en daarna op "Adresgegevens" en je weet waar dat mobieltje
>> mogelijk te vinden is, en voor de zekerheid ook nog even op af- en
>> bijschrijvingen om te kijken wanneer het salaris gestort wordt. Je hebt
>> dan bij elkaar de inlog gegevens van een goed gevulde rekening, een
>> adres, de beste datum en het 06-nummer. Wat er daarna kan gebeuren kan
>> je nauwelijks meer toeval noemen.
>
> Met de inloggegevens wijzig je toch gewoon even het 06 nummer. Voordat
> je slachtoffer merkt dat het gewijzigd is, heb jij zijn rekening geleegd.
>

Daarbij wordt om een TAN gevraagd, in ieder geval is dat zo als je een
papieren TAN lijst hebt.


--
Chel van Gennip (chel vangennip nl)

On Wed, 23 Jul 2008 14:57:12 +0200, Piet Beertema
<www.godfatherof.nl/@opt-in.invalid> wrote:
>Jan Ehrhardt wrote:
>> Chel van Gennip wrote:
>> >In dat geval kloppen het rekeningnummer en/of het bedrag in de
>> >TAN SMS niet.
>>
>> En kennelijk bevatten die elektronische Tannetjes niet eens
>> het rekeningnummer, getuige de reactie van Jasper Janssen.
>
>Bedoeld werd niet het rekeningnummer, maar het volgordenummer
>van de transactie. Dat moet overeenstemmen met het transactie-
>nummer op het scherm. Zo niet, dan is er stront aan de knikker.

Maar dat volgnummer geeft alleen maar aan de hoeveelste TAN-code het is en
biedt nul (zéro points) bescherming tegen een MitM.

Jasper

On Wed, 23 Jul 2008 17:09:41 +0200, Peter Peters <p.g.m.peters@utwente.nl>
wrote:
>Piet Beertema wrote on 23-7-2008 14:57:
>> Jan Ehrhardt wrote:
>>> Chel van Gennip wrote:
>>>> In dat geval kloppen het rekeningnummer en/of het bedrag in de
>>>> TAN SMS niet.
>>> En kennelijk bevatten die elektronische Tannetjes niet eens
>>> het rekeningnummer, getuige de reactie van Jasper Janssen.
>>
>> Bedoeld werd niet het rekeningnummer, maar het volgordenummer
>> van de transactie. Dat moet overeenstemmen met het transactie-
>> nummer op het scherm. Zo niet, dan is er stront aan de knikker.
>
>Als je in 1 keer 10 overboekingen indient, is dat dan 1 transactie?

Yup.

>Want in dat geval wil een crimineeltje nog wel eens een 11e overboeking
>er tussendoor gooien via een MitM aanval. Hij filtert in de richting van
>de klant die 11e overboeking eruit. Misschien dat hij bij het totaal wel
>alle 11 telt. Wie gaat de optelling controleren? Dan klopt het
>transactienummer en het totaalbedrag. Ik weet niet of er het aantal
>overboekingen in wordt genoemd.

De MitM kan net zo goed (uitgaande ervan dat hij niet onder de radar wil
opereren) alle 10 overschrijvingen wel doorlaten, maar alleen bij allemaal
z'n eigen rekeningnummer invullen aan de postbank kant en ze netjes goed
laten zien aan de klant. De enige out-of-band communicatie waar de MitM
niet bijkan zegt helaas niets relevants om dat te blokkeren.

Het totaalbedrag zegt de PB wel expliciet dat je moet controleren, en dat
wordt ook op de tan invulpagina genoemd (check totaalbedrag en volgnummer,
vul dan de tan in).

Jasper

On 24 Jul 2008 03:33:16 GMT, free@securityaudit.val.newsbank.net (Dick
Wesseling) wrote:

>In article <4884abd7$0$49588$e4fe514c@news.xs4all.nl>, schreef ik:
>
>> Echter, dat verklaart niet hoe je een client kun vervuilen,
>> fascinerend. Nog maar 14 nachtjes slapen, dan weten we het.
>>
>
>Zo lang hoeven we niet slapen, zie <g688t2$pgs$1@sf1.isc.org>

http://www.jbip.net/content/text-man...kys-dns-attack

legt het wat extra uit.



Jasper