Sự cố bảo mật dịp Lễ Tạ ơn năm 2023

Sự cố bảo mật dịp Lễ Tạ ơn năm 2023

• Vào Lễ Tạ ơn ngày 23 tháng 11 năm 2023, Cloudflare đã phát hiện tác nhân đe dọa trên máy chủ Atlassian tự lưu trữ của mình.
• Đội ngũ bảo mật ngay lập tức bắt đầu điều tra và chặn quyền truy cập của tác nhân đe dọa.
• Đến ngày 26 tháng 11, Cloudflare đã mời đội pháp chứng của CrowdStrike vào để thực hiện phân tích độc lập.
• CrowdStrike đã hoàn tất điều tra và Cloudflare chia sẻ chi tiết của sự cố bảo mật thông qua bài viết blog này.
• Cloudflare nhấn mạnh rằng dữ liệu hay hệ thống của khách hàng không bị ảnh hưởng bởi sự cố này.
• Nhờ áp dụng kiểm soát truy cập, quy tắc tường lửa và bắt buộc dùng khóa bảo mật phần cứng bằng các công cụ Zero Trust, khả năng di chuyển ngang của tác nhân đe dọa đã bị hạn chế.

Công tác khôi phục và củng cố “Code Red”

• Sau khi tác nhân đe dọa bị loại khỏi môi trường, đội ngũ bảo mật đã huy động tất cả những người cần thiết trên toàn công ty để hoàn tất điều tra xâm nhập và chặn truy cập.
• Từ ngày 27 tháng 11, nhân sự kỹ thuật được huy động để tập trung vào một dự án mang tên "Code Red".
• Mục tiêu của dự án này là siết chặt và xác minh mọi biện pháp kiểm soát trong môi trường để chuẩn bị cho các cuộc xâm nhập trong tương lai và ngăn tác nhân đe dọa quay lại truy cập môi trường.
• CrowdStrike đã thực hiện một đánh giá độc lập về phạm vi và mức độ hoạt động của tác nhân đe dọa.

Dòng thời gian cuộc tấn công

• Cuộc tấn công bắt đầu từ vụ vi phạm bảo mật của Okta vào tháng 10, và từ giữa tháng 11 tác nhân đe dọa đã nhắm vào các hệ thống của Cloudflare bằng thông tin xác thực có được từ sự cố Okta.
• Vào ngày 18 tháng 10, vụ vi phạm của Okta đã khiến tác nhân đe dọa có thể truy cập thông tin xác thực.
• Từ ngày 14 tháng 11, tác nhân đe dọa bắt đầu dò xét hệ thống và thử truy cập.
• Ngày 15 tháng 11, chúng đã truy cập thành công vào Atlassian Jira và Confluence.
• Ngày 16 tháng 11, chúng tạo tài khoản người dùng Atlassian.
• Từ ngày 17 đến 20 tháng 11, chúng không truy cập vào các hệ thống của Cloudflare.
• Ngày 22 tháng 11, chúng cài đặt Sliver Adversary Emulation Framework để duy trì quyền truy cập.
• Ngày 23 tháng 11, đội ngũ bảo mật phát hiện sự hiện diện của tác nhân đe dọa và bắt đầu chặn truy cập.

Kết luận

• Sự cố này được cho là do một tác nhân tấn công được nhà nước hậu thuẫn, và Cloudflare đã nỗ lực rất nhiều để hạn chế tác động của sự cố cũng như chuẩn bị cho các cuộc tấn công trong tương lai.
• Đội ngũ kỹ sư của Cloudflare đã bảo vệ hệ thống, tìm hiểu cách tác nhân đe dọa truy cập, xử lý các ưu tiên trước mắt và xây dựng kế hoạch cải thiện bảo mật tổng thể.
• CrowdStrike đã thực hiện đánh giá độc lập, và sau khi báo cáo cuối cùng hoàn tất, Cloudflare đã công bố bài viết blog này với sự tự tin vào phân tích nội bộ cũng như các biện pháp đã thực hiện đối với vụ xâm nhập.

