Quelques notes sur Coriin 2015
mardi 4 août 2015 à 18:00GuiGui's Show - Liens
Le 19 janvier 2015, j'étais présent dans le public de la Conférence sur la réponse aux incidents & l’investigation numérique (http://www.cecyf.fr/activites/recherche-et-developpement/coriin/) organisée par le Cecyf. Voici les notes que j'avais pris ce jour-là.
Mot d'accueil par Éric Freyssinet : le but est de rassembler les enquêteurs, les entreprises, les académiques. En france, on manque de formation concernant les enquêtes numériques. Appel à forker Cecyl.
Présentation du référentiel d’exigences applicables aux prestataires de réponse aux incidents de sécurité, Yann Tourdot et Arnaud Pilon (ANSSI) :
* Roue de Daming : PASSI (audit), PDIS (détection incidents de sécu), PRIS (réponse aux incidents)
* PRIS
* Un prestataire qualifié = un prestataire qui suit l'ANSSI au doigt et à l'œil
* Nivellement (par le bas) du référentiel au niveau des compétences en France. Sérieusement...
* Vu sur twitter : "Dans l'audit, on est 2 (auditeur et audité), dans la réponse à incidents, on est 3 (avec l'attaquant, qui peut être root)" #CoRIIN
* PRIS est itératif, incrémental : toujours faire des analyses post-mortel pour pas que ça se reproduise, pas juste se dire "ho j'ai un virus je le vire et basta".
* Une action judiciaire peut être engagée avant, pendant ou après donc il faut faire attention lors de l'analyse à suivre les préréquis pour que, si l'on va en justice, la demande soit recevable (conservation des preuves, journal des actions effectuées, datation, ...)
* Référenciel de détection établi avec des prestas (oui oui, ceux qui doivent être évalués via ce référentiel) et par des comanditeurs comme les OIV.
* Garantie de confidentialité des analyses par les prestas et si jamais une fuite apparaît -> moyen de poser une réclamation auprès de l'ANSII pouvant conduire au retrait de l'accréditation ANSII.
* Accréditation bullshit et sans valeur sauf si le commanditeur suit les recommandation de l'ANSII de choisir un presta qualifié, ce qui arrivera sur les marchés publics...
* Bilan : ça me semble être un label bullshit... L'ANSII préfère avoir beaucoup de prestas que des prestas réellement qualifiés. Garantir la confidentialité des audits par retrait du label... Sérieusement, quoi. L'ennui c'est que l'accréditation a un coût qu'il faudra reporter sur le client. Elle sera requise d'abord pour les marchés publics, ce qui aura une influence sur le reste du marché...
CERTitude : ou comment simplifier les campagnes de recherche d’IOC, Vincent Nguyen et Jean Marsault (CERT-Solucom) :
C'est un soft qui se connecte à des postes compromis pour remonter les IOC (Indicator of compromise) en laissant le moins de traces possibles. Je ne comprends pas : rien que l'ouverture des connexions laisse des traces. Avantage : un tool python + une remontée via le réseau ira plus vite que la lib winwin de base. :D
D&D de malwares avec des C&C exotiques, Paul Rascagnères et Eric Leblond :
* Fun fact : un botnet dont les zombies reçoivent les ordres du C&C via une boîte mail yahoo \o/
* Exfiltration de données via des requêtes DNS
* Fun fact #2 : "ils font 3 XOR, bon ok, ça revient au même que 1 XOR mais ils devaient pas le savoir [...] rigolez pas, j'ai déjà vu des attaquants faire du double riot13"
* Les IDS c'est bien mais il faut les mettre au bon endroit : pas qu'en bordure, sinon on néglige les échanges internes
* Les "langages" des IDS sont limités. Pas de boucle, par exemple. D'où une extensibilité avec des scritps (Lua par exemple) est souhaitable
* Pas d'appliance magique. Même si leur usage ne nécessite pas 15 personnes en astreinte de nuit pour écrire les regex. #troll. :D
* Les créateurs de malwares avancés suivent ce qui se dit de leur code sur le net et s'adaptent donc les règles IDS peuvent vite être contournées si tu fais pas attention.
* Regex, ça a les mêmes limites que les anti-virus : on peut faire du proactif, voire détecter des comportements anormaux donc suspects mais ça a des limites. Si tu ne sais pas ce que tu cherches -> tu ne trouveras pas, comme d'hab.
Mimikatz et la mémoire de Windows, Benjamin Delpy :
* Bon à rappeler : les attaquants sont des bourrins, ils font des trucs qui marchent, pas des trucs compliqués.
* Fun fact : pour tricher au démineur sous winwin, il suffit d'utiliser deux fonctions de l'API winwin : create process, read process. Pas besoin de droits admins vu que c'est ton démineur. :D
* L'ennemi, c'pas forcément la NSA mais les anciens employés toujours dans le domaine car gestion du domaine sous-traitée donc travail pas fait.
* La fonctionnalité minidump (dump de la mémoire lors d'un crash) est super pratique car pas besoin d'installer un code sur le poste ciblé donc discrétion. Pas besoin de droits admin, même pour dumper le process d'un autre utilisateur : il faut "juste" faire planter le processus visé. L'API winwin permet même de demander un dump sur un processus ciblé.
* Implémentation Kerberos de winwin + minidump = combo : les dumps mémoires du process LSASS contiennent les mots de passe et les tickets Kerberos.
* Fun fact #2 : Bitlocker ne marche pas avec les disquettes :D
* Fun fact #3 : l'API winwin prévoit l'enregistrement d'une DLL qui sera appelée lorsqu'un mdp est changé.
* Le tout permet donc de récupérer des accès.
* Winwin 10 ne sera pas vulnérable à tout ce qui a été exposé.
Investigation dans le DNS, pièges et solutions, Stéphane Bortzmeyer (AFNIC) :
* But de la présentation : comment trouver une info sur un nom de domaine, pièges et limites
* Un nom de domaine a un nombre quelconque de composants. Plus spécifique à gauche, plus global à droite ("."). En voyant un nom, on ne sait pas où se trouve les cut de délégation (exemple : gouv.fr. n'est pas délégué, co.uk si) : il faut utiliser une résolution DNS pour le savoir.
* Plusieurs acteurs dont au moins le titulaire d'un nom (celui qui l'a choisi et réservé) et le registre (l'organisme qui enregistre le nom). Dans la vraie vie, on a un 3e acteur : le bureau d'enregistrement qui s'occupe de la partie business. Modèle RRR (register, registry, registrar). On peut avoir des acteurs supplémentaires : agence de création web qui a acheté le nom ou hébergeur DNS différent du bureau d'enregistrement.
* Deux sortes de registres : mince ou épais. Registre épais : la base de données contenant les informations "sociales" (nom du titulaire, adresse, mail,...) sont stockées chez le registre. Registre mince : ces informations sont stockées chez le bureau d'enregistrement. Exemples de registre mince : com. , net. Registre épais : fr.. Org était épais mais est devenu mince. C'est ça qui explique les redirections que l'on voit dans whois.
* Quels sont les inconvénients à utiliser whois de manière déportée (cloud, site web,...) ?
* Base possiblement pas à jour ;
* On n'a pas la source de l'information (son authenticité est donc à questionner) ;
* Le tiers voit ce que vous faites, ce qui pose de gros problèmes de confidentialité dans le cas d'une enquête judiciaire ;
* Risque de sécurité : des malins enregistrent des noms avec des informations (nom, adresse) avec des bouts de JS/XSS.
* Même si l'ICANN impose que les titulaires de noms communiquent des informations exactes, c'est rarement le cas et pas souvent vérifier : pour quelques euros par an, un humain ne peut pas faire de vérifications poussées.
* Tous les clients whois ne sont pas optimaux parfois même entre systèmes GNU/Linux car les options de compilation sont différentes...
* DNS : pas forcément de coincidence entre whois et DNS, c'est des acteurs différents.
* DNS et caches : attention au fast-forward (nom pour contacter le C&C change rapidement).
* nslookup sous winwin c'est naze : incomplet, pas d'horodatage, il fait des requêtes qu'on ne lui demande pas (reverse IP, serveur de nom)
* mes quqestions :
* Pourquoi BDD passives DNS pas publiques compte tenu du caractère public des infos DNS (cf RFC DNSSEC) ? Sociétés commerciales derrière donc business.
* Tu pourrais nous dire deux mots sur les looking glasses DNS ? C'est bien pour voir la censure et ce genre de choses. Stéphane utilise RIPE Atlas mais on a toujours les limites présentées au début de l'exposé : intervention d'un tier d'où problème habituel de confiance
Internet Explorer 10 et 11: un nouveau format de données pour de nouveaux défis, Jean Philippe Noat et Bruno Valentin :
* Aucune logique dans le nommage des fichiers caches d'IE : webCacheV01, V16 et V24, pas les autres ... pas de logs tournants so wtf ? l'orateur n'a pas la réponse
* Cache pas optimisé : plusieurs tables peuvent servir au même usage, semble utiliser un parcours itératif/index chelou.
* Dans la inforensic, on cherche à savoir si un téléchargement a eu lieu suite à une action de l'utilisateur ou si prefetch ou cache : le stockage de cette info par IE est prévue.
* Ces fichiers d'index du cache sont "sales", pas mis à jour, résiste mal à un arrêt brutal de la machine (ce qui arrive lors de perquisitions) donc beaucoup d'infos manquent à l'appel.
* Fun fact : les applis sur FB et co échappent au cache IE au sens premier. :D
* Fun fact #2 : le cache IE tourne toujours en navigation privée ;)
* Fun fact #3 : l'épinglage/dé-épinglage d'une app est stocké dans une base de données sqlite. Dé-éplinger une app ne fait pas disparaitre les infos dans la base mais un re-épinglage fait disparaître les infos précédentes
FastResponder: Nouvel outil open source pour détecter et comprendre des compromissions de grande ampleur, Sébastien Larinier (CERT Sekoia) :
* Lors d'une compromission, il faut faire une collecte rapide du SI et analyser les infos collectées rapidemment pour agir vite et répondre vite à l'incident de sécurité.
* Analyse à la mano / à la papa : chiant, coûteux et lent. Genre on trouve encore des analyses forensic faites sous Excel.
* Il faut utiliser du matos simple à déployer et des outils de data-visualisation comme Kibana.
* L'intérêt du live forensic (exemple : analyse RAM in-situ) se justifie avec l'augmentation de la quantité de RAM dans les serveurs (64G+ ce n'est plus rare). Je ne suis pas convaincu puisque Zythom, sur son blog, nous parle de dump de disques dur de plusieurs tera, même pendant une perquisition...
(Permalink)
Le 19 janvier 2015, j'étais présent dans le public de la Conférence sur la réponse aux incidents & l’investigation numérique (http://www.cecyf.fr/activites/recherche-et-developpement/coriin/) organisée par le Cecyf. Voici les notes que j'avais pris ce jour-là.
Mot d'accueil par Éric Freyssinet : le but est de rassembler les enquêteurs, les entreprises, les académiques. En france, on manque de formation concernant les enquêtes numériques. Appel à forker Cecyl.
Présentation du référentiel d’exigences applicables aux prestataires de réponse aux incidents de sécurité, Yann Tourdot et Arnaud Pilon (ANSSI) :
* Roue de Daming : PASSI (audit), PDIS (détection incidents de sécu), PRIS (réponse aux incidents)
* PRIS
* Un prestataire qualifié = un prestataire qui suit l'ANSSI au doigt et à l'œil
* Nivellement (par le bas) du référentiel au niveau des compétences en France. Sérieusement...
* Vu sur twitter : "Dans l'audit, on est 2 (auditeur et audité), dans la réponse à incidents, on est 3 (avec l'attaquant, qui peut être root)" #CoRIIN
* PRIS est itératif, incrémental : toujours faire des analyses post-mortel pour pas que ça se reproduise, pas juste se dire "ho j'ai un virus je le vire et basta".
* Une action judiciaire peut être engagée avant, pendant ou après donc il faut faire attention lors de l'analyse à suivre les préréquis pour que, si l'on va en justice, la demande soit recevable (conservation des preuves, journal des actions effectuées, datation, ...)
* Référenciel de détection établi avec des prestas (oui oui, ceux qui doivent être évalués via ce référentiel) et par des comanditeurs comme les OIV.
* Garantie de confidentialité des analyses par les prestas et si jamais une fuite apparaît -> moyen de poser une réclamation auprès de l'ANSII pouvant conduire au retrait de l'accréditation ANSII.
* Accréditation bullshit et sans valeur sauf si le commanditeur suit les recommandation de l'ANSII de choisir un presta qualifié, ce qui arrivera sur les marchés publics...
* Bilan : ça me semble être un label bullshit... L'ANSII préfère avoir beaucoup de prestas que des prestas réellement qualifiés. Garantir la confidentialité des audits par retrait du label... Sérieusement, quoi. L'ennui c'est que l'accréditation a un coût qu'il faudra reporter sur le client. Elle sera requise d'abord pour les marchés publics, ce qui aura une influence sur le reste du marché...
CERTitude : ou comment simplifier les campagnes de recherche d’IOC, Vincent Nguyen et Jean Marsault (CERT-Solucom) :
C'est un soft qui se connecte à des postes compromis pour remonter les IOC (Indicator of compromise) en laissant le moins de traces possibles. Je ne comprends pas : rien que l'ouverture des connexions laisse des traces. Avantage : un tool python + une remontée via le réseau ira plus vite que la lib winwin de base. :D
D&D de malwares avec des C&C exotiques, Paul Rascagnères et Eric Leblond :
* Fun fact : un botnet dont les zombies reçoivent les ordres du C&C via une boîte mail yahoo \o/
* Exfiltration de données via des requêtes DNS
* Fun fact #2 : "ils font 3 XOR, bon ok, ça revient au même que 1 XOR mais ils devaient pas le savoir [...] rigolez pas, j'ai déjà vu des attaquants faire du double riot13"
* Les IDS c'est bien mais il faut les mettre au bon endroit : pas qu'en bordure, sinon on néglige les échanges internes
* Les "langages" des IDS sont limités. Pas de boucle, par exemple. D'où une extensibilité avec des scritps (Lua par exemple) est souhaitable
* Pas d'appliance magique. Même si leur usage ne nécessite pas 15 personnes en astreinte de nuit pour écrire les regex. #troll. :D
* Les créateurs de malwares avancés suivent ce qui se dit de leur code sur le net et s'adaptent donc les règles IDS peuvent vite être contournées si tu fais pas attention.
* Regex, ça a les mêmes limites que les anti-virus : on peut faire du proactif, voire détecter des comportements anormaux donc suspects mais ça a des limites. Si tu ne sais pas ce que tu cherches -> tu ne trouveras pas, comme d'hab.
Mimikatz et la mémoire de Windows, Benjamin Delpy :
* Bon à rappeler : les attaquants sont des bourrins, ils font des trucs qui marchent, pas des trucs compliqués.
* Fun fact : pour tricher au démineur sous winwin, il suffit d'utiliser deux fonctions de l'API winwin : create process, read process. Pas besoin de droits admins vu que c'est ton démineur. :D
* L'ennemi, c'pas forcément la NSA mais les anciens employés toujours dans le domaine car gestion du domaine sous-traitée donc travail pas fait.
* La fonctionnalité minidump (dump de la mémoire lors d'un crash) est super pratique car pas besoin d'installer un code sur le poste ciblé donc discrétion. Pas besoin de droits admin, même pour dumper le process d'un autre utilisateur : il faut "juste" faire planter le processus visé. L'API winwin permet même de demander un dump sur un processus ciblé.
* Implémentation Kerberos de winwin + minidump = combo : les dumps mémoires du process LSASS contiennent les mots de passe et les tickets Kerberos.
* Fun fact #2 : Bitlocker ne marche pas avec les disquettes :D
* Fun fact #3 : l'API winwin prévoit l'enregistrement d'une DLL qui sera appelée lorsqu'un mdp est changé.
* Le tout permet donc de récupérer des accès.
* Winwin 10 ne sera pas vulnérable à tout ce qui a été exposé.
Investigation dans le DNS, pièges et solutions, Stéphane Bortzmeyer (AFNIC) :
* But de la présentation : comment trouver une info sur un nom de domaine, pièges et limites
* Un nom de domaine a un nombre quelconque de composants. Plus spécifique à gauche, plus global à droite ("."). En voyant un nom, on ne sait pas où se trouve les cut de délégation (exemple : gouv.fr. n'est pas délégué, co.uk si) : il faut utiliser une résolution DNS pour le savoir.
* Plusieurs acteurs dont au moins le titulaire d'un nom (celui qui l'a choisi et réservé) et le registre (l'organisme qui enregistre le nom). Dans la vraie vie, on a un 3e acteur : le bureau d'enregistrement qui s'occupe de la partie business. Modèle RRR (register, registry, registrar). On peut avoir des acteurs supplémentaires : agence de création web qui a acheté le nom ou hébergeur DNS différent du bureau d'enregistrement.
* Deux sortes de registres : mince ou épais. Registre épais : la base de données contenant les informations "sociales" (nom du titulaire, adresse, mail,...) sont stockées chez le registre. Registre mince : ces informations sont stockées chez le bureau d'enregistrement. Exemples de registre mince : com. , net. Registre épais : fr.. Org était épais mais est devenu mince. C'est ça qui explique les redirections que l'on voit dans whois.
* Quels sont les inconvénients à utiliser whois de manière déportée (cloud, site web,...) ?
* Base possiblement pas à jour ;
* On n'a pas la source de l'information (son authenticité est donc à questionner) ;
* Le tiers voit ce que vous faites, ce qui pose de gros problèmes de confidentialité dans le cas d'une enquête judiciaire ;
* Risque de sécurité : des malins enregistrent des noms avec des informations (nom, adresse) avec des bouts de JS/XSS.
* Même si l'ICANN impose que les titulaires de noms communiquent des informations exactes, c'est rarement le cas et pas souvent vérifier : pour quelques euros par an, un humain ne peut pas faire de vérifications poussées.
* Tous les clients whois ne sont pas optimaux parfois même entre systèmes GNU/Linux car les options de compilation sont différentes...
* DNS : pas forcément de coincidence entre whois et DNS, c'est des acteurs différents.
* DNS et caches : attention au fast-forward (nom pour contacter le C&C change rapidement).
* nslookup sous winwin c'est naze : incomplet, pas d'horodatage, il fait des requêtes qu'on ne lui demande pas (reverse IP, serveur de nom)
* mes quqestions :
* Pourquoi BDD passives DNS pas publiques compte tenu du caractère public des infos DNS (cf RFC DNSSEC) ? Sociétés commerciales derrière donc business.
* Tu pourrais nous dire deux mots sur les looking glasses DNS ? C'est bien pour voir la censure et ce genre de choses. Stéphane utilise RIPE Atlas mais on a toujours les limites présentées au début de l'exposé : intervention d'un tier d'où problème habituel de confiance
Internet Explorer 10 et 11: un nouveau format de données pour de nouveaux défis, Jean Philippe Noat et Bruno Valentin :
* Aucune logique dans le nommage des fichiers caches d'IE : webCacheV01, V16 et V24, pas les autres ... pas de logs tournants so wtf ? l'orateur n'a pas la réponse
* Cache pas optimisé : plusieurs tables peuvent servir au même usage, semble utiliser un parcours itératif/index chelou.
* Dans la inforensic, on cherche à savoir si un téléchargement a eu lieu suite à une action de l'utilisateur ou si prefetch ou cache : le stockage de cette info par IE est prévue.
* Ces fichiers d'index du cache sont "sales", pas mis à jour, résiste mal à un arrêt brutal de la machine (ce qui arrive lors de perquisitions) donc beaucoup d'infos manquent à l'appel.
* Fun fact : les applis sur FB et co échappent au cache IE au sens premier. :D
* Fun fact #2 : le cache IE tourne toujours en navigation privée ;)
* Fun fact #3 : l'épinglage/dé-épinglage d'une app est stocké dans une base de données sqlite. Dé-éplinger une app ne fait pas disparaitre les infos dans la base mais un re-épinglage fait disparaître les infos précédentes
FastResponder: Nouvel outil open source pour détecter et comprendre des compromissions de grande ampleur, Sébastien Larinier (CERT Sekoia) :
* Lors d'une compromission, il faut faire une collecte rapide du SI et analyser les infos collectées rapidemment pour agir vite et répondre vite à l'incident de sécurité.
* Analyse à la mano / à la papa : chiant, coûteux et lent. Genre on trouve encore des analyses forensic faites sous Excel.
* Il faut utiliser du matos simple à déployer et des outils de data-visualisation comme Kibana.
* L'intérêt du live forensic (exemple : analyse RAM in-situ) se justifie avec l'augmentation de la quantité de RAM dans les serveurs (64G+ ce n'est plus rare). Je ne suis pas convaincu puisque Zythom, sur son blog, nous parle de dump de disques dur de plusieurs tera, même pendant une perquisition...
(Permalink)