Leveraging Universal Embedding Geometry for Data Exfiltration

I modelli di embedding sono diventati la spina dorsale di moltissime applicazioni NLP (Natural Language Processing), dal recupero di informazioni tramite RAG (Retrieval Augmented Generation) alla classificazione e al clustering di documenti e informazioni.

Questi modelli trasformano il testo in vettori numerici che ne catturano il significato semantico: testi simili avranno vettori vicini nello spazio.

Tuttavia, modelli diversi, magari addestrati su dati differenti o con architetture eterogenee, producono embedding in spazi vettoriali completamente incompatibili tra loro.

Immagina di avere due scatole di LEGO. Entrambe contengono mattoncini per costruire la stessa casa. Però, i mattoncini della prima scatola hanno incastri quadrati, mentre quelli della seconda scatola hanno incastri rotondi.
Anche se servono allo stesso scopo (costruire una casa) e rappresentano le stesse parti (pareti, tetto, ecc.), non puoi scambiare i mattoncini tra le due scatole perché gli incastri sono diversi.
Gli embedding sono come questi mattoncini: vettori che rappresentano il significato del testo. E i modelli diversi che li creano sono come le scatole: ognuno usa un suo “tipo di incastro” (cioè un suo modo di organizzare i vettori nello spazio), rendendoli incompatibili tra loro.

Recentemente, un gruppo di ricercatori ha introdotto un metodo chiamato vec2vec che promette di abbattere queste barriere. La loro ricerca (Harnessing the Universal Geometry of Embeddings) presenta la prima tecnica in grado di tradurre embedding testuali da uno spazio vettoriale all’altro senza bisogno di dati appaiati, encoder o set predefiniti di corrispondenze, praticamente non c’è bisogno di fare supervised learning

Questo approccio si basa sull’ipotesi, definita “Strong Platonic Representation Hypothesis” che suggerisce che il linguaggio in sé, nella sua essenza più profonda, possa essere rappresentato in uno spazio universale di significato, indipendentemente dalla lingua specifica o dal modello che lo elabora (che figata!).
In pratica, esiste una struttura semantica latente universale condivisibile tra tutte le lingue e tutti i modelli di embedding sufficientemente grandi.

Un altro paper precedente (Discovering Universal Geometry in Embeddings with ICA) del 2023, esplora concetti simili e tecniche di analisi per rivelare questa struttura semantica universale negli embedding.

Vec2Vec

L’idea di base di vec2vec è quella di “imparare” una rappresentazione latente condivisa in cui gli embedding provenienti da modelli diversi, e relativi a testi diversi, possano essere allineati.

Immagina di avere due libri scritti in linguaggi diversi, da autori diversi, ma che parlano degli stessi concetti. “Imparare una rappresentazione latente condivisa” significa che il sistema trova un modo per “tradurre” entrambi i libri in un linguaggio universale che permette di capire facilmente come i concetti in un libro si relazionano a quelli nell’altro, senza aver bisogno di un dizionario pre-esistente per ogni coppia di lingue.
Il sistema, attraverso l’addestramento (non supervisionato), scopre autonomamente queste regole di trasformazione.

I risultati ottenuti sono notevoli: le traduzioni di vec2vec raggiungono similarità elevate rispetto ai vettori originali nello spazio di destinazione e riescono ad accoppiare correttamente migliaia di embedding mescolati senza conoscere le corrispondenze in anticipo. Il metodo funziona bene anche tra modelli con architetture, numero di parametri e dataset di addestramento differenti.

Implicazioni per la Sicurezza

La capacità di tradurre embedding “sconosciuti” in uno spazio differente preservandone la geometria ha serie implicazioni per la sicurezza dei vector database.

Immaginate uno scenario del genere: un attaccante riesce a ottenere un dump di un vector db compromesso; normalmente, senza il modello originale, quei vettori sarebbero una black-box, dati incomprensibili.

  • L’attaccante usa vec2vec per tradurre gli embedding “sconosciuti” nello spazio di un modello a lui noto.
  • Una volta “comprensibili”, questi embedding possono essere interrogati con tecniche standard di inferenza di attributi (es. recuperare informazioni categoriche come sesso, età, tema del documento) o, peggio ancora, di inversione degli embedding (tentativo di ricostruire porzioni del testo originale).

