Playing with the last layer before bare metal ; Grub2

July 2nd, 2008

I screwed up my machine and spent almost two days trying to repair it…

Context

My machine’s hard drive is fully encrypted. This volume is then the PV of an LVM with one VG and several LVs. As the whole hard drive is encrypted, the /boot partition is on a usbkey. So the idea is that Grub is installed on the hard drive (/dev/sda/) MBR, boot with the /boot on a usbkey, then open the crypto container and then activate the LVM and finally mount all the partitions.

My machine is using Sid and therefore Grub2. And this configuration was fully achieve just by using Debian Installer.

Problem

The first thing I tried was to remove the usbkey without unmounting /boot. The system was fully functional but it was then impossible to regain access to /boot.

Then one day, I rebooted… (actually, this was an error ;))

Solution

After the reboot, I was welcomed with Grub message « Welcome to Grub! » (in rescue mode).

So first, I rebooted on my usbkey (not the one with the /boot partition) which has a Debian installed (see FIXME for details about this usbkey). The idea was to

  1. boot,
  2. open the crypto-container,
  3. activate the LVM,
  4. mout all partitions (including /boot on the other usbkey),
  5. chroot
  6. and re-generate an initramfs.

Except that this system is i386 and my machine is amd64 ; no way to chroot…

So, Corsac generated an amd64 LiveDebian cd.

This time, I was able to follow the plan (see § chroot operation below for details). And I rebooted… to get the same message from Grub.

At that stage, we worked together with Corsac (I still did not find a better solution than working with a friend to solve problems ! It’s good to keep moral up, exchange ideas, get help… ;))

So, now we had to play with Grub

The first thing to know is that Grub2 does not work like Grub.

root, kernel and initrd are variables to set. And Grub2 has lots of modules that must be loaded before being able to actually do something. Making long story short, the prefix variable was set to (fd1,0)/grub/. Which is totally wrong as I do not even have a floppy drive…

So first, all variables ware unset.

unset prefix
unset root

Then the right ones were set.

set root=(hd1,1)
set prefix=(hd1,1)/grub/

Then the normal.mod module was loaded and the normal mode launched.

insmod /grub/normal.mod
normal

At that stage, the Grub menu was launched and my machine booted normally.

What we tried within Grub2 « shell »

But we tried lots of things before finding this. Before finding those two culprits we

  • loaded manually ls.mod, _linux.mod and then linux.mod modules and set linux variable to the right value
insmod /grub.ls.mod
insmod /grub/_linux.mod
insmod linux.mod
set linux=/boot/vmlinuz-2.6.24-1-amd64 root=/dev/mapper/sda1_crypt
  • then initrd.mod module and set initrd variable to the right value
insmod /grub/initrd.mod
set initrd=/boot/initrd.img-2.6.24
  • finaly booting
insmod /grub/boot.mod
boot

chroot operation

During the chroot operation, the following steps were done.

Open the cryptocontainer (the name of the unencrypted logical volume must be the one from the system to be rescued. Indeed, it will be exported to the chrooted system and be used when generating the initramfs. If it is not the same unencrypted LV as the system to be rescued, when booting the initramfs won’t have the name actually used by the system ; it will fail)

# cryptsetup luksOpen /dev/sda5 sda5_crypted

Activate the LVM using the (now unencrypted) encrypted partition

# lvm vgchange -a y

Mount the root LV somewhere to chroot within

# mount /dev/mapper/vg_main-slash /mnt/toberescued

Mount /dev within the chroot so that other LVs are available

# mount --bind /dev /mnt/toberescued/dev

Actually chroot

# chroot /mnt/toberescued

Mount the other partitions (the chrooted system /etc/fstab is available)

<toberescued># mount /proc
<toberescued># mount /sys
<toberescued># mount /home
<toberescued># mount /var
<toberescued># mount /usr
<toberescued># mount /tmp
<toberescued># mount /var/log
<toberescued># mount /boot

Regenerate the initramfs

<toberescued># update-initramfs -u -t

Re-install Grub

<toberescued># grub-install --recheck /dev/sda

Unmount everything and exit the chrooted system.

sstic 2008 - compte-rendu

June 19th, 2008

Ces notes sont la retranscription de mes notes prises lors des conférences, complétées de celles de mes camarades Yves-Alexis et Delphine.

Elles ne sont qu’une vue (parfois très) partielle des présentations. Reportez-vous aux présentations mises à disposition par le SSTIC. Ces présentations ne sont elles-mêmes qu’une synthèse sans les aspects les plus gore des papiers publiés dans les actes.

Les parties Avis / commentaire n’engagent que moi.

Enfin, toute erreur dans ces notes est mienne.

Sinon, vous pouvez aussi consulter http://sid.rstack.org/blog/index.php/279-le-sstic-2008-en-live qui est un compte-rendu live des conférences.

Et pour finir, les actes prennent le temps d’expliquer plein de choses qui sont jugées connues lors des conférences. Les actes comme les présentations sont disponibles là : http://actes.sstic.org/sstic08/.

1. Sécurité, anatomie d’un désastre annoncé

par Marcus Ranum / CSO Tenable Network Security, Inc.

1.1. Notes

“La sécurité n’est pas prise en compte”…

Le logiciel est désormais plus complexe qu’un système tel que la navette spatiale. “C’est un miracle que ça marche un peu”.

D’un autre côté, l’informatique n’a pas (encore) provoqué de morts ; seulement des millions de dollars de perte.

La position générale est qu’”il n’y a pas de problème puisque ça marche”. Mais la question n’est pas de savoir si il va y avoir une catastrophe, mais quand.

Le cheminement habituel est :

  1. Une mauvaise idée est proposée
  2. Des warnings sont levés pour stopper cette idée
  3. L’idée survit à ces warnings
  4. On procède à des ajustements pour s’accommoder des warnings levés. En fait ces accommodements rendent l’idée moins manifestement dangereuse et surtout compliquent la solution. L’idée est toujours mauvaise et une catastrophe aura lieu.
  5. L’écart entre les objectifs et la réalité augmente. L’écart est de l’ordre du gouffre.
  6. La catastrophe se produit
  7. On cherche les responsables et on retrouve les mémos
  8. Massacre des innocents
  9. On n’apprend pas de l’expérience
  10. Et on recommence

Une fois qu’il y a eu beaucoup d’investissements sur une idée, même mauvaise, elle ne sera plus stoppée. L’inertie intellectuelle et financière est quasi-infinie.

Les décideurs n’assumeront pas, malgré les discours.

Une solution possible est que les équipes de sécurité puissent avoir accès au numéro 1 directement. Dès lors, on évite la création artificielle d’un gouffre entre réalité et perception.

Souligne la perversité des statistiques utilisées pour dire n’importe quoi.

Les organisations n’apprennent quasiment jamais de leurs catastrophes…

1.2. Avis / commentaire

La position de Ranum est clairement le fruit de (très) nombreuses années d’expérience, et son constat est assez désabusé.

Ranum complète beaucoup son analyse à l’aide de l’analyse de Feyman sur la catastrophe de la navette Columbia. Ce qui a le mérite d’éclairer la problématique de la sécurité plus largement. Ce n’est pas (qu’)une problématique informatique. C’est une problématique générale entre les gens qui comprennent les technologies utilisées et le management.

Néanmoins, il faut bien “faire des choses” et donc prendre des décisions. De mon point de vue, tant que les décisions intègrent l’état de l’art au moment où elle est prise, il est difficile de faire des reproches a posteriori. Même, si à terme, cette décision s’avère mauvaise.

2. Identification et exploitation des failles humaines par les prédateurs

informationels : un risque sous-estimé par les entreprises ?

par Michel Iwochewitsch

2.1. Notes

Prédateurs

  • one shot : social engineer, escroc, journaliste
  • long terme : établissement longue dans l’entreprise. Discret et bien formé. Peut viser tout le monde. Renseignement, activiste, criminalité organisée.

Valeurs de l’information

  • pécuniaire : connaître une information avant, même quelques heures
  • intégrité :
  • confidentialité : en fusion/acquisition par exemple
  • disponibilité : non accès au système Sabre pour tout l’aéroport de Londres
  • nuisance : temps passé à reconstituer l’information (vol de laptop)
  • pour l’opposition

Vulnérabilité

L’exploitation de vulnérabilité n’a rien d’un art depuis le développement des sciences cognitives. Pour les russes, le cerveau humain est un système sans firewall.

  1. exploitation de la personne
  2. capacité décisionnelle
  3. besoins sociaux : reprogrammation d’un fax pour copie systématique (4/10)
  4. loi d’influence, manipulation, psychologie sociale
  5. heuristiques et biais cognitif

Disposer des outils pour mieux appréhender la cible.

Failles

  1. la personnalité
  2. la perception et la capacité de réflexion : elle influent sur les décisions et les heuristiques
  3. l’environnement social : universel

