Chapitre 1

Politique de sécurité et analyse

de risques

1.1 Analyse de risques Ebios : généralités

Exercice 1 : Bien supports et menaces génériques

1. Classer les bien supports suivants selon les catégories : matériels (MAT), logiciels
(LOG), canaux informatiques et de téléphonie (RSX), personnes (PER), supports
papier (PAP), canaux interpersonnels (CAN), locaux (LOC) :
— fibre optique
— document imprimé
— cartouche de sauvegarde
— commutateur téléphonique
— assistant personnel (PDA)
— SGBD Oracle
— discussions de couloir
— salle de réunion
— Linux
— client de courrier électronique
— poste de travail
— salle de conférence
— ligne téléphonique
2. Proposer des exemples d’impacts génériques : sur le fonctionnement, les humains,
les biens. Quels autres impacts ne rentrent pas dans les catégories précédentes ?
3. Pour les catégories LOG et CAN précentes, proposer des menaces génériques en
précisant le(s) critère(s) de sécurité concernés et les vulnérabilités exploitables. Par
exemple pour PER on proposerait "Dissipation de l’activité d’une personne" par
l’exploitation du temps de travail, du blocage de l’accès d’une personne ou
l’exploitation d’une personne en dehors de ses prérogatives. Cette menace porte
atteinte à la disponibilité de la personne et sera efficace sur les sujets à la
dissipation.

Exercice 2 : Évaluation des risques

L’action « Analyser les risques » consiste à mettre en évidence l’ensemble des risques qui pèsent
réellement sur le périmètre de l’étude et à déterminer leur gravité et leur vraisemblance, une première
fois sans tenir compte des mesures de sécurité existantes, et une seconde fois en les prenant en
compte. On fait ainsi le lien entre les événements redoutés et les
scénarios de menaces, c’est-à-dire entre ce que l’organisme craint et ce à quoi il est
exposé
 1. Connaissant les résultats produits par les étapes précédentes de l’analyse des
risques, expliquer comment identifier les risques.

1.2 Analyse de risques: cas d’étude UCBL

Description du cas La Direction du Système d’Information (DSI) de l’UCBL désire mettre en place
une Politique de Sécurité du Système d’Information (PSSI). La complexité du SI impose d’utiliser une
méthode pour recenser et classifier exactement ce qu’il faut sécuriser. Parmi les services de l’UCBL,
notons celui des finances, en charge de la comptabilité, de la gestion des budgets, des marchés et
des payes. Les services financiers s’appuient sur le logiciel SIFAC (Système d’Information, Financier
Analytique et Comptable) hébergé sur un serveur du bâtiment Braconnier. Notons que l’activité
services financiers n’est pas régulière, en effet, ces services sont particulièrement sollicités chaque
fin de mois pour les payes et de façon intense aux mois de novembre et de début décembre avec la
clôture de l’exercice budgétaire.

Exercice 3 : Étude du contexte

1. Les sources de menaces sont les sources non humaines (code malveillant, phénomène
naturel, catastrophe naturelle ou sanitaire, activité animale, événement interne) ou humaines.
Les humaines sont décomposées en interne/externe, avec/sans intention de nuire et selon
leur capacité (faibles, importantes, illimitées). Indiquer quelles sont les sources de menaces
qui peuvent raisonnablement être écartées du contexte de l’étude.
2. Donner des exemples de sources de menaces pour les types de sources de menaces suivants :

1. Source humaine interne, sans intention de nuire, avec de faibles capacités ;

2. Source humaine interne, sans intention de nuire, avec des capacités illimitées ;
3. Source humaine externe, sans intention de nuire, avec de faibles capacités ;
4. Source humaine externe, malveillante, avec de faibles capacités ;
5. Événement interne.
3. Quels sont les critères traditionnels de la sécurité ? La DSI souhaite ajouter le critère
de traçabilité dans le périmètre de son étude. Proposer une définition de ce critère et
justifier l’inclusion de ce nouveau critère dans le contexte.

Exercice 4 : Détermination des objectifs de sécurité

Dans le module d’étude des risques, les risques intolérables du service des finances sont :
— risque lié à l’arrêt de SIFAC en période de clôture ;
— risque lié l’usurpation d’identité sur la messagerie électronique ;
1. Quelles sont, en général, les différentes possibilités de traitement des risques ?
Lesquelles sont envisageables dans le contexte de l’étude ?
2. Proposer des mesures de sécurité pour réduire les risques.

1.3 Analyse de risques Ebios : cas d’étude @RCHIMED

