hackrocchio 2022

Ci vediamo il 9-10 Aprile al Edera per hackroccho!

 

hackrocchio

https://hackrocchio.org

 

si ma cos’è?

Due giorni di smanettamenti, autoformazione, workshop, seminari, riappropriazione dei saperi, hacking e cattivi odori.

Costruire comunità resistenti complici nelle lotte, saldare relazioni di fiducia tra le moltitudini sommerse nell’estrattivismo cognitivo, riuscire ad immaginare e a costruire tecnologie conviviali che sostituiscano le megamacchine digitali. Non promettiamo la rivoluzione ma il crepuscolo degli dei, per farlo inietteremo lo shellcode nel paese reale, andando nelle case ma sopratutto nei cuori di chi ancora ci crede, a decifrare le blockchain corrotte di un sistema che nulla ha più di umano se non la scalabilità del vostro frigorifero nel cloud, insomma, in una parola, quantum machine learning 🙂

eee ma cosa si fa?

Stiamo ancora raccogliendo i contributi. Crediamo fortissimamente nella contaminazione delle discipline: dall’informatica alla fisica, dalla meccanica alla filosofia, dall’agricoltura alla matematica, dalla logica all’arte, dall’architettura all’antropologia e continuate voi con gli abbinamenti che preferite.
Siamo persone curiose in ogni campo e riconosciamo la necessità di intrecciare le esperienze per indagare la complessità del reale, senza arroganti semplificazioni di comodo.
Se vuoi proporre un seminario, un workshop, un contributo, un laboratorio, invia una e-mail all’indirizzo underscore [chiocciola] autistici.org indicando il nome e il tipo dell’intervento, la durata, una breve descrizione, il necessario (proiettore, lavagna, pentole, persone, etc.) e un orario preferenziale.

Se l’intervento che hai in mente è più una suggestione o non te la senti di parlare per troppo tempo, sono previsti alcuni momenti dedicati ai “ten minutes talks”. Di solito si tengono a fine giornata, qualcuno si occuperà di segnalare lo sforamento eccessivo dei dieci minuti.

ok, ma se voglio venire e partecipare cosa devo fare?

Vuoi sbrodolare per 10 minuti o 2 ore la tua malsana idea?
Stai progettando la rivoluzione in html e c++?
Stai sublimando la tua libido nel do it yourself lisergico?

Portaci il tuo feticcio indomabile, che sia il tuo progettino della domenica o il piano segreto per conquistare il mondo dalla cantina.

Troverai le persone giuste che dilapideranno le proprie ore salariate per contribuire al tuo delirio personale e far trionfare l’HackЯocchio sul prodotto dell’etica protestante capitalista.

Perche’ in una societa’ che obbliga all’eccellenza, scegliere di fare schifo alla merda è un gesto rivoluzionario.

 

per maggiori informazioni: https://hackrocchio.org/

Chi è Area Spa?

Ripubblichiamo piu’ che volentieri un tentativo di censura finito male dei nostri eroi di Area Spa

 

streisand

 

 

Il consiglio è quello di condividere l’articolo sul vostro blog, ma soprattutto di leggerlo con attenzione, senza dimenticare di guardare questi due imperdibili video!

da notav.info

 

Dai contatti con Al Sisi alla sorveglianza per Assad, chi è Area spa, l’azienda che spia i notav.

Nei giorni scorsi abbiamo ricevuto e pubblicato un video inviato da alcuni escursionisti della Val Clarea che, andando per funghi, si sono imbattuti in una vasta rete di telecamere nascoste cablate sotto le rocce e dissimulate dalla polizia in pieno lockdown per spiare i valsusini. Nei video recuperati dai notav si vedono la dirigenza della digos di Torino farsi selfie con le nuove apparecchiature durante la scampagnata e alcuni tecnici che li aiutano nell’istallazione dei dispositivi.

Se sulla figura di palta della mitica polizia politica del capoluogo piemontese non c’è molto da dire visto che ha fatto già sganasciare la metà della rete, vale la pena spendere due parole in più sul profilo dell’azienda che li accompagnava, la Area spa, tra le principali ad aver investito il mercato in piena espansione dei dispositivi per la sorveglianza di massa e protagonista di diversi affari con regimi dittatoriali di tutto il

https://www.notav.info/wp-content/uploads/2020/07/Schermata-2020-07-21-alle-13.56.22.png

 

In Italia, un pugno di società private si dividono il mercato delle intercettazioni telefoniche e web. Una delle più importanti è un’azienda del varesotto, l’Area spa, specializzata nei dispositivi cosiddetti dual use, apparecchi di spionaggio utilizzabili sia in ambito militare che civile e quindi molto comodi per eludere le legislazioni contro la vendita di armamenti. Fondata nel 1996, Area spa attraversa anni travagliati che portano la società a più riprese sull’orlo del fallimento fino al 2009 quando arriva la svolta: vince una grossa commessa, circa 17 milioni di euro, per un dispositivo DPI (Deep packet Inspection) che consente di intercettare e analizzare email, conversazioni e ricerche internet dei cittadini siriani per conto dei servizi del presidente Assad. L’affare è denunciato dal giornale Bloomberg nell’autunno del 2011 e le rivelazioni costringeranno cinque anni dopo la procura di Milano ad aprire un’inchiesta che travolgerà l’amministratore delegato di Area, Andrea Fromenti, con le accuse di esportazione illegale di materiale dual use e dichiarazioni non veritiere. Secondo i PM, esattamente nelle settimane in cui il vento delle primavere arabe faceva vacillare il presidente siriano che reagiva lanciando barili di dinamite sui manifestanti dagli elicotteri, gli ingegneri dell’azienda sarebbero volati da Milano a Damasco con le apparecchiature nascoste nei bagagli facilitando la feroce repressione dei dissidenti (dopo le rivelazioni di Bloomberg la sede dell’azienda a Vizzola Ticino sarà tra l’altro il bersaglio di un sit-in di rifugiati politici siriani).

Nonostante la vicenda, il MISE nel giugno del 2016 autorizza Area spa a installare attrezzature analoghe a beneficio del regime egiziano di Al Sisi. L’affare avrebbe dovuto andare in porto appena poche settimane dopo la morte di Giulio Regeni e avrebbe avuto come destinatario finale il Technical Research Department (TRD), sorta di unità distaccata dei servizi segreti incaricata di infiltrare e monitorare l’opposizione alla giunta militare. Solo grazie alle pressioni della famiglia del giovane ricercatore italiano la licenza è infine revocata. I dispositivi dovevano essere forniti in tandem con un’altra azienda italiana specializzata nella programmazione di trojan e malware per spiare gli attivisti politici, la Hacking team. Le circostanze sono state rese pubbliche dopo la pubblicazione delle email della società sul portale di wikileaks in cui si possono leggere i centinaia di scambi tra le due aziende lombarde e grazie a cui si evincono anche le simpatie politiche del CEO di Hacking team, David Vincenzetti, che conclude gli scambi con i suoi collaboratori con un pittoresco “Boia chi molla”.

