Archives de catégorie : Références

VLAN

Un VLAN (Virtual Local Area Network) est un réseau local virtuel qui permet de regrouper un ensemble d’équipements au sein d’un même réseau local logique, même s’ils sont physiquement dispersés dans un réseau plus large. Un VLAN divise un réseau physique en plusieurs réseaux virtuels distincts, chacun avec ses propres segments, créant ainsi une séparation entre les groupes d’équipements.

Continuer la lecture →

Attaques (références)

Sources principales

Les principales attaques

Autres sources d’erreur et d’attaque

  • Envoi non sécurisé des informations de connexion (toujours via une requête POST via TLS)
  • De façon générale, il faut éviter de passer des informations critiques via l’URL (identifiants de connexion mais aussi de session) : tout cela peut se retrouver dans les logs, dans l’historique du navigateur, dans les en-têtes divers et variés, dans les proxies, etc.
  • Code de développement non supprimé (ou non désactivé), car il contient souvent des bypass pratiques mais dangeureux !
  • Enumération d’utilisateurs : les messages d’erreur des formulaires de connexion ou de réinitialisation de mot de passe peuvent révéler l’existence d’un utilisateur (via son identifiant ou son e-mail). Autant garder des messages génériques tels que :
    • Pour la connexion : « combinaison identifiant/mot de passe invalide » que l’erreur vienne du nom d’utilisateur ou du mot de passe.
    • Pour la réinitialisation de mot de passe : « un lien de réinitialisation sera envoyé si cet utilisateur existe dans la base » .

Reflected XSS

On dit aussi XSS réfléchi en français, mais la terminologie anglaise prévaut souvent en ce qui concerne la SSI. Une faille XSS non permanente consiste à faire utiliser une URL contenant du script malveillant. Pour cela, il faut communiquer à un utilisateur cette URL pour qu’il clique dessus, par exemple. Rien n’est stocké sur le site web ciblé, à l’inverse d’une stored XSS.

Les champs HTML de recherche sont de bons candidats pour ce genre de faille, car ils doivent souvent laisser passer des caractères variés (par exemple en langage naturel). Comme le contenu d’un tel champ doit être passé ensuite dans une requête GET ou POST, l’absence de contrôle approprié sera forcément dommageable.

Continuer la lecture →

Fixation de session

Un serveur web peut avoir un comportement étrange même si tout semble bien conçu. En effet, la gestion des sessions (qui n’est pas vraiment le point fort du protocole HTTP) peut s’avérer délicat et peut entraîner des problèmes de type fixation de session.

Marquons la session

Il est assez courant de voir qu’un identifiant unique et impossible à deviner soit associé à une session particulière d’un utilisateur. Pour se connecter, il faut en général que l’utilisateur s’authentifie avec ce numéro de session unique, attribué par le serveur web. Donc a priori aucune chance qu’un attaquant externe arrive connecter sans connaître les crédentités de l’utilisateur.

Demandons poliment à l’utilisateur de le faire pour nous

Qu’à cela ne tienne : demandons alors à l’utilisateur légitime de s’authentifier à notre place (si on est l’attaquant). Comment ? D’abord en s’attribuant un numéro de session. Pour cela, il suffit d’aller sur le site ciblé. Si cet identifiant est inséré dans l’URL, on obtiendra alors quelque chose qui ressemble à ça : 

https://lebeausitevisé.com/accueil?app_session_id=1c9d5e00dcbc3c77e55798b74c5267f

