Cách kẻ tấn công vượt qua Passkeys được đồng bộ hóa

TLDR

Ngay cả khi bạn không nắm được điều gì khác từ bài viết này, nếu tổ chức của bạn đang xem xét triển khai passkeys, thì việc triển khai synced passkeys là không an toàn.

• Synced passkeys kế thừa rủi ro từ các tài khoản đám mây và quy trình khôi phục bảo vệ chúng, điều này tạo ra những rủi ro đáng kể cho doanh nghiệp.
• Các bộ công cụ Adversary-in-the-middle (AiTM) có thể buộc các phương pháp xác thực dự phòng, vô hiệu hóa xác thực mạnh hoàn toàn.
• Các tiện ích mở rộng trình duyệt độc hại hoặc bị xâm phạm có thể chiếm quyền các yêu cầu WebAuthn, thao túng việc đăng ký hoặc đăng nhập passkey, và tự động điền để rò rỉ thông tin đăng nhập và mã một lần.
• Passkeys gắn với thiết bị (device-bound passkeys) trong khóa bảo mật phần cứng mang lại sự đảm bảo cao hơn và kiểm soát quản trị tốt hơn so với synced passkeys, và nên là bắt buộc cho các trường hợp sử dụng truy cập doanh nghiệp.

Rủi ro của Synced Passkeys

Các lỗ hổng của Synced Passkeys

Passkeys là thông tin xác thực được lưu trữ trong một Authenticator. Một số được gắn với thiết bị (device-bound), số khác được đồng bộ hóa giữa các thiết bị thông qua các dịch vụ đám mây tiêu dùng như iCloud và Google Cloud. Việc đồng bộ hóa cải thiện khả năng sử dụng và khôi phục trong các tình huống bảo mật thấp, hướng đến người tiêu dùng, nhưng lại chuyển ranh giới tin cậy sang các tài khoản đám mây và quy trình khôi phục. FIDO Alliance và Yubico đều đã đưa ra các khuyến nghị quan trọng để các doanh nghiệp đánh giá sự phân chia này và ưu tiên các tùy chọn gắn với thiết bị (device-bound) để có độ tin cậy cao hơn.

Về mặt vận hành, synced passkeys mở rộng bề mặt tấn công theo ba cách:

1. Việc chiếm đoạt tài khoản đám mây hoặc lạm dụng quy trình khôi phục có thể ủy quyền các thiết bị mới, làm suy yếu tính toàn vẹn của thông tin xác thực.
2. Nếu người dùng đăng nhập trên thiết bị công ty bằng tài khoản Apple iCloud cá nhân của họ, thì các passkey được tạo có thể được đồng bộ hóa với các tài khoản cá nhân của họ; điều này làm tăng đáng kể bề mặt tấn công vượt ra ngoài ranh giới bảo mật của doanh nghiệp.
3. Bộ phận hỗ trợ (help desk) và khôi phục tài khoản trở thành những điểm kiểm soát thực sự mà kẻ tấn công nhắm đến, vì chúng có thể sao chép cùng một chuỗi khóa được bảo vệ sang một thiết bị mới, không xác định và không đáng tin cậy.

Các cuộc tấn công hạ cấp xác thực (Authentication downgrade attacks)

Các nhà nghiên cứu của Proofpoint đã ghi nhận một cuộc tấn công hạ cấp (downgrade attack) thực tế chống lại Microsoft Entra ID, trong đó một proxy lừa đảo giả mạo một trình duyệt không được hỗ trợ, chẳng hạn như Safari trên Windows. Entra sau đó vô hiệu hóa passkeys, và người dùng được hướng dẫn chọn một phương pháp yếu hơn, như SMS hoặc OTP. Proxy sau đó chiếm đoạt thông tin đăng nhập và session cookie, rồi nhập chúng để giành quyền truy cập.

Vector tấn công này dựa vào sự hỗ trợ không đồng đều của WebAuthn passkey trên các hệ điều hành và trình duyệt, cũng như sự chấp nhận các phương pháp xác thực yếu của nhà cung cấp danh tính (IdP) để đổi lấy trải nghiệm người dùng (UX) tiện lợi. Đây là một cuộc tấn công Adversary-in-the-middle (AiTM) cổ điển được hỗ trợ bởi định hướng chính sách (policy steering). Nó không phá vỡ liên kết nguồn gốc WebAuthn vì nền tảng không bao giờ đạt đến nghi thức WebAuthn khi một nhánh tương thích vô hiệu hóa nó. Phương pháp xác thực yếu nhất của bạn sẽ định nghĩa mức độ bảo mật thực sự của bạn.