Heuristique (modèle mental appliqué dans des situations de danger ou même quotidienne permettant des décisions rapides en environnement incertain)

  • de disponibilité : estimation d’une fréquence en fonction de la facilité des exemples qui nous viennent à l’esprit. Ex: un attaquant veut avoir des numéros. Il appelle d’abord la standardise et demande des petites choses sans importance, et ce régulièrement. Puis pour la standardiste c’est normal qu’il appelle et elle lui donne les numéros. Mémoire de ce qui s’est déjà passé.
  • de représentativité : comparaison cas particulier et cas général. Ex: un médecin comparant nos symptômes à des listes de combinaisons.
  • d’ancrage : estimation de valeurs. On rapproche des valeurs incertaines de valeurs déjà connues. Ex: nombre de pays dans l’OTAN → environ 30. En appel, l’attaquant devient sympathique, il pose des questions, habitude de l’avoir en ligne. Ex: chat sur internet, on connaît les individus sans les avoir rencontrés.
  • d’émotions (primaires et secondaires) : raccourcis heuristiques fondamentaux. Simple à provoquer et facile à exploiter. Une amorce de base est de demander de l’aide. Échanger des émotions avec son interlocuteur. Ex: un attaquant appelle est dit que son patron a absolument besoin d’une information sinon il va se faire lyncher. Mais pour cela il doit se connecter au réseau. Influence la prise de décision par la pitié.

Biais cognitif

  • effet de primauté : ce biais est lié à l’archi-cortex. On retient mieux la première information que celles qui suivent (”oui mais…”)
  • effet de Halo : on applique à l’ensemble d’un raisonnement un premier jugement (positif ou négatif) non lié. La 1ère chose qu’on fait, va déterminer le reste de la journée. Ex: un escroc va faire se sentir mal un employé dans son entreprise et lui présenter une porte de sortie
  • connaissance rétrospective : auto-manipulation de la mémoire. Se ré-approprier des choses du passé alors qu’on ne les a pas vécues
  • complaisance égocentrique : on s’approprie la réussite et on refuse l’échec. Ex: Lors d’un match, si la France gagne, les supporters s’exclament “On a gagné!”, lorsque la France perd : “Ils ont perdu!”

De manière générale, une perception se forme facilement et est difficile à changer.

La personnalité et son exploitation

  • comportement passé
  • prise de décision
  • bain culturel
  • heuristiques et biais cognitif
  • émotions
  • personnalité

Définition des humains (publicité et politique le font)

On utilise plusieurs outils

  • big five factors : en moins d’une heure et par téléphone il est possible d’avoir le profil de quelqu’un. (utilisé par les psy, étoile a 5 branches (schéma))
  • système de défense de l’Ego
  • besoins sociaux de base

L’EDS objectif bloquer le processus de décision. Augmenter le stress de décisions.

Les boutons universels

  • besoins de reconnaissance
  • tendance naturelle à l’effacement
  • tendance naturelle à corriger les autres
  • tendance naturelle à vouloir que l’autre se trompe (l’ego)
  • absence d’oreilles dans ce monde …

Manipulation des sources

  • MICE
  • ASIE
  • SANSOUCIS

Prédateur “one shot”

  • social engineer : peu formé, peu de méthodologie
  • con artist : très bien formé exploite bien les failles simples
  • opérateur IE

Il choisit le maillon le plus fragile, et agit rapidement et agressivement.

Élicitation : action d’obtenir une information sans l’avoir explicitement demandée.

2.2. Avis / commentaire

Une grosse reprise de son article dans le Misc.

J’ai trouvé les slides plus intéressantes car moins méthodologiques et plus proches des outils psy / neuro-science. [les slides sont maintenant disponibles].

Grosso-modo, le cerveau humain est facilement manipulable dès que placé en situation de stress ou flatté. Les taux de réussite sont significatifs.

3. Contactless smartcard activation without cardholder agreement

par Carine Boursier, Pierre Girard, Christophe Mourtel / Menalto

3.1. Notes

Présentation des cartes à puce (avec un micro-processeur) et non des RFID.

Constituants :

  • antenne
  • chip : micro-processeur
  • portée : de 0 à 10 cm
  • champs magnétique : 14 - 19 MHz
  • pas de batterie

La carte et l’émetteur modulent le champs magnétique pour communiquer (en half-duplex).

Norme ISO1443.

La carte à 250 ms maximum pour tout faire (y compris la sécurité donc).

La bande passante est de 106 kb.s-1.

L’UID de la carte fait de 4 à 10 octets. C’est cet UID que l’on peut tracer.

Deux catégories de risques :

  • passif : pas d’action sur le système. Pas de modification de données possible. Soft attack (bug) et side channel analysis (on capte le signal, on enregistre et l’on en déduit ce que fait la carte)
  • actif : fault attack (perturbation physique), invasive attack (modification du circuit imprimé)

Les risques :

  • listen and eavesdrop data exchanged between the reader and the smart card during the transaction
  • tracking : the same during the samrtcard activation. On e-passport there is a mandatory random value for the UID…
  • active scanning : unauthorized reader
  • relay attack : ability to propagate an information over the physical limitation distance

Les attaques

  • RFID de TI
  • augmentation de la distance de lecture jusqu’à 50 cm
  • Mifare (puce Philips représentant environ 90 % du marché) cracking. Un algorithme propriétaire a été reversé et craqué.

Solutions :

  • carte dans une cage de Faraday (le papier aluminium est effectif)
  • action par l’utilisateur signifiant son accord (push-button)
  • authentification du lecteur et secure channel (vraies solutions à long terme)

Évocation des téléphones NFC (near field communication) qui vont être émetteur et carte… Il existe déjà une attaque publiée…

3.2. Avis / commentaire

Présentation claire de l’état de l’art.

Diminue les fantasmes mais montre aussi que des “attaques” ne sont pas difficiles à monter. Semble montrer que la solution e-passport est relativement robuste.

Le problème fondamental est d’avoir un moyen de solliciter l’accord explicite de l’utilisateur. Quid d’une box se souvenir de ma décision à la FF pour les cookies. Ainsi l’utilisateur pourrait choisir.

4. Expertise judiciaire des téléphones mobiles

par David Naccache

4.1. Notes

Statistiques (attention de 2004)

  • Motorola Nokia Siemens + Samsung = 70 % marché
  • types
    • basiques = 22 %
    • améliorés = 72 %
    • intelligents = 5 %
    • pda = 1 %
  • ~ 1 500 modèles

Trois types de données

  • utilisateur : répertoire, appels, marqueur WAP. Pré-requis : code PIN. Les fabriquants fournissent des outils pour gérer ces données (i.e. pas les analyser). Leurs utilisations modifient l’état du téléphone.
  • opérateur : IMSI, paramètres SMS, géo-localisation (dernière balise accrochée)
  • mobile : IMEI (tracé dans l’envoi de SMS…) et paramétrage

Deux problèmes :

  • PIN : papier officiel du juge le demandant à l’utilisateur (art. 164 CPC). Sinon pour récupérer un PIN/PUK on peut :
    • se baser sur les papiers d’ouverture de la ligne (perquisition)
    • demander à l’opérateur
    • demander au fabriquant de carte
    • craquer la carte
  • analyser sans modifier l’état du téléphone

Techniques d’extraction

  • téléphone cassé = extraction de la flash
  • piratage légal (extraction du PIN)
    • ver légal
    • attaque par faute
    • attaque par consommation de courant
    • cheval de Troie sur portable (expérimental)
  • injection de faute
    • objectif = extraction de PIN, données, etc.
    • outils = lecteur de précision, oscilloscope, traitement du signal, microscope, laser (écrasement du PIN), logiciels spécifiques…
    • deux étapes :
      1. identifier où et quand injecter la faute
      2. analyser les données fausses obtenues
  • cheval de Troie
    • code hostile dans une applet attractive/innocente et/ou “faussement” certifiée (comme un jeu)
    • se déclenche sur sms reçu
    • demande le code PIN (“error SIM…”)
    • stocke le PIN, puis l’envoie

Un outil : GemXplore CASE lite

Passage à la présentation et démonstration qu’une machine peut toujours communiquer quoique l’on fasse. Basé sur un exemple “rigolo” : c’est le ventilateur qui communique en jouant sur l’échauffement des composants et un “thermo-bug” récupère l’information. L’autre exemple est le passage d’information entre deux zones isolées par des “pont-levis” (“norme” NSA) sur un FPGA. Tout est fait numériquement…

4.2. Avis / commentaire

Une bonne introduction / présentation du contexte.

Un long point sur l’utilisation d’applet malicieuses. Qui pose toujours la même question : qui signe quoi pour qui ?

Je n’ai toujours pas compris la digression sur la communication par canal caché mais c’était rigolo et très impressionnant.

5. Outils d’intrusion automatisée : risques et protections

par Mathieu Blanc /

