Les pirates contournent la sécurité de .htaccess en utilisant les GETS

C'est quelque chose que je n'ai pas écrit moi-même, mais lors des recherches, j'ai trouvé assez intéressant de recherche.

Les pirates contournent la sécurité de .htaccess via obtient plutôt que GET

Hier soir, j'ai reçu un message urgent d'un client. Mon ordinateur a été piraté, quelqu'un entré dans la zone admin, j'ai besoin de tous les détails de cette adresse IP.

Alors, j'ai grepped les journaux, a saisi les entrées appropriées et vu quelque chose de bizarre.



Un extrait modifié du fichier .htaccess :



Bien sûr, nous savons GETS n'est pas valide, mais pourquoi Apache est remise état 200 s et les longueurs qui semblent valides de contenu ? Nous savons que la région était le mot de passe derrière les .htaccess et avec quelques travaux de clavier rapide, nous avons un système qui invite correctement pour l'authentification de base avec une requête HTTP/1.0 correctement formée. Retirer la restriction <Limit> le .htaccess protège le site, mais, pourquoi il existe d'autres méthodes capables de passer à travers ? Remplacement obtient avec n'importe quoi autre que POST, PUT, DELETE, piste, TRACE, OPTIONS, tête traduit par Apache traiter ces demandes comme si obtenir avait été saisi.

Nous allons configurer un environnement en double sur une autre machine pour savoir ce que fait Apache.



Essayons ce qu'ils ont fait :



Bizarre, c'est le comportement que nous attendions, mais pas ce que nous vivons sur l'ordinateur du client. Creuser un peu plus loin, nous regardons les différences et commence à soupçonner que la machine peut avoir été compromise. La première chose qui a frappé était mod_negotiation – probablement pas. mod_actions, peut-être, mais, non. DAV n'a pas été chargé, mais, Zend Optimizer était sur la machine qui semblaient avoir été exploité. Test de ce qui précède de script sur le client machine a entraîné po.. exactement le même comportement — méthode non prise en charge. Tester le répertoire qui a été exploitée entraîne la demande obtient servi comme si c'était une demande GET.

Donc, maintenant nous avons un domaine particulier sur la machine qui ne se comporte pas comme l'indique les fichiers config. Un test rapide sur le domaine d'origine et comme prévu, obtient répond avec les données et permet de contourner la clause d'autorisation dans le .htaccess. Permet d'essayer un autre test :




Bingo. Un fichier codé de Zend nous a remis une erreur 200 même si elle contenait une méthode de requête non valide.

La solution était dans ce cas simple, supprimez la clause de <Limit> du .htaccess.

La question est, est Zend Optimizer en train de faire la bonne chose ici. Je regarde Apache avec gdb, Zend Optimizer ne semble pas accrocher le gestionnaire Apache un peu plus élevé, mais pourquoi il tente de corriger une requête non valide ?

Les premières règles de validation des entrées est valider et rejeter en cas d'erreur. Ne jamais essayer de rectifier les données et l'accepter. Si vous essayez de corriger la situation et faire une erreur, vous êtes tout aussi vulnérable et les pirates vont essayer de comprendre les motifs et l'ajouter extra s'échappant dans leur demande d'url. Dans ce cas, seulement quelques pages ont pu être affichées comme il y avait des contrôles pour s'assurer des formes ont été affichés. Mais, la limite dans .htaccess qui aurait dû protéger l'application, n'a pas fonctionné comme prévu parce que les méthodes non valides n'ont pas été précisés.

Comme tant d'applications sur le web génèrent des fichiers .htpasswd avec la clause Limit, il me fait me demander combien d'applications Zend encodés est vulnérables. Prenez une minute pour vérifier vos systèmes.

plus de ressources avec le correctif :http://www.natexim.com/how-to-bypass-ht ... ntication/