SAPwned: Kerentanan AI SAP mengekspos lingkungan cloud pelanggan dan output AI privat

• Wiz Research mengonfirmasi bahwa melalui rangkaian kerentanan isolasi tenant di SAP AI Core, eksekusi kode yang dimulai dari tugas pelatihan AI yang sah dapat berujung pada pengambilalihan layanan dan akses ke rahasia pelanggan
• Jalur serangan tersusun dari rangkaian kelemahan yang saling terkait: bypass pembatasan jaringan Istio, kebocoran token AWS dalam konfigurasi Loki, share EFS tanpa autentikasi, dan akses Helm v2 Tiller tanpa autentikasi
• Dengan hak akses yang diperoleh, peneliti dapat membaca dan memodifikasi image serta artefak di Docker Registry internal SAP, Google Container Registry, dan Artifactory internal, serta memperoleh hak cluster-admin pada klaster Kubernetes
• Penyerang potensial dapat mengakses kredensial AWS, Azure, dan SAP HANA Cloud milik pelanggan, serta output AI privat seperti model, dataset, dan kode, atau meracuni artefak internal
• SAP telah memperbaiki semua kerentanan yang dilaporkan dan merotasi secret terkait, dan Wiz menyatakan tidak ada pelanggaran data pelanggan

---

Masalah isolasi tenant yang terungkap di SAP AI Core

• Wiz Research telah menyelidiki isolasi tenant pada penyedia layanan AI, dan SAP AI Core adalah laporan ketiga setelah Hugging Face dan Replicate
• SAP AI Core adalah layanan terkelola yang memungkinkan pengguna mengembangkan, melatih, dan menjalankan layanan AI di resource cloud SAP
• Layanan pelatihan AI perlu mengakses data pelanggan sensitif dalam jumlah besar, dan SAP AI Core menggunakan cloud access key yang mengakses data internal pelanggan untuk integrasi dengan HANA dan layanan cloud lainnya
• Riset dimulai dengan membuat proyek AI dari akun pelanggan SAP dengan hak dasar, lalu membuat Kubernetes Pod melalui file Argo Workflow yang diizinkan oleh SAP AI Core
• Secara desain, pengguna dapat menjalankan kode arbitrer di dalam Pod, tetapi pada lingkungan awal, sidecar proxy Istio membatasi akses jaringan sehingga pemindaian jaringan internal sulit dilakukan

Bug #1: Bypass pembatasan Istio

• Admission controller SAP memblokir opsi keamanan berisiko, termasuk upaya menjalankan container sebagai root
• Dua konfigurasi yang tidak diblokir justru memungkinkan bypass pembatasan jaringan
  • shareProcessNamespace memungkinkan berbagi namespace proses dengan container sidecar, sehingga konfigurasi proxy Istio dan token akses ke server pusat Istiod dapat dilihat
  • runAsUser dan runAsGroup mengizinkan UID selain root, sehingga proses dapat dijalankan sebagai UID Istio, yaitu 1337
• Karena Istio sendiri dikecualikan dari aturan iptables Istio, proses yang berjalan dengan UID 1337 dapat beroperasi tanpa pembatasan trafik
• Setelah itu, token Istio dapat digunakan untuk membaca konfigurasi server Istiod dan memperoleh informasi tentang lingkungan internal

Bug #2: Kebocoran token AWS dari konfigurasi Loki

• Di dalam klaster, peneliti menemukan instance Grafana Loki, dan permintaan ke endpoint /config memperlihatkan seluruh konfigurasi
• Respons tersebut menyertakan secret AWS yang digunakan Loki untuk mengakses S3
• Secret ini memberikan akses ke bucket S3 milik Loki, yang berisi banyak log layanan AI Core dan log Pod pelanggan
• SAP menilai log tersebut tidak sensitif

Bug #3: File pengguna terekspos melalui share EFS tanpa autentikasi

• Di jaringan internal, ditemukan 6 instance AWS Elastic File System atau EFS yang mendengarkan di port 2049
• Instance EFS tersebut memungkinkan file dilihat atau diedit tanpa kredensial selama akses jaringan tersedia
• Isi share dapat diakses bebas hanya dengan tool NFS open source
• EFS menyimpan sejumlah besar data AI seperti kode dan dataset pelatihan yang dikelompokkan berdasarkan ID pelanggan

Bug #4: Helm Tiller tanpa autentikasi mengekspos Registry internal dan Artifactory

