Sự cố bảo mật Cloudflare dịp Lễ Tạ ơn 2023
(blog.cloudflare.com)- Cloudflare công bố rằng vào ngày 23 tháng 11 năm 2023, công ty đã phát hiện tác nhân đe dọa trong máy chủ Atlassian tự lưu trữ của mình, nhưng dữ liệu khách hàng, hệ thống khách hàng, hệ thống mạng toàn cầu và cấu hình không bị ảnh hưởng
- Con đường xâm nhập là 1 access token và 3 thông tin xác thực tài khoản dịch vụ không được xoay vòng sau sự cố xâm nhập Okta vào tháng 10 năm 2023, và quyền truy cập tập trung vào môi trường Atlassian như Jira, Confluence, Bitbucket
- Tác nhân đe dọa đã thực hiện trinh sát và truy cập tài liệu nội bộ trong giai đoạn 14–17 tháng 11, sau đó vào ngày 22 tháng 11 cài Sliver thông qua ScriptRunner for Jira để duy trì quyền truy cập lâu dài
- Cloudflare đã phản ứng ở mức “Code Red” bằng cách xoay vòng hơn 5.000 thông tin xác thực production, sàng lọc pháp chứng 4.893 hệ thống, đồng thời reimage và khởi động lại mọi máy trong mạng toàn cầu cùng toàn bộ sản phẩm Atlassian
- Cuộc điều tra độc lập của CrowdStrike cũng không phát hiện hoạt động nào bị bỏ sót, và bằng chứng cuối cùng về hoạt động của tác nhân đe dọa được xác nhận vào 10:44 UTC ngày 24 tháng 11 năm 2023
Tổng quan sự cố và phạm vi ảnh hưởng
- Cloudflare đã phát hiện tác nhân đe dọa trong máy chủ Atlassian tự lưu trữ của mình vào ngày 23 tháng 11 năm 2023
- Đội ngũ bảo mật lập tức bắt đầu điều tra và chặn quyền truy cập
- Ngày 26 tháng 11, công ty mời đội pháp chứng của CrowdStrike để thực hiện phân tích độc lập
- Dữ liệu khách hàng và hệ thống khách hàng không bị ảnh hưởng bởi sự cố này
- Các dịch vụ không liên quan
- Không có thay đổi nào đối với hệ thống mạng toàn cầu hay cấu hình
- Kiểm soát truy cập, quy tắc tường lửa và khóa bảo mật phần cứng do công cụ Zero Trust nội bộ áp đặt đã hạn chế di chuyển ngang
- Phạm vi truy cập của tác nhân đe dọa bị giới hạn trong wiki nội bộ Atlassian Confluence, cơ sở dữ liệu lỗi Jira, hệ thống quản lý mã nguồn Bitbucket và các máy chủ chạy Atlassian
Thông tin xác thực được dùng cho xâm nhập
- Vụ xâm nhập bắt đầu từ 1 service token và 3 tài khoản dịch vụ đã bị lộ sau sự cố xâm nhập Okta vào tháng 10 năm 2023 nhưng không được xoay vòng
- Service token Moveworks: dùng để truy cập từ xa vào hệ thống Atlassian
- Tài khoản dịch vụ Smartsheet: có quyền quản trị trên instance Atlassian Jira
- Tài khoản dịch vụ Bitbucket: dùng để truy cập hệ thống quản lý mã nguồn
- Tài khoản môi trường AWS: không có quyền truy cập mạng toàn cầu, dữ liệu khách hàng hay dữ liệu nhạy cảm
- Các token và tài khoản này bị đánh giá nhầm là không còn sử dụng nên bị loại khỏi diện xoay vòng
- Cloudflare nêu rõ vấn đề này không phải lỗi của Atlassian, AWS, Moveworks hay Smartsheet mà là hệ quả từ việc Cloudflare không xoay vòng thông tin xác thực
Dòng thời gian tấn công
- Từ 09:22:49 ngày 14 tháng 11, tác nhân đe dọa bắt đầu khám phá hệ thống và trinh sát
- Nỗ lực đăng nhập vào instance Okta bị từ chối
- Quyền truy cập vào Cloudflare Dashboard cũng bị chặn
- Họ đã truy cập môi trường AWS vận hành Cloudflare Apps marketplace, nhưng môi trường này được tách biệt khỏi mạng toàn cầu và dữ liệu khách hàng
- Vào 16:28:38 ngày 15 tháng 11, chúng đã truy cập thành công Atlassian Jira và Confluence
- Chúng đi qua gateway bằng service token Moveworks và truy cập bộ sản phẩm Atlassian bằng tài khoản dịch vụ Smartsheet
- Chúng tìm kiếm trong wiki các từ khóa remote access, secret, client-secret, openconnect, cloudflared, token
- Chúng truy cập 36 trong số 2.059.357 ticket Jira và 202 trong số 194.100 trang wiki
- Các ticket Jira bị truy cập gồm các mục liên quan đến quản lý lỗ hổng, xoay vòng secret, vượt MFA, truy cập mạng và phản ứng với sự cố Okta
- Vào 14:36:37 ngày 16 tháng 11, bằng thông tin xác thực Smartsheet, chúng tạo một tài khoản Atlassian trông như người dùng Cloudflare thông thường và thêm vào nhiều nhóm
- Đây là biện pháp nhằm tiếp tục truy cập môi trường Atlassian ngay cả khi tài khoản dịch vụ Smartsheet bị gỡ bỏ
- Từ 14:33:52 ngày 17 tháng 11 đến 09:26:53 ngày 20 tháng 11, quyền truy cập vào hệ thống Cloudflare bị gián đoạn ngoại trừ một số thử nghiệm truy cập ngắn
- Vào 14:18:22 ngày 22 tháng 11, chúng dùng quyền quản trị Jira của tài khoản dịch vụ Smartsheet để cài Sliver Adversary Emulation Framework thông qua plugin ScriptRunner for Jira
- Sliver là công cụ và framework được red team và kẻ tấn công dùng cho C2, kết nối, và duy trì quyền truy cập bền bỉ, bí mật
- Qua đó, chúng duy trì quyền truy cập vào máy chủ Atlassian và cố gắng di chuyển ngang
- Nỗ lực truy cập vào máy chủ console phi production tại trung tâm dữ liệu ở São Paulo, Brazil chưa được đưa vào production đã thất bại
Truy cập mã nguồn và tài liệu
- Trong một ngày sau 22 tháng 11, tác nhân đe dọa đã xem 120 kho mã trong tổng số 11.904 kho lưu trữ
- Trong số đó, 76 kho đã được tải xuống máy chủ Atlassian bằng tính năng git archive của Atlassian Bitbucket
- Cloudflare không thể xác nhận có bị exfiltrate ra ngoài hay không, nhưng đã ứng phó như thể dữ liệu đã bị lấy đi
- 76 kho này chủ yếu liên quan đến các lĩnh vực sau
- Cách hoạt động của sao lưu
- Cấu hình và quản lý mạng toàn cầu
- Hệ thống định danh của Cloudflare
- Truy cập từ xa
- Việc sử dụng Terraform và Kubernetes
- Một số kho có chứa secret đã mã hóa, và Cloudflare đã xoay vòng ngay lập tức dù chúng được mã hóa mạnh
- Cloudflare tập trung điều tra không phải bản thân mã nguồn mà là secret nhúng sẵn trong mã, các lỗ hổng và những con đường có thể bị lợi dụng cho các cuộc tấn công tiếp theo
- Cloudflare giải thích rằng họ đã công khai nhiều mã nguồn dưới dạng mã nguồn mở và cũng công khai thảo luận trên blog về các thuật toán và kỹ thuật mình sử dụng
Phát hiện và ngăn chặn
- Vào 16:00 ngày 23 tháng 11, đội bảo mật nhận được cảnh báo về sự hiện diện của tác nhân đe dọa
- 15:58: tác nhân đe dọa thêm tài khoản dịch vụ Smartsheet vào nhóm quản trị
- 16:00: cảnh báo tự động về thay đổi này được gửi đến đội bảo mật
- 16:12: Cloudflare SOC bắt đầu điều tra
- 16:35: vô hiệu hóa tài khoản dịch vụ Smartsheet
- 17:23: phát hiện và vô hiệu hóa tài khoản người dùng Atlassian do tác nhân đe dọa tạo ra
- 17:43: tuyên bố incident nội bộ tại Cloudflare
- 21:31: áp dụng quy tắc tường lửa để chặn các địa chỉ IP đã biết của tác nhân đe dọa
- Ngày 24 tháng 11 xác nhận hoạt động cuối cùng và việc gỡ bỏ Sliver
- 10:44: hoạt động cuối cùng đã biết của tác nhân đe dọa
- 11:59: gỡ bỏ Sliver
- Tác nhân đe dọa đã cố truy cập nhiều hệ thống như chỉ số nội bộ, cấu hình mạng, hệ thống build, hệ thống cảnh báo và hệ thống quản lý phát hành, nhưng không thành công
- Không phát hiện bằng chứng truy cập vào mạng toàn cầu, trung tâm dữ liệu, khóa SSL, cơ sở dữ liệu khách hàng hoặc thông tin cấu hình, Cloudflare Workers, mô hình AI, hạ tầng mạng, hay các kho dữ liệu như Workers KV, R2, Quicksilver
Ứng phó “Code Red” và công việc tăng cường
- Sau khi loại bỏ tác nhân đe dọa khỏi môi trường vào ngày 24 tháng 11, Cloudflare đã huy động nhân sự trên toàn công ty để điều tra vụ xâm nhập và xác định phạm vi truy cập
- Từ ngày 27 tháng 11, nhiều nhân sự kỹ thuật cả trong và ngoài đội bảo mật đã tập trung vào dự án Code Red
- Tăng cường, xác minh và sửa đổi các biện pháp kiểm soát trong môi trường để chuẩn bị cho các vụ xâm nhập trong tương lai
- Xác minh rằng tác nhân đe dọa không còn có thể tiếp tục truy cập
- Điều tra mọi hệ thống, tài khoản và log để xác định khả năng duy trì truy cập cũng như các mục tiêu đã bị truy cập hoặc bị nhắm tới
- Các biện pháp chính gồm
- Xoay vòng hơn 5.000 thông tin xác thực production
- Tách biệt vật lý các hệ thống test và staging
- Sàng lọc pháp chứng 4.893 hệ thống
- Reimage và khởi động lại mọi máy trong mạng toàn cầu
- Reimage và khởi động lại toàn bộ sản phẩm Atlassian như Jira, Confluence, Bitbucket
- Thiết bị tại trung tâm dữ liệu São Paulo đã được trả lại cho nhà sản xuất
- Đội pháp chứng của nhà sản xuất điều tra khả năng đã bị truy cập hoặc thiết lập cơ chế tồn tại
- Không phát hiện gì, nhưng Cloudflare vẫn thay thế phần cứng
- Ngoài ra, công ty còn điều tra các gói phần mềm chưa được cập nhật, các tài khoản người dùng có thể đã được tạo, các tài khoản nhân viên còn hoạt động nhưng không sử dụng, các secret có thể còn lại trong ticket Jira hoặc mã nguồn, và các tệp HAR được tải lên wiki
- Các tệp HAR đã bị xóa để phòng trường hợp chúng chứa token
- Công việc Code Red khẩn cấp kết thúc vào ngày 5 tháng 1 năm 2024, nhưng các cải tiến về quản lý thông tin xác thực, tăng cường phần mềm, quản lý lỗ hổng và cải thiện cảnh báo bổ sung vẫn tiếp tục
Điều tra của CrowdStrike và IOC
- CrowdStrike đã đánh giá độc lập phạm vi hoạt động của tác nhân đe dọa và bằng chứng về khả năng duy trì truy cập
- Không phát hiện hoạt động nào mà cuộc điều tra của Cloudflare đã bỏ sót
- Kết luận rằng bằng chứng cuối cùng về hoạt động của tác nhân đe dọa là vào 10:44 UTC ngày 24 tháng 11 năm 2023
- Dựa trên hợp tác với các đồng nghiệp trong ngành và cơ quan chính phủ, Cloudflare cho rằng cuộc tấn công này do tác nhân được nhà nước hậu thuẫn thực hiện nhằm giành quyền truy cập dai dẳng và trên diện rộng vào mạng toàn cầu của Cloudflare
- Cloudflare công bố các chỉ dấu xâm nhập để những tổ chức khác có thể đã bị ảnh hưởng bởi sự cố Okta kiểm tra log
193.142.58[.]126: hạ tầng chính của tác nhân đe dọa, thuộc sở hữu của M247 Europe SRL198.244.174[.]214: máy chủ Sliver C2, thuộc sở hữu của OVH SASidowall[.]com: hạ tầng phân phối payload Sliverjvm-agent: tên tệp payload Sliver, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 bình luận
Ý kiến trên Hacker News
Chính nhờ kiểu phân tích công khai và phản ứng như thế này của Cloudflare mà tôi thấy có thể giao dữ liệu và doanh nghiệp của mình cho họ
Họ không hoàn hảo và cũng có những việc tôi không đồng ý, nhưng tư duy kỹ thuật được chia sẻ trong toàn công ty và thái độ coi trọng nghiêm túc những chuyện như thế này khiến tôi cảm thấy họ đáng tin
Cách làm là nhấn mạnh rằng họ có tính liêm chính cao hơn đối thủ, rồi chia sẻ một vài cuộc điều tra vận hành sau sự cố bảo mật gần đây
Nhưng Cloudflare không cung cấp phân tích rủi ro SOC với tư cách là bên xử lý thẻ thanh toán PCI/DSS, cũng không giải thích vì sao họ bỏ sót các tài khoản bị nâng quyền, hay ban đầu các tài khoản đó đã bị xâm phạm như thế nào. Họ chỉ mô tả remediation hơn là trách nhiệm
Họ có nhắc đến kiểm toán bên thứ ba, nhưng đó không phải vì nghĩ cho người dùng, mà vì PCI/DSS yêu cầu các tổ chức bị xâm phạm thông tin thẻ thanh toán phải được kiểm toán tại chỗ hằng năm. Nếu không, các hãng thẻ lớn đã ngừng cho họ xử lý thanh toán rồi
Khó mà tin lời nói rằng không mất gì cả; hầu hết Jira/Confluence tôi từng thấy đều chứa đầy thông tin bí mật
Nhìn vào đoạn “sau khi phân tích các trang wiki, issue trong cơ sở dữ liệu lỗi và kho mã nguồn đã bị truy cập, có vẻ họ đang tìm kiếm thông tin về kiến trúc, bảo mật và quản lý của mạng lưới toàn cầu”, cách dễ nhất đối với một tác nhân nhà nước là đưa một công dân trung thành vào làm nhân viên của công ty mục tiêu rồi để người đó gửi thông tin đó ra ngoài
Một câu chuyện thú vị, dù chưa rõ thực hư: hơn 10 năm trước, trong một buổi gặp gỡ xã giao của SRE tại Google, được kể là có vài người đã thừa nhận họ đang nhận lương từ cơ quan tình báo nước mình
Nếu không thì tôi tò mò không biết trong buổi gặp đó đã có thứ thuốc mạnh đến mức nào mà lại xảy ra một thất bại an ninh tác chiến kinh khủng như vậy
Người Úc thì có “cơ hội” tham gia kiểu hoạt động gián điệp đó như một điều kiện cơ bản của quyền công dân https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
Nếu có điểm tốt nào thì nó có thể giúp buộc áp dụng các thực hành tốt trong việc phát triển quy trình và hệ thống zero trust
Nhìn vào phần “chúng tôi đã lần thứ hai trở thành nạn nhân của vụ xâm phạm hệ thống Okta”, tôi tự hỏi liệu Cloudflare có đang xem xét lại việc dùng Okta hay không
Okta cũng đáng bị chỉ trích, nhưng vụ này có cảm giác Cloudflare đang đẩy trách nhiệm xuống dưới để che lỗi của mình
Tôi vẫn dùng chiếc MacBook cũ được nhận từ “thuở ban đầu”, nên không có phần mềm quản lý nào cả. Khi đó chưa có IT, và tôi chỉ nhận một chiếc laptop mới nguyên chưa bị động vào
Công ty đã đề nghị nâng cấp cho tôi lên M1/M2 Pro, nhưng tôi từ chối vì không muốn dùng hệ thống đăng nhập Okta nếu trên máy tính làm việc có dù chỉ một mật khẩu hay khóa cá nhân nào
Vì vậy tôi không thể nâng cấp cho đến khi công việc bị ảnh hưởng nghiêm trọng. Có lẽ tôi có thể dùng những sự cố như thế này làm bằng chứng để biện minh quan điểm của mình với bộ phận IT
Câu “một service token và ba tài khoản không được xoay vòng vì chúng tôi tin nhầm rằng chúng không được sử dụng” nghe lạ. Nếu không dùng thì vì sao không hủy hẳn đi?
Có lẽ có gì đó bị thiếu hoặc mất đi trong quá trình truyền đạt, nhưng nếu đọc đúng nguyên văn thì tôi không hiểu lắm
Ví dụ, ở đâu đó trong cơ sở dữ liệu, service account đó có thể đã được đánh dấu ở trạng thái không hoạt động như “đã hủy” hoặc “đã dọn”, nhưng nhãn đó là sai. Vì vậy họ đã xoay vòng mật khẩu của tất cả tài khoản đang hoạt động nhưng bỏ qua các tài khoản không hoạt động
Chỉ xét trong bối cảnh hạ tầng khóa công khai và thu hồi chứng chỉ mà tôi biết rõ, việc để chứng chỉ hết hạn, đánh dấu là “không còn sử dụng”, và thu hồi hoàn toàn là những việc khá khác nhau. Cơ quan chứng thực không cần làm gì trong trường hợp đầu; trường hợp thứ hai thì có thể không làm gì hoặc thu hồi; còn trường hợp thứ ba thì phải chủ động duy trì và phân phối danh sách thu hồi. Nếu ai đó nói “tôi lỡ ghi đè private key rồi, hãy cấp cho tôi chứng chỉ cho khóa mới”, thường thì chứng chỉ cũ sẽ không bị đưa vào danh sách thu hồi
Việc họ viết rõ “đây hoàn toàn không phải lỗi của AWS, Moveworks hay Smartsheet, mà chỉ là các thông tin xác thực mà chúng tôi đã không xoay vòng” là một điểm đáng ghi nhận
Cloudflare tin rằng quyền truy cập của kẻ tấn công là có giới hạn và sau đó đã xác nhận điều đó, nhưng vẫn xoay vòng hơn 5.000 thông tin xác thực production, tách biệt vật lý các hệ thống test/staging, kiểm tra pháp chứng 4.893 hệ thống, đồng thời reimage và reboot mọi máy trong mạng lưới toàn cầu
Dù nỗ lực truy cập vào console server của trung tâm dữ liệu São Paulo, vốn chưa được đưa vào production, cũng thất bại, họ vẫn gửi thiết bị của trung tâm dữ liệu Brazil trả về nhà sản xuất để làm pháp chứng; dù không phát hiện gì, họ vẫn thay phần cứng
Đáng lẽ không cần làm đến mức đó, và cũng rất dễ chọn không làm, nên việc họ thực sự làm vậy đáng được khen ngợi
Xâm nhập vào giai đoạn đầu khi xây dựng một trung tâm dữ liệu mới gần như là exploit tối thượng. Hãy tưởng tượng việc lọt vào giữa một Meet-Me room mới (https://en.wikipedia.org/wiki/Meet-me_room) và có được quyền truy cập bền vững vào các switch lõi
Các trung tâm dữ liệu của Cloudflare thường là hub cho lượng traffic dữ liệu khổng lồ. Việc kẻ tấn công hiểu giá trị của một trung tâm dữ liệu “tiền production” có lẽ cũng đồng nghĩa Cloudflare nhận ra rằng nếu có được chỗ đứng ở đó trước khi hệ thống bảo mật chính quy được dựng lên thì 100% là game over. Nếu ai đó thành công bám trụ bên trong một trung tâm dữ liệu đang được xây dựng/khởi động, đó có thể là sự cố kết liễu cả công ty
Cũng cần nhớ rằng ở giai đoạn đầu xây dựng trung tâm dữ liệu, mọi switch và thiết bị thường dùng giá trị mặc định hoặc mật khẩu root trống (admin/admin), firmware thì cũ và nhiều lỗ hổng. Nếu cuộc tấn công kiểu này xảy ra trước khi tự động hóa kịp patch toàn bộ firmware, thì đây là sự cố ở mức “trả lại toàn bộ thiết bị và yêu cầu nhà sản xuất gửi thiết bị mới”
Nếu chỉ giả định kẻ tấn công truy cập đúng phạm vi có thể chứng minh được, tức là bạn đang để lại lỗ hổng cho kẻ tấn công sống sót. Muốn nói rằng không cần làm việc này thì phải cần sự phê duyệt theo quorum của nhiều người
Tất nhiên đó là câu chuyện trong một thế giới lý tưởng. Tôi vẫn thấy may mắn khi đội của mình được cấp thời gian để triển khai những tính năng không đem lại lợi ích tiền bạc hay người dùng trực tiếp
Để sẵn sàng thực hiện kiểu xoay vòng thông tin xác thực này cần kỷ luật và sự chuẩn bị, và nói thật là phần lớn đội ngũ không đầu tư vào đó. Kể cả các đội thông minh và nhiều tài nguyên cũng vậy
Nếu đội bảo mật Cloudflare có thể quyết định xoay vòng mọi secret và reimage mọi máy, rồi việc đó thực sự diễn ra trong một khoảng thời gian hợp lý, thì khá ấn tượng
† https://twitter.com/badthingsdaily?lang=en
Điều đáng ngạc nhiên nhất ở đây là Cloudflare dùng Bitbucket
Một khi dữ liệu đã rò rỉ ra ngoài, trong trường hợp này là mã nguồn, thì về cơ bản nó sẽ vĩnh viễn ở ngoài đó và bạn hoàn toàn không kiểm soát được ai lấy nó
Sau sự cố, bạn có thể gia cố bao nhiêu tùy thích và nói về điều đó nhiều đến đâu cũng được, nhưng chuyện bạn muốn ngăn đã xảy ra rồi. Trứng đã đánh tan thì không thể quay lại như cũ
Trong code cũ cũng có thể tìm thấy các easter egg khác. Gần như công ty nào cũng có backdoor không được ghi tài liệu
Rò rỉ dữ liệu khách hàng thì tệ hơn, nhưng chuyện này cũng thật sự không tốt
Dữ liệu khách hàng của năm sau cũng không giống dữ liệu khách hàng của năm nay
Trong Confluence của Atlassian, chỉ riêng công cụ tìm kiếm Apache Lucene tích hợp cũng có thể làm lộ thông tin nhạy cảm, và kiểu truy cập này có thể rất khó theo dõi/nhận diện
Nếu thông tin nhạy cảm đã hiển thị ngay trên trang kết quả tìm kiếm, kẻ tấn công thậm chí không cần mở trang Confluence
Đoạn “một service token và ba tài khoản đã không được xoay vòng vì bị tin nhầm là không được sử dụng” nghe lạ. Thông tin xác thực không dùng nhiều khả năng nên bị xóa, chứ không phải xoay vòng
Có phải kiểu “Mấy tài khoản này là gì?” “À, không dùng đâu. Trong log cũng không thấy” “Dù vậy vẫn phải xoay vòng chứ” “Không, cứ để mấy tài khoản tùy ý có thông tin xác thực cũ có thể đã bị xâm phạm đó… lý do thì đại khái là có” không?
Sau sự cố Okta, nếu đã xoay vòng các thông tin xác thực bị rò rỉ, tôi nghĩ nên đặt honeypot lên chúng và chờ xem kẻ tấn công làm gì
Honeypot cũng có tác dụng khiến kẻ tấn công không dám tiếp tục vì sợ bị phát hiện