La sécurité physique est-elle moins importante avec les disques d'un serveur cryptés?
Si vous pouviez obtenir un accès physique à un serveur, vous pourriez changer le mot de passe root/admin même si vous ne connaissiez pas le mot de passe actuel.
Cependant, avec des disques cryptés, je ne pense pas que ce soit possible (ou est-ce?).
Cela signifie-t-il que la sécurisation physique de votre serveur est devenue moins importante - elle est toujours nécessaire pour d'autres raisons - mais cette raison n'est-elle plus là?
L'accès physique, dans de nombreuses situations, probablement la plupart, signifie une perte totale de sécurité - pour diverses raisons (tout cela suppose des disques cryptés):
- Vol - Un attaquant pourrait voler le serveur ou les disques, pour attaquer à son rythme. Cela permet à un attaquant de prendre son temps, et vous ne savez pas s'il a réellement accédé aux données.
- Modification physique - Si je peux accéder à un serveur, je pourrais ajouter du matériel, cela peut aller de la connexion USB ou du clavier à l'ajout d'une interface sans fil pour permettre l'accès à distance.
- Cold Boot Attack - Il existe des attaques qui peuvent être utilisées pour extraire des clés de chiffrement, permettant le déchiffrement des disques.
- etc.
Il y en a bien sûr d'autres, mais ce n'est qu'un exemple de ce qui peut arriver si un attaquant a un accès physique. Il existe des attaques possibles qui sont encore quelque peu théoriques, telles que l'application d'images UEFI avec porte dérobée, etc.
La pire partie d'une attaque physique est peut-être que vous ne savez même pas exactement ce qui a été fait, il y a donc un réel problème à pouvoir faire confiance au matériel par la suite.
L'accès physique est un accès total. Un peu. Donnez-moi un accès physique à un serveur avec un disque crypté et la première chose que je ferais est de brancher un enregistreur de frappe sur le clavier pour prendre en charge ce cryptage embêtant.
Présentez-vous à ma porte avec un disque dur crypté et je vais le formater et vider des films dessus.
Le chiffrement est le plus souvent vaincu non pas en le cassant mais en le contournant. Il ne vous protège que lorsque vous l'utilisez. Vous avez accès parce que vous avez quelque chose qui vous donne accès. Que ce soit par mot de passe, RFID, empreinte digitale, peu importe. Donnez-moi un accès physique pendant que vous l'utilisez toujours et je découvrirai comment vous y avez accès.
Le cryptage du disque peut être vaincu en remplaçant la machine par une machine malveillante qui ressemble et se comporte exactement de la même manière, mais son seul but est de tromper l'utilisateur légitime en tapant le mot de passe FDE. Dans le cas d'un utilisateur local, cela peut être aussi simple qu'un enregistreur de frappe USB, dans le cas d'un utilisateur distant (saisissant la clé via SSH), vous devez extraire les clés privées SSH (qui se trouvent sur la partie non chiffrée du stockage depuis le La clé FDE n'est pas encore disponible), puis démarrez votre propre SSHd avec cette clé et attendez que l'utilisateur revienne.
Cold Boot Attack a été utilisé sur les ordinateurs portables pour déjouer le chiffrement du disque et fonctionnerait certainement sur les serveurs. Il y a également eu RAM attaques à l'aide de DMA via Thunderbolt, PCI Express et d'autres technologies de bus. Et les logiciels malveillants ont accès aux données non chiffrées; un attaquant physique peut avoir un temps plus facile de l'installer via le matériel local.
N'oubliez pas que pour fonctionner, le serveur doit être démarré, ce qui signifie que les clés de disque sont situées quelque part dans la machine.
Dans le cas d'un accès physique, vous contournez de nombreux dispositifs de sécurité tels que les pare-feu et les périphériques ips ids sur la périphérie du réseau, vous avez donc plusieurs pas en avant. Lorsque vous obtenez un accès à distance au serveur, vous devez toujours faire face au cryptage, donc c'est la même chose dans les deux cas. Il y a une citation à ce sujet qui dit: "Ils n'ont pas à contourner votre pare-feu s'ils peuvent contourner votre réceptionniste."
Il convient de noter que la sécurité ne concerne pas seulement la vie privée et la confidentialité, elle inclut également la disponibilité et l'intégrité (et la traçabilité, etc.).
En tant que tel, avec un accès physique - même s'il ne peut pas accéder à vos données - un attaquant peut faire beaucoup de dégâts.
Je suppose que l'intégrité et la disponibilité sont vos "autres raisons". Pourtant, si la question est de savoir si la sécurité physique est ou non moins importante, la réponse est que même si vous retirez la confidentialité de vos préoccupations, la sécurité physique reste primordiale.
Considérez cette réponse comme un complément aux autres ici, il n'est pas nécessaire de répéter leurs points.
Si vous pouviez obtenir un accès physique à un serveur, vous pourriez changer le mot de passe root/admin même si vous ne connaissiez pas le mot de passe actuel.
Quel système d'exploitation ne vous demandera pas le mot de passe actuel lorsque vous souhaitez changer? Ou vous voulez dire changer le mot de passe d'un autre utilisateur (qui est un administrateur)?
Cependant, avec des disques cryptés, je ne pense pas que ce soit possible (ou est-ce?).
Avec mon expérience sur Windows, le dossier/fichier EFS ne sera pas accessible si un autre administrateur modifie le mot de passe avec force. Vous devrez avoir un certificat EFS pour le même si vous perdez le mot de passe ou qu'un changement de mot de passe forcé se produit (ou si le compte lui-même est supprimé).
Cela signifie-t-il que la sécurisation physique de votre serveur est devenue moins importante - elle est toujours nécessaire pour d'autres raisons - mais cette raison n'est-elle plus là?
OMI, les deux sont nécessaires.
Réponse courte: Non, c'est toujours très important
La plupart des gens ont publié des réponses qui incluent l'ingénierie sociale ou des attaques qui sont nécessairement interactives (comme des enregistreurs de frappe ou des variantes de l'attaque de la méchante). Ceux-ci peuvent être vaincus à l'aide de techniques d'attestation à distance sécurisées (impliquant généralement Intel TXT ou SGX). Parce que la plupart d'entre elles sont interactives, et de nombreux adversaires ne peuvent pas se permettre d'attendre que quelqu'un se connecte au serveur, Je vais fournir quelques exemples qui peuvent être utilisés pour compromettre un serveur chiffré à tout moment, ainsi que des atténuations. Notez que cela sera centré sur Linux, mais les points matériels sont indépendants du système d'exploitation.
Récupération directe de la mémoire à l'aide d'attaques de démarrage à froid
La méthode que tout le monde connaît, une attaque de démarrage à froid, peut récupérer les clés de chiffrement sur la plupart du matériel avec une fiabilité modérée avec deux méthodes. La première consiste à refroidir la mémoire à l'aide d'un spray de congélation, à la retirer physiquement et à la placer dans une nouvelle carte mère pour lire le contenu. La seconde implique de conserver la mémoire, de la refroidir éventuellement pour améliorer la fiabilité et de redémarrer le système dans un système d'exploitation malveillant et léger, un chargeur de démarrage ou, dans au moins un cas connu, un BIOS personnalisé, qui lit et décharge la mémoire sur un non -milieu volatil.
L'attaque de démarrage à froid fonctionne parce que la mémoire informatique moderne à haute capacité, appelée DRAM, qui stocke les données dans des condensateurs qui doivent être actualisés à un rythme élevé lorsqu'ils stockent une charge, ou ils perdront leur charge. Ils sont généralement actualisés toutes les 64 ms pour plus de fiabilité, mais même sans alimentation, beaucoup d'entre eux conservent leurs données pendant une courte période.
Il existe trois principaux types de mémoire couramment utilisés dans les serveurs aujourd'hui: DDR2, DDR3 et DDR4. La DDR2 peut parfois conserver des données pendant 30 secondes ou plus sans alimentation. La DDR3 et la DDR4 perdront leur puissance en quelques secondes, ce qui les rend beaucoup plus difficiles à monter contre les attaques de démarrage à froid. De plus, la mémoire DDR3 et DDR4 brouillera leur contenu pour réduire les interférences électriques, mais l'algorithme qu'il utilise est un LFSR, qui n'est pas sécurisé cryptographiquement et qu'il est trivial de casser.
Atténuer la première méthode est aussi simple que de s'assurer que les barrettes DIMM ne peuvent pas être retirées. Cela peut être fait en utilisant correctement une résine époxy anti-effraction. S'il est utilisé correctement, toute tentative de le supprimer détruira la mémoire dans le processus. Cela peut ne pas être possible si vous utilisez un serveur que vous ne possédez pas physiquement. Atténuer la deuxième méthode nécessite que votre BIOS efface la mémoire avant de démarrer. La désactivation du démarrage rapide peut parfois entraîner l'effacement de la mémoire dans le cadre de POST. La mémoire ECC nécessite également souvent d'être initialisée par le BIOS avant utilisation. Cependant, au moins une fois, une attaque de démarrage à froid de ce type impliquait une version personnalisée de démarrage à froid. BootGuard, une fonctionnalité de nombreux nouveaux systèmes Intel, empêchera l'installation de BIOS personnalisés, mais un adversaire particulièrement avancé pourra toujours le contourner.
Il existe encore une méthode finale pour vaincre l'attaque de démarrage à froid, qui fonctionne contre les deux types d'attaques de démarrage à froid, et qui est de ne jamais permettre à la clé de chiffrement d'entrer en contact avec la mémoire. C'est exactement ce que fait le patch du noyau TRESOR pour Linux, en plaçant les clés dans les registres de débogage x86. Cela n'immunise pas votre ordinateur contre toutes les attaques impliquant un accès physique, il empêche uniquement les attaques de démarrage à froid de lire vos clés de chiffrement. Les données de votre disque qui restent dans les tampons du système de fichiers par exemple seront toujours récupérables.
Lecture et écriture dans la mémoire en utilisant DMA attaques
Tout périphérique connecté au PCH (PCI, PCIe, LPC) a le potentiel de lire et d'écrire directement en mémoire via DMA, ou Direct Memory Access, des attaques, également appelées mastering de bus malveillant (un périphérique qui est maître de bus est autorisé à envoyer = DMA requêtes, entre autres). DMA est une technique qui permet aux périphériques de lire et d'écrire de manière asynchrone en mémoire, sans avoir à impliquer le CPU, pour de meilleures performances . Malheureusement, si un tel périphérique est détourné ou inséré de manière malveillante, il peut lire et écrire dans toute la mémoire et le CPU ne peut rien y faire. Le CPU peut dire si le périphérique a des capacités DMA, mais s'il est activé, le CPU fait confiance à l'appareil, lui faisant confiance pour ne pas le trahir.
Il y a trois types d'attaques DMA que je connais. Le premier est le hotplugging PCI/PCIe, impliquant de placer un périphérique malveillant dans un emplacement sur la carte mère et de laisser le système d'exploitation se configurer automatiquement Il est trivial d'atténuer, en désactivant le branchement à chaud. Cela peut nécessiter une modification de la configuration du noyau. Le deuxième type d'attaque consiste à détourner un périphérique existant et approuvé qui est maître de bus, et à l'utiliser pour lire ou écrire dans la mémoire. Cela peut être fait soit en exploitant le micrologiciel exécuté sur l'appareil, soit en détournant le matériel via des interfaces de débogage exposées, en reflasher le micrologiciel et en déclenchant une réinitialisation à froid du processeur de l'appareil, etc. Le type final, beaucoup moins connu, est une attaque sur le LPC. Le LPC est l'équivalent du bus archaïque ISA sur le matériel moderne. Il gère les anciens périphériques à faible vitesse. Cependant, il peut également être rendu maître du bus en affirmant le LDRQ # toutes les cartes mères n'exposent pas cela, et bien que ce soit purement anecdo tal, un développeur Intel que j'ai rencontré a déclaré qu'il n'avait jamais vu un ordinateur portable qui exposait LDRQ #. Cela peut être différent pour les serveurs. Malheureusement, la fiche technique Intel PCH spécifie que le bit maître du bus du LPC est en lecture seule, forcé. Si votre système prend en charge LDRQ #, l'atténuation des attaques basées sur LPC DMA doit être effectuée par d'autres moyens.
Il existe deux façons d'atténuer les attaques de DMA. La première tire parti du fait que, tandis que DMA fonctionne indépendamment du CPU, tourner DMA on exige toujours que le CPU lui donne son autorisation en activant le bit maître du bus. Un pilote, qui est juste un logiciel, peut refuser un périphérique qui veut cette permission. Si le périphérique n'est pas autorisé, il ne peut pas lancer le DMA. Par exemple, si vous n'utilisez pas le pilote Firewire ou si vous n'utilisez pas le pilote Firewire plus moderne qui a DMA désactivé par défaut, le périphérique PCI Firewire aura DMA désactivé ( le bit maître du bus ne sera pas défini.) Cette technique a ses inconvénients, car certains périphériques nécessitent DMA pour fonctionner. Les cartes d'interface réseau, les cartes graphiques, etc. nécessitent DMA, ou elles seraient si lentes qu'ils ne seraient pas inutilisables. Bien que vous n'ayez pas à vous soucier d'un nouveau, malveillant étant branché, d'un exploit contre la carte ou d'une attaque contre le matériel (le contrôler à l'aide d'interfaces de débogage, par exemple). exemple) peut utiliser ce privilège contre l'hôte.
L'autre atténuation consiste à utiliser une fonctionnalité dans la plupart des processeurs modernes, l'IOMMU (la fonctionnalité est nommée VT-d sur les processeurs Intel). L'IOMMU est capable de filtrer efficacement tous les accès DMA, sans les désactiver complètement. Cela s'appelle DMAR, ou DMA Remappage. La spécification ACPI spécifie un blob de données appelées la table DMAR qui est stockée dans le BIOS que l'IOMMU utilisera pour isoler les périphériques individuels compatibles DMA, redirigeant tous les accès directs à la mémoire vers une zone de mémoire spécifique et sûre. Sur de nombreux systèmes Linux, vous devez l'activer en démarrant avec le paramètre intel_iommu=on (pour Intel) ou AMD_iommu=force (pour AMD). Ces options ne sont pas activées par défaut car de nombreux BIOS ont une table DMAR cassée, empêchant le démarrage du système ou provoquant Vérifiez si votre système utilise l'IOMMU pour isoler les périphériques si dmesg | grep -e IOMMU -e DMAR affiche Intel(R) Virtualization Technology for Directed I/O (évidemment spécifique à Intel) dans la sortie et si plusieurs périphériques sont référencés.
Détournement du CPU lui-même en utilisant JTAG
JTAG est un groupe de normes spécifiant des interfaces et des protocoles pour le débogage matériel. Une norme, intitulée IEEE 1149.1, permet de mettre un processeur en mode de débogage de bas niveau simplement en attachant une sonde JTAG sur un en-tête sur la carte mère. Les systèmes Intel utilisent un en-tête propriétaire modifié, appelé ITP-XDP. Si quelqu'un veut attaquer un serveur chiffré avec JTAG, il doit connecter la sonde à l'en-tête XDP. Même si l'en-tête n'est pas clairement visible, les traces seront toujours là, et seront toujours vivantes et viables. Dès que la sonde est connectée, tous les cœurs de processeur s'arrêteront et l'attaquant pourra lire le contenu de tous les registres, lire toute la mémoire, écrire dans tous les registres, écrire dans n'importe quelle mémoire, suivre l'instruction CPU par instruction, changer le pointeur d'instructions, suspendre et mettre en pause le CPU, et bien plus encore. En bref, JTAG permet à un attaquant de prendre le contrôle total du CPU, en le contrôlant comme une marionnette, et il ne peut rien y faire.
Il n'y a aucun moyen d'atténuer une attaque JTAG dans un logiciel. Essentiellement, toutes les cartes mères ont des en-têtes XDP. Un moyen possible de l'atténuer, si vous avez un accès physique au serveur et que vous êtes autorisé à le modifier de manière permanente (par exemple colo, hébergement à la maison, etc.), vous pouvez utiliser une résine époxy forte et la placer sur l'en-tête XDP. Cette technique peut être encore améliorée en plaçant une épaisse plaque de métal sur l'époxy, empêchant les forets fins de casser des trous dans l'époxy. On m'a dit qu'il n'y avait pas à craindre qu'un attaquant perce à travers le fond, car il y a tellement de couches de traces dans une carte mère moderne que cela détruirait le système. Je ne sais pas si cela entraînerait l'arrêt du système ou empêcherait JTAG de fonctionner, il est donc préférable de mettre de l'époxy et une tôle des deux côtés.
Attaques exotiques, extrêmement difficiles ou théoriques
Il y a le problème bien connu des attaques par canal latéral par l'analyse de puissance et l'analyse thermique. Cela peut être possible lorsque le programme effectuant le chiffrement/déchiffrement n'utilise pas d'opérations à temps constant où elles sont critiques, ce qui entraîne des retards détectables ou de grandes consommations d'énergie qui se produisent à différents moments en fonction de la valeur de la clé. Les pilotes de cryptographie modernes sont peu susceptibles d'avoir ce problème, et l'accélération matérielle comme AES-NI en fait encore moins un problème. Les atténuations incluent l'utilisation de chiffrements qui prennent en charge l'accélération matérielle, comme AES sur le matériel approprié, des chiffrements qui ont de petites boîtes en S et peuvent être optimisés en utilisant le découpage de bits, comme Serpent, ou en utilisant une séparation rouge/noire pour une EMSEC appropriée (recherchez NATO SDIP-27 Pour les spécifications, il vous suffit généralement d'acheter un ordinateur approuvé).
Les analyseurs de bus logique peuvent être connectés directement à toute trace ou fil électrique exposé, sans jamais avoir besoin de couper le circuit. Cela est possible avec la DRAM, mais à mesure que les vitesses augmentent de plus en plus, cela devient de plus en plus difficile. PCIe utilise des techniques pour améliorer la vitesse, ce qui entraîne des phénomènes électriques très étranges que les analyseurs logiques n'aiment pas du tout (une voie PCIe n'a pas une séparation nette entre salut et lo, car les données saignent dans les lignes adjacentes et les signaux électriques résonnent d'avant en arrière). C'est peut-être possible, mais ce serait difficile à faire. Si votre concentrateur racine PCI prend en charge AER, le rapport d'erreurs, vous pouvez configurer votre système pour désactiver immédiatement le maître de bus de tout périphérique qui signale les erreurs corrigibles, plutôt que de continuer, comme c'est le cas par défaut. Cette technique à échec rapide peut détecter une tentative d'insertion d'un analyseur de bus logique dans un périphérique PCIe. Parce qu'il s'agit d'une telle attaque théorique et exotique qui peut très bien ne pas être possible de toute façon, et l'atténuation n'est pas testée (simplement une idée qui est née lors d'une conversation que j'ai eue avec un chercheur), j'explique simplement le concept, pas le étapes pour le faire. Il est probable que vous n'ayez pas à vous soucier de lire les données PCIe de toute façon, car il est peu probable qu'elles portent la clé, mais je l'inclus par souci d'exhaustivité.
Enfin, et de la manière la plus irréaliste, un attaquant extrêmement avancé pourrait déclencher des bogues dans le CPU en exploitant le timing et les bizarreries de puissance. Ces attaques (appelées attaques glitching) sont couramment utilisées pour exploiter de simples microcontrôleurs tels que les Atmel 8051 bon marché, mais ce sont de nombreux ordres de grandeur moins bien testés que les processeurs Intel. Les pépins peuvent impliquer de régler l'horloge ou les horloges sur des valeurs invalides ou instables, de mettre les tensions hors spécifications, de violer les spécifications de synchronisation, etc. Dans des cas particulièrement avancés, les pépins peuvent impliquer une technique appelée injection de défaut laser, où le processeur est décapé (le haut est soigneusement dissous ou brûlés), et un laser contrôlé avec précision est utilisé pour provoquer une activité électrique dans des zones spécifiques, provoquant des défauts. L'objectif final du glitch est de provoquer une erreur qui modifie l'état interne du périphérique à un état plus convivial pour les attaquants, tel que celui où le maître de bus peut être activé ou les restrictions IOMMU peuvent être rompues. Les exemples réels avec les microcontrôleurs 8051 tentent souvent de désactiver les bits de verrouillage de sécurité, tels que le bit de lecture du micrologiciel. Ils réussissent presque toujours sur des appareils aussi simples.
tout atténuer, au moins en théorie
Enfin, il existe une atténuation commerciale qui protège de tout sauf de l'attaque JTAG, et c'est PrivateCore vCage. Il s'agit d'une solution de virtualisation qui crypte toute la mémoire et place le noyau dans le cache du processeur. DMA sont fondamentalement empêchées et le TCB (Trusted Computing Base) est entièrement réduit au CPU lui-même, ce qui signifie que peu importe ce qui est détourné, seul le CPU doit être approuvé. En théorie, même Les attaques JTAG pourraient être vaincues si le système exécutait tout le code non approuvé dans une enclave SGX. Cela fonctionnerait parce que le mode sonde, le mode CPU JTAG place le système, ne peut pas être utilisé dans le contexte d'une enclave SGX. Malheureusement, cette implémentation est fermée source, et le service est très cher, il est donc plus intéressant d'un point de vue académique.