Quand une vulnérabilité logicielle remet en cause la sécurité physique

Il y a quelques mois, j'ai décidé de jeter un œil au PremiSys IDenticard, un système d'identification et de gestion des accès aux bâtiments.

Ce logiciel permet aux clients de créer des cartes d'identité personnalisées pour le personnel, de gérer les niveaux d'accès pour des pièces ou des parties spécifiques d'un bâtiment, ainsi que de gérer à distance les lecteurs d'identité et les dispositifs similaires. Il n'était pas aussi sécurisé qu'on aurait pu l'imaginer. 

Au moment de cette analyse, la version du logiciel à laquelle j'avais l'autorisation d'accéder était la 3.1.190. Je n'avais pas accès à l'équipement physique (badges ou autres), ce qui a limité la portée de mes recherches. Cela dit, mes efforts n'ont pas été vains.

Après avoir trouvé plusieurs failles de divers degrés de gravité, Tenable Research a tenté une divulgation coordonnée avec le fournisseur. Après 45 jours et plusieurs tentatives infructueuses pour contacter le fournisseur, Tenable Research a divulgué ses conclusions au CERT, qui a également tenté de contacter le fournisseur. Après 90 jours, Tenable Research a rendu publiques ses conclusions. Le texte qui suit décrit la découverte d'une porte dérobée codée en dur qui donne un accès administratif au système de badge.

Modèle de menace

Comme on peut s’y attendre, la surface d'attaque de ce système de contrôle d'accès, riche en fonctionnalités, est assez grande. La création d'un modèle de menace raisonnable pour l'ensemble du système de badges, des imprimantes de badges, des mécanismes d'authentification, des serrures, etc. n'aurait pas été pratique vu le temps limité dont je disposais. Heureusement, le fait que je n'avais pas accès à la plupart de ces composants, a beaucoup simplifié le ciblage et la cartographie de la surface d'attaque du service d'hébergement. Après avoir joué avec l'application pendant un certain temps pour comprendre l'utilisation pour laquelle elle était prévue, avoir regardé la documentation du fournisseur et avoir jeté un œil aux ressources utilisées par le service, j'ai trouvé ce qui suit :

 
L'image ci-dessus manque un peu de contenu en raison d'une portée considérablement réduite, mais elle est assez appropriée pour donner un cadre de référence pendant le processus de recherche.  
Un module au nom intéressant

PremiSys est une application basée sur .Net. Heureusement, il existe une myriade d'outils disponibles pour décompiler les applications .Net. J'ai choisi d'utiliser le décompilateur de .Net dotPeek de Jetbrain. D'après mon expérience, cet outil est assez rapide et précis. De plus, son interface permet une navigation facile, la recherche, et offre la capacité de rebondir entre les références au code ou au contenu connexe.

Selon le modèle de menace, il existe cinq extrémités distinctes sur lesquelles il est possible d'enquêter. Cela signifie qu’en naviguant dans la base de code préalablement décompilée, je devais me concentrer sur les fonctionnalités directement liées à ces extrémités - idéalement en accordant une attention particulière aux fonctionnalités influencées par les entrées des utilisateurs.

Un module dans la base de code s’appelle PremiSysWCFService. Du point de vue de l'utilisateur final et vu la documentation, il semblerait que ce service soit conçu pour servir de tableau de bord pour le serveur d'application principal et de point d'accès interne WCF (Windows Communication Foundation) pour les autres dispositifs et services clients. La WCF est un cadre pour la construction d'applications orientées services. Ce cadre est similaire à SOAP ou REST en ce sens que les données sont échangées entre les extrémités, mais différent en ce qu'il nécessite des implémentations spéciales afin d'interagir avec lui. En surface, il semble que PremiSysWCFService existe surtout pour fournir des informations sommaires sur le service et les périphériques connectés (utilisateurs badgés, portes problématiques, etc.), mais après avoir creusé davantage, il s'avère qu'il est capable de faire beaucoup plus.

En effet, nous avons trouvé dans son module du code faisant référence à ce qui semble être une routine d'authentification standard. La voici en détail :

 

namespace IDenticard.Common.Security
{
  ...
  public static class ApiSecurity
  {
    private static readonly IDMembershipProvider UserManager = (IDMembershipProvider) Membership.Provider;
    private const string AdminShortCircuit = "IISAdminUsr";
    private const string PasswordShortCircuit = "Badge1";

    [Localizable(false)]
    public static void AuthenticateLogin(string username, string password)
    {
      if (!ApiSecurity.IgnoreAuthentication(username, password) && !ApiSecurity.UserManager.ValidateUser(username, password))
        throw new Exception("Login Failed, unable to proceed.");
    }

    private static bool IgnoreAuthentication(string username, string password)
    {
      if (username == "IISAdminUsr")
        return password == "Badge1";
      return false;
    }
  }
  ...
}

 

Oui, IgnoreAuthentication() fait exactement ce dont il a l’air, tant que les identifiants fournis par l'utilisateur correspondent aux valeurs codées en dur. Tandis qu'un attaquant plus déterminé développerait probablement un client WCF personnalisé pour interagir avec cette extrémité de service, j'ai décidé de prendre un raccourci et d'utiliser WCF Storm LITE, une application de test gratuite pour les services WCF. Il liste les méthodes et les paramètres de saisie disponibles, tout en offrant une interface qui permet de manipuler et de soumettre des requêtes à la volée.



 

Il s'avère que cette porte dérobée codée en dur permet aux pirates d'ajouter de nouveaux utilisateurs au système de gestion des badges, de modifier des utilisateurs existants, de supprimer des utilisateurs, d'attribuer des permissions et à peu près toutes les autres fonctions administratives.

Des priorités mal placées

La plupart des gens ne se rendent pas compte que de nombreuses entreprises comptent sur des tiers pour installer et maintenir leurs systèmes de badges. Il n'est pas rare que ces tiers installent un système avec les paramètres par défaut et ne s’en préoccupent pas, jusqu’à la prochaine mise à jour payante quelques mois après. C'est là que les priorités sont faussées. Le fournisseur de contrôle d'accès crée des logiciels qu'un tiers installe pour un client. Le client utilise ce dont il a besoin tout en laissant de nombreuses fonctionnalités inutilisées mais toujours activées. Cela conduit à une cyber-exposition inutile de l'infrastructure physique critique et à un point d'entrée possible dans l'infrastructure numérique.

Bien que les systèmes de badges doivent être isolés du reste du réseau, nous savons tous que tout le monde ne va pas suivre ces meilleures pratiques. De plus, il est probable que la plupart des personnes qui administrent ces applications ne sont même pas au courant de toutes les fonctionnalités supplémentaires et des doodads qui y sont intégrés. Dans un déploiement en production, la surface d'attaque de ce service unique est absolument massive. Si une entreprise en dépend pour sa sécurité physique, des erreurs logicielles simples et critiques comme celles-ci doivent être prises au sérieux.

J’ai partagé avec vous le cheminement qui m’a permis de découvrir l’une des failles logicielles de la version 3.1.190 de PremiSys IDenticard. En exploitant cette faille, un individu mal intentionné aurait pu s’introduire dans le système et y causer d’importants dégâts, ou aurait tout simplement pu s’introduire physiquement dans le bâtiment pour y faire ce que bon lui semble. Cela met en lumière le lien sensible entre sécurité informatique et sécurité physique : quelle que soit l’épaisseur d’une porte, il faut s’assurer que seules les personnes réellement habilitées puissent l’ouvrir.