Depuis que X a shooté Nitter et XCancel à grands coups de lettres d'avocat fin août, lire X sans compte c'est redevenu une méga galère. Mais il reste pourtant un outil que plein de gens utilisent sans le savoir, parce qu'il tourne dans les coulisses de Discord et Telegram. Son nom ?

FxTwitter !

À la base, le projet FxEmbed , qui fait tourner FxTwitter et FixupX, sert à réparer les aperçus de liens X. Vous mettez fx devant twitter.com (ou fixup devant x.com) et Discord affiche enfin la vidéo, le sondage ou toutes les images du post. Sauf que derrière, il y a surtout une API publique et gratuite, api.fxtwitter.com, qui affiche n'importe quel post public en JSON sans avoir besoin de compte ou de clé API facturé une couille. Ché Elon !

Alors oui, les rageux diront que x.com affiche encore n'importe quel post isolé à un visiteur déconnecté, même les longs, mais sur un profil, ça s'arrête à 5 posts avant de vous demander de "Continuer sur X". Et surtout, ça ne vous affichera pas les vidéos et ça ne vous permettra pas d'avoir ça sous la forme d'un flux RSS.

Alors que FxTwitter, lui, nous sort tout ça sans avoir à ouvrir x.com !

Lire un post dans le navigateur

Maintenant pour nos tests, prenons un vieux de la vieille, un vétéran, le post numéro 20 de @jack, publié le 21 mars 2006 et dont l'URL est x.com/jack/status/20. Le nombre à la fin, c'est l'identifiant du post.

Collez tout simplement cet identifiant au cul de api.fxtwitter.com/2/status/ et ouvrez ça dans votre navigateur :

https://api.fxtwitter.com/2/status/20

Et vous obtiendrez un gros pavé en JSON avec dedans le texte du post dans le champ "text", l'auteur dans "author", et un peu plus bas vous trouvez les likes, les reposts, les réponses et la date.

Le post 20 de @jack vu par l'API : le texte dans le champ text, l'auteur juste en dessous.

Et si vous avez la flemme de recopier l'identifiant (vous êtes toujours dans l'abus, vous ^^), remplacez simplement x.com par api.fxtwitter.com dans l'adresse complète du post et voilà ! Ça marche à tous les coups, même si c'est le retour de l'ancienne version de l'API, conservée pour la compatibilité.

Le texte et sa traduction avec curl

Pour utiliser ça avec un script, je vous conseille d'utiliser curl pour faire la requête et jq pour trier tout ça ( jq, c'est le petit utilitaire qui extrait un champ précis d'un JSON ).

Ainsi, pour n'afficher que le texte du post :

curl -s "https://api.fxtwitter.com/2/status/20" | jq -r '.status.text'

Et si le post n'est pas en français, ajoutez ?lang=fr à l'adresse et hop, magie magie, l'API glisse alors un bloc "translation" dans la réponse, avec le texte en français :

curl -s "https://api.fxtwitter.com/2/status/20?lang=fr" | jq -r '.status.translation.text'

Le texte d'origine du post 20, puis sa traduction demandée avec ?lang=fr.

La traduction provient de X lui-même quand elle existe (sur ce post, le champ "provider" indiquait "grok"), sinon l'API se rabat avec joie sur un service de traduction. Et pour un profil, c'est le même principe avec /2/profile/ : api.fxtwitter.com/2/profile/jack qui affichera la bio de @jack, son nombre d'abonnés et sa date d'inscription. Les autres "routes" qui récupèrent les fils, les abonnés ou les médias d'un compte sont dans la documentation de l'API .

Elle est pas belle la vie ?

Récupérer une vidéo

Maintenant, on va rentrer dans le dur parce qu'ici, pour récupérer une vidéo, vous n'avez pas besoin d'API. Suffit de jouer avec l'adresse.

Mettez d. devant fxtwitter.com et le lien vous renverra directement le fichier, sans HTML autour. Avec curl, ça donne ça (le -L sert à suivre la redirection) :

curl -L -o video.mp4 "https://d.fxtwitter.com/NASA/status/2102748685792596449"

Grâce à ça, on peut par exemple récupérer le MP4 de cette vidéo bien kitchou de 30 secondes de la NASA. Et ajouter .mp4 à la fin d'une adresse fxtwitter.com fera la même chose. Et pour choisir la qualité, jetez un œil au JSON du post, où la liste des formats de media.videos donne chaque version de la vidéo avec son adresse et son bitrate.

Suivre un compte en RSS

Dernier truc que je trouve pratique avec cet outil c'est que chaque compte public peut avoir son flux RSS. Il suffit d'ajouter /feed.xml après le nom du compte :

https://fxtwitter.com/korben/feed.xml

Collez ensuite ça dans votre lecteur RSS et vous suivrez le compte X de vos rêves sans avoir à y mettre les pieds. Le flux remonte ainsi les 90 derniers posts par défaut, et le paramètre ?count= permet de réduire ce nombre ou de l'augmenter jusqu'à 100 maximum. Et si vous remplacez feed.xml par media.xml vous ne verrez dans le flux que les posts contenant des photos ou des vidéos. Et si vous ajoutez ?with_replies=1 vous verrez aussi les réponses.

