Ti è mai capitato di voler scaricare una mod per Wesnoth e trovarti di fronte a un muro di codice JavaScript che ti chiede di dimostrare che non sei un bot? Bene, ora è ufficiale: anche i giochi open-source si devono difendere dagli scraper famelici.

Il team di Wesnoth ha implementato Anubis, un sistema Proof-of-Work ispirato a Hashcash, per rallentare i bot che cercano di succhiare dati dal loro server. In pratica, se arrivi con un headless browser o un crawler aggressivo, ti tocca risolvere un problema di calcolo prima di poter accedere al sito. Per gli umani, dovrebbe essere trasparente (a meno che non usi estensioni come JShelter, in quel caso sei fritto).

Per noi che amiamo smanettare con il codice, questa è una notizia interessante. Anubis è un esempio pratico di come il Proof-of-Work possa essere usato per altri scopi oltre al mining di criptovalute. Certo, non è perfetto: qualche utente legittimo potrebbe avere problemi, e se sei un maker che usa browser modificati, preparati a qualche grattacapo.

Ma la domanda vera è: quanto è efficace? Gli scraper troveranno un modo per aggirarlo (come sempre), ma nel frattempo Wesnoth guadagna tempo per lavorare su soluzioni più sofisticate, come il fingerprinting dei browser. Insomma, è una soluzione temporanea, ma meglio di niente.

Se sei un appassionato di Wesnoth, probabilmente avrai già notato il cambiamento. Se invece sei uno sviluppatore, potrebbe valere la pena dare un’occhiata al codice di Anubis per vedere come funziona sotto il cofano. E se sei un bot? Beh, speriamo che ti tocchi un bel po’ di lavoro inutile prima di poter rubare i dati.

In conclusione, è una mossa che dimostra quanto sia importante proteggere i progetti open-source dagli abusi. E se anche tu hai un sito che soffre di scraper, forse vale la pena dare un’occhiata ad Anubis. Intanto, buon divertimento con le tue campagne su Wesnoth, e ricordati di disabilitare JShelter se vuoi giocare senza problemi!

Source: Battle for Wesnoth: open-source, turn-based strategy game

Sai quella sensazione quando scarichi un pacchetto npm e ti dici: “Ma chi me lo fa fare di usare qualcosa che non ho scritto io”? Bene, ora hai un motivo in più per essere paranoico. Axios, il client HTTP più usato nel mondo JavaScript, è stato appena compromesso in modo elegante e subdolo.

La storia inizia con due versioni maligne (1.14.1 e 0.30.4) che sono state pubblicate su npm. L’attaccante ha preso il controllo dell’account di un maintainer e ha iniettato una dipendenza nascosta chiamata plain-crypto-js@4.2.1. Questa dipendenza non viene mai importata nel codice di axios, ma ha un solo scopo: eseguire uno script postinstall che scarica un Remote Access Trojan (RAT) cross-platform. Sì, avete capito bene: il tuo pacchetto preferito per le chiamate HTTP è diventato un cavallo di Troia.

Ma la cosa più inquietante? Dopo aver fatto il suo lavoro sporco, il malware si cancella e sostituisce il proprio package.json con una versione “pulita” per evitare di essere scoperto. Insomma, un lavoro da professionisti del crimine informatico.

Se pensavi che gli attacchi supply chain fossero roba da film, beh, ora è realtà. Questo attacco è stato così ben orchestrato che è stato rilevato solo grazie a strumenti avanzati come StepSecurity Harden-Runner, che ha notato connessioni sospette durante le build CI.

Per noi smanettoni, maker e hacker, questo è un promemoria importante: anche i pacchetti più affidabili possono essere compromessi. Ecco alcune lezioni pratiche:

1. **Sii paranoico**: Controlla sempre le dipendenze e usa strumenti come npm audit per rilevare vulnerabilità.

2. **Non fidarti, verifica**: Se vedi un pacchetto sospetto, ispeziona il codice prima di installarlo. Anche se è axios.

3. **Usa sandbox**: Se lavori su progetti importanti, considera l’uso di ambienti isolati per testare le dipendenze.