• Di jaringan internal, ditemukan layanan Tiller, komponen server dari Helm v2
• Tiller berkomunikasi melalui antarmuka gRPC di port 44134 dan secara default terekspos tanpa autentikasi
• Hasil kueri ke Tiller mengungkap secret berprivilege tinggi untuk SAP Docker Registry dan server Artifactory
• Dengan izin baca, image dan build internal dapat dibaca untuk mengekstrak rahasia dagang dan data pelanggan
• Dengan izin tulis, image dan build dapat diracuni untuk melakukan serangan supply chain terhadap layanan SAP AI Core

Bug #5: Hak tulis Helm Tiller memungkinkan pengambilalihan klaster Kubernetes

• Tiller tidak hanya mengizinkan operasi baca tetapi juga operasi tulis
• Karena perintah install menerima paket Helm dan menerapkannya ke klaster Kubernetes, tim riset membuat dan memasang paket Helm berbahaya yang membuat Pod baru dengan hak cluster-admin
• Melalui proses ini, mereka memperoleh hak penuh atas klaster
• Hak ini cukup untuk mengakses langsung Pod milik pelanggan lain dan mencuri data sensitif seperti model, dataset, dan kode
• Hak ini juga memungkinkan mengganggu Pod pelanggan, meracuni data AI, dan memanipulasi inferensi model
• Dengan hak yang sama, secret pelanggan di luar cakupan SAP AI Core juga dapat dilihat dalam bentuk plaintext
  • Akun AI Core milik tim riset memiliki secret akun AWS untuk akses data S3
  • Ada secret akun SAP HANA untuk akses Data Lake
  • Ada secret akun Docker Hub untuk pull image
• Dari penelusuran yang sama, mereka juga menemukan kunci akses SAP untuk Google Container Registry bernama sap-docker-registry-secret, yang memberikan hak baca dan tulis

Cakupan akses yang terkonfirmasi dan dampak potensial

• Melalui rangkaian kerentanan ini, tindakan berikut dimungkinkan
  • Membaca dan memodifikasi image Docker di container Registry internal SAP
  • Membaca dan memodifikasi image Docker SAP di Google Container Registry
  • Membaca dan memodifikasi artefak di server Artifactory internal SAP
  • Memperoleh hak cluster-admin pada klaster Kubernetes SAP AI Core
  • Mengakses kredensial cloud pelanggan dan output AI privat
• Penyerang potensial dapat mengakses data pelanggan dan meracuni artefak internal untuk menyebarkan dampak ke layanan terkait dan lingkungan pelanggan lain
• Semua kerentanan telah dilaporkan ke tim keamanan SAP dan telah diperbaiki oleh SAP, dan SAP mengakuinya di halaman kredit peneliti keamanan
• Data pelanggan tidak dilanggar

Masalah yang terlihat dari sudut pandang pertahanan

• Garis pertahanan utama adalah Istio yang memblokir akses ke jaringan internal, tetapi setelah penghalang ini dibypass, banyak aset internal tidak memerlukan autentikasi tambahan
• Karena jaringan internal diperlakukan seperti area tepercaya, satu bypass berkembang menjadi pengambilalihan layanan
• Jika layanan internal telah diperkeras, dampak serangan bisa berkurang dari pengambilalihan layanan total menjadi insiden keamanan kecil
• Pada layanan terkelola berbasis Kubernetes, control plane dan compute pelanggan terhubung secara logis melalui API, ID, compute bersama, dan pemisahan jaringan berbasis perangkat lunak, sehingga dapat muncul jebakan isolasi tenant
• Pelatihan AI pada dasarnya memerlukan eksekusi kode arbitrer, sehingga diperlukan guardrail agar kode yang tidak tepercaya terisolasi dengan benar dari aset internal dan tenant lain

Jadwal pengungkapan

• 25 Januari 2024: Wiz Research melaporkan temuan keamanan ke SAP
• 27 Januari 2024: SAP merespons dan menetapkan nomor kasus
• 16 Februari 2024: SAP memperbaiki kerentanan pertama dan merotasi secret terkait
• 28 Februari 2024: Wiz Research membypass patch dengan 2 kerentanan baru dan melaporkannya ke SAP
• 15 Mei 2024: SAP merilis perbaikan untuk semua kerentanan yang dilaporkan
• 17 Juli 2024: Dipublikasikan

[GN⁺]

Pendapat di Hacker News

