Posts

Posted on

Fastweb, modem libero e il marketing dell’ignoranza

Questo post illustra come configurare correttamente il tuo router su rete Fastweb, sia in IPv4 che in IPv6. Io uso un Mikrotik 5009UG+S+ ma i concetti sono trasportabili a qualsiasi macchina supporti le tecnologie utilizzate.

Ma prima, alcune riflessioni sul marketing dell’ignoranza.

Terminazione GPON di Fibercop appena collaudata sotto casa. È qui che inizia questa storia, con un passaggio di consegne tra la vecchia FTTCab e la nuova FTTH.

Per evitare problemi, il giorno prima dell’appuntamento, ho passato io stesso la sonda da elettricista dall’androne fino al mio rack. Un gesto non dovuto, ma comunque necessario per evitare che il tecnico terminasse la fibra appena dentro casa.

Appena i tecnici hanno finito, ho fatto accesso al router. Sapevo che avrei imprecato, e infatti: Bio Parco!

Il sistema mi chiede di premere due pulsanti entro 20 secondi. Corro nello stanzino, apro la scala, premo, scendo, torno al PC. Ventidue secondi. Fallito.

Al secondo tentativo, con il cuore che batte per l’assurdità del gesto, entro e provo a configurare quello che oggi, con un termine che nasconde l’ignoranza tecnica sotto un velo di modernità, è chiamato DMZ ma che resta un NAT 1:1.

“Senza restrizioni”, dice la descrizione. Eppure non posso nemmeno lasciarmi martellare la porta 22 da un bot cinese per puro diletto. Così ho staccato tutto e ho collegato l’ONT direttamente al mio Mikrotik 5009, gettando via quella scatola del piacere per scimmie allo zoo chiamata “Fastgate”.

Il marketing dell’ignoranza

Capitolo 1: Vogliamo WiFi! (cit.)

Ovvero: quando Bello Figo diventa il direttore marketing di tutti gli ISP italiani mainstream: https://www.youtube.com/watch?v=aR7EK2cYnPk

Viviamo in un’era dove tutto è “WiFi”. Da Sky a TIM, ogni offerta ha perso il contatto con la realtà fisica dei cavi e dell’infrastruttura per abbracciare un’astrazione commerciale che si adatta a un popolo che non vuole più capire.

https://www.youtube.com/watch?v=9oIDAeXqkH0

Ho sentito ragazzi in età universitaria parlare di “abbonamento al wifi”, come se l’infrastruttura fosse svanita nell’etere. È una semplificazione che uccide la cultura tecnica, trasformandola in una melassa indistinguibile.

Capitolo 2: admin:admin

E poi c’è la questione dei due pulsantini. Una scelta “passwordless” che è, tecnicamente parlando, una cagata pazzesca. È scomoda coma la carta igienica da un velo fatta di carta riciclata, ma è soprattutto pericolosa.

Immaginate una festa a casa vostra, la password del WiFi che gira come figurine Panini negli anni ’90. Un amico di amici, quello bravo col computer, con un’App colorata scaricata dall’app store, fa una scansione di rete e vi becca l’NVR delle telecamere di videosorveglianza. Mentre siete distratti a ridere, lui si avvicina al modem e preme quei maledetti tasti per tre secondi. In un istante è dentro. Si configura un port-forwarding verso l’NVR e torna da voi al barbecue, a mangiare salsicce e a chiedervi del vostro cane.

Torna a casa, vi bruteforza la password delle telecamere che, se non è admin o 123456 è quasi certamente il nome di quella bestiola che gli avete presentato. A questo punto la vostra vita privata è su internet. Grazie anche ai pulsantini di Fastweb!

Capitolo 3: Devo andare a prendere Bubba!

Il NAT 1:1 (o 1:1 Network Address Translation) si limita a mappare un indirizzo IP pubblico su uno privato, mantenendo l’esatta corrispondenza dei numeri di porta. È quella funzionalità che nei router casalinghi viene spacciata per “DMZ” solo per dare un nome altisonante a un’operazione di sostituzione di indirizzi dai pacchetti in transito. Evidentemente NAT gli stava sul cazzo.