5.1. Notes

Outils :

  • Matasploit
  • CoreImpact
  • Canvas

Tous intègrent :

  • une base d’exploits
  • des vulnérabilités distantes, locales et “client side”
  • une exécution des exploits fiabilisée
  • la possibilité d’intégrer des zero days (payant)

Ces outils passent par les étapes suivantes :

  • découverte des systèmes
  • identification des versions des systèmes
  • tentative d’exploitation des vulnérabilités trouvées
  • déploiement d’agents sur les machines compromises
  • élévation des privilèges éventuellement

Risques :

  • erreurs de manipulation
  • une utilisation d’un exploit peut déclencher un DoS

→ il faut connaître les détails des exploits et ses conséquences

Ils ciblent surtout et avant tout Windows.

Pas de furtivité : ces outils sont bruyants et les communications ne sont pas chiffrées

Il y a deux étapes :

  1. la découverte et l’exploitation d’une faille pour installer un agent
  2. la mise en place du-dit agent et son utilisation.

Il est proposé d’utiliser des signatures de ces agents puisque cela indique 1/ que l’attaque a réussie et 2/ que l’outil utilisé est connu.

Cette signature est basée soit :

  • sur les traces réseaux de l’envoi de l’agent. Ces signatures sont intégrables à Snort, ce qui permet d’être pro-actif (à condition d’être rapide ;) ;
  • sur les appels systèmes de l’agent et leur séquence. La solution est nettement plus lourde.

Dans les deux cas, elle est indépendante de la vulnérabilité utilisée en phase 1/.

En conditions réelles, il n’y a jamais eu de faux-positif sur un mois et demi d’analyse.

FIXME- syscall proxying

En contre-mesures, l’habituel :

  • la mise à jour des systèmes…
  • bloquage avec un IDS à partir des signatures détectées ou re-routage dans un environnement confiné
  • contre-attaque de l’outil utilisé (eux aussi ont des failles et la machine qui fait tourner l’outil est en général en petite culotte)

5.2. Avis / commentaire

Présentation intéressante de ces outils.

J’en retiens qu’un bon audit requiert une bonne utilisation de ces outils “automatiques” qui exige toujours une (très) bonne compétence générale et surtout l’utilisation d’outils maison. Ouf ! ;)

6. Bogues ou piégeages des processeurs : quelle conséquence sur la sécurité ?

par Loïc Duflot / DCSSI

6.1. Notes

Toute la présentation s’appuie sur la réalisation de l’hypothèse suivante : une machine boguée ou piégée, c’est la même chose.

Est aussi rappelé que les bogues CPU ont tendance à s’empiler d’une génération à une autre et qu’un CPU lorsqu’il bogue a un comportement complètement aléatoire.

Petits rappels sur l’architecture x86 :

  • les privilèges vont du ring0 au ring3
  • deux niveaux de traduction dans le CPU :
    • la segmentation : traduit les adresses physiques en adresses virtuelles utilisées par les programmes. Elle permet le contrôle d’accès en désignant des modes sur des blocs (adresse de base + taille)
    • la pagination : présente l’adressage mémoire pour chaque processus et gère derrière (mémoire principale vs. swap). Des droits sont aussi gérables sur les pages.

Objectif du bogue/piège :

  • exploitable avec le minimum de droits
  • donner accès au ring0
  • fonctionne quelque soient les couches supérieures
  • discret

Il est alors démontré en partant de l’hypothèse d’un bogue sur l’instruction “salc”, qu’en positionnant des registres à une valeur particulière, le champs CPL du processeur est passé à zéro (soit un passage en ring0 pour la tâche courante).

Les démonstrations sont faites avec un QEMU modifié afin d’émuler un bogue.

Démonstration que cela peut même fonctionner sur des machines virtuelles…

Contre-mesures pour réduire (i.e. pas supprimer) le risque :

  • réduire la surface d’attaque
  • pas d’outils de compilation ou d’exécution de code (macro)
  • respect des bonnes pratiques de sécurité (accès réseaux…)

6.2. Avis / commentaire

De manière générale, présentation nettement trop bas niveau pour mes compétences. Ce qui me laisse perplexe, c’est comment on se débrouille pour planquer du code déclenchant le piège dans une application… Je sais, ce n’est pas le plus dur, mais n’empêche.

C’est flippant. Et pour ceux qui se posent encore la question, ni SELinux, ni TPM ne sont des barrières.

Une autre contre-mesure : disposer de ses propres fondeurs… Au moins, il n’y a pas de bogue volontaire ;)

7. Autopsie et observation in vivo d’un banker

par Frédéric Charpentier et Yannick Hamon

7.1. Notes

Présentation du virus anserin, spécialisé dans le vol d’information bancaire.

Ce virus s’accroche à IE.

Deux types de serveur dans l’architecture :

  1. collector :
    • mise à jour
    • collecte des identifiants
    • sécurisation des flux entre les agents et le back-office (URL chiffré, blacklistage d’agent “méchant”)
  2. injector :
    • fonctionnalité optionnelle
    • distribution de formulaires malicieux avec injections simples et évoluées (cartes multi-entrées, clavier virtuel, etc.)

Le processus est le suivant :

  1. l’utilisateur accède à sabank.com
  2. anserin demande à son injector s’il connaît cette banque
  3. injector répond oui et envoie le formulaire malicieux qui va bien
  4. anserin récupère les données saisies et les envoie sur son collector à un moment ou à un autre

Les communications sont chiffrées (inversées, hexadécimalisées, XORées avec l’ID de l’agent).

Les formulaires (pour 500 et des brouettes banques) sont mis à jour quasi quotidiennement et proprement localisés.

Ce virus est extrêmement résilient au chambardement de l’architecture (coupure des serveurs) : par un mécanisme de FQDN pseudo-aléatoire il saura retrouver un serveur avec un peu de temps. L’architecture est aussi capable d’utiliser des fast-flux DNS. Tout cela est hébergé chez des providers bullet-proof (i.e. ne coupant pas les services même quand la police leur demande) et l’hébergeur change toutes les semaines. Basé sur la documentation de ces hébergeurs, le coût de fonctionnement mensuel est estimé à 1 000 USD par mois. anserin a commencé en étant hébergé sur le RBN, et utilise des registrar au Panama et Nassau, ce dernier semblant être le pivot. Il est très lié au “secure hosting” et affiche fièrement un blason “hacker free” de FIXME.

La conclusion est la suivante :

  • la course aux signatures anti-virus est perdue
  • Firefox est aussi concerné (une rump précisera même que Firefox dispose de fonctionnalités (sans hack) au moins aussi dangereuses que celles d’IE…)
  • l’authentification double canal devient impératif (SMS, OTP, etc.)
  • l’authentification deux-tiers pour les paiements par CB (3DSecure, SecureCode, etc.)
  • quid du filtrage par les FAI des serveurs C&C ?

7.2. Avis / commentaire

Présentation extrêmement visuelle et accessible.

Après ça, on peut se demander pourquoi les banques ne font pas systématiquement de l’authentification forte / double canal…

Cette présentation illustre bien un sentiment de fond de “professionalisation” (j’ai horreur de ce terme ; il est employé au sens de “pour faire de l’argent”) des méchants.

Le dernier point de la conclusion laisse un goût amer…

8. GenDbg : un débogueur générique

par Jean-Marie Fraygefond et Didier Eymery / Cellar

8.1. Notes

Présentation d’un débogueur multi-plateforme, multi-architecture et multi-OS.

Le but étant de disposer du meilleur de ce qui existe pour chaque point : IHM, scripting, etc.

Les fonctionnalités :

  • IHM en mode texte pour l’efficacité
  • moteur de script “maison” pour rester cohérent avec leurs applications
  • architecture client/serveur

L’architecture est minimaliste. Elle est essentiellement composée de :

  • framework : permet de communiquer entre les différents modules
  • stub : code exécuté sur la machine cible. Il implémente les primitive et est chargé des interruptions/exceptions de la machine cible.
  • module ASM : assembleur/désassembleur lié à l’architecture.
  • modules optionnels :
    • modules de commande liés à l’architecture (IA-32, etc.)
    • modules d’OS helper (propre à l’OS cible)
    • module de symboles
    • module BT (breakpoint extenders lié à l’architecture cible)

GenDbg permet de mettre plusieurs stub sur une même application. Ce qui est très pratique pour les applications sur VM.

8.2. Avis / commentaire

Encore très bas niveau.

Y’a des gens comme les opérateurs dans Matrix ; ils lisent l’assembleur en direct-live… Pas moi ;)

9. Sécurisation, état de l’art et nouveaux enjeux des green data center

par Christophe Weiss / APL France

9.1. Notes

Présentation des mesures de protection des data centers (DC) : sécurité physique, disponibilité, supervision, etc.

Un DC est un bâtiment sûr et sécurisé avec personne.