• Saya paham ini produk AI, tetapi kerentanannya di sini ada pada konfigurasi k8s
  Ini tidak terlalu terkait dengan produk AI itu sendiri, pelatihan AI, machine learning, atau AI generatif; lebih dekat ke keamanan platform cloud yang buruk

  • Justru bisa jadi lebih buruk. Perusahaan sebesar SAP yang menangani begitu banyak informasi penting malah mengacaukan keamanan cloud dasar; ini terdengar bukan seperti salah menerapkan hal baru, melainkan melakukan kesalahan umum
  • Tulisannya tidak mengatakan bahwa ini masalah pada produk itu sendiri. Justru dijelaskan dengan baik sebagai masalah isolasi model pelatihan AI
    Akar masalahnya adalah “penyerang dapat menjalankan model AI berbahaya dan prosedur pelatihan,” yang pada dasarnya adalah eksekusi kode
    Saya memahaminya sebagai sesuatu yang diteliti/diinvestigasi karena produk AI makin meluas, sehingga infrastrukturnya perlu diwaspadai
  • Merek yang dijual harus bertanggung jawab
    Menerapkan keamanan, mengetahui perlunya keamanan, menguji, atau tidak merilis sampai aman—semua itu adalah tugas merek tersebut sebagai penjual

• Saya berharap SAP melakukan retrospeksi keras soal mengapa riset Wiz tidak diblokir sebelum mencapai hak administrator penuh atas klaster
  Saya ingin tahu apakah pihak SAP menerima peringatan atas aktivitas ini dan apakah mereka menyelidikinya dengan benar. Saya juga penasaran apakah SAP tunduk pada regulasi yang mewajibkan sistem peringatan memadai untuk aktivitas jaringan mencurigakan, dan apakah riset ini bisa menjadi bukti bahwa mereka gagal memenuhinya

  • Aturan dan regulasinya jelas ada. Lihat halaman sertifikasi: https://www.sap.com/about/trust-center/certification-complia...
    Masalahnya adalah apakah itu benar-benar dipatuhi, atau cuma ada di binder yang tersimpan di rak
  • Biasanya peneliti keamanan harus menghubungi target sebelum masuk lebih dalam ke sistem dan meminta izin untuk melanjutkan
    Program bug bounty pun sering mewajibkan aturan seperti ini dalam cakupan target. Karena penelitinya berasal dari perusahaan keamanan, saya menduga hal yang sama juga terjadi di sini
    Peneliti biasanya menulis di titik mana mereka meminta izin tambahan, tetapi tidak selalu begitu
  • Kalau memang tidak terdeteksi, saya bertanya-tanya bagaimana mereka bisa tahu bahwa data pelanggan tidak dilanggar
  • SAP kurang memiliki kapabilitas keamanan cloud. Ada daftar panjang masalah keamanan pada layanan cloud SAP, dan itu pun hanya yang diketahui
  • Akan bagus kalau ada tulisan yang menunjukkan cara mendeteksi hal seperti ini di AI

• Mengejutkan bahwa instans tiller masih berjalan. Itu sudah tidak didukung sejak 2020: https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Anda mungkin akan ngeri kalau tahu berapa banyak software pra-2020, bahkan pra-2010, yang masih berjalan di lingkungan produksi
    Dalam kasus ini perusahaannya besar dan ada migrasi yang agak rumit untuk lepas dari tiller, tetapi software lama mudah ditemukan bahkan tanpa keadaan yang meringankan seperti itu
  • Dari pengalaman, “tidak didukung lagi” sering ditafsirkan sebagai “belum dihapus, jadi masih boleh dipakai,” yang kadang cukup membuat putus asa
  • Microsoft Dynamics punya sangat banyak kode legacy yang tua, tidak aman, dan tidak ditambal

