Requêtes HTTP et modules Apache: vecteurs d'attaque créatifs

Question

Question légèrement peu orthodoxe ici:

J'essaie actuellement de casser un Apache avec une poignée de modules personnalisés. Ce qui a engendré le test, c'est qu'Apache envoie en interne les requêtes qu'il considère trop volumineuses (par exemple 1 Mo) aux modules connectés de manière appropriée, les forçant à gérer les données parasites - et le manque de manipulation dans les modules personnalisés. dans son intégralité pour aller en flammes. Aïe, aïe, aïe.

Ce problème particulier a été heureusement résolu, mais la question s'est posée de savoir s'il y avait ou non d'autres vulnérabilités similaires.

Actuellement, j'ai un outil à ma disposition qui me permet d'envoyer une requête HTTP brute au serveur (ou plutôt, des données brutes via une connexion TCP établie qui pourrait être interprétée comme une requête HTTP si elle suivait la forme d'un , par exemple "GET ...") et j'essaie de trouver d'autres idées. (Attaques au niveau TCP comme Slowloris et Nkiller2 sont pas mon objectif pour le moment.)

Est-ce que quelqu'un a quelques bonnes idées comment confondre les modules personnalisés du serveur au point de serveur auto-immolation?

• Broken UTF-8? (Bien que je doute qu'Apache se soucie de l'encodage - j'imagine qu'il ne fait que jongler avec les octets bruts.)
• Des choses qui sont à peine trop longues, suivies d'un 0 octet, suivies d'ordures.
• et ainsi de suite

Je ne me considère pas comme un testeur très bon (je fais cela par la nécessité et le manque de main-d'œuvre, malheureusement je ne même pas avoir une compréhension plus fondamentale de Apache qui internals m'aiderait), c'est pourquoi j'espère une réponse perspicace ou deux ou trois. Peut-être que certains d'entre vous ont fait des tests similaires pour vos propres projets?

(Si stackoverflow n'est pas le bon endroit pour cette question, je présente mes excuses. Je ne sais pas quel autre endroit pour le mettre.)

Answer 1

Selon les autres modules que vous avez accroché à, et quoi d'autre les active (ou est-ce que les demandes trop grandes?), Vous voudrez peut-être essayer quelques-uns des éléments suivants:

• encodages Bad - par exemple Comme vous l'avez mentionné, il y a des scénarios où les modules en dépendent, par exemple certains paramètres.
• manipulation des paramètres - encore une fois, en fonction de ce que font les modules, certains paramètres peuvent les perturber, soit en modifiant les valeurs, en supprimant les paramètres attendus, soit en ajoutant des paramètres inattendus.
• contrairement à votre autre suggestion, j'examiner les données qui à peine assez court, à savoir un ou deux octets plus courte que le maximum, mais dans différentes combinaisons - différents paramètres, en-têtes, corps demander, etc.
• Examinez HTTP Request Smuggling (également here et here) - des en-têtes de requête incorrects ou des combinaisons non valides, telles que la longueur de contenu multiple ou des terminateurs non valides, risquent de provoquer une erreur de lecture de la commande de la part d'Apache.
• Considérons également gzip, codage en morceaux, etc. Il est probable que le module personnalisé implémente le contrôle de longueur et le décodage, dans le désordre.
• Qu'en est-il de la demande partielle? Par exemple, les demandes qui provoquent une réponse 100-Continue, ou des demandes de plage?
• L'outil de fuzzing, Peach, recommandé par @TheRook, est également une bonne direction, mais ne vous attendez pas à un excellent retour sur investissement dès la première utilisation.
• Si vous avez accès au code source, une révision ciblée du code de sécurité est une bonne idée. Ou, même un balayage de code automatisé, avec un outil comme Coverity (comme @TheRook mentionné), ou un meilleur ...
• Même si vous n'avez pas accès au code source, pensez à un test de pénétration de sécurité, soit par un expérimenté consultant/pentester, ou au moins avec un outil automatisé (il y en a beaucoup là-bas) - par exemple appscan, webinspect, netsparker, acunetix, etc

Answer 2

Apache est l'un des projets les plus endurcis de logiciels sur le visage de la planète. Trouver une vulnérabilité dans le HTTPD d'Apache ne serait pas un mince exploit et je recommande de vous couper les dents avec des proies plus faciles. En comparaison, il est plus fréquent de voir des vulnérabilités dans d'autres HTTPD tels que celui-ci dans Nginx que j'ai vu aujourd'hui (pas de blague). Il y a eu d'autres vulnérabilités de divulgation de code source qui sont très similaires, je regarderais this et voici another. lhttpd a été abandonné sur sf.net pendant presque une décennie et il existe des dépassements de tampon connus qui l'affectent, ce qui en fait une application amusante à tester. Lorsque vous attaquez un projet, vous devriez regarder quelles vulnérabilités ont été trouvées dans le passé. Il est probable que les programmeurs feront les mêmes erreurs encore et encore et souvent il y a des modèles qui émergent. En suivant ces modèles, vous pouvez trouver plus de défauts. Vous devriez essayer de rechercher des bases de données de vulnérabilités telles que Nist's search for CVEs. Une chose que vous verrez est que les modules Apache sont le plus souvent compromis.

Un projet comme Apache a été fortement fuzzed. Il existe des frameworks de fuzzing tels que Peach. Peach aide à fuzzing de plusieurs façons, une façon dont il peut vous aider en vous donnant des données de test désagréables pour travailler avec.Fuzzing n'est pas une très bonne approche pour les projets matures, si vous allez dans cette voie, je voudrais cibler apache modules avec le moins de téléchargements que possible. Lorsqu'une entreprise s'inquiète de la sécurité, elle paie souvent beaucoup d'argent pour un outil d'analyse de sources automatisé tel que Coverity. Le département de la sécurité intérieure a donné à Coverity une tonne d'argent pour tester des projets open source et Apache is one of them. Je peux vous dire de première main que j'ai trouvé a buffer overflow avec fuzzing que Coverity n'a pas ramassé. Coverity et d'autres outils d'analyse de code source comme le open source Rats produiront beaucoup de faux positifs et de faux négatifs, mais ils aident à affiner les problèmes qui affectent une base de code. Quand j'ai lancé RATS pour la première fois sur le noyau Linux, j'ai failli tomber de ma chaise car mon écran listait des milliers d'appels à strcpy() et strcat(), mais quand je creusais dans le code, tous les appels fonctionnaient avec le texte statique, qui est sûr.)

Vulnérabilité resarch un développement d'exploit est a lot of fun. Je recommande d'exploiter les applications PHP/MySQL et d'explorer The Whitebox. Ce projet est important car il montre qu'il existe des vulnérabilités du monde réel qui ne peuvent être trouvées que si vous lisez manuellement le code ligne par ligne. Il a également des applications du monde réel (un blog et un magasin) qui sont très vulnérables aux attaques. En fait, ces deux applications ont été abandonnées en raison de problèmes de sécurité. Un fuzzer d'application Web comme Wapiti ou acuentix viole ces applications et celles qui lui plaisent. Il y a un truc avec le blog. Une nouvelle installation n'est pas trop vulnérable. Vous devez utiliser l'application un peu, essayer de vous connecter en tant qu'administrateur, créer une entrée de blog, puis l'analyser. Lors du test d'une application d'application Web pour l'injection sql, assurez-vous que le rapport d'erreurs est activé. En PHP, vous pouvez définir display_errors=On dans votre php.ini.

Bonne chance!