La vera DMZ (Demilitarized Zone), invece, è una sottorete ben precisa di un firewall, esposta su internet ma rigorosamente isolata dalle altre reti interne. È un’architettura di sicurezza, non una semplice regola di traduzione indirizzi. Non è la funzionalità del vostro modem. Ma allora perché la chiamano DMZ? Forse per quell’abitudine tutta moderna di usare parole grandi per coprire realtà piccole, o forse perché nel marketing dell’ignoranza la precisione è un rumore di fondo che disturba il messaggio.

Capitolo 4: L’eutanasia della curiosità

Perché abbiamo smesso di pretendere la precisione? Forse perché è più comodo affogare in un’interfaccia colorata che guardare nell’abisso della configurazione. Ci siamo arresi a una fruizione passiva, un’esistenza dove capire è diventato un optional trascurabile.

Il RANT è finito.

Liberiamo il router

La delibera AGCOM n. 348/18/CONS (in vigore dal 31 dicembre 2018) sancisce il diritto in Italia del modem libero. Gli utenti possono scegliere e utilizzare un modem/router alternativo a quello fornito dall’operatore, senza costi aggiuntivi, penali o discriminazioni tecniche, garantendo la libera scelta dell’apparecchiatura terminale.

La delibera AGCOM 348/18/CONS sancisce il diritto al modem libero. Una su mille l’hanno azzeccata.

La documentazione ufficiale di Fastweb è volutamente caotica: il loro interesse è tenervi legati al loro router per semplicità di gestione. Dicono che con il modem libero non sarà possibile usare l’IPv6.
Cito: “Nel caso di utilizzo di un modem-router non fornito da Fastweb non sarà possibile usufruire dei […] servizi aggiuntivi specializzati Fastweb previsti dall’offerta, quali ad esempio il servizio IPV6.”
Ovviamente non è un limite tecnico assoluto; dipende da quanto è evoluto il vostro router. Infatti, lo configuriamo.

IPv4

Sniffando il traffico tra ONT e router si vedono le VLAN 200 e 835. La 835 è quella che ci interessa. Fastweb usa l’autenticazione IPoE con mac-address invece del classico tunnel PPPoE. IPoE non ha bisogno di credenziali per ogni cliente e non mangia MTU con l’incapsulamento.

Per prima cosa bisogna clonare il mac-address della WAN del router ufficiale. Non serve fare M-i-t-M tra router e ONT, basta osservare il traffico con Wireshark perché l’interfaccia non è silente:

  • c’è del traffico IEEE-1905 untagged (un errore di configurazione loro, secondo me, perché credo che questo traffico debba esistere solamente lato LAN, si saranno scordati di mettere una bella policy tagged-only)
  • c’è DHCP Discover sulla VLAN 835
  • c’è ICMPv6 Neighbor Solicitation sulla VLAN 200

Preso il mac-address, lo assegniamo all’interfaccia WAN e creiamo una VLAN figlia con ID 835, affiancandoci un DHCP Client. Fine. Abbiamo IPv4 con MTU pieno a 1500.

/interface vlan
  add interface=ether1 name=vlan835 vlan-id=835
/ip dhcp-client
  add interface=vlan835

IPv6

Ho visto provider che hanno dual-stack sia su PPPoE che IPoE, probabimente dipende dal segmento della rete GPON su cui siete e non tanto dal provider.
Nel mio caso il servizio nativo è solo IPv4.

Per avere IPV6 bisogna quindi fare un tunnel 6rd (IPv6 Rapid Deployment) che è una estensione del 6to4. Si tratta di incapsulamento, che mangia 20 byte di overhead (la dimensione dell’header IPv4). L’MTU della connettività IPv6 sarà quindi 1480 (1500-20).