Immediate mediation trong WebAuthn là một tính năng cho phép các trang web cung cấp phương pháp xác thực thay thế khi WebAuthn không khả dụng. Điều này hữu ích cho UX nhưng cũng có thể bị kẻ tấn công lạm dụng để hướng người dùng đến các đường dẫn không phải WebAuthn nếu chính sách cho phép.

Bảo mật dựa trên trình duyệt dễ bị tấn công bởi tiện ích mở rộng và khai thác tự động điền

Các nhà nghiên cứu của SquareX đã chỉ ra rằng một môi trường trình duyệt bị xâm phạm có thể chiếm quyền các lệnh gọi WebAuthn và thao túng việc đăng ký hoặc đăng nhập passkey. Kỹ thuật này không phá vỡ mã hóa passkey. Nó tiêm hoặc chặn quá trình phía trình duyệt, ví dụ thông qua một tiện ích mở rộng độc hại hoặc một lỗ hổng XSS, để khởi tạo lại đăng ký, buộc quay về mật khẩu, hoặc tự động hoàn thành một xác nhận.

Chrome tài liệu một API tiện ích mở rộng có tên "webAuthenticationProxy" có thể chặn các phương thức navigator.credentials.create() và navigator.credentials.get() sau khi được gắn vào, sau đó cung cấp các phản hồi của riêng nó. Khả năng này tồn tại cho các trường hợp sử dụng máy tính từ xa, nhưng nó cho thấy rằng một tiện ích mở rộng với quyền hạn thích hợp có thể nằm trong đường dẫn WebAuthn.

Các tiện ích mở rộng cũng chạy các tập lệnh nội dung bên trong ngữ cảnh trang, nơi chúng có thể đọc và sửa đổi DOM và điều khiển các luồng giao diện người dùng, bao gồm cả việc gọi các API thông tin xác thực từ trang.

Nghiên cứu độc lập được trình bày tại DEF CON đã mô tả kỹ thuật DOM-based extension clickjacking nhắm mục tiêu vào các yếu tố UI được tiêm bởi các tiện ích quản lý mật khẩu. Một cú nhấp chuột của người dùng trên một trang được thiết kế tinh vi có thể kích hoạt tính năng tự động điền và rò rỉ dữ liệu được lưu trữ như thông tin đăng nhập, thẻ tín dụng và mã một lần. Nhà nghiên cứu báo cáo rằng trong một số trường hợp, xác thực passkey cũng có thể bị khai thác và liệt kê các phiên bản dễ bị tổn thương trên nhiều nhà cung cấp khác nhau.

Credentials gắn với thiết bị là giải pháp hiệu quả duy nhất cho doanh nghiệp

Passkeys gắn với thiết bị (device-bound passkeys) được gắn với một thiết bị cụ thể, thường với việc tạo và sử dụng khóa riêng tư được thực hiện trong các thành phần phần cứng bảo mật. Trong doanh nghiệp, các khóa bảo mật phần cứng cung cấp các tín hiệu thiết bị nhất quán, xác nhận và một vòng đời mà bạn có thể kiểm kê và thu hồi.

Hướng dẫn cho chương trình Passkey cấp doanh nghiệp

Chính sách

• Yêu cầu xác thực chống lừa đảo (phishing-resistant authentication) cho tất cả người dùng, đặc biệt là những người có vai trò đặc quyền. Chỉ chấp nhận các Authenticator gắn với thiết bị tạo ra thông tin xác thực không thể xuất (non-exportable credentials) khi đăng ký và không bao giờ rời khỏi thiết bị. Credentials phải được gốc rễ trong phần cứng bảo mật và có thể xác minh được gắn với thiết bị vật lý đang cố gắng đăng nhập.
• Loại bỏ tất cả các phương pháp dự phòng như SMS, cuộc gọi thoại, ứng dụng TOTP, liên kết email và phê duyệt đẩy (push approvals). Những phương pháp này tồn tại để bị khai thác trong các cuộc tấn công lừa đảo xã hội và hạ cấp (downgrade attacks). Nếu một phương pháp dự phòng tồn tại, kẻ tấn công sẽ buộc nó. Hãy biến đường dẫn mạnh mẽ thành đường dẫn duy nhất.
• Đảm bảo hỗ trợ phổ quát cho hệ điều hành và trình duyệt đối với các thông tin xác thực chống lừa đảo, gắn với thiết bị. Không cung cấp các lựa chọn thay thế – vâng, điều này là có thể, chúng tôi rất vui được trình diễn cho bạn một bản demo với nền tảng phòng thủ định danh của Beyond Identity. Phạm vi bao phủ toàn cầu là cần thiết cho phòng thủ hoàn chỉnh vì bạn chỉ được bảo vệ an toàn bằng liên kết yếu nhất của mình.