4. **Aggiorna con cautela**: Anche se un aggiornamento sembra legittimo, controlla sempre le note di rilascio e le firme delle versioni.

5. **Non sottovalutare il postinstall**: Gli script postinstall possono essere pericolosi. Leggi sempre cosa fanno prima di eseguirli.

La community di StepSecurity sta organizzando un webinar per spiegare meglio l’attacco e le contromisure. Se sei interessato, registrati pure. Ma nel frattempo, fate attenzione a cosa installate. Il mondo npm è pieno di insidie, e oggi abbiamo visto quanto possa essere pericoloso.

E ora, torniamo a smanettare con i nostri Raspberry Pi e Arduino, ma con un occhio di più sulle dipendenze. Stay safe, coders!

Source: Axios compromised on NPM – Malicious versions drop remote access trojan

Avete mai avuto quella sensazione di quando lasci il portafoglio sul bancone di un bar e te ne accorgi solo dopo tre isolati? Ecco, qualcosa di simile è successo ai creatori di Claude Code: hanno appena scoperto che il loro prezioso codice sorgente è finito online perché un file di mappatura (map file) nell’NPM registry ha deciso di fare il fischietto.

Per chi non è del mestiere, un map file è un po’ come il manuale di montaggio di un mobile IKEA: ti dice dove sono tutti i pezzi, ma non dovrebbe mai rivelare il design segreto del prodotto finito. E invece, boom, ecco che il codice di Claude fa il suo debutto su Twitter, grazie a un post di Fried_rice che ha scatenato il solito putiferio su Hacker News.

La community, ovviamente, non si è fatta sfuggire l’occasione per sbatterci sopra le mani. C’è chi ha già analizzato il codice in cerca di bug, chi ha provato a reverse-engineer le funzionalità e chi, più semplicemente, si gode lo spettacolo di un altro colosso tech che inciampa nei propri piedi.

Da smanettone, non posso che trovare la situazione esilarante. È come se avessero lasciato le chiavi di casa sotto lo zerbino e poi si fossero lamentati quando il vicino ha usato la lavatrice. Certo, è una situazione imbarazzante per Claude, ma per noi che amiamo mettere le mani in pasta è una manna dal cielo: finalmente possiamo dare un’occhiata sotto il cofano e capire come funziona davvero.

E poi, ammettiamolo, queste storie sono un ottimo promemoria: la sicurezza non è un’opzione, ma un requisito. Quante volte abbiamo visto progetti open-source con password hardcoded o chiavi API esposte? Troppo spesso. Ecco perché, quando lavorate ai vostri progetti, ricordatevi di fare un controllo incrociato prima di pubblicare qualsiasi cosa. Perché sì, anche il file di mappatura più innocente potrebbe trasformarsi nel vostro peggior nemico.

E ora, mentre Claude cerca di limitare i danni, noi possiamo solo goderci lo spettacolo e imparare dalla loro disavventura. Dopotutto, come si dice: “Se non è rotto, non lo hai ancora smontato abbastanza.”

Source: Claude Code's source code has been leaked via a map file in their NPM registry

Immagina di installare un pacchetto Python per semplificarti la vita e invece di farti risparmiare tempo, ti ruba tutte le credenziali. È successo a LiteLLM, e il risultato è un bel casino.

Il pacchetto LiteLLM versione 1.82.8 è stato compromesso con un attacco supply chain che ha inserito un file nascosto (litellm_init.pth) in grado di rubare dati sensibili non appena avvii Python. Niente import necessario, niente avviso: il file si attiva automaticamente e inizia a raccogliere informazioni.

La lista delle cose rubate è impressionante: chiavi SSH, credenziali cloud (AWS, GCP, Azure), configurazioni di Docker, token CI/CD, e persino le tue crypto-wallets. Tutto questo viene compresso, crittografato e inviato a un server controllato dagli attaccanti. Il peggio? Il file è stato nascosto con un doppio encoding base64, quindi non lo becchi nemmeno con un semplice grep.

