• La deuxième édition de la conférence Hack.lu s'est tenue du 19 au 21 octobre au Luxembourg.

• Compte-rendu au jour le jour de cette Hack.lu 2.0.

• MAJ 24/10/2006 : j'avions pas vu que les archives sont déjà en ligne.

• La première journée de la conférence Hack.lu fut consacrée aux ateliers.
• Ce fut la journée la plus frustrante des trois, ce pour plusieurs raisons dont certaines pas tout à fait indépendantes de ma volonté.
• Frustrante tout d'abord parce que n'ayant pu me libérer plus tôt, je fus contraint de prendre la route vers Luxembourg jeudi matin, ce qui, immanquablement, faisait passer la matinée à la trappe.
• Frustrante, ensuite, parce que l'atelier MetaSploit qui fut un temps programmé pour l'après-midi se tint finalement le matin.

• Arrivé sur site à 15h45, j'ai juste eu le temps de serrer deux/trois pognes ici et là avant de me précipiter à l'atelier “Tactical VoIP: VoIPhreaking by The Grugq” à 16h30.
• The Grugq, c'est un savant cocktail de compétences alliées à une bonne dose d'humour. Après avoir fait fuir deux personnes à l'aide d'un slide sur les failles XSS, on est entré dans le vif du sujet.

• Que nous a donc dit The Grugq ? Tout d'abord que la VoIP repose sur des protocoles que les moins de vingt ans pourraient presque ne pas connaitre, et qui ont hérité de la philosophie qui prévalait il y a dix/quinze ans sur le Net, à savoir que tout “le monde il est beau tout le monde il est gentil”, devise qu'un Bisounours ne réfuterait pas. Que donc, déjà, c'était mal parti d'un point de vue Sécurité.
• Après avoir rappelé les trois principales fonctionnalités qui rendent possible l'utilisation de la VoIP : signalisation, Transport de contenu et intégration au réseau filaire “classique”, The Grugq a détaillé pour chacun de ces fonctionnalités leurs angles d'attaque et leurs vulnérabilités.
• Côté signalisation, seul SIP a été abordé car ouvert, H.232 a été laissé de côté et décrit comme plus robuste car issu du monde des Telco, mais cauchemardesque pour ce qui est de l'interopérabilité entre stacks H.232 de constructeurs différents.
• Les différentes attaques ont ensuité été présentées pour chaque fonctionnalité à l'aide de quelques scenarii tels que redirection d'appels ou man-in-the-middle entre un appelant et un centre d'appels bancaire par exemple.
• Conférence plus qu'intéressante, mais là aussi frustrante : ce devait être un atelier et on ne mit pas les mains dans le cambouis. Une partie de l'auditoire resta donc sur sa faim en sortant de la salle, et cela tombait bien puisque l'heure du dîner approchait.

• Petite consolation après toutes ses frustrations : le wifi mis à disposition par les organisateurs de la conf était compatible avec les cartes Airport bridées aux seuls canaux 10 à 14, ce qui n'est pas le cas partout (sans vouloir dénoncer, disons que ce ne fut pas le cas du côté de Rennes en juin dernier…).
• Cette “série noire” n'était cependant pas terminée : les activités de l'aéroport de Luxembourg se prolongent jusque tard dans la soirée, ce qui est assez énervant quand on a une chambre avec vue sur les pistes et qu'on est pas fan d'avions plus que de raison ou que d'autres.