Description du cas La société @RCHIMED est un bureau d’ingénierie en architecture.
Cette PME toulonnaise est constituée d’une douzaine de personnes.
La société @RCHIMED réalise des plans d’usines ou d’immeubles avec l’établissement préalable
de devis. Pour cela, elle calcule des structures, élabore des plans techniques pour ses architectes et
propose des maquettes virtuelles pour ses clients. Le suivi des constructions est aussi assuré
par le cabinet, qui met à jour les plans et calculs si des modifications sont nécessaires.
Le cabinet d’architecture bâti sa réputation grâce à des solutions architecturales originales
basées sur des techniques innovantes. Cette société concourt pour de grands projets nationaux
ou interna-tionaux ; elle s’appuie pour cela sur son système informatique qui lui permet de réagir
extrêmement rapidement aux appels d’offre ou aux demandes des clients.
Elle attache également une importance extrême à la qualité des documents remis et plus pré-
cisément aux maquettes virtuelles (visualisations 3D) qui permettent de donner à ses clients une
idée précise et concrète de la solution proposée. Dans un contexte de rude concurrence,
rapidité, précision et originalité des travaux sont des composantes essentielles de son activité.
Par ailleurs, elle a créé son site Internet sur lequel sont présentés les informations
concernant la société et des exemples de devis et de maquettes virtuelles.
L’informatique de la société est reliée par un réseau wifi et le bureau d’études dispose
d’un réseau local de type Ethernet. Le site Internet est hébergé sur un serveur externe. Le
bureau d’étude possède 7 ordinateurs, le service commercial 2 ordinateurs portables, le
service comptabilité 1 ordinateur, et le service de gestion de site Internet 1 ordinateur.

Sécurité du système d’information Il n’y a pas de principes généraux, ni de politique de

sécurité, seulement les quelques règles suivantes :
— le contrôle d’accès se fait par identifiant /mot de passe ;
— principe de sauvegarde de tout fichier ;
— chaque ingénieur est responsable du fichier qu’il traite, les fichiers sont sauvegardés sur des
disques USB stockés dans une armoire fermant à clé, située dans le bureau d’études ;
— parallèlement, les documents papiers sont rangés dans une armoire forte du service
commer-cial ;
— en ce qui concerne la maintenance, un contrat a été établi avec les fournisseurs de
logiciels avec intervention sous 4 heures.

Conjoncture La mise en réseau des systèmes informatiques s’est effectuée avec succès et
a permis de réduire encore plus les délais de réalisation des travaux. L’entreprise doit
maintenant répondre au souhait de la majorité des clients qui est de correspondre
directement avec le bureau d’étude via Internet pour transmettre tous les types de
documents (dossiers techniques, devis, appel d’offre, messages...).
L’entreprise a dernièrement perdu un marché : la rénovation de la mairie de Draguignan.
Lors de la présentation des projets, il est apparu de curieuses similitudes entre la maquette
virtuelle d’@RCHIMED et la proposition d’un concurrent de Nice. Le directeur d’@RCHIMED
soupçonne une compromission du projet qu’il avait présenté. Il a maintenant des craintes
sur la confidentialité de certains projets.
D’autre part, de plus en plus de contrats pour lesquels @ARCHIMED souhaite se
positionner sont conditionné par la capacité du cabinet à assurer la confidentialité relative
aux aspects techniques du projet. Par exemple, L’appel d’offre pour la rénovation de
certaines installations de la marine nationale de l’arsenal de Toulon entre dans ce cadre.
Compte tenu de son volume et de sa disposition, la société travaille de façon très ouverte.
Cependant, les experts du bureau d’études sont les seuls à pouvoir accéder aux logiciels les plus
performants de conception et de maquettage. Ces experts ont par ailleurs bénéficié d’une formation
à la manipulation de ces outils. Chacun est conscient de ces responsabilités financières, civiles et
pénales associées à l’usage des informations qu’il manipule : dossier client, données nominatives. . .
Le choix d’une étude de sécurité s’impose donc pour, d’une part, déterminer les
conditions qui permettent l’ouverture du système informatique vers l’extérieur et d’autre part
pour déterminer les mesures de sécurité nécessaires à la protection des projets sensibles.
 Exercice 5 : étude du contexte
