Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTFR-2015-ACT-032

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 10 août 2015
No CERTFR-2015-ACT-032

Affaire suivie par :

CERT-FR

Objet : Bulletin d'actualité CERTFR-2015-ACT-032

1 - Bénéfices des RODC

Introduction

Afin de répondre à certaines problématiques de sécurité, les RODC (Read-Only Domain Controllers) sont aujourd'hui de plus en plus répandus en environnement Active Directory. Cependant, leur intérêt est souvent mal compris et ils sont rarement utilisés et configurés de manière satisfaisante. Par exemple, il est fréquent d'observer des RODC utilisés comme serveur mandataire vers un RWDC (contrôleurs de domaine "complets", par opposition aux RODC) afin d'en limiter l'exposition et la surface d'attaque, ce qui ne fait pas partie des cas d'usage des RODC et vient complexifier l'administration du domaine sans apport de sécurité.

Cet article se propose donc de détailler les intérêts réels des RODC, de donner des détails techniques quant à leur configuration, puis de formuler des recommandations à l'usage des RODC.

Présentation et intérêts des RODC

Les RODC sont des contrôleurs de domaine, pour lesquels on observe les différences suivantes :
  • ils possèdent des partitions de l'annuaire AD en lecture seule ;
  • ils possèdent une copie du SYSVOL en lecture seule ;
  • ils n'effectuent pas de réplication sortante avec les autres DC, c'est-à-dire qu'aucun RWDC ne réplique depuis un RODC ;
  • ils possèdent une copie "filtrée" de l'annuaire : certains attributs ne leur sont jamais transmis et les attributs secrets (les plus sensibles d'un domaine, comme ceux contenant les empreintes de mot de passe) ne leur sont transmis que pour certains comptes explicitement autorisés, par défaut aucun.

Ainsi, du point de vue de la sécurité, un RODC doit permettre de limiter la compromission d'un domaine à la surface gérée par le RODC compromis, sans entraîner la compromission totale du domaine. Un attaquant ne pourra pas en effet créer, modifier ou supprimer des informations dans l'annuaire ou dans le SYSVOL de manière globale au domaine, et ne pourra également pas récupérer d'attributs sensibles ou secrets suite à l'extraction de la base contenant les données de l'annuaire AD d'un RODC (« ntds.dit »).

Cependant, cette sécurité n'est effective que dans certains cas d'usage, et d'après les documentations Microsoft, les intérêts des RODC sont les suivants :

  1. installer un contrôleur de domaine sur un site pour lequel la sécurité physique n'est pas garantie ou d'un niveau de confiance moindre ;
  2. déléguer l'administration d'un contrôleur de domaine à un administrateur sur un périmètre restreint, n'ayant pas d'autres privilèges particuliers sur le domaine, permettant ainsi de ne pas étendre les groupes privilégiés d'administration du domaine (au contraire d'un RWDC, sur lequel il n'est pas possible de dissocier « administrateur local du DC » et « administrateur du domaine ») ;
  3. permettre l'authentification d'une population d'utilisateurs spécifiques sur un site distant disposant d'un lien réseau faible (ou subissant des coupures avec le SI principal), sans avoir à y déployer un RWDC ;
  4. alléger la réplication des RWDC centraux dans certaines topologies en étoile où ces contrôleurs de domaine possèdent de nombreux partenaires de réplication.

Dans un prochain article, nous aborderons les détails techniques et la configuration des RODC.

2 - Vulnérabilités dans le cadriciel StageFright

De multiples vulnérabilités affectant le cadriciel multimédia "StageFright" du système Android ont été découvertes par Joshua Drake, chercheur à l'entreprise Zimperium Zlabs.
Ces vulnérabilités affectent toutes les versions du système Android depuis 2.2 (Froyo).
Le chercheur a identifié des vulnérabilités de type "dépassement d'entier" permettant d'exécuter du code arbitraire à distance. Les plus critiques affectent le parseur mpeg4 de StageFright.
Les vecteurs d'attaques sont multiples et il est possible d'exploiter un appareil à distance sans aucune interaction de la part de l'utilisateur. La disposition stochastique de l'espace d'adressage (ASLR) à partir des versions 4 d'Android rend l'attaque plus compliquée mais néanmoins possible.

L'exploitation de la vulnérabilité sur l'appareil peut se faire via :

  • la réception d'un MMS contenant le média malveillant,
  • la visite d'une page web contenant le fichier incrusté,
  • le chargement du fichier mp4 malformé avec un lecteur multimédia quelconque.

Cette vulnérabilité pourrait permettre d'installer une application malveillante sur un appareil Android de manière furtive.

Analyse de la vulnérabilité CVE-2015-3827