Nel 2017 in un’inchiesta della rete Al Jazeera di cui consigliamo la visione a chiunque voglia farsi un’idea su questo opaco mercato che sta divorando le libertà civili di tutto il mondo, il vice-presidente di Area spa, Marco Braccioli, viene ripreso da una telecamera nascosta durante uno scambio in cui si dice pronto a fornire un IMSI catcher al regime sud sudanese. Si tratta di un dispositivo grande come una valigia che consente di agganciare i telefoni cellulari di chiunque nel raggio di qualche decina di metri per poi poter attivare telecamera, microfono, tracciare il gps e persino inviare messaggi come se provenissero dai propri contatti. Nonostante l’embargo, Area spa assicura di potersi appoggiare su un paese terzo come la Tanzania per far arrivare la merce a destinazione. Dettaglio inquietante ma particolarmente rivelatore, nelle immagini Braccioli rassicura il suo interlocutore a proposito degli agganci che ha all’interno dell’apparato statale italiano che gli consentirebbero di snellire le procedure di esportazione.

Perché se Area fornisce i suoi servizi a regimi di tutto il mondo, i suoi principali clienti sono le forze di polizia italiane che usano le tecnologie di sorveglianza per spiare gli attivisti di casa nostra. Anche per questi affari interni, Area spa è finita nuovamente sotto inchiesta prima da parte della procura di Trieste poi di quella di Milano per accesso abusivo a sistema informatico. L’accusa è di aver scaricato sui pc dell’azienda sms, whatsapp, chiamate, intercettazioni e altri dati sensibili che dovrebbero invece essere di sola disponibilità degli inquirenti. Proprio le accuse di aver un proprio archivio privato frutto del lavoro di sorveglianza hanno portato il Consiglio di stato il 20 marzo del 2019 a concludere della legittimità dell’esclusione di Area spa dalle gare per l’aggiudicazione di appalti legati alle intercettazione per mancanza “di onorabilità, sicurezza e affidabilità“.

Mancanza di onorabilità che non ha impedito alla digos di Torino di avvalersi dei servizi di Area durante la pandemia quando, sfruttando un po vigliaccamente il fatto che i valsusini erano confinati a casa e non potevano difendere il proprio territorio, hanno deciso di affidare una ricca commessa all’azienda di Varese.

A vederlo dalla Val Susa, pare proprio che per tutti i governi i cittadini rimangono tali finché rigano dritto. Se osano mobilitarsi sono da trattare come un nemico interno da sorvegliare, infiltrare, molestare e incarcerare usando le stesse tecniche, le stesse tecnologie e addirittura gli stessi servizi forniti dalle medesime aziende.

Pandemia. Di tecno-assoluzionismo e di come la tecnologia non ci salverà

Pandemia. Di tecno-assoluzionismo e di come la tecnologia non ci salverà

In questi mesi abbiamo dovuto lavorare molto di più: sembra buffo, visto che eravamo a casa. Nel frattempo tante cose sono successe su internet e, con l’avvicinarsi di un “dopo” incerto, vorremmo dire la nostra sperando che queste riflessioni servano ad aprire una discussione. O almeno chiarire un poco alcune vicende fondamentali di queste lunghe giornate.

Se c’è qualcosa che l’hacking ci ha insegnato è che la tecnologia è un terreno di dominio e come tale va scardinato. Oggi la soluzione tecnica viene sbandierata come panacea, semplice, accessibile, ma è pura propaganda.

La tecnica asservita al potere economico e politico sembra avere il diritto di parlare di tutto, proponendo soluzioni che vanno dalla sanità, alla formazione, alla gestione dei flussi di persone, ma parla sempre da una posizione disincarnata, senza l’esperienza diretta delle problematiche e delle risorse fondamentali da preservare. Questo tipo di approccio alla tecnica è per noi tossico e l’hacking continuerà a voler sollevare queste contraddizioni con i suoi strumenti.

La premessa

Le istituzioni hanno scelto di avere fin da subito un atteggiamento paternalista, con l’obiettivo di scaricare il pesante impatto del virus sulla “popolazione indisciplinata” che non rispetta i dettami della quarantena. Come se la limitatissima capacità di intervento non fosse dovuta alle condizioni critiche della sanità pubblica, stremata da anni di tagli, aziendalizzazioni su base regionale, privatizzazioni, accorpamenti e scelte sbagliate.

Invece di assumersi le responsabilità di una strategia che ha privilegiato i grandi centri nevralgici ospedalieri (grandi centri che da soli sotto pressione non avrebbero retto) a discapito di una sanità diffusa sul territorio, nelle comunicazioni ufficiali abbiamo assistito sgomenti all’elezione quotidiana di nemici pubblici, inviduati in categorie finora impensabili: il runner, il genitore con passeggino, il ciclista.

Si sono lasciate sole le persone anziane nelle RSA o nelle loro case, incrociando le dita perché non si presentassero negli ospedali, nascoste sotto a un grande tappeto mentre il problema del contenimento del virus veniva trasformato, con atteggiamento ottuso e punitivo, nel contenimento/isolamento della popolazione.

In cima a tutto questo spesso si è preferito dar seguito alla volontà di confindustria e di molte aziende di tenere aperti i luoghi di lavoro a tutti i costi, senza procedure di protezione verificate ed efficaci, sviando l’attenzione grazie ad un’insostenibile retorica di guerra (il personale medico-sanitario come “eroi in prima linea”) a giustificazione dell’esistenza della carne da cannone in corsia e nelle fabbriche così come in trincea. Il costo del sacrificio è caduto sulle persone più vulnerabili.

Tecno-buzzword e Covid-19

La prassi sanitaria è stata opportunamente confusa con la norma legislativa, attivando spesso un completo nonsense. Si è operato uno spostamento del problema: dal contenimento del virus si è passati ad un sistema di infrazioni da sanzionare, traslando così l’attenzione su quest’ultimo (il runner come arma di distrazione di massa). Di nuovo, si prende un problema complesso e lo si riduce a uno collegato, ma più semplice, illudendosi e lasciando intendere che il secondo sia equivalente e risolva il primo. Si fa strada il sillogismo per cui contrastare il virus significa sorvegliare le persone che zuzzurellano in qua e in là. A questo si aggiunge la più classica politica delle buzzword (parole tecniche, usate spesso in modo improprio per impressionare/influenzare chi ascolta con termini “alla moda”). Ci troviamo di fronte a un proliferare di “tecno-buzzword”: buzzword che presentano strumenti tecnologici come panacea di tutti i mali. Questa è una forma di tecno-soluzionismo che non risolve realmente i problemi e apre a una serie di ulteriori contraddizioni e criticitá.

Tecno-buzzword 1: drone

