SAPwned: ช่องโหว่ SAP AI เปิดเผยสภาพแวดล้อมคลาวด์ของลูกค้าและผลงาน AI ส่วนตัว

 (wiz.io)
1 คะแนน โดย GN⁺ 2024-07-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Wiz Research พบว่าชุดช่องโหว่ใน การแยกเทนแนนต์ ของ SAP AI Core สามารถทำให้การรันโค้ดที่เริ่มจากงานฝึก AI ปกติ ลุกลามไปสู่การยึดบริการและการเข้าถึงความลับของลูกค้าได้
  • เส้นทางโจมตีเป็นโครงสร้างที่หลายประเด็นเชื่อมต่อกันเป็นลูกโซ่ ได้แก่ การเลี่ยงข้อจำกัดเครือข่ายของ Istio, การเปิดเผยโทเคน AWS ในการตั้งค่า Loki, EFS share ที่ไม่ต้องยืนยันตัวตน และการเข้าถึง Helm v2 Tiller ที่ไม่ต้องยืนยันตัวตน
  • ด้วยสิทธิ์ที่ได้มา สามารถอ่านและแก้ไข image และ artifact ใน Docker Registry ภายในของ SAP, Google Container Registry และ Artifactory ภายในได้ รวมถึงได้รับสิทธิ์ cluster-admin ของ Kubernetes cluster ด้วย
  • ผู้โจมตีที่เป็นไปได้สามารถเข้าถึง credentials ของลูกค้าสำหรับ AWS, Azure, SAP HANA Cloud รวมถึง ผลงาน AI ส่วนตัว เช่น โมเดล ชุดข้อมูล และโค้ด หรือทำให้ artifact ภายในปนเปื้อนได้
  • SAP แก้ไขช่องโหว่ทั้งหมดที่ถูกรายงานและ rotate ค่าความลับที่เกี่ยวข้องแล้ว โดย Wiz ระบุว่า ไม่มีการละเมิดข้อมูลลูกค้า

ปัญหาการแยกเทนแนนต์ที่พบใน SAP AI Core

  • Wiz Research ได้ตรวจสอบ การแยกเทนแนนต์ ของผู้ให้บริการ AI และ SAP AI Core เป็นรายงานฉบับที่สาม ต่อจาก Hugging Face และ Replicate
  • SAP AI Core เป็นบริการแบบ managed ที่ให้ผู้ใช้พัฒนา ฝึก และรันบริการ AI บนทรัพยากรคลาวด์ของ SAP ได้
  • บริการฝึก AI จำเป็นต้องเข้าถึงข้อมูลลูกค้าที่ละเอียดอ่อนจำนวนมาก และ SAP AI Core ใช้ cloud access key ที่เข้าถึงข้อมูลภายในของลูกค้าเพื่อผสานการทำงานกับ HANA และบริการคลาวด์อื่น ๆ
  • การวิจัยเริ่มจากการสร้างโปรเจกต์ AI ด้วยบัญชีลูกค้า SAP ที่มีสิทธิ์พื้นฐาน แล้วสร้าง Kubernetes Pod ผ่านไฟล์ Argo Workflow ที่ SAP AI Core อนุญาต
  • ตามการออกแบบ ผู้ใช้สามารถรันโค้ดใด ๆ ภายใน Pod ได้ แต่ในสภาพแวดล้อมเริ่มต้น Istio proxy sidecar จำกัดการเข้าถึงเครือข่าย ทำให้การสแกนเครือข่ายภายในทำได้ยาก