Tình trạng trình duyệt và tiện ích mở rộng

• Thực thi danh sách cho phép tiện ích mở rộng (extension allowlists) trong các trình duyệt được quản lý. Cấm bất kỳ tiện ích mở rộng nào yêu cầu các quyền webAuthenticationProxy, activeTab hoặc quyền tập lệnh nội dung rộng.
• Liên tục giám sát cài đặt tiện ích mở rộng và xu hướng sử dụng để tìm các hành vi xóa hàng loạt đáng ngờ hoặc leo thang quyền hạn không giải thích được. Sự xâm phạm cấp tiện ích mở rộng ngày càng khó phân biệt với người dùng hợp pháp. Khóa chặt hành vi trình duyệt giống như bạn khóa một Endpoint.

Đăng ký và Khôi phục

• Sử dụng Authenticator có độ tin cậy cao làm gốc rễ của quá trình khôi phục. Không có bộ phận hỗ trợ (help desk), hộp thư đến email hoặc trung tâm cuộc gọi nào có thể bỏ qua các kiểm soát chống lừa đảo. Khôi phục thường là điểm vào của kẻ tấn công. Loại bỏ các vector lừa đảo xã hội và buộc xác minh lại tuân thủ chính sách.
• Chỉ cho phép đăng ký Credentials gắn với thiết bị.
• Thu thập siêu dữ liệu xác nhận (attestation metadata) khi đăng ký, bao gồm kiểu thiết bị và mức độ đảm bảo. Từ chối các Authenticator không được nhận dạng hoặc không thể xác minh. Niềm tin bắt đầu từ việc đăng ký. Nếu bạn không biết điều gì đã tạo ra thông tin xác thực, bạn sẽ không kiểm soát được quyền truy cập.

Vệ sinh thiết bị và phòng thủ thời gian chạy (Runtime Defense)

• Gắn các phiên làm việc (sessions) vào ngữ cảnh thiết bị đáng tin cậy. Một session cookie không bao giờ nên là một Artifact có thể di chuyển được. Thực thi phiên làm việc thời gian chạy (Runtime session enforcement) nên gắn định danh với tình trạng thiết bị liên tục, không chỉ là xác thực ban đầu.
• Thực thi xác thực liên tục (continuous authentication). Nếu tình trạng thiết bị (device posture), vị trí hoặc trạng thái bảo mật thay đổi, yêu cầu xác thực lại hoặc từ chối quyền truy cập. Một lần đăng nhập không phải là một "vé thông hành". Rủi ro là năng động, xác thực cũng phải vậy.
• Giả định rằng các nỗ lực xác thực bằng các yếu tố yếu nên bị chặn theo mặc định. Xem cách khách hàng của Beyond Identity ngay lập tức chặn các cuộc tấn công định danh dựa trên thực tế đơn giản là đó không phải là một Credential mạnh đang cố gắng truy cập.

Điều này trông như thế nào trong thực tế

Kiến trúc của một hệ thống bảo mật định danh cung cấp khả năng phòng thủ không khoan nhượng chống lại các cuộc tấn công dựa trên định danh, trình duyệt và thiết bị có thể được định nghĩa bởi ba đặc điểm sau:

1. Credentials gắn với thiết bị: Credentials không bao giờ rời khỏi thiết bị. Chúng không thể xuất (non-exportable), được hỗ trợ bởi phần cứng, và không thể được đồng bộ hóa hoặc phát lại ở nơi khác.
2. Niềm tin liên tục: Xác thực không bao giờ dừng lại ở việc đăng nhập. Nó tiếp tục trong suốt phiên làm việc, gắn liền với các tín hiệu tình trạng từ thiết bị.
3. Thực thi vệ sinh Endpoint phổ quát: Tất cả các Endpoint đều nằm trong phạm vi. Ngay cả các thiết bị không được quản lý cũng phải được đánh giá theo thời gian thực về tình trạng rủi ro và tính toàn vẹn của phiên làm việc.

Kết luận

Synced passkeys không phải là một "lá chắn" phù hợp cho mục đích phòng thủ. Chúng cải thiện khả năng sử dụng cho các trường hợp tiêu dùng nhưng phải trả giá bằng bảo mật truy cập của doanh nghiệp.

Hãy xem thêm chi tiết trong một hội thảo trực tuyến sắp tới, How Attackers Bypass FIDO: Why Synced Passkeys Fail and What To Do Instead, nơi Beyond Identity sẽ xem xét cách các lỗi của synced passkey xảy ra và cách các đội bảo mật hàng đầu, bao gồm Snowflake và Cornell University, khắc phục những lỗ hổng này.

Ngay cả khi bạn không thể tham gia, hãy đăng ký và bạn sẽ nhận được bản ghi!