Alcune caratteristiche di un tunnel 6rd:

  • Setta il flag del protocollo IPv4 a 41 come 6to4
  • 6to4 utilizza il prefisso riservato 2002::/16, mentre 6rd utilizza un prefisso dell’ISP, quello di Fastweb è 2001:b07::/32. L’indirizzo IPv6 viene ricavato incorporando l’indirizzo IPv4 in notazione esadecimale, aggiungendo il suffisso ::2 e chiaramente il prefix /64 che è l’unità minima routabile in IPv6.
  • 2001:b07::/32 fa parte di 2000::/3, ovvero gli indirizzi Global Unicast assegnati dai vari registri (RIPE, ARIN, ecc.) per il traffico IPv6 nativo.
  • L’endpoint del tunnel 6rd di Fastweb è 81.208.50.214 che poi farà da Relay Router sulla rete IPv6 nativa.
   6rd specifies a protocol mechanism to deploy IPv6 to sites via a
   service provider's (SP's) IPv4 network.  It builds on 6to4 [RFC3056],
   with the key differentiator that it utilizes an SP's own IPv6 address
   prefix rather than a well-known prefix (2002::/16).  By using the
   SP's IPv6 prefix, the operational domain of 6rd is limited to the SP
   network and is under its direct control.  From the perspective of
   customer sites and the IPv6 Internet at large, the IPv6 service
   provided is equivalent to native IPv6.

A differenza di un 6to4, l’indirizzo di un 6rd fa sembrare il traffico IPv6 nativo.

Per calcolare la /64 si converte l’IPv4 in esadecimale. Esempio: 10.11.12.13 diventa 0A0B:0C0D. L’indirizzo sarà 2001:b07:0a0b:0c0d::2/64.

/interface 6to4
  add mtu=1480 name=6rd-fastweb remote-address=81.208.50.214
/ipv6 address
  add address=2001:b07:OMISSIS:OMISSIS::2 advertise=no interface=6rd-fastweb

Per vostra curiosità, questo è il contenuto del frame che sta trasmettendo quel ping:

  • 15 byte di header Ethernet
  • 4 byte di vlan
  • 20 byte di header IPv4
  • 40 byte di header IPv6
  • 16 byte di ICMPv6

MTU

Mentre l’MTU è standardizzato dagli RFC 791 (IPv4) e RFC 8200 (IPv6) come la somma dell’header IP + Dati, l’L2MTU non lo è.

In Mikrotik, l’L2MTU non tiene conto dei 14 byte dell’header Ethernet, mentre il Full Frame MTU rappresenta la lunghezza reale sul cavo. Altri vendor inglobano i 14 byte dell’header L2 nel conteggio, altri ancora includono pure i 4 byte di checksum, ecc.

Come Mikrotk conteggia gli L2MTU

Considerando la massima dimensione del pacchetto IPv6 a 1480 abbiamo:

  • IPv6 MTU (1480): IPv6 (40 byte) + Data: (1440)
  • IPv4 MTU (1500): IPv4 (20 byte) + IPv6 (40 byte) + Data: (1440)
  • L2MTU (1504): Vlan (4 byte) + IPv4 (20 byte) + IPv6 (40 byte) + Data: (1440)
  • FullFrame MTU (1518): Ethernet (14 byte) + Vlan (4 byte) + IPv4 (20 byte) + IPv6 (40 byte) + Data: (1440)

Per IPv4:

  • IPv4 MTU (1500): IPv4 (20 byte) + Data: (1480)
  • L2MTU (1504): Vlan (4 byte) + IPv4 (20 byte) + Data: (1480)
  • FullFrame MTU (1518): Ethernet (14 byte) + Vlan (4 byte) + IPv4 (20 byte) + Data: (1480)

L’L2MTU impostato di default sul mio modello è 1514 (configurabile fino a un massimo di 9796) ed è sufficiente in quanto 1514 >= 1504.

Enjoy!

Posted on

La cybersecurity non è più cosa da hacker – il caso GoSign di Tinexta InfoCert

English version: here

C’è stata un’epoca, fino ai primi anni 2000, in cui chi si occupava di sicurezza informatica lo faceva perché non poteva farne a meno. Non per il mercato, non per le certificazioni, non per una carriera nel settore. Lo faceva perché era finito dentro un mondo strano, pieno di persone curiose, spesso sregolate, ma animate da un’irrefrenabile voglia di capire come funzionavano davvero le cose, e soprattutto, di condividere e confrontarsi.

Era un ecosistema vivo, underground, dove ogni scoperta diventava automaticamente anche la scoperta di qualcun altro. Dove lo spirito hacker – quello vero, fatto di collaborazione e confronto – era più importante del titolo sul biglietto da visita.

Oggi, guardando come si è trasformato il settore, questo spirito sembra evaporato.

