312 -🛡️ 🔑 📡

Stratégie, expertise & accompagnement individuelle, je vous aide à reprendre votre souveraineté, financière & numérique.
#Privacy #OSINT #BitcoinOnly ↘️

[312 -🛡️ 🔑 📡 @Lab312_]

⚡ LAB312 OUVRE SON PROGRAMME PARTENAIRES

Vous avez une audience. 👀 (ou pas...?)
Nous avons des formations, des services, et du matériel. 📚

On partage les revenus. En sats. ₿

🔧 Voici comment ça marche :
- Vous recevez un code promo personnalisé 🎫
- Vos abonnés et proches l'utilisent sur https://t.co/BqtvKibx1z
- Vous touchez une commission sur chaque vente ⚡
- On track tout via notre stack be-BOP nativement 📊

🤝 Le partenariat :
On discute ensemble des termes - taux de commission, produits concernés, modalités. Chaque partenariat est négocié en direct, pas un contrat générique envoyé en masse. Si ça matche, on lance. Si ça matche pas, on se dit au revoir proprement.

🚫 Ce qu'on ne fait PAS :
- Pas de formulaire kafkaïen 📝
- Pas de PayPal 🤮
- Pas de délai de 45 jours pour recevoir vos euros dépréciés 📉

✅ Ce qu'on fait :
Des sats, directement, sur votre wallet, une fois par mois. 🔐

On cherche des partenaires qui ont une communauté - peu importe la taille. 🌍(Ou pas...)
Creators Bitcoin 🦡, podcasteurs 🎧, formateurs 🏫, commerçants 🛍️, projets de l'éco ⚡, ou simple PLEB.

Si votre audience bouge des sats, on peut travailler ensemble.

Not your keys, not your coins. 🔐
But your audience, your revenue. 💰

DM ou [email protected] 📩

[312 -🛡️ 🔑 📡 @Lab312_]

🔗https://t.co/E002XNRUUa

[312 -🛡️ 🔑 📡 @Lab312_]

🛡 PLUTON - L'INTERFACE WEB QUI REND LA RÈGLE 3-2-1-0 ENFIN PRATICABLE

1. Restic chiffre.
2. rclone parle à 70 services de stockage.
Mais les connecter ensemble demande des scripts, de la maintenance, et de la surveillance.

Pluton fait ça depuis un navigateur.

🔍 COMMENT CA MARCHE
Tu décris ton plan de backup via un formulaire:
- Source
- Destination (disque local, S3, Backblaze B2, Google Drive)
- Fréquence
- Politique de rétention

Pluton génère les commandes restic derrière. Sauvegardes incrémentielles, chiffrées avant envoi, réplicables vers plusieurs destinations pour respecter la règle 3-2-1-0.
Docker Compose, deux fichiers, une minute et c'est en ligne.

⚠️ LE POINT A NE PAS RATER L'ENCRYPTION_KEY
dans le .env, c'est le mot de passe de tous tes dépôts restic. La perdre = perdre tes sauvegardes.
La changer = rendre illisible tout ce qui a déjà été écrit. Copie-la dans ton gestionnaire de mots de passe avant toute chose.
C'est la règle 0 avant même la règle 3-2-1.
Et si tu es sur Mac avec Docker Desktop, vérifie les colonnes après ta première sauvegarde. Pluton peut afficher "Complete" avec 0 fichier et 0 octet sauvegardés.

Le statut vert ne prouve rien - les chiffres, si.

🎯 CE QU'ON RETIENT
- Gratuit pour une machine
- Pro à 59$/an pour piloter plusieurs machines depuis la même interface
- Restauration testable en dry run avant de toucher au disque
- Dépôt restic standard: récupérable même si Pluton disparaît demain

Une bonne sauvegarde non testée n'est pas une sauvegarde. C'est une fausse sécurité.

La règle 3-2-1-0, on en parle en formation, et on vérifie que ça restaure vraiment. 💼

Source en commentaire ! 👇

[312 -🛡️ 🔑 📡 @Lab312_]

