SAPwned: Lỗ hổng SAP AI làm lộ môi trường đám mây của khách hàng và các đầu ra AI riêng tư

• Wiz Research xác nhận rằng thông qua chuỗi lỗ hổng cô lập tenant trong SAP AI Core, việc thực thi mã bắt đầu từ một tác vụ huấn luyện AI hợp lệ có thể dẫn tới chiếm quyền dịch vụ và truy cập vào bí mật của khách hàng
• Đường tấn công là một chuỗi liên kết gồm vượt qua hạn chế mạng của Istio, rò rỉ token AWS trong cấu hình Loki, chia sẻ EFS không cần xác thực và truy cập Helm v2 Tiller không cần xác thực
• Với quyền đã chiếm được, họ có thể đọc và sửa image và artifact trong Docker Registry nội bộ của SAP, Google Container Registry và Artifactory nội bộ, đồng thời giành được quyền cluster-admin của cụm Kubernetes
• Kẻ tấn công tiềm năng có thể truy cập thông tin xác thực AWS, Azure, SAP HANA Cloud của khách hàng và các đầu ra AI riêng tư như mô hình, bộ dữ liệu và mã nguồn, hoặc đầu độc các artifact nội bộ
• SAP đã vá tất cả các lỗ hổng được báo cáo và xoay vòng các secret liên quan, còn Wiz cho biết không có vi phạm dữ liệu khách hàng

---

Vấn đề cô lập tenant bị phơi bày trong SAP AI Core

• Wiz Research đã nghiên cứu cô lập tenant ở các nhà cung cấp dịch vụ AI, và SAP AI Core là báo cáo thứ ba sau Hugging Face và Replicate
• SAP AI Core là một dịch vụ được quản lý cho phép người dùng phát triển, huấn luyện và chạy các dịch vụ AI trên tài nguyên đám mây của SAP
• Dịch vụ huấn luyện AI cần truy cập lượng lớn dữ liệu nhạy cảm của khách hàng, và SAP AI Core sử dụng khóa truy cập đám mây để truy cập dữ liệu nội bộ của khách hàng nhằm tích hợp với HANA và các dịch vụ đám mây khác
• Nghiên cứu bắt đầu bằng việc tạo một dự án AI từ tài khoản khách hàng SAP có quyền cơ bản, rồi tạo Kubernetes Pod bằng tệp Argo Workflow mà SAP AI Core cho phép
• Theo thiết kế, người dùng có thể chạy mã tùy ý bên trong Pod, nhưng trong môi trường ban đầu, sidecar proxy Istio hạn chế truy cập mạng nên việc quét mạng nội bộ gặp khó khăn

Bug #1: Vượt qua hạn chế của Istio

• Admission controller của SAP chặn các tùy chọn bảo mật nguy hiểm và cả nỗ lực chạy container bằng root
• Hai cấu hình không bị chặn đã dẫn tới việc vượt qua hạn chế mạng
  • shareProcessNamespace cho phép chia sẻ process namespace với container sidecar, từ đó có thể thấy cấu hình proxy Istio và token truy cập vào máy chủ Istiod trung tâm
  • runAsUser và runAsGroup cho phép các UID khác ngoài root, nên có thể chạy bằng UID 1337 của Istio
• Bản thân Istio được loại trừ khỏi các quy tắc iptables của Istio, vì vậy các tiến trình chạy dưới UID 1337 hoạt động không bị hạn chế lưu lượng
• Sau đó, họ dùng token Istio để đọc cấu hình từ máy chủ Istiod và thu thập thông tin về môi trường nội bộ

Bug #2: Rò rỉ token AWS trong cấu hình Loki

• Họ phát hiện một instance Grafana Loki bên trong cụm và có thể xem toàn bộ cấu hình bằng cách gọi endpoint /config
• Phản hồi chứa secret AWS mà Loki dùng để truy cập S3
• Secret này cấp quyền truy cập bucket S3 của Loki, nơi chứa nhiều log dịch vụ AI Core và log Pod của khách hàng
• SAP cho rằng các log này không nhạy cảm

