shanker-sec/hlf-time-oracleChaincode для блокчейна Hyperledger Fabric предоставляет точное время другим chaincode. Таким образом решается проблема безопасности, связанная с манипуляцией временем транзакции (CVE-2024-45244).
hlf-time-oracle — это chaincode для блокчейна Hyperledger Fabric, который предоставляет точное время другим chaincode. hlf-time-oracle основан на пакете ntp и пакете nts. Таким образом решается проблема безопасности, связанная с возможной манипуляцией временем транзакции со стороны клиента блокчейна (CVE-2024-45244). Chaincode предоставляет функции GetTimeNtp() и GetTimeNts(). Вызов этих функций создает запрос к серверам NTP (Network Time Protocol) и NTS (Network Time Security). Время, полученное от любого из этих серверов, может быть использовано для проверки корректности времени транзакции, заданного на стороне клиента. Разработчики chaincode для блокчейна могут использовать hlf-time-oracle вместо самостоятельного написания кода для взаимодействия с серверами NTP и NTS. hlf-time-oracle не сохраняет никаких данных в блокчейн во время своей работы.
hlf-time-oracle для Hyperledger Fabric версии 2.4.x находится в папке hlf_2.4. hlf-time-oracle для Hyperledger Fabric версии 2.5.x находится в папке hlf_2.5.
Решение проблемы централизации
Устойчивость к атаке «человек посередине»
Если вы не хотите зависеть от одного сервера времени, вы можете использовать несколько оракулов времени.
Оракулы
NTS является улучшением NTP (см. RFC 8915). Используются 2 соединения: TCP для TLS и UDP для NTP. Порт для NTP-соединения определяется NTS-сервером. Он может отличаться от стандартного 123/UDP. Учитывайте это при настройке брандмауэра.
Для корректного установления TLS-соединения требуется, чтобы клиент (т.е. система, на которой работает hlf-time-oracle) имел относительно правильное системное время (в пределах срока действия сертификата NTS-сервера). В противном случае соединение не будет установлено.
Рекомендуется использовать GetTimeNts() вместо GetTimeNtp(). В отличие от NTP, использование NTS устойчиво к атаке «человек посередине». В случае несанкционированной подмены открытой части данных регистрируется следующая ошибка: authentication failed on client. При попытке подмены сертификата NTS-сервера регистрируется следующая ошибка: key exchange failure: tls: failed to verify certificate: x509: certificate signed by unknown authority.
Модель
hlf-time-oracle работает в Docker (сеть Docker 172.18.0.0/24). На хосте Docker (Host_1) запущены netsed (порт 4000/UDP) и mitmproxy (порт 8080/TCP). Трафик от hlf-time-oracle к ним будет проходить через iptables. Второй хост (Host_2) обращается к функциям Oracle GetTimeNtp() и GetTimeNts() (через вызов peer chaincode query). Вызов этих функций заставляет Oracle обращаться к серверу NTP и серверу NTS соответственно.
An iptables rule to redirect traffic to 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
Run netsed with rule.
Создание правила в netsed для замены %ea%33 на %eF%33
Результат успешной атаки.
An iptables rule to redirect traffic to netsed (NTS server ntp1.glypnod.com has an IP address 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
Run netsed with rule.
Создание правила в netsed для замены %ea%33 на %eF%33
Результат неудачной атаки.
Let's see docker logs:
логи Docker
An iptables rule to redirect traffic to mitmproxy (NTS server ntp1.glypnod.com has an IP address 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
Let's see mitmproxy logs:
логи mitmproxy
Let's see docker logs:
логи Docker
MIT