mercredi 10 juillet 2013

RMLL live blogging - jour 3

Bruce Momjian - Securing PostgreSQL

Bruce Momjian fait partie du consortium postgreSQL et propose ce talk car il lui a semblé que la sécurisation des bases SQL peuvent être difficiles, alors que cette sécurité est importante.

La présentation démarre par les vecteurs d'attaques SQL. Concernant postgre, il s'agira des attaques externes, i.e. sans droits d'accès. Les attaques internes ne seront pas couvertes (SQL injection, application vulnerability, OS compromis, permissions etc..).

La sécurite de postgreSQL débute par le réseau, il est important de ne pas truster tout le monde, ce que fait initdb par défaut (utilisez initdb -A). La connexion par mot de passe est déconseillée, car il est envoyé en clair sur le réseau. L'authentification MD5 est préférable car un salt est envoyé du serveur, et va servir à empêcher un rejeu des credentials de connexion. Côté serveur, les mots de passe sont concaténés au login et hashé MD5. Postgre n'a pas de contremesures spécifiques contre le bruteforce de mots de passe. Les échanges sont ensuite chiffrés pour éviter les écoutes.

Mais certaines attaques restent possibles. Un scénario utilise un faux serveur écoutant sur le même port que postgre (5432, non privilégié), et attend qu'un client se connecte et lui demande son mot de passe en clair (et non MD5). Ce scénario peut s'améliorer en connectant le faux serveur au vrai et réaliser ainsi un "proxy" malicieux lisant l'ensemble des requêtes/réponses. Une mauvais réponse serait de forcer SSL côté client, mais le serveur malicieux peut l'utiliser car il n'y a pas vraiment de CA qui authentifie ces échanges. Il faut alors forcer l'usage d'une CA (Verify CA dans la conf). L'usage de Verify-full est encore meilleur, car le client vérifie également si le nom du serveur correspond à celui du certificat. Bruce parle ensuite du chiffrement des donnés pour éviter le vol de celles-ci lors du vol physique des disques (ou les bandes de sauvegardes). La première solution est le chiffrement de disque. Mais postgre propose du chiffrement de colonne. Soit réversible, à l'aide d'AES, ou one-way avec MD5 dans les cas ou il suffit de comparer une valeur et non de la lire. (mais le chiffrement peut poser des problèmes de performances dans la recherche ou la création des index). La clé de déchiffrement est stocké sur le serveur (mais qui pose problème en cas de vol physique de serveur). La clé peut également être déportée sur un serveur de déchiffrement, qui va agir comme un proxy pour déchiffrer les colonnes. Enfin, cette clé peut aussi être sur le client, sur le poste ou dans un token hardware ce qui est sans doute la méthode la plus sûre.

