Blog Sécurité Informatique

Shellcode IsProcessDebugged (25 octets)

2007-08-06T14:40:00.000+02:00

J'ai très récemment développer un nano-shellcode pour Win32, consistant à détecter si le process courant (dans lequel est injecté le shellcode) est en train d'être debuggé ; ce n'est pas d'un réel interêt lors d'une attaque, mais c'est intéressant :

char shellcode_dbg[] = "\x60\x33\xDB\x83\xC3\x18\x64\x8B\x03\x8B\x40\x30"
"\x0F\xB6\x40\x02\x8B\xFD\x83\xC7\x04\x29\x07\x61\xC3";

Il ne fait pas plus de 25 octets (23 mais j'ai rajouté les instrucitons pushad et popad pour éviter un éventuel plantage), il récupère la valeur PEB->BeingDebugged qui indique si le processus est débuggé (== 1) ou non (==NULL), puis modifie la valeur de retour sauvegardée dans la pile avec cette valeur, ce qui fera que le programme crash si il est debuggé, ou continue son exécution normale si ce n'est pas le cas.

PacketStorm : http://packetstormsecurity.org/shellcode/shellcode-crash.c

Il sera prochainement publié sur milw0rm.

BAC

2007-07-06T14:36:00.000+02:00

Une longue interruption, après le passage du baccalaureat...
Des news seront de temps en temps postées sur ce blog...

Détection Sniffer : les sources - TECH

2007-03-31T23:57:00.000+02:00

Il y'a plus d'un mois, j'avais décrit grossièrement le protocole à suivre basé sur le protocole ARP afin de détecter à travers un réseau d'éventuelles utilisations de Sniffers (ou d'IDS) sur un des postes. J'avais développé auparavant un outil qui se chargeait de faire cela, avec une interface graphique (très mal faite ^^).

Vous pouvez vous référez à mon billet précédent sur le sujet ou au papier de SecurityFriday : Promiscuous node detection using ARP packets.

Source : http://touronster.free.fr/Dev/C%20-%20CPP/Network%20Map/
Et aussi disponible un screenshot..

Attention cependant, il est très loin d'être complètement fonctionnel, en effet il y'a des adresses IP codées en dur dans le source, que vous devrez modifier si vous souhaitez le faire marcher sur votre réseau (le source a été adapté à ma configuration réseau).

Sécurité de la pile avec compilateur DDK - TECH

2007-03-18T00:15:00.000+01:00

Voici un court article que j'ai écrit cet après-midi, qui explique les mécanismes de protection de la pile contres les attaques par dépassement de tampon, implémentés dans les fonctions internes des drivers compilés avec le DDK de Microsoft. Ce mécanisme (la technique du canary) est peu différent de celui implémenté par les compilateurs Visual Studio avec le Flag /GS, seules quelques petites différences subsistent.

Article PDF : Mécanisme Anti-BoF du compilateur DDK

Détermination de PI avec FPU - FUN

2007-03-09T20:14:00.000+01:00

Récemment en cours de maths, on a abordé une méthode pour déterminer pi en utilisant les suites numériques dites adajacentes, c'est alors que j'ai proposé une méthode se basant sur les probabilités pour approximer la valeur de pi, grand moment de solitude pour moi, incompris par ma classe :-)

Je refais face : je vais représenter plus en détail cette méthode simple d'approximation de pi, cette méthode n'est pas la mienne, c'est la méthode Monte Carlo. Démonstration.

Pour utiliser cette méthode, on se place dans une certaine figure : un carré de côté 1 contenant un quart de cercle trigonométrique inscrit (de rayon 1). Techniquement, le principe est basé sur une génération aléatoire de coordonées de points dans le repère ayant pour origine un angle du carré.

Soit alpha le nombre de points du cercle et beta les points hors du cercle, ce quotient sera donc égale au quotient de l'aire du quart de cercle sur l'aire du carré, soit l'égalité :

J'ai donc développé un court programme d'une centaine de ligne en C/Assembleur inline, qui se base donc sur une génération de coordonées aléatoires pour différents points dans le carré, ensuite il calcule la distance de chaque point pour définir s'il appartient oui ou non au quart de cercle, le calcul ne consiste donc seulement à calculer un pourcentage le plus précis possible, pour qu'on puisse par la suite le multiplier par 4 pour obtenir une approximation de PI.

Vous pouvez régler dans le code source le nombre d'itération à effectuer (ce qui correspond au nombre de points générés) ; plus ce nombre est important, plus l'approximation de PI sera fine : la loi des grands nombres. Cependant, si on augmente trop le nombre d'itérations, le résultat final sera incohérent, c'est un petit bug : il y'a un moment donné un integer overflow qui surgit, pour le corriger il faut modifier le type de la variable int i, par une variable de 64 bits ou plus suivant les envies...
On pourrait aussi améliorer le code pour gérer plus de décimales.

Dans le code, j'ai préféré programmer les calculs sur les flottants en utilisant le FPU avec des blocs __asm (avec VS 2005 Express). une version distribuée du calcul pourrait être intéressant à développer : source.

Screenshot
Source + Bin

Monsieur Cyr si vous passez ... ^_^

PS : cela n'a rien à voir, une connaissance Mathieu Suiche a récémment publié un billet sur le blog MSDN de Microsoft, concernant les nouvelles conventions d'appels sous architecture 64 bits, voici le lien :
Introduction aux Conventions d'appels 64 bits

Détournement d'écoute des sockets sous Windows – TECH

2007-03-02T21:28:00.000+01:00

La plupart des développeurs le savent, pour donner la possibilité à une application de traiter des flux réseaux, on doit utiliser les sockets, qui sont en quelque sorte des descripteurs de connexion, un handle comme on en parle sous Windows. Pour la suite du billet, je vais considérer que vous savez les utiliser.

Seulement, les systèmes NT peuvent présenter une faiblesse si on utilise mal ces sockets. En effet, les fonctionnalités systèmes de socket sont programmées de telle sorte que certaines sockets utilisées par un programme puissent être prioritaires vis-à-vis d'autres, suivant leur définition par le programme utilisateur. Concrétement, il est possible de définir l'adresse d'une socket par la valeur générique INADDR_ANY, cette valeur permet de définir une socket sur toutes les adresse d'une machine, c'est-à-dire que le programme utilisateur sera en mesure de récupérer des paquets réseaux à destination d'une des différentes adresses du système.

C'est là qu'intervient le concept de priorité, en effet sur les systèmes NT, une socket définie sur une adresse spécifique sera priviliégiée au niveau de la déléguation des paquets réseau, comparé à une socket définie avec INADDR_ANY, si ces deux sockets sont définies sur un même port.

Par exemple, si un programme utilise une socket définie avec INADDR_ANY, celui-ci pourra présenter une faiblesse. En effet, il serait possible de développer un petit programme d'écoute sur le même port que le programme vulnérable, mais cette fois-ci en définissant la socket sur une adresse spécifique et non générique. Le programme attaquant devra utiliser la fonction setsockopt appliquée sur sa socket en utilisant l'argument SO_REUSEADDR, afin de pouvoir binder sa socket sur la même adresse (et port) que ceux du programme vulnérable.

Depuis les nouvelles versions de Windows, une nouvelle option pour les socket a été instaurée : c'est l'option SO_EXCLUSIVEADDR, que l'on applique au socket en question. Cette option empêche la définition d'une autre socket sur la même adresse réseau et même port, donc protège d'un détournement de l'écoute réseau d'un programme. Elle évite également de devoir définir plusieurs sockets sur toutes les adresses réseaux du système. Dorénavant, pensez à appliquer cette option à la socket que vous utilisez dans vos programmes pour plus de sécurité.

Voici pour exemple un code présentant un très simple serveur vulnérable : source. Pour tester la chose, on peut utiliser netcat, voici le résultat du test :

On lance les deux serveurs...

cmd> server -vuln
cmd> nc -p 1337 -L 192.168.0.4

On se connecte au système (port 1337)...

cmd> nc 192.168.0.4 1337

On remarque que l'on ne reçoit pas de message d'accueil de la part de notre serveur, on s'est donc connecté au serveur lancé via netcat, on peut le vérifier en envoyant un message au serveur.

On relance ensuite un second test, avec l'option de sécurité -safe du serveur...

cmd> server -safe
cmd> nc -p 1337 -L 192.168.0.4
can't grabe 0.0.0.0:1337 with bind

En effet, netcat renvoie une erreur lors de l'éxecution de la fonction bind, car en effet netcat tente de bindersocket sur la même adresse que notre serveur de test qui a appliqué l'option SO_EXCLUSIVEADDRUSE sur sa socket. L'application server est donc sécurisé à ce niveau-là.

Peu de malwares se basent sur cette technique d'attaque, celle-ci ne semble pas être très répandue mais mérite néanmoins une petite explication et prévention. Dorénavant, vous saurez quoi faire de votre socket...

Liens :

Prochain billet : Appels systèmes Windows (SSDT) [SUITE]

Version PDF du billet

La SSDT de Windows [INTRO] - TECH

2007-02-21T13:03:00.000+01:00

Comme tout système d'exploitation, Windows possède certaines fonctions systèmes propres au noyau. Ce sont les appels systèmes, utilisées par les fonctions API de Windows. En effet, les API ne sont qu'une interface avec le noyau pour les programmes utilisateurs.

Comme exemple, l'appel de la fonction API CreateFile engendre une cascade d'appels de fonction. Lorsqu'un programme nécéssite un accés disque via l'appel CreateFile, cette API initialement exportée par la bibliothèque Kernel32.dll va par la suite faire appel à la fonction NtCreateFile exportée, elle, par NtDll.dll. Ces deux appels de fonction successifs sont réalisés dans le User Land.

Les appels systèmes interviennent à ce niveau-là. En effet, la transition API / Syscall va s'effectuer lors de l'exécution de l'API native NtCreateFile. Le rôle de l'API native (NtCreateFile dans ce cas) est de faire appel à une interruption spécifique à Windows, afin que la fonction noyau correspondante soit appelée ; elle effectue donc un appel système. On peut situer le code permettant cette transition :

- Désassemblage de ZwCreateFile dans NtDll.dll (avec IDA Pro) :

   |     public ZwCreateFile
   |     ZwCreateFile proc near
   |     mov eax, 25h      ; numéro de service (offset) pour la SSDT
   |     mov edx, 7FFE0300h
   |     call dword ptr [edx]      ; appel de KiFastSystemCall
   |     retn 2Ch
   |     ZwCreateFile endp

Ici, on a désassemblé ZwCreateFile, en effet NtCreateFile et ZwCreateFile sont toutes les deux exportées par NtDll.dll et pointent sur les mêmes instructions. On voit que ZwCreateFile stocke la valeur 25h dans le registre EAX, puis par la suite effectue un appel de fonction, à l'adresse stockée dans [7FFE0300]. En réalité, cette instruction CALL est une interruption logicielle nécéssaire à l'appel de la fonction noyau qui gère les accés disques.

En effet, lors de l'interruption logicielle, le processeur va rechercher dans l'IDT (Interrruption Descriptor Table) le gestionnaire d'interruption correspondant à celle-ci. Dans notre cas, ce gestionnaire d'interruption se basera sur le registre EAX, dans lequel ZwCreateFile a stocké l'offset pour la SSDT.

En effet, il relèvera dans la SSDT (qui est un tableau de DWORD) un pointeur de fonction correspondant au service d'accés disque. Toutes APIs natives possède cette forme, la différence réside dans la valeur qu'elles stockent dans le registre EAX, pour faire appel au bon service. Le graphique représente la cascade d'appels pour l'appel d'une API.

Ce mécanisme d'appel aux fonctions noyau est similaire à celui mise en place dans les systèmes linux. En effet, ils possèdent une interruption (la 0x80), qui permet de lancer des fonctions systèmes du noyau linux, pour cela il suffit de placer une valeur également dans le registre EAX, correspondant à la fonction système souhaitée (telle que sys_execve, sys_open, sys_fork etc...).

L'adresse de la SSDT est obtenue par l'intermédiaire d'un tableau de ServiceDescriptorEntry, lui-même contenue dans la structure ServiceDescriptorTable. En effet, son adresse correspond à SDT.ServDescEntry[0].ServiceTable. L'adresse ce premier membre du tableau de structures ServiceDescriptorEntry peut-être obtenue par un symbole exporté par ntoskrnl.exe, le noyau du système Windows, le symbole KeServiceDescriptorTable, de là, on a directement accés au tableau de DWORD ; la SSDT.

L'intégrité de cette SSDT est donc très importante, car le bon fonctionnement du système, des fonctions APIs en dépend. C'est sur cela que se base les rootkits, en effet ils modifients la SSDT de façon à détourner les appels systèmes, de cette manière ils peuvent falsifier les données retournées par ces fonctions, dans le but de cacher leur activité (invisibilité de processus, de fichier / dossiers, de ports tcp / udp, etc...).

Un logiciel anti-rootkit vérifie donc l'intégrité des entrées de la SSDT (donc les différents membres du tableau SDT.ServDescEntry[0].ServiceTable) à la recherche de d'entrées falsifiés (par d'éventuels rootkits).

Cependant, de fausses alertes peuvent être soulevées, car en effet, les pare-feu (entre autres) utilisent le SSDT hooking afin de maintenir une protection et une surveillance.

Différents outils peuvent vérifier l'intégrité de cette SDT dont KProCheck, et aussi Vice.

Voici aussi une documentation intéressante : http://3psilon.info/Les-rootkits.html.

Prochainement, je travaillerai sur une source d'un driver illustrant ce billet, et un autre billet détaillant le mécanisme du kernel utilisé pour les syscalls Windows sera publié.

Version PDF du billet

Méthode de détection de Sniffer - TECH

2007-02-17T15:13:00.000+01:00

Il s'agit ici d'une pratique qui consiste à détecter l'utilisation frauduleuse d'outils de sniffing, qui permettent la capture et l'analyse de paquets de données émis sur un réseau compromis (pour d'éventuelles captures d'identifiants). La grande différence réside sur le fait que cette détection s'effectue au niveau réseau et non local, autrement dit, il est possible de détecter sur un poste distant l'utilisation éventuelle d'un sniffer. Pour mieux comprendre cet article, quelques connaissances de base sur les en-têtes Ethernet et ARP sont nécéssaires :

Liens :

Le principe est basé sur une "défaillance" au niveau des kernels de plusieurs OS : Linux(2.2/2.4/2.6) et Windows(9x/Me/2k/NT4/XP). En effet, lors d'une résolution ARP, l'en-tête Ethernet est remplie de telle sorte que le paquet soit envoyé en broadcast, vers tous les postes présents sur le réseau : soit le champ Destination affecté de la valeur FF:FF:FF:FF:FF:FF (BROADCAST), afin que l'adresse IP puisse être résolue.

Et c'est précisement avec ce champ Destination que l'on peut parvenir à déterminer si un poste utilise un sniffer. Il faut savoir que pour un paquet réseau, notamment pour un paquet Ethernet, avant qu'il parvienne à la stack réseau de kernel du système, il passe par plusieurs "contrôles". Il passe déjà un contrôle Hardware, autrement dit un filtrage sur le périphérique réseau, qui détermine si le paquet lui est destiné ou non.

Dans le cas d'un paquet Ethernet envoyé en broadcast, ces paquets passeront tous le filtrage de la carte réseau. Ils devront ensuite passer le contrôle sofware, situé au niveau du noyau, et c'est à ce niveau précis que peut s'effectuer une différentiation.

En effet, le filtrage noyau n'est pas "complet", autrement dit, un paquet failsifié avec comme champ ethernet destination de valeur FF:FF:FF:FF:FF:FE passe aussi bien le filtrage qu'un destination de valeur FF:FF:FF:FF:FF:FF. On voit donc que le paquet falsifié peut donc aisément contourner le filtrage SOFTWARE, mais logiquement il ne devrait pas passer le filtrage hardware (celui-ci n'accepte que l'adresse MAC lui étant affectée en usine, ou l'adresse broadcast).

C'est là qu'intervient le Sniffing, en effet un sniffer a pour rôle de configurer la carté réseau en mode Promiscuous, un mode qui permet de capturer tous les paquets réseaux circulant sur le même noeud que le poste en question. Ce mode permet donc d'annuler en quelque sorte le filtrage hardware de la cartes réseau.

Par conséquent, en associant les deux filtrages, et la défaillance au niveau kernel, on en déduit qu'un paquet Ethernet falsifié peut donc être traité par la stack réseau du système, passant ainsi les contrôles software et hardware, mais uniquement dans le cas où la carte réseau du poste distant est en mode promiscuous, autrement dit lorsqu'un sniffer est en marche sur la machine.

Une technique pour détecter si un poste du réseau est en mode promiscuous, consiste à envoyer une série de paquets Ethernet embarquant de l'ARP, avec pour champ destination la valeur FF:FF:FF:FF:FF:FE (broadcast falsifié), et en incrémentant la valeur de l'adresse IP du champ Target Internet Address de l'en-tête ARP à chaque nouveau paquet envoyé. Ensuite, lors de l'écoute pour réceptionner des paquets, tout paquets ARP comportant pour valeur reply du champ operation de l'en-tête ARP, seront donc des réponses à notre envoi de paquets successifs.

Il suffit juste par la suite de relever dans ces paquets REPLY la valeur de l'adresse IP Source et de l'adresse MAC Source des postes qui nous ont répondu, et de là on en déduit qu'un logiciel sniffer est en marche sur ces machines.

Cette technique n'est pas très répandue sur internet, on trouve peu d'articles, néanmoins un article est disponible sur le site de SECURITY FRIDAY, qui en ont fait une implémentation : PromiScan.

Liens :

L'auteur de cette découverte est un chercheur en sécurité, que l'on peut retrouver chez Safe-Protect.

Prochain billet : Windows et la SSDT

API Hooking avec Registry Guard - TECH

2007-02-12T16:14:00.000+01:00

Première vraie publication, et cette fois-ci un petit programme. Registry Guard est un petit projet que j'ai développé l'an dernier en C/C++ avec API Win32. Il consiste en une démonstration de API Hooking via une DLL, en utilisant la méthode dite IAT Patching.

En effet, ce programme a pour but de détouner les appels aux API ayant relation avec la base de registre windows, ceci n'est qu'une ébauche qui a pour but de démontrer ce concept et cette méthode de hooking, il n'est pas fini, de nombreuses modifications pourraient y être apportées. Donc le hooking agit au niveau utilisateur (user level), sûrement qu'une prochaine version en kernel-level (développement d'un driver) sera développée.

Liens :

Aussi :

Aussi, une documentation technique est en cours d'écriture, concernant la méthode utilisée dans Registry Guard pour le hooking. N'hésitez pas à me contacter.

Prochain billet : Détection de sniffing basée sur ARP

Ouverture du blog

2007-02-11T22:04:00.000+01:00

Bonjour, 11/02/2007, début des vacances à Toulouse, et ouverture de mon premier blog orienté sur la sécu, des projets et des news sur ce sujet sont à venir, des bouts de code, des exemples, des articles, des papers techniques, des liens, et quelques unes de mes créations... revenez souvent.

Bonne visite.

PS : petite nomenclature pour les billets:

TECH correspond à un article Technique
NEWS pour des billets concernant l'actualité dans la sécu