mardi 29 novembre 2011

Linux Magazine 144 - Compiler son noyau linux

Le numéro 144 de Linux Magazine est sorti. J'ai écrit un article expliquant la manière de compiler un noyau linux.

Citation de circonstance:

jeudi 24 novembre 2011

Sécurité SSL et certificat malais compromis

Le marronnier actuel de la sécurité concerne SSL. Sur le papier, SSL, c'est très bien. Cela permet d'augmenter la sécurité de manière peu intrusive pour l'utilisateur. Dans les faits, l'implémentation laisse à désirer. NewsOft a déjà expliqué ça très bien dans un message de blog il y a quelque temps.

Le dernier évènement concerne un virus possédant du code signé par un certificat Malais valide. On peut imaginer que la clé privée a été volée, comme cela a été le cas pour les drivers signés de Stuxnet, mais une autre hypothèse émerge, sans doute plus plausible.

La Malaisie possède plusieurs sites gouvernementaux en .gov.my. Certains sont sécurisés en SSL. Un certificat signé par une autorité reconnue leur a donc été généré.
C'est un de ces certificats qui a été utilisé pour signer le code d'un virus, explication de l'attaque.

Si vous volez une clé privée associée à un certificat, alors il est possible de profiter de la confiance relative à ce certificat. Il se trouve que des certificats de serveurs webs en malaisie avait en utilisation de la clé l'autorisation de signature de code (premier problème). Dans une optique de moindre privilège, il est inutile de donner à un certificat authentifiant un site web une autorisation de signature de code! Si le pirate a la clé privée de ce certificat, alors il peut signer du code avec la confiance de ce certificat.

Si un pirate n'a pas la clé privée, il peut essayer de la calculer. Une clé RSA768 bits a été cassée en plus de deux ans et demis de calculs. Les docs de l'ANSSI recommandent des clés supérieures à 1536 bits (chercher "Niveau standard").
Dans le cas du certificat malais, la clé ne faisait que 512 bits, et c'est le second problème! On peut donc dire que sa factorisation est possible en un temps relativement court. [A ce sujet, je n'ai pas trouvé de bench précis sur ce point. Si quelqu'un a des valeurs chiffrées, je prends.]. [1]

Donc un autre scénario que le vol de clé privée se dessine: Un pirate scanne internet [2] à la recherche de certificats exhibant une clé faible et des privilèges de signature de code, casse la clé privée et l'utilise pour signer son code offensif. Aucune intrusion chez le possesseur de la clé est nécessaire. HeadShot.

Nous savons que des CA sont à éviter, il faudrait désormais un mécanisme permettant de surveiller les certificats exhibant des particularités "faibles". Typiquement un certificat signé avec une clé de 512 bits ne doit pas être de confiance indépendamment de la validité de sa signature par une CA.


Note:
[1] Si quelqu'un sait casser une clé avant le 16 décembre, il peut profiter d'un certificat SSL valide! Le prendre ici. 512 bits de clé. Chrome refuse le téléchargement de la page pour cause de révocation, by the way.

[2] Ce travail de scan des sites HTTPS est effectué en tâche de fond par l'EFF, sans doute les pirates ont ils profité de ces bases?

jeudi 10 novembre 2011

Remote code execution sur pile IP - CVE-2011-2013 - MS-2011-83

Mon flux RSS m'a remonté hier une vulnérabilité intéressante, MS-2011-83.
L'attaque est dévastatrice: remote code execution sur pile IP. Cela signifie qu'il suffit qu'une machine windows soit connectée sur un réseau, quels que soient es services en écoute (voire aucun), pour qu'un attaquant puisse en prendre le contrôle. C'est donc le plus haut niveau de gravité possible.

J'avais commencé à écrire un post de blog en faisant référence à mon message "TCP/IP security is boring" en indiquant le peu d’intérêt de la communauté de sécurité pour ce genre d'exploits. Mais au fur et à mesure de l'écriture du message, j'ai vu à ma bonne surprise mes fils d'actualités se remplir concernant cette faille.

Les informations techniques sur cette faille sont maigres. Le bulletin microsoft est comme d'habitude sibyllin.

  • Nous déduisons tout d'abord que seule la nouvelle pile IP est vulnérable du fait des systèmes impactés, à partir de Vista. Ce bulletin remplace le MS-2011-64, qui était lui aussi lié à un flot continu de paquets, mais ICMP.
  • Aucun Proof of Concept n'est disponible sur internet.
  • Le port UDP n'a pas à être en écoute Microsoft parle de "closed port". Ceci à du sens, contrairement à ce que j'ai pu lire. Lorsqu'un paquet est reçu du réseau, un certain nombre de vérifications doivent être faites, menant éventuellement à son rejet. Ce paquet est donc copié en mémoire, puis analysé. Donc envoyer un (ou des) paquet(s) sur un port fermé conduit donc à l’exécution de plusieurs parties de code du système, dont l'une au moins semble vulnérable.
  • Les paquets UDP ne sont pas aléatoires. Le bulletin indique "specially crafted", mais ne précise pas comment (ce qui est compréhensible).
  • L'exploitation de la faille est indiquée comme non triviale, mais possible, exploitability index de 2.
Un honeypot a été démarré, peut-être quelque chose en sortira, mais j'en doute.

Quelques informations ont émergées de mes flux, notamment celle-ci:
http://www.twitlonger.com/show/e30d0n qui de plus fait référence à des paquets ICMP, et donc le précédent bulletin remplacé. Une piste? Le bulletin MS2011-64 était lié à des paquets ICMP entrants, le twitlonger fait référence à des paquets ICMP sortants, dûs à des paquets UDP envoyés à des ports fermés. Cela semble plausible.

Edit: L'auteur du twitlonger ci-dessus semble arriver à crasher windows:
http://twitter.com/#!/_fel1x/status/134392807816306688. Il "suffit" d'envoyer 2^32 paquets UDP via un simple nmap -sU pour avoir un déclencheur de cette faille. Bon, 2^32 paquets, ça semble un peu beaucoup tout de même. Calcul à la louche. Imaginons une carte 100Mbit/s, et un paquet UDP de 160 octets.

(160x2³2)/100x10^6 = 6871 s, soit un peu plus de 2h de bombardement UDP continu au minimum...