Sur les publications en sécurité informatique et l'anonymat

Pour raviver mon blog, voici un article des plus narcissiques. Je vous aurais prévenu...

Je tiens tout d'abord à contredire les rumeurs qui pèsent actuellement sur mon existence : Nan, je ne suis pas mort ! Et non, je ne suis pas tenu au silence par mon nouvel employeur...

C'est juste que la découverte de nouveaux domaines (SCADA et autres domaines de l'informatique industrielle) ne me permet pas, pour l'instant, de réaliser des articles satisfaisants qui puissent avoir un quelconque intérêt pour mes trois lecteurs référencés.

En tant que maître persiffleur, je rajouterais d'ailleurs que je ne suis pas payé, moi, à faire de la veille ou de la R&D... (calme toi News0ft, c'est juste un effet de manche pour avoir des remarques dans mon blog)

J'en profite pour réagir à la réponse d'Hervé à Cédric au travers la lettre mensuelle de sa société (mes trois lecteurs comprendront. Les autres ne me lisent pas de toute façon !! Je tiens à devenir de plus en plus cryptique au fil de mes articles. C'est un moyen de passer à la prospérité dans quelques siècles parait-il ! ;-))

Bon, je reprends. Je disais que j'étais d'accord avec Hervé sur le mythe bidon de la double-vie des professionnels de la SSI. Il alimente depuis des années les légendes à la greyhats qui pourrissent notre profession et l'empêche de devenir véritablement adulte.

Alors, me direz-vous, pourquoi écrire sous un pseudo et ne pas m'afficher librement et assumer mes écrits ??

Bonne question n'est-ce pas ! Ma réponse est toute simple : tout article, aussi savant et brillant soit-il fournit des renseignements précieux sur les domaines que ne maîtrise pas son auteur ! Lorsque cet auteur est responsable SSI ou acteur SSI majeur d'une entreprise, il s'agit d'informations de première main pour tout assaillant.

Dans le même registre, Il m'arrive encore d'aller chercher (sur google ou auprès du client avec une technique de relation sociale pour ingénieur [j'adore cette traduction littérale, vue sur intranet !!]) la liste des sociétés de la profession qui se vantent d'avoir auditer ou sécuriser un futur client. J'aime alors prendre le temps de référencer les systèmes et les thèmes qui semblent ne pas être la tasse de thé des dites sociétés. Vous devez avoir déjà essayer, le recoupement est souvent édifiant...

D'ailleurs, lorsque l'on connait les penchants risibles de certaines écoles en SSI pour d'étranges systèmes d'exploitation supposés ultra-sûrs, mais absolument pas déployés dans le monde réel (je ne donne pas de nom, les cibles sont trop évidentes...), il y a de quoi s'amuser de nombreuses années encore, en écoutant les réunions des professionnels de la profession. Ce n'est pas News0ft qui va me contredire...

Voila, pour ce soir. C'est court, mais c'est un blog et j'ai plein d'autres trucs à faire (récupérer des heures de sommeil, par exemple). J'espère simplement que mes trois lecteurs comprennent désormais mieux la raison de mon semblant d'anonymat. Et oui, ce n'est peut être pas uniquement de la pure schizophrénie (tiens, un mot de plus de trois syllabes. Je m'améliore ;-))

La "récente" évolution des systèmes SCADA

Jusqu'au milieu des années 90, les systèmes SCADA n'ont que peu évolués. Présents dans toute l'industrie, surveillant les chaînes de montage, les centrales électriques, les systèmes de production et de distribution d'eau, gaz ou pétrole, les installations portuaires... ces systèmes spécialisés étaient bâtis à partir de mini-calculateurs dédiés (les PLC : programmable Logic Controler) chargés de récolter l'information et de l'envoyer sur des liaisons de 1200 bauds à des terminaux distant RTU (Remote Terminal Unit), eux même controlés par un MTU (Master Terminal Unit). Ces RTU ne possédaient alors aucune intelligence et n'avaient aucune interaction avec d'autres systèmes d'information.

Alors, que s'est-il passé pour que ces systèmes isolés, compartementalisés deviennent des architectures réseaux classiques qui utilisent des liaisons T-1, de l'Ethernet, du wifi et même des liaisons Internet non-protégées ?

Ma théorie est que ces systèmes ont souffert des mêmes causes qui ont permis à nos SI de la Défense de devenir vulnérables aux maux de l'Internet : la réduction des coûts et la volonté des hauts responsables d'avoir une vue temps réel du terrain (le tableau de bord avec des camemberts qui clignotent en continu) !!

L'évolution technologique majeure s'est passée au niveau des RTU. Ces équipements dédiés et monofonctions se sont peu à peu transformés en logiciels multifonctions chargés sur des systèmes d'exploitation grand public (MS Windows, Linux). Ce changement a permis de réduire considérablement l'implémentation de ces RTU qui se sont dotés des éléments logiciels suivants :
- les DPA (Data Processing Applications) permettant la reprogrammation du RTU et l'ajout d'une GUI possèdant un accès utilisateur.
- les DCA (Data Collection Applications) permettant l'intégration de données collectées sur de nouveaux contrôleurs
- une base de données...

Cette évolution a cependant eu un cout caché phénoménal : ces systèmes de contrôle industriels, hier isolés et utilisant des équipements propriétaires, sont désormais vulnérables à tous les maux qui visent nos simples PC.

Et oui, l'une des premières surprises que j'ai eu en découvrant les systèmes SCADA a été de contempler le célèbre logo "TUX" sur un boitier RTU qui surveillait les vibrations de la pompe d'un système de refroidissement ultra-sensible. De tels boitiers sont généralement disséminés sur l'ensemble d'un site et sont interconnectés via un réseau Ethernet partagé ou un réseau wifi.

Même si je suis loin d'être un adepte de la grande peur de l'après 9/11, j'ai quand même eu quelques sueurs froides lorsque j'ai commencé à étudier la dizaine de protocoles utilisés par les systèmes SCADA : ces protocoles n'ont pas du tout été pensés pour partager un réseau d'entreprise avec d'autres systèmes d'information. Je me suis alors pencher sur les RTU, et la situation m'a paru désespérée : ces systèmes, bien que bâtis sur du MS Windows classiques ou du Linux, ne sont jamais patchés et il existe même des clauses constructeurs qui interdisent toute mise à jour du système d'exploitation !

Mais, je garde le meilleur pour la fin : la "mentalité particulière" des ingénieurs de l'industrie. En tant que consultant Infosec, on trouve parfois difficile de persuader un ingénieur IT de mettre en place un système de bascule de serveurs afin de pouvoir patcher (et rebooter pour MS Windows) un système critique. Avoir la même démarche avec un ingénieur industriel est une mission impossible. En effet, la mise à jour d'un RTU signifie souvent l'arrêt d'une pompe d'une central électrique ou la fermeture d'un pipeline. Vous imaginez les centaines de millier d'euro perdus à chaque Black Tuesday !!

Bref, la sécurisation d'un système de contrôle industriel passe essentiellement par la conception du système lui-même et surtout par une énorme campagne de sensibilisation des ingénieurs industriels. Et là, nous avons du boulot pour une bonne dizaine d'années...

Voila pour une petite mise en situation de l'infosec pour systèmes SCADA. Si cela intéresse l'un de mes trois lecteurs, je vais continuer et réaliser des descriptions plus détaillées. ;-)

