- Pixnapping là một kỹ thuật tấn công mới cho phép ứng dụng Android độc hại âm thầm đánh cắp thông tin cá nhân hiển thị trên ứng dụng hoặc trang web khác
- Cuộc tấn công này lợi dụng API Android và kênh kề phần cứng GPU, ảnh hưởng đến hầu hết các thiết bị mới nhất của các hãng lớn như Google, Samsung
- Mọi thông tin hiển thị trên màn hình như mã xác thực, cuộc trò chuyện, email đều có thể bị lộ và có thể bị tấn công ngay cả khi không có quyền ứng dụng
- Trên Google Authenticator, có thể đánh cắp mã xác thực hai lớp trong vòng 30 giây
- Cả Google lẫn các nhà cung cấp GPU hiện đều thiếu bản vá hay biện pháp ứng phó chắc chắn để giảm thiểu cuộc tấn công này
Tổng quan
- Pixnapping là một cuộc tấn công cho phép ứng dụng Android độc hại đánh cắp thông tin hiển thị trên ứng dụng hoặc trang web khác mà người dùng không hề hay biết
- Rò rỉ thông tin diễn ra bằng cách lạm dụng kênh kề (side channel) của API Android và GPU, và ảnh hưởng đến phần lớn smartphone Android gần đây như thiết bị của Google và Samsung
- Các ứng dụng đã được xác nhận chịu ảnh hưởng gồm Gmail, Signal, Google Authenticator, Venmo, Google Maps; ngay cả mã 2FA của Google Authenticator cũng có thể bị đánh cắp trong vòng 30 giây
Bài nghiên cứu và bản trình diễn
- Dự kiến sẽ được công bố tại ACM CCS 2025 qua bài báo “Pixnapping: Bringing Pixel Stealing out of the Stone Age”
- Có thể xem trước bản preprint của bài báo để nắm nguyên lý tấn công và chi tiết kỹ thuật
Hỏi đáp chính
Thiết bị nào bị ảnh hưởng
- Đã được chứng minh thực nghiệm trên Google Pixel 6, 7, 8, 9, Samsung Galaxy S25 chạy Android 13~16
- Khả năng cao nguyên lý tấn công cốt lõi cũng hoạt động tương tự trên thiết bị của các hãng khác
Điều kiện tấn công
- Mọi ứng dụng Android không có quyền cũng có thể thực hiện tấn công
- Có thể kích hoạt ngay cả khi không khai báo quyền riêng nào trong file manifest của ứng dụng
Có thể đánh cắp loại thông tin nào
- Mọi thông tin hiển thị trên màn hình (trò chuyện, mã xác thực, email, v.v.) đều là mục tiêu tấn công
- Thông tin nội bộ không hiển thị trên màn hình thì không thể bị rò rỉ
Trường hợp bị khai thác ngoài thực tế
- Hiện chưa xác nhận liệu lỗ hổng này đã bị khai thác ngoài thực tế hay chưa
Cách người dùng tự bảo vệ
- Khuyến nghị cài đặt ngay mỗi khi có bản vá bảo mật Android mới
Cách nhà phát triển tự bảo vệ
- Hiện chưa xác định được biện pháp phòng vệ hay cách né tránh hiệu quả
- Nếu có insight liên quan đến bảo mật, nhóm nghiên cứu đề nghị liên hệ trực tiếp
Nguyên lý hoạt động của cuộc tấn công
- Ứng dụng độc hại gọi ứng dụng mục tiêu (ví dụ: Google Authenticator) để khiến thông tin nhạy cảm được render lên màn hình
- Trên màn hình ứng dụng mục tiêu, nó buộc áp dụng phép xử lý đồ họa (như blur) lên pixel cụ thể
- Dùng kênh kề như GPU.zip để trích xuất các pixel ở bước 2, từng pixel một
- Lặp lại bước 2 và 3 để khôi phục toàn bộ pixel, sau đó dùng OCR để trích xuất nội dung gốc
- Hiệu ứng này tương tự việc ứng dụng độc hại chụp ảnh màn hình của phần hiển thị mà bình thường nó không thể truy cập
API Android bị lạm dụng
- Sử dụng window blur API để áp dụng xử lý đồ họa (blur) lên vùng pixel nhạy cảm
- Dùng callback VSync để đo thời gian render và khai thác việc trích xuất theo từng pixel
Bản vá và phản ứng của Google
- Google đã đối phó bằng cách giới hạn số lượng activity xử lý blur mà ứng dụng có thể gọi, nhưng nhanh chóng xuất hiện biện pháp vượt qua (workaround)
- Workaround này hiện vẫn đang trong trạng thái chưa công khai (embargo)
Kênh kề ở mức phần cứng
- Trích xuất thông tin pixel bằng kênh kề dựa trên GPU có tên GPU.zip
- Tính đến tháng 10/2025, các nhà sản xuất GPU vẫn chưa có kế hoạch vá riêng
Thông tin định danh lỗ hổng (CVE)
- Đã được đăng ký chính thức với mã CVE-2025-48561
Ảnh hưởng đến hệ điều hành khác hay không
- Android trở thành mục tiêu vì cho phép ứng dụng thực hiện phép toán đồ họa lên dữ liệu màn hình của ứng dụng khác và đo side effect phát sinh
- Chưa xác nhận khả năng áp dụng với hệ điều hành khác
Lỗ hổng bổ sung App List Bypass
- Còn tồn tại lỗ hổng app list bypass cho phép xác định danh sách các ứng dụng khác đã cài đặt mà không cần quyền riêng hay khai báo manifest
- Lỗ hổng này có thể được dùng để lập hồ sơ người dùng, và khác với các cách vượt qua trước đây ở chỗ nó hoạt động mà không cần khai báo bổ sung
- Google đánh giá đây là vấn đề “Infeasible” và khép lại mà không có biện pháp xử lý riêng
Logo, mã nguồn và giấy phép
Ứng phó và các mốc thời gian chính
- Từ tháng 2 đến tháng 10/2025, lỗ hổng đã được tiết lộ theo từng giai đoạn cho Google và Samsung, đồng thời yêu cầu phản ứng xử lý
- Google phân loại mức độ rủi ro của Pixnapping và app list bypass là High/Low; một số bản vá được đánh giá là chưa đủ hoặc không thể sửa (Fix không khả thi)
- Dự kiến có thêm bản vá trong thông báo bảo mật Android tháng 12/2025
Tóm tắt
- Pixnapping là một cuộc tấn công có thể rò rỉ trái phép thông tin quan trọng trên màn hình thực tế bằng cách khai thác kết hợp lỗ hổng trong cấu trúc quyền ứng dụng và cách phần cứng vận hành
- Cả bảo mật phần mềm Android lẫn bảo mật phần cứng đều đang cần các biện pháp cải thiện mang tính cấu trúc
1 bình luận
Ý kiến trên Hacker News
Tôi cho rằng vấn đề cốt lõi là hệ thống quyền của Android mặc định cho phép "chạy nền" hoặc "truy cập Internet" mà không cần người dùng cho phép; các kiểu tấn công như vậy khả thi vì mọi ứng dụng—ngay cả game offline—đều mặc định có các quyền này. Nhiều ứng dụng chỉ nên được phép truy cập Internet "khi đang sử dụng ứng dụng"; điều này không phải bảo vệ hoàn hảo, nhưng vì luôn có rủi ro vô tình chạy phải ứng dụng độc hại, nó có thể làm giảm đáng kể hiệu quả của cuộc tấn công.
Tôi tự hỏi không biết có nghiên cứu nghiêm túc nào về rủi ro của tự động cập nhật so với cập nhật thủ công/không cập nhật hay không, đặc biệt là trong môi trường bán sandbox như Android; muốn hỏi liệu có nghiên cứu so sánh tỷ lệ lỗi nào như vậy không.
Thực ra quyền truy cập Internet có tồn tại, và trên GrapheneOS có thể từ chối hoàn toàn truy cập Internet đối với các ứng dụng khai báo quyền đó.
Có một câu trả lời khá thuyết phục về lý do vì sao ứng dụng Android không phải xin phép người dùng cho quyền truy cập Internet; đây là câu trả lời trực tiếp từ nhóm phát triển Android nguồn. Còn về "chạy nền", vì Android dựa trên "intent" nên ứng dụng có thể bị đánh thức bất cứ lúc nào, do đó một tùy chọn đơn giản kiểu "cấm chạy nền" có thể sẽ không hoạt động theo cách người dùng mong đợi.
Dù đã xem video, tôi vẫn thấy khó hiểu cuộc tấn công này hoạt động như thế nào; tôi thắc mắc liệu sau khi chuyển sang ứng dụng khác thì vẫn có thể truy cập vào các pixel của ứng dụng xác thực hay không.
Trước câu hỏi các nhà phát triển ứng dụng nên làm gì để bảo vệ người dùng, dù nói là chưa có biện pháp đối phó công khai, tôi nghĩ vẫn có thể thử vài cách cơ bản; ví dụ không cố định vị trí mã trên màn hình, ẩn nó khi chạy nền, liên tục di chuyển mã, thay đổi màu sắc/độ tương phản, hiển thị nhiễu tĩnh, hoặc chỉ cho một phần mã nhấp nháy rất ngắn thay vì hiện toàn bộ. Tất nhiên những cách này sẽ ảnh hưởng phần nào đến UX, nhưng về mặt lý thuyết có thể nâng độ khó cho kẻ tấn công lên khá nhiều. Tuy vậy, tôi cũng nói rõ rằng nếu đã có thông tin bí mật bị cache dưới dạng screenshot thì những biện pháp này sẽ có giới hạn.
Tôi nhớ Google Authenticator trước đây từng đổi sang kiểu phải chạm mới hiện mã TOTP. Khi đó tôi nghĩ nó không thực sự ngăn được mối đe dọa nào mà chỉ gây bất tiện, và nhiều người cũng đồng ý nên chẳng bao lâu sau tính năng đó đã bị âm thầm rollback. Tôi thắc mắc không biết đó có phải là biện pháp phòng ngừa sớm cho lỗ hổng này hay không.
Giới thiệu demo unscreenshottable.vercel.app.
Về TOTP, tôi nhấn mạnh rằng để cuộc tấn công này khả thi trong thực tế thì font và vị trí pixel phải được biết chính xác. Theo bài báo, việc đánh cắp các vùng màn hình nhạy cảm mất khá nhiều thời gian; ví dụ mã 2FA mặc định làm mới mỗi 30 giây nên có giới hạn thời gian rất chặt. Nếu kẻ tấn công không lấy được đủ cả 6 chữ số trong vòng 30 giây thì giá trị sẽ biến mất. Tuy nhiên, nếu font đã được kẻ tấn công biết trước thì chỉ cần rò rỉ vài pixel cũng có thể phân biệt được.
Đây là kỹ thuật đã tồn tại từ trước, nhưng rất hiệu quả khi nhắm mục tiêu chính xác. Nếu bạn có thể cài một ứng dụng cụ thể lên điện thoại của người dùng thì thật ra không cần làm quá phức tạp; bạn có thể dùng chính ứng dụng đó để truy cập thông tin mình muốn. Ví dụ, như Facebook, nếu hiện một thông báo quyền riêng tư kiểu "ứng dụng này sẽ định kỳ chụp màn hình", sẽ có số lượng đáng kinh ngạc người cứ thế cho phép. Mã nguồn Pixnapping được nói là sẽ công bố ở đây khi việc vá lỗi khả thi, nhưng thực ra có vẻ reverse engineering cũng không khó lắm. Họ có thể đã chờ đến khi được vá xong, nhưng có vẻ các nhà nghiên cứu muốn thu hút sự chú ý sớm hơn.
Bản vá lỗ hổng ban đầu thực ra đã được công bố; ngay trong thông điệp của commit liên quan cũng ghi rõ "ngăn đánh cắp pixel bằng cách đo thời gian làm mờ giữa các cửa sổ". Lý do các nhà nghiên cứu chưa công bố mã là vì họ phát hiện có cách обход bản vá đó. Họ còn nói thêm rằng "không có vendor GPU nào hứa sẽ vá GPU.zip" và "Google cũng không có ý định vá lỗ hổng bypass danh sách ứng dụng" ("đóng với trạng thái không sửa"). Xét ngày báo cáo ban đầu là 24 tháng 2 năm 2025 thì khó nói là các nhà nghiên cứu đã vội vàng. Và dù có thông báo kiểu "ứng dụng này đang định kỳ chụp màn hình", những màn hình được thiết lập rõ ràng là không cho chụp màn hình vẫn không thể bị chụp nếu không có exploit riêng.
Ngày báo cáo đầu tiên cho Google là 24 tháng 2 năm 2025; họ đã cho đủ thời gian.
Tôi công nhận đây là một kỹ thuật thông minh tận dụng thời gian render (side channel). Ngay cả với Google Authenticator, để thu thập toàn bộ pixel cũng mất khá nhiều thời gian. Điều tôi lo hơn là phương pháp này có thể áp dụng đến mức nào để đánh cắp OTP từ tin nhắn văn bản. Các email phishing với mẫu cố định như email thông báo GitHub cũng ngày càng nhiều, nên tôi đã ngừng bấm liên kết trong email; giờ tôi cũng nghĩ nên tránh cả việc mở ứng dụng qua gợi ý intent. Tốt hơn là tự mở ứng dụng, tự làm việc cần làm, và xóa những ứng dụng vô dụng. Bề mặt tấn công còn có thể mở rộng qua SDK hoặc web page intent, nên tôi cho rằng khía cạnh này bị xem nhẹ quá nhiều.
Tôi cứ tưởng đây là game trên web browser nên chỉ nhìn tiêu đề rồi đi tìm.
Tôi không phải chuyên gia bảo mật, nhưng tôi nghĩ nếu cài ứng dụng trên desktop Windows thì có thể tấn công nhanh hơn và kín đáo hơn nhiều so với pixnapping trên Android. Nếu dùng cùng một mật khẩu cho nhiều website, một bên có thể đánh cắp mật khẩu đó để đăng nhập sang nơi khác (nếu không có lớp bảo vệ bổ sung). Về lý thuyết thì bảo mật khá yếu, nhưng trên thực tế kiểu tấn công này không hẳn là phổ biến hay dễ thực hiện.
Có liên kết đến thảo luận trước.
Tôi nghĩ thiết bị hiện đại đã trở nên quá phức tạp nên bảo mật hoàn hảo là bất khả thi. Có quá nhiều tính năng không thực sự cần thiết cứ liên tục được thêm vào nên mới sinh ra chuyện như vậy. Tôi tin rằng về sau nhu cầu với các OS tập trung vào bảo mật, chỉ chứa tính năng tối thiểu như FreeBSD, sẽ ngày càng tăng.
Tôi muốn có một môi trường mà ngay cả lúc đang di chuyển cũng có thể
make worldtrong terminal.Có Precursor do Bunnie tạo ra; nó rất ngầu nhưng tôi thấy quá đắt. Nếu bạn thấy một chiếc máy tính cầm tay giá $100 đã đắt, thì Precursor có hình thức khá giống và sức mạnh tính toán cũng tương tự nhưng lại có giá tới $1000, mà cũng không thể mang vào phòng thi toán. Blog chính thức của Precursor (hiện không truy cập được, có thể sau này sẽ mở lại).
Sau vài năm đọc bình luận trên hn, tôi có cảm giác kiến thức và thực hành bảo mật đã thụt lùi đáng kể, và có lẽ sự lan rộng của AI tạo sinh sẽ còn làm tình hình tệ hơn. Dạo này cũng có nhiều người vừa nói về dự án điện thoại của fsf vừa than phiền rằng dùng ứng dụng ngân hàng trên di động rất bất tiện. Cũng có người than việc phải nhập mật khẩu mỗi 30 phút trên desktop là phiền phức, rồi nhiều lời phàn nàn kiểu "chẳng lẽ phải mang hai chiếc điện thoại". Theo tôi, nếu kẻ trộm điện thoại chỉ cần nhìn thấy cảnh bạn nhập mật khẩu, chúng sẽ lập tức mở app ngân hàng, app tiền bạc và cố lấy càng nhiều dữ liệu càng tốt. Thực tế ngày nào cũng có những vụ như vậy. Tốt nhất là đừng cài các ứng dụng đó lên điện thoại, hoặc ít nhất đừng để chúng ở trạng thái đã đăng nhập; ứng dụng 2FA cũng vậy. Làm như thế chẳng khác nào mang một chiếc vali du lịch hàng hiệu đắt tiền và tự biến mình thành mục tiêu. Nếu bạn không phải CEO hay mục tiêu của tấn công cấp quốc gia thì càng nên cẩn trọng hơn. Thiết bị chạy "OS bảo mật tối giản" về bản chất vẫn còn vấn đề bị cướp thiết bị vật lý (ai đó nhìn thấy mật khẩu rồi lấy máy), nhưng điện thoại dùng để chơi game, cài app quảng cáo ở quán bar với điện thoại dùng cho ngân hàng, 2FA và công việc nên được tách biệt hoàn toàn.