Ý kiến của GN⁺:

1. Sự cố này nhấn mạnh tầm quan trọng của kiến trúc Zero Trust của Cloudflare. Kiến trúc này hoạt động theo cách hạn chế sự lan rộng của mối đe dọa ra toàn tổ chức thông qua việc cô lập giữa các hệ thống.
2. Phản ứng nhanh chóng của Cloudflare và nỗ lực tăng cường bảo mật thông qua dự án "Code Red" mang lại góc nhìn về cách doanh nghiệp ứng phó với các mối đe dọa an ninh mạng.
3. Bài viết này là một ví dụ hữu ích giúp hiểu cách tổ chức nên phản ứng và cần thực hiện những biện pháp nào khi xảy ra sự cố an ninh mạng.

[GN⁺]

Ý kiến trên Hacker News

• Lý do những hành động như bài đăng blog của Cloudflare tạo được niềm tin

  • Cloudflare không hoàn hảo, nhưng vẫn đáng tin nhờ tư duy kỹ thuật và cách ứng phó với các vấn đề nghiêm trọng.
  • Bày tỏ sự cảm kích đối với bài đăng blog.

• Vấn đề của rò rỉ dữ liệu

  • Một khi dữ liệu đã bị rò rỉ thì vĩnh viễn không thể kiểm soát được.
  • Việc tăng cường sau sự cố và trao đổi là quan trọng, nhưng không thể ngăn được điều đã xảy ra.

• Vấn đề bảo mật của hệ thống Okta

  • Lo ngại về việc hệ thống Okta bị ảnh hưởng lần thứ hai.

• Token dịch vụ và tài khoản không được xoay vòng

  • Chúng không được xoay vòng vì đã bị nhầm tưởng là không còn được sử dụng.
  • Đặt câu hỏi vì sao chúng không bị thu hồi hoàn toàn.

• Quyền truy cập hạn chế của kẻ tấn công và các biện pháp ứng phó

  • Dù tin rằng quyền truy cập của kẻ tấn công là có giới hạn, họ vẫn thực hiện các biện pháp trên diện rộng như xoay vòng mọi thông tin xác thực sản xuất, phân tích pháp y hệ thống, re-image và khởi động lại.
  • Nỗ lực truy cập vào hệ thống mới tại trung tâm dữ liệu Brazil đã thất bại, và thiết bị đã được trả lại cho nhà sản xuất để kiểm tra và thay thế.

• Phân tích mục tiêu của kẻ tấn công

  • Qua việc phân tích các trang wiki, cơ sở dữ liệu lỗi và kho mã nguồn, có vẻ như chúng đang tìm kiếm thông tin về kiến trúc mạng toàn cầu, bảo mật và quản trị của Cloudflare.

• Sự ngạc nhiên về việc Cloudflare dùng BitBucket

  • Bày tỏ sự ngạc nhiên trước việc Cloudflare sử dụng BitBucket.

• Cách xử lý thông tin xác thực không còn dùng đến

  • Với những thông tin xác thực được cho là không còn sử dụng, lẽ ra xóa bỏ sẽ phù hợp hơn là chỉ xoay vòng.

• Đề xuất xoay vòng thông tin xác thực và dùng honeypot sau sự cố Okta

  • Đề xuất sau khi xoay vòng thông tin xác thực bị lộ, nên dùng honeypot để quan sát hành vi của kẻ tấn công.

• Hoài nghi về Zero Trust (ZT)

  • Chỉ ra rằng việc có thể truy cập ứng dụng chỉ bằng một bearer token duy nhất không phù hợp với định nghĩa của Zero Trust.

Kiến thức nền: Cloudflare là công ty cung cấp dịch vụ bảo mật Internet và dịch vụ máy chủ tên miền phân tán, còn Okta là công ty cung cấp dịch vụ quản lý danh tính và truy cập. Zero Trust là một mô hình bảo mật mạng, theo đó mặc định không tin tưởng bất kỳ người dùng hay thiết bị nào mà luôn yêu cầu xác minh.