🥇შროდინგერის სანდო ჩამოტვირთვა. Intel Boot Guard

ჩვენ ვთავაზობთ ისევ დაბალ დონეზე ჩამოსვლას და ვისაუბროთ firmware x86-თან თავსებადი კომპიუტერული პლატფორმების უსაფრთხოებაზე. ამჯერად, კვლევის მთავარი ინგრედიენტია Intel Boot Guard (არ უნდა აგვერიოს Intel BIOS Guard-ში!) - ტექნიკის მხარდაჭერით BIOS სანდო ჩატვირთვის ტექნოლოგია, რომელიც კომპიუტერული სისტემის გამყიდველს შეუძლია სამუდამოდ ჩართოს ან გამორთოს წარმოების ეტაპზე. ისე, ჩვენ უკვე ვიცით კვლევის რეცეპტი: წვრილად დავჭრათ ამ ტექნოლოგიის დანერგვა საპირისპირო ინჟინერიით, აღწერეთ მისი არქიტექტურა, შეავსეთ იგი დაუსაბუთებელი დეტალებით, დააგემოვნეთ შეტევის ვექტორებით გემოვნებით და აურიეთ. მოდით დავამატოთ ცეცხლი ამბავი იმის შესახებ, თუ როგორ კლონირებული ხარვეზი რამდენიმე გამყიდველის წარმოებაში წლების განმავლობაში საშუალებას აძლევს პოტენციურ თავდამსხმელს გამოიყენოს ეს ტექნოლოგია ფარული rootkit-ის შესაქმნელად, რომლის ამოღებაც შეუძლებელია (თუნდაც პროგრამისტის მიერ) სისტემაში.

სხვათა შორის, სტატია ემყარება კონფერენციის მოხსენებებს „On Guard for Rootkits: Intel BootGuard“ ZeroNights 2016 წელი და 29-ე შეხვედრა დეფკონი რუსეთი (ორივე პრეზენტაცია აქ).

Firmware კომპიუტერული პლატფორმისთვის Intel 64 არქიტექტურით

დასაწყისისთვის, მოდით ვუპასუხოთ კითხვას: რა არის თანამედროვე კომპიუტერული პლატფორმის firmware Intel 64 არქიტექტურით? რა თქმა უნდა, UEFI BIOS. მაგრამ ეს პასუხი არ იქნება ზუსტი. მოდით შევხედოთ ფიგურას, რომელიც გვიჩვენებს ამ არქიტექტურის დესკტოპის (ლეპტოპის) ვერსიას.

საფუძველი არის ბმული:

პროცესორი (CPU, Central Processing Unit), რომელსაც ძირითადი ბირთვების გარდა აქვს ჩაშენებული გრაფიკული ბირთვი (არა ყველა მოდელში) და მეხსიერების კონტროლერი (IMC, Integrated Memory Controller);
ჩიპსეტი (PCH, Platform Controller Hub), რომელიც შეიცავს სხვადასხვა კონტროლერებს პერიფერიულ მოწყობილობებთან ურთიერთობისა და ქვესისტემების მართვისთვის. მათ შორის არის ცნობილი Intel Management Engine (ME), რომელსაც ასევე აქვს firmware (Intel ME firmware).

ლეპტოპებს, გარდა ზემოაღნიშნულისა, საჭიროებენ ინტეგრირებულ კონტროლერს (ACPI EC, Advanced Control and Power Interface Embedded Controller), რომელიც პასუხისმგებელია კვების ქვესისტემის მუშაობაზე, სენსორული პანელი, კლავიატურა, Fn კლავიშები (ეკრანის სიკაშკაშე, ხმის მოცულობა, კლავიატურა). განათება და ა.შ.) ) და სხვა. და მას ასევე აქვს საკუთარი firmware.

ამრიგად, ზემოაღნიშნული პროგრამული უზრუნველყოფის კომბინაცია არის კომპიუტერული პლატფორმის firmware (სისტემის firmware), რომელიც ინახება საერთო SPI ფლეშ მეხსიერებაზე. იმისათვის, რომ ამ მეხსიერების მომხმარებლები არ დაიბნენ სად დევს ვინმე, ამ მეხსიერების შინაარსი იყოფა შემდეგ რეგიონებად (როგორც ნაჩვენებია სურათზე):

UEFI BIOS;
ACPI EC firmware (გამოჩნდა ცალკე რეგიონი Skylake-ის პროცესორის მიკროარქიტექტურასთან ერთად (2015), მაგრამ ბუნებაში ჩვენ ჯერ არ გვინახავს მისი გამოყენების მაგალითები, ამიტომ ჩაშენებული კონტროლერის firmware კვლავ UEFI BIOS-ის ნაწილია);
Intel ME firmware;
ჩაშენებული GbE (Gigabit Ethernet) ქსელის ადაპტერის კონფიგურაცია (MAC მისამართი და ა.შ.);
ფლეშ დესკრიპტორები - ფლეშ მეხსიერების ძირითადი რეგიონი, რომელიც შეიცავს სხვა რეგიონების მითითებებს, ასევე მათზე წვდომის ნებართვებს.

რეგიონებში წვდომის დიფერენციაციას (მითითებული ნებართვების შესაბამისად) ახორციელებს SPI bus master - ჩიპსეტში ჩაშენებული SPI კონტროლერი, რომლის მეშვეობითაც ხდება ამ მეხსიერების წვდომა. თუ ნებართვები დაყენებულია Intel-ის მიერ რეკომენდებულ მნიშვნელობებზე (უსაფრთხოების მიზეზების გამო), მაშინ SPI flash-ის თითოეულ მომხმარებელს აქვს სრული წვდომა (წაკითხვა/ჩაწერა) მხოლოდ თავის რეგიონში. დანარჩენი ან მხოლოდ წასაკითხია ან მიუწვდომელია. ცნობილი ფაქტი: ბევრ სისტემაზე CPU-ს აქვს სრული წვდომა UEFI BIOS-ზე და GbE-ზე, წაკითხვის წვდომა მხოლოდ ფლეშ დესკრიპტორებზე და საერთოდ არ აქვს წვდომა Intel ME რეგიონში. რატომ ბევრი და არა ყველა? რაც რეკომენდირებულია არჩევითია. დაწვრილებით მოგვიანებით სტატიაში მოგიყვებით.

კომპიუტერული პლატფორმის პროგრამული უზრუნველყოფის მოდიფიკაციისგან დაცვის მექანიზმები