Prendiamo un esempio: i droni. L’Enac ha dovuto effettuare una serie di concessioni sull’utilizzo di questi giocattolini, perché i sindaci italiani più “smart” avevano iniziato ad autorizzarne l’uso in autonomia. L’ente ministeriale ha dunque in fretta e furia liberato l’uso di droni nei controlli legati alle ordinanze covid, prima fino al 3 aprile, poi nella paranoia generalizzata dell’apocalittico weekend di pasquetta, l’ha rinnovata fino al 18 maggio.

L’utilizzo propagandistico, per quanto inquietante, di questi oggetti volanti è chiaro: l’autorizzazione prevede la presenza di chi pilota sul posto, non in remoto, e la guida a linea di vista; i droni possono solo segnalare la presenza di persone da controllare, il materiale video registrato deve essere rimosso dopo il controllo e le infrazioni contestate sul momento. I controlli con droni sono stati effettuati in luoghi semi deserti, fluviali o marittimi. A conti fatti sembra più un divertissement per non annoiarsi in quarantena, visto che praticamente un vigile con un binocolo da 20 euro avrebbe avuto lo stesso effetto. Il salto di qualità avverrebbe con la guida da remoto e la registrazione ed elaborazione automatica delle immagini. Ricordiamocelo bene e non lasciamoci distrarre quando inevitabilmente qualcuno cercherà di far passare inosservato qualche “temporaneo aggiustamento alla normativa”, magari per far fronte ad un’altra “emergenza”. Attualmente però i droni funzionano solo da generico spauracchio, utile a terrorizzare le persone, o da spot per sindaci sceriffi col pallino dell’innovazione in cerca di visibilità e consenso.

Tecno-buzzword 2: app di tracciamento contatti

Altro esempio: la app per tracciare i contatti.

Non ci sembra interessante disquisire se il tracciamento avvenga con la collaborazione degli operatori telefonici, o come sembra essere stato scelto, con il bluetooth e le app sviluppate da google ed apple. La pre-condizione per questa fantomatica fase due è il ripristino di una sanità pubblica di prossimità, colpevomente smantellata da scelte di governo bipartisan e risorsa imprescindibile per contenere la pandemia. Servono assunzioni, formazione, presìdi medici diffusi sui territori, capacità di analisi: eppure non se ne sente parlare. Se non ci sono abbastanza laboratori d’analisi per fare un tampone a una persona con la polmonite, se non c’è nessuna persona in grado di andarglielo a fare a casa, se non ci si prende cura delle persone capillarmente, a poco serviranno uno smartphone e una app. Al massimo una app segnerebbe un numeretto, ma a leggere quel numeretto poi chi ci sarebbe? Più chiaramente: è come costruire una casa a partire dalla porta, rifinirla di tutto punto con gli intarsi e lo spioncino a fotocamera, e poi chiamare tutti e dire: “Ecco qui: la porta è fatta secondo standard europei, è molto innovativa e rispettosissima della vostra privacy”. È normale che poi ti si chieda: “Ok, ma c’è solo la porta. La casa dov’è?” La app trasla ancora il problema da una cosa difficile a una facile: in due settimane la app la fai. Poi, tossendo, la apri sul cellulare e scopri che non ha proprietà curative.

Affrontare il discorso in termini di privacy e di tecnologie, è esattamente il terreno su cui ci vogliono portare, per attuare il giochino dello spostamento del problema e puntarci contro un’altra ennesima grande arma di distrazione di massa.

Non ci sono dubbi: preservare l’intimità digitale e la privacy è uno dei campi di lotta di quest’epoca, il problema del controllo è connaturato al sistema in cui viviamo e la raccolta massiva di dati è uno degli elementi fondamentali su cui si basano abusi e repressione. Immediatamente però, alle attuali condizioni e per contrastare la diffusione del virus qui e ora, un’app è semplicemente inutile e chi utilizza le buzzword app o innovazione sta colpevolmente contribuendo a sviare l’attenzione da quelle che sono le reali problematiche e a deresponsabilizzare chi ha realmente causato questa catastrofe sanitaria.

Tecno-buzzword 3: DAD – didattica a distanza

La didattica, nell’impossibilità di utilizzare piattaforme pubbliche, si è frastagliata in mille rivoli e strumenti, pesando sulla buona volontà, intraprendenza e connessione del corpo docente che, lasciato alla propria iniziativa individuale, si getta a spegnere l’incendio che divampa grazie al vuoto sociale. Navigando tra un google, zoom, teams, whatsapp, skype, facebook, youtube, nella consapevolezza che l’esperienza didattica non sia riducibile esclusivamente all’erogazione di contenuti.

Al netto di tutti i ragionamenti vi è la (banale?) constatazione che la didattica a distanza non può essere sostitutiva e considerata equivalente della didattica in presenza, sopratutto per la fascia di età 6-18 e che il motivo per cui è stata imposta sono le carenze strutturali delle scuole che, disorganizzate e sovraffollate, non permettono la didattica in aula opportunamente distanziati.

Quindi si torna di nuovo alla questione principale: i problemi materiali si spostano nel digitale, ma il digitale non può risolverli.

La scuola, nel vuoto del pensiero e delle risorse strategiche, è stata di fatto consegnata in toto alle grosse piattaforme commerciali. Ancora una volta, il meccanismo è il solito: di fronte a una scuola trasformata in azienda, svilita, dove mancano i soldi anche per il sapone, che andrebbe ripensata e riorganizzata con affetto, ci si affida al presunto potere taumaturgico della tecnologia. Non si può pensare che questa scelta non avrà ripercussioni sul futuro. Né si può pensare che sia una scelta ovvia ed automatica, con buona pace di tutti i discorsi sul free software nella pubblica amministrazione, che si fanno da praticamente 20 anni.

Salvo poi scoprire che la tecnologia non è così accessibile, ma è invece ulteriore fonte di diseguaglianza sociale. Perchè possiamo fare finta che non sia vero che molte persone facciano teledidattica con i giga del proprio cellulare, che il territorio italiano sia fatto di paesini sperduti e nient’affatto connessi, che sfavillanti e velocissimi computer non siano affatto in ogni casa, però, per l’appunto, stiamo facendo finta.

Quella che era già una tendenza problematica (una scuola fatta di didattica frontale e di valutazioni basate sulla quantificazione) rischia ora di diventare la norma perché “siamo in emergenza”. L’emergenza di oggi porta al pettine i nodi problematici della società che abitiamo. Lo stato di crisi è strutturale e rende evidenti vulnerabilità preesistenti che non si possono risolvere normando l’emergenza ma solo in un processo di profondo cambiamento.

Una tecno-buzzword non ci salverá

Amiamo gli enigmi e non ci spaventano le complessità dei problemi. Quello che temiamo sono le false piste e gli specchietti per le allodole. Ciò che stiamo vedendo, e subendo, in questi giorni, non è altro che l’esasperata manifestazione di una serie di nodi che vengono al pettine e nessuna bacchetta magica smart basterà a scioglierli.