Bug #3: File người dùng bị lộ từ EFS chia sẻ không cần xác thực

• Trong mạng nội bộ, họ phát hiện 6 instance AWS Elastic File System, tức EFS, đang lắng nghe trên cổng 2049
• Các instance EFS này cho phép xem hoặc chỉnh sửa file mà không cần thông tin xác thực, chỉ cần có thể truy cập mạng
• Chỉ với các công cụ NFS mã nguồn mở, họ có thể tự do truy cập nội dung chia sẻ
• EFS lưu trữ lượng lớn dữ liệu AI như mã nguồn và bộ dữ liệu huấn luyện, được phân loại theo ID khách hàng

Bug #4: Helm Tiller không cần xác thực làm lộ Registry và Artifactory nội bộ

• Họ phát hiện dịch vụ Tiller, thành phần máy chủ của Helm v2, trong mạng nội bộ
• Tiller giao tiếp qua giao diện gRPC trên cổng 44134 và mặc định bị lộ mà không có xác thực
• Kết quả truy vấn Tiller cho thấy các secret có đặc quyền cao đối với SAP Docker Registry và máy chủ Artifactory
• Với quyền đọc, có thể đọc các image và bản build nội bộ để lấy bí mật thương mại và dữ liệu khách hàng
• Với quyền ghi, có thể đầu độc image và bản build để thực hiện tấn công chuỗi cung ứng vào dịch vụ SAP AI Core

Bug #5: Quyền ghi qua Helm Tiller dẫn tới chiếm toàn bộ cụm Kubernetes

• Tiller không chỉ cho phép đọc mà còn cho phép các thao tác ghi
• Vì lệnh install nhận gói Helm và triển khai vào cụm Kubernetes, nhóm nghiên cứu đã tạo và cài một gói Helm độc hại để sinh ra Pod mới có quyền cluster-admin
• Qua đó, họ giành được toàn quyền đối với cụm
• Mức quyền này đủ để truy cập trực tiếp vào Pod của khách hàng khác và đánh cắp dữ liệu nhạy cảm như mô hình, bộ dữ liệu và mã nguồn
• Ngoài ra còn có thể gây gián đoạn Pod của khách hàng, đầu độc dữ liệu AI và thao túng suy luận mô hình
• Với cùng quyền đó, họ cũng có thể xem ở dạng rõ ràng các secret của khách hàng vượt ra ngoài phạm vi SAP AI Core
  • Tài khoản AI Core của nhóm nghiên cứu có secret tài khoản AWS để truy cập dữ liệu S3
  • Có secret tài khoản SAP HANA để truy cập Data Lake
  • Có secret tài khoản Docker Hub để pull image
• Trong cùng lần kiểm tra, họ cũng thấy khóa truy cập SAP cho Google Container Registry có tên sap-docker-registry-secret; khóa này cấp cả quyền đọc và ghi

Phạm vi truy cập đã xác nhận và tác động tiềm tàng

• Các hành động có thể thực hiện thông qua chuỗi lỗ hổng gồm
  • Đọc và sửa Docker image trong container Registry nội bộ của SAP
  • Đọc và sửa Docker image của SAP trên Google Container Registry
  • Đọc và sửa artifact trong máy chủ Artifactory nội bộ của SAP
  • Giành quyền cluster-admin trên cụm Kubernetes của SAP AI Core
  • Truy cập thông tin xác thực đám mây của khách hàng và các đầu ra AI riêng tư
• Kẻ tấn công tiềm năng có thể truy cập dữ liệu khách hàng và đầu độc các artifact nội bộ để mở rộng ảnh hưởng sang các dịch vụ liên quan và môi trường khách hàng khác
• Tất cả lỗ hổng đã được báo cho đội ngũ bảo mật SAP và SAP đã khắc phục; SAP cũng ghi nhận điều này trên trang ghi công cho các nhà nghiên cứu bảo mật
• Dữ liệu khách hàng không bị xâm phạm

Các vấn đề bộc lộ từ góc độ phòng thủ

