Archives de catégorie : Non classé

Chiffrement cloud

Vive les masques jetables !

Comme tout le monde, vous vous êtes toujours demandé comment lancer un missile nucléaire en toute sécurité, sans que les Russes, les Chinois ou les Américains ne viennent perturber vos communications en changeant les cibles à l’insu de votre plein gré ou en connaissant vos cibles à l’avance : impossible de (sur)vivre sans savoir cela. Plus sérieusement, vous vous êtes plus probablement demandé s’il existait un moyen de chiffrement infaillible et infalsifiable permettant la transmission d’un message de façon vraiment confidentielle ? La réponse est oui : le masque jetable est la meilleure des solutions, et c’est même la seule. Nous ne parlons pas ici de la covid mais du chiffre de Vernam. La suite sur… NextINpact !

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

DevSecOps

Pas de stratégie DevSecOps possible sans une forte culture CI/CD dans l’entreprise, une plate-forme cloud ou On-Premise qui fonctionne et une automatisation à outrance des outils de test, de build et de déploiement.

Il est essentiel de ne plus penser à intégrer la sécurité dans les projets mais dans le cycle de vie des applications (SDLC).

Bertrand Méens, CTO de l’entreprise Oskab

Sources

Réponse automatique aux incidents

Analyse d’une instance

Un mot sur GuardDuty

One of the most common observations after enabling GuardDuty is that it can be daunting at the beginning and that it requires a significant amount of time to tune it to make it serviceable for your environment.

https://auth0.com/blog/guardians-of-the-cloud-automating-response-to-security-events/

Types d’attaquants

Par grand type

  • Script kiddies
  • Hacktivistes
  • Opportunistes
  • Mafia
  • Etats (ou groupe soutenus par des états)

Par niveau d’habileté

  • Minimal/Faible : les script kiddies, les Anonymous, qui exécutent des bidules sans les comprendre, sans aucune connaissance de sécurité offensive (ou très peu) ;
  • Standard : du personnel compétent mais isolé (loup solitaire, petit groupe type hacktivistes) ;
  • Avancé : groupes organisés, avec du support technique et financier, profil typique dans le milieu de la cybercriminalité ;
  • Prédateurs/Hors catégorie : les groupes étatiques ou soutenus par des états, tels que des services de renseignements, l’armée.