iLeakage: Tấn công thực thi suy đoán không cần bộ đếm thời gian dựa trên trình duyệt nhắm vào thiết bị Apple
(ileakage.com)- Dù các biện pháp giảm thiểu Spectre đã được duy trì khoảng 6 năm, iLeakage cho thấy kênh bên thực thi suy đoán vẫn có thể bị khai thác trong Safari trên Mac, iPad và iPhone
- Kẻ tấn công dụ người dùng truy cập một trang web độc hại và nhấp chuột, sau đó dùng JavaScript và WebAssembly để khiến Safari kết xuất các trang web tùy ý và khôi phục thông tin nhạy cảm
- Các màn trình diễn bao gồm khôi phục tiêu đề tin nhắn gần đây trên Gmail, thông tin đăng nhập tự động điền của Instagram, lịch sử xem YouTube, cũng như mật khẩu Facebook và mã SMS 2FA trên MacBook Pro dùng Apple M3
- Phạm vi ảnh hưởng là các thiết bị macOS và iOS dùng CPU Apple A-series và M-series; đã được giảm thiểu trong iOS 17.2 và macOS 14.2, vốn bao gồm Safari 17.2
- Lockdown Mode hoặc tắt JavaScript cũng có thể ngăn chặn, nhưng đi kèm hạn chế về chức năng; do chạy bên trong Safari và không để lại dấu vết trong nhật ký hệ thống nên rất khó phát hiện
Nguy cơ Spectre tái lộ diện trên thiết bị Apple
- iLeakage là một cuộc tấn công kênh bên thực thi suy đoán nhắm vào trình duyệt web Safari
- Mục tiêu là các thiết bị macOS và iOS sử dụng CPU A-series hoặc M-series của Apple
- Bao gồm các mẫu iPhone và iPad gần đây
- Cũng bao gồm laptop và máy tính để bàn Apple từ năm 2020 trở về sau
- Về nguyên tắc, mã trong một tab trình duyệt không thể suy luận nội dung của tab khác, nhưng iLeakage có thể đọc nội dung trang web mục tiêu của người dùng đã truy cập và nhấp vào trang của kẻ tấn công
- Thông tin có thể khôi phục có thể bao gồm dữ liệu cá nhân, mật khẩu và thông tin thẻ tín dụng
- Nhóm nghiên cứu đã tiết lộ kết quả cho Apple vào ngày 12/9/2022, tức 408 ngày trước khi công bố rộng rãi
Dữ liệu nhạy cảm đã thực sự được khôi phục
- Nhóm nghiên cứu đã trình diễn các trường hợp khôi phục thông tin có giá trị cao từ các dịch vụ phổ biến
-
Thông tin đăng nhập Instagram
- Sử dụng tình huống người dùng đăng nhập Instagram trên Safari macOS bằng trình quản lý thông tin đăng nhập tự động điền LastPass
-
Hộp thư đến Gmail
- Giả định người dùng đã đăng nhập Google trên Safari iOS, nhóm khôi phục tiêu đề các tin nhắn gần đây trong tài khoản Gmail trên iPad
-
Lịch sử xem YouTube
- Khôi phục lịch sử xem YouTube trên Chrome cho iOS
- Do chính sách Apple App Store, Chrome cho iOS hoạt động như một lớp vỏ bên trên engine duyệt web Safari
-
Mật khẩu Facebook và mã 2FA
- Trước tiên khôi phục mật khẩu Facebook trong môi trường MacBook Pro trang bị chip Apple M3, macOS 14.1.1 và Safari 17.1
- Sau đó khôi phục mã SMS 2FA được gửi tới điện thoại Android thông qua Google Messages
Cách Spectre và kênh bên hoạt động
- Phần lớn CPU hiện đại sử dụng thực thi suy đoán, trong đó CPU dự đoán đường thực thi khi chưa có ngay kết quả rẽ nhánh và xử lý trước các lệnh trên đường đó
- Nếu dự đoán sai, CPU sẽ hoàn tác các thay đổi trạng thái, nhưng dấu vết vẫn có thể còn lại trong trạng thái vi kiến trúc như bộ nhớ đệm
- Spectre là một lỗ hổng phần cứng lợi dụng các dấu vết này để đọc dữ liệu mà theo ngữ nghĩa chương trình ban đầu không thể truy cập
- Kênh bên có thể khai thác đặc tính triển khai của hệ thống ngay cả khi chương trình chạy thuật toán an toàn
- Ví dụ gồm âm thanh, bức xạ điện từ, thermal throttling và việc chia sẻ tài nguyên vi kiến trúc CPU
- Khi kẻ tấn công và mục tiêu chạy trên cùng một CPU, chúng chia sẻ các tài nguyên như lõi, bộ nhớ đệm và bộ đệm nội bộ; sự cạnh tranh này có thể được đo gián tiếp qua các biến như thời gian hoặc mức tiêu thụ điện năng
Cấu hình tấn công không cần bộ đếm thời gian vượt qua phòng vệ của Safari
- Các nhà cung cấp trình duyệt đã tăng cường phòng vệ trước các cuộc tấn công thực thi suy đoán và thực thi tạm thời kể từ sau Spectre
- Phòng vệ của Safari bao gồm 35-bit addressing, value poisoning, chính sách cô lập tiến trình theo từng tab và bộ đếm thời gian độ phân giải thấp
- iLeakage là màn trình diễn tấn công thực thi suy đoán đầu tiên nhắm vào CPU Apple Silicon và Safari
- Cuộc tấn công bắt đầu bằng việc khôi phục thực nghiệm cấu hình bộ nhớ đệm chưa được công bố của CPU Apple
- Sau đó tạo một gadget dựa trên suy đoán có thể phân biệt cache hit và cache miss chỉ bằng bộ đếm thời gian độ phân giải thấp
- Nhóm cũng trình diễn một biến thể tận dụng race condition mà không cần bộ đếm thời gian
- Gadget này được dùng cho cả kiểm thử tạo eviction set lẫn covert channel
- Sau khi chuyển kỹ thuật sang Safari, nhóm khiến Safari thực thi mã dành cho một kiểu dữ liệu cụ thể trên đối tượng sai kiểu do kẻ tấn công tạo ra khi CPU đang thực thi suy đoán
- Kết quả cuối cùng là có thể đọc ngoài giới hạn ở bất cứ đâu trong không gian địa chỉ của tiến trình kết xuất Safari
- Kết hợp với một phương pháp mới để hợp nhất các website từ các miền khác nhau vào cùng một không gian địa chỉ, nhóm thực hiện cuộc tấn công speculative type confusion làm rò rỉ thông tin nhạy cảm
Biện pháp giảm thiểu, độ khó phát hiện và tác động theo từng trình duyệt
- iLeakage đã được giảm thiểu trong Safari 17.2; Safari 17.2 được bao gồm trong iOS 17.2 và macOS 14.2
- Cách ứng phó là cập nhật thiết bị Apple lên phiên bản hệ điều hành mới nhất
- Lockdown Mode giảm thiểu iLeakage bằng cách vô hiệu hóa biên dịch JIT của Safari
- Biên dịch JIT là tính năng hiệu năng mà iLeakage dùng để tạo primitive tấn công
- Lockdown Mode có thể thay đổi cách thiết bị hoạt động, chẳng hạn chặn một số tệp đính kèm tin nhắn và các cuộc gọi FaceTime từ người lạ
- Danh sách đầy đủ có trong tài liệu Lockdown Mode của Apple
- Tắt JavaScript cũng chặn được iLeakage, nhưng Safari có thể kết xuất một số website sai hoặc không đầy đủ, và các chức năng web nâng cao như thanh toán trực tuyến có thể không hoạt động
- iLeakage chạy bên trong Safari và không để lại dấu vết trong tệp nhật ký hệ thống nên rất khó phát hiện
- Tuy vậy, dấu vết truy cập trang web của kẻ tấn công có thể còn trong bộ nhớ đệm trình duyệt của các trang đã truy cập gần đây
- Chưa có bằng chứng bị khai thác trong thực tế
- Việc xây dựng một cuộc tấn công đầu cuối rất khó, đòi hỏi kiến thức nâng cao về tấn công kênh bên dựa trên trình duyệt và triển khai của Safari
- Vẫn nên tiếp tục dùng trình quản lý thông tin đăng nhập
- iLeakage có thể khôi phục thông tin đăng nhập đã được tự động điền trên trang web
- Nhiều nền tảng yêu cầu tương tác của người dùng để quá trình tự động điền diễn ra
- Chrome, Firefox và Microsoft Edge trên macOS dùng các JavaScript engine khác, nên iLeakage vốn khai thác đặc thù của JavaScript engine Safari sẽ không hoạt động
- Trên iOS, do chính sách Apple App Store và sandboxing, các ứng dụng trình duyệt khác cũng dùng JavaScript engine của Safari
- Chrome, Firefox và Edge cho iOS là các wrapper bên trên Safari, cung cấp các chức năng phụ trợ như đồng bộ dấu trang và cài đặt
- Hầu như mọi ứng dụng trình duyệt trên App Store đều dễ bị iLeakage
- Bài báo học thuật được cung cấp dưới dạng iLeakage paper và đã được đăng tại 2023 ACM Conference on Computer and Communications Security
1 bình luận
Ý kiến Hacker News
Có vẻ FAQ còn thiếu vài điểm: đây là lỗ hổng WebKit hay lỗ hổng Safari, trên Safari di động không có thiết lập nhà phát triển đó thì Lockdown Mode có giúp giảm thiểu hay không, và đã công bố cho Apple từ khi nào
Sau đó trang đã được cập nhật và câu hỏi cuối đã có lời đáp: nhóm nghiên cứu đã công bố kết quả cho Apple vào ngày 12 tháng 9 năm 2022, tức là 408 ngày trước khi phát hành công khai
Việc loại bỏ mọi gadget Spectre có thể có trong WebKit là không thực tế, nên trình duyệt phải tận dụng các biện pháp giảm thiểu Spectre của hệ điều hành bằng cách cô lập các website khác nhau vào các tiến trình khác nhau
Vì FAQ nói rằng “cuối cùng đạt được khả năng đọc ngoài phạm vi ở bất kỳ đâu trong không gian địa chỉ của tiến trình render Safari”, nên cá nhân tôi xem đây là lỗ hổng do triển khai sai cơ chế cô lập trang web của Safari
Việc nó có thể bị khai thác trong những môi trường nào phụ thuộc vào chi tiết triển khai của gadget dựa trên JavaScript dùng để gây ra và đo kênh kề này, và điều đó có thể nằm trong bài báo mà tôi vẫn chưa đọc
Lockdown Mode giúp giảm thiểu vì nó vô hiệu hóa biên dịch JIT trong Safari, đồng thời chặn các tính năng hiệu năng mà iLeakage dùng để tạo primitive tấn công
Với câu hỏi “dùng trình quản lý thông tin đăng nhập có nguy hiểm không?”, đa số trả lời là không, nhưng nếu có thứ gì đó đang rò rỉ khỏi bộ nhớ thì chẳng phải nó phải ảnh hưởng đến toàn bộ bộ nhớ trong không gian tiến trình Safari sao
Tôi không rành lĩnh vực này nên chưa hiểu vì sao việc có dùng trình quản lý thông tin đăng nhập hay không lại là một điều kiện ngoại lệ
Có vẻ họ muốn tránh việc mọi người quay lại kiểu đặt mật khẩu như “newpassword2”, và nếu tắt tự động điền rồi dùng phím tắt hoặc tương tác người dùng khác để điền thì sẽ an toàn hơn
Có thể đọc theo kiểu nếu không dùng trình quản lý mật khẩu, không lưu trong trình duyệt và tự gõ mỗi lần thì sẽ miễn nhiễm, nhưng đó là một phản biện không tốt vì nhiều lý do
Trình quản lý mật khẩu có lợi vì nhiều lý do khác, và ngay cả khi mật khẩu bị lộ thì ít nhất cũng chỉ làm tổn hại một website
Kỹ thuật này có lẽ cũng có thể đánh cắp token phiên, dù không tệ bằng lộ mật khẩu nhưng vẫn rất xấu
Nếu cấu hình để phải bấm vào trình quản lý mật khẩu mới điền thì cũng có thể chặn được cuộc tấn công này
Mật khẩu đã được tự động điền vào trang có thể bị khôi phục giống như mật khẩu tự gõ, nhưng không có nghĩa là có thể trực tiếp đọc ra toàn bộ mật khẩu được lưu trong trình quản lý mật khẩu
window.openMật khẩu được lưu trong ứng dụng quản lý mật khẩu riêng biệt thì không thể truy cập, trừ khi ứng dụng đó tự động điền vào cửa sổ hoặc tiến trình Safari đã bị xâm phạm
Cuộc tấn công lần này là tìm ra cách khiến hai origin khác nhau cùng chia sẻ một không gian địa chỉ, và tôi cho rằng nó không áp dụng cho extension
Bài báo viết: “Bằng cách khai thác chính sách cô lập trang web của Safari, chúng tôi chỉ ra một kỹ thuật mới cho phép trang của kẻ tấn công chia sẻ không gian địa chỉ với một trang nạn nhân tùy ý chỉ bằng cách mở nó qua JavaScript API
window.open”Tôi hơi bối rối không biết cách đóng khung đây là thứ chỉ dành riêng cho WebKit có thực sự đúng không. Bản thân việc khai thác cache có vẻ là chuyện phổ biến, và ngay trong đoạn trích cũng nói rằng nó cho độ chính xác gần như hoàn hảo trên Safari, Firefox và Tor
Tôi cũng thắc mắc liệu tấn công qua
window.open()có thật sự chỉ riêng WebKit hay chỉ là vì nghiên cứu này đào sâu vào WebKit hơnwindow.open()ngụ ý một ngữ cảnh chia sẻ trong đó cửa sổ gọi nhận tham chiếu tới cửa sổ mới, còn cửa sổ mới có tham chiếu ngược quawindow.opener, nên tôi cũng nghi ngờ liệu các engine trình duyệt khác có đạt được cách ly hoàn toàn hay khôngTrên trình duyệt di động thì cơ chế cô lập trang web của Chromium còn hạn chế, còn Firefox vẫn chưa hoàn tất triển khai
https://www.chromium.org/Home/chromium-security/site-isolati...
Thật khó hiểu. Trông đây như một vấn đề có mức độ nghiêm trọng cao, nhưng bản sửa lại nằm sau menu gỡ lỗi. Không rõ vì sao nó bị công bố trước khi được phát hành đúng cách đến mọi nơi
Điều này cũng cho thấy các biện pháp giảm thiểu kênh kề về cơ bản là vô dụng và không nên giả vờ rằng các kiểu tấn công như thế này đã được khắc phục
Nếu là máy chủ chạy nhiều ứng dụng trên CPU hiện đại, thì việc chạy mã không đáng tin cậy là không an toàn dù có sandbox kỹ đến đâu
So với việc để người dùng Apple tiếp tục bị phơi nhiễm thêm hơn 1 năm mà không hề biết rủi ro, tôi nghĩ thà thông báo rủi ro còn tốt hơn nhiều
Tôi đồng ý nên cho công ty thời gian sửa lỗi, nhưng đến một thời điểm nào đó thì việc không thông báo cho những người bị ảnh hưởng còn vô trách nhiệm hơn
Bài báo giải thích rằng việc thoát khỏi sandbox JavaScript suy đoán vẫn có thể xảy ra, nhưng kẻ tấn công bị giới hạn trong việc đọc không gian địa chỉ và dữ liệu của chính mình
Tại thời điểm viết bài, bản vá Apple đã được công khai và được triển khai trong Safari Technology Preview 173 trở lên, và [57] là https://github.com/WebKit/WebKit/pull/10169
Bên dưới đó, một kỹ sư vẫn tiếp tục liên kết thêm các bản vá tăng cường cho
window.open()và cô lập tiến trìnhSwap Processes on Cross-Site Window Openđã được bật sẵn và được đánh dấu là StableKhông phải do tôi tự bật, nên tôi nghĩ có thể Apple đã kích hoạt rồi và phần mô tả đã lỗi thời, nhưng sau đó tôi nhận ra mình đang nhìn nhầm
Swap Processes on Cross-Site Navigation, tên gần giống nhưng khác, và có vẻ hiện chưa được bật mặc địnhNên trách Apple vì đã chần chừ lâu như vậy hơn là trách nhóm nghiên cứu đã công bố trước khi bản vá được phát hành
Không phải mọi cuộc tấn công kênh kề đều đã được sửa, nhưng nói rằng các biện pháp giảm thiểu kênh kề là vô dụng thì không phù hợp
Cũng như đeo dây an toàn không có nghĩa là sẽ không ai chết trong tai nạn ô tô, nhưng không vì thế mà dây an toàn trở nên vô dụng; biện pháp giảm thiểu làm tăng đáng kể độ khó khai thác
“Các nhà nghiên cứu đã tiết lộ kết quả cho Apple vào ngày 12 tháng 9 năm 2022”, nên tôi thực sự tò mò vì sao Apple lại gần như để mặc nó suốt hơn 1 năm
Apple là một trong những ông trùm CVE, nên họ có thể từ chối cấp CVE cho lỗi trong sản phẩm của chính mình, và khi có quyền lực như vậy thì họ có thể chậm chạp bao lâu tùy thích
Tôi cứ nghĩ mình đã thấy dòng chữ về bản sửa trên trang web iLeakage, nhưng giờ nó biến mất. Tôi tưởng mình nhớ nhầm, nhưng thực ra trang web đã thay đổi trong vòng một giờ qua
Đã từng có dòng “Apple vừa phát hành iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1, hãy cập nhật thiết bị của bạn”, nhưng giờ đã bị hoàn tác
https://github.com/ileakage-authors/ileakage-authors.github....
Sau khi tôi chỉ ra rằng trang web không có lịch công bố, một mục ngắn đã được thêm vào FAQ, và có vẻ ngay cả nhóm nghiên cứu cũng bắt đầu bối rối vì tình hình phát hành bản vá quá khó hiểu
Swap Processes on Cross-Site Navigationvà nó được bật mặc địnhTôi tự hỏi liệu nó có khác với
Swap Processes on Cross-Site Window Opentrên macOS hay khôngCâu “iLeakage là một cuộc tấn công khá khó để thực hiện trọn vẹn và đòi hỏi kiến thức chuyên sâu về tấn công kênh kề dựa trên trình duyệt cũng như cách Safari được triển khai” có thể là lý do Apple không quá bận tâm
Việc còn gắn thêm một biệt danh đáng sợ và cả tên miền riêng nữa khiến nó trông không chuyên nghiệp cũng không đáng tin lắm
Nếu phạm vi ảnh hưởng là các thiết bị macOS hoặc iOS dùng CPU Apple dòng A hoặc M, tức các iPhone/iPad gần đây và laptop, desktop Apple từ năm 2020 trở đi, thì với tư cách là một người dùng Intel Mac hiếm hoi, có vẻ tôi không bị ảnh hưởng
Chỉ khác đôi chút ở hệ thống phân cấp cache, và bản proof of concept có lẽ chỉ cần chỉnh sửa nhẹ
Nếu là iOS thì phải dùng Lockdown Mode, đó là cách duy nhất để dùng iPhone an toàn
Không có Lockdown Mode thì một benchmark cũng vô nghĩa chẳng khác nào chạy benchmark CPU với
mitigations=offĐây là thêm một lý do chính đáng nữa để cho phép các engine trình duyệt khác trên thiết bị iOS
Nếu gặp lỗi khi chạy lệnh dưới đây, hãy cấp Full Disk Access cho Terminal rồi thử lại
defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1