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!
Inscription à :
Articles (Atom)
