mardi 20 août 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.

jeudi 15 août 2013

La gestion risque/coût au quotidien

C'est étrange comment pour économiser quelques euros on peut intuitivement faire des paris et risquer de perdre plus.

Comme tous les 2 ans j'ai emmené ma voiture au contrôle technique et j'ai hésité à faire une pré-visite dans un garage. D'un côté je sais, je sens, qu'elle roule bien. Elle n'a que 7 ans. Il y a bien un impact sur le pare-brise, mais il est net et ne devrait pas se fissurer. Puis en fait la franchise est la même pour son remplacement ou pour une injection de résine... Alors ça peut attendre.

Bref je prends le risque d'emmener ma voiture directement au contrôle technique, mais je sais que je peux au moins contrôler les feux moi-même. Et ça n'a pas raté ! J'avais un feux de position et un feux de brouillard arrière grillés... Surtout que ça peut se changer tout seul. Bref je change les ampoules, mais le feux de brouillard ne veut rien savoir. Un tour sur Internet et je découvre d'une part qu'il n'est pas contrôlé et d'autre part... qu'il n'est pas utilisé, juste décoratif (pourquoi mettre une ampoule dans l'emplacement alors ?).

Résultat OK pour le contrôle technique. Ca aurait été bête de ne pas faire ce petit contrôle juste avant :)

PS : j'ai pris une ampoule Norauto et non Philips pour gagner 5€. Là encore je prends un risque, mais d'un autre côté ils les vendent par pack de 2. J'ai une marge de manœuvre :D

Pentest sur la production ou non ?

Un nouvel appel d'offre tombe, on nous propose d'auditer un système de gestion de chèques. Il est demander de faire des tests de corruption de données. "Avez-vous des questions ? - Oui, s'agira-t-il d'un système en production ? - Tout à fait cela sera en production."

Très bien monsieur le client ! Vos désirs seront nos ordres. Il n'est évidemment pas de notre ressort de contredire le client surtout dans un appel d'offre... Mais juste juste pour rappel, ce n'est pas parce qu'on est assuré professionnellement pour ce type d'activité qu'on sera tenu responsable en cas d'incident. En effet le client est responsable de ce qu'il demande de faire sur son SI. Le pentester doit rappeler les risques et le client valide (accepte de prendre la responsabilité). Lorsqu'on veut faire un débordement de tampon, on pose la question avant le test en précisant que le service peut devenir instable et qu'il faudra peut-être le relancer par la suite. Le pentester se dégage alors de toute responsabilité si le client accepte de faire le test.

Cela étant dit, pourquoi les clients nous demandent de faire des tests en production ? Est-ce mieux ou moins bien que sur un système en pré-production ?

Je vois plusieurs raisons à ce problème :
  • On n'a pas de pré-production :)
    Une recette alors ? Euh chez le prestataire chargé du développement, mais on n'y a pas accès.
    Il y a effectivement encore beaucoup de systèmes gérés à l'arrache sans environnements de pré-production et recette. Comment font les équipes pour être sûres qu'une mise à jour fonctionnera correctement ? Ca pourrait être une vulnérabilité à mettre dans notre rapport...
    Alors faites bien une sauvegarde avant l'audit et chaque soir. Oui, il faut le rappeler... Et donnez-nous un contact à appeler si le système devient indisponible.
    Bref on bosse sur un système vivant, mais avec beaucoup de contraintes et de risques.
  • On a un système qui vient d'être livré (en production) et pas encore d'utilisateurs, donc aucun impact sur la production. Sauf qu'il est vierge... Les bases de données sont vides.
    Dans certains cas cela n'est pas gênant, mais de plus en plus de fonctions ne sont accessibles que lorsque des données sont présentes en base. Il faut demander à ce que de fausses données soient présentes ou bien une copie de la production.
    Il m'est arrivé plusieurs fois récemment de faire un pentest à la fin du développement d'un projet, avant qu'il soit mis en production. Il n'y a rien de pire que de tester un système vierge, par exemple un site de recrutement dans lequel il n'y a pas d'offre d'emplois et aucun profil de candidat... Il faut alors se palucher les modes d'emploi et découvrir le fonctionnement du site.
    Encore pire, le système était en cours de livraison. Les fonctions arrivaient les unes après les autres. Le lundi on voyait une page d'erreur avec un mot de passe en clair, puis le mardi une nouvelle partie du site apparaît à la place...
  • On a bien un système en pré-production, mais il n'est pas interfacé avec le même annuaire et avec les mêmes webservices.
    A la rigueur on peut travailler en pré-production, puis faire les tests de contournement d'authentification en production.
  • On a un système en production avec des données similaires à la production et toutes anonymisées.
    Voilà, on y est. C'est le Paradis. Sauf que j'en ai entendu parler et je ne l'ai jamais vu :)
