Tin tặc đánh cắp token truy cập từ bộ phận hỗ trợ của Okta

 (krebsonsecurity.com)
1 điểm bởi GN⁺ 2023-10-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • Do hệ thống hỗ trợ khách hàng của Okta bị xâm phạm, các tệp mà một số khách hàng tải lên trong các case hỗ trợ đã bị lộ; kẻ tấn công dường như đã truy cập nền tảng hỗ trợ trong ít nhất 2 tuần trước khi bị chặn
  • Kẻ tấn công dùng thông tin xác thực bị đánh cắp để vào hệ thống quản lý case hỗ trợ, qua đó có thể xem các tệp HAR mà khách hàng gửi để khắc phục sự cố
  • Tệp HAR có thể chứa cookie và token phiên, nên nếu bị đánh cắp, kẻ tấn công có nguy cơ tái sử dụng phiên như một người dùng hợp lệ
  • BeyondTrust phát hiện một nỗ lực tạo tài khoản quản trị trong môi trường Okta của mình vào ngày 2/10; 30 phút trước đó, họ đã chia sẻ với Okta một tệp HAR chứa token phiên Okta hợp lệ
  • Okta đã thông báo cho khoảng 170 khách hàng, tương đương khoảng 1% trong hơn 18.000 khách hàng; 1Password và Cloudflare cũng công bố nền tảng xác thực Okta của họ bị ảnh hưởng, nhưng cho biết không có tác động tới thông tin khách hàng hay hệ thống

Tệp khách hàng bị lộ trong hệ thống quản lý case hỗ trợ

  • Okta là công ty cung cấp công cụ định danh cho hàng nghìn doanh nghiệp, bao gồm xác thực đa yếu tố và đăng nhập một lần; sự cố lần này bắt đầu từ việc bộ phận hỗ trợ khách hàng bị xâm phạm
  • Trong thông báo gửi tới một số khách hàng ngày 19/10, Okta cho biết thông tin xác thực bị đánh cắp đã được dùng để truy cập hệ thống quản lý case hỗ trợ
  • Kẻ tấn công có thể xem các tệp mà một số khách hàng Okta đã tải lên trong các case hỗ trợ gần đây
  • Phạm vi ảnh hưởng ban đầu được mô tả là “rất ít”, và sau đó được xác nhận là đã thông báo cho khoảng 170 khách hàng, tương đương khoảng 1% cơ sở khách hàng

Vì sao tệp HAR trở nên nguy hiểm

  • Khi xử lý vấn đề của khách hàng, Okta đôi khi yêu cầu tệp HTTP Archive(HAR), tức bản ghi phiên trình duyệt web
  • Tệp HAR nhạy cảm vì có thể chứa cookie và token phiên của khách hàng
  • Kẻ tấn công có thể dùng cookie hoặc token trong tệp để giả mạo như một người dùng hợp lệ
  • Okta đã phối hợp với các khách hàng bị ảnh hưởng để điều tra và thực hiện các biện pháp bảo vệ, bao gồm thu hồi các token phiên được nhúng
  • Trước khi chia sẻ tệp HAR, cần loại bỏ tất cả thông tin xác thực, cookie và token phiên

Luồng tấn công BeyondTrust phát hiện

  • Công ty bảo mật BeyondTrust là một trong các khách hàng nhận được thông báo ngày 19/10 của Okta
  • CTO BeyondTrust Marc Maiffret nói rằng thông báo này đến hơn 2 tuần sau khi BeyondTrust đã báo cho Okta về một vấn đề tiềm ẩn
  • Ngày 2/10, đội bảo mật BeyondTrust phát hiện có người dùng tài khoản Okta được gán cho một kỹ sư của họ để cố tạo một tài khoản quản trị quyền cao trong môi trường Okta của công ty
  • Khi rà soát hoạt động của tài khoản nhân viên đó, họ phát hiện 30 phút trước hoạt động trái phép, kỹ sư hỗ trợ đã chia sẻ với Okta một tệp HAR chứa token phiên Okta hợp lệ theo yêu cầu của Okta
  • Kẻ tấn công đã cố dùng cookie trong lịch sử trình duyệt để thực hiện chiếm quyền phiên, rồi hành động thay mặt người dùng đó
  • BeyondTrust đã thông báo vào ngày 3/10 rằng Okta nhiều khả năng đã bị xâm phạm, và tiếp tục truyền đạt nhận định này trong các cuộc gọi ngày 11/10 và 13/10
  • BeyondTrust cho biết họ đã phát hiện cuộc tấn công khi nó đang diễn ra, và khách hàng của họ không bị ảnh hưởng