Alexandre Dulaunoy - CVE search : un logiciel libre de collecte, recherche et analyse des vulnérabilités et expositions logicielles publiées par NIST
Alexandre fait partie du CIRCL, un Computer Incident Response Center du Luxembourg. CVE est un bon moyen de vérifier si ses logiciels sont à jour et/ou vulnérable. Mais la recherche à l'intérieur de ces bases ne sont pas simples. L'idée est donc de créer un outil à la manière des outils unix traditionnel qui va permettre de "grepper" facilement ces bases de vulnérabilités.
cve-search a été développé au début par Wim Remes, qui se limitait à prendre la base en XML pour la pousser dans une base de données mongoDB. Les données viennent du NIST, sont parsées et remplissent la base mongoDB. Cette base contient les CVE, les CPE (liste de softs), un ranking et des  infos. La base se met à jour deux à trois fois par jour.
Des outils permettent de lire cette base (recherche, liste des dernières vulnérabilite, recherche au travers d'un bot XMPP (si, si) et des recherches full text).
Il est possible de chercher par nom de soft (joomla par exemple), par n° de CVE, ou CPE. CPE est une manière de spécifier l'OS, l'application ou le matériel (ou une combinaison) ciblé par le CVE.
Des exemples de recherches sont donnés. Par exemple, quels sont les éditeurs qui utilisent le plus souvent le mot "unknown" (oracle, puis Sun et HP).
Un autre exemple permet de calculer les moyennes et variations de score CVSS des failles java par exemple.
L'outil permet aussi de pondérer selon ses propres critères des failles, des CVE ou des softs afin de les suivre plus facilement.

La présentation continue sur l'usage de cve-search. Le logiciel libre peut être utilisé par tout le monde, pour tous les usages, mais est ce qu'un "bad guy" peut utiliser ce soft? Certainement, car cela peut lui simplifier la recherche de vulnérabilités sur un système qu'il cible.

Malgré tout, le développement de cve-search continue et l'outil restera libre.

Sebastien Deleersnyder - Mise en place d'un cycle de développement sûr avec OWASP

OWASP introduit une méthode appelé OpenSAMM pour promouvoir le développement sécurisé. Un rappel est donné sur les risques de sécurité et
indique que le software est toujours vulnérable. Une méthode permettant de sécuriser le soft devient de fait intéressante. La sécurité peut être proactive (design, build) ou reactive (test, production). La méthode proactive est meilleure pour réduire la surface d'attaque, mais les tests et scan de vulnérabilités restent nécessaire.
L'OWASP propose un modèle de dévloppement prenant ces points en compte, ainsi qu'une méthode pour l'appliquer.
Quatre business fonctions sont définies (governance, construction, verification et developpement) avec pour chacun d'entre eux trois axes de travail. Les slides suivantes précisent ces points. L'orateur conseille d'aller sur le site de l'OWASP qui contient un grand nombre de ressources, de videos, de présentations sur le sujet. La suite de la présentation effectue une revue de ces points, je renvoie donc vers les slides et le site de l'OWASP
Je note le proxy offensif https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project qui semble intéressant à essayer.

Cedric Foll - (Net|S)Flow Détection d'anomalies et d'attaques sur le campus

La dernière conférence de la matinée est donné par un des rédacteurs en chef de MISC qui va présenter comment détecter des activités malicieuses sur un réseau à l'aide de Netflow. Netflow est un protocole standard qui permet (entre autre) de visualiser de manière graphique des flots, au lieu de lire des longues de pages de logs. Netflow a été développé par Cisco, standardisé  par IPFIX, et Sflow est une version dédiée pour les switchs.
Le principe repose sur les flux contenant les informations suivantes: IP src, dst, L4 ports, heure démarrage, durée, et quantité échangée. Un flux expire après 15s d'inactivité, 30 mn d'activités, quand un RST ou FIN est envoyé. Les routeurs envoient ces infos à un collecteur qui enregistre ces données.
Ces enregistrements s'exploitent à l'aide de nfdump/nfsen et permettent de créer des représentations graphiques des flux.
La suite de la présentation va montrer comment on utilise ces outils sur des exemples réels, extraits d'enregistrements de flux de l'université de Lille. Après des exemples généraux nous arrivons à une démonstration de détection de comportement malicieux. L'exemple montre comment un pic TCP sur le port 53 est facilement repéré, puis investigué. Un second exemple tout aussi parlant montre comment un DNS en configuration open a été trouvé. Les exemples continuent, toujours aussi visuels.
Netflow permet aussi de trier les ports par usage, par exemple pour trouver les ports les scannés. D'autres types de scan horizontaux (une IP qui scan un range) sont également facilement trouvés.
Les tunnels HTTP/HTTPs se détectent facilement: long flux avec peu de data; ainsi que les tunnels DNS: beaucoup de DATA, par contre les tunnels ssh sont plus difficiles à trouver.
La présentation est très visuelle, j'invite à voir les slides qui vont être dispos sur le site des RMLL d'ici peu.

 Jonathan Clarke - Rudder

Le talk va parler d'infrastructures et de l'automatisation de certaines tâches IT. L'automatisation est une composante essentielle de l'activité d'IT pour plusieurs bonnes raisons, rapidité, reproductibilité, éviter d'oublier des points, etc.. Plusieurs outils existent, comme CFEngine, puppet ou Rudder.

Mais plus que l'automatisation, l'important est la compliance. Celle ci permet de connaitre l'état de l'IT, d'obtenir une vue d'ensemble et surtout de la prouver. Ce besoin de compliance provient de multiples endroits: les lois, les réglementations industrielles ou d'entreprises et les "best practices".
Cette compliance s'appuye sur des messages de préventions, des politiques de mots de passe, des paramétrages particuliers, etc.. L'automatisation mentionnée plus haut n'est pas forcément de la compliance. La fréquence des vérifications est importante et doit être fait le plus souvent possible. La compliance ne peut pas être faite à moitié, c'est un système all-or-nothing qui se complique vite, du fait de l'hétérogénéité des machines, OS et versions. La compliance ne peut pas être mal faite car cela touche généralement des serveurs en productions et la moindre erreur peut avoir de grandes répercussions.

L'orateur continue avec une démonstration de l'interface graphique de Rudder. Le but de Rudder est de donner un outil Plug&Play qui permet d'automatiser les tests de compliance. La conf par défaut marche out-of-the-box elle est prépackagé pour tous les OS et l'intégralité de la configuration se fait à l'aide d'une interface Web. Le workflow d'utilisation est assez simple à prendre en main.

En conclusion, l'orateur explique que la compliance en sécurité bénéficie beaucoup de l'automatisation. Mais cette automatisation n'est pas tout. Il faut croiser ces données avec celles du monitoring pour une couverture maximale.




Je ne peux rester pour les autres talk, ayant un impératif de transport.
Merci RMLL2013, merci à l'organisation, c'était encore une très bonne année.

mardi 9 juillet 2013

RMLL 2013 - live blogging - jour2

Le réseau wifi est présent et actif, me permettant de mettre en ligne directement après les talks, merci au NOC des RMLL :-)

