[Cybersécurité] Scanner les vulnérabilités d’un site web avec Arachni

Arachni est un scanneur de vulnérabilités web écrit en Ruby (cross-plateforme) par Tasos Laskos et permettant d’automatiser la détection d’un grand nombre de failles (XSS, SQL Injection, Local File Injection, Remote File Injection, etc.). Il est disponible sous la forme d’une interface web, une application console et une API REST.

Types de scans

Arachni permet de faire des scans actifs ou passifs.

Scans actifs

Ils testent la présence de failles sur les pages web visitées, par exemple :

  • Envoie de code malicieux dans les formulaires pour tester les injections SQL ou XSS
  • Injection de chemins vers des fichiers locaux dans les URLs (/etc/passwd par exemple)

Scan passifs

Ils sont non intrusifs et ne laissent pas de traces dans les bases de données des application testées. Ils se décomposent en 3 types de détection :

  • Vérification de configuration (utilisation de HSTS, présence du flag HTTP_ONLY sur les cookies, etc.)
  • Récupération d’informations (méthodes HTTP autorisées, dossiers communs, listing de répertoires, etc.)
  • Présence d’informations sensibles (présence d’adresses IP, de numéros de sécurité sociales américains, emails dans les pages HTML)

Configuration

La configuration d’Arachni fonctionne avec des « checks » et des profils.

Checks

Les checks correspondent aux actions qui seront effectuées par Arachni. Ils sont divisés en 2 catégories : Actif et Passif

