shanker-sec/hlf-time-oracleChaincode para blockchain Hyperledger Fabric fornece hora precisa para outros chaincodes. Assim resolvendo o problema de segurança associado à manipulação do tempo de transação (CVE-2024-45244).
hlf-time-oracle é um chaincode para blockchain Hyperledger Fabric que fornece tempo preciso para outros chaincodes. hlf-time-oracle baseia-se nos pacotes ntp e nts. Assim, resolve o problema de segurança associado à possível manipulação do tempo de transação pelo cliente blockchain (CVE-2024-45244). O chaincode fornece as funções GetTimeNtp() e GetTimeNts(). Chamar essas funções cria uma chamada para os servidores NTP (Network Time Protocol) e NTS (Network Time Security). O tempo recebido de qualquer um desses servidores pode ser usado para verificar a correção do tempo de transação definido no lado do cliente. Desenvolvedores de chaincodes para blockchain podem usar hlf-time-oracle em vez de escrever código independente para interagir com servidores NTP e NTS. hlf-time-oracle não salva nenhum dado no blockchain durante sua operação.
hlf-time-oracle para Hyperledger Fabric versão 2.4.x está na pasta hlf_2.4. hlf-time-oracle para Hyperledger Fabric versão 2.5.x está na pasta hlf_2.5.
Resolvendo o problema de centralização
As características do protocolo NTS
Resistência ao ataque man-in-the-middle
Se você não quer depender de um único servidor de tempo, pode usar múltiplos oráculos de tempo.
Oráculos
NTS é uma melhoria do NTP (veja RFC 8915). Existem 2 conexões: TCP para TLS e UDP para NTP. A porta para conexão NTP é determinada pelo servidor NTS. Pode ser diferente da padrão 123/UDP. Lembre-se disso ao configurar o firewall.
Para o estabelecimento correto da conexão TLS, é necessário que o cliente (ou seja, o sistema no qual hlf-time-oracle está sendo executado) tenha um horário do sistema relativamente correto (dentro do período de validade do certificado do servidor NTS). Caso contrário, a conexão não será estabelecida.
Recomenda-se usar GetTimeNts() em vez de GetTimeNtp(). Diferentemente do NTP, o uso do NTS é resistente ao ataque man-in-the-middle. Em caso de falsificação não autorizada dos dados abertos, o seguinte erro é registrado: authentication failed on client. Em caso de tentativa de falsificação do certificado do servidor NTS, o seguinte erro é registrado: key exchange failure: tls: failed to verify certificate: x509: certificate signed by unknown authority.
Modelo
hlf-time-oracle está sendo executado no docker (rede docker 172.18.0.0/24). No host docker (Host_1), netsed (porta 4000/UDP) e mitmproxy (porta 8080/TCP) estão em execução. O tráfego para eles a partir de hlf-time-oracle passará pelo iptables. O segundo host (Host_2) acessa as funções GetTimeNtp() e GetTimeNts() do Oracle (através de chamada peer chaincode query). Chamar essas funções faz com que o Oracle chame o servidor NTP e o servidor NTS, respectivamente.
Uma regra iptables para redirecionar o tráfego para o 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
Execute o netsed com a regra.
Criação de uma regra no netsed para substituir %ea%33 por %eF%33
Resultado de um ataque bem-sucedido.
Uma regra iptables para redirecionar o tráfego para o netsed (servidor NTS ntp1.glypnod.com tem endereço 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
Execute o netsed com a regra.
Criação de uma regra no netsed para substituir %ea%33 por %eF%33
Resultado de um ataque mal-sucedido.
Vamos ver os logs do docker:
logs do docker
Uma regra iptables para redirecionar o tráfego para o mitmproxy (servidor NTS ntp1.glypnod.com tem endereço 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
Vamos ver os logs do mitmproxy:
logs do mitmproxy
Vamos ver os logs do docker:
logs do docker
MIT