Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Sécurité Sécurité Sécurité Verisign, va bruler en enfer !

Verisign, va bruler en enfer !

91 réponses
Avatar
Alain Thivillon
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, 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.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3 4 5 6 7
Avatar
lavaurs.on.news
Alain Thivillon wrote in message news:...

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, ou il y a une belle page web avec un moteur de

recherche, et un serveur de mail qui refuse tout.





En lisant ce qui s'écrit sur tout ça, j'ai noté quelque part que
Verisign se défendait par un "on est pas les seuls à faire ça" ;
effectivement je viens de regarder ce qui se fait dans l'ensemble des
domaines par pays. Comme la liste des Méchants qui ont anticipé
Verisign ne m'est pas tombée sous la main par recherche Google
sommaire, je la publie ici pour les ceusses que ça intéresse (le nom
du gestionnaire du topLevel est disponible pour chacun à
http://www.iana.org/cctld/cctld-whois.htm ). Pour chacun je joins une
description de ce que renvoie une requête html.

com
64.94.110.11
Connexion impossible, victime de son succès !

net
64.94.110.11
Connexion impossible, victime de son succès !

ac (Ascension Island)
194.205.62.122
Une pub du vendeur des domaines .ac

cc (Cocos (Keeling) Islands)
206.253.214.102
Une pub du vendeur des domaines .cc

cx (Christmas Island)
219.88.106.80
Une pub du vendeur des domaines .cx, qui a au moins le mérite
d'expliquer
au visiteur comment il s'est retrouvé là.

mp (Northern Mariana Islands)
202.128.12.163
Semble une pub du vendeur des domaines .mp, assez cryptique.

nu (Niue)
64.55.105.9 212.181.91.6
Une pub du vendeur des domaines .nu ; explique vaguement comment on
s'est retrouvé là.

ph (Philippines)
203.119.4.6
Une pub du vendeur des domaines .ph ; un lien est proposé au passant
"venu là par accident" vers une recherche Google dans .ph

pw (Palau)
65.125.231.178 216.98.141.250
Celui-là est marrant : la promotion touristique de Palau.

sh (St Helena)
194.205.62.62
Une pub du vendeur des domaines .sh

td (Tchad)
146.101.245.154
Une pub du vendeur des domaines .td (prétendant que ça veut dire
"trade domains"...)

tk (Tokelau)
195.20.32.86 195.20.32.83
Une pub du vendeur des domaines .tk

tm (Turkmenistan)
194.205.62.42
Une pub du vendeur des domaines .tm

ws (Western Samoa)
216.35.187.246
Une pub du vendeur des domaines .ws (prétendant que ça veut dire "web
site")

Avatar
Eric Razny
"Paul GABORIT" a écrit dans le message de
news:
À (at) 16 Sep 2003 15:37:04 GMT,

Un autre document intéressant est la réponse de l'IAB :

<http://www.iab.org/Documents/icann-vgrs-response.html>


Merci pour le lien.
Effectivement il est interressant car non seulement il met l'accent sur des
problèmes de "choix" ("The DNS is not a search service, and presenting
speculative mappings based on HTTP inputs is not the service that the
registry is expected to provide.") mais aussi sur les problèmes techniques
que ça génère et les nombreuses violations des RFCs.

Comme Cédric le disait ailleurs dans ce même thread, verisign ne devrait
plus avoir le droit de gérer un root server.

Quand aux certifs ils ont déjà montré depuis longtemps leur incompétance[1]
ici aussi.

Eric

[1] quand on délivre des "vrais" certifs à des gens qui n'ont pas
d'habilitation j'appelle ça de l'incompétance. Ca devraient aussi refroidir
les ardeurs de certains qui ne jurent que par les certifs et les tiers de
confiance en oubliant toutes les implications de la mise en place de PKI.

Avatar
Eric Razny
"Pierre Lavaurs" a écrit dans le message de
news:
Alain Thivillon wrote in message
news:...


En lisant ce qui s'écrit sur tout ça, j'ai noté quelque part que
Verisign se défendait par un "on est pas les seuls à faire ça" ;
effectivement je viens de regarder ce qui se fait dans l'ensemble des
domaines par pays. Comme la liste des Méchants qui ont anticipé
Verisign ne m'est pas tombée sous la main par recherche Google
sommaire, je la publie ici pour les ceusses que ça intéresse (le nom
du gestionnaire du topLevel est disponible pour chacun à
http://www.iana.org/cctld/cctld-whois.htm ). Pour chacun je joins une
description de ce que renvoie une requête html.


[snap une série de tld assez "confidentiel"].

Une question complémentaire : existe-t-il un registrar unique pour ces
domaines? (contrairement aux domaines com et net).

Par contre les critiques concernant le non respect des RFCs reste
probablement valable.

Et comme moyen de défense, le "j'ai tué ma voisine parce que untel, untel et
untel l'ont fait aussi" c'est un peu léger, non?

--
Eric

Avatar
Eric Razny
"Philippe Chevalier" a écrit dans le message de
news:

Tu n'as pas tout vu. A cause de ca, spamassassin genere des
faux-positifs :

RCVD_IN_ORBS (0.5 points) RBL: Received via a relay in
orbs.dorkslayers.com

[RBL check: found
xxx.xxx.xxx.xxx.orbs.dorkslayers.com., type: 64.94.110.11]


Osirusoft et dorkslayers etant HS, tous les outils utilisant ces
serveurs pour verifier l'existence d'un openrelay se plantent en beauté
et considèrent des mails valides comme du spam.


Amusant oui. Il reste encore suffisament de DNSBL libre d'utilisation (et
gratuites) en activité, néanmoins.

Tous les mails entrants ont gagné 1 point a cause de ca.


oui mais bon, relays.osirusoft.com est dans les choux depuis longtemps et
une config MTA ça se suit un peu aussi, quand même (la config générale n'a
pas souvent l'occasion de bouger mais quand on utilise des ressources
externes ont s'abonne à des mailing-lists qui en parlent ou on regarde le
site de temps en temps, non?).

En plus les logs doivent hurler et enfler, et si les logs ne sont pas
suivis....
Mais bon, ça doit être chiant de perdre ses emails, même pour quelques
heures :(

Ceci dit ça donnera une probabilité supplémentaire pour que le gag verisign
ne passe pas inaperçu.

Eric

Avatar
Eric Razny
"Jerome" a écrit dans le message de
news:3f676810$0$27038$
"Alain Thivillon" wrote in message
news:

- Tous les mails avec des domaines incorrects que vos utilisateurs
envoient finissent chez eux.

[snap]

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


Pas pour la résolution faite par les MTA pour vérifier que le domaine
existe, et c'est chiant.
Par contre, effectivement, les emails ne finissent pas chez eux (je n'ajoute
pas "pour combien de temps" : ils sont cons mais la ils vont peut être
réfléchir aux conséquence -sinon d'image, apparement ce n'est pas ça qui les
gêne- sur leur serveurs.).

Eric


Avatar
Emmanuel Florac
Dans article <1g1eg5a.1fx8sdtiffuftN%,
disait...

En tout cas, avec la dictionnary attack que je me suis prise hier, j'ai
du contribuer des mes 10 Kbounces :-)



Toi aussi? Je connais quelqu'un qui a eu ça hier aussi (spamming de
toutes les adresses possibles en 3 et 4 lettres sur le domaine, MTA à
genoux, 50000 bounces en queue bloqués par Yahoo, l'enfer!), c'est la
nouvelle mode (dangereuse) du SPAM?

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Avatar
Jerome
"Cedric Blancher" wrote in message
news:

Ces mecs là ne méritent plus amha d'avoir un root server chez eux. Y'a
plein de monde qui gueule pour en avoir un autre en Europe, c'est peut
être l'occasion. Et ils méritent d'ailleurs encore moins que je leur
fasse confiance en matière de certification.


Malheureusement, ils restent toujours "operator" de la zone .com... Pour
qu'ils ne le soient plus, il faut soit que leur contrat avec l'ICANN expire,
ou que les Service Level Agreement (SLA) ne soient pas respectées... Je ne
les ai pas, mais si quelqu'un les avait ça serait cool de donner un lien.
Parce que dans les SLA, il devrait y avoir le respect des RFC, et là ce
n'est plus le cas...

Par exemple, un entrée DNS inexistante donne une réponse pour le champ A,
par contre, ce n'est pas le cas pour le champ SOA. Déjà ça, ça contredit les
RFC.
Ca peut avoir des conséquences imprévus, parce que les serveurs DNS n'ont
pas forcément prévu d'avoir un champ A pour un domain qui n'existe pas.. Ca
peut créer des bases corrompues etc... et donc ça peut poser des problèmes
de sécurité...

Maintenant si on ne peut plus truster les root servers pour leur compliance
RFC, ça devient grâve...

Une solution, irréalisable tellement elle demanderait que les internautes
fassent corps contre cela, serait de retirer tous les certificats de CA
Verisign de nos navigateur et d'informer les webmaster de sites qui


Très bonne idée!

Avatar
Stephane Catteau
Cedric Blancher nous disait récement dans fr.comp.securite
<news: :

Parce que bon, c'est quoi la prochain étape ? Monter un serveur
HTTPS qui fournit un certificat généré à la volée, signé par une
CA Verisign, pour répondre à une requête sur une erreur de nom de
domaine ? Commencer à filer du code signés à la volée de la même
manière sur ses sites pour qu'elles s'exécutent en catimini avec
des droits monstrueux ? Et pourquoi pas finallement monter tout un
service payant basé là dessus, comme un truc à but publicitaire
par exemple, avec son lot de spywares et de traceurs à gogo ?


Je pensais justement à un truc dans le genre. Avec toutes les failles
que l'on trouve au niveau de Windows et d'IE, et compte-tenu qu'il
s'agit du système d'exploitation le plus répandue, que la quasi
totalité de ces utilisateurs ne font pas ou presque de mises à jour de
sécurité[1], et que le système entier se tourne vers un "tout doit être
certifié", on arrive au final à quelque chose de monstrueux.
D'un côté Verisign va certifier que le code est correct, et de l'autre
le dit code va exploiter l'une des failles pour pomper un max
d'informations à caractère commerciales. Une petite faille sur "send",
et les utilisateurs de Windows auront droit à de la publicitée ciblée
et certifiée sur leur ordinateur.
Le pire dans tout cela étant que Verisign n'a même pas besoin de faire
le travail lui-même, avec le niveau de non confiance qu'ils viennent de
gagner, pourquoi ne se mettraient-ils pas à vendre des certificats aux
plus offrant, en échange par exemple d'une part du gateau...
D'ailleurs, quelqu'un peut-il me confirmer qu'ils ne le font pas déjà ?


Une solution, irréalisable tellement elle demanderait que les
internautes fassent corps contre cela, serait de retirer tous les
certificats de CA Verisign de nos navigateur et d'informer les
webmaster de sites qui proposent des certificats serveur délivrés
par Verisign qu'à la lumière de ce qui vient de se passer, nous ne
faisons plus confiance à Verisign pour la certification et que par
conséquent, nous ne pouvons pas considérer le certificat délivré
lors de l'accès au service comme un élément de sécurité
appréciable.


Ce n'est pas aussi irréalisable que cela. Enfin, la première partie
si, mais pour la seconde il suffirait d'une levée de bouclier de la
part des professionnels. Seuls les sociétés les plus robustes, celles
qui peuvent se permettre de perdre quelques clients à cause de cela,
peuvent initier le mouvement, et a elles seules elles représentent
beaucoup de monde.


[...] Cependant, cela ne fera que renforcer le pouvoir d'une ou deux
autres autorités de certification commerciales, et le problème
restera encore entier.


<utopie>
Ou alors il en sortira une entité indépendante à l'image de l'IAB (ou
bon, j'aurais pu trouver mieux ;-)) qui se chargera de la
certification.
</utopie>


[1]
Il ne s'agit ni d'anti-microsoftisme primaire, ni d'une dénigration
(ça se dit ? :-/) de ses utilisateurs, mais hélas d'un constat amère.
Merci donc de laisser les trolls de côté.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Avatar
Alain Thivillon
Par contre, effectivement, les emails ne finissent pas chez eux (je n'ajoute


Si. Vous avez essayé ? Parce que moi oui.

Avatar
Cedric Blancher
Dans sa prose, Stephane Catteau nous ecrivait :
D'un côté Verisign va certifier que le code est correct, et de l'autre
le dit code va exploiter l'une des failles pour pomper un max
d'informations à caractère commerciales.


Pourquoi s'emmerder à exploiter des failles ? Les failles, c'est bon pour
les gens qui ne peuvent justement pas produire de code signé et qui ont
besoin d'une manière détournée d'élever leur niveau de privilèges.
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.

--
Quand je pense qu'il y a quelque semaines j'avais complètement décroché de fmbl
Tu aurais dû t'inscrire aux fmbliques anonymes (il suffit de passer par

un proxy anonymisateur).
-+- JS in GFA : fmbl, c'est dur de décrocher. -+-

3 4 5 6 7