Investigation du jour sur une fraude au président

Début d'après-midi avant d'aller en réunion, un utilisateur ouvre un incident de sécurité concernant un cas de fraude au président. Jusqu'à maintenant je me disais qu'une fois détecté par l'utilisateur il n'y a plus de risque et je classais l'affaire.
Ici un élément a attiré ma curiosité, il y a un typosquatting en plus avec un 1 à la place d'un L. Pourquoi se donner tant de mal ? Qu'est-ce qu'il se cache derrière ?

Avant de creuser, j'ai identifié 5 destinataires du même message, fait blacklisté le domaine et préparé une comm pour le RSSI... Place aux choses sérieuses. =)

Première étape le whois, je passe par RiskIQ au lieu de domaintools.
Je découvre que le domaine est déposé chez "PDR Ltd. d/b/a PublicDomainRegistry.com" avec une adresse mail chez outlook.com.

On peut voir que le nom a été déposé il y a 2 jours... Merci l'antispam qui laisse passer ça...

Ensuite on a une adresse IP associée au domaine qui pointe sur un range Google. (Pas creusé ce point.)

Plus de 1000 domaines ont pointé sur cette IP... Et beaucoup sont taggués comme malveillant par divers éditeurs (Kaspersky, emerging_threats). On voit l'intérêt de RiskIQ, même en version community.

Mais avec cette réputation comment le mail a-t-il pu passer ?

Seconde étape, analyse en profondeur des headers du mail et de l'enregistrement SPF lié au domaine.
Pour le SPF et les "dig" en général, il y a un outil de Google ici.

Magnifique, un service de messagerie online... Confirmé dans les headers mail c'est bien passé par eux et donc reverse DNS OK et SPF OK (et même DKIM).

En conclusion, un domaine acheté il y a 2 jours sans doute avec paypal ou une CB volée et de fausses infos, puis associé à un service de messagerie SaaS permet d'avoir la réputation suffisante pour passer les antispam actuels. Au vu de la réutilisation des données du whois, ces personnes font du volume et non de la qualité (mail en anglais entre 2 français ???).

Premier test de PRINCE avec oclhashcat sous Windows

Atom (le dev de hashcat) vient de sortir un algorithme appelé PRINCE qui génère des mots de passe dérivés d'un dictionnaire. Ça semble assez puissant et comme je viens de me faire plaisir avec une nouvelle carte graphique (j'en reparlerai un autre jour), j'ai envie de m'amuser en cassant un peu de mots de passe :)

Sur la base du tutoriel d'Atom, j'ai testé la ligne de commande suivante sous Windows :

C:\Users\xxx\oclHashcat-1.31>pp64.exe < rockyou.txt |
oclHashcat64.exe -m 1000 -o NTLM_prince.txt "c:\Users\xxx\hash_ntlm.txt"

En fait dans son tutoriel, Atom utilise mkfifo, mais sous Windows, il n'y a pas d'équivalent potable (en 2 minutes de recherche Google). Heureusement qu'il est possible de piper avec oclhashcat.

Ce que j'aime bien avec ces algorithmes, c'est que des mots de passe de 13 caractères ou plus peuvent tomber facilement s'ils sont bêtement dérivés d'un mot d'un dictionnaire.

En 24h j'ai cassé presque autant de mots de passe qu'en bruteforce pur durant 4 jours, mais ce ne sont pas les mêmes mots de passe qui tombent. J'ai constaté que les CPU et GPU sont largement sous-utilisés.

Session.Name...: oclHashcat
Status.........: Running
Input.Mode.....: Pipe
Hash.Target....: File (c:\Users\xxx\hash_ntlm.txt)
Hash.Type......: NTLM
Time.Started...: Mon Dec 29 23:59:01 2014 (1 day, 0 hours)
Speed.GPU.#1...:  2386.7 kH/s
Recovered......: 396/1513 (26.17%) Digests, 0/1 (0.00%) Salts
Progress.......: 233595600896
Skipped........: 0
Rejected.......: 0
HWMon.GPU.#1...: 57% Util, 51c Temp, 34% Fan

Je pense qu'il est possible de faire un PRINCE avec hashcat en même temps qu'un bruteforce en GPU avec oclhashcat. Les deux méthodes sont complémentaires. Peut-être qu'il peut être intéressant de lancer plusieurs PRINCE/hashcat avec des dictionnaires différents pour mieux utiliser le CPU. Ce n'est que le début, mais c'est déjà prometteur.

Offre d'emploi mensongère :-/