ცხადია, კომპიუტერული პლატფორმის პროგრამული უზრუნველყოფა დაცული უნდა იყოს შესაძლო კომპრომისისაგან, რაც პოტენციურ თავდამსხმელს საშუალებას მისცემს მასში დაიმკვიდროს ფეხი (გადარჩება ოპერაციული სისტემის განახლებები/ინსტალაციები), შეასრულოს მათი კოდი ყველაზე პრივილეგირებულ რეჟიმებში და ა.შ. და SPI ფლეშ მეხსიერების რეგიონებში წვდომის დელიმიტაცია, რა თქმა უნდა, არ არის საკმარისი. ამიტომ, სხვადასხვა მექანიზმები, რომლებიც სპეციფიკურია თითოეული აღსრულების გარემოსთვის, გამოიყენება პროგრამული უზრუნველყოფის ცვლილებებისგან დასაცავად.

ამრიგად, Intel ME firmware ხელმოწერილია მთლიანობისა და ავთენტურობის კონტროლისთვის და მოწმდება ME კონტროლერის მიერ ყოველ ჯერზე, როდესაც ის იტვირთება ME UMA მეხსიერებაში. ეს გადამოწმების პროცესი უკვე განვიხილეთ ჩვენ მიერ ერთ-ერთში სტატიებიეძღვნება Intel ME ქვესისტემას.

და ACPI EC firmware, როგორც წესი, მოწმდება მხოლოდ მთლიანობისთვის. თუმცა, იმის გამო, რომ ეს ორობითი შედის UEFI BIOS-ში, იგი თითქმის ყოველთვის ექვემდებარება იმავე დაცვის მექანიზმებს, რომლებსაც იყენებს UEFI BIOS. მოდით ვისაუბროთ მათზე.

ეს მექანიზმები შეიძლება დაიყოს ორ კატეგორიად.

ჩაწერეთ დაცვა UEFI BIOS რეგიონში

SPI ფლეშ მეხსიერების შიგთავსის ფიზიკური დაცვა ჩაწერის დამცავი ჯემპრით;
პროცესორის მისამართების სივრცეში UEFI BIOS რეგიონის პროექციის დაცვა ჩიპსეტის PRx რეგისტრების გამოყენებით;
UEFI BIOS რეგიონში ჩაწერის მცდელობების დაბლოკვა შესაბამისი SMI შეფერხების გენერირებით და დამუშავებით ჩიპსეტის რეგისტრებში BIOS_WE / BLE და SMM_BWP ბიტების დაყენებით;
ამ დაცვის უფრო მოწინავე ვერსიაა Intel BIOS Guard (PFAT).

ამ მექანიზმების გარდა, მოვაჭრეებს შეუძლიათ შეიმუშაონ და განახორციელონ საკუთარი უსაფრთხოების ზომები (მაგალითად, კაფსულების ხელმოწერა UEFI BIOS განახლებებით).

მნიშვნელოვანია აღინიშნოს, რომ კონკრეტულ სისტემაზე (დამოკიდებულია გამყიდველზე) ყველა ზემოთ ჩამოთვლილი დამცავი მექანიზმი შეიძლება არ იყოს გამოყენებული, ისინი შეიძლება საერთოდ არ იყოს გამოყენებული ან დაუცველად განხორციელდეს. ამ მექანიზმებისა და მათი განხორციელების ვითარების შესახებ მეტი შეგიძლიათ წაიკითხოთ აქ ეს მუხლი. დაინტერესებულ პირებს გირჩევთ, წაიკითხოთ სტატიების მთელი სერია UEFI BIOS უსაფრთხოების შესახებ CodeRush.

UEFI BIOS ავთენტიფიკაციის შემოწმება

როდესაც ვსაუბრობთ სანდო ჩატვირთვის ტექნოლოგიებზე, პირველი რაც მახსენდება არის უსაფრთხო ჩატვირთვა. თუმცა, არქიტექტურულად, ის შექმნილია UEFI BIOS-ის გარე კომპონენტების ავთენტიფიკაციისთვის (დრაივერები, მტვირთავები და ა.შ.) და არა თავად firmware.

ამიტომ, Intel-მა SoC-ებში Bay Trail მიკროარქიტექტურით (2012) დანერგა ტექნიკის შეუცვლელი Secure Boot (Verified Boot), რომელსაც არაფერი აქვს საერთო ზემოხსენებულ Secure Boot ტექნოლოგიასთან. მოგვიანებით (2013) ეს მექანიზმი გაუმჯობესდა და, სახელწოდებით Intel Boot Guard, გამოვიდა დესკტოპისთვის Haswell-ის მიკროარქიტექტურით.

სანამ Intel Boot Guard-ს აღვწერთ, მოდით შევხედოთ გაშვების პერიოდებს Intel 64 არქიტექტურაში, რომლებიც კომბინაციით არის სანდო ჩატვირთვის ტექნოლოგიის ნდობის საფუძველი.

Intel CPU

Cap ვარაუდობს, რომ პროცესორი არის მთავარი შესრულების გარემო Intel 64 არქიტექტურაში. რატომ არის ის ასევე ნდობის საფუძველი? გამოდის, რომ ეს არის შემდეგი ელემენტების ფლობა, რაც მას ასე ხდის:

Microcode ROM არის არასტაბილური, გადაწერილი მეხსიერება მიკროკოდის შესანახად. ითვლება, რომ მიკროკოდი არის პროცესორის ინსტრუქციის სისტემის განხორციელება უმარტივეს ინსტრუქციებზე. მიკროკოდშიც ხდება შეცდომები. ასე რომ, BIOS-ში შეგიძლიათ იპოვოთ ბინარები მიკროკოდის განახლებებით (ისინი გადატვირთულია ჩატვირთვის დროს, რადგან ROM-ის გადაწერა შეუძლებელია). ამ ბინარების შინაარსი დაშიფრულია, რაც მნიშვნელოვნად ართულებს ანალიზს (აქედან გამომდინარე, მიკროკოდის სპეციფიკური შინაარსი ცნობილია მხოლოდ მათთვის, ვინც მას ავითარებს) და ხელმოწერილია მთლიანობისა და ავთენტურობის გასაკონტროლებლად;
AES გასაღები მიკროკოდის განახლებების შინაარსის გაშიფვრისთვის;
RSA საჯარო გასაღების ჰეში, რომელიც ამოწმებს მიკროკოდის განახლების ხელმოწერას;
RSA საჯარო გასაღების ჰეში, რომელიც ამოწმებს Intel-ის მიერ შემუშავებული ACM (Authenticated Code Module) კოდის მოდულების ხელმოწერას, რომლებიც CPU-ს შეუძლია გაუშვას BIOS-ის დაწყებამდე (გამარჯობა მიკროკოდი) ან მისი მუშაობის დროს, როდესაც ხდება გარკვეული მოვლენები.