https://t.co/ZILAE2Racz

[312 -🛡️ 🔑 📡 @Lab312_]

🔊Fermeture de la newsletter jusqu'à nouvel ordre.

[312 -🛡️ 🔑 📡 @Lab312_]

Incident de sécurité chez Brevo (ex-Sendinblue) est confirmé, annoncé les 9 et 10 septembre 2026.

Brevo a indiqué sur X qu’un attaquant a accédé à 120 comptes clients. Avec cet accès, il a envoyé des e-mails de phishing depuis ces comptes vers les listes de contacts des clients concernés. L’accès non autorisé a été fermé à 11 h 30 CEST le 10 septembre 2026. La majorité de ces 120 comptes n’a montré aucune autre activité suspecte. Brevo contacte les clients touchés et a annoncé un post-mortem pour plus tard dans la journée.

Ce qui s’est passé concrètement:
Trezor (fabricant de portefeuilles matériels) a confirmé faire partie des clients touchés. Des attaquants ont envoyé un e-mail de phishing depuis le compte newsletter Trezor sur Brevo à environ 347 000 abonnés opt-in.

L’objet était : « Critical Security Alert: STM32 Entropy Vulnerability », pour inciter les destinataires à entrer leur sauvegarde de portefeuille. Trezor a coupé le domaine concerné en environ 20 minutes (environ 2 500 personnes avaient déjà cliqué) et a contacté ses abonnés. Aucun système Trezor (firmware, wallets, comptes) n’a été compromis. Trezor ne peut pas confirmer si la liste d’e-mails a été exportée ; par prudence, elle la considère comme potentiellement connue de l’attaquant.

Des e-mails de phishing similaires sont partis d’autres clients crypto de Brevo, notamment BitBox, CoinTracking, Peach Bitcoin et Blocktrainer. Des sources parlent aussi de clés API créées sans autorisation dans les comptes compromis.

Ce n’est pas le dump de toute la base clients de Brevo. Il s’agit d’un accès non autorisé à un nombre limité de comptes, ensuite utilisé pour du phishing.

État actuel
L’incident est très récent (hier / aujourd’hui).
Brevo n’avait pas encore publié de post-mortem détaillé au moment de cette synthèse, et le vecteur d’accès initial n’est pas encore clairement documenté.

Si vous utilisez Brevo : vérifiez les campagnes inattendues, les nouvelles clés API et l’historique de connexion, activez la 2FA si ce n’est pas déjà fait, et méfiez-vous des e-mails « d’alerte sécurité » qui semblent venir de marques auxquelles vous êtes abonné.

[312 -🛡️ 🔑 📡 @Lab312_]

🔊Fermeture de la newsletter jusqu'à nouvel ordre.

[312 -🛡️ 🔑 📡 @Lab312_]

@underclass21 . @ivpnnet 👀

[312 -🛡️ 🔑 📡 @Lab312_]

@giacomozucco it hit hard, AF 🧨

[312 -🛡️ 🔑 📡 @Lab312_]

@mononautical Source: https://t.co/fsFUmZphP8

[mononaut @mononautical]

There's some confusion about what, exactly, was exploited here.

I've seen claims that this was a long-standing bug, exploited after the "fix" was pushed to the open source repo but before that fix could be rolled out in production.

That does not appear to be true.

Instead, it seems that the fix *was* deployed, but inadvertently introduced a new bug which was subsequently exploited.

Most of the network was still running official releases, none of which contain the new bug. Those nodes correctly rejected the block containing the exploit and stalled at height 4050335.

The timeline is roughly as follows:
• 2016-07-12: Range proof caching added
• 2017-11-08: Range proofs extended to support assets
• 2019-03-19: Range proof cache key "simplified", dropping asset & script fields. introduces Bug A.
• 2026-09-01: Bug A "fixed" by extending cache key to include asset + script. introduces Bug B.
• 2026-09-06: Bug B exploited, reserves drained, chain split.

The original "Bug A" allows some limited cache poisoning because the cache key doesn't commit to the asset and script, allowing a cached result for a range proof for one asset to be applied to a different asset or context.