Actifs

  • Code injection
  • Code injection (php://input wrapper)
  • Code injection (timing)
  • CSRF
  • File Inclusion
  • LDAPInjection
  • NoSQL Injection
  • Blind NoSQL Injection (differential analysis)
  • OS command injection
  • OS command injection (timing)
  • Path Traversal
  • Response Splitting
  • Remote File Inclusion
  • Session fixation
  • Source code disclosure
  • SQL Injection
  • Blind SQL Injection (differential analysis)
  • Blind SQL injection (timing attack)
  • Trainer
  • Unvalidated redirect
  • Unvalidated DOM redirect
  • XPath Injection
  • XSS
  • DOM XSS
  • DOM XSS in script context
  • XSS in HTML element event attribute
  • XSS in path
  • XSS in script context
  • XSS in HTML tag
  • XML External Entity

Plus d’informations sur Github

Passifs

  • Allowed methods
  • Backdoors
  • Backup directories
  • Backup files
  • CAPTCHA
  • Common administration interfaces
  • Common directories
  • Common files
  • Cookie set for parent domain
  • Credit card number disclosure
  • CVS/SVN users
  • Directory listing
  • E-mail address
  • Form-based File Upload
  • HTTP Strict Transport Security
  • .htaccess LIMIT misconfiguration
  • HTML objects
  • HttpOnly cookies
  • HTTP PUT
  • Insecure client-access policy
  • Insecure cookies
  • Insecure CORS policy
  • Insecure cross-domain policy (allow-access-from)
  • Insecure cross-domain policy (allow-http-request-headers-from)
  • Interesting responses
  • localstart.asp
  • Mixed Resource
  • Origin Spoof Access Restriction Bypass
  • Password field with auto-complete
  • Private IP address finder
  • SSN
  • Unencrypted password forms
  • WebDAV
  • Missing X-Frame-Options header
  • XST

Plus d’informations sur Github

Profils

Les profiles rassemblent ensuite un ou plusieurs « checks » au sein de la configuration d’un scan. Parmi les autres options disponibles, on retrouve par exemple :

  • Exclure des paths
  • Configuration de l’audit du site web
  • Configuration du fingerprinting pour ne jouer que les payloads correspondants aux applications ou technologies utilisées sur le site web audité (gain de performance)
  • Gestion des plugins
  • Gestion des paramètres HTTP (proxy, nombre de requêtes, etc.)

Lors du lancement d’un scan, il suffit ensuite de renseigner l’URL a auditée et le profil choisi.

Interfaces web

L’interface web est complète en permettant les actions suivantes :

  • Configuration des comptes utilisateurs
  • Gestion des profiles
  • Gestion des agents permettant de déporter la charge sur d’autres machines
  • Planification des scans
  • Lancement et consultation des scans

Lancement d’un scan

start_scan

A noter qu’il est possible de déporter la charge du scan sur une ou plusieurs autres machines en fonction des agents configurés (dispatchers).

 

Liste des vulnérabilités détectées

 

liste_vulnerabilites

Les vulnérabilités sont regroupées en fonction de leurs sévérités et de leurs types.

 

Détails d’une vulnérabilité

details_vulnerabilite_1details_vulnerabilite_2

Dans chaque détail, il y a la requête HTTP envoyée ainsi que la réponse reçue avec une mise en évidence de la faille détectée (ici du XSS).

Mon avis

J’ai testé initialement Arachni pour effectuer une recherche automatisée de failles XSS sur une application volontairement vulnérable. Après avoir tester ZAP et xsser, Arachni semble être l’outil qui a détecté les failles que j’attendais. Attention toutefois à correctement configurer les profiles pour ne sélectionner que les éléments pertinents. Sans une configuration spécifique, le scan pourra durer plusieurs heures pour un site très simple. Les rapports sont complets et permettent l’identification et la correction rapide des problèmes.

Sources

Notes

Attention, les tests automatisés ne remplacent pas les tests manuels

Retours sur le livre surveillance:// de Tristan Nitot

Dans un monde ou internet est omniprésent, les smartphones sont devenus des objets utilisés à outrance, le nombre d’objets connectés augmentent et ou les GAFAM (Google, Amazon, Facebook, Apple, Microsoft) nous connaissent mieux que nous même, la question de la protection de la vie privée est de plus présente dans les esprits.

Je suis gêné quand Google lit mes emails lorsque je réserve un hotel ou un avion et me propose les informations sur le terminal de l’aéroport ou l’heure à laquelle je dois partir de chez moi pour ne pas rater mon vol. Ces services sont certes pratiques mais très intrusifs dans ma vie. De la même manière, lorsque je fais des recherches sur un produit qui m’intéresse (ex : une perceuse), je me retrouve avec des pubs de perceuses sur tous les sites que je visite.

Beaucoup de questions peuvent ainsi être posées : Où partent mes données ? Qui peut y avoir accès ? En suis-je encore le propriétaire ? Les services liés à ces informations qui me sont proposés ne sont-ils pas qu’un leurre ? Pourquoi Google, Facebook, etc. sont-ils gratuits ? Pourquoi dit-on de plus en plus souvent « Si c’est gratuit, c’est toi le produit » ?

surveillance://

Le livre surveillance proposé par Tristan Nitot tente de répondre à une bonne partie de ces questions en illustrant les réponses avec beaucoup d’exemples concrets et compréhensibles par tous.

Le livre est présenté en 2 axes majeurs. Le premier dresse un bilan de la réalité concernant les données personnelles (données collectées par les GAFAM, la NSA, pourquoi dois-je me préoccuper de mes données, les lois en vigueur, etc.). Le deuxième axe donne les outils et les philosophies à adopter pour contrôler nos données (l’open source, les outils à utiliser, les configurations à mettre en place, les projets à suivre, etc.).

J’ai trouvé ce livre intéressant pour les raisons suivantes :

  • Il peut être lu et être utile aussi bien à un ingénieur en informatique qu’à une mère au foyer
  • Il n’est pas extrémiste, c’est à dire que le but n’est pas d’empêcher complétement la collecte des données et donc de se priver d’un outils formidable qu’est internet mais de prendre conscience et reprendre le contrôle
  • La liste des contre-mesures est intéressante et bien détaillée
  • Tout est illustré par des exemples concrets

Bref, ce livre est à mettre entre toutes les mains.

Vous pouvez le commander sur Amazon et sur le site de l’éditeur C&F.

[Cybersécurité] Principe et implémentation de HSTS (HTTP Strict Transport Security)

HTTPS est devenu quasiment obligatoire sur tous les sites web et particulièrement sur ceux contenant des formulaires. Même si ce n’est pour le moment qu’une indication non bloquante, Firefox émet une erreur lors de la visite d’une page non sécurisée contenant des formulaires (en savoir plus).

Warning Firefox formulaire HTTP

Pour rappel, la mise en place du protocole HTTPS est maintenant facilitée par l’initiative Let’s Encrypt.

Problématique

Traditionnellement, sur un site web implémentant HTTPS, un utilisateur qui souhaite accéder à la version HTTP est redirigé via une HTTP 301 sur la version HTTPS :

Redirection HTTP vers HTTPS avec HTTP 301

 

Par exemple sur LinkedIn :

Redirection HTTP vers HTTPS Linkedin

Ce scenario sera répété à chaque fois que l’utilisateur tente d’accéder au site web en utilisant le protocole HTTP.

Le problème avec ce mécanisme de redirection c’est que la première requête sur http://monsite.com est transmise en clair sur le réseau. On imagine qu’elle peut contenir des cookies sans le flag « secure », des données de formulaires, etc. Toutes ces données peuvent être interceptées par une attaque de type « Man in the middle ».

Pour éviter cet aller/retour, il faut indiquer au navigateur que le site souhaité doit être accédé en HTTPS et qu’il doit donc remplacer le HTTP par le HTTPS.

Implémentation

Pour avertir le navigateur que le site doit être utilisé en HTTPS, il faut rajouter le header « Strict-Transport-Security » dans les réponses HTTP renvoyées par le site web.

hsts_header

Ce header dispose de plusieurs paramètres :

  • max-age (obligatoire) : durée pendant laquelle le navigateur va accéder au site web uniquement en HTTPS. La valeur conseillée étant généralement de 1an (31536000s).
  • includeSubDomains (facultatif) : permet d’appliquer HSTS aux sous-domaines
  • preload (facultatif) : permet d’être ajouté à la liste de preloading

Le scenario est donc maintenant le suivant :

Scenario HSTS

Grâce à ce mécanisme, seul le premier accès au site web contient un aller/retour en HTTP. Tout le reste se fait en HTTPS. Afin d’éliminer ce dernier échange non sécurisé, nous allons utiliser le preloading.

Les navigateurs Chrome, Firefox, IE et Edge intègre une liste de sites web implémentant HSTS. Ils savent donc que ces sites web doivent être accédés uniquement en HTTPS. Pour s’inscrire sur cette liste, il faut se rendre sur la page mise à disposition par l’équipe Chromium : https://hstspreload.appspot.com.

Certains pré-requis doivent être satisfaits pour être éligible :

  • Avoir un certificat valide
  • Rediriger le HTTP vers le HTTPS (comme décrit ci-dessus)
  • Tous les sous-domaines doivent être en HTTPS
  • le sous-domaine www doit exister
  • Avoir le header HSTS (comme décrit ci-dessus) avec les paramètres « includeSubDomains » et « preload ».

Une fois inscrit, il faut attendre la mise à jour de chaque navigateur. Une fois chargé dans les différents navigateurs, le scenario est le suivant :

HSTS avec preload

Compatibilité

HSTS est supporté par les derniers navigateurs (http://caniuse.com/#feat=stricttransportsecurity):

Compatibilité HSTS

Sur les navigateurs ne supportant par HSTS, le header est simplement ignoré.

Vérification

Pour vérifier que le site web dispose d’un header HSTS valide et qu’il est bien préloadé dans les différents navigateurs, il est possible d’utiliser des outils en ligne comme https://www.ssllabs.com.

Vérification HSTS

Liens utiles

 

[Cybersécurité] Se protéger des failles XSS avec les headers CSP (Content Security Policy)

Les failles XSS (Cross-Site Scripting), étant classées en troisième position du dernier TOP 10 de l’OWASP, sont une porte d’entrée dans les systèmes d’information (scan de ports, exploits, etc.) et une menace pour les utilisateurs (vol d’information d’identifications).  Les traditionnelles contre mesures mises en place sont le filtrage des données entrantes sur le serveur (input filtering) et l’encodage des données sortantes (output encoding) afin d’éviter l’exécution de scripts malveillants sur les postes clients.

Principe

Une autre manière de se protéger de ce type de faille est de mettre en place le header HTTP Content-Security-Policy définissant la stratégie mise en place pour contrôler les contenus récupérés et envoyés par une page web côté client. Le principe du CSP est de définir quelles sources pourront être utilisées pour les scripts javascript, les styles CSS, les fonts, les POST de formulaires, les requêtes AJAX, etc.

Les sources disponibles sont les suivantes :

  • self  : domaine courant
  • none : aucun domaine
  • all : tous les domaines
  • liste de domaines séparés par un espace.

Si un élément n’a pas de configuration, la valeur du paramètre default-src sera utilisée.

default-src dispose de 2 valeurs supplémentaires disponibles :

  • unsafe-inline : autorise l’exécution de scripts inline (<script></script). Avec CSP ils sont par défaut interdits
  • unsafe-eval : autorise l’utilisation de la méthode eval()

En plus des types de ressources énumérés ci-dessus, d’autres options sont disponibles, entre autres :

  • Manipulation du module Anti-XSS des navigateurs
  • Gestion de nonce pour les scripts inline (CSP v2)

Récupération de contenu

La quasi totalité des éléments (font, fichiers de style CSS, fichiers javascript, images, iframe, etc.) pouvant être téléchargés et/ou exécutés par une page web peuvent être contrôlés par CSP. Pour chacun de ces éléments il est possible de définir une ou plusieurs sources de confiance.

Par exemple :

  • Javascript et CSS : tous les fichiers doivent provenir du domaine suivant : https://cdn.azure.com
  • Images : toutes les images doivent provenir du domaine : http://images.azure.com
  • Les scripts inline (<script></script>) sont interdits
  • Pour tous les autres contenus, n’autoriser que le domaine de la page courante

Se traduira par le header HTTP suivant :

Content-Security-Policy: default-src ‘self’ ; script-src https://cdn.azure.com; style-src https://cdn.azure.com; img-src http://images.azure.com;

La liste des paramètres est disponible ici.

Envoi de contenu

De la même manière, il est possible de définir une politique pour l’émission de requêtes depuis la page cliente. C’est principalement le cas pour les requêtes AJAX et les formulaires (CSP v2).

Par exemple :

  • Requêtes AJAX/WebSocket : N’autoriser les requêtes que vers les domaines : https://api.monsite.com et https://api.sitetiers.com
  • Envoi de formulaire : N’autoriser les requêtes que vers le domaine courant

Se traduira par le header HTTP suivant :

Content-Security-Policy: connect-src https://api.sitetiers.com https://api.monsite.com; form-action ‘self’ ;

Les paramètres sont cumulables avec l’exemple précédent.

Mode reporting

Mettre en place CSP avec une mauvaise configuration peut avoir de lourdes conséquences sur un site web. Si une source est oubliée, on peut facilement se retrouver avec des fichiers javascript qui ne se chargent pas, un site sans style CSS ou sans images par exemple.

A des fins de tests, le header Content-Security-Policy-Report est disponible. Il se comporte comme le header Content-Security-Policy mais ne bloque pas réellement les ressources.

Exemple :

content-security-policy-report

CSP met également à disposition un paramètre report-uri pour notifier une url des violations de stratégies CSP via une requête POST.

Exemple de requête report reçue :

report-uri

Compatibilité et versions

En terme de compatibilité, la version 1 de ce header est pris en charge par les dernières versions de principaux navigateurs :

Compatibilite_CSP

Source : http://caniuse.com/#feat=contentsecuritypolicy

La version 2 n’est quant à elle pas encore disponible partout :

Compatibilite_CSP2

Source : http://caniuse.com/#feat=contentsecuritypolicy2

Sur les navigateurs non compatibles, le header est simplement ignoré.

Un draft de la version 3 est sorti et est disponible ici.

Implémentation

Pour implémenter le CSP sur un site web, il suffit de rajouter des headers HTTP personnalisés sur les réponses faites par notre serveur. Ce type de mécanisme est intégré à la plupart des frameworks de développement web.

Afin de faciliter la mise en place et la maintenabilité des règles CSP, certaines librairies sont disponibles en fonction des frameworks. Par exemple :

Le serveur web peut également être configuré pour ajouter automatiquement ce header HTTP à toutes les requêtes sortantes.

Liens utiles

 

 

ASCII Folding dans Elasticsearch et appel de _analyze

Dans Elasticsearch, pour une faire une recherche sur un mot contenant un caractère unicode non présent dans la table ASCII (un accent par exemple) sans avoir à rechercher spécifiquement le mot avec ce caractère, une phase d’ASCII folding est nécessaire pour convertir ces caractères unicodes en leurs équivalents ASCII (si possible). Par exemple « ê » devient « e ».

Pour réaliser cette étape, le mapping du champ contenant ces caractères doit spécifier le filtre « asciifolding » fourni nativement par le moteur Elasticsearch.

Exemple de création d’index avec déclaration de notre analyzer avec asciifolding :

PUT /my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "my_analyzer": {
          "tokenizer": "standard",
          "filter":  [ "standard", "asciifolding" ]
        }
      }
    }
  }
}

