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 lectureAnatomie 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 lectureLa bourse ou la vie
Les ransomwares sont une menace constante depuis plusieurs années. Ce qui les rend redoutables est que leur modèle évolue et s’adapte pour être les plus efficaces possibles. Dernière évolution : la menace physique.
Continuer la lectureRansomware Task Force
Ça pète. Avec un nom pareil, les ransomwares n’ont qu’à bien se tenir. Trêve de plaisanterie, cette initiative est louable, et montre bien les préoccupations dans ces années 20 : autrefois on luttait joint contre les botnets, maintenant il faut ajouter une corde à l’arc de la SSI : la lutte contre le ransomware.
Continuer la lectureSolarWinds
L’attaque via SolarWinds, un éditeur de logiciels, restera dans les annales (avant de passer à la méga-attaque suivante). Une bourde de cet éditeur a conduit à une attaque à la fois sophistiquée, étendue, et particulièrement grave. Beaucoup de commentaires suivront, mais regardons les grandes lignes.
Continuer la lectureFireEye piratée
Arroseur arrosé ou cible particulièrement intéressante ? FireEye est une société réputée et performante dans le domaine de la sécurité informatique, notamment dans la réponse à incident (Madiant étant une des sociétés du groupe), mais aussi dans la protection contre les menaces même les plus avancées. Et pourtant, fin 2020, elle a été ciblée et l’attaque a abouti.
Continuer la lectureZerologon
BGP
BGP est un protocole méconnu mais structurant d’internet, Facebook1 ne dira pas le contraire (même si le DNS a aussi son rôle à jouer2). « La meilleure définition est que c’est le protocole de routage qui fait fonctionner Internet »3 selon LeMagIT. Rien de moins. Et pourtant il s’appuie sur des mécanismes anciens qui datent du temps où tout le monde était gentil sur internet…
Continuer la lectureCovid 19
Difficile de rester confiné pendant plusieurs semaines sans ronger son frein. Je vais essayer de comptabiliser ici les bonnes et les mauvaises initiatives durant cette période. Les bonnes sont les gestes d’entraide, les mauvaises sont les attaques profitant du sujet.
Continuer la lectureCrypto AG
Beaucoup de bruit pour rien… On découvre en 2020 que les espions espionnent. Si je m’attendais à ça…
Continuer la lecturePrix de l’innovation
Une idée géniale : si ton système n’a pas de faille de sécurité, alors introduis-en une ! Des attaquants ont profité d’un driver de Gigabyte, signé et légitime mais qui présentait une vulnérabilité non corrigée, pour lancer des attaques.
Continuer la lecture