Changement de disciplines en vue...

Ayant changé de job au début du mois, je n'ai actuellement plus la possibilité de pratiquer le live forensique et la réponse aux incidents. D'où ce silence assez long...

J'avoue qu'il m'est même venu à l'esprit de fermer ce blog après le SSTIC (évènement qui a sonné le glas de mon anonymat... pour ceux, bien sûr, qui se donnent la peine de lire un papier jusqu'à sa 26e page !)

En fait, je ne désespère pas de trouver un jour une mission intéressante dans ces domaines et je vais d'ailleurs m'y employer dès la semaine prochaine (reste à faire une prés' sur le sujet ce weekend)

En attendant cet heureux jour, je vais m'adonner aux missions classiques des consultants Infosec : audit, pentests, stratégie de sécu, architectures, plans de progrès ou de changement... Rien de bien passionnant, encore que cela faisait des années que je n'avais pas pratiqué. Je m'efforce tant bien que mal de placer de temps à autre mes idées et ma touche personnelle, bien que pas grand chose puisse être inventé dans ces disciplines usées jusqu'à la corde.

Après quelques discussions, je crois avoir trouvé un domaine intéressant dans le domaine de l'audit et du pentest : les systèmes SCADA. Nous touchons là un territoire qui m'était complètement inconnu voila encore quelques semaines. C'est en fait à des kilomètres du serveur Oracle en back-office qui semble faire saliver les premières années Epitec (ils se reconnaitrons).

Après avoir pris quelques avis, il semble qu'il s'agisse d'un territoire quasiment vierge pour l'Infosec. Le fait est qu'un certain nombre d'expériences en la matière se sont mal déroulées. Il coure sur le sujet des légendes très croustillantes : redémarrage complet des chaînes de production d'une usine automobile après un scan nmap mal ficelé, infrastructures critiques isolées pour l'éternité de toute téléadministration et de toute mise à jour, suite à un simple connect' mal placé...

Les systèmes SCADA se révèlent être un sujet super épineux, que cela soit par la difficulté des pentests ou encore par la paranoïa outre-atlantique dont ils font l'objet (Homeland Security...). Il convient donc de les aborder avec un oeil neuf. Cela tombe bien, je me suis écarté des pentests et des audits depuis suffisamment longtemps pour essayer de tenter d'autres approches.

La pratique du forensique et la chasse aux hackers m'ont appris la furtivité, qualité qui manque trop souvent aux pentesteurs de base qui ne jurent que par les scans de vulnérabilités et la grosse artillerie... (je vais encore me faire des amis ;-))

Pour débutter en la matière, il faut que je trouve du temps pour la mise au point d'un scanner passif (sniffer+reconnaissance de motifs sur bannières et autres infos clés) qui me coute moins de 10.000$, afin de répertorier rapidement, mais grossièrement les systèmes les plus vétustes.

Le plus difficile, sans doute, sera de trouver des clients pour ce genre de manip', d'autant qu'en Europe ces systèmes ne soient pas légions. Il est vrai que les techniciens européens coutent beaucoup moins chers que leur homologues étasuniens et que, par conséquent, la téléadministration de systèmes critiques n'est pas très répandue.

Au final, cela reste tout de même un beau sujet pour un stagiaire désirant s'essayer aux micro-controleurs et aux protocoles SCADA ou encore un sujet exotique pour le prochain SSTIC ! Avis aux amateurs...

Deux pistes sérieuses pour le live forensique

Chose promise, chose due, voici enfin un article faisant la preuve de mon intérêt constant pour le live forensique.

Le RFC 3227 - Guidelines for Evidence Collection and Archiving recommandait, dès février 2002, que le premier élément de preuve à récolter dans le cadre d'une enquête forensique était la mémoire physique (la RAM) du système suspecté. Si le recueil de cette mémoire physique est peu à peu rentrée dans les procédures forensiques et de réponse aux incidents (IR), son analyse, quant à elle, reste problématique.

Lorsque j'ai quitté mon équipe IR voilà trois mois, cette analyse n'était réalisée qu'en cas de besoin impérieux de retrouver des mots de passe, adresses IP, adresses de messagerie ou URL, permettant de confondre un suspect contre lequel de fortes présomptions existaient. Pour cela, le binôme IR utilisait les outils strings et grep pour retrouver de tels éléments de preuve. L'analyse la plus "poussée" consistait alors en une exploration rapide sous bintext des mégaoctets de l'image de cette mémoire physique, afin de relever les chaînes de caractères ASCII pouvant avoir une quelconque utilité.

L'été 2005 avec son challenge forensique du DFRWS (Digital Forensic Research Workshop) a marqué une révolution pour les chercheurs INFOSEC de la planète qui se sont pris d'intérêt pour le live forensique. Sur le terrain, c'est en fait la tendance lourde des codes malveillants (virus et rootkits et autres malwares de dernière génération) à empêcher leur analyse statique via les techniques anti-forensiques qui ont amené les équipes IR et les enquêteurs forensiques à vouloir se doter d'outils puissants pour analyser efficacement cette mémoire physique, seule détentrice d'éléments non chiffrés (non-cryptés, pour utiliser un anglissisme) de ces malwares.

L'année 2006 a vu l'apparition publique des premiers outils d'analyse live fonrensique. Les uns bâtis sur l'accès à l'objet \Device\PhysicalMemory, les autres s'appuyant sur le contenu du fichier crash dump généré par les systèmes Windows après un BSoD (Blue Sreen of Death). Deux problèmes techniques sont actuellement à prendre en compte pour le choix d'une de ces familles d'outils :
- à partir de la sortie du service pack 1 de MS Windows 2003 (printemps 2005), l'objet \Device\PhysicalMemory n'est plus accessible à partir du mode utilisateur
- à l'exception de Windows 2003, les systèmes MS Windows génèrent par défaut un crash dump de taille insuffisante (il en est de même pour Windows Vista RC1)

Après avoir fait le tour de quelques outils, ma préférence va à la famille bâtie sur les crash Dump. Il est vrai qu'elle convient d'avantage à une équipe IR qui peut se permettre d'imposer de grandes images crash dump aux serveurs MS Windows sous sa responsabilité, plutôt qu'à un enquêteur forensique envoyé auprès d'un quelconque système suspect. Voir pour cela l'article de la base de connaissance Microsoft ici.

Afin d'affiner mon expérience en la matière, je pense à très court terme (dès la semaine prochaine) travailler sérieusement sur les deux pistes suivantes :
- l'outil Kernel Memory Space Analyzer de Microsoft
- une extraction à l'aide de l'outil LiveKD.exe et sa commande .dump /f fichier-dump.dmp à partir d'un système distant ou d'un système dont la fonction ou la fragilité le rendent impossible à crasher.

D'ici là, il me reste à préparer le TOEIC que je passe à la fin de cette semaine ! ;-)