Au détour d'un chouette article présentant des failles identifiées sur Pagurz, le système de gestion des compilations de paquets pour Fedora, Thomas Chauchefoin constate :

We could also be overriding Python files of the application. It worked locally on a Pagure deployed from source, but when validating the finding on the staging instance, we noticed that this idea and a few other ones simply didn’t work! The instance must have been deployed from the Fedora RPM packages where application files are owned by root.

Moralité: quand on déploie une application, il faut s'assurer si possible que lors de son exécution elle n'ait pas les privilèges nécessaires pour modifier son code source ou même sa propre configuration.

Pour rassurer leurs clients sur la sécurité de leurs données, les fournisseurs cloud ont d'abord promis: "nous chiffrons les données au repos", empêchant qu'une sauvegarde égarée ou un disque décommissionné et perdu se promènent avec les données des clients.

Puis ils ont dit : "on va plus loin, on vous permet de chiffrer les données au repos avec VOTRE clé, c'est vous qui maîtrisez le stockage des données" (exemple avec Azure SQL). Et ça, c'est franchement bidon, car pour que les données soient utilisées dans le cloud, il faut leur transmettre notre clé. Que ce soit le client qui l'ait définie dans son coin ou le fournisseur cloud qui l'ait définie, à la fin c'est le fournisseur cloud qui l'a pour permettre aux systèmes de traiter les données. Donc en terme de contrôle, le client ne gagne pas grand chose.

Ce qui permet d'aller réellement plus loin, c'est la "virtualisation confidentielle", i.e. la capacité que peut avoir un système infonuagique de faire tourner du code et des calculs chiffrés, sans pouvoir connaître le contenu des données traitées. Et c'est un peu plus compliqué, notamment parce que ça nécessite une transparence totale de l'infrastructure du fournisseur cloud.

2 évolutions s'opèrent en parallèle en matière de logiciels :

• de plus en plus de logiciels promettent le chiffrement de bout en bout, rendant le fournisseur incapable d'accéder aux données de l'utilisateur (exemple: signal, réseau Matrix, Nextcloud avec chiffrement de bout en bout, etesync)
• de plus en plus de logiciels sont développés comme "applications web", servies depuis un site internet (exemple: le client Matrix element.io, Microsoft Office365, ...)

En l'état actuel des technologies, les deux objectifs ne sont pas totalement compatibles. Une application qui fait du chiffrement de bout en bout, si on y accède via le navigateur depuis un site internet tiers, sera vulnérable à une attaque sur ce site internet : un intrus peut modifier l'application de sorte à faire fuiter les clés de chiffrement de ceux qui l'exécutent dans l'intervalle, ou trouver une faille (type XSS) de façon à exfiltrer les clés de certain.e.s utilisateurs ou utilisatrices. À l'inverse, une application "desktop" sera moins rapidement attaquable : il faut que l'attaquant publie une version vérolée, puis que les utilisateurs mettent à jour, avant que l'attaque soit effective. Si la validité des mises à jour est contrôlée à l'aide d'un mécanisme de signature cryptographique (comme c'est le cas des mises à jour logicielles des distributions Linux), l'attaque est rendue encore plus compliquée.

Pour les applications web, l'équipe derrière eteSync propose une solution sous forme d'extension de navigateur qui vérifie la signature GPG des pages renvoyées par le serveur.