Périmètre :

  • terrain et environnement
  • coque (on laisse les générateurs à l’air libre ?)
  • architecture intérieure adaptée à l’exploitation
  • des installations lourdes et complexes (courants forts…)
  • supervision en temps réel

Avant 2004 : 500 W.m-2 maximum. Redondance n+1

À partir de 2004 : les serveurs 2U et autres pizza-box arrivent. 500 à 800 W.m-2

À partir de 2005 : arrivée des blades. 700 à 1 000 W.m-2 . Passage à une redondance 2n ou 2(n+1). Introduction de charges capacitives.

2006 - 2007 : généralisation des charges capacitives. Généralisation des blades. On passe à plus de 1 000 W.m-2. Classification des DC par tiers (4).

2008 : jusqu’à 12 à 15 kW par baie haute densité.

Les questions sont :

  • refroidir le matériel
  • état capacitaire et marge d’évolution réelle
  • quid du tiers IV
  • solution d’extinction en cas d’incendie
  • optimisation énergétique

Sustainability : aspects liés à la bonne gestion du site

Marier l’efficience énergétique et la continuité de service (raison d’être des DC) est très délicat, ces deux objectifs étant antinomiques.

La climatisation d’un site représente 63 % de la consommation électrique d’un DC (33 % pour l’équipement IT).

Ration PUE (power unit efficiency) = consommation globale du site sur un an (lissage de l’effet saison) / consommation des équipement IT (sans prise en compte de la charge CPU)

Les PUE sont aux environs de 2,5. La cible est de 1,8 voire 1,6.

Ordre de grandeur du coût de l’électricité (en France où elle est très peu chère) d’un DC de 2 000 m2, à 1 kW.m-2 avec un PUE de 2,3 : 1,3 M€ par an.

La recherche de la redondance exige une multiplication des équipements, donc une augmentation de la consommation et de pertes à faible charge.

La classification par tiers est faite par l’uptime institute.

L’idéal est le tiers IV où tout est doublé, y compris l’alimentation secourue. Ce qui exige plus de surface générale pour moins de surface utile. Un DC appartenant à cette catégorie souffrira d’une interruption de 0,8 heure par an, soit un arrêt tous les quatre ans.

Les valeurs des dissipations des constructeurs sont fausses : il faut les diviser par deux.

Listage des besoins et contraintes ÷

  • surface
  • puissance
  • niveau de service / continuité
  • évolutions envisageables
  • modalités d’exploitation futures

80 % des DC vont devoir être restructurés dans les cinq ans à venir. Vaut-il mieux restructurer ou reconstruire ?

Les réserves de fioul sont pour une durée de 3 à 5 jours. C’est une denrée périssable, à renouveler donc.

A priori, seule l’armée a été intéressée par des DC faradaysés, à sa connaissance.

9.2. Avis / commentaire

Une présentation un peu plus éloignée du CPU (encore que…).

De mon point de vue, un super état de l’art avec des ratios remis à jour (par rapport à ce que l’on trouve dans la littérature). Clairement, le monsieur semble savoir de quoi il parle.

10. Déprotection semi-automatique de binaire

par Alexandre Gazet et Yoann Guillot

10.1. Notes

On repart dans du bas niveau.

Rappels sur l’outil Metasm et en particulier les fonctionnalités de backtracing (fonction limitée dans IDA).

En fait, toute la présentation repose sur deux exemples tirés de challenges de sécurité.

Avant de présenter leurs exemples, ils présentent ce qui est la base de leur raisonnement / façon de faire. Trouver la sémantique de tout morceau de code et donc pouvoir le factoriser au maximum.

Ils présentent ensuite tout un tas de techniques d’obfuscation (insertion d’éléments neutres, expansion de constantes, obfuscation structurelle et complexification à l’envie).

Le premier exemple (pouet.exe) leur permet de présenter les fonctionnalités de détection de sauts conditionnels biaisés ainsi que le nettoyage/factorisation du code, enfin du graphique présentant le code. On passe d’un truc impossible à un code exploitable ; il est réduit de près de 80 %.

Le second exemple présente les capacités de nettoyage de junk code inséré par un packer pour rendre illisible/inexploitable le code. Y compris lorsque le-dit code utilise une machine virtuelle (interpréteur)…

10.2. Avis / commentaire

Présentation très claire. Limite j’avais l’impression de pouvoir me lancer dans un débogage pour le prochain challenge sécurité…

Ah, aussi, y’a vraiment des gens vicieux et pas bien dans leur tête quand on voit l’obfuscation qui peut être faite…

11. ERESI : une plate-forme d’analyse binaire au niveau noyau

par Anthony Desnos et Sébastien Roy

11.1. Notes

Ne prenez pas l’ascenseur, on reste en bas…

Il s’agit d’un ensemble d’outils dédiés au reverse du noyau. Il assemble de quoi faire du débogage statique et dynamique, ainsi que du scripting. Le tout utilisant un langage propre et commun à toutes les fonctionnalités offertes.

ERESI se compose de :

  • logiciels scriptables
  • librairies+API

ERESI supporte :

  • les architectures : IA-32, Sparc, Mips
  • les plateformes : Linux, BSD, Solaris

Il ont ressuscité Kernsh pour l’occasion et l’intégrer (aussi). Et puis comme Kernsh il s’exécute en contexte utilisateur, ils ont écrit Ke2dbg qui lui tourne entièrement en contexte kernel (ça va plus vite, mais c’est potentiellement plus instable et puis ça peut modifier l’état du chat…).

Pour imager tout ça, ils présentent le tout dans le contexte d’un rootkit (injection de code, détournement de fonctions kernel non-exportées, etc.).

Les fonctionnalités sont entre autres :

  • lecture/écriture dans la mémoire kernel (utilisation de get_raw, surcharge des fonctions de libkernsh)
  • possibilité d’allouer/libérer de la mémoire (kmalloc et/ou syscall existant)
  • injection de code
  • redirection de fonctions (jump)

Les inconvénients :

  • le changement de contexte induit des problèmes de performance et de fiabilité des informations obtenues
  • bogues

11.2. Avis / commentaire

Impressionnant mais pas utile tous les jours pour moi ;)

12. Cryptographie : attaques tous azimuts

par Jean-Baptiste Bédrune / ESAT

12.1. Notes

Le but est de présenter comment craquer du chiffrement sans avoir recours à la cryptanalyse lourde.

Présentation de deux cas :

  • application web / client lourd Java : les clefs (privées) étaient dans des fichiers…
  • MacOSX : mot de passe en clair (dans le swap, puis après un fix, dans la RAM)

L’idée est qu’il y a beaucoup de fonctions cryptographiques un peu partout. Le but est alors de retrouver les primitives puis d’analyser leur utilisation et enchaînements afin d’isoler une faiblesse.

Les primitives sont retrouvées à l’aide de patterns tels que les constantes utilisées (fonction de hash) :

  1. analyse statique : identification des primitives
  2. analyse dynamique : appel à quelle primitive identifiée en 1/ et où.

12.2. Avis / commentaire

Bref, pas besoin de disposer d’un centre de calcul en peta flops pour s’attaquer à la cryptographie. Néanmoins, une connaissance avancée des principales fonctions cryptographiques est requise.

13. Sécurité dans les réseaux de capteurs

par Jean-Claude Castellucia / INRIA

13.1. Notes

Capteurs : ensemble de nœuds déployés plus ou moins aléatoirement. Chaque nœud est un capteur et un routeur.

Architecture en arbre : les capteurs sont les feuilles et la station de base la racine

Applications :

  • militaire
  • surveillance de l’environnement
  • structure de bâtiment
  • conditions routières
  • médicale

Problème difficile :

  • capacités très restreintes (cpu et mémoire en quantité limitée)
  • énergie très limitée et lorsqu’elle est épuisée, le nœud est out (énergie = 2 × 1,5 V). Utilisation de protocoles très économes
  • nœud facilement accessible
  • protection physique difficile
  • contrainte de prix

Sécurité

  • passif : écoute de ce qui se passe. Mise en place de capteurs dans le même environnement
  • actif : re-routage des capteurs.

→ Bambi contre Godzilla.

Résolution

Problématiques diverses selon les usages ÷

  • intégrité confidentialité des données
  • protocole d’échange de clefs efficaces : comment échanger des clefs entre capteurs sans utilisation d’un protocole à clefs publiques (trop coûteux)
  • sécurité du routage (attaquant peut entrer dans le réseau car réseau ad-hoc)
  • sécurité de localisation du nœud
  • agrégation sécurisée

Deux illustrations

  • application médicale avec le pacemaker
    • 1 ou 2 nœuds non accessible car dans le patient
  • application militaire : surveillance

13.1.1. Médicale

Interface sans fil. Le médecin configure l’implant à distance. Stockage d’informations dans l’implant. Récupération des mesures par le médecin. Surveillance, monitoring du patient et réaction en temps réel.

