На фона на неуспеха, в който се превърна ограничаването на действието на бууткита BlackLotus, Агенцията за киберсигурност и инфраструктурна сигурност (CISA) призовава за подобряване на сигурността на механизмите за актуализация на Unified Extensible Firmware Interface (UEFI).

В публикация в блога си, публикувана днес, CISA призовава компютърната индустрия да възприеме подход за сигурност по проект, за да засили цялостната сигурност на UEFI, който е фърмуерът, отговорен за процедурата за зареждане на системата. Той се състои от няколко компонента – включително инициализатори за сигурност и платформа, драйвери, зареждащи програми и интерфейс за управление на захранването.

„Secure-by-design означава организациите, които проектират софтуера, да поемат отговорност за сигурността, което включва и пътищата за актуализация“, казва Джонатан Спринг, старши технически съветник в CISA, в ексклузивно интервю за Dark Reading.

UEFI е популярна повърхност за атаки, тъй като ако е заредена със злонамерен код, участниците в заплахите могат да постигнат високо ниво на устойчивост на системата, тъй като този код ще се стартира преди операционната система или какъвто и да е софтуер за сигурност. Това го прави невидим за повечето тактики за реагиране на инциденти и защити на ниво операционна система, както и неподатлив на рестартиране на системата. Спринг казва, че призивът за действие на CISA е искане за повсеместно стандартно движение за неутрализиране на заплахите за UEFI чрез създаване на софтуер и придружаващ го път за актуализация, който е по същество защитен.

„Всеки, който купува система, очаква тя да е сигурна по замисъл и да може да се актуализира по сигурен начин“, казва той. „Това е постоянна грижа.“

BlackLotus и продължаващата заплаха, свързана с този зловреден софтуер, са донякъде пример за проблемите, които могат да възникнат без по-сигурен механизъм за актуализация, добавя той.

BlackLotus и проблемите с UEFI актуализациите

BlackLotus, първият зловреден софтуер, който успешно заобикаля внедряването на UEFI Secure Boot на Microsoft, беше забелязан за продажба в Dark Web миналата есен. В момента защитата срещу него изисква ръчно прилагане на пачове, издадени от Microsoft през януари 2022 г. и май 2023 г.

Но това не е всичко: през юни АНС предупреди, че прилагането на настоящите кръпки за BlackLotus е „добро начало“, но не е достатъчно, за да се отстрани напълно проблемът. Това е така, защото Microsoft не е издала кръпки за отмяна на доверието в непоправените зареждащи устройства чрез базата данни Secure Boot Deny List Database (DBX), което дава възможност на лошите играчи просто да заменят напълно поправените зареждащи устройства с легитимни, но уязвими версии, което им позволява да изпълняват BlackLotus.

„BlackLotus се възползва от провал в безопасното разпространение на актуализации“, обяснява Спринг в публикацията на CISA. „BlackLotus може да върне файл до уязвима версия и след това да я използва, което прави канала за разпространение на актуализации за UEFI актуализации на Windows недостатъчно устойчив или сигурен.“

Във връзка с това Спринг също така казва, че ако Microsoft беше използвала по-сигурен по проект подход за инфраструктурата на публичния ключ (PKI) за UEFI заедно с автоматизирана система за актуализации, проблемът можеше вече да е отстранен.

Обикновено при управлението на PKI има един секретен ключ или сертификат, който се пази в „много голяма тайна“, докато други, междинни сертификати се използват за подписване на други файлове, които лесно се отменят в случай на проблем. В PKI на Windows обаче един ключ подписва голям брой файлове, така че отмяната му с цел намаляване на проблема с BlackLotus „би причинила много съпътстващи щети“ в други части на операционната система, казва той и добавя: „Инфраструктурата с публичен ключ не трябва да се подписва по този начин.“

Спринг отбелязва: „Ако механизмът за разпространение на актуализациите използваше подходяща PKI, вярвам, че тези актуализации щяха да се разпространяват по подразбиране и ключовете за уязвимите файлове щяха да бъдат премахнати по подразбиране и всичко щеше да е готово.“

В резултат на всичко това NSA препоръча на собствениците на инфраструктури да предприемат допълнителни ръчни стъпки за укрепване на своите системи, като например затягане на политиките за изпълними файлове на потребителите и наблюдение на целостта на стартовия дял. Междувременно Майкрософт очаква автоматизирана и цялостна поправка за BlackLotus някъде в началото на 2024 г.

„Ръчното смекчаване на последиците е доста трудно и не мисля, че всеки ще го направи“, казва Спринг. Ето защо CISA се надява да насърчи бъдеще, в което „тези ръчни поправки на сигурността не са норма“, казва той.

Специфични особености на CISA за подобряване на киберсигурността при актуализация на UEFI

BlackLotus със сигурност подчертава пейзажа на заплахите в UEFI и може да се използва като тема за разговор, за да се насърчи разработването на по-сигурни системи в бъдеще, казва Спринг: „Никога няма лош момент да се посочи, че целият софтуер, който използваме, трябва да бъде сигурен по замисъл, че има някои начини, по които в момента не е, и да се насърчат хората да очакват и създават по-добри системи, така че всеки да има по-малък риск от дълготраен устойчив зловреден софтуер в системите си.“

За тази цел CISA очерта в публикацията си конкретика за това как стратегията за сигурност по проект, работеща в тандем със зрял екип за реагиране на инциденти, свързани със сигурността на продукта (PSIRT), може съвместно да подсили „цялостно инженерно решение за сигурност“.

Това включва следните усилия:

• Собствениците на системи трябва да могат да одитират, управляват и актуализират компонентите на UEFI, както всеки друг софтуер, който се придобива, в комплект със софтуерни спецификации.
• Оперативните екипи трябва да очакват да могат да събират, анализират и реагират на дневници за събития, които идентифицират дейности, свързани с UEFI – като промени, актуализации и добавяне/премахване на компоненти – като използват естествените за UEFI възможности за наблюдение и докладване, предавани на операционната система или на инструменти за откриване и реагиране на крайни точки, както е подходящо.
• Разработчиците на UEFI компоненти трябва да използват сигурни среди за разработка и да възприемат най-добрите практики за разработка на софтуер, както при всеки друг софтуер.
• Общността на доставчиците на UEFI следва да приеме универсални възможности за непрекъснато и надеждно актуализиране, за да се гарантира, че актуализациите на компонентите на UEFI не натоварват оперативните общности и крайните потребители.
• При наличието на екип за реагиране на сигурността на UEFI (USRT), който да осигури непрекъснато ръководство, общността на UEFI следва да разшири участието си в общностите, за да разшири възприемането на най-добрите практики за операциите на PSIRT.

Спринг цитира в блога по-задълбочено проучване на Института по софтуерно инженерство към университета Карнеги Мелън в публикацията си „Securing UEFI: An Underpinning Technology for Computing“ за допълнителна информация относно това как да се прилагат тези пътища.