Une vulnérabilité de type "dépassement d'entier" affecte la fonction "MPEG4Extractor::parseChunk" du parseur mpeg4 lors du traitement de l'atome "covr".
Dans le code ci-dessous, la valeur de la variable "chunk_data_size" n'est pas vérifiée. Si cette valeur vaut la taille maximale d'un entier, le tampon alloué sera de taille nulle. Si la valeur de "chunk_data_size" est inférieure à kSkipBytesOfDataBox (donc 16), une très grande valeur (correspondant à la taille de la donnée à copier) sera passée en argument à la méthode MetaData::setData, ce qui pourra provoquer un dépassement de tampon sur le tas.
case FOURCC('c', 'o', 'v', 'r'):
{
        [...]
        sp<ABuffer> buffer = new ABuffer(chunk_data_size + 1);
        [...]
        const int kSkipBytesOfDataBox = 16;
        mFileMetaData->setData(KeyAlbumArt, MetaData::TYPE_NONE,
        buffer->data() + kSkipBytesOfDataBox, chunk_data_size - kSkipBytesOfDataBox);
        [...]

}
La variable chunk_data_size est définie plus haut dans le code.
off64_t data_offset = *offset + 8;
[...]
off64_t chunk_data_size = *offset + chunk_size - data_offset;
Pour que chunk_data_size puisse être égale à MAX_SIZE, chunk_size doit être égale à 0xFFFFFFFF + 8 car :
*offset + chunk_size - data_offset == 0xFFFFFFFF
*offset + chunk_size - (*offset+8) == 0xFFFFFFFF
chunk_size - 8 = 0xFFFFFFFF
La variable chunk_size est définie au début de la fonction :
uint64_t chunk_size = ntohl(hdr[0]);
Cette variable est contrôlable par l'attaquant car hdr[0] correspond aux 4 premiers octets de l'atome.
if (chunk_size == 1) {
        if (mDataSource->readAt(*offset + 8, &chunk_size, 8) < 8) {
                return ERROR_IO;
        }
        chunk_size = ntoh64(chunk_size);
        data_offset += 8;
[...]
}

D'après la documentation du format mpeg4, l'atome correspondant à l'ajout d'une illustration au fichier est constitué de :

  • la taille de l'atome (4 octets),
  • l'étiquette (4 octets),
  • la taille de la donnée qui suit (8 octets),
  • la donnée.

Pour exploiter la vulnérabilité, il faut que la taille de l'atome soit égale à 1 et que la taille de la donnée (à la position suivant le tag 'covr') soit égale ou supérieure à 0xFFFFFFFF. La lecture du fichier modifié provoquera un plantage du service mediaserver

%F/libc (13326): Fatal signal 7 (SIGBUS) at 0x41414141 (code=1), thread 13340 (Binder_1)
%I/DEBUG ( 271): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
%I/DEBUG ( 271): Revision: 'p2d0'
%I/DEBUG ( 271): pid: 13326, tid: 13340, name: Binder_1~>>> /system/bin/mediaserver <<<
%I/DEBUG ( 271): signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 41414141
%W/NativeCrashListener( 989): Couldn't find ProcessRecord for pid 13326
%I/DEBUG ( 271): r0 41414141 r1 b58cf180 r2 ffffffff r3 41414141

Recommandations

Il est recommandé d'attendre qu'un correctif de sécurité soit disponible afin de corriger ces vulnérabilités et de se référer à l'alerte publié par le CERT-FR (voir documentation) pour appliquer des mesures préventives en attendant la disponibilité d'un correctif.

Il est possible de vérifier si un appareil est vulnérable en utilisant l'application "StageFright Detector App" disponible sur le "Google Play Store".

Documentation


3 - Rappel des avis émis

Dans la période du 03 au 09 août 2015, le CERT-FR a émis les publications suivantes :

  • CERTFR-2015-AVI-325 : Multiples vulnérabilités dans Xen
  • CERTFR-2015-AVI-326 : Multiples vulnérabilités dans Wordpress
  • CERTFR-2015-AVI-327 : Multiples vulnérabilités dans les produits Huawei
  • CERTFR-2015-AVI-328 : Multiples vulnérabilités dans le noyau Linux Red Hat
  • CERTFR-2015-AVI-329 : Vulnérabilité dans Mozilla Firefox
  • CERTFR-2015-AVI-330 : Multiples vulnérabilités dans PHP
  • CERTFR-2015-AVI-331 : Multiples vulnérabilités dans le noyau Linux Debian

Gestion détaillée du document

10 août 2015
version initiale.
Dernière version de ce document : http://cert.ssi.gouv.fr/site/CERTFR-2015-ACT-032

CERT-FR
2015-08-10
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-04-28