1. Donner des exemples de sources de menaces à prendre en compte dans l’étude
pour les types de sources de menaces suivants :
1. Source humaine interne, sans intention de nuire, avec de faibles capacités ;
2. Source humaine interne, sans intention de nuire, avec des capacités illimitées ;
3. Source humaine externe, malveillante, avec des capacités importantes ;
4. Source humaine externe, malveillante, avec des capacités illimitée ;
5. Source humaine externe, sans intention de nuire, avec de faibles capacités ;
6. Événement interne.
2. Identifier 3 processus (métiers) essentiels du cabinet. Quelles sont les informations
essentielles concernées ?
Exercice 6 : étude des événements redoutés
Pour les activités de création de plans et de calculs de structures, évaluer les
événements re-doutés selon les 3 critères de sécurité disponibilité, intégrité, confidentialité.
On utilisera les échelles suivantes :
— Disponibilité : plus de 72h entre 24 et 72h entre 4 et 24h moins de 4h.
— Intégrité : détectable maîtrisé intègre.
— Confidentialité : public limité réservé privé.
— Gravité : négligeable limitée importante critique.
Evt. Besoin Source Impacts Gravité
Indisponibilité
Altération
Compromission

Exercice 7 : étude des scénarios de menaces

Détailler les sources et la vraisemblance des menaces portant sur le réseau wifi. On
utilisera l’échelle de vraisemblance suivante : minime significative forte maximale.
Menace Source Vraisemblance
Menaces sur le réseau wifi causant une
indisponibilité
Menaces sur le réseau wifi causant une
altération
Menaces sur le réseau wifi causant une
compromission

Exercice 8 : détermination des objectifs de sécurité

Au terme de la conduite de la méthode, les risques intolérables identifiés sont :
— risque lié à l’altération d’un devis qui doit rester rigoureusement intègre ;
— risque lié à la compromission d’un devis au-delà du personnel et des partenaires ;
— risque lié à l’altération de plans ou de calculs de structures qui doivent rester
rigoureusement intègres ;
 — risque lié à la compromission de plans ou calculs de structures au-delà des
personnels et partenaires.
Proposer des mesures de sécurité portant sur le bien support « serveurs logiciels du
réseau interne » pour réduire ces risques. Quelles autres mesures fautdrait’il appliquer pour
compléter les précédentes ?

1.4 Politique de sécurité

Exercice 9 : Critères non-fonctionnels des systèmes

Remplir le tableau récapitulatif en identifiant pour chacune des capacités d’un système,
les cri-tères associés (authenticité, auditabilité, intégrité, imputabilité, sûreté, exactitude,
fiabilité, disponi-bilité, accessibilité, continuité, traçabilité, confidentialité) et des exemples de
mesures qui contribuent à les assurer.
Capacité Critères Mesures

Exécuter des actions

Permettre l’accès aux entités
autorisées
Prouver les actions

Exercice 10 : Rentabilité d’une politique de sécurité

Une entreprise remarque que, statistiquement, elle sou ffre chaque année de 5 infections virales
et 3 défigurations de son site web. La remise en état après une infection coûte 2 jours de travail de
l’administrateur, soit environ 2000 e. La remise en état du site web nécessite environ 500 e. On
évalue la mise en place d’un produit d’antivirus ainsi qu’un système de protection pour le site web
à environ 30.000 e par an.
1. À partir des données numériques précédentes, évaluer le retour sur investissement
des mesures envisagées.
2. En quoi cette évaluation n’est pas adéquate, que faut’il prendre en compte d’autre ?

Exercice 11 : Niveau de sécurité

On appelle security gap la constatation que le niveau réel de sécurité d’un système
d’information est toujours inférieur à celui estimé. De plus, cette différence de niveau tend à
augmenter à mesure que le temps passe.
1. Donner deux raisons qui expliquent cette différence.
2. Décrire le genre de mesures à prendre pour éviter une baisse du niveau de sécurité.

Exercice 12 : Audit de sécurité

Une entreprise organise un appel d’offre pour faire auditer la sécurité de son réseau.
Trois offres sont proposées :
1. un audit conceptuel : plans, schémas et configurations du réseau sont demandés. À
partir de ces informations, l’expert estimera si le réseau est sûr ou non ;
2. un scan de vulnérabilités : à l’aide de sondes spécialisées plaçées à différents endroits
du réseaux, l’expert découvrira automatiquement les vulnérabilités des équipements ;
3. un test d’intrusion : sans aucune information préalable, l’expert tentera de pénétrer le
réseau de l’entreprise depuis Internet et de s’approprier des informations confidentielles.
 Chaque audit est utile à sa manière. Pour chacun, décrire une situation qui en ferait
l’usage approprié.
 Chapitre 3

Exploitation de vulnérabilités logicielles

3.1 Bonnes pratiques de développement logiciel

Exercice 30 : Authentification en PHP