Quando la politica parla di tecnologia, spesso lo fa per sviare l’attenzione dalle ingiustizie e problematiche sociali a cui ci chiede di rassegnarci. Consapevoli che ogni piccolo spazio di libertà sacrificato non verrà restituito ma dovrà essere duramente riconquistato, quando la parola chiave è “emergenza” è ancora piu’ importante svelare i meccanismi nascosti e leggere oltre la propaganda.

Dobbiamo mantenere la concentrazione, scrollarci di dosso il ruolo di gregge e ritrovare quello di comunità pensante, ricordarci ogni buzzword che è stata utilizzata sulla nostra pelle, scartarla e continuare a guardare dritto davanti, al cuore del problema.

  • Av.A.Na. Avvisi Ai Naviganti – Roma
  • Ifdo Hacklab – Firenze
  • HacklabBo – Bologna
  • underscore _TO* hacklab – Torino
  • Unit hacklab – Milano
  • Associazione Culturale “Verde Binario” – Cosenza
  • Freaknet Medialab Poetry Hacklab – Palazzolo Acreide (Siracusa)
  • MSAck Hacklab – Napoli
  • Fablab Buridda – Genova
  • e altre individualità hacker e cyberpunk

Di trojan di stato – details

questo scritto è lungo, confuso e denso di appunti, link e domande, se avete il caffè sul fuoco, toglietelo. è stato un lavoro sudato, speriamo vi piaccia.

parliamo di captatori informatici, sicurezza offensiva e il tentativo di normare questi trojan di stato.

per iniziare

siccome ci piace toccare con mano gli oggetti dei nostri ragionamenti, ci siamo procurati uno di questi “captatori informatici” e ne abbiamo documentato il setup completo per chi volesse sporcarsi le mani con noi (grazie al lab61 per averci messo la pulce nell’orecchio).

successivamente abbiamo infettato volontariamente un dispositivo con il malware per vederne il funzionamento da vicino, quali funzionalità presenta e quali difetti.

in ultimo, dal momento che nel tentativo di normare questi pericolosi strumenti leggiamo della “necessità di forti garanzie per essere inattacabile sul piano della veridicità dei dati acquisiti“, abbiamo provato a generare delle prove non valide per capire quanto sono affidabili questi malware (non contenti l’abbiamo fatto in due modi diversi).

la conclusione a cui siamo arrivati è che no, non esiste modo di garantire tecnicamente che le prove raccolte siano veritiere.

abbiamo anche fatto un’analisi tecnica della proposta di legge sottolineandone le criticità qui.

(legenda: le parti a sfondo bianco come questa sono per tutti i lettori,
quelle a sfondo nero sono più tecniche e interessanti per qualcuno, noiose per qualcun altro, vi assicuriamo che saltarle non pregiudicherà la lettura).

installare galileo

un piccolo disclaimer: vi potete fare male, noi non abbiamo mai fatto uscire nessuna delle installazioni su internet liberamente, suggeriamo di fare lo stesso.
siamo partiti da questo link, un tutorial per il setup, modificando alcuni passaggi.
in particolare abbiamo eliminato vari check della licenza per cui non è più necessario cambiare la data del sistema (molto scomodo su una macchina virtuale) ed è ora quindi possibile abilitare tutte le funzionalità.

il setup minimo necessita almeno di 4 macchine:

  • un master (windows 7, almeno 4Gb di ram)
  • un collector (windows 7, almeno 1Gb di ram)
  • un anonymizer (suggerito centos solo cli, anche solo 300mb di ram, io ho usato un container con alpine via runc)
  • un target (fate voi, una debian, un android, un mac)

se volete strafare, servirá anche una macchina che faccia da network tactical injector, cioè l’oggetto usato per infettare le vittime attraverso attacchi wifi.

le prime due voci le abbiamo installate in macchine virtuali su un portatile con 8Gb di ram usando virtualbox, ma se avete delle macchine da sacrificare è uguale.

per iniziare guardiamo uno schema di come funziona l’architettura:

schemarcs

ora decidiamo gli ip statici per ogni macchina:

master: 192.168.56.2
collector: 192.168.56.3
anonymizer: 192.168.56.4

master

  1. installo Windows 7 su una VM e imposto come ip dell’interfaccia 192.168.56.2
  2. installo rcs-setup-2015032102.exe
  3. installo rcs-exploits-2015032101.exe
  4. seleziono Master Node
  5. in CN metto 192.168.56.2:
    questo ip verra’ usato anche come CN del certificato https, potevo anche usare un nome ma poi toccava editare /etc/hosts di windows
  6. metto la password con cui controllerò tutto: RCSMaster1
  7. metto la licenza e a questo punto parte l’installazione.
  8. quando vedo “Remove previous master node files” sostituisco questo file in C:\RCS\bin\
  9. siccome ad ogni avvio ricontrolla la licenza, finita l’installazione devo sostituire anche questo file in C:\RCS\DB\lib\
  10. ora installo anche Adobe Air e la console
  11. a questo punto riavvio la macchina o i servizi e apro la console
  12. inserisco la loro CA come trusted dentro l’albero delle root CA

    root1
    root2
    root3
    root4

  13. inserisco le credenziali, vado dentro monitor e passo ad installare il collector

collector

  1. come sopra ma scelgo Collector invece di Master Node
  2. imposto l’ip come scelto in precedenza per il collector, quindi 192.168.56.3
  3. il common name del master richiesto sará quindi 192.168.56.2
  4. torno sul master

master #2

  1. dentro System della console dovrebbe a questo punto comparire un collector
  2. faccio un nuovo anonymizer a cui assegno come ip 192.168.56.4
  3. collego l’anonymizer al collettore
    anon
    anon
    anon

  4. creo il pacchetto per l’anonymizer premendo Download installer

anonymizer

  1. preparo una macchina per installare l’anonymizer (consigliano una centos)
  2. io ho usato un container (runc) a cui ho dato come ip 192.168.56.4
  3. prendo lo .zip creato sopra e installo l’anonymizer (bbproxy, lo mette dentro /opt)
  4. quando tutto funziona, in System della console vediamo questo:

a questo punto siamo pronti per studiare, ecco i manuali di riferimento:

  1. RCS_9.6_Admin_1.7_IT.pdf
  2. RCS_9.6-Analyst_1.9_IT.pdf
  3. RCS_9.6_SysAdmin_1.9_IT.pdf
  4. RCS_9.6_Technician_2.0_IT.pdf

usare un captatore informatico

dopo aver installato e letto i manuali d’uso di RCS, abbiamo voluto provare effettivamente cosa è in grado di fare questo captatore informatico.

abbiamo quindi volontariamente infettato una nostra macchina linux e testato il funzionamento del tutto.

per prima cosa apriamo un’indagine (Operations->New Operation) a cui aggiungiamo un indagato sul cui ipotetico computer d’ufficio vogliamo installare un agente:

