«Allrequestsallowed.com»… Tentative de piratage?

11

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 200 à la place. Est-ce OK? Cela me semble bizarre, mais mes connaissances dans ce domaine (et bien d'autres) sont, pour le dire doucement, limitées.

server security webserver luri
la source
1
On dirait que je ne suis pas autorisé à poster une nouvelle réponse, mais nous avons trouvé une entrée comme celui - ci dans nos journaux, et nous avons pu vérifier qu'il était pas dangereux en reproduisant la demande avec boucle: curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. La configuration par défaut semble renvoyer une page "Bienvenue sur nginx" sans contenu significatif, sur notre système ubuntu. C'est donc une réponse de 200, mais c'est une simple page fourre-tout - nous ne procurons pas réellement la demande ailleurs ou quelque chose comme ça.
Frank Farmer

Réponses:

12

Tout d'abord, je ne sais pas ce que l'attaquant présumé essaie d'accomplir. Peut-être existe-t-il un script PHP ou une version PHP vulnérable à une étrange attaque d'ID de session, je ne sais pas. Mais vous n'avez probablement rien à craindre.

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.comest traité comme l'en-tête `` Host: '' le plus habituel ( notez que je ne pense pas que cela soit spécifié dans le RFC et que d'autres serveurs ne puissent pas l'interpréter de cette façon, j'avais tort, cela est spécifié dans le RFC 2616 dans la section 5.1. 2, même si les clients semblent rarement utiliser ce formulaire. Excusez-moi, je dois aller corriger une implémentation de serveur HTTP que j'ai écrite il y a quelque temps ...).

Maintenant, vous n'avez probablement pas de site nommé «allrequestsallowed.com». Que se passe-t-il donc quand Apache obtient un en- Host:tête (ou équivalent) pour un nom d'hôte qu'il ne reconnaît pas? Il sélectionne le premier hôte virtuel par défaut. Il s'agit d'un comportement bien défini et documenté pour Apache. Quel que soit votre premier hôte virtuel (ou simplement la configuration du serveur principal s'il n'y a pas de vhosts), il prend le relais, quel que soit son nom.

Maintenant, le reste de l'URL donné se compose de deux parties - le chemin d'accès /et un paramètre GET (le ?PHPSESSID...bit).

Maintenant, le chemin /devrait être présent sur à peu près tous les serveurs Web. Dans la plupart des cas, il correspond à quelque chose comme index.htmlou peut-être à un index.phpscript, bien que vous puissiez remplacer tout cela bien sûr.

S'il correspond à un fichier HTML statique, rien d'inhabituel ne se produit - le contenu du fichier est retourné, et c'est tout, le paramètre est simplement ignoré. (En supposant que vous n'avez pas défini certaines directives de configuration avancées, et ce n'est certainement pas le cas.)

D'un autre côté, s'il s'agit d'un script quelconque, cette PHPSESSIDvariable 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 sont susceptibles de le faire), son comportement dépendra du contenu.

Selon toute vraisemblance, cependant, même si votre /mappage avec un script PHP à l'aide de sessions, rien de remarquable ne se produira. L'ID 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 éventuellement détourner la session de quelqu'un d'autre. Ce serait mauvais, mais ce n'est pas vraiment un trou de sécurité en soi - le trou serait là où l'attaquant a obtenu les informations d'ID de session (renifler un réseau sans fil est un bon candidat si vous n'utilisez pas HTTPS). En fait, ils ne seraient pas en mesure de faire quoi que ce soit que l'utilisateur dont la session était à l'origine ne pouvait pas faire.

Edit: En outre, 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.

Nicholas Knight
la source
J'ai eu des demandes similaires 404, 500, 403 et 20x sur mes serveurs exécutant nginxou lighttpd, et après avoir envoyé les adresses IP / hôtes source à une firme de cyber-analyse, il a été confirmé qu'il s'agissait entre autres de tentatives d'exploitation de trous dans le serveur . Demandes similaires à celle spécifiée par l'OP, hôtes différents. Êtes-vous en train de dire qu'ils devraient être totalement ignorés? Parce que s'ils sont vraiment inquiets, ils peuvent bloquer les hôtes iptables.
Thomas Ward
@The Evil Phoenix: l'hôte dans l'URL n'est pas d'où vient la demande, c'est juste l'équivalent d'un en-tête «Host:». L'adresse IP réelle du client, que OP a obscurcie, pourrait être bloquée avec iptables s'il le souhaitait, mais à moins qu'il ne soit inondé de demandes, cela n'a vraiment pas d'importance. Ce n'est pas parce que quelqu'un essaie d'exploiter un trou qu'il y a un trou. J'administre de nombreux serveurs (Linux) qui enregistrent chaque jour de nombreuses requêtes étranges destinées à exploiter des trous - la plupart étant des trous Windows / IIS! C'est juste un balayage aveugle. S'il ne reçoit pas de hit, il passe à la prochaine adresse IP.
Nicholas Knight
@The Evil Phoenix: De plus, si un trou était présent, bloquer l'adresse IP qui l'exploiterait ne ferait aucun bien. Votre serveur serait déjà compromis et serait toujours vulnérable à la même attaque d'autres sources - et il existe de nombreuses sources. Chaque système zombie (et il y en a plusieurs millions) est une source potentielle d'analyses malveillantes.
Nicholas Knight
Explication agréable et approfondie .... Merci beaucoup. J'ai obscurci l' IP incriminé au cas où il / elle surferait sur ip :). Mon / mappe sur le défaut d'Apache "Ça marche" (je sais, comment peu professionnel ... mais j'ai dit que c'était personnel, lol). Je suppose donc que je ne dois rien faire à moins que la même adresse IP ne devienne pénible, auquel cas je la bloquerai avec iptables (ou même hosts.deny?). Merci encore.
luri
1

J'ai toutes ces demandes autorisées enregistrées sur une adresse IP qui est utilisée comme enregistrement A pour tous nos domaines de stationnement.

Mon tir est que 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 réel au 31.44.184.250 est juste pour gérer les demandes externes.

Mon avis: totalement inoffensif. Ne voyez aucune utilisation à valeur ajoutée, sauf pour les choses que vous pouvez faire avec tout autre faux nom de domaine dans votre fichier hôte.

Kajje
la source