Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
gobalance-patch — تصحيح أمني وإثبات مفهوم لموازن التحميل GoBalance onion، يغطي استعادة المفتاح الرئيسي عبر blindedSign وقبول الوصف المزوّر، مع اختبارات الانحدار. | Kitploit
أدوات/GitHubGitHub/kolmteistov/gobalance-patch
تحليل الثغرات الأمنيةالاستغلالاستغلال تطبيقات الويبالتشفيراختبار الاختراقالتعلم والتعليم
GitHubkolmteistov/gobalance-patch

gobalance-patch

تصحيح أمني وإثبات مفهوم لموازن التحميل GoBalance onion، يغطي استعادة المفتاح الرئيسي عبر blindedSign وقبول الوصف المزوّر، مع اختبارات الانحدار.

عرض المستودع
36منذ يوم واحدلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

GoBalance Security Patch & PoC

حزمة استشارية لـ gitlab.com/n0tr1v/gobalance - فرع master، الالتزام bb1b0f3 ("fix crash"). الحالة: حرجة - مساران مستقلان للاستيلاء الكامل. فرع patch1 upstream لا يصلح أياً منهما.

تحتوي هذه الحزمة على تصحيح أمني كامل، وإثبات مفهوم شامل من البداية إلى النهاية لكلا مساري الهجوم، واختبارات انحدار تُثبت نجاعة الإصلاحات. وهي مصاحبة لتقرير تحليل الثغرات الكامل ("Laporan Analisis Keamanan GoBalance") المُعدّ فيما يتعلق بحوادث الاستيلاء على نطاقات onion التي أثرت على منتدَيين مؤخراً. يوجد دليل بناء واختبار خطوة بخطوة في USAGE.md.


1. الملخص التنفيذي

#الثغرةالخطورةالتأثيرالحالة
1تسرّب مفتاح الهوية الرئيسي عبر blindedSign (بادئة nonce ثابتة)حرجةاسترداد كامل لهوية onion من واصف عام واحدمُصلحة
2يقبل RegisterDescriptor واصفات نسخ مزوّرة (بدون تحقق من التوقيع / الارتباط)حرجةاختطاف حركة المرور لأي واجهة GoBalanceمُصلحة
3مسار RNG حتمي مبذور بالوقت في pkg/brandعالية (خطر كامن)مادة مفاتيح قابلة للتنبؤ لأي شيء يستخدمهمُزال
4خلط نقاط المقدمة يستخدم math/randمنخفضةعشوائية ضعيفة في كود مجاور للبروتوكولمُستبدل بـ crypto/rand

الثغرة #1 - استرداد المفتاح الرئيسي من واصف عام واحد (حرجة)

كان المُوزِّع blindedSign() في pkg/stem/descriptor/hidden_service.go يمرّر identityKey.Seed() - السكالر الخام المكوّن من 32 بايت a - إلى BlindedSignWithTorKey(). مفاتيح صيغة Tor هي مفاتيح ممتدة: 64 بايت (a || h)، حيث h هو مفتاح PRF الذي يشتق بادئة nonce لكل توقيع. مع غياب h، كان مُدخل اشتقاق nonce فارغاً وأصبح

kPrime = SHA512("Derive temporary signing key hash input" || <empty>)

ثابتاً عاماً. النتيجة: أي شخص يستطيع قراءة واصف منشور واحد يمكنه إعادة حساب nonce r، وحل السكالر المُعمّى s' = (S − r) · H(R‖PK‖M)⁻¹ mod L، وإلغاء تعميته بمُضاعِف عام - مما يسترد المفتاح الرئيسي لهوية خدمة onion. لا وصول للخادم، لا MitM، لا قوة غاشمة. هذا بدائي استيلاء صامت على النطاق ويتوافق مع الآلية الملاحظة في عمليات اختطاف المنتدى الأخيرة.

الإصلاح: يمرّر المُوزِّع الآن المفتاح الممتد الكامل (gobpk.PrivateKey.PrivKey())؛ ويُطلق BlindedSignWithTorKey panic على أي مفتاح لا يكون بالضبط 64 بايت؛ ويفرض blindedSignP2 بشكل مستقل طول ESK كدفاع في العمق؛ ويرفض gobpk.New مفاتيح Tor المقتطعة عند وقت التحميل.

الثغرة #2 - قبول واصفات نسخ مزوّرة (حرجة)

كان NewReceivedDescriptor() يحلّل ويثق بكل ما تعطيه إياه الشبكة. ولأن الاعتمادات الفرعية تُشتق من المفتاح المُعمّى المحمول داخل الواصف نفسه، كان بإمكان المهاجم سكّ واصفات متسقة ذاتياً تشفيرياً لعنوان onion الخاص بشخص آخر باستخدام مفاتيحه الخاصة. ثم تعيد الواجهة الأمامية نشر نقاط مقدمة المهاجم تحت هوية الضحية - اختطاف كامل لحركة المرور لا يتطلب أي استرداد للمفاتيح على الإطلاق.

الإصلاح: تحقق ثلاثي الطبقات في VerifyHiddenServiceDescriptorV3() الجديد: (1) توقيع الشهادة تحت المفتاح المُعمّى، (2) توقيع الواصف تحت مفتاح التوقيع المُصدّق، و (3) الارتباط - يجب أن يساوي المفتاح المُعمّى القيمة التي تحسبها الواجهة الأمامية بشكل مستقل من الإجماع (GetBlindingParam + الفترة الزمنية) وعنوان النسخة. RegisterDescriptor يفشل مغلقاً: بدون إجماع حي يرفض التسجيل بدلاً من الثقة العمياء.