Implant cardiaque (défibrillateur et pacemaker)

Stimulateur cardiaque : stimuli électriques faible périodiquement Défibrillateur : émet des stimuli quand le cœur ne va plus, et hop un stimulus plus fort pour permettre au cœur de reprendre un rythme normal.

Systèmes actuels

  • ultra low power cpu + 128ko de RAM
  • communication par induction (donc proche)
  • bande passante limitée

Nouveaux systèmes

  • fréquence radio portée de 2 à 3 m. Surveillance à distance, facilité de programmation et d’installation
  • bande passante plus importante (400 bits.s-1)

Aspect sécurité

Les systèmes actuels n’ont aucune sécurité : pas de mécanisme de contrôle d’accès, pas de confidentialité des données. Un attaquant peut facilement lire les données mesurées et stockées, lire les données personnelles du patient et du médecin, modifier les paramètres et désactiver l’implant.

Pourquoi ce manque de sécurité ?

  • les fabricants jugent cela inutile. Il faut être proche du patient. Mais un attaquant peut utiliser un équipement non standard et donc accéder à une distance plus importante aux données (cf. conférence Gemalto)
  • coûteux en terme de ressources (cpu, bande passante, énergie)

→ compromis sécurité/sûreté : la sécurité ne doit pas mettre en danger le patient en cas d’urgence. Pas d’accès aux données par les attaquants mais dans ce cas les données sont aussi inaccessibles aux médecins en cas d’urgence ? Un attaquant ne doit pas désactiver l’appareil mais un urgentiste doit pouvoir le faire…

Il faut pouvoir authentifier le lecteur : gestion de clés (données au médecin traitant mais en cas d’urgence ?) carte a puce ? Comment révoquer les clefs ? PKI ?

Solution contre DoS : combiner RFID et capteur. La puce RFID sert de parefeu. RFID implémente le contrôle d’accès et vérifie que le lecteur est autorisé. Si le lecteur est accepté alors la communication est rendue possible avec le capteur sinon RFID bloque. Comme RFID est passif il ne consomme pas d’énergie. Le RFID pourrait émettre un son pour avertir le patient de l’interaction.

L’authentification passive est prometteuse. Mais la cryptographie ne suffit pas car le fait d’émettre des signaux révèle en soi des informations : le patient porte un pacemaker, information intéressante pour un assureur ou un employeur… Il y a déjà atteinte à la protection de la vie privée.

Besoin de protocole qui ne s’active qu’en présence de lecteur autorisé mais détectable et accessible en cas d’urgence. Le patient doit être mis dans la boucle (conscience de ce qui se passe, ça le rassure).

13.1.2. Surveillance

Un avion envoie des capteurs sur une zone. Le passage d’un char est détecté et les capteurs préviennent. Ex: feu de foret, routes…

Caractéristiques

  • nombre important de capteurs
  • capteurs bon marché

Problème de sécurité

  • capteurs facilement accessibles (ils sont dans la nature)
  • sécurité de l’infrastructure
  • distribution et échange de clefs
  • agrégation des données chiffrées
    • besoin de minimiser les transmissions (consomme beaucoup : 1 bit transmit = 1 000 opérations CPU)
    • agrégation : données compressées/traitées dans le réseau

Agrégation triviale sans sécurité mais devient difficile avec. Confidentialité ? Assurer l’authenticité ? Intégrité des données ?

  • approche saut à saut : chaque noeud chiffre et authentifie les données avec la clef qu’il partage avec l’agrégateur.
    • nécessite un protocole d’échange de clef
    • coûteux
    • sécurité faible (agresseur compromis peut accéder aux données)
  • approche bout en bout : chaque noeud partage une clef avec la station de base, l’agrégateur manipule les données chiffrées sans les déchiffrer.
    • besoin d’un algorithme de chiffrement homomorphe par l’addition (un peu magique mais ça marche)
    • l’agrégateur additionne les données chiffrées
    • la station de base reconnaît les clefs

13.2. Avis / commentaire

Mon seul endormissement pendant quelques slides mais un gros regret. Super, super intéressant. J’ai lu les actes et les recommande.

14. Dépérimétrisation : futur de la sécurité réseau ou pis aller passager ?

par Cédric Blancher / EADS

14.1. Notes

L’idée serait de sécuriser les données elles-mêmes.

La think-tank derrière le buzz est le Jericho forum.

Périmètre :

  • vieux
  • ne protège pas
  • contre productif

→ il faut donc :

  • ouvrir les réseaux
  • remonter la sécurité vers les applications

Tout cela pose beaucoup de questions :

  • réalité technique ?
  • réel apport ?
  • pour quelle cible ?

D’un point de vue réseau, l’objectif est le réseau plat :

  • moins de firewall
  • plus de connectivité (principe IPv6)
  • sécurité de bout en bout
  • fonctionnalités telles que l’overlay (réseau logique over réseau IP, tel que Skype)

On voit que l’on ne supprime pas le périmètre mais qu’on le reconstruit. Le problème est déplacé sur une couche logique.

La situation n’évolue pas trop :

  • mêmes moyens de sécurité
  • menaces client-side
  • problématique de confinement

→ la question reste de savoir comment gérer l’exposition des systèmes en terme de résilience, en particulier par rapport au reste du périmètre.

En fait la problématique reste la même :

  • mêmes services
  • mêmes données
  • mêmes accès
  • plus une gestion de l’impact de l’exposition accrue…

Le fond du problème réside dans la gestion des données

  • la valeur réside dans les données
  • comment protéger efficacement les données ?

Et quid de toutes les données ne transitant pas sur un réseau (clef USB) ?

14.2. Avis / commentaire

Probablement la conférence la moins technique.

Une bonne synthèse sur un sujet hot en ce moment qui évite de se taper pas mal de lecture pour se forger son opinion.

Surtout à faire lire à des n+x pour tuer le zombie avant qu’il ne s’élance…

Pas de solution miracle concernant la protection de la donnée elle-même (étonnant ;)). Et même, ce qu’il faudrait c’est une protection de la donnée selon le contexte d’utilisation… /dream_off

15. Pentests : réveillez-moi, je suis en plein cauchemar !

par Marie Barel / Orange business service

15.1. Notes

Mission du pen-testeur : détecter et exploiter des vulnérabilités d’un SI.

Démarche en boite noire :

  1. recueil d’information sur la cible et cartographie
  2. identification des vulnérabilités
  3. exploit
  4. collecte des preuves

Risques liés à la cible :

  • tests sur un système sans autorisation (avant-vente…)
  • erreur sur la cible
  • test sur une partie SI hors du champs de responsabilité du signataire du contrat
  • dépassement du périmètre contractuel des tests
  • SI cible hébergé par un tiers
  • test impliquant l’attaque de systèmes tiers pour faire un rebond

Article 323.1 du CP. Pour prouver, il faut :

  • un fait matériel
  • une intention frauduleuse
    • sans droit
    • en connaissance de cause

Protections :

  • caractère obligatoire du contrat “mandat express”
  • durée et modalités des tests
  • étapes de validation :
    • qualité et pouvoir du signataire
    • périmètre de la cible (validation de la cartographie après la première étape)
    • collecte de l’autorisation des tiers

15.2. Avis / commentaire

Encore une bonne synthèse sur le sujet.

Évidemment, l’intervenant (le masculin ne marque pas le genre en français, faites pas iech…) n’approuve pas les contrats type. On se doute que chaque cas est unique et qu’il faille adapter, mais éviter de repartir à zéro à chaque fois, ça fait gagner un peu de temps et des gens capables d’inventer l’eau chaude, il n’y en a pas beaucoup…

16. Une architecture de workspaces ubiquitaires, sécurisée et distribuée

par J. Rouzaud-Cornabas / LIFO

16.1. Notes

L’idée du bureau distant part du constat suivant :

  • augmentation bande passante
  • clients légers
  • centralisation du SI (mutualisation, économies d’énergie…)
  • augmentation de la sécurité

Le projet est pensé avec la sécurité en premier plan depuis la conception.

La solution s’appuie sur :

  • KDE
  • technologie NX : 10 kb.s-1 par utilisateur
  • sécurisation des flux avec openssh
  • authentification sur la base du couple Kerberos et LDAP. Solution de SSO.
  • virtualisation : virtualisation légère utilisant la solution OpenVZ (gestion de quotas poussée)

Migration à chaud et répartition de charge (dynamique de par l’utilisation d’un système P2P) et reprise automatique sur panne. Pas encore en production.

Le système est très surveillé à l’aide SNORT, NAGIOS, OSIRIS. De nombreuses alarmes sont générées ; ce n’est pas gérable par un humain. Aussi, y a-t-il des machines à état pour corréler toutes ces alertes :

  1. nœud = événement
  2. arc = transition chronologique, à autoriser sous conditions

L’architecture est entièrement composée d’élément en GPL.

