shanker-sec/hlf-time-oracleتوفر Chaincode الخاصة ببلوكتشين Hyperledger Fabric وقتًا دقيقًا لغيرها من الـ Chaincode، وبالتالي تحل المشكلة الأمنية المرتبطة بالتلاعب بوقت المعاملات (CVE-2024-45244).
hlf-time-oracle هو سلسلة كود (chaincode) لبلوكتشين Hyperledger Fabric توفر وقتًا دقيقًا لسلاسل الكود الأخرى. يعتمد hlf-time-oracle على كلٍّ من حزمة ntp وحزمة nts، مما يحل المشكلة الأمنية المرتبطة بالتلاعب المحتمل في وقت المعاملة من قِبل عميل البلوكتشين (CVE-2024-45244). توفر سلسلة الكود الدالتين GetTimeNtp() و GetTimeNts(). يؤدي استدعاء هاتين الدالتين إلى إنشاء استدعاء لخوادم NTP (بروتوكول وقت الشبكة) و NTS (أمان وقت الشبكة). يمكن استخدام الوقت المُستلَم من أيٍّ من هذه الخوادم للتحقق من صحة وقت المعاملة المحدد من جانب العميل. يمكن لمطوّري سلاسل الكود الخاصة بالبلوكتشين استخدام hlf-time-oracle بدلاً من كتابة كود مستقل للتفاعل مع خوادم NTP و NTS. لا يحفظ hlf-time-oracle أي بيانات على البلوكتشين أثناء تشغيله.
يتوفر hlf-time-oracle لإصدار Hyperledger Fabric 2.4.x في مجلد hlf_2.4، ولإصدار Hyperledger Fabric 2.5.x في مجلد hlf_2.5.
إذا كنت لا ترغب في الاعتماد على خادم وقت واحد، يمكنك استخدام عدة أوراكل وقت.
الأوراكل
NTS هو تحسين لـ NTP (انظر RFC 8915). هناك اتصالان: 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) إلى دالتي الأوراكل GetTimeNtp() و GetTimeNts() (عبر استدعاء peer chaincode query). يؤدي استدعاء هاتين الدالتين إلى جعل الأوراكل يستدعي خادم NTP وخادم NTS على التوالي.
قاعدة iptables لإعادة توجيه حركة المرور إلى 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
شغّل netsed مع القاعدة.
أنشئ قاعدة في netsed لاستبدال %ea%33 بـ %eF%33
نتيجة هجوم ناجح.
قاعدة iptables لإعادة توجيه حركة المرور إلى netsed (خادم NTS ntp1.glypnod.com لديه عنوان 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
شغّل netsed مع القاعدة.
أنشئ قاعدة في netsed لاستبدال %ea%33 بـ %eF%33
نتيجة هجوم غير ناجح.
لنلقِ نظرة على سجلات docker:
سجلات docker
قاعدة iptables لإعادة توجيه حركة المرور إلى mitmproxy (خادم NTS ntp1.glypnod.com لديه عنوان 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
لنلقِ نظرة على سجلات mitmproxy:
سجلات mitmproxy
لنلقِ نظرة على سجلات docker:
سجلات docker
MIT