Come smanettoni, sappiamo che il supply chain è il nuovo fronte di battaglia. I pacchetti che scarichiamo sono come ingredienti per le nostre ricette: se uno è avariato, rovina tutto il piatto. E qui il piatto era proprio avariato di brutto.

Cosa possiamo imparare?
1. **Verifica sempre i pacchetti che scarichi**: guarda le dipendenze, controlla le firme, usa strumenti come `pip check`.
2. **Isola gli ambienti**: usa container o macchine virtuali per i progetti sensibili. Se qualcosa va storto, almeno non si propaga.
3. **Rotazione credenziali**: se hai usato LiteLLM 1.82.8, cambia tutte le credenziali. Tutte. Sì, anche quelle che non pensavi fossero a rischio.
4. **Monitora i tuoi progetti**: se vedi file sospetti in site-packages/, indaga. Non aspettare che sia troppo tardi.

E un ultimo pensiero per i vendor: PyPI, è ora di prendere sul serio la sicurezza del tuo ecosistema. Un attacco del genere è un segnale che il supply chain è un bersaglio facile, e senza misure più stringenti, sarà sempre la porta sul retro per gli hacker.

Se hai installato LiteLLM 1.82.8, corri a sistemare il casino. E se non l’hai fatto, considera questo un promemoria per essere sempre più paranoici del solito. Perché in questo gioco, la paranoia è la tua migliore amica.

Source: LiteLLM Python package compromised by supply-chain attack

Hai mai pensato che la cosa più pericolosa in un progetto open source potesse essere qualcosa che non riesci nemmeno a vedere? Bene, benvenuto nel futuro degli attacchi informatici.

Arstechnica ha appena rivelato un attacco supply-chain che sfrutta caratteri Unicode invisibili per infettare repository su GitHub e altre piattaforme. Sì, hai capito bene: codice che non vedi, ma che può farti un sacco di danni.

La storia inizia con l’abbandono di caratteri Unicode invisibili, che sembravano destinati a finire nel dimenticatoio. Finché, ovviamente, qualcuno non ha pensato: “E se li usassi per hackerare?”. E così è stato. Gli attaccanti hanno iniziato a inserire codice malizioso nascosto in caratteri che non vengono visualizzati, ma che i computer eseguono comunque. Il risultato? Progetti apparentemente puliti che, in realtà, contengono backdoor pronte a scattare.

Come smanettoni, questo dovrebbe farci riflettere. Abbiamo sempre sottovalutato l’importanza di strumenti di analisi del codice che vanno oltre il semplice “controllo visivo”. Ora, dobbiamo essere ancora più attenti, perché il nemico è diventato invisibile.

E non parliamo solo di GitHub. Altri repository potrebbero essere colpiti, e il problema è che questi attacchi sono difficili da rilevare. Anche se usi Git con diff, potresti non notare la differenza. Ecco perché è fondamentale integrare strumenti di analisi statica e dinamica nel nostro flusso di lavoro. Sì, so che odiate aggiungere altri passaggi, ma meglio prevenire che piangere su un server compromesso.

E poi c’è la questione della responsabilità. GitHub e gli altri giganti del cloud dovrebbero fare di più per proteggere i developer. Non è accettabile che un attacco così subdolo possa passare inosservato. Forse è ora di smetterla di fidarsi ciecamente dei vendor e iniziare a chiedere trasparenza e strumenti migliori.

Ma non tutto è perduto. Questo attacco ci ricorda l’importanza di essere sempre un passo avanti. Se siete tra quelli che amano smanettare con il codice, ecco alcuni consigli pratici:

1. **Usa strumenti di analisi del codice**: Non fidarti solo del tuo occhio. Strumenti come SonarQube o CodeQL possono aiutarti a rilevare anomalie.

2. **Controlla i log**: Se qualcosa sembra strano, indaga. Anche se non vedi nulla, i log potrebbero rivelare attività sospette.

3. **Aggiorna sempre**: Sì, lo so, è noioso. Ma gli aggiornamenti spesso includono patch di sicurezza critiche.

4. **Fai backup**: Non sottovalutare l’importanza di avere copie di sicurezza. Anche se non riesci a vedere il codice dannoso, un backup può salvarti.

