Journal Surfez avec Internet Explorer et offrez vous un système de sauvegarde gratuit

Posté par  (site web personnel) .
Étiquettes : aucune
24
7
déc.
2009
Je vais partager avec vous une anecdote concernant Microsoft, Internet Explorer, et les données que le premier peut récolter avec le deuxième. Des informations (certaines adresses IP, les noms de fichier...) sont modifiées, mais l'histoire reste compréhensible.

Je souhaitais permettre à quelqu'un de télécharger des totos, je les ai donc posés sur mon serveur, et ajouté cette configuration dans Apache :

Alias /toto "/var/toto"
Directory "/var/toto"
AuthName toto
Require valid-user
/Directory


Pour ceux qui ne parlent pas la configuration Apache, j'indique que l'URL /toto pointe sur le dossier contenant les totos, et qu'il faut s'identifier pour y accéder.

J'indique l'URL et les identifiants à la personne, qui commence à télécharger des totos.

Ce matin, je regarde les logs Apache, et que vois-je ?

1.2.3.4 - toto [07/Dec/2009:05:30:31 +0100] "GET /toto/TOTO-TITI-02.zip HTTP/1.1" 200 1810155071 "http://url.com/toto/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 1.1.4322)"
208.50.101.155 - - [07/Dec/2009:05:57:55 +0100] "GET /toto/toto-titi-02.zip HTTP/1.1" 401 561 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"


La fin du tracepath vers 208.50.101.155 :

6: MSN-HOTMAIL.Gi3-7.ar4.LAX1.gblx.net (208.51.42.22) 141.841ms asymm 8
7: xe-3-0-0-0.lax-96cbe-1b.ntwk.msn.net (207.46.47.11) 146.395ms asymm 8
8: ge-3-2-0-0.sjc-64cb-1a.ntwk.msn.net (207.46.46.54) 168.917ms
9: ge-5-1-0-0.sn1-64cb-1b.ntwk.msn.net (207.46.46.86) 161.422ms
10: 207.46.46.104 (207.46.46.104) 154.348ms asymm 9
11: 208.50.101.146 (208.50.101.146) 188.222ms asymm 9
12: 208.50.101.155 (208.50.101.155) 185.519ms reached


Pour ceux qui ne parlent pas le log Apache ou le tracepath, la personne a téléchargé un des fichiers que je mettais à sa disposition avec IE8. 27 minutes plus tard, une adresse, qui d'après ce que j'ai trouvé se situe aux États-Unis, et qui semble très fortement reliée à Microsoft, a tenté d'accéder au même fichier, mais avec le chemin en bas de casse, et s'est fait bouler par une demande d'authentification.

Que suis-je tenté de déduire de cette anecdote ?

  1. Microsoft récupère une partie (toutes ?) des URL que vous consultez et essaye d'y accéder discrétos de son côté
  2. Par contre ils sont trop bêtes pour pomper les identifiants nécessaires
  3. Ils n'ont toujours pas remarqué qu'il n'existe pas qu'une casse

