1Password phát hiện “hoạt động đáng ngờ” trong tài khoản Okta nội bộ
(arstechnica.com)- 1Password đã phát hiện hoạt động đáng ngờ vào ngày 29/9 trong instance Okta nội bộ dùng để quản lý quyền truy cập ứng dụng cho nhân viên, và không phát hiện việc xâm phạm dữ liệu người dùng hay các hệ thống nhạy cảm
- Lần truy cập này có liên quan đến vụ xâm phạm hệ thống quản lý hỗ trợ khách hàng của Okta, và kẻ tấn công có thể đã lấy được cookie xác thực cùng token phiên từ các tệp HAR do khách hàng tải lên
- Một báo cáo Notion nội bộ của 1Password tóm tắt rằng kẻ tấn công đã lấy được tệp HAR do nhân viên IT tạo ra khi làm việc với bộ phận hỗ trợ Okta, trong đó có lưu lượng Okta và cookie phiên
- Kẻ tấn công đã yêu cầu báo cáo người dùng quản trị trong tenant Okta của 1Password và cập nhật, kích hoạt IDP dùng để xác thực môi trường production của Google, nhưng lần tái sử dụng sau đó đã thất bại vì IDP đã bị gỡ bỏ
- Vụ xâm phạm Okta trở thành một trường hợp tấn công nối tiếp khi việc đột nhập nhà cung cấp dẫn tới tấn công vào khách hàng, và 1Password là khách hàng Okta thứ hai được biết đến trở thành mục tiêu
1Password phát hiện truy cập vào Okta nội bộ
- 1Password là trình quản lý mật khẩu được hàng triệu người dùng và hơn 100.000 doanh nghiệp sử dụng
- Công ty xác nhận hoạt động đáng ngờ vào ngày 29/9 trong instance Okta mà họ dùng để quản lý ứng dụng cho nhân viên
- CTO Pedro Canahuati cho biết công ty đã chấm dứt hoạt động này ngay lập tức và tiến hành điều tra, đồng thời không phát hiện việc xâm phạm dữ liệu người dùng hay các hệ thống nhạy cảm dành cho nhân viên hoặc người dùng
- Sau đó, 1Password đã phối hợp với Okta để điều tra con đường mà một kẻ tấn công chưa xác định đã dùng để truy cập vào tài khoản
Vụ xâm phạm hệ thống hỗ trợ của Okta và rủi ro từ tệp HAR
- Sự cố của 1Password được xác nhận là bắt nguồn từ vụ xâm phạm hệ thống quản lý hỗ trợ khách hàng mà Okta đã công bố
- Okta cho biết tác nhân đe dọa đã truy cập trái phép vào hệ thống quản lý case hỗ trợ khách hàng và xem được các tệp do một số khách hàng Okta tải lên
- Trong số các tệp bị lộ có tệp HAR, vốn được nhân viên hỗ trợ Okta dùng để tái hiện hoạt động trình duyệt của khách hàng trong quá trình xử lý sự cố
- Tệp HAR có thể lưu trữ thông tin nhạy cảm như cookie xác thực và token phiên, nên có thể bị kẻ tấn công lợi dụng để giả mạo người dùng hợp lệ
Mục tiêu được biết đến thứ hai sau BeyondTrust
- Công ty bảo mật BeyondTrust đã phát hiện vụ xâm nhập sau khi kẻ tấn công cố truy cập tài khoản Okta của họ bằng cookie xác thực hợp lệ
- Tại BeyondTrust, kẻ tấn công có thể thực hiện “một vài hành động hạn chế”, nhưng các cơ chế kiểm soát chính sách truy cập đã chặn hoạt động này và ngăn truy cập tài khoản
- 1Password trở thành khách hàng Okta thứ hai được biết đến là mục tiêu của một cuộc tấn công nối tiếp sau vụ xâm phạm Okta
Diễn biến sự cố trong báo cáo Notion nội bộ
- Một báo cáo đề ngày 18/10 và được chia sẻ trong workspace Notion nội bộ của 1Password cho biết kẻ tấn công đã lấy được tệp HAR do một nhân viên IT của công ty tạo ra
- Nhân viên này gần đây đã tạo tệp khi làm việc với bộ phận hỗ trợ Okta
- Tệp chứa toàn bộ lưu lượng giữa trình duyệt của nhân viên 1Password và máy chủ Okta, cùng cookie phiên
- 1Password không phản hồi yêu cầu xác nhận tính xác thực của tài liệu do một nhân viên ẩn danh cung cấp dưới dạng văn bản và ảnh chụp màn hình
- Theo báo cáo, kẻ tấn công cũng đã truy cập vào tenant Okta của 1Password
- Tenant Okta được dùng để quản lý quyền truy cập hệ thống và mức phân quyền được cấp cho nhân viên, đối tác và khách hàng
- Kẻ tấn công đã xem các gán nhóm và thực hiện thêm các thao tác khác, nhưng một số thao tác không được ghi lại trong event log
- Trong quá trình đăng nhập, chúng đã cập nhật IDP (identity provider) dùng để xác thực cho môi trường production do Google cung cấp
Những gì kẻ tấn công đã làm và lần tái thử bị chặn
- Nhóm IT của 1Password phát hiện việc truy cập sau khi nhận được một email bất ngờ vào ngày 29/9, ám chỉ có yêu cầu danh sách người dùng 1Password có quyền quản trị
- Các thành viên trong nhóm xác định rằng không có nhân viên được phê duyệt nào thực hiện yêu cầu đó, nên đã báo cho đội ứng phó an ninh của công ty
- Những hành động mà kẻ tấn công đã thực hiện gồm:
- Cố truy cập dashboard Okta của một nhân viên IT nhưng bị chặn
- Cập nhật IDP hiện có gắn với môi trường Google production của 1Password
- Kích hoạt IDP đó
- Yêu cầu báo cáo người dùng quản trị
- Vào ngày 2/10, kẻ tấn công lại đăng nhập vào tenant Okta của 1Password và cố dùng Google IDP mà trước đó chúng đã kích hoạt, nhưng thất bại vì IDP đã bị gỡ bỏ
- Cả hai lần truy cập đều đến từ máy chủ LeaseWeb tại Mỹ và sử dụng phiên bản Chrome trên máy Windows
- Sau sự cố, 1Password đã thay đổi cấu hình tenant Okta để từ chối đăng nhập thông qua các nhà cung cấp danh tính không phải Okta
Cấu trúc mà xâm phạm nhà cung cấp dẫn đến tấn công khách hàng
- Vụ xâm phạm Okta là một trong chuỗi tấn công những năm gần đây nhắm vào các nhà cung cấp phần mềm và dịch vụ có lượng khách hàng lớn
- Kẻ tấn công đột nhập vào nhà cung cấp rồi lợi dụng vị trí đó để thực hiện các cuộc tấn công nối tiếp nhắm vào khách hàng
- Có khả năng sẽ còn thêm nhiều khách hàng Okta khác được xác nhận
1 bình luận
Các ý kiến trên Hacker News
Việc giao SSO cho bên ngoài không chỉ là chuyện về mặt kỹ thuật có dễ hơn hay không, hoặc liệu có đủ năng lực vận hành hay không. Một yếu tố lớn là trong hợp đồng với khách hàng có thể ghi rằng họ dùng nhà cung cấp SSO có uy tín, và nhà cung cấp đó cũng gánh trách nhiệm lập tài liệu về cách quản lý khóa và bảo vệ vật liệu khóa
Trường hợp 1Password hơi đặc biệt vì nhiều khả năng họ đã có sẵn một hệ thống như vậy, nhưng thông thường nói rằng “không ai trong tổ chức có thể truy cập khóa” dễ hơn nhiều so với “Bob là ngoại lệ duy nhất; anh ấy vận hành máy chủ SSO và chúng tôi tin tưởng anh ấy”
Thật thú vị khi lỗ hổng an toàn bộ nhớ của C được nói đến nhiều nhất, nhưng trong nhiều trường hợp, thứ có tác động thực sự lớn lại là cái gọi là sự sụp đổ khả năng thấu hiểu do độ phức tạp quá mức phát sinh khi chạy theo các thiết kế được xem là chuẩn mực
Tôi cho rằng nguyên nhân gốc rễ là giới hạn của con người trong việc nắm bắt độ phức tạp khổng lồ
Vế sau nhiều khả năng phức tạp vì liên quan đến con người, nên người ta dễ tìm kiếm sự cứu rỗi trong công nghệ
Nhìn vào phần “đã thay toàn bộ thông tin xác thực hệ thống của thành viên nhóm IT, và đổi MFA sang chỉ dùng Yubikey”, hy vọng đây sẽ là cơ hội để bắt toàn bộ nhân viên dùng xác thực hai bước dựa trên Yubikey. Những thứ dưới FIDO2 thật sự yếu
Không hiểu vì sao mọi người vẫn chọn Okta. Cá nhân tôi thấy dùng GSuite làm nhà cung cấp danh tính tiện hơn nhiều. Okta đã trải qua một vụ xâm nhập khá nghiêm trọng, và nói thật là ngay cả trước đó tôi cũng chưa từng nghe điều gì tốt đẹp về các thực hành bảo mật của họ
Bắt buộc MFA dựa trên phần cứng là một thực hành tốt và có thể ngăn các cuộc tấn công như spear phishing trong tương lai, nhưng không liên quan đến bản thân sự cố lần này
Việc mọi người chọn Okta gần giống kiểu “chưa ai bị sa thải vì đã mua IBM”. Nếu tự vận hành Keycloak rồi bị tấn công thì đó là trách nhiệm của tôi, còn với Okta thì nó trở thành cấu trúc thuê ngoài khiến vấn đề không còn là của tôi nữa, điều này cũng góp phần
Tôi nghi ngờ liệu bạn đã từng thực sự dùng Google Workspace cho mục đích nghiêm túc chưa. Đây là một trong những nhà cung cấp danh tính thiếu tính năng nhất, còn Okta thuộc nhóm nhiều tính năng nhất. So sánh hai thứ này chỉ vì cả hai đều có hai bánh chẳng khác nào so sánh xe đạp với xe máy
Tôi không ngờ lại thấy Google Workspace được khuyến nghị làm nhà cung cấp danh tính trên một diễn đàn kỹ thuật
Nếu dùng Yubikey, mọi vấn đề hỗ trợ khách hàng liên quan đến mật khẩu sẽ do bộ phận IT nội bộ đảm nhận thay vì nhà thầu bên ngoài
MFA có cả vấn đề kỹ thuật lẫn xã hội; khía cạnh bảo mật kỹ thuật của các triển khai như khóa, token, điện thoại, SMS gần như chỉ là chuyện nhỏ, còn các vấn đề xã hội như hỗ trợ khách hàng, mật khẩu bị mất, khóa bị cho vào máy giặt, không nhận được email mới là thứ áp đảo
Ai cũng muốn thuê ngoài cái vai trò hỗ trợ khách hàng khổng lồ và ngớ ngẩn trong bảo mật, nhưng sau khi làm vậy thì ai cũng có động lực cắt giảm chi phí. Kết quả chính là Okta
Ví dụ, nếu muốn cung cấp quyền truy cập vào AWS organization trong một tổ chức mà toàn bộ nhân viên đều ở GSuite, cách được khuyến nghị là AWS SSO[1]. Thiết lập kết nối thì có thể đăng nhập được, nhưng có các lỗ hổng
Không có chức năng tự động provision hoặc gỡ người dùng trong AWS SSO dựa trên nhóm người dùng GSuite. Có thể tự viết code bằng hỗ trợ SCIM của SSO, nhưng sẽ phải bảo trì
Không có cách nào bắt buộc kiểm tra MFA khi tạo phiên SSO, cả phía GSuite lẫn phía AWS SSO. GSuite không thể yêu cầu kiểm tra MFA trước khi xác thực ứng dụng SAML, và AWS SSO cũng không thể bắt buộc kiểm tra MFA khi dùng nhà cung cấp danh tính, khác với khi dùng Directory nội bộ
Okta và các sản phẩm tương tự làm được những việc này, và nghe nói còn có thể yêu cầu kiểm tra MFA tùy theo endpoint đang dùng. Tôi chưa trực tiếp thử, chỉ dựa trên tài liệu marketing và giải thích của đội bán hàng
Tóm lại, Okta cung cấp nhiều lớp keo tự động hóa và bảo mật hơn rất nhiều giữa nhà cung cấp danh tính và các ứng dụng sử dụng
[1] Ở đây AWS SSO chỉ sản phẩm AWS “AWS IAM Identity Center (Successor to AWS Single Sign-On)”
Bằng chứng hiện thấy chỉ là Okta đã bị xâm nhập năm ngoái, lần này lại bị xâm nhập, và vụ xâm nhập lần này xảy ra ở bộ phận hoặc hệ thống hỗ trợ khách hàng. Việc công bố xâm nhập có thể đã chậm, nhưng cũng có thể do có nhiều báo cáo sai nên đến gần đây họ mới tìm được bằng chứng. Họ không ghi nhận công lao của khách hàng báo cáo đầu tiên, và có thể đã không trao đổi đúng cách với khách hàng sau khi được báo
Những điều chưa biết còn nhiều hơn nhiều. Không biết kẻ tấn công thành thạo đến mức nào, mỗi nhà cung cấp danh tính đã bị xâm nhập bao nhiêu lần, phát hiện được bao nhiêu lần, có phát hiện rồi che giấu hay không, mỗi dịch vụ có bao nhiêu lỗi bảo mật, mức độ nghiêm trọng ra sao và dễ tìm thế nào, năng lực phát hiện xâm nhập thế nào, đào tạo nhân viên tốt đến đâu, tỷ lệ nhân viên thực sự quan tâm đến bảo mật là bao nhiêu
Không thể kết luận sản phẩm tệ hơn chỉ vì Okta đã báo cáo xâm nhập. Chúng ta không biết các sản phẩm khác tốt đến đâu, và Okta cũng có thể tốt hơn một phần hoặc tất cả đối thủ, dĩ nhiên cũng có thể tệ hơn
Trước đây tôi mua 1Password với giá niêm yết, phần mềm hoạt động hoàn toàn offline và lưu kho mật khẩu đã mã hóa ở local hoặc Dropbox. Vì không có gì trên mạng để đánh cắp nên cũng không cần lo hacker
Nhưng rồi ai đó bấm máy tính và quyết định rằng con đường tăng lợi nhuận là chuyển dữ liệu của mọi người lên cloud và thu phí thuê bao. Và giờ chúng ta phải lo liệu dữ liệu có bị rò rỉ hay không
Và với những gì hiện biết, nó khác bao nhiêu so với việc để kho mật khẩu trên Dropbox? Dropbox cũng có thể bị hack, và dữ liệu đó nổi tiếng là không được mã hóa. Chưa có trường hợp nào thực sự biết là kho 1Password đã bị xâm nhập, đúng không?
https://blog.1password.com/okta-incident/
Báo cáo sự cố gốc: https://blog.1password.com/files/okta-incident/okta-incident...
Sau đó, một tác nhân không xác định đã truy cập cổng quản trị Okta bằng chính phiên Okta đã được dùng khi tạo file HAR đó
Như các ngân hàng vẫn luôn nói, không được đưa mật khẩu cho nhân viên hỗ trợ
Lần này trách nhiệm rõ ràng thuộc về Okta. Để xử lý sự cố, họ yêu cầu phiên HAR được mã hóa dạng văn bản thuần, rồi chỉ trông đợi người dùng cuối dọn dẹp đúng cách.
Chẳng phải chỉ cần làm sạch dữ liệu HAR ngay lúc tải lên, để khi đi vào hệ thống và được các kỹ thuật viên hỗ trợ lương thấp, thiếu nhân lực xem xét thì chỉ còn lại những phần liên quan và an toàn sao?
HAR là dữ liệu có cấu trúc nên rất dễ làm sạch bằng chương trình. Không phải khoa học tên lửa gì cả.
Mọi người cứ hỏi vì sao lại dùng trình quản lý mật khẩu tự host, tự đồng bộ thay vì một dịch vụ trực tuyến siêu đơn giản, siêu thân thiện; lý do cũng như vậy thôi. Giống như bạn không ném chìa khóa căn hộ vào két sắt ở ga tàu trong khu phố vậy.
Những tổ chức như vậy thường đã sửa sự cố vài tuần, đôi khi vài tháng trước khi ra tuyên bố.
Nếu bạn dùng mã nguồn mở và phát hiện một lỗi nghiêm trọng, bạn sẽ nhận được bản vá cùng với thông cáo báo chí, nhưng các dịch vụ lớn có khả năng đã sửa vấn đề đó rồi. Với người dùng trung bình, xét theo tương quan rủi ro/lợi ích thì giải pháp dạng dịch vụ có lợi hơn.
Cũng có thể dùng trong script.
Không có chuyện máy chủ bị xâm nhập, không có lỗ hổng extension web, cũng không có chuyện mất toàn bộ mật khẩu vì lỗi máy chủ. Nó cứ thế hoạt động tốt.
Câu “1Password trở thành khách hàng Okta thứ hai được biết đến là mục tiêu của một cuộc tấn công tiếp theo” nghe kỳ lạ. Ars không biết Cloudflare cũng là nạn nhân sao?
https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...
Tôi tò mò về các thực hành tốt nhất để giám sát hành vi đáng ngờ trong ứng dụng. Những thứ cơ bản như kiểm tra tỷ lệ yêu cầu hay tỷ lệ lỗi ở phạm vi dịch vụ thì tôi hiểu, nhưng thực tế có thể tinh vi đến mức nào?
Tôi muốn biết liệu có công cụ thông minh nào nhận luồng sự kiện rồi tìm hành vi bất thường, hay phải cân nhắc trước toàn bộ những gì cần giám sát rồi thêm quy tắc.
Khi đã có luồng sự kiện như vậy, có thể chạy công cụ phân tích dữ liệu. Dựa trên hoạt động trong vài ngày, vài tuần, vài tháng để tạo đường cơ sở bình thường, rồi các hành vi nổi bật như đổi mật khẩu hàng loạt hoặc đổi email phải kích hoạt cảnh báo.
Tuy nhiên đây chỉ là giả thuyết từ một người ngoài cuộc, nên tôi tò mò liệu có ai đã thực sự xử lý audit log và cách sử dụng chúng chưa.
Lại phát hiện nữa à?
https://news.ycombinator.com/item?id=37991863