WEASEL: منارة DNS خفية

WEASEL هي أداة خفيفة صغيرة تعمل في الذاكرة باستخدام Python 3 بدون أي تبعيات. يرسل عميل المنارة كمية صغيرة من المعلومات التعريفية عن مضيفه إلى منطقة DNS تتحكم فيها. يمكن لخادم WEASEL تكليف العملاء بتنفيذ أوامر جاهزة أو عشوائية.

WEASEL هي حمولة من المرحلة الأولى، مصممة لتكون صعبة الاكتشاف ومفيدة لاستعادة الوصول عندما يتم اكتشاف مراحلك الكاملة المزعجة.

الحالة

• تم استخدامها بنجاح في عملية وتجنبت الاكتشافات.
• يمكن للعميل بدء جلسة مع الخادم وإنشاء اتصال ثنائي الاتجاه.
• الخادم يحتوي على واجهة سطر أوامر تعمل بالكامل.
• يدعم العميل عددًا من الوظائف التي يمكن للخادم تكليفها.
• حجم العميل 5.2 كيلوبايت عند التصغير + التعتيم.
• التعتيم التلقائي غير مكتمل ويحتاج إلى إصلاح يدوي (انظر القيود في ملف README الخاص بالعميل).
• لا يدعم الخادم اللاعبين المتعددين (مشغلين متزامنين).

أمثلة

انظر الاستخدام في README الخاص بالعميل و README الخاص بالخادم للحصول على تعليمات محددة.

لبدء الخادم أو العميل، قم بتنفيذ البرامج النصية مباشرة أو مررها إلى مفسر Python.

تأكد من أن كل نطاق C2 لديه سجل NS مع عنوان IP للمضيف الذي يشغل server.py.

المتطلبات

يتطلب WEASEL Python 3.6+.

العميل مكتفي ذاتيًا ويستخدم فقط المكتبات القياسية، لذلك يمكن تشغيله على macOS و Linux وغيرها.

الخادم يحتوي على بعض التبعيات من pip، المضمنة في ملف requirements.txt الخاص بالخادم. يجب تشغيل الخادم على Linux، لكن لا شيء يمنع تشغيله على macOS أو أنظمة *nix أخرى.

الاختبار / التشغيل في بيئة التطوير

لا حاجة لتعتيم وتصغير المنارة في هذه الحالة. يتم الاحتفاظ بجمل الطباعة. كما هو الحال مع الاستخدام أعلاه، تأكد من أن سجلات NS للنطاق (النطاقات) في servers في beacon.py تشير إلى عنوان IP الخاص بـ server.py.

على مضيف الخادم:

sudo python3 server.py

على مضيف الضحية (يمكن أن يكون نفس الخادم):

python3 beacon.py

الهندسة المعمارية

لا تحتاج إلى فهم أي من هذا لاستخدام WEASEL.

تتواصل المنارة عبر DNS باستخدام استعلامات وإجابات AAAA. لا تستخدم سجلات TXT لأنها معروفة باستخدامها من قبل برامج DNS الضارة والأنفاق. غالبًا ما يكون لدى الفرق الزرقاء اكتشافات نفق DNS التي تنبه على استعلامات TXT الكبيرة.

لا يحتاج جانب العميل إلى صلاحيات الجذر للعمل، ولا يستخدم مقابس خام، ولا ينشئ حزم DNS مشوهة. يستخدم واجهات النظام واللغة العادية لتقديم طلبات DNS. يتم ترميز المعلومات + تشفيرها في السجلات نفسها.

• يمكن لسجل A واحد (عنوان IPv4) أن يحتوي على 4 بايتات من المعلومات.
• يمكن لسجل AAAA واحد (عنوان IPv6) أن يحتوي على 16 بايت من المعلومات.
• يمكن لسجلات CNAME وأسماء المضيفين المستخدمة في الاستعلامات أن تحتوي على ما يصل إلى 64 بايت لكل نطاق فرعي ويجب ألا يزيد طولها عن 255 بايت إجمالاً وفقًا لـ RFC. ومع ذلك، تنص إرشادات اكتشاف DNS من SANS على أن النطاقات الفرعية التي يزيد طولها عن 52 حرفًا مشبوهة. لهذا السبب، نحدد النطاقات الفرعية إلى 52 حرفًا (قابلة للتكوين في الكود) ونحاول استخدام أقل عدد ممكن من النطاقات الفرعية والطلبات.
• يمكن أن تحتوي الاستجابة على سجلات متعددة، حتى الحد الأقصى لحجم مخطط بيانات UDP (65,507 بايت).

