Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

SSTIC 2012, matinée du premier jour

20 years of PaX

PaX team - plus qu'une personne sur trois dans l'équipe

Introduction sur ce que PaX est aujourd'hui. Modèle de menace: accès aribitraire à la mémoire (userland, kerneland) en lecture/écriture. Il vaut mieux dépenser son temps à prévenir l'exploitation des bugs que de les chercher. Une fonction importante: kernel self-protection. Nous n'aborderons dans ce compte-rendu que cette fonction qui est moins connue.

Quelques techniques d'exploitation :

  • return-to-libc
  • ROP (Return Oriented Programming)
  • JOP (Jump Oriented Programming)

Fonctions de kernel self-protection :

  • Non-exec kernel pages
    • Les pages userland ne doivent pas être exécutables depuis le kernel
  • Read-only kernel data
    • constification : création de mappings des données vers du read-only
  • Séparation de la mémoire userland/kerneland
    • Prévention de l'utilisation de code userland depuis le kernel
  • Restriction sur les copies userland/kerneland
    • Bounds checking pour les copies kerneland vers userland ou vice versa
    • Protection contre les stack overflow (limiter aussi les attaques ROP/JOP)
  • Protection contre les race condition de type copie/utilisation
  • Nettoyage automatique sur les appels free()
    • La mémoire libérée est nettoyée, tout de suite (2 lignes de code au bon endroit)

Certaines fonctions implémentées dans PaX ont été inspirées par le reverse engineering de Windows 95 (durant les années 90). Ces fonctions nécessitent une mise à jour de la toolchain de compilation : plugin gcc, par exemple. Quelques plugins :

  • Stackleak : prévention de la fuite d'information depuis la stack
  • Constify : constification automatique des structures ops
  • Kernexec : prévention de l'exécution de code userland
  • Size overflow : prévention de l'exploitation de failles integer overflow

Les futures protections :

  • Control Flow Enforcement : protection compète contre les ROP/JOP
    • Sous forme d'un plugin compilateur
    • Support JIT (Just-in-Time)
  • Détection et prévention des size overflow
    • Même plugin que pour le kernel
    • Ce plugin aurait protégé contre les failles CVE-2012-2110 et CVE-2012-2131 (OpenSSL)
  • User-after-free

Et beaucoup d'autres protections basées sur des plugins compilateur. Cela semble être le meilleur moyen aujourd'hui d'avoir des protections génériques. Le support LLVM/clang est également envisagé.

Les hyperviseurs : ils ajoutent une couche de complexité dans le système, et donc abaissent la sécurité du système. Le support ARM est prévu, mais seulement les fonctions compilateur et userland (beaucoup plus difficile pour le kerneland).

SSL/TLS - état des lieux et recommandations

Olivier Levillain - ANSSI

