CVE-2014-3566 — Vulnérabilité POODLE

Posté par gnutux95 le 17 octobre 2014 à 07:26. Édité par Nÿco, bubar🦥, Davy Defaud, Xavier Teyssier, palm123 et Benoît Sibaud. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

oct.

2014

Qu’est‐ce POODLE ?

POODLE signifie Padding Oracle On Downgraded Legacy. Il s’agit d’une vulnérabilité permettant via une attaque de l’« homme du milieu » (MIM, Man In the Middle), en se plaçant entre le navigateur Web et le serveur Web, de déchiffrer les informations chiffrées.

POODLE affecte les anciennes normes de chiffrement, notamment Secure Socket Layer (SSL) version 3.0. Il n’affecte pas le mécanisme de chiffrement plus récent, et standardisé, appelé Transport Layer Security (TLS).

Recommandations

Pour atténuer cette vulnérabilité, désactivez SSL 3.0 en forçant l’utilisation de TLS, tout en vérifiant la compatibilité des navigateurs clients devant y avoir accès.

Plusieurs bulletins de sécurité ont annoncé la vulnérabilité :

alerte CERT : http://cert.ssi.gouv.fr/site/CERTFR-2014-ALE-007/ ;
alerte NVD : https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566.

Histoire et aides diverses

Google a identifié une faille dans le protocole SSL v3. Il existe des contournements côté serveurs comme côté clients : garder en tête la compatibilité avec les navigateurs clients. Red Hat n’a pour l’instant pas publié d’errata. Cela affecte RHEL5, RHEL6 et RHEL7, également les CentOS. À voir pour les autres distributions…

Remarque : poodle signifie caniche en anglais.

Page pour tester votre navigateur client

https://www.poodletest.com/

Tester par vous même

openssl s_client -connect mon_site:443 -ssl3

Configurer Apache

SSLProtocol All -SSLv2 -SSLv3

Configurer Postfix

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

Tester la vulnérabilité de vos sites

Voici le script proposé par Red Hat :

#!/bin/bash
#
# Copyright (C) 2014 by Dan Varga <dvarga@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.


host=$1
port=$2

if [ "$2" == "" ]
then
    port=443
fi

out="`echo x | timeout 5 openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
ret=$?

if [ $ret -eq 0 ]
then
    echo "VULNERABLE! SSLv3 detected."
    exit
