SAPwned: SAP AI güvenlik açıkları müşteri bulut ortamlarını ve özel AI çıktılarını açığa çıkardı

• Wiz Research, SAP AI Core’daki kiracı izolasyonu güvenlik açığı zinciri aracılığıyla, normal bir AI eğitim işinde başlayan kod çalıştırmanın hizmetin ele geçirilmesine ve müşteri sırlarına erişime yol açabileceğini doğruladı
• Saldırı yolu; Istio ağ kısıtlamalarının atlatılması, Loki yapılandırmasında AWS token’ının açığa çıkması, kimlik doğrulamasız EFS paylaşımı ve kimlik doğrulamasız Helm v2 Tiller erişiminin zincirleme biçimde birleştiği bir yapıdaydı
• Elde edilen yetkilerle SAP’nin dahili Docker Registry’sindeki, Google Container Registry’deki ve dahili Artifactory’deki imajlar ile artefaktlar okunup değiştirilebiliyordu; ayrıca Kubernetes kümesinde cluster-admin yetkisi de elde edilebiliyordu
• Potansiyel bir saldırgan müşterilerin AWS, Azure ve SAP HANA Cloud kimlik bilgilerine ve modeller, veri kümeleri, kod gibi özel AI çıktılarına erişebilir ya da dahili artefaktları kirletebilirdi
• SAP bildirilen tüm güvenlik açıklarını düzeltti ve ilgili gizli değerleri döndürdü; Wiz ise müşteri verilerinin ihlal edilmediğini belirtti

---

SAP AI Core’da ortaya çıkan kiracı izolasyonu sorunu

• Wiz Research, AI hizmet sağlayıcılarının kiracı izolasyonunu araştırıyordu; SAP AI Core, Hugging Face ve Replicate’in ardından üçüncü rapor oldu
• SAP AI Core, kullanıcıların SAP’nin bulut kaynakları üzerinde AI hizmetleri geliştirmesine, eğitmesine ve çalıştırmasına olanak tanıyan yönetilen bir hizmettir
• AI eğitim hizmetleri büyük miktarda hassas müşteri verisine erişmek zorundadır; SAP AI Core, HANA ve diğer bulut hizmetleriyle entegrasyon için müşterinin dahili verilerine erişen bulut erişim anahtarları kullanır
• Araştırma, temel yetkilere sahip bir SAP müşteri hesabında bir AI projesi oluşturup SAP AI Core’un izin verdiği Argo Workflow dosyasıyla Kubernetes Pod’u oluşturma yöntemiyle başladı
• Kullanıcılar tasarım gereği Pod içinde rastgele kod çalıştırabiliyordu, ancak başlangıç ortamında Istio proxy sidecar’ı ağ erişimini kısıtladığı için dahili ağ taraması zordu

Hata #1: Istio kısıtlamalarının atlatılması

• SAP’nin admission controller’ı tehlikeli güvenlik seçeneklerini engelliyordu; konteyneri root olarak çalıştırma girişimleri de engellendi
• Engellenmeyen iki ayar ağ kısıtlamalarının atlatılmasına yol açtı
  • shareProcessNamespace, sidecar konteyneriyle işlem ad alanını paylaşmayı sağlayarak Istio proxy yapılandırmasını ve merkezi Istiod sunucusuna erişim token’ını görmeyi mümkün kıldı
  • runAsUser ve runAsGroup, root dışındaki UID’lere izin veriyordu ve Istio’nun UID’si olan 1337 ile çalıştırmak mümkündü
• Istio’nun kendisi Istio iptables kurallarından hariç tutulduğu için, UID 1337 ile çalışan süreçler trafik kısıtlaması olmadan çalışır
• Ardından Istio token’ıyla Istiod sunucusunun yapılandırması okunarak dahili ortam bilgileri elde edilebildi

Hata #2: Loki yapılandırmasında AWS token’ının açığa çıkması