• Ini benar-benar buruk. Mereka menjalankan satu klaster K8s dan berharap ada jaminan multi-tenancy yang kuat?
  Semua cloud besar memakai batas mesin virtual dan klaster K8s terpisah antar pelanggan. Microsoft juga pernah mengalami hal serupa beberapa tahun lalu pada salah satu produk functions mereka yang mengandalkan K8s sebagai batas keamanan utama

  • Mungkin saya melewatkan bagian di tulisan yang menyebut mereka mengharapkan jaminan kuat, tetapi di mana ekspektasi itu terlihat?
    Misalnya dalam situasi menjalankan kode arbitrer seperti pelatihan model, saya kurang paham peran multi-tenancy K8s
    Menurut saya masalah utamanya adalah setelah masuk di belakang Istio sebagai proxy/firewall, semua komunikasi jaringan internal dipercaya. Namun bisa jadi saya memang belum cukup memahami klaster k8s
  • Multi-tenancy yang kuat di dalam klaster K8s logis yang sama sulit dicapai dalam praktik
    Targetnya terus bergerak, jadi rencana membuatnya aman dengan admission controller juga tidak terlalu bagus
    Kalau ingin mempertimbangkan multi-tenancy kuat dengan tenant yang bersifat adversarial, mulailah melihat hal seperti VirtualClusters (https://github.com/kubernetes-sigs/cluster-api-provider-nest...). Itu pun baru soal control plane dan belum menyentuh data plane
    Saya juga tidak tahu seberapa aman meski ada lapisan tambahan itu. Di ranah mesin virtual pun selama bertahun-tahun ada kerentanan pelarian VM yang tidak masuk akal
  • K8S yang dikonfigurasi dengan benar secara harfiah dirancang untuk multi-tenancy
    Menyediakan klaster terpisah untuk setiap pelanggan biayanya tidak masuk akal besar dan juga buruk bagi bumi. Mungkin bisa untuk produk premium yang mengutamakan keamanan, tetapi klaster terpisah per pelanggan pada dasarnya membakar uang

• Menurut saya perusahaan yang menyusup ke jaringan tanpa izin demi menemukan kerentanan dan membuat konten blog harus dituntut
  Tulisan ini khususnya terdengar seperti tulisan agresif yang dibungkus tipis sebagai pengungkapan kerentanan. Kalimat “kami berterima kasih atas kerja samanya” juga terdengar agak seperti pemerasan

  • Pernyataan ini bisa diparafrasakan menjadi “perusahaan yang secara ceroboh mengumpulkan data pengguna sensitif dan menyimpannya secara tidak aman tidak seharusnya mendapat pengawasan ketat, dan harus dibiarkan terus mengekspos data pengguna tak bersalah kepada penjahat siber jahat”
    Dilihat dari sudut itu, bukankah kesannya jadi cukup berbeda?
  • Mencoba meretas perusahaan besar tanpa diundang adalah kejahatan, dan biasanya akan dituntut secara serius
    Namun seperti kata praktik hukum, arahnya menjadi semacam “kalau punya miliaran dolar, hukum tidak lagi berlaku”

• Ada yang pernah memakai Wiz?
  Mungkin ini roket tercepat di antara perusahaan perangkat lunak enterprise. Mencapai ARR 100 juta dolar AS dalam 1,5 tahun, lalu 350 juta dolar AS pada akhir tahun ketiga
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Saya memakainya dan sangat puas. Bahkan di luar aspek keamanan, ini alat terbaik yang pernah saya coba untuk benar-benar mengelola aset multicloud dengan baik
    Dengan fitur graph, jika mau Anda bisa mengkueri praktis apa saja di semua akun
  • Google juga sedang berupaya mengakuisisinya senilai 23 miliar dolar AS

• Saya lega berhasil meyakinkan orang-orang di perusahaan untuk menjalankan penetration test tahunan produk di lingkungan produksi, dan memasukkan seluruh infrastruktur produksi ke dalam cakupannya
  Fokusnya mungkin produk atau sistem tertentu, tetapi semuanya masuk cakupan. Tes pertama sedang berjalan dan sejauh ini belum ada yang berteriak, jadi semoga berjalan baik

  • Kalau disebut tahunan, apakah boleh dipahami bahwa tidak ada penetration test internal yang rutin?
    Saya juga penasaran apakah Anda bisa merekomendasikan perusahaan penetration test yang benar-benar melakukan pengujian dengan baik, bukan sekadar memindai sekilas memakai Metasploit

• Kalau saya membacanya dengan benar, apakah maksudnya data akun pelanggan terekspos kepada pelanggan yang sama? Sepertinya hanya sebagian log yang menjadi pengecualian

  • Bukan hanya sebagian log; data pelatihan dan kode pelanggan lain, bahkan repositori image Docker internal SAP, juga terekspos. Dan itu dengan izin baca-tulis!

• Sebagai peneliti keamanan, mestinya tahu bahwa pixelation untuk menyamarkan teks bukan pilihan yang baik
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Semua bug yang dilaporkan sudah ditambal, dan secret yang mungkin terdampak juga kemungkinan sudah diganti
    Terlepas dari efektif atau tidaknya blur atau pixelation, pada dasarnya tampaknya tidak terlalu diperlukan. Data yang disamarkan terlihat seperti hostname lokal dan sebagian hash image
  • Menurut saya itu bukan pixelation, melainkan blur
    Edit: setelah melihat lagi, sepertinya di beberapa tempat memakai blur, dan di tempat lain memakai pixelation