Peter Czanik - Logging & syslog-ng
La conférence parle de syslog-ng et de la journalisation en général. syslog-ng est développé par balabit, une compagine de 150 personnes dont
80% savent configurer un kernel linux ;)
Le logging est la science qui enregistre les évènements qui se passent sur un ordinateur. Le premier outil utilisant le logging fut sendmail. Logger est essentiel pour l'administration IT, aussi bien pour les développeurs, les administrateurs ou pour la sécurité dans des situations d'audits ou réponse à incident; mais seulement si les logs sont managés.
Syslog-ng existe depuis 1997, est appelé le couteau suisse du log, et essaye de centraliser tous les logs. La centralisation permet une collecte et une utilisation simple des logs et de permettre leur accès même si les machines sources sont down ou compromises.
La version la plus populaire de syslog-ng est la 1.6 (10 ans d'âge) qui est utilisée par les kindle d'amazon. La dernière version est la 3.4. L'orateur parle ensuite du format de log. Généralement, nous avons une date, puis une hostname et enfin du texte en anglais permettant une lecture simple du message. Lorsqu'un grand nombre de ligne de logs existe, il devient difficile de chercher les logs intéressant. Il est nécessaire alors de mieux structurer les logs afin de pouvoir les parser automatiquement.
syslog-ng utilise une méthode clé/valeur et un parseur pour pouvoir "grepper" plus facilement de l'information. Les autres features concernent une correlation facilitée, un formatage json des données, un export mongoDB et des destinations AMQP.
Dans le monde des logs, un nouveau challenger du nom de journal a fait son apparition. Journal est appareillé avec systemd. Il utilise également un système de clés/valeurs. Il peut exporter ses logs vers syslog-ng. journal dispose d'une feature intéressante d'authentification du process émetteur pour éviter qu'un attaquant ne pollue des logs avec des faux messages. Journal n'est pas un concurrent de syslog-ng, mais plutôt un allié qui concerne le log local des machines linux.
Pour revenir à sylog-ng, il apparait qu'une standardisation de ces clés valeurs devient de plus en plus important. Ce Graal du logging aurait beaucoup d'applications pratiques, mais trop d'applications continuent d'utiliser des logs non formattées.
Un outil graphique se basant sur ces systèmes clés valeur est ELSA, basé sur syslog-ng, patternDB et mySQL et permet des recherches de log tournés vers la sécurité.
En conclusion, l'orateur donne les raisons poussant à utiliser syslog-ng:
15 ans de développements, scalability, une documentation exemplaire.

Xavier Mertens - What will you investigate today

Encore une conférence sur les logs, mais plus tourné sur la sécurité et la recherche à l'intérieur de ceux-ci.
Le problème des logs n'est pas d'en manquer, le problème est plutôt de retrouver parmi les millions d'évènements ceux qui font sens. Pour des raisons de compliance, les entreprises installent des outils de logging, mais l'exploitation des résultats n'est pas forcément simple. Malgré tous ces logs, les entreprises mettent plusieurs mois pour se rendre compte des brèches: 66% des brèches sont détectées plusieurs mois après après et 69% des data breach sont remontées par des tiers!
Le premier outil de recherche dans les logs est "grep". Il permet déjà d'extraire des infos intéressantes. Toutefois, cela permet de trouver des choses connues, que l'on cherche et ne donne pas d'idée sur l'inconnu (Par exemple, grepper des logs apache sur des codes peu usités peut donner des pistes intéressantes)
Pour aider, il existe aussi la corrélation de plusieurs sources, mais la classification n'est pas forcément simple.
Certaines listes permettent de classifier les données brutes; par exemple GeoIP pour les IP, ou une liste de noms d'utilisateurs importants (admin, root, "bob", etc..). Ces listes peuvent être dynamiques: une IP effectuant un portscan devient suspicieuse et a besoin d'une plus grande attention si elle se logge sur un service particulier.
Aujourd'hui, il est très difficile de filtrer tous ces évènements, tout le bruit afin de pouvoir se concentrer sur les plus importants.

Les premiers logs à creuser sont ceux du DNS, car il est essentiel et beaucoup de canaux d'exfiltrations l'utilisent. Il est également utilisé par les malwares pour trouver l'IP de leur C&C. Une liste de domaine malveillant va permettre de cibler des machines suspicieuses. Des machines tentant d'utiliser d'autres DNS que les DNS d'entreprises doit également être surveillée.
Les seconds logs sont les logs HTTP. "HTTP est le nouveau TCP". Il est nécessaire de surveiller les domaines, de faire de l'inspection SSL et de vérifier les hashs des fichiers échangés.
Le troisième protocole à surveiller est le SMTP. Les méthodes sont identiques, les domaines de sortie, et les flux de données.
Enfin, un outil à utiliser est netflow, qui permet d'obtenir des graphes intéressants listant les IP/ports sur une échelle de temps.

L'orateur donne des ressources sur internet à connaître. Tout d'abord, le site wwww.malwaredomainlist.com donnant des IP à chercher dans les logs.
Ensuite, GeoIP donne un point de vur intéressant sur les IP circulant sur ses réseaux. La seconde liste concerne les domaines DNS malveillant: malwaredomaines.com . Une troisième ressource est liée aux URLs.
malwareurls.joxeankoret.com, ou la liste malware URL de google (une API
existe). Toutefois, certaines de ces listes ont des limites légales (pas de
redistribution commerciales, API limitée, etc..) Enfin, il faut savoir utiliser des méthodes originales propres à ses domaines d'activités.

D'autres outils sont donné: pastebin a souvent des informations de première main. Des outils de parsing ne sont pas à négliger comme d3js. Un outil
comme OSSEC est conseillé par l'orateur pour ses qualités. Une série d'outils online est fournie (donnée sur les slides de la conf) comme malwr.com ou virustotal qui peut aider à détecter des comportements ou fichiers suspicieux.

En conclusion, l'orateur indique qu'il existe beaucoup de données à investiguer et qu'il est nécessaire de bien connaitre son environnement. Le logiciel libre va vous aider, mais il reste un gros travail de recherche et de corrélation qui demande du temps.

Pendant les questions, une remarque intéressante est faite concernant pastebin. Il existe  beaucoup de surveillances sur ces sites de paste. Malheureusement, aucun outil de partage des informations sur ces "pasties" n'existe et un framework de recherche serait très intéressant, remarque que je partage pleinement.

Eric Leblond - Suricata the terminator of IDS/IPS

La conférence démarre par une présentation d'Eric Leblond, contributeur
de Suricata, Ex-CEAo d'EdenWall. Cette présentation va faire une présentation de Suricata et continuer par une démo de ses possibilités.
Eric démarre par une définition des IDS/IPS. L'ids est passif et se compare à une caméra de surveillance, l'IPS bloque et s'apparente plus à un checkpoint de sécurité. Un IDS va écouter le réseau, effectuer une reconstruction de paquet/flux et appliquer enfin une normalisation des données pour appliquer une politique de détection de flux malveillants. Les projets ressemblant à suricata sont BRO, plus orienté capture de paquets, et Snort qui a inspiré le développement de Suricata. Suricata veut devenir un "Snort meilleur que Snort". Snort souffre d'un manque de performances et de 10 ans de développement, mais à l'avantage d'être bien connu. Suricata sait utiliser les rulesets de Snort (au prix de performances faibles et d'une impossibilité d'utiliser toutes les optimisations de suricata). Suricata propose un jeu de règle open source (emerging threat) directement utilisable.

Le développement d'OISF (fondation derrière suricata) a démarré avec l'aide du gouvernement US (DHS, Navy) dans l'idée d'en faire un outil open source. Ce financement souhaite dès le début du projet pouvoir se désengager de celui-ci afin qu'il puisse vivre en open source.
Le core developpement est assuré par trois personnes, et environ 35 contributeurs poussent régulièrement du code. Suricata est multiplateformes, supporte IPv6, multithreaded, accéléré en hardware, orienté perfs, permet d'être utilisé en mode "test", en mode IPS pur, sait détecter les protocoles indépendemment des numéros de ports, extraire des fichiers des flux, et est capable d'appeler un script LUA pour effectuer des
méthodes de détection plus intelligentes, et se connecte avec GeoIP.

Suricata sait digérer plusieurs méthodes d'entrées, pcap (live & offline) AF_PACKET, PF_RING, etc... Et en output sait renvoyer du Fastlog, pcaplog, unified2log, Prelude, etc.. Un des points central de suricata est la libhtp, une bibliothèque capable de reconstruire les flux HTTP et qui donne des pointeurs vers chaque partie du flux (en-tête, cookie, url, etc..), et surtout qui sait reconnaître du HTTP quel que soit le port. La lib HTP sait aussi extraire et critériser selon les metadata (extraire un fichier, son filetype, son extension, son hash, etc..) Plusieurs exemples sont donnés, ou l'on peut surveiller le type des fichiers entrant sur un serveur web, si des clés RSA circulent sur le réseau (!!).

Un manque de temps oblige l'orateur a accélerer et nous passons sur le mode IPS. Le jeu de règles est un peu différent, car basculer d'un mode "alert" à "drop" peut surbloquer des services.

Enfin, nous passons à la démo qui consiste à ralentir au maximum les flux des personnes envoyant des documents Word sur le réseau (car "Word is heavy as hell"). Suricata sait reconnaitre les fichiers word grâce aux mots-clés de la libhtp, et peut poser des marques netfilter. iptables va utiliser la target CONNMARK pour propager le marquage sur la connection entière. L'orateur réussit ensuite le tour de force consistant à expliquer comment la QoS sous linux fonctionne en une slide et 45 secondes ;) Il pose une règle de QoS restreignant les flots portant un fichier .doc a 1ko/s (très généreux de sa part). Les utilisateurs peuvent essayer de modifier l'extension, mais suricata sait le détecter et il devient possible de mettre une règle autorisant 10ko/s pour ces gens intelligents :). Mais ces gens intelligents sont peut-être à  surveiller. Dans ce cas, iptables peut repérer ces IP grâce à suricata et les mettre dans une table pour les logger.