Ad esempio, applicando queste tecniche ad un dataset di email della Enron (dataset pubblico di email interne di una defunta compagnia energetica), vec2vec è stato in grado di estrarre informazioni sensibili come nomi di persone e aziende, date, informazioni finanziarie e persino l’argomento di specifiche email, il tutto partendo solo dagli embedding e senza conoscere il modello che li aveva prodotti.
La percentuale di email per cui è stato possibile estrarre informazioni significative arriva fino all’80%!

In un altro esperimento, utilizzando un dataset di cartelle cliniche (MIMIC), il sistema è riuscito a inferire attributi relativi a descrizioni di malattie MedCAT, anche se queste erano scarsamente presenti nei dati di addestramento di vec2vec.

Questo suggerisce che lo spazio latente appreso da vec2vec è effettivamente una rappresentazione universale, capace di generalizzare anche a concetti molto specifici.

È pazzesco come, nonostante siamo noi a progettare queste AI, pezzo per pezzo, neurone dopo neurone, alla fine ci ritroviamo ad osservare i loro comportamenti come se stessimo studiando un fenomeno naturale.
La scoperta di questa “geometria universale” negli embedding ci mostra che c’è ancora moltissimo da capire. E soprattutto, ci ricorda che quando si parla di sicurezza e AI, mai dare nulla per scontato.


Bit4id – Autenticazione CNS e Firma Digitale su Linux Debian/Ubuntu

Anche se “l’anno di Linux sul desktop sarà l’anno prossimo” (cit.), ormai le distro moderne funzionano senza troppi problemi anche per gli utenti meno tecnici.
A complicare le cose, spesso, ci si mettono gli altri. Nello specifico la TS-CNS italiana (Tessera Sanitaria/Carta Nazionale dei Servizi) e il middleware sviluppato da Bit4id.

Normalmente ci sarebbe OpenSC per interagire con i certificati presenti all’interno della Smart Card, tramite le API PKCS#11 fornite dalla libreria opensc-pkcs11.so.
Ma la CNS italiana è “speciale” e quindi ha bisogno di un middleware proprietario. Ci pensa Bit4id ed è scaricabile da qui oppure da qui come riportato anche nel Wiki di Ubuntu, ma voi non fatelo!.

Fantastico che ci sia la versione per Linux, ma il pacchetto .deb per le distro Debian/Ubuntu utilizza un PATH non standard e installa all’interno delle directory di sistema destinate alle librerie alcuni file (con estensioni .rc e .conf) non conformi agli standard, dove normalmente dovrebbero essere presenti esclusivamente file con estensione .so (ELF shared object). La libreria bit4id richiede che i file .conf siano nella stessa directory 🙁

A seguito dell’installazione, il sistema genera dei warning ogni qual volta venga eseguito ldconfig.

Warning all’esecuzione di ldconfig

Ho segnalato la questione a Bit4id. Nel frattempo possiamo sfruttare InfoCert GoSign che si porta dietro la stessa libreria middleware (libbit4xpki.so) evitando così di installare il pacchetto buggato.

GoSign è un software per la firma digitale e, visto che supporta la TS-CNS, ha bisogno di quel middleware. InfoCert l’ha inclusa nel suo pacchetto di installazione di GoSign per Debian/Ubuntu.

Autenticazione CNS e Firma Digitale con TS-CNS su Linux Debian/Ubuntu, un’installazione pulita senza warning

Firma Digitale

Autenticazione CNS con Firefox

  • Scaricare e installare InfoCert GoSign se non l’avete già fatto
  • Aprire Firefox, andare su impostazioni, Privacy & Sicurezza, scorrere fino alla sezione Certificati e cliccare “Dispositivi di Sicurezza
  • Cliccare su Carica
  • Inserire come Nome Modulo quello che volete, ad esempio Bit4id e come file /usr/lib/gosigndesktop/resources/app/node_modules/@ice/dike-core-js/node_modules/@ice/dike-core-linux/native/lib/libbit4xpki.so e date OK a tutto
  • Fine

Autenticazione CNS con Chrome o Chromium

sudo apt install libnss3-tools opensc-pkcs11
  • Aggiungere il middleware al DB tramite il comando