Actuellement en production sur quatre machines physiques avec chacune 6 à 7 workspaces.

Sont passés de MySQL à PostgreSQL à cause d’un problème de mise à l’échelle.

16.2. Avis / commentaire

Intéressant.

Je ne suis pas sûr qu’une présentation de 30 minutes permette de se rendre compte de la quantité de travail que ce projet représente…

Je serai curieux de connaître le résultat de la mise en production lors de la rentrée 2009.

17. Take a walk on the wild side

par G. Arcas

17.1. Notes

La papier s’appuie sur l’analyse de 6 Go de traces réseaux (juillet 2007 à mars 2008). Pas de reverse.

Stormworm : cheval de Troie, rootkit.

Apparu fin 2006.

Premier botnet avec un C&C en P2P fiable.

Principalement utilisé pour :

  • du spam
  • DDoS
  • proxification web/DNS

Utilise du fast-flux hosting.

Suspect numéro 1 ruse | en russie (au choix). Utilisation des infrastructures RBN jusqu’en octobre 2007.

17.2. Avis / commentaire

Pour ceux qui ne se seraient pas tapés la lecture de la tonne de littérature sur le sujet, ben c’est un bon point d’entrée ;).

J’ai beaucoup aimé la question de l’ajout de certificats sur les postes infectés ou de l’utilisation de capacités de stockage, suite à l’ajout de la capacité DNS dans l’architecture de storm.

18. SinFP, unification de la prise d’empreinte active et passive des systèmes d’exploitation

par P. Auffret /

18.1. Notes

OSFP = art d’identifier la nature d’un OS par l’analyse de la manière dont il construit ses paquets réseaux

Deux modes :

  • actif : provoquer des réponses à l’aide de requêtes construites
  • passif : écoute seule des requêtes et des réponses

→ les empreintes sont différentes dans les deux modes.

Outils actuels ont de nombreuses limitations :

  • très détectable par les IDS
  • utilisation de nombreux protocoles souvent filtrés
  • utilisation de paquets non standard avec dommages collatéraux (crash et détection)
  • utilisation de ports différents : une autre machine en coupure peut répondre à la place
  • souvent IPv4 seulement
  • utilisation de bases de signatures (grosses) différentes pour l’actif et le passif

Les principes de SinFP :

  • utilisation de trois paquets standards sur un même port ouvert maximum (mais il est tout à fait possible de faire une prise d’empreinte avec seulement le deuxième paquet)
    1. 1 paquet TCP SYN sans option TCP
    2. 1 TCP SYN avec options TCP
    3. 1 TCP SYN+ACK (pour RST+ACK)
  • une seule base de signatures (les signatures passives sont dérivées)
  • IPv6 compliant

en se plaçant toujours dans les pires conditions possibles. (un seul port ouvert, filtrage state-full, packet scrubbing, etc.)

Une empreinte peut varier en fonction :

  • des conditions réseau
  • des dispositifs de filtrage
  • de la personnalisation de la pile IP

→ on utilise donc des masques pour redresser les distortions

Ces masques se basent sur cinq éléments :

  • binary
  • flags
  • window size
  • options
  • mss

18.2. Avis / commentaire

Avec mes maigres connaissances en la matière, je trouvais que des réponses différentes à des sollicitations de ports différents dues à des répondeurs en coupure ou re-routés permettaient justement d’avoir une bonne cartographie…

Le type présente ça avec une simplicité déconcertante alors qu’il doit pouvoir directement parler sur le réseau…

Je ne connaissais pas et je vais essayer (ce n’est pas dans la Debian).

19. Le recueil de la preuve numérique

par Nicolas Duvinage / département informatique-électronique de l’IRCGN (i.e. les experts au pays merveilleux…)

19.1. Notes

IRCGN :

  • 25 % de 3ème cycle
  • 50 % de 2ème cycle

Département : 15 personnes dont 12-13 ingénieurs

L’institut répond aux normes ISO 17025.

Quotidien : très peu de piratage. C’est du basique :

  • très peu d’intrusion/compromission mènent à des affaires judiciaires
  • 90 % de Windows, très peu de chiffrement (zip avec mots de passe)
  • communications email et MSN

Trois types de crimes & délits :

  • ceux où l’objet numérique est accessoire (mails, sms)
  • ceux où l’objet numérique est utilisé de façon principale (contenu illicite sur le net)
  • ceux où l’objet numérique est l’objet de l’infraction (craquage de carte téléphonique)

Les deux premiers types, le suspect a une faible connaissance (voire nulle) des objets numériques en cause.

Dans tous les cas, le travail d’analyse de la preuve doit être scientifique et indiscutable.

Preuve numérique :

  • tout élément matériel ou immatériel
  • recueilli et analysé dans le respect de la législation
  • apportant un indice (disculpant, incriminant, autre)

En pratique, il s’agit de :

  • supports de stockage numérique : magnétique, (les plus ennuyeux étant les cassettes de sauvegarde), flash, optique, magnéto-optique, micro-contrôleur, carte à puce
  • informations stockées chez des tiers : logs des FAI

Le recueil se fait de manière :

  • directe : perquisition
  • indirecte : réquisition judiciaire

Difficultés :

  • objets numériques très répandus, qui peuvent tous contenir quelque chose d’intéressant, mais les enquêteurs ne peuvent pas être partout
  • preuve peut être stockée sur un serveur distant (hors de France)
  • très grande variété de formes
  • ordinateur allumé, comment l’éteindre
    • extinction propre ou arrache de prise ?
    • transporter sans l’éteindre ?
  • GSM et sim en fonctionnement
    • extinction avec risques de non accès ultérieur ?
    • transport allumé avec risque de réception de messages ?
    • cage de faradayø?

Exploitation :

  • l’exploitation ne doit pas modifier l’élément de preuve car :
    • il faut pouvoir rendre indiscutable ce qui est trouvé
    • il faut, si il y a contre-expertise, qu’elle trouve les mêmes résultats
  • mais :
    • booter modifie pleins de choses (logs, etc.)
    • même en montant le disque dur en esclave sur un autre système, il y a des précautions à prendre (-ro est un peu court) Quid de SMART et GListRemapper ?
  • risques de pannes matériel

Donc, on travaille systématiquement (autant que possible) sur une copie :

  • blocage (matériel - voir http://tableau.com - ou logiciel - again -ro ne suffit pas) en écriture
  • ordre des examens (empreintes sur un CD, etc.)
  • connectique trop ancienne ou trop rare
  • connectique ne supportant pas la copie bit à bit
  • copie bit à bit qui modifie l’originale (dessoudage)
  • secteurs défectueux
  • supports endommagés / en panne

La copie est ensuite (techniquement) analysée :

  • analyse semi-automatique de systèmes de fichiers avec divers outils commerciaux ou pas (PhotoRec pour le carving)
  • FS rares ou pas documentés (GSM etc.)
  • formats bizarres
  • problèmes non techniques
    • quoi chercher
    • comment les mettre à disposition (format de fichier et support physique)
  • capacité des disques croissante, mais temps de GAV ne bouge pas
  • problèmes de tri et de temps d’analyse

Mais l’analyse technique ne suffit pas :

  • mettre les données en perspective, wrt. reste de l’enquête
  • rendre les analyses compréhensibles par un non-spécialiste
  • exprimer clairement les limites de l’analyse

Conseils lors de la découverte de ce que l’on pense être une infraction :

  • ce n’est pas forcément une infraction
  • le suspect n’est pas forcément responsable
  • un responsable n’est pas forcément coupable (pour de vrai)
  • même coupable, il ne sera peut-être pas forcement condamné
  • attention aux fausses accusations
  • prudence et discrétion
    • attention aux complicités internes
  • pas de jugements hâtifs (présomption d’innocence)
  • réagir vite, mais en respectant le droit
    • pas de perquisition sauvage, analyse de fichiers personnels, etc.
  • préserver les éléments de preuves
    • changer le pc (en prétextant une maintenance, une mise à jour, une infraction moins grave, etc.)

19.2. Avis / commentaire

Une présentation carrée, structurée, claire, intéressante. Non pas que les autres ne l’étaient pas aussi, mais là je pense que c’est un modèle d’école.

Sinon, pensez à regarder des séries françaises. Le monsieur a dit que ça a tendance à énerver le gendarme qui débarque à 0600 quand on lui demande un mandat…

Je vous invite à lire les papiers concernant les cold boot attack pour certaines questions levées ici.

20. Voyage au cœur de la mémoire

par D. Aumaître

20.1. Notes

  • présentation orientée Windows
  • mémoire physique = vue indépendante de l’OS
  • multiples points d’accès

Mais :

  • besoin de reconstruire les structures de l’OS
  • base de la mémoire pour un process stocké dans la structure _KProcess
  • la structure _KProcess est retrouvable en cherchant les structures _Dispatcher_header qui ont une signature fixe puis en éliminant les mauvaises possibilités

20.1.1. Comment accéder à la mémoire physique ?

  • firewire
  • VMWare
  • fichiers d’hybernation
  • forensic
  • coldboot attack

Le firewire permet l’accès direct à la mémoire physique via DMA.

L’accès à la mémoire est contrôlé par deux registres dans le contrôleur firewire qui est interdit par défaut sous Windows sauf pour certains périphériques (stockage de masse). La carte d’identité d’un ordinateur est modifiable, on peut donc la transformer et faire passer son Linux pour un iPod…

20.1.2. Accès direct à la mémoire

  • en lecture :
    • utilisation de Process Explorer 101, clone de Process Explorer. Utilise les informations suivantes : voir papier
    • utilisation de Regedit 101, clone de Regedit. Utilise les informations suivantes : voir papier
    • → forensic, récupération de données « sensibles »
  • en écriture :
    • patch de deux octets dans la base de registre
    • → login sans mot de passe
  • en exécution
    • détournement de pointeurs de fonctions. Si l’adresse d’un gestionnaire d’interruption est modifiée par du code contrôlé, celui-ci est exécuté à chaque fois que l’interruption est appelée
    • démonstration en exécutant un shell alors que la machine attaquée à la fenêtre de login
    • → whatever ;)