elif [ $ret -eq 1 ]
then
    out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`
    if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ]
    then
        echo "Not Vulnerable. We detected that this server does not support SSLv3"
        exit
    fi
elif [ $ret -eq 124 ]
then
    echo "error: timeout connecting to host $host:$port"
    exit
fi
echo "error: Unable to connect to host $host:$port"

Aller plus loin

OpenSSL décrit POODLE (229 clics)
Préconisation Red Hat (184 clics)
Détection de la faille proposée par Red Hat (145 clics)
Piqûre de rappel TLS (277 clics)
Explication claire en français (681 clics)

# Précision que le `DLE` de `POODLE`

Posté par Burps le 17 octobre 2014 à 08:45. Évalué à 9.
Je pense qu'il manque une information sur cette attaque. Le Padding Oracle est sur SSL3.0. le Downgraded Legacy vient du comportement des clients. Le scénario est le suivant:
- le client se connecte et demande une connexion en TLS1.0 - TLS1.2 par exemple
- le MIM renvoie un refus de ces versions (cette partie n'est pas encore authentifiée)
- le client se reconnecte (c'est une choix d'implémentation ici - mais qui est très répandue) et demande alors du SSL3.0
Pour éviter ce scénario, une cipher suite vide a été rajoutée: TLS Fallback Signaling Cipher Suite Value (SCSV). Cf

http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
# Quelques ressources supplémentaires sur le sujet

Posté par Xavier Teyssier (site web personnel) le 17 octobre 2014 à 09:19. Évalué à 4.
- Le CVE : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
- Un autre article en français qui parle de Poodle : https://www.libwalk.so/2014/10/15/die-sslv3-die.html
- Pour les utilisateurs Red-Hat/CentOS, l'advisory qui va bien : https://access.redhat.com/security/cve/CVE-2014-3566
- Et pour Debian : https://security-tracker.debian.org/tracker/CVE-2014-3566
- Un article (en) avec une règle Snort pour détecter l'utilisation de SSLv3 sur votre réseau : http://blog.fox-it.com/2014/10/15/poodle/
- Une explication technique (en) et pourtant claire de Poodle : https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html
Pour savoir si un serveur accepte encore SSLv3, il y a par exemple la commande openssl citée ci-dessus, on peut aussi utiliser nmap :
nmap --script ssl-enum-ciphers -p https HOST

Un point sur lequel on n'insiste peut-être pas assez : ce problème n'est pas un bogue logiciel, pas un problème d'implémentation, mais bien un problème dans le protocole lui-même !
- [^] # Re: Quelques ressources supplémentaires sur le sujet
  
  Posté par Burps le 17 octobre 2014 à 10:00. Évalué à 4.
  
  Un point sur lequel on n'insiste peut-être pas assez : ce problème n'est pas un bogue logiciel, pas un problème d'implémentation, mais bien un problème dans le protocole lui-même !
  
  La partie MIM, quand même, personne n'obligeait les clients à se reconnecter en demandant SSL3.0, même si d'un point de vue client, être utilisable est prioritaire (TLS propose maintenant un mécanisme pour se protéger lorsqu'on désire avoir ce comportement, mais ce n'est pas un comportement impliqué par le protocole à mon avis).
  
  Pour la partie Padding Oracle, c'est en effet intrinsèque. Mais là, pas de surprise non plus. On sait maintenant que Mac-then-Encrypt est problématique. Je suis même étonné que cette attaque ne sort que maintenant.
  - [^] # Re: Quelques ressources supplémentaires sur le sujet
    
    Posté par Zenitram (site web personnel) le 17 octobre 2014 à 12:48. Évalué à 2.
    
    Je suis même étonné que cette attaque ne sort que maintenant.
    
    Pareil.
    en fait, je me demande où est la "nouveauté" : par design (partie non authetifiée, dont l'intégrité sur qui cause n'est pas testée, donc il modifie tout ce qu'il veut), un MITM peut choisir le protocole à utiliser en refusant les protocoles "trop sécurisés" et c'est le client qui passe de lui-même en une version plus faible.
    
    Le problème vient donc "juste" que SSLv3 est plus ou moins (il faut du temps quand même) troué est qu'il peut toujours être utilisé (il est accepté autant côté client que serveur), et donc ce problème apparait automatiquement (par design) dès qu'on a su que SSLv3 avait un problème.
    
    La nouveauté est-elle que quelqu'un a regardait comment fonctionnait la phase de négociation du protocole et s'en rendu compte que n'importe quel MITM peut choisir le protocole utilisé? C'est gros (car c'est assez basique), sutout qu'on aura alors exactement le même problème quand on aura TLSv2.0 et que TLSv1.x sera troué : qu'est-ce qui est prévu pour ne pas avoir le même problème plus tard? On redécouvrira cette faille de la négociation à ce moment-la (est-ce que TLSv1.3 a un mécanisme pour détecter que c'était pas le protocole qui été préféré par le client)?
    
    Ou alors, j'ai loupé un passage du problème, je n'arrive pas à comprendre. Quelqu'un pour expliquer en quoi ça ne fait pas partie du design de l'initialisation HTTPS qu'un MITM puisse décider quel protocole utiliser (quel mécanisme est mis en oeuvre pour sécuriser la liste des protocoles supportés qui est envoyée au serveur, et qui est ici cassé)?
    - [^] # Re: Quelques ressources supplémentaires sur le sujet
      
      Posté par Hobgoblins Master (Mastodon) le 17 octobre 2014 à 13:06. Évalué à 4.
      
      Concernant la rétrogradation de protocole, il y a ça : https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ qui est utilisé par OpenSSL dans le jeu de mises à jour de sécurité livré mercredi (https://www.openssl.org/news/secadv_20141015.txt). Mais encore à l’état de brouillon.
      - [^] # Re: Quelques ressources supplémentaires sur le sujet
        
        Posté par Zenitram (site web personnel) le 17 octobre 2014 à 13:22. Évalué à 3.
        
        Si j'ai bien compris (mais je suis vraiment pas à l'aise, n'hésitez pas à me corriger), c'est un ajout au protocole, donc tous les clients et serveurs actuels ne pourront pas tester, et il faut que les deux supportent cette extension, si un seul ça ne marche pas, exact?
        On parle quand même d'IE6 dans l'histoire (le seul encore dans la nature qui ne supporte pas TLS), donc des produits qui n'ont plus aucun support et donc aucune mise à jour, pas sûr qu'IE7 (TLS1.0) sera mis à jour…
        
        [^] # Re: Quelques ressources supplémentaires sur le sujet
        
        Posté par Kioob (site web personnel) le 17 octobre 2014 à 14:07. Évalué à 1.
        
        Si j'ai bien compris, pour cette fois c'est effectivement mort. Donc le cas d'IE6 me semble tranché.
        
        Mais cette faille met en évidence le problème que pose le «fallback» SSL/TLS de manière générale, et donc oui il est important d'y trouver une solution.
        En effet TLS 1.0 est lui aussi sensible à certaines attaques (BEAST par exemple), à priori de moins grande envergure, et il est dommage qu'il «suffise» de forcer les clients compatibles TLS 1.2 à basculer sur ce protocole.
        
        alf.life
        
        [^] # Re: Quelques ressources supplémentaires sur le sujet
        
        Posté par Hobgoblins Master (Mastodon) le 17 octobre 2014 à 14:08. Évalué à 3.
        
        Pour la faille actuelle, ça ne sert pas à grand chose sur les vieux systèmes puisqu’il faut en effet que client et serveur prennent en charge cette nouvelle extension (implémentée côté client comme un nouvel algorithme de chiffrement ajouté à la suite des autres). Par contre, elle devrait répondre à ta question concernant le futur passage à TLSv1.3 ou TLSv3, tant que la validation des messages ChangeCipherSpec et Finished n’est pas cassée (ils permettent de confirmer au pair que la poignée de main initiale et notamment la suite d’algorithmes de chiffrements supportés n’a pas été modifiée par un MITM).
        
        Pour IE6 et SSLv3, je crois qu’il n’y a plus rien à faire, SSLv3 était déjà connu pour ne pas être solide, là, c’est certainement le coup de grâce…
# Configurer Dovecot

Posté par jihele le 17 octobre 2014 à 10:28. Évalué à 8.

Dans conf.d/10-ssl-conf
ssl_protocols = !SSLv2 !SSLv3
# Mozilla

Posté par Spack le 17 octobre 2014 à 11:00. Évalué à 9.
A noter, l'excellent article sur le Wiki de Mozilla pour bien configurer son serveur Web.
https://wiki.mozilla.org/Security/Server_Side_TLS

Et en bonus, une petite commande pour avoir la liste des protocoles SSL utilisés en utilisant nmap :
```
$ nmap --script ssl-enum-ciphers -p 443 <IP>
```
- [^] # et aussi
  
  Posté par AgentSteel (site web personnel) le 18 octobre 2014 à 12:40. Évalué à 3.
  
  cet article :
  
  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
  
  qui est régulièrement mis à jour (pour Apache, nginx…)
- [^] # Re: Mozilla
  
  Posté par jve (site web personnel) le 18 octobre 2014 à 13:33. Évalué à 7.
  
  Je suis l'auteur du wiki de Mozilla. Merci pour la référence :)
  A voir aussi, l'outil cipherscan écrit pour rapidement lister les paramètres d'une connexion TLS. Moins poussé que SSL Labs, mais en console et plus rapide.
```
$ git clone https://github.com/jvehent/cipherscan.git && cd cipherscan && ./cipherscan google.com
……………….
Target: google.com:443

