En 2019 Matrix a subi une intrusion sur ses serveurs. Ils en retirent plusieurs recommandations.
Sur le plan technique :
- Ne PAS utiliser l'agent forwarding avec SSH, privilégier le ProxyJump (
-J) - placer le fichier
authorized_keyssous le contrôle de root plutôt que sous celui de l'utilisateur - avoir des procédés automatisés pour détecter les mises à jour à lettre en œuvre
- segmenter le réseau, limiter les privilèges au minimum nécessaire
Sur le plan organisationnel:
- ils notent le danger des infrastructures (ou outils) "legacy", maintenus en fonctionnement et laissés en l'état quand les efforts se concentrent sur une nouvelle architecture/version plus sûre: il faut impérativement avoir une personne en responsabilité de lettre fin à cette situation.
- il faut des check-lists pour la remise en route des services et la rotation des secrets
- lors d'un incident, il faut quelqu'un pour coordonner les travaux, gérer la communication interne et la communication externe: si peuvent être remplies par la même personne, il s'agit bien de 3 missions distincted
Pour un projet informatique, l'intégration continue permet de faire des opérations automatiquement: tests, construction de binaires, déploiement. Le déploiement et certains tests utilisent des éléments secrets (clés privées, mots de passe) tandis que d'autres ne nécessitent aucune information privée.
Lors du développement, les tests sont utilisés pour contrôler la qualité de modifications proposées au logiciel. Si les propositions externes sont permises (développement ouvert), L'outil d'intégration continue se retrouve à exécuter le code ainsi soumis, potentiellement malveillant. Celui-ci ne doit pas avoir accès aux secrets, sous peine de voir un attaquant les exfiltrer par ce canal.
Les opérations de déploiement et de tests avec secrets sont donc réservées au code approuvé et seuls les tests n'utilisant pas de secrets peuvent être réalisés sur les propositions externes. De plus, les secrets utilisés dans le premier cas ne doivent pas être exposés dans le second.
Pendant une semaine, Travis CI exposait des secrets aux code qui n'était pas sensé y avoir accès, mettant en danger les nombreux projets utilisant cet outil.
James 'albinowax' Kettle explore tout un tas de choses qui peuvent mal se passer à cause des proxys web :
- le serveur proxy et celui de destination n'interprètent pas les requêtes de la même façon (http desync attacks)
- le serveur proxy émet des requêtes HTTP ou DNS sur la base de ce qu'il voit passer (cracking the lens)
- ils ne parlent pas le même dialecte (http/2 vs http/1.1) (l'article en question)
Toutes ces choses peuvent permettre à un attaquant de cartographier le réseau cible, d'accéder à des ressources normalement cachées ou d'accéder aux données d'autres utilisateurs du même service.
Une isolation insuffisante entre les notebook jupyter exécutés par différents clients sur le cloud Azure (Microsoft) permettait, après plusieurs étapes, à un client mal intentionné d'accéder aux données d'autres clients.
TLS est un protocole de chiffrement permettant à 2 partenaires de mener une discussion sans que celle-ci soit lue par un tiers, et certifiant l'identité d'au moins un des 2 partenaires à l'autre partenaire.
Il est utilisé pour sécuriser d'autres protocoles, répondant à des besoins spécifiques (HTTP pour le web, SMTP et IMAP pour l'envoi d'emails, FTP pour le transfert de fichiers, T-SQL pour l'interrogation de bases de données SQL server).
TLS et le protocole chiffré par TLS peuvent s'articuler de 2 façons :
- on commence par établir la connexion chiffrée avec TLS puis on démarre le second protocole, entièrement chiffré (mode "implicite")
- on commence le protocole d'échange, puis les participants signalent leur souhait de chiffrer la communication, l'échange TLS se met en place puis le premier protocole reprend son cours, désormais protégé par le chiffrement (mode "explicite").
Le premier mode est considéré comme plus sûr mais, pour des raisons de rétrocompatibilité, de nombreux protocoles utilisent encore le mode explicite.
Cette étude fait le point sur de nombreuses failles logicielles permises par le mode explicite de SMTP ("starttls"), le protocole d'envoi de mails. Quasiment tous les clients mails sachant utiliser smtps (TLS implicite pour SMTP), il est recommandé d'autoriser seulement ce mode dans les clients SMTP.
Ayant identifié récemment quelques fragilités dans l'usage de TLS avec SQL Server, je ne serai pas surpris si certaines de ces failles trouvaient à s'appliquer pour le T-SQL :-) .
Les services de certificats AD sont parfois un point faible de l'environnement, permettant des mouvements latéraux ou une escalade de privilèges au sein du domaine.
L'article commence par une introduction très claire à l'authentification dans le monde Active Directory.
Une personne qui observe le trafic chiffré entre un visiteur et un site web peut reconstituer sa navigation en mesurant la taille de chaque page consultée et des autres éléments chargés en même temps, en s'appuyant sur une image précise du site (poids de chaque page, éléments associés à chaque page, liens entre ces pages).
Cela ne permet pas de déchiffrer des messages particuliers envoyés par le visiteur au site web (mot de passe, code de carte bancaire ...).
Cellebrite vend un logiciel pour extraire plein d'informations d'un portable arraché aux mains de son propriétaire (e.g. en garde à vue), dont les clés de déchiffrement de conversations Signal. Signal remarque que leur logiciel n'est pas sécurisé et distribue des fichiers exploitant ces failles aux utilisateurs de l'application.
Anyone familiar with software security will immediately recognize that the primary task of Cellebrite’s software is to parse “untrusted” data from a wide variety of formats as used by many different apps. That is to say, the data Cellebrite’s software needs to extract and display is ultimately generated and controlled by the apps on the device, not a “trusted” source, so Cellebrite can’t make any assumptions about the “correctness” of the formatted data it is receiving. This is the space in which virtually all security vulnerabilities originate.
La machinerie k8s répartit des pods (groupe de conteneurs) sur des machines formant un cluster de façon à garantir la haute disponibilité. Les pods se composent en services pour mettre en œuvre une application complète. Tous ces objets et leurs droits d'accès sont gérés par k8s. Les failles peuvent permettre à un conteneur compromis de prendre le contrôle d'un pod, d'un node (machine physique ou virtuelle qui héberge les pods) ou d'objets k8s, voire du cluster complet). Xavier Mehrenberger présente tout ça puis 2 vecteurs d'attaque : helm (gestionnaire de paquets pour k8s), dans sa version 2, avait les droits d'administration du cluster mais n'effectuait par défaut aucune authentification, et la compromission d'images docker via le respository (parfois accessible en écriture) ou la liaison entre k8s et le repository (non chiffrée par défaut !)
Le filtrage du réseau entre les conteneurs doit être pris en charge par un network plugin (il en existe plusieurs, avec des fonctionnalités différentes). Guillaume Fournier examine la possibilité d'affiner les règles en contrôlant les processus de départ et/ou d'arrivée, et pas seulement les conteneurs, comme on le ferait à l'échelle d'un système avec un pare-feu classique.
Frédéric Raynal et Damien Aumaitre remarquent que kubernetes fonctionne comme un système d'exploitation, dont les processus seraient les pods (les threads les conteneurs), où le noyai est en charge de la bonne exécution de chacun et d'une juste répartition des ressources. Les modalités d'attaque classiques (compromission de processus, élévation de privilèges...) sont tout à fait transposable à cet environnement.
Les auteurs ont aussi donné une interview à nolimitsecu fin mars.
Une corruption de mémoire dans SQLite permettait, à partir d'un fichier de base de données compromis, de faire exécuter du code arbitraire au processus qui ouvre la base. Cela permettait ainsi de réaliser une élévation de privilèges sur iOS, via la base de données du carnet d'adresse.
L'attaquant utilise le caractère Turing-complet du SQL pour construire, en SQL, une ROP-chain permettant l'exécution de code.
Le client VPN AnyConnect de Cisco contient (contenait) de nombreuses failles de sécurité. En intégrant dans le logiciel un mécanisme de déploiement de configuration à distance et de mise à jour à distance de l'application sur les terminaux clients, celui-ci permet à un serveur compromis de prendre le contrôle de l'ensemble des clients.
Voir aussi CVE-2020-3433 : élévation de privilèges sur le client VPN Cisco AnyConnect (article en français, payant) : le client Windows contenait aussi des failles permettant à un processus malveillant sur la machine cliente d'effectuer une élévation de privilèges.