In conclusione, questo attacco è un promemoria che il mondo del coding è pieno di insidie. Ma con un po’ di attenzione e gli strumenti giusti, possiamo evitare di diventare le prossime vittime. E ora, tornate a smanettare, ma con gli occhi ben aperti!

Source: Supply-chain attack using invisible code hits GitHub and other repositories

Se pensavi che i malware fossero roba da corporate IT, preparati a ricrederti. Lumma Stealer, quel fastidioso parassita digitale che sembrava essersi ritirato in buon ordine, è tornato con una nuova versione che fa venire voglia di cliccare anche ai più scettici. E sì, purtroppo per noi, le vittime preferite sono proprio quelli come noi: smanettoni, curiosi e sempre alla ricerca di qualcosa di nuovo da provare.

La novità? Lumma ha imparato a nascondersi meglio, grazie a un nuovo meccanismo di infezione che sfrutta il ClickFix bait e il malware Castleloader. In pratica, si è trasformato in un’astuta trappola che sfrutta la nostra naturale curiosità per software aggiornamenti e patch di sicurezza. Insomma, il classico “trojan horse” ma con un look più moderno e un approccio più subdolo.

Ma perché dovrebbe interessarci? Beh, perché noi che passiamo le notti a smanettare con Arduino e Raspberry Pi siamo anche quelli che scaricano più facilmente software da sorgenti non ufficiali, che testano beta di programmi sconosciuti e che cliccano su link sospetti “solo per vedere cosa succede”. Ecco, Lumma ha imparato a sfruttare proprio questo nostro lato più… esplorativo.

Allora, cosa possiamo fare per proteggerci? Innanzitutto, ricordiamo che la prudenza non è mai troppa. Installare un buon antivirus (sì, lo so, sembra una cosa da nonni, ma fidati), aggiornare sempre i sistemi operativi e, soprattutto, evitare di scaricare software da fonti non verificare. Se devi provare qualcosa di nuovo, fallo in un ambiente virtuale o su una macchina dedicata. E se qualcosa ti sembra troppo bello per essere vero, probabilmente lo è.

Un’ultima cosa: se sei un maker o un hacker, sei anche una potenziale vittima. Non sottovalutare il rischio solo perché ti credi immune. Lumma Stealer non fa distinzioni tra professionisti e dilettanti, tra esperti e principianti. Quindi, teniamo gli occhi aperti e continuiamo a smanettare… ma con più cautela.

E ora, tornate pure ai vostri progetti. Ma prima, fate un backup. Grazie.

Source: Once-hobbled Lumma Stealer is back with lures that are hard to resist

Immagina di aprire il tuo editor di testo preferito, Notepad++, e scoprire che per sei mesi ha installato aggiornamenti… da parte di hacker statali cinesi. Sì, hai letto bene.

La notizia arriva fresca fresca da Ars Technica e riguarda un attacco supply-chain che ha sfruttato l’infrastruttura di aggiornamento di Notepad++ per distribuire una versione backdoored. In parole povere, mentre pensavi di stare tranquillo a smanettare con il tuo codice, qualcuno ha approfittato della tua fiducia per installare un bel cavallo di Troia sul tuo sistema.

L’attacco è stato scoperto solo dopo sei mesi di attività, il che significa che migliaia di utenti potrebbero essere stati compromessi senza saperlo. La domanda sorge spontanea: come è possibile che un software open-source così diffuso abbia subito un attacco del genere?

Da smanettone a smanettone, posso dirvi che questa storia è un promemoria importante: anche i tool che usiamo tutti i giorni possono nascondere insidie. Notepad++ è un editor fantastico, ma come tutti i software, dipende da chi lo mantiene e da come gestisce gli aggiornamenti.

Per noi che amiamo mettere le mani in pasta, questa vicenda è un’occasione per riflettere su alcune buone pratiche:

1. **Controlla sempre gli aggiornamenti**: prima di installare un aggiornamento, chiediti se è davvero necessario e se proviene da una fonte attendibile.
2. **Usa alternative open-source**: se Notepad++ ti ha deluso, potresti dare un’occhiata a Visual Studio Code, Sublime Text o altri editor con community attive e trasparenti.
3. **Fai backup**: perché quando le cose vanno male, è sempre meglio avere un piano B.