• github (comme gitlab, non mentionné par l'auteur) permet de lister les clés SSH publiques d'un utilisateur
• quelqu'un a compilé la table de toutes les clés, permettant de retrouver un utilisateur github à partir de n'importe laquelle de ses clés présentes sur github
• en pratique, les clients SSH annoncent la clé publique au serveur pour lui demander si elle est acceptée par celui-ci avant d'utiliser la clé privée

Tout ça mis bour à bout permet de :

• pour un serveur SSH : tenter de trouver l'identifiant github du quidam qui se connecte
• pour un curieux : en essayant toutes les clés publiques de la table (très long!), trouver l'identifiant github de personnes ayant accès à un serveur en particulier
• (non mentionné par l'auteur) établir la correspondance entre les comptes d'un même développeur sur plusieurs plateformes (savoir que HaxORR_du_91 sur github est Robert Dupont sur gitlab)

Il s'agit donc d'une belle fuite involontaire de données personnelles.

Pour se prémunir de telles attaques, il convient d'utiliser des clés SSH dédiées aux connexions sur les forges. Par exemple en générant une clé dédiée :

$ ssh-keygen -f ~/.ssh/id_git_ed25519 -t ed25519

Puis en indiquant uniquement ces clés à github/gitlab et en indiquant dans votre .ssh/config :

Host github.com gitlab.com [ou tout autre forge]
    IdentityFile ~/.ssh/id_git_ed25519.pub

Notez aussi que si vous utilisez une clé GPG publique comme back-end d'authentification SSH (ce qui est une bonne idée en soi !), on peut recalculer votre clé SSH publique avec l'option --generate-ssh-key (merci au collègue qui m'a transmis l'astuce).

L'OSINT a de beaux jours devant elle!

PyPI, le point central de distribution de paquets Python, demande aux mainteneurs des paquets les plus populaires de sécuriser leur compte avec un second facteur d'authentification, afin de limiter le risque que le compte soit compromis et tous les utilisateurs du paquet par ricochet.

Armin Ronacher s'élève vivement contre cette nouvelle exigence, trouvant gonflé de demander à celui qui a gentiment et gratuitement partagé son travail de supporter la charge de la sécurité des utilisateurs de son travail. Après tour, ça n'est pas "sa faute" si son travail devient populaire.

Dans Yes, I have opinions on your open source contributions, James Bennett lui répond que nous sommes tous et toutes utilisatrices des paquets Python (et pas seulement les grosses entreprises qui ont de l'argent), et que si la communauté propose de fixer des règles pour nous protéger tous, c'est être singulièrement asocial de les refuser.

Le premier commentateur sur Linux Weekly News remarque avec malice que les obligations qu'Armin Ronacher craint de voir imposées ensuite par PyPI (signature cryprographique, standard de qualité, traitement diligent des problèmes de sécurité, mesures en cas de défaillance du mainteneur) sont précisément les garanties apportées par les dépôts des distributions Linux. Ce sont les attentes des utilisateurs, y compris (à tort) quand ils utilisent PyPI, npm, cargo ou autre dépôt lié à un langage de programmation.

The lie marketers told us in the late 1990s and early 2000s (and that many in tech still believe as an article of faith) was that people don’t dislike ads, they only dislike irrelevant ones. [...] The problem is, to make ads ever more relevant, Big Tech firms have argued they must collect vast amounts of information about people to build dossiers on them that can predict their wants and needs.

Une faille permettait à une application confinée via flatpak de s'échapper de son confinement.

On apprend au passage qu'une application flatpak qui a accès au bus DBus org.freedesktop.Flatpak peut s'échapper en exécutant flatpak-spawn --host <commande>. C'est le cas notamment de l'IDE VSCode (et de sa version sans télémétrie VSCodium), ce trou dans la raquette étant nécessaire pour accéder à un terminal non confiné depuis l'IDE, comme documenté sur le dépôt de l'empaquetage flatpak de VSCode

• L'agent GPG stocke le mot de passe de la clé en mémoire vive.
• Ce mot de passe est lui-même chiffré : un dump de l mémoire vive ne permet pas de le retrouver en clair.
• Néanmoins, la clé de chiffrement de ce mot de passe étant aussi en mémoire, on peut la retrouver et déchiffrer le mot de passe à partir d'un tel dump : en l'état, la protection apportée par le chiffrement est illusoire (la fonctionnalité est présentée comme pouvant servir à terme avec un TPM)
• La clé privée protégée par le mot de passe est-elle aussi stockée en mémoire vive?
  • Si oui, il est inutile stocker aussi le mot de passe, c'est absurde. J'en déduis que non
  • Si non, ça fait une petite protection contre attaquant peu probable qui aurait accès à la mémoire vive (accès très difficile à obtenir) mais pas au système de fichiers (accès a priori moins difficile).

Points relatifs à la sécurité:
✅ stabilité du langage (mais il manque encore des choses indispensables)
✅ la doc indique clairement de séparer la résolution des dépendances par projet
⛔ installer une dépendance passer par l'exécution de code provenant de celle-ci

Arnaud Rebillot rend compte des efforts fructueux pour "debianiser" Docker-ce (sous le nom de docker.io). Le problème principal réside dans le fort couplage en go entre un projet et ses dépendances : il faut alors séparer en plusieurs paquets indépendants lorsque les dépendances peuvent être utilisées ailleurs et maintenues séparément, mais sans séparer les composants d'un même logiciel.

Il est ironique de déployer tout cet effort pour "débundler" (définitions) un outil destiné à faire tourner des applications qui le sont au plus haut point (les conteneurs).

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_keys sous 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

Le proxy SSH fonctionne de façon similaire au proxy HTTP avec CONNECT :

• le client C ouvre une session SSH (http) vers le proxy P
• dans cette session, il demande l'ouverture d'une connexion TCP par le proxy vers le serveur S de destination
• le serveur ouvre la connexion et la redirige vers le client (il encapsule la session TCP dans la session SSH ou HTTP)
• via cette nouvelle connexion TCP, le client démarre une nouvelle session SSH ou HTTP vers S.

Plusieurs conséquences:

• si les conditions de sécurité sont réunies, le proxy ne peut ni déchiffrer ni altérer la communication entre le client et le serveur de destination (conditions réunies = usage de TLS et de certificat valide pour HTTP et préconnaissance mutuelle du serveur et du client pour SSH ou usage de SSHFP ou usage de PKI SSH)
• le proxy P connait l'adresse du client et l'adresse et le nom du serveur de destination (si le client demande un serveur par son nom plutôt que par IP), sauf si plusieurs proxies sont utilisés pour atteindre la destination.
• le serveur S de destination ne voit plus l'adresse du client, mais seulement celle du proxy.

C'est donc une forme de connexion bien plus sécurisée que par l'usage du SSH agent forwarding, qui permet au serveur proxy P d'usurper l'identité du client C auprès de n'importe quel serveur.

Voir aussi man ssh_config#ProxyJump

Les conteneurs sous Linux sont un assemblage de plusieurs outils plus simples: cgroups, namespace (et chroot) à des fins d'isolation des programmes. De leur côté, les jails de BSD, les zones de solaris ou les machines virtuelles sont des objets plus simples, conçus pour l'isolation dès le début.

En conséquence, les conteneurs sont plus complexes: plus flexibles mais aussi plus fragiles (il est plus facile de se tirer une balle dans le pied).

Un problème d'isolation permet au worker PHP, qui exécute le code de l'application pour le compte du visiteur du site web, de prendre le contrôle de l'orchestrateur php-fpm qui, dans la configuration par défaut, s'exécute avec tous les droits sur le serveur. Cette faille permet une élévation de privilèges et est potentiellement exploitable à distance si un script PHP vulnérable est présent sur le serveur.

Mitigation évidente: ne pas faire tourner php-fpm avec les droits root. Dans une installation LEMP classique, on a:

• systemd qui doit orchestrer les services et s'exécute en root (inévitable)
• nginx qui reçoit les les requêtes web et les répartit, notamment vers php-fpm. Il fonctionne avec un processus maître qui fonctionne en root pour se mettre en écoute sur le port 443 et des workers, non privilégiés, qui traitent les requêtes
• php-fpm qui tourne sous root, reçoit les requêtes vers des scripts PHP de la part de nginx et les répartit vers des workers moins privilégiés.

Ça fait beaucoup trop de choses qui tournent avec les droits root. Systemd, c'est inévitable. Mais:

• php-fpm il n'y a aucune raison
• nginx la seule raison est de pouvoir écouter sur le port 443 (port privilégié). Mais on peut confier cette tâche à systemd et ainsi réduire les droits de nginx.

Une petite page sur freedesktop explique comment utiliser l'activation par socket pour nginx et php-fpm ce qui permet pour nginx de le lancer sans les privilèges root. Dans la configuration proposée, php-fpm est lancé avec l'utilisateur "nginx", ce qui est bien car ce n'est pas root, mais pas idéal car c'est le même utilisateur que nginx, donc ça expose les clés privées TLS a des scripts PHP compromis.

Avec cette configuration, si un script contient une faille, l'attaquant pourra:

• voler les identifiants et les données d'un autre utilisateur
• accéder à la base de données sans filtre ou à toute donnée à laquelle une application PHP sur le même serveur donne accès
• (potentiellement) modifier l'application

Mais il ne pourra pas:

• installer une application arbitraire sur le système
• accéder aux clés privées du système (SSH, TLS)
• rebondir vers d'autres systèmes via les comptes administrateurs

Le même type de failles est susceptible d'apparaître sur des serveurs logiciels d'autres langages (uwsgi ou gunicorn avec python, etc.), selon la configuration par défaut (droits root pour le processus maître ou non). La même mesure de protection s'applique.

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.

Les États détournent des technologies existantes pour des fins policières et, dans des états non démocratiques, à des fins de police politique. C'est du moins l'argument des oppositions à la technologie anti-pédophilie d'Apple. Est-il fondé ?

Quelques exemples (liste à compléter...) :

• The new warrant: how US police mine Google for your location and search history (The Guardian) : la police requiert de google de lui communiquer la liste des usagers présents dans telle zone à telle moment pour identifier des suspects (et non pas pour confirmer la présence de telle personne déjà suspectée ...), voire de communiquer la liste des usagers ayant cherché tel ou tel mot clé. La collecte de données opérée par Google à des fins commerciales se voit exploitée à des fins policières.
• British Telecom espionne ses usagers de cloud.mail.ru pour identifier des infractions au copyright (section « investigating intent: BT ») : « They also shared that the interception system was originally constructed as part of CleanFeed, a government initiative to block access to images of child abuse. However, it was inevitably repurposed to target copyright abuse. »
• Le fichier national des empreintes génétiques : ciblait initialement les personnes condamnées (ou soupçonnés ?) pour des délits ou crimes de nature sexuelle, et cible aujourd'hui toute infraction.

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.

Seald fournit :

• un SDK fournissant le chiffrement de bout en bout aux applications avec gestion des équipements (sous-identités associées à une identité principale) et des groupes pour partager l'information
• un séquestre stockant les clés de déchiffrement de chaque couple (information, utilisateur OU groupe), clés elles-mêmes chiffrées par le mot de passe utilisateur (le déchiffrement s'opère donc côté client)

Une interview du fondateur présente de manière claire ce dispositif et ses limites. La principale : la "racine de confiance" se résume au code exécuté. S'agissant d'applications web le plus souvent, la principale faille est donc la prise de contrôle du serveur web qui distribue l'application javascript aux clients.

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 :-) .