Depuis cette nuit Verisign (la registry, pas netsol) a mis un wildcard
A sur *.com et *.net : tout ce qui n'est pas enregistré arrive sur
64.94.110.11, ou il y a une belle page web avec un moteur de
recherche, et un serveur de mail qui refuse tout.
Conséquences:
- Toutes les urls avec un noms de domaine incorrect dans .com et .net
que tapent vos utilisateurs arrivent chez eux. Bonjour la confidentialité.
- Tous les mails avec des domaines incorrects que vos utilisateurs envoient
finissent chez eux. Actuellement ils bouncent des la phase SMTP, mais
rien ne dit qu'ils ne gardent pas dans une liste une jolie liste
de domaines à créer et d'adresses emetteur et destinataires.
- Plus grave : Tous les spammeurs vont pouvoir a nouveau utiliser
n'importe quoi dans leur enveloppe SMTP (il faut espérer que l'effet
de bord qui consistera a flooder le serveur de Verisign avec des
bounces sera suffisant pour qu'ils crevent la bouche ouverte).
*PIRE*, Verisign est present dans *tous* nos navigateurs, on peut
imaginer que les glorieux marketoïdes qui sont derriere tout ça
vont générer automatiquement des certificats SSL qui seront corrects
pour n'importe quelle faute de frappe.
La solution brutale:
- null router 64.94.110.11 (ca fait mal parce que les mails incorrects
vont rester des jours dans la file). C'est visiblement ce qu'ont
commencé à faire des ISPs.
- bloquer l'accès à 64.94.110.11 sur vos relais HTTP (facile).
- Pour les mails, c'est moins simple, je ne connais pas de
serveur de mail permettant de refuser de relayer des messages
sur l'adresse IP de destination.
Il y a aussi des patches de Bind en préparation visiblement.
J'en suis encore sur le cul, j'essaye de faire une liste des implications
éventuelles sur la sécurité, il y a surement des choses à creuser,
notamment au niveau du XSS.
Depuis cette nuit Verisign (la registry, pas netsol) a mis un wildcard A sur *.com et *.net : tout ce qui n'est pas enregistré arrive sur 64.94.110.11
Dans ce forum-ci furent écrits récements des articles sur l'utilisation de scripts pour tester ses machines après qu'une faile ait été rendue publique. Y a il un protocole de test pour ce problème ci ? A priori, je ferai quelque chose comme (mais je ne suis pas spécialiste) : 1 Démarez un navigateur/client web/client http. 2 Demandez l'adresse http:// .com/ (ce domaine n'existe pas, vérifié au 2003-09-17). 3 Vous tombez sur la page ..... 4 Si non, soit votre DNS n'a pas encore été mis à jour, soit sont gestionnaire a censuré « verisign».
De plus, si ce problème est si grave, serait-il possible de faire une annonce dans fr.comp.infosystemes.www.navigateurs, fr.comp.mail, fr.comp.reseaux.ip, fr.comp.securite, fr.misc.droit.internet ?
Bonjour,
Alain Thivillon écrivit dans l'article
<news:slrnbmdf2a.toq.at-2003-03@roadrunner.rominet.net>
Bonjour,
Depuis cette nuit Verisign (la registry, pas netsol) a mis un wildcard
A sur *.com et *.net : tout ce qui n'est pas enregistré arrive sur
64.94.110.11
Dans ce forum-ci furent écrits récements des articles sur l'utilisation de
scripts pour tester ses machines après qu'une faile ait été rendue
publique.
Y a il un protocole de test pour ce problème ci ?
A priori, je ferai quelque chose comme (mais je ne suis pas spécialiste) :
1 Démarez un navigateur/client web/client http.
2 Demandez l'adresse http:// .com/ (ce domaine n'existe pas,
vérifié au 2003-09-17).
3 Vous tombez sur la page .....
4 Si non, soit votre DNS n'a pas encore été mis à jour, soit sont
gestionnaire a censuré « verisign».
De plus, si ce problème est si grave, serait-il possible de faire une
annonce dans fr.comp.infosystemes.www.navigateurs, fr.comp.mail,
fr.comp.reseaux.ip, fr.comp.securite, fr.misc.droit.internet ?
Depuis cette nuit Verisign (la registry, pas netsol) a mis un wildcard A sur *.com et *.net : tout ce qui n'est pas enregistré arrive sur 64.94.110.11
Dans ce forum-ci furent écrits récements des articles sur l'utilisation de scripts pour tester ses machines après qu'une faile ait été rendue publique. Y a il un protocole de test pour ce problème ci ? A priori, je ferai quelque chose comme (mais je ne suis pas spécialiste) : 1 Démarez un navigateur/client web/client http. 2 Demandez l'adresse http:// .com/ (ce domaine n'existe pas, vérifié au 2003-09-17). 3 Vous tombez sur la page ..... 4 Si non, soit votre DNS n'a pas encore été mis à jour, soit sont gestionnaire a censuré « verisign».
De plus, si ce problème est si grave, serait-il possible de faire une annonce dans fr.comp.infosystemes.www.navigateurs, fr.comp.mail, fr.comp.reseaux.ip, fr.comp.securite, fr.misc.droit.internet ?
Erwan David
Fabien LE LEZ écrivait :
On 16 Sep 2003 14:57:31 GMT, Erwan David wrote:
DOnc il est interdit de donner accès à un .com ou un .net depuis l'UE...
A un .com ou un .net _invalide_, plus exactement.
À un .com ou un .net ne publiant pas de DNS. Car on peut avoir un domaine, mais pas de DNS pour ce domaine (juste pour éviter le cybersquatting).
Par ailleurs j'ai constaté que ces jean-foutres sur les ports autres que 80 et 25 font du drop.
Conclusion les autres applis qui auraient un mauvais .com ou .net doivent tomber en timeout...
Fabien LE LEZ <gramster@gramster.com> écrivait :
On 16 Sep 2003 14:57:31 GMT, Erwan David <erwan@rail.eu.org> wrote:
DOnc il est interdit de donner accès à un .com ou un .net depuis
l'UE...
A un .com ou un .net _invalide_, plus exactement.
À un .com ou un .net ne publiant pas de DNS.
Car on peut avoir un domaine, mais pas de DNS pour ce domaine (juste
pour éviter le cybersquatting).
Par ailleurs j'ai constaté que ces jean-foutres sur les ports autres
que 80 et 25 font du drop.
Conclusion les autres applis qui auraient un mauvais .com ou .net
doivent tomber en timeout...
DOnc il est interdit de donner accès à un .com ou un .net depuis l'UE...
A un .com ou un .net _invalide_, plus exactement.
À un .com ou un .net ne publiant pas de DNS. Car on peut avoir un domaine, mais pas de DNS pour ce domaine (juste pour éviter le cybersquatting).
Par ailleurs j'ai constaté que ces jean-foutres sur les ports autres que 80 et 25 font du drop.
Conclusion les autres applis qui auraient un mauvais .com ou .net doivent tomber en timeout...
Erwan David
"Jerome" écrivait :
"Alain Thivillon" wrote in message news:
- Tous les mails avec des domaines incorrects que vos utilisateurs envoient
finissent chez eux. Actuellement ils bouncent des la phase SMTP, mais rien ne dit qu'ils ne gardent pas dans une liste une jolie liste de domaines à créer et d'adresses emetteur et destinataires.
Les champs MX ne semblent pas concernés, pour l'instant seuls les champs A ont un wildcard d'après ce que j'ai vu... Donc on est épargné pour les mails pour le moment...
Non, car en l'absence de MX un A est un MX implicite.
"Jerome" <abc@abc.com> écrivait :
"Alain Thivillon" <at@rominet.net> wrote in message
news:slrnbmdf2a.toq.at-2003-03@roadrunner.rominet.net...
- Tous les mails avec des domaines incorrects que vos utilisateurs
envoient
finissent chez eux. Actuellement ils bouncent des la phase SMTP, mais
rien ne dit qu'ils ne gardent pas dans une liste une jolie liste
de domaines à créer et d'adresses emetteur et destinataires.
Les champs MX ne semblent pas concernés, pour l'instant seuls les champs A
ont un wildcard d'après ce que j'ai vu... Donc on est épargné pour les mails
pour le moment...
Non, car en l'absence de MX un A est un MX implicite.
- Tous les mails avec des domaines incorrects que vos utilisateurs envoient
finissent chez eux. Actuellement ils bouncent des la phase SMTP, mais rien ne dit qu'ils ne gardent pas dans une liste une jolie liste de domaines à créer et d'adresses emetteur et destinataires.
Les champs MX ne semblent pas concernés, pour l'instant seuls les champs A ont un wildcard d'après ce que j'ai vu... Donc on est épargné pour les mails pour le moment...
Non, car en l'absence de MX un A est un MX implicite.
lfrigault
In article , Michel Guillou writes:
Il n'y a pas de MX, donc les mails envoyés finissent sur le A.
ont un wildcard d'après ce que j'ai vu... Donc on est épargné pour les mails pour le moment... Non.
Pourtant j'ai encore des reject_unknown_sender_domain.
Moi aussi.
Dans le cas des .COM|.NET, les quelques exemples que j'ai vérifiés correspondaient à des sous-domaines de domaines existant ou des domaines existant dont les DNS déclarés étaient en panne (SERVFAIL).
Lolo -- Laurent Frigault - NOC GANDI
In article <3f6a099d.489612265@news.neottia.net>,
Michel Guillou <mg@neottia.net> writes:
Il n'y a pas de MX, donc les mails envoyés finissent sur le A.
ont un wildcard d'après ce que j'ai vu... Donc on est épargné pour
les mails pour le moment...
Non.
Pourtant j'ai encore des reject_unknown_sender_domain.
Moi aussi.
Dans le cas des .COM|.NET, les quelques exemples que j'ai vérifiés
correspondaient à des sous-domaines de domaines existant ou des domaines
existant dont les DNS déclarés étaient en panne (SERVFAIL).
Il n'y a pas de MX, donc les mails envoyés finissent sur le A.
ont un wildcard d'après ce que j'ai vu... Donc on est épargné pour les mails pour le moment... Non.
Pourtant j'ai encore des reject_unknown_sender_domain.
Moi aussi.
Dans le cas des .COM|.NET, les quelques exemples que j'ai vérifiés correspondaient à des sous-domaines de domaines existant ou des domaines existant dont les DNS déclarés étaient en panne (SERVFAIL).
Lolo -- Laurent Frigault - NOC GANDI
Eric Razny
"Alain Thivillon" a écrit dans le message de news:
Par contre, effectivement, les emails ne finissent pas chez eux (je n'ajoute
Si. Vous avez essayé ? Parce que moi oui.
Effectivement. Je n'avais pas pris le temps de tester. Bien que le A est pris comme MX par défaut je n'osais pas imaginer qu'ils aient un service dessus :-(
Pire, ce n'est pas un MTA mais une merde écrite à la va vite qui ne respecte pas les RFCs.
Après quelques tests on s'aperçoit vite que ça ne teste même pas l'entrée :
220 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 ready trop con verisign 250 OK meme pas fichu de respecter 250 OK les rfc 550 User domain does not exist. baleze non? 250 OK et ces gens emettent des certificats!!! 221 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Donc je retire ce que j'ai dis : ils sont assez con pour... !
Eric.
"Alain Thivillon" <at@rominet.net> a écrit dans le message de
news:slrnbmflc2.eh.at-2003-03@roadrunner.rominet.net...
Par contre, effectivement, les emails ne finissent pas chez eux (je
n'ajoute
Si. Vous avez essayé ? Parce que moi oui.
Effectivement. Je n'avais pas pris le temps de tester. Bien que le A est
pris comme MX par défaut je n'osais pas imaginer qu'ils aient un service
dessus :-(
Pire, ce n'est pas un MTA mais une merde écrite à la va vite qui ne respecte
pas les RFCs.
Après quelques tests on s'aperçoit vite que ça ne teste même pas l'entrée :
220 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 ready
trop con verisign
250 OK
meme pas fichu de respecter
250 OK
les rfc
550 User domain does not exist.
baleze non?
250 OK
et ces gens emettent des certificats!!!
221 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission
channel
Donc je retire ce que j'ai dis : ils sont assez con pour... !
"Alain Thivillon" a écrit dans le message de news:
Par contre, effectivement, les emails ne finissent pas chez eux (je n'ajoute
Si. Vous avez essayé ? Parce que moi oui.
Effectivement. Je n'avais pas pris le temps de tester. Bien que le A est pris comme MX par défaut je n'osais pas imaginer qu'ils aient un service dessus :-(
Pire, ce n'est pas un MTA mais une merde écrite à la va vite qui ne respecte pas les RFCs.
Après quelques tests on s'aperçoit vite que ça ne teste même pas l'entrée :
220 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 ready trop con verisign 250 OK meme pas fichu de respecter 250 OK les rfc 550 User domain does not exist. baleze non? 250 OK et ces gens emettent des certificats!!! 221 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Donc je retire ce que j'ai dis : ils sont assez con pour... !
Eric.
Stephane Catteau
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
[...] Mais dans le cas présent, le fait de pouvoir signer le code avec un certificat valide représente une élévation de privilèges suffisante.
Euh oui, pourquoi ai-je parlé des failles ? :-( Alors qu'ils peuvent avoir tellement plus d'informations en utilisant les voies prévues pour.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Cedric Blancher nous disait récement dans fr.comp.securite
<news:pan.2003.09.17.05.40.18.789070@cartel-securite.fr> :
[...] Mais dans le cas présent, le fait de pouvoir signer le code
avec un certificat valide représente une élévation de privilèges
suffisante.
Euh oui, pourquoi ai-je parlé des failles ? :-( Alors qu'ils peuvent
avoir tellement plus d'informations en utilisant les voies prévues
pour.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry
VeriSign décrébilise l'ensemble du système, connue de longue date pour son business de requin, zéro-conscience, avocats, max de dollars.
Et c'est là que Microsoft pourra nous ressortir son Passport du chapeau pour sauver le monde :(
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Erwan David
(Jean-Yves Bernier) écrivait :
Je serais fort étonné que les spécialistes de la chose ne nous pondent pas un patch qui refuse les wildcards au toplevel, ou toute autre contre-mesure ou escalade de contre-mesures.
bind 9.2rc3 : possibilité de définir des zones pourlesquelles les seules réponses admises sont NS.
Je serais fort étonné que les spécialistes de la chose ne nous pondent
pas un patch qui refuse les wildcards au toplevel, ou toute autre
contre-mesure ou escalade de contre-mesures.
bind 9.2rc3 : possibilité de définir des zones pourlesquelles les
seules réponses admises sont NS.
Je serais fort étonné que les spécialistes de la chose ne nous pondent pas un patch qui refuse les wildcards au toplevel, ou toute autre contre-mesure ou escalade de contre-mesures.
bind 9.2rc3 : possibilité de définir des zones pourlesquelles les seules réponses admises sont NS.
Thomas Pedoussaut
Jean-Yves Bernier wrote:
Je serais fort étonné que les spécialistes de la chose ne nous pondent pas un patch qui refuse les wildcards au toplevel, ou toute autre contre-mesure ou escalade de contre-mesures.
L'ISC (les codeurs de Bind) a dejà pondu le sien: http://www.isc.org/products/BIND/delegation-only.html
Je connais pas la proportionexacte de Bind parmis les resolveurs, mais on doit avoisiner les 90% versions 8 et 9 confondues.
Bref un patch "officiel" de bind, donc qui sera maintenu au fil des verisons, avec une entrée de conf ad-hoc. (Enfin 2, un pour .com et une pour .net)
-- Thomas Pedoussaut Dublin IRLANDE http://irlande.staffeurs.org/
Jean-Yves Bernier wrote:
Je serais fort étonné que les spécialistes de la chose ne nous pondent
pas un patch qui refuse les wildcards au toplevel, ou toute autre
contre-mesure ou escalade de contre-mesures.
L'ISC (les codeurs de Bind) a dejà pondu le sien:
http://www.isc.org/products/BIND/delegation-only.html
Je connais pas la proportionexacte de Bind parmis les resolveurs, mais
on doit avoisiner les 90% versions 8 et 9 confondues.
Bref un patch "officiel" de bind, donc qui sera maintenu au fil des
verisons, avec une entrée de conf ad-hoc. (Enfin 2, un pour .com et une
pour .net)
--
Thomas Pedoussaut
Dublin IRLANDE
http://irlande.staffeurs.org/
Je serais fort étonné que les spécialistes de la chose ne nous pondent pas un patch qui refuse les wildcards au toplevel, ou toute autre contre-mesure ou escalade de contre-mesures.
L'ISC (les codeurs de Bind) a dejà pondu le sien: http://www.isc.org/products/BIND/delegation-only.html
Je connais pas la proportionexacte de Bind parmis les resolveurs, mais on doit avoisiner les 90% versions 8 et 9 confondues.
Bref un patch "officiel" de bind, donc qui sera maintenu au fil des verisons, avec une entrée de conf ad-hoc. (Enfin 2, un pour .com et une pour .net)
-- Thomas Pedoussaut Dublin IRLANDE http://irlande.staffeurs.org/
