
إثبات مفهوم لثغرة CVE-2025-40778: تسميم ذاكرة التخزين المؤقت لنظام DNS في BIND 9 عبر سجلات قسم إضافية غير مرغوب فيها.
تتيح هذه الثغرة الأمنية للمهاجم إفساد ذاكرة التخزين المؤقت لنظام DNS في خادم BIND، مما يجبر المستخدمين الشرعيين على إعادة التوجيه إلى عناوين IP خبيثة دون علمهم.
يعتمد الهجوم على استغلال الثقة. الضحية تثق في الخادم المُحلِّل (Resolver)، والخادم المُحلِّل (BIND) يثق في الإجابات التي يتلقاها من الخوادم الموثوقة (Authoritative Servers). يكمن الخلل في أن BIND يعالج ويخزن مؤقتًا البيانات غير المطلوبة المقدمة في قسم ADDITIONAL من استجابة DNS، حتى لو كانت هذه البيانات تخص نطاقًا مختلفًا تمامًا وغير مطلوب.
الإعداد: يتحكم المهاجم في خادم DNS موثوق (Authoritative) خبيث لنطاق معين (مثل poc.lab). ينتظر المهاجم حتى يقوم الخادم المُحلِّل المستهدف (BIND) بطرح استعلام حول هذا النطاق.
الحقن: عندما يستعلم الخادم المُحلِّل من خادم المهاجم عن poc.lab، يستجيب المهاجم بإجابة شرعية عن poc.lab ولكنه يتضمن إجابة غير مرغوب فيها في قسم ADDITIONAL لنطاق مختلف (في مثالنا www.hacker.com، ويمكن أن يكون أي نطاق شرعي مثل facebook.com) تشير إلى عنوان IP خبيث.
التسميم: بسبب الثغرة الأمنية، يقبل الخادم المُحلِّل السجل غير المرغوب فيه "Additional" ويخزنه في ذاكرة التخزين المؤقت، دون التحقق من أن المهاجم لا يملك سلطة على النطاق غير المطلوب.
استعلام الضحية: عندما تستعلم الضحية لاحقًا من الخادم المُحلِّل عن النطاق غير المطلوب (www.hacker.com)، يُرجع الخادم المُحلِّل السجل المسموم من ذاكرة التخزين المؤقت، مما يعيد توجيه الضحية إلى عنوان IP الخبيث الذي يتحكم فيه المهاجم.
[!IMPORTANT]
الخلاصات الرئيسية لهذا الإثبات (PoC)
الهجوم غير المباشر: لا تتواصل الضحية مع المهاجم بشكل مباشر أبدًا.
اختراق نقطة الثقة: جهاز الضحية يعمل بشكل صحيح؛ إنها البنية التحتية (DNS) هي التي تكذب.
الآلية: يستغل هذا الإثبات معالجة قسم ADDITIONAL لحقن سجلات لم تُطلب أبدًا.
[!CAUTION]
هذا الإثبات (PoC) مخصص للأغراض التعليمية فقط. الاستخدام غير المصرح به لهذه المعلومات لاختراق الأنظمة أمر غير قانوني وغير أخلاقي. احصل دائمًا على إذن قبل اختبار أو استغلال الثغرات الأمنية على أي شبكة أو نظام.
تُستخدم الأجهزة الافتراضية التالية في هذا العرض التوضيحي:
الأوامر التالية مخصصة لإعداد BIND 9.21.12 على نظام قائم على Debian لتوضيح الثغرة الأمنية CVE-2025-40778.
[!NOTE] يستخدم هذا العرض التوضيحي BIND 9.21.12، وهو أحد الإصدارات المتأثرة بهذه الثغرة الأمنية.
تشمل النطاقات المعروفة الأخرى للإصدارات المتأثرة ما يلي:
- 9.11.0 – 9.16.50
- 9.18.0 – 9.18.39
- 9.20.0 – 9.20.13
- 9.21.0 – 9.21.12
ستقوم الأوامر التالية بتثبيت التبعيات الضرورية، وتنزيل الكود المصدري لـ BIND 9.21.12، وترجمته، وتثبيته على النظام.
sudo apt install -y build-essential pkg-config perl meson ninja-build libssl-dev libuv1-dev liburcu-dev libcap-dev liblmdb-dev libnghttp2-dev
cd /usr/local/src
sudo wget -O bind-9.21.12.tar.xz https://isc.mirrorservice.org/bind/9.21.12/bind-9.21.12.tar.xz
sudo tar -xf bind-9.21.12.tar.xz
cd bind-9.21.12
sudo meson setup build --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var
sudo ninja -C build
sudo ninja -C build install
echo /usr/local/lib/x86_64-linux-gnu | sudo tee /etc/ld.so.conf.d/bind9-local.conf
sudo ldconfig
ldconfig -p | grep 'libdns-9.21.12' || true
/usr/local/sbin/named -v
فيما يلي المخرجات المتوقعة للأمر الأخير:
> student@student:/usr/local/src/bind-9.21.12$ /usr/local/sbin/named -v
BIND 9.21.12 (Development Release) <id:9bafc35>
قبل بدء تشغيل خادم BIND، نحتاج إلى إنشاء مستخدم ومجموعة مخصصين لتشغيل خدمة named:
sudo groupadd --system named 2>/dev/null || true
sudo useradd --system --no-create-home --home /nonexistent --shell /usr/sbin/nologin --gid named named 2>/dev/null || true
نظرًا لأن هذا التثبيت لـ BIND لا يأتي مع ملفات إعداد افتراضية، نحتاج إلى إنشاء الدلائل الضرورية يدويًا:
sudo mkdir -p /etc/bind
sudo mkdir -p /var/cache/bind
sudo mkdir -p /var/log/named
sudo mkdir -p /var/run/named
sudo chown -R named:named /var/cache/bind /var/log/named /var/run/named
sudo chmod 750 /var/cache/bind /var/log/named /var/run/named
الخطوة التالية هي إنشاء ملف الإعداد الرئيسي /etc/bind/named.conf بالمحتوى التالي:
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.logging";
include "/etc/rndc.key";
بخصوص إعدادات الخيارات، أنشئ الملف /etc/bind/named.conf.options بالمحتوى التالي:
options {
directory "/var/cache/bind";
recursion yes;
allow-recursion { 192.168.174.0/24; };
allow-query { 192.168.174.0/24; };
listen-on { 192.168.174.131; 127.0.0.1; };
listen-on-v6 { none; };
dnssec-validation no;
forwarders {
1.1.1.1;
8.8.8.8;
};
minimal-responses no;
// for manual start
pid-file "/var/run/named/named.pid";
};
من أجل إعداد منطقة إعادة توجيه (forward zone) للنطاق poc.lab لإعادة توجيه الاستعلامات إلى خادم DNS الخاص بالمهاجم على العنوان 192.168.174.130 والمنفذ القياسي 53، نحتاج إلى تعديل ملف /etc/bind/named.conf.local على النحو التالي:
zone "poc.lab" {
type forward;
forward only;
forwarders { 192.168.174.130; };
};
بخصوص إعدادات التسجيل، أنشئ الملف /etc/bind/named.conf.logging بحيث يحتوي على:
logging {
channel queries_file {
file "/var/log/named/queries.log" versions 3 size 20m;
severity info;
print-time yes;
print-category yes;
};
channel default_stderr {
stderr;
severity info;
print-time yes;
print-category yes;
};
category queries { queries_file; };
category default { default_stderr; };
};
أخيرًا، نحتاج إلى إعداد RNDC:
sudo /usr/local/sbin/rndc-confgen -a -c /etc/bind/rndc.key
sudo chown root:named /etc/bind/rndc.key
sudo chmod 640 /etc/bind/rndc.key
أولاً، نحتاج إلى التأكد من أن المنفذ 53 غير مستخدم من قبل أي خدمة أخرى (في حالتنا اضطررنا إلى تعطيل systemd-resolved):
sudo systemctl disable --now systemd-resolved || true
sudo ss -lunp | grep ':53' || true # To verify that port 53 is free
أخيرًا، يمكننا بدء تشغيل خادم BIND باستخدام الأمر التالي:
sudo /usr/local/sbin/named -g -u named -c /etc/bind/named.conf
[!TIP]
للتحقق من أن BIND يعمل بشكل صحيح، يمكننا استخدام الأمر التالي:
ss -lunpt | grep :53
بالنسبة لجهاز الضحية، نحتاج إلى تعيينه لاستخدام خادم BIND كخادم محلل DNS خاص به. أيضًا، علينا تعطيل systemd-resolved لتجنب التعارضات:
sudo systemctl disable --now systemd-resolved
ثم يمكننا تعيين خادم DNS ثابت باستخدام الأوامر التالية:
sudo rm -f /etc/resolv.conf
sudo nano /etc/resolv.conf
> nameserver 192.168.174.129
> options timeout:1 attempts:1
sudo chattr +i /etc/resolv.conf #block overwrites
على جهاز المهاجم، نحتاج إلى تشغيل السكربت الموجود في المستودع (attacker.py).
في السيناريو الخاص بنا، يتحكم المهاجم في نطاق poc.lab. عندما يُطلب هذا النطاق أو أي نطاق فرعي منه، يضيف سجل إجابة غير مرغوب فيه (www.hacker.com) يشير إلى عنوان IP الخاص به.
عندما تستعلم الضحية عن النطاق poc.lab، يقوم خادم BIND بإعادة توجيه الطلب إلى خادم DNS الخاص بالمهاجم. يستجيب المهاجم بسجل إجابة غير مرغوب فيه يعمل على تسميم ذاكرة التخزين المؤقت لخادم BIND. وعندما تصل الضحية إلى www.hacker.com، ستتم إعادة توجيهها إلى عنوان IP الخاص بالمهاجم بدلاً من العنوان الشرعي.
فيما يلي توضيح لاستعلام الضحية عن كلا النطاقين:
student@student:~/Desktop$ dig www.poc.lab +noall +answer
www.poc.lab. 60 IN A 192.168.174.99
student@student:~/Desktop$ dig www.hacker.com +noall +answer
www.hacker.com. 60 IN A 192.168.174.130
كما هو موضح أعلاه، يُرجع استعلام DNS الخاص بالضحية عن www.hacker.com عنوان IP الخاص بالمهاجم (192.168.174.130).
[!NOTE]
هذا الفيديو هو توضيح للثغرة الموضحة: https://drive.google.com/file/d/1PATD0tUqw8-BipfSf6TkQQfnJBvV110Z/view?usp=sharing