20.2. Avis / commentaire

Impressionnant. Je pense que tout le monde était relativement pantois devant la démonstration ;)

Pourquoi, puisque les *nix autorisent par défaut l’accès directe à la mémoire (en r pour Linux, en rw pour BSD et OSX), l’exploit n’est pas (aussi) présenté sur les *nix ?

21. Recherche et développement en sécurité des systèmes d’information : orientations et enjeux

par F. Chabaud / DCSSI

21.1. Notes

21.1.1. Enjeux de souveraineté

  • autonomie
  • protection du citoyen

21.1.2. La sécurité

Se base sur l’article « the six dumbest ideas in computer security » par Marcus Ranum (http://www.ranum.com/security/computer_security/editorials/dumb/)

  • autorisation par défaut : principe de la démocratie mais… Un utilisateur utilise moins de trente applications…
  • recenser les vulnérabilités
  • pénétrer et corriger
  • le hacking c’est super : quid d’enseigner à faire des systèmes sûrs…
  • sensibiliser l’utilisateur : si l’on compte sur l’utilisateur, c’est que l’on est en autorisation par défaut… Si ça avait dû marcher, ça aurait déjà marché…
  • il vaut mieux agir que de ne rien faire : « il est plus facile de ne pas faire quelque chose d’idiot que de faire quelque chose d’intelligent »

Tout ça, mais avec quelques nuances.

21.1.3. Défense en profondeur

Olivier Gobelin

Travailler sur tous les points suivants qui définissent la défense en profondeur :

  • prévenir
  • bloquer
  • renforcer
  • détecter
  • réparer

Mais, de manière générale :

  • on est mauvais en prévention
  • on mise trop sur le blocage (firewall), systèmes très connectés
  • on est mauvais en tolérance aux agressions
  • on commence à peine à faire de la détection
  • capacité de réparation très faible
    1. cycle de réparation très long
    2. quid de la réparation d’une puce de téléphone «ømauvaiseø»ø?

La plupart des problèmes est liée à des erreurs de conception.

La priorité devrait être au développement d’OS moins vulnérable et plus tolérant.

Point sur le concept du honeypot. Pourquoi ne pas utiliser le principe mais pour des systèmes en production ?

21.1.4. Forces & faiblesses de la recherche française

  • atouts
    • bonne école de cryptographie
    • bonne école de méthodes formelles

Mais les systèmes sont déjà bien standardisés aux niveau de la cryptographie et utilisent rarement les méthodes formelles. La qualité de la recherche française dans ces domaines a peu d’impact sur les systèmes opérationnels.

  • faiblesses
    • déséquilibre grave. Des compétences cruciales ne sont pas couvertes :
      1. OS
      2. protocoles réseaux
      3. architectures matérielles
    • bonne expertise dans l’analyse, mais pas dans la conception
    • recherches académiques sont peu connues des industriels
    • sensibilisation des décideurs
    • ré-équilibration de la recherche dans les domaines de la SSI (vastes domaines : cryptographie, informatique, électronique, protocoles, physique, etc.)
    • problème du retour sur investissement
    • besoin d’une communauté SSI
    • industriels doivent pouvoir identifier facilement les chercheurs susceptibles de les aider
    • structure d’échange

21.1.5. Thématiques prioritaires

Issues du rapport d’orientation du 10/04/2008

  • architectures des produits et des systèmes
    • enseigner à concevoir des architectures saines
    • les architectures sont beaucoup plus pérennes que les technologies (IP)
    • utiliser les compétences en architecture auto-organisante
  • informatique de confiance
    • TCG = futur des architectures de PC (qu’on le veuille ou non)
    • impact sur toutes les technologies
    • industrie de la carte à puce en première ligne (trois entreprises françaises sur 180)
    • représentation française insuffisante
    • initiative de la DCSSI en cours pour faire mieux connaître les travaux et y participer
    • éviter la politique de l’autruche / les approches idéologiques
  • cryptographie et gestion de clefs
    • ne pas se reposer sur ses lauriers
    • « la cryptographie c’est ce qui reste quand toutes les protections ont disparu »
    • le plus difficile à changer dans un système opérationnel
  • faciliter la SSI : ergonomie et supervision
    • l’amélioration de l’ergonomie faciliterait l’adoption de solutions sécurisées
  • fédération d’identités
    • réponse à une problématique d’ergonomie
    • crucial pour l’identification distante
    • éviter la politique de l’autruche
    • vraiment de la recherche à faire
      1. référentiel de la DCSSI pour l’authentification distante (proposé à l’AFNOR)

21.1.6. Fondations de la SSI

  • formats de données et protocoles
  • systèmes d’exploitation
    • anti-virus doivent être « éradiqués » (pas la réponse appropriée)
  • développer une masse critique pour avoir une communauté à même d’avoir de l’influence. Communauté mêlant recherche et industriels
  • défi SEC&SIø: Système d’Éxploitation Cloisonné et Sécurisé pour l’Internaute
    • appel à projet de l’ANR
    • 6 mois de conception pour proposer une configuration linux
      1. dédiée à l’internaute
      2. dédiée aux opérations sensibles (banque, télé-déclaration, messagerie signée)
    • 6 mois d’évaluation
      1. par attaque théorique ou pratique
      2. arbitrage DCSSI
  • trois challengers :
    • OSOSOSOS
    • Safe OS
    • SPACLik
  • bientôt site de référence

21.2. Avis / commentaire

Comme pour la première conférence, toute ressemblance avec des situations connues ne serait que purement fortuite…

J’ai bien aimé la mise en exergue de l’importance de l’OS… SELinux rulez ;)

Je me demande dans quelle mesure le développement de politiques SELinux pour faire un kiosque (contexte propre à Iceweasel et les deux ou trois plugins autorisés) de Dan Walsh répondrait au défi.

Très intéressant.

On sent l’intervenant légèrement désabusé par un certain nombre de comportements de nos dirigeants.

22. Dynamic malware analysis for dummies

par Philippe Lagadex / NATO/NC3A

22.1. Notes

Scénario type : gestion d’incidents - fichier infecté, on veut savoir ce que fait le code malveillant rapidement, sans avoir besoin d’une analyse exhaustive - temps réduit, pas forcément expert ASM

But de l’analyse

  • est-ce vraiment malveillant ?
  • est-ce un fichier connu ou une attaque ciblée ?
  • etc.

Etapes de l’analyse

  • désassemblage
    • vue complète et détaillée du code
    • mais besoin d’un expert, et ça peut prendre du temps
  • débogage
    • vision pas à pas de l’exécution
    • complémentaire du désassemblage
  • exploration de fichier
    • éditeur hexa
    • recherche de chaînes
    • explorateur de formats
    • file carving / forensic
    • anti-virus
    • scanners d’exploits
    • extraction simple, mais ne fonctionne pas si camouflage
  • analyse dynamique runtime : exécuter le code pour observer son fonctionnement
    • aperçu rapide et « facile »

Exemple

En cas d’attaque . exploration de fichier . analyse dynamique

On obtient des résultats partiels mais rapides. Si on a plus de temps, on passe au désassemblage et au débogage.

Pour ce genre d’ananlyse un laboratoire détient (au moins) :

  • sandnet = sandbox + internet simulé
  • deux machines (virtuelles ou non) connectées
  • un serveur
    • passerelle par défaut
    • serveur DNS
    • répond sur toutes les IPs
    • faux serveurs
    • enregistre toute l’activité réseau
  • une machine victime
    • OS brut, pas d’AV/firewall
    • compte administrateur
    • enregistrement des actions locales en temps réel ou par delta avant/après

