Petit article juste pour l'insolite. J'ai eu la surprise, il y a quelques jours de voir le distributeur automatique de ma banque m'accueillir via une jolie... Windows Error MessageBox!
Oui oui, il semble bien que les automates (ceux-ci en tout cas...) tournent sous windows. Etrange lorsque l'on sait le niveau de sécurité que ceux-ci requièrent, dit incompatible avec les stratégies de sécurité par l'obscurité, telles que pratiquées par Microsoft.
Et de retomber dans ce domaine en pleine expansion de la sécurité des noyaux et des systèmes embarqués! Même si les automates banquaires doivent être blindés au moins autant logiciellement que physiquement, connaitre la présence d'un noyau windows à l'intérieur est amusant!
Aujourd'hui, alors que je m'apprêtais à effectuer une banale opération sur ce même automate, celui-ci eût des ratées, options inaccessibles, ou annulations intempestives des opérations en cours!!
Je ne suis pas resté assez longtemps pour connaitre l'avis des techniciens (en aurais-je seulement eût un?) mais cette mésaventure me fit repenser au noyau qui anime la machine...
Vous avez dit fiable?
27 nov. 2007
7 nov. 2007
SQL et registre Windows
Un jour et un mois se sont écoulés depuis mon article sur la modification de la base de registres
Windows en javascript depuis le browser.
Aucun anniversaire donc, mais une coïncidence me fait revenir sur ce sujet. Je viens de découvrir qu'il était possible de modifier cette base de registres depuis... SQL Server!
Là encore il existe des méthodes pour lire, écrire et effacer des entrées:
o xp_regread
o xp_regwrite
o xp_regdeletekey
xp_regwrite peut par exemple être utilisée ainsi:
Pour mettre la valeur 'Hello' dans la variable
'Msg_hello',d'une clef 'SOFTWARE\Microsoft\any',
'HKEY_ADMINISTRATEUR', il suffit d'éxecuter :
Bon là tout de suite les injections SQL font un peu plus mal... Malheureusement ces méthodes, si elles sont documentées sur le net, ne le sont apparament pas par Microsoft. Ainsi, n'ayant pas de SQL server sous la main, je ne peux pas les tester. Car je suppose quand même que leur utilisation doit être relativement contrôlée, j'espère...
Windows en javascript depuis le browser.
Aucun anniversaire donc, mais une coïncidence me fait revenir sur ce sujet. Je viens de découvrir qu'il était possible de modifier cette base de registres depuis... SQL Server!
Là encore il existe des méthodes pour lire, écrire et effacer des entrées:
o xp_regread
o xp_regwrite
o xp_regdeletekey
xp_regwrite peut par exemple être utilisée ainsi:
Pour mettre la valeur 'Hello' dans la variable
'Msg_hello',d'une clef 'SOFTWARE\Microsoft\any',
'HKEY_ADMINISTRATEUR', il suffit d'éxecuter :
EXEC master..xp_regwrite
@rootkey='HKEY_ADMINISTRATEUR',
@key='\\SOFTWARE\\Microsoft\\any',
@value_name='Msg_hello',
@type='REG_SZ',
@value='Hello'
Bon là tout de suite les injections SQL font un peu plus mal... Malheureusement ces méthodes, si elles sont documentées sur le net, ne le sont apparament pas par Microsoft. Ainsi, n'ayant pas de SQL server sous la main, je ne peux pas les tester. Car je suppose quand même que leur utilisation doit être relativement contrôlée, j'espère...
4 nov. 2007
XSS / DOS -- Deux failles pour le prix d'une!
Au détour d'un script de redirection je viens de trouver une vulnérabilité sur un site dont je tairais le nom. Après un dizaine de alert('XSS') je compris que la page devait sans doute être réinitialisée à l'infini. Ainsi, l'injection d'un simple : "> provoquait une réactualisation extrêmement rapide de la page, En effet le script de redirection me permettait d'injecter dans les headers!
Et voici à quoi ressemblait le code source de la page :
Ainsi, un script de redirection tout bête, qui prend une url et redirige l'utilisateur dessus se trouve être une ouverture aux attaques par XSS et également un outil de DOS (Denial Of Service, un trop grand nombre de requêtes en peu de temps sature le serveur).
Un autre trou dans lequel aiment à se lover les failles XSS est les pages d'erreurs. Nottament ces 404 qui ressortent, sans le filtrer, le referer, ou n'importe quelle information des headers.
Ceci démontre deux choses, la première est la difficulté de se protéger contre les failles XSS (deux furent découvertes sur le site de papal cette semaine!), la seconde est l'ampleur des attaques qui peuvent être menées via de telles failles, encore considérées par certains comme des failles mineures.
Peut être car les preuves de concept semblent enfantines, ("Qu'ils sont mignons ces hackers avec leurs petites boites de dialogue qui leur disent "Hello" ou "XSS").
Petit hors sujet pour terminer cet article :
Une XSS dans un webmail est plus qu'ennuyeux, si vous désirez tester la fiabilité du votre, il existe un outil efficace, le mailgun de Mario Heiderich (from Gnucitizen quand même...). Cet outil à utiliser avec prudence tout de même vous envoi un email contenant toute la base de vecteurs XSS du Gnucitizen think-tank!
Et voici à quoi ressemblait le code source de la page :
<html><meta HTTP-EQUIV="REFRESH"
CONTENT="0;URL=">/></head><body></body>
Ainsi, un script de redirection tout bête, qui prend une url et redirige l'utilisateur dessus se trouve être une ouverture aux attaques par XSS et également un outil de DOS (Denial Of Service, un trop grand nombre de requêtes en peu de temps sature le serveur).
Un autre trou dans lequel aiment à se lover les failles XSS est les pages d'erreurs. Nottament ces 404 qui ressortent, sans le filtrer, le referer, ou n'importe quelle information des headers.
Ceci démontre deux choses, la première est la difficulté de se protéger contre les failles XSS (deux furent découvertes sur le site de papal cette semaine!), la seconde est l'ampleur des attaques qui peuvent être menées via de telles failles, encore considérées par certains comme des failles mineures.
Peut être car les preuves de concept semblent enfantines, ("Qu'ils sont mignons ces hackers avec leurs petites boites de dialogue qui leur disent "Hello" ou "XSS").
Petit hors sujet pour terminer cet article :
Une XSS dans un webmail est plus qu'ennuyeux, si vous désirez tester la fiabilité du votre, il existe un outil efficace, le mailgun de Mario Heiderich (from Gnucitizen quand même...). Cet outil à utiliser avec prudence tout de même vous envoi un email contenant toute la base de vecteurs XSS du Gnucitizen think-tank!
1 nov. 2007
Fingerprinting Windows Vista
Que de titres en anglais ces temps-ci! Mais aussi plus d'articles (car plus de temps libre pour tester, coder et écrire). Celui-ci relate une petite découverte que je fis il y a déjà un moment. Lors du débuggage d'un programme réseau, je faisais tourner Wireshark (non je ne parle pas que de sniffers dans mes articles) et je vis apparaitre un flood monstrueux de paquets ARP!
D'abord quelque peu inquiet, car me revenaient en mémoire ces articles sur l'ARP spoofing etc... mais également intrigué, je décortiquais les paquets reçus.
Il apparût qu'ils provenaient TOUS de 192.168.1.18, le laptop de ma môman, que je ne saurait suspecter de la moindre tentative d'intrusion (surtout sur notre propre réseau)...
Capture des paquets à l'aide de Wireshark : 16 requêtes en 13 secondes!
Après quelques analyses sur d'autres machines, je peux l'affirmer, mon floodeur s'appelle Microsoft Windows Vista!! La bestiole crache dans les 80/85 paquets par minutes.
Ce qui est étrange c'est que Vista émet des requêtes portant sur des hôtes qu'il détient en cache (vous pouvez afficher le cache arp sous windows via la commande arp -a). Il doit s'agir d'un dysfonctionnement dans le système d'entretien de ce cache mais je un bug à ce niveau est plutôt inattendu...
Dump du cache ARP sous Windows Vista
Si quelqu'un a une explication ou des informations à ce sujet je suis preneur, n'hésitez pas à poster dans les commentaires.
En attendant cela permet une détection aisée de machines sous Vista sur un réseau, d'où le titre de l'article.
Ainsi, si vous observez un important traffic ARP sur votre réseau, il peut soit s'agir d'un pirate à l'oeuvre, soit d'une machine sous Vista, dans les deux cas vous êtes confrontés à un grave problème!
D'abord quelque peu inquiet, car me revenaient en mémoire ces articles sur l'ARP spoofing etc... mais également intrigué, je décortiquais les paquets reçus.
Il apparût qu'ils provenaient TOUS de 192.168.1.18, le laptop de ma môman, que je ne saurait suspecter de la moindre tentative d'intrusion (surtout sur notre propre réseau)...
Capture des paquets à l'aide de Wireshark : 16 requêtes en 13 secondes!
Après quelques analyses sur d'autres machines, je peux l'affirmer, mon floodeur s'appelle Microsoft Windows Vista!! La bestiole crache dans les 80/85 paquets par minutes.
Ce qui est étrange c'est que Vista émet des requêtes portant sur des hôtes qu'il détient en cache (vous pouvez afficher le cache arp sous windows via la commande arp -a). Il doit s'agir d'un dysfonctionnement dans le système d'entretien de ce cache mais je un bug à ce niveau est plutôt inattendu...
Dump du cache ARP sous Windows VistaSi quelqu'un a une explication ou des informations à ce sujet je suis preneur, n'hésitez pas à poster dans les commentaires.
En attendant cela permet une détection aisée de machines sous Vista sur un réseau, d'où le titre de l'article.
Ainsi, si vous observez un important traffic ARP sur votre réseau, il peut soit s'agir d'un pirate à l'oeuvre, soit d'une machine sous Vista, dans les deux cas vous êtes confrontés à un grave problème!
30 oct. 2007
Détection de sniffers, what about mac OS??
Suite à mon billet sur la détection à distance de sniffers, je me suis mis à effectuer une série de test afin de tester l'efficacité de la méthode. J'ai pû rapidement constater qu'elle était redoutable envers les systèmes Windows (9x -> Vista) et Linux 2.4.x->2.6.x autant dire quasiment tous! Néanmoins, en raison de la convergeance vers moi des regards désaprobateurs des utilisateurs de MAC OS, se sentant oubliés, voici un petit billet sur la detection de sniffers tournant sous mac OS X.
Le test a été effectué en lançant tcpdump (l'installation de Wireshark a planté par un refus de l'installation de l'icone de l'application!!) sur un iBook G4.
Tant pis pour wireshark, tcpdump fait le même boulot, pas envie de chercher le problème...
Pour ceux qui seraient interessés, vous pouvez trouver wireshark pour mac ici, si vous avez le même problème que moi, installez les paquets à la main (par contre c'estsuper chiant un peu long) et lancez tcpdump dans un terminal.
J'ai relié le laptop à mon pc en ethernet (bien que le programme fonctionne aussi via le wifi, en point to point). Et là miracle (ou pas miracle en fait car MAC OS X est basé sur un kernel mach, il s'agit d'un système Unix, proche d'ailleurs des BSD), je pouvais détecter, à distance, si tcpdump était lancé ou non!
Petit copier/coller de la console, de deux essais, tcpdump étant lancé pour le premier et coupé pour le second. Pour ceux qui n'auraient pas lu le premier post de la série, une réponse de la cible à un paquet ARP transformé constitue une preuve que la machine est en mode promiscuous (capture de tous les paquets, même ceux qui ne lui sont pas destinés).
Je commence à avoir fait le tour des principaux systèmes, et tous réagissent de la même manière à mes petits paquets ARP request bidouillés. Je pense qu'il va falloir se faire à l'idée que la méthode n'est pas trop mauvaise bien que basée sur un bug des noyaux. Si vous pouvez effectuer des tests sur des plateformes plus ou moins "exotiques" celà m'interresse grandement.
Le test a été effectué en lançant tcpdump (l'installation de Wireshark a planté par un refus de l'installation de l'icone de l'application!!) sur un iBook G4.
Tant pis pour wireshark, tcpdump fait le même boulot, pas envie de chercher le problème...
Pour ceux qui seraient interessés, vous pouvez trouver wireshark pour mac ici, si vous avez le même problème que moi, installez les paquets à la main (par contre c'est
J'ai relié le laptop à mon pc en ethernet (bien que le programme fonctionne aussi via le wifi, en point to point). Et là miracle (ou pas miracle en fait car MAC OS X est basé sur un kernel mach, il s'agit d'un système Unix, proche d'ailleurs des BSD), je pouvais détecter, à distance, si tcpdump était lancé ou non!
Petit copier/coller de la console, de deux essais, tcpdump étant lancé pour le premier et coupé pour le second. Pour ceux qui n'auraient pas lu le premier post de la série, une réponse de la cible à un paquet ARP transformé constitue une preuve que la machine est en mode promiscuous (capture de tous les paquets, même ceux qui ne lui sont pas destinés).
root@debianne:~/rsd# ./rsd -t 169.254.22.20 -i eth1
La cible 169.254.22.20 a repondu!
root@debianne:~/rsd# ./rsd -t 169.254.22.20 -i eth1
root@debianne:~/rsd#
Je commence à avoir fait le tour des principaux systèmes, et tous réagissent de la même manière à mes petits paquets ARP request bidouillés. Je pense qu'il va falloir se faire à l'idée que la méthode n'est pas trop mauvaise bien que basée sur un bug des noyaux. Si vous pouvez effectuer des tests sur des plateformes plus ou moins "exotiques" celà m'interresse grandement.
29 oct. 2007
Portes dérobées nouvelle génération
Les Chevaux de Troie sont monnaie courante en ce moment et les analystes des sociétés de protection antivirale leur prédisent encore un bel avenir. Ces portes dérobées permettent à un pirate de conserver un accès sur une machine compromise, de la manipuler à distance, donc contrôler son contenu ou constituent des points d'entrée sur un réseau, permettant de compromettre d'autres machines.
Le modèle "classique" consiste à binder un serveur sur un port inutilisé, et à lui envoyer des commandes qu'il exécute. Evidemment, un simple nmap révèle la présence d'un tel programme et un firewall normalement configuré bloquera l'arrivée des commandes. Suivent alors les "reverse shells", qui se connectent aux pirates, là encore la parade est aisée à mettre en oeuvre (nmap et affinage des règles des firewalls si besoin).
Les portes dérobées "nouvelle génération" ont migrées là où à peu près personne ne les embête : dans les noyaux des sytèmes d'exploitation! Ces rootkits sont théoriquement indétectables (oui, je sais le débat fait rage...)
Sans aller jusqu'à coder en kernelspace, vous pouvez masquer un processus en écrivant dans argv[0], la chaine que vous y mettrez sera alors le nouveau nom du processus. Vous éliminez la menace ps -A (waw!)
Mais un autre facteur de furtivité est la manière de capturer les paquets contenant les commandes à exécuter. Un programme qui sniffe les paquets sans passer la carte en mode promiscuous, et qui n'écoute aucun port est indétectable par les outils actuels (à ma connaissance).
Le bypass des firewall peut se faire en envoyant les commandes à un service autorisé, et/ou en utilisant un smartspoofing si le contrôle est basé sur les adresses IP.
Pour peu que les commandes soient envoyées cryptées sur le réseau, la détection de la porte dérobée devient alors "mission très improbable"!!
Le modèle "classique" consiste à binder un serveur sur un port inutilisé, et à lui envoyer des commandes qu'il exécute. Evidemment, un simple nmap révèle la présence d'un tel programme et un firewall normalement configuré bloquera l'arrivée des commandes. Suivent alors les "reverse shells", qui se connectent aux pirates, là encore la parade est aisée à mettre en oeuvre (nmap et affinage des règles des firewalls si besoin).
Les portes dérobées "nouvelle génération" ont migrées là où à peu près personne ne les embête : dans les noyaux des sytèmes d'exploitation! Ces rootkits sont théoriquement indétectables (oui, je sais le débat fait rage...)
Sans aller jusqu'à coder en kernelspace, vous pouvez masquer un processus en écrivant dans argv[0], la chaine que vous y mettrez sera alors le nouveau nom du processus. Vous éliminez la menace ps -A (waw!)
Mais un autre facteur de furtivité est la manière de capturer les paquets contenant les commandes à exécuter. Un programme qui sniffe les paquets sans passer la carte en mode promiscuous, et qui n'écoute aucun port est indétectable par les outils actuels (à ma connaissance).
Le bypass des firewall peut se faire en envoyant les commandes à un service autorisé, et/ou en utilisant un smartspoofing si le contrôle est basé sur les adresses IP.
Pour peu que les commandes soient envoyées cryptées sur le réseau, la détection de la porte dérobée devient alors "mission très improbable"!!
6 oct. 2007
Javascriptus delirium tremensis
Voilà ce qui fut pour moi une découverte hallucinante. Lors d'un passage sur l'excellent "Hacker webzine", je vis qu'il était possible d'accéder à la base de registres de Windows en JavaScript, via internet explorer. De plus, cet accès n'est pas limité (lecture à l'aide de la méthode RegRead, écriture avec RegWrite, effacement avec RegDelete). (source : http://www.0x000000.com/index.php?i=443)
L'auteur présente un exemple de code permettant de désactiver le filtre anti-phishing de Internet Explorer, mais imaginez la puissance de la chose!
En surfant avec IE (personne ne vous y oblige non plus hein...) vous hurlez à tous les sites visités votre clef d'activation Windows ou le path vers votre carnet d'adresses.
Mes tests sous IE_7 montrent que ce dernier détecte tout de même un "contenu actif" et demande confirmation de l'exécution à l'utilisateur.
D'un autre côté, pour naviguer en toute sécurité il faudrait se limiter à la lecture de contenus passifs, sans images etc... Hmmmm je vais continuer ma prise "insensée" de risques via Opera ou Firefox, selon l'humeur! Passer d'un web 2.0 à un web 0.2 n'est pas pour me ravir!
L'auteur présente un exemple de code permettant de désactiver le filtre anti-phishing de Internet Explorer, mais imaginez la puissance de la chose!
En surfant avec IE (personne ne vous y oblige non plus hein...) vous hurlez à tous les sites visités votre clef d'activation Windows ou le path vers votre carnet d'adresses.
Mes tests sous IE_7 montrent que ce dernier détecte tout de même un "contenu actif" et demande confirmation de l'exécution à l'utilisateur.
D'un autre côté, pour naviguer en toute sécurité il faudrait se limiter à la lecture de contenus passifs, sans images etc... Hmmmm je vais continuer ma prise "insensée" de risques via Opera ou Firefox, selon l'humeur! Passer d'un web 2.0 à un web 0.2 n'est pas pour me ravir!
Inscription à :
Articles (Atom)