modutil -force -dbdir sql:$HOME/.pki/nssdb -add Bit4id -libfile /usr/lib/gosigndesktop/resources/app/node_modules/@ice/dike-core-js/node_modules/@ice/dike-core-linux/native/lib/libbit4xpki.so
  • Fine

Dev & Hacking

Tool non necessari al funzionamento di cui sopra, ma utili per interagire con la Smart Card

pcscd libpcsclite1 pcsc-tools libccid libnss3-tools opensc-pkcs11

Usage of TLS in DDNS Services leads to Information Disclosure in Multiple Vendors

Impatto sulla sicurezza relativo all’utilizzo di TLS con i servizi di Dynamic DNS (DDNS) proprietari dei vendor.

I published the original advisory, in English, @ USH – a beautiful place.

Scenario di rischio

L’utilizzo dei servizi Dynamic DNS (DDNS) integrati nelle appliance, ovvero quelli messi a disposizione direttamente dai produttori come Fortinet o QNAP, comporta un impatto sulla sicurezza in quanto il loro utilizzo si ripercuote su una maggiore superficie di attacco identificabile da un attaccante.

Attraverso questa breve analisi, si intende dimostrare come l’implementazione di tale servizio su una rete influisca sulla sua sicurezza creando un’opportunità per un attaccante di sfruttare eventuali vulnerabilità.

Introduzione a TLS e Certificate Transparency Log

La sicurezza delle comunicazioni su Internet è essenziale per garantire la confidenzialità e l’integrità delle informazioni scambiate tra utenti e siti web.
Uno strumento fondamentale per implementare questa sicurezza è rappresentato dai certificati X.509 e dal protocollo TLS, tecnologie che consentono di stabilire connessioni crittografate e autenticate.

Il Certificate Transparency (CT) è un meccanismo progettato per migliorare la sicurezza e la trasparenza nell’emissione dei certificati SSL, consentendo a terze parti di monitorare e verificare il processo di certificazione.

Il Certificate Transparency Log è un registro pubblico e immutabile di tutti i certificati emessi da una Certification Authority (CA). Questo registro fornisce un meccanismo trasparente per monitorare e verificare l’emissione dei certificati, consentendo di individuare e mitigare potenziali minacce alla sicurezza, come l’emissione di certificati fraudolenti.

Il funzionamento del Certificate Transparency Log può essere riassunto nei seguenti passaggi:

  1. Richiesta di Certificato SSL: Un sito web richiede un certificato SSL a una Certification Authority (CA).
  2. Emissione del Certificato SSL: La CA emette un certificato SSL.
  3. Registrazione nel Certificate Transparency Log: Il certificato emesso viene registrato nel Certificate Transparency Log insieme ad altre informazioni pertinenti, come il nome del dominio, la data e l’ora di emissione e altri dettagli.

Nonostante il Certificate Transparency Log sia stato progettato per migliorare la sicurezza e la trasparenza, la sua stessa natura pubblica può comportare rischi di Information Disclosure.

Di fatto, non è una novità che gli attaccanti abusino del Certificate Transparency Log per individuare sotto-domini e ampliare in questo modo la superficie di attacco e, di conseguenza, la possibilità di fare breccia nell’azienda target.

Introduzione a DDNS (Dynamic-DNS)

Dynamic Domain Name System (Dynamic DNS o DDNS) è una tecnologia che consente agli utenti di associare un Fully Qualified Domain Name (FQDN) a un indirizzo IP che può cambiare nel tempo.
Il processo coinvolge due elementi principali: un client DDNS installato sul dispositivo che si desidera rendere accessibile e un server DDNS gestito da un provider di servizi.

Sebbene questo tipo di tecnologia non sia consigliata per l’uso in ambienti SMB (Small and Medium Business) o Enterprise, è molto popolare in ambienti SOHO (Small Office/Home Office). Infatti, un numero crescente di fornitori sta integrando questo servizio nelle proprie appliance.

Mass-Exploitation

L’ultilizzo combinato delle due tecnologie, ovvero richiedere un certificato SSL per un FQDN associato a un dominio DDNS di un determinato vendor, può creare un problema relativo allo sfruttamento massivo di vulnerabilità.