Bref, le pentester a beaucoup de donne volonté, mais si on ne lui donne pas les bonnes conditions pour réaliser tous les tests correctement, il va éviter de faire ceux qui peuvent secouer la production comme une blind SQL injection ou alors il va rater des fonctions car elles n'étaient pas activées faute de données disponibles. Et on ne pourra pas le tenir responsable.

Alors cher client, si tu veux rentabiliser ton audit en optimisant le temps de travail des auditeurs pour qu'ils trouvent le plus possible de vulnérabilités, prépare leur un beau terrain de jeu en pré-production avec des données représentatives.

lundi 12 août 2013

Si c'est pas malheureux :-/

Bonjour M. xxx,
Nous avons été en contact en début d’année pour un poste d’ingénieur sécurité au sein de yyy.
Le process n’avait pas abouti car vous aviez préféré donner suite à une proposition de collaboration d’un de nos concurrents.
Néanmoins, j’avais vraiment apprécié nos échanges et je me permets donc de revenir vers vous aujourd’hui afin de vous demander si vous connaissez dans votre entourage des profils qui seraient susceptibles d’être intéressés par nos offres d’emploi. Ma cible première, concerne des candidats avec 3-6 ans d’expérience en sécurité réseau.
Je vous remercie beaucoup pour votre retour et pour votre aide,

Bien cordialement,

zzz | Chargée de Recrutement

------------------

J'en ai encore la larme à l'œil de cet appel en détresse. Comment transformer des candidats qui ne sont pas venus en chasseurs de tête gratuits ???
Un chasseur de tête est généralement payé entre 10 et 30% du salaire annuel du recruté alors qu'une cooptation peut aller de 300€ à 1500€.
Bref du gros foutage de gueule de SSII.

dimanche 9 juin 2013

Kali sur Android

Ce petit post pour faire un récapitulatif des manipulations à effectuer pour installer Kali sur Android et plus particulièrement sur un Galaxy Note 8.

Tout d'abord pour installer un linux ARM sur Android il faut avoir les droits root. Je laisse à chacun l'exercice d'aller sur Google et xda pour trouver son bonheur. Pour la Note 8 c'est ici (framaroot).

Ensuite il faut télécharger le programme "Linux deploy" sur Play. Kali est directement installable depuis le menu sans devoir télécharger un iso indépendamment. Je vous préviens d'avance, il faut configurer un disque de 6Go pour pouvoir installer par la suite les outils de hack. L'installation initiale ne déploie que le noyau il faut ensuite installer les packages. La méthode rapide est la suivante :

sudo -s
apt-get update
apt-get install kali-linux -yq


Cela va occuper 5,5 Go d'espace (ce qui explose les 4Go par défaut), puis avec un apt-get clean on redescend à 4Go...

Petite subtilité, Linux Deploy configure un compte utilisateur appelé "android" et dont le mot de passe est "changeme". Il faut ensuite faire un sudo pour effectuer des actions en root.

Pour me connecter à Kali j'utilise "connectbot" et pour VNC "android-vnc-viewer" (il faut configurer la résolution du VNC dans Linux deploy 1280x800 pour la Note 8). Pour le clavier le top c'est Hacker's keyboard.

Pour info Metasploit se lance en 1 minute alors qu'il me faut 8 minutes sur raspberry :)


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.

mercredi 22 mai 2013

Synology : réconcilier Youtube et Free

Comme tout le monde le sait Youtube depuis une Freebox c'est pas la joie... N'étant pas un gros consommateur de vidéo ou plutôt ne regardant pas des micro-vidéos de chats, je peux me permettre de les télécharger et de les regarder plus tard.

Si vous êtes en manque d'inspiration, regardez du côté de http://www.securitytube.net/. Il y a de très bonnes conférences à mater. (Sinon une recherche sur "film complet" peut faire l'affaire.)

<facultatif>Maintenant que vous avez sélectionné une vidéo il faut ajouter une extension Chrome qui ajoute un lien directement dans la page Youtube pour télécharger la vidéo depuis votre Synology : Synology Download Station.</facultatif>

Cela marchait très bien jusqu'au jour où ça a arrêté de télécharger. Si cela vous arrive, sachez qu'il est possible de mettre à jour les scripts (ou parser) qui permettent de télécharger.

Vérifier bien que vous avez la version 1.7 du parser Youtube sinon recherchez les mises à jour.


Pour les paresseux, il est possible d'ajouter des moteurs de recherches supplémentaires dans le synology dont Youtube. Ces moteurs sont disponibles sur le site de synoboost. En fait vous pouvez tous les prendre et éviter Youtube. Cela polue les résultats :)

Pour les malheureux qui arrivent à vivre sans Synology, il est possible d'en installer un sous Virtualbox. Un tuto est disponible ici.

Allez A+