• Küme içinde bir Grafana Loki örneği bulundu ve /config endpoint’ine yapılan istekle tüm yapılandırma görülebildi
• Yanıtta Loki’nin S3 erişimi için kullandığı AWS gizli değerleri yer alıyordu
• Bu gizli değerler Loki’nin S3 bucket’ına erişim yetkisi sağlıyordu; ilgili bucket’ta çok sayıda AI Core hizmet günlüğü ve müşteri Pod günlüğü bulunuyordu
• SAP bu günlüklerin hassas olmadığını değerlendirdi

Hata #3: Kimlik doğrulamasız EFS paylaşımında kullanıcı dosyalarının açığa çıkması

• Dahili ağda 2049 portunu dinleyen 6 AWS Elastic File System, yani EFS örneği bulundu
• Bu EFS örnekleri, yalnızca ağ erişimi mümkün olduğunda kimlik bilgisi olmadan dosyaların görüntülenip düzenlenebileceği durumdaydı
• Yalnızca açık kaynak NFS araçlarıyla paylaşımların içeriğine serbestçe erişilebildi
• EFS üzerinde müşteri kimliklerine göre sınıflandırılmış kodlar ve eğitim veri kümeleri dahil büyük miktarda AI verisi saklanıyordu

Hata #4: Kimlik doğrulamasız Helm Tiller, dahili Registry ve Artifactory’yi açığa çıkardı

• Dahili ağda Helm v2’nin sunucu bileşeni olan Tiller hizmeti bulundu
• Tiller, 44134 portundaki gRPC arayüzü üzerinden iletişim kurar ve varsayılan olarak kimlik doğrulaması olmadan açığa çıkar
• Tiller sorgusu sonucunda SAP Docker Registry ve Artifactory sunucularına yönelik yüksek yetkili gizli değerler açığa çıktı
• Okuma yetkisiyle dahili imajlar ve build’ler okunarak ticari sırlar ve müşteri verileri çıkarılabiliyordu
• Yazma yetkisiyle imajlar ve build’ler kirletilerek SAP AI Core hizmetine yönelik bir tedarik zinciri saldırısı gerçekleştirilebiliyordu

Hata #5: Helm Tiller yazma yetkisiyle Kubernetes kümesinin ele geçirilmesi

• Tiller yalnızca okuma değil, yazma işlemlerine de izin veriyordu
• install komutu Helm paketlerini alıp Kubernetes kümesine dağıttığından, araştırma ekibi cluster-admin yetkisine sahip yeni bir Pod oluşturan kötü amaçlı bir Helm paketi hazırlayıp kurdu
• Bu süreçle küme üzerinde tam yetki elde edildi
• Bu yetki, diğer müşterilerin Pod’larına doğrudan erişip model, veri kümesi ve kod gibi hassas verileri çalabilecek düzeydeydi
• Ayrıca müşteri Pod’larını engellemek, AI verilerini kirletmek ve model çıkarımını manipüle etmek mümkündü
• Aynı yetkiyle SAP AI Core kapsamının ötesindeki müşteri gizli değerleri de düz metin olarak sorgulanabiliyordu
  • Araştırma ekibinin AI Core hesabında S3 veri erişimi için AWS hesap gizli değerleri vardı
  • Data Lake erişimi için SAP HANA hesap gizli değerleri vardı
  • İmaj pull işlemi için Docker Hub hesap gizli değerleri vardı
• Aynı sorguda Google Container Registry için sap-docker-registry-secret adlı SAP erişim anahtarı da görüldü; bu anahtar hem okuma hem yazma yetkisi sağlıyordu

Doğrulanan erişim kapsamı ve potansiyel etki

• Güvenlik açığı zinciriyle yapılabilecek işlemler şunlardı
  • SAP dahili konteyner Registry’sindeki Docker imajlarını okuma ve değiştirme
  • Google Container Registry’deki SAP Docker imajlarını okuma ve değiştirme
  • SAP dahili Artifactory sunucusundaki artefaktları okuma ve değiştirme
  • SAP AI Core Kubernetes kümesinde cluster-admin yetkisi elde etme
  • Müşteri bulut kimlik bilgilerine ve özel AI çıktılarına erişme
