Microsoft Edge lưu mọi mật khẩu ở dạng văn bản thuần trong bộ nhớ ngay cả khi không sử dụng

• Microsoft Edge giải mã toàn bộ mật khẩu đã lưu ngay khi khởi động và giữ các thông tin xác thực đó trong bộ nhớ tiến trình ở dạng văn bản thuần
• Hành vi này xảy ra ngay cả khi người dùng không truy cập các trang web sử dụng những thông tin xác thực đó
• Giao diện Password Manager của Edge vẫn yêu cầu xác thực lại trước khi hiển thị cùng mật khẩu đó, nhưng tiến trình trình duyệt thực tế đã giữ sẵn toàn bộ mật khẩu ở dạng văn bản thuần
• Trong số các trình duyệt nền tảng Chromium được thử nghiệm, chỉ Edge hoạt động theo cách này; Chrome được thiết kế để việc chỉ đọc và trích xuất mật khẩu đã lưu từ bộ nhớ tiến trình trở nên khó hơn
• Chrome chỉ giải mã khi cần thông tin xác thực, và dùng App-Bound Encryption (ABE) để gắn việc giải mã với tiến trình Chrome đã được xác thực, ngăn các tiến trình khác tái sử dụng khóa mã hóa của Chrome
• Nhờ cơ chế kiểm soát này, mật khẩu dạng văn bản thuần chỉ xuất hiện trong thời gian ngắn khi tự động điền hoặc khi người dùng tự xem, làm giảm hiệu quả của việc quét bộ nhớ trên diện rộng

Các kịch bản rủi ro và tình trạng công khai

• Trong môi trường dùng chung, rủi ro do giữ mật khẩu dạng văn bản thuần trong bộ nhớ tăng lên
• Nếu kẻ tấn công có được quyền quản trị viên trên máy chủ terminal, chúng có thể truy cập bộ nhớ của tiến trình thuộc mọi người dùng đang đăng nhập
• Trong phần trình diễn, một kẻ tấn công đã chiếm được tài khoản người dùng có quyền quản trị viên có thể xem thông tin xác thực đã lưu của hai người dùng khác đang đăng nhập hoặc đã ngắt kết nối nhưng vẫn đang chạy Edge
• Hành vi này đã được báo cho Microsoft, và phản hồi chính thức là đây là hành vi “by design”
• Tác giả cũng đã thông báo với Microsoft rằng sẽ chia sẻ theo hướng công bố có trách nhiệm để người dùng và tổ chức có thể tự đánh giá cách quản lý thông tin xác thực của mình
• Vào thứ Tư, ngày 29 tháng 4, nội dung này đã được công bố tại BigBiteOfTech của Palo Alto Networks Norway, kèm phần trình diễn một công cụ đơn giản có thể dễ dàng kiểm tra liệu mật khẩu có đang được lưu ở dạng văn bản thuần trong bộ nhớ hay không
• Công cụ proof-of-concept đã được công khai trên GitHub, và tác giả đang tìm kiếm phản hồi vì chưa có nhiều kinh nghiệm với C# và phát hành trên GitHub: EdgeSavedPasswordsDumper

[GN⁺]

Ý kiến trên Hacker News