Non perché manchino persone competenti: al contrario.
Il cambio generazionale porta nei reparti cyber delle aziende figure con un background accademico, master, certificazioni e un CV luccicante su LinkedIn. Ma manca qualcosa. Manca quel senso di comunità, di “noi contro la complessità del mondo”, che ha sempre fatto da collante.

E quando questo spirito manca, si vede. Si vede nelle community che si sgretolano, e poi muoiono. Si vede nei vendor che reagiscono alle segnalazioni di sicurezza come se fossero rotture di scatole da minimizzare invece che occasioni di miglioramento, come quello che ho vissuto sulla mia pelle con GoSign Desktop di Tinexta InfoCert.

Un caso che racconta (purtroppo) il presente

GoSign Desktop è un software di firma digitale usatissimo: pubbliche amministrazioni, aziende, professionisti. Migliaia di documenti firmati ogni giorno.

A inizio ottobre di quest’anno (2025) ho trovato due problemi seri in GoSign Desktop (versioni <= 2.4.0):

  • la verifica TLS veniva disattivata quando si utilizzava un proxy (molto comune in ambienti enterprise);
  • il meccanismo di aggiornamento si basava su un manifest non firmato.

In pratica: chiunque in grado di eseguire un MitM poteva:

  • intercettare e leggere traffico;
  • fornire un manifest “falso” contenente un aggiornamento malevolo;
  • far eseguire codice arbitrario sulla macchina della vittima.
    • Su Windows e Mac con i privilegi dell’utente.
    • Su Linux con privilegi root.

Inoltre, su Linux esiste anche un altro scenario di Local Privilege Escalation, sfruttabile a prescindere dall’impostazione “proxy” di GoSign.

Un disastro annunciato.

Link alla disclosure ufficiale.

Responsible Disclosure (unidirezionale)

Faccio quello che ogni ricercatore serio fa: segnalo la vulnerabilità al vendor, condivido dettagli, PoC, mitigazioni. Mi rendo disponibile per una call tecnica il 16 ottobre, dove il responsabile della sicurezza e il product owner mi confermano tutto. Insieme fissiamo una deadline a fine mese per la patch.

Non ho chiesto soldi, se fosse stato possibile una citazione nel ChangeLog – come si fa in questi casi – sarei stato grato.

Ad ogni modo, rimanevo in attesa di una loro comunicazione che mi avvisava della patch pronta, di modo da poter pubblicare l’advisory della vulnerabilità senza alcun rischio per gli utenti.

E qui la storia si interrompe.
O meglio: si interrompe da parte di Tinexta Infocert S.p.A.

Dopo quella call in cui ho condiviso tutti i dettagli tecnici pro-bono, il silenzio. Nessun aggiornamento. Nessuna risposta alle email. Nessun confronto.

Poi, il 4 novembre, esce la versione 2.4.1. Me ne accorgo qualche giorno dopo. Versione che includeva proprio la fix da me proposta pubblicata in silenzio, senza alcun avviso, senza nessuna menzione, senza riconoscere il lavoro di chi ha segnalato il problema, senza nemmeno un messaggio a dire “ok, è uscita”.

Una gestione che definire scorretta è un eufemismo.
Una gestione che racconta benissimo lo stato del settore.

Perché?

Perché in uno scenario sano, basato sulla fiducia reciproca, un vendor sarebbe grato. Collaborerebbe. Si confronterebbe. Riconoscerebbe.
Invece oggi la sicurezza sembra diventata un pezzo del ciclo di prodotto: qualcosa da chiudere in fretta, minimizzare, mettere a tacere.

ACN/CSIRT Italia è stata informata dell’accaduto, sia della vulnerabilità che del comportamento scorretto del vendor. Ed era giusto così.

Oltre GoSign

Questa storia non è interessante solo per le vulnerabilità – gravi – o per la disclosure gestita male.

È interessante perché è simbolica. È un esempio del mondo che resta quando lo spirito hacker scompare: un mondo freddo, aziendalista, senza empatia, dove chi segnala un problema, mettendo a disposizione le sue competenza gratuitamente, è visto come un rischio reputazionale invece che come un alleato.

