Antichesse (o ^ω^ o)
Titre PutaclickSur20.
Il s'agit en réalité d'une n-ème faille de sécurité de Windows, ici via l'utilitaire cmd.exe qui lance une invite de commande, et qui affecte tous les langages de programmation parce que (contrairement à Linux), je cite :
L'API Windows ne fournit qu'une seule chaîne de caractères contenant tous les arguments, laissant au processus créé la responsabilité de les diviser. La plupart des programmes utilisent la chaîne d'exécution standard argv en C, ce qui permet d'obtenir un comportement cohérent en matière de division des arguments. Cependant, cmd.exe possède sa propre logique de découpage des arguments, qui nécessite un échappement personnalisé par la bibliothèque standard Rust [et des autres langages].
Mais comme les communautés qui développent langages libres et interopérables sont de vrais professionnels eux, les langages compensent à la place de Microchiotte ce que Microchiotte aurait dû codé correctement dans Windows...
Bref, Rust est déjà patché. Si vous ne voulez pas être affectés par cette faille de sécurité, travaillez sur un OS digne de ce nom et quittez les boites qui vous forcent à bosser sur OSX ou Windows.
Je cite cet article car j'ai rigolé aux éclats à la lecture de cette phrase :
Les chercheurs ont prévenu l'industrie de ces risques depuis déjà 10 ans, mais « l'opinion dominante était que les criminels étaient loin d'être suffisamment instruits et intelligents pour pénétrer dans l'électronique interne des voitures », selon un spécialiste des technologies automobiles.
Tout le monde sait que la sécurité devrait être basée sur le fait qu'un assaillant soit armée d'une profonde gentillesse ou victime de déficit mentale...
Que dire des ces "spécialistes" qui ont prodigué ces bons conseils, escrots ou incompétents ? 🤣
Les cabinets de conseils s'en mettent vraiment plein les fouilles pour pas grand chose.
En quatre étapes :
1) Récupérer le certificat au format TXT
openssl s_client -connect mon-domaine:443 > mon-certif.pem2) Nettoyer le fichier TXT pour ne garder que ce qu'il y a entre les sections BEGIN CERTIFICATE et END CERTIFICATE inclus, par exemple :
-----BEGIN CERTIFICATE-----
MIIDnzCCAocCBE/xnXAwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkRFMRUw
EwYDVQQIEwxMb3dlciBTYXhvbnkxEjAQBgNVBAcTCVdvbGZzYnVyZzEYMBYGA1UE
ChMPU2FhUy1TZWN1cmUuY29tMRowGAYDVQQDFBEqLnNhYXMtc2VjdXJlLmNvbTEj
MCEGCSqGSIb3DQEJARYUaW5mb0BzYWFzLXNlY3VyZS5jb20wHhcNMTIwNzAyMTMw
OTA0WhcNMTMwNzAyMTMwOTA0WjCBkzELMAkGA1UEBhMCREUxFTATBgNVBAgTDExv
d2VyIFNheG9ueTESMBAGA1UEBxMJV29sZnNidXJnMRgwFgYDVQQKEw9TYWFTLVNl
Y3VyZS5jb20xGjAYBgNVBAMUESouc2Fhcy1zZWN1cmUuY29tMSMwIQYJKoZIhvcN
AQkBFhRpbmZvQHNhYXMtc2VjdXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMUZ472W3EVFYGSHTgFV0LR2YVE1U//sZimhCKGFBhH3ZfGwqtu7
mzOhlCQef9nqGxgH+U5DG43B6MxDzhoP7R8e1GLbNH3xVqMHqEdcek8jtiJvfj2a
pRSkFTCVJ9i0GYFOQfQYV6RJ4vAunQioiw07OmsxL6C5l3K/r+qJTlStpPK5dv4z
Sy+jmAcQMaIcWv8wgBAxdzo8UVwIL63gLlBz7WfSB2Ti5XBbse/83wyNa5bPJPf1
U+7uLSofz+dehHtgtKfHD8XpPoQBt0Y9ExbLN1ysdR9XfsNfBI5K6Uokq/tVDxNi
SHM4/7uKNo/4b7OP24hvCeXW8oRyRzpyDxMCAwEAATANBgkqhkiG9w0BAQUFAAOC
AQEAp7S/E1ZGCey5Oyn3qwP4q+geQqOhRtaPqdH6ABnqUYHcGYB77GcStQxnqnOZ
MJwIaIZqlz+59taB6U2lG30u3cZ1FITuz+fWXdfELKPWPjDoHkwumkz3zcCVrrtI
ktRzk7AeazHcLEwkUjB5Rm75N9+dOo6Ay89JCcPKb+tNqOszY10y6U3kX3uiSzrJ
ejSq/tRyvMFT1FlJ8tKoZBWbkThevMhx7jk5qsoCpLPmPoYCEoLEtpMYiQnDZgUc
TNoL1GjoDrjgmSen4QN5QZEGTOe/dsv1sGxWC+Tv/VwUl2GqVtKPZdKtGFqI8TLn
/27/jIdVQIKvHok2P/u9tvTUQA==
-----END CERTIFICATE-----3) Dire à git d'aller chercher ce certificat
git config --global http.sslCAInfo /mon/chemin/vers/mon/certif.pem4) S'assurer que la vérification SSL/TLS n'est pas désactivée dans Git
git config --global http.sslVerify trueOAuth 2.0 est un protocole d'autorisation d'accès à des données. Il s'incrit dans la mouvance RESTful où c'est la sécurisation des données qui compte et où l'idéologie dominante est que la donnée doit être fluide dans les SI.
Selon moi c'est incomplet et cela fait partie des saletés poussées par les GAFAM qui vivent de la récolte et de l'échange des données, tels des vampires.
En complément, cela me semble être très mal indiqué dans le monde industriel "classique" où il figure plusieurs niveaux de sécurité.
Je m'explique :
-
L'identification
On déclare qui on est et c'est tout. -
L'authentification
On prouve que l'on est bien celui que l'on prétend être (par un mot de passe ou un challenge cryptographique par exemple). -
L'autorisation (d'accéder aux données)
On peut récupérer les données sensibles ou personnelles qui sont entreposées pour nous dans un système. -
L'habilitation (à effectuer des modifications sur les données)
On peut créer ou modifier des données sensibles ou personnelles qui sont entreposées pour nous dans un système. -
L'accréditation (permettant de lancer certains traitements)
On peut déclencher des actions sur le serveur qui vont impacter les données. Par exemple supprimer une donnée, lancer un calcul complexe s'exerçant sur les données, ou plus modestement, passer une commande ou signer un document, etc.
OAuth 2.0 répond uniquement au point (3), ce qui représente une usine à gaz pour peu de choses au final. Mais vous permettez aux GAFAM de s'interfacer facilement avec votre SI.
De plus, le protocole part du principe que dès qu'une autorisation est octroyée, alors aussitôt tous les traitements sont permis, comme si certaines actions n'étaient pas réservées qu'aux admins, aux commerciaux, à la direction, à l'ingénierie, etc.
Bref mon sentiment à l'égard d'OAuth 2.0 se cristallise autour d'un "mouais".
@Doudou il faut que nous en discutions.
À la rentrée, je travaillerai sur l'architecture d'un service de sécurité. Voici une liste des protocoles standards qui gèrent la chose.
Je lis cet n-ième article qui annonce la mort des mots de passe et fait l'éloge des passkeys, c'est-à-dire des périphériques qui contiennent le secret qui va bien pour s'authentifier.
Problème, il faut verrouiller le périphérique en cas de perte ou de vol pour que seul son propriétaire puisse l'utiliser et que dit le site alors :
Il peut s'agir d'un déverrouillage biométrique (reconnaissance faciale, empreinte digitale), d'un code PIN, d'un schéma…
Et les deux dernières solutions sont ni plus ni moins que des mots de passe... L'autre étant un moyen irrévocable en cas de vol #FacePalm.
J'adore aussi le fait que l'article prétende que les keepass sont des outils faillibles par nature tout en sous-entendant que les passkeys ne le seraient pas eux parce que juste la magie des passkeys #FacePalmBis
J'espère qu'il s'agit d'une publicité déguisée en article.
Redisons-le, la façon la plus sûr de se connecter à quelque chose est :
Le mot de passe ultra-complexe stocké dans un keepass lui-même dans un endroit sécurisé + une double authentification via un autre périphérique en xOTP + que des logiciels libres et algos publics utilisés dans tout le process.
Et évidemment, les deux moyens étant révocables en cas de vol/perte c'est parfait, le reste c'est de l'arnaque selon moi.
Tout est dans le titre. Je dois implémenter un système d'authentification et d'autorisation. OAuth2 répond à une partie de mes besoins.
Un guide simple de sécurisation de la commande sudo.
@Animal j'ai un rôle Ansible à te commander :P
Un tuto simple parlant de l''injection CRLF avec les loggers en Kotlin/Java.
Penser à ajouter la dépendance suivante pour se prémunir de cela avec LogBack :
<dependency>
<groupId>org.owasp</groupId>
<artifactId>security-logging-logback</artifactId>
<version>1.1.6</version>
</dependency>(à voir avec ce que propose la 1.4.4 de LogBack sortie récemment).
Edit
Une autre façon de se protéger du problème est de se servir de la fonction replace de logback en lui demandant d'effectuer un search & replace de tous les caractères de type CR/LF by une chaîne connue (ici {EOL}) qui permettra de détecter l'injection de nouvelles lignes dans les logs :
<included>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%replace(%msg){'[\r\n]', '{EOL}'}</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</included>Cool, Apple ne vous authentifie plus et se contente de vous identifier avec vos données biométriques personnelles (parce que c'est tout à fait normal de confier ses données biométriques à une société commerciale, vous en conviendrez #Facepalm).
Dit autrement, si quelqu'un venait à vous voler votre empreinte, votre image ou quoi que ce soit qui ne soit pas révocable, vous devrez faire face à un très gros problème.
Bref, l'authentification c'est la preuve que la personne est bien celle qu'elle prétend être. L'identification, c'est la déclaration de cette prétention mais sans preuve puisque n'importe qui peut vous voler votre ADN, vous prendre en photo, etc.
Le point du litige est que l'on peut décider de changer de mot de passe quand on veut et sans effort mais ça n'est pas possible de changer de visage, d'ADN, d'empreintes, etc.
Nous sommes à la mi 2022 et la Caisse d'Épargne n'est toujours pas fichue d'employer des développeurs qui comprennent qu'on ne peut pas partager des requêtes avec des sous-domaines lorsque l'on active le contrôle de sécurité Same Origin !
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://www.as-ex-ano-groupe.caisse-epargne.fr/api/oauth/v2/token. Raison : échec de la requête CORS.
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://fonts.gstatic.com/s/ubuntu/v20/4iCv6KVjbNBYlgoC1CzjsGyN.woff2. Raison : échec de la requête CORS.
downloadable font: download failed (font-family: "Ubuntu" style:normal weight:300 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://fonts.gstatic.com/s/ubuntu/v20/4iCv6KVjbNBYlgoC1CzjsGyN.woff2Et tout leur site est bloqué pour un pauvre token et deux polices de caractères ! Mais leurs développeurs / sous-traitant sont nuls ! C'est incroyable que le B.A.BA ne soit pas maîtrisé à ce point. On se croirait chez ERDF / Enedis (ceux qui y sont passés doivent me comprendre) #FacePalm
Edit : en fait le site a été conçu pour Chrome et je suis sous Waterfox (une fork de Firefox sans les problèmes inhérents à Mozilla / Google). Bref, des polyfills JS sont chargés et font du cross-origin et forcément personne n'a lancé un Firefox like pour vérifier que ça marche...
À toutes ces personnes qui font du spécifiques Chrome je souhaite que ça vous gratte en permanence et à mort quelque part et qu'à chaque fois que votre doigt s'approche du point qui vous démange, celui-ci se déplace !
Après Log4j au tour de Spring d'avoir sa faille zero-day.
Comment créer un environnement sécurisé avec chroot. Plus le temps passe et plus je me dis que docker n'est pas si nécessaire.
A tous les non informaticiens, si vous vous demandez ce qu'est une "backdoor" (ou "porte dérobée" en français). Si vous vous demandez pourquoi tous les informaticiens râlent dès que l'état demande à disposer de clefs numériques privées pour déchiffrer nos communications, et bien l'analogie avec le monde réel est là.
Une seule clef permettant d'ouvrir toutes les boites à lettres, sauf que si cette clef tombe entre de mauvaises mains (ou une de ses copies), cela devient une catastrophe.
Tiens j'étais passée à côté de ça. Microsoft tente encore une fois de vendre de l'identification pour de l'authentification.
J'avais fait un post à ce sujet il y a quelques temps et je n'ai toujours pas changé d'avis sur la question.
Une fois notre image compromise, une fois que quelqu'un sera parvenu à nous filmer / photographier / enregistrer (emprunte vocale), voire de poster ces images/vidéos sur des réseaux sociaux (chose qui n'arrive jamais n'est-ce pas), alors comment changer de visage ou de voix ensuite ? Via de la chirurgie plastique ? Ça fait cher la resécurisation d'un compte compromis...
D'autant que cette chirurgie bloquera l'accès à tous les comptes sur les autres réseaux sociaux/pro/etc le temps qu'on leur réapprenne et que l'on prouve que cette nouvelle tête, c'est bien nous.... LOL
Le mot de passe est certes contraignant mais c'est le seul et unique système qui puisse être révoqué en cas de corruption. Tout le reste n'est que prétexte pour absorber nos données ou caractéristiques personnelles.
Merci à je ne sais plus qui pour le lien.
Le problème que j'ai avec l'application, c'est qu'elle associe un périphérique qui se perd, qui se casse et surtout qui se fait voler (coucou le métro parisien) à votre compte.
L'autre problème est que ces applications ne sont disponibles que sur les stores Google et Apple, or comment faire lorsque l'on utilise n'y l'un ni l'autre ?
Enfin, ces applications ne sont en général pas open-source, donc aucun moyen d'être certain qu'elles n'aspirent pas toutes les données persos...
Bref, les niveaux 3/2/1 sont au même degré de sécurité pour moi, seulement si l'on prend l'aspect global de la chose, c'est-à-dire vol du device + vol des données personnelles bien-sûr.
Si j''ai bien compris, toute la sécurité du DRM Widevine repose sur le fait que la clef privée permettant de déchiffrer les flux audio/vidéo ne soit pas volée côté client lorsqu'elle est envoyée au navigateur...
Redisons-le nous deux trois fois en décomposant bien les étapes afin d'identifier ce qui clocherait :
- Widevine envoie une clef privée aux navigateurs...
- Widevine envoie une clef privée...
- Une clef privée.
Si la clef qui doit restée privée est communiquée à toute la terre entière c'est qu'elle n'est plus privée bon-sang ! Je compte regarder dans le détail ce qu'il en retourne mais si c'est bien ce que je pense, alors le fait que Google n'emploierait que "les meilleurs des meilleurs des meilleurs Monsieur... Avec mention Monsieur" ne serait bel et bien qu'un mythe !
La petite citation qui va bien :
En plus de cette demande, nous avons déposé une demande distincte de retrait des données sensibles de ce fichier : /widevine-l3-decryptor, parce qu’il contient la clé privée secrète Widevine RSA, qui a été extraite du CDM de Widevine et peut être utilisée dans d'autres technologies de contournement.
@Guigui : super je me le note. Merci !
Brihx merci pour le lien. Par contre le coup des fonctions de dérivation de clefs qui doivent êtres rejouées n-fois pour éviter le brut-force j'ai toujours trouvé cela stupide et je m'explique.
Le but d'augmenter le nombre d'itérations est de ralentir l'algorithme de hash/crypto afin de se protéger des attaques de type brut-force. Or la puissance de calcul augmentant sans cesse avec le temps, plus les générations de CPU passent et plus il faut augmenter ce nombre d'itérations, ceci encore et toujours, jusqu'à consommer tout le pétrole sur terre pour le calcul d'un simple hash...
Sinon, on arrête de coder comme des profs de math débiles et on ajoute un Thread.sleep(1000) après le calcul du hash. Comme ça et quoi qu'il arrive, le check d'un mot de passe prendra toujours au moins 1 seconde quelque soit le CPU derrière, évitant ainsi les attaques du type brut-force, et en plus ça évite de contraindre un algo à utiliser un proc à 100% pour rien et ainsi de exposer son service à des attaques de type DDos.
Après ce n'est pas le rôle des matheux de coder efficace, c'est à nous (les IT) de comprendre ce qu'il faut faire et de bien le faire.