
Chaincode per la blockchain Hyperledger Fabric fornisce un tempo accurato ad altri chaincode. Risolvendo così il problema di sicurezza associato alla manipolazione del tempo delle transazioni (CVE-2024-45244).
hlf-time-oracle è un chaincode per la blockchain Hyperledger Fabric che fornisce l'ora esatta ad altri chaincode. hlf-time-oracle si basa sul pacchetto ntp e sul pacchetto nts. Risolve così il problema di sicurezza associato alla possibile manipolazione del tempo di transazione da parte del client della blockchain (CVE-2024-45244). Il chaincode fornisce le funzioni GetTimeNtp() e GetTimeNts(). La chiamata a queste funzioni effettua una richiesta ai server NTP (Network Time Protocol) e NTS (Network Time Security). L'ora ricevuta da uno qualsiasi di questi server può essere utilizzata per verificare la correttezza dell'ora di transazione definita lato client. Gli sviluppatori di chaincode per blockchain possono utilizzare hlf-time-oracle invece di scrivere codice in modo indipendente per interagire con i server NTP e NTS. hlf-time-oracle non salva alcun dato sulla blockchain durante il suo funzionamento.
hlf-time-oracle per Hyperledger Fabric versione 2.4.x si trova nella cartella hlf_2.4. hlf-time-oracle per Hyperledger Fabric versione 2.5.x si trova nella cartella hlf_2.5.
Risolvere il problema della centralizzazione
Le caratteristiche del protocollo NTS
Resistenza all'attacco man-in-the-middle
Se non vuoi dipendere da un singolo server di tempo, puoi utilizzare più oracle di tempo.
Oracle
NTS è un miglioramento di NTP (vedi RFC 8915). Ci sono 2 connessioni: TCP per TLS e UDP per NTP. La porta per la connessione NTP è determinata dal server NTS. Può essere diversa dalla standard 123/UDP. Tienilo presente quando configuri il firewall.
Per stabilire correttamente una connessione TLS è necessario che il client (cioè il sistema su cui è in esecuzione hlf-time-oracle) abbia un'ora di sistema relativamente corretta (che rientri nel periodo di validità del certificato del server NTS). In caso contrario la connessione non verrà stabilita.
Si consiglia di utilizzare GetTimeNts() invece di GetTimeNtp(). A differenza di NTP, l'uso di NTS è resistente all'attacco man-in-the-middle. In caso di spoofing non autorizzato della parte di dati in chiaro, viene registrato il seguente errore: authentication failed on client. In caso di tentativo di spoofing del certificato del server NTS, viene registrato il seguente errore: key exchange failure: tls: failed to verify certificate: x509: certificate signed by unknown authority.
Modello
hlf-time-oracle è in esecuzione in docker (rete docker 172.18.0.0/24). Sull'host docker (Host_1) sono in esecuzione netsed (porta 4000/UDP) e mitmproxy (porta 8080/TCP). Il traffico verso di loro da hlf-time-oracle passerà attraverso iptables. Il secondo host (Host_2) accede alle funzioni GetTimeNtp() e GetTimeNts() dell'Oracle (tramite la chiamata peer chaincode query). La chiamata a queste funzioni fa sì che l'Oracle chiami rispettivamente il server NTP e il server NTS.
Una regola iptables per reindirizzare il traffico a netsed:
iptables -t nat -A PREROUTING -s 172.18.0.0/24 -d 213.234.203.30/32 -p udp -m udp --dport 123 -m udp -j REDIRECT --to-ports 4000
Esegui netsed con la regola.
Crea una regola in netsed per sostituire %ea%33 con %eF%33
Il risultato di un attacco riuscito.
Una regola iptables per reindirizzare il traffico a netsed (il server NTS ntp1.glypnod.com ha un indirizzo IP 104.131.155.175):
iptables -t nat -A PREROUTING -s 172.18.0.0/24 -d 104.131.155.175/32 -p udp -m udp --dport 8123 -m udp -j REDIRECT --to-ports 4000
Esegui netsed con la regola.
Crea una regola in netsed per sostituire %ea%33 con %eF%33
Il risultato di un attacco non riuscito.
Diamo un'occhiata ai log di docker:
Log di docker
Una regola iptables per reindirizzare il traffico a mitmproxy (il server NTS ntp1.glypnod.com ha un indirizzo IP 104.131.155.175):
iptables -t nat -A PREROUTING -p tcp -s 172.18.0.0/24 --dport 4460 -m tcp -d 104.131.155.175 -j REDIRECT --to 8080
Diamo un'occhiata ai log di mitmproxy:
Log di mitmproxy
Diamo un'occhiata ai log di docker:
Log di docker
MIT