Description du fonctionnement du protocole de communication ("SSLv3/TLSv1.*) (ClientHello, ServerHello'', ...). Le client propose des algorithmes crypto, le serveur choisi.

SSLv2 (1995) à proscrire pour des raisons de faiblesses sécuritaires. Ce protocole tend à disparaitre. SSLv3 (1996) : problèmes avec la vieille implémentation. Ces problèmes sont corrigés par TLSv1.0.

Mais attaque à clair-choisi adaptative sur TLSv1.0 (Rogeway 2002). Corrigée dans TLSv1.1. Dans TLSv1.2, nouveaux algorithmes de gestion de l'authentification. Comme DHE/ECDHE qui assure la PFS (Perfect Forward Secrecy), afin qu'une caputre de session à un instant t ne puissent pas être déchiffrée dans le future.

Test de différents navigateurs pour le support des différentes version du protocole :

  • SSLv2 est désactivé par défaut sur les dernières versions de firefox
  • Chrome ne semble pas basé sur OpenSSL, il utilise son implémentation

Test de différents serveurs sur le support des différentes version du protocole. Scan de serveurs avec sslscan. A voir : référentiel RGS.

Test automatisé des navigateurs : http://ssltest.offenseindepth.com.

Le magasin de certificat : différents programmes utilisent différents magasins. Des avantages et des inconvenients à l'utilisation de magasins. Le magasin sous Linux est dans $HOME/.pki.

Note : Voir l'IDS Suricata.

Aucune réponse dans cette présentation concernant la gestion de la confiance globale au système (les PKI). Aucune étude non-plus sur le certificate pinning.

Netzob : un outil pour la rétro-conception de protocoles de communication

Frédéric Guihery Georges Bossert Guillaume Hiet

De nombreux protocoles (propriétaires ou non) qui ne sont pas documentés. Un des buts de la rétro-conception est le fuzzing de l' API, ou l'écriture de règles d' IDS. La communauté est globalement dépourvue d'outils d'analyse (processus manuel et visuel).

  • Vocabulaire : liste des messages et leur format
  • Grammaire : règles de procédure permettant d'assurer la cohérence des messages échangés.

Découpage du message brut en couches, puis champs. Les champs possèdent une liste d'attributs qui donneront la sémantique (optionnelle). La partie découpage en champ (automatisé) est basée sur un algorithme issu de la bio-informatique. Classification des messages (regroupés par similarité) aussi basé sur un algorithme issu de la bio-informatique.

Fonctions de l'outil :

  • Import => inférence du protocole => simulation => export.
  • Export : génération automatique de module Scapy.

Démo : découpage (presque) automatique de messages Ehernet/IP/UDP/DNS. Démo : instrumentation d'un serveur TCP pour inférence des différents état d'un protocole.

  • Output : un automate des états du protocole.

Note : aHR0cDovL2dvby5nbC9pOFo3UA==

prompt$ perl -MMIME::Base64 -e 'print decode_base64("aHR0cDovL2dvby5nbC9pOFo3UA=="),"\n"'
http://goo.gl/i8Z7P
prompt$ printf "GET /i8Z7P HTTP/1.1\r\nHost: goo.gl\r\n\r\n" |nc goo.gl 80 |grep http
Location: http://sarssi-conf.org/SAR-SSI2011-Programme.pdf
The document has moved <A HREF="http://sarssi-conf.org/SAR-SSI2011-Programme.pdf">here</A>.

Sécurité de RDP

Arnaud EBALARD - ANSSI Aurélien Bordes - ANSSI Raphaël Rigo - ANSSI

Microsoft recommande l'utilisation des RPC via la MMC et non pas de RDP. Initialement uniquement un protocole de déport d'affichage, mais étendu ensuite avec de nouvelles fonctions (énormément, tellement qu'il est lié à tout le système au final). 2000 pages de documentation sur le site de Microsoft ...

RDP participe simplement à la mise en place de canaux de communication entre composants (matériel ou logiciel). Protocole complexe : 8 messages pour établir une session.

Démo : recupération de la clé RSA (512-bits) depuis une capture de paquets. Factorisation du RSA, puis rejeu du traffic déchiffré : accès mot de passe admin et tout le déport de session. C'est beau. Pas de perfect forward secrecy.

Pour corriger ces erreurs de sécurité, Microsoft a introduit Enhanced RDP Security (pour remplacer le Standard RDP Security) :

  • TLS

Un protocole avec beaucoup de fonctions (même pour la sécurité), mais (presque) pas configurable. Une logique étrange pour le client Microsoft RDP au fil des versions (exemple : certificats X.509 doivent être formés d'une manière particuilère).

Démo :

  • L'admin a déjà coché la case pour reconnaître le certificat serveur
  • Attaque : MiTM sur Enhanced RDP Security
    • on laisse passer les premiers messages pour l'authentification
    • on se met ensuite en MiTM pour la suite afin de récupérer le mot de passe.

Finalement, le passage à TLS n'a pas vraiment amélioré la sécurité de RDP. Conclusion : l'utiliser sur un réseau vraiment sécurisé.

Commentaires

1. Le jeudi, juin 7 2012, 12:03 par dzrider

Concernant le base64 de la conf Netzob il y a eu un petit fail... et le vrai lien qui se cachait derrière vous amenais ici :
http://www.netzob.org/protocol-sec....
;)

2. Le jeudi, juin 7 2012, 14:18 par GR

Ca va pas commencer à troller sur mon blog hein ;)