Pierre-olivier Vauboin et Omar Awile - mobile telecom et securité

Dernier talk de la journée. Les réseaux télécom sont bien plus complexes que les réseaux IP. Un slide montrant une infrastructure opérateur permet de bien visualiser l'hétérogénéité des équipements et des réseaux, les différences entre le réseau de "signaling" (entrée sur le réseau, sortie, payement etc..) et le réseau data (données utilisateurs clients (voix, etc.) Il y a aussi un nombre beaucoup plus grand d'équipements, depuis la femtocell jusqu'au HLR, ouvrant de fait plus de surfaces d'attaque. Les protocoles aussi sont beaucoup plus nombreux en telecom qu'en IP: SCTP, SIgtran, M3UA, MAP, GPRS, etc.. contre DNS, HTTP, etc.. Les slides montrent des stacks IP versus des stacks telecom qui permettent de se rendre compte de la jungle dans lesquels vivent ceux-ci.

Le routage en IP est relativement simple (ethernet, IP, numéros de ports) alors qu'en telecom il existe de multiples standard et de multiples données dans toutes les couches protocolaires et le routage utilise une combinaison de toutes ces données. SCTP (RFC 4960) a été développé pour remplacé TCP, qui ne convient pas très bien aux réseaux télécom (délais, stream-oriented, pas de support du multi-homing). SCTP implémente une méthode permettant de gérer des flux répondant aux contraintes télécom. La plus grosse différence repose dans les chunks: un paquet SCTP peut embarquer des paquets différents, de différentes connexions. SCTP est la glu permettant de connecter des réseaux IP avec des réseaux telecom.