newoperation newtarget newagent

l’agente

ora con una facile interfaccia punta e clicca possiamo selezionare le funzionalità del trojan da attivare

agentconfig

se invece vogliamo una configurazione particolare, come ad esempio limitare l’uso della batteria dell’agente
possiamo utilizzare la modalità avanzata:

agentconfig2 agentconfigbattery agentconfigac agentconfig2

qui sopra un esempio di come è possibile attivare determinati moduli solamente quando il dispositivo è in carica.
per completezza ecco l’elenco dei possibili eventi, delle possibili azioni e di tutti i moduli.
se volete studiare tutte le funzionalità, rimandiamo alla documentazione ufficiale.
ovviamente non tutte le funzionalità sono compatibili con tutti i sistemi operativi, per avere una lista delle compatibilità vi rimandiamo anche in questo caso alla documentazione ufficiale e a quella non ufficiale.

quando la configurazione ci soddisfa, procediamo con la creazione del vero e proprio agente premendo in alto a sinistra su Build.
ora manca solo di scegliere come infettare la vittima:

build vector

i vettori

i vettori di infezione sono tanti, anche in questo caso la documentazione ufficiale ci viene in aiuto.
la scelta del vettore da usare dipende in gran parte dalla vicinanza del dispositivo da infettare:

accesso fisico

avendo accesso fisico al dispositivo (ad esempio in aereoporto, durante un controllo o una perquisizione) è possibile installare il malware via:

  • Silent Installer: un programma da eseguire direttamente sul dispositivo della vittima
  • Offline Installation: avvio del dispositivo da una pennetta usb
  • U3 Installation: usa una chiave U3 per installare l’agente
  • Persistent Installation: installa l’agente in maniera permanente (resistente ad una formattazione di windows o un factory reset di android)

vicinanza spaziale

se è possibile avvicinare la vittima (facendo ad esempio un appostamento fuori dall’abitazione) è possibile introdursi nella sua rete wireless o emularla attraverso una serie di attacchi usando quello che viene chiamato il Tactical Network Injector.

negli altri casi

  • lo stesso strumento, chiamato in questo caso Network Injector, può venire utilizzato installandolo direttamente
    dal provider/ISP (tim, wind, vodafone, ecc) dove attraverso dei filtri è possibile specificare chi infettare.
  • inviando un’allegato (pdf, doc) via mail contenente uno zero-day.

noi purtroppo non abbiamo la possibilità di provare direttamente da un ISP l’installazione del Network Injector e avendo accesso fisico al dispositivo del fittizio indagato, ci infettiamo volontariamente con un Silent Installer per linux.

l’infezione

agentinfection

pubblichiamo l’agente venuto fuori dalla build per chi volesse sporcarsi le mani, SE NON SAPETE COSA STATE FACENDO, NON FATELO, SUL SERIO

NON SCARICARMI SE NON DEVI.zip

ovviamente non ci sarebbe bisogno di fare reverse engineering visto che abbiamo i sorgenti, ma siccome se non vediamo non crediamo, lo faremo ugualmente, non prima di vederlo in azione però.
se avete linux e avete paura di essere infetti da un paio d’anni e non potete aspettare, date un’occhio dentro ~/.config/autostart/.*, /var/crash/.report* e /var/tmp/.report* ma non sperate di trovare qualcosa perchè nelle licenze italiane le funzionalità per infettare linux non sono state comprate.
ps. abbiamo ascoltato il traffico con wireshark ma sembra che non cerchi di andare altrove.

abbiamo le prove

attendiamo 5 minuti che l’agente raccolga i dati e ce li invii ed ecco i primi risultati in una comoda dashboard:

dashboard

vediamo ora una carrellata delle possibilità, possiamo navigare il file system della vittima

fs

possiamo inserire file, eseguirli e ovviamente scaricarli

updown
files

possiamo inviare comandi e riceverne i risultati

commands

e poi ovviamente guardare tutte le prove, quindi screenshoot (con supporto OCR)

screenshoot screenshoot

un simpatico keylogger e tutti gli eventi del mouse

keylogger

le foto dalla webcam con la frequenza scelta

camera

la lista dei siti visitati

www

le password salvate da firefox e chrome

password

ovviamente con la possibilità di filtrare il materiale con filtri di tutto rispetto

filtri

ci fermiamo qui anche se ci sarebbero tanti altri moduli da provare, i messaggi, i contatti, i wallet bitcoin, l’infezione di un’android, il network tactical injector, gli exploits….

rompere un captatore informatico

ok, l’abbiamo installato e provato per poterlo analizzare meglio
e farci la seguente domanda: ma quanto sono sicuri questi captatori informatici?
sono veramente dei generatori di prove affidabili e veritiere come si vorrebbe sostenere?

come raccolgono le prove? proviamo ad immaginare come potremmo fare noi, prendendo a titolo di esempio i contatti skype:
i contatti skype sono presenti nel computer dentro un file
contentente una base dati.
questa base dati non è protetta in nessun modo, ed è direttamente accessibile da chiunque, sia da Skype che da un qualsiasi altro programma e ovviamente anche dai captatori informatici, che vanno a cercare dentro quella base dati la lista dei contatti e la nostra messaggistica.
dove si trova di preciso? la base dati di skype su linux si trova dentro ~/.Skype/<profiloutente>/main.db

proviamo allora a creare da noi questa base dati senza neanche avere skype installato sul computer e inserire dei contatti fittizi al suo interno. funzionerà?

falsi contatti

la base dati in questione è un sqlite, il cui schema è reperibile pubblicamente.
creiamo quindi dentro la macchina della vittima una directory per ospitare il nostro finto profilo skype al cui interno inseriamo il nostro db sqlite compatibile con lo schema skype:

mkdir -p ~/.Skype/fakeprofile/
sqlite3 ~/.Skype/fakeprofile/main.db

# creo i db 'Accounts' e 'Contacts'
# https://github.com/suurjaak/Skyperious/blob/master/skyperious/skypedata.py#L128

# creo un account
INSERT INTO Accounts (skypename, fullname, is_permanent) VALUES ('account falso', 'account falso', 1);

# inserisco dei contatti a piacimento
INSERT INTO Contacts (skypename, displayname, birthday, is_permanent) VALUES("contatto falso", "contatto falso",0,1);
.quit

a questo punto attendiamo che il captatore raccolga le nuove prove e ….

fake_contact
fake_contact2

per i siti visitati attraverso chrome/firefox e altri browser vale lo stesso discorso, perchè questi vengono salvati all’interno di una base dati simile a quella usata da skype.

anche per il microfono, la webcam, gli screenshoot del monitor e in generale per ogni tipo di dato acquisito, non solo è difficile se non impossibile dire con certezza se i dati carpiti all’insaputa dell’utente siano veritieri o meno, ma è anche relativamente semplice falsificare questi dati da parte di terzi (pensiamo ad un’applicazione su android ad esempio).