Intel ME

ჩვენს ბლოგში ეს ქვესისტემა მიეძღვნა две მუხლი. შეგახსენებთ, რომ ეს შესრულებადი გარემო ეფუძნება ჩიპსეტში ჩაშენებულ მიკროკონტროლერს და არის ყველაზე დამალული და პრივილეგირებული სისტემაში.

საიდუმლოების მიუხედავად, Intel ME ასევე არის ნდობის საფუძველი, რადგან მას აქვს:

ME ROM - არასტაბილური, გადაწერადი მეხსიერება (არ არის მოწოდებული განახლების მეთოდი), რომელიც შეიცავს დაწყების კოდს, ასევე RSA საჯარო გასაღების SHA256 ჰეშს, რომელიც ამოწმებს Intel ME firmware-ის ხელმოწერას;
AES გასაღები საიდუმლო ინფორმაციის შესანახად;
წვდომა საკრავებზე (FPFs, Field Programmable Fuses) ინტეგრირებული ჩიპსეტში გარკვეული ინფორმაციის მუდმივი შენახვისთვის, მათ შორის კომპიუტერული სისტემის გამყიდველის მიერ მითითებულ ინფორმაციას.

Intel Boot Guard 1.x

მცირე უარი პასუხისმგებლობაზე. Intel Boot Guard ტექნოლოგიის ვერსიების ნომრები, რომელსაც ჩვენ ვიყენებთ ამ სტატიაში, არის თვითნებური და შეიძლება არ ჰქონდეს რაიმე კავშირი Intel-ის შიდა დოკუმენტაციაში გამოყენებულ ნუმერაციასთან. გარდა ამისა, აქ მოცემული ამ ტექნოლოგიის დანერგვის შესახებ ინფორმაცია მიღებული იქნა საპირისპირო ინჟინერიის დროს და შეიძლება შეიცავდეს უზუსტობებს Intel Boot Guard-ის სპეციფიკაციასთან შედარებით, რომელიც ნაკლებად სავარაუდოა, რომ ოდესმე გამოქვეყნდეს.

ასე რომ, Intel Boot Guard (BG) არის აპარატურის მხარდაჭერილი UEFI BIOS ავთენტიფიკაციის ტექნოლოგია. ვიმსჯელებთ წიგნში მისი მცირე აღწერილობით [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], ის მუშაობს როგორც სანდო ჩატვირთვის ჯაჭვი. და მასში პირველი ბმული არის ჩატვირთვის კოდი (მიკროკოდი) CPU-ს შიგნით, რომელიც გამოწვეულია RESET მოვლენით (არ უნდა აგვერიოს BIOS-ის RESET ვექტორთან!). CPU პოულობს კოდის მოდულს (Intel BG startup ACM) შემუშავებული და ხელმოწერილი Intel-ის მიერ SPI ფლეშ მეხსიერებაზე, ატვირთავს მას თავის ქეშში, ამოწმებს (ზემოთ უკვე აღინიშნა, რომ CPU-ს აქვს საჯარო გასაღების ჰეში, რომელიც ამოწმებს ACM ხელმოწერას. ) და იწყება.

კოდის ეს მოდული პასუხისმგებელია UEFI BIOS-ის მცირე საწყისი ნაწილის გადამოწმებაზე - Initial Boot Block (IBB), რომელიც, თავის მხრივ, შეიცავს UEFI BIOS-ის ძირითადი ნაწილის გადამოწმების ფუნქციას. ამრიგად, Intel BG საშუალებას გაძლევთ გადაამოწმოთ BIOS-ის ავთენტურობა OS-ის ჩატვირთვამდე (რომელიც შეიძლება შესრულდეს Secure Boot ტექნოლოგიის ზედამხედველობით).

Intel BG ტექნოლოგია უზრუნველყოფს მუშაობის ორ რეჟიმს (და ერთი არ ერევა მეორეს, ანუ ორივე რეჟიმი შეიძლება ჩართოთ სისტემაში და ორივე გამორთოთ).

გაზომილი ჩექმა

გაზომილი ჩატვირთვის (MB) რეჟიმში, თითოეული ჩატვირთვის კომპონენტი (დაწყებული CPU ჩატვირთვის ROM-ით) "ზომავს" შემდეგს სანდო პლატფორმის მოდულის (TPM) შესაძლებლობების გამოყენებით. ვინც არ იცის, ნება მომეცით აგიხსნათ.

TPM-ს აქვს PCR-ები (პლატფორმის კონფიგურაციის რეგისტრები), რომლებიც ჩაწერენ ჰეშირების ოპერაციის შედეგს ფორმულის მიხედვით:

იმათ. ამჟამინდელი PCR მნიშვნელობა დამოკიდებულია წინაზე და ეს რეგისტრები გადატვირთულია მხოლოდ მაშინ, როდესაც სისტემა გადატვირთულია.

ამრიგად, MB რეჟიმში, დროის გარკვეულ მომენტში, PCR-ები ასახავს უნიკალურ (ჰეშის ოპერაციის შესაძლებლობების ფარგლებში) კოდის ან მონაცემების "გაზომილი" იდენტიფიკატორს. PCR მნიშვნელობები შეიძლება გამოყენებულ იქნას ზოგიერთი მონაცემების (TPM_Seal) ოპერაციის დაშიფვრაში. ამის შემდეგ, მათი გაშიფვრა (TPM_Unseal) შესაძლებელი იქნება მხოლოდ იმ შემთხვევაში, თუ PCR მნიშვნელობები არ შეცვლილა დატვირთვის შედეგად (ანუ არც ერთი „გაზომილი“ კომპონენტი არ შეცვლილა).

დამოწმებული ჩატვირთვა

ყველაზე საშინელი მათთვის, ვისაც UEFI BIOS-ის შეცვლა მოსწონს, არის Verified Boot (VB) რეჟიმი, რომელშიც თითოეული ჩატვირთვის კომპონენტი კრიპტოგრაფიულად ამოწმებს შემდეგის მთლიანობასა და ავთენტურობას. და ვერიფიკაციის შეცდომის შემთხვევაში (ერთ-ერთი შემდეგი) ხდება:

გამორთვა დროით 1 წუთიდან 30 წუთამდე (ისე, რომ მომხმარებელს აქვს დრო, გაიგოს, რატომ არ ჩაიტვირთება მისი კომპიუტერი და, თუ ეს შესაძლებელია, შეეცდება BIOS-ის აღდგენას);
დაუყოვნებელი გამორთვა (ისე, რომ მომხმარებელს არ ჰქონდეს დრო, რომ გაიგოს და, უფრო მეტიც, გააკეთოს);
სამუშაოს გაგრძელება სწორი სახით (შემთხვევა, როდესაც უსაფრთხოების დრო არ არის, რადგან უფრო მნიშვნელოვანი საქმეებია გასაკეთებელი).