Mais je dois être paranoïaque, en fait.
  • # AMHA

    Posté par  . Évalué à -6.

    le premier obtient bien un code 200 (OK)
    il provient de l'adresse 1.2.3.4 (ou alors c'est toi qui a modifier l'IP)

    le 2e obtient un 401 (Unauthorized) ce qui est normal


    apres il ne faut pas oublier que TOUS les moteurs de recherche (Microsoft comme Google ou autre...) parcourent les sites à la recherche de mise à jour afin d'indexer les contenus

    pour eviter cela il me semble qu'il faut mettre un fichier robot.txt (ou robots.txt)
    contenant certaines directives.
    • [^] # Re: AMHA

      Posté par  . Évalué à 10.

      je croyais que les robots étaient censés indexer les pages ayant des liens qui pointaient vers elles sur internet, pas les liens dans un courriel privé...

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: AMHA

        Posté par  (site web personnel) . Évalué à 2.

        Ça a changé depuis belle lurette, le premier à faire ça est google...

        Ça lui permet de facilement mettre à jour son index avec les nouveaux sites que les gens visitent.

        Et clairement ça coûte moins cher pour un moteur de recherche de pomper les urls de page des navigateur que de parcourir encore et encore tous les liens qu'ils ont en db, parser le html pourris et ainsi de suite...

        Par contre il ne se permettent pas de pomper tes accès, mais gare au session id qui se baladerais en url, paf => tes données sur le moteur de recherche si la session est mal protégée...
    • [^] # Re: AMHA

      Posté par  (site web personnel) . Évalué à 10.

      J'ai en effet modifié la ligne avec l'IP 1.2.3.4 pour cacher l'IP de la personne légitime. Elle obtient en effet un 200 mais ça c'est normal :)

      L'IP de Microsoft qui tente d'accéder au fichier ensuite n'a laissé que cette trace (aucun GET sur /, sur /toto/, uniquement le GET /toto/toto-titi-02.zip).

      Je suis régulièrement scanné par le bot msn, mais sur des URL que j'ai publiées, donc tout à fait normal.

      En revanche, cette URL /toto n'est accessible que depuis hier soir. Je ne l'ai publiée nul part. Cette nuit quelqu'un y accède avec IE8, puis y télécharge un fichier, et moins de 30 minutes après Microsoft tente de télécharger ce même fichier.
      • [^] # Re: AMHA

        Posté par  . Évalué à 10.

        L'outil antiphishing de d'IE8 récolte les URL et Microsoft peut vérifier les téléchargements :
        http://www.microsoft.com/security/filters/smartscreen.aspx
        http://windows.microsoft.com/en-US/windows-vista/SmartScreen(...)
        http://www.microsoft.com/windowsvista/privacy/default_ie.msp(...)

        Si l'outil n'est pas désactivé, ça vient de là j'imagine.
        • [^] # Re: AMHA

          Posté par  . Évalué à 10.

          Wow, très joli trouvaille !

          Premier lien :

          SmartScreen Filter is a feature in Internet Explorer 8 that helps you avoid socially engineered malware phishing Web sites and online fraud when you browse the Web.

          2è lien (la FAQ) :

          What information does SmartScreen Filter send to Microsoft?

          SmartScreen Filter uses an SSL (Secure Socket Layer) web connection to send website addresses to Microsoft. For more information about what data is sent and how it is used, go to the Internet Explorer Privacy Statement online.


          Bon, donc ça doit venir de là ...

          Dans le privacy statement :

          it first checks the address of the website you are visiting against a list of high traffic website addresses stored on your computer that are believed by Microsoft to be legitimate. Addresses that are not on the local list and the addresses of files you are downloading will be sent to Microsoft and checked against a frequently updated list of websites and downloads that have been reported to Microsoft as unsafe or suspicious.

          J'aime bien aussi le :

          To help protect your privacy, the information sent to Microsoft is encrypted.

          Oui, pour protéger votre vie privée de tout le monde excepté MS ...

          Bon, pour leur "défense", à priori c'est anonymisé avec un id aléatoire (sauf quand des identifiants sont dans l'URL bien sûr, mais ils n'en feront rien, c'est précisé dans le dernier lien) et c'est de l'opt in, donc à priori activé par l'utilisateur (qui, j'imagine, a cliqué sur OK au premier démarrage d'IE8 sans lire le message ...)
    • [^] # Re: AMHA

      Posté par  (site web personnel) . Évalué à 10.

      apres il ne faut pas oublier que TOUS les moteurs de recherche (Microsoft comme Google ou autre...) parcourent les sites à la recherche de mise à jour afin d'indexer les contenus

      Le problème semble être ici, que l'url vers toto n'a été communiquée qu'a la personne concernée et en aucun cas sur un accès publique qu'un moteur de recherche puisse trouver. Donc oui les moteurs parcourent les sites... mais pour ça ils passent par un point d'entrée... si aucun *liens* accessible ne pointent vers toto... il n'y a que l'explication de la transmission de l'url par IE.
    • [^] # Re: AMHA

      Posté par  . Évalué à 9.

      Rien à voir. Là, on voit bien que c'est un robot qui va lire EXACTEMENT à l'adresse que la personne à visitée. Un moteur de recherche se « contente » généralement de suivre des liens depuis d'autres sites (enfin, c'est pas exactement ça mais presque).

      Pour le 1.2.3.4, c'est lui qui a modifier (il allait pas balancer l'adresse d'un de ses potes qui utilisent encore IE quoi ^^).
      • [^] # Re: AMHA

        Posté par  (site web personnel) . Évalué à 6.

        il y avait une polémique identique avec les robots ms qui allaient voir les url pointé à travers de MSN.

        "La première sécurité est la liberté"

      • [^] # Re: AMHA

        Posté par  . Évalué à 2.

        D'ailleurs, les moteurs de recherche envoient les referrer au serveur, donc permettent de savoir d'où ils viennent, non?

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: AMHA

          Posté par  . Évalué à 0.

          Il me semble que c'est le navigateur lui-même qui envoie le referer au site lié.
          Ceci est parfois désactivable selon le navigateur et les extensions/plugins/mods mais certains sites bloquent les images (par exemple) si le referer n'est pas chez eux (liens directs) ou absent (marque-page).

          Source : R%C3%A9f%C3%A9rant
  • # hotmail?

    Posté par  (site web personnel) . Évalué à 10.

    commentaire purement technique, je ne cherche d'excuse a personne:

    Est-ce que ton ami amateur de totos n'aurait pas par hasard une adresse mail chez Hotmail ? Faut-il incriminer obligatoirement le navigateur, ou bien l'hébergeur de ses mails?

    (dans les deux cas on pointe sur la même boite au final, mais les implications sont différentes)
    • [^] # Re: hotmail?

      Posté par  (site web personnel) . Évalué à 7.

      Oui, je lui ai indiqué l'URL du dossier via MSN messenger (enfin Empathy de mon côté, mais du sien... :)) mais je précise que c'est l'URL du dossier (http://url.com/toto/). Et comme dit plus haut, je n'ai aucune trace d'un GET sur le dossier, uniquement le GET sur le fichier que la personne a téléchargé.
      • [^] # Re: hotmail?

        Posté par  (site web personnel) . Évalué à 4.

        Et ton pote il aurait pas publié ce lien?
        Genre à son pote qui kiffe aussi les totos?
      • [^] # Re: hotmail?

        Posté par  . Évalué à 10.

        je lui ai indiqué l'URL du dossier via MSN

        Et comme tout lecteur attentif du CLUF de Msn, tu ne dois en rien être étonné de ce qu'il vient de t'arriver. Utiliser Msn sans lire le cluf, c'est être con. Utiliser Msn après avoir lu le cluf, c'est être vraiment con.
        • [^] # Re: hotmail?

          Posté par  (site web personnel) . Évalué à 10.

          L'URL du fichier .zip n'a pas transité par MSN. MSN a deviné tout seul qu'il fallait ajouter le chemin d'un fichier existant, mais en bas de casse ? :-)
      • [^] # Re: hotmail?

        Posté par  (site web personnel) . Évalué à 4.

        Ca me fait penser au journal MSN search utilise t'il les URL qui transitent sur MSN messenger ?
        http://linuxfr.org/~dawar/16034.html
        • [^] # Re: hotmail?

          Posté par  . Évalué à 4.

          J'avais constaté plusieurs fois ce phénomène, il y a quelques années (à l'époque où j'avais un compte MSN).

          J'avais même fait un tout petit test en activant un serveur FTP. Dans les 2 minutes qui suivaient la publication du lien FTP sur MSN il y avait un hit qui suivait.
          C'était systématique à l'époque. J'ignore si c'est toujours le cas mais c'est simple à tester et à vérifier.

          Maintenant cela doit être caché dans les conditions d'utilisation du service MSN non ?
    • [^] # Re: hotmail?

      Posté par  . Évalué à 1.

      Peut être que l'antivirus/antiphising de MSN analyse les cibles des URL en plus de fichiers joints?
      • [^] # Re: hotmail?

        Posté par  . Évalué à 5.

        Encore une fois, il a envoyé : « site.tld/toto » et le robot est venu fouiller à « site.tld/toto/tot-titi.zip ».

        La 2nde adresse n'a été utilisé que par la personne avec IE8
        • [^] # Re: hotmail?

          Posté par  . Évalué à 2.

          Et comment le client a pu connaître site.tld/toto/tot-titi.zip directement si ce n'est pas cette adresse qu'on lui a envoyé ? Ou alors j'ai raté quelque chose.
          • [^] # Re: hotmail?

            Posté par  (site web personnel) . Évalué à 2.

            Que désignes-tu par le client ?
            J'ai envoyé /toto/ à mon contact, ainsi que l'identifiant et le mot de passe. Lui, s'y est connecté avec IE8, a parcouru le dossier et a téléchargé le fichier.
            • [^] # Re: hotmail?

              Posté par  (site web personnel) . Évalué à 0.

              Donc tu as un GET sur le dossier qui apparaît dans le log Apache ?
              • [^] # Re: hotmail?

                Posté par  (site web personnel) . Évalué à 3.

                Comme déjà répondu ailleurs, mais ça commence à être compliqué de recouper tous les fils de discussion :) : depuis cette IP vraisemblablement Microsoftienne, je n'ai que ce GET sur le fichier, aucune autre trace (parmi les traces légitimes de mon contact).
                • [^] # Re: hotmail?

                  Posté par  (site web personnel) . Évalué à 3.

                  Certes, mais comme ton log apache affiche le GET sur le fichier de 1.2.3.4 mais pas le GET sur le dossier, on pouvait penser qu'il avait eu l'url directement, d'où l'incompréhension, et ma question pour bien comprendre ce qu'il s'est passé.

                  Ceci mis à part, es-tu sûr que ton ami n'a pas refilé le lien à quelqu'un ?
              • [^] # Re: hotmail?

                Posté par  (site web personnel) . Évalué à 1.

                Oui, mais c'est juste monsieur 1.2.3.4, pas monsieur evilMSbot.
          • [^] # Re: hotmail?

            Posté par  . Évalué à 1.

            A priori le navigateur, ici IE8, a affiché le contenu du dossier toto et l'utilisateur a cliqué sur le fichier qui l'intéressait.
            Dès lors le client a eu connaissance du document a récupéré sur le serveur web.

            Par contre, l'interrogation porte sur comment cette information connue du seul navigateur/client a été communiquée à un autre équipement en un autre point de l'Internet.
          • [^] # Re: hotmail?

            Posté par  (site web personnel) . Évalué à 0.

            Son pote reçois site.tld/toto/ qu'il consulte avec IE, il voit tot-titi.zip et path[1] il le télécharge avec IE. Non ?

            [1] http://www.nojhan.net/geekscottes/index.php?strip=15
  • # MSN

    Posté par  . Évalué à 7.

    On dirait des serveurs MSN. Ton pote n'aurait pas transféré le fichier via MSN ? Dans ce cas, c'est plus ou moins normal, MSN ne marche pas en P2P, tous les échangent transitent par un serveur qui fait l'intermédiaire entre les clients.
    • [^] # Re: MSN

      Posté par  (site web personnel) . Évalué à 4.

      Il l'a téléchargé avec IE8 comme le montre la première ligne de log Apache. Ensuite il l'a peut-être ré-échangé avec un autre via MSN, je me renseigne. Mais de toute façon, un échange de fichier de son ordi vers l'ordi d'un autre donne lieu à un GET malformé sur mon serveur ?
    • [^] # Re: MSN

      Posté par  . Évalué à 1.

      parenthese:

      pas tous, les transferts de fichiers via msn se font bien evidemment en p2p.
      Ou sinon va falloir m'expliquer le transfert a 1.5Mo/s sur un lan derriere une freebox.

      fin de la parenthese.
      • [^] # Re: MSN

        Posté par  . Évalué à 2.

        Si je me souviens bien, MS bridait MSN pour éviter le piratage de mp3.

        PS: parenthèse ça s'écrit ( ou ) :-)

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: MSN

          Posté par  . Évalué à 1.

          Et qu'en était il des wma ? Pas bête pour imposer un format ... Enfin il aurait fallu tester avec les .ogg et les .flac ou .aac pour ne pas tirer de conclusions hatives.
        • [^] # Re: MSN

          Posté par  . Évalué à 2.

          mmmmmh
          t'es sur que tu confonds pas avec le "filtre de securite" de msn qui bloque l'echange de certains types de fichiers? Genre les .exe, .bat, et apparement les .mp3 aussi.

          J'ai echange a peu pres tout et n'importe quoi via msn et j'ai jamais remarque un quelconque bridage.

          La parade est simple: renommer le fichier :)
          • [^] # Re: MSN

            Posté par  . Évalué à 1.

            Je ne sais pas de quand date la mesure et si elle est toujours active mais j'avais lu ça quelque part et j'en avais eu la preuve. Mais il me semble que c'était pas lié au type de fichier. Peut-être aussi que c'était lié à certains pays.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: MSN

              Posté par  . Évalué à 1.

              ce qui m'etonne dans ce que tu dit, c'est que j'ai souvent echange des p3 via msn.

              Les .exe et autres executables, clairement ca passe pas, et encore heureux, quand on voit le nombre de salete qui hijackent ton compte msn et discutent avec tes contacts pour les envoyer sur des sites a la con...
          • [^] # Re: MSN

            Posté par  . Évalué à 4.

            Explique ça à un neuneu qui ne voit pas ses extensions sur son poste windows...
      • [^] # Re: MSN

        Posté par  . Évalué à 2.

        Si mes souvenirs sont bons, le système p2p n'est utilisé que lorsqu'il y a un chemin possible entre les deux personnes ... bref, si les deux sont derrière un NAT, on passe par le réseau micro avec des vitesse d'échange assez impressionnantes.
  • # IE => Ouin

    Posté par  . Évalué à 2.

    Je ne sais pas s'il faut incriminer directement ms dans l'histoire. Si ton contact utilise IE, il utilise plus que probablement le système d'exploitation lié.

    Et ce n'est une découverte pour personne que c'est un bouillon de culture pour malware (quel que soit l'argent investi dans les études qui affirment le contraire).

    Le protocole "je chope l'adresse, j'espionne" est tellement gros que j'ai du mal à leur attribuer la culpabilité...

    Il reste à laisser ce genre de serveur à l'abri d'OS malicieux.
    • [^] # Re: IE => Ouin

      Posté par  . Évalué à 7.

      La fin du tracepath vers 208.50.101.155 :

      6: MSN-HOTMAIL.Gi3-7.ar4.LAX1.gblx.net
      ...
      • [^] # Re: IE => Ouin

        Posté par  . Évalué à 2.

        <mauvaise foi>C'est bien ce que je dis, un malware...</mauvaise foi>

        C'est pas net, mais comme on nous le rabache, une IP ne dit pas tout...

        Mais ce serait pas tout simplement dans les CGUs ? Non parce que si le monsieur a cliqué sur "Oui, je le veux", il y a moins de questions à se poser.
  • # Un peu facile

    Posté par  . Évalué à -10.

    En gros t'as la preuve de rien, tu penses que, mais dans le doute, c'est la faute de IE8.
    Non, non, t'as pas paranoïaque. Juste de mauvaise foi.
  • # Sécurité...

    Posté par  . Évalué à 4.

    Ce ne serai pas un mécanisme de sécurité Crosoft, genre liste anti Phishing ou un truc du genre? Il aurait pas les mécanisme de sécurité IE8 en fonction ton pote?

    C'est quoi l'adresse IP exacte que tu as dans tes log?
  • # Et le referrer ?

    Posté par  (site web personnel) . Évalué à 2.

    Une explication bien simple serait la suivante :

    La personne a téléchargé ton fichier. Ensuite elle a été directement sur un site Microsoft, celui-ci récupère le "referrer" transmis par le navigateur, et utilise cette information pour nourrir le moteur de recherche.

    Il y a une autre explication plausible : j'ai assez vu des utilisateurs aller sur google et entrer l'URL dans la zone de recherche au lieu de l'introduire dans la barre d'adresse.

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Et le referrer ?

      Posté par  (site web personnel) . Évalué à 1.

      Pas de google ici, en revanche l'idée du referer est intéressante (plus que d'autres exprimées auparavant, qui montrent que leurs auteurs n'ont juste pas lu les logs ou leurs explications :)).

      En revanche elle n'invalide pas ma 3ème conclusion, donc on peut se moquer un peu de Microsoft quand même.
      • [^] # Re: Et le referrer ?

        Posté par  . Évalué à 7.

        Non, le referer marcherait seulement s'il avait cliqué sur un lien ms.com depuis ton site.
    • [^] # Re: Et le referrer ?

      Posté par  . Évalué à 5.

      La personne a téléchargé ton fichier. Ensuite elle a été directement sur un site Microsoft, celui-ci récupère le "referrer" transmis par le navigateur, et utilise cette information pour nourrir le moteur de recherche.

      Pour que le referrer soit transmis, il faut que l'utilisateur ait cliqué sur un lien sur le site source. Ouvrir une URL, puis une autre en tapant son adresse directement n'envoie pas de referrer (et heureusement, j'ai pas forcément envie que linuxfr.org sache que juste avant d'aller dessus, j'étais sur microsoft.com).
    • [^] # Re: Et le referrer ?

      Posté par  . Évalué à 3.

      Plutôt que le referrer, je soupçonnerais l'historique. Je n'ai pas IE, mais supposons un instant qu'il se comporte comme Firefox (uniquement de ce point de vue, hein, faut pas déconner), je viens de faire le test : si je télécharge un fichier avec mon navigateur, même simplement en cliquant sur un lien hypertexte, il apparaît dans l'historique. Il suffit ensuite de visiter un site web qui pompe le "history" via Javascript, et c'est plié.
      • [^] # Re: Et le referrer ?

        Posté par  . Évalué à 2.

        Ouhla, encore une bonne raison de désactiver javascript.
        Cette fonction n'est elle pas bloquée dans la plupart des navigateurs web?
        • [^] # Re: Et le referrer ?

          Posté par  . Évalué à 5.

          Il faut voir la façon dont le "pompage" fonctionne, c'est un peu un hack :
          On peut tester si une url est présente dans l'historique en mettant le lien sur la page, et en faisant tester la couleur du lien par javascript : bleu s'il n'est pas visité, ou violet s'il l'est.
          C'est le browser qui s'occupe de la coloration, c'est donc "involontairement" que le browser donne ces infos sur l'historique.
          • [^] # Re: Et le referrer ?

            Posté par  . Évalué à 2.

            Et d'ailleurs, cela fonctionne aussi sans javascript ! Une css qui va pomper des resources différentes en fonction de l'état visité du lien et le tour est joué. Ceci dit, il est vrai que javascript permet des optimisations plus intéressantes :)

            Sinon, on en a déja parlé ici je crois (flemme de rechercher le journal).
      • [^] # pompage

        Posté par  . Évalué à 6.

        Attention, le "pompage d'historique" ne peut pas lister tout l'historique, ce qu'il peut faire c'est demander si une url précise (ou plusieurs, ou des milliers) est présente ou pas dans l'historique, mais il n'y a pas de listage exhaustif.
  • # Barre d'outil?

    Posté par  . Évalué à 8.

    La personne n'aurait-elle pas une barre d'outil supplémentaire installée, en l'occurence une MSN Toolbar).

    Une toolbar style MSN permettrait sûrement de récupérer sans aucun problème l'url du fichier téléchargé même dans dans un espace avec accès restreint, tout cela se faisant au niveau client.
    • [^] # Re: Barre d'outil?

      Posté par  (site web personnel) . Évalué à 2.

      en effet, google fait pareil pour indexer un max de pages difficiles à trouver (ex: un blog peu connu, qu'on se passe par msn)

      la norme est donc toujours le fichier robots.txt à la racine du domaine pour interdire les robots.
      • [^] # Re: Barre d'outil?

        Posté par  . Évalué à 1.

        La question est donc: il y-a-t-il un GET sur le robots.txt ?
  • # Apache

    Posté par  . Évalué à -6.

    Moi je ne suis pas pro-Microsoft, ni anti-Apache, c'est même le contraire, mais avec les éléments dont nous disposons, apache peut aussi très bien être le coupable !!

    Il nous faut plus de preuve !
    • [^] # Re: Apache

      Posté par  (site web personnel) . Évalué à 1.

      Heing ? Qu'est-ce qu'apache viendrait faire ici ? Et puis il est open-source, lui, et je doute franchement qu'un comportement pareil serait longtemps passé inaperçu.
      • [^] # Re: Apache

        Posté par  (site web personnel) . Évalué à 2.

        Un tiers a eu l'url d'un fichier que seul le serveur et le client connaissaient. Considérer que seul le client est en tort est clairement un parti pris. Qui te dit que son serveur ne possède pas de malware ? Que son apache n'est pas issue d'une source compromise ?
        • [^] # Re: Apache

          Posté par  . Évalué à 7.

          En l'occurence, le malware en question transmettrait la liste fichiers téléchargés sur Apache à son site source. Site source qui appartient... à Microsoft.

          On en revient au même : ce serait MS le fautif, qui aurait dans ce cas conçu un malware pour Apache.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Apache

        Posté par  . Évalué à 0.

        Pareil pour IE (non, il n'est pas open-source :)) mais bon, tu peux analyser le trafic entrant/sortant beaucoup plus facilement que l'on peut étudier le code source d'apache.

        Attention, je ne suis pas du tout fan d'IE, je pense juste qu'Apache peut être autant coupable qu'IE (c'est à dire pas du tout à mon avis).
        • [^] # Re: Apache

          Posté par  . Évalué à 1.

          Suffit de se trouver une VM sale, de faire une capture sur le réseau de cette VM et de reproduire la démarche ci-dessus (si tant est que ceci est facilement reproductible).

          On en saura sans doute davantage...
          • [^] # Re: Apache

            Posté par  (site web personnel) . Évalué à 10.

            J'ai fais une petite capture pour le fun avec wireshark. Je clique sur un lien qui lance le téléchargement d'un fichier et paf, ~0.5s plus tard j'ai une communication avec l'adresse 213.199.161.251 qui commence en https.

            Alors si on va sur l'adresse en http (depuis son navigateur), il n'y a rien, en https on a un certificat qui est valide pour urs.microsoft.com. et si on cherche sur google, on trouve ce pdf[1] qui explique, en page 14, que microsoft envoies les url à son outil anti-phishing ...


            [1] http://download.microsoft.com/download/2/8/e/28e60dcc-123c-4(...)

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: Apache

              Posté par  . Évalué à 2.

              Mon dieu, aurai-je posté un commentaire intéressant?
              A tout ceux qui m'ont "moinssé" précédemment... IE8 envoie souvent des info sur les pages visité, afin de compléter et mettre à jour leurs base de données pour leurs outils de sécurités (ne me demandez pas plus de détail ça reste de la boite noir...). Du Crosoft tout craché.
              Avant de crier au viol de l'anonymat, aucune informations n'est transmis sur le poste émetteur de ces informations (enfin...logiquement...).

              Quand à ceux qui ont émis l'hypothèse hilarante qu'apache envoyait des informations sur ces visiteurs, a part d'une manière volontaire de l'admin, et encore...
              • [^] # Re: Apache

                Posté par  . Évalué à -1.

                Je ne vois pas ton pseudonyme ("Olorim") apparaitre dans ce le fil de discussion. Alors le coup de dire "ouin ouin on m'a moinssé c'est affreux et inadmissible".........
                Perso je suis
                - pour le moinsage automatique des alts pourris.
                - pour le moinsage automatique des posts "ouin ouin pourquoi on me moinsse je suis persécuté par la kabale qui cherche a me censurer"
                - pour la mise à mort des gens qui combinent les deux.
  • # Petit élément supplémentaire

    Posté par  (site web personnel) . Évalué à 3.

    Je précise que j'ai inversé les deux lignes de log (celle venant des ÉUA est écrite avant dans le fichier, bien que la date de la requête soit ultérieure ; j'imagine que c'est parce qu'Apache n'écrit le log que quand la requête est terminée, or le fichier faisant de l'ordre de 1Go, forcément le transfert a duré plus longtemps que le 401).

    Je viens de voir la ligne :

    ./access.log:208.50.101.151 - - [07/Dec/2009:13:17:45 +0100] "GET /toto/toto-titi-03.zip HTTP/1.1" 401 561 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"

    dans mes logs, sans ligne de téléchargement correspondante venant de mon contact.
    J'extrapole que d'ici quelques temps je vais la voir apparaître (quand il aura fini de télécharger cet autre fichier) :-)

    L'IP est différente (mais dans le même /24) et tracepath me sort bien évidemment tout plein de HOTMAIL/msn.
    • [^] # Re: Petit élément supplémentaire

      Posté par  . Évalué à 4.

      Tu devrais rester en contact avec ton correspondant téléchargeur de totos, afin de savoir ce qu'il fait exactement.
      Mieux encore, lui expliquer grosso modo qu'il se passe de choses bizarres, et lui demander de faire des tests sur un dossier toto2.
      Dis-lui que c'est pour la bonne cause ;+)

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Petit élément supplémentaire

      Posté par  (site web personnel) . Évalué à 4.

      Ah bah tiens :

      1.2.3.4 - toto [07/Dec/2009:12:52:25 +0100] "GET /toto/TOTO-TITI-03.zip HTTP/1.1" 200 1713421248 "http://url.com/toto/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 1.1.4322)"

      Exactement comme prévu (date ultérieure mais plus loin dans le log, même nom de fichier...)

      M'enfin Earered a déjà éclairci ce mystère plus haut et benoar a éclairci son éclaircissement. Merci à eux !
      • [^] # Re: Petit élément supplémentaire

        Posté par  . Évalué à 9.

        Moralité: pour faire du fisching, il vaut mieux proposer une page dont l'URL contient des majuscules, afin de rendre inutilisable le filtre anti-fisching d'IE. Si un jour j'ai envie de vider des comptes et de finir en prison, j'y penserai.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Petit élément supplémentaire

          Posté par  . Évalué à 1.

          Sauf si la comparaison entre l'URL de ton site et celle de la base de Microsoft se fait aussi sans vérifier la casse, ce qui semblerait logique.
          • [^] # Re: Petit élément supplémentaire

            Posté par  . Évalué à 4.

            Ouais, enfin si Microsoft se bouffe une erreur 404 en demandant /microsoft.html alors que je piège les gens sur /microsOft.html, ils seront bien avancés.
            À moins qu'ils ne considèrent comme du fisching toutes les pages inaccessibles? :P

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Petit élément supplémentaire

      Posté par  (site web personnel) . Évalué à 2.

      un toto de 1 Go !? il fait du sumo ?

      GNU's Not Unix / LINUX Is Not Unix Xernel

  • # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Et sinon, pour récupérer ses sauvegardes, on fait comment ?

    Posté par  . Évalué à 6.

    On hacke le miroir que Microsoft s'est fait ? Y'a un moyen de le faire facilement et compatible avec rsync ?

    ==========> []

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.