è possibile evitarlo? no.

rompere un captatore informatico #2

ma quanto sono sicuri questi captatori informatici?
nel proseguire il nostro studio sull’argomento, vogliamo sottolineare una questione secondo noi importante. non divulgare le falle di sicurezza dei nostri dispositivi per avere la possibilità di poterli infettare mantiene inevitabilmente meno sicuri i dispositivi di tutti, compresi quelli di chi i captatori informatici li utilizza.

abbiamo visto come sia possibile falsificare le prove prima che vengano raccolte, cerchiamo ora di capire come funziona l’invio dei dati raccolti in RCS e vediamo se è possibile inviare delle prove create ad-hoc.

reverse engeenering

ed eccoci alla parte più interessante del nostro studio (nonchè la più divertente).
la descrizione del reverse engeenering che segue è molto piu’ lineare di come si è svolta nella realtà, abbiamo saltato le parti noiose e ripetitive (openssl l’abbiamo ricompilato almeno 6 volte) e cercato inoltre di rendere i ragionamenti sequenziali, quando nella realtà tante scelte sono state fatte intuitivamente.
siamo inoltre convinti che si poteva ottenere lo stesso risultato in altri N modi e che
quello da noi usato è sicuramente molto grezzo.

innanzitutto, ipotizziamo di avere solo il binario, il malware.
dobbiamo capire cosa fa e come si comporta. creiamo quindi un ambiente di studio, un container che lo isoli in un posto sicuro dove non puo’ fare danni e in cui è possibile studiarne il comportamento.

noi abbiamo usato runc usando come rootfs una debian
dentro una directory montata con loggedfs per controllare tutti i suoi movimenti sul file system (file creati, letti, etc…).
vediamo subito che si installa dentro /var/crash/.report*/whoopsie-report
e cerchiamo di capire di che file si tratta con un:

$ file whoopsie-report
whoopsie-report: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped`

è un piccolo file statico di 77kb, un po’ troppo piccolo per essere veramente statico,
lo avviamo con strace ./whoopsie-report e notiamo infatti che cerca di aprire parecchie librerie di sistema, tra cui:

  • /lib/x86_64-linux-gnu/libpthread.so.0
  • /lib/x86_64-linux-gnu/libc.so.6
  • /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
  • /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
  • /usr/lib/x86_64-linux-gnu/libX11.so.6

e qui gia’ ci sarebbe spazio per divertirsi: libX11 viene sicuramente utilizzata per fare gli screenshot dello schermo, sarebbe possibile ricompilarla per fare in modo che per alcuni programmi dei metodi tornino cose inaspettate.

ad un certo punto notiamo che vengono creati dei files dentro /var/crash/.report*/.tmp*, sono presumibilmente le prove raccolte, anche perchè ciclicamente si moltiplicano.

all’interno solo dati binari, controlliamo se sono solamente compressi, ma non ci sembra, saranno cifrati? ma come? per una cosa del genere a noi verrebbe da utilizzare le librerie standard, quindi openssl, ma come possiamo esserne sicuri?
in effetti il malware accede a libssl.
perdiamo un po’ di tempo provando con gdb ma stufi di seguire tutti i thread, ci viene in mente di ricompilare libssl inserendo del debug che ci mostri come vengono cifrati i dati.

per ricompilare un pacchetto debian seguiamo questa guida, ci armiamo di pazienza e scarichiamo il tutto.
cercando come si cifra con openssl vediamo che ci sono parecchie chiamate differenti, quindi proviamo con ltrace (con strace si vedono le syscall, con ltrace le libcall) a vedere se possiamo capire quale chiamata viene usata:

 $ ltrace ./whoopsie-report
 Couldn't find .dynsym or .dynstr in "/proc/30234/exe"

questo e’ parecchio strano ma smanettando un po’ troviamo con strings la seguente stringa dentro il malware:

$ strings ./whoopsie-report
$Info: This file is packed with the UPX executable packer http://upx.sf.net $

leggiamo che upx è un packer che comprime binari, installiamo quindi upx-ucl e proviamo un upx-ucl -d whoopsie-report per fare il processo inverso e decomprimere il binario:

         File size         Ratio      Format      Name
    --------------------   ------   -----------   -----------
     261044 <-     77972   29.87%  linux/ElfAMD   whoopsie-report

ora abbiamo il binario “in chiaro” e riprovando con ltrace (qui siamo passati dentro una macchina virtuale con VirtualBox perchè dentro runc si bloccava per qualche motivo) otteniamo le chiamate usate dal malware, in particolare nel nostro interesse ricadono le seguenti:

  • dlsym(0x122f4c0, "EVP_get_cipherbyname")
  • dlsym(0x122f4c0, "BIO_set_cipher")

a questo punto cerchiamo quei metodi nei sorgenti di libssl e troviamo la prima chiamata in crypto/evp/names.c linea 112 a cui aggiungiamo questo debug che scrive il cifrario usato dentro un file

const EVP_CIPHER *EVP_get_cipherbyname(const char *name)
{
  const EVP_CIPHER *cp;

  // DEBUG: scrivo il cifrario utilizzato dentro un file
  FILE *f;
  f = fopen("/tmp/debug_ciphername", "w"); // <- qui trovo il cifrario
  fprintf(f, "%s", name);
  fclose(f);

  cp = (const EVP_CIPHER *)OBJ_NAME_get(name, OBJ_NAME_TYPE_CIPHER_METH);
  return (cp);
}

e la seconda chiamata in crypto/evp/bio_enc.c e anche qui aggiungiamo del debug:

void BIO_set_cipher(BIO *b, const EVP_CIPHER *c, const unsigned char *k,
               const unsigned char *i, int e)
{
  BIO_ENC_CTX *ctx;

  // DEBUG: scrivo i parametri del cifrario su file
  FILE *f;
  f = fopen("/tmp/debug_cipher", "a+");
  fprintf(f, "\n----\n");
  fprintf(f, "block_size: %d, key_len: %d, iv_len: %d\nkey: ", c->block_size, c->key_len, c->iv_len);
  for(int co=0; co<c->key_len; co++)
  {
    fprintf(f, "%02X",k[co]);
  }
  fprintf(f,"\n\niv: ");
  for(int co=0; co<c->iv_len; co++) {
    fprintf(f, "%02X", i[co]);
  }
  fprintf(f,"\n\n");
  fclose(f);
  ....

ricompiliamo le librerie, installiamo e rilanciamo il malware.
dentro /tmp troviamo ora il cifrario usato dal malware e la chiave:

$ cat /tmp/debug_ciphername 
aes-128-cbc
$ cat /tmp/debug_cipher
----
block_size: 16, key_len: 16, iv_len: 16
key: 692CC9D0DC834E4663EF389470E445B4
iv: 00000000000000000000000000000000

(= a questo punto proviamo a decifrare i file salvati su disco dal malware, lo scopo è ovviamente tentare di scriverne noi uno ad-hoc, con la chiave a disposizione dovrebbe essere facile, invece perdiamo un sacco di tempo a capire come mai non riusciamo a decifrare la prima parte del file.
pensavamo fosse legato al vettore di inizializzazione e invece nel file c’e’ un header di qualche tipo, ovvero il blocco cifrato non comincia all’inizio (questo però ovviamente openssl non lo dice).
il punto è che la lunghezza del testo cifrato ogni tanto non è un multiplo del BLOCK_SIZE del cifrario a blocchi usato, il che significa che c’è qualcosa che non dovrebbe esserci.
abbiamo provato prima manualmente ad eliminare un po’ di bytes prima di tentare il decrypt ed effettivamente ha funzionato:

#!/usr/bin/python
from Crypto.Cipher import AES
import sys

key = "692cc9d0dc834e4663ef389470e445b4"
IV =  "00000000000000000000000000000000"
encrypted = open(sys.argv[1]).read()
x = 16 - len(encrypted)%16 if len(encrypted)%16 else 0
x += 16*int(sys.argv[2])
encrypted = encrypted[x:]
aes = AES.new(key.decode('hex'), AES.MODE_CBC, IV.decode('hex'))
print aes.decrypt(encrypted)


$ chmod +x test.py
$ ./test.py .tmp-1491179387-220638-SJBo7P 10 > image.jpg

il file in questione (il .tmp-149..) è stato selezionato perchè dalle dimensioni poteva sembrare un’immagine, inoltre decifrandolo inizialmente c’erano stringhe che riconducevano al formato JPG (ma non trovavamo il magic byte DD F8!).
quel 10 invece indica che prima dell’inizio dell’immagine all’interno del file salvato su disco, ci sono ben 160 bytes di header.
il prossimo passo è cercare di scrivere noi l’immagine dentro uno dei file, quindi apriamo con gimp l’immagine estratta in precedenza (quindi con il vero screenshot) in modo da mantenerne le proprietà (colori, dimensioni, ecc.) e sostituirla dentro il file di cui sopra.

#!/usr/bin/python
from Crypto.Cipher import AES
import sys

key = "692cc9d0dc834e4663ef389470e445b4"
IV =  "00000000000000000000000000000000"
original_header = open(sys.argv[1]).read()[:168]
new_image = open('.tmp-1491179387-220638-SJBo7P','w')

# mantengo l'header come era prima senza indagare oltre
new_image.write(original_header)
fake_image = open(sys.argv[2]).read()

# padding
x = 16 - len(fake_image)%16 if len(fake_image)%16 else 0
fake_image += x*"\0"

# cifro l'immagine fake e la scrivo sul nuovo file
aes = AES.new(key.decode('hex'), AES.MODE_CBC, IV.decode('hex'))
new_image.write(aes.encrypt(fake_image))
new_image.close()

ora basta solo aspettare e….

fake_screenshot1
fake_screenshot2

Underscore _TO* Hacklab // underscore chiocciola autistici.org
Key fingerprint = 5DAC 477D 5441 B7A1 5ACB F680 BBEB 4DD3 9AC6 CCA9
gpg2 –recv-keys 0x9AC6CCA9
https://autistici.org/underscore

Di trojan di stato

questo scritto è lungo, confuso e denso di appunti, link e domande, se avete il caffè sul fuoco, toglietelo. è stato un lavoro sudato, speriamo vi piaccia.

parliamo di captatori informatici, sicurezza offensiva e il tentativo di normare
questi trojan di stato.

per iniziare

siccome ci piace toccare con mano gli oggetti dei nostri ragionamenti, ci siamo procurati uno di questi “captatori informatici” e ne abbiamo documentato il setup per chi volesse sporcarsi le mani con noi.

successivamente abbiamo volontariamente infettato un dispositivo con il malware per vederne il funzionamento da vicino, quali funzionalità presenta e quali difetti.

in ultimo, dal momento che nel tentativo di normare questi pericolosi strumenti leggiamo della “necessità di forti garanzie per essere inattacabile sul piano della veridicità dei dati acquisiti“, abbiamo provato a generare delle prove non valide per capire quanto sono affidabili questi captatori.

la conclusione a cui siamo giunti è che non esiste modo di garantire tecnicamente che le prove raccolte siano veritiere.

abbiamo documentato tutto in questo dettagliato post,
qui invece ci proponiamo di fare un’analisi alle proposte di normare questi captatori informatici.

mi sono entrati nel computer

la concreta minaccia dell’abuso di questo potente strumento ci muove a far luce su questa fumosaquestione.

non siamo giuristi ma ci sembra che i captatori informatici siano già normati, il reato lo conosciamo bene noi acari, il 615-ter c.p. “accesso abusivo ad un sistema informatico” che presenta anche un comma specifico se il reato è commesso da un pubblico ufficiale.
il fatto che questi strumenti siano, però, quotidianamente usati dalle forze di polizia come strumento di indagine e che nessuno stia storcendo il naso per questo, è la dimostrazione di come la legge sia un’ottimo strumento repressivo ma non funzioni un granchè come strumento di giustizia sociale. quale procura potrebbe indagare sui suoi stessi strumenti di indagine?

quello che ci proponiamo di fare per il futuro è cercare di evitare che i nostri (e i vostri) dispositivi ci spiino.
vogliamo inoltre diffondere delle buone pratiche di sicurezza per evitare di farsi infettare da questi e altri trojan: avremo sicuramente bisogno di aiuto perchè sappiamo che non sarà affatto semplice.

regolamentare carri armati: ddl captatori

come si giustifica l’uso di un carro armato? basta parlare di terrorismo, di pedofilia?
è sufficiente parlare male di un parlamentare? o magari opporsi alla costruzione di una
grande opera? non ci sentiamo per niente tutelati dal decreto di legge presentato dai
civici e innovatori (ddl quintarelli) dalla quale emergono moltissime criticità;
ci siamo soffermati sulla “disciplinare tecnico operativa

la tesi di fondo del documento è quella di fare un paragone tra le funzionalità del captatore e le corrispondenti azioni di polizia giudiziaria già attualmente normate, per esempio paragonando pedinamento reale e intercettazione dati di posizionamento, o sequestro reale con acquisizionefile da dispositivo.

l’equiparazione tra le modalità classiche e quelle implementate dal captatore ci sembra assurdo da ogni punto di vista e per qualunque tipologia di azione giudiziaria considerata:

  • paragonare un sequestro all’acquisizione remota di file sul dispositivo è ridicolo. durante un sequestro c’è la presenza dell’indagato che può verificare quello che accade, può richiedere la presenza di un legale e gli viene rilasciata una lista del materiale sequestrato. non riusciamo ad immaginarci come questo sia possibile tramite un sequestro da remoto tramite captatore.

  • il sequestro reale è teso a togliere la disponibilità di un oggetto, una pistola ad esempio.
    il captatore non toglie la disponibilità dell’oggetto del sequestro, perchè non è quello il suo scopo.

  • paragonare il tracciamento gps ad un pedinamento è ridicolo.
    avere i dati digitalizzati e facilmente analizzabili da algoritmi invasivi non è paragonabile ad un pedinamento, la qualità del dato è proprio di un altro livello.

  • ma soprattutto c’è una questione quantitativa e di costi: fare un pedinamento dalle scrivanie della questura verso 1000 persone non ha lo stesso costo che farlo per davvero, è evidente che se fino a ieri pedinare gli indagati richiedeva un certo dispiegamento di forze e denaro, con l’utilizzo di un captatore il tutto si riduce a premere qualche tasto su un’interfaccia punta e clicca. la conseguenza di questo è abbastanza ovvia. immaginare l’equivalenza delle due situazioni è ridicolo.

  • si parte poi dal presupposto che un dispositivo sia di un indagato, mentre non è sempre vero.
    prendiamo come esempio tutti i dispositivi “pubblici”, gli internet point, le biblioteche, le università. leggendo le mail da un internet point usato da un indagato
    prima di noi (e quindi su un computer infetto) le stesse finirebbero in questura. comprando un dispositivo usato, le nostre mail finirebbero in questura.

  • c’è inoltre un problema temporale. all’avvio di un’intercettazione telefonica classica, gli sms intercettati partono appunto da un giorno e l’intercettazione ha poi un limite di tempo per ovvi motivi. il trojan invece può leggere i dati senza limiti temporali, inviando tutte le conversazioni avvenute sul tuo dispositivo dall’inizio dei tempi (perchè sono tutte salvate lì).

  • durante un pedinamento c’è la garanzia (a meno di assumere un sosia?) che la posizione sia quella effettiva dell’indagato. il dispositivo invece potrebbe non viaggiare con l’indagato, potrebbe essere stato rubato o potrebbe essere stato lasciato sul sedile di un taxi. insomma il dispositivo dell’indagato non è l’indagato.

  • credere, come si legge nel documento, che l’installazione di un captatore non abbassi il livello di sicurezza dei dispositivi su cui è installato è ridicolo, l’idea del captatore si basa proprio sul fatto di lasciare aperte delle falle di sicurezza e quindi di mantenere appositamente insicuri i dispositivi di tutti, per avere la possibilità di poterli infettare.

  • certificare la non modificabilità delle prove acquisite ci sembra impossibile da ottenere e l’abbiamo provato in due modi diversi. inoltre come è possibile certificare che il produttore non sia stato compromesso? come è possibile certificare che nella imponente architettura non ci sia una backdoor? no, non è possibile farlo.

  • e ancora, ci sembra paradossale che lo stato utilizzi armi digitali acquistate su un mercato opaco e poco trasparente come quello degli zero day.

compiti a casa

durante gli esperimenti abbiamo notato che gli input di questi oggetti vengono considerati trusted (cioè non modificabili dall’utente), cosa ovviamente non vera. cosa succede se un contatto skype si chiama AAAA’ DROP ALL TABLES–? e se è lungo 10mila caratteri? e se al posto di un’immagine mettiamo qualcosa di altro e il captatore si rompe? (si, si rompe male).
come la legge vedrebbe un comportamento simile? legittima difesa? occultamento di prove?

cosa vogliamo

per noi questi oggetti non sono normabili. per noi c’è un pericolo insito nell’azione segreta di una parte dell’apparato dello stato sul cittadino e questo pericolo sovrasta ogni altro pericolo.
punto.

vogliamo sapere non solo le statistiche di esportazione di questi strumenti (come richiesto di recente dal centro hermes al ministero dello sviluppo economico), ma soprattutto come e quanto vengono utilizzate in italia oggi queste tecnologie di sorveglianza, che si chiamino imsi catcher o trojan di stato. se qualcuno vuole comunicarcelo, ci scriva una mail.

Underscore _TO* Hacklab // underscore chiocciola autistici.org
Key fingerprint = 5DAC 477D 5441 B7A1 5ACB F680 BBEB 4DD3 9AC6 CCA9
gpg2 –recv-keys 0x9AC6CCA9

Ancora Warmup Hackmeeting 0x14

Vi invitiamo questo sabato 25 febbraio dalle 16 al Salone Polivalente di Bussoleno per un evento preparatorio ad Hackmeeting 0x14 (che ricordiamo quest’anno si terrá qui vicino in Val Susa, in particolare a Venaus, dal 15 al 18 giugno).

Ci sará il collettivo Ippolita che parlerá di social network e tecnologie del dominio, a seguire un avvocato fará una panoramica sull’utilizzo dei captatori informatici, mentre noi come _TO hacklab mostreremo nella pratica l’utilizzo di un captatore informatico.

A seguire domande, chiacchiere e condivisione di idee in preparazione di Hackmeeting.

locandina
Vi aspettiamo

Open Hacklab

Volevamo un hacklab più aperto, ma non in questo senso.
perquisa-agosto

 

Durante la perquisizione al CSOA Gabrio di ieri le divise blu hanno deciso di accanirsi anche contro _TO*hacklab, tentando di forzare la porta blindata per poi distruggere il muro a fianco, entrare e constatare che quello spazio era un’officina per computer come effettivamente poteva sembrare dalla breccia nella finestra.

Per giustificare l’impegno speso nel distruggere questo muro è stata staccata la spina all’armadio hub/gateway; come conseguenza un alimentatore si è sentito male ed è stato soccorso nelle ore successive, quando tutto è tornato operativo.

Ci fa sorridere la miseria di queste indagini e di questi piccoli personaggi ancora a cavalcare un modello proibizionista che nessuno più intende perseguire perché ampiamente fallimentare, decidendo di colpire una delle poche esperienze di autoproduzione nello stesso giorno in cui un magistrato di rilevo occupa le prime pagine dei quotidiani schierandosi a favore della legalizzazione.

Siamo solidali con i due compagni colpiti dalla repressione, continueremo ad essere complici del CSOA Gabrio nell’antiproibizionismo come nelle diverse lotte.

_TO*hacklab

Altre informazioni:

Ciao Danny


Android ArchLinux Anime Basket Breaking Cinema DannyTheBBoy Darkspirit Debian Dungeons&Dragons FreeBSD Gadgets HipHop IRC Kodi Linoleum LordSkylark MIUI Odroid outoforder Raspberry remorhaz.underto.mil Snapbacks Vegetarian Xiaomi ZSH

Work In Progress

Stiamo ricostruendo l’hacklab (e il sito, e tutto quanto). Se vuoi darci una mano ci trovi al primo piano del CSOA Gabrio, in Via F. Millio 42 a Torino. Non c’è (ancora) un orario stabilito, la cosa migliore è contattarci con una mail a underscore[at]autistici[dot]org . A presto!