La deuxième partie de la conférence traire de pysctp, une bibliothèque pour monter des flux SCTP facilement. Un serveur M3U peut s'écrire en une vingtaine de ligne de code. Un second exemple implémentant une backdoor over SCTP tient également en une vingtaine ligne de code, et comme SCTP n'est pas TCP, les méthodes de détection utilisant netstat sont aveugles (quelques patch pour netstat existent pour afficher le SCTP toutefois). Il faut alors regarder dans /proc/net/sctps/eps et assocs pour connaitre les connexions SCTP.
Cette bibliothèque permet également de scanner les serveurs SCTP. Les réponses dépendent des serveurs et de leurs implémentations, mais il en connaissant ces différences le scan est efficace. Wireshark sait disséquer les protocoles telecom, et sait dépiler le mille-feuilles des protocoles utilisés. Le problème de SCTP est qu'il est de plus en plus utilisé, alors qu'il n'a pas d'authentification et qu'il faudrait utiliser IPsec, sauf qu'IPsec n'est pas vraiment déployé. L'orateur donne des exemples d'analyse réseau passive de réseaux télécom, ou de scan actif.

Pour conclure, l'orateur redit que le monde telecom est plus compliqué que le monde IP en raison du grand nombre de technologies et protocoles. Malgré tout SCTP est ubiquitaire dans ces telecom comme interface entre l'IP et le monde telecom. Il reste encore beaucoup de sécurité à creuser
et à mettre en oeuvre dans ces réseaux.

