Entre deux malversations gentilles dans un réseau, nous nous attachons à développer des outils libres que nous pensons utiles pour la communauté (ou à minima utiles à nos progrès en développement).
Par soucis d’impartialité, Astar ne commercialise aucun produit de sécurité. Nous tenons à éviter le travers (un peu trop répandu) des sociétés de sécurité qui font du service ET du produit: “Votre problème c’est que vous n’avez pas de SIEM et vous savez quoi ? Il se trouve justement que nous commercialisons un SIEM”.
Tous nos outils sont donc sous license OpenSource et utilisables gratuitement.
Actuellement, 6 projets sont ouverts.
Parce que tout le monde n’a pas les moyens de s’offrir un SIEM triple A à 100k, Honeyris propose une alternative “low cost” pour détecter les intrusions en cours dans votre réseau.
Le principe est sybillin : Honeyris est une machine (ou une VM) placée dans le réseau au milieu des autres et qui n’intéragit avec personne. Si elle reçoit une requête (ARP, IP, ICMP, TCP, UDP, …), elle sait qu’il s’agit forcément d’un cas non légitime (évidemment la gateway est whitelistée tout comme les serveurs DHCP, DNS, etc.).
Il peut s’agir d’un équipement mal configuré (auquel cas il est toujours bon de s’en rendre compte pour économiser de la bande passante) ou d’un attaquant en train d’effectuer des mouvements latéraux.
Il y a donc très peu de chances de faux positif (contrairement aux SIEM du marché) et des chances moyennes de faux négatif. En effet, un attaquant ayant compromis une machine initiale et qui ne se répand qu’en ciblant le domaine Active Directory et ses machines déclaréés passerait entre les mailles d’Honeyris.
Dans tous les autres cas : scan nmap, arp-scan, netbios ping, etc. il sera identifié.
Bien entendu, cela nécessite aussi qu’Honeyris se trouve dans le même segment réseau.
La philosophie de cet outil est donc de fournir un moyen simple et gratuit de détecter une attaque en cours suffisamment tôt.
Tester que ses utilisateurs respectent bien les consignes de robustesse pour leurs mots de passe est essentiel.
Cela demeure cependant difficile pour qui n’a pas de connaissances en intrusion informatique. Or il serait souhaitable que chaque entreprise effectue un test de robustesse des mots de passe du parc informatique, au moins une fois par an.
En dehors des tests d’intrusion et audits de vulnérabilités (qui ne testeront probablement pas ce point de manière exhaustive), il peut être utile que les entreprises sachent gérer cette tâche par leurs propres moyens.
Or il n’existe pas vraiment d’outil sur étagère pour ce besoin.
Le projet Lestat consiste à fournir un framework, aux entreprises, pour auditer la robustesse des mots de passe des comptes de leur Active Directory.
Il facilite aussi, lors d’un pentest, le post-traitement des comptes crackés pour isoler rapidement les comptes prometteurs parmi eux (à la base il servait surtout à ça d’ailleurs).
Ce chantier consiste à essayer d'établir un référentiel des tests qui devraient être réalisées dans un réseau interne d’entreprise pour couvrir l'état de l’art.
La philosophie du projet est d'être un OWASP des audits internes. Bien qu’il s’agisse de quelque chose de moins focalisé et pour lequel il sera donc délicat d’avoir un niveau de précision équivalent.
Des projets similaires existent et sont bien plus détaillés comme le PTES mais ils sont majoritairement abandonnés.
Une des difficultés majeures d’un tel projet consiste à décider d’un cloisonnement pertinent entre les types de vulnérabilités à tester.
Par exemple, est-ce qu’un mot de passe faible est un problème d’authentification, un problème de configuration (car on a laissé l’utilisateur choisir un mot de passe peu robuste) ou un problème de sensibilisation du personnel (que l’on a mal entrainé à choisir ses mots de passe) ?
Finalement le choix s’est porté sur une approche qui suit les lignes de défense en profondeur. De la sensibilisation de l’utilisateur en front pour éviter qu’il ouvre une pièce jointe malveillante jusqu'à l’architecture du réseau qui peut limiter sa propagation en bout de chaine, nous descendons dans les couches d’abstraction.
Ce projet nous sert également de pense bête pour rapidement retrouver les commandes que l’on utilise pas fréquemment. A cet effet, il a été forké de l’outil cheat qui nous permet de retrouver ces exemples directement en ligne de commande.
Aujourd’hui tout le monde a envie de faire du python. La plupart des exploits sont maintenant rédigés en python.
Or dans le monde des scanners de vulnérabilités, la seule solution open source et gratuite, OpenVAS, fonctionne sur le pseudo langage NASL qui est… peu séduisant et que personne n’a envie d’appréhender.
L’idée est ici de proposer un scanner de vulnérabilités gratuit et libre, en python et dont on puisse facilement écrire des plugins en python.
Rattraper le retard sur OpenVAS serait fastidieux, mais des raccourcis peuvent être trouvés, notamment quant à la manière de détecter les manques de patch de sécurité.
Plutôt que d’embarquer un plugin pour telle version d’apache qui contient telles vulnérabilités, il est plus intéressant de compiler dynamiquement la liste des vulnérabilités connues qui affectent un CPE donné. Cela demande de faire un travail de parsing sur la base des CVE (et autres bases de vuln) pour les associer proprement à des CPE et de pouvoir sortir un CPE d’après une bannière. Heureusement ce travail a déjà quasiment entièrement été fait pas nos amis de Vulners dont l’API et la base sont librement accessibles.
Il devient même alors possible de distinguer parmi les CVE qui affectent un CPE, ceux qui sont en fait gérés par retro-portage dans telle ou telle distribution. Et donc de réduire significativement les faux positifs dès lors que l’on a pu identifier la distribution que l’on attaque.
Ce gros morceau achevé, il reste à incorporer :
Ce projet est tiré de SubZero (ci-dessus) et s’adresse aux entreprises qui n’ont pas de moyen de vérification de leurs vulnérabilités en interne. Il s’agit d’une approche “best effort” qui permet, depuis une liste de COTS (logiciels sur étagère), d’obtenir la liste des vulnérabilités associées.
L’outil ingère une liste de CPE qui est un format qui standardise les noms de logiciels, appliances, systèmes d’exploitation, …
Il restitue ensuite une liste de CVE qui est un format standard pour décrire les vulnérabilités informatiques.
Donc si vous arrivez à faire un inventaire de vos outils au format CPE, vous pouvez obtenir automatiquement un rapport CSV ou PDF qui décrit et classe les vulnérabilités qui concernent ces outils.
cpe2cve se présente comme un programme Linux en ligne de commande OU une application Web. Dans tous les cas, c’est un outil on premise.
Après des années d’audits internes en milieu Windows, on se rend rapidement compte du bond spectaculaire qui pourrait être effectué en sécurité si les Active Directory n'étaient pas aussi moisis par défaut.
Alors que l’attaque Pass-The-Hash existe depuis quasiment 12 ans, Microsoft n’a fourni une correction satsifaisante que sur les toutes dernières versions de Windows. 12 ans pour corriger une vulnérabilité qui permettait souvent de devenir Administrateur sur les autres machines du réseau en quelques minutes.
Il s’agit là d’un exemple parmi tant d’autres.
Le monde Linux jouit d’une meilleure réputation en termes de sécurité de l’OS. A tort ou à raison, mais l’on peut au moins reconnaitre aux différentes distributions que les vulnérabilités découvertes sont corrigées.
Cependant, utiliser des postes de travail Linux en entreprise semble encore loin. Notamment car la fédération de ces postes au travers d’une interface graphique qui permette “simplement” de pousser les configurations de son choix, d’autoriser ou non des programmes, etc. (comme le fait un Active Directory) n’existe pas telle quelle.
Luxin Tenebris se voudrait un AD pour Linux.
Qu’on ne crie pas tout de suite à la barbarie. L’idée n’est pas tant de créer des choses nouvelles que d’agréger simplement des choses qui existent déjà: FreeIPA, Zorin Grid, The Foreman, … aux travers de protocoles conçus de manière robuste pour éviter de batir des cathédrales sur de la mousse (comme l’AD Windows): SSH notamment pour remplacer SMB/RPC.
Un problème absolument délirant aujourd’hui réside aussi dans la capacité d’une entreprise d'être capable de répondre à :
Deux question devenues fondamentales avec le RGPD. Pourtant si vous vous essayez à l’audit de droits Windows en milieu Active Directory, vous souffrirez mille tourments. Aujourd’hui quelques outils proposent de faire ce travail maisils coutent un bras…
On marche sur la tête, répondre à ces deux questions, dans un milieu de postes fédérés, devrait être trivial.
Ce sera notamment un objectif de Luxin Tenebris, fournir un console de vision globale du SI. Pouvoir mapper une machine avec sa configuration matérielle (nombre de coeurs, RAM, etc.), logicielle (OS, programmes installés en plus de l’OS nu), son utilisateur, les services qu’elle expose (SSH, Apache, FTP, …), les utilisateurs de ces services, etc.