shanker-sec/hlf-time-oracleChaincode para blockchain Hyperledger Fabric que proporciona tiempo preciso a otros chaincodes, resolviendo así el problema de seguridad asociado con la manipulación del tiempo de transacción (CVE-2024-45244).
hlf-time-oracle es un chaincode para blockchain Hyperledger Fabric que proporciona hora precisa a otros chaincodes. hlf-time-oracle se basa en el paquete ntp y en el paquete nts. De esta manera se resuelve el problema de seguridad asociado con la posible manipulación del tiempo de transacción por parte del cliente de blockchain (CVE-2024-45244). El chaincode proporciona las funciones GetTimeNtp() y GetTimeNts(). Llamar a estas funciones genera una llamada a los servidores NTP (Network Time Protocol) y NTS (Network Time Security). El tiempo recibido de cualquiera de estos servidores puede usarse para verificar la corrección del tiempo de transacción definido en el lado del cliente. Los desarrolladores de chaincodes para blockchain pueden usar hlf-time-oracle en lugar de escribir código independiente para interactuar con los servidores NTP y NTS. hlf-time-oracle no guarda ningún dato en la blockchain durante su funcionamiento.
hlf-time-oracle para Hyperledger Fabric versión 2.4.x se encuentra en la carpeta hlf_2.4. hlf-time-oracle para Hyperledger Fabric versión 2.5.x se encuentra en la carpeta hlf_2.5.
Si no quieres depender de un único servidor de tiempo, puedes usar múltiples oráculos de tiempo.
Oráculos
NTS es una mejora de NTP (ver RFC 8915). Hay 2 conexiones: TCP para TLS y UDP para NTP. El puerto para la conexión NTP lo determina el servidor NTS. Puede ser diferente del estándar 123/UDP. Ten esto en cuenta al configurar el firewall.
Para que el establecimiento de la conexión TLS sea correcto, se requiere que el cliente (es decir, el sistema en el que se ejecuta hlf-time-oracle) tenga una hora del sistema relativamente correcta (dentro del período de validez del certificado del servidor NTS). De lo contrario, la conexión no se establecerá.
Se recomienda usar GetTimeNts() en lugar de GetTimeNtp(). A diferencia de NTP, el uso de NTS es resistente al ataque de hombre en el medio. En caso de suplantación no autorizada de la parte de datos abierta, se registra el siguiente error: authentication failed on client. En caso de un intento de suplantar el certificado del servidor NTS, se registra el siguiente error: key exchange failure: tls: failed to verify certificate: x509: certificate signed by unknown authority.
Modelo
hlf-time-oracle se ejecuta en docker (red docker 172.18.0.0/24). En el host docker (Host_1) se ejecutan netsed (puerto 4000/UDP) y mitmproxy (puerto 8080/TCP). El tráfico hacia ellos desde hlf-time-oracle pasará a través de iptables. El segundo host (Host_2) accede a las funciones GetTimeNtp() y GetTimeNts() del oráculo (mediante una llamada peer chaincode query). Llamar a estas funciones hace que el oráculo llame al servidor NTP y al servidor NTS, respectivamente.
Una regla de iptables para redirigir el tráfico 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
Ejecute netsed con la regla.
Cree una regla en netsed para reemplazar %ea%33 por %eF%33
El resultado de un ataque exitoso.
Una regla de iptables para redirigir el tráfico a netsed (el servidor NTS ntp1.glypnod.com tiene una dirección 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
Ejecute netsed con la regla.
Cree una regla en netsed para reemplazar %ea%33 por %eF%33
El resultado de un ataque fallido.
Veamos los registros de docker:
registros de docker
Una regla de iptables para redirigir el tráfico a mitmproxy (el servidor NTS ntp1.glypnod.com tiene una dirección 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
Veamos los registros de mitmproxy:
registros de mitmproxy
Veamos los registros de docker:
registros de docker
MIT