Outils :

  • rescan
  • scalpel
  • hachoir
  • fess / officecat
  • sysanalyzer
  • anubis
  • cwsandbox
  • norman sandbox
  • joelbox
  • decalogue.info/sstic08/

22.2. Avis / commentaire

Conférence m’ayant donné l’impression que je n’étais peut-être pas si nul. Bon en même temps c’est pour dummies ;)

D’autant que pas mal des techniques proposées sont largement utilisables pour d’autres besoins du SI.

Scuttle collaborative bookmarks manager needs a captcha

May 6th, 2008

We operate a nice collaborative bookmarking site for our little community. We use the ’scuttle’ Debian package of the Scuttle social bookmarking system and it serves our needs well. But lately we have seen it inundated by torrents of spam unchecked by the slightest user registration control. Not checking whether the poster is human was all right twenty years ago, but in an age where most of the traffic is spam it is looking for trouble.

Some sort of registration validation has been requested more than three years ago, but progress of the project has been quite slow - apparently in part because Marcus Campbell prefers working alone to avoid having to manage other developers and conflicting agendas.

Last year, Telgorn submitted a patch to add captcha for user registration. But is probably stands no chance of inclusion into the main branch : Marcus Campbell has stated two years ago that he “will not be adding captcha” to Scuttle.

For now, having no patience for spam and only having to support a tiny community, I resorted to remove user registration from Scuttle and manage the registrations manually. The result can be witnessed at the modified registration page, and I’ll post this trivial patch if anyone asks. But for any significant community this is not an acceptable fix.

As Telgorn’s captcha patch shows, adding that functionality to Scuttle is simple. The question is rather about the future of Scuttle. Scuttle is a very nice tool, and compatibility with the del.icio.us API is a wonderful way to open it to a world of interactions. But not including CAPTCHA is a death wish for a tool that can only thrive if larger community can use it without overwhelming their administrative staff with spam cleanup duties.

The network effect inherent to social bookmarking grows faster than the number of users - which means that larger sites are the one who benefit the most from Scuttle. Scuttle is quite fast and I guess it could handle large crowds… If only it was capable of dealing with spam.

Will someone fork Scuttle or will it be soon confined to small communities ? Time will tell, but for now the future is incertain as far as I can see.

Let secure the client part of ssh

January 30th, 2008

ssh-add is a life saver, no doubt about that.

Of course, once your keys are loaded, anybody taking control of your machine can connect to any server for which you loaded a key.

There are a few solutions to this “problem”.

Wiping keys known by ssh-agent

First, you can empty your ssh-agent with the following command when you are leaving your machine for a long time:

$ ssh-add -D
All identities removed.
$

All identities you loaded are deleted from your agent.

Setting a lifetime to keys loaded

If you are afraid to forget wiping your identities, you can tell your ssh-agent to forget all identities it knows about after a specific lifetime of <time_s> in seconds :

$ ssh-add -t 
Enter passphrase for
:
Lifetime set to  seconds
$

The lifetime in seconds by default can be entered in minutes by adding m or in hours by adding h. Nevertheless, the echo by the program is always returned in seconds.

So, in the case presented above, if your are working 8 hours a day, set <time_s> to 28800 (or 8h), and all your identities will be removed after 8 hours.

Locking the ssh-agent

When your are leaving for a short time, you can also lock your ssh-agent with the following command:

$ ssh-add -x
Enter lock password:
Again:
Agent locked.
$

If you try to ssh a server you have loaded a key for, the login will ask for your passphrase (Enter passphrase for key /home/<login>/.ssh/id_rsa:)

You can unlock your ssh-agent with:

$ ssh-add -X
Enter lock password:
Agent unlocked.
$

Source: man ssh-add

How-to setup a secured SSH daemon ?

January 24th, 2008

After reading a good article explaining how-to setup a secured platform to exchange file based on SCP (http://www.unixgarden.com/index.php/securite/une-plate-forme-d%e2%80%99echange-securisee-avec-scponly [fr]), I decided to publish here my configuration of SSH daemon.

The configuration and its documentation is available here :

http://svn.timetombs.org/svn/dot/sshd_config

I tried to have it as secured as possible.

Enjoy!

How-to get a directory with wget ?

January 21st, 2008

I needed to get a whole directory this afternoon from an https site.

Here is the command :

$wget \
  --no-check-certificate \ ## do not validate the certificate (beware…)
  --recursive \ ## get the whole content of the directory, including subdirectories if any
  --no-clobber \ ## don't get twice the same file
  --no-parent \ ## don't ever get parent directory
  --continue \ ## continue getting a partially-downloaded content
  <https_url_site>/the/directory/ineed/
$

Look at man wget for more information as usual.

Enjoy!

How-to setup and use Tripwire

January 18th, 2008

Well, I spent a bit of time setting up Tripwire for a bastion system quite a few months ago.

Here is the result :

http://svn.timetombs.org/svn/tripwire/tip-timetombs-nix-security-tripwire.html

You can also find the policy (Debian one modified by myself) and the configuration :

Those two files must not be in text form on a protected machine ; they must be encrypted !

Enjoy!

tip - ssss - Shamir’s Secret Sharing Scheme

January 13th, 2008

Do you need to share a secret among several people ?

Do you want the secret to be revealed by only a sub-group of these people ? (different person could have different weight, i.e. more or less slices of the secret)

But do you want also to be absolutely sure that if someone has all the secret parts except one, he has no more information than with only one slice ?

Well, Shamir’s secret sharing scheme (or ssss) was designed for you!

So here is a short tip I wrote while discovering this tool. It is a bit useless because the man is quite well done. But it integrates small difficulties I met and, I think, easily understandable cases.

You can find the tip here :  http://svn.timetombs.org/svn/tip/tip-nix-soft-ssss.html

You can find more information about ssss here http://en.wikipedia.org/wiki/Secret_sharing

Enjoy!

Setting a small NTP architecture

January 9th, 2008

Imagine you want to set up the following NTP architecture :

  • three stratum 1 servers,
    • each one with its own receiver ;
  • three stratum 2 servers,
    • each one having a sibling,
    • each one (and its sibling) synchronized (potentially) to the three stratum 1,
    • each one (and its sibling) being authenticated (only symmetric authentication) with the stratum 1 servers,
    • being peers (the siblings being part of a round robin) ;
  • all other machines being synchronized on a round robin including the three stratum 2 servers.

Well, here are the configuration to implement that :

Notes about those configuration files :

  • they are heavily documented (resources are listed) ;
  • they are half French, half English ;
  • they were tested and are actually used in production (they are working…) ;
  • after one week working on public authentication, and having it working only half the time, I fell back on the symmetric authentication ;
  • some precisions are given for RHEL4 and RHEL5 ;
  • I probably forgot some details in this post ;) (use comments if you need precisions).

Enjoy !

Set a nice keymap for xorg

January 7th, 2008

Here is the keymap configuration I use.

This configurations allows :

  • full usage of Unicode characters such as ×, œ, « », …, ¿, É, À, etc. and especially the insecable space ;
  • switching between American and French keymaps (american keymap is easier for Vim) by hitting the keys <Shift><Caps> ;

Keyboard configuration in /etc/X11/xorg.conf

Section "InputDevice"
    Identifier      "Keyboard"
    Driver    "kbd"
    Option    "CoreKeyboard"
    Option    "XkbRules"        "xorg"
    Option    "XkbModel"       "pc105"
    Option    "XkbLayout"      "fr,us"
    Option    "XkbVariant"    "oss,altgr-intl"
    ## change keymap with shift+caps / do insecable space with altgr + space
    Option    "XkbOptions"    "grp:shift_caps_toggle,keypad:oss,nbsp:level3"
EndSection

To do the same from the command line, enter

$ setxkbmap \
  -layout fr,us \
  -variant oss,altgr-intl \
  grp:shift_caps_toggle,keypad:oss,nbsp:level3

vim - cheat sheet

November 21st, 2007

As said previously here is an application of the svg template I did for cheat sheets.

This is a Vim cheat sheet, inspired by the excllent vi / vim graphical cheat sheet.

So, here is the .pdf version, and here the .svg one (Firefox is not rendering it correctly).

Let me know if there are errors, or any improvment you may think of.

Enjoy !

Setup an USB stick to [ boot & install & store sensitive information ] securely

November 20th, 2007

Well, finally I post it. I haven’t touch this document it for a month, while using the result everyday…

So here it is :

http://svn.timetombs.org/svn/usbstick/usbstick.html

The goal of this howto is to setup a USB stick with the following possibilitie :

I heavily used the document Howto install Debian Linux onto a USB thumb drive with the root partition encrypted (using UUIDs, Initramfs-tools & Dm-Crypt). I asked for the permission to use it, but did not get any answer. See § Sources for more details.

Enjoy !


Bad Behavior has blocked 27 access attempts in the last 7 days.