SAPwned: SAP AI की खामी से ग्राहकों के cloud environment और private AI outputs उजागर

 (wiz.io)
1 पॉइंट द्वारा GN⁺ 2024-07-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Wiz Research ने पुष्टि की कि SAP AI Core में tenant isolation vulnerabilities की chain के जरिए, एक सामान्य AI training job से शुरू हुआ code execution service takeover और customer secrets तक पहुंच में बदल सकता था
  • attack path में Istio network restrictions को bypass करना, Loki configuration में AWS token exposure, बिना authentication वाली EFS share, और बिना authentication वाले Helm v2 Tiller access की chain शामिल थी
  • हासिल की गई permissions से SAP internal Docker Registry, Google Container Registry और internal Artifactory की images और artifacts को पढ़ा और modify किया जा सकता था, और Kubernetes cluster की cluster-admin permissions भी मिल सकती थीं
  • संभावित attacker ग्राहकों के AWS, Azure, SAP HANA Cloud credentials और models, datasets, code जैसे private AI outputs तक पहुंच सकता था, या internal artifacts को contaminate कर सकता था
  • SAP ने report की गई सभी vulnerabilities fix कर दीं और संबंधित secrets rotate किए, और Wiz ने कहा कि customer data breach नहीं हुआ

SAP AI Core में सामने आई tenant isolation problem

  • Wiz Research AI service providers के tenant isolation की जांच कर रहा है, और SAP AI Core, Hugging Face और Replicate के बाद तीसरी report है
  • SAP AI Core एक managed service है जो users को SAP के cloud resources पर AI services develop, train और run करने देती है
  • AI training services को बड़ी मात्रा में sensitive customer data तक पहुंच की जरूरत होती है, और SAP AI Core HANA व अन्य cloud services से integration के लिए customer internal data तक पहुंचने वाली cloud access keys इस्तेमाल करता है
  • research एक SAP customer account से शुरू हुई जिसके पास default permissions थीं; उसमें AI project बनाया गया और SAP AI Core द्वारा allow की गई Argo Workflow file से Kubernetes Pod create किया गया
  • design के हिसाब से user Pod के अंदर arbitrary code चला सकता था, लेकिन initial environment में Istio proxy sidecar network access restrict कर रहा था, जिससे internal network scan मुश्किल था

Bug #1: Istio restriction bypass

  • SAP का admission controller खतरनाक security options को block करता था, और container को root के रूप में चलाने की कोशिश भी रोकी गई
  • दो unblocked settings ने network restrictions bypass करने का रास्ता दिया
    • shareProcessNamespace sidecar container के साथ process namespace share करने देता है, जिससे Istio proxy configuration और central Istiod server access token दिख सकता था
    • runAsUser और runAsGroup ने root को छोड़कर अन्य UID allow किए, और Istio के UID 1337 के रूप में run करना संभव था
  • Istio खुद Istio iptables rules से exclude होता है, इसलिए UID 1337 से run की गई process बिना traffic restrictions काम करती है
  • इसके बाद Istio token से Istiod server की configuration पढ़कर internal environment की जानकारी हासिल की जा सकती थी

Bug #2: Loki configuration में AWS token exposure

  • cluster के अंदर Grafana Loki instance मिला, और /config endpoint request से पूरी configuration देखी जा सकती थी
  • response में Loki द्वारा S3 access के लिए इस्तेमाल किए जाने वाले AWS secrets शामिल थे
  • इन secrets ने Loki के S3 bucket तक access दिया, और उस bucket में AI Core service logs और customer Pod logs बड़ी मात्रा में थे
  • SAP ने माना कि ये logs sensitive नहीं थे