Ed è paradossale, perché la sicurezza – e in questo caso anche un pezzo di sicurezza nazionale – dipende proprio da chi ha ancora quella mentalità lì: persone indipendenti, curiose, che dedicano tempo libero e competenze a controllare ciò che nessuno controlla. Persone che fanno ricerca pro-bono, senza strutture, senza budget, senza team di product management.

Persone che lo fanno perché credono che, se c’è qualcosa che non funziona, è giusto segnalarlo per portare un miglioramento a beneficio di tutti.

Quello che abbiamo perso

Abbiamo perso il senso di responsabilità collettiva.
Abbiamo perso la capacità di discutere senza filtri.
Abbiamo perso l’idea che la sicurezza sia un bene comune, non un asset commerciale da proteggere dietro una muraglia di NDA.

E quando il settore si riempie di professionisti top-down, cresciuti più nell’accademia che nel fango delle community, succede questo: si diventa bravissimi a fare threat modeling, e incapaci di parlare con chi ti sta dando una mano.

Perché manca l’empatia.
Manca la cultura del confronto.
Manca lo spirito.

La cybersecurity non è più cosa da hacker. Ed è un problema.

Perché senza hacker – quelli veri, non quelli disegnati come personaggi cattivi nelle slide aziendali – rimane solo un settore pieno di regole, procedure, KPI… e vuoti enormi. Vuoti e buchi che nessuno vede.

Posted on

Cybersecurity Is No Longer a Hacker’s Game – An Italian Story: The Tinexta InfoCert GoSign Case

Versione italiana: qui

There was a time, up until the early 2000s, when those who worked in computer security did so because they simply couldn’t help it. Not for the market, not for certifications, not for a career. They did it because they had fallen into a strange world full of curious, often unruly people, all driven by an unstoppable desire to understand how things really worked, and -above all – to share and compare notes.

It was a living, underground ecosystem where every discovery automatically became someone else’s discovery, too. Where the hacker spirit – the real one, built on collaboration and exchange – mattered far more than any job title printed on a business card.

Today, looking at what the industry has become, that spirit seems to have evaporated.

Not because competent people are lacking, quite the opposite.
The generational shift brings into corporate cyber teams professionals with academic backgrounds, master’s degrees, certifications, and sparkling LinkedIn CVs. But something is missing. That sense of community, of “us against the complexity of the world”, which once held everything together, is gone.

And when that spirit is gone, you can tell.
You see it in communities that crumble and then die.
You see it in vendors who treat security reports as nuisances to be minimized rather than opportunities to improve – like what I personally experienced with Tinexta InfoCert’s GoSign Desktop.

A case that (unfortunately) reflects the present

GoSign Desktop is a widely used digital-signature application: public administrations, companies, professionals. Thousands of documents signed every day.

At the beginning of October this year (2025), I found two serious issues in GoSign Desktop (versions ≤ 2.4.0):

  • TLS verification was disabled when using a proxy (very common in enterprise environments);
  • the update mechanism relied on an unsigned manifest.

In practice, anyone capable of performing a MitM attack could:

  • intercept and read traffic;
  • provide a fake manifest with a malicious update;
  • execute arbitrary code on the victim’s machine:
    • on Windows and macOS with user privileges;
    • on Linux with root privileges.

Additionally, on Linux there was another Local Privilege Escalation scenario exploitable regardless of GoSign’s proxy settings.

A disaster waiting to happen.

Link to the official disclosure.

Responsible Disclosure (one-way)

I did what any serious researcher does: I reported the vulnerability to the vendor, shared details, PoCs, mitigations. I made myself available for a technical call on October 16th, where the security lead and product owner confirmed everything. Together we agreed on a patch deadline at the end of the month.

I didn’t ask for money; if anything, a mention in the ChangeLog – as is customary -would have been appreciated.

Anyway, I was waiting for them to notify me once the patch was ready, so I could publish the advisory with no risk to users.

And this is where the story stops.
Or rather: Tinexta Infocert S.p.A. stopped.

After that call, during which I shared all technical details pro bono, silence. No updates. No email replies. No discussion.

Then, on November 4th, version 2.4.1 was released. I noticed a few days later. A version that quietly included the very fix I had proposed – published silently, without any notice, without any acknowledgment, without recognizing the work of the person who found the issue, without even a message saying “okay, it’s out”.