მოქმედების არჩევანი დამოკიდებულია მითითებულ Intel BG კონფიგურაციაზე (კერძოდ, ე.წ. აღსრულების პოლიტიკაზე), რომელიც მუდმივად არის ჩაწერილი კომპიუტერული პლატფორმის გამყიდველის მიერ სპეციალურად შექმნილ საცავში - ჩიპსეტის ფუჟები (FPF). ამ საკითხზე უფრო დეტალურად მოგვიანებით ვისაუბრებთ.

კონფიგურაციის გარდა, გამყიდველი ქმნის ორ RSA 2048 კლავიშს და ქმნის მონაცემთა ორ სტრუქტურას (ნაჩვენებია სურათზე):

გამყიდველის ძირეული გასაღების მანიფესტი (KEYM, OEM Root Key Manifest), რომელიც აყენებს ამ მანიფესტის SVN-ს (უსაფრთხოების ვერსიის ნომერს), შემდეგი მანიფესტის საჯარო გასაღების SHA256 ჰეშს, RSA საჯარო გასაღებს (ანუ საჯარო ნაწილს. გამყიდველის root გასაღები) ამ მანიფესტის ხელმოწერისა და თავად ხელმოწერის დასადასტურებლად;
IBB Manifest (IBBM, Initial Boot Block Manifest), რომელიც აყენებს ამ მანიფესტის SVN-ს, IBB-ის SHA256 ჰეშს, ამ მანიფესტის ხელმოწერის გადამოწმების საჯარო კლავიშს და თავად ხელმოწერას.

OEM Root Key-ის SHA256 ჰეში მუდმივად არის ჩაწერილი ჩიპსეტის ფუჟებზე (FPF), ისევე როგორც Intel BG კონფიგურაციაში. თუ Intel BG კონფიგურაცია ითვალისწინებს ამ ტექნოლოგიის ჩართვას, მაშინ ამიერიდან ამ სისტემას მხოლოდ OEM Root Key-ის პირადი ნაწილის მფლობელს შეუძლია BIOS-ის განახლება (ანუ შეძლებს ამ მანიფესტების ხელახლა გამოთვლას), ე.ი. გამყიდველი.

როდესაც სურათს უყურებ, მაშინვე ჩნდება ეჭვი ასეთი გრძელი გადამოწმების ჯაჭვის საჭიროების შესახებ - შეგეძლო გამოეყენებინა ერთი მანიფესტი. რატომ ართულებს?

სინამდვილეში, Intel ამგვარად აძლევს გამყიდველს შესაძლებლობას გამოიყენოს სხვადასხვა IBB კლავიშები სხვადასხვა პროდუქტის ხაზისთვის და ერთი, როგორც root. თუ IBB გასაღების პირადი ნაწილი (რომელიც ხელს აწერს მეორე მანიფესტს) გაჟონა, ინციდენტი იმოქმედებს მხოლოდ ერთ პროდუქტის ხაზზე და მხოლოდ მანამ, სანამ გამყიდველი არ გამოიმუშავებს ახალ წყვილს და არ ჩართავს ხელახლა გამოთვლილ მანიფესტებს BIOS-ის შემდეგ განახლებაში.

მაგრამ თუ root გასაღები გატეხილია (რომლითაც ხელმოწერილია პირველი მანიფესტი), მისი ჩანაცვლება შეუძლებელი იქნება, გაუქმების პროცედურა არ არის გათვალისწინებული. ამ გასაღების საჯარო ნაწილის ჰეში ერთხელ და სამუდამოდ დაპროგრამდება FPF-ებში.

Intel Boot Guard კონფიგურაცია

ახლა მოდით უფრო ახლოს გადავხედოთ Intel BG კონფიგურაციას და მისი შექმნის პროცესს. თუ დააკვირდებით Flash Image Tool-ის შესაბამის ჩანართს Intel System Tool Kit-დან (STK), შეამჩნევთ, რომ Intel BG კონფიგურაცია შეიცავს გამყიდველის root გასაღების საჯარო ნაწილის ჰეშს, რამდენიმე ბუნდოვანს. ღირებულებები და ა.შ. Intel BG პროფილი.

ამ პროფილის სტრუქტურა:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

ზოგადად, Intel BG კონფიგურაცია ძალიან მოქნილი პირია. განვიხილოთ, მაგალითად, Force_Boot_Guard_ACM დროშა. როდესაც ის გასუფთავდება, თუ BG გაშვების ACM მოდული SPI ფლეშზე ვერ მოიძებნა, სანდო ჩატვირთვა არ მოხდება. არასანდო იქნება.

ჩვენ უკვე დავწერეთ ზემოთ, რომ VB რეჟიმის აღსრულების პოლიტიკა შეიძლება იყოს კონფიგურირებული ისე, რომ თუ ვერიფიკაცია ვერ მოხერხდა, კვლავ მოხდება არასანდო ჩამოტვირთვა.

მიატოვეთ მსგავსი რამ გამყიდველებს...

პროგრამის GUI გთავაზობთ შემდეგ "მზა" პროფილებს:

ნომერი
რეჟიმი
აღწერა

0
No_FVME
Intel BG ტექნოლოგია გამორთულია

1
VE
VB რეჟიმი ჩართულია, გამორთვა ვადამდე

2
VME
ორივე რეჟიმი ჩართულია (VB და MB), გამორთვა დროით

3
VM
ორივე რეჟიმი ჩართულია სისტემის გამორთვის გარეშე

4
ხუთი
ჩართულია VB რეჟიმი, მყისიერი გამორთვა

5
FVME
ორივე რეჟიმი ჩართულია, მყისიერი გამორთვა

როგორც უკვე აღვნიშნეთ, Intel BG კონფიგურაცია ერთხელ და სამუდამოდ უნდა ჩაიწეროს სისტემის გამყიდველმა ჩიპსეტის ფუჟებში (FPF) - მცირე (დაუმოწმებელი ინფორმაციის მიხედვით, მხოლოდ 256 ბაიტი) აპარატურის ინფორმაციის შენახვა ჩიპსეტის შიგნით, რომელიც შეიძლება დაპროგრამდეს გარეთ. Intel-ის საწარმოო ობიექტებზე (ამიტომაც ველის პროგრამირებადი საკრავები).

ეს შესანიშნავია კონფიგურაციის შესანახად, რადგან:

აქვს ერთჯერადი პროგრამირებადი მონაცემთა შენახვის არე (მხოლოდ იქ, სადაც იწერება Intel BG კონფიგურაცია);
მხოლოდ Intel ME-ს შეუძლია მისი წაკითხვა და დაპროგრამება.

ასე რომ, იმისათვის, რომ დააყენოთ Intel BG ტექნოლოგიის კონფიგურაცია კონკრეტულ სისტემაზე, გამყიდველი აკეთებს შემდეგს წარმოების დროს:

Flash Image Tool-ის გამოყენებით (Intel STK-დან), ქმნის firmware სურათს მოცემული Intel BG კონფიგურაციით, როგორც ცვლადები Intel ME რეგიონში (ე.წ. დროებითი სარკე FPF-ებისთვის);
Flash Programming Tool-ის გამოყენებით (Intel STK-დან) წერს ამ სურათს სისტემის SPI ფლეშ მეხსიერებაში და ხურავს ე.წ. წარმოების რეჟიმი (ამ შემთხვევაში, შესაბამისი ბრძანება იგზავნება Intel ME-ზე).

ამ ოპერაციების შედეგად, Intel ME გადასცემს FPF-ებს მოცემულ მნიშვნელობებს სარკედან FPF-ებისთვის ME რეგიონში, დააყენებს ნებართვებს SPI ფლეშ აღწერებში Intel-ის მიერ რეკომენდებულ მნიშვნელობებზე (აღწერილია დასაწყისში. სტატია) და შეასრულეთ სისტემის RESET.

Intel Boot Guard განხორციელების ანალიზი

ამ ტექნოლოგიის განხორციელების კონკრეტულ მაგალითზე გასაანალიზებლად, ჩვენ შევამოწმეთ შემდეგი სისტემები Intel BG ტექნოლოგიის კვალისთვის:

სისტემის
შენიშვნა

გიგაბაიტი GA-H170-D3H
Skylake, არის მხარდაჭერა

გიგაბაიტი GA-Q170-D3H
Skylake, არის მხარდაჭერა

გიგაბაიტი GA-B150-HD3
Skylake, არის მხარდაჭერა

MSI H170A Gaming Pro
Skylake, არანაირი მხარდაჭერა

Lenovo ThinkPad 460
Skylake, მხარდაჭერა ხელმისაწვდომია, ტექნოლოგია ჩართულია

Lenovo Yoga X Prox
ჰასუელ, არანაირი მხარდაჭერა

Lenovo U330p
ჰასუელ, არანაირი მხარდაჭერა

„მხარდაჭერა“ ნიშნავს Intel BG გაშვების ACM მოდულის, ზემოთ ნახსენები მანიფესტებისა და შესაბამისი კოდის არსებობას BIOS-ში, ე.ი. განხორციელებები ანალიზისთვის.

მაგალითად, ავიღოთ ოფისიდან გადმოწერილი. გამყიდველის საიტის სურათი SPI ფლეშ მეხსიერებისთვის Gigabyte GA-H170-D3H (ვერსია F4).

Intel CPU ჩატვირთვის ROM

პირველ რიგში, მოდით ვისაუბროთ პროცესორის მოქმედებებზე, თუ ჩართულია Intel BG ტექნოლოგია.

გაშიფრული მიკროკოდის ნიმუშების მოძიება შეუძლებელი გახდა, შესაბამისად, როგორ ხორციელდება ქვემოთ აღწერილი მოქმედებები (მიკრკოდში თუ აპარატურაში) ღია კითხვაა. მიუხედავად ამისა, ის ფაქტი, რომ თანამედროვე Intel პროცესორებს „შეუძლიათ“ შეასრულონ ეს ქმედებები, ფაქტია.

RESET მდგომარეობიდან გასვლის შემდეგ, პროცესორი (რომლის მისამართის სივრცეში უკვე დატანილია ფლეშ მეხსიერების შიგთავსი) პოულობს FIT-ს (Firmware Interface Table). მისი პოვნა მარტივია, მასზე მითითება იწერება მისამართზე FFFF FFC0h.

ამ მაგალითში ეს მისამართი შეიცავს FFD6 9500h მნიშვნელობას. ამ მისამართის მიბრუნებით, პროცესორი ხედავს FIT ცხრილს, რომლის შინაარსი დაყოფილია ჩანაწერებად. პირველი ჩანაწერი არის შემდეგი სტრუქტურის სათაური:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

გაურკვეველი მიზეზის გამო, საკონტროლო ჯამი ყოველთვის არ არის გამოთვლილი ამ ცხრილებში (ველი დარჩა ნული).

დარჩენილი ჩანაწერები მიუთითებს სხვადასხვა ბინარებზე, რომლებიც უნდა იყოს გაანალიზებული/შესრულებული BIOS-ის შესრულებამდე, ე.ი. მემკვიდრეობით RESET ვექტორზე გადასვლამდე (FFFF FFF0h). თითოეული ასეთი ჩანაწერის სტრუქტურა შემდეგია:

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

EntryType ველი მიუთითებს ბლოკის ტიპზე, რომელზეც მიუთითებს ეს ჩანაწერი. ჩვენ ვიცით რამდენიმე ტიპი:

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

ახლა აშკარაა, რომ ერთ-ერთი ჩანაწერი მიუთითებს Intel BG გაშვების ACM ბინარის მდებარეობაზე. ამ ბინარის სათაურის სტრუქტურა ტიპიურია Intel-ის მიერ შემუშავებული კოდის მოდულებისთვის (ACM, მიკროკოდების განახლებები, Intel ME კოდის სექციები, ...).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

პროცესორი ატვირთავს ამ ბინარს თავის ქეშში, ამოწმებს და იწყებს.

Intel BG გაშვება ACM

ამ ACM-ის მუშაობის ანალიზის შედეგად გაირკვა, რომ ის აკეთებს შემდეგს:

იღებს Intel ME-დან Intel BG კონფიგურაციას, რომელიც ჩაწერილია ჩიპსეტის ფუჟებზე (FPFs);
პოულობს KEYM და IBBM მანიფესტებს, ამოწმებს მათ.

ამ მანიფესტების საპოვნელად ACM ასევე იყენებს FIT ცხრილს, რომელსაც აქვს ორი ტიპის ჩანაწერი ამ სტრუქტურებზე მითითებისთვის (იხ. ზემოთ FIT_ENTRY_TYPES).

მოდით უფრო ახლოს მივხედოთ მანიფესტებს. პირველი მანიფესტის სტრუქტურაში ჩვენ ვხედავთ რამდენიმე ბუნდოვან მუდმივობას, საჯარო გასაღების ჰეშს მეორე მანიფესტიდან და საჯარო OEM Root Key-ს, რომელიც ხელმოწერილია როგორც წყობილი სტრუქტურა:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