Bug #3: बिना authentication वाली EFS share से user files exposed

  • internal network में port 2049 सुनने वाले AWS Elastic File System, यानी EFS, के 6 instances मिले
  • ये EFS instances ऐसी स्थिति में थे कि network access मिलते ही credentials के बिना files देखी या edit की जा सकती थीं
  • केवल open source NFS tools से share contents तक freely access किया जा सकता था
  • EFS में customer ID के हिसाब से classified code और training datasets समेत बड़ी मात्रा में AI data stored था

Bug #4: बिना authentication वाले Helm Tiller ने internal Registry और Artifactory expose किए

  • internal network में Helm v2 के server component Tiller service मिली
  • Tiller port 44134 के gRPC interface से communicate करता है, और default रूप से authentication के बिना exposed रहता है
  • Tiller query के result में SAP Docker Registry और Artifactory servers के लिए high-privilege secrets exposed हुए
  • read permission से internal images और builds पढ़कर trade secrets और customer data extract किया जा सकता था
  • write permission से images और builds contaminate करके SAP AI Core service पर supply-chain attack किया जा सकता था

Bug #5: Helm Tiller write permission से Kubernetes cluster takeover

  • Tiller read के साथ-साथ write operations भी allow कर रहा था
  • install command Helm package लेकर Kubernetes cluster में deploy करती है, इसलिए research team ने cluster-admin permission वाला नया Pod create करने वाला malicious Helm package बनाया और install किया
  • इस process से cluster पर full permissions हासिल हो गईं
  • यह permission level अन्य customers के Pods तक direct access करके models, datasets, code जैसे sensitive data चुराने के लिए काफी था
  • साथ ही customer Pods को disrupt किया जा सकता था, AI data contaminate किया जा सकता था और model inference manipulate किया जा सकता था
  • इसी permission से SAP AI Core के scope से बाहर के customer secrets भी plaintext में query किए जा सकते थे
    • research team के AI Core account में S3 data access के लिए AWS account secrets थे
    • Data Lake access के लिए SAP HANA account secrets थे
    • image pull के लिए Docker Hub account secrets थे
  • इसी query में sap-docker-registry-secret नाम की Google Container Registry के लिए SAP access key भी दिखी, और यह key read व write दोनों permissions देती थी

Confirmed access scope और potential impact

  • vulnerabilities की chain से ये काम संभव थे
    • SAP internal container Registry की Docker images read और modify करना
    • Google Container Registry में मौजूद SAP Docker images read और modify करना
    • SAP internal Artifactory server के artifacts read और modify करना
    • SAP AI Core Kubernetes cluster की cluster-admin permissions हासिल करना
    • customer cloud credentials और private AI outputs तक access
  • संभावित attacker customer data तक पहुंच सकता था और internal artifacts contaminate करके impact को related services और अन्य customer environments तक फैला सकता था
  • सभी vulnerabilities SAP security team को report की गईं और SAP ने उन्हें fix किया; SAP ने इन्हें security researcher credits page पर acknowledge किया
  • customer data breach नहीं हुआ

Defense perspective से सामने आई problems

  • मुख्य defense line यह structure था कि Istio internal network access रोकता था, लेकिन यह barrier bypass होने के बाद कई internal assets ने additional authentication नहीं मांगा
  • internal network को trusted area की तरह treat करने से, एक bypass service takeover तक expand हो गया
  • अगर internal services hardened होतीं, तो attack impact complete service takeover की बजाय एक छोटी security incident के level तक घट सकता था
  • Kubernetes-based managed services में control plane और customer compute API, identity, shared compute और software-based network separation से logically connected होते हैं, इसलिए tenant isolation traps पैदा हो सकते हैं
  • AI training inherently arbitrary code execution मांगती है, इसलिए guardrails चाहिए ताकि untrusted code internal assets और दूसरे tenants से properly isolated रहे