• Potansiyel bir saldırgan müşteri verilerine erişebilir ve dahili artefaktları kirleterek etkinin ilgili hizmetlere ve diğer müşteri ortamlarına yayılmasına neden olabilirdi
• Tüm güvenlik açıkları SAP güvenlik ekibine bildirildi ve SAP tarafından düzeltildi; SAP bunu güvenlik araştırmacıları kredi sayfasında kabul etti
• Müşteri verileri ihlal edilmedi

Savunma açısından ortaya çıkan sorunlar

• Başlıca savunma hattı Istio’nun dahili ağ erişimini engelleyen yapısıydı; ancak bu bariyer aşıldıktan sonra birçok dahili varlık ek kimlik doğrulaması istemiyordu
• Dahili ağ güvenilir bir bölge gibi ele alındığı için tek bir atlatma hizmetin ele geçirilmesine dönüştü
• Dahili hizmetler sıkılaştırılmış olsaydı saldırının etkisi tam hizmet ele geçirmeden küçük bir güvenlik olayı seviyesine düşürülebilirdi
• Kubernetes tabanlı yönetilen hizmetlerde kontrol düzlemi ve müşteri compute’u API’ler, kimlikler, paylaşımlı compute ve yazılım tabanlı ağ ayrımıyla mantıksal olarak bağlandığından kiracı izolasyonu tuzakları ortaya çıkabilir
• AI eğitimi doğası gereği rastgele kod çalıştırmayı gerektirdiğinden, güvenilmeyen kodun dahili varlıklardan ve diğer kiracılardan uygun şekilde ayrılmasını sağlayan koruma raylarına ihtiyaç vardır

Açıklama takvimi

• 25 Ocak 2024: Wiz Research güvenlik bulgularını SAP’ye bildirdi
• 27 Ocak 2024: SAP yanıt verdi ve vaka numarası atadı
• 16 Şubat 2024: SAP ilk güvenlik açığını düzeltti ve ilgili gizli değerleri döndürdü
• 28 Şubat 2024: Wiz Research yamayı 2 yeni güvenlik açığıyla atlattı ve SAP’ye bildirdi
• 15 Mayıs 2024: SAP bildirilen tüm güvenlik açıkları için düzeltmeleri dağıttı
• 17 Temmuz 2024: Kamuya açıklandı

[GN⁺]

Hacker News görüşleri

• Bunun bir yapay zeka ürünü olduğunu anlıyorum, ama buradaki açık k8s yapılandırmasında
  Yapay zeka ürününün kendisiyle, yapay zeka eğitimiyle, makine öğrenmesiyle veya üretken yapay zekayla pek ilgisi yok; daha çok zayıf bulut platformu güvenliği meselesi

  • Hatta daha da kötü olabilir. SAP gibi büyük ve çok kritik bilgi işleyen bir şirketin temel bulut güvenliğini berbat etmesi söz konusu; yeni bir şeyi yanlış yapmış da değiller, kulağa yaygın bir hatayı yapmışlar gibi geliyor
  • Yazı bunun ürünün kendisinin sorunu olduğunu söylemiyor. Aksine, bunu yapay zeka eğitim modelinin izolasyonu sorunu olarak iyi açıklıyor
    “Saldırganın kötü amaçlı bir yapay zeka modeli ve eğitim prosedürleri çalıştırabilmesi” temel nedendi; bu da özünde kod çalıştırmadır
    Yapay zeka ürünleri yaygınlaştığı ve altyapılarına dikkat etmek gerektiği için bunun araştırılıp incelendiğini düşünüyorum
  • Satılan marka sorumluluğu üstlenmeli
    Güvenliği uygulamak, güvenlik ihtiyacını bilmek, test etmek ya da güvenli olana kadar piyasaya sürmemek; bunların hepsi satıcı olarak o markanın yapması gereken işler