prio ciphersuite protocols pfs_keysize
1 ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 ECDH,P-256,256bits
2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits
3 ECDHE-RSA-AES128-SHA TLSv1.1,TLSv1.2 ECDH,P-256,256bits
4 ECDHE-RSA-RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
5 AES128-GCM-SHA256 TLSv1.2
6 AES128-SHA256 TLSv1.2
7 AES128-SHA TLSv1.1,TLSv1.2
8 RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
9 RC4-MD5 SSLv3,TLSv1,TLSv1.1,TLSv1.2
10 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits
11 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits
12 ECDHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
13 AES256-GCM-SHA384 TLSv1.2
14 AES256-SHA256 TLSv1.2
15 AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
16 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits
17 ECDHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
18 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2

Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
TLS ticket lifetime hint: 100800
OCSP stapling: not supported
Server side cipher ordering
```
  - [^] # Re: Mozilla
    
    Posté par jve (site web personnel) le 18 octobre 2014 à 13:59. Évalué à 5.
    
    Cipherscan contient également un script d’analyse des configuration pour aider a atteindre les trois niveaux proposes sur le wiki:
    
    $ ./analyze.py -l intermediate -t google.com
    google.com:443 has bad ssl/tls
    and DOES NOT comply with the 'intermediate' level
    
    Things that are really FUBAR:
    * remove cipher ECDHE-RSA-RC4-SHA
    * remove cipher RC4-SHA
    * remove cipher RC4-MD5
    
    Changes needed to match the intermediate level:
    * remove cipher ECDHE-RSA-CHACHA20-POLY1305
    * remove cipher ECDHE-RSA-RC4-SHA
    * remove cipher RC4-SHA
    * remove cipher RC4-MD5
    * remove cipher ECDHE-RSA-DES-CBC3-SHA
    * disable SSLv3
    * consider using a SHA-256 certificate
    * consider enabling OCSP Stapling
    
    A noter que Google.com maintient la compatibilité avec les vieux clients, comme windows XP pre-SP3 et java6, ce qui explique la présence de SSLv3, RC4 et un certificat a signature SHA-1.
  - [^] # Re: Mozilla
    
    Posté par neitsab le 18 octobre 2014 à 23:26. Évalué à 4.
    
    Merci à toi pour ce wiki, j'ai récemment mis en place mon premier serveur et j'étais justement en recherche de bonnes pratiques pour sécuriser nginx ! C'est génial de la part de Mozilla de partager ses recommandations (et de manière aussi détaillée), ça permet aux personnes qui n'ont pas l'expérience d'avoir un référentiel sur lequel s'appuyer : en effet quand on ne s'y connaît pas, il est pour le moins ardu de trouver une réponse qui fasse autorité parmi toutes les préconisations présentes sur le web…
    
    En parlant de bonnes pratiques : j'ai remarqué que dans l'exemple de configuration pour nginx donné sur le wiki, la directive ssl on; est utilisée. Or ayant justement récemment regardé la documentation officielle, il se trouve que celle-ci est considérée obsolète ; à la place il est recommandé d'utiliser le paramètre ssl de la directive listen. Je ne pense pas que cela change grand chose en termes de sécurité, mais ça fait toujours gagner une ligne…
    ;-)
# ProFTPd, NGinx

Posté par Adminrezo (site web personnel) le 17 octobre 2014 à 11:22. Évalué à 2.

Configurer ProFTPd

TLSProtocol TLSv1

Configurer NGinX

ssl_protocols -SSLv2 -SSLv3 TLSv1;
- [^] # Re: ProFTPd, NGinx
  
  Posté par Adminrezo (site web personnel) le 17 octobre 2014 à 11:53. Évalué à 2.
  
  Configurer OpenLDAP
  
  TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:!SSLv3
  - [^] # Re: Minepeon
    
    Posté par voxmundix le 17 octobre 2014 à 14:03. Évalué à 2. Dernière modification le 17 octobre 2014 à 14:05.
    
    Pour sécuriser le serveur de minepeon (arch):
    sudo nano /etc/httpd/conf/extra/httpd-ssl.conf
    
    Ajouter "SSLProtocol all -SSLv3" juste après "SSLEngine on" puis redémarrer.
  - [^] # Re: ProFTPd, NGinx
    
    Posté par Misc (site web personnel) le 17 octobre 2014 à 22:23. Évalué à 4.
    
    J'ai du mal à piger en quoi une attaque qui requiert que l'attaquant fasse des requetes actives ( ie, la partie ou le js intervient dans le papier ) va marcher pour openldap ?
    
    Quel client va poser souci, dans quels conditions ?
- [^] # Re: ProFTPd, NGinx
  
  Posté par ianux (site web personnel, Mastodon) le 17 octobre 2014 à 18:16. Évalué à 3. Dernière modification le 17 octobre 2014 à 18:18.
  
  Configurer Nginx
  
  Attention, les versions récentes de Nginx semblent ne plus supporter la soustraction de protocole mais uniquement l'explicitation (voir http://nginx.org/en/docs/http/configuring_https_servers.html). La bonne ligne serait donc :
  
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  - [^] # Re: ProFTPd, NGinx
    
    Posté par Antoine le 18 octobre 2014 à 02:02. Évalué à 3.
    
    C'est un peu bête, parce que le jour où TLS 1.3 est supporté par ta bibliothèque de crypto, tu n'en tires partie qu'à la condition de penser à modifier ton fichier de conf…
- [^] # Re: ProFTPd, NGinx
  
  Posté par neitsab le 18 octobre 2014 à 23:42. Évalué à 0.
  
  Configurer NGinX
  
  ssl_protocols -SSLv2 -SSLv3 TLSv1;
  
  Es-tu sûr que l'adjonction d'un - devant les protocoles à exclure soit la bonne manière de faire ?
  
  À la limite ajouter un ! devant comme pour ssl_ciphers, pourquoi pas, mais le plus simple ne serait-il pas de tout simplement mentionner uniquement les protocoles acceptés ? Et d'ailleurs, pourquoi exclure TLSv1.1 et TLSv1.2, qui sont les seuls à atténuer le risque d'attaque BEAST ?
  - [^] # Re: ProFTPd, NGinx
    
    Posté par neitsab le 18 octobre 2014 à 23:54. Évalué à 0.
    
    J'ai pris trop de temps pour éditer mon commentaire, le vilain sorcier de la page d'erreur m'a repoussé…
    
    L'édit que je voulais faire :
    
    J'aurais dû lire tous les commentaires, ianux répond déjà à ce sujet (et en plus le point d'exclamation dans les paramètres de ssl_ciphers semble être lié au format compris par openSSL).
    
    C'est un peu bête, parce que le jour où TLS 1.3 est supporté par ta bibliothèque de crypto, tu n'en tires partie qu'à la condition de penser à modifier ton fichier de conf…
    
    À tester : ajouter TLSv1.3 à la directive pour anticiper… Mais pas sûr que nginx accepte de se lancer s'il détecte une anomalie dans sa config (ça m'est arrivé pour moins que ça). Pour tester : $ nginx -t.
    - [^] # Re: ProFTPd, NGinx
      
      Posté par KiKouN le 22 octobre 2014 à 09:12. Évalué à 2.
      
      Cela ne résous pas le problème, On ne peut prédire les numéro de version de TLS pour les 10 ans à venir.
      - [^] # Re: ProFTPd, NGinx
        
        Posté par Sytoka Modon (site web personnel) le 22 octobre 2014 à 22:15. Évalué à 3.
        
        Mes fichiers de conf sont gérés par cfengine… Je fais un coup de sed lorsqu'il faut durcir la configuration de temps en temps et hop, c'est validé puis déployé (et versionné). Imaginer une conf qui puisse tenir 10 ans me semble une idée plus que fumeuse ;-)
- [^] # Re: ProFTPd, NGinx
  
  Posté par Kwiknclean le 21 octobre 2014 à 13:53. Évalué à 1.
  
  Je ne comprends pas j'ai effectué les modifications dans Nginx.
  
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  
  root@www-prod:/usr/local/etc/nginx/conf.d # service nginx restart
  Performing sanity check on nginx configuration:
  nginx: [warn] invalid value "TLSv1.3" in /usr/local/etc/nginx/conf.d/ssl:4
  nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
  
  Dans le cas ou l'on met TLSv1.3 effectivement il rale au check.
  
  En testant après modification avec le script fournit par Red Hat …
  
  Depuis l'extérieur :
  
  ~$ ./test-poodle.sh www.pentakonix.fr 443
  VULNERABLE! SSLv3 detected.
  
  Hein ?!
# Script

Posté par claudex le 19 octobre 2014 à 14:45. Évalué à 5.

Le script proposé n'est pas très pratique pour tester STARTTLS, du coup, j'ai fais un petit script en Python qui test SMTP, IMAP, POP, HTTPS sur l'hôte donnés (et on peut même spécifier un réseau pour tester tous les hôtes). C'est loin d'être parfait mais ça permet de faire le tour rapidement. Si vous avez des idées de ports à ajouter, n'hésitez pas. https://github.com/claudex/test-ssl

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Routeur

Posté par voxmundix le 19 octobre 2014 à 15:42. Évalué à 1. Dernière modification le 19 octobre 2014 à 15:44.

Les routeurs de belgacom (bbox2 je crois) sont faillible (ça ne m'étonne même pas…):

PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak
| TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 - weak
| TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 - weak
| TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_IDEA_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak
| TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 - weak
| TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 - weak
| TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_IDEA_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: weak
- [^] # Re: Routeur
  
  Posté par claudex le 19 octobre 2014 à 15:45. Évalué à 4.
  
  ça reste un service accessible uniquement en interne. Ça ne me semble pas si grave que ça.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Routeur
    
    Posté par voxmundix le 19 octobre 2014 à 15:51. Évalué à 2.
    
    Non tu peux tout a fait activer l'accès externe a l'interface d'administration (je pense que c'est pour cela que le NAT de belgacom bloque la redirection des ports 80 et 443).
    Mais si non pour les attaques MITM en interne bah c'est un moyen comme un autre de choper un accès admin au routeur. (bon reste a voir quel proportion d'utilisateur utilise https au lieu de http)
    - [^] # Re: Routeur
      
      Posté par claudex le 19 octobre 2014 à 15:57. Évalué à 4.
      
      Non tu peux tout a fait activer l'accès externe a l'interface d'administration (je pense que c'est pour cela que le NAT de belgacom bloque la redirection des ports 80 et 443).
      
      Je doute que ce soit très utilisé, et si tu en as absolument besoin, tu peux désactivé SSLv3 sur ton navigateur.
      
      Mais si non pour les attaques MITM en interne bah c'est un moyen comme un autre de choper un accès admin au routeur. (bon reste a voir quel proportion d'utilisateur utilise https au lieu de http)
      
      Vu que le certificat génère un gros warning sur les navigateurs, je doute que ceux qui y accède en https se rendent compte d'une attaque MitM si le certificat est différent. Du coup, ça me semble une attaque bien plus simple qu'utiliser Poodle.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

# script de test

Posté par Frogg le 20 octobre 2014 à 11:11. Évalué à 0. Dernière modification le 20 octobre 2014 à 11:58.

voici le script de Dan Varga modifié, pour être plus simple à l'utilisation et à la lecture

Script call = bash poodle.sh {serverIP} {serverPort}

#Sent variable (host & port)
host=$1
port=$2
# #If empty IP then set 127.0.0.1 as default
if [ -z $host ];then
host="127.0.0.1"
fi
if [ -z $port ];then
port=443
fi
#create the returned code
out="`echo x | timeout 5 openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
ret=$?
#create a switch statement on $ret, exploit depend on result code
case "$ret" in
0)
    echo "VULNERABLE! SSLv3 detected.";
;;
124)
    echo "error: timeout connecting to host $host:$port";
;;
1)
    out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`;
    if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ];then
        echo "Not Vulnerable. We detected that this server does not support SSLv3";exit
    fi  
;;
*)
    echo "warning: $ret isn't a valid code while connecting to host $host:$port";
;;
esac


# https://github.com/Fro99666/froggPoodler

# Pour désactiver SSL 3.0 dans votre firefox

Posté par Xavier Poinsard le 21 octobre 2014 à 15:37. Évalué à 1.

En attendant la version 34 (pour le 25 novembre), une extension permet de désactiver SSLv3 :
https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

Qu’est‐ce POODLE ?

Recommandations

Plusieurs bulletins de sécurité ont annoncé la vulnérabilité :

Histoire et aides diverses

Tester la vulnérabilité de vos sites

Aller plus loin

Configurer ProFTPd

Configurer NGinX

Configurer OpenLDAP

Configurer Nginx

Configurer NGinX

Qu’est‐ce POODLE ?