• Tuyến phòng thủ chính là Istio ngăn truy cập mạng nội bộ, nhưng sau khi vượt qua rào cản này, nhiều tài sản nội bộ lại không yêu cầu xác thực bổ sung
• Mạng nội bộ bị đối xử như một vùng đáng tin cậy, khiến chỉ một lần vượt qua cũng có thể leo thang thành chiếm quyền dịch vụ
• Nếu các dịch vụ nội bộ được siết chặt hơn, tác động của cuộc tấn công có thể chỉ dừng ở một sự cố nhỏ thay vì chiếm toàn bộ dịch vụ
• Với dịch vụ được quản lý dựa trên Kubernetes, mặt phẳng điều khiển và tài nguyên tính toán của khách hàng được kết nối logic thông qua API, ID, tài nguyên tính toán chia sẻ và tách biệt mạng bằng phần mềm, nên có thể phát sinh bẫy cô lập tenant
• Huấn luyện AI về bản chất đòi hỏi thực thi mã tùy ý, nên cần các guardrail để bảo đảm mã không đáng tin cậy được tách biệt thích đáng khỏi tài sản nội bộ và các tenant khác

Lịch công bố

• 25 tháng 1 năm 2024: Wiz Research báo cáo phát hiện bảo mật cho SAP
• 27 tháng 1 năm 2024: SAP phản hồi và cấp số case
• 16 tháng 2 năm 2024: SAP vá lỗ hổng đầu tiên và xoay vòng các secret liên quan
• 28 tháng 2 năm 2024: Wiz Research vượt qua bản vá bằng 2 lỗ hổng mới và báo lại cho SAP
• 15 tháng 5 năm 2024: SAP phát hành bản sửa cho toàn bộ lỗ hổng được báo cáo
• 17 tháng 7 năm 2024: Công bố công khai

[GN⁺]

Ý kiến trên Hacker News

• Dù hiểu đây là một sản phẩm AI, nhưng lỗ hổng ở đây nằm ở cấu hình k8s
  Nó không liên quan nhiều đến bản thân sản phẩm AI, hay AI training, machine learning, generative AI, mà gần hơn với bảo mật nền tảng đám mây kém

  • Thậm chí có thể còn tệ hơn. Một công ty lớn như SAP, nơi xử lý rất nhiều thông tin quan trọng, lại làm hỏng cả bảo mật đám mây cơ bản, nên nghe không phải là họ làm sai thứ gì mới, mà là mắc một lỗi quá phổ biến
  • Bài viết không nói đây là vấn đề của bản thân sản phẩm. Ngược lại, nó giải thích khá rõ rằng đây là vấn đề về cô lập mô hình huấn luyện AI
    “Việc kẻ tấn công có thể chạy mô hình AI độc hại và quy trình huấn luyện” mới là nguyên nhân gốc rễ, và về bản chất đó là thực thi mã
    Tôi hiểu đây là thứ được nghiên cứu/điều tra vì các sản phẩm AI đang lan rộng, nên cần phải cẩn thận với hạ tầng của chúng
  • Thương hiệu đang bán sản phẩm phải chịu trách nhiệm
    Việc áp dụng bảo mật, biết rằng cần bảo mật, kiểm thử, hay không phát hành cho đến khi an toàn đều là việc thương hiệu đó phải làm với tư cách bên bán

