• chevron_right

      Un FestIn de roi pour vos Buckets S3

      news.movim.eu / Korben · 2 days ago - 07:00 · 7 minutes

    Aujourd’hui on va parler d’un outil de ouf pour trouver des buckets S3 ouverts : FestIn !

    C’est le genre d’outil dont raffolent les chercheurs en sécurité puisqu’il qui explore tous les recoins du web pour dénicher des trucs que vous n’auriez jamais trouvé.

    FestIn c’est la grosse artillerie de l’énumération de buckets S3 puisqu’il a tellement d’options que les autres outils à côté c’est de la gnognotte. Attention, c’est bien sûr à utiliser uniquement sur vos propres noms de domaines ou dans le cadre de missions d’audit pour lesquelles vous avez toutes les autorisations.

    Avec lui, vous allez pouvoir :

    • Utiliser différentes techniques pour trouver des buckets : crawling du DNS et des pages web, analyse des réponses S3
    • Faire vos requêtes en passant par un proxy, no stress 🕶
    • Vous passer des credentials AWS, puisque ça marche avec n’importe quel provider compatible S3
    • Configurer vos propres serveurs DNS, parce que vous êtes trop beau gosse.
    • Profiter d’un crawler HTTP de compétition qui va retourner le web pour vous
    • Faire des recherches récursives et avoir du feedback entre les différents modules pour un max d’efficacité
    • Faire tourner le schmilblick en mode « watch » pour choper les nouveaux domaines en temps réel, ce qui est assez ouf quand on y pense.
    • Sauvegarder tous les domaines découverts dans un fichier, pour faire joujou avec plus tard
    • Indexer direct le contenu des objets des buckets pour faire des recherches full text de la mort, mieux que Google ! 😎
    • Cibler votre recherche sur des domaines spécifiques si vous voulez pas vous éparpiller

    Pour l’installer c’est fastoche, au choix :

    pip install festin

    Ou en mode Docker :

    docker run --rm -it cr0hn/festin -h

    C’est du brut, du bourrin, puisqu’on va envoyer des requêtes en masse et gratter un max d’infos. Attention cependant, on reste fair-play, on ne veut pas faire planter le serveur non plus.

    Par défaut, FestIn prend un unique domaine en argument :

    festin mon-super-site.com
    

    Mais on peut aussi lui filer un fichier texte contenant une liste de domaines, histoire d’être plus productif :

    1. Crée un fichier domaines.txt avec tes domaines, un par ligne.
    2. Lance la commande :
    cat domaines.txt | festin -f -
    

    FestIn balance plusieurs tests en même temps pour aller plus vite. Par défaut, il en lance 5. Si vous êtes pressé et que votre machine encaisse, vous pouvez augmenter ce nombre avec l’option -c :

    festin -c 10 mon-super-site.com
    

    Attention cependant, ne balancez pas un truc de fou, ça risque de faire bugger le site ciblé. On est là pour glaner des infos, pas pour casser du serveur.

    L’outil dispose également d’un petit bot intégré qui va scanner le site à la recherche de liens pouvant mener à des buckets S3. On peut le configurer avec plusieurs options :

    • Timeout (-T ou –http-timeout) : Si le site est lent, on augmente le timeout pour pas que le scan plante. Par défaut, c’est 5 secondes.
    • Récursion max (-H ou –http-max-recursion) : On limite la profondeur du scan pour éviter de partir en vadrouille sur tout le net. Par défaut, c’est 3 niveaux, genre site.com -> lien -> site2.com -> lien -> site3.com .
    • Limite de domaine (-dr ou –domain-regex) : On peut dire au robot de se focaliser uniquement sur les sous-domaines qui correspondent à une expression régulière.
    • Liste noire (-B) : Fich un fichier texte contenant des mots clés. Si un domaine contient un de ces mots, on l’ignore.
    • Liste blanche (-W) : Même principe, mais à l’envers. On scanne uniquement les domaines contenant des mots clés de la liste blanche.

    Pour cela, vous devez créer un fichier blacklist.txt contenant « cdn » et « photos » (on ignore les liens vers des CDN et des images) puis lancer la commande :

    festin -T 20 -M 8 -B blacklist.txt -dr .mondomaine\.com mon-super-site.com
    

    Attention : l’option -dr attend une expression régulière valide au format POSIX. Par exemple, mondomaine.com est invalide, alors que \.mondomaine\.com est correct.

    FestIn crache un paquet d’infos intéressantes, pas seulement sur les buckets S3, mais aussi sur d’autres éléments identifiés. Ces infos peuvent ensuite être utilisées avec d’autres outils comme nmap.

    Pour récupérer les résultats, FestIn propose trois modes qu’on peut combiner :

    • Fichier de résultats FestIn (-rr ou –result-file) : Ce fichier contient une ligne JSON par bucket trouvé, avec le nom de domaine d’origine, le nom du bucket et la liste des objets qu’il contient.
    • Fichier de domaines découverts filtrés (-rd ou –discovered-domains) : Celui-là liste un domaine par ligne. Ce sont des domaines trouvés par le crawler, le DNS ou les tests S3, mais qui ont été filtrés selon les options définies.
    • Fichier brut de tous les domaines découverts (-ra ou –raw-discovered-domains) : Comme son nom l’indique, c’est la liste brute de tous les domaines identifiés par FestIn, sans aucun filtre. Idéal pour du post-traitement et de l’analyse.

    récupérer les résultats dans trois fichiers distincts et enchaîner avec nmap :

    festin -rr festin.results -rd domaines_filtres.txt -ra domaines_bruts.txt mon-super-site.com
    
    festin -rd domaines_filtres.txt && nmap -Pn -A -iL domaines_filtres.txt -oN nmap-resultats.txt
    

    FestIn peut utiliser Tor pour plus de discrétion. Il faut juste avoir un proxy Tor lancé en local sur le port 9050 (configuration par défaut). Activez-le avec l’option --tor :

    tor & festin --tor mon-super-site.com
    

    Et il peut aussi effectuer des recherches DNS. Voici les options dispo :

    • Désactiver la découverte DNS (-dn ou –no-dnsdiscover) : Si on a pas besoin de ce type de recherche.
    • Serveur DNS personnalisé (-ds ou –dns-resolver) : Pratique si on veut utiliser un serveur DNS différent de celui par défaut.

    Comme ceci :

    festin -ds 8.8.8.8 mon-super-site.com
    

    Ce script ne se contente pas de dénicher les buckets S3 ouverts, il peut aussi télécharger leur contenu et l’indexer dans un moteur de recherche plein texte. Ça permet ensuite de lancer des recherches directement sur le contenu des buckets ! Pour activer l’indexation, FestIn utilise Redis Search, un projet Open Source.

    Il faut deux options :

    • Activer l’indexation (–index) : Indispensable pour que le contenu soit stocké dans le moteur de recherche.
    • Configuration du serveur Redis Search (–index-server) : Uniquement si votre serveur Redis Search est sur une IP/port différent de localhost:6379 par défaut.

    Lancez d’abord Redis Search en tâche de fond :

    docker run --rm -p 6700:6379 redislabs/redisearch:latest -d
    

    Puis lancez FestIn avec l’indexation et le serveur distant :

    festin --index --index-server redis://127.0.0.1:6700 mon-super-site.com
    

    Attention : l’option --index-server doit obligatoirement commencer par le préfixe redis:// .

    Bien sûr, on a pas forcément envie de relancer FestIn à chaque nouveau domaine à analyser. C’est pour ça qu’il existe le mode surveillance. FestIn se lance et attend l’ajout de nouveaux domaines dans un fichier qu’il surveille. Pratique pour l’utiliser avec d’autres outils comme dnsrecon.

    Lancez FestIn en mode surveillance avec le fichier domaines.txt :

    festin --watch -f domaines.txt
    

    Dans un autre terminal, ajoutez des domaines à domaines.txt :

    echo "encore-un-autre-site.com" >> domaines.txt
    

    Dès qu’un nouveau domaine est ajouté au fichier, FestIn le scanne automatiquement à la recherche de buckets S3 ouverts. Pour aller plus loin, on peut combiner FestIn avec un outil de reconnaissance DNS comme DnsRecon. L’idée est de récupérer des sous-domaines potentiels liés au domaine principal et de les balancer ensuite à FestIn pour scanner d’éventuels buckets S3 cachés.

    Etape 1 : Scruter le domaine cible avec DnsRecon

    On va utiliser DnsRecon pour trouver des sous-domaines associés à cible.com . Sauvegardez la sortie dans un fichier CSV :

    dnsrecon -d cible.com -t crt -c cible.com.csv
    

    Etape 2 : Préparer le fichier pour FestIn

    On isole les sous-domaines du fichier CSV pour les injecter dans FestIn (un domaine par ligne) :

    tail -n +2 cible.com.csv | sort -u | cut -d "," -f 2 >> cible.com.domaines
    

    Etape 3 : Lancer FestIn et récupérer les résultats

    On balance le fichier de sous-domaines à FestIn en activant la recherche Tor, la concurrence à 5, un serveur DNS personnalisé et en sauvegardant les résultats dans des fichiers distincts :

    festin -f cible.com.domaines -
    

    Et pour automatiser tout ça sur plein de domaines à la chaîne, on a même un petit script loop.sh bien pratique dans les examples du repo GitHub.

    Voilà les amis, vous avez toutes les clés pour utiliser FestIn comme un pro et aller secouer les buckets S3 qui traînent ! C’est quand même un outil hyper complet et puissant, pensez à l’utiliser avec un proxy ou Tor pour pas vous faire bloquer, et amusez vous bien mais toujours de manière éthique et responsable hein !

    • chevron_right

      Alleged cryptojacking scheme consumed $3.5M of stolen computing to make just $1M

      news.movim.eu / ArsTechnica · 5 days ago - 19:46

    Alleged cryptojacking scheme consumed $3.5M of stolen computing to make just $1M

    Enlarge (credit: Getty Images)

    Federal prosecutors indicted a Nebraska man on charges he perpetrated a cryptojacking scheme that defrauded two cloud providers—one based in Seattle and the other in Redmond, Washington—out of $3.5 million.

    The indictment , filed in US District Court for the Eastern District of New York and unsealed on Monday, charges Charles O. Parks III—45 of Omaha, Nebraska—with wire fraud, money laundering, and engaging in unlawful monetary transactions in connection with the scheme. Parks has yet to enter a plea and is scheduled to make an initial appearance in federal court in Omaha on Tuesday. Parks was arrested last Friday.

    Prosecutors allege that Parks defrauded “two well-known providers of cloud computing services” of more than $3.5 million in computing resources to mine cryptocurrency. The indictment says the activity was in furtherance of a cryptojacking scheme, a term for crimes that generate digital coin through the acquisition of computing resources and electricity of others through fraud, hacking, or other illegal means.

    Read 9 remaining paragraphs | Comments

    • chevron_right

      Redis’ license change and forking are a mess that everybody can feel bad about

      news.movim.eu / ArsTechnica · Monday, 1 April - 17:47

    AWS data centers built right next to suburban cul-de-sac housing

    Enlarge / An Amazon Web Services (AWS) data center under construction in Stone Ridge, Virginia, in March 2024. Amazon will spend more than $150 billion on data centers in the next 15 years. (credit: Getty Images)

    Redis , a tremendously popular tool for storing data in-memory rather than in a database, recently switched its licensing from an open source BSD license to both a Source Available License and a Server Side Public License (SSPL).

    The software project and company supporting it were fairly clear in why they did this. Redis CEO Rowan Trollope wrote on March 20 that while Redis and volunteers sponsored the bulk of the project's code development, "the majority of Redis’ commercial sales are channeled through the largest cloud service providers, who commoditize Redis’ investments and its open source community." Clarifying a bit, "cloud service providers hosting Redis offerings will no longer be permitted to use the source code of Redis free of charge."

    Clarifying even further: Amazon Web Services (and lesser cloud giants), you cannot continue reselling Redis as a service as part of your $90 billion business without some kind of licensed contribution back.

    Read 5 remaining paragraphs | Comments

    • chevron_right

      Amazon unleashes Q, an AI assistant for the workplace

      news.movim.eu / ArsTechnica · Wednesday, 29 November - 17:13

    The Amazon Q logo.

    Enlarge / The Amazon Q logo. (credit: Amazon)

    On Tuesday, Amazon unveiled Amazon Q , an AI chatbot similar to ChatGPT that is tailored for corporate environments. Developed by Amazon Web Services (AWS), Q is designed to assist employees with tasks like summarizing documents, managing internal support tickets, and providing policy guidance, differentiating itself from consumer-focused chatbots. It also serves as a programming assistant.

    According to The New York Times , the name "Q" is a play on the word “question" and a reference to the character Q in the James Bond novels, who makes helpful tools. (And there's apparently a little bit of Q from Star Trek: The Next Generation thrown in, although hopefully the new bot won't cause mischief on that scale.)

    Amazon Q's launch positions it against existing corporate AI tools like Microsoft's Copilot , Google's Duet AI , and ChatGPT Enterprise . Unlike some of its competitors, Amazon Q isn't built on a singular AI large language model (LLM). Instead, it uses a platform called Bedrock, integrating multiple AI systems, including Amazon's Titan and models from Anthropic and Meta .

    Read 5 remaining paragraphs | Comments

    • chevron_right

      S5cmd – L’outil ultra-rapide pour manipuler vos fichiers S3

      news.movim.eu / Korben · Saturday, 12 August, 2023 - 07:00 · 1 minute

    Connaissez vous s5cmd ?

    C’est une solution ultra-rapide pour manipuler des objets stockés dans des buckets S3.

    S5cmd est comme un couteau suisse conçu pour la manipulation des fichiers S3 : il permet de lister les buckets et les objets, d’uploader et de télécharger des objets, de les déplacer, les copier, les renommer et bien plus encore. En gros, s5cmd va vous permettre de maîtriser l’ensemble de votre univers de stockage d’objets chez sans effort.

    Mais alors, qu’est-ce qui rend s5cmd si rapide? La réponse réside principalement dans deux éléments: le langage de programmation utilisé qui est le Go et la parallélisation des tâches. Cette combinaison propulse ainsi s5cmd à un niveau supérieur de performance, loin devant d’autres utilitaires comme s3cmd et aws-cli .

    En moyenne, s5cmd est 32 fois plus rapide que s3cmd et 12 fois plus rapide que aws-cli ! Vous imaginez bien que cela rend les choses beaucoup plus fluide.

    Comme c’est un outil qui s’utilise en ligne de commande, vous pouvez tout à fait l’intégrer dans vos propres process. Et si vous voulez pousser les limites encore plus loin, il existe même des scripts de tests de performance pour comparer s5cmd à d’autres outils du marché.

    En somme, s5cmd est un outil fantastique pour tous ceux qui travaillent avec des buckets S3 et souhaitent accélérer leurs tâches de manipulation d’objets. Il offre des fonctionnalités avancées et un niveau de performance remarquable.

    Alors, pourquoi ne pas l’essayer ?

    À découvrir ici

    • chevron_right

      How we host Ars, the finale and the 64-bit future

      news.movim.eu / ArsTechnica · Wednesday, 9 August, 2023 - 13:00

    How we host Ars, the finale and the 64-bit future

    Enlarge (credit: Aurich Lawson | Getty Images)

    Greetings, dear readers, and congratulations—we've reached the end of our four-part series on how Ars Technica is hosted in the cloud, and it has been a journey. We've gone through our infrastructure , our application stack , and our CI/CD strategy (that's "continuous integration and continuous deployment"—the process by which we manage and maintain our site's code).

    Now, to wrap things up, we have a bit of a grab bag of topics to go through. In this final part, we'll discuss some leftover configuration details I didn't get a chance to dive into in earlier parts—including how our battle-tested liveblogging system works (it's surprisingly simple, and yet it has withstood millions of readers hammering at it during Apple events). We'll also peek at how we handle authoritative DNS.

    Finally, we'll close on something that I've been wanting to look at for a while: AWS's cloud-based 64-bit ARM service offerings. How much of our infrastructure could we shift over onto ARM64-based systems, how much work will that be, and what might the long-term benefits be, both in terms of performance and costs?

    Read 50 remaining paragraphs | Comments

    • chevron_right

      Hosting Ars, part three: CI/CD, or how I learned to stop worrying and love DevOps

      news.movim.eu / ArsTechnica · Wednesday, 2 August, 2023 - 13:00 · 1 minute

    Image of devops

    Enlarge / DevOps, DevOps, DevOps! (credit: ArtemisDiana / Getty Images)

    One of the most important things to happen in the evolution of development over the past many years is the widespread adoption of continuous integration and continuous deployment , or CI/CD. (Sometimes the "CD" stands for "continuous delivery," depending on who you're talking to.)

    It's a concept that jettisons a lot of older ideas about how systems should be managed and instead gives you a way to update code and integrate changes as live rolling deployments while ensuring that the new code is tested and slots in smoothly with stuff that's already running. A properly architected CI/CD pipeline means you can get code changes into production faster and with fewer errors. But what does that look like in practice?

    It looks like Ars Technica, because we've adopted a CI/CD workflow to take full advantage of the flexibility afforded us by serverless cloud hosting. Welcome to part three of our four-part series on how we host Ars—here, we’re going to swing away from the "ops" side of "DevOps" and peer more closely at the "dev" part instead. Join us for a look behind the curtain at how Ars uses CI/CD in both our deployed applications and our infrastructure management!

    Read 38 remaining paragraphs | Comments

    • chevron_right

      How we host Ars Technica in the cloud, part two: The software

      news.movim.eu / ArsTechnica · Wednesday, 26 July, 2023 - 13:00 · 1 minute

    Welcome aboard the orbital HQ, readers!

    Enlarge / Welcome aboard the orbital HQ, readers! (credit: Aurich Lawson | Getty Images)

    Welcome back to our series on how Ars Technica is hosted and run! Last week, in part one , we cracked open the (virtual) doors to peek inside the Ars (virtual) data center. We talked about our Amazon Web Services setup, which is primarily built around ECS containers being spun up as needed to handle web traffic, and we walked through the ways that all of our hosting services hook together and function as a whole.

    This week, we shift our focus to a different layer in the stack—the applications we run on those services and how they work in the cloud. Those applications, after all, are what you come to the site for; you’re not here to marvel at a smoothly functioning infrastructure but rather to actually read the site. (I mean, I’m guessing that’s why you come here. It’s either that or everyone is showing up hoping I’m going to pour ketchup on myself and launch myself down a Slip-'N-Slide , but that was a one-time thing I did a long time ago when I was young and needed the money.)

    How traditional WordPress hosting works

    Although I am, at best, a casual sysadmin, having hung up my pro spurs a decade and change ago, I do have some relevant practical experience hosting WordPress. I’m currently the volunteer admin for a half-dozen WordPress sites, including Houston-area weather forecast destination Space City Weather (along with its Spanish-language counterpart Tiempo Ciudad Espacial ), the Atlantic hurricane-focused blog The Eyewall , my personal blog, and a few other odds and ends.

    Read 55 remaining paragraphs | Comments

    • chevron_right

      Behind the scenes: How we host Ars Technica, part 1

      news.movim.eu / ArsTechnica · Wednesday, 19 July, 2023 - 13:00 · 1 minute

    Take a peek inside the Ars vault with us!

    Enlarge / Take a peek inside the Ars vault with us! (credit: Aurich Lawson | Getty Images)

    A bit over three years ago, just before COVID hit, we ran a long piece on the tools and tricks that make Ars function without a physical office . Ars has spent decades perfecting how to get things done as a distributed remote workforce, and as it turns out, we were even more fortunate than we realized because that distributed nature made working through the pandemic more or less a non-event for us. While other companies were scrambling to get work-from-home arranged for their employees, we kept on trucking without needing to do anything different.

    However, there was a significant change that Ars went through right around the time that article was published. January 2020 marked our transition away from physical infrastructure and into a wholly cloud-based hosting environment. After years of great service from the folks at Server Central (now Deft ), the time had come for a leap into the clouds—and leap we did.

    There were a few big reasons to make the change, but the ones that mattered most were feature- and cost-related. Ars fiercely believes in running its own tech stack, mainly because we can iterate new features faster that way, and our community platform is unique among other Condé Nast brands. So when the rest of the company was either moving to or already on Amazon Web Services (AWS), we could hop on the bandwagon and take advantage of Condé’s enterprise pricing. That—combined with no longer having to maintain physical reserve infrastructure to absorb big traffic spikes and being able to rely on scaling—fundamentally changed the equation for us.

    Read 51 remaining paragraphs | Comments