Back to Basics -5- Patchez Patchez Patchez !

Back to Basics -5- Patchez Patchez Patchez !

Autopsie d’un piratage au FBI…

 

Comme promis voici l’autopsie du piratage d’un ordinateur du FBI en septembre dernier. Comment peut-on pirater un ordinateur d’une des entités les mieux protégées
au monde ? Quels sont les points faibles trouvés et comment les repérer et les corriger dans nos organisations ?

antisec1-copie-1.PNG

 

Tout d’abord voyons comment le piratage a été annoncé et comment le FBI a réagi.

 

« Dans les articles qui circulent aujourd’hui sur le net, les pirates affirment avoir pénétré un ordinateur portable d’un agent spécial du FBI et avoir copié des
données présentes sur son disque. Les pirates affirment qu’ils ont recopié un fichier de type base de données contenant des informations sur l’identité de plus de 12 millions d’appareils mobiles
d’Apple et leurs utilisateurs. »

 « Parmi les informations stockées sur la base de données, les pirates indiquent qu’il s’agit d’une liste de codes uniques UDID qui identifient chaque appareil
d’Apple, y compris les iPhones et iPads avec le nom d’utilisateur, les adresses complètes, les numéros de téléphone cellulaire. » 

 

Il s’agit donc apparemment d’une brèche sur les données personnelles de possesseurs de produits Apple. Plusieurs questions se posent: est-ce que Apple (société
Américaine) diffuse les identifiants de tous ses clients au FBI ou bien le FBI a-t-il constitué le fichier à l’insu d’Apple ? Comment les pirates ont-il procédé ?

 Le FBI a publié aussitôt une déclaration disant qu’il n’y avait «aucune preuve» du piratagé ou que de telles données aient été divulguées ou obtenues par
l’intermédiaire de l’agence.

antisec2.PNG 

AntiSec (faisant partie du mouvement plus large des Anonymous), le collectif qui a déclaré l’exploit, a dit « il n’y aura pas d’autres détails à propos de la
manière dont on a obtenu ces données. » 

Voici leur page FB:

https://www.facebook.com/pages/AntiSec/174945179234154

 

Ce qui est sûr c’est que le fichier existe bel et bien puisque j’ai pu le télécharger sur le net quelques minutes après l’annonce et vérifié
que mon UDID ne figurait pas dans la liste. Cette liste représentant les personnes « suivies » par le FBI, c’est plutôt une bonne nouvelle ! J’ai testé avec pas mal d’amis en France qui ont des
Ipads ou des Iphones et aucun ne figure sur la liste. Il semble donc que cette liste vise des personnes vivant aux USA et donc tracés par le FBI, ce qui est plutôt logique le FBI étant restreint
à l’activité sur le sol Américain.

Voici l’extrait qui concerne mon iPad:

 

fbi1.PNG

 

Le fichier qui ne listait que 2 millions de lignes -en ayant caviardé les noms et adresses- n’est plus téléchargeable, mais voici un lien pour vérifier vous-mêmes
que votre UDID n’est pas dans la liste: 

http://thenextweb.com/apple/2012/09/04/heres-check-apple-device-udid-compromised-antisec-leak/

 

Pour connaître votre UDID il suffit d’aller dans iTunes avec votre smartphone connecté et de cliquer dans le numéro de série qui apparaît dans les paramètres
généraux:

udid.PNG

L’UDID apparaîtra à la place du numéro de série. Il suffit ensuite de le saisir dans le site en question.

 

Plusieurs commentaires: Le fait de connaître l’identifiant unique d’un appareil permet de suivre les déplacements du propriétaire (ou de celui qui l’utilise) à
travers les connexions Wifi, 3G ou GPS, comme cela est démontré ici pour mon iPad.

 

GPS-paris1.png

C’est donc logique que le FBI maintienne une telle base permettant des recoupements avec identités, adresses et numéros de téléphone.

Le fait que Antisec publie cette liste démontre que même le FBI peut être piraté et donc que notre niveau de sécurité réelle est à revoir.

 

Intéressons -nous donc au mode opératoire. Comme toujours lorsque les données sont précises lors d’un inforensics (autopsie
post-incident de sécurité informatique) elles sont authentiques:

 