Calling this mishandling “inappropriate” is an understatement.
It perfectly illustrates the state of the industry.

Why?

Because in a healthy environment – one based on mutual trust – a vendor would be grateful. They would collaborate. Engage. Acknowledge.
Instead, today security feels like just another piece of the product lifecycle: something to wrap up quickly, minimize, hush.

ACN/CSIRT Italy (the Italian National Cybersecurity Agency) has been informed about both the vulnerability and the vendor’s improper behavior. And that was the right thing to do.

Beyond GoSign

This story isn’t interesting only because of the vulnerabilities – serious ones – or the poorly handled disclosure.

It’s interesting because it’s symbolic. It’s an example of what’s left when the hacker spirit disappears: a cold, corporate world with no empathy, where someone reporting an issue – donating their skills for free – is seen as a reputational risk rather than an ally.

And it’s paradoxical, because security – and in this case even a bit of national security – depends precisely on those who still have that mindset: independent, curious people who dedicate their free time and expertise to checking what no one else checks. People who do pro bono research, without structures, without budgets, without product management teams.

People who do it because they believe that if something is broken, the right thing to do is to report it, for everyone’s benefit.

What We Lost

We’ve lost our sense of collective responsibility.
We’ve lost the ability to speak openly.
We’ve lost the idea that security is a common good, not a commercial asset to be locked behind a wall of NDAs.

And when the industry fills up with top-down professionals, trained more in academia than in the mud of real communities, this happens: we become excellent at threat modeling and incapable of talking to someone who’s trying to help.

Because empathy is missing.
The culture of exchange is missing.
The spirit is missing.

Cybersecurity is no longer a hacker’s game. And that’s a problem.

Because without hackers- the real ones, not the cartoon villains in corporate slides – what’s left is a sector full of rules, procedures, KPIs… and massive gaps. Gaps and holes no one sees.

Posted on

Vibe Reverser – A reverse engineer AI agent

Non importa se funziona, l’importante è che il vibe sia giusto!

L’idea è semplice: dentro un container Docker, l’agente si installa da solo tutto l’arsenale da vero reverse engineer, da radare2 a gdb, passando per binwalk, xxd e compagnia bella.

Poi prendi un binario, gli dici “ehi, analizza questo e dimmi come non farlo esplodere”, e lui inizia a produrre disassemblati, log e perfino un report PDF bello pronto. Perfetto da mostrare al capo oppure da usare per fare colpo con studentesse e studenti di ingegneria informatica.

Crack me, baby!

Per testare questa meraviglia gli ho fatto affrontare diverse challenge di crack-me. Spoiler: se l’è cavata niente male!

Prendiamo il classico esercizio della “bomba” da disinnescare.

Abbiamo un binario ELF strippato, quindi senza simboli di debug (già qui lo studente medio di ingegneria inizia a deprimersi), che quando lo lanci esplode subito con un bel messaggio: “Sono esploso!”. L’obiettivo? Farlo sopravvivere.

Ovviamente ci sono vari modi per riuscirci, ma la challenge chiede esplicitamente di non fare binary patching, ovvero di non girare i salti condizionali (JE , JNE, ecc). Quindi diciamo alla nostra creatura di non farlo. Bisognerà trovare una strada diversa, trovare una password, fare lib preloading, ecc, ma noi non gli diciamo niente di tutto ciò e lasciamo che trovi la sua strada (per l’inferno).

Avviamo l’agente dicendogli semplicemente:

Analyze the target file ./target/bingus and find a way to prevent it from exploding without a binary-patch.

Il fascino del caos incontrollato

A questo punto lui parte: tribola, disassembla, riflette e vomita a schermo tutto il vibe possibile, fino a mettere insieme la soluzione. Il tutto condito con un bel report ordinato.

Nel report ci rivela che la soluzione è lanciare il programma passandogli un parametro “pp” per non farlo esplodere, ed effettivamente è così.

Bello vero?

Se vuoi provarlo, trovi tutto sul mio GitHub. Prima di avviarlo leggiti il README, soprattutto il paragrafo “SECURITY”. Oppure fregatene: tanto lo sai già, l’importante è che il vibe sia giusto!