On créé ensuite le type en indiquant que notre champ utilisera notre nouvel analyzer :

PUT /my_index/_mapping/fruit
{
  "properties": {
    "name": {
      "type": "string",
      "fields": {
        "asciifolding": {
          "type": "string",
          "analyzer": "my_analyzer"
        }
      }
    }
  }
}

Enfin, on ajoute un document contenant une valeur accentuée dans le champ « name » :

POST my_index/fruit 
{
  "name": "pêche"
}

Les exemples de recherche suivants illustrent l’utilité de notre analyzer.

Requête Réponses
GET my_index/fruit/_search
{
  "query": {
    "match": {
      "name": "peche"
    }
  }
}
{
   "took": 1,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 0,
      "max_score": null,
      "hits": []
   }
}

GET my_index/fruit/_search
{
  "query": {
    "match": {
      "name.asciifolding": "peche"
    }
  }
}

{
   "took": 1,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "max_score": 1,
      "hits": [
         {
            "_index": "my_index",
            "_type": "fruit",
            "_id": "AVR4VgBfRZI8D8Bc982h",
            "_score": 1,
            "_source": {
               "name": "pêche"
            }
         }
      ]
   }
}

A noter que si on est en présence de mots français, il est plus intéressant d’utiliser l’analyzer « french » fourni dans Elasticsearch qui procède aussi à cette étape d’asciifolding mais ajoute également le stemming, les stopwords, etc. (analyzers de langues).

Pour tester un analyzer (ou un tokenizer ou un filtre), il est possible d’appeler « _analyze » sur un index via une requête HTTP GET.

Par exemple :

http://localhost:9200/my_index/_analyze?analyzer=my_analyzer&text=pêche

va renvoyer

{
  "tokens": [
    {
      "token": "peche",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

Alors que

http://localhost:9200/my_index/_analyze?analyzer=standard&text=pêche

va renvoyer

{
  "tokens": [
    {
      "token": "pêche",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

Attention, n’exécutez pas la requête « _analyze » dans Sense. L’encodage ne sera pas correct lors de la requête et la réponse sera fausse.

Requête :

GET /my_index/_analyze?analyzer=my_analyzer&text=pêche

Réponse :
{
   "tokens": [
      {
         "token": "p",
         "start_offset": 0,
         "end_offset": 1,
         "type": "<ALPHANUM>",
         "position": 1
      },
      {
         "token": "che",
         "start_offset": 2,
         "end_offset": 5,
         "type": "<ALPHANUM>",
         "position": 2
      }
   ]