Disclosure timeline

  • 25 जनवरी 2024: Wiz Research ने security findings SAP को report कीं
  • 27 जनवरी 2024: SAP ने जवाब दिया और case number assign किया
  • 16 फरवरी 2024: SAP ने पहली vulnerability fix की और related secrets rotate किए
  • 28 फरवरी 2024: Wiz Research ने 2 नई vulnerabilities के साथ patch bypass किया और SAP को report किया
  • 15 मई 2024: SAP ने report की गई सभी vulnerabilities के fixes deploy किए
  • 17 जुलाई 2024: public disclosure हुआ

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-19
Hacker News टिप्पणियाँ

  • यह AI प्रोडक्ट है, यह समझ में आता है, लेकिन यहाँ vulnerability k8s configuration में है
    इसका AI प्रोडक्ट, AI training, machine learning, या generative AI से बहुत कम लेना-देना है, और यह ज़्यादा cloud platform security की कमी जैसा मामला है

    • यह शायद इससे भी बदतर हो सकता है। SAP जैसी बड़ी कंपनी, जो बहुत संवेदनशील जानकारी संभालती है, अगर बुनियादी cloud security ही बिगाड़ दे, तो यह किसी नई चीज़ में हुई गलती नहीं बल्कि बहुत आम गलती लगती है
    • लेख यह नहीं कहता कि समस्या खुद प्रोडक्ट में है। बल्कि यह AI training model isolation की समस्या के रूप में इसे काफ़ी अच्छी तरह समझाता है
      “हमलावर malicious AI model और training procedure चला सकते थे” यही मूल कारण था, और मूल रूप से यह code execution ही है
      AI प्रोडक्ट्स तेज़ी से फैल रहे हैं, इसलिए उनकी infrastructure के प्रति सावधान रहने की ज़रूरत है; मुझे लगता है इसी वजह से इस पर research की गई
    • बिकने वाले brand को ज़िम्मेदारी लेनी चाहिए
      security लागू करना, security की ज़रूरत समझना, testing करना, और सुरक्षित होने तक release न करना — यह सब seller के रूप में उसी brand की ज़िम्मेदारी है

  • उम्मीद है SAP ने इस पर गंभीर आत्ममंथन किया होगा कि Wiz की research को full cluster admin privileges तक पहुँचने से पहले क्यों नहीं रोका गया
    मैं जानना चाहूँगा कि SAP को इस activity के alerts मिले थे या नहीं, और उन्होंने इसकी सही जाँच की या नहीं। यह भी जिज्ञासा है कि suspicious network activity के लिए पर्याप्त alerting व्यवस्था रखना SAP पर कोई regulatory requirement है या नहीं, और क्या यह research इस बात का सबूत हो सकती है कि वे उस requirement को पूरा नहीं कर पाए

    • नियम और regulations तो निश्चित रूप से हैं। certification page देखिए: https://www.sap.com/about/trust-center/certification-complia...
      सवाल यह है कि क्या इन्हें वास्तव में पालन किया जाता है, या वे सिर्फ़ शेल्फ़ पर रखे binder में ही मौजूद हैं
    • आम तौर पर security researchers को system में और गहराई तक जाने से पहले target से संपर्क करके यह अनुमति लेनी चाहिए कि वे आगे बढ़ सकते हैं या नहीं
      bug bounty programs भी अक्सर in-scope targets पर ऐसे rules की माँग करते हैं। चूँकि researcher किसी security company से था, इसलिए यहाँ भी ऐसा हुआ होगा, ऐसा अनुमान है
      researchers अक्सर अपने लेख में बताते हैं कि किस बिंदु पर उन्होंने additional permission माँगी, लेकिन हमेशा ऐसा नहीं होता
    • अगर उन्होंने सच में इसे detect नहीं किया, तो फिर वे कैसे जानते हैं कि customer data से समझौता नहीं हुआ?
    • SAP की cloud security capability कमज़ोर है। SAP cloud services की security issues की सूची लंबी है, और वह भी सिर्फ़ ज्ञात मामलों की
    • अच्छा होगा अगर कोई लेख आए जो दिखाए कि AI में ऐसी चीज़ों को detect कैसे किया जाए

  • यह चौंकाने वाला है कि tiller instance चल रहा था। इसका support 2020 से बंद है: https://helm.sh/blog/helm-v2-deprecation-timeline/

    • अगर आपको पता चले कि production में अभी भी 2020 से पहले का, यहाँ तक कि 2010 से पहले का software कितना चल रहा है, तो आप दंग रह जाएँगे
      यहाँ मामला बड़े enterprise का है और tiller से बाहर आने के लिए कुछ जटिल migration भी है, लेकिन ऐसी अतिरिक्त परिस्थितियों के बिना भी पुराना software आसानी से मिल जाता है
    • मेरे अनुभव में “support बंद” को अक्सर “अभी हटाया तो नहीं गया है, इसलिए इस्तेमाल करते रहो” की तरह लिया जाता है, और यह कभी-कभी काफ़ी निराशाजनक होता है
    • Microsoft Dynamics में बहुत सारा पुराना, असुरक्षित और unpatched legacy code है

  • यह वाकई बहुत बुरा है। क्या वे single K8s cluster चलाकर strong multi-tenancy guarantees की उम्मीद कर रहे थे?
    सभी बड़े cloud providers ग्राहकों के बीच virtual machine boundary और अलग K8s clusters का उपयोग करते हैं। कुछ साल पहले Microsoft भी एक ऐसे function product में इसी तरह फँसा था जहाँ K8s को मुख्य security boundary माना गया था

    • हो सकता है मैं लेख में strong guarantee की अपेक्षा वाली बात चूक गया हूँ, लेकिन यह अपेक्षा कहाँ दिखती है?
      जैसे model training जैसी स्थिति में, जहाँ arbitrary code execute होता है, वहाँ K8s multi-tenancy की भूमिका क्या है, यह मुझे स्पष्ट नहीं है
      मुझे तो मुख्य समस्या यह लगती है कि proxy/firewall Istio के पीछे आते ही पूरे internal network communication पर भरोसा कर लिया गया। हालाँकि संभव है कि मैं k8s clusters को पूरी तरह न समझता हूँ
    • एक ही logical K8s cluster के अंदर strong multi-tenancy को व्यवहारिक रूप से हासिल करना मुश्किल है
      यह लगातार बदलता हुआ लक्ष्य है, इसलिए admission controllers के ज़रिए इसे सुरक्षित बनाने की योजना भी बहुत अच्छी नहीं लगती
      अगर hostile tenants को ध्यान में रखते हुए strong multi-tenancy पर विचार करना है, तो VirtualClusters जैसी चीज़ों से शुरू करना चाहिए(https://github.com/kubernetes-sigs/cluster-api-provider-nest...). और वह भी सिर्फ़ control plane की बात है, data plane को तो छूता भी नहीं
      उस अतिरिक्त layer के बाद भी यह कितना सुरक्षित होगा, कहना मुश्किल है। virtual machine क्षेत्र में भी वर्षों तक अजीबोगरीब VM escape vulnerabilities मिलती रही हैं
    • सही तरह configured K8S को वास्तव में multi-tenancy के लिए ही डिज़ाइन किया गया है
      हर customer के लिए अलग cluster रखना बेहिसाब महँगा है और पर्यावरण के लिए भी बुरा है। अगर security सर्वोच्च प्राथमिकता वाला premium product हो तो अलग बात है, लेकिन हर ग्राहक के लिए अलग cluster रखना व्यावहारिक रूप से पैसे जलाने जैसा है

  • मेरा मानना है कि जो कंपनियाँ vulnerability ढूँढकर blog content बनाने के लिए बिना अनुमति network में घुसपैठ करती हैं, उन पर मुकदमा चलना चाहिए
    यह लेख खास तौर पर vulnerability disclosure की हल्की परत चढ़ाए हुए आक्रामक लेख जैसा लगता है। “सहयोग के लिए धन्यवाद” वाली पंक्ति भी थोड़ी extortion जैसी लगती है

    • इसे यूँ भी कहा जा सकता है: “जो कंपनियाँ लापरवाही से sensitive user data इकट्ठा करती हैं और असुरक्षित ढंग से store करती हैं, उन्हें गहराई से जाँचा नहीं जाना चाहिए, और उन्हें malicious cybercriminals के सामने निर्दोष users का data उजागर करते रहने दिया जाना चाहिए”
      इस नज़रिए से देखें तो क्या यह काफ़ी अलग नहीं लगता?
    • बिना बुलावे किसी बड़ी कंपनी को hack करने की कोशिश करना अपराध है, और सामान्यतः इस पर गंभीर prosecution होना चाहिए
      लेकिन जैसा कि कानूनी व्यवहार अक्सर दिखाता है, बात कुछ ऐसी हो जाती है कि “अगर आपके पास अरबों डॉलर हैं, तो कानून अब आप पर लागू नहीं होता”

  • क्या किसी ने Wiz इस्तेमाल किया है?
    यह enterprise software कंपनियों में सबसे तेज़ रॉकेट हो सकता है। सिर्फ 1.5 साल में $100M ARR, और तीसरे साल के अंत तक $350M तक पहुँच गया
    https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

    • मैं इसका इस्तेमाल कर रहा हूँ और बहुत संतुष्ट हूँ। security पहलू को छोड़ भी दें, तो multi-cloud asset management ठीक से करने के लिए जिन tools को मैंने आज़माया है, उनमें यह सबसे अच्छा था
      इसकी graph functionality से आप चाहें तो लगभग किसी भी चीज़ के बारे में सभी accounts में query कर सकते हैं
    • Google इसे $23 billion में acquire करने की कोशिश भी कर रहा है

  • अच्छा हुआ कि मैं कंपनी के लोगों को मना पाया कि product का सालाना penetration test production environment में चलाया जाए, और पूरे production infrastructure को scope में रखा जाए
    फ़ोकस किसी खास product या system पर हो सकता है, लेकिन सब कुछ scope में है। पहला test चल रहा है और अभी तक किसी ने चीखना शुरू नहीं किया है, तो उम्मीद है सब ठीक रहेगा

    • जब आप सालाना कहते हैं, तो क्या इसका मतलब यह समझा जाए कि नियमित internal penetration testing नहीं होती?
      यह भी जानना चाहूँगा कि क्या आप ऐसी penetration testing company recommend कर सकते हैं जो Metasploit से बस ऊपर-ऊपर scan करके निकल जाने से बेहतर काम करे

  • अगर मैंने सही पढ़ा है, तो क्या ग्राहक के account का data उसी ग्राहक को exposed हो रहा था? सिर्फ logs का कुछ हिस्सा अपवाद लगता है

    • सिर्फ logs का कुछ हिस्सा ही नहीं, बल्कि दूसरे ग्राहकों का training data और code, और यहाँ तक कि SAP का internal Docker image repository भी exposed था। वह भी read-write permissions के साथ!

  • अगर आप security researcher हैं, तो शायद आपको इतना तो पता होना चाहिए कि टेक्स्ट छिपाने के लिए pixelation अच्छा विकल्प नहीं है
    https://www.bleepingcomputer.com/news/security/researcher-re...

    • report किए गए bugs सब patch कर दिए गए हैं, और जिन secrets के compromise होने की आशंका थी, वे शायद rotate भी कर दिए गए होंगे
      blur या pixelation, असरदार हो या न हो, यहाँ व्यावहारिक रूप से अनावश्यक लगते हैं। छिपाया गया data local hostnames और image hashes के कुछ हिस्सों जैसा दिखता है
    • मेरी नज़र में वह pixelation नहीं बल्कि blur था
      संपादन: दोबारा देखने पर लगता है कि कुछ जगह blur था, और कुछ जगह pixelation