Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
19 octobre 2013 6 19 /10 /octobre /2013 16:16

J'ai eu récemment un réel souci sur une machine perso : les navigateurs n'arrivaient plus à accéder au contenu Internet... alors que le ping marchait. Détails ci-dessous.

Machine (contexte perso) : Windows 7 SP1, tous correctifs, KAV 2014. Rappelons que que Windows Vista et ultérieurs, en 64 bits, ont des vérifications renforcées des pilotes (validité des certificats de signature).

NB : je n'avais pas installé l'outil EMET (durcissement sécurité)

 

Tout commence par un problème simple : ni Internet Explorer, ni Chrome n'arrivent à accéder à Internet ! subitement, sans prévenir...

HTTP_HS_KAV_181013.PNG

 

Pareil en HTTPS :

HTTPS_HS_KAV_181013.PNG

 

Pourtant, le ping (ICMP), marche, et comme j'ai demandé un FQDN, la résolution DNS aussi !

ping_OK_181013.PNG

Strange,  non ?

Il pourrait donc y avoir un souci dans la couche HTTP, notamment WinHTTP...

Il se trouve également que KAV a injecté dans chaque navigateur (IE/Chrome) des modules additionnels de contrôle de la navigation... A garder en tête pour la suite.

Le problème est tel que même la mise à jour de Chrome ne marche plus !

Chrome_MaJ_HS_181013.PNG

NB: oui la machine est connectée sur un routeur ADSL... et ICMP marche :(

 

KAV montre de son côté des symptômes de fatigue... l'ouverture de l'interface graphique via l'icône en barre de notification Windows, pédale dans la semoule...

 

gel_KAV_181013.PNG

La barre verte ne s'arrête jamais... Cela met la puce à l'oreille !

 

En cherchant bien, une fenêtre Windows (qui n'avait pas gardé le focus) indique un message d'alerte sécurité pour KAV :

confiance_kav_181013.PNG

 

Là, clairement, il y a un loup. Un tel message ne devrait pas apparaître !

Ici, impossible de s'en sortir sans redémarrer la machine : KAV ne s'ouvre pas, et même en "acceptant de faire confiance à l'éditeur" plusieurs fois, rien ne se débloque.

Redémarrons donc... :|

 

Au redémarrage, certains points s'éclaircissent :

KAV_obsolete_reboot_181013.PNG

 

Hmmm donc effectivement, il y a bien eu un dysfonctionnement car KAV devrait être parfaitement à jour vu que la machine était restée connectée à Internet pendant plusieurs heures, avant l'incident en question !

Je suspecte que l'alerte "faites-vous confiance à cet éditeur" ait bloqué des composants Internet à KAV, notamment la mise à jour et la surveillance du traffic HTTP des navigateurs, ceci donc impactant ma navigation par effet de bord !

 

Voici maintenant une petite vérification via l'utilitaire SigCheck de SysInternals (téléchargeable depuis la TechNet) :

sigcheck_sgantures_files_KAV_181013.PNG

 

Certains champs des certificats semblent vides...

J'espère que ce problème n'impactera pas une trop grande population. Je répète la solution : redémarrer et vous assurer que vous avez validé le message "faites-vous confiance à cet éditeur ?".

 

Mise à jour 1 :

Vérification supplémentaire avec SignTool, outil disponible dans le SDK de Windows :

signtool_kav_KO_19013.PNG

Bingo...

 

A bon entendeur...

PS : un article de KB à lire, pour tout admin ou personne impliquée dans la sécurité : http://technet.microsoft.com/en-us/library/cc733026.aspx#BKMK_Code_Local 

Attention à ce type de paramètres assez méconnus de la PKI standard de Windows (indépendante de la PKI propre à l'entité !)

 

Mise à jour 2 :

Ca continue !

kav_maj_err_151113.PNG

Les impacts sont assez pénibles : accès réseau totalement gelé, lenteurs système, et Windows donc qui alerte régulièrement sur KAV qui n'est pas à jour... 

Et au passage, quand je regarde de plus près le certificat, je vois qu'il utilise SHA1...!

kav_sha1_151113.PNG

 

Or SHA1 n'est plus un algo de condensat encore considéré comme fiable... Surprenant de le voir ici (sauf peut-être, pour des contraintes de perfs ?)

 

En fait, le problème n'est pas là, mais quelques crans plus haut !!

Voici le certificat de l'autorité racine de confiance :

KAV_TrustCA_md5_181113.PNG

 

Il apparaît que l'algo de hachage est ici le MD5.

Or Microsoft a publié récemment une mise à jour (2862966) qui, dans le cadre de la défense en profondeur, fait que la CryptoAPI refuse maintenant le MD5 pour les certificats !

Et évidemment, la mise à jour en question est bien installée sur la machine...

http://blogs.technet.com/b/askds/archive/2013/08/14/md5-signature-hash-deprecation-and-your-infrastructure.aspx

Il serait donc temps que GTE CyberTrust Global Root mette à jour ses certificats ! Ou que Kaspersky, d'ici là, se fasse signer ses fichiers par une autre autorité racine de confiance.

CQFD...?

 

Partager cet article

Repost0

commentaires