Ce qui coince

Maintenant ce qui peut être relou, c'est que l'API n'encaisse que 1 000 requêtes par minute et par adresse IP. Par contre, si vous pensiez absorber tout x.com sans la moindre vergogne, vous allez vite vous retrouver coincé.

Attention aussi au domaine que vous tapez. Les seuls officiels sont fxtwitter.com, twittpr.com, fixupx.com, xfixup.com et fxbsky.app pour Bluesky. Je précise ça parce qu'il y a eu, par exemple un fxtwiter.com avec un t en moins, qui a été signalé sur le dépôt du projet et qui renvoyait les gens vers des arnaques.

Comme d'hab, une faute de frappe et c'est le drame... Soyez très vigilants.

Maintenant, si vous êtes un petit peu curieux comme moi, vous vous êtes sûrement demandé comment FxTwitter récupérait tout ça ??

Eh bien, comme le fait Nitter, ou plutôt comme le faisait Nitter , il récupère les données en utilisant de vrais comptes X sur lesquels il répartit les requêtes. Et comme c'est ce qui a été reproché à Nitter, je me dis qu'il y a des chances qu'à un moment FxEmbed soit visé aussi.

On verra bien, mais si un jour le service tombe, sachez que le code est bien dispo sous licence MIT, donc vous pouvez le faire tourner chez vous sans problème dans un Docker. Et si vous n'utilisez pas de compte X connecté dessus, ça marchera quand même avec, c'est vrai, des limites de requêtes plus basses et surtout sans accès au contenu NSFW (Et ça, je sais que ça vous rend super triste.)

Source : GitHub

Bon, j’étais un petit peu occupé aujourd’hui parce que c’est mercredi et c’est le jour des enfants, mais je ne pouvais pas finir ma journée sans vous parler de cette histoire incroyable.

Si vous faites partie des gens qui utilisent des sites comme JSONFormatter ou CodeBeautify pour rendre votre JSON lisible ou reformater du code, et bien figurez-vous que des chercheurs en sécu viennent de découvrir que ces outils ont laissé fuiter des tonnes de données sensibles durant des années. Et quand je dis tonnes, c’est pas une figure de style puisque ce sont plus de 80 000 extraits de code contenant des credentials en clair qui ont fuité, soit plus de 5 Go de données.

En effet, les chercheurs de WatchTowr ont découvert que la fonction “Recent Links” de ces plateformes permettait d’accéder à tous les bouts de code collés par les utilisateurs. Les URLs suivaient un format prévisible, ce qui rendait le scraping automatique hyper fastoche pour n’importe qui, et c’est comme ça qu’on a découvert que JSONFormatter a exposé durant 5 ans de données les données de ses utilisateurs. Et du côté de CodeBeautify, ça a duré 1 an.

Les chercheurs ont mis la main sur des identifiants Active Directory, des identifiants de bases de données et services cloud, des clés privées de chiffrement, des tokens d’accès à des repos Git, des secrets de pipelines CI/CD, des clés de passerelles de paiement, des tokens API en pagaille, des enregistrements de sessions SSH, et même des données personnelles de type KYC. Bref, le jackpot pour un attaquant, quoi.

Et côté victimes, c’est un festival puisqu’on y retrouve des agences gouvernementales, des banques, des assurances, des boîtes d’aéronautique, des hôpitaux, des universités, des opérateurs télécom… et même une entreprise de cybersécurité. On a même retrouvé les credentials AWS d’une bourse internationale utilisés pour leur système Splunk, ainsi que des identifiants bancaires provenant de communications d’onboarding d’un MSSP (Managed Security Service Provider). C’est cocasse comme dirait Macron.

Et pour prouver que le problème était bien réel et exploitable, les chercheurs de WatchTowr ont utilisé un service appelé Canarytokens dont je vous ai déjà parlé. Ils ont implanté de faux identifiants AWS sur les plateformes et ont attendu de voir si quelqu’un y accédait…

Résultat, quelqu’un a tenté de les utiliser 48 heures après que les liens étaient censés avoir expiré, et 24 heures après leur suppression supposée. Les données restaient donc accessibles bien au-delà de ce que les utilisateurs pouvaient imaginer.

Et le pire dans tout ça c’est qu’au moment de la publication des articles, les liens “Recent Links” étaient toujours accessibles publiquement sur les deux plateformes. Bref, aucune correction n’a été déployée.

Donc, voilà, si vous avez utilisé ces outils par le passé et que vous y avez collé du code contenant des identifiants et autres clés API (même par inadvertance), c’est le moment de faire une petite rotation de vos secrets.

Et même si c’est une évidence, de manière générale, évitez de balancer du code sensible sur des outils en ligne dont vous ne maîtrisez pas la politique de conservation des données.

Source