Nouvelle(?) methode de securisation de site bancaire
29 réponses
Laurent Blume
Bonsoir à tous,
Comme les méthodes de sécurisation de sites bancaires ont déjà été évoquées ici,
je signale celle maintenant utilisée par ma banque pour information et
éventuellement remarques (je veux savoir si mon compte est vulnérable à quelque
subtilité qui m'échappe :-)
Il s'agit du Crédit Mutuel Méditerranéen.
Ils ont envoyé une petite table («Carte de clés personnelles») de 8x8 cases.
Les colonnes sont numérotées, les lignes alphabétisées. Chaque case contient un
nombre de 4 chiffres.
Cela s'ajoute au login/mot de passe habituel, et le fonctionnement, d'après le
site, est simple:
«Par exemple, au moment de l'ajout d'un bénéficiaire de virements, nous vous
demandons d'indiquer la clé contenue dans la case F7 de votre carte.
La clé saisie débloque également les autres opérations protégées pour votre
connexion en cours. Vous disposez de 3 essais pour saisir la clé demandée ; 3
saisies erronées consécutives révoquent votre carte de CLÉS PERSONNELLES.»
Ça me plait assez, encore qu'évidemment, il faut maintenant faire attention à ne
pas perdre la carte en question.
Je ne vois pas encore de durée de vie de cette carte, je suppose qu'il les
remplaceront.
On Wed, 20 Jul 2005 22:27:30 +0000, Cedric Blancher wrote:
http://nicob.net/SSTIC05/ Cela dépasse de loin ce que je croyais possible.
Merci, merci ;-)
Je tiens juste à préciser que cette présentation est le fruit d'une collaboration entre membres de "La Meute (c)", et que je ne suis pas le uber-Win32-coder en question.
Ca se saurait si j'avais des compétences en Windows ;-)
[...] MiM SSL complètement transparent à partir du poste visé : http://actes.sstic.org/SSTIC05/Rump_sessions/SSTIC05-rump-Detoisien-SSLug.pdf
C'est clair que c'est une technique des plus élégantes ! Et que c'est bien plus intéressant pour piquer les informations bancaires que les keyloggers et leurs évolutions récentes.
Pour en revenir aux claviers virtuels, j'ai vu la semaine dernière le premier outil "black-hat" implémentant la fonctionnalité de mini-screenshots déclenchés par les clics de la souris. C'était apparemment une version beta (au vu de la qualité du malware), mais cela prouve qu'ils (les méchants) ont eux aussi calculé que les claviers virtuels, c'est surtout de la poudre aux yeux ...
Nicob
On Wed, 20 Jul 2005 22:27:30 +0000, Cedric Blancher wrote:
http://nicob.net/SSTIC05/
Cela dépasse de loin ce que je croyais possible.
Merci, merci ;-)
Je tiens juste à préciser que cette présentation est le fruit d'une
collaboration entre membres de "La Meute (c)", et que je ne suis pas le
uber-Win32-coder en question.
Ca se saurait si j'avais des compétences en Windows ;-)
[...] MiM SSL complètement transparent à partir du poste visé :
http://actes.sstic.org/SSTIC05/Rump_sessions/SSTIC05-rump-Detoisien-SSLug.pdf
C'est clair que c'est une technique des plus élégantes ! Et que c'est
bien plus intéressant pour piquer les informations bancaires que les
keyloggers et leurs évolutions récentes.
Pour en revenir aux claviers virtuels, j'ai vu la semaine dernière le
premier outil "black-hat" implémentant la fonctionnalité de
mini-screenshots déclenchés par les clics de la souris. C'était
apparemment une version beta (au vu de la qualité du malware), mais cela
prouve qu'ils (les méchants) ont eux aussi calculé que les claviers
virtuels, c'est surtout de la poudre aux yeux ...
On Wed, 20 Jul 2005 22:27:30 +0000, Cedric Blancher wrote:
http://nicob.net/SSTIC05/ Cela dépasse de loin ce que je croyais possible.
Merci, merci ;-)
Je tiens juste à préciser que cette présentation est le fruit d'une collaboration entre membres de "La Meute (c)", et que je ne suis pas le uber-Win32-coder en question.
Ca se saurait si j'avais des compétences en Windows ;-)
[...] MiM SSL complètement transparent à partir du poste visé : http://actes.sstic.org/SSTIC05/Rump_sessions/SSTIC05-rump-Detoisien-SSLug.pdf
C'est clair que c'est une technique des plus élégantes ! Et que c'est bien plus intéressant pour piquer les informations bancaires que les keyloggers et leurs évolutions récentes.
Pour en revenir aux claviers virtuels, j'ai vu la semaine dernière le premier outil "black-hat" implémentant la fonctionnalité de mini-screenshots déclenchés par les clics de la souris. C'était apparemment une version beta (au vu de la qualité du malware), mais cela prouve qu'ils (les méchants) ont eux aussi calculé que les claviers virtuels, c'est surtout de la poudre aux yeux ...
Nicob
Dominique Blas
[...]
Pas d'accord. Ce nouveau mécanisme permet d'éviter les attaques où le pirate n'a pas accès à l'ordinateur, telles que la récente tentative de phishing massif en France. Je ne parlais pas spécifiquement des pirates en ligne mais
accessoirement des collègues de bureau agissant de la même manière. Autre marché visé : les voleurs de portables communiquant les informations à un réseau de pirates.
J'ai reçu le fameux mail "Dear Societe Generale/ BNP Paribas/ CIC Banque/ Banque CCF Member" le 27 mai 2005. On peut dire que les banques ont réagi vite, ou qu'elles s'y attendaient.
Le phishing sévit outre-Altantique depuis 2 ans. Les banques françaises ne sont pas trèsdouées pour assurer la sécurité de leur client c'est un fait acquis désormais. Mais, la médiatisation aidant, pour celles qui se sentent un tantinet concernées la moindre des choses c'est au moins d'écouter ce qui se passe là-bas !
[...]
Bof, si je me fais kidnapper, Oui, bon, la probabilité de se faire kidnapper est tout de même proche
de zéro non et si cela devait arriver je pense que tes comptes bancaires seraient bien le dernier de tes soucis ?
[...]
db
--
Courriel : usenet blas net
[...]
Pas d'accord. Ce nouveau mécanisme permet d'éviter les attaques
où le pirate n'a pas accès à l'ordinateur, telles que la récente
tentative de phishing massif en France.
Je ne parlais pas spécifiquement des pirates en ligne mais
accessoirement des collègues de bureau agissant de la même manière.
Autre marché visé : les voleurs de portables communiquant les
informations à un réseau de pirates.
J'ai reçu le fameux mail "Dear Societe Generale/ BNP Paribas/ CIC
Banque/ Banque CCF Member" le 27 mai 2005. On peut dire que les
banques ont réagi vite, ou qu'elles s'y attendaient.
Le phishing sévit outre-Altantique depuis 2 ans.
Les banques françaises ne sont pas trèsdouées pour assurer la sécurité
de leur client c'est un fait acquis désormais. Mais, la médiatisation
aidant, pour celles qui se sentent un tantinet concernées la moindre des
choses c'est au moins d'écouter ce qui se passe là-bas !
[...]
Bof, si je me fais kidnapper,
Oui, bon, la probabilité de se faire kidnapper est tout de même proche
de zéro non et si cela devait arriver je pense que tes comptes bancaires
seraient bien le dernier de tes soucis ?
Pas d'accord. Ce nouveau mécanisme permet d'éviter les attaques où le pirate n'a pas accès à l'ordinateur, telles que la récente tentative de phishing massif en France. Je ne parlais pas spécifiquement des pirates en ligne mais
accessoirement des collègues de bureau agissant de la même manière. Autre marché visé : les voleurs de portables communiquant les informations à un réseau de pirates.
J'ai reçu le fameux mail "Dear Societe Generale/ BNP Paribas/ CIC Banque/ Banque CCF Member" le 27 mai 2005. On peut dire que les banques ont réagi vite, ou qu'elles s'y attendaient.
Le phishing sévit outre-Altantique depuis 2 ans. Les banques françaises ne sont pas trèsdouées pour assurer la sécurité de leur client c'est un fait acquis désormais. Mais, la médiatisation aidant, pour celles qui se sentent un tantinet concernées la moindre des choses c'est au moins d'écouter ce qui se passe là-bas !
[...]
Bof, si je me fais kidnapper, Oui, bon, la probabilité de se faire kidnapper est tout de même proche
de zéro non et si cela devait arriver je pense que tes comptes bancaires seraient bien le dernier de tes soucis ?
[...]
db
--
Courriel : usenet blas net
Fabien LE LEZ
On 21 Jul 2005 13:39:28 GMT, Nicob :
[...] ont eux aussi calculé que les claviers virtuels, c'est surtout de la poudre aux yeux ...
Du moment que le client soit assez rassuré pour ne pas changer de banque, et accepte de payer les pots cassés en cas de problème, tout va bien.
On 21 Jul 2005 13:39:28 GMT, Nicob <nicob@I.hate.spammers.com>:
[...] ont eux aussi calculé que les claviers
virtuels, c'est surtout de la poudre aux yeux ...
Du moment que le client soit assez rassuré pour ne pas changer de
banque, et accepte de payer les pots cassés en cas de problème, tout
va bien.
[...] ont eux aussi calculé que les claviers virtuels, c'est surtout de la poudre aux yeux ...
Du moment que le client soit assez rassuré pour ne pas changer de banque, et accepte de payer les pots cassés en cas de problème, tout va bien.
Jean-Marc Desperrier
Nicob wrote:
Pour en revenir aux claviers virtuels, j'ai vu la semaine dernière le premier outil "black-hat" implémentant la fonctionnalité de mini-screenshots déclenchés par les clics de la souris. C'était apparemment une version beta (au vu de la qualité du malware), mais cela prouve qu'ils (les méchants) ont eux aussi calculé que les claviers virtuels, c'est surtout de la poudre aux yeux ...
Perfect Keylogger le fait depuis longtemps, non ? Peut-être pas des mini-screen shot (encore que si cela se trouve l'emplacement/taille est réglable), mais l'utilisateur en ADSL ne verra pas la différence.
Nicob wrote:
Pour en revenir aux claviers virtuels, j'ai vu la semaine dernière le
premier outil "black-hat" implémentant la fonctionnalité de
mini-screenshots déclenchés par les clics de la souris. C'était
apparemment une version beta (au vu de la qualité du malware), mais cela
prouve qu'ils (les méchants) ont eux aussi calculé que les claviers
virtuels, c'est surtout de la poudre aux yeux ...
Perfect Keylogger le fait depuis longtemps, non ? Peut-être pas des
mini-screen shot (encore que si cela se trouve l'emplacement/taille est
réglable), mais l'utilisateur en ADSL ne verra pas la différence.
Pour en revenir aux claviers virtuels, j'ai vu la semaine dernière le premier outil "black-hat" implémentant la fonctionnalité de mini-screenshots déclenchés par les clics de la souris. C'était apparemment une version beta (au vu de la qualité du malware), mais cela prouve qu'ils (les méchants) ont eux aussi calculé que les claviers virtuels, c'est surtout de la poudre aux yeux ...
Perfect Keylogger le fait depuis longtemps, non ? Peut-être pas des mini-screen shot (encore que si cela se trouve l'emplacement/taille est réglable), mais l'utilisateur en ADSL ne verra pas la différence.
Nicob
On Thu, 21 Jul 2005 15:03:29 +0000, Jean-Marc Desperrier wrote:
Perfect Keylogger le fait depuis longtemps, non ?
J'ai googlé un brin et trouvé ça : http://www.agentland.fr/pages/learn/articles/perfectkeylogger.html
"[..] faire des captures d'écran à des intervalles réguliers. [...] l'utilité de faire des captures d'écran est laissée à votre appréciation, d'autant plus que ces fichiers (environ 150 Ko chacun) consomment rapidement de l'espace disque."
L'outil black-hat prenait des JPG 120x120 pixels, soit entre 3 et 8 Ko. Notre outil fait du GIF 16x16 à 64x64 soit entre 1 et 16 Ko.
Nicob
On Thu, 21 Jul 2005 15:03:29 +0000, Jean-Marc Desperrier wrote:
Perfect Keylogger le fait depuis longtemps, non ?
J'ai googlé un brin et trouvé ça :
http://www.agentland.fr/pages/learn/articles/perfectkeylogger.html
"[..] faire des captures d'écran à des intervalles réguliers. [...]
l'utilité de faire des captures d'écran est laissée à votre
appréciation, d'autant plus que ces fichiers (environ 150 Ko chacun)
consomment rapidement de l'espace disque."
L'outil black-hat prenait des JPG 120x120 pixels, soit entre 3 et 8 Ko.
Notre outil fait du GIF 16x16 à 64x64 soit entre 1 et 16 Ko.
On Thu, 21 Jul 2005 15:03:29 +0000, Jean-Marc Desperrier wrote:
Perfect Keylogger le fait depuis longtemps, non ?
J'ai googlé un brin et trouvé ça : http://www.agentland.fr/pages/learn/articles/perfectkeylogger.html
"[..] faire des captures d'écran à des intervalles réguliers. [...] l'utilité de faire des captures d'écran est laissée à votre appréciation, d'autant plus que ces fichiers (environ 150 Ko chacun) consomment rapidement de l'espace disque."
L'outil black-hat prenait des JPG 120x120 pixels, soit entre 3 et 8 Ko. Notre outil fait du GIF 16x16 à 64x64 soit entre 1 et 16 Ko.
"[..] faire des captures d'écran à des intervalles réguliers. [...] l'utilité de faire des captures d'écran est laissée à votre appréciation, d'autant plus que ces fichiers (environ 150 Ko chacun) consomment rapidement de l'espace disque."
L'outil black-hat prenait des JPG 120x120 pixels, soit entre 3 et 8 Ko. Notre outil fait du GIF 16x16 à 64x64 soit entre 1 et 16 Ko.
Je serais quand même surpris qu'il ne le rajoute pas assez vite, parceque c'est vraiment pas la partie compliquée.
Et puis pour la capture clavier on peut filtrer suivant l'appli, et aussi filtrer sur la moment où l'utilisateur tape une phrase clé, donc je suppose qu'il y a la même chose pour la capture. Comme l'outils sait aussi envoyer les capture d'écran au fur et à mesure par mail, ça doit quand même être assez redoutablement efficace en ADSL même avec cet inconvénient sur la taille des captures.
"[..] faire des captures d'écran à des intervalles réguliers. [...]
l'utilité de faire des captures d'écran est laissée à votre
appréciation, d'autant plus que ces fichiers (environ 150 Ko chacun)
consomment rapidement de l'espace disque."
L'outil black-hat prenait des JPG 120x120 pixels, soit entre 3 et 8 Ko.
Notre outil fait du GIF 16x16 à 64x64 soit entre 1 et 16 Ko.
Je serais quand même surpris qu'il ne le rajoute pas assez vite,
parceque c'est vraiment pas la partie compliquée.
Et puis pour la capture clavier on peut filtrer suivant l'appli, et
aussi filtrer sur la moment où l'utilisateur tape une phrase clé, donc
je suppose qu'il y a la même chose pour la capture. Comme l'outils sait
aussi envoyer les capture d'écran au fur et à mesure par mail, ça doit
quand même être assez redoutablement efficace en ADSL même avec cet
inconvénient sur la taille des captures.
"[..] faire des captures d'écran à des intervalles réguliers. [...] l'utilité de faire des captures d'écran est laissée à votre appréciation, d'autant plus que ces fichiers (environ 150 Ko chacun) consomment rapidement de l'espace disque."
L'outil black-hat prenait des JPG 120x120 pixels, soit entre 3 et 8 Ko. Notre outil fait du GIF 16x16 à 64x64 soit entre 1 et 16 Ko.
Je serais quand même surpris qu'il ne le rajoute pas assez vite, parceque c'est vraiment pas la partie compliquée.
Et puis pour la capture clavier on peut filtrer suivant l'appli, et aussi filtrer sur la moment où l'utilisateur tape une phrase clé, donc je suppose qu'il y a la même chose pour la capture. Comme l'outils sait aussi envoyer les capture d'écran au fur et à mesure par mail, ça doit quand même être assez redoutablement efficace en ADSL même avec cet inconvénient sur la taille des captures.
Fabien LE LEZ
On 20 Jul 2005 07:36:56 GMT, Dominique Blas :
4. On aurait également pu envisager un formulaire contenant des questions personnelles (une dizaine) auxquelles doit répondre le prétendu client lors d'une opération sensible (virement, boursicotage, etc) sur le portail. Questionnaire à remplir à l'ouverture du service de consultation via Internet.
C'est comme les empreintes digitales : non révocable, et pas si dur que ça à obtenir par un tiers qui se donne un peu de mal.
On 20 Jul 2005 07:36:56 GMT, Dominique Blas <db@internet.invalid>:
4. On aurait également pu envisager un formulaire contenant des
questions personnelles (une dizaine) auxquelles doit répondre le
prétendu client lors d'une opération sensible (virement, boursicotage,
etc) sur le portail. Questionnaire à remplir à l'ouverture du service de
consultation via Internet.
C'est comme les empreintes digitales : non révocable, et pas si dur
que ça à obtenir par un tiers qui se donne un peu de mal.
4. On aurait également pu envisager un formulaire contenant des questions personnelles (une dizaine) auxquelles doit répondre le prétendu client lors d'une opération sensible (virement, boursicotage, etc) sur le portail. Questionnaire à remplir à l'ouverture du service de consultation via Internet.
C'est comme les empreintes digitales : non révocable, et pas si dur que ça à obtenir par un tiers qui se donne un peu de mal.
Jean-Marc Desperrier
Cedric Blancher wrote:
Bref, comme ça était dit récemment lors d'un conférence de sécurité, le poste de l'utilisateur lambda est mort, et les gens vont devoir s'y faire (i.e. prendre en compte cet état de fait) s'ils veulent avancer un peu en matière de sécurité des accès sensibles comme les portails bancaires et proposer des trucs qui tiennent vraiment la route...
Si on part du principe que le poste de l'utilisateur ne peut être sécurisé, tout s'arrête et on rentre à la maison. Si c'est cela le point de départ, il n'y *aucun* moyen de proposer quelquechose qui tient la route à moins de dire qu'un PC ne sert à rien d'autre que des jeux, et que les opérations sécurisées on les fait sur "autre chose".
Mais cet "autre chose" sera finalement un ordinateur à part entière, donc il s'agit de reconstruire une architecture d'ordinateur personnel en évitant les erreurs que l'on a fait sur les PC pour la sécurité.
On est sur cette orientation aussi loin de la solution au problème que si on part sur l'approche "on va corriger les erreurs de l'architecture PC jusqu'à pourvoir en faire une plate-forme solide".
Ne reste guère dans l'immédiat qu'à prendre toutes ses attaques une par une et à les résoudre :
- exe caché dans un zip chiffré/extension modifiée : Ici on se raproche du "social engineering". L'attaque ne marche que avec la collaboration de l'utilisateur, et il faudra travailler sur la sensibilisation des utilisateurs à ces problèmes. A un premier niveau, on peut renforcer le filtrage (virer les zip chiffrés, virer les pièces jointe de type inconnu) *et* mettre en place une solution de secours bien balisée pour les utilisations légitimes génées par ces filtrages.
- Exe dans fichier word : je connais pas bien ce problème mais fondamentalement c'est un bug d'auto-interprétation que MSFT peut régler s'ils se bougent, non ?
- Active X signés : Toute la sécurité repose sur à qui on donne un certificat de signature. Déjà, si on signale à Verisign qu'un certificat est utilisée abusivement, il est révoquée, et un grand nombre d'install de Windows sont configurées pour télécharger cette crl automatiquement (la BP utilisée pour cela sur le site de Verisign se compte en gbit/s). L'erreur cependant ici est d'être parti sur un modèle où les vendeurs de certificats de signature cherche à faire de l'argent, donc évitent de prendre des responsabilités, et cherche à en vendre beaucoup. Il faut passer à un modèle où l'on ne donne un certificat à une entitée qu'après un niveau d'authentification qui garanti qu'on aura quelqu'un de à traduire en justice et faire raquer un max en cas d'abus.
- page web exécutant un active X en mode local : SP2 contre-attaque précisément sur cela en l'interdisant. Outlook pourrait ajouter la "Mark of the Web" sur les pages enregistrées depuis la messagerie.
- OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6 ans que ce problème est connu en fait et que les black hat ne l'ont guère exploité. Ces fonctions ont été ajoutées à l'API Windows pour l'usage des debuggeurs, il faudrait vraiment que Microsoft se décide à faire en sorte que seul un admin ou mieux seul un programme autorisé puisse s'en servir. Programme autorisé càd enregistré comme déboggeur, il y a déjà en fait une liste des déboggueurs installés pour que Windows sache à quelle appli passer la main en cas d'erreur fatale. Il faudrait gérer cela comme la liste des autorité de certificat qu'aucun programme ne peut modifier de manière silencieuse, car c'est un service qui affiche le dialogue de confirmation quand on en ajoute une. Il est clair que la seule raison pour laquelle ce n'est pas encore beaucoup attaqué est que d'autres failles pour les Black Hat ont un meilleur rapport effort/résultat. Une grande question est jusqu'à quel point ce type d'attaque est transportable sous Linux ? Parceque quand on voit cela on se dit mais qu'est-ce qu'il sont cons chez Microsoft d'autoriser des trucs pareils, mais est-ce vraiment infaisable sous d'autres OS ? Il faudrait passer par /proc/pid/mem et ça serait beaucoup plus délicat, mais il y a certainement des possibilités d'exploit aussi. Et en fait, gdb n'a pas besoin de privilèges particuliers pour faire un 'attach' et manipuler un peu ce qu'il veut sur un autre processus de l'utilisateur.
Cedric Blancher wrote:
Bref, comme ça était dit récemment lors d'un conférence de sécurité,
le poste de l'utilisateur lambda est mort, et les gens vont devoir s'y
faire (i.e. prendre en compte cet état de fait) s'ils veulent avancer un
peu en matière de sécurité des accès sensibles comme les portails
bancaires et proposer des trucs qui tiennent vraiment la route...
Si on part du principe que le poste de l'utilisateur ne peut être
sécurisé, tout s'arrête et on rentre à la maison.
Si c'est cela le point de départ, il n'y *aucun* moyen de proposer
quelquechose qui tient la route à moins de dire qu'un PC ne sert à rien
d'autre que des jeux, et que les opérations sécurisées on les fait sur
"autre chose".
Mais cet "autre chose" sera finalement un ordinateur à part entière,
donc il s'agit de reconstruire une architecture d'ordinateur personnel
en évitant les erreurs que l'on a fait sur les PC pour la sécurité.
On est sur cette orientation aussi loin de la solution au problème que
si on part sur l'approche "on va corriger les erreurs de l'architecture
PC jusqu'à pourvoir en faire une plate-forme solide".
Ne reste guère dans l'immédiat qu'à prendre toutes ses attaques une par
une et à les résoudre :
- exe caché dans un zip chiffré/extension modifiée : Ici on se raproche
du "social engineering". L'attaque ne marche que avec la collaboration
de l'utilisateur, et il faudra travailler sur la sensibilisation des
utilisateurs à ces problèmes. A un premier niveau, on peut renforcer le
filtrage (virer les zip chiffrés, virer les pièces jointe de type
inconnu) *et* mettre en place une solution de secours bien balisée pour
les utilisations légitimes génées par ces filtrages.
- Exe dans fichier word : je connais pas bien ce problème mais
fondamentalement c'est un bug d'auto-interprétation que MSFT peut régler
s'ils se bougent, non ?
- Active X signés : Toute la sécurité repose sur à qui on donne un
certificat de signature. Déjà, si on signale à Verisign qu'un certificat
est utilisée abusivement, il est révoquée, et un grand nombre d'install
de Windows sont configurées pour télécharger cette crl automatiquement
(la BP utilisée pour cela sur le site de Verisign se compte en gbit/s).
L'erreur cependant ici est d'être parti sur un modèle où les vendeurs de
certificats de signature cherche à faire de l'argent, donc évitent de
prendre des responsabilités, et cherche à en vendre beaucoup. Il faut
passer à un modèle où l'on ne donne un certificat à une entitée qu'après
un niveau d'authentification qui garanti qu'on aura quelqu'un de à
traduire en justice et faire raquer un max en cas d'abus.
- page web exécutant un active X en mode local : SP2 contre-attaque
précisément sur cela en l'interdisant. Outlook pourrait ajouter la "Mark
of the Web" sur les pages enregistrées depuis la messagerie.
- OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6
ans que ce problème est connu en fait et que les black hat ne l'ont
guère exploité.
Ces fonctions ont été ajoutées à l'API Windows pour l'usage des
debuggeurs, il faudrait vraiment que Microsoft se décide à faire en
sorte que seul un admin ou mieux seul un programme autorisé puisse s'en
servir. Programme autorisé càd enregistré comme déboggeur, il y a déjà
en fait une liste des déboggueurs installés pour que Windows sache à
quelle appli passer la main en cas d'erreur fatale. Il faudrait gérer
cela comme la liste des autorité de certificat qu'aucun programme ne
peut modifier de manière silencieuse, car c'est un service qui affiche
le dialogue de confirmation quand on en ajoute une.
Il est clair que la seule raison pour laquelle ce n'est pas encore
beaucoup attaqué est que d'autres failles pour les Black Hat ont un
meilleur rapport effort/résultat.
Une grande question est jusqu'à quel point ce type d'attaque est
transportable sous Linux ? Parceque quand on voit cela on se dit mais
qu'est-ce qu'il sont cons chez Microsoft d'autoriser des trucs pareils,
mais est-ce vraiment infaisable sous d'autres OS ? Il faudrait passer
par /proc/pid/mem et ça serait beaucoup plus délicat, mais il y a
certainement des possibilités d'exploit aussi. Et en fait, gdb n'a pas
besoin de privilèges particuliers pour faire un 'attach' et manipuler un
peu ce qu'il veut sur un autre processus de l'utilisateur.
Bref, comme ça était dit récemment lors d'un conférence de sécurité, le poste de l'utilisateur lambda est mort, et les gens vont devoir s'y faire (i.e. prendre en compte cet état de fait) s'ils veulent avancer un peu en matière de sécurité des accès sensibles comme les portails bancaires et proposer des trucs qui tiennent vraiment la route...
Si on part du principe que le poste de l'utilisateur ne peut être sécurisé, tout s'arrête et on rentre à la maison. Si c'est cela le point de départ, il n'y *aucun* moyen de proposer quelquechose qui tient la route à moins de dire qu'un PC ne sert à rien d'autre que des jeux, et que les opérations sécurisées on les fait sur "autre chose".
Mais cet "autre chose" sera finalement un ordinateur à part entière, donc il s'agit de reconstruire une architecture d'ordinateur personnel en évitant les erreurs que l'on a fait sur les PC pour la sécurité.
On est sur cette orientation aussi loin de la solution au problème que si on part sur l'approche "on va corriger les erreurs de l'architecture PC jusqu'à pourvoir en faire une plate-forme solide".
Ne reste guère dans l'immédiat qu'à prendre toutes ses attaques une par une et à les résoudre :
- exe caché dans un zip chiffré/extension modifiée : Ici on se raproche du "social engineering". L'attaque ne marche que avec la collaboration de l'utilisateur, et il faudra travailler sur la sensibilisation des utilisateurs à ces problèmes. A un premier niveau, on peut renforcer le filtrage (virer les zip chiffrés, virer les pièces jointe de type inconnu) *et* mettre en place une solution de secours bien balisée pour les utilisations légitimes génées par ces filtrages.
- Exe dans fichier word : je connais pas bien ce problème mais fondamentalement c'est un bug d'auto-interprétation que MSFT peut régler s'ils se bougent, non ?
- Active X signés : Toute la sécurité repose sur à qui on donne un certificat de signature. Déjà, si on signale à Verisign qu'un certificat est utilisée abusivement, il est révoquée, et un grand nombre d'install de Windows sont configurées pour télécharger cette crl automatiquement (la BP utilisée pour cela sur le site de Verisign se compte en gbit/s). L'erreur cependant ici est d'être parti sur un modèle où les vendeurs de certificats de signature cherche à faire de l'argent, donc évitent de prendre des responsabilités, et cherche à en vendre beaucoup. Il faut passer à un modèle où l'on ne donne un certificat à une entitée qu'après un niveau d'authentification qui garanti qu'on aura quelqu'un de à traduire en justice et faire raquer un max en cas d'abus.
- page web exécutant un active X en mode local : SP2 contre-attaque précisément sur cela en l'interdisant. Outlook pourrait ajouter la "Mark of the Web" sur les pages enregistrées depuis la messagerie.
- OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6 ans que ce problème est connu en fait et que les black hat ne l'ont guère exploité. Ces fonctions ont été ajoutées à l'API Windows pour l'usage des debuggeurs, il faudrait vraiment que Microsoft se décide à faire en sorte que seul un admin ou mieux seul un programme autorisé puisse s'en servir. Programme autorisé càd enregistré comme déboggeur, il y a déjà en fait une liste des déboggueurs installés pour que Windows sache à quelle appli passer la main en cas d'erreur fatale. Il faudrait gérer cela comme la liste des autorité de certificat qu'aucun programme ne peut modifier de manière silencieuse, car c'est un service qui affiche le dialogue de confirmation quand on en ajoute une. Il est clair que la seule raison pour laquelle ce n'est pas encore beaucoup attaqué est que d'autres failles pour les Black Hat ont un meilleur rapport effort/résultat. Une grande question est jusqu'à quel point ce type d'attaque est transportable sous Linux ? Parceque quand on voit cela on se dit mais qu'est-ce qu'il sont cons chez Microsoft d'autoriser des trucs pareils, mais est-ce vraiment infaisable sous d'autres OS ? Il faudrait passer par /proc/pid/mem et ça serait beaucoup plus délicat, mais il y a certainement des possibilités d'exploit aussi. Et en fait, gdb n'a pas besoin de privilèges particuliers pour faire un 'attach' et manipuler un peu ce qu'il veut sur un autre processus de l'utilisateur.
Cedric Blancher
Le Thu, 21 Jul 2005 17:09:48 +0000, Jean-Marc Desperrier a écrit :
Si on part du principe que le poste de l'utilisateur ne peut être sécurisé, tout s'arrête et on rentre à la maison. Si c'est cela le point de départ, il n'y *aucun* moyen de proposer quelquechose qui tient la route à moins de dire qu'un PC ne sert à rien d'autre que des jeux, et que les opérations sécurisées on les fait sur "autre chose".
Pas forcément. Par exemple, le simple fait de fournir à l'utilisateur un token générateur de mots de passe jetables ou d'authentification par certificat sur carte à puce réduit à néant tout tentative de fishing et oblige l'attaquant à passer à une attaque active, synchronisée avec la session de l'utilisateur pour l'hijacker complètement, ce qui implique pas mal de conditions à réaliser. Avec un certificat client, on règle également le problème du MiM dans la mesure où l'attaquant ne peut pas présenter au serveur le bon certificat. Et ce serveur n'a pas un M. Michu pour cliquer sur "Accepter", il refuse point à la ligne. Tu me diras, oui, mais on sait extraire les clés privées d'un certificat logiciel et on peut capturer la passphrase. OK, d'où le certificat sur carte à puce.
Aujourd'hui, la banque rejette la responsabilité entière sur le client. Les crédences sont expédiées par courrier simple facilement identifiable, l'identifiant est présent sur tous les relevés de compte (eux aussi facilement identifiables), la taille des mots de passe est limitée à 6 ou 5 caractères quand ce n'est pas des chiffres (!?), mais c'est pas grave, le client reste responsable de la protection de ces crédence. Rien que ça devrait faire tiquer, non ?
- OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6 ans que ce problème est connu en fait et que les black hat ne l'ont guère exploité.
Les Blackhat peut-être pas, mais les développeurs de spywares les utilisent. De plus en plus de keyloggers utilisent cette technique, ainsi que des sniffers. Je ne crois pas non plus me tromper (Nicob me corrigera) en disant que le gang Dumaru lance régulièrement dans la nature des bots qui utilisent ces techniques. Ce n'est pas parce qu'on n'a pas eu notre API Hooking compliant Blaster-like ou que les outils ne courent pas les rues que des gens ne s'en servent pas. De toute manière, ce n'est pas non plus très étonnant qu'on en voit pas tant que ça. Il est tellement plus simple d'installer des Browser Helpers Objects :) Cf. :
Les gars qui codent ça ne recherchent pas l'excellence, mais l'efficacité. Si un BHO suffit, pourquoi utiliser de l'API hooking ?
-- Je vais mettre Mouse Office pour voir combien de kilomètres je parcours entre 2 changements de scotch et nettoyage de boule. Même dans le domaine du petit bricolage, il faut savoir rester rigoureux. :-) -+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Le Thu, 21 Jul 2005 17:09:48 +0000, Jean-Marc Desperrier a écrit :
Si on part du principe que le poste de l'utilisateur ne peut être
sécurisé, tout s'arrête et on rentre à la maison.
Si c'est cela le point de départ, il n'y *aucun* moyen de proposer
quelquechose qui tient la route à moins de dire qu'un PC ne sert à rien
d'autre que des jeux, et que les opérations sécurisées on les fait sur
"autre chose".
Pas forcément.
Par exemple, le simple fait de fournir à l'utilisateur un token
générateur de mots de passe jetables ou d'authentification par
certificat sur carte à puce réduit à néant tout tentative de fishing
et oblige l'attaquant à passer à une attaque active, synchronisée avec
la session de l'utilisateur pour l'hijacker complètement, ce qui implique
pas mal de conditions à réaliser.
Avec un certificat client, on règle également le problème du MiM dans
la mesure où l'attaquant ne peut pas présenter au serveur le bon
certificat. Et ce serveur n'a pas un M. Michu pour cliquer sur "Accepter",
il refuse point à la ligne. Tu me diras, oui, mais on sait extraire les
clés privées d'un certificat logiciel et on peut capturer la passphrase.
OK, d'où le certificat sur carte à puce.
Aujourd'hui, la banque rejette la responsabilité entière sur le client.
Les crédences sont expédiées par courrier simple facilement
identifiable, l'identifiant est présent sur tous les relevés de compte
(eux aussi facilement identifiables), la taille des mots de passe est
limitée à 6 ou 5 caractères quand ce n'est pas des chiffres (!?), mais
c'est pas grave, le client reste responsable de la protection de ces
crédence. Rien que ça devrait faire tiquer, non ?
- OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6
ans que ce problème est connu en fait et que les black hat ne l'ont
guère exploité.
Les Blackhat peut-être pas, mais les développeurs de spywares les
utilisent. De plus en plus de keyloggers utilisent cette technique, ainsi
que des sniffers. Je ne crois pas non plus me tromper (Nicob me corrigera)
en disant que le gang Dumaru lance régulièrement dans la nature des bots
qui utilisent ces techniques.
Ce n'est pas parce qu'on n'a pas eu notre API Hooking compliant
Blaster-like ou que les outils ne courent pas les rues que des gens ne
s'en servent pas. De toute manière, ce n'est pas non plus très étonnant
qu'on en voit pas tant que ça. Il est tellement plus simple d'installer
des Browser Helpers Objects :) Cf. :
Les gars qui codent ça ne recherchent pas l'excellence, mais
l'efficacité. Si un BHO suffit, pourquoi utiliser de l'API hooking ?
--
Je vais mettre Mouse Office pour voir combien de kilomètres je parcours
entre 2 changements de scotch et nettoyage de boule. Même dans le
domaine du petit bricolage, il faut savoir rester rigoureux. :-)
-+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Le Thu, 21 Jul 2005 17:09:48 +0000, Jean-Marc Desperrier a écrit :
Si on part du principe que le poste de l'utilisateur ne peut être sécurisé, tout s'arrête et on rentre à la maison. Si c'est cela le point de départ, il n'y *aucun* moyen de proposer quelquechose qui tient la route à moins de dire qu'un PC ne sert à rien d'autre que des jeux, et que les opérations sécurisées on les fait sur "autre chose".
Pas forcément. Par exemple, le simple fait de fournir à l'utilisateur un token générateur de mots de passe jetables ou d'authentification par certificat sur carte à puce réduit à néant tout tentative de fishing et oblige l'attaquant à passer à une attaque active, synchronisée avec la session de l'utilisateur pour l'hijacker complètement, ce qui implique pas mal de conditions à réaliser. Avec un certificat client, on règle également le problème du MiM dans la mesure où l'attaquant ne peut pas présenter au serveur le bon certificat. Et ce serveur n'a pas un M. Michu pour cliquer sur "Accepter", il refuse point à la ligne. Tu me diras, oui, mais on sait extraire les clés privées d'un certificat logiciel et on peut capturer la passphrase. OK, d'où le certificat sur carte à puce.
Aujourd'hui, la banque rejette la responsabilité entière sur le client. Les crédences sont expédiées par courrier simple facilement identifiable, l'identifiant est présent sur tous les relevés de compte (eux aussi facilement identifiables), la taille des mots de passe est limitée à 6 ou 5 caractères quand ce n'est pas des chiffres (!?), mais c'est pas grave, le client reste responsable de la protection de ces crédence. Rien que ça devrait faire tiquer, non ?
- OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6 ans que ce problème est connu en fait et que les black hat ne l'ont guère exploité.
Les Blackhat peut-être pas, mais les développeurs de spywares les utilisent. De plus en plus de keyloggers utilisent cette technique, ainsi que des sniffers. Je ne crois pas non plus me tromper (Nicob me corrigera) en disant que le gang Dumaru lance régulièrement dans la nature des bots qui utilisent ces techniques. Ce n'est pas parce qu'on n'a pas eu notre API Hooking compliant Blaster-like ou que les outils ne courent pas les rues que des gens ne s'en servent pas. De toute manière, ce n'est pas non plus très étonnant qu'on en voit pas tant que ça. Il est tellement plus simple d'installer des Browser Helpers Objects :) Cf. :
Les gars qui codent ça ne recherchent pas l'excellence, mais l'efficacité. Si un BHO suffit, pourquoi utiliser de l'API hooking ?
-- Je vais mettre Mouse Office pour voir combien de kilomètres je parcours entre 2 changements de scotch et nettoyage de boule. Même dans le domaine du petit bricolage, il faut savoir rester rigoureux. :-) -+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Nicob
On Thu, 21 Jul 2005 17:09:48 +0000, Jean-Marc Desperrier wrote:
OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6 ans que ce problème est connu en fait et que les black hat ne l'ont guère exploité.
Ca fait au moins 7 à 8 ans que des malwares (du genre "à diffusion restreinte" et/ou "attaques ciblées") utilisent CreateRemoteThread(). Je dirais donc plutôt que ce n'est pas les kiddies (plutôt que black-hats) qui n'ont guère exploité cette fonctionnalité.
Nicob
On Thu, 21 Jul 2005 17:09:48 +0000, Jean-Marc Desperrier wrote:
OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6
ans que ce problème est connu en fait et que les black hat ne l'ont
guère exploité.
Ca fait au moins 7 à 8 ans que des malwares (du genre "à diffusion
restreinte" et/ou "attaques ciblées") utilisent CreateRemoteThread(). Je
dirais donc plutôt que ce n'est pas les kiddies (plutôt que black-hats)
qui n'ont guère exploité cette fonctionnalité.
On Thu, 21 Jul 2005 17:09:48 +0000, Jean-Marc Desperrier wrote:
OpenProcess / WriteProcessMemory / CreateRemoteThread : Ca fait 5 ou 6 ans que ce problème est connu en fait et que les black hat ne l'ont guère exploité.
Ca fait au moins 7 à 8 ans que des malwares (du genre "à diffusion restreinte" et/ou "attaques ciblées") utilisent CreateRemoteThread(). Je dirais donc plutôt que ce n'est pas les kiddies (plutôt que black-hats) qui n'ont guère exploité cette fonctionnalité.