Juste un petit coup de gueule parce que je vois des offres d'emploi attrayantes qui sont tagguées Areva et qui ne sont en fait que pour leur ex-filiale informatique Euriware.

Pour avoir côtoyé cette société, les missions étaient rarement pour la maison mère et un pentester faisait vaguement du pentest à 30% de son temps et même penser à approcher un système SCADA relevait du fantasme. Leur seul intérêt était les passerelles avec le groupe, mais encore fallait-il faire des missions pour les bonnes personnes pouvant créer un poste pour vous internaliser. Je ne parle pas non plus de la convention Syntec et de l'intéressement qui était celui de la filiale et non du groupe. De quoi déprimer quand on fait une régie longue durée dans une équipe Areva sans avoir les avantages de ses collègues de bureau.

Force est de constater qu'Euriware joue encore à ce petit jeu (source APEC) :

Alors qu'Euriware n'a plus de rapport avec Areva.

Bref, c'est moche de tagguer l'annonce sous la société Areva... Déjà que ce n'était pas terrible avant :D

Mon petit 0day pour l'ANSSI :)

Au cours d'un test un peu farfelu je suis tombé sur une faille un peu inclassable et un peu inutile :)
Mais finalement vu tous les articles sur la "privacy" qu'on peut lire actuellement, je vais balancer mon 0day... et puis je doute obtenir un bug bounty de Microsoft.

Je faisais de la classification d'informations recueillies avec FOCA et j'ai creusé un peu plus que nécessaire dans les metadata des documents récupérés. Dans un premier temps j'ai fait une passe sur les metadata des fichiers PDF avec pdfinfo, puis j'ai fait la même chose sur les images avec exiv2. Et là je me suis dit. Est-ce qu'on ne pourrait pas chopper les données exif des images contenues dans les pdf ???

Rien de plus simple ! Il existe un outil qui s'appelle pdfimages pour extraire les images des pdf. Alors en route.

#!/bin/bash

# dependances:
# md5deep
# poppler-utils -> pdfimages

mkdir images
for file in *.pdf
do
 echo ${file}
 pdfimages -j "${file}" ./images/"${file}"
 #on vire les bouzins n&b
 find ./images/ -name "${file}*.pbm" -exec rm -f {} \; 
 #ppm
 find ./images/ -name "${file}*.ppm" -size -300k -exec rm -f {} \; 
 #jpg
 find ./images/ -name "${file}*.jpg" -size -20k -exec rm -f {} \;
 #moulinette pour virer les doublons
 md5deep "./images/${file}"* | sort | while read arg1 arg2
 do
  newsum=$arg1
  if [ "$newsum" = "$oldsum" ]
  then
   rm  "$arg2"
  fi
  oldsum="$newsum"
 done