During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from
FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some
files were downloaded from his Desktop folder one of them with the name of « NCFTA_iOS_devices_intel.csv » turned to be a list of 12,367,232 Apple iOS devices including
Unique Device Identifiers (UDID)
, user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details
fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose.

A cette lecture il est clair que le FBI a vraiment été piraté malgré leurs démentis…

Quelle est donc cette faille Java que les Antisec ont utilisé pour avoir accès à un ordinateur du FBI ? Il est exclu que le pirate se soit introduit dans les
locaux. Il est possible qu’un agent du FBI ait fuité l’information volontairement ou involontairement (voir l’épisode précédent sur mon blog de la divulgation des plans de l’Elysée).

 Le fait de donner le nom du portable, celui de l’agent et le nom du fichier trouvé montre bien que l’exploit a eu lieu. Qu’est ce que le « NCFTA » mentionné
dans le nom du fichier ?
Il s’agit
du 
National Cyber-Forensics & Training Alliance. Une organisation non gouvernementale http://www.ncfta.net qui traque le cybercrime et notamment l’usurpation d’identité.

 

ncfta.PNG

 

Clairement cet agent du FBI travaille en collaboration avec
cette agence dont l’initiative est soutenue par le gouvernement Américain: 
Regional Cyber Action Team and New York FBI
Office Evidence Response Team.

 

Voyons maintenant les étapes qui permettent d’exploiter cette faille avec Metasploit:

ara java exploit    

      On liste ensuite les options disponibles;

 ara-java-2-copie-1.png

On passe les paramètres et notamment le port à utiliser, ici le port 80 http ou bien on peut également utiliser le port 443 https avec un fake certificat généré

 ara java3

      On liste les payloads disponibles…

 ara java4

      On charge un payload et on indique les paramètres…

ara java5

      Le payload est paramétré…

ara java6

      L’exploit est lancé…

ara java7

            Bingo !

ara java8

      Un shell de commandes s’est ouvert sur la machine cible et permet notamment d’accéder au système de fichiers !

 

Cette vulnérabilité est due au final au fait que la classe AtomicReferenceArray ne
vérifie pas correctement si le tableau est un objet de type approprié. L’absence de patch permet l’attaque.

La plupart des attaquants utilisent cet exploit afin de distribuer des logiciels malveillants à des machines
cibles. Ce type d’attaque n’est pas détectée par la plupart des antivirus.

Elle affecte diverses plates-formes Windows, Linux et MacOS X et vous devez donc patcher
votre environnement d’exécution Java
afin de protéger vos systèmes contre ce type d’attaque. Les plug-in Java et d’autres plug ins s’executent notamment dans le navigateur en
autorisations « système ». Il faut donc non seulement patcher les systèmes mais également les plug-ins exécutés dans les navigateurs. 

 

Pour vérifier que les plug-ins du navigateur sont bien à jour j’utilise Qualys Browsercheck:

qualys browser check 

Il s’agit d’un logiciel en ligne gratuit disponible au lien suivant:

https://browsercheck.qualys.com/

Il existe d’ailleurs une version « entreprise » pour gérer plusieurs ordinateurs.

Encore une fois, il est clair que s’abstenir ou différer le fait de patcher est « criminel »! En effet, une fois un exploit publié et son patch
connu, les hackers vont faire un reverse engineering sur le patch pour remonter au code source, de ce que le patch corrige comme faille. Ensuite des sites comme Metasploit vont publier
un code d’attaque approprié aux machines non patchées. La suite est quasi enfantine puisque toutes les machines non patchées vont être sensibles à l’attaque. Le firewall ne protègera pas puisque
l’attaque sera « encapsulée » dans des ports autorisés (80 ou 443). L’IPS mal positionné, non plus, lors d’une attaque encapsulée dans un flux SSL (443) puisque ce flux sera chiffré donc non
visible de l’IPS. 

En résumé, une organisation qui omet de patcher ses systèmes y compris au niveau des navigateurs créé une opportunité importante et facile à exploiter de piratage.
Il s’agit clairement d’une enfreinte aux fondamentaux de la sécurité.