• Tôi muốn SAP phải nhìn lại thật nghiêm túc vì sao nghiên cứu của Wiz đã không bị chặn trước khi đạt tới quyền quản trị toàn bộ cụm
  Tôi muốn biết phía SAP có nhận được cảnh báo về hoạt động này hay không, và có điều tra đúng cách không. Tôi cũng tò mò liệu SAP có chịu quy định nào buộc phải có hệ thống cảnh báo đầy đủ với hoạt động mạng đáng ngờ hay không, và liệu nghiên cứu lần này có thể là bằng chứng cho thấy họ đã không đáp ứng được điều đó hay không

  • Chắc chắn là có quy tắc và quy định. Chỉ cần xem trang chứng nhận: https://www.sap.com/about/trust-center/certification-complia...
    Vấn đề là họ có thực sự tuân thủ hay chỉ để đó trong mấy cuốn binder trên kệ
  • Thông thường, nhà nghiên cứu bảo mật phải liên hệ với bên mục tiêu trước khi đi sâu hơn vào hệ thống để xin phép có được tiếp tục hay không
    Các chương trình bug bounty cũng thường yêu cầu những quy tắc như vậy trong phạm vi được phép. Vì nhà nghiên cứu thuộc một công ty bảo mật nên tôi đoán ở đây cũng vậy
    Các nhà nghiên cứu thường viết trong bài rằng họ đã xin thêm phép ở mốc nào, nhưng không phải lúc nào cũng thế
  • Nếu thực sự họ không phát hiện được, thì làm sao biết được dữ liệu khách hàng chưa bị xâm phạm?
  • SAP thiếu năng lực bảo mật đám mây. Các vấn đề bảo mật của dịch vụ đám mây SAP có cả một danh sách dài, mà đó còn chỉ là những gì đã được biết đến
  • Sẽ rất hay nếu có bài viết cho thấy người ta phát hiện kiểu việc này trong AI như thế nào

• Thật sốc khi vẫn có instance tiller đang chạy. Nó đã bị ngừng hỗ trợ từ năm 2020: https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Nếu biết có bao nhiêu phần mềm từ trước 2020, thậm chí trước 2010, vẫn đang chạy trong môi trường production thì bạn sẽ hoảng hốt
    Ở đây là doanh nghiệp lớn và còn vướng một đợt migration hơi phức tạp để rời khỏi tiller, nhưng ngay cả khi không có những tình tiết tăng nặng như thế, phần mềm cũ vẫn rất dễ bắt gặp
  • Theo kinh nghiệm của tôi, “ngừng hỗ trợ” thường bị hiểu thành “vẫn chưa bị gỡ bỏ nên cứ tiếp tục dùng”, điều này đôi khi khá làm nản lòng
  • Microsoft Dynamics có một lượng khổng lồ mã legacy cũ, không an toàn và không được vá