Un étudiant de licence a développé une application de gestion. Voici un extrait du code
qu’il a utilisé pour l’authentification des utilisateurs de l’application.
1 $username = $_GET [ ’ username ’ ] ;
2 $ p a s s w o r d = $_GET [ ’ p a s s w o r d ’ ] ;
3 $ s q l u s e r = mysql_query ( "SELECT␣COUNT( ) ␣FROM␣ u s e r s ␣WHERE␣ username ␣=␣ ’ " . $username .
"’");
4
5 $ countuser = mysql_fetch_row ( $ s q l u s e r ) ;
6 i f ( $ countuser [ 0 ] == 0) {
7 $ errormsg = " Your ␣ Username ␣ i s ␣ i n c o r r e c t . ␣ P l e a s e ␣ t r y ␣ again " ;
8 } else {
9 $ s q l p a s s = mysql_query ( "SELECT␣COUNT( ) ␣FROM␣ u s e r s ␣WHERE␣ username ␣=␣ ’ " .
$username . " ’ ␣AND␣ password ␣=␣ ’ " . $ password . " ’ " ) ;
10 $ countpass = mysql_fetch_row ( $ s q l p a s s ) ;
11 i f ( $ countpass [ 0 ] == 0) {
12 $ errormsg = " Your ␣ Password ␣ i s ␣ i n c o r r e c t . ␣ P l e a s e ␣ t r y ␣ again " ;
13 } else {
14 $page = $_GET[ ’ page ’ ] ;
15 i f ( f i l e _ e x i s t s ( ’ pages / ’ . $page . ’ . php ’ ) ) {
16 i n c l u d e ( ’ pages / ’ . $page . ’ . php ’ ) ;
17 ...
18 }
19 }
20 }

1. Identifier différentes failles de sécurité du code de l’authentification.

2. Quelles mesures correctives suggérer ?

Exercice 31 : Bonnes et mauvaises pratique du PhP

Une page PhP vous est fournie ci-dessous :
1 <?php r equire _ o n c e ’ header . php ’ ?>
2
3 <h1>Free o n l i n e t o o l s </h1>
4
5 <d i v c l a s s=" c o n t a i n e r ␣ background−white ">
6<!−− Nmap Box −−>
7 <d i v c l a s s=" col −md−6␣ col −md−o f f s e t −3␣ col −sm−o f f s e t −3">
8 <form c l a s s=" " method="POST" a c t i o n=" ">

23
 9 <d i v a l i g n=" c e n t e r " c l a s s=" e r r o r ">
10 <?php i f ( i s s e t ( $ e r r o r ) ) echo $ e r r o r ; ?>
11 </d i v >
12 <d i v c l a s s=" l o g i n −header ␣ margin−bottom −30">
13 <h2>Enter an IP Address </h2>
14 </div >
15 <d i v c l a s s=" input −group ">
16 <span c l a s s=" input −group−addon ">
17 <i c l a s s=" f a ␣ fa −eye "></i >
18 </span>
19 <i n p u t name=" i p " p l a c e h o l d e r=" i p " c l a s s=" form−c o n t r o l " type=" t e x t ">
20 </div >
21 <d i v c l a s s=" row ">
22 <d i v c l a s s=" col −md−6">
23 <i n p u t type=" submit " c l a s s=" btn ␣ btn−primary ␣ p u l l −r i g h t " name="
submit " v a l u e=" Try ! " />
24 </div >
25 </div >
26 <hr>
27 <h4>Nmap, the b e s t network scanner of the world ... </ h4>
28 <p>
29 </form>
30 </div >
31 <!−− End Nmap Box −−>
32 </div >
33
34 <?php
35 i f ( i s s e t ($_POST[ " submit " ] ) )
36 {
37 i f ( empty ($_POST[ ’ i p ’ ] ) )
38 $ e r r o r = " IP ␣ f i e l d ␣ i s ␣ r e q u i r e d . " ;
39 else
40 {
41 $ ip=$_POST[ ’ i p ’ ] ;
42 echo "<pre>" ;
43 system ( "nmap␣−A␣ " . $ ip ) ;
44 echo "</pre>" ;
45 }
46 }
47 require _ o n c e ( ’ f o o t e r . php ’ ) ;
48 ?>

1. Expliquez quelle la fonctionnalité proposée par cette page.

2. Identifiez ses problèmes de sécurité et leurs impacts potentiels.
3. Que proposez-vous comme solution ?