Phản ứng của Okta và những câu hỏi còn lại

  • Deputy CISO của Okta, Charlotte Wylie, nói rằng ban đầu Okta không xem cảnh báo ngày 2/10 của BeyondTrust là hệ quả của việc hệ thống của chính Okta bị xâm phạm
  • Đến ngày 17/10, Okta đã xác định và chặn sự cố, vô hiệu hóa tài khoản quản lý case khách hàng bị xâm phạm và hủy hiệu lực các token truy cập Okta liên quan
  • Wylie không công bố chính xác số khách hàng nhận được cảnh báo về vấn đề bảo mật tiềm ẩn, nhưng mô tả đó là “một phần rất, rất nhỏ” trong hơn 18.000 khách hàng
  • Okta không công bố kẻ xâm nhập đã truy cập tài khoản quản lý case của công ty trong bao lâu, cũng như ai đứng sau cuộc tấn công
  • Wylie cho biết kẻ tấn công lần này là một tác nhân đe dọa đã biết, từng nhắm vào Okta và một số khách hàng cụ thể của Okta

Các vụ xâm phạm liên quan và công bố tiếp theo

  • Công bố của Okta xuất hiện chỉ vài tuần sau các vụ hack Caesar’s Entertainment và MGM Resorts
  • Trong hai vụ liên quan đến các công ty casino này, kẻ tấn công đã dùng kỹ thuật xã hội để lừa nhân viên đặt lại yêu cầu đăng nhập xác thực đa yếu tố cho tài khoản quản trị Okta
  • Tháng 3/2022, Okta công bố một vụ xâm phạm liên quan đến nhóm hacker chuyên tấn công bằng kỹ thuật xã hội LAPSUS$
  • Theo báo cáo hậu sự cố của Okta, LAPSUS$ đã dùng kỹ thuật xã hội để truy cập workstation của một kỹ sư hỗ trợ thuộc Sitel, nhà cung cấp outsourcing bên thứ ba có quyền truy cập tài nguyên Okta
  • Sau đó Okta đăng bài blog liên quan đến sự cố, trong đó có các chỉ báo xâm phạm để khách hàng có thể kiểm tra liệu mình có bị ảnh hưởng hay không
    • Okta cho biết đã thông báo cho tất cả khách hàng bị ảnh hưởng
    • Okta nhấn mạnh rằng môi trường hoặc ticket hỗ trợ của các khách hàng Okta không nhận được liên hệ riêng không bị ảnh hưởng
  • BeyondTrust cũng công bố kết quả điều tra riêng
  • Trong bản cập nhật ngày 24/10, 1Password và Cloudflare công bố rằng nền tảng xác thực Okta của họ đã bị xâm phạm do hệ quả từ vụ xâm phạm Okta
    • Cả hai công ty đều cho biết kết quả điều tra cho thấy thông tin khách hàng hoặc hệ thống không bị ảnh hưởng
    • Người phát ngôn của Okta nói với TechCrunch rằng công ty đã thông báo cho khoảng 1% cơ sở khách hàng, tức khoảng 170 khách hàng

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-22
Ý kiến trên Hacker News

  • Điểm buồn cười trong bài này là Okta được một bên thứ ba thông báo về hoạt động tenant đáng ngờ, ban đầu không tìm thấy bằng chứng bị xâm phạm, rồi chỉ sau khi BeyondTrust tiếp tục gây sức ép thì mới điều tra lại và xác nhận có xâm phạm
    Okta đã đăng bài blog ở đây: https://sec.okta.com/harfiles
    Câu mở đầu là “Okta Security has identified adversarial activity”, nhưng không hề nhắc đến thông báo từ bên thứ ba. Minh bạch ghê

    • Đến giờ vẫn không hiểu ai còn dùng Okta. Xác thực là phần quan trọng nhất trong mọi hệ thống IT, nhưng Okta đã nhiều lần chứng minh họ là một bên không thể tin cậy và thiếu tính toàn vẹn. Trông như một quả bom hẹn giờ sắp nổ
    • Tiêu đề của Okta có lẽ là tiêu đề nhạt nhẽo nhất trong lịch sử các thông báo vi phạm bảo mật: “Tracking Unauthorized Access to Okta's Support System”
      Tiêu đề tệ hại, không minh bạch cũng chẳng trực diện. Việc Okta thậm chí không nhắc rằng BeyondTrust đã báo cho họ vào ngày 2/10, chỉ 30 phút sau khi tải file HAR lên Okta Support, thật sự quá kém

  • “Phó CISO của Okta, Charlotte Wylie, nói rằng ban đầu Okta cho rằng cảnh báo ngày 2/10 của BeyondTrust không phải là kết quả của việc hệ thống của họ bị xâm phạm. Nhưng bà nói rằng đến ngày 17/10, công ty đã xác định và chặn sự cố”
    Tức là một công ty tự nhận là chuyên gia an ninh mạng và xác thực được báo trong vòng 30 phút rằng họ đã bị hack, nhưng họ nói bên kia sai và suốt 15 ngày không thừa nhận, trong khi kẻ tấn công tự do hoạt động
    Wylie, phải làm tốt hơn nữa

  • Nên xem bài blog này được liên kết trong bài gốc. Một công ty bảo mật, cũng là một khách hàng của Okta, đã phát hiện hoạt động đáng ngờ trong mạng của mình ngay sau khi chia sẻ file HAR với Okta và báo cho Okta về vụ xâm phạm
    https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...

    • Amazon Service vừa yêu cầu tôi chia sẻ file HAR, và tôi nghĩ đó chắc chắn là rủi ro bảo mật. Điều đó chẳng phải có nghĩa là nhân viên hỗ trợ sẽ có cookie xác thực của tài khoản tôi sao? Không hiểu vì sao thực hành này lại có thể phổ biến
    • Bài đó lướt qua khá mơ hồ việc họ phát hiện chiếm đoạt phiên chính xác như thế nào. Họ nói “cơ chế phát hiện này tìm các phiên đáng ngờ xuất hiện mà không có sự kiện xác thực, phù hợp với hành vi chiếm đoạt phiên”, nhưng để một phiên tồn tại thì hiển nhiên phải từng có xác thực ở một thời điểm nào đó
      Có lẽ đó là cách nói phức tạp rằng IP đã thay đổi sau khi đăng nhập. Dĩ nhiên cách xử lý dễ nhất là không tự nguyện chia sẻ file HAR của phiên đang hoạt động
    • Bài này có đủ chi tiết hợp lý để hiểu vấn đề. Ngược lại, bài của Okta cần rất nhiều ngữ cảnh mới hiểu được

  • Nói thế này có thể không được lòng mọi người, nhưng tôi nghĩ cổng lõi SSO dùng OAuth, SAML, 2FA có lẽ nên được vận hành on-premise thay vì bấm “nút dễ” của SaaS
    Không chỉ Okta, mà còn gồm cả Auth0 (được Okta mua lại), Authy, Duo

    • Đáng tiếc là vận hành on-premise không ngăn được vi phạm bảo mật, và thậm chí có thể tệ hơn nhiều so với giao xác thực cho nhà cung cấp đám mây
      Mọi phần mềm đều có lỗi bảo mật, và phần mềm on-premise cũng không ngoại lệ. Nhiều tổ chức IT không có chuyên môn để vận hành và bảo vệ directory. Đây không phải là việc cài phần mềm, tạo vài tài khoản rồi nhét vào một góc, mà là công việc rất khó, bao gồm khôi phục thảm họa, kiểm thử sao lưu, xác định có bị xâm phạm hay không
      Chưa ai chứng minh được bảo mật IT on-premise tốt hơn bảo mật của nhà cung cấp đám mây. Trong các bộ phận IT on-premise tôi từng thấy, có những nơi bảo mật cực kỳ tệ: vận hành VPN dùng chứng chỉ MD5 ngay cả giai đoạn 2010–2020, triển khai dịch vụ web cho phép người dùng chưa xác thực truy cập thông tin cá nhân như số an sinh/số thuế, địa chỉ, tên, số điện thoại, đưa cho y tá một trình soạn thảo văn bản có quảng cáo để ghi chú bệnh nhân, không cập nhật phiên bản Redcap đã hết hỗ trợ dù có lỗi bảo mật đã biết, v.v.
      Theo tôi biết, Redcap là phần mềm lưu trữ thông tin dùng trong nghiên cứu y học và tính toán thống kê y tế công cộng, nên có rất nhiều dữ liệu nhạy cảm
      Điểm chính là chuyển từ đám mây sang on-premise có thể làm bảo mật tốt hơn, cũng có thể không. Điều đó phụ thuộc vào năng lực của từng tổ chức IT, và nhiều tổ chức không có khả năng vận hành dịch vụ danh tính như Okta. Ngoài ra, nhà cung cấp đám mây thường có ngân sách lớn hơn nhiều và có thể phân bổ chi phí cho nhiều khách hàng, nên đầu tư được nhiều hơn vào chuyên gia bảo mật, bảo vệ hệ thống và phát hiện xâm phạm
    • Đồng ý, nhưng ngày nay chi phí on-premise thì bị tính toán khá nghiêm ngặt, còn với đám mây thì chỉ cần ai đó nói “chúng tôi đã chuyển chi tiêu vốn thành chi phí vận hành và triển khai giải pháp cloud-native tự động mở rộng hàng đầu” là được coi như thiên tài
      Những quản lý và lãnh đạo như vậy chẳng bị hỏi gì cả
    • Thêm một ý nữa có lẽ cũng không được lòng mọi người: nếu không cần kết nối vào mạng thì đừng kết nối
      Thực tế là có thể viết và kiểm thử phần mềm trên những hệ thống chưa từng được kết nối. Nghe khó tin nhưng là thật
    • Cũng đừng quên Azure AD. Đó là nơi từng bị lộ root key
    • Duo có phiên bản on-premise không? Hay nếu muốn có gần đủ phần lớn chức năng trên domain của mình thì tôi phải triển khai và thành thạo năm giải pháp khác nhau?

  • Những nơi như nhà cung cấp danh tính, trình quản lý mật khẩu, công ty VPN tuyệt đối không được để bị hack. Họ là những công ty kiếm tiền từ sản phẩm bảo mật, và tôi sẽ không dùng nơi nào đã bị xâm phạm. Rất có thể còn có vấn đề sâu xa hơn

    • Ai cũng có thể bị hack. Rõ ràng là không ai biết cách dùng phần mềm an toàn tuyệt đối. Cũng không ai biết cách vận hành mà không bao giờ mắc lỗi, không cấu hình sai, không quên thu hồi quyền truy cập, và luôn xoay vòng các bí mật
    • Trước khi chứng minh được rằng họ không thể bị xâm phạm, tôi không hiểu vì sao phải dùng
      Giả định mặc định là tất cả đều có thể bị xâm phạm, và trách nhiệm chứng minh rằng họ sẽ không bị xâm phạm thuộc về họ. Thay vì dành thiện chí cho những người đã nhiều lần thể hiện sự bất tài, có vẻ thận trọng hơn khi chờ bằng chứng tích cực hậu thuẫn cho tuyên bố bất thường rằng họ không bị hack
    • Như câu nói cũ, bảo mật không phải là một sản phẩm mà là một quy trình. Nhưng vì quy trình đó rất khó, nên luôn có cám dỗ muốn dựa vào cái trước hơn cái sau
    • Những dịch vụ như vậy, theo định nghĩa, là hũ mật. Nghĩ rằng chúng tuyệt đối không bị hack là ngây thơ. Bị hack chỉ là vấn đề thời gian
      Nếu đủ năng lực và có trách nhiệm, họ sẽ phát hiện và công khai, nhưng tôi nghĩ phần lớn sẽ không làm vậy. Vì những người như bạn sẽ ngừng sử dụng ngay. Vì thế bất cứ ai dù chỉ hơi lo lắng cũng nên dùng các phương án thay thế ngoại tuyến, tự host, tự làm

  • Thử thách Okta không bị hack trong một tháng: độ khó bất khả thi
    Bỏ đùa sang một bên, Okta trông như thể rất thích bị đánh cắp dữ liệu. Người ta sẽ kỳ vọng giá cổ phiếu cứ tiếp tục giảm vì những vụ như thế này thì sẽ có thay đổi, nhưng có vẻ không phải vậy

    1. https://www.malwarebytes.com/blog/news/2023/01/okta-breached...
    2. https://www.theverge.com/2022/4/20/23034360/okta-lapsus-hack...
    3. https://techmonitor.ai/technology/cybersecurity/okta-cyberat...

  • Ma quỷ nằm ở chi tiết. Có lẽ họ đã vận hành theo mô hình zero trust
    Một mặt, đây không phải là việc sản phẩm cốt lõi bị xâm phạm. Mặt khác, mọi vụ xâm phạm sản phẩm cốt lõi đều đi kèm một vụ xâm phạm gián tiếp ở phần không cốt lõi

  • Thật may là họ được phép mua lại đối thủ Auth0 nhỉ

  • Một ngày nào đó, trong một bài trình bày hội nghị, tôi sẽ thử nghiệm bằng cách trả tiền để đưa người vào các vị trí hỗ trợ của nhiều công ty, rồi dùng quyền truy cập hệ thống được cấp cho họ để xâm phạm các công ty đó

  • Ở cuối email có ghi như thế này
    “Thông tin này là thông tin mật của Okta và không được chia sẻ ra ngoài tổ chức của bạn”
    Thành thật mà nói thì khá buồn cười

    • Nếu họ yêu cầu file HAR như một quy trình hỗ trợ mặc định, tại sao lúc tải lên lại không tự động loại bỏ thông tin nhạy cảm?