Problème avec https: // url allant à un location inconnu

Nous avons un site Web (ASP.NET/Plesk 9.5.5) auquel on peut accéder facilement via l'URL ordinaire ( http://example.com ).

Cependant, lorsque vous accédez au site via https : //example.com, le site affiche l'avertissement du certificate de security invalide, ce qui est bien puisque nous n'avons pas de certificate SSL. Si j'ajoute une exception, je suis envoyé à un site complètement distinct qui héberge apparemment un script de logiciels malveillants (je suis toujours sur https://example.com ).

En raison de cela, Google a signalé que le site était dangereux.

Je ne peux rien find dans le panneau Plesk qui aiderait à résoudre ce problème, et autant que je puisse dire que ces files n'existent pas sur notre server. Comment puis-je savoir où le lien https: // m'envoie? Je ne suis pas familier avec le DNS, mais c'est ce qui cause ce comportement?

La raison pour laquelle cela se produit est que votre fournisseur d'hébergement possède plus d'un (probablement des centaines ou même des milliers) de sites Web tous partageant la même adresse IP. C'est parfaitement correct et normal.

Catch est que le SSL "normal" ne peut prendre en charge qu'un seul site Web par adresse IP. Ainsi, chaque site Web qui partage cette adresse IP affichera le même site sur https:// .

Il semblerait que le HTTPS:// par défaut HTTPS:// site hébergé par votre hôte sur votre adresse IP présente cette vulnérabilité.

Il n'y a rien que vous puissiez faire à ce sujet; C'est juste un piège pour l'hébergement partagé. Comme l'indique Somantra, vous devez contacter votre fournisseur d'hébergement.

Cela semble être une injection xss d'injection javascript qui exploite une vulnérabilité dans plesk.

Selon l' article que vous avez lié, l'injection semble append le code aux files js existants.

Je suggérerais fortement de suivre les conseils des auteurs pour contacter votre fournisseur d'hébergement concernant l'attaque et modifier vos passwords.

Il y a un patch pour la vulnérabilité, alors je ferais cela aussi longtime que possible.

Cela n'empêchera pas tout cela, mais pour répondre à votre question sur la détermination de l'URL de redirection:

Utilisez netstat pour observer les tentatives de connection au site xss apparent.

J'aime utiliser netstat comme ceci:

netstat -noab >> out.txt

Ensuite, ouvrez le file out.txt lorsqu'il finit et searchz ce dont vous avez besoin.

Vous pouvez supprimer une partie de l'encombrement de sortie par quelque chose comme:

netstat -noab | find / i ": 80"

ou

netstat -noab | find / i ": 443"