E poi, diciamocelo, questa storia è anche un po’ ironica: un editor di testo usato da sviluppatori per scrivere codice sicuro è diventato il punto debole di una catena di attacco. La vita è strana, no?

In conclusione, se sei un utente di Notepad++, è il momento di fare un po’ di pulizie e controllare se il tuo sistema è stato compromesso. E ricordate: la prossima volta che vedete un aggiornamento, chiedetevi se è davvero un regalo… o un tranello.

Buon hacking a tutti!

Source: Notepad++ users take note: It's time to check if you're hacked

Avete mai pensato a come sarebbe un mondo in cui anche i giganti della tech si mettono a costruire giocattoli per smanettoni? Bene, Microsoft ha appena fatto un passo in questa direzione con LiteBox, un sistema operativo libreria open-source che promette di rivoluzionare la sicurezza del software.

LiteBox è un progetto che punta a ridurre al minimo l’attacco superficie delle applicazioni, offrendo un ambiente sandboxed in cui eseguire codice in modo sicuro. Ma cosa significa davvero tutto questo? In parole povere, LiteBox è come un Lego per sviluppatori: ti dà i mattoncini per costruire ambienti isolati in cui far girare programmi senza che possano combinare troppi guai.

Il progetto è scritto principalmente in Rust, quel linguaggio che tutti noi amiamo per la sua sicurezza e la sua eleganza. Ma non è solo questo: LiteBox supporta sia l’esecuzione in modalità kernel che user-mode, il che lo rende incredibilmente flessibile. Puoi usarlo per eseguire programmi Linux su Windows, sandboxare applicazioni Linux su Linux stesso, o addirittura far girare codice su piattaforme come SEV-SNP o OP-TEE.

Ora, voi vi chiederete: “Ma perché dovrebbe interessarmi? Io sono solo uno smanettone che passa le notti a programmare su Arduino!” Beh, ecco perché: LiteBox è open-source e sotto licenza MIT, il che significa che potete prenderlo, smontarlo, modificarlo e farci quello che volete. È un giocattolo perfetto per chi ama sperimentare con la sicurezza, testare nuovi ambienti isolati o semplicemente capire come funzionano le cose sotto il cofano.

Certo, non è tutto rose e fiori. LiteBox è ancora in fase di sviluppo attivo, il che significa che alcune API e interfacce potrebbero cambiare. Se siete alla ricerca di stabilità a lungo termine, potrebbe essere meglio aspettare una release ufficiale. Ma per noi smanettoni, questo è un invito a nozze: finalmente un progetto che possiamo contribuire a plasmare fin dalle prime fasi.

E poi, ammettiamolo: è sempre bello vedere i giganti della tech fare qualcosa di utile per la community. Microsoft ha fatto un bel passo avanti con questo rilascio, e noi non possiamo che apprezzare. Ora, però, tocca a noi: è il momento di mettersi le mani in pasta, esplorare il codice e vedere cosa si può fare con LiteBox.

Quindi, cosa state aspettando? Andate a dare un’occhiata al repository su GitHub, scaricate il codice e iniziate a sperimentare. Chi lo sa, magari la prossima grande innovazione nella sicurezza del software potrebbe partire proprio da uno di noi.

Source: Microsoft open-sources LiteBox, a security-focused library OS

Immagina di essere pagato per fare il tuo lavoro, solo per finire in galera. Questo è ciò che è successo a Gary DeMercurio e Justin Wynn, due pentesters che hanno testato la sicurezza di un tribunale. Il loro crimine? Avere fatto esattamente quello per cui erano stati ingaggiati.

La contea in questione ha deciso di pagare 600mila dollari per sistemare la situazione, ma la storia è molto più interessante di così. Vediamo insieme cosa è successo e cosa possiamo imparare da questo pasticcio.