RMLL 2013 - Live blogging

Je suis de nouveau aux RMLL afin de suivre le track sécurité.
Je propose comme l'année dernière un live blogging des conférences.
Les tracks ont commencés hier, mais un problème d'accès au réseau m'a empêché de poster hier. Voici donc un CR du 8 juillet 2013. Les slides sont disponibles sur

Werner Koch - GnuPG Status Report

Werner commence par un historique des versions de GPG. La version 2 a amené la modularisation de GPG. GPG est multiplateformes, utilisable pour le desktop. GPG a une base de développeurs solide, ainsi qu'un groupe de mainteneurs, bug reporters, code reviewers, etc.. GPG est couvert par plusieurs aspects légaux un travail est donc fait pour le contourner, plusieurs copyright assignments leur ayant été remonté. Werner Koch passe ensuite en revue la liste des features de GPG: Tout d'abord S/MIME avec management de clé qui propose aussi une CLI complète permettant de gérer des clés, et le mécanisme de gestion de CA est presque au point.
GPG-Agent s'occupe de la gestion des clés privées et de leur mise en cache. GPG-agent dispose d'une fonction de scripting GPG sait se connecter avec ssh, en remplaçant ssh-agent par gpg-agent. Il fonctionne avec des cartes à puces. GPG utilise un framework spécifique pour les cartes à puces (carte openPGP), qui serait un sujet de talk à part entière, il passe donc rapidement sur le point.
Il parle ensuite du projet g13 pour le chiffrement de surface. La clé maître du device est wrappée par PGP. Il devient donc possible d'utiliser sa smartcard openPGP pour ouvrir des fichiers encFS. Le portage pour dm-crypt est en cours, ainsi que GELI (BSDs).
Le projet qui intéresse les développeurs en ce moment est GPGME, l'API standard d'accès à GnuPG. Il s'agit d'une interface pour avoir accès aux  clés et à gpg-agent.
Dans le domaine des améliorations, Werner indique que les clés GPG secrètes sont désormais controllées par GPG-agent. Cela permet des simplifications de code et le merging de clés. Une autre amélioration concerne la Keybox. En effet, les clés sont concaténées les unes aux autres, et un grand nombre de clés va demander plusieurs secondes pour y accéder. Cette amélioration permet d'accéder en moins de 100ms à une clé parmi 20000. Une autre amélioration concerne le mode pinentry qui devrait permettre d'utiliser facilement GPG sur les postes non desktop. GPG est également en train de remplacer les threads Pth par nPth pour des raisons de simplicité. De son côté la libgcrypt se voit amélioré en utilisant les optimisations des CPU modernes (AES-ni, SSE2, etc..) et quelques nettoyages de code.
Le cas d'openpgpjs est évoqué. C'est intéressant mais cela ouvre beaucoup d'axes d'attaques, malgré les demandes. Werner Koch remercie ensuite les développeurs et la communauté.