• SAP’nin, Wiz’in araştırmasının neden tam küme yöneticisi yetkisine ulaşmadan engellenmediğini ciddi biçimde değerlendirmesini isterim
  SAP tarafının bu etkinlik için uyarı alıp almadığını, doğru düzgün soruşturup soruşturmadığını bilmek isterim. SAP’nin şüpheli ağ etkinliği için yeterli uyarı mekanizmalarına sahip olmasını gerektiren düzenlemelere tabi olup olmadığını ve bu araştırmanın bunları karşılamadıklarının kanıtı sayılıp sayılamayacağını da merak ediyorum

  • Kurallar ve düzenlemeler kesinlikle var. Sertifikasyon sayfasına bakmak yeterli: https://www.sap.com/about/trust-center/certification-complia...
    Sorun, bunlara gerçekten uyulup uyulmadığı; yoksa sadece raftaki klasörlerde mi kaldığı
  • Normalde güvenlik araştırmacısı, sistemde daha derine inmeden önce hedefle iletişime geçip devam etmek için izin almalı
    Bug bounty programları da genellikle kapsam içindeki hedefler için bu tür kurallar ister. Araştırmacı bir güvenlik şirketine bağlı olduğuna göre burada da böyle olmasını beklerim
    Araştırmacılar genelde hangi noktada ek izin istediklerini yazıya ekler, ama bu her zaman olmaz
  • Gerçekten tespit edemedilerse müşteri verilerinin ihlal edilmediğini nasıl bilebiliyorlar, merak ediyorum
  • SAP’nin bulut güvenliği yetkinliği eksik. SAP bulut hizmetlerindeki güvenlik sorunlarının uzun bir listesi var; üstelik bunlar sadece bilinenler
  • Yapay zekada bu tür şeylerin nasıl tespit edileceğini gösteren bir yazı çıksa iyi olurdu

• Bir tiller instance’ının çalışıyor olması şok edici. 2020’den beri desteği kesilmiş durumda: https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Üretim ortamlarında hâlâ 2020 öncesinden, hatta 2010 öncesinden ne kadar çok yazılımın çalıştığını bilseniz dehşete düşerdiniz
    Burada söz konusu olan büyük bir şirket ve tiller’dan uzaklaşmayı gerektiren nispeten karmaşık bir migrasyon var; ama bu hafifletici nedenler olmasa bile eski yazılımlara kolayca rastlanıyor
  • Deneyimlerime göre “desteği kesildi” ifadesi çoğu zaman “henüz kaldırılmadı, o yüzden kullanmaya devam edilebilir” diye algılanıyor; bu da bazen epey moral bozucu oluyor
  • Microsoft Dynamics’te eski, güvensiz ve yamalanmamış legacy code inanılmaz derecede fazla