Tutto è iniziato nel 2020, quando i due esperti di sicurezza sono stati ingaggiati per testare le vulnerabilità del tribunale. Hanno fatto il loro lavoro, hanno trovato problemi seri, e poi… sono stati arrestati. Sì, avete capito bene. La contea ha deciso che il modo migliore per gestire una falla di sicurezza era sbattere in prigione chi l’aveva scoperta.

Dopo oltre sei anni di battaglie legali, finalmente la contea ha capito che forse non era stata un’idea geniale. E così, invece di continuare a fare la guerra ai suoi stessi esperti di sicurezza, ha preferito pagare un bel po’ di soldi per chiudere la faccenda.

Da smanettone, la prima cosa che mi viene in mente è: ma davvero? In un’epoca in cui la cybersecurity è più importante che mai, come si fa a non capire che arrestare chi cerca di proteggerti è l’ultimo dei buoni consigli? Se anche noi, quando troviamo un bug in un nostro progetto, venissimo arrestati per averlo segnalato, non credo che molti si sentirebbero motivati a continuare.

La lezione principale qui è che la sicurezza informatica non è un gioco. Se vuoi che la gente ti aiuti a proteggere i tuoi sistemi, devi trattarli con rispetto. Arrestarli non è esattamente il modo migliore per guadagnarsi la loro fiducia.

Per noi che amiamo smanettare, questo caso è un esempio perfetto di come la burocrazia possa trasformare una situazione semplice in un incubo. La prossima volta che qualcuno vi dice che la sicurezza è troppo complicata, ricordategli questa storia. E se qualcuno vi chiede di testare la sicurezza di un sistema, assicuratevi che abbiano capito bene cosa state facendo. Altrimenti, potreste finire nei guai.

In conclusione, la contea ha imparato la lezione a caro prezzo. Noi possiamo imparare da questo errore senza dover sborsare 600mila dollari. La prossima volta che qualcuno vi chiede di testare la sicurezza di qualcosa, assicuratevi che sappiano cosa stanno facendo. Altrimenti, potreste finire nei guai.

E ricordate: se vi arrestano per aver fatto il vostro lavoro, forse è il caso di cambiare lavoro.

Source: County pays $600,000 to pentesters it arrested for assessing courthouse security

Immagina di chiudere una chat con un assistente AI, convinto che la conversazione sia al sicuro. E invece? Un click malevolo può aver già rubato tutto.

Sì, avete letto bene. Un recente attacco ha dimostrato che Copilot può essere sfruttato per esfiltrate dati dalle chat storiche, anche dopo che l’utente ha chiuso la finestra. Niente di nuovo sotto il sole, direte voi, ma il punto è che questo exploit è stato particolarmente subdolo: si è nascosto in un click, ha fatto il suo sporco lavoro e poi è sparito senza lasciare tracce.

Per noi smanettoni che usiamo questi tool per automatizzare il lavoro o per esperimenti geek, la notizia dovrebbe suonare come un campanello d’allarme. Se pensavate che chiudere una chat fosse sufficiente a proteggere i vostri dati, beh, è ora di rivedere le vostre abitudini.

Ma non è solo questione di sicurezza. Questo attacco solleva anche domande scomode sul vendor lock-in di Microsoft e su quanto possiamo davvero fidarci degli assistenti AI. Se anche i big del settore hanno falle così evidenti, cosa possiamo aspettarci dai tool open-source che usiamo nei nostri progetti?

Per noi maker, la lezione è chiara: se state usando Copilot (o qualsiasi altro AI assistant) per gestire dati sensibili, fate attenzione. Non solo per l’esfiltrate, ma anche per il fatto che questi tool potrebbero non essere così “intelligenti” come vogliono farci credere.

E poi, ammettiamolo: c’è qualcosa di profondamente inquietante nel pensiero che un click possa rubare i nostri segreti. Forse è tempo di tornare a smanettare con soluzioni più trasparenti, anche se meno “cool”.

In conclusione, se c’è una cosa che questo attacco ci insegna, è che la tecnologia, per quanto avanzata, non è mai immune da vulnerabilità. E per noi che viviamo di codice e circuiti, è un promemoria utile: la sicurezza è sempre l’ultimo step, mai il primo.

Source: A single click mounted a covert, multistage attack against Copilot