l'accès à PayPal depuis les liens disponibles sur les pages eBay (tel
les liens "Afficher la transaction PayPal") sont actuellement vérolés.
ces liens conduisent au vrai site PayPal où les noms (email) et mot de
passe sont saisis, puis *quelque soit le mot de passe saisi* un
formulaire pirate est affiché.
ce formulaire apparait en anglais même si vous étiez sur PayPal France,
il vous demande notamment le code PIN de votre carte bancaire et votre
numéro de sécurité sociale.
il apparait de plus correctement servi en SSL par PayPal, pour autant il
ne peut être que ILLEGALE.
ce type d'attaque était récemment discuté ici (fr.comp.securité), il est
navrant (pas peu surprenant) de constater que PayPal ne se protège pas
mieux.
Le Tue, 03 Jun 2008 09:10:17 +0000, Paul Gaborit a écrit :
À (at) 02 Jun 2008 22:20:17 GMT, j'écrivais :
Quant aux grosses boites, en général, je veux bien le croire... Mais pour celles dont toute l'activité dépend uniquement d'internet et donc de leurs serveurs, je pense (naïvement peut-être) qu'ils ont effectivement investi en sécurité/surveillance avec des équipes efficaces au moins pour détecter ce qui se passer sur leurs propres sites.
Il semble bien que j'étais naïf...
;)
Le problème est que j'ai l'impression que beaucoup supposent qu'un admin réseau est nécessairement compétant en sécu. Or non seulement ce n'est pas le cas, mais en plus la sécu du réseau elle même n'est qu'une petite partie de celle du SI. Va simplement jetter un oeil sur un unix un peu ancien (ie il ne vient pas d'être installé à partir d'une distrib récente) au niveau des perms (répertoires et suid root par exemple) c'est généralement assez édifiant.
Tu ajoutes les softs créés par des boites sans aucune notions de sécu, les failles diverses et variées des kernels, les faiblesses inhérentes de certains protocoles, les LANs modifiés à l'arrache et ça devient évident que ce n'est pas si facile que ça, même en étant compétant d'assurer une très bonne sécurité dans le monde réel (celui où on doit faire des compromis ;) ).
En parlant de facilité, le social engineering reste quand même très accessible. Avec des infos très partielles (ligne téléphonique, nom du titulaire et sans adresse complète ni aucun autre document) je me suis fait fournir les identifiants et mots de passe complets complets de compte et d'accès ADSL d'un client chez un FAI de premier plan. Là c'était pour la "bonne cause" mais aucun des intervenant que j'ai eu n'a penser à sécuriser la procédure (questions complémentaires sur le dossier ou callback). Pire, à une étape (celle ou j'ai obtenu les identifiants mais où mon interlocutrice n'avait pas les passwords) on m'a donné des informations supplémentaires (genre numéro de dossier interne, mais je resterais vague pour qu'on ne puisse identifier le FAI) et un numéro de téléphone pour continuer ma demande!
Bref, ça fout la trouille (c)
Le Tue, 03 Jun 2008 09:10:17 +0000, Paul Gaborit a écrit :
À (at) 02 Jun 2008 22:20:17 GMT, j'écrivais :
Quant aux grosses boites, en général, je veux bien le croire... Mais
pour celles dont toute l'activité dépend uniquement d'internet et donc
de leurs serveurs, je pense (naïvement peut-être) qu'ils ont
effectivement investi en sécurité/surveillance avec des équipes
efficaces au moins pour détecter ce qui se passer sur leurs propres
sites.
Il semble bien que j'étais naïf...
;)
Le problème est que j'ai l'impression que beaucoup supposent qu'un admin
réseau est nécessairement compétant en sécu. Or non seulement ce n'est
pas le cas, mais en plus la sécu du réseau elle même n'est qu'une
petite partie de celle du SI. Va simplement jetter un oeil sur un unix un
peu ancien (ie il ne vient pas d'être installé à partir d'une distrib
récente) au niveau des perms (répertoires et suid root par exemple)
c'est généralement assez édifiant.
Tu ajoutes les softs créés par des boites sans aucune notions de sécu,
les failles diverses et variées des kernels, les faiblesses inhérentes
de certains protocoles, les LANs modifiés à l'arrache et ça devient
évident que ce n'est pas si facile que ça, même en étant compétant
d'assurer une très bonne sécurité dans le monde réel (celui où on
doit faire des compromis ;) ).
En parlant de facilité, le social engineering reste quand même très
accessible. Avec des infos très partielles (ligne téléphonique, nom du
titulaire et sans adresse complète ni aucun autre document) je me suis
fait fournir les identifiants et mots de passe complets complets de compte
et d'accès ADSL d'un client chez un FAI de premier plan. Là c'était
pour la "bonne cause" mais aucun des intervenant que j'ai eu n'a penser à
sécuriser la procédure (questions complémentaires sur le dossier ou
callback). Pire, à une étape (celle ou j'ai obtenu les identifiants mais
où mon interlocutrice n'avait pas les passwords) on m'a donné des
informations supplémentaires (genre numéro de dossier interne, mais je
resterais vague pour qu'on ne puisse identifier le FAI) et un numéro de
téléphone pour continuer ma demande!
Le Tue, 03 Jun 2008 09:10:17 +0000, Paul Gaborit a écrit :
À (at) 02 Jun 2008 22:20:17 GMT, j'écrivais :
Quant aux grosses boites, en général, je veux bien le croire... Mais pour celles dont toute l'activité dépend uniquement d'internet et donc de leurs serveurs, je pense (naïvement peut-être) qu'ils ont effectivement investi en sécurité/surveillance avec des équipes efficaces au moins pour détecter ce qui se passer sur leurs propres sites.
Il semble bien que j'étais naïf...
;)
Le problème est que j'ai l'impression que beaucoup supposent qu'un admin réseau est nécessairement compétant en sécu. Or non seulement ce n'est pas le cas, mais en plus la sécu du réseau elle même n'est qu'une petite partie de celle du SI. Va simplement jetter un oeil sur un unix un peu ancien (ie il ne vient pas d'être installé à partir d'une distrib récente) au niveau des perms (répertoires et suid root par exemple) c'est généralement assez édifiant.
Tu ajoutes les softs créés par des boites sans aucune notions de sécu, les failles diverses et variées des kernels, les faiblesses inhérentes de certains protocoles, les LANs modifiés à l'arrache et ça devient évident que ce n'est pas si facile que ça, même en étant compétant d'assurer une très bonne sécurité dans le monde réel (celui où on doit faire des compromis ;) ).
En parlant de facilité, le social engineering reste quand même très accessible. Avec des infos très partielles (ligne téléphonique, nom du titulaire et sans adresse complète ni aucun autre document) je me suis fait fournir les identifiants et mots de passe complets complets de compte et d'accès ADSL d'un client chez un FAI de premier plan. Là c'était pour la "bonne cause" mais aucun des intervenant que j'ai eu n'a penser à sécuriser la procédure (questions complémentaires sur le dossier ou callback). Pire, à une étape (celle ou j'ai obtenu les identifiants mais où mon interlocutrice n'avait pas les passwords) on m'a donné des informations supplémentaires (genre numéro de dossier interne, mais je resterais vague pour qu'on ne puisse identifier le FAI) et un numéro de téléphone pour continuer ma demande!
Bref, ça fout la trouille (c)
Stephane Catteau
Pascal Hambourg devait dire quelque chose comme ceci :
2) Renvoyer sur une autre adresse local ne marche pas sur tous les systèmes, certains nunux la traduisant automatiquement en 127.0.0.1
Jamais vu ça. Tu aurais un exemple ?
J'aimerais pouvoir répondre "oui", mais j'ai beau me creuser la tête, je n'arrive pas à me souvenir dans quelle version de quelle distrib' j'avais vu ça. Seul le fait lui-même m'a marqué tellement il était hallucinant.
Pascal Hambourg devait dire quelque chose comme ceci :
2) Renvoyer sur une autre adresse local ne marche pas sur tous les
systèmes, certains nunux la traduisant automatiquement en 127.0.0.1
Jamais vu ça. Tu aurais un exemple ?
J'aimerais pouvoir répondre "oui", mais j'ai beau me creuser la tête,
je n'arrive pas à me souvenir dans quelle version de quelle distrib'
j'avais vu ça. Seul le fait lui-même m'a marqué tellement il était
hallucinant.
Pascal Hambourg devait dire quelque chose comme ceci :
2) Renvoyer sur une autre adresse local ne marche pas sur tous les systèmes, certains nunux la traduisant automatiquement en 127.0.0.1
Jamais vu ça. Tu aurais un exemple ?
J'aimerais pouvoir répondre "oui", mais j'ai beau me creuser la tête, je n'arrive pas à me souvenir dans quelle version de quelle distrib' j'avais vu ça. Seul le fait lui-même m'a marqué tellement il était hallucinant.
Stephane Catteau
Pascal Hambourg devait dire quelque chose comme ceci :
:/d2b/tth/Essais/Csound$ uname -a Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux :/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime Trying 127.0.0.1... Connected to 127.0.0.1. Sun Jun 8 13:48:12 2008 :/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime Trying 127.0.0.2... Connected to 127.0.0.2. Sun Jun 8 13:48:21 2008
Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en 127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2.
Il faudrait voir la configuration exacte utilisé, mais je constates quand même que daytime répond sur 127.0.0.2, ce qui semble "idiot". Le problème ici n'est *peut-être* pas le fait que le système transforme 127.0.0.2 en 127.0.0.1 lors d'une requête, mais qu'il transforme un 127.a.b.c en 127/8 lorsque le serveur est bindé, le faisant alors écouter sur tous les ports.
La question est donc : pourquoi Linux fait-il cela ? Le problème vient du masque du loopback (255.0.0.0), mais quel est le comportement 'officiel' ?
Lorsqu'on configure une adresse et un masque de sous-réseau IP à l'interface de loopback, Linux considère que tout le sous-réseau est une destination locale, et pas seulement l'adresse configurée. Donc quand on configure 127.0.0.1/8 sur l'interface de loopback, tout 127.0.0.0/8 est considéré comme une destination locale, et pas seulement 127.0.0.1.
Ce qui me semble excessif. Dans l'absolue il ne peut y avoir qu'une adresse par interface (et l'interface de loopback en est une), les autres devant être déclarées comme alias. Linux n'a aucune raison de se comporter autrement pour l'interface de loopback.
Par conséquent une socket qui écoute sur 0.0.0.0 (toutes les adresses locales)
0/8, ce n'est pas plutôt l'adresse interne de la pile IP ?
Je pense qu'il n'y a pas de comportement officiel. RFC 3330 stipule seulement :
" 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host.
En fait, j'ai l'impression que les gars qui se sont occupés de l'interface loopback de Linux se sont arrêtés là ("Un datagram envoyé par un protocole de haut niveau à une adresse n'importe où dans ce bloc devrait boucler à l'interieur de la machine".)
En prenant la phrase littéralement, une requête faite à destination de n'importe quelle adresse en 127/8 devrait tomber sur le serveur en écoute sur l'interface loopback, même si la configuration de celui-ci lui dit de n'écouter que sur 127.0.0.1/32.
This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere."
Alors que ceux qui se sont occupés de l'interface loopback BSD ont, eux, utilisés cette phrase ("Cela est généralement implémenté en utilisant seulement 127.0.0.1/32 comme loopback, mais aucune adresse dans ce bloc devrait apparaître autre part sur le réseau.")
Ce qui revient aux commportements constatés par Thierry et JKB.
Pascal Hambourg devait dire quelque chose comme ceci :
tth@flo:/d2b/tth/Essais/Csound$ uname -a
Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
tth@flo:/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Sun Jun 8 13:48:12 2008
tth@flo:/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime
Trying 127.0.0.2...
Connected to 127.0.0.2.
Sun Jun 8 13:48:21 2008
Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en
127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2.
Il faudrait voir la configuration exacte utilisé, mais je constates
quand même que daytime répond sur 127.0.0.2, ce qui semble "idiot". Le
problème ici n'est *peut-être* pas le fait que le système transforme
127.0.0.2 en 127.0.0.1 lors d'une requête, mais qu'il transforme un
127.a.b.c en 127/8 lorsque le serveur est bindé, le faisant alors
écouter sur tous les ports.
La question est donc : pourquoi Linux fait-il cela ? Le problème
vient du masque du loopback (255.0.0.0), mais quel est le
comportement 'officiel' ?
Lorsqu'on configure une adresse et un masque de sous-réseau IP à
l'interface de loopback, Linux considère que tout le sous-réseau est une
destination locale, et pas seulement l'adresse configurée. Donc quand on
configure 127.0.0.1/8 sur l'interface de loopback, tout 127.0.0.0/8 est
considéré comme une destination locale, et pas seulement 127.0.0.1.
Ce qui me semble excessif. Dans l'absolue il ne peut y avoir qu'une
adresse par interface (et l'interface de loopback en est une), les
autres devant être déclarées comme alias. Linux n'a aucune raison de se
comporter autrement pour l'interface de loopback.
Par conséquent une socket qui écoute sur 0.0.0.0 (toutes les adresses
locales)
0/8, ce n'est pas plutôt l'adresse interne de la pile IP ?
Je pense qu'il n'y a pas de comportement officiel. RFC 3330 stipule
seulement :
" 127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
En fait, j'ai l'impression que les gars qui se sont occupés de
l'interface loopback de Linux se sont arrêtés là ("Un datagram envoyé
par un protocole de haut niveau à une adresse n'importe où dans ce bloc
devrait boucler à l'interieur de la machine".)
En prenant la phrase littéralement, une requête faite à destination de
n'importe quelle adresse en 127/8 devrait tomber sur le serveur en
écoute sur l'interface loopback, même si la configuration de celui-ci
lui dit de n'écouter que sur 127.0.0.1/32.
This is ordinarily implemented using only 127.0.0.1/32 for loopback, but
no addresses within this block should ever appear on any network anywhere."
Alors que ceux qui se sont occupés de l'interface loopback BSD ont,
eux, utilisés cette phrase ("Cela est généralement implémenté en
utilisant seulement 127.0.0.1/32 comme loopback, mais aucune adresse
dans ce bloc devrait apparaître autre part sur le réseau.")
Ce qui revient aux commportements constatés par Thierry et JKB.
Pascal Hambourg devait dire quelque chose comme ceci :
:/d2b/tth/Essais/Csound$ uname -a Linux flo 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux :/d2b/tth/Essais/Csound$ telnet 127.0.0.1 daytime Trying 127.0.0.1... Connected to 127.0.0.1. Sun Jun 8 13:48:12 2008 :/d2b/tth/Essais/Csound$ telnet 127.0.0.2 daytime Trying 127.0.0.2... Connected to 127.0.0.2. Sun Jun 8 13:48:21 2008
Et en quoi cela permet-il de conclure que Linux traduit 127.0.0.2 en 127.0.0.1 ? Tout ce que je vois, c'est une connexion à 127.0.0.2.
Il faudrait voir la configuration exacte utilisé, mais je constates quand même que daytime répond sur 127.0.0.2, ce qui semble "idiot". Le problème ici n'est *peut-être* pas le fait que le système transforme 127.0.0.2 en 127.0.0.1 lors d'une requête, mais qu'il transforme un 127.a.b.c en 127/8 lorsque le serveur est bindé, le faisant alors écouter sur tous les ports.
La question est donc : pourquoi Linux fait-il cela ? Le problème vient du masque du loopback (255.0.0.0), mais quel est le comportement 'officiel' ?
Lorsqu'on configure une adresse et un masque de sous-réseau IP à l'interface de loopback, Linux considère que tout le sous-réseau est une destination locale, et pas seulement l'adresse configurée. Donc quand on configure 127.0.0.1/8 sur l'interface de loopback, tout 127.0.0.0/8 est considéré comme une destination locale, et pas seulement 127.0.0.1.
Ce qui me semble excessif. Dans l'absolue il ne peut y avoir qu'une adresse par interface (et l'interface de loopback en est une), les autres devant être déclarées comme alias. Linux n'a aucune raison de se comporter autrement pour l'interface de loopback.
Par conséquent une socket qui écoute sur 0.0.0.0 (toutes les adresses locales)
0/8, ce n'est pas plutôt l'adresse interne de la pile IP ?
Je pense qu'il n'y a pas de comportement officiel. RFC 3330 stipule seulement :
" 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host.
En fait, j'ai l'impression que les gars qui se sont occupés de l'interface loopback de Linux se sont arrêtés là ("Un datagram envoyé par un protocole de haut niveau à une adresse n'importe où dans ce bloc devrait boucler à l'interieur de la machine".)
En prenant la phrase littéralement, une requête faite à destination de n'importe quelle adresse en 127/8 devrait tomber sur le serveur en écoute sur l'interface loopback, même si la configuration de celui-ci lui dit de n'écouter que sur 127.0.0.1/32.
This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere."
Alors que ceux qui se sont occupés de l'interface loopback BSD ont, eux, utilisés cette phrase ("Cela est généralement implémenté en utilisant seulement 127.0.0.1/32 comme loopback, mais aucune adresse dans ce bloc devrait apparaître autre part sur le réseau.")
Ce qui revient aux commportements constatés par Thierry et JKB.