Exploiting this in practice looks quite difficult, since the amount must match the primer and the proof must be genuine.

The 2026 "fix" added those missing fields to the cache key, producing a format like:

"proof | amount | asset | scriptpubkey"

But this unfortunately made the key easier to manipulate and exploit:

The four fields are concatenated without separators or length indicators.

Since both the proof and the scriptpubkey are variable length, an attacker can stretch the proof and shrink the script to produce the exact same cache key from different proofs, amounts, assets and scripts.

This lets an attacker smuggle arbitrary confidential output amounts and junk proofs past the range proof checker without proper validation, which breaks the guarantees that prevent hidden inflation.

On-chain evidence suggests that this second bug is what was exploited:

Two primer transactions each created an op_return with carefully constructed scriptpubkey and valid range proof for a (presumably) zero value output.

https://t.co/u0PrqAavhB
https://t.co/LX3AK0pRdu

This produced a cache key like:

"<valid proof> | <valid amount> | <L-BTC> | OP_RETURN <negative amount> <L-BTC> OP_RETURN"

The exploit transaction then created a large negative op_return output with an invalid range proof:

https://t.co/9yQQM5w379

The invalid proof is padded with bytes corresponding to the primer's valid amount and asset fields, aligning the actual amount and asset fields with the same bytes from the primer's opreturn payload:

"<valid proof> <valid amount> <L-BTC> OP_RETURN | <negative amount> | <L-BTC> | OP_RETURN"

The exploit transaction could then include a second output crediting the attacker with a large positive value, balanced out by the fake negative amount.

Because the success was already cached, the invalid proof was never actually checked and the transaction was accepted as valid by nodes running versions of the software vulnerable to bug B.

Although the amounts are blinded, this is the only output with an invalid range proof anywhere in the peg-out's recent ancestry, so this must be where the inflated coins were created.

And since the padding only produces a cacheable key under the new format, it must have been the newer bug that was exploited.

[312 -🛡️ 🔑 📡 @Lab312_]

🔴 ERRATUM - J'AI EU TORT SUR L'EXPLOIT LIQUID

L'analyse de ce matin était partiellement incorrecte, un thread de @mononautical remet les pendules à l'heure.

Ce que j'ai dit:
-bug vieux de 7 ans exploité après que le patch ait été publié trop tôt sans déploiement. FAUX.

La réalité est plus subtile et franchement plus inquiétante.

🔍 LA VRAIE TIMELINE
- 2019: Bug A introduit. La cache key oublie l'asset et le script. Difficile à exploiter en pratique.
- 2026-09-01: Le "fix" ajoute ces champs manquants. Et introduit Bug B.
- 2026-09-06: Bug B exploité. 4 000 BTC partis.

💣 LE VRAI BUG
Le fix concatène les champs sans séparateurs ni indicateurs de longueur: "proof | amount | asset | scriptpubkey"
Comme proof et scriptpubkey sont de longueur variable, un attaquant peut étirer l'un et réduire l'autre pour produire exactement la même cache key avec des données complètement différentes.

Deux transactions d'amorçage créent une cache key valide en mémoire, la transaction d'attaque utilise une preuve paddée pour aligner ses champs sur cette même key.

Cache hit. Pas de vérification. Inflation cachée. Réserves vidées.

Les noeuds qui tournaient sur les releases officielles - sans Bug B - ont correctement rejeté le bloc et se sont figés à 4050335. Ce sont les noeuds qui avaient déployé le patch qui ont accepté l'exploit.

🎯 CE QUI NE CHANGE PAS
Le résultat: 3 998,67 BTC volés en 9 minutes.
La leçon: un patch de sécurité mal implémenté peut être pire que le bug qu'il corrige.
Et Liquid reste une sidechain centralisée dont les fonctionnaires ont payé sur une mauvaise chaîne.

Merci à @mononautical pour l'analyse, & @PaulADW pour le ping, mille excuse frère.

#Bitcoin #InfoSec #LAB312