Bug #1: เลี่ยงข้อจำกัดของ Istio

  • admission controller ของ SAP บล็อกตัวเลือกด้านความปลอดภัยที่อันตราย และบล็อกความพยายามในการรันคอนเทนเนอร์เป็น root ด้วย
  • มีการตั้งค่าสองรายการที่ไม่ถูกบล็อกและนำไปสู่การเลี่ยงข้อจำกัดเครือข่าย
    • shareProcessNamespace ทำให้แชร์ process namespace กับคอนเทนเนอร์ sidecar ได้ จึงมองเห็นการตั้งค่า Istio proxy และโทเคนสำหรับเข้าถึงเซิร์ฟเวอร์ Istiod ส่วนกลาง
    • runAsUser และ runAsGroup อนุญาต UID อื่นที่ไม่ใช่ root และสามารถรันด้วย UID ของ Istio คือ 1337 ได้
  • Istio เองถูก ยกเว้นจากกฎ iptables ของ Istio ดังนั้น process ที่รันด้วย UID 1337 จึงทำงานได้ โดยไม่มีข้อจำกัดทราฟฟิก
  • หลังจากนั้นสามารถใช้โทเคน Istio อ่านการตั้งค่าของเซิร์ฟเวอร์ Istiod และรวบรวมข้อมูลสภาพแวดล้อมภายในได้

Bug #2: การเปิดเผยโทเคน AWS ในการตั้งค่า Loki

  • พบ instance ของ Grafana Loki ภายใน cluster และสามารถดูการตั้งค่าทั้งหมดได้จากการส่งคำขอไปยัง endpoint /config
  • การตอบกลับมี ค่าความลับ AWS ที่ Loki ใช้เข้าถึง S3 อยู่ด้วย
  • ค่าความลับนี้ให้สิทธิ์เข้าถึง S3 bucket ของ Loki โดย bucket ดังกล่าวมี log ของบริการ AI Core และ log ของ Pod ลูกค้าจำนวนมาก
  • SAP มองว่า log เหล่านี้ไม่ใช่ข้อมูลอ่อนไหว

Bug #3: ไฟล์ผู้ใช้รั่วไหลจาก EFS share ที่ไม่ต้องยืนยันตัวตน

  • พบ instance ของ AWS Elastic File System หรือ EFS จำนวน 6 รายการที่รับฟังพอร์ต 2049 ในเครือข่ายภายใน
  • instance EFS เหล่านี้อยู่ในสถานะที่หากเข้าถึงเครือข่ายได้ ก็สามารถดูหรือแก้ไขไฟล์ได้โดยไม่ต้องใช้ credentials
  • สามารถเข้าถึงเนื้อหาใน share ได้อย่างอิสระด้วยเครื่องมือ NFS แบบโอเพนซอร์สเท่านั้น
  • ใน EFS มี ข้อมูล AI จำนวนมาก เช่น โค้ดและชุดข้อมูลฝึกที่ถูกจัดหมวดหมู่ตาม ID ลูกค้า

Bug #4: Helm Tiller ที่ไม่ต้องยืนยันตัวตนเปิดเผย Registry และ Artifactory ภายใน

  • พบ service Tiller ซึ่งเป็น server component ของ Helm v2 ในเครือข่ายภายใน
  • Tiller สื่อสารผ่านอินเทอร์เฟซ gRPC บนพอร์ต 44134 และโดยค่าเริ่มต้นถูกเปิดให้เข้าถึงโดยไม่ต้องยืนยันตัวตน
  • ผลการ query Tiller เปิดเผยค่าความลับที่มีสิทธิ์สูงสำหรับ SAP Docker Registry และ Artifactory server
  • สิทธิ์อ่านสามารถใช้อ่าน image และ build ภายในเพื่อดึงความลับทางธุรกิจและข้อมูลลูกค้าได้
  • สิทธิ์เขียนสามารถใช้ทำให้ image และ build ปนเปื้อน เพื่อทำ การโจมตี supply chain ต่อบริการ SAP AI Core ได้