Si pensi ad esempio a un produttore di firewall “ACME Inc.” che offra il suo servizio DDNS sul dominio “acme-firewall.com”.
In caso di vulnerabilità su questo firewall, un attaccante può sfruttare il log della Certificate Transparency per individuare target vulnerabili semplicemente cercando tutti i sotto-domini di “acme-firewall.com” e compromettere massivamente migliaia di dispositivi esposti.

Fortinet

FortiNet nei prodotti firewall FortiGate, ha introdotto il servizio “FortiGuard DDNS” che, oltre ad agevolare il setup di sistemi VPN in assenza di IP statico, di fatto incoraggia l’esposizione ad internet dell’interfaccia amministrativa dell’appliance.

Il servizio FortiGuard DDNS utilizza tre domini di proprietà di FortiNet: fortiddns.com, fortidyndns.com, float-zone.com, e integra un client ACME per la generazione automatica dei certificati SSL tramite Let’s Encrypt.

Interrogando un servizio di Certificate Transparency Log per il dominio fortiddns.com un attaccante può venire a conoscenza di oltre 2300 potenziali target a cui è stato rilasciato di recente un certificato per fortiddns.com (risultati filtrati per certificati non ancora scaduti). Il servizio usato per questo esempio ha troncato i risultati per la presenza di troppe entry corrispondenti alla query di ricerca, questo significa che in realtà i potenziali target sono molti di più.

Su Shodan invece sono indicizzati ben 7968 target per lo stesso dominio. La quasi totalità degli host è stata indicizzata tramite il campo “Common Name” del certificato SSL.

QNAP

QNAP dispone del servizio “myQNAPcloud” per semplificare l’accesso remoto ai propri prodotti NAS.
Anche in questo caso, il produttore incoraggia di fatto l’esposizione ad internet dell’appliance tramite tale servizio che utilizza il DDNS proprietario myqnapcloud.com.

Il servizio di Certificate Transparency Log interrogato restituisce oltre 4400 potenziali target, anche in questo caso i risultati di ricerca sono troncati.

Shodan restituisce 39027 target, anche in questo caso indicizzati tramite il campo “Common Name” del certificato SSL.

Mikrotik

Anche Mikrotik, produttore di router e switch, dispone di un servizio DDNS sul dominio sn.mynetname.net e integra un client ACME sulle loro appliance.
Il sotto-dominio generato dal servizio è composto dal numero seriale dell’appliance (che corrisponde al MAC address della prima interfaccia di rete), esempio: serialnumber.sn.mynetname.net.

L’FQDN generato dal servizio è composto dal numero seriale dell’appliance (che corrisponde al MAC address della prima interfaccia di rete), esempio: serialnumber.sn.mynetname.net.

Il servizio di Certificate Transparency Log interrogato restituisce oltre 1300 potenziali target, anche in questo caso i risultati di ricerca sono troncati.

Shodan invece restituisce 3885 target indicizzati per Common Name.

Conclusioni

Anche se l’utilizzo di DDNS non implica automaticamente l’esposizione ad internet di interfacce amministrative e servizi, di fatto ne incoraggia la pratica.
Ad ogni modo, quando utilizzato in concomitanza con un client ACME che genera automaticamente un certificato X.509 sul dominio DDNS, si viene a creare automaticamente un problema di Information Disclosure.

Pertanto, è fondamentale che i produttori comunichino chiaramente agli utenti questi potenziali rischi per la sicurezza, sottolineando l’importanza di una configurazione prudente.

Metasploit’s post-exploitation module to extracts Mikrotik Winbox credentials

Metasploit’s post gather modules are useful to gathering additional information from a host after a Metasploit session has opened.

This module is a Post-Exploitation Windows Gather to perform credentials extraction against the Mikrotik Winbox when the “Keep Password” option is selected in Winbox.

I sent a Pull Request to Rapid7 wich was accepted and this module is now part of metasploit. So, now I’m a metasploit contributor 😉

Usage

  • Get a session on Windows host (meterpreter, shell and powershell sessions are supported)
  • Run: run post/windows/gather/credentials/winbox_settings
  • If any users in the system has a Keep Password enabled in Winbox, the credentials will be printed out