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 lectureArchives de catégorie : Attaques
KeePass : word ou oire ?
Mauvaise période pour les outils de sécurité : KeePass est à son tour sujet à un problème de sécurité (une vulnérabilité, dirons certains). On peut discuter longuement de la responsabilité du problème, mais il n’en reste pas moins qu’il est nécessaire de se sentir en confiance quand on utilise un gestionnaire de mots de passe, et force est de constater que la vulnérabilité en question prête… à questions.
Continuer la lectureLog4shell
La faille sur log4j est en train de devenir une véritable saga. Voici une petite synthèse en image, avec la mise-à-jour (le 23 décembre) pour Java 61.
Continuer la lectureDirectory (path) transversal
La traversée de répertoire fait également partie des grands classiques du poutrage de site. Dans son principe, il s’agit d’accéder à un répertoire normalement inaccessible. Comme souvent, une validation insuffisante des entrées en est souvent la cause.
Continuer la lectureDOM XSS
A première vue, cela ressemble énormément à du reflected XSS (XSS non persistent). Pourtant il y a une différence de taille : l’action se déroule uniquement au niveau du navigateur, alors que pour du XSS réfléchi ou stocké la vulnérabilité se situe directement au niveau du serveur web.
Continuer la lectureStored XSS
Ou persistent XSS en anglais, et XSS stocké ou permanent en français. Cette faille de la famille des XSS (cross site scripting) se différencie d’une XSS réfléchie par le fait qu’elle soit stockée. D’où son nom. Logique.
Continuer la lectureAttaques (références)
Sources principales
- CWE – CWE-1337: Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses (4.6) (mitre.org)
- OWASP Top Ten Web Application Security Risks | OWASP
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 lectureFixation 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 :
- 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.
- Ne pas utiliser d’identifiant de session dans les requêtes GET ou POST et le stocker dans un cookie.
- 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
Les bons conseils de la Maison Blanche et du CISA
Sous ce titre teinté de condescendance se cache une préoccupation réelle de la part des autorités (de tous pays, pas uniquement des Etats-Unis) : la menace liée aux ransomwares est telle qu’il faut impérativement diffuser les bonnes pratiques et les mesures essentielles à mettre en œuvre.
Continuer la lecture