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

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.

Modèle de menace : soit votre ennemi n'est pas le Mossad, et avec un bon mot de passe et un minimum de bon sens vous pouvez vous défendre, soit votre ennemi est le Mossad et vous êtes fichus.

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

Les iPhone sont bien sécurisés, comparables à un château fort. Mais c'est un château fort dont Apple a les clés, pas vous : c'est davantage une prison dorée qu'un domicile. À cette conception de la sécurité comme "faites confiance à Apple", les auteurs opposent l'idée de donner le contrôle à l'utilisateur, via la transparence du système.

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.

   FS_SECRM_FL 's'
         Mark the file for secure deletion.  This feature is not
         implemented by any filesystem, since the task of securely
         erasing a file from a recording medium is surprisingly
         difficult.

Les TPM sont des composants stockant des clés, des "mesures" (hachés) et réalisant des opérations cryptographiques (chiffrement, signature, génération d'aléa ou de clés). L'espace de stockage est minimal : on y stocke des clés "maître" qui (dé)chiffrent d'autres clés, stockées sur le disque dur ou ailleurs. Les TPM peuvent prendre la forme de puces matérielles dédiées (HSM simples), d'un firmware intégré à la carte mère (Trustes Execution Environment) ou d'implémentations logicielles.

On peut s'en servir pour enregistrer une séquence de démarrage, où chaque composant de la chaîne, du bios à l'OS, mesure le suivant avant de lui passer la main. On peut ensuite témoigner de la séquence auprès d'un tiers (comparaison avec des valeurs de références), utiliser ces valeurs de référence pour autoriser ou bloquer le démarrage (authenticated boot) ou conditionner l'usage d'une clé à ces valeurs, typiquement pour déchiffrer un disque dur.

Le niveau de sécurité que ça permet d'atteindre est intéressant, mais :

• la complexité de mise en place semble assez grande (au moins sur Linux)
• ça apporte une sécurité contre un attaquant qui aurait accès au matériel mais en attaquant uniquement le logiciel (bios, bootloader, OS...). Un attaquant sophistiqué saura ajouter une puce matérielle et contourner ces protections. Le scénario d'attaque auquel ces mesures répondent est donc assez improbable.

Résultat : les cas d'usage me semblent limités pour le moment.

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.

En France, la censure d'internet est ordonnée par la police (terrorisme), l'Arjel (jeux en ligne) et la justice (partage de la culture et des connaissances). Elle est faite au niveau du DNS par les 4 principaux fournisseurs d'accès à internet (FAI).
La montée en puissance du DNS over HTTPS compromet ce fonctionnement, les FAI ne jouant plus mécaniquement ce rôle de résolveur DNS.

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.

Un petit pas en matière de sécurité, facile à faire : sécuriser ses clés SSH (que ce soit des clés pour l'administration système, pour git, ou whatever) : en plus de les protéger par mot de passe, il faut que la protection par mot de passe soit bien fichue, avec une fonction lente de dérivation de clé (pbkdf). Pour générer une nouvelle clé avec des options correcte :

ssh-keygen -o

Pour protéger une clé déjà existante avec ce nouveau chiffrement :

ssh-keygen -o -p -f ~/.ssh/fichier_de_cle_privee

Le Conseil d'État se prononçait sur la possibilité ou non d'héberger des données de santé sur le cloud Microsoft : il constate que Microsoft pourra être soumis à des requêtes des autorités américaines sans que les personnes ciblées n'aient aucun recours. Mais serait-il possible d'héberger les données chez Microsoft sans que Microsoft y ait accès, par exemple avec du chiffrement ? Non.

17. Toutefois, la Commission nationale de l'informatique et des libertés, dans les observations qu'elle a produites à la suite de la communication de la requête, estime, en l'état des informations dont elle dispose, que le risque d'une demande telle que celles mentionnées au point 15 ne peut être totalement écarté. En outre, il résulte de l'instruction que les mesures techniques mises en oeuvre par Microsoft ou susceptibles de l'être à brève échéance n'écartent pas toute possibilité pour cette entreprise d'accéder aux données traitées sous la responsabilité de la Plateforme des données de santé, en dépit des précautions, limitant ce risque, qui entourent le chiffrement dont elles font l'objet et le stockage des clés de chiffrement utilisées. Il ne peut ainsi être totalement exclu, sur le plan technique, que Microsoft soit amenée à faire droit à une demande des autorités américaines fondée sur l'article 702 du FISA, ce qui méconnaîtrait alors les articles 28 et 48 du règlement général sur la protection des données, cités au point 5, qui interdisent qu'un sous-traitant transfère des données à caractère personnel vers un pays tiers si ce n'est sur instruction du responsable du traitement ou en vertu d'une obligation prévue par le droit de l'Union européenne ou d'un Etat membre, et que puisse être reconnue ou rendue exécutoire une décision d'une autorité administrative d'un pays tiers exigeant d'un responsable du traitement ou d'un sous-traitant qu'il transfère ou divulgue des données à caractère personnel, sauf sous certaines conditions qui ne seraient en l'espèce pas remplies.

Le Conseil d'État prend acte de la décision du ministère de la Santé de mettre fin à l'hébergement des données de santé sur la plate-forme Microsoft d'ici 2 ans et décide donc de ne pas condamner ledit ministère à une action plus rapide.

Par défaut docker n'écoute pas sur le réseau. Mais quand l'API réseau est activée (par exemple pour un orchestrateur), par défaut il n'y pas d'authentification et les communications se font en clair (port 2375).

Si on est root dans un conteneur et que celui-ci a les capacités DAC_OVERRIDE (présente par défaut) et CAP_READ_SEARCH (absente par défaut), on peut modifier des fichiers arbitraires sur l'hôte, donc en prendre le contrôle (shocker).