BLACK HAT ASIA 2022 — Bilgi işlem cihazlarına güç sağlayan ürün yazılımının geliştirilmesi söz konusu olduğunda, ekosistem, birden fazla katkıda bulunan karmaşık tedarik zincirlerinden oluşur. Herhangi bir cihaz için, bellenim farklı kaynaklardan gelen karmakarışık bileşenlerden oluşabilir. Bu da, güvenlik açıklarını ele alma zamanı geldiğinde, bir yama yayınlamanın basit bir süreçten çok uzak olduğu anlamına gelir.

Perşembe günü Black Hat Asia’da bir panel-tartışma oturumu sırasında, “Ürün Yazılımı Tedarik Zinciri Güvenliği Bozuldu: Onarabilir miyiz?“, Immune GmbH’nin kurucu ortağı ve CTO’su Kai Michaelis, aşırı büyümüş tedarik zinciri “ağacı” olarak adlandırdığı ve içinden zahmetli kod incelemeleri ve bir hata bulunduğunda uzun yama süreçleri oluşturan şeyi özetledi.

Aslında, panelistlere göre yamaların ortaya çıkması için altı ila dokuz ay ortalama – iki yıl nadir değildir. Ve bu, tedarik zincirinin uzlaşma için olgunlaşmış geniş bir saldırı yüzeyini temsil ettiği anlamına geliyor, diye uyardılar. Güvenlik açığı bulunan bellenimin işletim sisteminin ve herhangi bir uygulamanın güvenliğini tehdit ettiği düşünüldüğünde, siber saldırganların istismar edilebilir güvenlik açıklarını bulma potansiyeli ciddi bir endişe kaynağıdır.

Tedarik Zinciri Karmaşıklığının Dikenli Bir Ağacı

Michaelis, satıcıların donanımlarına dahil ettikleri son üretici yazılımının çok kaynaklı bir mesele olduğunu açıkladı. Paydaşlar, çeşitli bileşen satıcılarını, birkaç açık kaynak deposunu, referans uygulamalarını, orijinal tasarım üreticilerini, bağımsız BIOS satıcılarını ve son olarak, nihai ürünü oluşturup kanal ortaklarına ve son kullanıcılara satan orijinal ekipman üreticilerini (OEM’ler) içerebilir.

Daha da karmaşık bir konu, alt sistem satıcılarının, birden çok bileşen üreticisinin unsurlarını tek bir teklifte birleştiren kod ağacının ortasında oturuyor olmaları olabilir.

Talihsiz sonuç, bir güvenlik açığı bildirildiğinde, OEM’lerin genellikle yamaların ve güncellemelerin aktığı birden fazla “dal”ın olması ve genellikle birbirlerini görmemeleridir.

Michaelis, “Bu, aralarında çok az koordinasyon bulunan bir tedarikçi ve güncelleme ağacı ve OEM’in hepsini alması gerekiyor” dedi. “Satıcılar için, paketleme güncellemeleri oldukça manuel bir işlemdir ve daha sonra tüketicilerin bu güncellemeleri gerçekten yüklemeleri gerekir. Toplamda, yama süreci şu anki haliyle aylar veya yıllar içinde ölçülebilir.”

Michaelis’in işaret ettiği ana sorunlardan biri, böcekler bulunduğunda kendi içlerinde iyi huylu olabileceği gerçeğidir. Ancak, donanım yazılımının diğer bölümlerindeki ek güvenlik açıklarıyla birleştirildiğinde, kusurlar silaha dönüştürülebilir hale gelir ve katma değerli bayi (VAR) ortaklarına ve oradan son kullanıcılara yönelik saldırılara izin verebilir.

“Bir satıcıyı zararsız bir kusur olduğuna inandığı şeyi düzeltmeye ikna etmek kolay değil” dedi. “Ve bir yama olsa bile, aşağı akışı o kadar uzun sürüyor ki, bir saldırgan bu arada onunla birleştirmek için kolayca başka bir güvenlik açığı bulabiliyor. Yani sorun şu: Hatalar tecrit edilmiş durumda çünkü satıcılar konuşmazlar. birbirlerine ve böceklerin uzun bir raf ömrüne sahiptir.”

Sorunları daha da kötüleştiren en az üç özellik daha vardır: Kullanım ömrünün sonuna (EoL) sahip bir cihaz genellikle güncelleme almaz; iki, her satıcı kendi yama döngüsünü takip eder; ve üç, bazen satıcılar, OEM’leri yamaları dahil etmekten caydırabilecek bir tavsiye yayınlamadan sessiz güncellemeler sunar.

Aynı Hataları Tekrarlamak

Binarly’nin kurucusu ve CEO’su Alex Matrosov, panel sırasında, yazılım tedarik zincirinde olduğu gibi, ürün yazılımı hatalarının da yama yapıldıktan sonra bile yayılabileceğini ve yeniden içe aktarılabileceğini ve bunun “tekrarlanabilir hatalar” olarak adlandırdığı durumlarla sonuçlanabileceğini açıkladı.