Bug #5: ยึด Kubernetes cluster ด้วยสิทธิ์เขียนของ Helm Tiller

  • Tiller อนุญาตไม่เพียงงานอ่านเท่านั้น แต่ยังรวมถึงงานเขียนด้วย
  • คำสั่ง install รับ Helm package แล้ว deploy ไปยัง Kubernetes cluster ดังนั้นทีมวิจัยจึงสร้างและติดตั้ง Helm package อันตรายที่สร้าง Pod ใหม่พร้อมสิทธิ์ cluster-admin
  • กระบวนการนี้ทำให้ได้ สิทธิ์เต็มรูปแบบ เหนือ cluster
  • สิทธิ์ดังกล่าวอยู่ในระดับที่สามารถเข้าถึง Pod ของลูกค้ารายอื่นโดยตรงเพื่อขโมยข้อมูลอ่อนไหว เช่น โมเดล ชุดข้อมูล และโค้ดได้
  • อีกทั้งยังสามารถรบกวน Pod ของลูกค้า ทำให้ข้อมูล AI ปนเปื้อน และบิดเบือนการ inference ของโมเดลได้
  • ด้วยสิทธิ์เดียวกัน ยังสามารถดูค่าความลับของลูกค้านอกขอบเขต SAP AI Core ได้ในรูปแบบ plaintext
    • บัญชี AI Core ของทีมวิจัยมีค่าความลับของบัญชี AWS สำหรับเข้าถึงข้อมูล S3
    • มีค่าความลับของบัญชี SAP HANA สำหรับเข้าถึง Data Lake
    • มีค่าความลับของบัญชี Docker Hub สำหรับ pull image
  • ในการ query เดียวกัน ยังพบ access key ของ SAP สำหรับ Google Container Registry ชื่อ sap-docker-registry-secret และ key นี้ให้ทั้งสิทธิ์อ่านและเขียน

ขอบเขตการเข้าถึงที่ยืนยันแล้วและผลกระทบที่อาจเกิดขึ้น

  • การดำเนินการที่เป็นไปได้ผ่านชุดช่องโหว่นี้มีดังนี้
    • อ่านและแก้ไข Docker image ใน container Registry ภายในของ SAP
    • อ่านและแก้ไข SAP Docker image ใน Google Container Registry
    • อ่านและแก้ไข artifact ใน Artifactory server ภายในของ SAP
    • ได้รับสิทธิ์ cluster-admin ของ SAP AI Core Kubernetes cluster
    • เข้าถึง cloud credentials ของลูกค้าและผลงาน AI ส่วนตัว
  • ผู้โจมตีที่เป็นไปได้สามารถเข้าถึงข้อมูลลูกค้า และทำให้ artifact ภายในปนเปื้อนเพื่อขยายผลกระทบไปยังบริการที่เกี่ยวข้องและสภาพแวดล้อมของลูกค้ารายอื่นได้
  • ช่องโหว่ทั้งหมดถูกรายงานไปยังทีมความปลอดภัยของ SAP และ SAP ได้แก้ไขแล้ว โดย SAP ยอมรับเรื่องนี้ใน หน้าขอบคุณนักวิจัยด้านความปลอดภัย
  • ข้อมูลลูกค้าไม่ได้ถูกละเมิด

ประเด็นที่ปรากฏในมุมมองด้านการป้องกัน

  • แนวป้องกันหลักคือโครงสร้างที่ Istio ป้องกันการเข้าถึงเครือข่ายภายใน แต่เมื่อข้ามกำแพงนี้ได้แล้ว สินทรัพย์ภายในหลายรายการก็ไม่ต้องการการยืนยันตัวตนเพิ่มเติม
  • เมื่อเครือข่ายภายในถูกปฏิบัติเหมือนเป็นพื้นที่ที่เชื่อถือได้ การเลี่ยงเพียงจุดเดียวจึงขยายผลเป็น การยึดบริการ
  • หากบริการภายในถูก harden ไว้ ผลกระทบจากการโจมตีอาจลดลงจากการยึดบริการเต็มรูปแบบเหลือเพียงเหตุการณ์ความปลอดภัยขนาดเล็กได้
  • managed service ที่ใช้ Kubernetes อาจเกิด กับดักการแยกเทนแนนต์ เพราะ control plane และ compute ของลูกค้าเชื่อมต่อกันในเชิงตรรกะผ่าน API, identity, compute ที่ใช้ร่วมกัน และการแยกเครือข่ายด้วยซอฟต์แวร์
  • การฝึก AI โดยธรรมชาติจำเป็นต้องรันโค้ดใด ๆ ได้ จึงต้องมี guardrail เพื่อให้โค้ดที่ไม่น่าเชื่อถือถูกแยกออกจากสินทรัพย์ภายในและเทนแนนต์อื่นอย่างเหมาะสม

