Yo, Hiro ici. J'ai fouiné sur le bureau de Johnny. Il a les trucs typiques. Photo de famille. Un chien cute. Je vais pas commenter sur les kids.

Mais c'est pas ce que je cherche. Ces photos vont pas m'acheter du souper.

PowerShell. ls cert:\localmachine\my. Ouais, il y a du stuff.

get-item .\54798D42DD60FF87761782345FBB234A04F2BEFB | select *

Oh. Wow.

EnhancedKeyUsageList: {Code Signing (1.3.6.1.5.5.7.3.3)}!

Joyeux Noël, Hiro.

Je viens de trouver un certificat de signature de code enterprise. Assis sur la workstation d'un développeur. Pas de HSM. Pas de workflow d'approbation. Pas de log d'audit. Pas de monitoring sur qui l'utilise ou ce qu'il signe.

Laisse-moi penser à ce que les certificats de signature de code font.

Un certificat de signature de code prouve que le code a été signé par quelqu'un en qui l'enterprise fait confiance. Windows Defender vérifie la signature. Si elle est valide et que le cert vient d'une source approuvée, le code roule. SmartScreen vérifie la signature. Si elle est approuvée, pas d'avertissement. Le code roule.

Un certificat de signature de code est une credential qui accorde l'exécution approuvée.

J'exporte le cert et la clé privée. Prend trente secondes. J'ai la credential maintenant. Je l'utilise pour signer un module PowerShell. Le module a une backdoor dedans. Beacon de command-and-control, whatever. La signature est cryptographiquement valide parce que j'ai utilisé un certificat enterprise pour la signer.

Maintenant je dois la faire rouler à quelqu'un. C'est la seule partie difficile, et c'est pas difficile.

J'envoie un courriel à l'équipe de serveurs. Sujet : « Module d'automatisation de patch, de IT ». La pièce jointe c'est le module PowerShell signé. « Importez ça et roulez-le contre vos serveurs de mise à jour pour accélérer les cycles de patch. Nouveau tooling de central IT ».

Certains la roulent. Parce que ça vient du PKI enterprise lui-même. Parce que la signature s'est validée. Parce que Windows n'a pas criaillé après eux.

Le module roule. Probablement comme SYSTEM parce qu'il touche à l'infrastructure de patch. J'ai SYSTEM sur leurs serveurs. J'installe de la persistence. Je pivote.

Toute l'attaque repose sur une chose : un certificat qui était supposé prouver que le code est légitime vient juste de prouver que mon code est légitime.

L'enterprise faisait confiance au certificat. Donc l'enterprise me fait confiance maintenant.

Si tu es un défenseur, voici ce qui vient d'arriver.

Les certificats de signature de code sont une credential qui accorde l'exécution approuvée. Ils devraient être traités comme infrastructure Tier 0.

La plupart des enterprises ne le font pas.

Les certificats de signature de code sont émis aux développeurs. Ils vivent sur les workstations des développeurs ou les laptops des développeurs. Ils se font check in au source control parfois (mauvaise pratique mais ça arrive). Ils sont sauvegardés. Ils sont peut-être dans un password manager. Ils sont définitivement pas HSM-backed. Ils sont définitivement pas monitorés pour utilisation.

Les développeurs qui les tiennent ne pensent pas à eux comme des credentials. Ils pensent à eux comme des certificats — juste un autre truc qui vient avec une clé. Les admins qui les émettent ne pensent pas à eux comme Tier 0. Ils pensent à eux comme des tools développeurs.

Mais un certificat de signature de code c'est une clé à toute l'enterprise. Tout code signé par ce certificat est approuvé par Windows. Tout malware signé par ce certificat est approuvé par Windows. Toute backdoor signée par ce certificat passe chaque vérification de validation.

Hiro n'a pas besoin de cracker Windows Defender. Il n'a pas besoin de désactiver SmartScreen. Il n'a pas besoin de bypasser quoi que ce soit. Il a juste besoin de signer son malware avec le certificat propre de l'enterprise.

Ce qu'il faut vérifier cette semaine

Regarde ton déploiement de certificats de signature de code.

Où sont-ils stockés? Si la réponse c'est « sur les workstations des développeurs » ou « sur les serveurs de build » ou « dans le password manager partagé de l'équipe », tu as un problème. Les certificats de signature de code devraient être HSM-backed. Ils devraient être stockés dans un Hardware Security Module qui ne permet pas l'export. Ils devraient seulement être utilisables via l'API du HSM.

Qui a accès? Si la réponse c'est « tout développeur sur l'équipe » ou « toute l'équipe de build », tu as un problème. L'accès aux certificats de signature de code devrait être spécifique, auditable, et rare. Pas tout développeur n'a besoin de signer du code. Les développeurs qui ont besoin de signer du code ont besoin que cet accès soit loggé.

Est-ce que tu monitorises l'utilisation? Si la réponse c'est « non », tu as un problème. Chaque utilisation d'un certificat de signature de code devrait générer un log d'audit. Quoi a été signé? Quand? Par qui? Si Hiro exporte la clé privée et signe une backdoor offline sur sa propre machine, tu ne le sauras jamais. Mais si le certificat est HSM-backed et accessible via l'API du HSM, chaque utilisation se log.

Est-ce que les certificats se font rotater? Si un certificat a été utilisé pendant trois ans, la clé privée a trois ans d'exposition. Les certificats devraient se faire rotater annuellement. Quand un certificat se fait rotater, l'ancien devrait être révoqué et monitoré pour utilisation suspecte.

Le principe de fermeture

Les certificats de signature de code sont des credentials qui permettent l'exécution approuvée sur chaque système dans ton environnement. Ce ne sont pas juste un autre certificat. Ce n'est pas un tool développeur. C'est équivalent Tier 0 parce que n'importe qui avec accès à la clé privée peut faire que Windows approuve n'importe quel code qu'il veut.

La plupart des enterprises les traitent comme s'ils étaient Tier 2. Ils vivent sur les workstations des développeurs. Ils sont protégés par les mêmes pratiques que les certificats réguliers. Ils ne sont pas audités. Ils ne sont pas monitorés.

Hiro en a trouvé un qui était protégé par un password que Johnny s'était souvenu. Ça lui a pris six minutes de « trouvé le cert sur le disque » à « possède l'enterprise ».

Le modèle de tiering a une réponse pour celui-ci aussi. Il dit que les certificats de signature de code devraient être traités comme Tier 0. La plupart des organisations ont décidé que c'était inconvénient.

Hiro est reconnaissant pour l'inconvénient.