تم تصميم هذه المنارة لتكون منخفضة وبطيئة، مع عرض نطاق ترددي قليل. يجب أن تخبرنا عن المضيفين الذين تتواجد عليهم وتوفر لنا طريقة لإطلاق مراحل أخرى حسب الحاجة، ولا شيء أكثر. على الرغم من أنها تدعم الأوامر العشوائية، إلا أنها ليست مصممة للاستخدام كقشرة تفاعلية منتظمة أو قناة اتصال.

WEASEL هي مرحلة أولى تتركها قيد التشغيل، مما يضمن الوصول المستمر عندما يتم اكتشاف مراحلك الكاملة (وبالتالي الأكثر ضوضاءً).

الاستمرارية

استهدفت WEASEL في البداية الخوادم ذات وقت التشغيل العالي حيث كان لدينا موطئ قدم/ناقل استغلال موثوق. كان تجنب التحقيق الجنائي أولوية عالية. نتيجة لذلك، ليس لديها ميزات استمرارية أصلية.

يمكنك جعلها مستمرة عن طريق إضافة تنفيذها إلى تقنية الاستمرارية المفضلة لديك، وهذا متروك للقارئ :)

البروتوكول وتنسيق الرسالة

طلب العميل

الطلب (من العميل) هو استعلام AAAA واحد لاسم مهيأ كالتالي:

<preamble><data>.<stream>.<session>.domain.tld

المقدمة هي 2 بايت. Preamble[0] هو رقم تسلسل تلك الحزمة. Preamble[1] هو العدد الإجمالي للحزم في ذلك التدفق.

البيانات محددة بـ 50 بايت (قابلة للتكوين) وتحتوي على الحمولة. يتم ترميز الحمولة بـ base32 باستخدام أبجدية مخصصة.

ترميز الحمولة

أولاً، يتم استبدال جميع أحرف 'w' بـ '-'.

بعد ذلك، يتم استبدال حرف الحشو من '=' إلى 'w' للتوافق مع مجموعة أحرف DNS: [a-z0-9] و [-].

لا نستبدل '=' بـ '-' مباشرة لأن الحشو سيكون دائمًا في نهاية السلسلة، وإنهاء اسم مضيف بـ '---' هو أمر مشبوه ويخالف RFC DNS. بهذه الطريقة، عندما تحتوي السلسلة على حشو، ستنتهي بـ 'www'، وهو أقل إثارة للشك ويتوافق مع RFC.

استجابة الخادم

الاستجابة (من الخادم) تتكون من إجابة AAAA واحدة أو أكثر.

كل إجابة AAAA هي حمولة مشفرة بحجم 16 بايت ممثلة كعنوان IPv6 باستخدام socket.inet_ntop. الإجابات في استجابة DNS لا تحافظ على ترتيبها أثناء النقل، لذلك يتم تسلسلها وإعادة تجميعها مثل طلبات العميل.

الحمولة الناقلة هي سلسلة من عناصر البيانات مفصولة بحرف ^.

تنسيق النقل

يتبع الطلبات والاستجابات هذا التنسيق:

<type>|<data>

الجلسات

الجلسات طويلة العمر: يبدأ العميل جلسة عند تنفيذ المنارة لأول مرة ويجب أن تستمر الجلسة طوال الوقت الذي تكون فيه المنارة نشطة على ذلك العميل. لاحظ أنه نظرًا لأن المنارة تعمل في الذاكرة وليست مستمرة، يتم تخزين بيانات الجلسة في ذاكرة عملية Python تلك. أي استدعاء جديد للمنارة سيبدأ جلسة جديدة.

يتضمن بدء جلسة قيام العميل بصياغة رسالة بمقدمة غير بيانات فريدة (للإشارة إلى الخادم بأن هذه جلسة جديدة): سلسلة من مفتاح عام Diffie-Hellman بحجم 32 بايت و IV عشوائي لـ AES بحجم 16 بايت.

يستقبل الخادم هذا ويرد بمفتاح عام خاص به بحجم 32 بايت. في هذه المرحلة، يكون العميل والخادم قد أنشأا مفتاح جلسة مشترك سيستخدم طوال عمر هذه الجلسة لتشفير حمولات البيانات باستخدام AES-128 في وضع CTR. يضمن تبادل Diffie-Hellman المؤقت أن كل اتصال بين العميل والخادم يستخدم مفتاح جلسة فريد مع سرية تامة.