[312 -🛡️ 🔑 📡 @Lab312_]

💀 4 000 BTC VOLÉS EN 9 MINUTES SUR LIQUID. LE CORRECTIF ÉTAIT PUBLIC DEPUIS 5 JOURS.

Le 6 septembre 2026, Liquid s'est fait vider de 3 998,67 BTC.

Pas par un génie. Par quelqu'un qui a lu un diff GitHub.
Voici comment.

🔍 LE BUG
Liquid utilise des preuves cryptographiques (rangeproofs) pour vérifier que les montants sont valides sans les révéler.
Pour aller plus vite, le code mémorisait les résultats dans un cache.
Problème: ce cache enregistrait "preuve vérifiée = OK" en oubliant deux paramètres essentiels du contexte cryptographique.

Résultat: une preuve valide dans le contexte A était automatiquement acceptée comme valide dans tout autre contexte B. Sans re-vérification. Sans contrôle.

💣 L'ATTAQUE
L'attaquant construit une transaction avec:
- Une valeur positive de ~4 milliards de BTC cachée dans un engagement cryptographique. Preuve honnêtement générée, valide.
- Une valeur NÉGATIVE équivalente. Impossible à prouver. Mais la preuve n'a jamais été vérifiée grâce au cache.

Les noeuds dont le cache avait été préparé au préalable: acceptent.
Les autres: rejettent.
Le réseau se scinde en deux chaînes.
En 9 minutes, l'attaquant convertit la valeur créée de toutes pièces en deux peg-outs Bitcoin légitimes. Les fonctionnaires Liquid, sur la mauvaise chaîne, ont payé. 3 998,67 BTC envoyés à deux adresses vidées dans les 20 minutes suivantes.

🚨 LE DÉTAIL QUI FAIT MAL
Le correctif existait depuis le 3 août 2026.
Mergé publiquement sur GitHub le 1er septembre. Clairement intitulé "Fix caching bug in rangeproof caching". 3 à 5 jours avant l'attaque.
Aucune release officielle ne contenait le correctif. Chaque noeud en production tournait encore sur le code vulnérable.

L'attaquant a lu le diff, compris la faille, exploité avant que quiconque déploie. Bug vieux de 7 ans. Patch publié trop tôt. 4 000 BTC partis.

🛡 CE QU'ON RETIENT
- Un cache de performance devenu oracle de consensus. La pire architecture possible pour un réseau financier.
- Des fonctionnaires centralisés qui ont signé des peg-outs sur une chaîne invalide.
- Publier un correctif critique sans embargo sur un réseau gérant des fonds réels, c'est publier la recette de l'exploit.

Liquid n'est pas Bitcoin. C'est une sidechain centralisée dont les fonctionnaires viennent de prouver qu'ils peuvent payer sur une mauvaise chaîne.

Stay humble, stack sats. [Sur la vraie chaîne.]

#Bitcoin #InfoSec #LAB312

https://t.co/V2hcJREAqE

[312 -🛡️ 🔑 📡 @Lab312_]

@Ed_L_P Rien et ça m'va bien.

[312 -🛡️ 🔑 📡 @Lab312_]

🚀0,23$ pour transferer pas loin de 780$
Qui dit mieux ? 🤠

#BeYourOwnBank #Bitcoin #FTW

[312 -🛡️ 🔑 📡 @Lab312_]

@Ed_L_P oui oui on connait la chanson. 🤡

[312 -🛡️ 🔑 📡 @Lab312_]

@Ed_L_P Non merci

[Scuba @Scuba_Wizard]

J'ai l'honneur de vous annoncer que Damien Theillier (@dtlier), fondateur de l'Institut Coppet, signe la préface de mon livre Le Collectif soumis.

Il en a saisi le fil avec une justesse qui m'a profondément touché.

Extrait ci-dessous.

Sortie le 06 octobre 👀

[312 -🛡️ 🔑 📡 @Lab312_]

Pour ceux de la région parisienne qui s'interesse à la cryptographie.

"Crypto means Cryptography" ⤵️

