"allrequestsallowed.com" ... Tentative de piratage?
J'ai de nombreuses tentatives sur mon serveur Web (petit, personnel et absolument sans importance), et Apache et fail2ban font généralement leur travail correctement. Mais il y a une entrée de journal qui m'inquiète:
xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"
Le problème est que la réponse n'était pas un code 404, mais un code 200. Est-ce OK? Cela me semble bizarre, mais ma connaissance de ce domaine (et de beaucoup d’autres) est, pour le dire doucement, limitée.
Tout d’abord, je ne sais pas ce que l’attaquant présumé tente d’accomplir. Peut-être y at-il un script PHP ou une version PHP vulnérable à une attaque de type ID de session étrange, je ne sais pas. Vous n'avez probablement rien à craindre, cependant.
Votre serveur s'est comporté exactement comme prévu. 200 est le code attendu dans cette situation particulière en raison de la façon dont Apache interprète l'URL qui lui est transmise.
Tout d'abord, http://allrequestsallowed.com est traité comme l'en-tête plus habituel 'Host:' (notez que je ne pense pas que cela soit spécifié dans la RFC et que d'autres serveurs ne l'interprètent pas de cette façon J'avais tort, c'est spécifié dans la RFC 2616 dans la section 5.1.2, même si les clients semblent rarement utiliser ce formulaire. Excusez-moi, je dois corriger une implémentation de serveur HTTP que j'avais écrite il y a quelque temps ...).
Maintenant, vraisemblablement, vous n'avez pas de site nommé 'allrequestsallowed.com'. Alors que se passe-t-il lorsque Apache obtient un en-tête Host: (ou équivalent) pour un nom d’hôte qu’il ne reconnaît pas? Il choisit le premier hôte virtuel par défaut. Ceci est un comportement bien défini et documenté pour Apache. Ainsi, quel que soit votre premier hôte virtuel (ou simplement la configuration du serveur principal s'il n'y a pas de vhosts), quel que soit son nom.
Désormais, le reste de l'URL donnée se compose de deux parties: le chemin, /, et un paramètre GET (le bit ?PHPSESSID...,).
Maintenant, le chemin / devrait être présent sur à peu près tous les serveurs Web. Dans la plupart des cas, cela correspond à quelque chose comme index.html ou peut-être à un script index.php, bien que vous puissiez naturellement le remplacer.
Si cela correspond à un fichier HTML statique, il ne se passe absolument rien d'inhabituel: le contenu du fichier est renvoyé et le paramètre est simplement ignoré. (En supposant que certaines directives de configuration avancées ne soient pas définies et que ce n’est certainement pas le cas.)
D'un autre côté, s'il s'agit d'un script, cette variable PHPSESSID sera transmise au script. Si le script utilise réellement cette variable (dans ce cas particulier, seuls les scripts PHP utilisant la gestion de session intégrée de PHP risquent de ), son comportement dépendra du contenu.
Cependant, même si votre / mappe sur un script PHP à l'aide de sessions, rien de remarquable ne se produira. L'identifiant de session n'existera probablement pas de toute façon et sera soit ignoré, soit le script affichera une erreur.
Dans le cas peu probable où l'ID de session existe, eh bien, l'attaquant pourrait peut-être pirater la session de quelqu'un d'autre. Ce serait dommage, mais ce n’est pas vraiment une faille de sécurité en soi, c’est là où l’attaquant obtiendra les informations d’identifiant de session (détecter un réseau sans fil est un bon candidat si vous n’utilisez pas HTTPS). En réalité, ils ne pourraient rien faire que l’utilisateur dont la session avait été initialement créée ne pouvait pas le faire.
Éditer: De plus, le '% 5C' à l'intérieur du SESSIONID correspond à un caractère barre oblique inverse. Cela semble être un test pour les attaques de traversée de répertoire sur les hôtes Windows.
J'ai enregistré toutes ces requêtes requises sur une adresse IP utilisée comme enregistrement A pour tous nos domaines de stationnement.
D'après moi, ce nom d'hôte est utilisé en combinaison avec le fichier hôte local de "l'attaquant" pointant vers l'hôte cible.
Le serveur Web actuel à 31.44.184.250 sert uniquement à traiter les demandes externes.
Mon avis: totalement inoffensif. Ne voyez aucune utilisation à valeur ajoutée, à l'exception de tout ce que vous pouvez faire avec tout autre faux nom de domaine dans votre fichier hôte.