• Seconde journée.
• Bravo tout d'abord aux organisateurs pour leur choix du Novotel comme lieu d'accueil de la conférence. Et bravo au Novotel pour la qualité de cet accueil. Seul bémol : le confort tout relatif des chaises.
• Premier réflexe avant la reprise des débats : choper l'adresse MAC de la borne wifi et coller une petite règle ipfw pour valider qu'elle ne change pas trop. En d'autres temps et en d'autres lieux (“à l'Ouest, toujours plus à l'Ouest”, Tryphon Tournesol) cela sauva des vies…
• Second réflexe : mettre Snort à jour en 2.6.0.2, récupérer les signatures Bleeding-Edge qui vont bien et coller cette même adresse MAC dans le snort.conf pour surveiller d'éventuelles modifications via de l'ARP Spoofing (non, vérifier que Sid n'est pas encore dans la salle ne suffit pas… ) :

# arpspoof
#----------------------------------------
# Experimental ARP detection code from Jeff Nathan, detects ARP attacks,
# unicast ARP requests, and specific ARP mapping monitoring.
#  SID     Event description
# -----   -------------------
#   1       Unicast ARP request
#   2       Etherframe ARP mismatch (src)
#   3       Etherframe ARP mismatch (dst)
#   4       ARP cache overwrite attack
preprocessor arpspoof_detect_host: 192.168.1.235 f0:0f:00:f0:0f:00

• Tout est prêt, let's roll.

• Tout en validant que tout fonctionne bien, je prête une oreille attentive au discours d'introduction de Renaud Deraison.
• Celui-ci nous explique que si le nombre de vulnérabilités reste élevé, il y en a un bon paquet qui ne sont pas si utilisables que ça “dans la vraie vie”, qu'au contraire le nombre de failles exploitables à distance diminue et que par conséquent (loi de l'offre et de la demande) leur valeur financière augmente.
• Cette diminution s'explique par une meilleure sécurisation des systèmes d'exploitation, y compris ceux issus de la banlieue de Redmond. La tendance ainsi chez Microsoft n'est plus seulement de boucher les trous mais aussi de limiter les impacts d'éventuelles failles.
• Cela s'explique par des protections au niveau des processeurs (bit NX - No eXecute - chez Intel et AMD), au niveau des OS (PaX pour Linux, W^X pour OpenBSD notamment, ASLR pour Vista, très inspirée de ce qui existe dans les OS Libre/OpenSource), au niveau physique (BitLocker) et au niveau des compilateurs (ProPolice pour Linux/OpenBSD, /GS pour Microsoft).
• Même les applications Web (y compris 2.0) sacrifient à cette mode : on note l'utilisation préférée de framework plutôt que de langages de scripts purs, frameworks qui contrôlent et limitent mieux les actions et entrées des utilisateurs, notamment en filtrant le code HTML ou en utilisant des requêtes SQL et des procédures stockées.
• D'une manière générale, on préfèrera laisser la porte (entr')ouverte à une attaque DoS plutôt qu'à une prise de contrôle à distance.

• Présentation du projet Xebek.
• Qu'est-ce que Xebek ? Eh bien c'est l'utilisation de machines virtuelles Xen pour mettre en oeuvre des piéjacons (honeypots) à l'aide de Sebek quasiment indétectables (Techniques anti-pièjacons)
• L'objectif est de réduire la visibilité de Sebek par l'attaquant.
• Comment peut-on détecter Sebek ?
• En local, il est possible/facile de détecter Sebek, même depuis un compte non privilégié. En observant les stats Réseaux et en comparant le nombre d'octets transmis et la valeur stockée dans /proc/net/dev. Ensuite au niveau disque en observant le nombre d'octets écrits (Sebek génère beaucoup de données). Enfin, en scannant la machine à la recherche des modules cachés (linux-airt by madsys). Une fois détecté, il est relativement possible de désactiver Sebek (unsebek.c).
• En sniffant le réseau, on aura vite fait de remarquer le trafic UDP entre les clients Sebek et le démon sebekd sur le serveur qui centralise les logs.
• Enfin, il est possible de lancer de bonnes attaques DoS contre le démon sebekd.
• D'où l'idée de monter le pièjacon sur des machines virtuelles Xen : plus d'échanges réseau entre clients Sebek et serveur Sebek, partage de données via un espace mémoire partagé.
• Xebek reste cependant détectable à l'aide de certaines techniques et il reste donc des points à améliorer.

• Pour les prochaines pauses café, ne pas oublier de sortir un peu plus tôt, en tout cas plus tôt que certains, si l'on veut trouver à se mettre quelquechose sous la dent.

• Etat des lieux et état de l'art en matière de malware

• Koen nous avait déjà gratifié l'an dernier d'une conférence sur le facteur humain en matière de sécurité.
• Cette conférence s'inscrit dans la lignée de cette réflexion et nous rappelle que derrière tout clavier il y a un humain.

• Une fois encore, bravo aux organisateurs. Les déjeuners sont pris au Sofitel voisin du Novotel sous forme de buffet entrées/sandwiches/dessert, formule qui permet de faire connaissance.

