BREACH - une nouvelle attaque contre HTTP. Ce qui peut être fait?
Dans la continuité de CRIME, nous avons maintenant VIOLATION qui sera présenté au Black Hat à Las Vegas jeudi (aujourd'hui). À partir de l'article lié, il suggère que cette attaque contre la compression ne sera pas aussi simple à désactiver que pour dissuader CRIME. Que peut-on faire pour atténuer cette dernière attaque contre HTTP?
EDIT: Les présentateurs de BREACH ont mis un site Web avec plus de détails. Les atténuations énumérées sont les suivantes:
- Désactiver la compression HTTP
- Séparer les secrets de l'entrée utilisateur
- Randomisation des secrets par demande
- Masquer les secrets
- Protection des pages vulnérables avec CSRF
- Longueur masquée
- Demandes de limitation de débit
(note - également édité le titre et la question d'origine pour clarifier cette attaque est contre HTTP qui peut être crypté, pas spécifiquement HTTPS)
Bien que l'article ne soit pas plein de détails, nous pouvons en déduire quelques éléments:
L'attaque utilise la compression avec le même principe général que CRIME : l'attaquant peut obliger un système cible à compresser une séquence de caractères qui comprend à la fois une valeur secrète (que l'attaquant tente de deviner) et certains personnages que l'attaquant peut choisir. C'est une attaque en texte clair choisie . La longueur compressée dépendra si la chaîne de l'attaquant "ressemble" ou non au secret. La longueur compressée fuit via le cryptage SSL, car le cryptage masque contenu, pas longueur.
L'article parle spécifiquement de "tout secret qui se trouve [...] dans le corps". Nous parlons donc de compression de niveau HTTP, pas de compression de niveau SSL. La compression HTTP s'applique uniquement au corps de la demande, pas à l'en-tête. Donc secrets dans l'en-tête, en particulier les valeurs des cookies, sont à l'abri de celui-là.
Puisqu'il y a des "demandes de sonde", l'attaque nécessite du code malveillant dans le navigateur client; l'attaquant doit également observer les octets chiffrés sur le réseau et coordonner les deux éléments. Il s'agit de la même configuration que pour CRIME et BEAST.
Il n'est pas clair (à partir de l'article seul, qui est tout ce que j'ai en ce moment à discuter) si le corps compressé est celui du client ou du serveur =. La "demande de sonde" est certainement envoyée par le client (au nom de l'attaquant) mais les réponses du serveur peuvent inclure une partie de celle qui est envoyée dans la demande, donc "l'attaque en texte clair choisie" peut fonctionner dans les deux sens.
Dans tous les cas, "BREACH" ressemble à une attaque méthodologie qui doit être adaptée au cas spécifique d'un site cible. En ce sens, ce n'est pas nouveau du tout; il était déjà "bien connu" que la compression fuit des informations et il n'y avait aucune raison de croire que la compression de niveau HTTP était magiquement immunisée. Heck, il a été discuté ici l'année dernière. C'est une bonne chose, cependant, que certaines personnes fassent un effort supplémentaire pour montrer des démonstrations de travail car sinon les défauts ne seraient jamais corrigés. Par exemple, le remplissage des attaques Oracle contre CBC avait été décrit et même prototypé en 2002, mais il a fallu une démonstration réelle contre ASP en 2010 pour convaincre Microsoft que le danger était réel. De même pour BEAST en 2011 (la nécessité d'une IV imprévisible pour le mode CBC était également connue depuis 2002) et CRIME en 2012; BREACH est plus "CRIME II": une couche de pédagogie de plus pour abattre les incroyants.
Malheureusement, beaucoup de gens vont se tromper et pensent que c'est une attaque contre SSL, ce qui n'est pas le cas. Cela n'a rien à voir avec SSL, vraiment. C'est une attaque qui force une fuite d'informations à travers un canal de données à faible bande passante, la longueur des données, que SSL n'a jamais couvert et n'a jamais prétendu couvrir.
Le résumé exécutif d'une ligne est que tu ne compresseras pas .
BREACH, comme CRIME, est une attaque liée à la compression. La désactivation de la compression rend l'attaque impossible.
AJOUTÉ
Notez que dans ce cas, il semble que vous désactiviez une configuration de compression différente ; alors que CRIME exploite la compression de la couche TLS, BREACH exploite la compression de la couche HTTP.
Je viens de penser à un moyen d'ajouter "Randomisation des secrets par demande", "Longueur masquée" et "Demandes de limitation de débit" à une mesure d'atténuation CSRF.
- Considérez les formulaires que vous ne voudriez pas qu'un attaquant POST au nom de l'utilisateur. Ce sont les formulaires que vous protégez contre CSRF.
- Pour chaque affichage de page, générez un sel aléatoire de longueur aléatoire. Envoyez ce sel comme entrée cachée. La longueur aléatoire devrait aider à ajouter du bruit aux longueurs, même si votre équilibreur de charge frontal supprime les commentaires ou minimise votre HTML.
- Calculez un hachage du sel, l'ID de session et un secret côté serveur, et envoyez cette clé CSRF comme une autre entrée masquée.
- Enregistrez éventuellement la clé salt ou CSRF dans une table. Cela permet de limiter le débit d'un compte d'utilisateur ou d'une adresse IP particulier à un nombre de hachages par heure et de limiter les rediffusions d'un sel particulier.
- Lorsque vous traitez le formulaire, calculez le hachage de la même manière que les étapes précédentes, en utilisant le sel dans le formulaire et assurez-vous qu'il correspond à la clé CSRF.
L'attaque fonctionne en déduisant des informations de la taille de la charge utile. Le remplissage artificiel des pages HTTPS servies (par exemple, une chaîne de commentaire de taille aléatoire) pourrait réduire son efficacité.