2. ما تحتويه هذه الحزمة

gobalance-patch/
├── README.md                  ← this file (English)
├── USAGE.md                   ← step-by-step build & test guide (English)
├── README_ID.md               ← ringkasan patch (Bahasa Indonesia)
├── gobalance-security.patch   ← unified diff against master@bb1b0f3 (7 files, +360/−94)
├── gobalance-patched/         ← full pre-patched source tree (drop-in)
│   ├── go.mod / go.sum / main.go
│   ├── pkg/…                  ← patched libraries, incl. regression tests
│   ├── poc/                   ← end-to-end attack demo + vulnerable code snapshot
│   ├── cmd/gbdemo/            ← standalone recovery demo CLI (+ E2E tests) - USAGE #13
│   └── tools/                 ← pem2tor.py (PEM→Tor key converter), get_desc.py (descriptor fetch)
└── gobalance-v1/              ← community fork "GoBalance Enhanced v1.0" (Dread), bundled
                                 as distributed for testing - still VULNERABLE - USAGE #14

3. البدء السريع

# Option A - patch a fresh upstream checkout
git clone https://gitlab.com/n0tr1v/gobalance && cd gobalance
git apply /path/to/gobalance-security.patch
go build ./... && go test ./...

# Option B - use the bundled pre-patched tree (fastest)
cd gobalance-patched
go build ./...
go test ./poc/ -v      # attack demo: succeeds vs vulnerable snapshot, fails vs patch
go test ./...          # full suite: 8 packages ok

راجع USAGE.md للشرح الكامل مع المخرجات المتوقعة.

4. ما يثبته PoC

  1. الهجوم (الكود المصاب): يُسترد السكالر الرئيسي من واصف عام واحد، ويُزوَّر توقيع لفترة زمنية مستقبلية بالمفتاح المسترد ليكون مطابقاً بايتاً ببايت لتوقيع الضحية الحقيقي - Test01_Vulnerable_MasterKeyRecoveredFromSingleDescriptor.
  2. الدفاع: البناء المُرقّع يرفض مفتاح Tor المقتطع ذا 32 بايت عبر panic صريح يسمّي الخطر - Test02_Patched_TruncatedTorKeyRejected.
  3. التوافق: توقيعات مسار Tor المُرقّعة لا تزال تُتحقق كـ ed25519 قياسي تحت المفتاح العام المُعمّى، لذا فإن التوافق البيني مع Tor دون تغيير - Test03_Patched_TorPathSignaturesVerifyAsStdEd25519.
  4. الدفاع: إعادة تشغيل نفس رياضيات الهجوم ضد الكود المُرقّع تُنتج بيانات غير صالحة لم تعد تطابق السكالر الرئيسي الحقيقي - Test04_Patched_AttackMathYieldsGarbage.
  5. الدفاع (#2): واصف مزوّر متسق ذاتياً يمر بفحوصات نموذج الثقة القديم (parse + cert-sig + descriptor-sig) لكنه يُرفض بواسطة فحص ارتباط الإجماع الجديد - TestForgedSelfConsistentDescriptorIsDetected.
  6. الدفاع (#2): مسار الاستقبال الحقيقي يقبل الواصفات الصادقة ويرفض المُتلاعَب بها / سيئة الارتباط - TestNewReceivedDescriptor_AcceptsHonestDescriptor, _RejectsTamperedSignature, _RejectsWrongIdentityBinding.

جميع المفاتيح في PoC تُولَّد محلياً وقت الاختبار. لم تُستهدف أي خدمات حقيقية.

5. ملاحظات تشغيلية - اقرأ قبل النشر

  1. قم بتدوير المفاتيح إذا شغّلت الكود المصاب يوماً ما. واصف عام واحد كان كافياً لاسترداد المفتاح الرئيسي (الثغرة #1). يُغلق التصحيح التسرّب مستقبلاً لكنه لا يستطيع إلغاء نشر واصفات كانت عامة بالفعل. أنشئ هوية onion جديدة وترحّل.
  2. التوافق البيني على مستوى الأسلاك محفوظ. صيغ الواصفات دون تغيير والتوقيعات تبقى ed25519 قياسية تحت المفتاح المُعمّى - لا يرى Tor والمتحققون العاديون أي فرق. المفاتيح بصيغة Seed/PEM تتصرف تماماً كما قبل (كان ذلك المسار صحيحاً دائماً؛ اختبار TestBlindedSign الأصلي لا يزال ينجح).
  3. سلوك الفشل المغلق مقصود. بدون إجماع حي، ترفض الواجهة الأمامية الآن تسجيل واصفات النسخ بدلاً من الثقة بها بشكل أعمى.
  4. فرع patch1 upstream لا يصلح الثغرة #1 أو #2. يجب تطبيق هذا التصحيح فوق master (أو استخدام الشجرة المُضمّنة).

6. بيئة الاختبار

  • Go 1.21.13، linux/amd64 (يعلن go.mod عن go 1.18).
  • go vet ./... نظيف؛ go build ./... ناجح.
  • go test ./... → 8 حزم ok، 0 إخفاقات، لا انحدارات (بما في ذلك اختبارات upstream الموجودة مسبقاً).
تنزيل الأداة