Archives annuelles : 2021

Echappement

Technique de substitution d’un caractère interprétable (par un navigateur, un serveur web) par un équivalent sans signification.

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

Kerberos

Kerberos est un service d’authentification permettant d’accéder à des ressources sur réseau, en se reposant sur un mécanisme de distribution de clés symétriques. Il est utilisé notamment par Windows pour le service d’Active Directory. Le Kerberos Consortium gère ce projet en accès libre.

Différence entre Kerberos et NTLM

NTLM était utilisé autrefois par Windows. Il fonctionnait à la façon classique d’un mot de passe, avec stockage en base du mot de passe que l’utilisateur devait fournir pour s’authentifier. La principale différence entre les deux systèmes est la vérification tierce partie et la capacité de chiffrement plus efficace de Kerberos. 

Voici le principe d’une authentification via Kerberos.

Principe de fonctionnement de Kerberos

Faut s’accrocher un peu pour comprendre. En gros, le client (C) peut se connecter au serveur (S) sans rien connaître de (S). Tout passe par une infrastructure tierce, appelée Centre de Distribution de Clés (KDC) qui comprend un serveur d’authentification et un serveur d’émission de tickets.

En termes imagées, le client va auprès d’un bureau de sécurité (le serveur d’authentification) et demande un badge ayant une durée limitée. A l’aide de ce badge, il se rend à un service d’émission de tickets (celui qui est responsable de la ressource), et demande un ticket pour accéder à la ressource. Sauf qu’à chaque étape, tout est chiffré avec des clés symétriques.

Pré-requis

Pour cela, des clés privées doivent au préalable avoir été échangées entre tiers. Ainsi :

  • La clé privée spécifique au client doit être connue du serveur d’authentification. La clé est (toujours ?) dérivée du mot de passe servant à l’authentification sur l’AS via une fonction string2key ;
  • La clé privée du serveur de tickets (TGS) doit être connue du serveur d’authentification ;
  • La clé privée du serveur ressource (S) doit être connue du serveur de tickets (TGS).

Comme autre pré-requis, le client (C) doit avoir un principal, c’est-à-dire être connu du réseau. Côté client, il faut également savoir gérer ce protocole, ce qui est le cas pour Windows (GSSAPI).

Les différentes étapes

Pour cela, voici les opérations :

  1. Le client s’authentifie auprès du serveur d’authentification (Authentication Server, AS), en général via login/mot de passe ;
  2. Le serveur d’authentification lui renvoie un ticket d’authentification (Ticket Granting Ticket, ou TGT), qui l’authentifie durant un certain temps. Ce TGT est chiffré avec la clé du serveur de tickets, et ne peut donc pas être déchiffré par le client. A côté de cela, le serveur d’authentification envoie également une clé de session à utiliser pour l’échange avec le serveur de tickets (TGS) ;
  3. Pour accéder au serveur (S), le client (C) va utiliser ces éléments : il envoie le ticket d’authentification (TGT) au serveur de tickets (TGS) en le chiffrant avec la clé de session ;
  4. Le serveur de tickets déchiffre le TGT, le vérifie, et envoie alors au client une clé d’échange finale entre le client et le serveur (en bleu), chiffrée avec la clé de session, ainsi qu’un ticket de service chiffré avec la clé du serveur ;
  5. Le ticket de service est chiffré avec la clé du serveur : le client ne peut donc ni le lire, ni le modifier.

Cache

Le ticket d’authentification (TGT) ayant une certaine durée de validité, il doit être protégé convenablement dans un cache approprié, dont Kerberos exige qu’il soit en mémoire non swappable (pour éviter qu’il soit écrit sur un disque), accessible uniquement au niveau noyau, etc.

Le protocole interdit également tout stockage du mot de passe ou du secret obtenu via string2key.

MIT Kerberos Consortium – Protocol Tutorial

Les attaques

Sources

Voir aussi

Anatomie d’un phishing (presque) ordinaire

Le phishing fait des ravages depuis longtemps, mais force est de constater qu’il évolue sans cesse afin de déjouer la vigilance des utilisateurs et des outils de sécurité en charge d’éradiquer les mails douteux. Une campagne récente (active en décembre 2020) visant le portefeuille Ledger constitue une excellente occasion de voir, par l’exemple, les techniques employées en ce moment.

Continuer la lecture →

Active Directory

Un Active Directory est un annuaire de type LDAP pour Windows, avec deux fonctions principales : identifier des façon unique les ressources (matérielles ou humaines) et les authentifier. Mais ça n’est pas tout, Active Directory Domain Services permet également :

  • L’installation, la configuration et la mise à jour d’applications ;
  • La gestion de l’infrastructure de sécurité ;
  • L’activation du service d’accès à distance et de DirectAccess ;
  • L’émission et la gestion de certificats numériques.
Continuer la lecture →