Kevin DENIS - le chiffrement de disque sous linux, vrai ou faux sentiment de sécurité, deuxième round.
Généralement, on pense que:
You choose to crypt your disk...
...and you're safe & secure
Alors qu'il s'agit plutôt de:
You choose to crypt your disk...
    and you know (basically) how it works
    and you check that crypto defaults choosen by your distro are safe
    and you check the crypto algorythm and implementation
    and you check the quality of the master key
    and you check that password inputs are safe
    and you check that you can change your keys
    and you check that your password can't be easily bruteforced
    and you check the integrity of your boot process
    and you check the integrity of the ciphered blocks
    and you check that your keys doesn't remains in RAM
...and you're safe & secure (sort of)

Paul Rascagnères - malware sous linux
Ce talk souhaite casser l'idée reçue comme quoi il n'y a pas de malware sous linux, au travers de 3 exemples réels de 2013: Darkleech, Cdorked, wirenet..
 - Darkleech/Chapro.
Darkleech est un module apache "authentique", qui va ajouter du javascript dans certaines pages pages web pour rediriger des clients. Darkleech est également une backdoor permettant de prendre la main du système. Le nom du malware varie (ex: sec2_config_module),  et injecte surtout des exploits kits. Les cibles sont choisies par les informations de headers clients, en excluant les moteurs de recherche et versions de navigateurs non ciblées par l'exploit kit. Ce malware est obfusqué par un simple XOR, ce qui permet facilement d'accéder aux informations.
 - Cdorked
Il ressemble au premier, sauf qu'il ne s'agit pas d'un module apache, mais du binaire apache lui-même. Il n'est pas obfusqué, et la première chose qui apparaît est la possibilité d'obtenir un reverse shell. (la clé pour ouvrir un shell consiste à demander le favicon.iso au lieu du favicon.ico)
 - Wirenet
Ce malware attaque plutôt les desktops, et ressemble aux malwares windows. Il est chiffré avec de la crypto forte (RC4), mais la clé est présente et permet de lire les chaines de caractères. Le malware communique avec un C&C, un faux serveur a donc été créé, la communication est chiffré avec AES prouvant que les développeurs connaissent la crypto (RC4, AES). Ce C&C permet de lancer des commandes arbitraires sur le poste victime (ps, rm, récupération de credentials pidgin, thunderbird, clear des logs, etc). Ce malware inclut toutefois l'intégralité de ces possibilités à la différence des malwares windows qui n'incluent que le strict minimum et pousse au fur et à mesure des modules additionnels.

En conclusion, Paul rappelle la facilité avec laquelle il est possible d'écrire des malwares sous linux. Une demo de 10 ligne nous montre comment écrire un ransomware en shell. Cette simplicité risque d'en faire une cible de choix, et l'idée comme quoi linux n'a pas de malware est une idée fausse.
Une question est posée lui demandant si les vecteurs d'infections sont connus, et Paul Rascagnères répond qu'il n'a travaillé que sur le reverse de ces malwares qui lui ont été fournis, et non pas sur leur détection. Pour Darkleech, nous savons que les pirates ont utilisés une faille de l'outil Plex pour obtenir un shell sur les machines hébergeant les serveurs web.