[Renaud Lifchitz ⠵ @nono2357]

Real World Cryptography in Paris! Our 5th meetup. Five talks on homomorphic encryption, key-based identity, anonymous auctions, and protocol verification.
https://t.co/blmwh70NsY

[312 -🛡️ 🔑 📡 @Lab312_]

@nono2357 mais pourquoi j'suis si loin de Paris 😓

[312 -🛡️ 🔑 📡 @Lab312_]

Coaching 1to1 ce soir, avec un nouvel amateur de monnaie dure.

📑 Au programme :
- Verification de signature de logiciel ✅
- prise en main complète de @SparrowWallet 🕊️
- MaJ firmware @COLDCARDwallet 🤠
- UTxO Management.⚠️

Accroches ton slip mon p'ti gars, et prends ton carnet de notes.

[312 -🛡️ 🔑 📡 @Lab312_]

@crypt0mancien Non.

[312 -🛡️ 🔑 📡 @Lab312_]

@SortieDeBanque Pour les plus tech d'entre nous, il y as tout le détail dans le lien gist en fin de publication. 🤓

[312 -🛡️ 🔑 📡 @Lab312_]

💀 4 000 BTC VOLÉS EN 9 MINUTES SUR LIQUID. LE CORRECTIF ÉTAIT PUBLIC DEPUIS 5 JOURS.

Le 6 septembre 2026, Liquid s'est fait vider de 3 998,67 BTC.

Pas par un génie. Par quelqu'un qui a lu un diff GitHub.
Voici comment.

🔍 LE BUG
Liquid utilise des preuves cryptographiques (rangeproofs) pour vérifier que les montants sont valides sans les révéler.
Pour aller plus vite, le code mémorisait les résultats dans un cache.
Problème: ce cache enregistrait "preuve vérifiée = OK" en oubliant deux paramètres essentiels du contexte cryptographique.

Résultat: une preuve valide dans le contexte A était automatiquement acceptée comme valide dans tout autre contexte B. Sans re-vérification. Sans contrôle.

💣 L'ATTAQUE
L'attaquant construit une transaction avec:
- Une valeur positive de ~4 milliards de BTC cachée dans un engagement cryptographique. Preuve honnêtement générée, valide.
- Une valeur NÉGATIVE équivalente. Impossible à prouver. Mais la preuve n'a jamais été vérifiée grâce au cache.

Les noeuds dont le cache avait été préparé au préalable: acceptent.
Les autres: rejettent.
Le réseau se scinde en deux chaînes.
En 9 minutes, l'attaquant convertit la valeur créée de toutes pièces en deux peg-outs Bitcoin légitimes. Les fonctionnaires Liquid, sur la mauvaise chaîne, ont payé. 3 998,67 BTC envoyés à deux adresses vidées dans les 20 minutes suivantes.

🚨 LE DÉTAIL QUI FAIT MAL
Le correctif existait depuis le 3 août 2026.
Mergé publiquement sur GitHub le 1er septembre. Clairement intitulé "Fix caching bug in rangeproof caching". 3 à 5 jours avant l'attaque.
Aucune release officielle ne contenait le correctif. Chaque noeud en production tournait encore sur le code vulnérable.

L'attaquant a lu le diff, compris la faille, exploité avant que quiconque déploie. Bug vieux de 7 ans. Patch publié trop tôt. 4 000 BTC partis.

🛡 CE QU'ON RETIENT
- Un cache de performance devenu oracle de consensus. La pire architecture possible pour un réseau financier.
- Des fonctionnaires centralisés qui ont signé des peg-outs sur une chaîne invalide.
- Publier un correctif critique sans embargo sur un réseau gérant des fonds réels, c'est publier la recette de l'exploit.

Liquid n'est pas Bitcoin. C'est une sidechain centralisée dont les fonctionnaires viennent de prouver qu'ils peuvent payer sur une mauvaise chaîne.

Stay humble, stack sats. [Sur la vraie chaîne.]

#Bitcoin #InfoSec #LAB312

https://t.co/V2hcJREAqE