Örneğin, Intel M15 dizüstü bilgisayar kitindeki (CVE-2022-27493) bileşenlerden birinde yakın zamanda açıklanan bir hata, sistem yönetimi modu (SMM) bellek bozulmasından kaynaklanan klasik bir sınır dışı yazma hatasıdır – ancak eskisi kadar değil. ne görünüyor.

Matrosov, “Aslında bu, AMI kod tabanında bulunan ve şimdi 2022 belleniminde keşfettiğimiz bir 2019 hatası” dedi. “Bu güvenlik açığı düzeltildi, ancak sabit sürüm cihaz satıcısı tarafından dahil edilmedi. Bu çok savunmasız bir bileşen ve yıllardır uygun bir saldırı vektörü olarak biliniyor ve kaldırılması gerekiyor.”

Başka bir örnekte, SecurityPkg adlı bir EDK açık kaynak kitaplığındaki savunmasız kod, 2018’de EDK II’de kaldırıldı. Ancak, bir şekilde, başka bir kitaplık aracılığıyla birkaç OEM’i etkileyen 2022 bellenimine girdi. Matrosov, “Risk katlanarak derlendi,” dedi.

Yama Sefaletini Geri Budamak İçin En İyi İlkeler

Peki, ne yapılmalı? Panele göre, ürün yazılımı güvenliğini güvenilir bir şekilde desteklemek için strateji ve düşüncede köklü bir değişiklik yapılacak. Bununla birlikte, başlamak için iyi bir yer, ilham verici bir ilk ilkeler listesidir.

Panelistler, örneğin, OEM’lerin ve bir bütün olarak güvenlik topluluğu üyelerinin, bileşen satıcılarını ve diğer tedarik zinciri unsurlarını güvenlik konusunda eğitmek ve güncellemelerin EoL cihazları için bile bir zorunluluk olduğuna ikna etmek için ortak bir çaba sarf ettiğini savundular – ve bu ayrıca, bir CVE yayınlamazlarsa, düzeltme ekinin aciliyetini iletmek daha zor hale gelir ve hataların izlenmesi zorlaşır.

Panele göre OEM’ler de risk şeffaflığını artırmak için çaba göstermelidir. Bu, satıcılar arasında daha fazla iletişimi kolaylaştırarak ve yamalar ve hatalar hakkında merkezi bir bilgi deposu oluşturarak yapılabilir.

Matrosov, “Tedarik zincirini onarmak bir ekip işidir” diyerek bilgisayar acil durum müdahale ekipleriyle (CERT’ler) çalışmanın iyi bir hedef olduğuna dikkat çekti.

“Birden fazla satıcıyı etkilediklerinde yamaları koordine etmeye ve aynı anda yamayı kolaylaştırmaya yardımcı olacak gerçekten bağımsız bir kuruluşa ihtiyacımız var. Bir satıcı yamaları ve bir diğeri yapmazsa, bu, cihazların bir alt kümesi için tehlikeli bir sıfırıncı gün durumu yaratır” dedi. katma.

Panelistler, özel güvenlik topluluğu işbirliğinin de önemli olacağını söyledi. Örneğin, Linux Vakfı, OEM’lerin Linux kullanıcılarına sıfır maliyetle dağıtılmak üzere bellenim güncellemelerini yüklemelerine olanak tanıyan bir satıcı bellenim hizmeti olan LVFS adlı bir web sitesi başlattı. Şu ana kadar Dell, HP, Intel ve Lenovo dahil olmak üzere yaklaşık 150 satıcı katılıyor.

Red Hat baş mühendisi panelist Richard Hughes, “Desteklenen yaklaşık 1000 farklı cihaz var ve projeye başladığımızdan bu yana 51 milyondan fazla güncelleme gönderdik” dedi. “Ayrıca, bellenimi alıp parçalara ayırabiliriz. Bir parça bir EFI, ikili, Intel mikro kodları, AMD PSP görüntüsü vb. olabilir. Dolayısıyla, tüm bu güncellemeleri yükleyen tüm bu satıcılar bize çok büyük miktarda veri sağlar. “

Buradan sistem, kullanıcılara sistemdeki tüm farklı modeller için mevcut en yeni Intel mikro kodunu gösterebilir ve güncellemeleri otomatik olarak aktarabilir.

Yapılması gereken çok şey var ama Hughes iyimser bir not aldı.

Hughes, “Kişisel sonucum, CERT’ler ve güvenlik şirketleriyle birlikte çalışarak bağışıklık sistemini daha da geliştirebilir, son kullanıcılara düzeltme gönderme sürecini hızlandırabilir ve güvenlik sorunlarının tüm satıcılar tarafından yamalandığından emin olabiliriz” dedi. “Bunlar, 20 yıldır tüm endüstriyi rahatsız eden gerçekten zor sorunlar. İşleri daha iyi hale getirmek için tüm altyapıya ve verilere ancak şimdi sahibiz.”



siber-1