ضعف التشفير

التشفير ضعيف عن قصد لعدة أسباب:

• نحن نحاكي المهاجمين الحقيقيين الذين ليس لديهم بشكل عام فكرة عن كيفية بناء أنظمة تشفير قوية وهم من محبي بناء أنظمتهم الخاصة
• عرض النطاق الترددي للمنارة منخفض بقدر الإمكان، مما يعني أن تبادل DHE الخاص بنا يجب أن يبقى صغيرًا جدًا
• عدم الإسناد مهم، لا نصادق على الخادم
• إنها أقل متعة للمستجيبين إذا استخدمنا تشفيرًا حديثًا لا يمكنهم أمل في كسره

فيما يلي بعض المشكلات المعروفة في مخطط التشفير:

1. معامل Diffie-Hellman p هو RFC 3526 Group 5 مختصر إلى أول 32 بايت. لا يقتصر هذا على الحد من المفاتيح العامة والخاصة إلى 32 بايت فحسب، بل إن Group 5 قد تم إهماله بالفعل ويوصى بعدم استخدامه. أسمي هذا القرار السيئ "Group 1".
2. نستخدم random.randint() للأس a بدلاً من CSPRNG.
3. نستخدم كمية صغيرة من البيانات من os.urandom() لتوليد معرف الجلسة ومعرف التدفق بدلاً من UUID، مما يعني أن التصادمات محتملة. نأخذ هذا في الاعتبار عن طريق إعادة المحاولة حتى نحصل على معرف غير مستخدم.
4. يتم إعادة تهيئة تشفير AES-CTR بنفس IV (الذي يعيش طويلاً مثل مفتاح الجلسة) لكل تدفق. هذا يعني أن نفس النص العادي في نفس الموضع عبر التدفقات سينتج نفس النص المشفر.
5. في AES-CTR، يُسمى IV بشكل صحيح nonce، ولكن في تنفيذنا نحن لا نستخدم الرقم مرة واحدة، لذا سيكون من الوقاحة تسميته بذلك.

التدفقات

يجب تجزئة كل رسالة ترسل بين العميل والخادم إلى حزم بحد أقصى 50 بايت، للبقاء تحت حد 52 بايت لاكتشافات قنوات DNS الخفية الشائعة. جميع الحزم لرسالة معينة تكون جزءًا من نفس التدفق. الرسالة == التدفق.

يتم تحديد التدفقات برقم سداسي عشري عشوائي بحجم 2 بايت. تذكر أن تنسيق طلب العميل هو: <preamble><data>.<stream>.<session>.domain.tld

المقدمة ذات البايتين لكل حزمة في التدفق تحتوي على رقم تسلسل والعدد الإجمالي للحزم في ذلك التدفق. وهذا يمكن الخادم من معرفة متى وصل كل شيء.

نظرًا لأن هذا يتم عبر DNS عبر UDP، والذي لا يوفر أي ضمانات حول ترتيب وصول الرزم. لهذا السبب يجب على WEASEL مراعاة التسلسل وإعادة التجميع وتتبع تدفقات متعددة من العديد من المنارات.

يعيد كل تدفق تهيئة تشفير AES-128-CTR المشترك عالميًا لتشفير/فك تشفير الحمولات.

يمكن فك تشفير الحمولة فقط بمجرد اكتمال التدفق (وصول جميع الحزم). لولا base32، لتمكنا من فك تشفير ما لدينا من الرسالة حتى لو كانت الحزم مفقودة (لأن AES-CTR هو تشفير تدفقي) لكننا لا نستطيع فك ترميز base32 لتدفقات جزئية. حسنًا. بحكم طبيعة عملاء DNS، يتم تقديم الطلبات عدة مرات (عادةً 2 أو 4 مرات) حتى يتم تلقي استجابة، لذا لدينا احتمالية جيدة أننا سنستقبل جميع الحزم في التدفق حيث يجب أن يرسل العميل كل حزمة مرتين على الأقل. إذا فقدنا حزمًا أو تدفقات، فهذا ليس مشكلة كبيرة، ستتحقق المنارة مرة أخرى لاحقًا وربما يكون حظها أفضل حينها.

انضم إلى مجتمع WEASEL

انظر ملف المساهمة لمعرفة كيفية المساعدة.

الترخيص

WEASEL مرخصة بموجب MIT، كما هو موجود في ملف الترخيص.