กำหนดการเปิดเผย

  • 25 มกราคม 2024: Wiz Research รายงานสิ่งที่ค้นพบด้านความปลอดภัยให้ SAP
  • 27 มกราคม 2024: SAP ตอบกลับและกำหนดหมายเลขเคส
  • 16 กุมภาพันธ์ 2024: SAP แก้ไขช่องโหว่แรกและ rotate ค่าความลับที่เกี่ยวข้อง
  • 28 กุมภาพันธ์ 2024: Wiz Research เลี่ยงแพตช์ด้วยช่องโหว่ใหม่ 2 รายการและรายงานให้ SAP
  • 15 พฤษภาคม 2024: SAP deploy การแก้ไขสำหรับช่องโหว่ทั้งหมดที่ถูกรายงาน
  • 17 กรกฎาคม 2024: เปิดเผยต่อสาธารณะ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-19
ความคิดเห็นบน Hacker News

  • เข้าใจว่าเป็นผลิตภัณฑ์ AI แต่ช่องโหว่ตรงนี้อยู่ที่ การตั้งค่า k8s
    แทบไม่เกี่ยวกับตัวผลิตภัณฑ์ AI เอง การฝึก AI, แมชชีนเลิร์นนิง หรือ generative AI แต่ใกล้เคียงกับ ความปลอดภัยของแพลตฟอร์มคลาวด์ ที่หละหลวมมากกว่า

    • อาจจะแย่กว่านั้นด้วยซ้ำ เพราะบริษัทขนาดใหญ่และจัดการข้อมูลสำคัญจำนวนมากอย่าง SAP กลับทำ ความปลอดภัยคลาวด์ ขั้นพื้นฐานพัง ฟังดูเหมือนไม่ใช่ความผิดพลาดกับของใหม่ แต่เป็นข้อผิดพลาดทั่วไป
    • บทความไม่ได้บอกว่าเป็นปัญหาของตัวผลิตภัณฑ์เอง ตรงกันข้าม อธิบายได้ดีว่าเป็นปัญหาเรื่อง การแยก isolation ของโมเดลฝึก AI
      สาเหตุรากคือ “ผู้โจมตีสามารถรันโมเดล AI และขั้นตอนการฝึกที่เป็นอันตรายได้” ซึ่งโดยแก่นแล้วก็คือการรันโค้ด
      ผมเข้าใจว่างานวิจัย/ตรวจสอบนี้เกิดขึ้นเพราะผลิตภัณฑ์ AI แพร่หลายขึ้น และต้องระวังโครงสร้างพื้นฐานของมัน
    • แบรนด์ ที่ขายต้องรับผิดชอบ
      การใส่ระบบความปลอดภัย การรู้ว่าจำเป็นต้องมีความปลอดภัย การทดสอบ หรือการไม่ปล่อยออกมาจนกว่าจะปลอดภัย ล้วนเป็นสิ่งที่แบรนด์นั้นต้องทำในฐานะผู้ขาย

  • อยากให้ SAP ทบทวนอย่างจริงจังว่าทำไมงานวิจัยของ Wiz ถึงไม่ถูกสกัดก่อนจะไปถึง สิทธิ์ผู้ดูแลระบบทั้งคลัสเตอร์
    อยากรู้ว่าฝั่ง SAP ได้รับการแจ้งเตือนเกี่ยวกับกิจกรรมนี้หรือไม่ และได้สอบสวนอย่างเหมาะสมหรือเปล่า ยังสงสัยด้วยว่า SAP อยู่ภายใต้กฎระเบียบที่กำหนดให้ต้องมีระบบแจ้งเตือนเพียงพอสำหรับกิจกรรมเครือข่ายต้องสงสัยหรือไม่ และงานวิจัยครั้งนี้อาจเป็นหลักฐานว่าพวกเขาไม่ผ่านข้อกำหนดนั้นได้หรือไม่

    • กฎและข้อกำหนดมีอยู่แน่นอน ดูหน้าการรับรองได้: https://www.sap.com/about/trust-center/certification-complia...
      ปัญหาคือปฏิบัติตามจริงหรือเปล่า หรือมีอยู่แค่ในแฟ้มที่วางบนชั้นเท่านั้น
    • ปกติแล้วนักวิจัยด้านความปลอดภัยควรติดต่อเป้าหมายเพื่อขออนุญาตก่อนจะเจาะลึกเข้าไปในระบบมากขึ้น
      โปรแกรม bug bounty ก็มักกำหนดกฎแบบนี้ภายในขอบเขตที่อนุญาตอยู่แล้ว นักวิจัยสังกัดบริษัทความปลอดภัย จึงคาดว่ากรณีนี้ก็น่าจะทำเช่นกัน
      นักวิจัยมักเขียนไว้ในบทความว่าขออนุญาตเพิ่มเติม ณ จุดไหน แต่ก็ไม่ใช่เสมอไป
    • ถ้าตรวจจับไม่ได้จริง ๆ ก็สงสัยว่าจะรู้ได้อย่างไรว่า ข้อมูลลูกค้า ไม่ได้ถูกละเมิด
    • SAP ขาด ความสามารถด้านความปลอดภัยคลาวด์ ปัญหาความปลอดภัยของบริการคลาวด์ SAP มีรายการยาวเหยียด และนั่นเฉพาะที่เป็นที่รู้กันแล้วเท่านั้น
    • อยากเห็นบทความที่แสดงให้เห็นว่าจะตรวจจับเรื่องแบบนี้ใน AI ได้อย่างไร

  • น่าตกใจที่ยังมี อินสแตนซ์ tiller รันอยู่ มันถูกยุติการซัพพอร์ตมาตั้งแต่ปี 2020 แล้ว: https://helm.sh/blog/helm-v2-deprecation-timeline/

    • ถ้ารู้ว่ายังมีซอฟต์แวร์ก่อนปี 2020 หรือกระทั่งก่อนปี 2010 รันอยู่ใน production มากแค่ไหน คงขนลุก
      กรณีนี้เป็นองค์กรขนาดใหญ่ และมีการย้ายออกจาก tiller ที่ค่อนข้างซับซ้อนเกี่ยวข้องอยู่ แต่แม้ไม่มีเหตุบรรเทาแบบนั้น ซอฟต์แวร์เก่าก็พบได้ง่ายมาก
    • จากประสบการณ์ “ยุติการซัพพอร์ต” มักถูกตีความว่า “ยังไม่ถูกลบออกไป แปลว่ายังใช้ต่อได้” ซึ่งบางครั้งก็ทำให้ท้อใจพอสมควร
    • Microsoft Dynamics มี โค้ด legacy เก่า ไม่ปลอดภัย และไม่ได้แพตช์อยู่มหาศาล

  • เรื่องนี้แย่มากจริง ๆ คาดหวังการรับประกัน multi-tenancy ที่แข็งแรงทั้งที่รัน คลัสเตอร์ K8s เดียว อย่างนั้นหรือ?
    คลาวด์รายใหญ่ทั้งหมดใช้ขอบเขต virtual machine และคลัสเตอร์ K8s แยกกันระหว่างลูกค้า Microsoft ก็เคยโดนเรื่องคล้ายกันเมื่อไม่กี่ปีก่อนในผลิตภัณฑ์ฟังก์ชันตัวหนึ่งที่คาดหวังให้ K8s เป็นขอบเขตความปลอดภัยหลัก

    • ผมอาจพลาดส่วนที่บทความบอกว่ามีการคาดหวังการรับประกันที่แข็งแรง แต่เห็นความคาดหวังนั้นตรงไหน?
      เช่น ในสถานการณ์ที่รันโค้ดได้ตามอำเภอใจอย่างการฝึกโมเดล ผมไม่ค่อยแน่ใจว่า K8s multi-tenancy มีบทบาทอย่างไร
      ในมุมผม ปัญหาหลักคือเมื่อเข้ามาหลัง Istio ซึ่งเป็นพร็อกซี/ไฟร์วอลล์แล้ว ก็เชื่อถือการสื่อสารเครือข่ายภายในทั้งหมด แต่ก็อาจเป็นเพราะผมเข้าใจคลัสเตอร์ k8s ไม่พอก็ได้
    • การทำ multi-tenancy ที่แข็งแรงภายใน คลัสเตอร์ K8s เชิงตรรกะเดียวกันนั้นทำได้ยากในทางปฏิบัติ
      เป้าหมายเปลี่ยนตลอดเวลา ดังนั้นแผนจะทำให้ปลอดภัยด้วย admission controller ก็ไม่ค่อยดีนัก
      ถ้าจะพิจารณา multi-tenancy ที่แข็งแรงโดยสมมติว่ามี tenant ที่เป็นศัตรู ควรเริ่มดูอย่าง VirtualClusters (https://github.com/kubernetes-sigs/cluster-api-provider-nest...) แต่นั่นก็พูดถึงแค่ control plane ยังไม่ได้แตะ data plane เลย
      แม้มีชั้นเพิ่มนั้น ก็ไม่รู้ว่าปลอดภัยแค่ไหน ในโลก virtual machine เองก็มีช่องโหว่ VM escape ที่เหลือเชื่อมาตลอดหลายปี
    • K8S ที่ตั้งค่าอย่างถูกต้องถูกออกแบบมาเพื่อ multi-tenancy อย่างแท้จริง
      การมีคลัสเตอร์แยกให้ลูกค้าแต่ละรายมีต้นทุนสูงอย่างไร้เหตุผลและไม่ดีต่อโลกด้วย อาจทำได้ถ้าเป็นผลิตภัณฑ์พรีเมียมที่ความปลอดภัยสำคัญสูงสุด แต่คลัสเตอร์แยกต่อลูกค้าโดยพื้นฐานแล้วคือการเผาเงินทิ้ง

  • ผมคิดว่าบริษัทที่เจาะเข้าเครือข่ายโดยไม่ได้รับอนุญาตเพื่อหาช่องโหว่แล้วทำคอนเทนต์ลงบล็อกควรถูกดำเนินคดี
    บทความนี้โดยเฉพาะฟังเหมือน บทความเชิงโจมตี ที่ห่อบาง ๆ ด้วยการเปิดเผยช่องโหว่ คำว่า “ขอบคุณสำหรับความร่วมมือ” ก็ฟังคล้ายการกรรโชกอยู่เล็กน้อย

    • คำพูดนี้สามารถเรียบเรียงใหม่ได้ว่า “บริษัทที่เก็บรวบรวมข้อมูลผู้ใช้ที่ละเอียดอ่อนอย่างประมาทและจัดเก็บอย่างไม่ปลอดภัยไม่ควรถูกตรวจสอบอย่างละเอียด และควรถูกปล่อยให้เปิดเผยข้อมูลผู้ใช้ผู้บริสุทธิ์ต่ออาชญากรไซเบอร์ที่มีเจตนาร้ายต่อไป”
      ถ้ามองจากมุมนั้น มันดูต่างออกไปไม่น้อยใช่ไหม?
    • การพยายามแฮ็กองค์กรขนาดใหญ่โดยไม่ได้รับเชิญเป็นอาชญากรรม และโดยปกติควรถูกดำเนินคดีอย่างหนัก
      แต่ก็ไหลไปในทำนองที่แนวปฏิบัติทางกฎหมายมักบอกว่า “ถ้ามีเงินหลายพันล้านดอลลาร์ กฎหมายก็ไม่บังคับใช้กับคุณอีกต่อไป”

  • มีใครเคยใช้ Wiz ไหม?
    อาจเป็นจรวดที่พุ่งเร็วที่สุดในบรรดาบริษัทซอฟต์แวร์ระดับองค์กร ทำ ARR 100 ล้านดอลลาร์ ได้ใน 1.5 ปี และแตะ 350 ล้านดอลลาร์ เมื่อสิ้นปีที่ 3
    https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

    • ใช้อยู่และพอใจมาก แม้ไม่นับด้านความปลอดภัย ก็เป็นเครื่องมือที่ดีที่สุดเท่าที่เคยลองมาเพื่อทำ การจัดการทรัพย์สินแบบมัลติคลาวด์ ให้ถูกต้อง
      ด้วยฟังก์ชันกราฟ ถ้าต้องการก็ query แทบทุกอย่างข้ามทุกบัญชีได้
    • Google ก็กำลังพยายามซื้อกิจการในราคา 23 พันล้านดอลลาร์ อยู่ด้วย

  • ดีใจที่โน้มน้าวคนในบริษัทให้รัน penetration test ประจำปีของผลิตภัณฑ์บนสภาพแวดล้อม production และทำให้รวมโครงสร้างพื้นฐาน production ทั้งหมดไว้ใน scope ได้
    จุดโฟกัสอาจเป็นผลิตภัณฑ์หรือระบบเฉพาะ แต่ทุกอย่างอยู่ใน scope การทดสอบแรกกำลังดำเนินอยู่และยังไม่มีใครกรีดร้อง ก็หวังว่าจะไปได้ดี

    • ถ้าพูดว่าประจำปี ควรเข้าใจว่าไม่ได้ทำ penetration test ภายในเป็นประจำใช่ไหม?
      อยากรู้ด้วยว่ามีบริษัท penetration test ที่ทำจริงจังมากกว่าระดับใช้ Metasploit กวาดผ่านๆ แล้วจบ แนะนำได้ไหม

  • ถ้าผมอ่านถูก หมายความว่าข้อมูลบัญชีของลูกค้าถูกเปิดเผยให้ลูกค้ารายเดิมเห็นใช่ไหม? ดูเหมือนมีข้อยกเว้นแค่บางส่วนของ log

    • ไม่ใช่แค่บางส่วนของ log แต่ยังเปิดเผย ข้อมูลและโค้ดสำหรับการฝึก ของลูกค้ารายอื่น รวมถึง repository อิมเมจ Docker ภายในของ SAP ด้วย แถมเป็นสิทธิ์อ่าน-เขียน!

  • ถ้าเป็นนักวิจัยด้านความปลอดภัย ก็น่าจะรู้อยู่แล้วว่า การทำพิกเซลเลต เพื่อปิดข้อความไม่ใช่ตัวเลือกที่ดี
    https://www.bleepingcomputer.com/news/security/researcher-re...

    • บั๊กที่รายงานทั้งหมดถูกแพตช์แล้ว และ secret values ที่อาจถูก compromise ก็น่าจะถูกหมุนเปลี่ยนแล้ว
      ไม่ว่าจะมีประสิทธิผลหรือไม่ การเบลอหรือทำพิกเซลเลตดูแทบไม่จำเป็นอยู่ดี ข้อมูลที่ถูกปิดดูเหมือนเป็น hostname บนเครื่อง local และบางส่วนของ image hash
    • เท่าที่ผมดู มันเป็น การเบลอ ไม่ใช่การทำพิกเซลเลต
      แก้ไข: ดูอีกที บางจุดเหมือนเบลอ และบางจุดเหมือนทำพิกเซลเลต