Avete mai desiderato che i vostri script di automazione facessero il lavoro sporco al posto vostro, magari pulendo il codice o aggiornando le dipendenze, senza però che si portassera via anche le vostre password del server? Ecco, sembra che qualcuno abbia preso questo concetto un po’ troppo alla lettera.

Arrivano notizie fresche (e decisamente poco rallegranti) da Ars Technica: per la seconda volta in poche settimane, abbiamo scoperto pacchetti Microsoft che sono in realtà dei cavalli di Troia travestiti. Non stiamo parlando della solita vecchia mail di phishing che arriva dal tizio che ti promette un iPhone gratis, ma di roba che si nasconde dentro pacchetti software ufficiali o apparentemente legittimi. Il payload in questione? Un credential stealer che si auto-replica non appena viene toccato da un agente AI.

Sì, avete letto bene. Il malware è progettato per sfruttare proprio quella nuova ondata di automazione basata su IA che tutti stiamo cercando di implementare nei nostri workflow. Se lasciate che un agente AI analizzi il codice o gestisca i pacchetti per voi, il malware si sveglia, si replica e inizia a succhiarti le credenziali. È come se avessi costruito un robot per pulire il garage e lui, invece di raccogliere le viti, iniziasse a svuotare il tuo conto in banca.

Da smanettone che non vive in una bolla di sudsata sicurezza corporate, trovo questo scenario assolutamente inquietante ma anche tragicamente prevedibile. Siamo in un’epoca in cui il marketing spinge l’automazione AI ovunque, ma la sicurezza della supply chain è rimasta ferma ai tempi del modem 56k. Microsoft, con tutta la sua infrastruttura mastodontica, si ritrova a essere il vettore perfetto per questo tipo di attacchi. È il classico problema del ‘too big to fail’ che diventa ‘too big to secure’.

Per noi che passiamo le notti a compilare kernel, buildare macchine CNC o far girare script Python per gestire i dati dei sensori, la lezione è una sola: l’automazione senza controllo è un suicidio digitale. Se state iniziando a usare agenti AI per gestire repository o per il deployment, fate attenzione. Non date in pasto ai bot qualsiasi cosa senza aver prima verificato l’integrità di quello che state scaricando. Il sandbox non è più un’opzione, è una necessità vitale.

In un mondo dove il software è sempre più una scatola nera e le dipendenze sono un labirinto di codice scritto da sconosciuti, l’unica difesa è tornare alle basi: ispezionare, testare e, se possibile, isolare. E per l’amor di Dio, tenete le chiavi SSH lontano dai bot che non avete configurato voi.

Source: For the 2nd time in weeks, Microsoft packages laced with credential stealer

Se pensavate che l’unico rischio nel fare build di una nuova libreria fosse un crash improvviso di Python o un conflitto di dipendenze che vi tiene svegli fino alle tre di notte, beh, devo comunicarti una brutta notizia.

서서 (Sospesa) tra un caffè e un glitch di sistema, la notizia che arriva da Ars Technica è una vera mazzata per chiunque viva di codice condiviso: un gruppo di hacker chiamato TeamPCP sta lanciando una campagna di inquinamento del codice open source a una scala che non abbiamo mai visto prima. Non si tratta del solito script kiddie che cerca di rompere il server di qualcuno per noia; qui parliamo di attacchi alla software supply chain che hanno colpito direttamente GitHub.

In pratica, stanno facendo ‘poisoning’ del codice. Immaginate di stare lavorando al vostro progetto preferito su Godot, scaricando una dipendenza che sembra innocua, solo per scoprire che dentro c’è un payload che trasforma il vostro PC in un zombie per una botnet. È come se qualcuno entrasse nel vostro laboratorio, scambiasse i vostri fili di rame con fili di plastica scadente e sperasse che il vostro nuovo CNC non prenda fuoco durante la prima lavorazione.

Il problema non è solo la sicurezza, è la fiducia. L’intero ecosistema su cui si regge il mondo moderno — dai server cloud alle macchine che controllano i bracci robotici — si basa sull’idea che se una libreria è popolare e testata, allora è sicura. TeamPCP sta usando questa fiducia contro di noi. È l’ennesima dimostrazione di come la centralizzazione della gestione del codice (grazie mille, GitHub) possa diventare un unico, enorme punto di fallimento.

Per noi che amiamo smanettare, che scarichiamo pacchetti senza leggere ogni singola riga di codice (perché, diciamocelo, chi ha tempo?), questa è una chiamata alle armi. Non significa che dobbiamo smettere di usare l’open source — sarebbe come dire di smettere di usare i componenti elettronici perché qualcuno potrebbe venderti un transistor truccato — ma significa che dobbiamo tornare alle vecchie buone abitudini della vera cultura hacker.

Dobbiamo imparare a fare auditing più severo, a monitorare le checksum come se fossero il tesoro più prezioso e, quando possibile, a isolare i processi critici in sandbox che non abbiano accesso diretto alla vostra rete locale. La comodità delle dipendenze automatiche sta diventando un boomerang. È un momento triste per l’entusiasmo senza filtri, ma è anche un promemoria: nel mondo del software, come nel modellismo 3D, se non controlli la qualità della materia prima, il risultato finale sarà un disastro.

Tenete gli occhi aperti, verificate i commit e, se vedete qualcosa di troppo strano nei vostri repository, non ignoratelo. Il prossimo aggiornamento potrebbe non essere solo un fix per un bug, ma un cavallo di Troia.

Source: A hacker group is poisoning open source code at an unprecedented scale