Qua mặt MFA không cần mở khóa: Chiêu trò tàng hình của mã độc nhắm vào Google Password Manager
Tổng Quan
Chỉ bằng cách đọc một tệp tin LevelDB cục bộ trên máy tính mà không hề cần đến quyền quản trị (Admin/System), một mã độc (malware) thông thường nay đã có thể qua mặt hoàn toàn lớp bảo vệ xác thực đa yếu tố chống lừa đảo (Phishing-resistant MFA) của Google.
Phát hiện chấn động này về bề mặt tấn công mới mang tên "Pass-ta-key" từ Unit 42 (Palo Alto Networks) đã đặt ra một câu hỏi lớn: Liệu sự hào nhoáng của xác thực không mật khẩu (passwordless) có thực sự an toàn tuyệt đối như chúng ta lầm tưởng? Bằng việc lạm dụng cơ chế đồng bộ private key, hacker có thể đánh cắp thông tin xác thực, mô phỏng sinh trắc học và vượt qua mọi rào cản MFA. Dưới đây là phân tích chi tiết về cách mã độc lách luật, tại sao kiến trúc Passkey hiện tại lại bộc lộ điểm yếu, và chúng ta cần hành động gì để ngăn chặn.
Giải Mã Passkey
Trước khi đi sâu vào lỗ hổng, chúng ta cần hiểu rõ bản chất của Passkey. Passkey ra đời nhằm mục đích thay thế hoàn toàn mật khẩu (password), giải quyết triệt để vấn đề dùng lại mật khẩu và các chiến dịch Phishing.
Ý nghĩa và Bản chất
Thay vì dùng một chuỗi ký tự bí mật (shared secret) mà cả server và người dùng đều biết, Passkey dựa trên Hệ mật mã khóa công khai (Public-Key Cryptography) theo chuẩn WebAuthn/FIDO2.
Mọi thông tin trên server chỉ là Khóa công khai (Public Key). Việc server bị hack hay rò rỉ dữ liệu sẽ không làm lộ thông tin xác thực.
Kẻ tấn công lập ra trang web giả mạo (phishing) cũng không thể lấy được chứng danh, vì quá trình ký số (signing) của trình duyệt luôn gắn chặt với tên miền (origin-bound) gốc.
Cấu trúc kỹ thuật
Một luồng xác thực Passkey hoàn chỉnh bao gồm các thành phần sau:
Relying Party (RP): Máy chủ dịch vụ (ví dụ: Google, Microsoft) yêu cầu xác thực.
Authenticator: Thành phần quản lý khóa (có thể là chip TPM trên máy tính, điện thoại, hoặc YubiKey).
Client/Trình duyệt: Cầu nối trung gian để chuyển tiếp thử thách (challenge) từ RP đến Authenticator.
Khi bạn đăng nhập, RP sẽ gửi một đoạn dữ liệu ngẫu nhiên (Challenge). Authenticator sẽ dùng Private Key nằm sâu trong phần cứng để ký (Sign) lên Challenge này và gửi lại server kiểm chứng. Để lệnh ký được thực thi, Authenticator yêu cầu User Presence (chạm vào thiết bị) và thường là User Verification (quét vân tay, khuôn mặt hoặc mã PIN).
Bối Cảnh: Khi Private Key "Lên Mây"
Trong thiết kế ban đầu (FIDO U2F / Security Key), private key nằm chết trên một con chip phần cứng duy nhất. Điều này cực kỳ an toàn nhưng lại mang đến "cơn ác mộng" trải nghiệm người dùng: nếu mất thiết bị, bạn mất luôn tài khoản.
Để giải quyết vấn đề này, Apple, Google và Microsoft đã giới thiệu Synced Passkey (Passkey đồng bộ).
Private key không còn bị khóa chết ở một thiết bị, mà được mã hóa và đồng bộ lên Cloud (ví dụ: Google Password Manager, iCloud Keychain).
Dù đồng bộ lên Cloud, Google bảo vệ các private key này bằng một môi trường cách ly (cloud-enclave) và kiểm soát việc giải mã bằng một "Master Key" được gắn trực tiếp vào phần cứng (hardware-backed) của từng thiết bị điểm cuối.
Chính sự chuyển dịch từ "khóa cứng" sang "khóa đồng bộ" này đã tạo ra một khe hở. Unit 42 đã chứng minh rằng nếu thiết bị điểm cuối đã bị kiểm soát bởi mã độc (Malware/Infostealer), các lớp phòng thủ phức tạp phía sau hoàn toàn có thể bị vô hiệu hóa.
Chi Tiết Kỹ Thuật
Các cuộc tấn công này nhắm trực tiếp vào Google Password Manager trên trình duyệt Chrome (Windows) đang sử dụng chip TPM. Kịch bản giả định là thiết bị nạn nhân đã bị nhiễm mã độc (malware) từ trước.
Bước 1: Quá trình thu thập thông tin
Luồng thực thi:
Malware hoạt động trên endpoint âm thầm truy cập vào cơ sở dữ liệu đồng bộ của Chrome tại đường dẫn:
%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB.Trích xuất các bản ghi
WebauthnCredentialSpecifics(chứa dữ liệu đồng bộ WebAuthn đã mã hóa).Liệt kê các dịch vụ mà nạn nhân sử dụng passkey, định danh người dùng và private key mã hóa. Lưu ý: Quá trình này hoàn toàn hoạt động ở không gian người dùng (user-space), không hề yêu cầu quyền Admin/System.
Bước 2: Pass-ta-key
Mục tiêu là lạm dụng "Identity Key" (Khóa định danh thiết bị) để thay mặt nạn nhân xác thực mà không cần họ thao tác. Luồng thực thi:
Khởi tạo: Kẻ tấn công chọn một dịch vụ mục tiêu và bấm "Đăng nhập bằng Passkey" trên máy của chúng. Máy chủ dịch vụ (RP) trả về một mã Challenge.
Handshake: Kẻ tấn công khởi tạo kết nối WebSocket với Google Cloud Authenticator.
Ký số ngầm (Silent Signing): Kẻ tấn công ra lệnh cho malware tương tác với TPM của nạn nhân. Nó xuất (export) identity key được mã hóa từ tệp
passkey_enclave_statevà dùng các hàm API mật mã chuẩn của Windows (CNG API) để ký lên yêu cầu mà không cần mật khẩu hay sinh trắc học.Giả mạo: Kẻ tấn công gửi yêu cầu đã ký lên Google Cloud Authenticator. Đám mây tưởng nhầm đây là thiết bị hợp lệ nên trả về một chữ ký hợp lệ (Assertion).
Hoàn tất: Chữ ký này được gửi lại cho RP để hoàn tất chiếm đoạt tài khoản (ATO). Nhược điểm của kỹ thuật này là cờ User Verified (UV) sẽ mang giá trị 0. Nếu RP bắt buộc UV=1, xác thực sẽ thất bại.
Bước 3: Silver Pass-ta-key - Tiếp tay bởi CVE-2026-34348
Để vượt qua rào cản User Verified = 1 (buộc phải có sinh trắc học/Mã PIN), kẻ tấn công đăng ký một "User Verification Key" (Khóa xác minh người dùng) giả mạo. Luồng thực thi:
Xóa dấu vết: Malware xóa tệp passkey_enclave_state trên máy nạn nhân, buộc Chrome phải thiết lập lại thiết bị (re-onboard) ở lần dùng passkey tiếp theo.
Lợi dụng trạng thái chờ: Trong quá trình thiết lập lại, Chrome đưa hệ thống vào trạng thái uv_key_pending (chờ tạo khóa sinh trắc học sau để tránh hỏi mã PIN nhiều lần).
Tiêm khóa giả: Kẻ tấn công lập tức gửi lệnh device/add_uv_key kèm theo một Public Key do chính chúng tạo ra gửi lên Cloud Authenticator. Đám mây chấp nhận khóa này mà không hề kiểm tra nó có xuất phát từ phần cứng an toàn hay không.
Vượt rào: Kẻ tấn công tự dùng khóa giả (đang nằm trong tay mình) để ký các yêu cầu. Đám mây trả về Assertion với cờ UV = 1, cho phép bypass hoàn toàn MFA.
Đáng chú ý, để hỗ trợ cho việc thao túng và thu thập dữ liệu phục vụ giả mạo trong quá trình này, hacker có thể lạm dụng thêm CVE-2026-34s348 (Điểm CVSS: 6.5) — lỗ hổng rò rỉ thông tin trong dịch vụ Windows Event Logging. Việc đọc các nhật ký nhạy cảm của hệ điều hành giúp mã độc bắt chước hệ thống một cách trơn tru.
Bước 4: Golden Pass-ta-key
Đây là đòn tấn công chí mạng: Lấy cắp "Chìa khóa vạn năng" (Master Key - SDS) để giải mã toàn bộ passkey đồng bộ. Luồng thực thi:
Ép thiết lập lại: Tương tự Silver, malware ép trình duyệt phải onboarding lại thiết bị với Cloud Authenticator.
Dò tìm bộ nhớ (Memory Dumping): Khi Chrome thực hiện phục hồi kết nối, nó sẽ kéo Master Key (Security Domain Secret - SDS) từ kho lưu trữ phục hồi của Google về. Khóa SDS dài 32-byte này xuất hiện dưới dạng văn bản thô (plaintext) trong một khoảng thời gian ngắn trên bộ nhớ của tiến trình Chrome.
Đánh cắp SDS: Malware dump (trích xuất) bộ nhớ Chrome và lấy được SDS.
Giải mã Offline: Dùng SDS, kẻ tấn công giải mã toàn bộ dữ liệu WebAuthn (thu được từ Stage 0).
Chiếm đoạt: Kẻ tấn công nắm trong tay tất cả các private key (khóa riêng tư) dạng thô của mọi dịch vụ nạn nhân dùng. Chúng có thể sử dụng, nhân bản, hoặc đem bán trên chợ đen, phá vỡ hoàn toàn nguyên lý cốt lõi của FIDO.
MITRE ATT&CK Mapping
T1555.003 - Credentials from Password Stores: Credentials from Web Browsers: Malware đọc dữ liệu từ LevelDB của Chrome để thu thập
WebauthnCredentialSpecifics.T1552.001 - Unsecured Credentials: Credentials In Files: Tìm kiếm và lạm dụng các file database lưu trữ dữ liệu xác thực cục bộ.
T1528 - Steal Application Access Token: Mặc dù Passkey không phải là Token, việc lạm dụng cơ chế ký (signing) tại chỗ tương đương với việc đánh cắp và duy trì phiên xác thực trái phép.
T1003 - OS Credential Dumping: Kỹ thuật dump bộ nhớ tiến trình Chrome (Golden Pass-ta-key) để trích xuất khóa SDS dạng plaintext.
Nhận định chuyên gia
Sự xuất hiện của Pass-ta-key là lời nhắc nhở thực tế khốc liệt: Passkey giải quyết rất tốt bài toán Phishing, nhưng nó lại chuyển toàn bộ rủi ro sang Endpoint Security.
Tại Việt Nam, nhiều tổ chức đang có xu hướng "nhảy cóc" lên passwordless để bảo vệ người dùng cuối. Tuy nhiên, tình trạng lây nhiễm mã độc (đặc biệt là infostealer như RedLine, Lumma, v.v.) qua các phần mềm crack/lậu cực kỳ phổ biến chính là "gót chân Achilles" của chiến lược này. Nếu endpoint đã bị thỏa hiệp, Passkey cũng không thể bảo vệ được người dùng.
Đặc biệt, một lỗ hổng thực thi nghiêm trọng nằm ở phía các Relying Parties (RP). Nhiều ứng dụng khi triển khai WebAuthn đã không yêu cầu hoặc không xác minh chặt chẽ cờ User Verified (UV) trong gói dữ liệu Authenticator trả về. Sự cẩu thả này vô tình biến xác thực đa yếu tố (MFA) thoái lui thành xác thực một yếu tố (Single-factor).
Khuyến nghị hành động
Kỹ thuật tấn công Pass-ta-key khai thác thẳng vào điểm yếu khi thiết bị đã nhiễm mã độc. Do đó, việc phòng thủ cần một chiến lược phối hợp giữa cả Đội ngũ kỹ thuật (RP) và Người dùng cuối.
Đối với Người dùng cuối (End-users)
Thận trọng với mã độc Infostealer: Hầu hết mã độc lấy cắp thông tin (như RedLine, Lumma) đều lây lan qua các phần mềm vi phạm bản quyền (crack), game lậu, hoặc tệp đính kèm email đáng ngờ. Tuyệt đối tránh tải xuống và chạy các tệp thực thi từ các nguồn không xác định.
Cập nhật hệ thống thường xuyên: Việc mã độc có thể tận dụng lỗ hổng hệ điều hành (như CVE-2026-34348) để hỗ trợ tấn công cho thấy tầm quan trọng của việc luôn giữ Windows và trình duyệt Chrome ở phiên bản mới nhất.
Cảnh giác với yêu cầu nhập mã PIN bất thường: Nếu Chrome hoặc Google Password Manager liên tục yêu cầu bạn nhập "Recovery PIN" (Mã PIN khôi phục) hoặc yêu cầu quét sinh trắc học một cách ngẫu nhiên khi bạn không chủ động đăng nhập, đó có thể là dấu hiệu mã độc đang cố ép hệ thống thiết lập lại (re-onboard) để đánh cắp Master Key.
Sử dụng phần mềm diệt virus (AV/EDR): Đảm bảo máy tính luôn được bảo vệ bởi phần mềm bảo mật uy tín có tính năng giám sát hành vi theo thời gian thực.
Đối với Tổ chức, Đội ngũ kỹ thuật & SOC
Vá lỗi hệ thống (Cấp bách 0-24h): Cài đặt ngay các bản cập nhật bảo mật mới nhất từ Microsoft để vá lỗ hổng. Việc bít lỗ hổng này sẽ cắt đứt một mắt xích giúp kẻ tấn công thu thập thông tin nhật ký (Event Logs).
Cấu hình bắt buộc User Verification (0-24h): Các Identity Teams/Developers phải kiểm tra lại quy trình xác thực WebAuthn/FIDO2. Bắt buộc yêu cầu
userVerification="required"và kiểm tra nghiêm ngặt cờUV = truetrên backend.Cấu hình giám sát SOC (0-24h): Thiết lập rules trên SIEM/EDR để monitor và block các tiến trình lạ (không phải Chrome.exe) cố gắng đọc vào thư mục
%LocalAppData%\Google\Chrome\User Data\*\Sync Data\LevelDB.Cập nhật dấu hiệu nhận diện (1-7 ngày): Cập nhật hệ thống Endpoint Protection/EDR của tổ chức để nhận diện các pattern của infostealer nhắm mục tiêu vào dữ liệu WebAuthn.
Đối với Chiến lược dài hạn
- Kết hợp chính sách Device Trust / Zero Trust Conditional Access. Xác thực passkey chỉ nên được máy chủ chấp thuận nếu thiết bị phát sinh yêu cầu là thiết bị "sạch" (đã cài EDR, tuân thủ chính sách công ty, không có dấu hiệu nhiễm mã độc).
Tài Liệu Tham Khảo
New Attack Methods Enable Malware to Hijack Passkey-Protected Accounts - SecurityWeek
New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA
Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