OEM Root Key-ის საჯარო გასაღების გადასამოწმებლად, შეგახსენებთ, რომ SHA256 ჰეში გამოიყენება საფუვრებიდან, რომელიც ამ მომენტში უკვე მიღებულია Intel ME-დან.

გადავიდეთ მეორე მანიფესტზე. იგი შედგება სამი სტრუქტურისგან:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

პირველი შეიცავს რამდენიმე მუდმივობას:

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

მეორე შეიცავს IBB-ის SHA256 ჰეშს და აღწერების რაოდენობას, რომლებიც აღწერს IBB-ის შიგთავსს (ანუ რისგან არის გამოთვლილი ჰეში):

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

IBB დესკრიპტორები მიჰყვებიან ამ სტრუქტურას ერთმანეთის მიყოლებით. მათ შინაარსს აქვს შემდეგი ფორმატი:

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

ეს მარტივია: თითოეული დესკრიპტორი შეიცავს IBB ნაწილის მისამართს/ზომას. ამრიგად, ამ დესკრიპტორების მიერ მითითებულ ბლოკთა შეერთება (თავად აღმწერების თანმიმდევრობით) არის IBB. და, როგორც წესი, IBB არის SEC და PEI ფაზების ყველა მოდულის კომბინაცია.

მეორე მანიფესტი მთავრდება სტრუქტურით, რომელიც შეიცავს IBB საჯარო გასაღების (დამოწმებული SHA256 ჰეშით პირველი მანიფესტიდან) და ამ მანიფესტის ხელმოწერით:

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

ასე რომ, UEFI BIOS-ის შესრულების დაწყებამდეც კი, პროცესორი დაიწყებს ACM-ს, რომელიც გადაამოწმებს სექციების შინაარსის ავთენტურობას SEC და PEI ფაზის კოდით. შემდეგ, პროცესორი გამოდის ACM-დან, მოძრაობს RESET ვექტორის გასწვრივ და იწყებს BIOS-ის შესრულებას.

PEI დამოწმებული დანაყოფი უნდა შეიცავდეს მოდულს, რომელიც შეამოწმებს დანარჩენ BIOS-ს (DXE კოდი). ეს მოდული უკვე შემუშავებულია IBV (დამოუკიდებელი BIOS გამყიდველი) ან თავად სისტემის გამყიდველის მიერ. იმიტომ რომ მხოლოდ Lenovo და Gigabyte სისტემები აღმოჩნდა ჩვენს განკარგულებაში და აქვთ Intel BG მხარდაჭერა, განვიხილოთ ამ სისტემებიდან ამოღებული კოდი.

UEFI BIOS მოდული LenovoVerifiedBootPei

Lenovo-ს შემთხვევაში, აღმოჩნდა, რომ Lenovo-ს მიერ შემუშავებული LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} მოდული.

მისი ამოცანაა მოძებნოს (GUID) ჰეშის ცხრილი DXE-სთვის და გადაამოწმოს DXE.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS მოდული BootGuardPei

Gigabyte-ის შემთხვევაში, აღმოჩნდა, რომ ეს იყო BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} მოდული, შემუშავებული AMI-ის მიერ და, შესაბამისად, წარმოდგენილია ნებისმიერ AMI BIOS-ში Intel BG-ის მხარდაჭერით.

მისი მოქმედების ალგორითმი გარკვეულწილად განსხვავებულია, თუმცა, ის ერთნაირია:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