Exercice 32 : Conseils pour du code sûr (Michael Howard & Steve Lipner)
Dans le chapitre 11 Secure Coding Policies de l’ouvrage The Security Development
Lifecycle : SDL : A Process for Developing Demonstrably More Secure Software, Michael
Howard & Steve Lipner, on trouve les bonnes pratiques suivantes pour l’écriture de code
sûr, expliquer et justifier chacune de ces pratiques :
1. use the latest compiler and supporting tool versions ;
2. use defenses added by the compiler ;
3. use source-code analysis tools ;
4. do not use banned functions.

Exercice 33 : Guide de style pour du code robuste (Matt Bishop & Chip Elliott)
 L’objectif de l’exercice est d’arriver, en critiquant un code C, à produire des
recommandations issues de Robust Programming by Example, Matt Bishop & Chip Elliott,
sur les bonnes pratiques pour écrire du code robuste.
1. Que font les appels qmanage(&qptr,85,1), qmanage(&qptr,1,85) et qmanage(&qptr,0,85).
Quelle(s) recommandation(s) suggérer concernant les paramètres des fonctions (en C) ?
2. Que se passe-t’il si qptr ou *qptr est 0 dans un appel à qmanage(&qptr,0,42). Que se
passe-t’il lorsque cet appel est passé plusieurs fois ? Quelle(s) recommandation(s)
supplémen-taire(s) suggérer concernant les paramètres ?
Pour une référence en ligne exhaustive et de première qualité sur la programmation
C/C++ sûre, voir http://www.securecoding.cert.org/. Pour un exemple de vulnérabilité
cau-sée par une double libération de la mémoire, voir par exemple
http://www.cert.org/ advisories/CA-2002-07.html
1 typedef struct queue {
2 int que ; / t h e a c t u a l a r r a y o f queue
elements /
3 int head ; / head i n d e x i n que o f t h e queue
/
4 int count ; / number o f e l e m e n t s i n queue /
5 int size ; / max number o f e l e m e n t s i n queue
/
6 } QUEUE ;
7
8 v o i d qmanage ( QUEUE , int , int ); / c r e a t e , d e l e t e queue /
9 v o i d qputon ( QUEUE , int ); / add t o queue /
10 v o i d q t a k e o f f ( QUEUE , int ); / remove from queue /
11
12 v o i d qmanage ( QUEUE qptr , int flag , int size ){
13 if (flag) { / a l l o c a t e a new queue /
14 ( q p t r ) = m a l l o c ( s i z e o f ( QUEUE ));
15 ( q p t r )−>head = ( q p t r )−> c o u n t = 0 ;
16 ( q p t r )−>que = malloc ( size sizeof ( int ));
17 ( q p t r )−> s i z e = s i z e ;
18 } else { / d e l e t e t h e c u r r e n t queue /
19 ( v o i d ) f r e e ( ( q p t r )−>que ) ;
20 ( void ) free ( qptr);
21 }
22 }
3.2 Reconnaissance et réseaux

Exercice 34 : SYN flooding

Le principe du SYN flooding consiste à submerger un serveur de requêtes TCP qui
seront vo-lontairement laissées dans un état semi-ouvert (plus précisément l’état
SYN_RCVD dans lequel est un serveur qui a reçu un SYN mais attend toujours le ACK
correspondant) afin de consommer un maximum de ressources sur la cible.

1. Que se passe-t’il lorsque un client essaie de se connecter légitime au serveur victime

de cette attaque ?
2. Le problème du SYN flooding est inhérent à la façon dont une connexion TCP est
établie. Comment réduire voire supprimer cette vulnérabilité ?
3. Une attaque de SYN flooding distribué (Distributed Deny of Service, DDoS) consiste à lancer des
attaques SYN flooding simultanées depuis de multiples sources. Comment s’en protéger ?

Exercice 35 : Analyse de ports avec nmap

Les traces A & B données en annexes sont des extraits obtenus avec l’outil nmap. Cet
outil permet de créer des paquets TCP/IP sur mesure permettant de déterminer quels sont
les ports La trace A a été obtenue avec l’interface eth0 et la trace B avec l’interface wlan0
d’une même machine.
1. Quelle est l’IP de la machine cible et la liste des ports scannés.
2. Quelles sont les IPs de la machine qui exécute nmap et le port source utilisé.
Pourquoi cette valeur ?
3. En quoi consiste la méthode de scan utilisée ?
4. Dans quels états sont les ports scannés (ouvert, filtré ou fermé) dans la trace A ?
5. Dans quels états sont les ports scannés (ouvert, filtré ou fermé) dans la trace B ?
6. Expliquer la différence de résultat entre les deux traces.
 3.3 Étude d’exploits

Exercice 36 : Vulnérabilité logicielle directory traversal

On donne l’extrait de code PHP suivant qui est vulnérable à une attaque dite directory traversal.
1 <?php
2 $ t e m p l a t e = ’ r e d . php ’ ;
3 i f ( i s s e t ( $_COOKIE [ ’ TEMPLATE ’ ] ) )
4 $ t e m p l a t e = $_COOKIE [ ’ TEMPLATE ’ ] ;
5 i n c l u d e ( " / home/ u s e r s / phpguru / t e m p l a t e s /" . $ t e m p l a t e ) ;
6 ?>

1. Expliquer quelle est la vulnérabilité de ce code.

2. Étant donné l’exemple suivant où un cookie contenant XXX pour la clef TEMPLATE
est transmis au serveur, proposer un exemple d’exploitation de la vulnérabilité.
1 GET / v u l n e r a b l e . php HTTP/ 1 . 0
2 C o o k i e : TEMPLATE=XXX

3. Proposer différentes mesures de protection pour limiter ces attaques au niveau :

— du traitement des paramètres dans le code PHP ;
— de la configuration dans l’OS hôte.

Exercice 37 : La faille CVE-2011-4029 (Magazine MISC numéro 60)

On s’intéresse à la vulnérabilité Xorg publiée fin 2011 sous l’identifiant CVE-2011-4029. Cette
dernière exploite une « condition de concurrence » (en anglais race condition) de Xorg qui permet
à un utilisateur local de positionner les droits en lecture sur n’importe quel fichier du
système. La sortie console suivante montre une trace des appels système exécutés pour
créer ce verrou lors du lancement d’un serveur X sur le display « :1 ».

# strace X:1
open("/tmp/.tX1-lock", O_WRONLY|O_CREAT|O_EXCL, 0644) = 0
write(0, " 20093\n", 11) = 11
chmod("/tmp/.tX1-lock", 0444) =0
close(0) =0
link("/tmp/.tX1-lock", "/tmp/.X1-lock") = 0
unlink("/tmp/.tX1-lock") =0

La trace est composée des étapes suivantes :