• “Lightning talks” signifie “Rump Sessions” dans le dialecte local.
• On aura ainsi droit à l'analyse d'une machine à voter néerlandaise par Hannes Mehnert et Andreas Bogk et une présentation très succinte de “A new approach to Cybercrime: the Hacker's Profiling Project (HPP)”.

• En l'absence de K. Finistère, Thierry Zoller a présenté des techniques d'exploitation des failles du protocole Bluetooth avec brio.
• Nous avons ainsi eu droit à une démonstration de prise de contrôle d'un Mac via Bluetooth et une PoC d'un ver Bluetooth.
• En parallèle de leurs recherches Sécurité Bluetooth, Thierry et Kevin ont cité quelques tests in vivo, notamment de distance, avec une record de 788 mètres entre une antenne et un récepteur (téléphone en l'occurence) réalisé par Kevin.

• Je me dois d'être honnête : durant cette conférence, j'étais plus occupé à chercher un webmail en HTTPS qu'à écouter.

• Voir remarque ci-dessus sur les pauses café du matin…

• Très bonne conférence sur IPv6 et la sécurité.
• Ont été notamment cités les usages déjà courants dans la communauté dite “BlackHat” d'IPv6 pour, dans le désordre : traverser des pare feux qui ne comprendraient que l'IPv4, scanner des machines, monter des tunnels, etc.
• Ont ensuité été cités les principales problématiques amenées par IPv6 lorsque son usage sera généralisé (qui a rigolé ??). En fait, les scans seront moins faciles mais pour le reste, le paysage devrait rester largement inchangé à ceci près que les serveurs DNS verront leur poids accru dans un environnement IPv6, et redeviendront donc des cibles de choix.
• Au niveau pare feu, il n'y aura plus de NAT mais il faudra laisser passer plus de trafic ICMP et, cerise sur le gâteau, IPSEC rendra toute analyse de contenu caduque et inutile.
• On devrait peu à peu voir disparaitre les vers réseaux purs, les vers SMTP survivront et les vers IM et P2P feront leur apparition.

• Je me dois d'être une fois de plus honnête : cette conférence était d'un niveau trop au-dessus de mes compétences et trop éloignée de mes centres d'intérèt.

• Quand un ingénieur du RIPE fait une conférence sur la sécurité des serveurs DNS, ont dit “Ahhhhh !!!”.
• Quand il met en garde contre les attaques par réflexion et contre les resolvers “ouverts” (équivalent DNS des open relay SMTP), qu'il attire notre attention sur l'utilisation de requêtes spoofées par des botnets, on se dit : “Hummmm !!!!!”.
• Mais quand ça se conclut par “use DNSSEC”, on dit “ohhhhh….”.

• A l'origine, il devait y avoir un Capture The Flag challenge comme celui de l'an dernier. Puis non. Finalement, un p'tit monsieur dont la pilosité faciale n'est pas sans rappeler celle de Pierre Vassiliu ou d'un Rigel a relevé le défi et a concocté un challenge de rechange. Pour planter le décor, notez au passage que le p'tit monsieur en question fait partie des organisateurs des CTF de DefCon et n'en est donc pas le dernier.
• Le but du CTF est limpide comme le règlement d'un challenge Securitech : trouver 7 clefs et les envoyer au CTF-master pour validation. Le premier qui trouve les 7 tokens a gagné.
• Le CTF s'appuie sur un serveur Web et les inscriptions donneront lieu à quelques épreuves non prévues par l'organisation. la page d'accueil mentionnait pourtant bien : “DON'T BREAK THE SERVER PLAY THE GAME”, ce que certains ont du traduire par “Compte là dessus, bois de l'eau fraîche” et d'autres par “Jawolh Herr General”.
• Pour valider chaque niveau il faut envoyer la clef par mail à l'organisateur.
• A 18h15, la page du site annonce “Game started !”.
• A partir de là, “Que faire ?” comme l'aurait dit Vladimir Ilitch Oulianov
• La pertinence et la portée de cette question sont inversement proportionnelles à ses compétences techniques dès lors qu'on peut raisonnablement penser qu'il y a du reverse engineering dans l'air, de l'analyse de code (le site étant en Ruby le pire - python - était à prévoir) voire de la cryptographie appliquée.
• Pas de panique cependant, les envois de clef se font par mail, la plupart des exploits se feront via le réseau : ne pleure pas Jeannette, tcpdump et ethereal n'ont pas été inventés que pour coller de belles icônes sur le bureau de ton Mac.
• Cecit dit, il se fait tard et surtout, il se fait faim.

• Je ne remercierai sans doute jamais assez Yann ni Fred pour leur invitation au dîner du jeudi soir à la Coque.
• A noter qu'en lieu et place de cacahouètes, certains se goinfrent des installations de FreeBSD à l'apéro…
• A l'occasion de ce moment très convivial, le Saint Thomas qui sommeille en moi a pu vérifié de visu que certaines rumeurs persistantes ne sont pas des légendes et que certains mangent vraiment beaucoup.

• Cette troisième et dernière journée fut riche, très riche. Bref, l'apothéose.
• Malheureusement, occupé comme je l'étais à suivre le CTF à distance mais en direct, l'attention prètée à certaines interventions en a pâti…

• Pendant que certains dorment, d'autres travaillent. C'est ainsi que la team Bisounours remporte le challenge aux alentours de 06h00 du matin (soit 03h13m37s en heure l0c4l3).
• Le Grand Jeu pouvait alors commencer…

• Quelqu'en soit le sujet, on ne rate pas une conférence de Mr Postfix/TCP Wrapper/SATAN, et j'en oublie sûrement.
• Au menu du jour : l'effacement de fichier sécurisé sous Unix. Où l'on apprend à se méfier des systèmes de fichiers journalisés, des caches et autres joyeusetés qui rendent parfois plus qu'aléatoire l'effacement d'un fichier. Moralité : use encrypted file systems & forget your keys !

• S'il faut se méfier des blondes, il ne faut pas pour autant se fier aux brunes… Sous ses allures ingénus, Lisa Thalheim a remporté un p'tit challenge 'Hack this box' organisé par un des sponsors de la conférence. Et ce en 6 minutes de moins et toute seule que la Red Team.
• Auparavant (chinois) elle nous présente les problématiques de sécurité au sein des grilles de calcul et des applications distribuées.

• Ces deux-là nous avait présenté la veille leur analyse d'une machine à voter électronique.
• Aujourd'hui ils nous présentent une méthode et un outil d'analyse du trafic réseau qui ressemble tout à la fois à NetFlow et à Ethereal dans sa syntaxe.
• Grosso modo l'idée est de décomposer le trafic en objet que l'on peut alors traiter et manipuler unitairement.

• Laurent et Franck se sont amusés à modifier des drivers wireless de manière à rendre invisibles des hotspots.
• Ils nous en font la preuve par la pratique.

• Pendant la pause déjeuner, certains s'éclipsent pour ramener de Luxembourg et de ses banques quelques photos souvenirs tandis que d'autres travaillent plus que de raison…

• Au menu des Rump Sessions du jour, Cédric Blancher qui ne présente ni arp-sk ni “son” lapin wifi mais comment Skype peut être utilisé pour construire un sacré botnet.
• Puis annonce de la prochaine édition de la Fast Software Encryption conference, un évènement entièrement dédié aux algorithmes de chiffrement symétrique. Bon, vu et dit comme ça ça peut laisser perplexe, mais quand on lit que le comité de programmation comprend entre autres Nicolas Courtois, Antoine Joux ou Serge Vaudenay, on se dit que ça peut valoir le coup de se déplacer…

• Certains ont peut-être eu l'occasion d'assister aux conférences de Krzysztof Zaraska, notamment aux LSM 2002 de Bordeaux. Et ils n'auront pas oublié son petit côté “Docteur Folamour”. Fabio n'est pas polonais mais son anglais m'a irrésitiblement fait penser à celui de Krzysztof. Je dis ça sans hargne ni mépris, étant donné mes propres exploits dans la pratique de la langue de Shakespeare.
• Cette plaisanterie mise à part, Fabio a présente le projet Laissez Faire Island et tout ce qu'il peut apporter à la préservation de l'anonymat sur Internet.
• Fabio constate l'utilisation en constante augmentation de Tor. En gros ça donne ceci :

• Il termine en citant le projet Vidalia.

• La fatigue se fait un peu sentir. Je sors me détendre un peu les jambes.

• Il règne une certaine animation dans le couloir : il semblerait que des bisounours très en forme se fritent (belges) et se frottent à des Germains rouges.
• Le site du challenge fait momentanément les frais de cette agitation :

• Allez savoir pourquoi, le CTF qui comptait 7 étapes en affichent désormais 8 puis 9…

• Le design devient au passage très “Web 2.0”.

• Dans le même temps, on note une certaine fébrilité sur le réseau : ça broadcaste pas mal…

• Le titre de cette intervention est quelque peu “mensongère” puisque Google sera bien utilisé pour illustrer le thème “anything is on the web”.
• Comme l'a dit le speaker : “stop downloading like idiots, don't use P2P”.
• Bref, une très belle et bonne leçon de “Google & other search engines hacks”.

• Pour conclure cette édition 2.0 de la Hack.lu en BOTé, Laurent Oudot que tout le monde connait (ou pas…) nous a gratifié de quelques trucs et astuces qu'un de ses copains utilise pour user et abuser des moteurs de Google et Yahoo! pour le fun et le profit.

• Je sais, c'est un sale défaut que d'être curieux mais c'est parfois très tentant de regarder ce qui se passe dans les coulisses d'une conférence Sécurité.
• Ci-dessous, quelques paquets “trouvés” dans les airs durant la Hack.lu.

• Tiens, quelqu'un tchatte pendant les confs :

Oct 20 11:18:33 localhost snort: [1:2001682:5] BLEEDING-EDGE Policy MSN IM Poll via HTTP
<snip>
Oct 20 11:23:46 localhost snort: [1:2001674:2] BLEEDING-EDGE Proxy POST Request 
Oct 20 11:23:47 localhost snort: [1:2001674:2] BLEEDING-EDGE Proxy POST Request 
Oct 20 11:23:49 localhost snort: [1:2001674:2] BLEEDING-EDGE Proxy POST Request 
Et caetera ad nauseam...

• L'arroseur arrosé, une vieille histoire pourtant…

CVR 2 0x0409 winnt 5.1 i386 MSNMSGR 6.0.0602 MSMSGS guillaume@sky.fr
POST http://207.46.107.56/gateway/gateway.dll?SessionID=881200207.17625 HTTP/1.1
Accept: */*
Accept-Language: en-us
User-Agent: MSMSGS
Host: 207.46.107.56
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Pragma: no-cache
Content-Type: application/x-msn-messenger
Content-Length: 30

• Faudra juste m'expliquer pour mon Mac est insulté (winnt 5.1 i386) au passage…

• Only the paranoid survive…

Oct 20 11:38:12 localhost snort: [1:2002952:2] BLEEDING-EDGE POLICY TOR 1.0 Inbound Circuit Traffic
Oct 20 11:38:12 localhost snort: [1:2002953:2] BLEEDING-EDGE POLICY TOR 1.0 Outbound Circuit Traffic
Oct 20 11:38:12 localhost snort: [1:2001728:4] BLEEDING-EDGE POLICY TOR 1.0 Client Circuit Traffic
<snip>
Oct 20 12:15:42 localhost snort: [1:2002951:2] BLEEDING-EDGE POLICY TOR 1.0 Status Update
Oct 20 12:15:54 localhost snort: [1:2002950:2] BLEEDING-EDGE POLICY TOR 1.0 Server Key Retrival

• Only the paranoid survive, still…

Oct 20 11:47:31 localhost snort: [1:2003020:5] BLEEDING-EDGE POLICY TLS/SSL Encrypted 
Application Data on Unusual Port

• Eh, le CTF est pas commencé !

Oct 20 12:13:30 localhost snort: [122:19:0] (portscan) UDP Portsweep {PROTO255} 
192.168.1.x -> 192.168.1.1

• A la recherche du serveur SSH perdu ?

Oct 20 16:38:37 iBook snort: [1:2001219:13] BLEEDING-EDGE Potential SSH Scan
Oct 20 16:38:37 iBook snort: [1:2003068:1] BLEEDING-EDGE Potential SSH Scan OUTBOUND
Oct 20 16:40:04 iBook snort: [1:2001219:13] BLEEDING-EDGE Potential SSH Scan
Oct 20 16:40:04 iBook snort: [1:2003068:1] BLEEDING-EDGE Potential SSH Scan OUTBOUND

• Le challenge est lancé… Nmap aussi on dirait :

Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:636
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:636
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:1723
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:1723
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:25
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:113
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:113
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:23
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:23
Oct 20 16:56:20  [122:1:0] (portscan) TCP Portscan {PROTO255} a.b.c.d -> 192.168.1.235
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:443
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:443
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:21
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:21
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:389
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:389
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:27491
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:27491
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:30119
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:30119
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:47162
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:47162
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:23652
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:23652
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:50291
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:50291
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:36461
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:36461
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:27767
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:27767
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:46671
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:46671
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:36150
Oct 20 16:56:20  [1:2000545:3]  SCAN NMAP -f -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:36150
Oct 20 16:56:20  [1:2000537:3]  SCAN NMAP -sS  {TCP} a.b.c.d:50326 -> 192.168.1.235:59165

• Le moins qu'on puisse dire est que ça manquait un peu de finesse…
• Le lendemain, une autre équipe remettait le couvert tandis que l'équipe a.b.c.d. se laissait aller à nmaper un peu au-delà du serveur du CTF.

• Attardons-nous un peu sur cette équipe a.b.c.d en plein travail.
• Au bout d'un moment, il s'est passé quelque chose sur le port TCP 666 du serveur 192.168.1.235 :

AUTH:team2:Claus
OK
bacon:........................

• J'avoue que je n'ai pas tilté tout de suite et qu'il m'a fallu plusieurs relectures de la page d'accueil de la conférence pour comprendre le pourquoi du “bacon”.
• Ce qui me rassure, c'est que notre équipe a.b.c.d a poireauté un certain temps aussi.

• Mais au final, il se passe quelque chose sur le port 4455/tcp :

ls;
touch /tmp/ttt;
chsh /bin/sh;
chsh: unknown user: /bin/sh
chsh -s /bin/sh;
chsh: /usr/sbin/nologin: curre
chsh -s /usr/local/bin/bash;
chsh: /usr/sbin/nologin: current shels /;
COPYRIGHT
bin
boot
cdrom
compa
cd /home
ls
breakme
ctf
hackerjoe
kenshoto
ls -l
total 124
drwxr-xr-x  2 breakm3
drwxr-xr-x  2 team4      tea
ls -R
ls: ctf: Permission denied
ls: team21: Permission denied

• Il y aurait même de la triche dans l'air que ça m'étonnerait pas :

cd /home
ls -l stage7
total 16
-rw-r-----  1 root  
ls
cd stage7
ls
key
stage7
date
Sat Oct 21 07:03:36 EDT 2006
date --help
date: illegal option -- -
usage: date [-jnu] [-d dst] [-
date Sat Oct 21 07:03:36 EDT 2date: illegal time format
usage: datdate "Sat Oct 21 07:03:36 EDT date: illegal time format
usagtime 

• A cette heure en effet une autre team avait gagné le challenge.
• Une étape est franchie dès lors que l'équipe arrive à se ménager un accès SSH au serveur :

id
uid=1005(team2) gid=1100(teamssh
ls
ls /
COPYRIGHT
bin
boot
cdrom
compa
exit
ls /
COPYRIGHT
bin
boot
cdrom
compacd /tmp
echo 'import os' > .x2
echo 'out=os.popen("chmod +s /echo >> .x2
cat .x2
import os
out=os.popen("chmod /usr/local/bin/python.hack .x2ls -l /bin/sh
-r-sr-sr-x  1 root  wheel  106/bin/sh
id
uid=1005(team2) euid=0(root) g
chmod -s /bin/sh
cd /root/.ssh
ls
known_hosts
cat /etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.68 for
# RhostsRSAAuthentication
pwd
/root/.ssh
echo ssh-rsa AAAAB3NzaC1yc2EAA

• Ves 14h00 (un peu avant même) deux équipes semblaient avoir un accès SSH au serveur. Forcément, le jeu devient moins facile à suivre.
• De temps en temps, de nouvelles bannières font leur apparition :

666 You Totally Suck Turnips

• Avec cette seconde édition, la Hack.lu transforme l'essai et s'inscrit dans le paysage des conférences Sécurité européennes incontournables.
• Et si certaines journées ont paru longues sur la fin, le confort des sièges y était pour beaucoup.
• Rendez-vous l'automne prochain pour la v3.

• Compte-rendu de Cédric Blancher (en anglais)
• Le CTF vu par la Red Team.