• Bu gerçekten kötü. Tek bir K8s kümesi işletip güçlü çok kiracılılık güvenceleri mi beklemişler?
  Büyük bulutların hepsi müşteriler arasında sanal makine sınırları ve ayrı K8s kümeleri kullanıyor. Microsoft da birkaç yıl önce K8s’i temel güvenlik sınırı olarak görmeyi beklediği fonksiyon ürünlerinden birinde benzer şekilde yakalanmıştı

  • Yazıda güçlü güvenceler beklendiği kısmı kaçırmış olabilirim; böyle bir beklenti nerede görünüyor?
    Örneğin model eğitimi gibi rastgele kod çalıştırılan bir durumda K8s çok kiracılılığının nasıl bir rol oynadığından emin değilim
    Bana göre ana sorun, proxy/güvenlik duvarı olan Istio’nun arkasına geçince tüm iç ağ iletişimine güvenilmesi. Yine de k8s kümelerini yeterince anlamıyor olabilirim
  • Aynı mantıksal K8s kümesi içinde güçlü çok kiracılılık gerçekçi olarak elde edilmesi zor bir şey
    Sürekli değişen bir hedef olduğu için, admission controller’larla bunu güvenli hale getirme planı da pek iyi değil
    Düşmanca kiracıları varsayan güçlü çok kiracılılığı düşünmek istiyorsanız önce VirtualClusters gibi şeylere bakmak gerekir (https://github.com/kubernetes-sigs/cluster-api-provider-nest...). Bu da sadece kontrol düzlemiyle ilgili; veri düzlemine dokunmuyor bile
    O ek katman olsa bile ne kadar güvenli olduğundan emin değilim. Sanal makine tarafında da yıllardır akıl almaz VM escape açıkları oldu
  • Doğru yapılandırılmış K8S, kelimenin tam anlamıyla çok kiracılılık için tasarlanmıştır
    Her müşteri için ayrı küme tutmak maliyet açısından saçma derecede pahalı ve gezegen için de kötü. Güvenliğin en öncelikli olduğu premium bir ürünse mümkün olabilir, ama müşteri başına ayrı küme fiilen para yakmaktır

• Açık bulup blog içeriği üretmek için izinsiz olarak ağlara sızan şirketlerin yargılanması gerektiğini düşünüyorum
  Bu yazı özellikle açık ifşasıyla ince bir şekilde paketlenmiş saldırgan bir yazı gibi duruyor. “İş birliği için teşekkür edildi” ifadesi de biraz şantaj gibi geliyor

  • Bu söz, “hassas kullanıcı verilerini dikkatsizce toplayıp güvensiz şekilde saklayan şirketler yakından incelenmemeli; masum kullanıcı verilerini kötü niyetli siber suçlulara açık bırakmaya devam etmelerine izin verilmeli” diye yeniden ifade edilebilir
    Bu açıdan bakınca oldukça farklı görünmüyor mu?
  • Davet edilmeden büyük bir şirketi hacklemeye çalışmak suçtur ve normalde ciddi şekilde kovuşturulacak bir iştir
    Ancak hukuk pratiğinin gösterdiği gibi, “milyarlarca dolarınız varsa hukuk artık size uygulanmaz” noktasına varıyor

• Wiz’i kullanan var mı?
  Kurumsal yazılım şirketleri arasında en hızlı roket olabilir. 1,5 yılda 100 milyon dolar ARR’ye, 3. yılın sonunda ise 350 milyon dolara ulaştı
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Kullanıyorum ve çok memnunum. Güvenlik tarafını bir kenara bıraksanız bile, çoklu bulut varlık yönetimini düzgün yapmak için denediğim araçlar içinde en iyisiydi
    Graf özelliğiyle, isterseniz tüm hesaplar genelinde neredeyse her şeyi sorgulayabiliyorsunuz
  • Google’ın 23 milyar dolara satın almaya çalıştığı şirket de bu

• Şirkettekileri ikna edip ürünün yıllık sızma testini üretim ortamında çalıştırabildiğim ve tüm üretim altyapısını kapsam içine aldırabildiğim için mutluyum
  Odak belirli bir ürün ya da sistem olabilir, ama her şey kapsamın içinde. İlk test devam ediyor ve henüz kimse çığlık atmadı; umarım iyi gider

  • Yıllık derken, düzenli iç sızma testi yapmadığınız anlamına mı geliyor?
    Metasploit ile üstünkörü tarayıp geçen seviyenin ötesinde, işini düzgün yapan bir sızma testi şirketi önerebilir misiniz, onu da merak ediyorum

• Doğru okuduysam, müşterinin hesap verileri yine aynı müşteriye mi açığa çıkıyor? Günlüklerin bir kısmı istisna gibi görünüyor

  • Yalnızca günlüklerin bir kısmı değil; başka müşterilerin eğitim verileri ve kodları ile SAP’nin dahili Docker imaj deposu da açığa çıkmış. Üstelik okuma-yazma yetkisiyle!

• Bir güvenlik araştırmacısı, metni gizlemek için pikselleştirmenin iyi bir tercih olmadığını bilecek kadarını biliyor olmalıydı
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Bildirilen tüm hatalar yamalandı ve ele geçirilmiş olabilecek gizli değerler de muhtemelen değiştirildi
    Bulanıklaştırma ya da pikselleştirme, etkili olup olmamasından bağımsız olarak, fiilen gereksiz görünüyor. Gizlenen veriler yerel ana makine adları ve imaj hash’lerinin bir kısmı gibi duruyor
  • Bana göre pikselleştirme değil, bulanıklaştırma vardı
    Düzenleme: Tekrar bakınca bazı yerlerde bulanıklaştırma, bazı yerlerde pikselleştirme yapılmış gibi görünüyor