1. Ouverture d’un fichier verrou temporaire (/tmp/.tX1-lock)
2. Écriture de l’identifiant du processus (PID) dans ce nouveau fichier
3. Positionnement des droits en lecture pour tous les utilisateurs
4. Fermeture du fichier temporaire
5. Création d’un lien physique avec le véritable nom du fichier verrou (/tmp/.X1-lock)
6. Suppression du fichier verrou temporaire (/tmp/.tX1-lock)
C’est dans la manière dont est manipulé le fichier verrou temporaire (étapes 1 à 4), lors
du lancement d’un serveur X, que la faille réside. Voici un extrait de la fonction LockServer()
du fichier os/utils.c :
 294 do {
295 i++;
296 lfd = open(tmp, O_CREAT | O_EXCL | O_WRONLY, 0644);
297 if (lfd < 0)
298 sleep(2);
299 else
300 break;
301 } while (i < 3);
...
314 if (lfd < 0)
315 FatalError("Could not create lock file in %s\n", tmp);
316 (void) sprintf(pid_str, "%10ld\n", (long)getpid());
317 (void) write(lfd, pid_str, 11);
318 (void) chmod(tmp, 0444);
319 (void) close(lfd);
...
328 haslock = (link(tmp,LockFile) == 0);
329 if (haslock) {
...
333 break;
334 }
335 else {
336 /*
337 * Read the pid from the existing file
338 */
339 lfd = open(LockFile, O_RDONLY);
340 if (lfd < 0) {
341 unlink(tmp);
342 FatalError("Can’t read lock file %s\n", LockFile);
343 }

La fonction open() permet la création du fichier tmp : en cas de réussite, open() assure qu’aucun
fichier du même nom n’était présent sur le disque et renvoie un descripteur de fichier. A l’inverse de
fchmod(), la fonction chmod() opère sur un nom de fichier et non sur un descripteur de fichier.

L’exploit de type « Time-Of-Check-To-Time-Of-Use » de la faille CVE-2011-4029,

consiste, entre les lignes lignes 296 et 317, à supprimer puis remplacer le fichier tmp par un
lien symbolique pointant vers un fichier arbitraire, afin que le changement de droits de la
ligne 318 soit effectué sur le fichier de notre choix.
La difficulté de l’exploit est de réussir à intercaler précisément ces actions dans l’exécution de
LockServer(). Le principe général de l’exploit, résumé par la figure 1, consiste :
— à exécuter une première instance (P1) de Xorg contrôlée via les signaux SIGSTOP et
SIGCONT qui permettent respectivement de mettre en pause un processus et de le
relancer là ou il s’était arrêté. L’arrêt de la première instance d’Xorg doit se faire
immédiatement après la création du fichier temporaire (ligne 296) ;
— à exécuter une deuxième instance (P2) qui supprimera le fichier tmp pendant que
(P1) est stoppé ;
— à scruter efficacement le système de fichier. Pour cela, l’API Inotify permet de
reporter à une application tout changement sur un système de fichier au lieu de
guetter l’apparition d’un fichier en testant sa présence avec une boucle while().
 (Figure 1) Fonctionnement de l’exploit

1. Expliquer le problème de la fonction LockServer().

2. Comment et pourquoi (P2) supprimera le lien physique (que l’on assimilera à un
fichier) vers LockFile ?
3. Quel est l’intérêt de Inotify ? Qu’adviendrait-il si on utilisait une technique naïve de
boucle while() pour scruter l’activité dans /tmp ?
4. Pourquoi le lancement de l’instance (P1) dans l’exploit se fait avec la plus basse priorité ?

5. Quelle correction pourrait-on apporter pour supprimer cette faille ?

6. Dans le proof of concept de l’exploit, le fichier sur lequel est positionné 0444 est
/etc/shadow. Donner des exemples d’impacts que l’exploitation de cette technique
permettrait d’avoir. Quel autres fichiers pourrait-on vouloir utiliser ?

Exercice 38 : Analyse du bulletin MS10-092

Bulletin MS10-092 : This security update resolves a publicly disclosed vulnerability in

Windows Task Scheduler. The vulnerability could allow elevation of privilege if an attacker
logged on to an affected system and ran a specially crafted application. An attacker must
have valid logon credentials and be able to log on locally to exploit this vulnerability. The
vulnerability could not be exploited remotely or by anonymous users. [. . . ]
An elevation of privilege vulnerability exists in the way that the Windows Task Scheduler
im-properly validates whether scheduled tasks run within the intended security context. An
attacker who successfully exploited this vulnerability could run arbitrary code in the security
context of the local system. An attacker could then install programs ; view, change, or delete
data ; or create new accounts with full user rights.
Les jobs du Task Scheduler sont décrits par des fichiers xml de la forme suivante. Notons qu’il est
possible d’ajouter des commentaires dans ce fichier avec les balises <!- - comment - ->. Le dossier où
sont stockés ces fichiers est lisible par LocalSystem et les administrateurs locaux. Un utilisateur (sauf
guest) peut écrire dans ce dossier. Pour protéger l’intégrité des commandes (qui sont exécutée par le
Task Scheduler qui est un utilisateur privilégié), un checksum est calculé à la création de la tâche.
Quand le job est lancé, le checksum est recalculé et comparé à celui enregistré avant d’être exécuté.
Un algorithme de cyclic redundancy check (CRC) est utilisé pour cela (en l’espèce, CRC32).
La description de l’exploit est la suivante :
1. Create a job that will be run under the current user account with the least available privileges ;
2. Read the task configuration file corresponding to the task created at step 1 and
calculate its CRC32 checksum ;
3. Modify the task configuration file corresponding to the task created at step 1 so that it
matches the same check sum as the original file and set the following properties :
(a) Run the task.Principal Id=LocalSystem (principal for the task that provides security
cre-dentials) ;
(b) Run the task.UserId=S-1-5-18 (SID of the LocalSystem) ;
(c) Run the task.RunLevel=HighestAvailable (run with the highest available privileges) ;
(d) Run the task.Actions Context=LocalSystem (security context under which the
actions of the task are performed) ;
4. Run the task.

1. Quel est le problème qui rend l’étape 3 de cet exploit possible ? De quelle forme
d’attaque cryptographique s’agit-il ? Quelle solution proposeriez-vous ?
2. Dans quelle catégorie de la classification SANS classeriez-vous cet exploit ? (à voir
après le cours sur les vulnérabilités).
Annexe A

Appendice

A.1 Traces nmap

Trace A
SENT (0.5190s) TCP 134.214.143.195:53 > 134.214.142.10:22 S ttl=64 id=45396 iplen=44
SENT (0.5190s) TCP 134.214.143.195:53 > 134.214.142.10:443 S ttl=64 id=23365 iplen=44
SENT (0.5190s) TCP 134.214.143.195:53 > 134.214.142.10:80 S ttl=64 id=53776 iplen=44
SENT (0.5190s) TCP 134.214.143.195:53 > 134.214.142.10:8080 S ttl=64 id=24307 iplen=44
SENT (0.5190s) TCP 134.214.143.195:53 > 134.214.142.10:631 S ttl=64 id=16206 iplen=44
RCVD (0.5190s) TCP 134.214.142.10:22 > 134.214.143.195:53 SA ttl=64 id=0 iplen=44
RCVD (0.5190s) TCP 134.214.142.10:443 > 134.214.143.195:53 SA ttl=64 id=0 iplen=44
RCVD (0.5190s) TCP 134.214.142.10:80 > 134.214.143.195:53 SA ttl=64 id=0 iplen=44
RCVD (0.5190s) TCP 134.214.142.10:8080 > 134.214.143.195:53 SA ttl=64 id=0 iplen=44
RCVD (0.5200s) TCP 134.214.142.10:631 > 134.214.143.195:53 RA ttl=64 id=0 iplen=40

Trace B
SENT (0.2300s) TCP 134.214.235.21:53 > 134.214.142.10:443 S ttl=64 id=49208 iplen=44
SENT (0.2300s) TCP 134.214.235.21:53 > 134.214.142.10:80 S ttl=64 id=32073 iplen=44
SENT (0.2300s) TCP 134.214.235.21:53 > 134.214.142.10:8080 S ttl=64 id=30178 iplen=44
SENT (0.2300s) TCP 134.214.235.21:53 > 134.214.142.10:22 S ttl=64 id=38225 iplen=44
SENT (0.2300s) TCP 134.214.235.21:53 > 134.214.142.10:631 S ttl=64 id=9262 iplen=44
RCVD (0.2320s) TCP 134.214.142.10:443 > 134.214.235.21:53 SA ttl=64 id=0 iplen=44
RCVD (0.2330s) TCP 134.214.142.10:80 > 134.214.235.21:53 SA ttl=64 id=0 iplen=44
RCVD (0.2340s) TCP 134.214.142.10:8080 > 134.214.235.21:53 SA ttl=64 id=0 iplen=44
SENT (1.3310s) TCP 134.214.235.21:53 > 134.214.142.10:631 S ttl=64 id=39325 iplen=44
SENT (1.3310s) TCP 134.214.235.21:53 > 134.214.142.10:22 S ttl=64 id=370 iplen=44

A.2 Syntaxe concrète web.xml

<security-constraint>
<web-resource-collection>
<web-resource-name>restricted methods</web-resource-name>
<url-pattern>/*</url-pattern> <url-pattern>/acme/wholesale/*</url-
pattern> <url-pattern>/acme/retail/*</url-pattern> <http-
method>DELETE</http-method> <http-method>PUT</http-
method>

</web-resource-collection>
<auth-constraint/>
</security-constraint>
<security-constraint>
43
 <web-resource-collection>
<web-resource-name>wholesale</web-resource-name>
<url-pattern>/acme/wholesale/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>SALESCLERK</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>wholesale</web-resource-name>
<url-pattern>/acme/wholesale/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>CONTRACTOR</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection> <web-resource-
name>retail</web-resource-name>
<url-pattern>/acme/retail/*</url-pattern> <http-
method>GET</http-method> <http-
method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>CONTRACTOR</role-name>
<role-name>HOMEOWNER</role-name>
</auth-constraint>
</security-constraint>

A.3 Exemple XACML

PS_patient = <Null, <P_patient_record, P_medical_record>, p-o>
P_patient_record = <Null, <RP1, RP2, RP3>, d-o> P_medical_record =
<Null, <RM1, RM2>, d-o>

RP1 =
< p,
subject(patient) /\ action(read) /\ resource(patient_record),
patient(id,X) /\ patient_record(id,Y) /\ (X = Y \/ (age(Y) < 18 /\
guardian(X,Y))>

RP2 =
< p,
subject(patient) /\ action(write) /\ resource(patient_survey), patient(id,X) /\
patient_survey(id, X)>

RP3=
< p,
 (subject(doctor) \/ subject(nurse)) /\ action(read) /\ resource(patient_record), true>

RM1 =
< p,
subject(doctor) /\ action(write) /\ resource(medical_record),
doctor(id,X) /\ patient(id,Y) /\ medical_record(id, Y) /\ patient_doctor(Y,X)>

RM2 =
< d,
subject(doctor) /\ action(write) /\ resource(medical_record), doctor(id,X),
patient(id,Y), medical_record(id, Y), not patient_doctor(Y,X)>