Vous devinez la suite ? Le méchant va envoyer un gentil mail à la victime en prétextant une mise à jour des fonctionnalités, une vérification de sécurité ou n’importe quoi d’autre en lui demandant de cliquer sur cette URL bien précise. Si la victime clique et que le serveur web ne prend pas les précautions adaptées, elle ira sur le site, où on lui redemandera se s’authentifier et le tour est joué : cette session sera considérée comme valide et authentifiée ! Il ne reste plus à l’attaquant à rafraîchir sa fenêtre (avec la même URL et donc le même numéro de session et il se retrouvera connecté avec l’identité de la victime, sans aucune manipulation complexe (tel qu’un vol de cookie).

Contre-mesures

Il y a plusieurs façons d’atténuer le risque. On peut :

  1. Modifier le numéro de session une fois l’authentification réalisée. Ainsi l’attaquant ne pourra pas profiter de la connaissance de cet identifiant impossible à deviner en théorie.
  2. Ne pas utiliser d’identifiant de session dans les requêtes GET ou POST et le stocker dans un cookie.
  3. Utiliser des identifiants de session non prévisibles et contrôlés uniquement par le serveur, ce qui implique (entre autres) l’utilisation d’un bon générateur de nombres aléatoires !

En Python, avec Django, cela peut donner :

request.session.flush()
request.session.cycle_key()

Voir aussi

Attaques XML

XML, comme toute technologie informatique, est potentiellement utilisable de façon détournée par de méchants pirates. Autrement dit, XML est attaquable. Certaines attaques sont relativement communes, d’autres sont plus spécifiques à la technologie elle-même.

Attaques XXE

Une attaque XXE consiste à utiliser le mécanisme XML External Entities qui permet de charger, dans un document XML, des données externes.

Principe

Il suffit donc ensuite que le serveur qui traite le fichier XML ait les droits sur la ressource demandées pour qu’il la récupère. Imaginons que le serveur soit installé sur une instance AWS : on peut très bien mettre, dans l’entité externe à charger, une URL du type //169.254.169.254/latest/meta-data/iam/security-credentials/role/ qui contient les informations d’authentification pour le rôle concerné.

<!DOCTYPE doctype [
<!ENTITY myentity SYSTEM "https://169.254.169.254/latest/meta-data/iam/security-credentials/role/"> ]>
<sell>
  ...
 <product>
  <name>Product Name</name>
  <price>100.00</price>
  <description>&myentity;</description>
 </product>
  ...
</sell>

On récupère alors une réponse :

{  "Code" : "Success",
  "LastUpdated" : "2018-02-06T15:12:30Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAJQAPNMGMDOUJ5LGQ",
  "SecretAccessKey" : "/jOIiFX...............eNBe0SigqvngXkXsMP",
  "Token" : "FQoDYXdzEKj//////////wEaDNzLiriTguzdpCK9A1/LsuWyHIqk...............7LLNrtnR2Sdy/VdfFjuLjzGw...............",
  "Expiration" : "2018-02-06T21:29:09Z" }

Contre-mesure

Ce risque est inhérent à l’utilisation de ce mécanisme, et le seul moyen efficace de s’en prémunir est… de l’interdire ! Hélas, chaque parseur XML a son propre paramétrage et il va falloir chercher dans la doc correspondante comment procéder. Pour Python/Django, cela peut donner :

from lxml import etree
parser = etree.XMLParser(resolve_entities=False)

Attaques XPath

L’attaque XPath est plus classique car elle est liée à l’éternel problème du contrôle des données entrées dans un système informatique.

Le principe est le même que celui d’une injection SQL, où on force, via des caractères spéciaux, une modification de la logique de la requête SQL générée avec l’entrée saisie par l’utilisateur. Ici, on modifie la logique du code ou de la requête SQL grâce à des caractères spéciaux introduits dans un champ XML.

Exemple : //coupon[code='ABCD' or '*']

Rien de bien nouveau, à part qu’il faut aussi penser à vérifier systématiquement ses documents XML, comme toute entrée (saisie) d’un utilisateur, notamment en échappant les caractères.

Attaques XSS

Les attaques XSS sur XML sont classiques et le principe est celui des XSS : on force un utilisateur à exécuter un script contenu dans le document XML.

Contre-mesures

Il y a deux façons de contrer ces attaques, qu’on peut combiner :

  • Filtrer les données du document XML, en échappant les caractères et/ou interdisant certains motifs (patterns) suspects ;
  • Empêcher l’exécution du script en modifiant le header de la réponse au niveau du serveur, en forçant le téléchargement du fichier.

Attaques XSS via un fichier SVG

SVG est un format d’image basé sur XML. Il est possible d’y inclure des scripts, ce qui le rend vulnérable aux attaques XSS comme vu juste au-dessus. Le principe est donc identique, à part que le script est désormais caché dans une image SVG qu’un attaquant cherchera à placer dans le site de sa cible.

Contre-mesures

Là où c’est un peu plus sioux, c’est qu’on peut effectivement faire la même chose que pour les attaques XSS. Mais si le fichier SVG doit être affiché sur une page web, il va être difficile (du point de vue ergonomie) de forcer l’image à être téléchargée ! Cela veut donc dire qu’il va falloir traiter très consciencieusement tout ficher SVG destiné à être affiché…

Voir aussi

Sources d’information

Voici mes différentes sources d’information, en ce qui concerne l’actualité.

Dans le registre des newsletters :

Côté sites d’informations informatiques, ayant souvent de bons articles sur la SSI :

Côté blogs, voici :

Chaînes d’infos, webinars, etc. :

Pour ce qui est des sources de formation, voici ce que j’ai en stock :

D’autres bons sites, payants :

  • PluralSight ;

Pour tout casser (et expérimenter des techniques d’attaque) :

De nombreux éditeurs et fournisseurs ont des rubriques sécurité (Microsoft, Intel, AWS…)

Les éditeurs de solutions de sécurité ont aussi souvent des pages intéressantes (base des virus, études, livres blancs, etc.)