done
#doublons inter documents
md5deep ./images/* | sort | while read arg1 arg2
do
 newsum=$arg1
 if [ "$newsum" = "$oldsum" ]
 then
  rm  "$arg2"
 fi
 oldsum="$newsum"
done

Ce script va extraire les images dans un sous-répertoire, ma première idée était de visualiser les images pour ne pas à me palucher 800 documents à lire. Donc j'ai mis une moulinette qui supprime les images trop petites. A vous de voir la quantité d'images que vous obtenez.
A noter que PDF Creator simule une imprimante virtuelle. J'ai l'impression qu'il fait des miettes d'images minuscules (des milliers). C'est pour cela que j'ai viré les petites images.

Puis enfin je passe le script exif sur les images :

#!/bin/bash
# dependance: exiv2

for file in *.jpg
do
 nbLine=$(exiv2 ${file} | grep -c "Exif")
 if [ "${nbLine}" -ne 0 ]
 then
  echo ${file}
  exiv2 -pt -u "${file}"
 fi
done

Si je prends par exemple un fichier appelé ANSSI_Presentation_PASSI_du_10_sept_2013.pdf, j'obtiens les informations suivantes avec pdfinfo :

pdfinfo ANSSI_Presentation_PASSI_du_10_sept_2013.pdf 
Creator:        Microsoft® PowerPoint® 2010

Et la sortie de mon script :

Exif.Image.0x0302                            Ascii      22  Photoshop ICC profile
Exif.Image.Software                          Ascii      37  Adobe Photoshop Elements 8.0 Windows
Exif.Image.DateTime                          Ascii      20  2011:08:09 09:08:37
Exif.Photo.UserComment                       Undefined 122  CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 90

Rien de vraiment intéressant, mais une belle preuve de concept montrant qu'Office 2010 ne supprime pas les données Exif des images intégrées dans les documents lorsqu'ils sont enregistrés en PDF. Je n'ai constaté le même résultat avec PDF creator ou PDF distiller. Je n'ai pas non plus tester sur un fichier issu d'Office 2013.

Review: The practice of network security monitoring

Je suis un fidèle lecteur de Richard Bejtlich et j'avais beaucoup aimé The art of network security monitoring. C'est pourquoi j'ai sauté sur son nouveau bouquin The practice of network security monitoring.

Pour tout vous dire, je l'ai reçu samedi et fini ce soir. Finalement autant parce que j'en attendais beaucoup que parce qu'il est creux. En effet une des idées que je défends et que Richard défend également est qu'il vaut mieux connaître des techniques et des stratégies que de savoir utiliser bêtement des outils.

Et son livre en est presque l'exemple opposé. Je vais un peu détailler les chapitres. (Le sommaire complet du livre est ici.)

Partie 1 (50 pages) : 
Chapitre 1 : On en retient qu'il n'y a pas de défense parfaite et qu'il faut monitorer son réseau pour savoir ce que fait le pirate, comment il est rentré et ce qu'il a volé. La sécurité est un cercle d'amélioration continu...

Chapitre 2 :  Le NAT c'est pas cool il faut sniffer là où ce n'est pas NATé donc derrière le firewall sur chaque patte interne alors que sans NAT on aurait pu sniffer simplement sur la patte externe.

Partie 2 (60 pages) :
J'installe Security Onion en local ou en distribué (juste des options à cocher lors de l'installation).

Partie 3 (70 pages) :
Très légère introduction pleine de capture d'écran aux outils suivants : tcpdump, dumpcap et tshark, Argus et Ra, Wireshark, Xplico, NetworkMiner, Squil, Squert, Snorby, ELSA.
Vous en apprendrez largement autant en cherchant chaque nom sur Google.

Partie 4 (120 pages) :
On commence enfin à voir de la valeur ajoutée.
Chapitre 9 : En 20 pages on a plein de définitions et le fonctionnement d'un CIRT. La finalité n'est pas de remonter des alertes, mais de traiter les alertes. C'est intéressant mais beaucoup trop court à mon goût.

Chapitre 10 : Compromission d'un serveur avec scan du réseau interne. Bonne démonstration de l'utilisation de Squil, Tshark et Bro. En plus macro on voit comment suivre les sessions pour identifier les rebonds et tracer les actions du pirate.

Chapitre 11 : Compromission d'un poste utilisateur et rebond sur un autre poste de travail. Belle démonstration de ELSA et Bro

Chapitre 12 : Comment dumper automatiquement les exe des communications réseau et envoyer manuellement les hash à virustotal.
Utilisation du module ATP1 (proof of concept) qui permet de rechercher des IOC (indicators of compromise) dans les différentes traces (DNS, certificats, MD5 de fichiers).
Utilisation de la MHR (malware hash registry) de la Team Cymru. qui fait un peu comme VirusTotal mais via des requêtes DNS.

Chapitre 13 : A l'instar du NAT, les proxy font sauter la correspondance des adresses IP. Bref il vaut mieux avoir accès aux logs du proxy.
Explication du mécanisme d'Offloading qui consiste à laisser la carte réseau calculer les checksums des paquets, ce qui fait que les tcpdump générés par le système d'exploitation sont à 0x0000. Ces fichiers sont parfois ignorés par les outils d'analyse dont Bro.

Conclusion : Ca va être compliqué avec le Cloud ?!

Bref, je n'ai trouvé que le chapitre 4 à mon goût, mais du coup c'est vraiment trop court pour assouvir ma faim. Je ne peux recommander ce livre qu'aux débutants qui auraient la volonté d'installer Security Onion, mais pas aux personnes qui connaissent le sujet et qui auraient voulu y découvrir de nouvelles techniques.

Update 22/08/13 : Un post sur le blog pauldotcom confirme exactement mon avis, mais en étant plus gentil.

The Tangled Web

Ayant la chance d'avoir beaucoup de transport quotidien, je peux dévorer un certain nombre de livres. J'ai acheté The Tangled Web de Michal ZALEWSKI l'année dernière et je n'avais pas encore pris le temps de le lire car j'avais peur que ça soit trop orienté développement sécurisé de Browser.

En fait Michal est un véritable surdoué. Il est à la fois un expert technique incontestable et un écrivain très clair dans ses explications. Il a réussi à organiser le livre en plusieurs parties logiques :

• Présentation du web, des protocoles et des échanges qui entrent en jeu (100 pages),
• La sécurité des browsers (100 pages),
• Les problèmes de sécurité qui restent à régler et ceux à venir (50 pages).

Dans chaque partie Michal donne de nombreux exemples de vulnérabilités qu'il a découvert dans les browsers et n'épargne pas Chrome, mais il aborde aussi de temps en temps la sécurité des serveurs web car ils peuvent être piégés pour renvoyer de mauvaises données aux navigateurs. J'ai enfin compris à quoi pouvait servir l'attaque "response splitting".

Le niveau de détail est tel qu'il est possible de comprendre un très grand nombre de subtilités sur les navigateurs et le pourquoi du comment des XSS en UTF7, UTF8, du clickjacking, du tabnapping et d'autres attaques dont je n'avais pas ou peu entendu parler : cookie forcing, superposition de fenêtre, timing attack on user interface.

Bref si vous avez toujours voulu savoir pourquoi il faut mettre "secure" et "httponly" sur les cookies, pourquoi il faut configurer les headers "X-Content-Options: nosniff" et "X-Frame-Options: sameorigin" sur votre serveur, alors ce livre est fait pour vous.

Petit état de l'art du cassage de mots de passe (matériel)

M'intéressant un peu au cassage de mots de passe, j'ai fait quelques tests et j'avoue être assez content du résultat car des mots assez longs sont tombés :

Mais pas à n'importe quel prix... Force est de constater qu'avec un quad core on prend vite 2 semaines dans la vue pour seulement décliner genre 100 000 fois un dictionnaire de 15 Go :D

Il m'est alors passé par la tête de lorgner du côté des professionnels. Encore une fois pour tomber sur un concours de b*** il suffit de chercher "benchmark" sur le forum de hashcat. On tombe alors sur ce genre de bête :

 

Là on est dans une toute autre catégorie. Outre le fait que ces 8 cartes AMD 7970 coûtent encore 300€ chacune, celles-ci consomment 300W, ce qui nécessite donc plus de 2400W (sans oublier de quoi faire fonctionner la carte mère). Ce boitier serveur a donc 3 alimentations. Je doute trouver ça à Montgallet ou sur leboncoin...

Moins visible cette fois-ci, c'est l'aération. Là encore ce boitier dispose de 3 ventilateurs 12cm en frontal et des cartes graphiques dont le modèle évacue l'air chaud sur le dessus (dans la configuration ci-dessus). Les GPU tournent à fond et sont en général overclockés.

Si maintenant vous chercher une configuration plus accessible il est recommandé de commencer avec 3/4 cartes graphiques espacées d'un slot pour les laisser respirer et limite laisser le boitier ouvert.

Pensez simplement à faire le ménage de temps en temps.

Pour continuer dans les astuces (ou dans l'état de l'art), il faut savoir qu'on peut utiliser des GPU de constructeurs différents (au final c'est toujours AMD) et surtout qu'on peut mettre des GPU différentsdans une même machine. Cela semble poser encore quelques problèmes sous Windows 7, mais passe très bien sous Linux. C'est un bon point pour la récup ou pour évoluer progressivement.

Dernier point, un projet appelé VirtualCL permet d'échanger les instructions openCL par le réseau. Cela permet d'utiliser plusieurs machines en cluster. Autant la charge est faible pour du cassage en bruteforce, autant elle explose quand on travaille avec un dictionnaire. Pour ce dernier point vous pouvez consulter cette présentation. Il s'agit d'un membre actif de hashcat qui a ainsi réalisé un cluster de 25 GPU composé de 4 types différents de cartes graphiques.

Evidemment pour rentabiliser ce genre de matériel, le propriétaire en a fait son activité : http://stricture-group.com/ (audit de password, cassage de hash, ...)

Si vous avez été attentif, seul AMD est cité et non Nvidia. Etrangement Nvidia ne fournit pas de fonction pour faire le décalage de bit. A cause de cette fonction, à matériel équivalent, AMD est 4 fois plus rapide que Nvidia.

Tiny Tiny RSS sur synology

Bon... J'ai testé Kriss_Feed et j'en suis revenu. L'initiative est louable mais ne correspond pas à mon besoin d'avoir un lecteur RSS synchronisé sur mon ordi et convivial sur android. L'affichage est pas glop sur un smartphone, mais en plus il me manque une fonction essentielle à laquelle je n'avais pas pensé : le mode hors connexion. On a beau dire ce qu'on veut, mais la 3g dans le train c'est pas la joie. On ne capte correctement que dans les gares :D

Bref j'ai poursuivi mes recherches et je suis tombé sur Tiny Tiny RSS.
L'interface dans un navigateur est top moumoute :

Et il a un client pour Android lui aussi top moumoute avec un mode hors connexion :

Pour l'installer sur Synology j'ai trouvé 2 tuto :

• En allemand avec mysql
• En anglais avec postgresql

J'ai fait un mixte des deux pour bien tout comprendre :D

Tout serait parfait si le client android n'était pas une démo valable 7 jours et que la vraie appli coûte 1,52€ !!!

Bref j'ai encore cherché un peu et je suis tombé sur un article indiquant que l'appli est en licence GPLv2 et donc que la code source est libre et donc que des gars l'ont compilé de leur côté et donc que c'est à télécharger ici gratuitement :)

Pour ceux qui ont un raspberry il y a un modop ici pour TTRSS (et accessoirement pour Kriss_Feed).

Shaarli et Kriss feed (auto-hébergement sur Synology)

Ca y est c'est la fin... A peine ai-je mis en place les bribes de la stratégie de veille avec Google Reader que tout s'effondre. Le 1 juillet 2013 Google Reader fermera ses portes. T_T

Bon qu'est-ce qu'on a comme concurrent qui ne se base pas sur l'API google reader ? Pas grand chose on dirait.

Mais à peine le temps de commencer la recherche que je tombe sur le message d'un mec qui aime bien gueuler : Sebsauvage. Ce développeur blogueur montre justement un exemple de logiciel que l'on peut installer chez soi pour être indépendant des aléas des sociétés à but lucratif.

Bref Sebsauvage propose d'installer l'application Kriss_feed de Tontof.

L'interface est sobre. Il est possible de grouper les liens. L'affichage est correct sur Android (les boutons sont trop énormes). Bref à voir sur la durée.

Maintenant il me reste à pouvoir classer les messages qui m'intéresent et c'est là qu'intervient Shaarli de Sebsauvage himself.

Shaarli est un mélange de Evernote, Twitter, microblog, StumbleUpon, Delicious. Bref il est ce que vous décidez d'en faire :D

Le principe est simple : vous créez un mini-message de description pour le lien que vous voulez partager et c'est fini. Vos amis n'ont qu'à suivre le flux RSS pour savoir ce qui vous a plu récemment. Mais il n'est pas obligatoire de partager les liens. Il y a un mode privé aussi qui est prévu à cet effet.

Le petit plus de Kriss_feed est qu'il y a un lien dans l'interface pour pousser le lien directement dans Shaarli afin de sauvegarder vos messages préférés. C'est Shaarli qui vous permettra de gérer les tags pour retrouver les informations par thème. Je pense que ça va bien me servir.

Les deux développeurs partagent la même philisophie de codage : Un fichier fichier de code et pas de base de données. C'est vraiment le rêve à déployer :)

Petite subtilité pour utiliser les deux applications sur un Synology : il faut activer l'extension zlib qui doit servir à compresser le fichier d'index qui remplace la base de données.

Je vais tester tout ça d'ici la mort de Google Reader en espérant que ça réponde à mes besoins.

La sécurité informatique avec un oeil extérieur

Au hasard de mes balades numériques je suis tombé sur le document suivant : Enquête sur la sécurité numérique des entreprises. La première chose qui saute aux yeux est que le rapport n'est pas écrit par un spécialiste du domaine (Bruno Gruselle) et qu'il ne semble pas non plus destiné aux acteurs du domaine. Il est indiqué qu'un questionnaire a été utilisé pour mener les entretiens avec 21 entreprises, mais les réponses semblent très libres et finalement c'est très plaisant à lire car des vérités ressortent et j'ai décidé de les retranscrire ici en espérant vous donner envie de lire ce rapport.
Bonne lecture.

Introduction :
Le premier point d'attention est de bien distinguer la sécurité informatique de la sécurité de l'information. Ces deux facettes sont gérées généralement par les mêmes acteurs alors que la sécurité des données serait plutôt du périmètre de la protection du patrimoine. Bien sûr cette remarque concerne surtout les grosses entreprises.

Les risques :
Les RSSI reconnaissent que les risques numériques sont critiques pour l'entreprise, mais qu'il faut distinguer parmi les attaques le bruit de fond (phishing, scans de ports, sites Internet piégés par des kits d'exploit) des attaques pouvant avoir un impact important (intrusion, fraude). A noter qu'en matière de phishing, il y a et aura toujours un taux incompressible d'erreur (humaine ?) qui devrait être pris en compte par les solutions de sécurité mises en place pour dépanner les utilisateurs qui se sont fait piéger.

Le niveau des attaques dépend souvent de la réputation et de la visibilité des entreprises. Pour les banques l'impact d'une attaque réussie serait très mauvais pour leur réputation. La préoccupation actuelle est aux APT (bizarrement écrit Advanced Permanent Threat partout sauf une fois Persistant) dans le sens où une bonne configuration des FW et un patch management correct ne sont plus suffisants. Surtout qu'en face nous avons des pirates professionnels.

Un point intéressant qui ressort est l'isolation de certains réseaux. Par exemple il est préférable d'isoler les systèmes critiques (SCADA) et les environnements R&D. Bien qu'ayant un coût important, cette mesure permet d'éviter bon nombre de risques.

En ce qui concerne les environnements type SCADA, l'enjeu n'est pas la confidentialité (à part les secrets de fabrication, configuration, ...) mais la disponibilité. On parlait avant de sûreté de fonctionnement, mais on converge vers la sécurité informatique.

L'organisation :
Côté organisation il semble que la plupart des entreprises ont mis en place un réseau de correspondants sécurité qui ont pour rôle de s'assurer que la politique de sécurité est appliquée et d'être en soutien aux utilisateurs pour les questions de sécurité.

En ce qui concerne le RSSI, il peut être dans la direction sécurité du patrimoine (sous la DG), sous le DSI, ou bien il n'y a pas vraiment de RSSI, mais un groupe d'acteur de chaque direction (DSI, RH, juridique, métier, ...). Il ressort qu'un RSSI sous la DSI gère de la sécurité Informatique alors qu'un RSSI sous la DG sera plus à même de faire de la gouvernance, avoir un rôle de prescripteur et d'assistance aux projets.

"Ainsi comme le souligne l'un des interlocuteurs, la notion de RSSI est une aberration car il faut concevoir la sécurité comme tout autre fonction et pas comme un métier à part. On doit faire évoluer pour intégrer la sécurité dans les besoins de tous les projets et pas comme une contrainte externe portée par une direction qui intervient en dernier ressort."

"Certaines des personnes concernées jugent toutefois que le manque de contraintes (comme celles qui peuvent peser sur le secret de la défense nationale) conduit à donner un poids plus important aux problématiques d'économies de préférence à celles de sécurité."

"Si la relation avec la CNIL est en général bien cadrée - du fait de la prise en compte des obligations réglementaires ou légales qui pèsent sur l'entreprise - le contact avec l'ANSSI est parfois plus compliqué. Pour certaines interlocuteurs, l'agence est encore trop peu réactive et s'intéresse encore trop aux grands comptes lés à l'Etat plutôt qu'à l'ensemble du tissu économique."

"L'une des personnes interrogées souligne que l'un des défis de sécurisation est de faire venir les utilisateurs à la sécurité plutôt que de les obliger à appliquer des mesures qu'ils ne comprennent pas ou qu'ils trouvent inutiles, voire incompréhensibles."

"Les éléments contractuels doivent être suffisamment précis pour englober la responsabilité du sous-traitant à un niveau équivalent à celui des sociétés appartenant au groupe."

"Le cadre juridique - quand il est clair et précis - s'avère en fait d'une grande aide et simplifie le travail de sécurisation."

Les orientations :
Plusieurs entreprises commencent à mettre en place un SOC (équipe de supervision dédiée).
Il va être important de créer un dispositif d'alerte et de gestion de crise.

La sensibilisation et la formation est toujours une priorité.
"Pour autant il faut noter l'existence de deux tendances antinomiques : d'une part on ne peut pas tout miser sur l'utilisateur et il faut concevoir la sécurité en imaginant que l'utilisateur va faillir. D'autre part les failles ou les attaques importantes (APT) sont le plus souvent détectées par les utilisateurs. Il est donc indispensable de faire de l'information, de la sensibilisation et de la formation."
" Il existe deux niveaux de formation : directement après le recrutement qui permet généralement de présenter les risques, la politique de sécurité mise en place et les outils de l'entreprise. Ensuite dans le cycle de vie de l'employé, se déroulent des modules spécifiques sur les SI et leur sécurité."

La progression du cadre juridique et réglementaire qui va apporter de nouvelles contraintes : déclaration des incidents, création d'un CIL, gestion des lois au niveau international.

"Enfin, quelques personnes rencontrées se sont étonnées de l'absence d'un outil juridique qui permettent d'imposer un certain niveau de confidentialité aux informations non industrielles détenues par leurs entreprises (de type secret des affaires)."

Mac mini et Debian, EFI et GPT

Je m'amuse comme un petit fou avec mon Mac mini (comprendre : ça fait une semaine que je perds mes soirées et que je n'avance pas).

J'avais donc prévu d'installer un ESXi, dessus mais en fait le côté hyperviseur "bare metal" m'a rebuté car il n'est pas possible d'utiliser le serveur comme station de travail en même temps (enfin c'est possible d'attacher une 2ieme carte graphique à une VM, mais je ne vois pas où je vais la mettre sur un Mac mini). Il m'aurait donc fallu un autre ordinateur pour me connecter aux machines virtuelles.

J'ai donc décidé de donner une chance à proxmox mais en l'installant sur une Debian et non en natif. A vrai dire je n'en suis qu'à l'étape Debian, mais c'est déjà pas mal :D

La première étape pour installer un nouveau système est évidemment de booter sur une clé USB (vu que le lecteur externe coûte un œil). Bref je me fais une clé Debian avec unetbootin et je redémarre. Bon je cherche le BIOS, par réflexe j'appuie sur del, F10, F12, mais j'aurai pu essayer toutes les touches du clavier car il n'y plus de BIOS sur les machines Macintel, mais un UEFI. Qu'à cela ne tienne, je trouve d'obscures raccourcis clavier à base de pomme et alt. Là encore c'est l'échec et je tombe sur un KB officiel d'Apple qui indique qu'il n'est pas possible de faire les manipulations au boot avec un clavier sans fil.

Finalement je suis tombé sur l'application Refit, puis sur son successeur Refind qui permet de détecter les systèmes présents et de sélectionner celui de son choix y compris sur clé USB ! Je peux donc booter sur ma live Debian. Au passage Debian a mis au point un système hybride qui permet d'extraire l'ISO du CD directement sur la clé USB avec la commande DD, mais je n'ai pas réussi à le faire :/

Je peux enfin commencer l'installation de ma Debian. Je suis un premier post qui m'indique que c'est bien possible à faire, mais le petit malin est en single boot. Je fais donc un partitionnement tout propre et je colle grub sur le MBR, sauf qu'il n'y a plus de MBR. En effet ça aussi je l'ignorais, mais les nouveaux systèmes configurent les disques en GPT. Cela permet d'avoir des partitions de plus de 2,2Go et 128 partitions sans passer par des bidouilles de partitions étendues ou encore du LVM. Mais au passage le MBR a été supprimé. J'ai donc un système installé  sur lequel je ne peux pas booter malgré Refind. Il faut en fait installer un grub-efi sur la première partition du disque en suivant ce second post.

Pour installer grub-efi je suis repassé par la Debian USB en mode live et comme il y a peu de drivers j'ai dû passer en mode sans échec et brancher une clé WIFI alfa car celle du Mac n'est pas reconnue. Il faut faire un chroot sur le système installé puis télécharger grub-efi et faire l'installation.

Et voilà ! J'ai mis une semaine à faire le genre de chose que je faisais en 1h avec le BIOS et le MBR, mais ça m'a appris plein de choses et je mettrai moins de temps la prochaine fois :)

Protection des mots de passe

On le voit tous les jours maintenant, des sites sont compromis et des tonnes de miyons de mots de passe sont volés !

Dommage pour vous votre mot de passe Paris75 est grillé dans le monde entier à cause du dernier site à la mode www.glandouille.com. En plus il faut le changer sur 36 sites et en urgence sur votre messagerie, ebay et paypal !

Bon on a tendance à toujours taper sur l'utilisateur, mais quand bien même il utiliserait un mot de passe complexe. qu'est-ce qui empêche un site de stocker ses mots de passe en clair ou en XOR ou encore en md5 ? Rien du tout... (ou peut-être PCI-DSS...)

Finalement je suis tombé sur un article disons sympa qui présente des statistiques non pas seulement sur la résistance des mots de passe, mais aussi sur la robustesse des algorithmes de hachage (je n'aime pas écrire hachage car je l'emploie comme un anglicisme).
http://resources.infosecinstitute.com/the-exponential-nature-of-password-cracking-costs

Dans un premier temps on commence avec un gentil MD5 et on voit qu'un mot de passe avec les 4 catégories de caractères est résistant à partir d'une longueur de 7 caractères alors qu'il faut plus de 10 lettres pour avoir un semblant de résistance identique. (Pas la peine d'évoquer un code PIN de 4 chiffres ici.) A mon avis les graphes sont au pif, mais l'idée est là :D

Maintenant ce qui est sympa c'est la comparaison de MD5 à bcrypt qui est un algorithme créé exprès pour protéger les mots de passe et non pour faire de la vérification d'intégrité (obligation de performance tout ça... bien pratique pour faire du bruteforce rapide).

Or donc bcrypt est basé sur un algorithme qui nécessite beaucoup de cycles processeur pour hasher un mot de passe. J'ai cru lire qu'un md5 prenait 1ms et un bcrypt 0,3s, soit 300 fois plus longtemps. Mais le plus beau dans l'histoire c'est qu'on peut même choisir le nombre d'itérations pour gonfler encore le temps de traitement. Et c'est ainsi qu'on obtient un algorithme robuste avec 6 caractères quand il en faut plus de 10 en MD5.

Et donc pour conclure, si on fait embête à choisir des mots de passe très longs, c'est parce que potentiellement ils sont mal protégés ! Mais en lui même le mot de passe n'est pas forcément mauvais.

Rainbow tables

Dans toute la petite ribambelle de blogs que je suis, celui de Robert David Graham me plaît particulièrement car il passe son temps à casser les mythes de la sécurité informatique. Je vous invite à suivre son blog Errata Security.

Un article récent m'a particulièrement interpellé car je faisais partie de ceux qui se trompait et il s'agissait de l'utilisation des Rainbow Tables. Il explique à juste titre que c'est loin d'être la panacée quand le minimum de précaution est respecté, c'est à dire désactiver le stockage des hash LM et mettre une politique de complexité des mots de passe à 8 caractères contenant 3 des 4 catégories suivantes : minuscules, majuscules, chiffres et caractères spéciaux.

Les rainbow tables sont malgré tout très grosses. La seule table présentant en intérêt serait "ntlm_mixalpha-numeric#1-8_40000" sur http://www.freerainbowtables.com/tables/ et on peut s’asseoir sur les caractères spéciaux et les mots de passe de plus de 8 caractères.

Mais le plus important est que la recherche des hashs dans la rainbow est séquentielle (ce qu'on peut voir dans l'image ci-dessous avec le cassage de "p@sswor", puis "d"). L'opération se fait hash par hash, ce qui fait que le nombre de hash multiplie d'autant le temps de calcul. Dans une entreprise avec 10000 comptes utilisateurs et un historique de 5 mots de passe on atteint facilement 60000 hashs. Je me souviens avoir passé une nuit à l'hôtel pour casser 300 hashs, alors pas la peine de faire le calcul pour 60000.




Bref si on veut casser un maximum de mots de passe (disons pour faire des statistiques), il faut s'en remettre au cassage avec GPU et un bon dictionnaire. Ce dictionnaire contient 14 millions de mots de passe unique et avec quelques mutations (min/maj et concaténation de chiffres à la fin) on casse très rapidement une grosse moitié des hashs. Vous trouverez quelques bases de mots de passe sur le site de skullsecurity. Mais la meilleure source de mots de passe, ce sont les résultats des audits précédents qu'il faut anonymiser et conserver précieusement. C'est sur cette idée que c'est basé Rob Fuller quand il a créé White Chapel dont l'idée est de créer une base de mots de passe issus de toutes les sources possibles (mysql, sqlserver, vnc, Active Directory) et de tout rehasher avec tous les algorithmes possibles.




Voilà encore une bonne raison de faire de la capitalisation :-)

Veille en vulnérabilités et patch management

Aujourd'hui j'ai repensé au patch management. Est-ce que la veille en vulnérabilité est si importante que cela ?

Admettons qu'on n'ait pas encore atteint une maturité suffisante pour mettre à jour régulièrement (disons 2 ou 3 fois par an) certaines applications telles que Flash, Adobe Reader et Java. Dès lors qu'il y a une vulnérabilité critique, est-il nécessaire de poursuivre la veille en vulnérabilité sur ces applications jusqu'au déploiement de la nouvelle version ? Certains diront qu'il faut aussi faire de la veille sur l'exploitation de ces vulnérabilités, par exemple en regardant les failles exploitées dans les principaux exploit packs. Malheureusement ces informations sont encore dures à obtenir. Ou alors on se limite aux logiciels commerciaux comme le fait Nessus en listant les vulnérabilités exploitées par Metasploit, Core Impact et Immunity.

Prenons maintenant le cas opposé, un parc Microsoft avec un bon WSUS ou SCOM. Si la mécanique est bien rodée et que les patchs sont déployés dans le mois courant, faut-il faire plus de veille que de suivre les patchs hors cycle ?

Il me semble donc que dans tous les cas une veille intense n'est pas nécessaire. A noter que je ne m'avance pas pour les environnements critiques et industriels qui sont d'un autre ressort.