• Chuyện này gần như thuộc kiểu đã ở sẵn bên trong cánh cửa kín rồi. Nếu có thể đọc bộ nhớ của tiến trình tùy ý, rất có thể bạn cũng đang ở vị trí có thể giả mạo người dùng đó và đơn giản dump mật khẩu ra
  Nếu kẻ tấn công có quyền quản trị máy chủ terminal server thì họ có thể truy cập bộ nhớ của mọi tiến trình người dùng đang đăng nhập, và nếu có quyền quản trị thì cũng có thể gắn debugger vào mọi tiến trình Chrome để ép giải mã mật khẩu
  Khác biệt thực sự chắc chỉ cỡ tấn công khởi động nguội thôi, mà ngay cả khi đó cũng chưa rõ là nó chỉ làm cuộc tấn công dễ hơn một chút hay biến một cuộc tấn công vốn bất khả thi thành khả thi
  [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
  • Lập luận này hoàn toàn khớp với mô hình đe dọa của Chromium. Khoảnh khắc kẻ tấn công có quyền quản trị thì theo định nghĩa là game over
    Có vẻ khó mà là vấn đề riêng của Edge, và cũng không có lý do gì để Microsoft làm trình duyệt kém an toàn hơn dự án thượng nguồn
    Chrome xem các cuộc tấn công cục bộ về mặt vật lý là nằm ngoài mô hình đe dọa; nếu ai đó đã đăng nhập vào thiết bị của tôi với tư cách tôi, hoặc có thể chạy phần mềm dưới quyền người dùng hệ điều hành của tôi, thì Chrome hay bất kỳ ứng dụng nào cũng không có cách phòng vệ
    Những kẻ tấn công như vậy có thể sửa file thực thi và DLL, thay đổi biến môi trường như PATH, sửa file cấu hình, đọc dữ liệu tài khoản người dùng và chuyển nó ra ngoài, nên lập trường là Chrome không thể đưa ra bảo đảm phòng vệ thực chất nào
    https://chromium.googlesource.com/chromium/src/+/148.0.7778....
  • Trong vài năm gần đây cũng đã có các lỗ hổng trình duyệt cho phép đọc bộ nhớ tùy ý chỉ với quyền người dùng thông thường, chỉ là chúng chậm hoặc không kiểm soát hoàn toàn được vị trí. Xóa thông tin xác thực càng sớm càng tốt sau khi dùng, dù chỉ là đào thêm một vòng hào, vẫn là biện pháp phòng ngừa khá hợp lý
  • Bảo mật không phải trắng đen. Dán giấy nhớ có ghi thông tin đăng nhập lên màn hình rõ ràng nguy hiểm hơn cất nó trong một ngăn kéo không khóa — có các mức độ khác nhau như vậy
  • Từ góc nhìn người dùng thì mỗi lần muốn dán mật khẩu, trước hết lại phải đăng nhập bằng xác thực sinh trắc học, vậy mà bất kỳ tiến trình người dùng nào cũng có thể câu mật khẩu từ bộ nhớ sao?
    Tôi không rõ mình đang bỏ sót điều gì
  • Mọi người quên Cloudbleed rồi sao?
    [0] https://en.wikipedia.org/wiki/Cloudbleed
• Để tham khảo, Google giải thích rằng Chrome lưu mật khẩu trong bộ nhớ dưới dạng được mã hóa, và dùng dịch vụ nâng quyền để tiến trình khác không thể giả làm Chrome rồi truy cập mật khẩu dạng rõ: https://security.googleblog.com/2024/07/improving-security-o...
• Nói cho rõ, một trong các đường tấn công khả dĩ là: bạn đi vệ sinh 5 phút mà không khóa máy, và một hacker độc hại có thể dump toàn bộ mật khẩu trước khi bạn quay lại
  Tôi nghĩ điều này đáng để cân nhắc. Có lý do mà trình quản lý mật khẩu sau 10 phút lại yêu cầu nhập lại mật khẩu chủ hoặc passkey
  Tôi đã nghĩ Chrome dựa vào một vùng bảo mật được mã hóa, nên ngay cả có quyền root thì việc trích xuất mật khẩu dễ dàng vẫn là khá khó
  Dĩ nhiên không nên bỏ mặc máy tính. Nhưng điều đó không có nghĩa là cứ thiết kế sản phẩm theo cách khiến một sai lầm khó tránh bị khai thác thành hậu quả nghiêm trọng là được
• Công cụ này có đang truy cập một instance Edge đang chạy trên cùng máy không? Nếu vậy chẳng phải cứ xuất trực tiếp các mật khẩu đã lưu là xong sao?
  https://support.microsoft.com/en-us/topic/export-passwords-i...
  • Các trình quản lý mật khẩu thường bỏ khá nhiều công sức để giữ an toàn cho mật khẩu trong bộ nhớ, nhưng nhiều khi mô hình tấn công của các công cụ đó lại không được hiểu rõ
    Ví dụ, các công cụ như KeePass khá cẩn thận về việc đăng ký plugin trình duyệt, nhưng nếu chỉ cần quyền người dùng thông thường là có thể lấy khóa đó từ trình duyệt và làm bất cứ gì thì sao
    Những kiểu “tin cậy trình duyệt này” của ứng dụng web cũng nghe có vẻ kỳ lạ nếu kho cookie có thể bị đọc quá dễ dàng
• Trên Linux, PAM dường như cũng có thể làm chuyện tương tự. Chỉ cần gắn gdb vào tiến trình đăng nhập openssh hoặc getty
• Có link mã nguồn của file .exe này không? Tôi muốn xem nó trích xuất bằng cách nào
• Sai lầm thật sự là chúng ta vẫn còn dùng xác thực bằng mật khẩu đơn thuần. Nên dùng challenge-response hoặc xác thực khóa công khai
• Nói công bằng thì, được nạp vào bộ nhớ và được lưu trữ không hẳn là cùng một chuyện
  • Tiêu đề nói là “lưu trong bộ nhớ”, mà với tôi nghe gần như giống nhau. Bạn có thể giải thích bạn nhìn nhận khác biệt giữa việc “nạp” vào bộ nhớ và “lưu” trong bộ nhớ như thế nào không?
• Có thể tôi nhớ nhầm, nhưng Chrome trên Windows cũng từng giữ mật khẩu ở dạng văn bản thô, hoặc ít nhất trước đây là vậy. Tôi từng lấy lại mật khẩu mà một người bạn quên từ Chrome bản 2021
  • Chuyện này là vài năm trước, nhưng tôi nhớ đã thấy các nhà phát triển Google tranh luận rằng nếu đã có quyền truy cập hệ thống file cục bộ thì coi như xong rồi
  • Chrome đã thêm mã hóa ràng buộc ứng dụng cho file cookie vào năm 2024