• Cái này thực sự rất tệ. Họ vận hành một cụm K8s duy nhất mà lại kỳ vọng có được đảm bảo đa thuê mạnh sao?
  Các đám mây lớn đều dùng ranh giới máy ảo giữa khách hàng và các cụm K8s tách biệt. Microsoft vài năm trước cũng từng bị tương tự ở một sản phẩm function, nơi họ đã kỳ vọng K8s sẽ là ranh giới bảo mật chính

  • Có thể tôi đã bỏ lỡ đoạn nói rằng họ kỳ vọng có đảm bảo mạnh, nhưng kỳ vọng đó thể hiện ở đâu?
    Ví dụ, trong bối cảnh chạy mã tùy ý như huấn luyện mô hình, tôi không rõ đa thuê K8s đóng vai trò gì
    Theo tôi thấy thì vấn đề chính là đã tin tưởng toàn bộ giao tiếp mạng nội bộ một khi vào phía sau Istio, tức proxy/firewall. Dù vậy cũng có thể là tôi chưa hiểu đủ về cụm k8s
  • Đa thuê mạnh trong cùng một cụm K8s logic là thứ rất khó đạt được trong thực tế
    Đây là mục tiêu luôn dịch chuyển, nên kế hoạch làm nó an toàn bằng admission controller cũng không mấy ổn
    Nếu muốn tính đến đa thuê mạnh với giả định có tenant đối kháng, có lẽ nên bắt đầu từ những thứ như VirtualClusters(https://github.com/kubernetes-sigs/cluster-api-provider-nest...). Mà đó còn chỉ là chuyện control plane, chưa đụng gì đến data plane
    Ngay cả khi có thêm lớp đó thì tôi cũng không biết nó an toàn đến đâu. Ngay trong thế giới máy ảo cũng từng có những lỗ hổng VM escape vô lý suốt nhiều năm
  • K8S được cấu hình đúng thì đúng nghĩa là được thiết kế cho đa thuê
    Mỗi khách hàng một cụm riêng thì chi phí phi lý và cũng không tốt cho môi trường. Có thể chấp nhận nếu là sản phẩm premium đặt bảo mật lên hàng đầu, nhưng cụm riêng cho từng khách hàng về cơ bản là đang đốt tiền

• Tôi cho rằng những công ty tự ý xâm nhập mạng chỉ để tìm lỗ hổng rồi làm nội dung blog thì nên bị truy tố
  Bài này nghe giống một bài viết công kích được bọc mỏng dưới danh nghĩa công bố lỗ hổng. Câu “cảm ơn vì đã hợp tác” cũng nghe hơi giống tống tiền

  • Có thể diễn đạt lại ý này thành: “Những công ty thu thập dữ liệu người dùng nhạy cảm một cách bất cẩn và lưu trữ không an toàn thì không nên bị điều tra kỹ lưỡng, và nên được phép tiếp tục để lộ dữ liệu người dùng vô tội cho tội phạm mạng độc hại”
    Nhìn từ góc đó thì chẳng phải sẽ thấy khác hẳn sao?
  • Cố hack một tập đoàn lớn khi không được mời là hành vi phạm pháp, và bình thường sẽ là chuyện bị truy tố nghiêm trọng
    Chỉ là thực tế pháp lý thường vận hành theo kiểu “nếu có hàng tỷ đô la thì luật không còn áp dụng nữa”

• Có ai từng dùng Wiz chưa?
  Đây có thể là tên lửa nhanh nhất trong số các công ty phần mềm doanh nghiệp. Chỉ sau 1,5 năm đã đạt 100 triệu USD ARR, và đến cuối năm thứ 3 thì chạm 350 triệu USD
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Tôi đang dùng và rất hài lòng. Ngay cả nếu bỏ qua khía cạnh bảo mật, đây vẫn là công cụ tốt nhất tôi từng dùng để làm quản lý tài sản đa đám mây cho ra hồn
    Với tính năng đồ thị, nếu muốn thì bạn có thể truy vấn gần như bất cứ thứ gì trên toàn bộ các tài khoản
  • Google cũng đang trong quá trình muốn mua lại với giá 23 tỷ USD

• May là tôi đã thuyết phục được mọi người trong công ty cho chạy kiểm thử xâm nhập hằng năm của sản phẩm ngay trên môi trường production, và đưa toàn bộ hạ tầng production vào phạm vi kiểm thử
  Trọng tâm có thể là một sản phẩm hay hệ thống cụ thể, nhưng mọi thứ đều nằm trong phạm vi. Bài kiểm thử đầu tiên đang diễn ra và chưa ai hét lên, nên hy vọng mọi chuyện ổn

  • Nếu nói là hằng năm thì có thể hiểu là không làm kiểm thử xâm nhập nội bộ định kỳ đúng không?
    Tôi cũng muốn biết có thể giới thiệu công ty pentest nào làm bài bản, vượt xa mức chỉ quét qua loa bằng Metasploit rồi thôi hay không

• Nếu tôi đọc đúng, nghĩa là dữ liệu tài khoản của khách hàng bị lộ cho chính khách hàng đó xem à? Có vẻ chỉ một phần log là ngoại lệ

  • Không chỉ một phần log, mà cả dữ liệu huấn luyện và mã nguồn của khách hàng khác, cùng cả kho lưu trữ image Docker nội bộ của SAP cũng bị lộ. Lại còn với quyền đọc-ghi nữa!

• Nếu là nhà nghiên cứu bảo mật thì chắc cũng phải biết pixel hóa không phải là lựa chọn hay để che văn bản
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Tất cả các lỗi được báo cáo đều đã được vá, và những secret có thể đã bị lộ chắc cũng đã được thay rồi
    Làm mờ hay pixel hóa có vẻ về cơ bản là không cần thiết, bất kể chúng có hiệu quả hay không. Dữ liệu bị che có vẻ là hostname cục bộ và một phần hash của image
  • Theo tôi thấy thì đó không phải pixel hóa mà là làm mờ
    Sửa: nhìn lại thì có vẻ chỗ thì làm mờ, chỗ khác thì pixel hóa