ჰეშის ცხრილს {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, რომელიც გამოჩნდება, აქვს შემდეგი ფორმატი:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

Intel Boot Guard 2.x

მოკლედ ვისაუბროთ Intel Boot Guard-ის კიდევ ერთ იმპლემენტაციაზე, რომელიც ნაპოვნი იქნა Intel SoC-ზე დაფუძნებულ ახალ სისტემაში Apollo Lake მიკროარქიტექტურით - ASRock J4205-IT.

მიუხედავად იმისა, რომ ეს ვერსია გამოყენებული იქნება მხოლოდ SoC-ებში (ახალი სისტემები Kaby Lake პროცესორის მიკროარქიტექტურით აგრძელებენ Intel Boot Guard 1.x-ის გამოყენებას), ის დიდ ინტერესს იწვევს Intel SoC-ზე დაფუძნებული პლატფორმებისთვის ახალი არქიტექტურული ვარიანტის შესწავლით, რაც ხელშესახები გახდა. ცვლილებები, მაგალითად:

BIOS და Intel ME რეგიონები (უფრო სწორად Intel TXE, Intel SoC ტერმინოლოგიის მიხედვით) ახლა არის ერთი IFWI რეგიონი;
მიუხედავად იმისა, რომ Intel BG ჩართული იყო პლატფორმაზე, სტრუქტურები, როგორიცაა FIT, KEYM, IBBM, არ მოიძებნა ფლეშ მეხსიერებაში;
TXE და ISH ბირთვების (x86) გარდა, ჩიპსეტს დაემატა მესამე ბირთვი (ისევ ARC, სხვათა შორის) - PMC (Power Management Controller), რომელიც დაკავშირებულია ენერგეტიკული ქვესისტემის ფუნქციონირებისა და შესრულების მონიტორინგთან.

ახალი IFWI რეგიონის შინაარსი შემდეგი მოდულების ნაკრებია:

მიკერძოება
სახელი
აღწერა

0000 2000 სთ
SMIP
ზოგიერთი პლატფორმის კონფიგურაცია, ხელმოწერილი გამყიდველის მიერ

0000 6000 სთ
RBEP
Intel TXE firmware კოდის განყოფილება, x86, ხელმოწერილია Intel-ის მიერ

0001 0000 სთ
PMCP
პროგრამული უზრუნველყოფის კოდის განყოფილება Intel PMC, ARC, ხელმოწერილი Intel-ის მიერ

0002 0000 სთ
FTPR
Intel TXE firmware კოდის განყოფილება, x86, ხელმოწერილია Intel-ის მიერ

0007B000h
UCOD
CPU მიკროკოდის განახლებები ხელმოწერილია Intel-ის მიერ

0008 0000 სთ
IBBP
UEFI BIOS, SEC/PEI ფაზები, x86, გამყიდველი ხელმოწერილია

0021 8000 სთ
ISHC
Intel ISH firmware, x86 კოდის განყოფილება, ხელმოწერილი გამყიდველის მიერ

0025 8000 სთ
NFTP
Intel TXE firmware კოდის განყოფილება, x86, ხელმოწერილია Intel-ის მიერ

0036 1000 სთ
IUNP
უცნობი

0038 1000 სთ
OBBP
UEFI BIOS, DXE ფაზა, x86, ხელმოუწერელი

TXE firmware-ის ანალიზის დროს აშკარა გახდა, რომ RESET-ის შემდეგ, TXE ინარჩუნებს პროცესორს ამ მდგომარეობაში, სანამ არ მოამზადებს მისამართების სივრცის ძირითად შინაარსს CPU-სთვის (FIT, ACM, RESET ვექტორი ...). უფრო მეტიც, TXE ათავსებს ამ მონაცემებს თავის SRAM-ში, რის შემდეგაც იგი დროებით აძლევს პროცესორს იქ წვდომას და „ათავისუფლებს“ მას RESET-დან.

Rootkits-ის დაცვაზე

აბა, ახლა გადავიდეთ „ცხელზე“. ჩვენ ერთხელ აღმოვაჩინეთ, რომ ბევრ სისტემაში, SPI ფლეშ დესკრიპტორებს აქვთ SPI ფლეშ მეხსიერების რეგიონებში წვდომის ნებართვა, რათა ამ მეხსიერების ყველა მომხმარებელს შეეძლოს ნებისმიერი რეგიონის დაწერა და წაკითხვა. იმათ. არ არსებობს გზა.

MEinfo უტილიტაში (Intel STK-დან) შემოწმების შემდეგ, ჩვენ ვნახეთ, რომ ამ სისტემებზე წარმოების რეჟიმი არ იყო დახურული, შესაბამისად, ჩიპსეტის საკრავები (FPF) დარჩა განუსაზღვრელ მდგომარეობაში. დიახ, Intel BG არც ჩართულია და არც გამორთულია ასეთ შემთხვევებში.

ჩვენ ვსაუბრობთ შემდეგ სისტემებზე (რაც შეეხება Intel BG-ს და რაც მოგვიანებით იქნება აღწერილი სტატიაში, ვისაუბრებთ სისტემებზე Haswell-ის პროცესორის მიკროარქიტექტურით და უფრო მაღალი):

გიგაბაიტის ყველა პროდუქტი;
ყველა MSI პროდუქტი;
21 Lenovo ლეპტოპის მოდელი და 4 Lenovo სერვერის მოდელი.

რა თქმა უნდა, აღმოჩენის შესახებ ჩვენ ვაცნობეთ ამ მოვაჭრეებს, ისევე როგორც Intel-ს.

ადეკვატური პასუხი მოჰყვა მხოლოდ Lenovoვინც პრობლემას აღიარებდა და გამოუშვა პაჩი.

გიგაბაიტი როგორც ჩანს, მათ მიიღეს ინფორმაცია დაუცველობის შესახებ, მაგრამ არანაირი კომენტარი არ გაუკეთებიათ.

კომუნიკაცია MSI მთლიანად შეჩერდა ჩვენი თხოვნით, გამოგზავნა ჩვენი საჯარო PGP გასაღები (იმისთვის, რომ მათ გაუგზავნოთ დაშიფრული უსაფრთხოების რჩევები). მათ განაცხადეს, რომ ისინი "ტექნიკის მწარმოებელი არიან და არ აწარმოებენ PGP გასაღებებს".

მაგრამ უფრო აზრზე. მას შემდეგ, რაც საფუარები რჩება განუსაზღვრელ მდგომარეობაში, მომხმარებელს (ან თავდამსხმელს) შეუძლია მათი დაპროგრამება თავად (ყველაზე რთულია იპოვნეთ Intel STK). ეს მოითხოვს შემდეგ ნაბიჯებს.

1. ჩატვირთეთ Windows OS-ში (ზოგადად, ქვემოთ აღწერილი ნაბიჯები ასევე შეიძლება განხორციელდეს Linux-დან, თუ შეიმუშავებთ Intel STK-ის ანალოგს სასურველი OS-სთვის). MEinfo უტილიტის გამოყენებით, დარწმუნდით, რომ ამ სისტემაზე არსებული საფუვრები არ არის დაპროგრამებული.

2. წაიკითხეთ ფლეშ მეხსიერების შინაარსი Flash Programming Tool-ის გამოყენებით.

3. გახსენით წაკითხული სურათი UEFI BIOS-ის რედაქტირების ნებისმიერი ხელსაწყოს გამოყენებით, შეიტანეთ აუცილებელი ცვლილებები (მაგალითად, განახორციელეთ rootkit), შექმენით / შეცვალეთ არსებული KEYM და IBBM სტრუქტურები ME რეგიონში.

სურათზე გამოკვეთილია RSA კლავიშის საჯარო ნაწილი, რომლის ჰეშიც დაპროგრამდება ჩიპსეტის ფუჟებში დანარჩენ Intel BG-ის კონფიგურაციასთან ერთად.

4. Flash Image Tool-ის გამოყენებით შექმენით ახალი პროგრამული უზრუნველყოფის სურათი (Intel BG კონფიგურაციის დაყენებით).

5. დაწერეთ ახალი სურათი Flash Programming Tool-ის გამოყენებით გასანათებლად, გადაამოწმეთ MEinfo-ს გამოყენებით, რომ ME რეგიონი ახლა შეიცავს Intel BG-ის კონფიგურაციას.

6. გამოიყენეთ Flash Programming Tool, რათა დახუროთ წარმოების რეჟიმი.

7. სისტემა გადაიტვირთება, რის შემდეგაც, MEinfo-ს გამოყენებით, შეგიძლიათ დაადასტუროთ, რომ FPF-ები ახლა დაპროგრამებულია.

ეს ქმედებები სამუდამოდ ჩართეთ Intel BG ამ სისტემაზე. შეუძლებელი იქნება მოქმედების გაუქმება, რაც ნიშნავს:

მხოლოდ root გასაღების პირადი ნაწილის მფლობელი (ანუ ის, ვინც ჩართო Intel BG) შეძლებს ამ სისტემაზე UEFI BIOS-ის განახლებას;
თუ თქვენ დააბრუნებთ ორიგინალ პროგრამულ უზრუნველყოფას ამ სისტემაში, მაგალითად, პროგრამისტის გამოყენებით, ის არც კი ჩაირთვება (აღსრულების პოლიტიკის შედეგი გადამოწმების შეცდომის შემთხვევაში);
ასეთი UEFI BIOS-ის მოსაშორებლად, თქვენ უნდა შეცვალოთ ჩიპსეტი დაპროგრამებული FPF-ებით „სუფთა“ (ანუ გადაადუღეთ ჩიპსეტი, თუ გაქვთ წვდომა ინფრაწითელ შედუღების სადგურზე მანქანის ფასად, ან უბრალოდ შეცვალეთ დედაპლატა. ).

იმის გასაგებად, თუ რისი გაკეთება შეუძლია ასეთ rootkit-ს, თქვენ უნდა შეაფასოთ, თუ რა იძლევა თქვენი კოდის შესრულებას UEFI BIOS გარემოში. ვთქვათ, პროცესორის ყველაზე პრივილეგირებულ რეჟიმში - SMM. ასეთ rootkit-ს შეიძლება ჰქონდეს შემდეგი თვისებები:

შესრულდეს OS-ის პარალელურად (შეგიძლიათ დააკონფიგურიროთ დამუშავება SMI შეფერხების გენერირებით, რომელიც გააქტიურდება ტაიმერით);
აქვს SMM რეჟიმში ყოფნის ყველა უპირატესობა (სრული წვდომა RAM-ისა და აპარატურის რესურსების შინაარსზე, ოპერაციული სისტემისგან საიდუმლოება);
Rootkit კოდის დაშიფვრა და გაშიფვრა შესაძლებელია SMM რეჟიმში გაშვებისას. ნებისმიერი მონაცემი, რომელიც ხელმისაწვდომია მხოლოდ SMM რეჟიმში, შეიძლება გამოყენებულ იქნას დაშიფვრის გასაღებად. მაგალითად, ჰეში SMRAM-ში მისამართების ნაკრებიდან. ამ გასაღების მისაღებად დაგჭირდებათ SMM-ში ასვლა. და ეს შეიძლება გაკეთდეს ორი გზით. იპოვეთ RCE SMM კოდში და გამოიყენეთ იგი, ან დაამატეთ თქვენი საკუთარი SMM მოდული BIOS-ში, რაც შეუძლებელია, რადგან ჩვენ ჩავრთეთ Boot Guard.

ამრიგად, ეს დაუცველობა საშუალებას აძლევს თავდამსხმელს:

შექმენით სისტემაში უცნობი დანიშნულების ფარული, მოუხსნელი rootkit;
შეასრულეთ თქვენი კოდი Intel SoC-ის შიგნით ჩიპსეტის ერთ-ერთ ბირთვზე, კერძოდ, Intel ISH-ზე (უფრო ახლოს დააკვირდით სურათს).

მიუხედავად იმისა, რომ Intel ISH ქვესისტემის შესაძლებლობები ჯერ არ არის შესწავლილი, როგორც ჩანს, ის საინტერესო თავდასხმის ვექტორია Intel ME-ზე.

დასკვნები

კვლევაში მოცემულია ტექნიკური აღწერა, თუ როგორ მუშაობს Intel Boot Guard ტექნოლოგია. მინუს რამდენიმე საიდუმლო ინტელის უსაფრთხოებაში გაურკვევლობის მოდელის მეშვეობით.
წარმოდგენილია თავდასხმის სცენარი, რომელიც საშუალებას გაძლევთ შექმნათ მოუხსნელი rootkit სისტემაში.
ჩვენ დავინახეთ, რომ Intel-ის თანამედროვე პროცესორებს შეუძლიათ შეასრულონ ბევრი საკუთრების კოდი BIOS-ის დაწყებამდეც კი.
Intel 64 არქიტექტურის მქონე პლატფორმები სულ უფრო და უფრო შესაფერისი ხდება თავისუფალი პროგრამული უზრუნველყოფის გასაშვებად: ტექნიკის გადამოწმება, საკუთრების ტექნოლოგიებისა და ქვესისტემების მზარდი რაოდენობა (SoC ჩიპსეტში სამი ბირთვი: x86 ME, x86 ISH და ARC PMC).

შერბილება

გამყიდველებმა, რომლებიც განზრახ ტოვებენ წარმოების რეჟიმს ღიად, აუცილებლად უნდა დახურონ იგი. ჯერჯერობით, ისინი მხოლოდ თვალებს ხუჭავენ და ახალი Kaby Lake სისტემები ამას აჩვენებს.

მომხმარებლებს შეუძლიათ გამორთონ Intel BG თავიანთ სისტემებზე (რომლებზეც გავლენას ახდენს აღწერილი დაუცველობა) Flash Programming Tool-ის გაშვებით -closemnf ოფციით. პირველ რიგში, თქვენ უნდა დარწმუნდეთ (MEinfo-ს გამოყენებით), რომ Intel BG-ის კონფიგურაცია ME რეგიონში ითვალისწინებს ამ ტექნოლოგიის ზუსტად გამორთვას FPF-ებში დაპროგრამების შემდეგ.

წყარო: www.habr.com

შრედინგერის სანდო ჩექმა. Intel Boot Guard

Firmware კომპიუტერული პლატფორმისთვის Intel 64 არქიტექტურით

კომპიუტერული პლატფორმის პროგრამული უზრუნველყოფის მოდიფიკაციისგან დაცვის მექანიზმები

ჩაწერეთ დაცვა UEFI BIOS რეგიონში

UEFI BIOS ავთენტიფიკაციის შემოწმება

Intel CPU

Intel ME

Intel Boot Guard 1.x

გაზომილი ჩექმა

დამოწმებული ჩატვირთვა

Intel Boot Guard კონფიგურაცია

Intel Boot Guard განხორციელების ანალიზი

Intel CPU ჩატვირთვის ROM

Intel BG გაშვება ACM

UEFI BIOS მოდული LenovoVerifiedBootPei

UEFI BIOS მოდული BootGuardPei

Intel Boot Guard 2.x

Rootkits-ის დაცვაზე

დასკვნები

შერბილება

ახალი კომენტარის დამატება

შრედინგერის სანდო ჩექმა. Intel Boot Guard

Firmware კომპიუტერული პლატფორმისთვის Intel 64 არქიტექტურით

კომპიუტერული პლატფორმის პროგრამული უზრუნველყოფის მოდიფიკაციისგან დაცვის მექანიზმები

ჩაწერეთ დაცვა UEFI BIOS რეგიონში

UEFI BIOS ავთენტიფიკაციის შემოწმება

Intel CPU

Intel ME

Intel Boot Guard 1.x

გაზომილი ჩექმა

დამოწმებული ჩატვირთვა

Intel Boot Guard კონფიგურაცია

Intel Boot Guard განხორციელების ანალიზი

Intel CPU ჩატვირთვის ROM

Intel BG გაშვება ACM

UEFI BIOS მოდული LenovoVerifiedBootPei

UEFI BIOS მოდული BootGuardPei

Intel Boot Guard 2.x

Rootkits-ის დაცვაზე

დასკვნები

შერბილება

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება